What faster?
And what containers is better to use in general MFC or STL?
P.S. I`m using MSVC.
Printable View
What faster?
And what containers is better to use in general MFC or STL?
P.S. I`m using MSVC.
std::vector. No comparison.
Jeff
... And what about CString and std::string?Quote:
Originally Posted by ncode
I `m going to rewrite some parts of my project to STL.
Well, here you might get some debate. std::string does not supply the complex interface that CString does.Quote:
Originally Posted by ncode
However, once you use a library like boost::string_algo, you'll be much better off with std::string.
My recommendation: use boost + std::string. It's more portable and powerful.
Jeff
In my experience STL is much much better than MFC.
IMO STL vector is superior.Quote:
Originally Posted by ncode
Also, the MFC CArray container has a serious bug when copying data (cilu would know more about this, since I believe he discovered the problem).
Regards,
Paul McKenzie
Well, as jfaust says, CString vs. std::string is debatable, but only if you plan to use the new version of CString that is templated and decoupled from the rest of MFC (CStringT is the templated class, and from what I remember, you can use it standalone from the other MFC classes).Quote:
Originally Posted by ncode
If you are using Visual C++ 6.0, then attempting to use CString and only CString without introducing other parts of MFC -- well it is very error-prone and not worth it. In the case of Visual C++ 6, use std::string.
Regards,
Paul McKenzie
Prior to considering the right choice based on efficiency and issues, comes the concern of portability.
If you are writing portable applications - you should try sticking to standard solutions otherwise you would consider other platform specific solutions.
Moreover, if it is an MFC application i.e. a framework based you should be better using framework based solutions (standard solutions are also a good choice but as long as they are not exposed to the public interface - they should be hidden as an implementation detail). Otherwise, you will almost see yourself overloading things for two types - CString and std::string or CArray and std::vector. You would also see yourself converting the types at all places where any cross interaction happens. These are un-necessary and can be avoided. If it is not especially an MFC application - you should be well off choosing a standard sequence.
Also, note that if you are working with wide-character type, you would use wstring.
In general, the STL is far better then MFC counter part.
However, CString not only provides better functions, but it's also more efficient then the std::string that comes with VC++ 6.0.
If portability is not an issue, I would recommend CString over std::string.
IMHO, there's nothing wroing with mixing STL and MFC, like std::vector<CString>
Also consider that it can be easier to port a ANSI MFC appliation using CString to a UNICODE application, then it would be if you were using std::string + std::wstring
Hello, in my assignment, I also use vector<CString> should this be better than CArrayString performancewise?
wine + vodka = headache
Once you are using the MFC class CString, then use the MFC CStringArray class as well.
This may increase a little bit the performance but it's not so important.
Important is the resulting more headache-free code.
Ask your teacher if I'm right... ;)
Yes of course, CArrayString performs worse than vector<CString>
But look, the vector has to construct their ctors at least twice
Carraystring is available/builtin class in the framework. Carraystring is composed also of many useful functions to easy-access and use. MFC is old but widely used framework at the present, rewriting the library to optimize everything would be what all developers are afraid of. The STL is newer and updated more frequently. It doesn't create much difference for moderate-mid sized application.
I would go for STL any time.
Even when you use MFC and is married to Windows it's better to use standard C++ as much as possible. Why? Becuse you minimize your dependency on a specific company that's why. Even if you're not planning to divorce MS it may suddenly decide to divorce you.