On 4/16/11 4:43 AM, Vicente BOTET wrote: Hi, Lastly I've been working on 3 Boost libraries proposals. * Boost.Conversion ([1]https://svn.boost.org/svn/boost/sandbox/conversion/libs/ conversion_ext/doc/html/index.html), * Boost.Enums ([2]https://svn.boost.org/svn/boost/sandbox/enums/libs/enums/doc/ html/index.html) * Boost.Opaque ([3]https://svn.boost.org/svn/boost/sandbox/opaque/libs/opaque/d oc/html/index.html) Boost.Conversion manages with generic explicit conversion between unrelated typ es. The template function convert_to allows to convert a source type to a targe t type, using argument dependent lookup (ADL) to select a specialized convert_t o function if available. If no specialized convert_to function is available, bo ost::conversion::convert_to is used. Boost.Enums intends to provide a partial solution to the scoped enums problem e nsuring a portable solution compatible with compilers supporting natively scope d enums or not. In addition provides a framework to view enumerations as ordina l types so we can define some specific and efficient enum containers. Boost.Enu ms is composed of the following parts: * Scoped enums * Ordinal enums * Enum containers * MPL enums * String <-> Enum conversions Boost.Opaque intends to provide a library partial solution to "opaque typedefs" . Boost.Opaque provides: * a generic mixin class hierarchy which can be specialized by the user to make new opaque classes. * a generic class hierarchy which can be instantiated by the user to make new o paque typedefs. * a meta-mixin concept that allows to compose in a easy way several aspects of a class in an orthogonal way. * a considerable number of meta-mixins that helps defining new types from an un derlying type * Some helper macros that can reduce the declaration of a new opaque type to a single line, emulating the language-based approach. Boost.Opaque and Boost.Enums depend in some degree on Boost.Conversion. These are quite basic libraries that any of you could find useful (or not) and that are not associated to a complex domain, so any of you could have an opinio n without spending too much time. Please follow the above links to have a better idea of the motivation of these libraries. Before continuing completing the design, docs and tests of these libraries I wo uld like to know if there is an interest on these libraries and if you have any suggestion on how to improve them, you see something missing or that should be removed. This will help me a lot to concentrate my efforts on the library that reveals more interest. Any comment will really be appreciated. Thanks, Vicente _______________________________________________ Unsubscribe & other changes: [4]http://lists.boost.org/mailman/listinfo.cgi/boo st Vicente, I reviewed the Boost.Enums documentation and I am very interested in this library. I could use this library right now exactly as it is described in the documentation. I'm sure once I started using it I will be able to comment more intelligently on changes/improvements. Due to client constraints, I must do most of my development on older gcc versions (3.4.6 and 4.1.1) and I would be willing to help you test this library on those compilers if you wish to support them. I haven't looked at the other two libraries yet to see if they meet any of my needs but I will do so soon. Thanks for your efforts, Timothy Moore Montecito Software LLC [5]http://www.montecito-software.com References 1. https://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/h... 2. https://svn.boost.org/svn/boost/sandbox/enums/libs/enums/doc/html/index.html 3. https://svn.boost.org/svn/boost/sandbox/opaque/libs/opaque/doc/html/index.ht... 4. http://lists.boost.org/mailman/listinfo.cgi/boost 5. http://www.montecito-software.com/

----- Original Message ----- From: "Vicente BOTET" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Saturday, April 16, 2011 1:43 PM Subject: [boost] Conversion/Enums/Opaque request for interest

Hi,

Lastly I've been working on 3 Boost libraries proposals.

* Boost.Conversion (https://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/h...), * Boost.Enums (https://svn.boost.org/svn/boost/sandbox/enums/libs/enums/doc/html/index.html) * Boost.Opaque (https://svn.boost.org/svn/boost/sandbox/opaque/libs/opaque/doc/html/index.ht...)

Boost.Conversion manages with generic explicit conversion between unrelated types. The template function convert_to allows to convert a source type to a target type, using argument dependent lookup (ADL) to select a specialized convert_to function if available. If no specialized convert_to function is available, boost::conversion::convert_to is used.

Hi, I've done something similar to Boost.Conversion for (un)marschalling data to some API. Rather than template functions I was using structs, the ones that were trivial were defined using some traits template <class C__> struct CastMarshal; template <> struct CastMarshal<char> { typedef int tyM; }; template <> struct CastMarshal<MyEnum> { typedef int tyM; }; template <> struct CastMarshal<int> { typedef int tyM; }; The conversions for them were done by the default definition of a template class: template <class C__> struct Marshal { typedef C__ tyU; typedef typename CastMarshal<C__>::tyM tyM; static tyM marshal(tyU pa) { return tyM(pa); } static tyU unmarshal(tyM pa) { return tyU(pa); } }; You could write specialisations of this class for marshalling any type. template <> struct Marshal<Point> { typedef Point tyU; typedef std::pair<double,double> tyM; static tyM marshal(tyU const& pa) { ... } static tyU unmarshal(tyM const& pa) { ... } }; I had also specialisations for containers like vector, map, pair, QMap, QVector, ... for example something like: template <class C__,class A__> struct Marshal<std::vector<C__,A__> > { typedef std::vector<C__,A__> tyU; typedef typename std::vector<Marshal<C__>::tyM,A__> tyM; static tyM marshal(tyU const& pa) { /* return vector with transformed elements here */ } static tyU unmarshal(tyM const& pa) { /* return vector with transformed elements here*/ } }; So if I defined how to marshall types X and Y, I was able to marshall QMap<X,vector<pair<Y,Y> > > and all other combinations as well. I went even further and wrote templates that created function-adapters wich did (un)marshalling of all parameters and the return-type. char f1(map<char,char> const& paIn, vector<char>& paOut); // wanted signature int f2(map<int,int> const& paIn, vector<int>& paOut); // signature with marshalled types I could define f1 as: char f1(map<char,char> const& paIn, vector<char>& paOut) { return MarshallParams(&f1,&f2)(paIn,paOut); } where MarshallParams was an overloaded templatefunction. It checked if the transformed version of f1 had the same signature as f2, and if so it returned a functor, otherwise it was a compile-error. The returned functor marshalled the first parameter paIn and unmarshalled the second parameter paOut (because in this case it was a rule that all reference parameters were output parameters, not in-out parameters! So it was useless in my case to do marshalling for non-const reference parameters, as well as unmarshalling of const reference parameters. If the corresponding types were identical like int to int then there was also no need for (un)marshalling and the parameters could be passed untransformed (by reference). I did assume that all functions were no-throw. For callbacks I had something similar but working in the other direction: char f3(map<char,char> const& paIn, vector<char>& paOut); // my signature int f4(map<int,int> const& paIn, vector<int>& paOut); // required signature int f4(map<int,int> const& paIn, vector<int>& paOut); { return UnmarshallParams(&f3,&f4)(paIn,paOut); } Regards, Wouter