Which project Template for STL coding?
-
STL is the C++ Standard Template Library and it offers a number of useful facilities for coding in C++. It has no connection with either MFC or ATL, both of which are concerned with Windows Programming. Spend some time learning STL and how to apply it to your applications, whether they are console, ATL Windows, Win32 Windows or MFC Windows.
Just say 'NO' to evaluated arguments for diadic functions! Ash
All good answers. I will spend some time learning STL.
-
STL is the C++ Standard Template Library and it offers a number of useful facilities for coding in C++. It has no connection with either MFC or ATL, both of which are concerned with Windows Programming. Spend some time learning STL and how to apply it to your applications, whether they are console, ATL Windows, Win32 Windows or MFC Windows.
Just say 'NO' to evaluated arguments for diadic functions! Ash
Other than CString (and not std::string) I use STL for everything else. std::string is terribly bad! For non-MFC project, you just need to include atlstr.h for CString (no DLL required).
-
I have been doing MFC coding. I am learning to do some STL lately, which Template project is the best for STL coding? is it ATL? Thanks
-
I have been doing MFC coding. I am learning to do some STL lately, which Template project is the best for STL coding? is it ATL? Thanks
if you want to use std::string, the best way to get into that is to redefine your string type with something like this: typedef std::basic_string, std::allocator > tstring; typedef std::basic_stringstream, std::allocator > tstringstream; using it you dont have to worry if using unicode or ansy character sets it's really useful!
Saludos!! ____Juan
-
if you want to use std::string, the best way to get into that is to redefine your string type with something like this: typedef std::basic_string, std::allocator > tstring; typedef std::basic_stringstream, std::allocator > tstringstream; using it you dont have to worry if using unicode or ansy character sets it's really useful!
Saludos!! ____Juan
Beware useing <and > in messages, since HTML mess them up! I try to rewrite your message properly. Correct me if I misinterpret. "
if you want to usestd::string, the best way to get into that is to redefine your string type with something like this:typedef std::basic_string<TCHAR,std::allocator<TCHAR> >tstring;
typedef std::basic_stringstream<TCHAR, std::allocator<TCHAR> > tstringstream;using it you dont have to worry if using unicode or ansy character sets "
2 bugs found. > recompile ... 65534 bugs found. :doh:
-
Other than CString (and not std::string) I use STL for everything else. std::string is terribly bad! For non-MFC project, you just need to include atlstr.h for CString (no DLL required).
-
Ajay Vijayvargiya wrote:
std::string is terribly bad!
I'd be interested to know why, especially as I do not have access to MFC.
Just say 'NO' to evaluated arguments for diadic functions! Ash
Richard MacCutchan wrote:
I'd be interested to know why, especially as I do not have access to MFC.
For one, it does not support direct conversion to plain C-style strings. You must call set of methods. It does not support Format/sprintf type of functions, not methods to convert to upper/lower, methods to trim, convert from Unicode/ANSI string and things that should be part of a good "string manipulation class". See wxString, which I prefer over CString!
-
Richard MacCutchan wrote:
I'd be interested to know why, especially as I do not have access to MFC.
For one, it does not support direct conversion to plain C-style strings. You must call set of methods. It does not support Format/sprintf type of functions, not methods to convert to upper/lower, methods to trim, convert from Unicode/ANSI string and things that should be part of a good "string manipulation class". See wxString, which I prefer over CString!
Ajay Vijayvargiya wrote:
For one, it does not support direct conversion to plain C-style strings
Which is good, because it saves you from a whole class of subtle bugs. Explicit conversion is always better than implicit. Having said that, I don't like std::string either - it is an example of monolithic design[^]. But that does not mean CString is any better.
-
Ajay Vijayvargiya wrote:
For one, it does not support direct conversion to plain C-style strings
Which is good, because it saves you from a whole class of subtle bugs. Explicit conversion is always better than implicit. Having said that, I don't like std::string either - it is an example of monolithic design[^]. But that does not mean CString is any better.
Nemanja Trifunovic wrote:
an example of monolithic design[^]
Excellent article, thanks, AR
When the wise (person) points at the moon the fool looks at the finger (Chinese proverb)
-
Ajay Vijayvargiya wrote:
For one, it does not support direct conversion to plain C-style strings
Which is good, because it saves you from a whole class of subtle bugs. Explicit conversion is always better than implicit. Having said that, I don't like std::string either - it is an example of monolithic design[^]. But that does not mean CString is any better.
Nemanja Trifunovic wrote:
Which is good, because it saves you from a whole class of subtle bugs. Explicit conversion is always better than implicit.
Heard of this umpteen number of times, but doesn't appease me at all. I am using a string-class for string, a text, and in C/C++ code it is supposed to mix with C-Style strings. The conversion is implicit to C-string and not from a C-string. You cannot assign a CString to
char*/``wchar_t*, the compiler wont be happy. If you say you can put into const char*, and then do forceful conversion, then my friend, you are placing the so called "bug" by yourself. I mean, what avector<char>would be called other thanstd::string? A good string-class must have string operations. Even in case, I wont have access to CString, I would write my own string-class, or download code written by some expert, instead of using this absurdstd::string!Nemanja Trifunovic wrote:
But that does not mean CString is any better.
Any better, compared to what?