[boost] Re: Formal review or Variant Library (Ed B.)

From: Ed Brey (brey_at_[hidden])
Date: 2003-02-19 13:17:52

Eric Friedman wrote:
> 
>> The area would be helped by renaming extract to access.
> 
> I tend to agree the name is confusing. So shall we call it
> boost::access<>? Input?

Dave A.'s comment that access is confusing because it is a noun and a verb is well taken.  Of course, the same can be said for extract. ;-)  Who designed English anyway, and how did it ever get ratified?  The suggestion to use the verbs (or are they nouns?) view and proxy do a good job reinforcing that you don't have a separate copy.  They are a step in the right direction.

> I don't think a member function really will solve the problem, but I do 
> agree the whole extract facility can be improved.

I agree the issues goes beyond member vs. free.  By the way, what is the motivation for using free over a member function?  Part of my motivation is because this following usage came to mind as a solution to the extract confusion:

T value = var.content<T>();  // Throws on type mismatch
T& ref = var.content<T&>();  // Throws on type mismatch
T* ptr = var.content<T*>();  // Returns null on type mismatch

The name "content" seems more nature here as a member function than it would as a free function.  Also, regardless of free or member, does such a syntax avoid ambiguity?

>> Finally, it wasn't clear to me why the return type for
>> which() wasn't unsigned.
> 
> It's not? I see that which() returns an unsigned int, which I believe is 
> the same as unsigned. (Am I wrong?)

The documentation in reference.html shows that which() returns int.  (I didn't check whether the code matched up.)

>> The destroyer class contains a function with an unreferenced
>> formal parameter, which triggers a warning under VC7.  Since
>> this a useful warning, all unreferenced formal parameters
>> should be removed (or commented out).
> 
> I'm not sure what parameter you're referring to. The only function in
> destroyer class is...
> 
>     template <typename T>
>     void operator()(const T& operand) const
>     {
>         operand.~T();
>     }
> 
> ...but certainly all formal parameters (i.e., operand) are referrenced
> in the function body.
> 
> What sort of warning are you getting from VC7?

You're right.  I didn't look carefully enough before to notice that this is clearly a bug in VC7.  It is reporting warning C4100 for the operator() function you mention above, if compiling at warning level 4.  I'll email this to Jason.  If you want to work around the bug, you can put the push, disable, pop pramgas around the function.  I checked that this works.

>> The copyright notice doesn't make clear that the copyright
>> notice need appear only in source code copies.
> 
> I'm not sure what you mean. Could you please explain?

One of the boost license requirements is this: Must not require that the license appear with executables or other binary uses of the library.

The copyright notice contains this clause: "provided that the above copyright notice appears in all copies".

To make it clear that a compiled program uses this library need not include the copyright notice, it would be good to change "copies" to "source code copies".

P.S. I just looked content up in the dictionary: it's a noun, verb, and adjective.  Sometimes you just can't win! :-)