Re: [boost] [type_erasure] Review started (July 18-27, 2012)

Subject: Re: [boost] [type_erasure] Review started (July 18-27, 2012)
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-07-23 12:40:01

AMDG

On 07/23/2012 08:31 AM, Andrey Semashev wrote:
> About conversion between different "any" types, I've found a note in the docs 
> that says it's possible. Disregard the question in my previous email.
> 
> Some more thoughts:
> 
> 1. In the docs, "Functions with Multiple Arguments", it is said that the 
> underlying types of the two "any" arguments must match or the behavior is 
> undefined. I assume this is due to the fact that the type_id_ concept is 
> optional and the implementation doesn't really know the underlying types of 
> the "any" values and simply assumes they match. I think this is a too dagerous 
> assumption and some basic check must always be performed.

I thought I had an assertion, but it looks like I
missed that.

> Probably, the 
> underlying type information must always be stored in one way or another and 
> verified when needed. Maybe, the type_id_ concept must be mandatory even.
> 

relaxed_match causes an exception to be thrown.

> 2. In the same section, I didn't really understand the second code snippet. 
> Why is the tuple needed? Why not this:
> 
>  any<requirements, _a> a = &array[0];
>  a = a + 2;
> 
> Also, from the implementation perspective, will it simply add 2 to the pointer 
> or construct an "any" from 2 and then perform the addition?
> 

This doesn't work.  There are two placeholders, _a
and _b.  When we create an any, we have to know
the types that all the placeholders bind to.

> 3. Are there plans to make the underlying value storage customizable? It would 
> be great if "any" supported small object optimization or custom memory 
> allocators.
> 

Yes.  I intentionally avoided trying to
optimize the library

> 4. How can I test if an "any" instance is null? I assume that I cannot compare 
> the instance with a default-constructed "any" because this would result in 
> attempt to compare stored values.
> 

typeid_of(a) == typeid(void)

> 5. The "Why do I have to specify the presence of a destructor explicitly?" 
> rationale doesn't seem like a good enough reason. The code already has a 
> specialization for references, and it is natural that references are stored as 
> a pointer to the external value (I really hope there are no dynamic memory 
> allocations performed in this case).

There is no memory allocation.

> So for references, there is no need to 
> call a destructor of the object at all. On the other hand, I can't imagine an 
> "any" with an object by value which cannot be destructed.
> 

The point is interface consistency.
The requirements on the contained type
can be determined solely from the Concept.
If the destructor were implicitly
added in some cases but not others,
it would cause a lot of problems.

In Christ,
Steven Watanabe