Jump to content

View more

Image of the Day

#ld38 #screenshotsaturday Mimosa Fizz action gif #2 https://t.co/TUzdppvfUL
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Why do large engines use their own string class

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Joshhua5   Members   


Posted 05 June 2014 - 09:24 AM

While looking through the CryEngine source code I found a file CryString.h



What I don't understand is why are they creating their own string class instead of using the std::string provided

are there benefits in doing so?

#2 KulSeran   Members   


Posted 05 June 2014 - 10:02 AM


1) looks like custom allocation (could be done with an allocator)


2) looks like most the copy functions don't actually copy data.  std::string is going to end up copying the data, because it usually doesn't know any better.  If you follow around the CryString header, it will AddRef in several places which results in _this_ string pointed to _other_ string without copying the underlying string data anywhere.  It's only on write operations where it will then say "oh, i'm a fake-copy" and finally allocate memory and do a real copy.  In theory, this could save you some memory.


3) A kinda important optimization I don't see in there, that would also be a good reason to have a custom string class is a replacement of substr.  There is often a need for things like "fileExtension = filename.substr(filename.lengh() - 3)"  which are clearly expressed with the intent of substr but are unfortunately non-optimal because it results in copied data.  Some code implements string "parts" that allow substr like functions to return <pointer, length> pairs that are read-only.  This allows you to do some heavier string processing without actually copying any of the base data, AND keeping the code clean.


4) older game platforms also had crappy std:: library support.  Depending on when they started working on their engine, this could be work-arounds for not actually having a working std::string on a target platform.  It would have carried through to their latest renditions even if std::string were equally performant now.

#3 L. Spiro   Members   


Posted 05 June 2014 - 10:08 AM


Most reasons explained here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

L. Spiro

#4 nobodynews   Members   


Posted 05 June 2014 - 10:12 AM

The big stuff I can see in their string class that doesn't exist in the std::string class is their class is reference counted and it has a lot of helper functions that don't exist in std::string, like comparisons that don't care about case. So they apparently felt the way std::string dealt with copying strings was too costly and they also wanted to perform a lot of actions that weren't built into std::string.

C++: A Dialog | C++0x Features: Part1 (lambdas, auto, static_assert) , Part 2 (rvalue references) , Part 3 (decltype) | Write Games | Fix Your Timestep!

#5 Promit   Senior Moderators   


Posted 05 June 2014 - 11:18 AM

It also uses a custom allocator (presumably without the psychosis of std allocator) and supports misc things like being constructed on top of an existing char*. When I see stuff like this, I'm reminded of a comment that appears in the Fluid Studios mmgr code: "Kids, please don't try this at home. We're trained professionals here." :)

Edited by Promit, 05 June 2014 - 11:19 AM.

SlimDX | Shark Eaters for iOS | Ventspace Blog | Twitter | Proud supporter of diversity and inclusiveness in game development

#6 achild   Members   


Posted 05 June 2014 - 12:51 PM

It's worth noting that even in this case it needs to be used with care.


If one assigns one CryStringT object to another (ref count is 2) and uses one of them in another thread, passing it along in some data structure or something, it can wreak havoc. It's not unreasonable to be responsible for protecting your own shared data, but the COW code is not thread safe either. I believe in the standard library 2 separate string objects are not supposed to have any hidden surprises like that (though it has been a problem in the past).

Edited by achild, 05 June 2014 - 12:53 PM.

#7 clb   Members   


Posted 05 June 2014 - 12:53 PM


In addition to the points mentioned above, I develop my own string class mostly because the std:: api is just plain stupid. I don't want to write over-verbose iterator madness or things like std::string::npos for operating the api. You can get a very good feeling of how obtuse it is to work with it when you search for most voted questions in StackOverflow related to std::string work: http://stackoverflow.com/questions/tagged/stdstring?sort=votes&pageSize=15 . With my own string class, I can make the functionality work as comfortably as I like. Compared to C#, JavaScript or Python, C++ has probably the weakest string api in existence.


C++11 improves handling of different unicode formats, but working with utf8/utf16/utf32 sources with just the std::string and std::wstring is a pain (see -fshort-wchar et al.). Having my own with explicit awareness for different encodings helps in my case.


Of course when you work on something like this, it should be associated with a good unit testing battery, and development will invariably take up time. It's not a "I'll just get it done in a weekend" type of project.

Me+PC=clb.demon.fi | C++ Math and Geometry library: MathGeoLib, test it live! | C++ Game Networking: kNet | 2D Bin Packing: RectangleBinPack | Use gcc/clang/emcc from VS: vs-tool | Resume+Portfolio | gfxapi, test it live!

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.