Re: [boost] [Review] Boost.Endian by BEman Dawes starts today

Subject: Re: [boost] [Review] Boost.Endian by BEman Dawes starts today
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-09-15 17:23:57

Hi Vicente,

There isn't time before the review ends to go into much detail, but
I'll try to answer a few of the easier questions:

On Thu, Sep 15, 2011 at 2:16 PM, Vicente J. Botet Escriba
<vicente.botet_at_[hidden]> wrote:

>>> The implicit conversion to the underlying type has the drawback that
>>> different endiannes will print always in native format. The library must
>>> overload the input and output operators, and as Beman has suggested add a
>>> facet and a some manipulators.
>>
>> I'll make sure printing issues are covered in the docs, and make sure
>> the tests cover these as actually delivered by the code.
>
> Could you tell us where you are related to i/o?

The binary I/O concerns seem to me to be best addressed by a bin() (or
binary(), or whatever name) function that looks like an I/O
manipulator. Boring, but it works. The other approaches (overloading
operators beyond << and >> to do binary I/O) were too hard to explain,
too error-prone, or both.

>> One issue is whether UDT's should "just work", or require some traits
>> helpers such as a way to get at the underlying type.
>>
>> I've just started to run tests on UDT's with the current code. So far,
>> it "just works". But that's without considering efficiency - knowing
>> more may be required to get reasonable performance.
>
> Could you show some examples?
> Have you tried with scoped enums in c++11?

Not yet.

>> I've already started work on a benchmark program, although it isn't
>> ready for prime time yet.
>
> Could you show your test now so we can test on other platforms?

Nothing ready just yet.

>>
>>> * Some examples reading a relatively complex data type (endian unaware)
>>> from
>>> a file, changing a field and then writing the data.
>>
>> Yes! That's the example I have in mind for the tutorial.
>
> Have you choosen already the data type?

I've been mentally working out an example of a program that just uses
built-in types for some record-oriented I/O.  Then, say, a requirement
arises for it to work portably. Maybe the boss bought some new servers
with different native endianness.

Then show how the program could be changed to use just endian
integers, then just endian buffers, then endian conversion functions.
And then a final version that uses a mixture of approaches.

Part of the example is timings; they show the motivation and rationale
for having multiple ways to handle endianness.

That approach would also meet the request for a timing or benchmark
program, since working versions of the example programs would be
provided.

>Could you show us, before the review
> ends, how the library will take care of conversions?

I don't really know yet! I think I'm going to develop the example
application described above, then try the conversion-oriented version
of it with several of the suggested approaches. If I was smarter, I
might be able to figure out ahead of time which was best. But I need
to see the code first.

> It would be great if you had time to give some details of how you see the
> evolution of your library before the review ends, otherwise we will have too
> much things to discuss/review during the the mini review.

Here is the rough sequence:

* Re-read all messages, and extract Acknowledgements and revise TODO list.
* Develop the use-cases example programs, applying revised conversion
functions. Iterate until happy.
* Apply the integers to the example programs, and also see if using
the revised conversion functions to implement some or all of the
integers.
* Apply mockups of the buffers to the example programs, to get a
firmer idea if the buffer idea actually seems to do be worthwhile in
practice.
* Post work-in-progress for feedback.
* Finalize and hold mini-review.

Thanks for the continued interest,

--Beman