Relationship Between CString Class, MFC, And iostream.h

[Frederick2]

Been meaning to ask that question for a long time. With Visual Studio 6 I seem to recall I had to include iostream.h to use the CString class. Do I have that right? I think I also had to specify in a configuration dialog that I wanted to either link statically or dynamically with MFC.dll. Do I have that right?

About five weeks ago I got myself Visual Studio Pro 2008 and I've been just setting up my projects as empty C++ Win32 console or Gui projects as the case may be without MFC support. Naturally, I don't have access to the CString class that way.

My questions are as follows:

1) What is the relationship between iostream.h and MFC? Can the one be used without the other?

2) Is it possible to use the CString class without MFC? Last I recall, the MFC library was upwards of a MB or bigger. I'm not an MFC user at all, but if I could access the CString Class without it, I'd consider it.

3) I just set up a VC9 C++ project (console) where I specified I didn't want to use MFC. However, on the later screen where you would check "Empty File" I checked "Add MFC Support". What I ended up with was a lot of wizzard generated code where both iostream.h and stdio.h were included, and when I declared a CString variable I didn't get an error on compile. However, the resulting Release Build exe file was only 9 or 10 K or so but I'm wondering if its statically linked with MFC? I'm confused about this and would greatly appreciate some enlightenment on tis topic.

To give more info on where I'm coming from, I'd consider using the professionally created CString class in my programming, but not if its going to cost me having to link with or include the MFC.dll. I have my own String Class I've created over the years that's pretty good and only adds next to nothing to my programs. However, I know its not as good as a professionally developed one.

[sfuo]

I use devC++ and if I want to use the <cstring> library I do not need to use <iostream> or <iostream.h>. And I have never used MFC so I wouldn't know but since I don't use it you do not need to include it.

[Frederick2]

Thanks for the idea Sfuo. I've got Dev-Cpp too and did a little research at Wikipedia...

http://en.wikipedia.org/wiki/String_(C%2B%2B)

and found a program I modified to this...

#include <stdio.h>
#include <string>
using std::string;

int main()
{
 string s1,s2;

 s1="Hello, ", s2="World!";
 s1=s1+s2;
 printf("s1=%s\n",s1.c_str());
 getchar();

 return 0;
}

...and that produced a 100K program with Dev-Cpp and a 48K program with GNU CodeBlocks, the latter of which allows for optimazations in terms of size. Note I didn't use iostream in that. So that's movement in the right direction anyway.

[Ancient Dragon]

>>I seem to recall I had to include iostream.h to use the CString class. Do I have that right?

No. You need to create an MFC program or a console program that supports MFC. The IDE will generate the files with necessary includes, such as afx.h.

1) There is no relationship between CString and iostream. They are two distinctly different c++ classes, one can be (and usually are) used without the other.

2) CString is part of MFC, so it can't be used without MFC.

Why would you want to use CString in a non-MFC program? There already is an alternative -- #include <string>

[Frederick2]

Thanks for the info AncientDragon. I'm slowly figuring it out. I had a feeling I was juxtoposing things that might not be related, that is, MFC & C++ generic String Class Concepts. Just tonight I tried my above program (slight modification of one I found at Wikipedia) with VC++9 and optimized for size it compiles down to 8 or 9 K.

What's really blowing my mind though in terms of just the unbelievable intricacies of all this...

...in the above blurb of code (post #3 in this thread), if <string> is replaced with <string.h>, the whole thing flies apart! If its not asking too much, I'd love an explanation of that one.

[opcode]

CString class is actually not belong the MFC class library. It is in ATL. You can use appropriate ATL headers to use CString in any Windows C++ application.
For more information on how you can use CString in a C++ project, read thease articles.
string classes

How to use CString

[Ancient Dragon]

...in the above blurb of code (post #3 in this thread), if <string> is replaced with <string.h>, the whole thing flies apart! If its not asking too much, I'd love an explanation of that one.

<string.h> is from C language and contains prototypes for C's standard string handling functions for character arrays, such as strcmp(), strcpy(), etc. It can be used in either C or C++ programs. When used in c++ programs <string.h> is normally renamed <cstring>. The only difference between the two is that <cstring> puts all those functions in std namespace while <string.h> the functions are in global namespace.

<string> is c++ only and contains the standard STL (standard template library) string class. It's completly independent of anything that is in string.h. Both <string> and <cstring> can be used in the same c++ program.

[Ancient Dragon]

CString class is actually not belong the MFC class library. It is in ATL. You can use appropriate ATL headers to use CString in any Windows C++ application.
For more information on how you can use CString in a C++ project, read thease articles.
string classes

How to use CString

I think Microsoft has changed CString since VC++ 6.0, where it was part of MFC. In VC++ 2005 and later compilers you reminded me that they changed it to be part of ATL, as they did many other MFC classes.

[Frederick2]

Thanks for the info opcode & Ancient Dragon. I'm slowly putting the pieces together. This is pretty embarissing to me actually that I didn't know C++ had a String class. For a number of years I'd been perfecting my own String class figurring when I finally got it right I'd be in good shape with C++. Only to find there is one. What had me confused were the constant references to 'string' or <string> as being 'The' C++ string class, and every time I'd see that I'd think, "Heck, all that is are all those strcpy(), strcat() wrappers around the asm byte blaster string primitives that hardly merits the name of a 'Class'.

I get the picture now!