🚀 go-pugleaf

In article <AE5J83na99@qsar.chem.msu.su> "Eugene Radchenko"
<eugene@qsar.chem.msu.su> writes:

|> I have just realized that something is grossly overlooked in C++ standard.
|> It requires every program to have the main() function (which implementation
|> is not allowed to supply) with parameters (void) or (int argc, int*argv[]).
|> However, Windows programs have another convention: prrogram must contain
|> the function
|>   int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline, int cmdShow)
|> Some of this is of course quirks or even outright ignored in Win32
|> (prevInst), but the full non-parsed command line could be useful sometimes,
|> and not all implementations provide the function retrieving it. And anyway
|> this is definitely not a main() from the specs. Maybe the requirements on
|> the main() should be relaxed somehow?

Implementations are not prevented from having extensions, nor from
requiring non-standard means of getting at those extensions.  A
program without a main (at least in a hosted environment) is
undefined; if the implementation wishes to give it a specific
definition, it is free to do so.

What the standard guarantees is what is portable.  If an
implementation wishes to support the above, it can, but it *must*
support the two variants of main described in the standard; if you
want your code to be even slightly portable, then you must provide one
of these variants.  Of course, portability can be compromised by other
things as well.  For example, if you are running under Windows, it is
probable that you also use a number of special library functions that
won't be available on other machines, either.  So it may not
particularly worry you that the absense of a main means that your
program is using a platform specific extension.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

"Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:

>I have just realized that something is grossly overlooked in C++ standard.

I think the problem is due to Microsoft overlooking the C and C++
standards, not vice versa.

>It requires every program to have the main() function (which implementation
>is not allowed to supply) with parameters (void) or (int argc, int*argv[]).

The implementation is allowed to make the program work even if main() is
not defined, so long as it issues a diagnostic.

>However, Windows programs have another convention: prrogram must contain
>the function
>  int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline, int cmdShow)

A compiler is allowed to accept the program

	int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline,
		int cmdShow)
	{
		return 0;
	}

so long as it issues at least one diagnostic, e.g.
"warning: standard C++ requires a definition of main()".

But if a compiler does not accept

	int main() { return 0; }

as a complete program, then that compiler is not a conforming C or C++
implementation.

>Some of this is of course quirks or even outright ignored in Win32
>(prevInst), but the full non-parsed command line could be useful sometimes,
>and not all implementations provide the function retrieving it.

In many operating systems, the command-line parsing is done by the
shell, not the OS.  Such operating systems cannot provide the non-parsed
command line.

>And anyway this is definitely not a main() from the specs.
>Maybe the requirements on the main() should be relaxed somehow?

Are you suggesting relaxing the requirements on implementations,
or the requirements on programs?

I presume you are referring to 3.6.1[basic.start.main]/1:

|	A program shall contain a global function called main, which is the
|	designated start of the program.

You are correct to infer that this means that all Windows programs
which do not define main() are ill-formed.

However, that means only that a compiler is required to issue
a diagnostic; it does not mean that the compiler must reject the
program.

Obviously a program that does not define main() is not going to be
portable, so I don't think that requirement on programs should be
relaxed.

Windows compilers which wish to conform to the C and C++ standards
should include code similar to

	HINSTANCE __curInst;
	HINSTANCE __prevInst;
	LPSTR __cmdline;
	int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline,
		int cmdShow)
	{
		int argc;
		char **argv;

		__curInst = curInst;
		__prevInst = prevInst;
		__cmdLind = cmdLine;
		__parse_command_line(cmdline, &argc, &argv);
		return main(argc, argv);
	}

in their libraries, so that they can accept programs which define main()
but not WinMain().

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Eugene Radchenko (eugene@qsar.chem.msu.su) wrote:
| Maybe the requirements on the main() should be relaxed somehow?

A while back I submitted several proposals to clean up [basic.start.main],
and one of the points that I addressed was implementations that gave `main' 
a different function signature.

Under my proposal, the set of function signatures that `main' could have
would be implementation defined (with the restriction that `int main()' and
`int main(int, char **)' be part of that set).  This would allow
implementations to define

    int main(HINSTANCE, HINSTANCE, LPSTR, int)

as an acceptable signature for `main', should they so wish.

( The current wording of [basic.start.main] is both self-contradictory 
  and ambiguous in this respect.  See the proposal for full details.  )

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

In article <9602010236.26117@mulga.cs.mu.oz.au>,
Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>You are correct to infer that this means that all Windows programs
>which do not define main() are ill-formed.

Perhaps Windows programs are expected to #include some standard header that
defines main(), and to link with a runtime library that defines it.  This
conformance requirement is on the program after inclusion of headers and
linking, so these programs would indeed be well-formed.
-- 
Barry Margolin
BBN PlaNET Corporation, Cambridge, MA
barmar@bbnplanet.com
Phone (617) 873-3126 - Fax (617) 873-6351

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

In article <9602010236.26117@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU
(Fergus Henderson) writes:

|> "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:

|> >I have just realized that something is grossly overlooked in C++ standard.

|> I think the problem is due to Microsoft overlooking the C and C++
|> standards, not vice versa.

|> >It requires every program to have the main() function (which implementation
|> >is not allowed to supply) with parameters (void) or (int argc, int*argv[]).

|> The implementation is allowed to make the program work even if main() is
|> not defined, so long as it issues a diagnostic.

By a curious coincidence, this point has just been discussed in
comp.std.c.  The concensus of the experts there was that the absense
of main (or a non-conformant main) is simply undefined behavior: no
diagnostic required.

|> >However, Windows programs have another convention: prrogram must contain
|> >the function
|> >  int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline, int cmdShow)

I believe that the simple answer is that Windows programs operate in a
unhosted environment.  In an unhosted evironment, the language is
defined, but which libraries are present, how the program is started,
etc., etc., are implementation defined.

By definition, a program written for an unhosted environment is not
portable outside that environment.  And in fact, a program written for
Windows will probably not work on my Unix box:-).

Another interesting point that was made in the discussion on
comp.std.c was that g++ normally operates in an unhosted environment,
at least according FSF.  It just so happens that the implementation
defined rules are *very* close to what the standard requires of a
hosted environment.  (The machine I'm typing this on runs Sun OS 4.1.
I have two compilers available, g++ and Sun CC.  On this machine, at
least, the unhosted g++ is closer to the standard than the supposedly
hosted environment of Sun CC:-).  As I understand it, the reason g++
is unhosted is that they don't provide the libraries themselves, and
thus cannot make any guarantees about them.)

|> A compiler is allowed to accept the program

|> 	int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline,
|> 		int cmdShow)
|> 	{
|> 		return 0;
|> 	}

|> so long as it issues at least one diagnostic, e.g.
|> "warning: standard C++ requires a definition of main()".

In conformant mode, I would expect to see something along the lines of
`_main undefined' when linking, although I am far from sure that the
standard requires it.

I feel fairly sure that Microsoft does provide a conformant mode, and
that when compiling in this mode, you will get such an error message.
Of course, when compiling in this mode, you probably cannot use
Windows.  But the standard does not require the capability to use
Windows, so this is not a problem.

|> But if a compiler does not accept

|> 	int main() { return 0; }

|> as a complete program, then that compiler is not a conforming C or C++
|> implementation.

Most compilers have non-conformant modes, with extensions.  I'm not
familiar with the newer Microsoft products (my MS C compiler is
version 1.2), but I rather suspect that if you don't request Windows
support (which is not really needed in the above program), the
compiler and linker will accept it.

Windows support is an extension, and the compiler is entitled to make
any requirements it wishes on programs using the extension.  A program
using the extension is not a C program, or in this case, since the
extension really involves the environment, and not the language
itself, it is not a C program for a hosted environment.

Whether requiring a different start-up procedure than calling main is
a good idea for this extension can be discussed under quality of
implementation; it is not a standards question, however.

|> >Some of this is of course quirks or even outright ignored in Win32
|> >(prevInst), but the full non-parsed command line could be useful sometimes,
|> >and not all implementations provide the function retrieving it.

|> In many operating systems, the command-line parsing is done by the
|> shell, not the OS.  Such operating systems cannot provide the non-parsed
|> command line.

|> >And anyway this is definitely not a main() from the specs.
|> >Maybe the requirements on the main() should be relaxed somehow?

|> Are you suggesting relaxing the requirements on implementations,
|> or the requirements on programs?

|> I presume you are referring to 3.6.1[basic.start.main]/1:

|> |	A program shall contain a global function called main, which is the
|> |	designated start of the program.

|> You are correct to infer that this means that all Windows programs
|> which do not define main() are ill-formed.

No, he's not.  They are simply programs for non-hosted environments.

I personally think that the Microsoft environment stinks, but I still
get the feeling that there is a double standard at work here.  If
someone complains that g++ doesn't issue a diagnostic when I define a
nested function, dozens of people (including you, Fergus?) will
quickly point out that all I have to do is add the flags -ansi
-pedantic, and it will; without these flags, the compiler is operating
in a non-conformant mode, and this fact is in the compiler
documentation.  Unless things have changed in the last 4 years, you
need to give a special flag to the compiler to get Windows support.
The default mode was the conformant mode.  And the non-conformity is
actually simply an unhosted environment (where it is conformant).

|> However, that means only that a compiler is required to issue
|> a diagnostic; it does not mean that the compiler must reject the
|> program.

|> Obviously a program that does not define main() is not going to be
|> portable, so I don't think that requirement on programs should be
|> relaxed.

|> Windows compilers which wish to conform to the C and C++ standards
|> should include code similar to

|> 	HINSTANCE __curInst;
|> 	HINSTANCE __prevInst;
|> 	LPSTR __cmdline;
|> 	int WinMain(HINSTANCE curInst, HINSTANCE prevInst, LPSTR cmdline,
|> 		int cmdShow)
|> 	{
|> 		int argc;
|> 		char **argv;

|> 		__curInst = curInst;
|> 		__prevInst = prevInst;
|> 		__cmdLind = cmdLine;
|> 		__parse_command_line(cmdline, &argc, &argv);
|> 		return main(argc, argv);
|> 	}

|> in their libraries, so that they can accept programs which define main()
|> but not WinMain().

And what will they do with all of the other Windows requests in the
code?  If you are writing Windows code, your program is, by
definition, unportable, and I wouldn't worry about not having a main.
If you are writing code which just happens to run in a shell under
Windows, but is not a Windows program itself, then don't request
Windows support of the compiler, but use the compatible (hosted) mode.
(If the Microsoft compiler doesn't have such a mode, which I seriously
doubt, other Windows compilers do.  Or at least, my old Zortech
compiler did.)

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

>> It requires every program to have the main() function (which 
>> implementation is not allowed to supply) with parameters (void) or (int 
>> argc, int*argv[]). However, Windows programs have another convention: 
>> prrogram must contain the function  int WinMain

I remember reading that you can write a Windows program with a main() 
function and the usual command line arguments, and then the Microsoft 
compiler will then generate WinMain somehow....but that the "operating 
system" does link to WinMain.

                 David
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

Could window's main be simply like this:

int main(int argc, char *argv[]) {
     // do some stuff
     return WinMain(// stuff here);
}



[Moderator's note: There have been a number of similar articles about
the role of main() in a Windows program; this thread is beginning to get 
a bit repetitive.  Please make sure, if you post something in this thread,
that it says something new about whether Windows implementations are
standard conforming and/or whether the standard needs to be modified to
accommodate Windows. mha]

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>|> "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
>
>|> The implementation is allowed to make the program work even if main() is
>|> not defined, so long as it issues a diagnostic.
>
>By a curious coincidence, this point has just been discussed in
>comp.std.c.  The concensus of the experts there was that the absense
>of main (or a non-conformant main) is simply undefined behavior: no
>diagnostic required.

If the comp.std.c experts are right, then I think that is a difference
between C++ and C, because the September 95 draft C++ standard makes it
pretty clear that a diagnostic is required.

| 3.6.1[basic.start.main]/1:
|	A program shall contain a global function called main, which is the
|	designated start of the program.

Here "shall" expresses a semantic requirement, and as 1.7 makes clear,
a diagnostic is required:

|   1.7  Processor compliance                           [intro.compliance]
| 
| 1 Every conforming C++ processor  shall,  within  its  resource  limits,
|   accept and correctly execute well-formed C++ programs, and shall issue
|   at least one diagnostic message when  presented  with  any  ill-formed
|   program  that contains a violation of any diagnosable semantic rule or
|   of any syntax rule, except as noted herein.
[...]
| 3 The set of "diagnosable semantic rules" consists of all semantic rules
|   in  this  International  Standard except for those rules containing an
|   explicit notation that "no diagnostic is required."

James Kanze continues:

>I believe that the simple answer is that Windows programs operate in a
>unhosted environment.

That's a possible answer with regard to C conformance, but C++ is different:
C++ programs must contain main() even in an unhosted environment, according
to the September 95 draft C++ standard.  (The reason for this is because
the definition of the order of execution of constructors for global variables
is defined with reference to when main() gets invoked.)

I'm not sure whether Windows C/C++ compilers claim conformance to the
relevant C/C++ standards.  One would need to consult the documentation
for the compiler in question to see whether they claimed conformance,
and if so, whether they claimed conformance as a hosted or unhosted
environment.  Even if they do claim conformance, they will usually have
some conforming and some non-conforming modes of operation; you need to
be sure that the compiler is being invoked in the correct mode.

>Another interesting point that was made in the discussion on
>comp.std.c was that g++ normally operates in an unhosted environment,
>at least according FSF.

That depends on what you mean by "normally".  If you have installed g++
together with the GNU C and C++ libraries, then I believe that the FSF
would claim conformance (modulo the odd bug here and there) as a hosted
environment, not just as an unhosted environment.  This is normally the
case on Linux, for example, although I agree that it is probably not
normally the case on most other systems.

>|> You are correct to infer that this means that all Windows programs
>|> which do not define main() are ill-formed.
>
>No, he's not.  They are simply programs for non-hosted environments.

No, I beg to differ -- as explained above, C++ requires main() even
for non-hosted environemnts.

>Whether requiring a different start-up procedure than calling main is
>a good idea for this extension can be discussed under quality of
>implementation; it is not a standards question, however.

Actually, I think it is, albeit not a direct one. Remember that the
purpose of the C++ standard is amoung other things to promote
portability of C++ programs.  Extensions should be done in a way that
makes it easy for customers to make selective use of them with
conditional compilation, so that they can easily write portable
programs that are nevertheless customized to take advantage of the
features of particular platforms.  Requiring a different start-up
procedure makes doing this more difficult than it need be.

>I personally think that the Microsoft environment stinks, but I still
>get the feeling that there is a double standard at work here. If
>someone complains that g++ doesn't issue a diagnostic when I define a
>nested function, dozens of people (including you, Fergus?) will
>quickly point out that all I have to do is add the flags -ansi
>-pedantic, and it will; without these flags, the compiler is operating
>in a non-conformant mode, and this fact is in the compiler
>documentation.  Unless things have changed in the last 4 years, you
>need to give a special flag to the compiler to get Windows support.
>The default mode was the conformant mode.

I don't think I am applying a double standard.

I did not claim that any or all Windows compilers were not conforming.
I simply pointed out what they were required to do in order to conform.

I did say that

| I think the problem is due to Microsoft overlooking the C and C++
| standards, not vice versa.

but the problem I was referring to was not that Microsoft's compilers
don't conform to the standard (most likely they do) but rather that
Microsoft encourages people to write non-portable, non-standard-conforming
code which is then subject to the usual problems of vendor lock-in.

Now GNU's compilers also have their own extensions, and the problem of
vendor lock-in can also arise for programs that use GNU extensions, but
I do think GNU aims to minimize the difficulty of writing portable
programs that selectively take advantage of those additional features.
For example, the syntax of GNU's __attribute__ feature is designed to
make it easy to use a conditionally defined macro to enable/disable the
use of that feature.

>|> Windows compilers which wish to conform to the C and C++ standards
>|> should include code [...for WinMain()...]
>|> in their libraries, so that they can accept programs which define main()
>|> but not WinMain().
>
>And what will they do with all of the other Windows requests in the
>code?

They can do whatever they like.  I was reiterating the need
for Windows compilers to accept strictly conforming programs, and
showing how that could easily be implemented, in a way which made the
selective use of Windows features possible without the programmer
having to define WinMain(), even if the OS required a program to define
WinMain() rather than main().

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

James Kanze US/ESC 60/3/141 #40763 wrote:
> I believe that the simple answer is that Windows programs operate in a
> unhosted environment.  

	This is a clear condemnation of the Standard,
Windows is obviously a hosting operating system.

> |> But if a compiler does not accept
> 
> |>      int main() { return 0; }
> 
> |> as a complete program, then that compiler is not a conforming C or C++
> |> implementation.


This is the crux of the problem. More important, when I
try to use "cout" the program won't link. This is 
important to me -- I've scrapped Win3.11 in favour
of NT mainly because of this deficiency (in Win3.1 wrt
the Standard).

In my opinion, program startup and environment
shouldn't be part of the language standard at all.

Instead, requirements should be created for creating
a BINDING to a particular environment, and then
bindings created.

For example, a POSIX binding would be popular;
but MS would still be free to create a Windows
binding.

In effect, there are _industry_ standards which
supercedes the ISO one, which is clearly
inadequate for modern needs. Unfortunately,
none of the "standards" are portable, _including_
the ISO one.

The distinction between "hosted" and "unhosted"
systems is better than nothing -- but it was more
useful 20 years ago than it is now, when it is
simply far too weak. (I.e two levels is just
not a good enough design any more)


-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 web: http://www.maxtal.com.au/~skaller/
AUSTRALIA                      email: skaller@maxtal.com.au
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

Claude Quezel <Claude.Quezel@gci.ulaval.ca> wrote:

>Could window's main be simply like this:

>int main(int argc, char *argv[]) {
>     // do some stuff
>     return WinMain(// stuff here);
>}

No.  This doesn't seem to accomplish anything.  First of all, it still
requires that the user's code have WinMain defined, which is exactly
what was being avoided to start with.  In addition, at least without
changes in the startup code, you can define main anyway you want to, and
it'll make no difference at all because it'll never get called.  If you
wanted to allow code that used main to compile, you could add something
like the following to the standard library:

extern int __argc;
extern char *__argv[];

int WinMain(/* arguments WinMain receives */) {
	return main(__argc, __argv);
}

However, this really won't buy you much WRT most Windows programs: the
basic structure of a normal Windows program, the header it includes, the
functions it needs to use, etc., prevent the normal Windows environment
from being a legal hosted implementation.  (E.g. stdin/stdout/stderr are
missing...)  OTOH, if we simply view a Windows program as running in a
freestanding environment, I don't see any obvious violations of the
standard, even though it's highly doubtful that this is what the
committee had in mind when they included freestanding implementions in
the standard.

IMO, a reasonable solution to the situation would be a bit of
modification in both Windows and the standard.  IMO, a slightly more
restrictive version of Jonathon De Boyne Pollard's proposal might work
best: require that any form of main the takes arguments have argc and
argv as the first two (with whatever names the programmer desires of
course) with other, implementation defined arguments allowed aftewards.
In this case, a suitable version for a Win32 program might be:

int main(int argc, char **argv, HINSTANCE hInst, int nCmdShow)

By requiring that argc/argv always be passed as the first to parameters,
conforming programs that expect those as the first two parameters are
supported in the extended environments, whether Windows or otherwise.
In this case, the entry point for a Win32 program might be:

#include <windows.h>
extern int __argc;
extern char *__argv[];

WinMain(HINSTANCE Inst, HINSTANCE PrevInst, char *CmdLine, int nCmdShow)
{
// under Win32, hPrevInst is included only for compatibility: it will
// alway be NULL, so we'll ignore it.  Likewise, since we're passing
// argc/argv, there's little reason to worry about the unprocessed
// command line.

	return main(__argc, __argv, Inst, nCmdShow);
}

This would, of course, require that main be called in such a way that if
some arguments were ignored that it wouldn't cause a catastrophe.  Given
the current requirement that main be able to ignore argc and argv, this
shouldn't require anything new.


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) wrote:

>I did not claim that any or all Windows compilers were not conforming.
>I simply pointed out what they were required to do in order to conform.

>I did say that

>| I think the problem is due to Microsoft overlooking the C and C++
>| standards, not vice versa.

>but the problem I was referring to was not that Microsoft's compilers
>don't conform to the standard (most likely they do) but rather that
>Microsoft encourages people to write non-portable, non-standard-conforming
>code which is then subject to the usual problems of vendor lock-in.

YES, YES, YES.  This is IT.

*IF* Microsoft decides that it's profitable, they may in the future
allow a standard-conforming C++ program to be compiled and executed.
My guess is that they won't bother.  It'll be easy enough to feign
"true compatability" while taking as much liberty as GNU does,
blithely compiling and executing programs that the standard says
should fail with diagnostics.

I know full well that my Windows programs follow Microsoft's
standards, and not anyone elses; Microsoft C, not ANSI or ISO; ODBC,
not SQL-92 nor SAG CLI, etc.

My only hope of "portability" is on a smaller component level.  I can
write fully ANSI-compliant functions and objects, but once compiled
and linked into a Windows program the whole becomes Microsoft-defined.

For what it's worth, I think the answer to the subject line is "yes".
All Windows programs are ill-formed according to the C++ standard.

--
Richard Krehbiel, Kastle Systems, Arlington VA USA
rich@kastle.com (work) or richk@mnsinc.com (personal)
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

In article <4evp66$a58@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus
Henderson) writes:

> James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:
> 
> >fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
> >
> >|> "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
> >
> >|> The implementation is allowed to make the program work even if main() is
> >|> not defined, so long as it issues a diagnostic.
> >
> >By a curious coincidence, this point has just been discussed in
> >comp.std.c.  The concensus of the experts there was that the absense
> >of main (or a non-conformant main) is simply undefined behavior: no
> >diagnostic required.
> 
> If the comp.std.c experts are right, then I think that is a difference
> between C++ and C, because the September 95 draft C++ standard makes it
> pretty clear that a diagnostic is required.
> 
> | 3.6.1[basic.start.main]/1:
> |	A program shall contain a global function called main, which is the
> |	designated start of the program.
> 
> Here "shall" expresses a semantic requirement, and as 1.7 makes clear,
> a diagnostic is required:
> 
> |   1.7  Processor compliance                           [intro.compliance]
> | 
> | 1 Every conforming C++ processor  shall,  within  its  resource  limits,
> |   accept and correctly execute well-formed C++ programs, and shall issue
> |   at least one diagnostic message when  presented  with  any  ill-formed
> |   program  that contains a violation of any diagnosable semantic rule or
> |   of any syntax rule, except as noted herein.
> [...]
> | 3 The set of "diagnosable semantic rules" consists of all semantic rules
> |   in  this  International  Standard except for those rules containing an
> |   explicit notation that "no diagnostic is required."

This would seem to be a difference.  In the C standard, there are never
any explicit words that say a program must/shall contain a function
main.  It does say that "the function called at program startup is named
main", but is rather silent about what happens if no such function
exists.  (Such silences are generally interpreted as undefined behavior.)

There are other differences as well: if it exists, the function main may
only have one of two forms.  Unlike in C++, there is no implication that
the implementation may permit other forms.

> James Kanze continues:
> 
> >I believe that the simple answer is that Windows programs operate in a
> >unhosted environment.
> 
> That's a possible answer with regard to C conformance, but C++ is different:
> C++ programs must contain main() even in an unhosted environment, according
> to the September 95 draft C++ standard.  (The reason for this is because
> the definition of the order of execution of constructors for global variables
> is defined with reference to when main() gets invoked.)

Correct.  I just checked the definition of an unhosted environment, and
it is far more restrictive than in C.  In fact, the only difference is
that in an unhosted environment, most of the libraries may be missing.

> I'm not sure whether Windows C/C++ compilers claim conformance to the
> relevant C/C++ standards.  One would need to consult the documentation
> for the compiler in question to see whether they claimed conformance,
> and if so, whether they claimed conformance as a hosted or unhosted
> environment.  Even if they do claim conformance, they will usually have
> some conforming and some non-conforming modes of operation; you need to
> be sure that the compiler is being invoked in the correct mode.

This is true for most compilers, I believe.  (Even for those claiming
compliance, the question arises: with which version of the draft.)

> >Another interesting point that was made in the discussion on
> >comp.std.c was that g++ normally operates in an unhosted environment,
> >at least according FSF.
> 
> That depends on what you mean by "normally".  If you have installed g++
> together with the GNU C and C++ libraries, then I believe that the FSF
> would claim conformance (modulo the odd bug here and there) as a hosted
> environment, not just as an unhosted environment.  This is normally the
> case on Linux, for example, although I agree that it is probably not
> normally the case on most other systems.

Well, normally, for me, means on a Sun:-).  In fact, however, g++ is
more compliant (in a hosted environment) than Sun CC, at least under Sun
OS 4.1.  They may use the local libc, but at least they fixed up
stdlib.h so that free takes a void*.  (It's obvious that Sun wants you
to upgrade to Solaris.  Rather pissed me off, though.  I'd told every
one at the customer site how great the Sun compiler was, and when they
finally bought it, we couldn't even compiler our overloaded operator
delete:-(.)

> >|> You are correct to infer that this means that all Windows programs
> >|> which do not define main() are ill-formed.
> >
> >No, he's not.  They are simply programs for non-hosted environments.
> 
> No, I beg to differ -- as explained above, C++ requires main() even
> for non-hosted environemnts.

Agreed.

Although one might ask what version of the draft (if any) they are
trying to comply with.  My impression is that the intent is to be
unhosted; until only a short time ago, however, the draft standard
didn't even mention the word (and the wording implying the call to main
in the initialization of statics is also very recent).

