Re: [GD-General] Compile times

[Tom S. <to...@pi...>]

> For C++, unless you want a base root Object class, there's no
> alternative, since STL is templatized and gives you the static type
> checking that many feel is so vitally important.  But in more dynamic
> languages such as Java (*shudder*) and Objective-C, the core container
> classes operate on base Objects and everything still manages to work
> just fine.

    You've traded static compile time error detection for runtime
exceptions.  I can't see that making your game more robust or your test loop
any quicker.  Tom

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Monday, December 09, 2002 4:38 PM
Subject: RE: [GD-General] Compile times


> > [to build the full Quake 2 source code]
> > > Let me repeat: 37 seconds.
> >
> > Wow, that's really the way it should be. I'm going to have a
> > hard look at our build environment and try to significantly
> > reduce our build time.
>
> The amusing thing, of course, is that the times I've mentioned this,
> it's poo-pooed that the Quake2 and Quake3 stuff wasn't very
> technologically advanced.
>
> > What are the alternatives other than rolling your own?
>
> Rolling your own? =)
>
> For C++, unless you want a base root Object class, there's no
> alternative, since STL is templatized and gives you the static type
> checking that many feel is so vitally important.  But in more dynamic
> languages such as Java (*shudder*) and Objective-C, the core container
> classes operate on base Objects and everything still manages to work
> just fine.
>
> > Along with:
> > - Lots of debugged code already written
> > - Already quite optimized
> > - Type safety
> > - Familiarity of new programmers with that API
> > - Other APIs build on top of it (boost for example)
>
> I can agree that the above are valuable, but in my experience, those are
> close to non-factors when compared to the cost (again) of using STL.
> Now, I tend to work on small teams -- 3 programmers at id, one
> programmer at my current gig.  So I do have a procedural advantage right
> there.
>
> In most cases, if a container class is showing up as a performance hit,
> my guess is that I'm either doing something wrong or, more likely, I
> need to optimize it beyond what is already done in STL.  But I don't
> have anything to substantiate that, so it's neither here nor there.
>
> > The counter argument of "how long does it take to write a
> > linked list" is totally convicing either. How long does it
> > take to write an efficient balanced red-black tree? Can you
> > write them so it is possible to change the way memory is
> > allocated easily? Can you write them so they can be reused
> > for different types and not make extra memory allocations?
>
> Even if I never, ever re-use any of my list or hash code,
> re-implementing from scratch is almost never a problem.  It's not like I
> have containers littered about so much that I need the absolute best,
> most generalized implementation available at all times.  I know that's a
> philosophical shift from what many believe in these days, but I almost
> never, ever have to implement radically specialized data structures.
> Every day, easy-to-write stuff like lists, maps, sets, etc. are
> basically all I ever use.  And when I start getting into more exotic
> data structures -- BSP trees, quad-trees, oct-trees -- then STL isn't
> going to help.
>
> Maybe that's a good summary -- for the things that STL can help with,
> rolling my own consumes almost zero time.  It's probably 15 minutes to
> write a simple binary tree implementation from scratch.  I spent more
> time writing this e-mail =)
>
> For the things that really need an optimized implementation, odds are
> it's a data structure that STL just doesn't understand.  So STL -- for
> me -- falls exactly in that area of being a non-issue.
>
> As a library for the masses, it's great, because it does a little bit of
> everything well, in a documented fashion.  But when it gets down to
> brass tacks for _one project_ I think the value plummets.
>
> But I do recognize I'm singularly alone on this.  I also recognize that
> I have 5 second compile and go times as well. =)
>
> > Just out of curiosity, what are you developing in these days?
> > Light C++, or straight C?
>
> Both, although frankly I wish I had just stick with pure ANSI C, since
> it compiles and runs in a much cleaner fashion.
>
> My core frameworks are 144 header files and 187 source files that cover
> a wide variety of platforms, and while the hierarchy started out clean,
> it has since become a mess because code just has a habit of growing,
> changing and morphing over time.
>
> And C++ hierarchies, to coin a phrase from Scott Bilas, tend to "harden"
> over time.  The more interdependent your class trees get via
> inheritance, delegation, aggregation, etc. the more difficult it becomes
> to refactor your existing code because the chain of dependencies grows
> longer and longer with time.
>
> The code base becomes resistant to change.
>
> All my new libraries are written in ANSI C, because many of them I plan
> to release as open source.  But in the process of writing them in ANSI C
> and acutely examining the dependencies that existed, I found that I was
> writing MUCH cleaner code, and not just because I expected others to
> read the code.
>
> Application frameworks are great for writing applications, but I think
> they're also extremely cumbersome and dangerous when trying to write
> libraries or allowing the reuse of code in a piece-meal fashion, which
> is often extremely handy.  I've been frustrated at times because I'll
> write a simple command line app that I want to give to someone, but it
> uses one tiny little class out of my frameworks, and now suddenly I have
> to hand over megabytes of source code so someone can compile a 10 line
> program.
>
> I believe strongly in using C++ as an application language, but for
> libraries, I think ANSI C is probably superior for many reasons.
> Frameworks make sense for developing entire apps, but by their very
> nature they're incredibly difficult to partition and release in pieces.
>
> Code reuse introduces dependencies, and dependencies work directly
> against refactoring code cleanly.  I'm not against code reuse, but it's
> worth pointing out that the more code is reused, the harder it is to
> change or improve.
>
> Brian
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>