Steven Watanabe wrote:

AMDG

On 09/13/2013 01:54 PM, Robert Ramey wrote:

...

<snip> What I expect to see is:

#include #include #include void main(){ using namespace boost::units; using namespace boost::units::si; using namespace boost::units::us; quantity l1; l1 = 1000.0 * meters; quantity l2; l2 = 1.0 * miles; // compile error quantity l3 = l1 + l2; }

and I expect this to pretty much work. The documentation says " Implicit conversions between unit systems are allowed only when the reduced units are identical, allowing, for example, trivial conversions between equivalent units in different systems (such as SI seconds and CGS seconds)" so I expected that it can convert miles into kilometers.

Try static_cast.

could you give me an example? That is how should the statement l2 = 1.0 * miles; // compile error be modified?

...

This is a disappointment - but I'll assume that the authors have a good reason for this.

<snip>

In Christ, Steven Watanabe

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Steven Watanabe wrote:

AMDG

On 09/13/2013 03:48 PM, Robert Ramey wrote:

...

Steven Watanabe wrote:

...

On 09/13/2013 01:54 PM, Robert Ramey wrote:

...

<snip> void main(){ using namespace boost::units; using namespace boost::units::si; using namespace boost::units::us; quantity l1; l1 = 1000.0 * meters; quantity l2; l2 = 1.0 * miles; // compile error quantity l3 = l1 + l2; }

<snip>

Try static_cast.

could you give me an example? That is how should the statement

l2 = 1.0 * miles; // compile error

be modified?

l2 = static_cast>(1.0 * miles);

Hmmmm - OK this looks promising, but I get another compiler error with MSVC 1>z:\projects\geflightquest\simulator2\solvecpp\flight.cpp(14) : error C2065: 'miles' : undeclared identifier it looks like I'm missing something; Here is the test program again - with all the headers. #include #include #include int main(int argc, char * argv[]){ using namespace boost::units; using namespace boost::units::si; using namespace boost::units::us; quantity l1; l1 = 1.0 * meters; quantity l2; l2 = static_cast >(1.0 * miles); quantity l3 = l1 + l2; return 0; }

In Christ, Steven Watanabe

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Robert Ramey wrote:

Steven Watanabe wrote:

...

AMDG

On 09/13/2013 03:48 PM, Robert Ramey wrote:

...

Steven Watanabe wrote:

...

On 09/13/2013 01:54 PM, Robert Ramey wrote:

...

<snip> void main(){ using namespace boost::units; using namespace boost::units::si; using namespace boost::units::us; quantity l1; l1 = 1000.0 * meters; quantity l2; l2 = 1.0 * miles; // compile error quantity l3 = l1 + l2; }

<snip>

Try static_cast.

could you give me an example? That is how should the statement

l2 = 1.0 * miles; // compile error

be modified?

l2 = static_cast>(1.0 * miles);

Hmmmm - OK this looks promising, but I get another compiler error with MSVC 1>z:\projects\geflightquest\simulator2\solvecpp\flight.cpp(14) : error C2065: 'miles' : undeclared identifier

it looks like I'm missing something; Here is the test program again - with all the headers.

#include #include #include int main(int argc, char * argv[]){ using namespace boost::units; using namespace boost::units::si; using namespace boost::units::us; quantity l1; l1 = 1.0 * meters; quantity l2; l2 = static_cast >(1.0 * miles); quantity l3 = l1 + l2; return 0; }

OK my latest attempt just adds the following: namespace boost { namespace units { namespace us { BOOST_UNITS_STATIC_CONSTANT(miles, mile_base_unit); } } } But this generates an error with MSVC (and a similar message with gcc) 1>z:\projects\geflightquest\simulator2\solvecpp\flight.cpp(18) : error C2678: binary '*' : no operator found which takes a left-hand operand of type 'double' (or there is no acceptable conversion) 1> z:\boost_1_54_0\boost\units\detail\one.hpp(47): could be 'T boost::units::operator *boost::units::us::mile_base_unit(const boost::units::one &,const T &)' 1> with 1> [ 1> T=boost::units::us::mile_base_unit 1> ] 1> z:\boost_1_54_0\boost\units\detail\one.hpp(53): or 'T boost::units::operator *<double>(const T &,const boost::units::one &)' 1> with 1> [ 1> T=double 1> ] 1> z:\boost_1_54_0\boost\units\detail\one.hpp(58): or 'boost::units::one boost::units::operator *(const boost::units::one &,const boost::units::one &)' 1> while trying to match the argument list '(double, const boost::units::us::mile_base_unit)' I went back and tried to compile the tutorial - and it failed in the same circumstance with the same message. I tried this with current release branch and version 1.54 . I'm pretty much at loss here. I can't believe that I'm the first person to have this problem. Any help appreciated Robert Ramey

...

In Christ, Steven Watanabe

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 9/14/2013 5:31 PM, Quoth Robert Ramey:

...

#include #include #include int main(int argc, char * argv[]){ using namespace boost::units; using namespace boost::units::si; using namespace boost::units::us; quantity l1; l1 = 1.0 * meters; quantity l2; l2 = static_cast >(1.0 * miles); quantity l3 = l1 + l2; return 0; } [...] 1>z:\projects\geflightquest\simulator2\solvecpp\flight.cpp(18) : error C2678: binary '*' : no operator found which takes a left-hand operand of type 'double' (or there is no acceptable conversion) 1> z:\boost_1_54_0\boost\units\detail\one.hpp(47): could be 'T boost::units::operator *boost::units::us::mile_base_unit(const boost::units::one &,const T &)'

Incidentally, the reason why you're getting this error is that you're specifying the value type as "float" but then passing it double values. Replace your "1.0" with "1.0f" etc (or omit the "float" type parameter, which will make it use double by default) and then you'll probably have more luck.

Hi Robert, Robert Ramey wrote:

it looks like I'm missing something; Here is the test program again - with all the headers.

#include #include #include int main(int argc, char * argv[]){ using namespace boost::units; using namespace boost::units::si; using namespace boost::units::us; quantity l1; l1 = 1.0 * meters; quantity l2; l2 = static_cast >(1.0 * miles); quantity l3 = l1 + l2; return 0; }

Just in case you haven't gotten this yet, here's something that compiles and runs (with g++): #include #include #include #include #include #include <iostream> namespace boost { namespace units { namespace us { typedef boost::units::make_systemboost::units::us::mile_base_unit::type mile_system; typedef boost::units::unitboost::units::length_dimension,mile_system mile_length; BOOST_UNITS_STATIC_CONSTANT(mile, mile_length); BOOST_UNITS_STATIC_CONSTANT(miles, mile_length); }}} int main(){ using namespace boost::units; using namespace boost::units::si; using namespace boost::units::us; quantity l1; l1 = 1000.f * meters; quantity l2; l2 = static_cast >(1.f * miles); quantity l3 = l1 + l2; std::cout << l3 << std::endl; } //Outputs 2609.34 m The key is that value times unit = quantity, but you can't create a unit from a base_unit without a system. (There doesn't appear to be a system which declares mile units definitions, as you already found, I think.) Unfortunately, any other base_units which aren't used in the systems folder will require similar boilerplate. HTH, Nate

Paul A. Bristow wrote:

I've had good results using Boost.Units - after much puzzlement and frustration.

I think there are several problems (at least).

1 Units are complicated - very, very complicated. Even if we could ditch Imperial and US units, the fundamental weight in kg makes trouble. There are many conversions that are essential for the thing to be useful.

agreed - that's why we need the library.

2 Implementing them in C++ using templates to avoid any runtime cost proved to need concerted efforts from the best brains we have.

speaking for myself, I'm using the best brain I have.

The whole idea is secure conversion, so explicitness is vital - but annoying and puzzling.

I understand this - it's a key point and a very subtle one

3 The examples are quite good - but pack a lot (probably too much) into a small space.

agreed.

4 The C++ Reference documentation (as you observe) lacks the vital info about what all the template and other parameters do (pretty much Concepts by another name).

totally agree. Its more than that, writing this documenation and the concepts classes clarifies the library user interface and likely feeds back into the design/implementation of the library itself.

This needs a lot of Doxygen comments and is a massive and tedious task - especially as many of these are not trivial and need to be quite detailed with notes and links to examples.

I've got mixed feelings about Doxygen in addressing this problem. I did do a little bit of investigation on this (see www.blincubator.com) and reached the tentative conclusion that Doxygen wasn't suitable. The basic problem is that documention a templated library is a different animal than documention non-templated classes. Another problem with Doxygen is that often times the documentation ends up just parroting the code rather than providing the extra insight. Long and short of it - I'm not convinced that Doxygen can do this.

5 After the years of struggle to get it working, I can appreciate that the authors are very tired. And there are other juicy challenges

lol - you're preaching to the choir. I doubt anyone appreciates this issue more than I do.

I believe that someone else should write a bigger set of smaller examples (also drawing on the many replies to cries of help) and use these as Quickbook snippets. With better documentation and examples, I think this brilliant package might get the full use it deserves.

my 2 cents here. a) I would like to see reference documentation which looks like other reference documents for templated libraries - ie built around type constraints (aka "concepts"). b) After a) I would like to see a tutorial which incrementally builds up the knowledge from the simplest most widely used cases to the more subtle and less widely used ones. I know a lot about this subject because I learned the hard way. I had a lot off difficulty documenting the serialization library. I didn't get it right the first time and received an incredible amount of criticism for this. Finally I figured it all out and the library was much the better for it. Now I go and look at other libraries and I get the feeling that they really need improvement along the same lines. The units is sort of special in that it's more difficult than other libraries and it's potential utility is huge. I really believe that this library (units) should be as widely used as the serialization library is now. But I see no hope of that happening unless this issue is addressed.

But I don't think that I am volunteering!

lol - me neither - but I'm happy to tell other people how to do it! Robert Ramey