Re: [Review] UUID library (mini-)review starts today, November 23rd

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Review] UUID library (mini-)review starts today, November 23rd

Here goes my little review:

- What is your evaluation of the design?

I like the overall design of the library. However, I think that the library 
should be better templatized by the string class and
document the string concept it uses. This would allow users of the library 
to switch to another string class implementation
compatible with the used string concept (std::string). For convenience it 
could provide a typedef for the std::string class.

IMHO, the library would be more useful if it provides an interface for 
generating uuids with different technologies:
    - random number generator
    - time based, MAC
    - OS
Different use cases may have different constraints a generator must 
fullfill. To be useful the library should document
the differences between the generators. It should especially doucument the 
guarantees that the different generators
provide (security, speed, memory consumption, ...).

That said, I do not think that the library should be rejected for missing of 
actual generators. It should solely provide
an interface which allows later contributers to add new uuid generators. I 
would however, appreciate at least the
OS generator case.

- What is your evaluation of the implementation?

Clean and readable. I'm fine with it.

- What is your evaluation of the documentation?

I think that it should give a little more background about the generator 
algorithm it uses. Additionally, given that
there are different generators provided, I would like to see a comparsion in 
the performance and security domain.

- What is your evaluation of the potential usefulness of the library?

This is (at least for me) a must have library. Boost should have such a 
component.
It is an usefull library in the form it exists today.

-  Did you try to use the library?  With what compiler?  Did you have any 
problems?

I'm using the library already in our CAD application. It works fine for us. 
We use the MS vc9 sp1 compiler.
Currently, we do  not have any problems with the library.

- How much effort did you put into your evaluation? A glance? A quick 
reading? In-depth study?

Some time.

- Are you knowledgeable about the problem domain?

Hmm, no not really. I'm a user and I do need such a component with a simple, 
stable interface.

I vote Yes, to include the UUID library in Boost.

Regards,
Johannes

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [Review] UUID library (mini-)review starts today, November 23rd

> The library can be downloaded from the vault here (it's the file
> uuid_v13.zip in the topmost directory): http://tinyurl.com/6xx28b

This link didn't work for me.  Is there a problem with it?

Dave Jenkins

Re: [Review] UUID library (mini-)review starts today, November 23rd

