Topic: Return type of main()


Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/30
Raw View
In article <36110B83.167E@wizard.net>, James Kuyper <kuyper@wizard.net>
writes
>>
>> Yes I had forgotten that we have to use a typedef to get round this
>> problem.
>
>A typedef does not create a new type; it just creates a new name for an
>existing type. You can't get around this problem that way. What you need
>is a struct/class containing the array.

I did not claim that I had a new type.  However typedefs sometimes
ensure that the compiler will parse code correctly (and sometimes
results in things that the naive programmer does not expect:

typedef char * cptr;
const cptr example;

which is equivalent to:

char * const example;  // note the position of the const

)

>
>> #include <iostream>
>> using std::cout;
>>
>> typedef char Word[3];

makes Word a typename for an array of three char
>>
>> void fn(Word words[]);

declares an array of arrays of 3 char, which decays to a pointer to an
array of three char.

>
>That is exactly equivalent to:
>
>       void fn(char words[][3]);

which is fine as long as your compiler does not treat this as a char**
but many do (and it was claimed earlier that this is correct)
>
>which in turn is equivalent to:
>
>       void fn(char (*words)[3]);

as above, words is a pointer to an array of three char, this is not the
same as a char**.  This distinction, as you know, matters.

>
>> void gn(char * words[]);
>
>which is equivalent to
>
>       void gn(char **words);

exactly.
>
>> int main(){
>>         char test[][4]={"abc","def","ghi"};
>>         char test1[][3]={"jk", "lm", "no", "pq"};
>>         fn(test);  //ERROR
attempts to pass a pointer to arrays of 4 char to pointer variable to
arrays of 3 char --- no conversion available
>>         fn((char**)test);  // OK but likely to fail in the call
sorry that should have been gn((char**)test);
OK I see what happened for some reason I interchanged fn and gn when
copying across my text program.
>>         gn(test);  //ERROR cannot convert from char*[4] to char*[3]
>>         gn(test1); //OK and has a chance of working
>>         return 0;
>> }
>
>My compiler objects to all four function calls, which makes sense to me.
>the only thing it should accept is
>
>       fn(test1);

You are right, and the other 'correct' line should have been
gn((char**)test);

The point I was trying to make so ineptly was that multi-dimesional
arrays do not decay to multiple levels of pointer.

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/30
Raw View
Francis Glassborow wrote:

> In article <36110B83.167E@wizard.net>, James Kuyper <kuyper@wizard.net>
> writes
> >[Francis Glassborow wrote:]
...
> >> #include <iostream>
> >> using std::cout;
> >>
> >> typedef char Word[3];

> makes Word a typename for an array of three char
> >>
> >> void fn(Word words[]);

> declares an array of arrays of 3 char, which decays to a pointer to an
> array of three char.

> >
> >That is exactly equivalent to:
> >
> >       void fn(char words[][3]);

> which is fine as long as your compiler does not treat this as a char**
> but many do (and it was claimed earlier that this is correct)

They're not conforming compilers if they do that.

> >which in turn is equivalent to:
> >
> >       void fn(char (*words)[3]);

> as above, words is a pointer to an array of three char, this is not the
> same as a char**.  This distinction, as you know, matters.

Agreed.

> >> void gn(char * words[]);

> >which is equivalent to

> >       void gn(char **words);

> exactly.

> >> int main(){
> >>         char test[][4]={"abc","def","ghi"};
> >>         char test1[][3]={"jk", "lm", "no", "pq"};
> >>         fn(test);  //ERROR
> attempts to pass a pointer to arrays of 4 char to pointer variable to
> arrays of 3 char --- no conversion available
> >>         fn((char**)test);  // OK but likely to fail in the call
> sorry that should have been gn((char**)test);
> OK I see what happened for some reason I interchanged fn and gn when
> copying across my text program.
> >>         gn(test);  //ERROR cannot convert from char*[4] to char*[3]
> >>         gn(test1); //OK and has a chance of working
> >>         return 0;
> >> }

> >My compiler objects to all four function calls, which makes sense to me.
> >the only thing it should accept is
> >
> >       fn(test1);

> You are right, and the other 'correct' line should have been
> gn((char**)test);

I'd have prefered it if your example had something like:

 char *p = test[0];
 gn(&p);

which would give gn() a chance of not producing a memory violation.

> The point I was trying to make so ineptly was that multi-dimesional
> arrays do not decay to multiple levels of pointer.

