J.deBoynePollard@tesco.net (Jonathan de Boyne Pollard) wrote
> AW> Perhaps Microsoft is the only vendor that ever tried to "lock in"
> AW> it's customers, by convincing them to write code that would turn
> AW> out to be difficult to port?
>
> It is certainly the case that Microsoft is not the only vendor who has
> ever
> used "void main()" in its documentation.

<harmless-sarcasm>
Shock! Dismay! Disbelief!
</harmless-sarcasm>

That was pretty much my point.

> AW> Textbooks ought not to flout non-standard code as good programming
> AW> practice, and textbooks that do this do not deserve to be
> successful.
>
> However, in the case of "void main()" we have textbooks that do this,
> and that _are_ successful. Clearly, whatever mechanism the world has in
> place to ensure that textbooks get what they deserve is faulty and in
> need of repair.

I'll be happy to file a defect report with the world... if you can find
the E-mail address for me.  :-)

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

FG> I did care that VC++ used to tell programmers who omitted a return
FG> from their main() that they needed to declare void main() because
FG> that was exactly wrong and unhelpful to programmers.

AW> More specifically, it was right and helpful to programmers on that
AW> particular compiler, but only if they didn't care about portability.
AW> Perhaps Microsoft is the only vendor that ever tried to "lock in"
AW> it's customers, by convincing them to write code that would turn
AW> out to be difficult to port?

It is certainly the case that Microsoft is not the only vendor who has
ever
used "void main()" in its documentation.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/legality-of-void-main.html>

AW> Textbooks ought not to flout non-standard code as good programming
AW> practice, and textbooks that do this do not deserve to be
successful.

However, in the case of "void main()" we have textbooks that do this,
and that _are_ successful.  Clearly, whatever mechanism the world has in
place to ensure that textbooks get what they deserve is faulty and in
need of repair.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 8 Oct 2002 12:34:25 +0000 (UTC), kuyper@wizard.net ("James Kuyper Jr.")
wrote:

>Alf P. Steinbach wrote:
>....
>> In conclusion I still maintain that MSVC is non-conforming wrt. main(),
>> since for the compiler's most common usage you cannot use main() without
>> some little-known technical trickery (as shown above).
>
>It doesn't matter how bizarre or obscure the procedure is that is needed
>to achieve this result; if using that procedure puts the compiler in a
>mode where it meets all of the standard's requirements, then that mode
>of the compiler is fully conforming. The fact that another mode exists
>that is not fully comforming is irrelevant, even if that mode is by far
>the more popular mode. In fact, that's usually the case. Most compilers
>are non-conforming in their default mode, and not many people bother to
>turn on (or off) the options needed to get into that compiler's fully
>conforming mode.


That is a good point.

Now we're onto territory where we differ by degrees, having established
most of the contended facts (at least I hope so).

So, what is the difference between the compiler's support for "main()"
and, say, support for RTTI (example chosen to best support your point)?

Using either a command line invocation or the vendor's IDE, support for
RTTI is off by default.  In the command line you have to add /GR, and in
the IDE you have a graphical way to do the same.  In fact the compiler
informs you that that would be a good idea, if the code uses RTTI.

One wouldn't argue that the compiler is non-conforming wrt. RTTI on the
basis of this  --  it's an optimization that you can turn off, and for
which it issues a diagnostic when it's clear that it should be turned
off (that is, RTTI support turned on).  For RTTI the compiler just has
non-conforming optimized behavior as default.  I, among others, would
like that default behavior changed, but that's another matter entirely.

For "main()" it is another story.  Here one part of the implementation
(the compiler proper) is happy as can be with the feature.  But another
part of the implementation (the linker) refuses to accept the language
feature for the most common kind of program.

There is a way around, yes, as I've shown, but that way is undocumented
(nowhere is it stated that this may or will work for a non-console app,
at least as far as I've been able to ascertain), and so, contrary to
the /GR RTTI switch, this technical trick *can not be relied on* in
production code.  It's worked with earlier versions and it works with
the current version, but perhaps with the next version of the compiler
it won't work anymore; there's no telling.

So, regarding support for "main()" the compiler effectively provides
no support, again, for the most common kind of program.

In short, it's not the case that "using that procedure puts the
compiler in a mode where it meets all of the standard's requirements",
at least if we want to have any guarantee that it does.

Although arguments by analogy are suspect, I think it is like if a
Unix compiler didn't support "main()" except for daemon programs, but
there was some undocumented technical trickery to make "main()" work
also for ordinary programs.  One problem with that analogy is that
AFAIK no Unix differentiates between daemons and other programs, so
that would be the compiler's own differentation.  But I think my
point here is clear enough despite the failing analogy.

Therefore, I still maintain that MSVC (version 7) is non-conforming
wrt. "main()"  --  and repeat my statement somewhere else in this
thread, that it would be absurd if version 8 became standard-
conforming in all respects except "export" and "main()", considering
the relative technical difficulties of supporting these features.


Cheers,

- Alf

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote
> Summing up: with the default invocation there is a very long list of
> compliance issues; with the common usage there is a somewhat shorter
> list, but that list includes lack of support for "main()".
...
> So if I understand you correctly the need for standard-conformance,
> e.g. support for "main()", is inversely proportional to the number
> of non-standard library functions used in the typical code compiled
> with a given mode of the compiler?

Your objection seems to be that you need to "put the compiler into
standard-conformance mode" before it conforms to the standard.

What happens if you have "scc.bat" in your path:
    cl /nologo /GX /GR myadware.cpp /link /subsystem:windows %1.cpp
    link /nologo /entry:mainCRTStartup /subsystem:windows %1.obj
Obviously you might need to make changes to this, to handle multiple
source files or whatever. But would you consider this scc
(Standard-Compliant C++) "compiler" to be standards-compliant?

Let's try it another way. Suppose you bought a new program named MC,
which stands for Mega-Compiler. Like Microsoft Visual Studio, this
system accepted code in many different languages -- in fact, it goes
even further, by accepting over 50 different computer languages,
including Assembly, Basic, C, C++, Cobol, Fortran, Java, Natural,
Pascal, and Perl. Unlike MVS, the name of the actual compiler is
identical no matter which language you invoke; a command-line
argument specifies which language to use:
    mc /assembly prog1.asm
    mc /basic    prog2.bas
    mc /c        prog3.c
    mc /c++      prog4.cpp
    mc /cobol    prog5.cob
...and so on.

The default language is assembly. That means it can never compile ANY
C++ program unless you specify the /c++ switch.

Is it impossible for this compiler to conform to the C++ standard?
If not, where do you draw the line? How many command-line switches
are too many?

> So that if a compiler is typically *used* for applications with a lot
> of non-standard library functions, that compiler need not be standard-
> compliant at all???

Of course not! Why would it need to?

Please recall the purpose of a standard: to specify a particular set
of rules in effect. These rules are not laws; you are at liberty to
create your own compiler, obeying as few or as many of the rules in
the standard as you care to. You can even sell your program as a C++
compiler, so long as you don't bill it as complying with the ANSI/ISO
standard.

To be successful, your compiler is going to have to be "close enough"
to standards-complaint to satisfy your customers. If you can truthfully
claim to comply with ALL of the rules, then you can say so in your
advertising -- that's a powerful thing. If you add this after the fact
(or if the next standard makes any incompatible changes), then you're
going to want to let your customers choose weather all of these rules
are in effect or not. Most of your customers are NOT going to need
full compliance, at least not all the time, so you might choose to make
non-compliance the default. That's up to you.

If you sell a "revolutionary new hammer," you can design it so that it's
held in a "revolutionary new way," but it better be able to drive nails.

If you sell a "standards-compliant C++ compiler," you can design it
so that your customers have to explicitly ask for standards compliance,
but when they do that, it better be able to compile standard code.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 9 Oct 2002 22:23:29 +0000 (UTC), allan_w@my-dejanews.com (Allan W) wrote:

>alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote
>> Summing up: with the default invocation there is a very long list of
>> compliance issues; with the common usage there is a somewhat shorter
>> list, but that list includes lack of support for "main()".
>...
>
>Your objection seems to be that you need to "put the compiler into
>standard-conformance mode" before it conforms to the standard.
>
>What happens if you have "scc.bat" in your path:
>    cl /nologo /GX /GR myadware.cpp /link /subsystem:windows %1.cpp
>    link /nologo /entry:mainCRTStartup /subsystem:windows %1.obj
>Obviously you might need to make changes to this, to handle multiple
>source files or whatever. But would you consider this scc
>(Standard-Compliant C++) "compiler" to be standards-compliant?

Wrt. "main()", yes I would.  But then I might have to __change__ it
for the next version of MSVC, since the effect of the linker
switch, in this context, is effectively undocumented (not documented
any place I can see in the latest version of the compiler's docs,
which gives the impression that it cannot be used this way).  And
it's possible that it would not even be supported by the next
version of the compiler.

The above is no better than arguing that MSVC is standard-compliant
because it can be used as back-end to Comeau, which unfortunately
I've never used.  A C compiler might likewise be wrapped behind
some front-end processing to make a standard C++ compiler; and is
actually used that way by e.g. Eiffel, probably there is also some
C++ implementation that works that way.  That doesn't make the C
compiler C++ standard compliant, nor an Eiffel compiler, just as
John Searle's poor Indians will probably never learn Chinese as they
toil away to simulate a computer AI conversant in Chinese...

Also, since very few programmers are aware of the linker trick,
they might search in vain for "WinMain" (ah, I'm poetical).

But, upshot:


  * The compiler can not be regarded as standard-compliant wrt.
    "main()" as long as one absolutely has to use a for this purpose
    undocumented and little-known switch argument.  IMHO, of course.


Regardless of whether that usage can be wrapped in a script, or
whether the compiler itself can be wrapped in a preprocessor, for
every concrete version of the compiler so far.



>Let's try it another way. Suppose you bought a new program named MC,
>which stands for Mega-Compiler. Like Microsoft Visual Studio, this
>system accepted code in many different languages -- in fact, it goes
>even further, by accepting over 50 different computer languages,
>including Assembly, Basic, C, C++, Cobol, Fortran, Java, Natural,
>Pascal, and Perl. Unlike MVS, the name of the actual compiler is
>identical no matter which language you invoke; a command-line
>argument specifies which language to use:
>    mc /assembly prog1.asm
>    mc /basic    prog2.bas
>    mc /c        prog3.c
>    mc /c++      prog4.cpp
>    mc /cobol    prog5.cob
>...and so on.

Hum, you're talking about gcc.



>The default language is assembly. That means it can never compile ANY
>C++ program unless you specify the /c++ switch.
>
>Is it impossible for this compiler to conform to the C++ standard?
>If not, where do you draw the line? How many command-line switches
>are too many?

One undocumented and unsupported necessary switch is IMHO enough to
make the compiler non-compliant.  With gcc you write "g++" to invoke
the C++ compiler.  No problem there.




>> So that if a compiler is typically *used* for applications with a lot
>> of non-standard library functions, that compiler need not be standard-
>> compliant at all???
>
>Of course not! Why would it need to?

This is out of context; the above is a possible conclusion (which
I don't agree with) of some earlier argument, a valid proof
technique where from an absurd conclusion one infers that some
earlier premise must be wrong.

So you don't think the conclusion is absurd.  Ok.  No need for
compilers to be standard-compliant, I can agree with that as an
assumption for the sake of discussion, although currently I'm
absolutely not convinced  --  rather the opposite.

Although trivial, note that this assumption is irrelevant to
anything except the original premise I tried to put down, which
under this assumption was necessarily a "red herring" fallacy.


Cheers,

- Alf

(wondering why so many argue against regarding MSVC as non-conforming
wrt. "main()"  --  I argue my original opinion because people drop in
to the discussion all the time to argue against it; mystifying!)

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 7 Oct 2002 21:45:29 +0000 (UTC),
alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote:

[in reply to kuyper@wizard.net ("James Kuyper Jr.")]

>Is your position then that the requirement of a "main()" is
>a meaningless one and should be removed from the standard?

I don't know the position of James Kuyper, but my position is that if
you did not invoke the compiler in its conforming mode, then the
entire C++ standard is irrelevant, including the clause stating that a
progam must have a main() function.
Conformance to a standard is only relevant if you invoke the
compiler/linker/assembler/whatever with those options that should make
it run in a conforming mode.

>
>>Could you show me why anyone not coding for Windows should care
>>that their program would have to be compiled as a console program to
>>run under Windows?
>
>Yes, a console window would pop up when the app was run from e.g.
>Explorer, courtesy of the very "helpful" operating system.

So the compiler, or even the language you wrote the program in, must
be changed ("corrected") because the OS does not exectly what you
want, even if it is the correct action for most users.

>Cheers,
>
>- Alf
>

Bart v Ingen Schenau

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 10 Oct 2002 12:01:27 +0000 (UTC), Bart.van.Ingen.Schenau@ict.nl (Bart van
Ingen Schenau) wrote:

>On Mon, 7 Oct 2002 21:45:29 +0000 (UTC),
>alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote:
>
>[in reply to kuyper@wizard.net ("James Kuyper Jr.")]
>
>>Is your position then that the requirement of a "main()" is
>>a meaningless one and should be removed from the standard?
>
>I don't know the position of James Kuyper, but my position is that if
>you did not invoke the compiler in its conforming mode, then the
>entire C++ standard is irrelevant, including the clause stating that a
>progam must have a main() function.
>Conformance to a standard is only relevant if you invoke the
>compiler/linker/assembler/whatever with those options that should make
>it run in a conforming mode.

Which options "should" make the MSVC compiler run in a conforming mode?

I'm willing to accept even an answer that restricts itself to
conformance wrt. "main()".

But as far as I know, there is no such thing as you suggest.




>>>Could you show me why anyone not coding for Windows should care
>>>that their program would have to be compiled as a console program to
>>>run under Windows?
>>
>>Yes, a console window would pop up when the app was run from e.g.
>>Explorer, courtesy of the very "helpful" operating system.
>
>So the compiler, or even the language you wrote the program in, must
>be changed ("corrected")

Well, actually, if I were Microsoft, I'd correct the documentation
and the linker.



> because the OS does not exectly what you want, even if it is the
> correct action for most users.

Please document or otherwise support the claim that for most users,
the correct action the OS should take when starting an app is to
pop up a console window.

I'm unable to believe it without some substantiation.

The reason this is at all relevant is that to avoid the side-effect,
MSVC must be used in a mode where "main()" is not accepted unless an
undocumented and little known feature is used, and not accepting
"main()" is in my very humble opinion non-conforming behavior.


Cheers,

- Alf

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) writes:

> On Fri, 4 Oct 2002 18:40:24 +0000 (UTC), andys@evo6.com (Andy Sawyer) wrote:
>
> >alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) writes:
> >
> >> 3.  As a hosted implementation MSVC is non-conforming wrt. main.
> >>     You can use any of "wmain", "WinMain" and "wWinMain" instead of
> >>     "main", and the tools make it *much* more difficult to use
> >>     "main" instead of one of the others for the most common usage of
> >>     the compiler -- so much so that most programmers, and indeed the
> >>     MS technical writers, seem to be unaware that by technical
> >>     trickery you can use "main".
> >
> >Thanks for telling me I had to use "technical trickery" to use main
> >with MSVC 6. I've been doing so for years, and wasn't aware that my
> >edit/compile/link cycle counted as "technical trickey".
> >
> >,----[ hello.cpp ]
> >| #include <iostream>
> >| int main( )
> >| {
> >|     std::cout << "Hello, techincal trickster!" << std::endl;
> >|     // lame attempt to stay on topic by dropping off the bottom
> >| }
> >`----
> >
> >c:\> cl hello.cpp
>
> Let's see.  We ordinarily use a C++ compiler to produce console
> "Hello, world!" programs.  Yes.

I often use C++ complies - MSVC included - to produce console
programs. I suspect I am not alone in that. Whilst many of them are
somewhat more complex that "Hello, world" they still use main as an
entry point and I see none of the "technical trickery" you refer to.

Once again, I apologise for presenting easily verified facts.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Allan W <allan_w@my-dejanews.com> writes
> >Turn the question around. You seem opposed to having the new standard
> >accept void main(). Is that simply because Microsoft does it today as
> >a non-standard extension (and is pretty lax about labelling it such)?
> >Or is there some more substantial reason why it should not be
> >permitted?

francis.glassborow@ntlworld.com (Francis Glassborow) wrote
> I am opposed to it because a major aspect of a standard is portability.
> It says that if you write code to conform to certain rules it will
> compile on any (in this case, hosted) system.

If the next standard says that void main() is allowed, it will become
portable. AFAIK, this will not impose an undue burden on compiler vendors.

> Now unlike you, I do not care that event driven programs for MS
> compilers have a WinMain for the simple reason that such programs are
> non-portable. I also care less than you do that some compilers allow
> void main(). I did care that VC++ used to tell programmers who omitted a
> return from their main() that they needed to declare void main() because
> that was exactly wrong and unhelpful to programmers.

More specifically, it was right and helpful to programmers on that
particular compiler, but only if they didn't care about portability.
Perhaps Microsoft is the only vendor that ever tried to "lock in"
it's customers, by convincing them to write code that would turn
out to be difficult to port?

> I do care about
> authors who give their readers wrong information because writers have a
> responsibility to correctly inform their readers.

Me too. I can forgive new programmers that make a mistake, but by
definition a textbook author is asserting his authority. Textbooks
ought not to flout non-standard code as good programming practice,
and textbooks that do this do not deserve to be successful.

> As long as their are
> systems that use the return from main for some purpose the standard
> should require the return value to be declared and for portability that
> means always declared for portable code.

As long as there are programs that don't bother signalling failure with
a return code (they always return 0), there will be programmers that
would prefer void main().

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote
> kuyper@wizard.net ("James Russell Kuyper Jr.") wrote:
> >There's two different ways of looking at it. One of them is, that there
> >is a main() - it's just defined in the Windows library, rather than in
> >your code.
>
> Nope  --  that kind of thinking means that no hosted implementation need
> to support user-defined "main", since it can be regarded as already
> defined.  That conflicts the standard's use of "shall contain", which
> would then be meaningless.

As a (possibly irrelevant) technical issue, the Windows library
doesn't supply a main(). (Well, maybe it does in MFC, I'm not sure,
but not in the normal case.) Instead, IIRC, the start-up code has a
weak reference to main, WinMain, wmain, and so on -- and it tries
them each until it finds one.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 4 Oct 2002 20:19:00 +0000 (UTC), andys@evo6.com (Andy Sawyer) wrote:

>alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) writes:
>
>> On Fri, 4 Oct 2002 18:40:24 +0000 (UTC), andys@evo6.com (Andy Sawyer) wrote:
>>
>> >alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) writes:
>> >
>> >> 3.  As a hosted implementation MSVC is non-conforming wrt. main.
>> >>     You can use any of "wmain", "WinMain" and "wWinMain" instead of
>> >>     "main", and the tools make it *much* more difficult to use
>> >>     "main" instead of one of the others for the most common usage of
>> >>     the compiler -- so much so that most programmers, and indeed the
>> >>     MS technical writers, seem to be unaware that by technical
>> >>     trickery you can use "main".
>> >
>> >Thanks for telling me I had to use "technical trickery" to use main
>> >with MSVC 6. I've been doing so for years, and wasn't aware that my
>> >edit/compile/link cycle counted as "technical trickey".
>> >
>> >,----[ hello.cpp ]
>> >| #include <iostream>
>> >| int main( )
>> >| {
>> >|     std::cout << "Hello, techincal trickster!" << std::endl;
>> >|     // lame attempt to stay on topic by dropping off the bottom
>> >| }
>> >`----
>> >
>> >c:\> cl hello.cpp
>>
>> Let's see.  We ordinarily use a C++ compiler to produce console
>> "Hello, world!" programs.  Yes.
>
>I often use C++ complies - MSVC included - to produce console
>programs. I suspect I am not alone in that. Whilst many of them are
>somewhat more complex that "Hello, world" they still use main as an
>entry point and I see none of the "technical trickery" you refer to.

I'm not sure that I get your point.  Is it


   (Premise 1)  Andy Sawyer (and indeed, also Alf P. Steinbach, and
                many others) often create console programs, and

   (Premise 2)  with MSVC such programs can have a "main()", and so

   (Conclusion) MSVC is standard-conforming wrt. "main()"?


If so, then it would be interesting to know the rule of inference
applied here.

But in light of earlier discussion, perhaps the point rather is that
for console applications MSVC "is" a hosted implementation, whereas
for the most common usage, non-console applications, it "is" a
freestanding implementation, at least when trickery isn't applied,
in which case it would again "be" a hosted implementation?

I shan't argue against it, since it isn't specified.




>Once again, I apologise for presenting easily verified facts.

No need to apologize for that easy verification (you say what you
use the compiler for, one must assume that that is true), since the
*conclusions* are not easily verified and not even stated.


Cheers,

- Alf

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alf P. Steinbach wrote:
....
> Let's see.  We ordinarily use a C++ compiler to produce console
> "Hello, world!" programs.  Yes.

Well, I certainly do write most of my code for what you would call
"console" programs. Though they're usually immensely more complicated
than "Hello, world!".

You can't argue against MSVC's conformance on the basis of the fact that
you only use it with a particular library (other than the C++ standard
library) that breaks conformance. There's not a single compiler anywhere
in the world that would survive a conformance test of that kind.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

[Dear moderator, perhaps you could forward this to Andy?  I received
a long mail from him that I'm now in his killfile, so otherwise he'll
not receive the glad news.  TIA, Alf.]

I've learned that Andy doesn't actually hold the viewpoints I've
attributed to him, although I still don't know what his actual views
are.  Unfortunately I took a number of remarks of his to be intended as
personal when they were, as I now understand, not intended that way, at
least not in a negative way.  I reacted, as I usually do when I sense no
fair play, whoever is on the receiving end, and unfortunately I've got a
sharp enough pen (keyboard?) to perhaps respond in more than kind.

I suspect that that sub-thread (this sub-thread) is now closed, except
for possibly this posting, and if so then Andy has no chance to respond
to that last posting of mine  --  which IMHO is not a fair situation.

Therefore, I'd like now to apologize to Andy for not taking the time
to cool off a bit and think about other possible interpretations, even
though I find that as difficult as I imagine Andy must find it difficult
to not feel insulted by my portraying of his positions and intentions.
Of course, I quoted what I found offensive and did what I thought was
right at the time.  I now think an apology is the appropriate thing.

Regards,

- Alf

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andy Sawyer wrote:
> kuyper@wizard.net ("James Russell Kuyper Jr.") writes:
>
>
>>Right. "Compiler+standard library + library X", considered as a single
>>entity acting on program Y, where X is just about any commonly used
>>library you care to choose, is NOT a conforming implementation of
>>C.
>
>
> I'd suggest that that would be a discussion for comp.lang.c. I'm

Sorry. I meant C++. I monitor both comp.std.c and comp.std.c++, and
sometimes lose track about which one I'm talking about. But that
particular statement is equally true for either language.

....
>>Yes, but how much of Microsoft's own library code is written
>>exclusively in that limited subset?
>
>
> I don't see how that's relevant, since I'm not aware of any
> requirement that _any_ of the standard library be written in C++. I'd

There's no such requirement. I didn't imply that there was. I was just
making a comment about their coding practices.

>>That's what I was talking about. I actually don't know, I've been
>>free of the need to write Windows code for more than six years
>>now.
>
>
> Just to clarify a couple of points about that statement:
> 1) are you claiming that it's been more that six years since you've
>    had any experience of what you're talking about?

No - I'm talking about what conformance to the C++ standard requires,
and that is extremely current expertise on my part. The standard does
not require that your code defining main() must compile and execute
properly when linked to a non-standard library that also defines main().

> 2) Are we talking about Microsoft's compiler or Windows programming?

Yes. To both.

>>I don't! I'm blissfully unaware of just how badly their compiler would
>>handle any of my code.
>
>
> Just to clarify that statement - are you saying that you're happy that
> you don't know what you're talking about? (I don't imagine for a
> moment that that _is_ what you're saying, but I can't find any other
> way to read it).