> >Whether requiring a different start-up procedure than calling main is
> >a good idea for this extension can be discussed under quality of
> >implementation; it is not a standards question, however.
> 
> Actually, I think it is, albeit not a direct one. Remember that the
> purpose of the C++ standard is amoung other things to promote
> portability of C++ programs.  Extensions should be done in a way that
> makes it easy for customers to make selective use of them with
> conditional compilation, so that they can easily write portable
> programs that are nevertheless customized to take advantage of the
> features of particular platforms.  Requiring a different start-up
> procedure makes doing this more difficult than it need be.

The different start-up procedure is only required if you are using
Windows (I think).  To use Windows, they also require you use a lot of
other special functions, that you won't find on any other machine.

> >I personally think that the Microsoft environment stinks, but I still
> >get the feeling that there is a double standard at work here. If
> >someone complains that g++ doesn't issue a diagnostic when I define a
> >nested function, dozens of people (including you, Fergus?) will
> >quickly point out that all I have to do is add the flags -ansi
> >-pedantic, and it will; without these flags, the compiler is operating
> >in a non-conformant mode, and this fact is in the compiler
> >documentation.  Unless things have changed in the last 4 years, you
> >need to give a special flag to the compiler to get Windows support.
> >The default mode was the conformant mode.
> 
> I don't think I am applying a double standard.
> 
> I did not claim that any or all Windows compilers were not conforming.
> I simply pointed out what they were required to do in order to conform.
> 
> I did say that
> 
> | I think the problem is due to Microsoft overlooking the C and C++
> | standards, not vice versa.
> 
> but the problem I was referring to was not that Microsoft's compilers
> don't conform to the standard (most likely they do) but rather that
> Microsoft encourages people to write non-portable, non-standard-conforming
> code which is then subject to the usual problems of vendor lock-in.

This is probably true.  IBM used to do the same thing.  I suspect that
a lot of other vendors would too, if they could get away with it.  (Will
using Java lock you into Sun?  If not, I'm willing to bet that it is
more because Sun's market would refuse to use it if this were the case,
rather than any generosity on the part of Sun.)

> Now GNU's compilers also have their own extensions, and the problem of
> vendor lock-in can also arise for programs that use GNU extensions, but
> I do think GNU aims to minimize the difficulty of writing portable
> programs that selectively take advantage of those additional features.
> For example, the syntax of GNU's __attribute__ feature is designed to
> make it easy to use a conditionally defined macro to enable/disable the
> use of that feature.

Hmmm...  I believe in fact that the GNU coding guidelines actually
encourages you to use GNU extensions in everything but the compiler
itself (since it has to be compiled with the native C compiler).  At any
rate, things like signatures and nested functions are turned on by
default.  You need special switches to be compliant.

> >|> Windows compilers which wish to conform to the C and C++ standards
> >|> should include code [...for WinMain()...]
> >|> in their libraries, so that they can accept programs which define main()
> >|> but not WinMain().
> >
> >And what will they do with all of the other Windows requests in the
> >code?
> 
> They can do whatever they like.  I was reiterating the need
> for Windows compilers to accept strictly conforming programs, and
> showing how that could easily be implemented, in a way which made the
> selective use of Windows features possible without the programmer
> having to define WinMain(), even if the OS required a program to define
> WinMain() rather than main().

Well, this was the case with the last Windows compiler I used (an early
Zortech).  The use of WinMain was for programs which managed Windows
themselves (and thus had a lot of calls to other proprietary routines).
The compiler would happily compile normal programs, and run them from a
shell within a window.  In practice, this is not much different from the
situation with Unix and X.  An X-Windows program may have a function
called main, but it has so many other things that aren't portable to
other systems, it really doesn't matter.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

rich@kastle.com writes:
>*IF* Microsoft decides that it's profitable, they may in the future
>allow a standard-conforming C++ program to be compiled and executed.
>My guess is that they won't bother.  It'll be easy enough to feign
>"true compatability" while taking as much liberty as GNU does,
>blithely compiling and executing programs that the standard says
>should fail with diagnostics.

There is a distinction between failing to compile correct programs and
permitting extensions.  Compilers that do permit extensions (such as GNU)
should provide a mechanism for turning extensions off (with GNU C++ you do
this with -ansi -pedantic).  Compilers aren't perfect; to improve them,
users should file bug reports.  But before filing a "this program should
have been rejected" report, you should make sure you've followed the
directions for turning off extensions.

-- 
-- Joe Buck 	<jbuck@synopsys.com>	(not speaking for Synopsys, Inc)

Work for something because it is good,
not just because it stands a chance to succeed.	   -- Vaclav Havel
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

In article <311417C8.4016@suphys.physics.su.oz.au> John Max Skaller
<maxtal@suphys.physics.su.oz.au> writes:

> James Kanze US/ESC 60/3/141 #40763 wrote:
> > I believe that the simple answer is that Windows programs operate in a
> > unhosted environment.  
> 
> 	This is a clear condemnation of the Standard,
> Windows is obviously a hosting operating system.

Not necessarily in terms of the standard.  The standard defines what a
hosted environment must provide.  If Windows doesn't provide it, then it
is not a hosted environment.

> > |> But if a compiler does not accept
> > 
> > |>      int main() { return 0; }
> > 
> > |> as a complete program, then that compiler is not a conforming C or C++
> > |> implementation.

> This is the crux of the problem. More important, when I
> try to use "cout" the program won't link.

An unhosted environment does not have to provide cout.  I suspect that
most won't.

If there is not a way to get the above program to compile, link and
execute, however, then I will have to take back my defense of Microsoft
in previous postings.  I find this hard to believe, however.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

[This is starting to drift away from the topic of C++ standardization;
I've cross-posted to gnu.misc.discuss and redirected followups. -fjh.]

kanze@gabi.gabi-soft.fr (J. Kanze) writes:

>Hmmm...  I believe in fact that the GNU coding guidelines actually
>encourages you to use GNU extensions in everything but the compiler
>itself (since it has to be compiled with the native C compiler).

No, that's not the case.  The GNU standards document says

| 	Whether to use these extensions in implementing your
| 	program is a difficult question.
...
| 	With some extensions, it might be easy to provide both alternatives.
| 	For example, you can define functions with a "keyword" `INLINE' and
| 	define that as a macro to expand into either `inline' or nothing,
| 	depending on the compiler.
|
| 	In general, perhaps it is best not to use the extensions if you can
| 	straightforwardly do without them, but to use the extensions if they
| 	are a big improvement.

It further suggests that widely-used programs such as emacs or compiler
programs such as gcc should not use any extensions at all.

I think this is a reasonable position.  I don't think anyone on the C++
standards committee believes that all C++ programs should be strictly
conforming.

The GNU standards document also says that GNU programs should be
upwardly compatible with the relevant ANSI and POSIX standards.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

kanze@gabi.gabi-soft.fr (J. Kanze) wrote:

<snip>
>> > |> But if a compiler does not accept
>> > 
>> > |>      int main() { return 0; }
>> > 
>> > |> as a complete program, then that compiler is not a conforming C or C++
>> > |> implementation.
<snip>
>If there is not a way to get the above program to compile, link and
>execute, however, then I will have to take back my defense of Microsoft
>in previous postings.  I find this hard to believe, however.

The program does compile, link, and run, with the command 

   cl test.cpp 

The result was a Win32 version 4 console application.

I've written console apps under Windows 95 for file-format hacking and
so forth, and I've used Win32 console apps (and OS/2 character-mode
apps for that matter) as the basis of porting ray tracers and so
forth. More than once, I've had to page past Unix-bigotted rants about
how such and such wouldn't work on intel-based machines, as I scanned
through the readme's of portable programs. 

The standards for C and C++ are working. There doesn't happen to be a
standard GUI library, which is why you have funky main functions under
some of the GUI's.


--------------
Mike Enright
75032.2070@compuserve.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]