Re: linker error
James Kanze wrote:
[..]
I know this is off topic, but the issue comes up so often: what
the hell is a "console application"? How does it differ from
any other application, other than, perhaps, it doesn't use
certain libraries? (In which case, of course, you don't need to
click anything. Just don't include the appropriate headers, nor
link against the corresponding library.)
It's specific to Windows OS, and how the hosting environment tries
to provide (or exclude) certain features we're so used to in some
other environs. E.g., even if you start a "normal" Windows app
from the command line, no output is going to appear. 'std::cout'
and 'std::cerr' are essentially "black holes". Same for the input
'std::cin', it just doesn't exist in a "normal" Windows app. In
order to have those elements, the app has to "create a console"
(in Windowese) and connect it to the standard I/O streams. In
a "console application" this is done automatically.
Unless I've misunderstood something greatly, in the end, an
application is an application.
Actually, a Windows application is not an application at all.
It's a dynamically loaded library (DLL). It cannot execute
without many other things from the system (compared to some true
executables in some systems that contain all the code necessary
to be run, except for BIOS, maybe).
If it invokes some system
function which opens a window, and plays around in it, then it
is a GUI (or Windowing) application, but that's a result of the
code the programmer wrote, and nothing else. The applications I
write don't normally do this: are they automatically console
applications (even if they are started by a cronjob, or at
system start-up, with cin, cout and cerr connected to
"/dev/null")?
No, they are not.
Is the application start point called "main" or "WinMain" in the
apps you write? What subsystem do you tell the linker to use?
If you don't tell, what does it use by default?
MS Windows can be viewed as a bit more sophisticated than other
systems we've encountered just for having those "subsystems".
I don't really care much about digging too deep into them, and
use "console" for "command-line I/O" and "windows" for the rest.
They do differ a bit in the ways to acquire the command-line args,
for example. But beyond that it doesn't matter for what most
folks do. Unless it does, of course, and then they learn about
those things.
I'd add: use command line tools for building.
Is there any other way? All the IDE's that I know (admittedly,
NOT Visual Studio) do is generate command lines.
VS does invoke the compiler with some command line, as well,
and captures its output, and then displays it in a window. Nothing
out of the "ordinary". It does have plenty of other tools to help
set up a project and navigate the source, and... But that's all
it does.
An IDE adds too much "helpful" stuff that just gets in the way.
:-) Boy can I agree with you there.
<shrug> Tastes differ. Project sizes differ.
At least for production code. I can imagine that when learning,
"one thing at a time" is not a bad policy, and if you could find
an IDE which actually worked correctly and usefully, it would be
nice. But professionally, never.
Never say "never". Then again, I've known people who never flew
on a plane or used a computer or a wireless phone...
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask