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

Subject: Re: [boost] [type_erasure] Review started (July 18-27, 2012)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-07-23 11:31:42

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. 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.

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?

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.

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.

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). 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.