c++: c-strings vs std::strings ( same thing for vectors!)
Author
Why would someone prefer std::strings over cstrings in C++? Std::strings have more overhead than char*. Much more overhead. Allocate memory, allocate more memory and copy all the chars of the previous memory to it, deallocate the previous memory, do the same thing for a couple of times and deallocate the last memory you got. TOOOO much!! With c strings, you jut get your memory from your stack TOO fast, and that's all. YOu can also use memory from the heap IF you want, it's your choice.
Exactly the same thing goes with arrays and vectors, with the difference that now the overhead of vectors is much more than that of std::strings, because they usually hold OBJECTS ( apart from ints and doubles ).
And in game programming, performance is USUALLY everything.
Security is an isue, yes, but if you are a good programmer it shouldn't be a problem.
...
Not everyone writes games, but they generally have bosses who provide tight deadlines. That's why.
Have you done any testing of your own dynamic string / vector library vs. the std/STL versions that come with your compiler? How much faster are yours exactly?
Have you done any testing of your own dynamic string / vector library vs. the std/STL versions that come with your compiler? How much faster are yours exactly?
Quote:Original post by valla2
Security is an isue, yes, but if you are a good programmer it shouldn't be a problem.
What makes a person a good programmer?
1. ...
2. being immune to immense amounts of caffeine
3. ... (just some reasons including knowing how to learn from different resources and stuff)
4. to know whether the development time saving is worth much more than the very slight performance increase...
5. more stuff
I still use c strings a lot but only because I just switch to c++.
You can mess around with the c strings if you want but I guess it's not worth the time... I don't know many performance things where you need to use many strings... I use approximately 10 strings in my game. Most of them are in the menu and config load state and I don't think you need to take care of nanoseconds if you load a level or load the config file...?
std::strings are normal classes, rather than arrays [or pointers to arrays], and thus can be more easily returned from and passed into functions due to their difference how going in and out of scope effects them. std::strings allow for easier internationalization. Even good programmers are people, and make mistakes. std::string limits many of the possbilities for mistake.
You can just as easily store pointers in a vector. Once again, passing arrays to and from functions is painful at best. Passing vectors [or rather references to vectors] is not. Being restrained to fixed size arrays sucks in many ways.
Sure, good programmers -might- be able to write everything perfectly the first time through, but it's likely they won't. Spending time debugging is not fun, and prevents them from working on the -game-. Further, any major game these days [save Chris Sawyer's] is done by teams of programmers. Even if the good lead programmer gets it right the first time through, other likely less skilled programmers almost certainly won't when they modify the code for bug fixes or for their own modules.
Tracking down memory leaks or overflows is damned tedious, and generally difficult to reproduce. Saving that time means that programmers are suddenly free to do real optimization rather than saving a few cycles here and there for string allocation.
You can just as easily store pointers in a vector. Once again, passing arrays to and from functions is painful at best. Passing vectors [or rather references to vectors] is not. Being restrained to fixed size arrays sucks in many ways.
Sure, good programmers -might- be able to write everything perfectly the first time through, but it's likely they won't. Spending time debugging is not fun, and prevents them from working on the -game-. Further, any major game these days [save Chris Sawyer's] is done by teams of programmers. Even if the good lead programmer gets it right the first time through, other likely less skilled programmers almost certainly won't when they modify the code for bug fixes or for their own modules.
Tracking down memory leaks or overflows is damned tedious, and generally difficult to reproduce. Saving that time means that programmers are suddenly free to do real optimization rather than saving a few cycles here and there for string allocation.
Author
How about this?:
fair?
Put the timers and check the results.
struct Player {Player( int ii) : i(ii) {}int x, y, i;double health;long weapon;double wait;};.....vector<Player> vec:for ( int i=0; i < 500; i++ ) // while(user_hits_enter) vec.push_back( Player(i) );.....Player ar[500] = { 0 }; // before the game it's ok to wait, IF you are going to wait, but NOT in the game loop etci= 0;while ( user_hits_enter ){ ar = i+1; ++i;}fair?
Put the timers and check the results.
Your homework for tonight, valla2: explain why modern computer games are not written in assembly language (at least 5 reasons). Explain the process by which certain parts of a game eventually are rewritten in assembly, and how the decision to rewrite those parts is made. Explain how all this applies to std::string.
Quote:Original post by valla2
Exactly the same thing goes with arrays and vectors, with the difference that now the overhead of vectors is much more than that of std::strings, because they usually hold OBJECTS ( apart from ints and doubles ).
Why? What's the time overhead beyond the initial object construction? What's the space overhead beyond a few pointers?
Quote:And in game programming, performance is USUALLY everything.
Even in game programming, performance is not as important as correct execution, not to mention actually having a finished program to run.
Your two code blocks are not equivalent.
vector<Player> vec;vec.resize( 500 );//is equivalent toPlayer arr[500];//but is different fromfor ( int i=0; i < 500; i++ ) vec.push_back( Player(i) );//and you can allocate a memory block without invoking constructors like so:vector<Player> vec;vec.reserve( 500 );
Author
Quote:Original post by Sneftelassembly requires time.
Your homework for tonight, valla2: explain why modern computer games are not written in assembly language (at least 5 reasons). Explain the process by which certain parts of a game eventually are rewritten in assembly, and how the decision to rewrite those parts is made. Explain how all this applies to std::string.
cstrings and std::strings are pretty much equal here
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement