On Tue, Jun 8, 2010 at 11:52 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Gottlob Frege wrote:
- I agree that the operators on an endian type are dangerous and should be separated. (I also think operators on atomics are dangerous, but that's another story.)
Dangerous? My only concern is that they are inefficient and can lead one to write unnecessarily inefficient code.
OK, not the best word, I guess. Or 'dangerous' for sufficiently small values of danger.
The latter is a departure from the new-style casts. This harkens back to the earlier notion of swap<to,from>() that I suggested and Tomas dismissed because of the confusion that can arise over template argument order. However, by naming the function "endian_cast," you sidestep that problem because the "to" type would always be first in keeping with the normal cast use case.
Let's see how this looks in code (I'm going to assume "endian_wrapper" as the base class name for exposition):
template <class T, class Endianness> T endian_cast(endian_wrapper<Endianness> _wrapped) { T const result( swap_to_host_order<Endianness>(_wrapped.value())); return result; }
template <class T, class Endianness> T endian_cast(T _wrapped) { T const result(swap_to_host_order<Endianness>(_value)); return result; }
It would be possible to also include the cases in which the input and output endiannesses are specified (the filter case), but those lead right back to confusion about the template argument order.
Technically, the output endianness would take the place of the int. But then you'd need a secondary cast, I suppose. ie big j = endian_cast<big, little>(k); int i = reinterpret_cast<int>(endian_cast<big, little>(k)); which could maybe be somehow shortened? But that is what is actually being done. If I understand the use case correctly.
Notice that endian_wrapper<> needed a means to get the value. I don't see the value of a wrapper type that specifies the endianness but gives no means to access the value.
Alternatively, you would reinterpret_cast<> internally. Otherwise I worry about the value of the wrapper - is it converted to host or not? I could live with something like: wrapper.data() // raw data. or raw_data() or raw() or... wrapper.value() // converted to host *value*
Does this make sense? It's still a bit vague in my mind, but I'm just wondering if we can somehow manage to use the same functions and syntax in both the typed and untyped scenarios.
I think I understood you and it seems rather interesting. It is useful to make the source endianness explicit in the call which this approach does by requiring either a wrapper type with endianness or a template argument, but that is also made explicit by the other function-based interfaces we've discussed.
If the value to be converted using something like endian_cast is a field in a struct, and that structure's definition is provided outside the client program, then the field will likely be a built-in type, not an endian_wrapper. That means the conversion is from T to T. convert_from<big_endian>() seems better than endian_cast<T,big_endian>(). IOW, I don't think endian_cast can be extended helpfully as you've suggested. Instead, endian_cast<int>(make_endian<big_endian>(t)) would be needed and convert_from<big_endian>(t) is much clearer. (Perhaps the latter would be implemented using the former.)
convert_from<big_endian>() is slightly nicer, but endian_cast<T, big_endian>() isn't really much worse (only 2 characters! (not really...)) The benefit of the latter is consistency and explicitness.
That concern aside, I do like your suggested use of endian_cast with the endian_wrapper type.
I'm just glad any of it made sense at all. I'd rather have you disagree with some of it than not understand what I was trying to say. Tony