Re: [boost] [TypeErasure] Composing Concepts & some notes

Subject: Re: [boost] [TypeErasure] Composing Concepts & some notes
From: Fabio Fracassi (f.fracassi_at_[hidden])
Date: 2012-07-20 03:08:57

On 7/20/12 1:02 AM, Steven Watanabe wrote:
> AMDG
>
> On 07/19/2012 03:35 PM, Fabio Fracassi wrote:
>> I did not have to define a
>> concept_interface for the composite interface. Now the first question is
>> why would I want to?
>>
>
> Take a look at the iterator concepts.
> forward_iterator is a composite of
> several operators.  The specialization
> of concept_interface adds
> typedef std::forward_iterator_tag iterator_category;
>

This is the kind of information is exactly what should be added to the 
docu (close to the compositing example)

>
> It is documented in the reference.
> I agree that conversions deserve a
> separate section.  (There is a subsection
> of Design Notes detailing the different
> constructors)

Only speaking for myself, but the most important section in any 
documentation (pun not intended but gladly taken :D) is the tutorial 
section. I hardly ever use reference docu, because it is only useful to 
find out that last detail in a library you are already proficient in.
The tutorial is the advertising and beginners section, which tells me 
what the library can do for me and how it does so.
Also most reference docus only show me the dots and leave connecting to 
me, which can still be difficult if you don't know what the picture is 
supposed to look like.

The best documentations I have seen have a "mini tutorial" for each 
class (and sometimes even each member) in their reference section.
It shows a minimal, compilable, useful example on how the given entity 
is used.

>> Now I gather that there is no way to do the opposite, something along
>> the lines of
>> any_vecconcept acvec3 = dynamic_any_cast<any_vecconcept>(s3);
>> Well over the next days I will dive a bit deeper into the internals to
>> see if implementing such a feature would be feasible. (because I need it
>> before I could replace my current solution with type erasure)
>>
>
> It's possible in principle, but it would
> require extra global tables, some
> extensions to the binding interface,
> and some kind of registration mechanism.
>

Yes, I do understand this, and this is basically what I have in place, 
so I have to see what extensions to the binding interface it would take 
and If such an extension (or hooks for it) could be added to your 
library. I'll dive into this today.

regards

Fabio