Re: [GD-General] Compile times

[Jesse J. <jes...@mi...>]

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