From: Simon Li (simon.li_at_[hidden])
Date: 2005-05-17 04:55:02
> > On the other hand, the boost libraries have never, as far as I can
> > tell, compromised on interfaces to accommodate programmers
> who don't
> > like templates or modern C++ idioms.
> > Why should the constants library be any different? Why should boost
> > give physicists special consideration that most C++
> programmers do not
> > get?
> There is nothing extraordinary about it. A library is
> designed for clients, and it's sound to listen to what they
> desire. If they don't like the product, they'll use
> something else. That may or may not matter to you.
True, but a library should also be consistent within itself. The
impression I get from Boost is that, as pointed out above, it tries to
apply strong principals in the design of its interfaces. It also seems
to have no qualms (and arguably makes a point) about using relatively
recent c++ features (eg. template specialisations) rather than getting
bogged down with established practice.
IMHO if a user wanted a library using long established programming
practice, they definitely wouldn't be using Boost. However, if for some
reason someone really did want the constants library, they'd be free to
rewrite it (and even release it) in a format they required... it's not
as if the values of constants are likely to change :-)
This e-mail message (including its attachments) is private, is intended for the recipient named in it and may contain material which is confidential and privileged.
No-one other than the named recipient may read, copy, rely on, redirect, save or alter the message or any part of it or any attachment to it in any way.
VMS does not accept legal responsibility for the contents of this message.
Any views or opinions presented are solely those of the author and do not represent those of VMS unless otherwise specifically stated.
While reasonable effort has been made to ensure this message is free of viruses, opening and using this message is at the risk of the recipient.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk