![]() |
Re: Strings In United Bot
botman spoke :)
inheritance hasnt been added just for fun :D |
Re: Strings In United Bot
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?
|
Re: Strings In United Bot
What problem are you trying to solve? Or is this just a learning exercise?
botman |
Re: Strings In United Bot
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 8)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 |
Re: Strings In United Bot
well in Bjarne Stroustrup's "The C++ Programming Language: Special Edition" on page 127 it says..
Quote:
|
Re: Strings In United Bot
Yes you are probably right. I will measure it and then be back with the numbers
|
Re: Strings In United Bot
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 |
Re: Strings In United Bot
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.
|
Re: Strings In United Bot
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 |
Re: Strings In United Bot
ok thanks anyway.
|
All times are GMT +2. The time now is 15:42. |
Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.