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