Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2003-12-19 18:54:15


"Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
news:brs8i8$6qh$1_at_sea.gmane.org...

  a.. What is your evaluation of the design?

My evaluation is based on a very quick read of the documentation (Well if
you call 6 hours quick...its Complicated!). So I hope you accept my comments
in that light.
I am very disappointed that I could not get the converter to compile "out of
the box" on VC 7.1.
I am not sure what the policy on code correctness at boost is, but in my
book that means I would have to give an automatic
"reject" vote to any design that doesnt actually work. ( I do understand
that the problems are in dependent libs... but... cmon guys... get it sorted
for VC7.1 please! ) ( as I am a "newbie" I'll just abstain...even though its
not allowed)

With no easy/lazy ability to find out about the converter using by my
preferred method of "messing about" with it to find what it does I was
forced into the docs.
My main interest in the converter is in promotion rather than conversion(
Yes I want to just promote<A,B>::type for UDT's... dream on buddy), and
apparently it is possible to use the
supertype mechanism for this for inbuilt types.
I have had problems with the whole syntax. Why is a subtype or supertype
direction dependent?
I would assume one range fits in another or it doesnt. Would not set theory
be better naming ie union intersection, subset etc.
The whole business, grammar etc is complex enough.. is this direction
dependent sub/supertype thing really the best way to achieve this?

These problems of comprehension aside and despite the fact that it it doesnt
compile the docs are very interesting indeed.
It will however take me a good few months (and a working implementation
:-) ) to fully appreciate what is going on here. As well as conversion
between
inbuilt types there are hints of possible ways to convert to from User
Defined Types and some attempts at classification of User defined types...
with a view to generic conversions from/to inbuilt/UDT.
This I have dreamed about but looks as if someone is actually getting down
to it in a serious way.
Here too I have problems with things such as the density of a type. Its a
nice idea but the implementation seems non-intuitive.
I would prefer a more conceptual(less mathematical ) approach to the whole
business of UDT classification.
e.g (say) some numerics are trying to be analog values, while others are
better at counting etc.
That said this is going to be a very complex business to get right..

On bounds which did compile...There are some oddities for instance the
bounds<>::smallest returns 0 for an int but non-zero for a float.
I would have expected either 1 for an int, or 0 for both (bit redundant).
The bounds class claims to try to sort out the differences between the
numeric_limits for real and int , but this doesnt seem a good way to go
about it.

To anyone who hasnt looked at the docs... head over to the file section and
take a look.
numerics.. are after all the basic building blocks... which I too often
ignore (use a double and hope for the best...ouch! :-) )
I am looking forward to testing out the converter rather than just reading
about it (err..hmm ... when it actually runs on VC7.1 that is :-) )

regards
Andy Little


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk