Re: Standard entry point and IO library for windows
* 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 ]