[Bug 1641] Red Black Tree data structure

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1641

--- Comment #12 from Chris Johns <chrisj at rtems.org> 2010-09-18 16:15:42 CDT ---
(In reply to comment #11)
> (In reply to comment #10)
> > I have been taking a close look at this code and have a few questions. I like
> > the idea of a standard tree being in RTEMS and have started some documentation.
> > 
> > You seem to define local variables in the middle of blocks like C++ allows. I
> > know GCC allows this but I thought this is an extension and currently not
> > standard ? Do we allow local declarations in the middle of blocks in score code
> > ? I did not think this was allowed.
> > 
> I see there are a few places where this is done, I can clean this up -- I don't
> recall ever seeing this explicitly stated, although I do typically avoid
> declaring variables after the start of a block.

I also cannot remember. It was as much a question as a general comment. If you
work with C++ you come like this feature.

> 
> > The code only supports an unsigned integer. Would it be possible to support a
> > string as well ? Maybe the value could be a union and control structure can
> > have a flag that indicates the union field. I could use a string based tree.
> Do you mean that you want to have a tree that sorts based on a string rather
> than an unsigned integer?  This can be done, we would have to replace direct
> comparisons of the value field with a function call that implements a compare
> operator, e.g. a default function that uses the < operator, and one with strcmp
> if the field is a string.

An operator call would be a nice solution but it does cost an extra call and I
was not sure of your use case. I was just thinking about explicit tests for an
int or a string via a union and a bool in the control which test.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.