Re: [boost] [Units] Unique ordinal values (was Re: Review)
On 4/3/07, Steven Watanabe <steven@providere-consulting.com> wrote:
David Walthall <walthall <at> stanfordalumni.org> writes:
The only complaint I have is that unique values of ordinal<N> have to be used.
Nod. The only way to prevent collisions is to use more bits and either guids or compile time strings storing the fully qualified name.
Matthias posted about this before and I can't remember the outcome. I was browsing some archived posts about Boost.Typeof and came across this: http://thread.gmane.org/gmane.comp.lib.boost.devel/101946/focus=102070 Would that be enough? Usage would look like: #include BOOST_UNITS_ORDINAL_GENERATOR() struct my_unit : ordinal<BOOST_UNITS_NEXT_ORDINAL> { }; Sorry if you guys have been over this ground before. --Michael Fawcett
http://thread.gmane.org/gmane.comp.lib.boost.devel/101946/focus=102070
Would that be enough? Usage would look like:
#include BOOST_UNITS_ORDINAL_GENERATOR() struct my_unit : ordinal<BOOST_UNITS_NEXT_ORDINAL> { };
I believe the problem with this is that it doesn't guarantee uniqueness across translation units; Steven understands these issues better than I do, though. Matthias
AMDG Matthias Schabel <boost <at> schabel-family.org> writes:
http://thread.gmane.org/gmane.comp.lib.boost.devel/101946/focus=102070
Would that be enough? Usage would look like:
#include BOOST_UNITS_ORDINAL_GENERATOR() struct my_unit : ordinal<BOOST_UNITS_NEXT_ORDINAL> { };
I believe the problem with this is that it doesn't guarantee uniqueness across translation units;
Right. The best I have been able to think of so far is (sizeof(__FILE__) * 1000000 + __LINE__). This is a dead end unless I can find some way to extract more information from __FILE__ than it's size at compile time. In Christ, Steven Watanabe
On 4/5/07, Matthias Schabel <boost@schabel-family.org> wrote:
http://thread.gmane.org/gmane.comp.lib.boost.devel/101946/focus=102070
Would that be enough? Usage would look like:
#include BOOST_UNITS_ORDINAL_GENERATOR() struct my_unit : ordinal<BOOST_UNITS_NEXT_ORDINAL> { };
I believe the problem with this is that it doesn't guarantee uniqueness across translation units; Steven understands these issues better than I do, though.
I think that problem only arises if you actually define units in a source file instead of a header file. That shortcoming could just be documented, since it seems pretty rare that someone would define their custom unit in a source file instead of a header. If they really wanted to do that, they could still just use the current method. A quick test with VC8.0 just now shows that even __COUNTER__ has that problem when used in source files, but in headers Paul M.'s method works just fine. --Michael Fawcett
AMDG Michael Fawcett <michael.fawcett <at> gmail.com> writes:
I think that problem only arises if you actually define units in a source file instead of a header file. That shortcoming could just be documented, since it seems pretty rare that someone would define their custom unit in a source file instead of a header. If they really wanted to do that, they could still just use the current method.
A quick test with VC8.0 just now shows that even __COUNTER__ has that problem when used in source files, but in headers Paul M.'s method works just fine.
Did you try multiple headers putting the #includes in different orders? In Christ, Steven Watanabe
Hello Michael, Thursday, April 5, 2007, 10:17:29 PM, you wrote:
On 4/5/07, Matthias Schabel <boost@schabel-family.org> wrote:
http://thread.gmane.org/gmane.comp.lib.boost.devel/101946/focus=102070
Would that be enough? Usage would look like:
#include BOOST_UNITS_ORDINAL_GENERATOR() struct my_unit : ordinal<BOOST_UNITS_NEXT_ORDINAL> { };
I believe the problem with this is that it doesn't guarantee uniqueness across translation units; Steven understands these issues better than I do, though.
I think that problem only arises if you actually define units in a source file instead of a header file. That shortcoming could just be documented, since it seems pretty rare that someone would define their custom unit in a source file instead of a header. If they really wanted to do that, they could still just use the current method.
A quick test with VC8.0 just now shows that even __COUNTER__ has that problem when used in source files, but in headers Paul M.'s method works just fine.
Does it work if headers are included in different order? I.e. // file1.cpp #include "header1.h" // Here I use ordinal<BOOST_UNITS_NEXT_ORDINAL> #include "header2.h" // Here I use it too // file2.cpp #include "header2.h" #include "header1.h" I should have the same ordinals for corresponding units in both TUs. -- Best regards, Andrey mailto:andysem@mail.ru
participants (4)
-
Andrey Semashev -
Matthias Schabel -
Michael Fawcett -
Steven Watanabe