* Tony -> Francis Glassborow:
>
> What possibilities emerge when one throws the main() paradigm away?
>
> Pretend you know nothing of main() and then make it work a new way.

Perhaps this has gone far enough?

You leave us guessing what you could possibly mean.  Is Tony referring
to Bertrand Meyer's "real systems have no top"?  Is Tony referring to
the Unix heritage for 'main'?  Is it the syntax or the action that
bothers Tony?  Does Tony actually mean anything (the focus on 'main' is
seemingly inconsistent with the thread's much more general title)?

So, with nothing concrete to go on, I'll discuss a few shortcomings of
current 'main', and their relevance to OO.  For those wishing to respond
I hasten to add that /I do not propose changing 'main'/, at all.  The
solutions I propose to listed problems would apply to either just new
library functionality, or to some new alternative startup function(s).


1. Unix & C heritage: the argument types.

Problems: the arguments to 'main' are tailored for the Unix programming
environment and C.

For example, (A) at the Microsoft Windows API-level a process is not
served a collection of arguments but a single command line, and (B) that
command line is not a char array but an array of 16-bit UCS2 characters.

In order to solve problem (A) Windows C++ compilers (such as MingW g++
and Visual C++) support an alternative startup function called
'WinMain', and in order to solve problem (B) at least one Windows C++
compiler, namely Visual C++, supports UCS2-based alternatives to 'main'
and 'WinMain', namely 'wmain' and 'wWinMain'  --  so the problem of Unix
heritage is not an academic problem, but causing most Windows C++
programs to be non-conforming from the outset...

Then we have (C) that the arguments for all these startup functions are
plain old C raw arrays, not safe string objects.

And we have (D) that the arguments are restricted to be strings, not
general objects of any type like in Microsoft's PowerShell (a.k.a.
Monad, which I abhor just like *COBOL*, which it's just like ;-), except
for the idea of passing objects around between processes, which is Very
Nice(TM), and enabled by a common binary format for object representations).

Finally there's problem (E), lack of standardized support for accessing
the process' environment variables, if any.

Possible solution: library support for obtaining process arguments and
other process environment info, with standardized emulation of Unix-like
separate arguments for a system with command line (like Windows), and
vice versa, and information about what is actual and what's emulated,
and conditional support for general objects as arguments.

Relevance to OO: 2/5, namely the raw array nature of the arguments,
problem (C), and lack of support for general objects as arguments,
problem (D).


2.  The result type.

Problem: (A) the result is 'int', yet only two logical values can be
portably specified, namely EXIT_SUCCESS (the same effect can be
specified as 0), and EXIT_FAILURE, and (B) to use the latter one must
include a header, and (C) AFAIK, on both Unix and Windows the actual
range of values that can be safely returned is limited to 0...255, so
the 'int' is highly misleading in practice, and furthermore it leads
novices to question perfectly valid code that has no 'return'.

Possible solution: make the startup function result type 'void' and let
the startup function signal failure by means of an exception, resulting
in the same process exit code (if any) as with EXIT_FAILURE; other exit
codes possible via 'std::exit' and 'std::abort'.

Relevance to OO: none that I can see.


3.  Real systems have no top.

Problems: (A) having 'main' singled out as "the" startup function forces
a 'main'-centered design, especially with respect to dynamic
initialization of statics, where only those appearing in 'main's
translation unit are guaranteed to occur before 'main' is entered, and
so dependencies are introduced just in order to guarantee initialization
(the spider anti-pattern), and (B) for testing it's convenient to be
able to specify alternate startup functions without rebuilding all.

Possible solution: perhaps the module proposal fixes (A)?  It should!
Problem (B) isn't IMO really a language problem, because it's trivial to
structure a system as a library where different startup functions can be
invoked by various starter programs.

Relevance to OO: high for (A), AFAICS none for (B).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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.comeaucomputing.com/csc/faq.html                      ]