> -----Original Message-----
> From: boost-bounces <at> lists.boost.org [mailto:boost-bounces <at> lists.boost.org]
On
> Behalf Of Hartmut Kaiser
> Sent: 24 November 2008 00:14
> To: boost <at> lists.boost.org; boost-users <at> lists.boost.org; boost-
> announce <at> lists.boost.org
> Subject: [boost] [Review] UUID library (mini-)review starts today,
November 23rd
> 
> The mini-review of Andy Tompkins UUID library starts today, November 23rd
> 2008, and will end on November 30th.
> I really hope to see your vote and your participation in the discussions
on
> the Boost mailing lists!
> 
> The library can be downloaded from the vault here (it's the file
> uuid_v13.zip in the topmost directory): http://tinyurl.com/6xx28b
> 
> The initial review of the UUID library ended with a provisional acceptance
> (read here: http://article.gmane.org/gmane.comp.lib.boost.user/27774/).

Re-reading the docs, I can't see any reasons against acceptance.

Nits:

I note that the docs uuid.html copyright date is still only 2006.

And it does not list/link all the tests.

Mis spelling of 'hexidecimal'

The external representation of a uuid is a string of hexidecimal digits

Note: boost::uuids::uuid::size() always returnes 16.
Mispelled 'returnes'

Is there a reason why create does not also take a std::string (with default
length .size() as parameter?)
    // Static functions
    static uuid create(uuid const& namespace_uuid, char const* name, int
name_length);

I assumed it would exist and was surprised when it didn't.

(Should the name_length have a default value? C-string size - 1?)

I also believe that a really basic example would be useful.  This helps
novices.

A little demo I knocked up quickly attached.  (MSVC 8 Sp1)

It reveals that the hated 4996 warnings are triggered (at default MS warning
level 3).
I think these need to be suppressed with push'n'popping.

Also I got a faceful of these at warning level 4. Again they should be
suppressed.
1>I:\boost_1_37_0\boost/random/detail/pass_through_engine.hpp(49) : warning
C4512:
'boost::random::detail::pass_through_engine<UniformRandomNumberGenerator>' :
assignment operator could not be generated

1>H:\uuid\boost/uuid/uuid.hpp(364) : warning C4244: '=' : conversion from
'int' to 'char', possible loss of data

Should be silenced using a static_cast?

        c = static_cast<ch>(is.peek());

But overall this seems 'OK to ship'.

HTH

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal, UK   LA8 8AB
+44 1539 561830, mobile +44 7714330204
pbristow <at> hetp.u-net.com

//  Copyright Paul A. Bristow.
//  Permission to copy, use, modify, sell and
//  distribute this software is granted provided this copyright notice appears
//  in all copies. This software is provided "as is" without express or implied
//  warranty, and with no claim as to its suitability for any purpose.

// Distributed under the Boost Software License, Version 1.0. (See
// accompanying file LICENSE_1_0.txt or copy at
// http://www.boost.org/LICENSE_1_0.txt)

//  libs/uuid/example/example.cpp  -------------------------------//

#define _CRT_SECURE_NO_WARNINGS
// h:\uuid\boost\uuid\seed_rng.hpp(132) : warning C4996: 'fopen':
// This function or variable may be unsafe. Consider using fopen_s instead.
// To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
// c:\program files\microsoft visual studio 9.0\vc\include\stdio.h(237) :
// see declaration of 'fopen'
#define _SCL_SECURE_NO_WARNINGS 

#include <boost/uuid/uuid.hpp>
#include <boost/uuid/seed_rng.hpp>
#include <iostream>
#include <string>
#include <vector>

using std::cout;
using std::endl;
using std::string;
using std::vector;
using std::copy;
using std::ostream_iterator;

int main()
{
  using boost::uuids::uuid;
  using boost::uuids::uuid_generator;
  using boost::uuids::showbraces;
  using boost::uuids::noshowbraces;

  uuid u; // Default constructor makes a null string - boring!
  cout << u << endl; // 00000000-0000-0000-0000-000000000000
  if (u.is_null())
  {
    cout << "uuid is null!" << endl; // uuid is null!
  }
  // Create from a std string.
  string s1("01234567-89ab-cdef-0123-456789abcdef");
  uuid us1(s1);
  cout << us1 << endl; // 01234567-89ab-cdef-0123-456789abcdef
  // Or a C string.
  const char* s2 = "{76543210-89ab-cdef-0123-456789abcdef}";
  uuid uc1(s2);
  cout << uc1 << endl; // 76543210-89ab-cdef-0123-456789abcdef
  // and also show {} braces around string.
  cout << showbraces << uc1 << endl; // {76543210-89ab-cdef-0123-456789abcdef}
  cout << uc1 << endl; // {76543210-89ab-cdef-0123-456789abcdef}

  // Get at the UUID individual bytes.
  vector<char> v(u.size()); // Always 16.
  copy(us1.begin(), us1.end(), v.begin());
  cout << "Length in bytes is " << v.size() << ", and values are: " << endl;
  for (int i = 0; i < 16; i++)
  {
    cout << int(v[i]) << " ";
  } // 1 35 69 103 -119 -85 -51 -17 1 35 69 103 -119 -85 -51 -17
  cout << endl; 

  // Create uuid from name.
  uuid dns_namespace_uuid("6ba7b810-9dad-11d1-80b4-00c04fd430c8");
  const char* url = "www.boost.org";
  uuid uurl = boost::uuids::uuid::create(dns_namespace_uuid, url, 13);
  cout << uurl << endl;
  string suurl = uurl.to_string(); 
  cout << suurl << endl; // ccb046db-74eb-53c9-9b6b-3ce5740dd29e

  // Generate uuid from random number, different every time.
  uuid_generator ur; //
  cout << showbraces << ur() << endl; // {f850857f-86cb-4518-ba45-c826aac45a03}
  cout << ur() << endl; // {b04004aa-c261-4a91-a79f-357d71780d0c}
  cout << ur() << endl; // {b305b7e1-80ef-4fa9-beed-c26b86a08cbb}
  // Note showbraces 'sticks' until noshowbraces.
  cout << noshowbraces << ur() << endl; // b305b7e1-80ef-4fa9-beed-c26b86a08cbb
  uuid u1 = ur();
  uuid u2 = ur();
  if (u1 == u2)
  {
    cout << "Ooops - UUIDs should be unique!" << endl;
  }

} // int main()

/*

Output:

1>Autorun "h:\uuid\libs\uuid\Example\Example\Debug\Example.exe"
1>00000000-0000-0000-0000-000000000000
1>uuid is null!
1>01234567-89ab-cdef-0123-456789abcdef
1>76543210-89ab-cdef-0123-456789abcdef
1>{76543210-89ab-cdef-0123-456789abcdef}
1>{76543210-89ab-cdef-0123-456789abcdef}
1>Length in bytes is 16, and values are: 
1>1 35 69 103 -119 -85 -51 -17 1 35 69 103 -119 -85 -51 -17 
1>{ccb046db-74eb-53c9-9b6b-3ce5740dd29e}
1>ccb046db-74eb-53c9-9b6b-3ce5740dd29e
1>{d0b211fd-6e42-4112-8270-dd470f0ccb08}
1>{6fa9bc27-ee4b-4d52-ac83-0868e94698ab}
1>{9fc020e5-54ea-4e42-b716-7b8c89e5b5f0}
1>b3e3936b-e6f1-4909-915a-8c7a4aba76a6
1>Build Time 0:02

*/

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [Review] UUID library (mini-)review starts today, November 23rd

Hi there,

>
> Please always state in your review, whether you think the library should be
> accepted as a Boost library!

I vote for acceptance.

>
> Additionally please consider giving feedback on the following general
> topics:
>
> - What is your evaluation of the design?

The design I like and fits into my world of c++ programming.

> - What is your evaluation of the implementation?

Looks good. I like the programming style. I would recommend to clean
up the files, in particular the commented out headers. Also, the
file uuid_serialize.hpp contains only commented out code besides the
macro instantiation. Is that functionality working?

How about having a uuid_all.hpp header?

> - What is your evaluation of the documentation?

Good.

> - What is your evaluation of the potential usefulness of the library?

Huge. We are using UUID's a lot and this library seems to be a good
candidate for the next code refactoring.

> - Did you try to use the library?  With what compiler?  Did you have any
> problems?

Yes, I compiled the test program which Paul Bristow posted and it
worked without a glitch. I'm using Visual Studio 8.

> - How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?

A quick reading.

> - Are you knowledgeable about the problem domain?

I'm a user.

Thanks for another very useful lib.

Christian

Re: [Review] UUID library (mini-)review starts today, November 23rd

> The mini-review of Andy Tompkins UUID library starts today, November
> 23rd 2008, and will end on November 30th.

i just did a quick compile/testsuite test for now,  and i see three 
trivial issues:

1. it doesn't compile with gcc-4.4, because of a missing include.
patch:
--- a/boost/uuid/seed_rng.hpp
+++ b/boost/uuid/seed_rng.hpp
@@ -26,6 +26,7 @@
 #include <memory.h>^M
 #include <ctime>^M
 #include <cstdlib>^M
+#include <cstdio>^M
 #include <boost/uuid/sha1.hpp>^M
 //#include <boost/nondet_random.hpp> //forward declare boost::random_device^M
 ^M

2. the testsuite fails on x86_64 because it is using hardcoded 32-bit 
hash values:
Running 1 test case...
libs/uuid/test/test_uuid.cpp(146): error in "test_main_caller( argc, argv )": check
uuid_hasher(uuid()) == 3565488559U failed [17562157925649023279 != 3565488559]
libs/uuid/test/test_uuid.cpp(147): error in "test_main_caller( argc, argv )": check
uuid_hasher(u1) == 4159045843U failed [6622376135548557651 != 4159045843]
libs/uuid/test/test_uuid.cpp(148): error in "test_main_caller( argc, argv )": check
uuid_hasher(u2) == 2713274306U failed [4700797755868797762 != 2713274306]

*** 3 failures detected in test suite "Test Program"

3. the sources use cr+lf eol style, i guess correctly importing the
sources into subversion will fix this

maybe i find some time to do a full review later this week. anyway, 
i have been using the library for quite some time and would like to 
see it being part of boost. thus i vote for acceptance.

cheers, tim

--

-- 
tim <at> klingt.org
http://tim.klingt.org

The composer makes plans, music laughs.
  Morton Feldman

Re: [Review] UUID library (mini-)review starts today, November 23rd

Hartmut Kaiser wrote:
> - What is your evaluation of the design?
> - What is your evaluation of the implementation?
> - What is your evaluation of the documentation?
> - What is your evaluation of the potential usefulness of the library?
> - Did you try to use the library?  With what compiler?  Did you have any
> problems?
> - How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?
> - Are you knowledgeable about the problem domain?
> 
> Regards Hartmut
> Review Manager

Herewith my non-exhaustive review:

I've looked at the library, good work, it looks very interesting. I did a
quick reading, and in particular, I paid attention to the many of its
intended uses (in the Rationale), and how this would have to be done in
practice (the Interface).

 * The design notes state that it is based on X.667-E. This document
describes three construction mechanisms: time-based, rng-based, and
string-based. The proposal doesn't have the time-based constructor. Is
there a reason why this is missing?
 * Is the boost namespace that cluttered that it isn't possible to
hold "boost::uuid" in it? I think boost::uuids::uuid is kind of repetitive.
(Or is there a policy against putting stuff in the boost root-namespace?)
 * Construction is described in "Constructors" and "Construction" -- this
could perhaps lead to confusion?
 * In Representation: Is there a reason for a .to_string() member function
instead of an operator std::string()? I.e., it reduces std::string s =
u.to_string() to std::string s( u );
 * Considering the examples in the Rationale and the available constructors:
I'm curious how to easily "tag an object" using the provided constructors.
By a random number? Or could I just pass the address of the object and use
a string-based method? In other words, it would be nice if such an example
from the Rationale would be topic of an example.

I vote for acceptance into boost, given that just a bit more attention is
paid to a potential user's convenience. 

Kind regards,

Rutger

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [Review] UUID library (mini-)review starts today, November 23rd

> - What is your evaluation of the design?

I like the design, but wish it had time-based UUIDs.

> - What is your evaluation of the implementation?

I had no problem reading the code.  But there's almost nothing in 
"uuid.ipp".  Could you merge it into "uuid.hpp" for simplicity?

> - What is your evaluation of the documentation?

I'd like to see the Rationale section come first, before you give the whole 
Class Synopsis. That would make it easier for casual readers to understand 
the purpose of the library before reading further.

A small example program near the beginning of the document would help too.

There is a spelling error in the Rationale section, s/indended/intended/.

> - What is your evaluation of the potential usefulness of the library?

It's a nice addition to Boost.

> - Did you try to use the library?  With what compiler?  Did you have any 
> problems?

Yes, I tried running some test code and had no problems.

I vote Yes, to include the UUID library in Boost.

Regards,
Dave Jenkins 

Re: [Review] UUID library (mini-)review starts today, November 23rd

AMDG

Hartmut Kaiser wrote:
> The mini-review of Andy Tompkins UUID library starts today, November 23rd
> 2008, and will end on November 30th. 
> I really hope to see your vote and your participation in the discussions on
> the Boost mailing lists!
>   

I only saw a couple of issues:

uuid::get_showbraces_index() is not reentrant
(there is a race the first time it is called.)

operator<< doesn't handle setw.
operator>> ignores spaces.  Is this intended?

In Christ,
Steven Watanabe

Re: [Review] UUID library (mini-)review starts today, November 23rd

Hi boosters,

First of all, my opinion is that this kind of classes, sometimes called
concrete types, are the very plus plus suggested by the language's name. A
well designed user type behaves and cost, exactly the same as any built in
type. This makes C++ unique in the plethora of available languages.
That said, I must mention that I am aware of the flaws pointed out by many
reviewers, specially those concerning interface. In particular, I don't like
the "default null constructor". For me, the default constructor MUST
generate a valid object, period. I have already copied/used Andy's code,
which I luckily found in your vault, and one thing I changed was this
default constructor [uuid_t uuid; // generates a valid random uuid]. If the
user is short of resources, she must use the copy constructor [uuid_t
nil(uuid_t::null());]. But I don't provide a bool is_null() const; method,
for operator==() does the job pretty well.
Despite this weaknesses, I think the library is ready for out-of-the-box
usage, so my vote is YES, this library should be part of boost.

Sincerely,
Kenneth

--

-- 
View this message in context: http://www.nabble.com/-Review--UUID-library-%28mini-%29review-starts-today%2C-November-23rd-tp20652849p20807056.html
Sent from the Boost - Users mailing list archive at Nabble.com.

Re: [Boost-announce] [Review] UUID library (mini-)review starts today, November 23rd

[Sorry for the lateness.  Haven't looked at any other reviews yet.]

On Nov 23, 2008, at 7:13 PM, Hartmut Kaiser wrote:

> The mini-review of Andy Tompkins UUID library starts today,  
> November 23rd
> 2008, and will end on November 30th.
> I really hope to see your vote and your participation in the  
> discussions on
> the Boost mailing lists!
>
> The library can be downloaded from the vault here (it's the file
> uuid_v13.zip in the topmost directory): http://tinyurl.com/6xx28b
>
> The initial review of the UUID library ended with a provisional  
> acceptance
> (read here: http://article.gmane.org/gmane.comp.lib.boost.user/ 
> 27774/).
>
> This mini review is meant to allow for a final decision after  
> looking at the
> changed parts of the library. Here is a list of things fixed and  
> changed:
>
> - fixed the licensing issues revealed by the initial review
> - fixed the security vulnerability revealed by the initial review
> - renamed to uuid, moved all classes, functions, etc. to namespace
> boost::uuids
> - implemented sha1 hash function (thus no license problem)

Others, including myself, are working on encoding libraries.  If this  
library, and an encoding library are added, we could change the  
implementation to use the new encoding library.

> - new class basic_uuid_generator to create random-based uuids.  The  
> random
> number generator is no longer hard coded.  It can use any random  
> number
> generator, default is boost::mt19937
> - implemented a good seed function for random number generators
> - all functions are now reentrant, all classes are as thread safe  
> as an int
> and the library is no longer dependent on Boost.Thread
>
> ---------------------------------------------------
>
> Please always state in your review, whether you think the library  
> should be
> accepted as a Boost library!

Yes, please accept it.

>
> Additionally please consider giving feedback on the following general
> topics:
>
> - What is your evaluation of the design?

Why is there a container interface for inspecting the value's  
octets?  For a similar problem in my code (the MD5 stuff in the  
Sandbox SVN), I defined a copying-out member function template that  
takes an output iterator and returns the updated version of same.   
You could do that, making sure to define some (compile-time) item  
indicating the length (16), to facilitate easier changes to internal  
storage.

Don't some operating systems provide UUID generation?  Could there be  
a way to add a creation function that uses the OS's code?

Is default construction useful besides when initialization can't be  
done in one step? Instead of an "is_null" member function, maybe  
(pseudo-)Boolean conversion (and "operator not") can be used.

I don't think the multitude of string conversion techniques are  
needed.  Keep the constructor with "char const *" for pseudo- 
literals.  Everything else, in either direction, could use  
"lexical_cast".

> - What is your evaluation of the implementation?

The "generator_iterator" substitute in "seed_rng.hpp" doesn't  
completely help.  It is supposed to improve on the version in "boost/ 
generator_iterator.hpp" in the area of end-iterator support.  I  
originally said more here, but I erased it because when I filed a  
ticket on this issue, I found one already (#2428) and put my notes  
there.

The implementation of the constructor that takes a byte-returning  
input-iterator shows why we need a double-bounded copy algorithm.   
(Now in new ticket #2578.)

The copy constructor, destructor, and copy-assignment operator don't  
do anything different than the automatically-defined versions would.   
So they could be omitted.

Maybe the "create_name_based" and "get_showbraces_index" member  
functions need to be in a new mandatory source file.  If so, you  
could move some common error strings there too.  BTW, why do  
"create" (and "create_name_based") need the length based in as a  
separate argument?  Just use "std::strlen".

The I/O function templates could be tightened up some.  (I noticed it  
since I work on I/O quite a bit.  It could be done later.)  The  
optimization would be more important if my dump-most-of-the-string- 
conversions-for-lexical_cast idea is used.

Should the serialization be done in a separate header?  BTW, how is a  
custom primitive type handled?  Is it just a byte-level save/load of  
memory?  (What if the type isn't POD, like this one?)

> - What is your evaluation of the documentation?

It's adequate, but maybe detailed Doxygen information on each item  
should be added.

> - What is your evaluation of the potential usefulness of the library?

It can be useful for (temporary) IDs.  We have to make sure that the  
type, especially its object representation, doesn't get heavy (i.e.  
stay quasi-POD).

> - Did you try to use the library?  With what compiler?  Did you  
> have any
> problems?

I used it on Mac OS X 10.4 (PowerPC) with XCode.  All the tests, and  
Paul Bristow's example, seemed to work.

> - How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?

Two days of reading and trying out the code.  Not too much of the  
theory, though.

> - Are you knowledgeable about the problem domain?

Not really.

--

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com

Re: [Boost-announce] [Review] UUID library (mini-)review starts today, November 23rd

[Sorry for the lateness.  Haven't looked at any other reviews yet.]

On Nov 23, 2008, at 7:13 PM, Hartmut Kaiser wrote:

> The mini-review of Andy Tompkins UUID library starts today,  
> November 23rd
> 2008, and will end on November 30th.
> I really hope to see your vote and your participation in the  
> discussions on
> the Boost mailing lists!
>
> The library can be downloaded from the vault here (it's the file
> uuid_v13.zip in the topmost directory): http://tinyurl.com/6xx28b
>
> The initial review of the UUID library ended with a provisional  
> acceptance
> (read here: http://article.gmane.org/gmane.comp.lib.boost.user/ 
> 27774/).
>
> This mini review is meant to allow for a final decision after  
> looking at the
> changed parts of the library. Here is a list of things fixed and  
> changed:
>
> - fixed the licensing issues revealed by the initial review
> - fixed the security vulnerability revealed by the initial review
> - renamed to uuid, moved all classes, functions, etc. to namespace
> boost::uuids
> - implemented sha1 hash function (thus no license problem)

Others, including myself, are working on encoding libraries.  If this  
library, and an encoding library are added, we could change the  
implementation to use the new encoding library.

> - new class basic_uuid_generator to create random-based uuids.  The  
> random
> number generator is no longer hard coded.  It can use any random  
> number
> generator, default is boost::mt19937
> - implemented a good seed function for random number generators
> - all functions are now reentrant, all classes are as thread safe  
> as an int
> and the library is no longer dependent on Boost.Thread
>
> ---------------------------------------------------
>
> Please always state in your review, whether you think the library  
> should be
> accepted as a Boost library!

Yes, please accept it.

>
> Additionally please consider giving feedback on the following general
> topics:
>
> - What is your evaluation of the design?

Why is there a container interface for inspecting the value's  
octets?  For a similar problem in my code (the MD5 stuff in the  
Sandbox SVN), I defined a copying-out member function template that  
takes an output iterator and returns the updated version of same.   
You could do that, making sure to define some (compile-time) item  
indicating the length (16), to facilitate easier changes to internal  
storage.

Don't some operating systems provide UUID generation?  Could there be  
a way to add a creation function that uses the OS's code?

Is default construction useful besides when initialization can't be  
done in one step? Instead of an "is_null" member function, maybe  
(pseudo-)Boolean conversion (and "operator not") can be used.

I don't think the multitude of string conversion techniques are  
needed.  Keep the constructor with "char const *" for pseudo- 
literals.  Everything else, in either direction, could use  
"lexical_cast".

> - What is your evaluation of the implementation?

The "generator_iterator" substitute in "seed_rng.hpp" doesn't  
completely help.  It is supposed to improve on the version in "boost/ 
generator_iterator.hpp" in the area of end-iterator support.  I  
originally said more here, but I erased it because when I filed a  
ticket on this issue, I found one already (#2428) and put my notes  
there.

The implementation of the constructor that takes a byte-returning  
input-iterator shows why we need a double-bounded copy algorithm.   
(Now in new ticket #2578.)

The copy constructor, destructor, and copy-assignment operator don't  
do anything different than the automatically-defined versions would.   
So they could be omitted.

Maybe the "create_name_based" and "get_showbraces_index" member  
functions need to be in a new mandatory source file.  If so, you  
could move some common error strings there too.  BTW, why do  
"create" (and "create_name_based") need the length based in as a  
separate argument?  Just use "std::strlen".

The I/O function templates could be tightened up some.  (I noticed it  
since I work on I/O quite a bit.  It could be done later.)  The  
optimization would be more important if my dump-most-of-the-string- 
conversions-for-lexical_cast idea is used.

Should the serialization be done in a separate header?  BTW, how is a  
custom primitive type handled?  Is it just a byte-level save/load of  
memory?  (What if the type isn't POD, like this one?)

> - What is your evaluation of the documentation?

It's adequate, but maybe detailed Doxygen information on each item  
should be added.

> - What is your evaluation of the potential usefulness of the library?

It can be useful for (temporary) IDs.  We have to make sure that the  
type, especially its object representation, doesn't get heavy (i.e.  
stay quasi-POD).

> - Did you try to use the library?  With what compiler?  Did you  
> have any
> problems?

I used it on Mac OS X 10.4 (PowerPC) with XCode.  All the tests, and  
Paul Bristow's example, seemed to work.

> - How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?

Two days of reading and trying out the code.  Not too much of the  
theory, though.

> - Are you knowledgeable about the problem domain?

Not really.

--

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost