Regardless of my target platform, I always write my code as fully
portable Standard C++ code. However I intertwine this code with OS-
specific calls for whatever my target is. For example:
Then it is not really "fully portable Standard C++ code".
This is the same kind of thinking that caused so much trouble for
Netscape-centric web designers when IE became widely used, and is
starting to cause problems for web designers who got too used to the IE
way of doing things.
#include<...
int main()
{
std::vector<std::string> vec;
/*** blah ***/
MessageBox(0, vec.at(3).c_str(), 0, 0 );
}
As long as MFC and Windows are your target platforms, I guess
everything will be OK. But with MFC thrown in here and there and
everywhere, you're making your job a lot harder when your company
decides it needs to have this application on UNIX, an embedded
platform, some future version of Windows, or anywhere you don't have
MFC.
Because his target platform is Windows. You can read the C++ Standard
five hundred times with a magnifying glass, but it still won't tell you
how to display a dialog box on Windows.
It doesn't tell you how to display a dialog box in X or on PalmOS
either. For me, this turns on a little light bulb that lets me read
the writing on the wall that says: "Standard C++ doesn't define a GUI
interface, you should keep your GUI separate from your implemenation to
ensure code is portable."
Again you miscontrue the notion of MFC or Win32API being related to the
learning of the language itself.
But MFC in particular is one library that really attempts to replace a
lot of standard library. Your original example used some MFC string
instead of std::string (or at least you didn't show any of the includes
and using statements that would show a someone new to C++ what they
need to do to make that code work), but MFC also defines exceptions
that don't inherit from those in the standard library, avoids using
templates to prefer polymorphism. I think that MFC encourages you to
use C++ as if it were Java or C#. It seems to me that if you learnt
C++ in the MFC world not only would your code not be portable, but your
knowledge wouldn't be either.
There is no doubt that using MFC is the right design decission for some
projects, but I wouldn't send someone who wants to learn C++ down that
path. MFC lets you do all sorts of wonderful things without having the
first clue about the standard library. So if you want to be an MFC
programmer, use MFC, but if you want to be a C++ programmer, stay away
from MFC until you really are one.
Oh... I finally see what you're getting at! You want him to use one of
those libraries that's designed to work with GUI on different OS's (e.g.
Windows, Linux).
But again, this has nothing to do with the language of C++ itself.
Very true, and maybe that is the crux of this discussion: to learn C++
don't worry about creating graphical interfaces, just learn standard
C++ (which, as we've already covered, doesn't define a method of
displaying a message box).
I'm just repeating what I have read, and what has worked for me, but
I'm sure many of the other posters to this newsgroup will appreciate
the complement.
To print your message in standard C++ to a console window do:
#include <iostream>
#include <string>
void info(const std::string &nachricht) {
std::cout << nachricht << std::endl;
}
int main(int argc, char *argv[]) {
if (argc > 1) {
info(argv[1]);
}
else {
info("Hello happy C++ land!");
info("Run this program with an argument to have that argument
printed.");
info("(To print a sentence, put quotes around your message.)");
}
}
Good... but the original poster wanted a dialog box.
Did he really want a dialog box, or to learn C++?
He actually asked how strings work.