Re: [boost] Formal Review: any

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-07 11:12:54

In message <Pine.SOL.4.21.0011021153390.10244-100000_at_philoctetes.lsc.nd.
edu>, Jeremy Siek <jsiek_at_[hidden]> writes
>Conclusion: I suggest the acceptance of library "any" to Boost.
> Its solve an important problem, the code looks good,
> and the documentation is thorough.

Thanks! Apologies for the delay in responding to what's gone up on the
list. I haven't had the chance to catch up with Boost for the last few
days. I will try to respond to points that have been raised.

>  One question: what's the relation between
>  class any and the class poly described in Dietmar's
>  paper? http://www.oonumerics.org/tmpw00/kuehl.html
>  I think the difference is that Dietmar used pointer syntax,
>  operator* and operator-> to provide access to the underlying
>  object... I'm not so sure that is a good idea.

Dietmar's poly<T>, like Peter Dimov's ref<T> IIRC, is anchored in a
specific type given by the template. poly<T> is intended to give value
semantics to objects of polymorphic type. any is intended to hold
arbitrarily (but knowingly) any value type w/o interpretation.

>  The predicate examples are confusing when you get to copy_to() and
>  to_ptr(). This is because these two functions have not yet been
>  introduced, and the predicate examples are basically using these
>  functions for their secondary purpose, not their primary purpose. It
>  would be better to first have examples that demonstrate the primary
>  purpose of these functions.

Agreed. This is a matter of documentation and a more complete worked
example. The predicate example is intended only to demonstrate syntax,
not common usage. I will work on a more compelling example that precedes
the predicates.

>  From what I can see, the MSVC_INCLUDE/MSVC_EXCLUDE is used to
>  workaround several different compiler bugs. It would be better to use
>  the bug-specific flag for each case instead of a compiler-specific
>  flag. This would make it easier to port to more compilers such as
>  Sun's C++.

Yes, this is intended to be a one-off, and the generalisation should be
pulled up into config.hpp when we are done.

>  In test.hpp line 11, use of "string" as a template parameter a but
>  confusing. How about "string_type" instead.

Agreed.

>  I got several errors of the following kind:
>
>  "test.hpp", line 40: error: exception specification for virtual function
>            "test::failure::what" is incompatible with that of overridden
>            function "std::exception::what"
>            virtual const char *what() const
>
>  The errors could be fixed by adding a throw():
>
>          virtual const char *what() const throw()

Oops! Thanks for spotting this one. Slight sloppiness on the part of the
author and the compilers he's been using :-}

>  This could be fixed by adding this destructor:
>
>          virtual ~failure() throw() { }

Ditto.

>  g++ doesn't provide <sstream> so I couldn't compile the test
>     using g++'s native headers. Would it be possible to
>     remove the use of <sstream> from the test?

Yes. I have migrated it to <strstream>, and that works out fine.

>Compiling for Sun WorkShop 6 2000/04/07 C++ 5.1
>===============================================
>
>  Lots of errors. I'd be willing to help port this once the
>  MSVC_INCLUDE macros get changed to bug-specific macros.

Great, thanks.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________