> What I think is an error is that our atomic text data structure gets so
> tied to a very particular container that, if sometime in the future we
> find the right container to fit its requirements, we will find it
> unnecessarily difficult to do the move.
Yes, this is true.
However, with this logic, we will never be able to use any container, because
there might come a better one in two days.
The std::string has all the common string operations, and they are implemented
efficiently. With the copy-on-write semantics, we get very good performance,
both memory and speed wise.
So I think that std::string fits our requirements 95%, and I think it would be
a mistake to hope for one that is 100%. That does not exist, because our
requirements change according to which container we choose.
Also if it turns out that we badly need something that std::string does not
provide (very unlikely IMO), the better approach is to fix our own std::string
version, and then use that, and live with the loss of compatibility with
std::string. I find this scenario to be very unlikely, but if it should
happen, we would be much faster going than if we should start from scratch with
any new container, because we have a head start with the container right here.
After all, rewriting code to use a new toolbox to replace the methods from
std::string that we suddenly would loose, is a much easier job than to live
without them from the start.
So, I still think we should decide to use std::string in full, but it's been
very interesting to discuss this, because it forces us to clear the minds and
we understand the problem better.
Greets,
Asger
