Re: [boost] [endian] Refresh based on comments received

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-06-08 12:51:09

Gennaro Prota wrote:
> On Sun, 04 Jun 2006 16:34:38 -0400, Beman Dawes <bdawes_at_[hidden]>
> wrote:
> 
>> A refresh of the .zip file for the Endian library, based on comments 
>> received so far, is available at 
>> http://mysite.verizon.net/~beman/endian-0.2.zip
>>
>> The docs are online at 
>> http://mysite.verizon.net/~beman/endian-0.2/libs/endian/index.html
>>
> 
> Hi Beman,
> 
> I had a quick look and hope to do a more careful analysis in the next
> days. Nonetheless I have some not very useful comments:
> 
> * as far as I know (I have been absent from the list for long time, so
> please correct me if this has changed again) the license reference
> text we use now doesn't contain "use, modification, and distribution",
> despite what http://www.boost.org/more/lib_guide.htm says. The adopted
> version is the one reported at
> http://www.boost.org/more/license_info.html

Fixed. lib_guide.htm corrected, too.

> * there is no guarantee that an unsigned char has 8 bits...

The C and C++ standards specify char, signed char, and unsigned char all 
have exactly 8 bits, AFAIK.

> * I fear I'm missing something but does unrolled_byte_loops really
> "unroll" loops at compile time? It seems to me it just uses (run-time)
> recursion.

The depth of recursion is controlled at compile time. The runtime calls 
are presumably optimized away by inlining. You would have to look at the 
generated code and/or run some tests to see if there is any abstraction 
penalty.

In any case, that is an implementation detail, as indicated by being in 
namespace detail. It can be replaced with something else if need be.

> * integer_cover_operators initial section reports
> "integer_operations.hpp", presumably as filename,

Fixed.

 > and seem to have
> many superfluous includes.

Fixed.

 > The guard macro name also seems
> inconsistent.

Fixed.

> More importantly, is it intentional that stream input
> and output only consider ostream and istream (no wide versions, no
> templates, etc.)?

Yep, that needs to be fixed. I suspect the current version reflects 
compiler problems cica 1999. I've added a "TODO" comment to the code in 
case so it won't be forgotten in case I don't get to it right away.

> * (minor) the example omits fclose()

It was omitted for brevity. I've now added it.

> * though the Wikipedia article seems to be, at the time I'm writing,
> in a decent state, it might easily degrade in the future (I've
> experience this myself; no ranting :)); OTOH we can't include it into
> the boost files, due to the Wikipedia license. It might be worth
> writing something ourselves, at least in the long run, or link to a
> specific version of it, with a word of caution that any newer versions
> have not been verified by the boost members.

Yes, reference to the Wikipedia in docs is something we need to discuss. 
The articles are often extremely well written and authoritative, and it 
save a lot of work (and then later maintenance) to link to them. But as 
you say, we have no way to know if an article might degrade in the future.

My current feeling is that the advantages of linking to a well-written 
Wikipedia entry outweigh the disadvantages, but it is an open question 
that other Boosters need to think about.

Thanks for the comments and corrections!

--Beman