Looking through the source of several open-source projects like Crazy-Eddies-GUI, Irrlicht etc. I have seen that most of these projects have their own string class. Why does they have this? I think it would be very hard to beat the STL one in performance. So why does they do it? Because some compilers(VC6 for example) doesn't have a good STL? or because they think they can do it better?

Good question! It seems like the "thing to do" on these boards is to reinvent the wheel and try to rewrite STL containers etc! And not for educational purposes either, that might actually be legitimate. Instead, people feel like they can come up with something better/faster, but what the write is of course non-standard so other people will have to learn how to use their damn code, rather than just look at it and immediately know how to use it.

Yay!

The C++ string class lacks a lot of the niceties of strings in other languages, such as Python or Java. So it might be beneficial to write your own to overcome that. I have a project that uses my own string class, but I did implement it in terms of std::string.

Quote:Original post by Telastyn
Add to that the fact that many libraries require [non-const] char arrays, it's a pain at times to use standard strings properly. So I can see where people might be tempted to rewrite a string class.

If its a C++ library and it requires char * as strings instead of taking std::string & I'd consider the library broken.
If its C library or an interface to another language I'd just write a small amount of glue code to get around the problem.

Quote:If its a C++ library and it requires char * as strings instead of taking std::string & I'd consider the library broken.

While I appreciate the point in context, I have to take issue with that. One of the tenets of C++ is 'only pay for what you use'. Why should an interface force someone to use a class which requires dynamic allocations? What if the user wants to pass in a string in a string table? How about a string literal? You may also have to deal with different allocators, multithreading, etc. What someone wants to use your library on a platform without a std::string implementation, or with a broken/different one?

I use std::strings extensively, but like any other piece of code, there are tradeoffs to using them. Lets not let use of std::strings become dogma. There are very legitimate reasons to both use them and to avoid them, particularly in interfaces.

It's nice to have any feature you can think up in your system. It's nice to be in total control. String classes are very simple, though.

What about linked lists? Does anyone actually use the STL implementation? From what I understand of it, it can be extremely inefficient when working with big lists. Something about trying to move from node to node without an iterator.

Quote:Original post by BrianL
While I appreciate the point in context, I have to take issue with that. One of the tenets of C++ is 'only pay for what you use'. Why should an interface force someone to use a class which requires dynamic allocations? What if the user wants to pass in a string in a string table? How about a string literal? You may also have to deal with different allocators, multithreading, etc. What someone wants to use your library on a platform without a std::string implementation, or with a broken/different one?

I use std::strings extensively, but like any other piece of code, there are tradeoffs to using them. Lets not let use of std::strings become dogma. There are very legitimate reasons to both use them and to avoid them, particularly in interfaces.

True, however the fact its a non-const char * implies that the string is going to be changed (and probably require reallocation of memory 'somewhere'), this brings up a whole host of issues ranging from when and where the memory is allocate to possible ownership issues.
So, while there might well be locations where a char * is required I'd argue that in the majortiy of cases a std::string & will serve you alot better.

Its all very well saying 'only pay for what you need', yet there is very very little difference in cost between a char * and a std::string &, both require dyamnic allocation 'somewhere', the difference between them is that std::string is alot safer.

As for your examples;
- a string table I'd probably impliment in terms of std::strings anyways
- string literals arent related to this really as char * implies memory which can be changed, literals are char const * const (or something like that) and thus shouldnt be reallocated or changed anyways.
- allocators might be a point, in that case you can fall back to std::strings parent class
- MT again might be a point but alot of libraries make no promises about thread safety anyways
- A platform without std::string is probably going to be too old to worry about and not C++, thus this is a non-problem. Plus you can install the std. lib. on old C++ compiles anyways (STLPort for example) and they shouldnt be 'different' as std::string is standard as is its interface, any changes make the platform broken (unless the standard changes) and thus not a library problem as it will be designed to conform with standard C++, not some broken system.

edit:
also, by using a char * the library in question is forcing me to adapt my program to its useage (while being unsafe at the same time) I'd consider that less acceptable than the library having an interface which uses safe and modern C++ constructs.

Also, on the topic of reinventing the wheel, the worse bit of all of these 'string' classes is that they probably arent compatible with each other, so you have to convert left, right and center to work with them if they are required for different libraries, where as if everyone had stuck with std::string all would have been good...