Re: [boost] Interest in specialized types

Subject: Re: [boost] Interest in specialized types
From: Henning Basold (h.basold_at_[hidden])
Date: 2010-08-23 03:49:45

  Am 22.08.2010 21:22, schrieb Robert Ramey:
> Pierre Morcello wrote:
>> Henning Basold wrote :
>>
>>> Robert Ramey talked about wrapping some POD to increase type
>>> safety. Some time ago I used something similar to ensure
>>> that misuse of values can be found by the compiler.
>>>
>>> So I think that is something that can be generalized. The
>>> concept is to wrap a type into a class and restrict the
>>> interface. This ensures that values from one context (e.g.
>>> an id) can't be used in another context (e.g. adding of
>>> number or as an id for other objects).
>> [...]
>>> Do you think this might be a useful utility? Or is there
>>> something similar already available? [...]
>> Personnaly, I simply use a strongtypedef macro. A good news is that
>> there is already one done in serialization : strong_typedef.hpp
>> (maybe this one could have gone into boost.utility?).
>>
>> I think you have got something to dig, even if I am not convinced
>> that I would use your interface in a real project over the already
>> existing strong_typedef. Could you give some real world cunny
>> examples of use?
> I see this proposal as quite different from strong_typedef (and by
> implication opaque which I think is a better implementation of
> strong_typedef).  When I say strong_typedef here I'm referring
> to BOOST_SERIALIZATION_STRONG_TYPEDEF.
>
> strong_typedef is just a way to assign a type to an integer or
> other POD type.  It inherits all the operators and is free convertible
> to the underlying type.  It's useful for template meta-programming
> where one wants to dispatch to code depending on the the type.
> In effect, it creates a compile time pair<specialized_type, POD>
> which acts just like the POD but is distinguishable.  One use case
> for this is the serialization library which permits one to have different
> code to handle special types which are in fact integers and permit
> them to be trapped and handled specially without accidently invoking
> the serialization code for the original POD through the whole program.
>
> This proposal is quite different.  Rather than inheriting all the behavior
> of the underlying POD, it's purpose is to restrict it - thereby trapping
> non-sensical operations at compile time.  I do see the value in generalizing
> this - bascally to avoid rookie mistakes like leaving out the assignment
> operartor (which C++ "helpfully" sticks in for me).  So I think this idea
> DOES have merit.
>
> I looked a little at your implementation and I think it's very, very cool.
>
> This is going to start a whole new thread.  Here are the things that
> come to my mind.
>
> a) The implementation isn't really enough for me to visualize how easy
> and useful it would be to use.  I realize that making a document with
> tutorial and examples is a bigger effort, but I for one would encourage
> you to invest this effort.
>
> b)  When I see a concept "Additive" I'm thinking uh-oh, this is going
> to spin a whole lot of new stuff.  Here is what goes on in my brain.
>
> Additive - hmmm why not multiplicative
> Additive/multiplicative - why not step back to
>
> set element  - no operations except equality
> group element - additive operators + null element
> different types of groups?
> field element - additive + multiplacative + ...
>
> Which to me is a facinating direction.  I believe that there have been
> proposals for C++ libraries to manage these kind of types.  And
> of course there is the unit's library which touchs this area.
>
> Sooooooooo - maybe you want to drop "additive" or maybe not.
>
> Anyway, I would encourage you to spend more effort in this.  I
> was using strong_typedef and it was fine for my purposes.  But
> I moved to the "restricted" typedef to elminate warnings and
> trap bugs.  So there is definitely a use for such a thing.
>
> I see this idea as one of those few which can be a library
> small enough to actually do, be easy and useful to use.  There
> aren't many opportunities like this these days.
>
> Good luck with this.
>
> Robert Ramey
>
>
>
>
>
>
>
>
> _______________________________________________
> Unsubscribe&  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi,

thank you very much for your feedback.

First: yes, permitting operations that don't make sense was my 
intention. The reason was that I'm a student and work in a company in 
parallel and was refactoring some software. That software has to be 
easily maintainable after I'm gone. There a strict type system helps a 
lot (beside design documents etc. :) ).

You may not believe it, but while adding "Additive" I had the same 
thoughts. "Multiplicative" is already there but I left it out to 
minimize the code and show only the relevant stuff.
While adding these concepts I thought about groups and rings etc., too. 
But the question is if it is needed. It might be useful to specify 
algorithms (e.g. associativity for folding). This also falls into the 
scope of concepts and their axioms which unfortunately have been dropped.
Side note: concept maps may be thought of as the reverse of the 
restriction that NewType imposes.

The implementation of a new concept that a type may be restricted to is 
very simple so one may provide only a small base which a user can easily 
extend. A rather contrived example here is to restrict a deque to a 
stack or a queue.

You are right that the current state does not really show good 
applications. I will think and come back with some (hopefully good) 
examples. Maybe someone already has one. I would be happy to hear about 
them.

Best Regards
Henning

PS: some credit for the implementation goes to Alexandresu's "Scattered 
Hierarchy" from "Modern C++ Design".