form c# to c++

[Peter Pippinger]

Hello NG,

i have done some work in c#. But now i want to learn c++. I cant find
out, how to use strings. in c# i have a function:

public void info(string nachricht)
{
System.Windows.Forms.MessageBox.Show(nachricht);
}

could you please give me an example, how the function should look like
in c++? And maybe some informations about handling strings in c++?

thaks a lot,
Peter

[mlimber]

Peter Pippinger wrote:

Hello NG,

i have done some work in c#. But now i want to learn c++. I cant find
out, how to use strings. in c# i have a function:

public void info(string nachricht)
{
System.Windows.Forms.MessageBox.Show(nachricht);
}

could you please give me an example, how the function should look like
in c++? And maybe some informations about handling strings in c++?

thaks a lot,
Peter

I'd suggest you pick up _Accelerated C++_ by Koenig and Moo, which
teaches C++ from the ground up the right way. You'll learn about
std::strings and a whole lot more. For an example of printing a string
of characters, see:

http://www.parashift.com/c++-faq-lit....html#faq-29.9

Cheers! --M

[Tomás]

Peter Pippinger posted:

public void info(string nachricht)
{
System.Windows.Forms.MessageBox.Show(nachricht);
}

could you please give me an example, how the function should look like
in c++?

void info( const string &nachricht )
{
MessageBox( 0, nachricht.c_str(), 0, 0 );
}
That's using the bare-bones Win32API without resorting to any wrappers. I
believe there's something called MFC which wraps the Win32API into neat
classes and the like.
-Tomás

[Sean]

If you are going to learn C++ don't learn Win32API (until it is
absolutely necessary) and avoid MFC at all costs. Why bother learning
C++ if you can only use it on Windows with Microsoft's compiler? If
you are going to learn C++, learn standard C++. C++ should not be
learned through distortion of a 3rd party, non-standard library.

Since you can write C++ as "write once, compile anywhere" (done right
it can be more portable than Java's suppossed "write once, run
anywhere"), I suggest you find a cross-platform graphical API and learn
that if you need a GUI (try gtk+, QT (if you have a budget or are
working open source), c++/tk, wxWidgets, or something else). As much
as possible use these libraries for your interface only, and use the
standard library and boost (www.boost.org - some of which will be
included in the next C++ standard) for everything else (the observer
pattern (http://en.wikipedia.org/wiki/Observer_pattern) can be quite
useful - use boost's signals
(http://www.boost.org/doc/html/signals.html) even if your graphical
toolkit has a signals implementation so that you can change your
interface library when you need to without changing your core
implementation).

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.)");
}
}

There are also some good online resources, my former OO design prof
recommends:
http://www.4p8.com/eric.brasseur/cppcen.html (beginner)
and
http://www.icce.rug.nl/documents/cplusplus/ (advanced)

[Tomás]

Sean posted:

If you are going to learn C++ don't learn Win32API (until it is
absolutely necessary) and avoid MFC at all costs.

Win32API and MFC have nothing to do with learning C++.

You use an operating system's built-in functionality when the Standard
language's built-in features are inadequate.

The original poster's code obviously displayed a dialog box on Windows.
Therefore I wrote an equivalent C++ piece of code which displayed a
dialog box on Windows.

That is orthogonal from one's choice of reusable code to utilise when
writing algorithms and the like.

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:

#include<...

int main()
{
std::vector<std::string> vec;

/*** blah ***/

MessageBox(0, vec.at(3).c_str(), 0, 0 );
}

Why bother learning
C++ if you can only use it on Windows with Microsoft's compiler?

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.

If
you are going to learn C++, learn standard C++.

Brilliant advice. (Although I don't see the alternative)

C++ should not be
learned through distortion of a 3rd party, non-standard library.

Again you miscontrue the notion of MFC or Win32API being related to the
learning of the language itself.

Since you can write C++ as "write once, compile anywhere" (done right
it can be more portable than Java's suppossed "write once, run
anywhere"), I suggest you find a cross-platform graphical API and learn
that if you need a GUI (try gtk+, QT (if you have a budget or are
working open source), c++/tk, wxWidgets, or something else).

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.

As much
as possible use these libraries for your interface only, and use the
standard library and boost (www.boost.org - some of which will be
included in the next C++ standard) for everything else

Brilliant advice.
<snip> 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.
-Tomás

[Daniel T.]

In article <BH******************@news.indigo.ie>,
"Tomás" <No.Email@Address> wrote:

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.

"intertwine" is probably not the best idea (or maybe not the best choice
of words?) You should bury OS specific calls in a few classes who's sole
job is to deal with OS specific information. Make it very clear what has
to be changed to get your program to work in a different environment.

Might I suggest:
<http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf>

[Sean]

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

Why bother learning
C++ if you can only use it on Windows with Microsoft's compiler?

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."

C++ should not be
learned through distortion of a 3rd party, non-standard library.

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.

Since you can write C++ as "write once, compile anywhere" (done right
it can be more portable than Java's suppossed "write once, run
anywhere"), I suggest you find a cross-platform graphical API and learn
that if you need a GUI (try gtk+, QT (if you have a budget or are
working open source), c++/tk, wxWidgets, or something else).

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).

As much
as possible use these libraries for your interface only, and use the
standard library and boost (www.boost.org - some of which will be
included in the next C++ standard) for everything else

Brilliant advice.

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.

<snip>

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.

[Tomás]

Sean posted:

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.

I chose my words poorly, and I gave a poor example of code. I keep my
full portable code separate from my OS-specific code. However, my OS-
specific code still uses as many constructs as it can from the Standard
C++ Library (rather than using OS-specific functions).
For instance, I recently wrote fully portable code for converting a
integral value like: 45623124

into:

Four hundred and fifty-six thousand, two hundred and thirty-one Euro
and twenty-four cent
I then wrote a Windows GUI for it, but I kept the Windows code entirely
separate from the "algorithm code" -- I even kept the files in a separate
directory.
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.

I don't know much about MFC; all I know is that it wraps the Win32API
functions into classes. Instead of having the likes of:

HWND wnd = CreateWindows();

SetWindowText(hwnd, "Hello");
ShowWindow(hwnd);

You have something like:

Window wnd;

wnd.SetText("Hello");
wnd.Show();

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."

I agree on this.

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.

I was unaware of this.
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)

I was in fact referring to std::string, and you're correct that I omitted
the necessary includes. I also omitted necessary using declarations. I
wanted to make the code snippet as simple as possible to read.

, 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.

I agree that the "Microsft way of programming in C++" is disgusting.
However, you can be a "Standard C++ programmer" and write programs for
Windows.
-Tomás

[Sean]

> However, you can be a "Standard C++ programmer" and write programs for

Windows.

Here we agree as well.

Peter, I hope you have found our discussion helpful, and good luck with
your std::string's.