🚀 go-pugleaf

In article <UPMAIL04.199602192354270852@msn.com> "Eugene Lazutkin"
<INT@msn.com> writes:

|> I don't care about the actual implementation.  Virtually there is a main().
|> I know that all my static constructors will be executed BEFORE main(), 
|> WinMain() or any other head procedure.  It is important.  It doesn't make 
|> any difference for me whether or not main() is the first called subroutine.
|> In fact, in most cases it is not true.  Almost all platforms call some
|> stub before your main().

You know something that is *NOT* guaranteed by the draft standard.
There is no guarantee that static constructors are executed before main,
although in fact, this is the case for all implementations I am familiar
with, at least as long as the static variables are not in DLL's.  (And:
I've got more than a little code which depends on this.  Despite it not
being guaranteed.)
-- 
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
---
[ To submit articles: Try just posting with your newsreader.  If that fails,
                      use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]

Eugene Lazutkin (INT@msn.com) wrote:
| On 	Tuesday, February 13, 1996 9:51 AM, 	JdeBP@jba.co.uk 
| 	(Jonathan de Boyne Pollard) wrote:
| > Again, this is not in fact true, and part of the problem that the original
| > poster was pointing out.  The startup code in most Windows compilers calls
| > WinMain directly.  There is no `main' function anywhere in the program at
| > all.
|
| I don't care about the actual implementation.  Virtually there is a main().

Wrong.  There is *no* `main', and this is the problem.

| Almost all platforms call some stub before your main().

Again, this is not true.  `main' doesn't even have to be a function at all.
All that is demanded is that the start of the program, *as it appears to the
programmer in the C++ language source*, is a function called `main'.  The 
implementation is perfectly free to recognise a definition of the `main'
function, and to do whatever is necessary to ensure that the program
"starts" with that function.

For instance, instead of emitting a symbol definition and a function
prologue into the object file, the a C++ implementation is free to emit the
C++ runtime initialisation code in place of a function prologue, and have 
it fall through directly into the body of `main'.  As long as `return', the 
arguments to `main', and exception processing appear just as they should 
for a real function, the implementation is free to do as it wishes.

| > | BTW, the same can be applied to the Unix (MacOS) platform.  X-based
| > | (Motif-based, Fresco-based,...) program are not portable either unless
| > | you have the specific GUI implementation for your target platforms.
| > 
| > Not so.  If we are expanding the discussion to other platforms, you will
| > find that many other platforms do not demand that programs be ill-formed 
| > (as a program lacking any definition of `main' surely is).
|
| You can call a main() from the WinMain().

But you cannot compile

int main ( int, char ** ) { return 0 ; }

.  Again, you are not quite getting it.  If the implementation *requires* 
you to define a `WinMain', and makes `main' optional then this is the 
reverse of the language definition, where `main' is required and `LibMain' 
(and indeed any other function) is optional.

| > I don't remember about X offhand, but OS/2 Presentation Manager does not
| > require non-standard startup procedures.  The PM API is, as far as the
| > applications programmer is concerned, just another function library in a
| > DLL, and OS/2 PM programs start with `int main(int, char **)' just the same
| > as text-mode programs do.
|
| I still think that PM API makes programs unportable.

Try reading the next pert of my original message :

| > And *this* is the issue at hand, not whether the APIs are portable.  Most
| > APIs appear as "just another function library" to the applications
| > programmer, and portability or otherwise of libraries is not an issue with
| > the C++ language itself.  The issue with the C++ language is that `main' is
| > the defined start procedure of *any* C++ program (sauf constructors of
| > objects at global namespace scope with static storage duration), and
| > Windows programs are *forced* to *not* use `main'.
|
| IMHO, C++ language doesn't care about the name of functions.  

Well in this case YHO is wrong.  The C++ standard is specific about one
particular function, denoted `main'.

| > Of course, as I've said before, the simple solution is to fix
| > [basic.start.main] to allow
| > 
| > 	int main ( HINSTANCE, HINSTANCE, char *, int ) { /*...*/ }
| > 
| > as a legal definition of `main' (my proposal is for the implementation to
| > define a set of legal function types for the definition of `main', which at
| > minimum must contain `int main()' and `int main(int, char**)').  Then 
| > compiler vendors targetting DOS+Windows who wish to claim conformance can do
| > so by allowing their compilers to recognise the above function definition.
|
| I'm not a pro in a standardization, but I think that this solution
| looks like a patch for MS Windows(TM).  What if totally graphical
| environment doesn't support any parameters or these parameters aren't a
| text?  This is a Unix heritage (and useful one :-) ).  What does
| HINSTANCE mean for ABCDOS?  What if all this four parameters don't make
| any sense at all for particular OS?  E.g., Win32 doesn't use the second
| HINSTANCE.  I don't speak about future OSes.

You didn't read the whole paragraph.  Read it again.  My proposal is that
implementations can define a set of legal function types that they will
accept in a program for the definition of `main', with the one restriction
that `int main()' and `int main(int, char **)' be members of that set.

This allows Windows implementations to state that (in addition to the
compulsory two definitions) they will accept a definition of `main' as 
given above, and other implementations with similar requirements to allow
whatever function definition of `main' makes their environment happy also.

This is known as meeting the problem halfway.  Currently, the C++ (draft)
standard is both self-contraditory and restricted to UNIX-lookalike startup
semantics.  Currently, Windows C++ implementations would not conform to the
standard (were the drafts as they stand made into a standard).  If Windows 
C++ implementations switch to using `main', and if the C++ standard is 
modified (and corrected) as I've suggested, then Windows (and other) C++ 
implementations will be able to conform in this area.
---
[ To submit articles: Try just posting with your newsreader.  If that fails,
                      use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]