Walter W. Karas wrote in message <34F9EEEF.6FD5@ibm.net>...
<snip>
>This is incorrect.  I admit my description is difficult to
understand.
<snip>

I believe the original author's (Walter W. Karas) intentions was to
make inert<T> be something like:
  inert<T> is the type T if T is a non-POD type
  else it is the type unusedname_sizeof_T where "sizeof_T" is replaced
by a literal representing the value returned by sizeof(T), and
"unusedname" is some name (the same for all inert<> types) such that
unusedname_intliteral is not declared anywhere in the program (for any
"intliteral").  The type unusedname_sizeof_T is equivalent to:
  struct unusedname_sizeof_T {
    char unspecified_name[sizeof(T)];
    bool operator==(const unusedname_sizeof_T& x) const {
      return equal(unspecified_name,
        unspecified_name+sizeof(unspecified_name),
        x.unspecified_name);
    }
    bool operator!=(const unusedname_sizeof_T& x) const
    { return !(*this == x); }
  };  // includes implicitly declared copy ctor and = operator
In addition, static_cast can be used to convert between the types
unusedname_sizeof_T and any POD types of the same size.

For reference, POD stands for "plain ol' data."  Given two objects of
the same POD type, it is possible to copy one's value to the other by
just copying the underlying bytes.  It is also possible to store the
value of a POD object in an array of sizeof(object) chars.  int is
obviously a POD type; so is struct{POD_type1 x; POD_type2 y;}.

There are at least two problems with the syntax of inert.  First, the
following, though it would be legal if sizeof(float) == sizeof(int),
does ugly things:
  float f = 0f; int i;
  i = static_cast<int> (static_cast<inert<int> > (f) );
The line above is equivalent to
  memcpy(&i, &f, sizeof(i));  // ick!

Another problem is in the assumption that == for all POD types does a
simple bytewise compare.  This, however, can be solved by changing the
definition of inert<> (by replacing "POD" with "bytewise-comparable
POD").

Just for the record, I agree with what Valentin Bonnard wrote in
message <34F9B66D.29F1@pratique.fr>:
>I think this is a case of false optimisation, when someone wants
<snip>
>There is nothing difficult with such code sharing, just that you
>need to rewrite the linker (ie you need access to the linker).
<snip>

The advantages of inert<> could be implemented transparently in an
optimizing linker, and should not be the concern of the programmer.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]