I need someone help me and share a programe 2 me.Help me... ok... Peace..:sad:

thanks for your idea...

Recommended Answers

All 25 Replies

you will have to be a tad bit more specific because there are millions of programs.:mrgreen:

you will have to be a tad bit more specific because there are millions of programs.:mrgreen:

That's just mean...
Here's a program for you:

#include <stdio.h>
 
int main()
{
    return 0;
}

I'm joking as you might have noticed :mrgreen:
Ancient Dragon is right, what do you want and what have you made so far?

Niek

that's in fact an excellent program. It compiles, it runs, and all without errors.

With the only problem being the wrong prototype of main....:D

I see nothing wrong with his main() -- argc and argv parameters are optional.

I see nothing wrong with his main() -- argc and argv parameters are optional.

I guess he's talking about empty parameter lists being deprecated in C. And old C headers are deprecated in C++ so that program is somewhere in between C and C++.

But let's be serious and remember that the chances of either of those causing a problem are vanishingly small. :)

In C, when a function defination or declaration is followed by an empty pair of parentheses it means that zero or more parameters. So main when written as int main( ) in C can stand for int main( int, int, int ) or int main( void, void ) or whatever, whereas the standard specifically says that the prototype of main can only be either int main( void ) or int main( int argc, char** argv ) . Hence the explicit void is required in case of pure C programs.

Whereas in C++ when a function defination or declaration is followed by an empty pair of parentheses it means it does not take any argument i.e. void . Hence the void can be safely omitted in C++.

In C, when a function defination or declaration is followed by an empty pair of parentheses it means that zero or more parameters.

Only for a declaration. For a definition an empty pair of parentheses really does mean zero parameters.

An extract from Google Groups:

A C program is not required to work right if its main function does not have one of these two types:

int main(void) { /*...*/ }
int main(int argc, char **argv) { /*...*/ }

An extract from Google Groups:

An extract from C89 (3.5.4.3 Function declarators (including prototypes))

An empty list in a function declarator that is part of a function definition specifies that the function has no parameters. The empty list in a function declarator that is not part of a function definition specifies that no information about the number or types of the parameters is supplied.

And another from C99 (6.7.5.3 Function declarators (including prototypes))

An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters. The empty list in a function declarator that is not part of a definition of that function specifies that no information about the number or types of the parameters is supplied.

A C program is not required to work right if its main function does not have one of these two types:

That quote doesn't include the part where equivalent definitions are also allowed, and because int main() is technically equivalent the only problem is that it's deprecated. ;) Here's the whole clause.

The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent;8) or in some other implementation-defined manner.

But there's no point in splitting hairs because this stuff is mostly academic fodder for pedantic programmers. I've only heard of a few problems with the definition of main, they were caused by the return type, and they were on obscure and little used systems.

With all that said, it is better to use int main( void ) in C. At least that way you're guaranteed not to have problems. But it's really important not to get too stuck worrying about the insignificant things and concentrate on problems that matter. :)

You guys lost me at the "Hello". :)

But since you seem to be very knowledgeable (I know you are) I have a question for you:
In C programming there's a way I could see what is in the stdin buffer?. I always hear about
stdin buffer, how big is this buffer?.
Another another question that is bothering me for sometime, if I would like to construct
a function I have only the C Standard Library functions to do that right?
for example if I want to create a function that read a caracter from stdin I have to use
getchar(),
Do you understand what I am asking?.
I would like to know how to make a getchar() function. Or better yet, what makes getchar()
behind the scene work, How is it that can read a character?.
I hope you can show me some words of wisdom.

You guys lost me at the "Hello". :)

Don't worry, I don't go into geeky programmer mode much. :cheesy:

But since you seem to be very knowledgeable (I know you are)

No no, my act is just very convincing. :)

In C programming there's a way I could see what is in the stdin buffer?

Yes and no, and yes. But mostly no. The best way to see what's in the buffer is to read it with something like fgets, but I'm guessing that's not what you want. ;) To see the buffer without reading from it means doing something that you shouldn't be doing.

#include <stdio.h>


int main( void )
{
  char first;
  char *p;

  printf( "Please type multiple characters: " );
  first = getchar();

  printf( "Your input buffer is \"" );

  for ( p = stdin->_ptr; *p; p++ ) {
    switch ( *p ) {
      case '\n': printf( "\\n" ); break;
      case '\t': printf( "\\t" ); break;
      default: putchar( *p ); break;
    }
  }

  printf( "\"\n" );

  return 0;
}

What I'm doing is jumping down my compiler's throat and yanking on its poor little insides. ;) The cool thing about I/O streams is they're really nothing more than some structures and functions that work with them. stdin is a FILE*, and a FILE is just a structure with a few housekeeping members.

The problem is that when you do this you're only doing it for one compiler and it's pretty sure that your code won't work if you move to another compiler. Each compiler does this stuff differently, so you can't assume that stdin will have a _ptr member.

I always hear about stdin buffer, how big is this buffer?

The buffer is BUFSIZ characters big, and you can find BUFSIZ in <stdio.h>.

what makes getchar() behind the scene work, How is it that can read a character?.

It probably just uses some OS function to read characters. Most of the time getchar() will just dole out characters from the buffer, and then when the buffer is empty, it calls another function to refill it from the data source. Something like this except a lot more complicated. :)

int getchar()
{
  if ( stdin->current == stdin->end )
    refill_buffer( stdin );
  return stdin->buffer[stdin->current];
}

@ Ravalon

It's hard to be humble when you're as gifted as I am at pretending to be an expert.

I love the your quote at the end.
You're alright, and I don't care what they say! :)

I'm going to bookmark your answer for futher study. I'm barely learning about pointers and you use some.
By the way, I noticed that you used

FILE*

with the * close to the word FILE which I understand that it is a structure. That
reminded me that I have seen instances with the word followed by a *,
Is that different that something like

char *p?.

Does the place of the * makes it a different thing that I haven't encounter in the pointer lession yet?.

Is it just me, or did this thread suddenly take a strange turn? We went from someone wanting programs to nitty-gritty details of the C89/C99 to reading input streams! Needless to say, the OP definitely should have been clearer when asking his/her question and then maybe this thread wouldn't have gotten so off-topic. ;)

@ Ravalon

I love the your quote at the end.
You're alright, and I don't care what they say! :)

:)

I'm barely learning about pointers and you use some.

I use a lot more than some. I'm like a pointer maniac. It drives my Java mates crazy. ;)

By the way, I noticed that you used with the * close to the word FILE which I understand that it is a structure. That
reminded me that I have seen instances with the word followed by a *,
Is that different that something like

char *p?.

Does the place of the * makes it a different thing that I haven't encounter in the pointer lession yet?.

An asterisk next to a type means a pointer to that type. FILE* means a pointer to a FILE instance, char* means a pointer to a char, and so on. :) Unfortunately, * is used in a lot of places and not all of them involve pointers. Usually T* --where T is some type--means a pointer type and *x --where x is some variable--means dereferencing a pointer.

Is it just me, or did this thread suddenly take a strange turn?

Tangents make the world go 'round. :)

Is it just me, or did this thread suddenly take a strange turn?

OK. sorry I won't ask any more questions in this post.

Thank you very much, is great to get answers sometimes. I hope someday I will be good enough to help others with answers.

OK. sorry I won't ask any more questions in this post.

Thank you very much, is great to get answers sometimes. I hope someday I will be good enough to help others with answers.

Persistance is the key. If you never give up, I can assure you that you can become a C/C++ expert.

Only for a declaration. For a definition an empty pair of parentheses really does mean zero parameters.

I don't think so, atleast not in C -- take a look at this program and compile it using a C compiler.

int add1( )
{
    return 1 ;
}

int add2( void )
{
    return 1 ;
}

int main( void )
{
    int sum1 = 0 ;
    int sum2 = 0 ;

    sum1 = add1( 1, 2, 3 ) ;  // silently ignored...
    sum2 = add2( 1, 2, 3 ) ;  // raises an error
    
    return 0 ;
}

An extract from C99 standard clause 6.5.2.2

If the expression that denotes the called function has a type that includes a prototype, the number of arguments shall agree with the number of parameters. Each argument shall have a type such that its value may be assigned to an object with the unqualified version of the type of its corresponding parameter.

So if you use int main( ) you can very well do something like:

int main( )
{
    if( 0 )
        main( 'a', 'b', 'x', "more crap" ) ;
   
    return 0 ;
}

...which actually shouldn't be allowed and doesn't make sense either.

Thus the only correct way of using main is :

  • int main( void )
  • int main( int argc, char* argv[] )

Anything else is implementation defined and though it will may get documented by the compiler writer, but since they are optional ,portable code won't use them.

But there's no point in splitting hairs because this stuff is mostly academic fodder for pedantic programmers.

Yeah, but its always fun clobbering someone or getting clobbered to unconciousness with these blasted standards....;)

But since you seem to be very knowledgeable (I know you are) You're alright, and I don't care what they say!

Yeah, I guess it comes from years of experience -- did I ever mention that Raye teaches his kids C++ in free time (yeah he is that old)....:twisted:

We went from someone wanting programs to nitty-gritty details of the C89/C99 to reading input streams!

Welcome to the world of thread hijackers....;)

So if you use int main( ) you can very well do something like:

int main( )
{
    if( 0 )
        main( 'a', 'b', 'x', "more crap" ) ;
   
    return 0 ;
}

...which actually shouldn't be allowed and doesn't make sense either.

It makes sense when you remember that an empty parameter list in a function definition doesn't introduce a prototype, just like an empty parameter list in a function declaration doesn't. That doesn't change the meaning of the emptiness though, it just means that a compiler is free to not enforce the number of arguments. That's a quality of implementation thing. :)

Thus the only correct way of using main is :

  • int main( void )
  • int main( int argc, char* argv[] )

Anything else is implementation defined and though it will may get documented by the compiler writer, but since they are optional ,portable code won't use them.

I don't know about 'thus' because I don't really agree with your reasoning, but I do agree that those are the two right ways to define main. :) The only portability problem so far is that with void a warning or error is required and without void it's not.

Yeah, I guess it comes from years of experience -- did I ever mention that Raye teaches his kids C++ in free time (yeah he is that old)....:twisted:

;)

but I do agree that those are the two right ways to define main. :)

Point very well driven home I guess....:D

;)

Did I forget to mention I was joking....oh wait yes I did forget *drats*...:mrgreen:

Point very well driven home I guess....:D

It's very easy to convince me of things I already believe. :)

Did I forget to mention I was joking....oh wait yes I did forget *drats*...:mrgreen:

I guessed so since I'm not that old, I don't have kids, and...yea. ;)

It's very easy to convince me of things I already believe. :)

Oh come on, I wouldn't try to convince you of things you already know. It was just for the other people who would stumble across this thread -- there has got to be a conclusion, don't you think so...;)

I guessed so since I'm not that old, I don't have kids, and...yea.

Sorry if it completely ruffled you, just was a small joke for Aia since he / she was so impressed by you...thought would give him / her a good scare, but I turned out to be quite the reverse I guess. :)

Sorry if it completely ruffled you, just was a small joke for Aia since he / she was so impressed by you...thought would give him / her a good scare, but I turned out to be quite the reverse I guess.

Just for the record, I am a "he". And I'm happily married with four children. My age is irrelevant :).

By the way I'm also, impressed with your knowledge ~s.o.s~. You pay attention to the little thing, and you are "methodological". Is that a word?. English is my second language. :)

Is that a word?. English is my second language. :)

Close, I think the word you were looking for was methodical. :)

Sorry if it completely ruffled you, just was a small joke for Aia since he / she was so impressed by you...thought would give him / her a good scare, but I turned out to be quite the reverse I guess. :)

No worries, it didn't bother me one bit. :)

Just for the record, I am a "he". And I'm happily married with four children. My age is irrelevant :).

By the way I'm also, impressed with your knowledge ~s.o.s~. You pay attention to the little thing, and you are "methodological".

Nah...nothing like that, I just love poking at things....Anyways thank you...:D

No worries, it didn't bother me one bit. :)

Good to hear that... *tries to think of another joke, since Raye doesn't object to them...* :cheesy:

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.