Re: [boost] operators.hpp (C++ Builder Fixes)

From: Jens Maurer (jmaurer_at_[hidden])
Date: 2000-04-27 16:18:38

John Maddock wrote:
> First the workaround, for some reason C++ Builder can't handle
> incrementable and decrementable, here is the specific workaround:

In another mail, you indicated that you're using C++ Builder 4.
I tried today with the freely available Borland C++ v5.5, which
seems to feature a somewhat different set of bugs.

In particular, inline friends of template functions don't work
at all.  According to the standard, something like

  template<class T>
  class A {
    friend void f(T x) { ... }
  };
  A<int> x;

should declare (and define) the non-template function "void f(int)"
at the namespace scope surrounding the definition of class A.
Borland C++, however, wants an additional namespace-scope
declaration of "void f(int)" before the definition of class A.

This would make boost/operators.hpp completely unusable, of course.

So I defined BOOST_NO_OPERATORS_IN_NAMESPACE, which isn't exactly
what I wanted to express (BOOST_NO_INLINE_FRIENDS_IN_CLASS_TEMPLATES
would be better), but it covers the issue for now.  This leads to a
different problem:  using-declarations for class template identifiers
(as thence employed by boost/operators.hpp) don't work.
(What about a BOOST_NO_USING_TEMPLATES?)  So we
have to leave all classes of boost/operators.hpp at global scope,
which is fine as long as they're only used by classes
in namespace boost. A qualification such as "boost::addable"
(required for user-defined classes which don't want to say
"using namespace boost") is then incorrect, of course.

For now, we should probably document that boost/operators.hpp is not
available for user-defined classes with Borland C++ v5.5.

To sum it up, please apply the proper #if __BORLANDC__ <= XXXXX
conditions to boost/config.hpp.

I am currently writing up my experience with BCC v5.5 as a HTML
page, which could be added to the "more" directory of boost.
Beman, what do you think?

> With this fix in place I can compile the operators.hpp example apps OK,
> however closer inspection shows that all is not well: in Jeremy's
> iterator_test.cpp sizeof(test_iter<T>) evaluates to 80bytes - let me say
> that again - test_iter<T> takes up 80bytes to encapsulate a single 4 byte
> pointer.

This, a bit less drastic, I also experienced with my interval
class.  Two doubles in an interval<double> should take 16 bytes,
but they took about 28 bytes (or something like that) with gcc 2.95.2.
This is not acceptable for a potentially heavily-used numeric type.
I've already implemented the omission of boost/operators.hpp when
optimizing with gcc, but I think I'll scrap it altogether until
the compilers get their act together.

> 1) How do other compilers handle this?

gcc 2.95.2: sizeof(test_iter<int>) = 16

> 2) Does this matter?  Will run time performance be affected by this?  My
> gut feeling is that in some cases maybe the answer is "yes", but some
> qualitative information would be useful.

Yes, in the case of copying my interval class, 16 bytes are copied
with unrolled straight-forward inline instructions, but anything
more sets up a "rep movs" (Intel x86 case) loop.

> 3) Is this required behaviour? If each unique direct base-class has to have
> a unique address then it would seem so, but I haven't been able to locate a
> definitive view from the standard - any takers?

This definitely seems to be a case for empty base class optimization.
However, it's also multiple inheritance so some compilers probably
get frightened and do it the safe (bloated) way.

> BTW I should add that I really like the concept of operators.hpp - I think
> it has a lot of potential applications for adding boilerplate code - but
> this kind of object size bloat may be something of a problem.

It's a cool concept, but the compilers are dumb.

Jens Maurer