Strings In United Bot

[@$3.1415rin]

botman spoke

inheritance hasnt been added just for fun

I Read the source for the STL version of string. Its bulky! My String is lighter, faster and more robust. What do I do now?

[botman]

What problem are you trying to solve? Or is this just a learning exercise?

botman

Problems I am trying to solve:
1) STL Strings dont have advanced string search functions
2) STL Strings involve using the null character
3) STL Strings have confusing syntax (there are lengths with and without the null)
4)STL Strings are as prone to buffer overflows as are the C-Style Strings

Isnt it enough to warrant starting from scratch?
My Strings can:
1)Split
2)Find Strings ignoring case and punctuation or takign them into account if desired
3)Change Case Easily
4)Prevent Buffer Overflows
5)Be Easily tailored to needs
6)Compare, the Advanced way, taking into account or ignoring (if desired) Caps and Punctuation
7)Be Added
Output to string, C-Style Strings and individual chars
9)Dont involve the null. It is automatically handled
10)Length is always without the null

[sPlOrYgOn]

well in Bjarne Stroustrup's "The C++ Programming Language: Special Edition" on page 127 it says..

Originally Posted by Bjarne StrouStrup

you should measure carefully before believing that some piece of handcrafted code outperforms library functions

Yes you are probably right. I will measure it and then be back with the numbers

[botman]

You can almost always make something faster than what's provided in a standard library, but usually only for specific cases (i.e. you usually can't make something significantly faster that handles the same features that the standard library function handles, if you could, someone would have replaced the standard library function with faster code long ago).

Magnus, I think you are focused on a few issues with STL strings (such as using a null terminator or splitting a string) that you assume other people would want (when they might not need or care about those).

If you want to create your own string library then other coders are required to learn your syntax instead of using what they already know. It would be sort of like replacing the C++ stream I/O (cout, cin, cerr, etc.) with your own input/output library of functions because some of the stream I/O functions were slow or confusing.

I'm not sure that speed is that big of an issue for string operations unless you are doing LOTS of string operations very frequently. For something like a database application or a word processing application, string operation speed would be critical, but for something that's using mostly mathematical operations, string performance probably isn't that critical.

botman

Syntax is same. Just Go through it. You are right i am developing a specific version of this string: advanced tuncate, find delete functions that i think United Bot needs. If I can make it **suitable** can you use it in United Bot? If not, tell me, i will trash this project.

[@$3.1415rin]

if you want to speed up the main string operation, the comparision, you need hashtables anyway, so no difference here.

I somehow like STL stuff better, since it's for sure more stable and bug free. I dont wanna say that your code is buggy, but like botman said, the STL was already improved for some time, and it's just a fact that it's stable

ok thanks anyway.