Boost logo

Boost :

From: Dave Dribin (dave-ml_at_[hidden])
Date: 2006-07-25 17:28:27

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.

> 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.

> 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? 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.

>> What good is a single big-endian variable on the stack? I
>> see far more use cases for these classes in structs and
>> unions, and then writing them out a file descriptor.
> But we also want it to be interchangeable - as far as possible - with
> integers in generic code (whether templates or "copy-and-pasting".)

Yes, I would agree. As far as possible, but not at the expense of
legitimate and useful use cases. An endian class library, that could
be used in unions, would have saved me a good chunk of time on a
recent client project.

I keep re-reading the documentation, and nowhere does it explain that
interchangeability with integer types is a key requirement. It talks
about providing "integer-like byte-holder binary types with explicit
control over byte order, value type, size, and alignment." It talks
about "use cases almost always involve I/O, either via files or
network connections." Unions are not uncommon in these situations.
In fact, the example at the end gives a structure representing a file
format. Again, it is not at all uncommon to have structures that
represent file formats that require unions.

Even one of the FAQ questions talks about why operators are are
provided at all, since that isn't really the prime feature of these
classes. Basically, they are nice to have to make code more
readable. And I agree with that, so long as reducing clutter doesn't
inhibit some real-world use cases. Removing constructors makes only
a small fraction of uses cases more wordy.

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.


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