On Thu, Sep 8, 2011 at 1:18 PM, Tomas Puverle < Tomas.Puverle@morganstanley.com> wrote:
Hi Beman,
- What is your evaluation of the design?
The design of the integer types seems reasonable to me, even though I would prefer not to have the overloaded operators on them. I feel that having the operators has the potential to break the boundary between program input and the program's processing. What do you I mean by that? Typically, I try to structure my programs as follows:
1) Read input data 2) Verify input invariants, construct internal representation 3) Process internal representation 4) Output result
The problem with having operators in the endian types is that they encourage the user to continue using them past the point 2).
I'm in complete agreement with you for large and/or performance critical programs need careful structuring. But not all programs are large and/or performance critical, so the convenience of having the full range of operations triumphs over other considerations. The conversion functions are available where the "input the data, do all the incoming byte reordering, do all the processing, do all the outgoing byte reordering, output the data" model is desired. But there can be other considerations. Program flow is sometimes chaotic, and then it become easy to become confused over which variables need to be reordered and which don't. The endian integer approach is much less error-prone in such situations.
However, as I said, that's my personal preference and last year plenty of people wanted to see the operators included. Perhaps they could be a policy?
endian<..., bool EnableOperators_ > ?
I'll give it some thought, but my initial reaction is that endian is already more complex than I like, so I'm leery of adding yet more complexity.
As for the rest of the library, I have the following comments:
- As many other people have mentioned, floating point support and user defined types are a must.
I think floating point is easily doable, although details haven't been worked out yet. Do you have an example of a UDT that you would like to see work? And what do you want it to work for? Both class endian and the conversion functions?
- I am happy that the "conversion functions" have been added, Unfortunately, I find them lacking in several departments: - (Note: I am going to try very hard not to get drawn into another naming discussion. That's pretty much what ended my efforts last year - 50 people commenting, each proposing a different set of names :D )
Understood:-) - While the endian types support unaligned data, the endian functions
don't appear to do so. I don't see how the endian types could be implemented using them.
Right. That would be a highly desirable addition.
- No support for user defined types, arrays/ranges of user defined types etc. This is extremely useful. A frequent example I come across is the following (using our syntax): //load a file into memory //... swapInPlace<BigToNative>(data.begin(), data.end());
Depending on the platform, that last statement may get compiled out to a no-op. This is also the big reason why our version of "reorder()" is not unconditional but depends on the "swap type".
Yep, that's why the conditional reodering functions are provided. The names are a serious impediment to understanding. Maybe they all should include "reorder" and "conditional" in the names for clarity. The other issue that has come up is the interface. A pure function (i.e. returning the new value) interface would allow use of std::transform. Not sure how that would play out with unaligned or unusual sized types, however. I'm glazing over, so will wait to reply to the rest of your comments. I'll also dig out your previous proposal and review the floating point issues you mention. Thanks! --Beman