Correct; only an '[]' or '[N]' immediately to the right of the parameter
name decays. "(*words)[3]", for instance, does not decay any further.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/29
Raw View
In article <360FC630.59E2@wizard.net>, James Kuyper <kuyper@wizard.net>
writes
>> However, if I remember correctly, char ** and char *[n] where n is a
>> compile time constant are not and never have been the same thing.
>
>Any function parameter of the type 'array of T' is automaticly treated
>as 'pointer to T', whether or not the size of the array is a compile
>time constant. I don't think this has ever changed. In particular,
>annoyingly, sizeof() gives the sizeof the pointer, not the size of the
>array.

Yes I had forgotten that we have to use a typedef to get round this
problem.

#include <iostream>
using std::cout;

typedef char Word[3];

void fn(Word words[]);
void gn(char * words[]);

int main(){
        char test[][4]={"abc","def","ghi"};
        char test1[][3]={"jk", "lm", "no", "pq"};
        fn(test);  //ERROR
        fn((char**)test);  // OK but likely to fail in the call
        gn(test);  //ERROR cannot convert from char*[4] to char*[3]
        gn(test1); //OK and has a chance of working
        return 0;
}

That is, of course, one of the standard counter examples to those that
consider typedefs as kinds of macros.




Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/29
Raw View
Francis Glassborow wrote:
>
> In article <360FC630.59E2@wizard.net>, James Kuyper <kuyper@wizard.net>
> writes
> >> However, if I remember correctly, char ** and char *[n] where n is a
> >> compile time constant are not and never have been the same thing.
> >
> >Any function parameter of the type 'array of T' is automaticly treated
> >as 'pointer to T', whether or not the size of the array is a compile
> >time constant. I don't think this has ever changed. In particular,
> >annoyingly, sizeof() gives the sizeof the pointer, not the size of the
> >array.
>
> Yes I had forgotten that we have to use a typedef to get round this
> problem.

A typedef does not create a new type; it just creates a new name for an
existing type. You can't get around this problem that way. What you need
is a struct/class containing the array.

> #include <iostream>
> using std::cout;
>
> typedef char Word[3];
>
> void fn(Word words[]);

That is exactly equivalent to:

 void fn(char words[][3]);

which in turn is equivalent to:

 void fn(char (*words)[3]);

> void gn(char * words[]);

which is equivalent to

 void gn(char **words);

> int main(){
>         char test[][4]={"abc","def","ghi"};
>         char test1[][3]={"jk", "lm", "no", "pq"};
>         fn(test);  //ERROR
>         fn((char**)test);  // OK but likely to fail in the call
>         gn(test);  //ERROR cannot convert from char*[4] to char*[3]
>         gn(test1); //OK and has a chance of working
>         return 0;
> }

My compiler objects to all four function calls, which makes sense to me.
the only thing it should accept is

 fn(test1);

and it does.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Ron Natalie <ron@sensor.com>
Date: 1998/09/24
Raw View
jim.hyslop@leitch.com wrote:
>
>
> That won't work - the Standard says compilers must allow at least two forms of
> main:
>
>    int main(void);
>    int main(int, char *[]);
>
> Thus, you would have to put both forms of main in your header, along with any
> environment-specific forms such as
>
>     // this is legal if your compiler supports it
>    int main(int argc, char *argv[], char *envp[]);

You shouldn't put any of these in a header, what good does it do
you anyway?  No one is allowed to call main other than the
system code.
>
> But, because you have now declared three possible variations on main, this
> breaks the rule that says main cannot be overloaded.  So now the Standards
> committee has to change that rule too.

Huh?  You're only allowed to use one version of main.  Bearing
that in mind, how can you overload it?  Overloading is providing
multiple versions of the same function for the caller to decide
between.  This is the opposite, provide exactly one function
and the caller has to reconcile itself with the signature.

The specification says the only ones the compiler must recognize
are main(void) and main(int,char*[]), but there can be others.
But the spec is equally emphatic in that they must return int
no matter what.

Frankly, if it were up to me I would do away with the "no
return in the main function" being legal.  This serves no
useful purpose whatsoever.  Programs that neglected to return
a value from main in existing C and C++ implementations already
had undefined return value (typically whatever was in the
register used to pass back integer return values).  Putting
"return 0" at the end of main is the least of the issues in
getting things to work in standard C++.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: jim.hyslop@leitch.com
Date: 1998/09/25
Raw View
In article <360931FF.8CF4C75F@sensor.com>,
  Ron Natalie <ron@sensor.com> wrote:
