|
Boost : |
Subject: [boost] Is there any interest in Boost.Conversion?
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-05-28 08:23:21
Hi,
The Boost.Conversion library (Generic explicit conversion between unrelated types) has not revealed too much interest for the Boost community since v0.4 was released on 10/09.
For those that don't know it yet you can get the documentation and download links from
https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Conversion
I have added on the sandbox some pending issues that Jeffrey Hellrung related to conversions that need extra information.
If B1 is covertible to A1 using convert_to, now we can conver vectors of conversible types.
B1 b10, b11, b12, b13;
std::vector<B1> vb2;
vb2[0]=b10;
vb2[1]=b11;
vb2[2]=b12;
vb2[3]=b13;
std::vector<A1> va2(boost::convert_to<std::vector<A1> >(vb2))
std::vector<A1,std::allocator<A1> > va6(
boost::convert_to<std::vector<A1,std::allocator<A1> > >(pack(vb2, std::allocator<A1>())));
Note that when the Target constructor has some arguments (as is the case for vector with a specific allocator) we pack the Source and the Target arguments in a pack. The first argument is the Source.
boost::conversion::pack(vb2, std::allocator<A1>())
The function 'pack' is currently a little bit rudimentary, but is usable already for vector conversions using a specific allocator. Currently accepts only two parameters, I plan to go up to 5 parameters. Any suggestion for better namming 'boost::conversion::pack'.
I have no solution for the ambiguity problem of a user getting two different overloads of the same conversion on different namespaces, other than suggesting that convert_to overloadings should be done on the namespace of the Source, for example.
Jeffrey does this answer to your attends?
I will release the pack function and vector conversion (v.0.5) on the Vault once I will update the documentation.
Comments are welcome :)
Best,
_____________________
Vicente Juan Botet Escribá
http://viboes.blogspot.com/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk