Jump to content
  • Advertisement
Sign in to follow this  

Why would you program your own string class?(C++)

This topic is 4722 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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!

Share this post


Link to post
Share on other sites
Hi

I think a lot of projects use older base code to work with and porting old code to use a new string class is a lot of work and actually of no use in most cases


also a lot of people aren t used to STL although you can consider it standard nowerdays


another thing to mention, you can replace the STL coming with the vc++ compiler
or just use the gcc compiler Mingw for windows


i personally stick with STL because i set on reuseability

Share this post


Link to post
Share on other sites
After learning a bit about standard string, I actually was suprised by its lack of functionality. stringstream allows for more functionality, but has its own series of quirks and limitations.

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.

I imagine the original reasons were not so noble though.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Jiia
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.


Despite the fact that linked lists -are- the main place where I've "re-invented the wheel", I still use std::list in places. It's better at doing things within the context of the data it contains.

And the use of homegrown linked lists is the classic example of people re-inventing the wheel for no good reason. In the majority of cases, a linked list is one of the worst container classes the programmer could've chosen.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!