I dont follow what you are saying here. Do you mean that I should use more meaningful variable names?
I mean that #include <boost/pqs/types/length.hpp> should really cover current and future length metrics.
The "t1"s would be hard to maintain in legacy code
You mean that :
#include <boost/pqs/types/length.hpp>
should bring in the (socalled) t1_quantity, t2_quantity for length?.
Its worth thinking about, though I do have certain doubts about putting everything in one header. It would make life simpler though. The current hierarchy is noticeably too deep.
Yes. The "t1" is arbitrary symbol that doesn't make much of sense. When someone wants to use the units the include path should be intuitive #include <boost/si_units/capacitance.hpp> _______________________________________________
25. Naming: people may not like long names like boost:pqs:xyz.
Perhaps there could be a macro that, given a namespace (i.e. global) and common name prefix, will create all typedefs where the user likes them. Something as
BOOST_UNITS_DECLARE_ALL_IN(::, unit_)
and then "unit_m" would be meters.
Maybe. but user can use namespace alias , typedef or using for preferred set of units. Unless the current mechanism is unacceptable I am in favour of not providing alternatives.
The macro could be generated. Hand-typing the typedefs would not be the best past-time. There is also chance that someone may want to replace existing a legacy unit typedefs with the new library.
I could remove all the named_quantities part of the library and leave it to the user to deal with which sounds like what you are suggesting. That would certainly save me a lot of work. However from my own point of view ( as a user) I am quite lazy and I like all this work to be done for me. I feel that the current interface works reasonably well. A point that is remarkable about the current library is that basically its a large database of value_types rather than something to compose ones own types from. In fact the format of the naming convention for the named_quantity typedef isnt well documented, but the ambition was that the interface (ie length::m) communicates better than the class template t1_quantity<length,zero_unit,double> does.
Another possible solution: have one internal header with things like: typedef .... BOOST_UNITS_CURRENT_PREFIX ## m; // meters Then the header that user will include could be: #define BOOST_UNITS_CURRENT_PREFIX boost::pqs:: #include "internal-header" #undef BOOST_UNITS_CURRENT_PREFIX
Apologies that I find it difficult to communicate what I am trying to say here. I feel that the interface ( which you want to be able to customise) is the most important part of the library in many ways. That is its most useful feature and is what saves the user time and effort, assuming they understand the 'feel' of it of course. The interface hides some rather messy details of the t1_quantity, ( coherent/incoherent units etc etc) . Remove the interface and the user is exposed to all that which is not good AFAICS. They then need to recreate their own interface.
The change would be from: boost::si_unit:m to my_m if people are too lazy to type or must obey different conventions. Existing interface would be always present and documented. It is not, however, showstopper in any case, just possible convenience for minority of users. /Pavel