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

From: jorg.schaible_at_[hidden]
Date: 2000-04-27 08:10:46

Hi John,

please add the version number to the compiler specific defines. Otherwise you never really know wether the compiler is conform or not, when a new compiler version is available.

Basically use something like this (don't know the current version number):

#if defined(__BORLANDC__) && __BORLANDC__ <== 550
// Workaround here
#else
// Standard conform code here
#endif

---------------------------------------- Message History ----------------------------------------

From: John_Maddock_at_[hidden] on 27/04/2000 11:30

Please respond to boost_at_[hidden]

To:   boost_at_[hidden]
cc:
Subject:  [boost] operators.hpp (C++ Builder Fixes)

Dave, Jeremy,

I have some workarounds to get operators.hpp working correctly with Borland
C++ Builder, one is a compiler bug workaround, the other may have more
profound implications.

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

//  incrementable and decrementable contributed by Jeremy Siek)
#ifdef __BORLANDC__
// compiler workaround:
template <class T>
struct incrementable
{
private:
  typedef T iterator_type;
public:
  friend T operator++(T& x, int)
  {
    iterator_type tmp(x);
    ++x;
    return tmp;
  }
};

template <class T>
struct decrementable
{
private:
  typedef T iterator_type;
public:
  friend T operator--(T& x, int)
  {
    iterator_type tmp(x);
    --x;
    return tmp;
  }
};
#else
template <class T>
struct incrementable
{
  friend T operator++(T& x, int)
  {
    T tmp(x);
    ++x;
    return tmp;
  }
};

template <class T>
struct decrementable
{
  friend T operator--(T& x, int)
  {
    T tmp(x);
    --x;
    return tmp;
  }
};
#endif

The workaround versions could be the only versions if you wanted to avoid
the conditional compile.

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 behaviour can be improved somewhat by topping and tailing the code in
operators.hpp with:

#ifdef __BORLANDC__
#pragma option push -a1
#endif

and

#ifdef __BORLANDC__
#pragma option pop
#endif

With these fixes in place then  sizeof(test_iter<T>) reduces to 20 bytes,
still too big, but better.  IMO these fixes do need to be applied to
operators.hpp to make the library usable with Borland C++.  I've attatched
the modified version to this mail, BTW I haven't tried Dave's new version
of operators.hpp yet - but I will.

Now this brings up a number of interesting questions:

1) How do other compilers handle this?  Do they also bloat the object size?
 A quick test shows that VC6 makes  sizeof(test_iter<T>) to be 12, which is
better but still not ideal.
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.
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?

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.

- John.

------------------------------------------------------------------------
IT Professionals: Match your unique skills with the best IT projects at
http://click.egroups.com/1/3381/2/_/9351/_/956835051/
------------------------------------------------------------------------