From: Christian Biesinger (email@example.com)
Date: Sat May 11 2002 - 18:02:40 EDT
On Sat, May 11, 2002 at 11:28:39PM +0200, Joaquín Cuenca Abela wrote:
> On Sat, 2002-05-11 at 16:55, Christian Biesinger wrote:
> > On Sat, May 11, 2002 at 01:27:21PM +0200, Joaquín Cuenca Abela wrote:
> > > UT_Map destructor should not be virtual (it was not virtual in the
> > > beginning on purpose). Consider it a "final" class.
> > Why that? Being able to override the constructor would make some things so
> > much easier.
> sadly, sometimes the easy way is not the right one. This one is just
> one example.
> > Is the overhead of the vtable so bad?
[detailed explanation snipped]
>In short, your class _IS_NOT_A_ UT_Map, because it's false that
> "everything that it's true for a UT_Map, it's also true for a
> UT_OwnMap". And thus you should not use public inheritance to model the
> relationship between UT_OwnMap and UT_Map.
OK... that sounds sensible.
> Anyway, you have a genuine problem that requires a solution, and the
> most simple the solution (as far as it's a right solution), the better.
> To free all the items in a UT_Map, you only need the public API. That
> shows us that we don't need to add another function to UT_Map.
While this is of course true, I thought it might be helpful to others to
have such a function as part of UT_Map.
The subclass I outlined would have only been used in one place anyway, I
wouldn't have put it in af/util.
> delete (YOUR_TYPE*) ((UT_Pair*) it.value)->first);
> (you may want to use C++ style casts. You will need 4 C++ casts (2
> statics, and 2 consts). That shows how ugly is to use void*
Hm, could I use const_cast<char*>(...->first); ? Or do I really have to
> The problem with this approach is that you may forget to call
Which is the reason why I wanted to use the destructor.
I didn't think of simply putting an UT_Map in an own class, which is of
course a wonderful solution.
> so if I were doing the work, I would write an adaptor
> to encapsulate this delete. Something as:
Right, I will do that. This way, I can also avoid the ugly int<->void*
and char*<->void* casts outside of UT_OwnMap or whatever I will call it.
> > > In the future, please consult any changes to UT_Map with me before
> > > committing.
> > Sorry for that; I consulted dom and thought that was sufficient.
> Try to consult the original author first. Dom and Martin are your best
> shot if you don't know who is the original author of the code, but in
> this case my name is clearly stated in the copyright notice.
Frankly, I was too lazily to write an email, so I just asked on IRC and
got an answer ;)
In the future I'll ask the original author. Thanks for the tip.
-- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin
This archive was generated by hypermail 2.1.4 : Sat May 11 2002 - 18:06:23 EDT