STL or MFC strings and containers? 
Author Message
 STL or MFC strings and containers?

I was wondering what people's opinions were on which string and
container classes to use in an MFC application. Would I be better off
sticking with the MFC CString and other list/array etc. classes? Or is
there a compeling reason to use the STL string and container classes?

I guess to make classes usable in non-MFC application I would use the
STL. Or can the two co-exist in an application without major problems?

Any ideas or comments from people who have had experience with this
topic would be greatly appreciated.

Regards,

Diego Barros



Fri, 04 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?
Probably for string you are better off with CString if only because all of
the MFC  classes work with it. For other STL classes this is really a
question of personal preference. Overall I think the STL classes are a
more flexible than the MFC classes and you can use the generic algorithms
with them. However for most routine stuff the MFC containers are perfectly
adequate. For less experienced programmers the MFC classes are probably
easier to use.

In my experience there is no problem with both types of containers
coexisting in your application and I can't think of any theoretical reason
why there should be.

Shimon



Fri, 04 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?
One remark.
The STL classes (at least string) are not thread-safe.

Best regards,
Alex Kalinin.

Quote:

>I was wondering what people's opinions were on which string and
>container classes to use in an MFC application. Would I be better off
>sticking with the MFC CString and other list/array etc. classes? Or is
>there a compeling reason to use the STL string and container classes?

>I guess to make classes usable in non-MFC application I would use the
>STL. Or can the two co-exist in an application without major problems?

>Any ideas or comments from people who have had experience with this
>topic would be greatly appreciated.

>Regards,

>Diego Barros



Sat, 05 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?
Does anyone know if the MFC container classes are thread-safe?. I suspect
not as regular MFC classes are not thread safe.

Regards,

Shimon

Quote:

> One remark.
> The STL classes (at least string) are not thread-safe.

> Best regards,
> Alex Kalinin.



Sat, 05 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?
An article by S. Ignatchenko in the July/August 1998 issue of  C++
Report
claims that Microsoft VC++ STL is not thread safe (as well as being very
slow).

I verified that Plauger's fixes (at least to VC++ 5) found at
      http://www.dinkumware.com/vc_fixes.html
do indeed fix both the thread-safe problem and the speed.

Quote:

>Standard C++ does not address directly the issue of multiprocessing,
>threads and thread safety. This is an implementation-dependent issue,
>which enables vendors to provide multithreading support for a specific
>environment or not to provide any support for it. It is important to
>note, however, that nothing in the Standard Library or the language
>itself *disallows* multithreading and thread safety. Thus, in a
>multithreaded environment, exception handling, STL and iostream should
>be thread safe, whereas a single threaded environment (such as DOS) may
>implement them in a non-thread safe manner.

>Some implementations of STL (including Rogue Wave's and HP's) *are*
>thread safe. As far as I know, MS STL is also thread safe to some
>extent, but I haven't actually tested it.
>Thread safety, is therefore irrelevant for this discussion, since it's
>entirely a vendor's (an users' alike) choice, not a language-inherent
>feature

>Danny Kalev
>ANSI J16


>> One remark.
>> The STL classes (at least string) are not thread-safe.

>> Best regards,
>> Alex Kalinin.




- Show quoted text -

Quote:
>> >I was wondering what people's opinions were on which string and
>> >container classes to use in an MFC application. Would I be better
off
>> >sticking with the MFC CString and other list/array etc. classes? Or
is
>> >there a compeling reason to use the STL string and container
classes?

>> >I guess to make classes usable in non-MFC application I would use
the
>> >STL. Or can the two co-exist in an application without major
problems?

>> >Any ideas or comments from people who have had experience with this
>> >topic would be greatly appreciated.

>> >Regards,

>> >Diego Barros



Sat, 05 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?
Standard C++ does not address directly the issue of multiprocessing,
threads and thread safety. This is an implementation-dependent issue,
which enables vendors to provide multithreading support for a specific
environment or not to provide any support for it. It is important to
note, however, that nothing in the Standard Library or the language
itself *disallows* multithreading and thread safety. Thus, in a
multithreaded environment, exception handling, STL and iostream should
be thread safe, whereas a single threaded environment (such as DOS) may
implement them in a non-thread safe manner.

Some implementations of STL (including Rogue Wave's and HP's) *are*
thread safe. As far as I know, MS STL is also thread safe to some
extent, but I haven't actually tested it.
Thread safety, is therefore irrelevant for this discussion, since it's
entirely a vendor's (an users' alike) choice, not a language-inherent
feature

Danny Kalev
ANSI J16

Quote:

> One remark.
> The STL classes (at least string) are not thread-safe.

> Best regards,
> Alex Kalinin.


> >I was wondering what people's opinions were on which string and
> >container classes to use in an MFC application. Would I be better off
> >sticking with the MFC CString and other list/array etc. classes? Or is
> >there a compeling reason to use the STL string and container classes?

> >I guess to make classes usable in non-MFC application I would use the
> >STL. Or can the two co-exist in an application without major problems?

> >Any ideas or comments from people who have had experience with this
> >topic would be greatly appreciated.

> >Regards,

> >Diego Barros



Sun, 06 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?

Quote:

> The STL classes (at least string) are not thread-safe.

std::string is as thread-safe as CString. Both use reference counting
(which means it is not safe sharing a string between threads) and both
do not have any static class members (which means you can safely use
different strings in different threads).

--
Have fun,
Yonat.

"The nice thing about standards is that
 there are so many of them to choose from."
                -- Andrew S. Tanenbaum



Mon, 07 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?


Quote:

>> The STL classes (at least string) are not thread-safe.

>std::string is as thread-safe as CString. Both use reference counting
>(which means it is not safe sharing a string between threads) and both
>do not have any static class members (which means you can safely use
>different strings in different threads).

OK, I'm confused by the plethora of posts on this.  I understand the
reference-counting issue with std::string, and, of course, I don't
expect the STL to protect me from from concurrent access to the exact
same object, but apart from that, is the MS STL thread-safe?  Can I
safely use two different std::maps (or whatever) in different threads,
without worrying about static members in the STL?

--
 David Foster            |  It has happened before, but there is

 finger for PGP key      |      -- "Gravity's Rainbow" Thomas Pynchon



Mon, 07 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?

Quote:

>OK, I'm confused by the plethora of posts on this.  I understand the
>reference-counting issue with std::string, and, of course, I don't
>expect the STL to protect me from from concurrent access to the exact
>same object,

The problem is that most STL implementations (including VC++)
don't protect you from using different objects (strings) that come from
one object:
string a = "abc";
string b = a, c = a;
Now you can't use 'b' in one thread and 'c' in another - they share
common data.

Quote:
>but apart from that, is the MS STL thread-safe?  Can I
>safely use two different std::maps (or whatever) in different threads,
>without worrying about static members in the STL?

--

My ICQ# is 3769608 or, http://wwp.mirabilis.com/3769608


Mon, 07 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?

Quote:


> >std::string is as thread-safe as CString. Both use reference counting
> >(which means it is not safe sharing a string between threads) and both
> >do not have any static class members (which means you can safely use
> >different strings in different threads).

> OK, I'm confused by the plethora of posts on this.  I understand the
> reference-counting issue with std::string, and, of course, I don't
> expect the STL to protect me from from concurrent access to the exact
> same object, but apart from that, is the MS STL thread-safe?

This depends on your definition of thread-safe, and on your STL
implementation.

Quote:
> Can I safely use two different std::maps (or whatever) in different threads,
> without worrying about static members in the STL?

In the STL that comes with MSVC - no. If you apply the fixes from
http://www.dinkumware.com/vc_fixes.html
 - yes (but I haven't tested this myself; I'm basing this on what
Dinkumware says and a quick look at the code).

--
Have fun,
Yonat.

"The nice thing about standards is that
 there are so many of them to choose from."
                -- Andrew S. Tanenbaum



Tue, 08 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?


Quote:

>> OK, I'm confused by the plethora of posts on this.  I understand the
>> reference-counting issue with std::string, and, of course, I don't
>> expect the STL to protect me from from concurrent access to the exact
>> same object, but apart from that, is the MS STL thread-safe?

>This depends on your definition of thread-safe, and on your STL
>implementation.

I would think MS STL would imply the Visual C++ implementation, not to
mention the group I'm posting in.   And my pseudo-definition of thread
safe for this post is in the next sentence.

Quote:
>> Can I safely use two different std::maps (or whatever) in different threads,
>> without worrying about static members in the STL?

>In the STL that comes with MSVC - no. If you apply the fixes from
> http://www.*-*-*.com/
> - yes (but I haven't tested this myself; I'm basing this on what
>Dinkumware says and a quick look at the code).

Where do they say this?  I'm missing it.  The only thing I've found on
their site is the statement that the fixes "improve thread safety",
which doesn't really warm the{*filter*}les of my heart.  Granted there can
always be bugs, but I can't even find a statement that the MS version
is 'intended' to be thread safe.  (I presume details will be in the
promised FAQ).

--
 David Foster         |  People don't want to be healed, they want a nice

 finger for PGP key   |  lights around it. -- The Journal of Albion Moonlight



Tue, 08 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?

Quote:

> >> is the MS STL thread-safe?

> >This depends on your definition of thread-safe, and on your
> >STL implementation.

> I would think MS STL would imply the Visual C++ implementation,

Yes, but what version? Using or not using the fixes?

Quote:
> not to mention the group I'm posting in.

Some people who post here use other STL implementations with MSVC.

Quote:
> And my pseudo-definition of thread safe for this post is in the
> next sentence.

For reference counted implementations (like the one for string), this
definition is not detailed enough, as Michael A.Entin shows in another
post in this thread.

Quote:
> >> Can I safely use two different std::maps (or whatever) in
> >> different threads, without worrying about static members in
> >> the STL?

> >In the STL that comes with MSVC - no. If you apply the fixes from
> > http://www.*-*-*.com/ (but I haven't
> >tested this myself; I'm basing this on what Dinkumware says
> >and a quick look at the code).

> Where do they say this?  I'm missing it.  The only thing I've
> found on their site is the statement that the fixes "improve
> thread safety", which doesn't really warm the{*filter*}les of my
> heart.

P.J. Plauger said this in a number of posts to this group. If he's
watching now, he may come out and say it again, clearer then me. :-)

--
Have fun,
Yonat.

"The nice thing about standards is that
 there are so many of them to choose from."
                -- Andrew S. Tanenbaum



Tue, 08 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?
There's nothing preventing 'b' and 'c' from being used in different threads as
long as both threads are reading only (other than poor implementation).  Its
when one thread tries to write that the problems start.  The same problem
comes up in a single threaded situation:

main() {
   string s("abc");
   string t;
   char & c(s[1]);

   t = s;       // Data typically shared between s and t.
   c = 'z';     // How many strings does this modify?
   if (t[1] == 'z') {
        printf("wrong\n");
   } else {
        printf("right\n");
   }

Quote:
}

This example is from SGI's web site, where they argue against a reference
counting basic_string implementation.  However, if you get the fixes from
Dinkumware, they've added copy-on-write semantics to basic_string to get
around this.

Quote:


> >OK, I'm confused by the plethora of posts on this.  I understand the
> >reference-counting issue with std::string, and, of course, I don't
> >expect the STL to protect me from from concurrent access to the exact
> >same object,

> The problem is that most STL implementations (including VC++)
> don't protect you from using different objects (strings) that come from
> one object:
> string a = "abc";
> string b = a, c = a;
> Now you can't use 'b' in one thread and 'c' in another - they share
> common data.

> >but apart from that, is the MS STL thread-safe?  Can I
> >safely use two different std::maps (or whatever) in different threads,
> >without worrying about static members in the STL?

> --

> My ICQ# is 3769608 or, http://wwp.mirabilis.com/3769608

--
==============================================
Michael Herstine       Pencom New Technologies


==============================================



Tue, 08 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?

Quote:

>There's nothing preventing 'b' and 'c' from being used in different threads as
>long as both threads are reading only (other than poor implementation).  Its
>when one thread tries to write that the problems start.  The same problem
>comes up in a single threaded situation:

>main() {
>   string s("abc");
>   string t;
>   char & c(s[1]);

>   t = s;       // Data typically shared between s and t.
>   c = 'z';     // How many strings does this modify?
>   if (t[1] == 'z') {
>        printf("wrong\n");
>   } else {
>        printf("right\n");
>   }
>}

>This example is from SGI's web site, where they argue against a reference
>counting basic_string implementation.  However, if you get the fixes from
>Dinkumware, they've added copy-on-write semantics to basic_string to get
>around this.

That's the easy problem. Unfortunately, it's probably impractical to support
a copy-on-write (CoW), standard-compliant string, that is thread-safe even
for simultaneous read-only access. For example, suppose you have a CoW
implementation and a global:

 std::string s = "Dangerous";

and in thread A you have:

 const std::string& r = s;
 r[1] == 'a'

while in thread B you have:

 std::string t = s;
 std::string::value_type c = s[0];
 t.clear();

Clearly, s is not modified by either thread, so I would expect it to work.
Unfortunately, it probably doesn't.

Following the implications of the standard, production of a non-const
reference to a string element requires a shared representation to be
unshared, and it also requires that the string be marked unshareable, at
least until some operation that invalidates iterators and references is
performed on it. Suppose thread A is pre-empted after it has computed the
address of r[1] but before it has dereferenced the pointer. Because r is a
const reference to a std::string, the const form of operator[] is called,
and s will not be marked unshareable. Now, thread B gets control, and the
initialization of t with s results in the two sharing the same
representation. When thread B says s[0], it forces unsharing of this
representation, because it's producing a non-const reference, and t is left
pointing at s's original representation. At this point, thread A is pointing
into t's representation, and when thread A resumes, t may have already been
cleared. All bets are off, and this resulted from read-only access to s. I
don't see how to fix this and conform to the standard, except perhaps by
making std::string a monitor class, but many people would object to the
performance implications of doing that.

You can avoid this problem by using iterator and reference proxy classes,
but then you have a non-standard string, because the C++ standard requires
that string::reference be a real reference type, not a proxy. Using proxies
means you don't have to unshare the string when you produce a non-const
iterator or reference, and read-only access by multiple threads doesn't
require excessive locking to be safe.

--
Doug Harrison



Thu, 10 May 2001 03:00:00 GMT  
 STL or MFC strings and containers?
That's a good example.  Of course, if we just drop the whole notion of strings
sharing common,. reference-counted data, the problem would go away, no?
Incidentally, this is exactly what SGI argues for.  BTW, what exactly do you mean
by "iterator and reference proxy classes"?

Quote:


> >There's nothing preventing 'b' and 'c' from being used in different threads as
> >long as both threads are reading only (other than poor implementation).  Its
> >when one thread tries to write that the problems start.  The same problem
> >comes up in a single threaded situation:

> >main() {
> >   string s("abc");
> >   string t;
> >   char & c(s[1]);

> >   t = s;       // Data typically shared between s and t.
> >   c = 'z';     // How many strings does this modify?
> >   if (t[1] == 'z') {
> >        printf("wrong\n");
> >   } else {
> >        printf("right\n");
> >   }
> >}

> >This example is from SGI's web site, where they argue against a reference
> >counting basic_string implementation.  However, if you get the fixes from
> >Dinkumware, they've added copy-on-write semantics to basic_string to get
> >around this.

> That's the easy problem. Unfortunately, it's probably impractical to support
> a copy-on-write (CoW), standard-compliant string, that is thread-safe even
> for simultaneous read-only access. For example, suppose you have a CoW
> implementation and a global:

>  std::string s = "Dangerous";

> and in thread A you have:

>  const std::string& r = s;
>  r[1] == 'a'

> while in thread B you have:

>  std::string t = s;
>  std::string::value_type c = s[0];
>  t.clear();

> Clearly, s is not modified by either thread, so I would expect it to work.
> Unfortunately, it probably doesn't.

> Following the implications of the standard, production of a non-const
> reference to a string element requires a shared representation to be
> unshared, and it also requires that the string be marked unshareable, at
> least until some operation that invalidates iterators and references is
> performed on it. Suppose thread A is pre-empted after it has computed the
> address of r[1] but before it has dereferenced the pointer. Because r is a
> const reference to a std::string, the const form of operator[] is called,
> and s will not be marked unshareable. Now, thread B gets control, and the
> initialization of t with s results in the two sharing the same
> representation. When thread B says s[0], it forces unsharing of this
> representation, because it's producing a non-const reference, and t is left
> pointing at s's original representation. At this point, thread A is pointing
> into t's representation, and when thread A resumes, t may have already been
> cleared. All bets are off, and this resulted from read-only access to s. I
> don't see how to fix this and conform to the standard, except perhaps by
> making std::string a monitor class, but many people would object to the
> performance implications of doing that.

> You can avoid this problem by using iterator and reference proxy classes,
> but then you have a non-standard string, because the C++ standard requires
> that string::reference be a real reference type, not a proxy. Using proxies
> means you don't have to unshare the string when you produce a non-const
> iterator or reference, and read-only access by multiple threads doesn't
> require excessive locking to be safe.

> --
> Doug Harrison


--
==============================================
Michael Herstine       Pencom New Technologies


==============================================



Fri, 11 May 2001 03:00:00 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. STL or MFC for containers/strings?

2. STL vector container inside MFC..

3. MFC Collection class vs STL container

4. mixing MFC containers and STL ??

5. STL vs MFC Containers

6. STL vector container inside MFC..

7. does MFC containers use STL??

8. Any stl bridge / adapter for mfc containers ?

9. STL/MFC problem with set<string>

10. Problem with STL string class and MFC Serialize()

11. STL Containers

12. Exporting STL containers (specifically std::map) from DLL?

 

 
Powered by phpBB® Forum Software