I'm quite happy about the fact that I don't have to know how badly MSVC
conforms to the C++ standard. I have no idea whether or not MSVC's
windows library does in fact define main(), but I'm fairly certain that
it used to. And I don't care, because every statement I made on the
subject contained a suitably placed conditional clause covering that
issue. My main point was that an avoidable failure to accept a
user-defined main() is not in itself a conformance violation for a
hosted implementation. And that remains true regardless of what MSVC
actually 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alf P. Steinbach wrote:
> On Fri, 4 Oct 2002 12:06:20 +0000 (UTC), kuyper@wizard.net ("James Russell Kuyper
> Jr.") wrote:
....
>>You're missing my point. There's a compiler, the standard C++ library,
>>and some other library or libraries. If one of the other libraries
>>happens to contain main(), and the compiler allows you to NOT link to
>>that library, then it remains a conforming compiler. Just because
>>linking in that library ahead of your own code would prevent you from
>>usefully defining your own main(), wouldn't make the compiler
>>non-conforming.
>
>
>
> 1.  You're literally correct that some library may contain a main().
>     I seem to remember that e.g. the MSVC screensaver lib does contain a
>     main().  But that isn't relevant to ordinary use of the compiler.
>
> 2.  The standard says explicitly that main shall not be predefined.
>     In other words, a hypothetical compiler that provided a main for ordinary
>     use of the compiler would be non-conforming.

main() isn't pre-defined by the implementation; it's defined by the
Windows library (unless they've changed it significantly since the last
time I had to use that junk). As you say, the Windows library cannot be
part of a conforming implementation. However, a conforming
implementation can link user code with that library. It just has to have
the option of not doing so, in order to be a conforming implementation.

> I don't understand the point of trying to use the concept of freestanding
> implementation as a sort of "legal loop-hole" for compilers that are
> obviously not meant as nor marketed as freestanding implementations.

Free-standing has never been anything but one big loop-hole. It's just a
two-level conformance ladder. Freestanding implementations implement the
language and an minimal portion of the library correctly, and as many
other parts of the library as they want, correctly or not. Hosted
implementations must implement both the language and the entire library
correctly. If you've attached any other meaning to free-standing, you
were misinterpreting it.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alf P. Steinbach wrote:
....
> I'm not sure that I get your point.  Is it
>
>
>    (Premise 1)  Andy Sawyer (and indeed, also Alf P. Steinbach, and
>                 many others) often create console programs, and
>
>    (Premise 2)  with MSVC such programs can have a "main()", and so
>
>    (Conclusion) MSVC is standard-conforming wrt. "main()"?

That isn't a proper summary of the conclusion. You can't actually
conclude that MSVC is standard-conforming wrt. main() on that basis,
because there's many other requirements place by the standard on main(),
than just the fact that it must be allowed. However, you can't claim
non-conformance on the basis of the "fact" that main() isn't allowed, if
in fact it is allowed. If it's only allowed in console programs, that's
fine. The C++ standard doesn't make a single requirement anywhere that
it must be possible to write non-console programs.

In fact, it's not possible to write such programs without including some
code somewhere that renders some or all of the standard's requirements
inapplicable. Simply linking your code to the windows library, without
doing anything else, is sufficient to make the behavior of your program
implementation-defined at  best, and undefined at worst.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat, 5 Oct 2002 03:21:47 +0000 (UTC), kuyper@wizard.net ("James Russell Kuyper
Jr.") wrote:

>Alf P. Steinbach wrote:
>....
>> Let's see.  We ordinarily use a C++ compiler to produce console
>> "Hello, world!" programs.  Yes.
>
>Well, I certainly do write most of my code for what you would call
>"console" programs. Though they're usually immensely more complicated
>than "Hello, world!".
>
>You can't argue against MSVC's conformance on the basis of the fact that
>you only use it with a particular library (other than the C++ standard
>library) that breaks conformance. There's not a single compiler anywhere
>in the world that would survive a conformance test of that kind.

Note: in Windows the operating system differentiates between console and
non-console applications.  This is a property of the executable file.
It is *not* a matter of which libraries it uses, which is independent.

Non-console applications constitute the larger number of applications
by far for this system (where the compiler is used).  It doesn't matter
which libraries one uses  --  one might even (perversely) choose
to use only the standard C++ library, although that would have serious
consequences for usability  --  with respect to the ability to use
"main()" or not a non-console application in MSVC means no "main()".

(Unless one employs the relatively unknown linker trickery mentioned.)

On the basis of that, I maintain that MSVC is non-conforming wrt.
"main()": for the most common kind of application, regardless of
libraries, you can't use "main()", and there is no "main()".

Cheers,

- Alf


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alf P. Steinbach wrote:
....
> Note: in Windows the operating system differentiates between console and
> non-console applications.  This is a property of the executable file.
> It is *not* a matter of which libraries it uses, which is independent.

If you say so; but that's a radical change from the way they did things
the last time I had to write a Windows program. Of course, that was a
long time ago (a fact for which I'm glad). Still, I wouldn't be
surprised if you were misinterpreting something, possibly because of a
development environment that hides certain aspects of the situation from
you.
Either way, it's not relevant to the conformance question.

....
> On the basis of that, I maintain that MSVC is non-conforming wrt.
> "main()": for the most common kind of application, regardless of
> libraries, you can't use "main()", and there is no "main()".

If MSVC has a mode that does permit main(), then it is can be a
conforming hosted implementation in that mode. It doesn't matter if it
has another mode that doesn't permit main(). And, as has been pointed
out before, even in a mode where it doesn't permit main(), it can still
qualify as a conforming free-standing implementation.

 From what I've heard, it doesn't qualify as conforming, in either mode,
but not because of whether or not it allows a user-defined main().


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat, 5 Oct 2002 23:36:21 +0000 (UTC), kuyper@wizard.net ("James Russell Kuyper
Jr.") wrote:

>Alf P. Steinbach wrote:
>....
>> Note: in Windows the operating system differentiates between console and
>> non-console applications.  This is a property of the executable file.
>> It is *not* a matter of which libraries it uses, which is independent.
>
>If you say so; but that's a radical change from the way they did things
>the last time I had to write a Windows program.

If that was 16-bits Windows 2.x or earlier, then perhaps.  It has not been
the way you describe (some library with "main") in Windows 3.0 and later,
which means essentially 1990, or thereabouts, till today.  I strongly doubt
that it ever was the way you describe, and suspect that



>you were misinterpreting something, possibly because of a development
>environment that [hid] certain aspects of the situation from you.



>...
>Either way, it's not relevant to the conformance question.

It removes the "library provided main()" argument from the equation,
and so it is of course relevant to the discussion.



>....
>> On the basis of that, I maintain that MSVC is non-conforming wrt.
>> "main()": for the most common kind of application, regardless of
>> libraries, you can't use "main()", and there is no "main()".
>
>If MSVC has a mode that does permit main(), then it is can be a
>conforming hosted implementation in that mode. It doesn't matter if it
>has another mode that doesn't permit main().

When that is the main usage of the compiler, which it is, it matters.



> And, as has been pointed out before, even in a mode where it doesn't
> permit main(), it can still qualify as a conforming free-standing
> implementation.

Let's concentrate on hosted implementation; the conformance or not as
a free-standing implementation is IMHO not interesting.



> From what I've heard, it doesn't qualify as conforming, in either mode,
> but not because of whether or not it allows a user-defined main().

That is correct, but given the work that is going on towards making it
a conforming implementation, involving some very good people, and given
the widespread usage of that compiler (perhaps the most used C++
compiler?), I think it *is* important to delineate the areas of
non-conformance  --  not just in the sense of conformance in some
artificial or trivial usage, but conformance in real-world usage,
including, e.g., support for "main()", for exceptions, for RTTI, etc.

If the concensus (how do you spell that?) of this group becomes that the
compiler doesn't need to support "main()" for its common usage, then we
can't expect that any effort will be expended in that direction.

Cheers,

- Alf

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alf P. Steinbach wrote:
> On Sat, 5 Oct 2002 23:36:21 +0000 (UTC), kuyper@wizard.net ("James Russell Kuyper
> Jr.") wrote:
....
> When that is the main usage of the compiler, which it is, it matters.

Standards conformance isn't a matter of practicality; almost no one ever
uses any compiler in it's fully conforming mode. Almost no-one writes
maximally-portable code. It should be the case that most
maximally-portable code will be translated and executed properly using
MSVC in it's fully conforming mode, and MSVC does indeed have a mode
that does a passable job of conforming (thought not a very good one).
However, that mode is almost necessarily a console mode, because
maximally-portable code tends to define console programs. That's because
the standard has no concept of a GUI interface.

If you want a fully conforming non-console mode, I have to ask "why?".
Because there's not much that you gain from such a mode that a fully
conforming console-mode doesn't already give you. You can't expect to
port GUI code between different GUI environments, without a fair amount
of very careful re-coding or conditional compilation. Changing main()
into something else is probably the least of your worries while
attempting such a port.

It would be nice if there were a GUI standard that code could conform
to, but that's outside the scope of the C++ standard. A GUI standard
should be multi-language - in the unlikely event that one ever gets
approved, the proper role of C++ standard should be limited to defining
a C++ interface conforming to that standard.

....
> Let's concentrate on hosted implementation; the conformance or not as
> a free-standing implementation is IMHO not interesting.

Well, you can complain about the fact that free-standing implementation
doesn't meet the conformance requirements of a hosted implementation,
but that seems pretty fruitless argument to me.

Could you show me a reason why anyone coding for Windows should care
about the absence of support for main()? Could you show me why anyone
not coding for Windows should care that their program would have to be
compiled as a console program to run under Windows? Only then will I see
that there's a point in worrying about this.

> If the concensus (how do you spell that?) of this group becomes that the

"consensus"

> compiler doesn't need to support "main()" for its common usage, then we
> can't expect that any effort will be expended in that direction.

On the contrary, the consensus of this group is almost completely
irrelevant. This group has no powers, whatsoever. A few committee
members post here, and some of them take ideas generated here back to
the committee itself. But it doesn't matter in the slightest how popular
those ideas are - all that matters is whether those committee members
like them well enough to take back to the committee. And of course, once
there, it matters what the consensus of the committee is; but that can
be quite different from the consensus of this newsgroup.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat, 5 Oct 2002 10:01:44 +0000 (UTC), kuyper@wizard.net ("James Russell Kuyper
Jr.") wrote:

>...
>The C++ standard doesn't make a single requirement anywhere that
>it must be possible to write non-console programs.

The C++ standard doesn't address the issue of program "kind".  However,
the std. support provided by a compiler for its most common usage must in
practice count in regarding it as conforming or not.  IMO, of course.


>In fact, it's not possible to write such programs without including some
>code somewhere that renders some or all of the standard's requirements
>inapplicable.

In fact, it is possible.  Since this is a textual medium, however, in
the following I must use a command line invocation that has console app
as default; therefore I must explicitly use a linker switch "/subsystem".
This is not necessary when using the compiler via the vendor supplied
IDE, so perhaps many folks are not aware that it is used.


========================================================================
C:\> copy con myadware.cpp
#include <iostream>
int main()
{
  std::cout << "Earn $$$!  Visit http://sneakysneaky.com NOW!" << std::endl;
  return 0;
}
^Z
        1 file(s) copied.

C:\> cl /nologo /GX /GR myadware.cpp /link /subsystem:windows
myadware.cpp
LIBC.lib(wincrt0.obj) : error LNK2019: unresolved external symbol _WinMain@16
referenced in function _WinMainCRTStartup
myadware.exe : fatal error LNK1120: 1 unresolved externals

C:\> link /nologo /entry:mainCRTStartup /subsystem:windows myadware.obj

C:\> myadware

C:\> myadware >t

C:\> type t
Earn $$$!  Visit http://sneakysneaky.com NOW!

C:\>
========================================================================

Note that no extra libraries, except libraries also linked in for a console
app, are linked to.

Off-topic explanation of details: /GX adds exception handling, which is off
by default for command line compiler invocation; /GR adds RTTI support, which
is off by default for command line compiler invocation; /subsystem specifies
the system kind of program, a property of the executable; the first program
invocation does nothing since, by virtue of being non-console, it's run as
a separate process with unconnected standard input and output; the second
invocation does have a result, since we explicitly connect standard output.



>Simply linking your code to the windows library, without
>doing anything else, is sufficient to make the behavior of your program
>implementation-defined at  best, and undefined at worst.

Note that above, no "windows library" is linked in.

In conclusion I still maintain that MSVC is non-conforming wrt. main(),
since for the compiler's most common usage you cannot use main() without
some little-known technical trickery (as shown above).

Cheers,

- Alf

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Russell Kuyper Jr.") wrote in message
news:<3D9CEEF8.1040807@wizard.net>...

> >  It certainly doesn't - we've all got examples of code that doesn't
> > "do the right thing" under the MS compiler.

> I don't! I'm blissfully unaware of just how badly their compiler would
> handle any of my code.

When I had to write code for Windows, I was actually pleasantly
surprised just how well their compiler handled my code.  Much better
than the Unix compilers which were current then.  This is VC++ 6.0
compared to g++ 2.95.2, Sun CC 4.2 and I'm not sure what version of
IBM's xlC.  Of the lot, VC++ was by far the most standards conform.
Largely because of its library, I'll admit, but the language does
include the library.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 7 Oct 2002 00:02:57 +0000 (UTC), kuyper@wizard.net ("James Kuyper Jr.")
wrote:

>Alf P. Steinbach wrote:
>> On Sat, 5 Oct 2002 23:36:21 +0000 (UTC), kuyper@wizard.net ("James Russell Kuyper
>> Jr.") wrote:
>....
>> When that is the main usage of the compiler, which it is, it matters.
>
>Standards conformance isn't a matter of practicality

We have a standard in order to support software development in practice.

It's not in order to support purely theoretic software development.

If it were, then very few folks would be interested in the standard.


>...
>If you want a fully conforming non-console mode, I have to ask "why?".
>Because there's not much that you gain from such a mode that a fully
>conforming console-mode doesn't already give you.

The details here are off-topic, but as background info: what the
non-console mode we're discussing (Windows GUI subsystem, a property of
the executable) is about is to not have a console window pop up when
you run the application from e.g. Explorer.  Which the operating system
otherwise does.  That's why that mode is used, and one problem with
the MSVC compiler is that it couples this property of the executable
with non-conformance wrt. "main()", that you don't then have a "main()".

(Unless the little known trick mentioned earlier is employed.)



>You can't expect to port GUI code between different GUI environments,
>without a fair amount of very careful re-coding or conditional compilation.

With some GUI libraries (e.g. TrollTech's) I understand that you can.

However, it's not relevant.


>Changing main() into something else is probably the least of your worries
>while attempting such a port.

That is also irrelevant.

Unless your position is that compiler standard-conformance is unimportant
except for creating programs that stick to the standard library exclusively?

If it is, then I must respect that you mean that, but cannot agree.



>....
>> Let's concentrate on hosted implementation; the conformance or not as
>> a free-standing implementation is IMHO not interesting.
>
>Well, you can complain about the fact that free-standing implementation
>doesn't meet the conformance requirements of a hosted implementation,
>but that seems pretty fruitless argument to me.

Since when did MSVC become a free-standing implementation?

It seems fruitless to me to regard it as free-standing.



>Could you show me a reason why anyone coding for Windows should care
>about the absence of support for main()?

Could you show me a reason why anyone coding for any specific system
should care about an absence of support for "main()"?

Is your position then that the requirement of a "main()" is
a meaningless one and should be removed from the standard?




>Could you show me why anyone not coding for Windows should care
>that their program would have to be compiled as a console program to
>run under Windows?

Yes, a console window would pop up when the app was run from e.g.
Explorer, courtesy of the very "helpful" operating system.



>Only then will I see that there's a point in worrying about this.

Perhaps there is hope... ;-)



>> If the concensus (how do you spell that?) of this group becomes that the
>
>"consensus"
>

Thanks.  That was sort of a test, also, although I honestly didn't
know the spelling.



>> compiler doesn't need to support "main()" for its common usage, then we
>> can't expect that any effort will be expended in that direction.
>
>On the contrary, the consensus of this group is almost completely
>irrelevant. This group has no powers, whatsoever. A few committee
>members post here, and some of them take ideas generated here back to
>the committee itself. But it doesn't matter in the slightest how popular
>those ideas are - all that matters is whether those committee members
>like them well enough to take back to the committee. And of course, once
>there, it matters what the consensus of the committee is; but that can
>be quite different from the consensus of this newsgroup.

Well, the process of awareness-forming has to start somewhere.  And if
people participating in this newsgroup can't agree that standard-
conformance is a Good Thing (TM), then IMHO the battle is lost before
it has even been considered.  Of course, there *are* more important
things than "main()", but let's say the end result would be that one
of the most used compilers, MSVC 8.0, was completely standard-conforming
as a hosted implementation, with just two exceptions: "export" and
"main"  --  wouldn't that be absurd, considering the relative technical
difficulties (high, near 0) of supporting these parts of the standard?

Cheers,

- Alf

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote in message
news:<3d9f81e3.205327125@news.bluecom.no>...
> On Sat, 5 Oct 2002 23:36:21 +0000 (UTC), kuyper@wizard.net ("James
> Russell Kuyper Jr.") wrote:

> >Alf P. Steinbach wrote:
> >....
> >> Note: in Windows the operating system differentiates between
> >> console and non-console applications.  This is a property of the
> >> executable file.  It is *not* a matter of which libraries it uses,
> >> which is independent.

> >If you say so; but that's a radical change from the way they did
> >things the last time I had to write a Windows program.

> If that was 16-bits Windows 2.x or earlier, then perhaps.  It has not
> been the way you describe (some library with "main") in Windows 3.0
> and later, which means essentially 1990, or thereabouts, till today.
> I strongly doubt that it ever was the way you describe, and suspect
> that

Two points of measure.  In 1990, the Microsoft OS that I was using was
MS-DOS 3.1.  There was no "console mode", of course, because there was
only one mode.  And the program required a main.  The second point is
that every time I've had to write software for a Microsoft OS, it has
been console mode.  Console mode is, as far as I can tell, the default
for command line invocation of the compiler under Windows NT.

I'm not sure what your point is.  If I want to write GUI software using
MFC, I'm so far from strictly conforming C++ that the name of the main
routine is irrelevant.  If I'm writing server software in C++, using,
say ACE to wrap my socket interface, most of my code (except for the
internals of ACE) is pretty close to standard C++.  And my program will
require a function main.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote
> Note: in Windows the operating system differentiates between console and
> non-console applications.  This is a property of the executable file.
> It is *not* a matter of which libraries it uses, which is independent.
>
> Non-console applications constitute the larger number of applications
> by far for this system (where the compiler is used).  It doesn't matter
> which libraries one uses  --  one might even (perversely) choose
> to use only the standard C++ library, although that would have serious
> consequences for usability  --  with respect to the ability to use
> "main()" or not a non-console application in MSVC means no "main()".
>
> (Unless one employs the relatively unknown linker trickery mentioned.)
>
> On the basis of that, I maintain that MSVC is non-conforming wrt.
> "main()": for the most common kind of application, regardless of
> libraries, you can't use "main()", and there is no "main()".

* Note: when operating a motor vehicle, I differentiate between
* home-state and out-of-state trips. This is a property of the
* destination for each trip. It is *not* a matter of which brand
* of gasoline I buy, which is independent.
*
* Home-state trips constitute the larger number of trips by far for
* my travels (when my car is used). It doesn't matter which gasoline
* one uses -- I might even (perversely) choose to use deisel fuel,
* although that would have serious consequences for my ability to
* start my car -- with respect to the ability to drive outside of my
* home state.
*
* On the basis of that, I maintain that my car is non-conforming wrt.
* traffic laws outside of my home state: for the most common kind of
* trip, regardless of the brand of gasoline, the out-of-state speed
* limit laws cannot be made to apply.

I suspect there is a flaw somewhere in that logic chain!

Here's another way to put it. Suppose you decide to use your MSVC
install disk as a coaster. (Given your apparent feelings about the
product, this might not be unbelievable.) However, your coffee cup
has a crack in it, and starts to leak resources. Even worse, your
coffee cup fails to declare even one variable, and has inconsistent
use of braces. Despite all of these failings in your coffee cup,
the MSVC install disk fails to "display a diagnostic." Are you
surprised? Of course not -- clearly, the C++ standard does not
apply to this particular use of the compiler.

But now suppose you start using it as a coaster 10 times as often
as you try to compile a standard-compliant application, so that
coaster-using becomes by far the most common use (in your home) for
that particular compiler. Despite this, the install disk still
mutely refuses to warn you about these potential problems.

Does that change things? I submit that it does not.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 7 Oct 2002 21:53:18 +0000 (UTC), allan_w@my-dejanews.com (Allan W) wrote:

>alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote
>> Note: in Windows the operating system differentiates between console and
>> non-console applications.  This is a property of the executable file.
>> It is *not* a matter of which libraries it uses, which is independent.
>>
>> Non-console applications constitute the larger number of applications
>> by far for this system (where the compiler is used).  It doesn't matter
>> which libraries one uses  --  one might even (perversely) choose
>> to use only the standard C++ library, although that would have serious
>> consequences for usability  --  with respect to the ability to use
>> "main()" or not a non-console application in MSVC means no "main()".
>>
>> (Unless one employs the relatively unknown linker trickery mentioned.)
>>
>> On the basis of that, I maintain that MSVC is non-conforming wrt.
>> "main()": for the most common kind of application, regardless of
>> libraries, you can't use "main()", and there is no "main()".
>
>* Note: when operating a motor vehicle, I differentiate between
>* home-state and out-of-state trips. This is a property of the
>* destination for each trip. It is *not* a matter of which brand
>* of gasoline I buy, which is independent.
>*
>* Home-state trips constitute the larger number of trips by far for
>* my travels (when my car is used). It doesn't matter which gasoline
>* one uses -- I might even (perversely) choose to use deisel fuel,
>* although that would have serious consequences for my ability to
>* start my car -- with respect to the ability to drive outside of my
>* home state.
>*
>* On the basis of that, I maintain that my car is non-conforming wrt.
>* traffic laws outside of my home state: for the most common kind of
>* trip, regardless of the brand of gasoline, the out-of-state speed
>* limit laws cannot be made to apply.
>
>I suspect there is a flaw somewhere in that logic chain!
>
>Here's another way to put it. Suppose you decide to use your MSVC
>install disk as a coaster. (Given your apparent feelings about the
>product, this might not be unbelievable.) However, your coffee cup
>has a crack in it, and starts to leak resources. Even worse, your
>coffee cup fails to declare even one variable, and has inconsistent
>use of braces. Despite all of these failings in your coffee cup,
>the MSVC install disk fails to "display a diagnostic." Are you
>surprised? Of course not -- clearly, the C++ standard does not
>apply to this particular use of the compiler.
>
>But now suppose you start using it as a coaster 10 times as often
>as you try to compile a standard-compliant application, so that
>coaster-using becomes by far the most common use (in your home) for
>that particular compiler. Despite this, the install disk still
>mutely refuses to warn you about these potential problems.
>
>Does that change things? I submit that it does not.

I think this is one of the best articles I've ever read on the Usenet,
at least one of the funniest.

But, seriously, the reasoning through analogy is erronous (as a
sidenote, this kind of "proof" is often submitted when no rational
argument exists, and it's a well-known form of fallacy, e.g. see
[http://www.nizkor.org/features/fallacies/appeal-to-ridicule.html]).

The main point where the above analogies break down:


  A compiler can meaningfully be standard-compliant or not, in
  various respects, but

  a car can not meaningfully be said to obey traffic laws or not,
  and

  a coaster can not meaningfully be C++ standard-compliant.


There are also other breakdowns of the above analogies.

But thanks for a good laugh... ;-)

Cheers,

- Alf

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alf P. Steinbach wrote:
....
> In conclusion I still maintain that MSVC is non-conforming wrt. main(),
> since for the compiler's most common usage you cannot use main() without
> some little-known technical trickery (as shown above).

It doesn't matter how bizarre or obscure the procedure is that is needed
to achieve this result; if using that procedure puts the compiler in a
mode where it meets all of the standard's requirements, then that mode
of the compiler is fully conforming. The fact that another mode exists
that is not fully comforming is irrelevant, even if that mode is by far
the more popular mode. In fact, that's usually the case. Most compilers
are non-conforming in their default mode, and not many people bother to
turn on (or off) the options needed to get into that compiler's fully
conforming mode.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 7 Oct 2002 21:48:00 +0000 (UTC), kanze@gabi-soft.de (James Kanze) wrote:

>alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote in message
>news:<3d9f81e3.205327125@news.bluecom.no>...
>> On Sat, 5 Oct 2002 23:36:21 +0000 (UTC), kuyper@wizard.net ("James
>> Russell Kuyper Jr.") wrote:
>
>> >Alf P. Steinbach wrote:
>> >....
>> >> Note: in Windows the operating system differentiates between
>> >> console and non-console applications.  This is a property of the
>> >> executable file.  It is *not* a matter of which libraries it uses,
>> >> which is independent.
>
>> >If you say so; but that's a radical change from the way they did
>> >things the last time I had to write a Windows program.
>
>> If that was 16-bits Windows 2.x or earlier, then perhaps.  It has not
>> been the way you describe (some library with "main") in Windows 3.0
>> and later, which means essentially 1990, or thereabouts, till today.
>> I strongly doubt that it ever was the way you describe, and suspect
>> that
>
>Two points of measure.  In 1990, the Microsoft OS that I was using was
>MS-DOS 3.1.  There was no "console mode", of course, because there was
>only one mode.  And the program required a main.

I'm not sure of the exact year, hence the "or thereabouts".  It's
possible Windows was in version 2.x in 1990.  Doesn't matter much,
does it?


>The second point is that every time I've had to write software for a
>Microsoft OS, it has been console mode.  Console mode is, as far as I
>can tell, the default for command line invocation of the compiler
>under Windows NT.

It sure is, and opposite when the compiler is used via the IDE.  The
command line default is also to not support proper stack unwinding
for exceptions, and to not support RTTI, wchar_t, for-loop scope, etc.

That doesn't mean very much wrt. actual use of the compiler, although
it would be nice to have those defaults fixed.

Summing up: with the default invocation there is a very long list of
compliance issues; with the common usage there is a somewhat shorter
list, but that list includes lack of support for "main()".


>I'm not sure what your point is.  If I want to write GUI software using
>MFC, I'm so far from strictly conforming C++ that the name of the main
>routine is irrelevant.  If I'm writing server software in C++, using,
>say ACE to wrap my socket interface, most of my code (except for the
>internals of ACE) is pretty close to standard C++.  And my program will
>require a function main.

So if I understand you correctly the need for standard-conformance,
e.g. support for "main()", is inversely proportional to the number
of non-standard library functions used in the typical code compiled
with a given mode of the compiler?

So that if a compiler is typically *used* for applications with a lot
of non-standard library functions, that compiler need not be standard-
compliant at all???

Cheers,

- Alf


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <7f2735a5.0210021231.3b1703e0@posting.google.com>, Allan W
<allan_w@my-dejanews.com> writes
>I agree that compilers should be required to accept void main().
>Microsoft isn't the only one that does this today (is it?), and
>it hasn't hurt anything. (Yes, Microsoft DOES support exiting
>with a value.)

And what else? A Standard is a contract between users and suppliers.
Basically it says 'if you, the user, does this then any standard
conforming implementation will do ...' If the user chooses to do
something else, that is fine but they have no right to expect an
implementation to support it just because others do.

Let me give you another example:
#include <iostream.h>
enum example { yes, no, maybe};

int main(){
   std::cout << example::yes;
   return 0;
}

Is accepted by MS VC++ 6. So should everyone else also accept it after
all treating iostream.h as a standard header is harmless and allowing an
enum to be treated as if it creates a scope would seem harmless.

Where do you want to stop?

--
Francis Glassborow      ACCU
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://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Allan W <allan_w@my-dejanews.com> writes
> >I agree that compilers should be required to accept void main().
> >Microsoft isn't the only one that does this today (is it?), and
> >it hasn't hurt anything. (Yes, Microsoft DOES support exiting
> >with a value.)

francis.glassborow@ntlworld.com (Francis Glassborow)
> And what else? A Standard is a contract between users and suppliers.
> Basically it says 'if you, the user, does this then any standard
> conforming implementation will do ...' If the user chooses to do
> something else, that is fine but they have no right to expect an
> implementation to support it just because others do.

Right. Furthermore, the process of changing the standard changes that
contract, usually (but not always) in ways that allow old code to be
accepted by the new standard. The changes might give programmers some
new capability that they did not previously have, but sometimes it's
just notational convenience -- and sometimes it merely documents
widespread (not neccesarily universal) existing practice.

> Let me give you another example:
> #include <iostream.h>
> enum example { yes, no, maybe};
>
> int main(){
>    std::cout << example::yes;
>    return 0;
> }
>
> Is accepted by MS VC++ 6. So should everyone else also accept it after
> all treating iostream.h as a standard header is harmless and allowing an
> enum to be treated as if it creates a scope would seem harmless.

I think you'll find that Microsoft isn't the only compiler that accepts
that, either. The other brands aren't neccesarily trying to be
compatible with Microsoft (although a lot of them clearly are), but with
pre-standard legacy C++ code.

> Where do you want to stop?

In general, I don't want any new features just because one brand happens
to accept it today. However, there is a lot of code written that
(incorrectly) uses void main(). In fact, there are even beginner-level
textbooks that do this (poor quality, to be sure -- but they exist).
People new to the language are sometimes surprised to find that
void main() is illegal, especially if they're writing code for a GUI
(which usually CAN take advantage of the exit code, but normally
doesn't). Even more advanced users can't easily tell you the reason
for that rule, as you've seen in this very thread.

By contrast, Microsoft also accepts a program that has no main() at
all, but does have a WinMain(). I would NOT want to see this in the
standard (and I think Microsoft made a mistake by introducing it in
the first place).

Turn the question around. You seem opposed to having the new standard
accept void main(). Is that simply because Microsoft does it today as
a non-standard extension (and is pretty lax about labelling it such)?
Or is there some more substantial reason why it should not be
permitted?

Where do you want to start?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message news:7f2735a5.0210031112.1def5cb5@posting.google.com...

> Right. Furthermore, the process of changing the standard changes that
> contract,

No contract is made about future changes of the standard, express or implied.


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
....
> By contrast, Microsoft also accepts a program that has no main() at
> all, but does have a WinMain(). I would NOT want to see this in the
> standard (and I think Microsoft made a mistake by introducing it in
> the first place).

Too late. The standard added that in a long time ago. I believe the
relevant clauses go all the way back to C90.

There's two different ways of looking at it. One of them is, that there
is a main() - it's just defined in the Windows library, rather than in
your code. It's the combination of the Windows library and your code
that constitutes a complete program under the rules of the C++ standard.
Of course, only parts of that library are written in C++, and since it's
Microsoft, even those parts are written in a highly non-standard dialect
of C++.
In any event, as long as the compiler allows you to NOT link to the
Windows library, it could (but probably doesn't) still qualify as a
fully comforming implementation of C++.

The second approach is to say that it's implementing a 'freestanding'
implementation of C++. As 3.6.1p1 says. "It is implementation-defined
whether a program in a freestanding environment is required to define a
main function." In such an environment, if main() isn't required,
there's usually some other function that serves a similar purpose, and
that's precisely what WinMain() is.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <7f2735a5.0210031112.1def5cb5@posting.google.com>, Allan W
<allan_w@my-dejanews.com> writes
>Turn the question around. You seem opposed to having the new standard
>accept void main(). Is that simply because Microsoft does it today as
>a non-standard extension (and is pretty lax about labelling it such)?
>Or is there some more substantial reason why it should not be
>permitted?

I am opposed to it because a major aspect of a standard is portability.
It says that if you write code to conform to certain rules it will
compile on any (in this case, hosted) system.

Now unlike you, I do not care that event driven programs for MS
compilers have a WinMain for the simple reason that such programs are
non-portable. I also care less than you do that some compilers allow
void main(). I did care that VC++ used to tell programmers who omitted a
return from their main() that they needed to declare void main() because
that was exactly wrong and unhelpful to programmers. I do care about
authors who give their readers wrong information because writers have a
responsibility to correctly inform their readers. As long as their are
systems that use the return from main for some purpose the standard
should require the return value to be declared and for portability that
means always declared for portable code.


--
Francis Glassborow      ACCU
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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 3 Oct 2002 22:33:56 +0000 (UTC), kuyper@wizard.net ("James Russell Kuyper
Jr.") wrote:

>Allan W wrote:
>....
>> By contrast, Microsoft also accepts a program that has no main() at
>> all, but does have a WinMain(). I would NOT want to see this in the
>> standard (and I think Microsoft made a mistake by introducing it in
>> the first place).
>
>Too late. The standard added that in a long time ago. I believe the
>relevant clauses go all the way back to C90.
>
>There's two different ways of looking at it. One of them is, that there
>is a main() - it's just defined in the Windows library, rather than in
>your code.

Nope  --  that kind of thinking means that no hosted implementation need
to support user-defined "main", since it can be regarded as already
defined.  That conflicts the standard's use of "shall contain", which
would then be meaningless.


>...
>The second approach is to say that it's implementing a 'freestanding'
>implementation of C++. As 3.6.1p1 says. "It is implementation-defined
>whether a program in a freestanding environment is required to define a
>main function." In such an environment, if main() isn't required,
>there's usually some other function that serves a similar purpose, and
>that's precisely what WinMain() is.

Nope  --  a freestanding implementation only needs to provide a handful
of critical headers; discussion about standards-conformance of that
compiler would then be meaningless (well, perhaps they are... ;-)).

But I think Microsoft's idea of a "wmain" function is a good one.

Yes, the argv strings are MBCS (whatever the standard calls it), but
there's no requirement, AFAIK, that e.g. a wide character filename in
the process argument(s) must be represented without information loss.

I've argued elsewhere (in [comp.lang.c++.moderated]) about the information
loss present in the whole main/argv Unix-inspired solution, but since that
solution is probably never going to be complemented by something better, as
a practical matter, wide character wmain arguments would be of of help to
especially C++ novices and for writing small test programs, I think.

Hm  --  thread drifting?

Cheers,

- Alf

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Russell Kuyper Jr.") writes:

> There's two different ways of looking at it. One of them is, that
> there is a main() - it's just defined in the Windows library, rather
> than in your code.

The standard says (3.6.1/p1)

 1 A program shall contain a global function called main, which is
   the designated start of the program. It is implementation defined
   whether a program in a freestanding environment is _required_ to
   define a main function.

[...]

  2 An implementation shall not predefine the main function.

[My emphasis]

So a program in a freestanding envirionment may or may not be
_required_ to provide a main() functions, but since an implementation
is prohibited from doing so, a program may feel free to do so.

*IF* the Windows libraries define the function main(), then it's clear
that this (i.e. Windows GUI programming) is neither a hosted
environment, nor a freestanding one and hence is non-conforming.

Console applications, on the other hand, still use main() as an entry
point.

> and since it's Microsoft, even those parts are written in a
> highly non-standard dialect of C++.

Not quite - Microsoft actually implement a fairly large subset of
standard C++, so you can write quite a lot of code in a highly
standard dialect of C++ - sure, it's a limited subset, but it *is*
standard. Like a lot (if not all) other vendors, they offer extentions
to the standard - and then it's up the the user whether they write
their code in your "highly non-standard dialect".

> In any event, as long as the compiler allows you to NOT link to the
> Windows library, it could (but probably doesn't) still qualify as a
> fully comforming implementation of C++.

 It certainly doesn't - we've all got examples of code that doesn't
"do the right thing" under the MS compiler.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) writes:

> On Thu, 3 Oct 2002 22:33:56 +0000 (UTC), kuyper@wizard.net
>  ("James Russell Kuyper Jr.") wrote:
>
> >Allan W wrote:
>
> >...  The second approach is to say that it's implementing a
> >'freestanding' implementation of C++. As 3.6.1p1 says. "It is
> >implementation-defined whether a program in a freestanding
> >environment is required to define a main function." In such an
> >environment, if main() isn't required, there's usually some other
> >function that serves a similar purpose, and that's precisely what
> >WinMain() is.
>
> Nope -- a freestanding implementation only needs to provide a
> handful of critical headers;

Which doesn't change the fact that the MS compiler, when used to build
Windows event-driven applications, could be considered a freestanding
environment to "sidestep" the main() requirement. The fact that a f/s
implementation is not _required_ to provide a complete library does
not _prevent_ it from doing so.

> discussion about standards-conformance of that
> compiler would then be meaningless

How so? The Standard spends a lot of time talking about the language,
which is distinct from the library. There's very little of the
language which is "optional" for a freestanding
implementation. Discussion about the standards conformance of a
language implemenation is anything but meaningless.

> (well, perhaps they are... ;-)).

Quite probably in the case of MSVC++ 6. In reality, since (AFAIK),
Microsoft (at least with MSVC 6) don't claim to implement ISO/IEC
14882 then discussion about their standards compliance is moot.

> But I think Microsoft's idea of a "wmain" function is a good one.

I don't. (See below)

> Yes, the argv strings are MBCS (whatever the standard calls it),

NTMBS - null-terminated multi-byte strings.

> but there's no requirement, AFAIK, that e.g. a wide character
> filename in the process argument(s) must be represented without
> information loss.

Similary, there's no requirement that information be lost.

> I've argued elsewhere (in [comp.lang.c++.moderated]) about the information
> loss present in the whole main/argv Unix-inspired solution

I believe I've seen some of that discussion, and I'm afraid I didn't
really follow it, since I consider it to be a bit of a non-starter.
Correct me if I'm wrong, but I understand your position to be that the
argv[] array can't contain the "command line" as used to invoke the
program? I'm afraid that it can - at least, as far as the C++ standard
is concerned.

3.6.1/p2 states:

   In the latter form argc shall be the number of arguments passed to
   the program from the environment in which the program is run.

There might be an enviromnet which considers the entire "command line"
to be a single argument, in which case argc would be "2", and argv[1]
would point to the start of a NTMBS which represents the entire command
line.

It's clear (to me) that the standard _allows_ environments which do
what [I think it is that] you want. The fact that many environments
don't is another problem altogether.

> but since that solution is probably never going to be complemented
> by something better

If by "better" you mean something more convenient for your use, I
don't know. Perhaps you should write an extention proposal, submit it
to WG21 and then lobby for support. I think you'd have a hard time of
it, given that "int main( int argc, char *argv[] )" allows all the
information that _you_ want to be passed to your program, but (as a
friend of mine is fond of saying), "if you don't ask you don't get".

> as a practical matter, wide character wmain arguments would be of of
> help to especially C++ novices

My experience of C++ novices is that wide characters draw blank stares
- I, personally, don't see a "wmain" being of help to them.

> Hm  --  thread drifting?

Indeed.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alf P. Steinbach wrote:
> On Thu, 3 Oct 2002 22:33:56 +0000 (UTC), kuyper@wizard.net ("James Russell Kuyper
> Jr.") wrote:
>
>
>>Allan W wrote:
....
>>There's two different ways of looking at it. One of them is, that there
>>is a main() - it's just defined in the Windows library, rather than in
>>your code.
>
>
> Nope  --  that kind of thinking means that no hosted implementation need
> to support user-defined "main", since it can be regarded as already
> defined.  That conflicts the standard's use of "shall contain", which
> would then be meaningless.

You're missing my point. There's a compiler, the standard C++ library,
and some other library or libraries. If one of the other libraries
happens to contain main(), and the compiler allows you to NOT link to
that library, then it remains a conforming compiler. Just because
linking in that library ahead of your own code would prevent you from
usefully defining your own main(), wouldn't make the compiler
non-conforming.

It would be a different matter if the windows library was packaged
inextricably with the C++ standard library. However, the last time I
checked (which, admittedly, was a VERY long time ago), they were
packaged as physically separate libraries.

>>The second approach is to say that it's implementing a 'freestanding'
>>implementation of C++. As 3.6.1p1 says. "It is implementation-defined
>>whether a program in a freestanding environment is required to define a
>>main function." In such an environment, if main() isn't required,
>>there's usually some other function that serves a similar purpose, and
>>that's precisely what WinMain() is.
>
>
> Nope  --  a freestanding implementation only needs to provide a handful
> of critical headers; discussion about standards-conformance of that
> compiler would then be meaningless (well, perhaps they are... ;-)).

To me that sounds a lot more like a "Yep, but in that case I don't
care", than a "Nope".

Saying that something is a conforming hosted implementation certainly
carries far more meaning than merely saying that it's a conforming
free-standing implementation. That doesn't make the latter statement
meaningless. If nothing else, a free-standing implementation must still
fully implement the language clauses of the standard (sections 2-16),
even if it's not required to provide most of the standard library. In
fact, there's an awful lot of implementations out there that don't
provide the full standard library. They rely on third-party
implementations for the templated parts of the library.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andy Sawyer wrote:
> kuyper@wizard.net ("James Russell Kuyper Jr.") writes:
....
> *IF* the Windows libraries define the function main(), then it's clear
> that this (i.e. Windows GUI programming) is neither a hosted
> environment, nor a freestanding one and hence is non-conforming.

Right. "Compiler+standard library + library X", considered as a single
entity acting on program Y, where X is just about any commonly used
library you care to choose, is NOT a conforming implementation of C.
That's because any unreserved symbol defined by library X can interfere
with user code that uses that symbol. However, that doesn't prevent
"Compiler+standard library" from being a conforming implementation, even
when it's acting on a program that consists of "library X + user code Y".

....
>>and since it's Microsoft, even those parts are written in a
>>highly non-standard dialect of C++.
>
>
> Not quite - Microsoft actually implement a fairly large subset of
> standard C++, so you can write quite a lot of code in a highly
> standard dialect of C++ - sure, it's a limited subset, but it *is*

Yes, but how much of Microsoft's own library code is written exclusively
in that limited subset? That's what I was talking about. I actually
don't know, I've been free of the need to write Windows code for more
than six years now. However, from my past experience, I doubt that any
section of Microsoft's own code longer than about 20 lines is entirely
free of Microsoft-specific extensions (usually brought in by way of
seemingly innocuous macros).

>>In any event, as long as the compiler allows you to NOT link to the
>>Windows library, it could (but probably doesn't) still qualify as a
>>fully comforming implementation of C++.
>
>
>  It certainly doesn't - we've all got examples of code that doesn't
> "do the right thing" under the MS compiler.

I don't! I'm blissfully unaware of just how badly their compiler would
handle any of my code.


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis.glassborow@ntlworld.com (Francis Glassborow) wrote in message
news:<eESy1mBxPgm9Ewfr@robinton.demon.co.uk>...
> In article <d6651fb6.0210010434.568be190@posting.google.com>, James
> Kanze <kanze@gabi-soft.de> writes
> >I would, in fact, recommend that the general structure of main be:

> >    int
> >    main()
> >    {
> >        try {
> >            //  ...
> >        } catch ( int returnValue ) {
> >            return returnValue ;
> >        }
> >        return 0 ;
> >    }

> >To terminate from an arbitrary place in the code, you execute "throw
> >returnValue".  At least for programs that normally terminate.

> Yes, what I once called the 'unexceptional exception' :-)

Well, it's exceptional enough.  I mean, it only happens once, no matter
how long the program runs. :-)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 4 Oct 2002 12:04:33 +0000 (UTC), andys@evo6.com (Andy Sawyer) wrote:

>alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) writes:
>
>> On Thu, 3 Oct 2002 22:33:56 +0000 (UTC), kuyper@wizard.net
>>  ("James Russell Kuyper Jr.") wrote:
>>
>> >Allan W wrote:
>>
>> >...  The second approach is to say that it's implementing a
>> >'freestanding' implementation of C++. As 3.6.1p1 says. "It is
>> >implementation-defined whether a program in a freestanding
>> >environment is required to define a main function." In such an
>> >environment, if main() isn't required, there's usually some other
>> >function that serves a similar purpose, and that's precisely what
>> >WinMain() is.
>>
>> Nope -- a freestanding implementation only needs to provide a
>> handful of critical headers;
>
>Which doesn't change the fact that the MS compiler, when used to build
>Windows event-driven applications, could be considered a freestanding
>environment to "sidestep" the main() requirement. The fact that a f/s
>implementation is not _required_ to provide a complete library does
>not _prevent_ it from doing so.

By that argument no C++ compiler need to insist on main; it would just
be a freestanding compiler in the cases where you omit main.

So, your position is that according to the standard no compiler need
to insist on a main function.

It seems sort of anti-logical to me... ;-)



>...
>Quite probably in the case of MSVC++ 6. In reality, since (AFAIK),
>Microsoft (at least with MSVC 6) don't claim to implement ISO/IEC
>14882 then discussion about their standards compliance is moot.

The v6 compiler was based on either CD1 or CD2, I don't remember which.

The v7 compiler is based on the actual standard, and a list of compliance
issues is provided in the documentation.



>> But I think Microsoft's idea of a "wmain" function is a good one.
>
>I don't. (See below)
>
>> Yes, the argv strings are MBCS (whatever the standard calls it),
>
>NTMBS - null-terminated multi-byte strings.
>
>> but there's no requirement, AFAIK, that e.g. a wide character
>> filename in the process argument(s) must be represented without
>> information loss.
>
>Similary, there's no requirement that information be lost.

Summing up, there are no requirement about the contents, so any program
relying on e.g. Unicode filenames in main arguments would be non-portable.




>> I've argued elsewhere (in [comp.lang.c++.moderated]) about the information
>> loss present in the whole main/argv Unix-inspired solution
>
>I believe I've seen some of that discussion, and I'm afraid I didn't
>really follow it, since I consider it to be a bit of a non-starter.
>Correct me if I'm wrong, but I understand your position to be that the
>argv[] array can't contain the "command line" as used to invoke the
>program?

No to both "can't" and "as used to invoke the program".

Short version: the standard places no clear requirements on argv.  This
allows an implementation to discard all or part of the information passed
to the process creation.  E.g., the convention for Windows compilers (not
specificied by the standard, but that lack of specification is an issue)
is to parse the Windows process creation command line into Unix-like
arguments, discarding information (e.g. spaces) as necessary to do that.




>I'm afraid that it can - at least, as far as the C++ standard is concerned.

No need to panic, even when the standard gets something right!



>3.6.1/p2 states:
>
>   In the latter form argc shall be the number of arguments passed to
>   the program from the environment in which the program is run.
>
>There might be an enviromnet which considers the entire "command line"
>to be a single argument, in which case argc would be "2", and argv[1]
>would point to the start of a NTMBS which represents the entire command
>line.
>
>It's clear (to me) that the standard _allows_ environments which do
>what [I think it is that] you want. The fact that many environments
>don't is another problem altogether.

No, that is the problem.



>> but since that solution is probably never going to be complemented
>> by something better
>
>If by "better" you mean something more convenient for your use, I
>don't know. Perhaps you should write an extention proposal, submit it
>to WG21 and then lobby for support. I think you'd have a hard time of
>it, given that "int main( int argc, char *argv[] )" allows all the
>information that _you_ want to be passed to your program, but (as a
>friend of mine is fond of saying), "if you don't ask you don't get".

I don't think it's important of itself.  The importance has to do with
e.g. an extension in C++0x to support fixed size types.  The connection
is the mind-set of trying to make the language theoretically compatible
with every system, even though in practice it isn't and cannot be.



>> as a practical matter, wide character wmain arguments would be of of
>> help to especially C++ novices
>
>My experience of C++ novices is that wide characters draw blank stares
>- I, personally, don't see a "wmain" being of help to them.
>
>> Hm  --  thread drifting?
>
>Indeed.

Cheers,

- Alf

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 4 Oct 2002 12:06:20 +0000 (UTC), kuyper@wizard.net ("James Russell Kuyper
Jr.") wrote:

>Alf P. Steinbach wrote:
>> On Thu, 3 Oct 2002 22:33:56 +0000 (UTC), kuyper@wizard.net ("James Russell Kuyper
>> Jr.") wrote:
>>
>>
>>>Allan W wrote:
>....
>>>There's two different ways of looking at it. One of them is, that there
>>>is a main() - it's just defined in the Windows library, rather than in
>>>your code.
>>
>>
>> Nope  --  that kind of thinking means that no hosted implementation need
>> to support user-defined "main", since it can be regarded as already
>> defined.  That conflicts the standard's use of "shall contain", which
>> would then be meaningless.
>
>You're missing my point. There's a compiler, the standard C++ library,
>and some other library or libraries. If one of the other libraries
>happens to contain main(), and the compiler allows you to NOT link to
>that library, then it remains a conforming compiler. Just because
>linking in that library ahead of your own code would prevent you from
>usefully defining your own main(), wouldn't make the compiler
>non-conforming.


1.  You're literally correct that some library may contain a main().
    I seem to remember that e.g. the MSVC screensaver lib does contain a
    main().  But that isn't relevant to ordinary use of the compiler.

2.  The standard says explicitly that main shall not be predefined.
    In other words, a hypothetical compiler that provided a main for ordinary
    use of the compiler would be non-conforming.

3.  As a hosted implementation MSVC is non-conforming wrt. main.
    You can use any of "wmain", "WinMain" and "wWinMain" instead of "main",
    and the tools make it *much* more difficult to use "main" instead of
    one of the others for the most common usage of the compiler  --  so
    much so that most programmers, and indeed the MS technical writers,
    seem to be unaware that by technical trickery you can use "main".


I don't understand the point of trying to use the concept of freestanding
implementation as a sort of "legal loop-hole" for compilers that are
obviously not meant as nor marketed as freestanding implementations.

Cheers,

- Alf

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Russell Kuyper Jr.") writes:

> Right. "Compiler+standard library + library X", considered as a single
> entity acting on program Y, where X is just about any commonly used
> library you care to choose, is NOT a conforming implementation of
> C.

I'd suggest that that would be a discussion for comp.lang.c. I'm
certainly not familiar enough with the C standard to agree or disagree
with your comment.

> > standard C++, so you can write quite a lot of code in a highly
> > standard dialect of C++ - sure, it's a limited subset, but it *is*
>
> Yes, but how much of Microsoft's own library code is written
> exclusively in that limited subset?

I don't see how that's relevant, since I'm not aware of any
requirement that _any_ of the standard library be written in C++. I'd
be grateful if you'd give me the reference in the standard which
places such a requirement on implementations. How many vendors can you
name whose _entire_ standard library is implemented entirely in C++?
And how many of them implement the _entire_ language, as specified by
the standard? I don't think I'm going to need both hands to count
them.

> That's what I was talking about. I actually don't know, I've been
> free of the need to write Windows code for more than six years
> now.

Just to clarify a couple of points about that statement:
1) are you claiming that it's been more that six years since you've
   had any experience of what you're talking about?
2) Are we talking about Microsoft's compiler or Windows programming?

> However, from my past experience, I doubt that any section of
> Microsoft's own code longer than about 20 lines is entirely free of
> Microsoft-specific extensions (usually brought in by way of
> seemingly innocuous macros).

Again, Microsoft (as can any implementor) can do whatever they want in
their own code - as long as they provide the interfaces and behaviour
specified by the standard.

> I don't! I'm blissfully unaware of just how badly their compiler would
> handle any of my code.

Just to clarify that statement - are you saying that you're happy that
you don't know what you're talking about? (I don't imagine for a
moment that that _is_ what you're saying, but I can't find any other
way to read it).

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

""James Russell Kuyper Jr."" <kuyper@wizard.net> wrote in message
news:3D9CEEF8.1040807@wizard.net...

> >>and since it's Microsoft, even those parts are written in a
> >>highly non-standard dialect of C++.
> >
> > Not quite - Microsoft actually implement a fairly large subset of
> > standard C++, so you can write quite a lot of code in a highly
> > standard dialect of C++ - sure, it's a limited subset, but it *is*
>
> Yes, but how much of Microsoft's own library code is written exclusively
> in that limited subset?

Quite a lot, actually.

>                         That's what I was talking about. I actually
> don't know, I've been free of the need to write Windows code for more
> than six years now. However, from my past experience, I doubt that any
> section of Microsoft's own code longer than about 20 lines is entirely
> free of Microsoft-specific extensions (usually brought in by way of
> seemingly innocuous macros).

There are, indeed, a few _CDECLs peppered around, which mostly matter
only when building DLLs (not discussed in the C++ Standard). But I
can think of long swatches of code that are unchanged between VC++
and several other compilers that also use our C++ library.

> >>In any event, as long as the compiler allows you to NOT link to the
> >>Windows library, it could (but probably doesn't) still qualify as a
> >>fully comforming implementation of C++.
> >
> >  It certainly doesn't - we've all got examples of code that doesn't
> > "do the right thing" under the MS compiler.
>
> I don't! I'm blissfully unaware of just how badly their compiler would
> handle any of my code.

Or how well...

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) writes:

> By that argument no C++ compiler need to insist on main; it would just
> be a freestanding compiler in the cases where you omit main.
>=20
> So, your position is that according to the standard no compiler need
> to insist on a main function.

My position is that according to the standard, no _freestanding
implementation_ need insist on main. It then becomes a commercial
decision on the part of the vendors whether or not to stay in business
in those marketplaces which expect a hosted implementation.

> It seems sort of anti-logical to me... ;-)

How is it "anti-logical" (whatever that means=B9). It seems to be
exactly what the standard says to me.

> >Quite probably in the case of MSVC++ 6. In reality, since (AFAIK),
> >Microsoft (at least with MSVC 6) don't claim to implement ISO/IEC
> >14882 then discussion about their standards compliance is moot.
>=20
> The v6 compiler was based on either CD1 or CD2, I don't remember which.
>=20
> The v7 compiler is based on the actual standard, and a list of complian=
ce
> issues is provided in the documentation.


The issue isn't which language specification the compiler was "based
on", it's whether Microsoft claim to be conforming. I don't believe
that they do (hence the list of issues which you mention).

> Summing up, there are no requirement about the contents, so any
> program relying on e.g. Unicode filenames in main arguments would be
> non-portable.

 It depends what you mean by "non-portable". If you mean "cannot be
ported to _all_ platforms where C++ compilers exists", then yes. But
that's true about a program relying on, e.g. the argv[] string being
split in the traditional Unix-inspired fashion. Or even the existence
of any kind of arguments in the argv[] array. Any program making _any_
assumptions about the contents of the argv[] array (other than argc is
non-negative and argv[argc] is null) is "non-portable" - because there
are environments where the concept of program arguments are
meaningless.

> Short version: the standard places no clear requirements on argv.

See above.
Actually, the standard DOES place requirements on argv - just not the
requirements that you want.

> This allows an implementation to discard all or part of the
> information passed to the process creation.  E.g., the convention
> for Windows compilers (not specificied by the standard, but that
> lack of specification is an issue) is to parse the Windows process
> creation command line into Unix-like arguments, discarding
> information (e.g. spaces) as necessary to do that.

This allows implementation-defined behaviour. So do lots of other
things in the standard - and many of those are more worthy of your
efforts than invocation arguments. The convention adopted by many
Windows compilers is (presumably) to _ease_ the porting of existing
Unix-targetted programs. There's no reason you shouldn't lobby
compiler (and OS) vendors to provide something different.

> >It's clear (to me) that the standard _allows_ environments which do
> >what [I think it is that] you want. The fact that many environments
> >don't is another problem altogether.
>=20
> No, that is the problem.

But that's a problem with the environments rather than the language
specification.

> I don't think it's important of itself.

Then why expend so much time, effort and bandwidth on it? It's quite
clear from the cogence of your arguments that if you directed your
attention to something which you _do_ deem to be important, you could
achive something useful.

> The importance has to do with e.g. an extension in C++0x to support
> fixed size types.  The connection is the mind-set of trying to make
> the language theoretically compatible with every system, even though
> in practice it isn't and cannot be.

I've never seen the existence of such a mind-set when sitting in WG21
commitee meetings. I /have/ seen a concerted effort to attempt to make
the language as widely usable as possible - not the same thing at all.
Bear in mind that the people who give their time (in many cases at
their own, personal, expense) and expertise to the standards process
have, both collectively and individually, a _huge_ wealth of
experience and knowledge regarding the many and varied platforms on
which languages such as C++ will be used. To label them with this
mind-set is a huge disservice to them, yourself and the C++ community
at large.

 Presumably you would be happier if they had the "mind-set" of
ensuring that the language was tailored specifically to your exact
needs on your preferred platform? I'd suggest the best place for that
would be your platform's vendors.

Regards,
 Andy S.

Footnotes:=20
=B9 I realise that you may not be a native English speaker, so would
  appreciate an explanation of what you intended "anti-logical" to
  mean.
--=20
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) writes:

> 3.  As a hosted implementation MSVC is non-conforming wrt. main.
>     You can use any of "wmain", "WinMain" and "wWinMain" instead of
>     "main", and the tools make it *much* more difficult to use
>     "main" instead of one of the others for the most common usage of
>     the compiler -- so much so that most programmers, and indeed the
>     MS technical writers, seem to be unaware that by technical
>     trickery you can use "main".

Thanks for telling me I had to use "technical trickery" to use main
with MSVC 6. I've been doing so for years, and wasn't aware that my
edit/compile/link cycle counted as "technical trickey".

,----[ hello.cpp ]
| #include <iostream>
| int main( )
| {
|     std::cout << "Hello, techincal trickster!" << std::endl;
|     // lame attempt to stay on topic by dropping off the bottom
| }
`----

c:\> cl hello.cpp

So the "technical trickery" you refer to is:
1) Write source code
2) Invoke compiler

Yes, I see the difficulty there.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 4 Oct 2002 18:40:24 +0000 (UTC), andys@evo6.com (Andy Sawyer) wrote:

>alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) writes:
>
>> 3.  As a hosted implementation MSVC is non-conforming wrt. main.
>>     You can use any of "wmain", "WinMain" and "wWinMain" instead of
>>     "main", and the tools make it *much* more difficult to use
>>     "main" instead of one of the others for the most common usage of
>>     the compiler -- so much so that most programmers, and indeed the
>>     MS technical writers, seem to be unaware that by technical
>>     trickery you can use "main".
>
>Thanks for telling me I had to use "technical trickery" to use main
>with MSVC 6. I've been doing so for years, and wasn't aware that my
>edit/compile/link cycle counted as "technical trickey".
>
>,----[ hello.cpp ]
>| #include <iostream>
>| int main( )
>| {
>|     std::cout << "Hello, techincal trickster!" << std::endl;
>|     // lame attempt to stay on topic by dropping off the bottom
>| }
>`----
>
>c:\> cl hello.cpp

Let's see.  We ordinarily use a C++ compiler to produce console
"Hello, world!" programs.  Yes.



>So the "technical trickery" you refer to is:
>1) Write source code
>2) Invoke compiler

No, it was to specify a runtime library entry-point to the linker.
That way you can use main() for a non-console application.  Which
is what that compiler is most commonly used for.



>Yes, I see the difficulty there.

Good.


Cheers,

- Alf

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 Please consider taking this to email; the standard-related content is flatlining...


===================================== END OF MODERATOR'S COMMENT
On Fri, 4 Oct 2002 18:25:37 +0000 (UTC), andys@evo6.com (Andy Sawyer) wrote:

>alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) writes:
>
>> By that argument no C++ compiler need to insist on main; it would just
>> be a freestanding compiler in the cases where you omit main.
>>=20
>> So, your position is that according to the standard no compiler need
>> to insist on a main function.
>
>My position is that according to the standard, no _freestanding
>implementation_ need insist on main. It then becomes a commercial
>decision on the part of the vendors whether or not to stay in business
>in those marketplaces which expect a hosted implementation.
>
>> It seems sort of anti-logical to me... ;-)
>
>How is it "anti-logical" (whatever that means=B9). It seems to be
>exactly what the standard says to me.

