Array of CString s vs. CString Array
Richard C
What's the deal with CStringArray? I have used CStringArray in several
places but now I'm wondering why can't I use an array of CStrings instead
- at least I wouldn't have to bother with SetSize().
TIA
Richard C
Ajay Kalra
vector other STL collection became a part of C++. I'd use vector<CString>.
--
Ajay Kalra [MVP - VC++]
ajay...@yahoo.com
"Richard C" <r...@replytogroup.com> wrote in message
news:tN97h.67412$rP1....@news-server.bigpond.net.au...
Joseph M. Newcomer
CString s[20];
for example? Is SetSize such a burden? Seems a silly thing to worry about...
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
MrAsm
wrote:
>You can use whatever you like. CStringArray has been part of MFC before
>vector other STL collection became a part of C++. I'd use vector<CString>.
I'd use CStringArray; IMHO it is not very good to mix STL with MFC
classes.
For example, if you "touch" a STL class like std::vector, you bring
with you all the STL system of exceptions. So your code should catch
them, to be robust.
Moreover, it seems that the only very standard compliant and
multiplatform (and high quality) implementation of STL is Dinkumware's
STL. It would certainly be an high quality code, but it also does cost
(exspecially if you want source code - but it's OK, the quality does
cost).
On the other side, MFC has cool classes (IMHO easier to use than STL
ones, too), good and robust since VC6 (while STL has problems in VC6),
with source code that can be inspected and followed step-by-step
during debugging.
Moreover, MFC container classes source code is IMHO much more easier
to read than STL one (I'm not speaking about Dinkumware STL, because I
don't have it).
Obviously, STL containers have much more power than MFC ones (STL has
iterators, algorithms, etc.), but I think that if you only need a
simple way to store data, MFC containers (also the templated ones),
would be just fine (at least for me, I'm absolutely not a C++/STL
guru, so I don't need all the STL big-power).
Mr. Asm
Ajay Kalra
We havent any problems whatsoever. In fact STL offers things like
containers(as you pointed out) which are essential in our system. For me,
using STL with MFC has been the case in various projects across multiple
jobs.
David Wilkinson
> I'd use CStringArray; IMHO it is not very good to mix STL with MFC
> classes.
I really disagree. In fact I make it a rule never to use an MFC class
unless the alternative is much more complicated. In particular, I never
use the MFC collection classes.
David Wilkinson
Joseph M. Newcomer
want to give up this valuable feature?
joe
Joseph M. Newcomer
who refuse to move forward. STL in VS6 is very buggy. Otherwise, STL has a lot of
important features which the MFC classes don't have, particularly the ability to compose
objects (try putting a CArray as a member of a CMap...).
joe
MrAsm
wrote:
>> IMHO it is not very good to mix STL with MFC classes.
>
>We havent any problems whatsoever. In fact STL offers things like
>containers(as you pointed out) which are essential in our system. For me,
>using STL with MFC has been the case in various projects across multiple
>jobs.
OK, but may I ask how do you catch STL and MFC exceptions...?
Do you catch for std::exception & (STL) and CException & (MFC)
separately? (From what I know, CException is not derived from
std::exception...)
Thanks,
Mr Asm
MrAsm
<newc...@flounder.com> wrote:
>The main reason I have not used STL is that I have a massive client base bound to VS6, and
>who refuse to move forward. STL in VS6 is very buggy.
Yes, it's true.
But did you and your clients try STLport?
It's used as a replacement for VC6 STL in many projects, like
OpenSceneGraph:
http://www.openscenegraph.org/
as you can read here:
However, I would like to make it clear that I don't doubt the *power*
of STL (as I already wrote in my original post).
Mr Asm
Ajay Kalra
Joseph M. Newcomer wrote:
> The main reason I have not used STL is that I have a massive client base bound to VS6, and
> who refuse to move forward. STL in VS6 is very buggy.
We were using STL w VC6 (since 1998 or so) without any major issue.
There were very minor issues which were tackled early on and it stayed
with us.
---
Ajay
David Ching
"MrAsm" <inv...@invalid.com> wrote in message
news:f2vql25t85ulj4fqr...@4ax.com...
>
> I'd use CStringArray; IMHO it is not very good to mix STL with MFC
> classes.
>
> For example, if you "touch" a STL class like std::vector, you bring
> with you all the STL system of exceptions. So your code should catch
> them, to be robust.
>
> Moreover, it seems that the only very standard compliant and
> multiplatform (and high quality) implementation of STL is Dinkumware's
> STL. It would certainly be an high quality code, but it also does cost
> (exspecially if you want source code - but it's OK, the quality does
> cost).
>
> On the other side, MFC has cool classes (IMHO easier to use than STL
> ones, too), good and robust since VC6 (while STL has problems in VC6),
> with source code that can be inspected and followed step-by-step
> during debugging.
>
> Moreover, MFC container classes source code is IMHO much more easier
> to read than STL one (I'm not speaking about Dinkumware STL, because I
> don't have it).
>
> Obviously, STL containers have much more power than MFC ones (STL has
> iterators, algorithms, etc.), but I think that if you only need a
> simple way to store data, MFC containers (also the templated ones),
> would be just fine (at least for me, I'm absolutely not a C++/STL
> guru, so I don't need all the STL big-power).
>
I agree with all your points. MFC containers are the solution for those who
just want to store our data somewhere and get it back with no fuss or muss
and don't want to spend much time wondering about the sanity of the STL API.
My focus is Control Panel and Windows Internals apps and thus do not
manipulate complex data structures, and for these, the simpler solution is
best. I've seen STL misused to the point where code becomes an unreadable
mess, but I'm sure is a reference in state-of-the-art usage of STL.
MFC is a unique library that appeals to those who appreciate the structure
of OOP to increase organization and maintainability of code as opposed to
something more RAD like VB (and .NET forms from what I can tell). At the
same time, its goals are the same as with VB: to make Windows programming
more approachable to more people. So that's why we get crap from both the
VB side (who say C++ is too hard) and the C++ CS-types (who say MFC has
limited power). I think those like you and me are solving exactly the types
of problems MFC was designed for and use it to our advantage.
BTW, for this reason I'm using VC++/CLI instead of C#.
-- David
Ajay Kalra
This is exactly how I do it now. Although early on (VC6 timeframe), I
was using MFC collection classes exclusively.
---
Ajay
David Wilkinson
> The main reason I have not used STL is that I have a massive client base bound to VS6, and
> who refuse to move forward. STL in VS6 is very buggy. Otherwise, STL has a lot of
> important features which the MFC classes don't have, particularly the ability to compose
> objects (try putting a CArray as a member of a CMap...).
> joe
>
Hi Joe:
Yes, the lack of assignment and copy cosntructor for the MFC collection
classes is a major drawback. These things are provided automatically in
the STL. I think a major problem with MFC is that its design is driven
by binary serialization, which I do not use.
OTOH, I disagree that the standard libraray in VC6 is very buggy. You
HAVE to apply the patches on the Dinkumware site, but if you do it works
well for the most part.
David Wilkinson
MrAsm
<d...@remove-this.dcsoft.com> wrote:
>I agree with all your points.
> [...cut...]
I agree with all your points, too! :)
Libraries (and languages) are *tools*. One should use the tools he/she
considers better for his/her needs.
Mr Asm
Tom Serface
1. Add values anywhere in the array is much easier than with a vector or
regular array.
2. Removing all values is very easy.
3. You can copy one array to another very easily.
4. etc.
I guess you could reproduce this functionality, but then you'd just end up
with another class that does the same thing.
FWIW you don't really need to call SetSize() unless you plan on adding lots
of objects quickly. The array will grow on its own, albiet slightly slower
because of reallocation.
Tom
"Richard C" <r...@replytogroup.com> wrote in message
news:tN97h.67412$rP1....@news-server.bigpond.net.au...
Ajay Kalra
> 1. Add values anywhere in the array is much easier than with a vector or
> regular array.
vector::insert
> 2. Removing all values is very easy.
vector::clear
> 3. You can copy one array to another very easily.
vector::vector (??)
> 4. etc.
??
---
Ajay
Jeff F
>> several places but now I'm wondering why can't I use an array of
>> CStrings instead - at least I wouldn't have to bother with SetSize().
>>
Assuming:
typdef std::vector<CString> tStrings;
tString Strings(5,"one of five strings");
> 1. Add values anywhere in the array is much easier than with a vector
> or regular array.
Strings.insert( Strings.begin() + 2, "a new string" );
> 2. Removing all values is very easy.
Strings.clear();
> 3. You can copy one array to another very easily.
tStrings MyCopy( Strings );
> 4. etc.
std::sort( Strings.begin(), Strings.end() );
...
> I guess you could reproduce this functionality, but then you'd just
> end up with another class that does the same thing.
Or the one above with full generality. :)
Jeff Flinn
Ajay Kalra
>
Exactly.
---
Ajay
Tom Serface
thinking. I have used this stuff before :o) Brain freeze.
So I guess it all comes down to preference.
Tom
"Jeff F" <no-r...@microsoft.com> wrote in message
news:uP4L9JmC...@TK2MSFTNGP02.phx.gbl...
MrAsm
wrote:
>> 4. etc.
>
> std::sort( Strings.begin(), Strings.end() );
>
> ...
>
>> I guess you could reproduce this functionality, but then you'd just
>> end up with another class that does the same thing.
>
>Or the one above with full generality. :)
CStringArray has the IMPLEMENT_SERIAL mechanism, so it supports
serialization and dumping of its elements "out of the box". It works
well with MFC archives and serialization.
(With std::vector< CString > you don't have this.)
Moreover, when you mix STL and MFC classes, do you catch for both
std::exception and CException?
Mr Asm
Ajay Kalra
> serialization and dumping of its elements "out of the box". It works
> well with MFC archives and serialization.
> (With std::vector< CString > you don't have this.)
That makes some sense but keep in mind that serialization in MFC is
weak, very weak. An archive created with one version of MFC is not
guaranteed to work with another version. But, yes, if serialization is
a factor and vector or other classes do not add any value, by all means
use CStringArray.
> Moreover, when you mix STL and MFC classes, do you catch for both
> std::exception and CException?
We had a different mechanism for handling exceptions but why would you
not want to handle both?
---
Ajay
MrAsm
wrote:
>> CStringArray has the IMPLEMENT_SERIAL mechanism, so it supports
>> serialization and dumping of its elements "out of the box". It works
>> well with MFC archives and serialization.
>> (With std::vector< CString > you don't have this.)
>
>That makes some sense but keep in mind that serialization in MFC is
>weak, very weak. An archive created with one version of MFC is not
>guaranteed to work with another version. But, yes, if serialization is
>a factor and vector or other classes do not add any value, by all means
>use CStringArray.
Yes, I agree.
On the other side, if one wants to build super-complex data structure
and/or use special algorithms (like Boost's ones), I think that STL is
the way to go.
>> Moreover, when you mix STL and MFC classes, do you catch for both
>> std::exception and CException?
>
>We had a different mechanism for handling exceptions but why would you
>not want to handle both?
I would just like to point out that mixing MFC and STL would imply
managing different exceptions "mechanisms" (different exception class
trees, not a single-rooted tree).
I would prefer to have a single base exception class (like MFC
CException or std::exception), and derive all exceptions from there.
OK, but sure this is not a major point.
Mr. Asm
Jeff F
> On 17 Nov 2006 09:29:39 -0800, "Ajay Kalra" <ajay...@yahoo.com>
> wrote:
>
>>> CStringArray has the IMPLEMENT_SERIAL mechanism, so it supports
>>> serialization and dumping of its elements "out of the box". It works
>>> well with MFC archives and serialization.
>>> (With std::vector< CString > you don't have this.)
>>
>> That makes some sense but keep in mind that serialization in MFC is
>> weak, very weak. An archive created with one version of MFC is not
>> guaranteed to work with another version. But, yes, if serialization
>> is a factor and vector or other classes do not add any value, by all
>> means use CStringArray.
>
> Yes, I agree.
Of course theres http://www.boost.org/libs/serialization/doc/index.html
which provides direct support for all of the standard containers,
encompasses most of the features of MFC serialization, and avoids most of
MFC's short comings. This includes supporting binary, text and xml formats.
The latter two which allow cross platform archival.
Jeff Flinn
Ajay Kalra
> which provides direct support for all of the standard containers,
> encompasses most of the features of MFC serialization, and avoids most of
> MFC's short comings. This includes supporting binary, text and xml formats.
> The latter two which allow cross platform archival.
Previous versions of MS compilers had serious issues with Boost. I dont
know how VS2005 is with it but I know MSFT made this(Working with
boost) a big issue in VS2003 timeframe. So I would expect it has
improved. AFAIN, VC6 and boost was not really compatible.
---
Ajay
Jeff F
"Ajay Kalra" <ajay...@yahoo.com> wrote in message
news:1163790771....@h54g2000cwb.googlegroups.com...
There are many libraries in boost. I've been succesfully using boost with
MSVC, EVC included for >7 years I think.
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/user/summary.html
lists all of the boost libraries and the compilers supported. The author of
serialization(an many others as well) have gone to great lengths to support
most MSVC versions.
Jeff Flinn