Subject: Re: commit -- fix for UT_RBTree
From: Joaquin Cuenca Abela (e98cuenc@yahoo.com)
Date: Wed Jul 18 2001 - 10:39:41 CDT
--- Mike Nordell <tamlin@algonet.se> wrote:
> Joaquin Cuenca Abela wrote:
> >
>
> > Fixed a bug in the UT_RBTree::insert code.
>
> Keeping a r-b tree balanced can be a somewhat
> "interesting" excercise. :-)
Yup. Insert is coming nicely (50000 random insertions
maintained the invariants all the time)... erasing is
another question... :-)
> Any particular reson why the implicitly inlined
> member functions are
> expliticly given the "inline" keyword in ut_set.h?
> Also, why the "UT_Set::"
> qualification for the iterator within the
> declaration of UT_Set member
> functions?
Ops, I didn't know that these methods were implicity
inlined. Good to know (is it, then, right to assume
that the compiler may inline all the methods that
would otherwise be in the same translation unit?).
The redundant UT_Set:: was a copy & paste error (these
methods born at ut_set.cpp and I started to erase
UT_Set::'s, but it seems that I forget some ones :-).
I will fix them in the next commit
> > Btw, I suppose that I'm not dreaming
> > or something... msvc doesn't cares about koenig's
> > rule, doesn't it?
>
> Partially, sometimes, sortof... but in reality it's
> broken.
>
> > I had:
> >
> > random_shuffle(numbers.begin(), numbers.end());
>
> Should this work? AFAIK, you must first "mention" a
> data type in another
> namespace for the lookup to consider that namespace,
> or?
numbers being a std::deque<int>, numbers.begin() gaves
us a std::deque<int>::iterator
so the two arguments are in the std namespace, and
thus it should also look for the
functions in this namespace, or am I missing
something?
Cheers,
-- Joaquín Cuenca Abela e98cuenc@yahoo.com__________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
This archive was generated by hypermail 2b25 : Wed Jul 18 2001 - 10:39:51 CDT