A requirement that in every concrete case can be dismissed is not
meaningful.  So your interpretation that on a case-by-case basis
an implementation should be regarded as freestanding or hosted,
depending on the case, isn't a meaningful interpretation.  Adopting
such a meaningless interpretation is not logical.  However, mr.
Spock has suggested that perhaps you've done this in order to
highlight a deficiency in the current wording.  Is that so?


>...
>This allows implementation-defined behaviour. So do lots of other
>things in the standard - and

[A]
>many of those are more worthy of your efforts than invocation arguments.
>...

[B]
>It's quite
>clear from the cogence of your arguments that if you directed your
>attention to something which you _do_ deem to be important, you could
>achive something useful.

I thank you for the compliment regarding my ability to argue so well
that to your mind it's "cogent" (whatever that is), while at the
same time I must apologize for arguing so well that you feel you must
imply things of a more personal nature, instead of arguing your case.



>> The importance has to do with e.g. an extension in C++0x to support
>> fixed size types.  The connection is the mind-set of trying to make
>> the language theoretically compatible with every system, even though
>> in practice it isn't and cannot be.
>
>I've never seen the existence of such a mind-set when sitting in WG21
>commitee meetings.

That does not, of course, mean that it does not exist.


>...
[C]
>To label them with this mind-set is a huge disservice to them, yourself
>and the C++ community at large.

