On Tue, Jun 8, 2010 at 11:13 AM, Gottlob Frege <gottlobfrege@gmail.com> wrote:
On Tue, Jun 8, 2010 at 10:39 AM, Gottlob Frege <gottlobfrege@gmail.com> wrote:
- so am I suggesting a base endian type that can't even be read? Possibly.
big_endian_int j = from_big_endian_file(); int i = endian_cast<int>(j); // OK
int k = from_big_endian_file(); int i = endian_cast<int>(k); // FAILS - not sure endian type for k
but then allow specifying the type for k:
int i = endian_cast<int, big_endian_int>(k); // OK - k is reinterpreted as big_endian_int
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.
Tony
I think what I am saying is that, conceptually at least, the endian-types come first, and the straight functions are built on top of that (instead of the other way around as most are suggested). Now, I wouldn't want that to impact performance, which is why I say 'conceptually'. We can specialize the heck out of everything so that performance wins, but I think the conceptual foundation is important. Which is to say that an int that is in the wrong endian order isn't really an int, conceptually. So we should avoid that. Conceptually. :-) And I'm thinking that base endian-type should be unreadable on its own. This enforces type-safety *and* performance. From that base type you can then choose the function-style code or a derived type that has readability and/or operators. We should be allowed to swap in place, etc, but the framework should make it clear that you are doing something like a reinterpret-cast. To be clear, the function-style doesn't need to start with an endian-type, but the functions take endian types - which can appear in the <> brackets, so that you don't have to actually have endian-types. ie hopefully we can allow you to do whatever you want, but at the same time get the benefit of type-safety and performance, and a consistent interface to it all. ie it is more of a spectrum or more/less typish, than a this or that divide, to me at least. Tony