Subject: Re: [boost] Single letter template type causes errors in compile of program_options and filesystem boost libraries
From: Mike Collier (mcollier69_at_[hidden])
Date: 2008-12-18 17:09:12
Thanks for the suggestions.
On Dec 18, 2008, at 1:37 PM, Beman Dawes wrote:
> On Thu, Dec 18, 2008 at 3:51 PM, Andrey Semashev
> <andrey.semashev_at_[hidden]> wrote:
>> Stefan Seefeld wrote:
>>> Sorry, but this is just bad coding practice. Instead of changing
>>> boost in
>>> order to accomodate for it, I suggest that you isolate the
>>> libraries from
>>> each other, by carefully undefining those single-letter macros
>>> prior to
>>> including boost.
>> Another solution might be simply changing include order, so that
>> headers get included prior to the vendor-provided headers.
> It might be better not include the vendor-provided headers at all,
> since it would not be surprising if these headers had many other
> additional problems. Better to provide a modern, safe interface via
> your own headers, implemented in an isolated translation unit that
> calls the vendor's functionality.
It's not really to practical to leave out the vendor header because
the defines are used a lot in code. Not using them would give
incorrect results or cause the compile to fail in code written such as
voltage = 10 V;
current = 100 uA;
where uA is :
#define uA *1.000000e-06
These are connivence ( or I might say crutch ) defines for electrical
engineers who don't want to code with proper exponents or want a
little documentation in the code. I know this is a bad practice but
it's in a header that's vendor supplied and these connivence defines
are used in lot's of code.
>>> If something should use longer names, it's these macros in your
>>> not boost template parameters.
>> Since this library is not Mike's, I'd rather suggest reporting this
>> issue to
>> the library vendor.
> Yep. One wonders what they could have been thinking and why they used
> macros rather than something that observed scoping.
The vendor ( Verigy ) is not known by people who use their software as
having good software so it's not surprising to me they coded their
macros this way. They probably thought it would be nice if non-
programmer electrical engineers could use units next to numbers to
save time or make code self documenting. I doubt they would be willing
to change the header since it's used around the world in legacy code
that would all fail the compile or worse compile and give incorrect
My solution is to change type names in the boost headers , since I can
control these locally and I don't see any benefit to using short names
in the boost headers. My ideal solution would be for the boost headers
to use longer names to start with.
Any other ideas are welcome.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk