gamedevlists-general

RE: [GD-General] Eiffel

[Tom H. <to...@3d...>]

At 12:58 PM 12/24/2001, Brian Hook wrote:
>It seemed to me that the bulk of your e-mail was raging against the
>notion of "debugging STL", I was merely stating that no one said as much
>(i.e. my complaints were on the "debuggability of programs that use
>STL").

My only problems with STL are:
1. Debugging code that uses it is ugly. Drilling into the containers and 
iterators to get at your data is cumbersome, and in some cases, impossible 
(can't think of an example right this second, but I seem to recall the 
overloading of -> operator to be a problem)
2. Compile time errors messages are so incredibly long and ugly that it 
takes ages to decipher what they're saying and what the proper fix is.

To solve #1 I've had to stop debugging, change the code to create a temp 
variable of the proper type, and run again. So far this hasn't been a huge 
problem since I've been able to at least get a workable solution in the 
situations I've run into so far, but if I ever have to deal with a hard to 
dupe bug, I'm going to be in hell.

#2 seems like it's mostly a debug environment issue that could be addressed 
with better tools.

I've been following this thread with great interest because I'm really not 
very happy with C++. It gets the job done, but it's an ugly bitch at times.

Tom

RE: [GD-General] Eiffel

[Brian S. <bs...@mi...>]

>> that's your baby.  But you can't argue that STL is badly=20
>> designed because Plauger's implementation does no input=20
>> validation or debug checking.  You might be able to argue it=20
>> from other standpoints, but not from that one.

> Which is good, because I don't think that's what I said =3D)

Just to set the record straight, you did say:

"Which is a pretty strong indicator that STL could use some tightening =
up
in its design or, alternatively, that implementation should provide
basic pre and post-condition checking."

I think I characterized that quite fairly, and as for the notion that my =
first email was "raging", well I'm not quite sure what to chalk that up =
to.  I actually thought that parts of it were amusing, and it was merely =
meant to relate my experience of watching people give up on STL after =
the briefest of encounters.  I thought my email might provide =
inspiration, or at least comfort, in the knowledge that programming with =
STL does actually improve with time (like so many other things).  I know =
that's an extremely wishy-washy position for me to hold.  As penance, =
I'm going to start a new thread with the subject  "STL: Rocks Like =
Slayer or Totally Sucks?" ;)

Happy holidays to all.=20

--brian

-----Original Message-----
From:	Brian Hook [mailto:bri...@py...]
Sent:	Mon 12/24/2001 12:58 PM
To:	gam...@li...
Cc:=09
Subject:	RE: [GD-General] Eiffel

> Near the end of your email, I think you made the right=20
> distinction between debugging STL (which I'm arguing is a=20
> distraction at best)

More generally, debugging a third party set of reusable code should be a
distraction at best.

> So - given that I was talking about debugging STL in that bit=20
> you excerpted - what's the contradiction?

It seemed to me that the bulk of your e-mail was raging against the
notion of "debugging STL", I was merely stating that no one said as much
(i.e. my complaints were on the "debuggability of programs that use
STL").

> lessons are deeply ingrained.  So since I never free things=20
> twice any longer, does that mean free() is badly designed?

Yes, in fact, it does.  The CRTL is not what I consider an example of
good library design.  A library that allows, for lack of a better
phrase, "intuitive but incorrect usage", is probably poorly implemented
(maybe not designed, but once again, I'm not against STL's design -- I
haven't used it enough to really judge -- but I am against the
implementations).

> that's your baby.  But you can't argue that STL is badly=20
> designed because Plauger's implementation does no input=20
> validation or debug checking.  You might be able to argue it=20
> from other standpoints, but not from that one.

Which is good, because I don't think that's what I said =3D)

> p.s. sorry if I got anyone's hopes up too high, the STLPort=20
> iterators do NOT actually use Mr. T voices.

Well crap, I guess I'm cancelling that download now.

Brian


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general