Printable View
I'm building a custom string class, and I'm wondering what operators I should overload, and what other functions should I implement? I already have overloaded =, +, +=, >>, <<, >, <, ==, >=, <=, and !=. I also have functions to return the length of the string, both with and without the null terminator. So what else should I use? I plan to bring in functions such as insertion, erasing, replacing, and subscription. Thanks for ideas / suggestions :D !
- copy constructor
- reference counting
- C-string access
- tokenizing
- printf style formatting
- searching
- uppercase/lowercase,
- case insensitive comparisons
- custom buffer management (capacity(), resize(), etc...)
- wide character support (wchar_t) (via templates?)
gg
>Thanks for ideas / suggestions
Any useful feature that cannot be separated from the string class. You'll notice that std::string is bloated because this was not done. We suffer because of poor design decisions.
>- copy constructor
Yes.
>- reference counting
Not necessary, but useful.
>- C-string access
Do you mean like c_str(), or something else?
>- tokenizing
Why should this be a part of the string class? Tokenizing is altogether separate from internal string operations.
>- printf style formatting
For what exactly?
>- uppercase/lowercase
A container shouldn't need to worry about the data that it holds. Also, what about locale specific character sets? How can you as the designer of a class know what upper and lower case means to every single client? Better to separate character traits from the string as well.
>- case insensitive comparisons
Once again, there are issues concerning what case is. If you separated character traits from the string class to begin with, a string can be created with a locale specific case insensitive character type. This solution is cleaner and far more robust.
- custom buffer management (capacity(), resize(), etc...)
This might actually be better in a high performance offshoot of the string class lest it cause clutter, but that is a borderline decision that depends on how the general class is to be used, generally.
>- wide character support (wchar_t) (via templates?)
Once again, separating character traits from the string solves your problem quite nicely.
A substring function would probably be useful. Other than that, keep it simple.
If you need a lot of functions to manipulate strings, consider separating them out and just using your set of primitive operations on the string.
Prelude, would you be able to explain what an "locale specific case insensitive character type." is?
thanks, subdene.
- copy constructor
Got it.
- reference counting
Not quite sure what that is - can you refresh me :D ?
- C-string access
I have operator char *
- tokenizing
- printf style formatting
- searching
- uppercase/lowercase,
- case insensitive comparisons
Basically same answer as prelude
- custom buffer management (capacity(), resize(), etc...)
Possibly, that might be an option.
- wide character support (wchar_t) (via templates?)
Same answer as preludes
I know exactly what you mean. What would you suggest taking out of std::string? Maybe my class will turn out better than Standard C++'s is :D .Quote:
Any useful feature that cannot be separated from the string class. You'll notice that std::string is bloated because this was not done. We suffer because of poor design decisions.
By the way, would a operator-(string s) be good to remove all instances of s from the string? Thanks again :D !
>Prelude, would you be able to explain what an "locale specific case insensitive character type." is?
Basically, a call to setlocale and normal tests with toupper and/or tolower. :)
>What would you suggest taking out of std::string?
http://www.gotw.ca/gotw/084.htm
>would a operator-(string s) be good to remove all instances of s from the string?
No. I don't know of any previous use in such a way, so you would only confuse people.
Ugh, I feel like I'm spamming, seeing a new question and posting again to answer it. A pity edit doesn't allow you to easily cut/paste from the rest of the thread. ;)
The string is only destroyed when there are no more references to it. This gives you opportunities for optimization like having objects with the same string to point to a single object. Then if you need to modify one of them but not any of the others, you can give that reference its own copy of the data, this is called copy-on-write semantics. Look up Effective C++ and More Effective C++ for detail.Quote:
- reference counting
Not quite sure what that is - can you refresh me ?
Beware, this conversion may be performed when you don't expect it. There is a good reason the standard library chose to use c_str() instead of operator const char*().Quote:
- C-string access
I have operator char *
I figured as much, thanks. Can you explain reference counting? It sounds familiar, but I can't place it.Quote:
Originally posted by Prelude
>would a operator-(string s) be good to remove all instances of s from the string?
No. I don't know of any previous use in such a way, so you would only confuse people.
EDIT: Nevermind, thanks for spamming :D .
I know, but it also has many advantages along with it.Quote:
Beware, this conversion may be performed when you don't expect it. There is a good reason the standard library chose to use c_str() instead of operator const char*().
Is this the Effective C++ you are talking about?
>I know, but it also has many advantages along with it.
The advantages are quiet, which means the disadvantages are too. It is better to have disadvantages that slap you in the face instead of sneak behind you. ;)
>Is this the Effective C++ you are talking about?
Yes.
My advice would be to stay away from reference counting and copy on write. Both have issues and neither of them are efficient in multithreaded usage. If writing a string class try the small string optimisation first. Thats where your member is a union with two members. A fixed size charT array and a charT pointer. If the string has length less than some default value ( 16-32 bytes reasonable) it can be stored within the string objects char array. If the string is too long for that you instead write it into dynamic memory and set the charT* to point to it.This allows for less dynamic allocations and is much more multithread friendly and worth consideration before you start planning.