Boost logo

Boost :

From: David Bergman (David.Bergman_at_[hidden])
Date: 2006-07-25 23:56:18

David Dribin wrote:

> On Jul 21, 2006, at 4:14 PM, David Bergman wrote:
> > What about the use of endian objects where one would expect raw
> > integral objects? Such use includes
> >
> > template<typename DestT, typename SourceT>
> > DestT make_double(SourceT val) { return 2 * val; }
> >
> > big4_t doubleVal = make_double<big4_t>(21);
> This doesn't seem to be a common use case for binary data
> structures used in I/O.

Ok, but *before* being output? The object might very well pass through some
generic code.
> > The generic code need not even deal with arithmetic at all,
> such as in
> >
> > vector<int> int_vect;
> > ...
> > vector<big4_t> big4_vect(int_vect.begin(), int_vect.end());
> And this has a workaround by using a for loop.

I don't understand. One would need to use "::init", right? That is not
exactly compatible with regular integer types - or most other types. I was
refering to generic code which we cannot easily change, as well.
> > Since we do not have the luxury of two user-defined
> conversions in the
> > chain from 'int' to 'endian<...>', which would allow us to write an
> > intermediate type with both an 'int' constructor and an 'endian'
> > operator, we have to
> > choose: unions (and other pure POD scenarios) or conversion
> from raw
> > integral objects. I think a wise decision was made in the
> choosing the
> > latter.
> I guess I disagree. With an assignment operator, most of the
> conversions from raw integral types are covered, and you can
> still use 'em in unions. If you still feel this way, would
> it be at least possible to add a #define to disable the
> constructors?

Yes, maybe.

> This would allow the user of the library to
> choose what is important to them, rather than the library
> writer. We obviously can't support all use cases with the
> current limitations of the C++ language.

You are right.


> Well, if I haven't convinced you by this point, hopefully at
> you'll at least consider using a #define to disable
> constructors for those people that *do* find a real-world use
> for such classes in unions.

I would probably not consider it, but it is not my choice :-)

What I *would have* considered, though, is to have two templates:

        template<...> struct pod_endian { ... no constructor but all the
endian logic ... }


        template<...> struct endian : pod_endian { ... constructors and not
much else ... }

And have conversion operator to get an endian from a pod_endian.

Additionally, I would probably use my embed_type proposal and get:

        template<.., typename IntType, ..> struct endian :
embed_type<IntType, endian> { ... }

using proper policies.


Boost list run by bdawes at, gregod at, cpdaniel at, john at