> jim.hyslop@leitch.com wrote:
> >
> >
> > That won't work - the Standard says compilers must allow at least two forms
of
> > main:
> >
> >    int main(void);
> >    int main(int, char *[]);
> >
> > Thus, you would have to put both forms of main in your header, along with
any
> > environment-specific forms such as
> >
> >     // this is legal if your compiler supports it
> >    int main(int argc, char *argv[], char *envp[]);
>
> You shouldn't put any of these in a header, what good does it do
> you anyway?  No one is allowed to call main other than the
> system code.
Exactly my point (the header idea wasn't mine - I guess I cut too much of the
previous conversation).

> > But, because you have now declared three possible variations on main, this
> > breaks the rule that says main cannot be overloaded.  So now the Standards
> > committee has to change that rule too.
>
> Huh?  You're only allowed to use one version of main.  Bearing
> that in mind, how can you overload it?  Overloading is providing
> multiple versions of the same function for the caller to decide
> between.  This is the opposite, provide exactly one function
> and the caller has to reconcile itself with the signature.

Correct me if I'm wrong, but I don't believe a function must be defined in
order to be overloaded.  If you have a header file which contains:

class T;
int func1(int);
int func1(const T&);

the compiler does not need to hunt for definitions of those functions to know
that func1 has been overloaded - you have declared them as being overloaded.

My point was, that if you take the original suggestion and put the
declaration of main inside a header (not my idea, someone else's and I don't
like it at all), then you must put all possible variations of main that the
compiler will recognize in said header, and therefore you have overloaded
main, which you are not allowed to do.

> The specification says the only ones the compiler must recognize
> are main(void) and main(int,char*[]), but there can be others.
> But the spec is equally emphatic in that they must return int
> no matter what.

Well, except for the provision that a compiler can allow any non-conforming
code it wants to, as long as it emits a diagnostic message.

> Frankly, if it were up to me I would do away with the "no
> return in the main function" being legal.  This serves no
> useful purpose whatsoever.  Programs that neglected to return
> a value from main in existing C and C++ implementations already
> had undefined return value (typically whatever was in the
> register used to pass back integer return values).  Putting
> "return 0" at the end of main is the least of the issues in
> getting things to work in standard C++.

Oh, I agree absolutely.  Suppose I have ugly legacy code which uses "void
main". And, in addition, the main function is not coded using a single-exit
strategy, IOW there are lots of early "return;" functions.  Now, if I'm using
a compiler that enforces the standard, I not only have to change "void main"
to "int main" but I have to change all my return statements to return a
value. So implicitly converting falling-off-the-end to "return 0;" is really
not all that helpful.

But this is still a small price to pay considering the other changes that the
Standard makes which *really* break existing code in a *VERY* nasty way.
Here, I'm (switching topics slightly) talking about the fact that "new" must
throw an exception.

Suppose I have code which assumes "new" simply returns NULL, such as:

   T *t = new T;
   if (t==NULL) {
      // do error handling
   }

This code will work under the old compiler, because it checks for a NULL
return value.

Under a new compiler, however, new must throw an exception, so the above code
no longer works as expected at runtime.

Worse still, this is not a compile-time or link-time error, it's a *runtime*
error. To fix it, I must manually hunt down each occurence of new (grep
helps, but still...), and either change it to "new (nothrow)" or wrap it in a
try/catch clause.  Veeerrry nasty, IMO.

Jim

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Ron Natalie <ron@sensor.com>
Date: 1998/09/25
Raw View
jim.hyslop@leitch.com wrote:
>
> > Huh?  You're only allowed to use one version of main.  Bearing
> > that in mind, how can you overload it?  Overloading is providing
> > multiple versions of the same function for the caller to decide
> > between.  This is the opposite, provide exactly one function
> > and the caller has to reconcile itself with the signature.
>
> Correct me if I'm wrong, but I don't believe a function must be defined in
> order to be overloaded.  If you have a header file which contains:
>
> class T;
> int func1(int);
> int func1(const T&);
>
> the compiler does not need to hunt for definitions of those functions to know
> that func1 has been overloaded - you have declared them as being overloaded.

Yes, but this isn't what's going on for main.   First, you
must define it some where.  If you have a call of "func(4)"
the func1(int) will be called and better be resolvable.

With main, you have exactly one implementation but the caller
has to figure out which of the two or more allowable definitions
you used.  It's reverse overloading/.


> > The specification says the only ones the compiler must recognize
> > are main(void) and main(int,char*[]), but there can be others.
> > But the spec is equally emphatic in that they must return int
> > no matter what.
>
> Well, except for the provision that a compiler can allow any non-conforming
> code it wants to, as long as it emits a diagnostic message.

Well, yes, but in that case we might as well say the compiler
can accept FORTRAN programs as long as it warns you, lets limit
our discussions to processing that doesn't invoke the "extension
clause."

If the compiler accepts an alternate signature for main,
lets say:
 int main(int, char*[], char*[])
it need not make any warning to the user when it occurs.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: "Paul D. DeRocco" <pderocco@ix.netcom.com>
Date: 1998/09/26
Raw View
jim.hyslop@leitch.com wrote:

> the Standard says compilers must allow at least two forms of
> main:

>    int main(void);
>    int main(int, char *[]);

By the way, does that imply that a compiler must accept char** in
addition to char*[], or would that be an extension?

--

Ciao,
Paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: sbnaran@localhost.localdomain (Siemel Naran)
Date: 1998/09/27
Raw View
On 26 Sep 1998 18:15:28 GMT, Paul D. DeRocco <pderocco@ix.netcom.com> wrote:

>By the way, does that imply that a compiler must accept char** in
>addition to char*[], or would that be an extension?

They are the same thing.

int f(int* ) { return 1; }
int f(int[]) { return 2; } // error: redeclaration error

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: "James Russell Kuyper Jr." <kuyper@wizard.net>
Date: 1998/09/27
Raw View
Paul D. DeRocco wrote:

> jim.hyslop@leitch.com wrote:

> > the Standard says compilers must allow at least two forms of
> > main:

> >    int main(void);
> >    int main(int, char *[]);

> By the way, does that imply that a compiler must accept char** in
> addition to char*[], or would that be an extension?

Yes, they're the same thing; no extensions needed.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/28
Raw View
In article <360D6299.DAF61A6A@wizard.net>, James Russell Kuyper Jr.
<kuyper@wizard.net> writes
>> By the way, does that imply that a compiler must accept char** in
>> addition to char*[], or would that be an extension?
>
>Yes, they're the same thing; no extensions needed.

However, if I remember correctly, char ** and char *[n] where n is a
compile time constant are not and never have been the same thing.

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: jim.hyslop@leitch.com
Date: 1998/09/28
Raw View
In article <360BF6F5.6976657E@sensor.com>,
  Ron Natalie <ron@sensor.com> wrote:

> jim.hyslop@leitch.com wrote:
[snip stuff I agree with]
> > Well, except for the provision that a compiler can allow any non-conforming
> > code it wants to, as long as it emits a diagnostic message.

> Well, yes, but in that case we might as well say the compiler
> can accept FORTRAN programs as long as it warns you, lets limit
> our discussions to processing that doesn't invoke the "extension
> clause."

Yes, you're right - I still had echoes of someone earlier in this thread
(Phlip, I think) who stated that "void main" cannot even be allowed as an
extension.

Jim

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: jkanze@otelo.ibmmail.com
Date: 1998/09/28
Raw View
In article <360C6B9B.5AB028D8@ix.netcom.com>,
  "Paul D. DeRocco" <pderocco@ix.netcom.com> wrote:

> jim.hyslop@leitch.com wrote:

> > the Standard says compilers must allow at least two forms of
> > main:

> >    int main(void);
> >    int main(int, char *[]);

> By the way, does that imply that a compiler must accept char** in
> addition to char*[], or would that be an extension?

In a function declaration, char*[] IS char**.  The compiler must accept i=
t,
but there in no "in addition" involved.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/28
Raw View
Francis Glassborow wrote:

> In article <360D6299.DAF61A6A@wizard.net>, James Russell Kuyper Jr.
> <kuyper@wizard.net> writes
> >> By the way, does that imply that a compiler must accept char** in
> >> addition to char*[], or would that be an extension?

> >Yes, they're the same thing; no extensions needed.

> However, if I remember correctly, char ** and char *[n] where n is a
> compile time constant are not and never have been the same thing.

Any function parameter of the type 'array of T' is automaticly treated
as 'pointer to T', whether or not the size of the array is a compile
time constant. I don't think this has ever changed. In particular,
annoyingly, sizeof() gives the sizeof the pointer, not the size of the
array.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Ari Lukumies <ari.lukumies@elmont.fi>
Date: 1998/09/22
Raw View
[This followup sent to comp.lang.c++ and to comp.std.c++ for their
comments]

Dennis Weldy wrote:

[someone questioned about correct return type for main]
>
> Ok...so lets see....
>
> I define in a header file:
>     int myfunc(int argcount, char **args) ;
>
> and call it thusly
>     a = myfunc(3, theargs)
>
> but the function in my source code is:
>     void myfunc(int argcount, char **args)
>
> would that be correct?
>
> If not, then why would it be acceptable for the run time library to call a
> void main function when it
> expects an int main?
>
> While the compiler may be "forbidden" to predefine main, it can make the
> assumption about the return type: namely int, which would get propagated
> back to the OS/caller.
>
> There ARE two functions: one being what the compiler expected, and the other
> being what the user provided.

Perhaps the standard should be expanded so, that it put into some
standard header file a prototype (or even better, use a similar way some
of the predefined identifiers are handled, inside the compiler):

 int main(int,char**);

Then, if you use

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

you'll get 'overloaded function only differs by return type' compilation
error. Trying to use

 void main(void) { ... }

seems to get 'main function cannot be overloaded' error. This way, the
programmer would be forced to write proper code (well, a proper function
return type and parameter list for main, anyway :)

 AriL
--
*DO NOT* send me email unless I ask you to.
I read the answers where I ask the questions.
This may also help some other people.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1998/09/23
Raw View
In article 4A2AAB0@elmont.fi, Ari Lukumies <ari.lukumies@elmont.fi> writes:
>
>Dennis Weldy wrote:
>
>[someone questioned about correct return type for main]
>>
>> ... then why would it be acceptable for the run time library to call a
>> void main function when it
>> expects an int main?
>>
>> While the compiler may be "forbidden" to predefine main, it can make the
>> assumption about the return type: namely int, which would get propagated
>> back to the OS/caller.
>>
>> There ARE two functions: one being what the compiler expected, and the other
>> being what the user provided.
>
>Perhaps the standard should be expanded so, that it put into some
>standard header file a prototype (or even better, use a similar way some
>of the predefined identifiers are handled, inside the compiler):
>
> int main(int,char**);
>
>Then, if you use
>
> void main(int argc, char **argv) { ... }
>
>you'll get 'overloaded function only differs by return type' compilation
>error.

I don't see how that solves any current problem, but it does create
new problems.

The global main function cannot be overloaded. There can be only one in
the program. Providing a header such as you suggest would seem to
imply something else.

The C++ language definition has special rules for the main function.
Among them are these:
 - main is the program entry point.
 - You can't call main or take its address.
 - main must have a return type of int.
 - Forms equivalent to
  int main() { ... }
  int main(int argc, char*argv[]) { ... }
   must be accepted by the implementation.
An implementation is allowed to relax or extend these (or any) rules, as
long as it produces a diagnostic message for any rule violation. One
hopes the implementation also documents for its users what the
extensions are and how to turn them off.

The compiler must treat a global function "main" in many special ways.
Noticing the return type and complaining if it isn't "int" is just one
of them. No special header is needed in order to do that.

---
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: jim.hyslop@leitch.com
Date: 1998/09/23
Raw View
In article <36025583.4A2AAB0@elmont.fi>,
  Ari Lukumies <ari.lukumies@elmont.fi> wrote:
> [This followup sent to comp.lang.c++ and to comp.std.c++ for their
> comments]
[snip]
> > While the compiler may be "forbidden" to predefine main, it can make the
> > assumption about the return type: namely int, which would get propagated
> > back to the OS/caller.
> >
> > There ARE two functions: one being what the compiler expected, and the other
> > being what the user provided.
>
> Perhaps the standard should be expanded so, that it put into some
> standard header file a prototype (or even better, use a similar way some
> of the predefined identifiers are handled, inside the compiler):
>
>  int main(int,char**);
>
> Then, if you use
>
>  void main(int argc, char **argv) { ... }
>
> you'll get 'overloaded function only differs by return type' compilation
> error.
That won't work - the Standard says compilers must allow at least two forms of
main:

   int main(void);
   int main(int, char *[]);

Thus, you would have to put both forms of main in your header, along with any
environment-specific forms such as

    // this is legal if your compiler supports it
   int main(int argc, char *argv[], char *envp[]);

But, because you have now declared three possible variations on main, this
breaks the rule that says main cannot be overloaded.  So now the Standards
committee has to change that rule too.

No, I think it's easier to leave the rule the way it is, and let compiler
writers implement "void main" as a non-standard, non-portable extension.  The
current rules allow this - there's no reason to change the rules.

Jim

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]