Quantcast

[poly_collection] throws upon insertion

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[poly_collection] throws upon insertion

Boost - Dev mailing list
Hi,
I am looking at the documentation of poly_collection. I will not be able to
thoroughly review and test the library. But judging from the documentation,
the problem is worth solving, and the approach to solve it is sound.

I have one question/observation though. I am trying to figure out how
preventing an incorrect insert() works. In the docs (
http://rawgit.com/joaquintides/poly_collection/website/doc/html/poly_collection/tutorial.html#poly_collection.tutorial.deeper_into_the_segmented_nature.type_registration)

it says that it will sometimes throw if it cannot determine the most
derived type.

In the class reference, I get:
(
http://rawgit.com/joaquintides/poly_collection/website/doc/html/poly_collection/reference.html#poly_collection.reference.polymorphic_containers.polymorphic_collections.modifiers
)

```
(1) c.insert(x)
(2) c.insert(it,x)

Effects: If the type of the subobject of t is not registered, then if this
type is T and T is acceptable, does the registration, otherwise throws. If
t is not a non-const rvalue expression and the type of its subobject is not
CopyConstructible, throws. Inserts an element with a subobject move
constructed or copy constructed from the subobject of t: (1) at the end of
the corresponding segment; (2) just before the position indicated by it, if
it points to the corresponding segment, or at the end of the segment
otherwise.

Returns: An iterator to the newly inserted element.

Complexity: Amortized constant time plus linear in the distance from the
insertion position to the end of the segment.
```

And maybe it is just me, but I cannot make the sense of it. First, it
refers to 't' but in the signatures we have an 'x'. Next, the first
sentence has two "if"s and one "otherwise" and I do not know which "if" the
"otherwise" binds to. I read it as saying: if T is derived from the
interface (like class `warrior`) but is not movable (which implies that T
is not "acceptable"), then the program will compile fine but will later
throw an exception. Is my interpretation correct? But if so, why not refuse
to compile instead?

Maybe it would be better tom make the prose longer in "Effects" clause, but
to make it harder for misinterpretation.

Regards,
&rzej;

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [poly_collection] throws upon insertion

Boost - Dev mailing list
El 08/05/2017 a las 16:55, Andrzej Krzemienski via Boost escribió:

> In the class reference, I get:
> [...]
>
> (1) c.insert(x)
> (2) c.insert(it,x)
>
> Effects: If the type of the subobject of t is not registered, then if this
> type is T and T is acceptable, does the registration, otherwise throws. If
> t is not a non-const rvalue expression and the type of its subobject is not
> CopyConstructible, throws. Inserts an element with a subobject move
> constructed or copy constructed from the subobject of t: (1) at the end of
> the corresponding segment; (2) just before the position indicated by it, if
> it points to the corresponding segment, or at the end of the segment
> otherwise.
>
> [...]
>
> And maybe it is just me, but I cannot make the sense of it. First, it
> refers to 't' but in the signatures we have an 'x'. Next, the first
> sentence has two "if"s and one "otherwise" and I do not know which "if" the
> "otherwise" binds to. I read it as saying: if T is derived from the
> interface (like class `warrior`) but is not movable (which implies that T
> is not "acceptable"), then the program will compile fine but will later
> throw an exception. Is my interpretation correct? But if so, why not refuse
> to compile instead?

First of all the 't' bit is indeed a typo, it should be 'x'. As for the
intended meaning of this
admittedly awkard clause, this is:

   1. If the type of the subobject of x is not registered, then:
     1.1. if T is acceptable, does the registration, otherwise throws.
   2. If x is not a non-const rvalue expression and the type of its
subobject is
     not CopyConstructible, throws.
   3. Inserts an element constructed or copy constructed from the
subobject of x, etc.

So, going to your example, consider

   boost::base_collection<sprite> c;
   warrior w; // warrior is not moveable
   c.insert(w);

This throws because the "real" (most derived) type of w is warrior and
warrior is
not acceptable: why not just mark this as a compile error? Because of
the following:

   boost::base_collection<sprite> c;
   moveable_warrior mw; // derived from warrior and moveable
   c.register_types<moveable_warrior>(); // fine, moveable_warrior can
be registered
   warrior& w=mw;
   c.insert(w); // works!!

Insertion is succesful because the real type of w is a valid (and indeed
registered)
type. So we can't just SFINAE-supress warrior from the overload set of
insert().
Did I make my self clear?

I can try to reword the reference sections into a more digestible form.
Thanks for
spotting the typo!

Joaquín M López Muñoz

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [poly_collection] throws upon insertion

Boost - Dev mailing list
2017-05-08 21:01 GMT+02:00 Joaquin M López Muñoz via Boost <
[hidden email]>:

> El 08/05/2017 a las 16:55, Andrzej Krzemienski via Boost escribió:
>
>> In the class reference, I get:
>> [...]
>>
>> (1) c.insert(x)
>> (2) c.insert(it,x)
>>
>> Effects: If the type of the subobject of t is not registered, then if this
>> type is T and T is acceptable, does the registration, otherwise throws. If
>> t is not a non-const rvalue expression and the type of its subobject is
>> not
>> CopyConstructible, throws. Inserts an element with a subobject move
>> constructed or copy constructed from the subobject of t: (1) at the end of
>> the corresponding segment; (2) just before the position indicated by it,
>> if
>> it points to the corresponding segment, or at the end of the segment
>> otherwise.
>>
>> [...]
>>
>> And maybe it is just me, but I cannot make the sense of it. First, it
>> refers to 't' but in the signatures we have an 'x'. Next, the first
>> sentence has two "if"s and one "otherwise" and I do not know which "if"
>> the
>> "otherwise" binds to. I read it as saying: if T is derived from the
>> interface (like class `warrior`) but is not movable (which implies that T
>> is not "acceptable"), then the program will compile fine but will later
>> throw an exception. Is my interpretation correct? But if so, why not
>> refuse
>> to compile instead?
>>
>
> First of all the 't' bit is indeed a typo, it should be 'x'. As for the
> intended meaning of this
> admittedly awkard clause, this is:
>
>   1. If the type of the subobject of x is not registered, then:
>     1.1. if T is acceptable, does the registration, otherwise throws.
>   2. If x is not a non-const rvalue expression and the type of its
> subobject is
>     not CopyConstructible, throws.
>   3. Inserts an element constructed or copy constructed from the subobject
> of x, etc.
>
> So, going to your example, consider
>
>   boost::base_collection<sprite> c;
>   warrior w; // warrior is not moveable
>   c.insert(w);
>
> This throws because the "real" (most derived) type of w is warrior and
> warrior is
> not acceptable: why not just mark this as a compile error? Because of the
> following:
>
>   boost::base_collection<sprite> c;
>   moveable_warrior mw; // derived from warrior and moveable
>   c.register_types<moveable_warrior>(); // fine, moveable_warrior can be
> registered
>   warrior& w=mw;
>   c.insert(w); // works!!
>
> Insertion is succesful because the real type of w is a valid (and indeed
> registered)
> type. So we can't just SFINAE-supress warrior from the overload set of
> insert().
> Did I make my self clear?
>
> I can try to reword the reference sections into a more digestible form.
> Thanks for
> spotting the typo!
>
> Joaquín M López Muñoz
>

Thanks for the explanation. I get it now. Could I suggest some rewording of
the description of insert. Maybe first define something like 'ad-hoc
registration':

'ad-hoc registration' of a reference `t` of a static type `T` into
> collection `c` is defined as follows:
> * If the dynamic type of `t` is already registered in `c`: nothing,
> otherwise
> * if the dynamic type of `t` is `T` and `T` is acceptable in `c`:
> registers `T`, otherwise
> * throws exception of type `unregistered_type`.
>

Then in the effects clause of `insert` just use it:

Effects: performs ad-hoc registration of `t` into `*this`. Then, If `t` is
> not a ...
>

Regards,
&rzej;

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [poly_collection] throws upon insertion

Boost - Dev mailing list
El 09/05/2017 a las 10:14, Andrzej Krzemienski via Boost escribió:

> Thanks for the explanation. I get it now. Could I suggest some
> rewording of
> the description of insert. Maybe first define something like 'ad-hoc
> registration':
>
> 'ad-hoc registration' of a reference `t` of a static type `T` into
>> collection `c` is defined as follows:
>> * If the dynamic type of `t` is already registered in `c`: nothing,
>> otherwise
>> * if the dynamic type of `t` is `T` and `T` is acceptable in `c`:
>> registers `T`, otherwise
>> * throws exception of type `unregistered_type`.
>>
> Then in the effects clause of `insert` just use it:
>
> Effects: performs ad-hoc registration of `t` into `*this`. Then, If `t` is
>> not a ...
>>

Thanks for the suggestion, I'll write something along that line.
("Dynamic type" can't be used
as the reference is common to all types of collections, and only
base_collection really uses
dynamic_cast).

Joaquín M López Muñoz

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Loading...