Re: [GD-General] Compile times
Brought to you by:
vexxed72
From: Jesse J. <jes...@mi...> - 2002-12-17 12:03:16
|
At 11:46 AM -0600 12/16/02, brian hook wrote: >Every time you call "new" or "delete" or return a pointer or accept a >pointer, it should set off alarm bells immediately. It should mean >that you need to stop and document what you're doing. It should mean >that you should take the time to make a Doxygen or similar style header >that defines exactly what you're doing. You should decide what >preconditions, postconditions and invariants need to be defined and >adhered to for your particular class or function. Pretty much. And that's the problem with what you're suggesting: it requires careful analysis of ownership issues and accompanying documentation. Whereas a smart pointer side steps all of these issues and AFAICT has no real drawbacks. >I hesitate to call my coding style "XP" since that's so overused, but >basically one reason I'm drifting away from large C++ frameworks is >that you almost never, ever get it right the first time. Or the second >time. Or the third time. The ability to abstract and refactor >iteratively is immensely powerful, but C++ code bases have a tendency >to build up resistance to fundamentaly change, making these changes >difficult to do. Part of this is the fault of tools, obviously. Frameworks don't have to have deep hierarchies or a zillion classes. But they do require some experience and knowledge of OOD. I'm confident that a skilled OO designer would have an easier time iterating classes than an equivalent C programmer evolving C code. >And honestly, dynamic memory allocation is so rare (at least in my code >base, because I abhor fragmentation) that it's not like I run into >these problems multiple times a day. That's a big difference. I, at least, use dynamic allocation a lot and I'd expect (naively?) that a lot of PC games do as well. -- Jesse |