C++ Is a std::string a container?
Asked Answered
T

3

10

This might be a simple question for some of you. But I was wondering if a std::string is a container. By container I mean the containers like for example std::vector, std::list and std::deque.

Since std::basic_string<> accepts other types than integral characters, but also is being optimized by working with character arrays. It isn't really clear to me in which category it falls.

This will compile:

#include <string>
#include <iostream>

int main() {
    std::basic_string<int> int_str;
    int_str.push_back(14);
    return 0;
}

But by adding this line:

std::cout << int_str << std::endl;

It won't. So by these facts I could conclude that an std::basic_string was not intended to work with other types than characters.

It might be a strange question for you. The reason I need to know this is because I'm working on a framework and I'm still not able to determine in which category a "string" would fall.

Tufts answered 23/6, 2013 at 9:58 Comment(7)
Strictly speaking, it is not part of the standard containers library. But which category to put it in depends on what you want to do with it: in many ways, a string does look very much like a container.Suttles
It is not generic enough to be a proper container. You can't make a string from struct X or float.Tala
The Standard has a Container concept. That's about the best definition we can use for this question.Placido
@MatsPetersson Why can't you make a string of float?Horsley
@Horsley I doubt it works, because the char_traits that are used for strings aren't defined for float types. [It would also be rather strange, what do you do with the character that is "between" A and B?]Tala
@MatsPetersson char_traits is a default value, you can supply you own. "what do you do with the character that is "between" A and B?" I don't understand.Horsley
What I mean is that a string is a set of distinct values representing characters (in the typical use, and I don't really see much purpose of using string to do something other than that - vector is much more generic for "storing stuff"). With a float value, you need to consider that whatever two values you have, there could be something in between (unless the difference between the two values is 1/1677216th of the first value to the second value, assuming a 24 bit mantissa).Tala
P
12

Yes, the std::basic_string template fulfills all the requirements of the Container concept. However, I think it has stronger requirements on the contained type. Just trying to dig out exactly what.

(This is not Bjarne's Concepts. Just the bit of The Standard labeled "23.2.1 General container requirements".)

Placido answered 23/6, 2013 at 10:43 Comment(0)
H
2

According to standards(2003,2011) std::basic_string is a container only for POD types. I.e. fundamental types or plain structs/classes without constructors, destructors or virtual functions. But gnu stdlib allow use non-POD types with std::basic_string. Here is an example of working with basic_string and non-POD types.

And if you what to make your example works you should define operator

std::ostream& operator<<(::std::ostream& out, std::basic_string<int> &dat) 
{ 
    out << dat[0];
    return out; 
}

Or something like that.

Hapsburg answered 23/6, 2013 at 11:27 Comment(0)
S
1

Well it is safe to say it is not a container at least not in the normal way you would think of an std container.

Most simple example is that you cant put any thing you want in it.

But it does have some classification of a container like the fact that you can put some of the basic types into it even if they are not chars, and perhaps most amazing thing is that you can get an iterator to it as if it was a normal container.

So is it a containr? I would say yes but! it is not an all genery one.

Sauter answered 23/6, 2013 at 10:48 Comment(1)
You can't put anything you want in some of the things you would normally think of as "container". For instance, you can put something in a std::vector if it is not LessThanComparable, but you couldn't put it into a std::set.Placido

© 2022 - 2024 — McMap. All rights reserved.