RE: [gtkmm] Talk about a major rewrite



> -----Original Message-----
> From: gtkmm-list-admin gnome org 
> [mailto:gtkmm-list-admin gnome org]On Behalf Of P. Christeas
> Sent: quarta-feira, 31 de Julho de 2002 14:14
> To: murrayc usa net
> Cc: gtkmm-list
> Subject: Re: [gtkmm] Talk about a major rewrite
> 
> 
> 
> > > At this point of discussion I don't expect to look into 
> the code. That's
> > > why I don't refer to particular bugs. My questions are:
> > > - do the design pitfals constitute the need for a re-design?
> >
> > What design pitfalls? Give us specifics.
> 
> [flame-starter..]
> I personally avoid stl. It introduces too many code lines for 
> the simplest 
> things. The compiler then is pushed and more likely to 
> mis-interpret things 
> (the gcc 3.1 problems etc.). Moreover, the core code is less 
> human-readable.


STL is here to stay. It is part of the standard and C++ developers
should make the best use of it.

Just see what boost is doing (www.boost.org) and what is the
standard practice among professional C++ developers (www.cuj.org).

And view the current trend in books, especily from Andrew Koening
and Scott Meyers.
 

I for one, praise the use that gtkmm makes of STL.

> One more thing is that of iterators. By referring to an 
> object with its 
> pointer, bad coding results in havoc. One example is when I 
> deleted an object 
> and the iterator was still around. It is very diffficult to check the 
> consistency of data holded by pointers. On the other hand, 
> integer indexes of 
> C lists are easier to debug. Giving a bad index can be 
> recognized at once. 
> Indexes are slower, but much safer. It will be the app's 
> fault when such a 
> thing happens, but the API must indicate the trouble.

It is somewhat reasonable. Must you shouldn't delete objects
that still have iterators pointing to them. As with all memory
management cases, YOU are responsible to ensure that
all references to something are no longer pointing to it before
deleting it.
 
--
Paulo Pinto



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]