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

Subject: Re: [boost] [type_erasure] Review started (July 18-27, 2012)
From: Julien Nitard (julien.nitard_at_[hidden])
Date: 2012-07-23 11:56:07

Hi Guys,

Let me add to the list of questions, below (I don't want to start a
N-th thread,  if this is inappropriate please let me know):

Julien

On Tue, Jul 24, 2012 at 12:31 AM, Andrey Semashev
<andrey.semashev_at_[hidden]> 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. 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?

My 2cts: I think this is because the return type depends on the 2nd
operand in the most general case.

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

6. I think it's not possible to define a basic concept with two
function at once. This should be mentioned somewhere that one "basic"
concept is equivalent to one operation. Actually, the whole idea of
"basic" concept and composed concept could deserve much more details
in a theoretical section, separate from the practice. This is
important because people will try mapping the techniques they know
(i.e. abstract class / interfaces) to what is in TypeErasure and there
is a big difference : for concept-based polymorphism you don't start
by the parent concept, you start by it's functions and then you
compose them back.