Topic: main [was: Enforcing virtual destructo


Author: Stephen.Clamage@Eng.Sun.COM (Steve Clamage)
Date: 1997/04/15
Raw View
In article 252F@nowhere.com, Michael Hudson <sorry.no.email@nowhere.com> writes:
>Fergus Henderson wrote:
>> James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
>> >One question: does the "shall" mean that the implementation is
>> >required to give a diagnostic if I write "void main()", or that the
>> >results of writing "void main()" or undefined behavior (which the
>> >implementation is free to define)?
>>
>> Since this is a requirement on the form of the program, not on its
>> behaviour, the implementation is required to give a diagnostic.
>>
>
>But that's very silly.
>On some (many?) systems, including the MacOS where I do my coding, the
>return value from main is of no significance, so I type
>void main() { ... }
>If this generated a warning, I'd get into the habit of not reading the
>warnings my compiler prooduces, which is not a good habit.
>What I'm saying is, to hell with sticking to the absolute letter of the
>standard, common sense has to kick in somewhere.

Right. Common sense. If implementing the standard is inconvenient on
some platform, we'll just do whatever feels good instead. But do we
claim standard conformance anyway?.

If we don't claim standard conformance, we can do whatever (literally,
*whatever*) we want. But what would it mean to claim standard conformance
if we are not required to conform to the standard?

C and C++ have always defined "main" in a hosted environment to return an
int value to the OS (or to whatever invoked main). The OS (or whatever)
is free to ignore the value. In a non-hosted environment, such as an
embedded system, there are no requirements at all on main, not even
a requirement that there be a function "main". Non-hosted systems are
deemed unique, and only the language elements are defined -- the
library is not required to be present.

What are the alternatives? You didn't suggest any, so I'll take a stab at it.
1. No requirements on the return type of main. Then how do you write a
 portable program?
2. The return type of main is implementation-defined. Again, how do you
 write a portable program?
3. Add "void main" as a required alternative. That might work. Let's
 look at some consequences.

Many systems expect a return value from the main program. If "void main"
were required to be accepted, such systems could add a hidden wrapper
around main along the lines of
 int __Entry(int argc, char** argv) // used only for "void main"
 {
  main(argc, argv);
  return 0;
 }
We would also have to revisit the wording in the standard about
the effect of returning from main versus the effect of terminating
the program via "exit", creating special cases.

What benefit do we derive from this extra work? Well, in C++ you are
not required to write a return statement in main. This is a valid C++
program:
 int main() { }
The compiler inserts an implied "return 0;" for you. If you could
write "void main" instead, you wouldn't save anything, since the
source program would be 1 character longer ("void" vs "int")! In the
case where a return value is needed by the operating system, the
executable program would also be bigger, since the extra wrapper
would be needed. So we don't get smaller source or object programs
by being able to write "void main". I don't see any benefit at all.

Now let's consider status quo. Platforms almost always have features
or requirements that are not addressed by the language standard.
C++ implementations are free to add any extensions they want, as long
as they don't invalidate programs which comply with the standard.
Sometimes conventions on a platform violate some provision in the
standard. In those cases, compiler implementors add a "standard-conforming"
mode to the implementation for the purpose of passing validation
suites, and for helping to ensure program portability. The "local
mode", which might be the default mode, enables the non-conforming
features.

Programs that don't care about portability but do care about old
conventions run in non-conforming mode and get the results they
expect.

Thus, an implementation could choose to allow "void main" without
emitting a diagnostic when not in "standard-conforming" mode. It
could issue a warning and continue to accept "void main" in
conforming mode.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: "Paul D. DeRocco" <strip_these_words_pderocco@ix.netcom.com>
Date: 1997/04/16
Raw View

Steve Clamage wrote:
>
> Right. Common sense. If implementing the standard is inconvenient on
> some platform, we'll just do whatever feels good instead. But do we
> claim standard conformance anyway?.

I think what would make everyone happy would be to add language that
would allow main to be void, requiring that in environments where the
value matters, the compiler would silently return zero. Thus, even in
environments that use error codes, programs that don't could write main
as a void function and not worry about it. It would also make sense,
then, to declare;

 extern void exit(int retval = 0);

in the standard header.

Since main is a "special" function to the compiler, there would be no
physical need for it to wrap it in another function call in order to get
this to work.

--

Ciao,
Paul D. DeRocco

(Please send e-mail to mail:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: Stephen.Clamage@Eng.Sun.COM (Steve Clamage)
Date: 1997/04/05
Raw View
In article dad90fea5778a59896ba@news.leitch.com, jim.hyslop@leitch.com (Jim Hyslop) writes:
>In article <199704022036.MAA15282@taumet.eng.sun.com>,
>Stephen.Clamage@eng.sun.com says...
>> In article dab18ee3669b3fc9896ac@news.leitch.com, jim.hyslop@leitch.com (Jim Hyslop) writes:
>> >- may break existing code (but not as badly as forcing only two valid
>> >signatures for main()!) ...
>>
>> Where did you get that idea?

>From various threads here and in comp.lang.c++.moderated; one
>"evangelist" in particular (and I mean that in the nicest way) will
>always post a correction to sample code that doesn't use int
>main(void) or int main(int, char **).

That reflects the difference between code which is required to work
on all platforms, and code which is not forbidden and which happens
to work on some platforms.

IMHO it is poor form to use "void main()" or "int main(int, char**, char**)"
in examples of general C++ programming, because neither form is supported
on all platforms. In addition, I would avoid the nonstandard forms unless
they are necessary for some reason. It avoids having to modify the code
when you move it to another platform.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]