The people you're referring to are *not* a homogenous mass of
conformists.

E.g., as far as I know, you're the first commitee member who has
used the approach exemplified by quotes [A, B, C, D] instead of a
technical approach in a discussion with me.

I have only the highest regard for e.g. Glassbarrow, Potter and
Stroustrup, which I believe are on the committee (I may be wrong),
and with whom I have sometime or other discussed various things.



[D]
>Presumably you would be happier if they had the "mind-set" of
>ensuring that the language was tailored specifically to your exact
>needs on your preferred platform? I'd suggest the best place for that
>would be your platform's vendors.

EOD.

Cheers,

- Alf

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <d6651fb6.0210010434.568be190@posting.google.com>, James
Kanze <kanze@gabi-soft.de> writes
>I would, in fact, recommend that the general structure of main be:
>
>    int
>    main()
>    {
>        try {
>            //  ...
>        } catch ( int returnValue ) {
>            return returnValue ;
>        }
>        return 0 ;
>    }
>
>To terminate from an arbitrary place in the code, you execute "throw
>returnValue".  At least for programs that normally terminate.
Yes, what I once called the 'unexceptional exception' :-)


--
Francis Glassborow      ACCU
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://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:
....
> I think we are talking about different things.  While there are many
> contexts where the exit status will not be used, there are almost no
> programs for which one can say that the exit status will never be used.

You can truthfully say it for most of the programs I've ever written. At
  the moment, the four most complicated and important programs that I'm
responsible for are contract deliverables that are used in scripts that
report and act upon the exit status. But I've written hundreds of
smaller non-deliverable programs while working on this same project, and
I don't think that there's more than a couple of them that ever were or
ever would be used in a context where the exit status would be used.

And I think the two programs I wrote where the exit status was used,
were written solely to prove my point when I got into an argument with
someone about how exit statuses are actually handled in our environment.
   One of the two was:

 #include <stdlib.h>
 int main(int argc, char *argv[])
 { return atoi(argv[1]); }

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:
> SPAMstephen.howeGUARD@tnsofres.com ("Stephen Howe") wrote in message
> news:<3d98a247$0$1285$ed9e5944@reading.news.pipex.net>...

....
>>For environments that require a value, your could always do
>>exit(value);
>>at the end of main().
>
>
> The semantics aren't the same.  Calling exit doesn't call any of the
> destructors.  ...

Not according to 18.3p8. It does call the destructors of static objects.
He specified calling exit() at the end of main(). Therefore, the only
objects which would have been destroying by a return from main(), but
which won't be destroyed by a call to exit(), are the ones which are
local to the outermost block of main().


> ... (Also, I don't know of an environment where a process
> doesn't return a value.)

I vaguely remember hearing of one that someone identified during a
previous discussion of exit() on comp.std.c, but I can't remember which
one.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.de (James Kanze) wrote
> SPAMstephen.howeGUARD@tnsofres.com ("Stephen Howe") wrote
> > For both ISO C99 and ISO C++99 I would argue that main() should not
> > special-cased in this way and that
>
> > return value;
>
> > should be required or alternatively
>
> > void main(void);
> > void main(int argc, char *argv[]);
>
> > be permitted (where "dropping off the bottom" _is_ okay).
>
> Or both.  Why limit main to require int, or void?

I agree that compilers should be required to accept void main().
Microsoft isn't the only one that does this today (is it?), and
it hasn't hurt anything. (Yes, Microsoft DOES support exiting
with a value.)

But other data types -- I'm not so sure about that.

    class Foo {
    public:
        Foo(char*) { /* ... really long function here... */ }
        operator int() { /* Even longer function here... */ }
    };

    Foo main() {
        return "main";
    }

Should the compiled code be required to construct the Foo object?
Should it be required to destroy the Foo object?
Should it call Foo::operator int() first, to get the return value?
What if Foo didn't have an operator int() -- should there be an
error, or should it just return 0?

Currently, when a function returns a value that the caller doesn't
want, it's almost always up to the caller to dispose of it. But this
wouldn't work for global main() unless the run-time system knew how
to destroy the data type that main returns. I suspect this would be
an infeasible burden on compilers (I'm sure someone will correct me
if this turns out to be pretty easy).

The alternative is for the compiler to make global main a special
case. Currently this is allowed but not required. If we decide that
the Foo object has to be created and then destroyed, this essentially
does require the compiler to recognize this special case, no matter
how rarely it is actually used.

> > For environments that require a value, your could always do
>
> > exit(value);
>
> > at the end of main().
>
> The semantics aren't the same.  Calling exit doesn't call any of the
> destructors.  (Also, I don't know of an environment where a process
> doesn't return a value.)

The semantics are almost the same. "Calling exit doesn't call *ANY* of
the destructors" (emphasis added) is simply wrong. You're right about
auto variables in main:

    3.6.1/4 Calling the function
        void exit(int);
    declared in <cstdlib> (18.3) terminates the program without leaving
    the current block and hence without destroying any objects with
    automatic storage duration (12.4).

However, local objects are (by definition) easily found, and they
can be manually destroyed by enclosing them in a block:

    void main() { // Presuming this was legal
        int retval;

        { // To force destruction before exit
            Foo foo(1, 2, 3);
            Bar bar(foo, 4, 5);
            // ... etc...
            retval = bar.get_retval();
        } // Here, foo and bar are destroyed

        exit(retval);
    }

As for the non-local objects:

    3.6.3/1 Destructors (12.4) for initialized objects of static
    storage duration (declared at block scope or at namespace scope)
    are called as a result of returning from main and as a result
    of calling exit (18.3).

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Stephen Howe wrote:
>
> As there is no rationale for ISO C++98, could I just ask what the rationale
> was for permitting execution to drop off the bottom of main() to be
> equivalent to return 0;  ?

I wasn't involved in the decision, but I think I can reverse-engineer
the rationale: this change standardizes a common existing practice,
which catered to people who didn't like bothering with "return 0" when
they aren't planning to make any use of the exit status anyway. I've
written programs where the exit status mattered, but in my experience
such programs are rare.

> Sorry if this is contentious but I would least like to find out the reasons.
> To me it seem inconsistent with the last sentence of 6.6.3.2

'main()' is a very special function - that's the only answer. Consider,
for instance, the fact that it can have multiple different signatures,
but it can't be overloaded. It can't be explicitly called, nor can it be
declared 'inline' or 'static'. What's one more special rule, on top of
all that?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

SPAMstephen.howeGUARD@tnsofres.com ("Stephen Howe") wrote in message news:<3d936158$0$1290$ed9e5944@reading.news.pipex.net>...
> As there is no rationale for ISO C++98, could I just ask what the rationale
> was for permitting execution to drop off the bottom of main() to be
> equivalent to return 0;  ?

Backwards compatibility with C, especially with the K&R book in which
the hello, world example missed that return.

Regards,
--
Michiel Salters

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 26 Sep 2002 21:11:50 +0000 (UTC),
SPAMstephen.howeGUARD@tnsofres.com ("Stephen Howe") wrote:

>As there is no rationale for ISO C++98, could I just ask what the rationale
>was for permitting execution to drop off the bottom of main() to be
>equivalent to return 0;  ?

Nobody knows, actually. Some guesses are in the thread

http://groups.google.com/groups?threadm=alqp9b%24v19%241%40localhost.localdomain


>Sorry if this is contentious but I would least like to find out the reasons.
>To me it seem inconsistent with the last sentence of 6.6.3.2

You meant 6.6.3/2. In any case, welcome to the wonderful world of
standardese, where the rule is that specifics override "generalities"
(i.e. something that would be "general" if it wasn't that it isn't
true in some particular cases). Please, don't ask me what does that
mean.


Genny.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Russell Kuyper Jr.") writes:

> Stephen Howe wrote:
> >
> > As there is no rationale for ISO C++98, could I just ask what the
> > rationale was for permitting execution to drop off the bottom of
> > main() to be equivalent to return 0; ?
>
> I wasn't involved in the decision, but I think I can
> reverse-engineer the rationale: this change standardizes a common
> existing practice, which catered to people who didn't like bothering
> with "return 0" when they aren't planning to make any use of the
> exit status anyway. I've written programs where the exit status
> mattered, but in my experience such programs are rare.

The rationale usually given is that it was to suppress spurious
warnings from compiler in case when one never exit from main.

Programs for which the exit status does not matter should simply
returns EXIT_SUCCESS.  If they do not, it may prevent their use in
scripts as it is common to write shell scripts which fail when any of
the programs they launch fails and the failure is not explicitly
handled.

--
Jean-Marc

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Russell Kuyper Jr.") wrote in message
news:<3D93963E.505A3873@wizard.net>...
> Stephen Howe wrote:

> > As there is no rationale for ISO C++98, could I just ask what the
> > rationale was for permitting execution to drop off the bottom of
> > main() to be equivalent to return 0; ?

> I wasn't involved in the decision, but I think I can reverse-engineer
> the rationale: this change standardizes a common existing practice,
> which catered to people who didn't like bothering with "return 0" when
> they aren't planning to make any use of the exit status anyway. I've
> written programs where the exit status mattered, but in my experience
> such programs are rare.

You must not work in a Unix world.  Under Unix (and under most other
systems I've used), the exit status always matters.  And of course,
C/C++ has been very influenced by Unix traditions (although I can't
remember using a system where it didn't matter).

All of this supposes that the program exits "normally", of course.
Today, of course, for larger programs, THAT is probably exceptional.
Most of my programs are servers, which run for years at a time, and I
can't see any reason why I should be required to write a return after an
endless loop.  (On the other hand, I can't see any reason why I
shouldn't be allowed to declare main void in such cases.)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Michiel.Salters@cmg.nl (Michiel Salters) wrote in message news:<cefd6cde.0209270222.115337be@posting.google.com>...
> SPAMstephen.howeGUARD@tnsofres.com ("Stephen Howe") wrote in message news:<3d936158$0$1290$ed9e5944@reading.news.pipex.net>...
> > As there is no rationale for ISO C++98, could I just ask what the rationale
> > was for permitting execution to drop off the bottom of main() to be
> > equivalent to return 0;  ?
>
> Backwards compatibility with C, especially with the K&R book in which
> the hello, world example missed that return.

Backwards compatibility with that example and many others in the
K&R book is already broken by removal of implicit int.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jean-Marc Bourguet wrote:
> kuyper@wizard.net ("James Russell Kuyper Jr.") writes:
>
>
>>Stephen Howe wrote:
....
>>I wasn't involved in the decision, but I think I can
>>reverse-engineer the rationale: this change standardizes a common
>>existing practice, which catered to people who didn't like bothering
>>with "return 0" when they aren't planning to make any use of the
>>exit status anyway. I've written programs where the exit status
>>mattered, but in my experience such programs are rare.
>
>
> The rationale usually given is that it was to suppress spurious
> warnings from compiler in case when one never exit from main.

That problem isn't really solved by an implicit 'return 0'. A decent
code analyzer will notice that the implicit return also is never
executed, and continue to issue the same warning. That problem would be
better solved by saying that main() doesn't have to return at all.
Which, as far as I know, is already the case, not only for main(), but
for all functions.

> Programs for which the exit status does not matter should simply
> returns EXIT_SUCCESS.  If they do not, it may prevent their use in
> scripts as it is common to write shell scripts which fail when any of
> the programs they launch fails and the failure is not explicitly
> handled.

Not quite. A return of 0 from main() also is translated into "an
implementation-defined form of the status _successful termination_".
This rule about an implicit 'return 0' has precisely that effect,
allowing programmers to not worry about it. It's inconsistent with the
rules for other functions, and I'm not particularly in favor of it, but
I understand the motivation.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:
[...]
> Most of my programs are servers, which run for years at a time, and I
> can't see any reason why I should be required to write a return after an
> endless loop.  (On the other hand, I can't see any reason why I
> shouldn't be allowed to declare main void in such cases.)

Yep and hopefully, once we'll get THREADS rolled in into {C/}C++
standard{(s)}, we can then safely{&&proudly} write something like:

void initial_thread::main(int argc, char* argv[]) { /* ... */ } ;-)

since *threads-aware* {C/}C++ standard would ALSO proclaim that:

http://www.opengroup.org/onlinepubs/007904975/functions/pthread_exit.html

"....
 The process shall exit with an exit status of 0 after the last thread
 has been terminated. The behavior shall be as if the implementation
 called exit() with a zero argument at thread termination time.
 ...."

regards,
alexander.

--
int main(int argc, char* argv[]) { /* ... */ pthread_exit(0); }

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kanze":
> Most of my programs are servers, which run for years at a time, and I
> can't see any reason why I should be required to write a return after an
> endless loop.

> (On the other hand, I can't see any reason why I
> shouldn't be allowed to declare main void in such cases.)

Because that would take away the reason for 50% of the posts in
comp.lang.c++ and I would not have any clever thing to post anymore. :-)
You have already taken away the "no <iostream.h>" from me, now you say I
have to loose the "int main()", too?  That is 75% of my expertise. :-)  If
you and Mr. Stroustrup succeed I have to learn C++ and even C to show up as
an expert. ;-)

WW


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

> All of this supposes that the program exits "normally", of course.
> Today, of course, for larger programs, THAT is probably exceptional.
> Most of my programs are servers, which run for years at a time, and I
> can't see any reason why I should be required to write a return after an
> endless loop.  (On the other hand, I can't see any reason why I
> shouldn't be allowed to declare main void in such cases.)

I find the ability to drop off the bottom of int main for both C and C++
objectionable on the grounds that main() returns an int type.
It is not considered good practice for other non-void returning functions so
why should int main() be exempt?

For both ISO C99 and ISO C++99 I would argue that main() should not
special-cased in this way and that

return value;

should be required or alternatively

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

be permitted (where "dropping off the bottom" _is_ okay). For environments
that require a value, your could always do

exit(value);

at the end of main().

Stephen Howe


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

>> Backwards compatibility with C, especially with the K&R book in which
>> the hello, world example missed that return.

Al> Backwards compatibility with that example and many others in the
Al> K&R book is already broken by removal of implicit int.

That is true.  However, the C committee, not the C++ committee, made
the initial decision to remove implicit int, and that happened after
the C++ committee's decision to make "return 0" the default from main.

In other words, the C++ committee made a change in order to bring the
C++ standard closer to existing C and C++ usage, and then the C
committee invalidated that usage.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:
> kuyper@wizard.net ("James Russell Kuyper Jr.") wrote in message
> news:<3D93963E.505A3873@wizard.net>...
....
>>I wasn't involved in the decision, but I think I can reverse-engineer
>>the rationale: this change standardizes a common existing practice,
>>which catered to people who didn't like bothering with "return 0" when
>>they aren't planning to make any use of the exit status anyway. I've
>>written programs where the exit status mattered, but in my experience
>>such programs are rare.
>
>
> You must not work in a Unix world.  Under Unix (and under most other
> systems I've used), the exit status always matters.  And of course,

I work exclusively in Unix environment, and the exit status almost never
matters. Oh, it matters in certain contexts, such as inside a make
file's build script for a given target. But it doesn't matter at the
command line or inside a script, unless you explicitly use constructs
that make it matter.

I do, as a matter of fact, compulsively make sure that every program I
write returns a fairly meaningful exit status, but I almost never put
that fact to use.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andrew Koenig wrote:
>>> Backwards compatibility with C, especially with the K&R book in which
>>> the hello, world example missed that return.
>
>Al> Backwards compatibility with that example and many others in the
>Al> K&R book is already broken by removal of implicit int.
>
>That is true.  However, the C committee, not the C++ committee, made
>the initial decision to remove implicit int, and that happened after
>the C++ committee's decision to make "return 0" the default from main.

I don't get this.  Implicit int was not removed until C99, which
postdates C++98.  The C89 standard referenced by C++98 still has
implicit int, doesn't it?

nobody

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net ("James Russell Kuyper Jr.") wrote in message
news:<3D98E04C.8010202@wizard.net>...
> James Kanze wrote:
> > kuyper@wizard.net ("James Russell Kuyper Jr.") wrote in message
> > news:<3D93963E.505A3873@wizard.net>...
>  ....
> >>I wasn't involved in the decision, but I think I can
> >>reverse-engineer the rationale: this change standardizes a common
> >>existing practice, which catered to people who didn't like bothering
> >>with "return 0" when they aren't planning to make any use of the
> >>exit status anyway. I've written programs where the exit status
> >>mattered, but in my experience such programs are rare.

> > You must not work in a Unix world.  Under Unix (and under most other
> > systems I've used), the exit status always matters.  And of course,

> I work exclusively in Unix environment, and the exit status almost
> never matters. Oh, it matters in certain contexts, such as inside a
> make file's build script for a given target. But it doesn't matter at
> the command line or inside a script, unless you explicitly use
> constructs that make it matter.

I think we are talking about different things.  While there are many
contexts where the exit status will not be used, there are almost no
programs for which one can say that the exit status will never be used.
In other words, there are almost no programs for which you can say that
the return value of main doesn't matter.

> I do, as a matter of fact, compulsively make sure that every program I
> write returns a fairly meaningful exit status, but I almost never put
> that fact to use.

The point is rather, that that fact can, and sometimes will, be put to
use for almost all programs.  So you can't just return anything, even if
most of the time, you don't use what you are returning.

I realize now that what I said was very poorly worded.  But I can't
figure out how to really word it: something along the lines of "it is
always true (for every program) that the exit status can matter."

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

SPAMstephen.howeGUARD@tnsofres.com ("Stephen Howe") wrote in message
news:<3d98a247$0$1285$ed9e5944@reading.news.pipex.net>...
> > All of this supposes that the program exits "normally", of course.
> > Today, of course, for larger programs, THAT is probably exceptional.
> > Most of my programs are servers, which run for years at a time, and
> > I can't see any reason why I should be required to write a return
> > after an endless loop.  (On the other hand, I can't see any reason
> > why I shouldn't be allowed to declare main void in such cases.)

> I find the ability to drop off the bottom of int main for both C and
> C++ objectionable on the grounds that main() returns an int type.  It
> is not considered good practice for other non-void returning functions
> so why should int main() be exempt?

I agree.

> For both ISO C99 and ISO C++99 I would argue that main() should not
> special-cased in this way and that

> return value;

> should be required or alternatively

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

> be permitted (where "dropping off the bottom" _is_ okay).

Or both.  Why limit main to require int, or void?

> For environments that require a value, your could always do

> exit(value);

> at the end of main().

The semantics aren't the same.  Calling exit doesn't call any of the
destructors.  (Also, I don't know of an environment where a process
doesn't return a value.)

I would, in fact, recommend that the general structure of main be:

    int
    main()
    {
        try {
            //  ...
        } catch ( int returnValue ) {
            return returnValue ;
        }
        return 0 ;
    }

To terminate from an arbitrary place in the code, you execute "throw
returnValue".  At least for programs that normally terminate.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Andrew Koenig":
> That is true.  However, the C committee, not the C++ committee, made
> the initial decision to remove implicit int, and that happened after
> the C++ committee's decision to make "return 0" the default from main.
>
> In other words, the C++ committee made a change in order to bring the
> C++ standard closer to existing C and C++ usage, and then the C
> committee invalidated that usage.

It seems to me that slips in communication like this should be avoided
first before we think to do fundamental changes to both languages to make C
a subset...

WW


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"nobody" <nobody@localhost.ucar.edu> wrote in message news:20021001031247.57490B8010@mscan1.ucar.edu...

> I don't get this.  Implicit int was not removed until C99, which
> postdates C++98.  The C89 standard referenced by C++98 still has
> implicit int, doesn't it?
>
C++ doesn't have implicit int.



---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

>>> Backwards compatibility with that example and many others in the
>>> K&R book is already broken by removal of implicit int.

>> That is true.  However, the C committee, not the C++ committee, made
>> the initial decision to remove implicit int, and that happened after
>> the C++ committee's decision to make "return 0" the default from main.

> I don't get this.  Implicit int was not removed until C99, which
> postdates C++98.  The C89 standard referenced by C++98 still has
> implicit int, doesn't it?

Yes.  However, the C committee's decision to remove implicit int
was known while the C++98 standard was still in progress.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

As there is no rationale for ISO C++98, could I just ask what the rationale
was for permitting execution to drop off the bottom of main() to be
equivalent to return 0;  ?

Sorry if this is contentious but I would least like to find out the reasons.
To me it seem inconsistent with the last sentence of 6.6.3.2

Thanks

Stephen Howe



---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]