On 31 May, 17:09, Noah Roberts <u...@example.netwrote:
kwikius wrote:
Well lads :-)... looking at your Boost Units library the impression I
get is that you got your library into boost Before writing anything
much apart from some documentation, which was AFAICS even noted and
allowed for in the review managers preamble. Nice work boost ... :-)
Why the library was moved to the top of the review queue and accepted
in such an unfinished state has I conjecture a lot to do with...
hmm ... the BoostCon circus?
I voted against that library and you can see my review in the archive.
I compared all the unit libraries that were available. This is one of
those things who's time has come;
That may be the case, but things whose time has come don't just
happen.
There have been a lot of C++ physical quantities libraries. For
example you can still see a selection on the now dormant boost files
section:
I was led to boost and those libraries (in 2003 I think) because I was
spending a lot of time tracking units of quantities in some
engineering code.
Unfortunately they didnt meet my requirements, which were relatively
simple as it seemed then.
1)I wanted quantities in units. I specifically remember I had lengths
as meters and as millimeters in my code (then implemented as doubles)
and I spent a lot of time one day tracking back and forth between
source files checking what units (e.g meters or millimeters etc) a
particular variable was meant to be in.
2)The other requirement I had was for input output and this wasnt
really catered for AFAICS.
3) Finally the libraries all seemed to have concentrated on the
dimensional analysis part and then tailed off and been abandoned,
which I found odd.
Anyway I decided then to write my own physical quantities library to
implement the requirements above. I presented the first version
pqs-1-00-0 to boost at that time. It became clear that pqs was
significantly different both because of implementing the above
requirements, but also because it made no use of Boost.MPL template
metaprogramming library.
especially since the challenge was
issued at the end of Chapter 3 of the MPL book.
At some stage on Boost I was recommended to reimplement PQS using
Boost.MPL and this seemed to be an unofficial requirement.
I think that all the above mentioned libraries in the yahoo boost
files section were implemented using MPL.
I reimplimented PQS using Boost.MPL.
What I found was that where prior to installing MPL in the libray, a
small example would previously take a couple of seconds to compile,
when using MPL the compile time jumped to maybe a minute or so for the
same example. This compile time issue was pretty exasperating and
slowed the pace of development to a crawl. I then reckon I had the
answer to why those libraries had been abandoned at such an early
stage.Anyway I decided "stuff this!" and ripped the MPL stuff out and
was relieved then to be able to get back to developing at a reasonable
pace.
I didnt realise the significance of this action but I suspect that
behind the scenes it didnt gone down too well at boost.org :-)
PQS still caused quite a bit of interest and controversy too.
Significant. PQS had done something right even in its earliest
versions where previously libraries hadnt.
Your PQS library is
very different from MCS is some rather fundamental ways. PQS had no
concept of a unit "system" for instance.
I needed to draw a line at the amount of work I wished to take on. SI
is my useage. Si is the biggest usage.
I made the decision to concentrate on the SI system.
Pqs and Quan do I believe provide a satisfactory, nigh on complete,
extensible solution to SI quantities both coherent and incoherent.
I dont seee any evidence that Boost Units has provided a comprehensive
impl of any unit system, except as vapourware.
MCS also uses a completely
different structure to represent dimensions; PQS is based on the
vector_c structure used in the book.
Quan could easily "eat" the Boost Units dimensional analysis impl:
Anything that models the Static Unit requirements will do :
http://tinyurl.com/2ma75k
The compile time dimensional analyis mechanism provided as default
model in PQS/Quan is implemented in the simplest possible way, solely
because I reasoned that no one will use a library where the cost
outweigh the benefits. The cost when using MPL is the huge jump in
compile time. I believe that this is a major reason why the search for
a viable C++ physical quantities library on Boost was stalled and had
been for some time.
I tried to design PQS primarily from a users point of view and this
compile time issue would I believe be a huge barrier to potential
users. On this subject, PQS/Quan has always had its user interface
layer, the style which should be familiar to anyone who has seen the
library.
This emphasis on placing the user first, the "pretty" source syntax as
well as the I/O facilities was designed to lower the barrier to entry
for those trying out the library. This emphasis on the user is
crucial and AFAICS was not considered by other library authors.
Unfortunately in many ways PQS/Quan is so elegant and simple from the
users viewpoint that it makes the whole subject of representing
physical quantities seem pretty trivial, though there was a huge
amount of work required to figure this out.
IIRC you yourself called Quan "cute", which sums up this approach.
What I wanted to achieve was that someone could download the library
have a look at a couple of code examples and say aha I see how this
works, thats pretty simple... and get on with it.
I also spent a long time in trying to get the library as near as
possible to industrial strength ( albeit only in gcc4 and VC7.1 and
later VC8), IOW by testing it in a lot of situations and non trivial
code, and also trying to get the library efficient in terms of
performance versus ibuilt types. This work is totally invisible but
takes again a large amount of thought and work, but a
library which only works in trivial examples is simply going to be
binned by users.
In my experience having brief look at the The Boost Units review
offering as presented, it would blow up in any no trivial use.(you
even gave the Boost Units authors a few hints about why this will
happen in your review IIRC)
By the end of the PQS review on Boost in May 2006, it was clear to me
that the library had achieved its purpose.
To sum up ... The above is some detail on how I went about arriving at
the stage of:
"This is one of those things who's time has come"
regards
Andy Little
"There is a crack in history one inch wide... we must use it"., David
Hare, "Fanshen"