Re: [C++] Initialization lists with array

From: Leor Zolman (leor_at_bdsoft.com)
Date: 03/30/04 

Date: Tue, 30 Mar 2004 15:04:53 GMT

On Tue, 30 Mar 2004 23:43:27 +1000, "Chris \( Val \)"
<chrisval@bigpond.com.au> wrote:

>
>| > std::string S;
>| > std::cout << S; // Ok...
>| >
>| > std::vector<char> V;
>| > std::cout << V; // Not ok...
>|
>| That should not disqualify std::string from being a container. Adding
>| additional behaviour has never before broken an is-a relation. :-)
>
>But this demonstrates that std::string was not part of the STL, and
>that it was built for completely different purposes.

Chris, why do you seem to be so hung up on string's /history/? Yes, before
the STL existed it was not an STL container. When the Standards committee
voted to incorporate STL into the library, some fancy footwork commenced to
unify (as best they were able to), strings and the STL. The result is that
now strings have a dual-personality; they perform both as faux-fundamental
types and as (restricted) STL containers (restricted as in designed to work
with char types, and not having much application outside of that...since
not too many folks would find great benefit from forging char_traits
specializations for non-character types).

>| >
>| > I would really love to here what the others have to say about
>| > this debate, and what their particular stance is. Then maybe
>| > we could add(in agreement), an brief sentence or two to the
>| > FAQs list for future reference ?

At this point, it looks like about the only thing folks here could agree
upon saying is that there's no common agreement on whether strings should
be considered to be STL containers, and even if there were, it wouldn't
have diddly-squat of an effect on how folks write their code.

But at least I think I've put forth a decent argument against making
emphatic statements denying std::string its container-hood, which was how
this whole thing got started in the first place...
        -leor 

-- 
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix  
C++ users: Download BD Software's free STL Error Message Decryptor at:
   www.bdsoft.com/tools/stlfilt.html

Relevant Pages

  • Re: Clean code vs. efficiency
    ... > instead of character arrays. ... The default STL ... In general, the STL containers are extremely fast, and might be faster than ... The STL allocators let you use pool allocators, but you can also that by ...
    (comp.lang.cpp)
  • Re: A solution to warning C4251 - class needs to have dll-interface...?
    ... Because the functions of the STL containers ... are completely defined by their header files. ... the static data for the entire program. ...
    (microsoft.public.vc.language)
  • Re: [C++] Initialization lists with array
    ... before the STL existed it was not an STL container. ... Are there specific container requirements that std::string fails ... The result is that now strings have a dual- ... it looks like about the only thing folks here could agree ...
    (alt.comp.lang.learn.c-cpp)
  • Re: multiset segfault
    ... > page and on Google for my STL information. ... some sections on STL containers, and it is anyway worth reading the ... if you google for "STL tutorial" you'll find many more ...
    (comp.lang.cpp)
  • Re: Cross platform C++ base library?
    ... This way, you should have both the cross-platform feature (because the class is built on top of STL), and the CString-like public interface: ... However, I learnt the basics of STL containers like vector and map, and now I'm glad to use these STL containers. ... If you really don't like STL, you could just use STL as the core to implement classes with an MFC-like interface (e.g. a David::CArray, ...
    (microsoft.public.vc.mfc)