From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2006-04-20 10:19:54
> First of all, from some of your comments I see you must have looked at the
> older revision. Rev.5 does not have any pointers in the interface, and no
> longer has get_d, get_b variants.
Gosh, I found I have two source code trees here
and I picked up the old one. Sorry for the mess.
I recall everything I said and will review the latest
>> 1. docs: it is rather unusual for me read code
>> without syntax highlighting.
> The problem is, it is written and maintained in HTML. I could add code
> coloring, but that would render it close to unmaintainable. Any change
> would be a nightmare. I should have used QuickBook, but unfortunately I
> had problems setting up the toolchain. So I stuck to HTML. Btw. some other
> well estabilished libraries in boost also do not have code coloring, and I
> didn't notice anybody complaining.
Newer libraries generaly have syntax highlighting.
I complain because it is years and years since I wrote code
without colorizing editor.
>> 6. Possible feature:
>> "...there is an additional indexing data structure
>> inside property tree that allows fast searches..."
>> There may be a type trait that disables creating
>> of such structure, where the search complexity
>> would degrade gracefuly to O(N).
> I know, you said that before, I have it hovering on my list of things to
> be done. It has never got big enough priority though.
It seems I rerun my previous review once again.
I do not keep the previous texts so it may happen
more than once I "discover" something repeatedly.
>> 7. The temptation to use std::lower_bound and similarly
>> dangeroud std algorithm may be eliminated by defining
>> unimplemented specialisations for ptree
> You can always sort the tree and then use the algorithm safely, so banning
> it would not be wise.
Hmm. Perhaps specialisations could be written that in debug
mode check the tree is actually sorted.
>> 15. The headers may have
>> #if (defined _MSC_VER) && (_MSC_VER >= 1200)
>> # pragma once
> Btw. is compilation time really shortened that much? I think that it only
> removes the preprocessing step, which is done in a snap anyway. I haven't
> done any measurements so I might be wrong.
Small but noticeable if applied rigorously:
>> 25. I tried to compile the test with BCB
> That's great. If somebody else with better knowledge of BCB intricacies
> could do it, it would be nice. On the other hand I'm afraid of introducing
> too many maintenance problems (aka ifdefs), or compromising the
> design/performance of the library to make old stuff happy.
#ifdefs will be necessary for BCB.
Generally, most of Boost libraries are littered with #ifdefs
to be almost unreadable. A "clean" version of Boost has been
suggested but it is not likely to happen in next few years.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk