Re: [GD-General] Compile times

[brian h. <bri...@py...>]

> You've said something similar to the "proper discipline" comment 
> several times now, and I think you've got a blind spot going on here. 

It's not a blind spot, it's called wishful idealism =)

> If you're coding by yourself, personal discipline is all you need. 
> But if you're coding on a team, you have to have discipline that 
> applies to everyone on the team.

Yes.

> And not everyone is a coding machine.

Don't have to be a machine, just have to be careful and thoughtful.

> Not everyone works on all the code all the time.

They don't have to.

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.

I don't think this is too much to ask.  No one is in such a hurry that 
they can't take a minute to think about and write down the assumptions 
about allocation, ownership and referencing for memory they're dealing 
with.

Now, don't get me wrong, my code isn't perfect in this regard, but I'm 
generally aware of where things are sloppy and when/how I need to fix 
them.  I write code in an iterative fashion, and I comment the hell out 
of it when I need to fix something later.  In fact, my code has 
probably gotten an order of magnitude better now that I'm going back to 
more ANSI C style of coding.

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.

> The old "He allocated it but *I* need to free it" is one example of 
> the problem.

But that's a trivial problem.  Ten years ago Taligent defined a set of 
naming conventions to indicate responsibility for creation, 
destruction, referencing, etc.

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.
 
> And some of the stuff you've dissed lately -- wrapping allocations in 
> smart pointers, typesafe containers, and so forth -- are useful in 
> almost direct proportion to the number of people working on the code. 

Maybe vast team size is a mitigating factor, but I still can't help but 
feel that when this is used as an excuse it's because:

- there is poor communication

- the individuals that make up the team aren't as good as they should 
be because of the required size of the team

I don't believe in trying to solve the above problems (poorly) by 
introducing a degree of non-determinism in my code (smart pointers), 
encouraging lazy and lack of thought (smart pointers), and increasing 
my build times by a factor of 100 (STL).

> It lets me think at a higher level.

Thinking about low level details is not mutually exclusive with 
thinking at a higher level.  In fact, I would argue that routinely 
discounting the former affects the latter.

Brian