Terry Golubiewski wrote:
Robert Stewart wrote:
Terry Golubiewski wrote:
(Since buf is a void * in the snipped code, static_cast would work for your casts, too.)
'buf' must be a pointer to "something". The void* is just masking what is really analagous to a reinterpret_cast. void* is just as ugly as reinterpret_cast. Maybe more so.
Data read from disk is untyped. Many APIs use void *, others char *. Either way, there's no useful type information. If you have a void *, you can use static_cast to another pointer type. If you have a char *, you must use reinterpret_cast to another pointer type (or two static_casts).
What bugs me is that 'buf' doesn't point to a 'T' yet. It points to a half-baked 'T'. Only after one calls swap_in_place() is the object really a 'T'.
That would apply to floating point, certainly. However, for integer types, your statement is false. Before the swap, they are still integers, they just don't have the desired value.
I disagree. Physically, they are compatible, but logically, they are different.
We're in violent agreement.
I think the logical view matters more.
I can't argue that point, but I don't think it signifies. In either case, the data read from disk is not usable until endianness has been addressed. Once it has, all remaining logic works with the appropriate type.
Even in the object-based approach, the object isn't a proper T until you access it and the swap occurs. The implicit swap veneer just gives you the impression that it is already in the desired form.
An endian<X, T> is not the same as a T. Even endian<native,T> must be converted to a T before you can operate on it. The veneer is important, because it works like a T, without actually being a T. I think that subtle distinction is important and is the primary motivation for type-based endian.
You've made a reasonable case. "Object-based" please.
I object to your use of the word "swap" though. My type-based approach does a reverse_copy, not a swap. This distinction is the fundamental topic of this discussion.
Perhaps you posted code that I was expected to have perused to know that your code did a reverse copy rather than a swap, but I didn't see such code or notice that it did so. However, a reverse copy is not always correct for changing endianness, though certainly so for changes between big and little endianness. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.