 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic Page: 1 2 »» |
Last Thread Next Thread |
| Using Modern C++ to Eliminate Memory Problems |
|
 |
randomZ Member since: 8/17/2002 From: Germany |
|||
 Posted - 10/26/2003 4:46:30 AM |
||||
| About std::vector and bounds checking: I'm sure many people know this, but the [] operator of vector doesn't perform bound checking, but the at() member function does. So the [] operator really should be as fast as array access. --- Just trying to be helpful. Sebastian Beschke Just some student from Germany http://mitglied.lycos.de/xplosiff |
||||
|
||||
|
deepdene Member since: 3/12/2001 From: Australia |
|||
|
Posted - 10/26/2003 7:53:03 AM |
||||
Thats one of the advantage of using the iterators. Because you are checking against the iter != container.end() it can't go past the end of the container. And because you're only checking against an variable it's still speedy.quote: [edited by - deepdene on October 26, 2003 8:10:08 AM] |
||||
|
||||
|
noVum Member since: 5/23/2002 From: Germany |
|||
|
Posted - 10/26/2003 8:00:39 AM |
||||
| The whole C++ standard library is written for speed instead of safety per default. |
||||
|
||||
|
Seriema Member since: 6/15/2001 From: Stockholm, Sweden |
|||
 Posted - 10/26/2003 8:40:49 AM |
||||
| "The whole C++ standard library is written for speed instead of safety per default." Isn't the whole language (the idea behind it) like that? anyways! nice article! I've read Effective C++, More Effective C++ and Effective STL so those things weren't new to me. But it's still great that it's out there so more newbies can catch on a little  one thing though Ex. 4 - the dread sprintf() you forgot to mension the nice stuff that happens if you say you're gonna send an int and then send a float, like this sprintf(s, "%d", 1.0f); which the std:streams don't have a problem with.. good work! hope to see more  }-- Programmer/Gamer/Dreamer --{ |
||||
|
||||
|
dmikesell Member since: 8/14/2003 From: Westerville, US |
|||
|
Posted - 10/26/2003 9:46:17 AM |
||||
quote: Yes, type-safety is another advantage of string streams over sprintf! Good catch. Thanks for the kind words - glad you enjoyed the article. -- Dave Mikesell Software & Consulting |
||||
|
||||
|
Ronin Magus Member since: 5/30/2002 From: Franklin, USA |
|||
|
Posted - 10/26/2003 10:52:58 AM |
||||
| Very nice. I picked up a few tips, thank you mucho! Esp. the tip on declaring but not implementing copy/operator== functions. I knew the trick on making them private, but not implementing them, too is an even better method. daveandrews.org - a Christian Programmer's Weblog |
||||
|
||||
|
thedo Member since: 11/1/2001 From: Gillingham, United Kingdom |
|||
|
Posted - 10/26/2003 3:32:09 PM |
||||
| Great article. Knew most of it, learnt a little :D. Is bookmarked as a good refernce article Neil WHATCHA GONNA DO WHEN THE LARGEST ARMS IN THE WORLD RUN WILD ON YOU?!?! |
||||
|
||||
|
Penance Member since: 5/15/2002 |
|||
|
Posted - 10/26/2003 5:21:20 PM |
||||
| Ditto. Knew alot of it, learned some things I didn't. Great article, good job =) Especially good for people new to C++ or unfamiliar with how it's "supposed to work" |
||||
|
||||
|
AikonIV Member since: 2/11/2003 |
|||
|
Posted - 10/26/2003 6:06:16 PM |
||||
| Good stuff =) This stuff is known (and used most of the time) by me, but newbies should find this really helpful. Keep up the good work! I'm sure some time in the future you could write a second part with some more advanced stuff. |
||||
|
||||
|
Rompa Member since: 10/26/2003 |
|||
 Posted - 10/26/2003 9:37:36 PM |
||||
| The tips mentioned in the article definitely apply to generic C++ programming - and indeed games tools fall into this category. I strongly oppose the suggestions for runtime game code, however, and have recently been through this at work. We found that STL has had such a performance impact (even when used properly) that we've actually banned it from production code. For PC only coding we might have let it slip, but definitely OUT for console work. Sorry, just had to voice my opinion on this particular issue, as it is so relevant to my full-time work as a game programmer. [edited by - Rompa on October 26, 2003 9:38:45 PM] |
||||
|
||||
|
haro Member since: 3/30/2002 |
|||
|
Posted - 10/27/2003 4:02:49 AM |
||||
| Well written and interesting article. I also completely disagree with everything in it. The STL is useful for some things but by no means an exclusive replacement for 'legacy style' code as you would call it. The STL overhead is by no means negligable. In fact, in development cycles when your compiles are not optimized/release versions the STL can send your performance spinning down the drain about as fast as anything. The overhead in final release/optimized builds is less, but it never goes away. The reason I disagree with this article is simply because of dogmatism. The STL and "modern C++" are tools, not rules. An intelligent developer would be the one who has intimate knowledge of "modern C++" as you call it, as well as "legacy style code" and is able to use each where they belong. For example, in the code sample you gave where the problem was that the code was returning a pointer to a block of data allocated on the stack, so your suggestion was to use a string instead. This works but the way you designed the code, that string is going to be COPIED and dumped countless times. A more logical way may have been to simply used an allocated static block of memory and returned a constant pointer to that memory if you needed to insure stability between calls..
const char* getName()
{
static char name[256];
strcpy( name, "...." );
.....
strcat( name, "...." );
return name;
}
Simple and safe 'legacy' code. In coding, ignorance is not bliss, and people should make it a point to be aware of most of all reasonable and logical alternatives to common tasks. Dogma = BAD. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 10/27/2003 4:23:57 AM |
||||
| Interesting article with some really good tips. Short and informative - the way i like it. @rompa: Indeed the STL is not designed for applications, which needs the last cpu-cycle. But its suitable in many, many cases. It is only one - but for me very important - fact, that makes me really angry using the STL. WHENEVER there is something going wrong, whenever i do not really know, why this iterator is invalid, whenever i ask, if i should delete always the first element or all of them in order... i take a look at the source code of the STL... and the headaches starts Never seen such code pieces around the world. Never seen such crude and abstruse ideas. Never i will spent my spare time with trying understanding this area complete. Nonetheless: IF it runs, it is a big advantage in every programming parts.@Dave: What i am missing in the article is one of the bigger memory problems, when programmer uses the STL - it is the place of reading resources of unknown count and unknown length from a stream (independent from the location). The question, WHERE to allocate the reading buffer (stack, global mem) or even use a static buffer of the most lenght size. The question, HOW to transport the data out of the reading function. The question, HOW i can use the STL in such a place. The last half year i am using the ATL 7.0 library for such things - especially the CAutoVectorPtr template. I have the source code, the lines of code are not too long, it is simple, it is fast and it is easily adaptable. And so i can work =Cy= |
||||
|
||||
|
dmikesell Member since: 8/14/2003 From: Westerville, US |
|||
|
Posted - 10/27/2003 6:48:10 AM |
||||
| The examples in the article were admittedly contrived. The article was an exercise in how to avoid common memory problems (the kind that are asked about daily on this site), not how to write the tightest game code possible. Like everything in programming (life?), you have to balance the tradeoffs, but I hope you profile the code first before deciding it's too slow. But by all means, if the STL is not right for your application, don't use it. Thanks for all the feedback, positive, negative, and otherwise. It will all help me with my future articles! -- Dave Mikesell Software & Consulting [edited by - dmikesell on October 27, 2003 7:42:38 AM] |
||||
|
||||
|
ares32585 Member since: 6/6/2002 |
|||
|
Posted - 10/27/2003 12:49:58 PM |
||||
quote: Amen. [edited by - ares32585 on October 27, 2003 1:12:44 PM] |
||||
|
||||
|
Anonymous Poster |
|||
 Posted - 10/27/2003 4:15:45 PM |
||||
| Great article! One thing you perhaps should have done is check for self-assignment in operator=. |
||||
|
||||
|
Rompa Member since: 10/26/2003 |
|||
|
Posted - 10/27/2003 9:27:01 PM |
||||
quote: I agree completely. STL has _constantly_ appeared in our game profiling, but don't get me wrong - we actively encourage its use in our tools. We decided that instead of constantly being reminded that STL is slow, we simply don't use it. Whenever we have the need for a container class or whatever that STL could provide, we roll our own. Its _always_ faster, conforms to our coding standards, doesn't fragment memory etc. so we're happy. By my initial reply I just meant that using STL can cause more troubles than not, so use it where appropriate - and seeing that this is a gamedev site, I thought it appropriate to share my experience in that capacity, for what its worth. |
||||
|
||||
|
petewood Member since: 3/5/2002 From: Bristol, United Kingdom |
|||
|
Posted - 10/28/2003 3:50:59 AM |
||||
quote: That's an optimisation. If your program 'requires' the check then you will possibly have problems with exception safety. See this link with comments from Jim Hyslop |
||||
|
||||
|
DerekSaw Member since: 11/26/1999 From: 5-Claw, Dragonland |
|||
|
Posted - 10/28/2003 8:16:47 AM |
||||
... static char name[256]; ... Be very careful when using static locals in function. Especially on multithreaded apps. [edited by - DerekSaw on October 28, 2003 8:20:41 AM] |
||||
|
||||
|
dmikesell Member since: 8/14/2003 From: Westerville, US |
|||
|
Posted - 10/28/2003 10:11:52 AM |
||||
quote: Besides thread safety concerns, why else would you want to avoid local statics? -- Dave Mikesell Software & Consulting |
||||
|
||||
|
ctechie Member since: 9/28/2002 From: USA |
|||
|
Posted - 10/28/2003 1:38:04 PM |
||||
| Great article. The ctor/dtor resource handling has saved me lots of grief - especially with MFC GDI objects. (i.e. select object) One nitpick, tho' - Looks like the assignment operator for the Matrix class is leaking memory... It is not deleting the memory before assigning the newly returned ptr to memory. |
||||
|
||||
|
dmikesell Member since: 8/14/2003 From: Westerville, US |
|||
 Posted - 10/28/2003 2:25:55 PM |
||||
quote: Nitpick nothing, that's a bug! Good catch. -- Dave Mikesell Software & Consulting |
||||
|
||||
|
Rompa Member since: 10/26/2003 |
|||
|
Posted - 10/29/2003 5:27:35 AM |
||||
quote: There's one performance related reason (on frequently called functions) that you should avoid local statics (an uninitialized array should be okay), and that is that the compiler actually generates code that reads something like 'if object is not created, then create it' This testing and branching can be enough to show up on a profile for very frequently called functions, though on CPUs with decent branch prediction it shouldn't be too much of a drama... If it makes the code clearer, easier to maintain and it doesn't show up on a profile, I say go for it :-) |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 10/31/2003 5:07:48 PM |
||||
| Sane article but as another poster pointer out, stl is not a favourite for consolecoding. we had a problem recently with the stl deque class just not working on the ps2 (in a redundant piece of code that was thrown away pretty quickly). for strings and other lowperformance work having a good stringclass is a good rule, last week i spotted a new favourite. FunctionThatCopiesAString(char *bla) { char *newString=new char(sizeof(bla)); // <- "4bytes should be enough for any string" strcpy(newString,bla); } memory fragmentation is another annoying issue, but that's another story. / Jonas Lund |
||||
|
||||
|
jmmolina Member since: 1/10/2002 From: Lyon, France |
|||
|
Posted - 11/1/2003 8:51:52 PM |
||||
| Hi, Very interesting article. I already know STL and "managed C++" but articles about these topics are always welcome, specially on gamedev.net. <SPAN CLASS=smallfont>quote: Well I already worked on a few games and in some way or an other we always used STL. On PSX we implemented our own way to handle objets properly, to avoid memory leaks, share common containers for all our developers, on PC our project manager had that crazy idea to implement its own STL (what about deadlines ? duuu ^^)... We couldn't affort using "good old C coding style" : impossible to maintain code on large projects when working with many developers, can't control memory allocations, can't control the way each developer "implements" its own way to deal with strings, new/delete, etc... So even if you don't want to use STL, for the performance issue you mentionned (I doubt STL is that greedy, like Dave said, use a profiler and see how your IA or 3D routines are greedy), in all projects you should use your own STL : C structures with a bunch of functions, pure C++ containers with get/set and all "modern C++" stuff, etc... Anecdote : I used to develop using my own STL implementation... Wait I didn't even know what STL was :). However It worked well and I learnt a lot about algorithms and data structures. So in some way It's a good thing to reinvent the wheel. But when it came to work as a team (cost, delay, dead lines...), not the poor lonesome coder I was, we agreed that STL was the way to go. Even if it took 5% of our cycles... Greedy STL :) [Edited by - jmmolina on April 7, 2009 9:51:02 AM] |
||||
|
||||
|
Page: 1 2 »» All times are ET (US) |
Last Thread Next Thread |
|
