jam wrote:
> On early days of C++ people used to provide a "main" function per
> project.But Since windows programming started, things became a lot
> more complicated - at least with VC++ - so that aside from the
> compiler options that must be set,the entry point for the program also
> differs;main ,_tmain  ,Winmain ,tWinmain Dllmain ... according to the
> project settings.But worse than that is that in case of using standard
> IO functions - either old C style ones defined in sdtio,conio... or
> new C++ style ones from iostream - in a windows application ,no io
> operation occurs unless you make some preparations(e.g start a new
> thread which uses console) or change the project settings to a console
> project.Maybe because IO libraries are supposed to operate under dos
> insead of windows.I would like to use the "main" function as the entry
> point always -just like the old days.And I wish there existed a
> version of standard IO tools specialized for windows;espesifically I
> want iostream members to open the terminal window automatically.I
> regret neglected easy-to-perform and overhead-free things that could
> keep C++ programming uniform and simple.

>From the perspective of the current C++ standard, this is
quite a simple matter: all portable C++ programs define a
main() function as their entry point, and access to the
standard input, output, error and log streams is available
(for hosted implementations, at least).

The standards committee can do little about non-standard
variants on C++ which don't follow the standard's rules,
or arguably choose to provided freestanding implementations
where a hosted implementation would be more sane.

The rules are still the same: for C++ code, you write
main().  For vendor-specific extensions/restrictions,
you might need to do otherwise.  If you want better
compilers on Windows, you can try to persuade those
who make compilers; the standard already says that this
should work, for conforming compilers.

-- James

---
[ 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                      ]

* James Dennett:
> jam wrote:
>> On early days of C++ people used to provide a "main" function per
>> project.But Since windows programming started, things became a lot
>> more complicated - at least with VC++ - so that aside from the
>> compiler options that must be set,the entry point for the program also
>> differs;main ,_tmain  ,Winmain ,tWinmain Dllmain ... according to the
>> project settings.But worse than that is that in case of using standard
>> IO functions - either old C style ones defined in sdtio,conio... or
>> new C++ style ones from iostream - in a windows application ,no io
>> operation occurs unless you make some preparations(e.g start a new
>> thread which uses console) or change the project settings to a console
>> project.Maybe because IO libraries are supposed to operate under dos
>> insead of windows.I would like to use the "main" function as the entry
>> point always -just like the old days.And I wish there existed a
>> version of standard IO tools specialized for windows;espesifically I
>> want iostream members to open the terminal window automatically.I
>> regret neglected easy-to-perform and overhead-free things that could
>> keep C++ programming uniform and simple.
>
>>From the perspective of the current C++ standard, this is
> quite a simple matter: all portable C++ programs define a
> main() function as their entry point, and access to the
> standard input, output, error and log streams is available
> (for hosted implementations, at least).
>
> The standards committee can do little about non-standard
> variants on C++ which don't follow the standard's rules,
> or arguably choose to provided freestanding implementations
> where a hosted implementation would be more sane.

Ah, I remember a long-winded discussion about this.  Probably in this
newsgroup.  It boiled down to three viewpoints:

   A. Visual C++ isn't standard-conforming wrt. 'main' (my viewpoint).

   B. What's a compiler? Just supply the relevant options! (somebody
      else's viewpoint after I explained that indeedy, you can).

   C. Visual C++ is a free-standing implementation, not a hosted one, and
      so is conforming( somebody third's viewpoint).

For the OP, concerned with practical matters of Making It Work, I think
viewpoint B is perhaps the most relevant.

An ordinary Windows app is either console or GUI, which is hardwired
into the executable (a subsystem id).  g++ for Windows supports standard
'main' for both by default.  Visual C++ only supports standard 'main'
for console apps by default, but, you can specify the entry point by a
linker option so as to use standard 'main' also for GUI apps.

Regarding IO libraries, it wouldn't be any catastrophe if iostreams
weren't supported for Windows GUI apps; after all, it's hard to see
where the output would go in a fridge or toaster application, so systems
exist where iostreams aren't supported.  However, Windows GUI apps do
support stream-oriented IO, so that's another environment where full
standard C++ can be used.  The OPs problem in that respect isn't the
standard, nor is it a particular non-standard-by-default compiler, but
simply tool usage: how to connect the streams to a console window, which
is simple (e.g. redirection will do) and has nothing to do with C++.

Where this impacts on the C++ standard is that

   * Standard 'main' is designed for early Unix: it's system-specific.

   * Iostreams are designed for Unix: they're system-specific.

Windows (disregarding early 16-bit Windows) is based on UCS2 character
set, wheras 'main' is based on one byte per character, as was and is
Unix.  Which means that you can't in general provide a Windows file name
as argument to a standard C++ Windows application.  Bugger.

Windows has a process command line, 'main' is based on a set of process
argument strings, as was and is Unix.  Which means that you run into
severe problems where spaces and such are needed.  Because the
environment's standard tools (especially the command interpreter) don't
support the C++ 'main' convention but only Windows' own convention.

In short, standard 'main' is Unix-oriented, very environment-specific,
and doesn't fit the Windows program execution model.

Regarding iostreams, there is the impossibility of writing a 'cat'
command in standard C++ for Windows.  Not that it is /in principle/
possible for Unix, either, if you want a guaranteed working 'cat' no
matter which hypothetical standard C++ compiler, because of the token
support for Windows (text mode) added to the iostreams.  But in
practice, it's possible for Unix, regardless of compiler, and not for
Windows, regardless of compiler.  So the C++ standard effectively
supports Unix for 'main' and for iostreams, but effectively doesn't
support Windows.  It's a system specific standard.

But what to do about it, if anything?

I don't know  --  and it's too late for C++0x, anyway.

--
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                      ]

On Mar 28, 7:38 am, James Dennett <jdenn...@acm.org> wrote:
> jam wrote:
> > On early days of C++ people used to provide a "main" function per
> > project.But Since windows programming started, things became a lot
> > more complicated - at least with VC++ - so that aside from the
> > compiler options that must be set,the entry point for the program also
> > differs;main ,_tmain  ,Winmain ,tWinmain Dllmain ... according to the
> > project settings.But worse than that is that in case of using standard
> > IO functions - either old C style ones defined in sdtio,conio... or
> > new C++ style ones from iostream - in a windows application ,no io
> > operation occurs unless you make some preparations(e.g start a new
> > thread which uses console) or change the project settings to a console
> > project.Maybe because IO libraries are supposed to operate under dos
> > insead of windows.I would like to use the "main" function as the entry
> > point always -just like the old days.And I wish there existed a
> > version of standard IO tools specialized for windows;espesifically I
> > want iostream members to open the terminal window automatically.I
> > regret neglected easy-to-perform and overhead-free things that could
> > keep C++ programming uniform and simple.
> >From the perspective of the current C++ standard, this is
>
> quite a simple matter: all portable C++ programs define a
> main() function as their entry point, and access to the
> standard input, output, error and log streams is available
> (for hosted implementations, at least).
>
> The standards committee can do little about non-standard
> variants on C++ which don't follow the standard's rules,
> or arguably choose to provided freestanding implementations
> where a hosted implementation would be more sane.
>
> The rules are still the same: for C++ code, you write
> main().  For vendor-specific extensions/restrictions,
> you might need to do otherwise.  If you want better
> compilers on Windows, you can try to persuade those
> who make compilers; the standard already says that this
> should work, for conforming compilers.
>
> -- James
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html                     ]- Hide quoted text -
>
> - Show quoted text -

Muli-tasking environments usually device visual interfaces.If you know
at least one mainstream visual compiler/library for C++ that does not
voilate this standard I will be happy to switch to .

regards,
FM

---
[ 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                      ]

On Mar 28, 5:38 am, James Dennett <jdenn...@acm.org> wrote:
> jam wrote:

> > On early days of C++ people used to provide a "main" function per
> > project.But Since windows programming started, things became a lot
> > more complicated - at least with VC++ - so that aside from the
> > compiler options that must be set,the entry point for the program also
> > differs;main ,_tmain  ,Winmain ,tWinmain Dllmain ... according to the
> > project settings.But worse than that is that in case of using standard
> > IO functions - either old C style ones defined in sdtio,conio... or
> > new C++ style ones from iostream - in a windows application ,no io
> > operation occurs unless you make some preparations(e.g start a new
> > thread which uses console) or change the project settings to a console
> > project. Maybe because IO libraries are supposed to operate under dos
> > insead of windows.I would like to use the "main" function as the entry
> > point always -just like the old days.And I wish there existed a
> > version of standard IO tools specialized for windows;espesifically I
> > want iostream members to open the terminal window automatically.I
> > regret neglected easy-to-perform and overhead-free things that could
> > keep C++ programming uniform and simple.

> From the perspective of the current C++ standard, this is
> quite a simple matter: all portable C++ programs define a
> main() function as their entry point, and access to the
> standard input, output, error and log streams is available
> (for hosted implementations, at least).

Yes and no.  The streams are available, but there's no guarantee
concerning what they're connected to.  In most of my
applications (under Unix), for example, std::cin is connected to
/dev/null, and std::cout and std::cerr are sometimes connected
there as well.  Which is, of course, fully conformant for a
hosted application, but not much good.

In my case, this is because the programs are started either from
the rc files at startup, or by cronjobs, and so have no
controlling terminal.  But such behavior would also seem
reasonable for a windowing based application started by clicking
on an icon.  Where do you send the output if there is no
controlling terminal?

I'm also not too sure about the WinMain business.  I was under
the impression that this was a "facility"---that you could write
code starting with "main", but if you didn't, there was a
library entity which would set up a number of things needed in
the windowing environment, and then call WinMain.

And of course, the standard doesn't cover windowing environments
at all, so all bets are off once you want to use windows.

> The standards committee can do little about non-standard
> variants on C++ which don't follow the standard's rules,
> or arguably choose to provided freestanding implementations
> where a hosted implementation would be more sane.

Given that the standard offers no support for windows, and that
you can't reasonably expect standard in and standard out to work
in the normal way in a windowing application, I'm not sure that
a hosted implementation in such cases really makes sense.

It's an interesting question what hosted really should mean
today.  My servers read and write mainly from a data base server
(Sybase or Oracle) or sockets, and when the write to "normal"
files, the writes must be fully synchronized; except for
logging, I make absolutely no use of the "hosted" IO.  The one
GUI I wrote was in Java, but the situation was similar---it
communicated with the server over sockets, and with the user via
the windowing subsystem (mouse clicks, etc.), and everything we
normally understand under "hosted", at least with regards to IO,
simply didn't hold.

> The rules are still the same: for C++ code, you write
> main().  For vendor-specific extensions/restrictions,
> you might need to do otherwise.  If you want better
> compilers on Windows, you can try to persuade those
> who make compilers; the standard already says that this
> should work, for conforming compilers.

The standard makes absolutely no statement as to what you have
to do to open a window.  While I find it a bit silly to say that
the program should start with a function called WinMain, instead
of main, I can't see where the standard has anything to say
about the issue.  Once you open a window, start a thread, or
connect to a socket, you're out of the realm of standard C++.

--
James Kanze (GABI Software)            mailto:james.kanze@gmail.com
Conseils en informatique orient?e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34

---
[ 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                      ]

On Mar 28, 7:38 am, James Dennett <jdenn...@acm.org> wrote:
> jam wrote:
> > On early days of C++ people used to provide a "main" function per
> > project.But Since windows programming started, things became a lot
> > more complicated - at least with VC++ - so that aside from the
> > compiler options that must be set,the entry point for the program also
> > differs;main ,_tmain  ,Winmain ,tWinmain Dllmain ... according to the
> > project settings.But worse than that is that in case of using standard
> > IO functions - either old C style ones defined in sdtio,conio... or
> > new C++ style ones from iostream - in a windows application ,no io
> > operation occurs unless you make some preparations(e.g start a new
> > thread which uses console) or change the project settings to a console
> > project.Maybe because IO libraries are supposed to operate under dos
> > insead of windows.I would like to use the "main" function as the entry
> > point always -just like the old days.And I wish there existed a
> > version of standard IO tools specialized for windows;espesifically I
> > want iostream members to open the terminal window automatically.I
> > regret neglected easy-to-perform and overhead-free things that could
> > keep C++ programming uniform and simple.
> >From the perspective of the current C++ standard, this is
>
> quite a simple matter: all portable C++ programs define a
> main() function as their entry point, and access to the
> standard input, output, error and log streams is available
> (for hosted implementations, at least).
>
> The standards committee can do little about non-standard
> variants on C++ which don't follow the standard's rules,
> or arguably choose to provided freestanding implementations
> where a hosted implementation would be more sane.
>
> The rules are still the same: for C++ code, you write
> main().  For vendor-specific extensions/restrictions,
> you might need to do otherwise.  If you want better
> compilers on Windows, you can try to persuade those
> who make compilers; the standard already says that this
> should work, for conforming compilers.
>
> -- James
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html                     ]- Hide quoted text -
>
> - Show quoted text -

PS:I have heard of some efforts to add some minimal facilities for
multi-threading to standard library.But IMHO having a standard visual
compiler with appropariate library is in higher priority.

---
[ 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                      ]

On Mar 28, 8:43 pm, "jam" <farid.mehr...@gmail.com> wrote:
> On Mar 28, 7:38 am, James Dennett <jdenn...@acm.org> wrote:

> PS:I have heard of some efforts to add some minimal facilities for
> multi-threading to standard library.But IMHO having a standard visual
> compiler with appropariate library is in higher priority.

Why?  Without some language support, you can't do anything in a
multithreaded environment; windowing support, on the other hand,
works very well as a third party add-in.  (I too would prefer to
see it as part of the standard, but it just isn't going to
happen: it's far too complicated an issue, with too many parties
having too much invested in their propriatory systems.  And
unlike threading, we can live without it.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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                      ]

On Mar 29, 6:52 pm, "James Kanze" <james.ka...@gmail.com> wrote:
> On Mar 28, 8:43 pm, "jam" <farid.mehr...@gmail.com> wrote:
>
> > On Mar 28, 7:38 am, James Dennett <jdenn...@acm.org> wrote:
> > PS:I have heard of some efforts to add some minimal facilities for
> > multi-threading to standard library.But IMHO having a standard visual
> > compiler with appropariate library is in higher priority.
>
> Why?  Without some language support, you can't do anything in a
> multithreaded environment; windowing support, on the other hand,
> works very well as a third party add-in.  (I too would prefer to
> see it as part of the standard, but it just isn't going to
> happen: it's far too complicated an issue, with too many parties
> having too much invested in their propriatory systems.  And
> unlike threading, we can live without it.)
>
Right but lots of multithreaded programs are windowed ones,even new
generation of unoid OS`s (linux for example) provide a window based
GUI.

---
[ 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                      ]

On Mar 28, 4:48 pm, a...@start.no ("Alf P. Steinbach") wrote:
> * James Dennett:
>
>
>
>
>
> > jam wrote:
> >> On early days of C++ people used to provide a "main" function per
> >> project.But Since windows programming started, things became a lot
> >> more complicated - at least with VC++ - so that aside from the
> >> compiler options that must be set,the entry point for the program also
> >> differs;main ,_tmain  ,Winmain ,tWinmain Dllmain ... according to the
> >> project settings.But worse than that is that in case of using standard
> >> IO functions - either old C style ones defined in sdtio,conio... or
> >> new C++ style ones from iostream - in a windows application ,no io
> >> operation occurs unless you make some preparations(e.g start a new
> >> thread which uses console) or change the project settings to a console
> >> project.Maybe because IO libraries are supposed to operate under dos
> >> insead of windows.I would like to use the "main" function as the entry
> >> point always -just like the old days.And I wish there existed a
> >> version of standard IO tools specialized for windows;espesifically I
> >> want iostream members to open the terminal window automatically.I
> >> regret neglected easy-to-perform and overhead-free things that could
> >> keep C++ programming uniform and simple.
>
> >>From the perspective of the current C++ standard, this is
> > quite a simple matter: all portable C++ programs define a
> > main() function as their entry point, and access to the
> > standard input, output, error and log streams is available
> > (for hosted implementations, at least).
>
> > The standards committee can do little about non-standard
> > variants on C++ which don't follow the standard's rules,
> > or arguably choose to provided freestanding implementations
> > where a hosted implementation would be more sane.
>
> Ah, I remember a long-winded discussion about this.  Probably in this
> newsgroup.  It boiled down to three viewpoints:
>
>    A. Visual C++ isn't standard-conforming wrt. 'main' (my viewpoint).
>
>    B. What's a compiler? Just supply the relevant options! (somebody
>       else's viewpoint after I explained that indeedy, you can).
>
>    C. Visual C++ is a free-standing implementation, not a hosted one, and
>       so is conforming( somebody third's viewpoint).
>
> For the OP, concerned with practical matters of Making It Work, I think
> viewpoint B is perhaps the most relevant.
>
> An ordinary Windows app is either console or GUI, which is hardwired
> into the executable (a subsystem id).  g++ for Windows supports standard
> 'main' for both by default.  Visual C++ only supports standard 'main'
> for console apps by default, but, you can specify the entry point by a
> linker option so as to use standard 'main' also for GUI apps.
>
> Regarding IO libraries, it wouldn't be any catastrophe if iostreams
> weren't supported for Windows GUI apps; after all, it's hard to see
> where the output would go in a fridge or toaster application, so systems
> exist where iostreams aren't supported.  However, Windows GUI apps do
> support stream-oriented IO, so that's another environment where full
> standard C++ can be used.  The OPs problem in that respect isn't the
> standard, nor is it a particular non-standard-by-default compiler, but
> simply tool usage: how to connect the streams to a console window, which
> is simple (e.g. redirection will do) and has nothing to do with C++.
>
> Where this impacts on the C++ standard is that
>
>    * Standard 'main' is designed for early Unix: it's system-specific.
>
>    * Iostreams are designed for Unix: they're system-specific.
>
> Windows (disregarding early 16-bit Windows) is based on UCS2 character
> set, wheras 'main' is based on one byte per character, as was and is
> Unix.  Which means that you can't in general provide a Windows file name
> as argument to a standard C++ Windows application.  Bugger.
>
> Windows has a process command line, 'main' is based on a set of process
> argument strings, as was and is Unix.  Which means that you run into
> severe problems where spaces and such are needed.  Because the
> environment's standard tools (especially the command interpreter) don't
> support the C++ 'main' convention but only Windows' own convention.
>
> In short, standard 'main' is Unix-oriented, very environment-specific,
> and doesn't fit the Windows program execution model.
>
> Regarding iostreams, there is the impossibility of writing a 'cat'
> command in standard C++ for Windows.  Not that it is /in principle/
> possible for Unix, either, if you want a guaranteed working 'cat' no
> matter which hypothetical standard C++ compiler, because of the token
> support for Windows (text mode) added to the iostreams.  But in
> practice, it's possible for Unix, regardless of compiler, and not for
> Windows, regardless of compiler.  So the C++ standard effectively
> supports Unix for 'main' and for iostreams, but effectively doesn't
> support Windows.  It's a system specific standard.
>
> But what to do about it, if anything?
>
> I don't know  --  and it's too late for C++0x, anyway.
>
> --
> 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?
>

Do not worry about main`s arguments there is always the possibility to
introduce new prototypes(taking different sets of arguments)  for
main .I merely mean to standardize the main function as the only valid
entry point here.

---
[ 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                      ]

On early days of C++ people used to provide a "main" function per
project.But Since windows programming started, things became a lot
more complicated - at least with VC++ - so that aside from the
compiler options that must be set,the entry point for the program also
differs;main ,_tmain  ,Winmain ,tWinmain Dllmain ... according to the
project settings.But worse than that is that in case of using standard
IO functions - either old C style ones defined in sdtio,conio... or
new C++ style ones from iostream - in a windows application ,no io
operation occurs unless you make some preparations(e.g start a new
thread which uses console) or change the project settings to a console
project.Maybe because IO libraries are supposed to operate under dos
insead of windows.I would like to use the "main" function as the entry
point always -just like the old days.And I wish there existed a
version of standard IO tools specialized for windows;espesifically I
want iostream members to open the terminal window automatically.I
regret neglected easy-to-perform and overhead-free things that could
keep C++ programming uniform and simple.

---
[ 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                      ]