DRYing BOOST_FUSION_ADAPT_STRUCT with decltype/Boost.TypeOf ?
Hi dear Boost Fusion developers,
I was asking myself if there were already plan to improve BOOST_FUSION_ADAPT_STRUCT to benefit from C++11 features like decltype ? This would be interesting to avoid the risk encountered that the types definitions can get out-of-sync. And would avoid typing type declarations twice.
Currently there is BOOST_FUSION_DEFINE_STRUCT to avoid repeating the type information for each field. However this is something that makes most developer I know unhappy, as it obliges to modify the readable C++ aggregate types definition (i.e. Could be public headers) with this macro.
Then there is the nice choice of BOOST_FUSION_ADAPT_STRUCT which obliges retyping the type and adds the risk that some field type information could get out-of-sync between the struct definition and the BOOST_FUSION_ADAPT_STRUCT listing.
I think it would be valuable to add macros that would enable to select the fields that we want to adapt to a Random Access Sequence without requiring to repeat the type information. I would find more comfortable to write the example provided here http://www.boost.org/doc/libs/1_55_0/libs/fusion/doc/html/fusion/adapted/ada... as follow :
namespace demo
{
struct employee
{
std::string name;
int age;
};
}
// demo::employee is now a Fusion sequence
BOOST_FUSION_ADAPT_STRUCT_EXT(
demo::employee,
(name)
(age))
And a naïve implementation of BOOST_FUSION_ADAPT_STRUCT_EXT could be:
#include
I think it would be valuable to add macros that would enable to select the fields that we want to adapt to a Random Access Sequence without requiring to repeat the type information. I would find more comfortable to write the example provided here http://www.boost.org/doc/libs/1_55_0/libs/fusion/doc/html/fusion/adapted/ada... as follow :
namespace demo { struct employee { std::string name; int age; }; }
// demo::employee is now a Fusion sequence BOOST_FUSION_ADAPT_STRUCT_EXT( demo::employee, (name) (age))
I think that's a good idea. I would file a ticket in Trac to make sure this is not forgotten. Regards, Nate
On 12/19/13, 5:23 AM, Nathan Ridge wrote:
I think it would be valuable to add macros that would enable to select the fields that we want to adapt to a Random Access Sequence without requiring to repeat the type information. I would find more comfortable to write the example provided here http://www.boost.org/doc/libs/1_55_0/libs/fusion/doc/html/fusion/adapted/ada... as follow :
namespace demo { struct employee { std::string name; int age; }; }
// demo::employee is now a Fusion sequence BOOST_FUSION_ADAPT_STRUCT_EXT( demo::employee, (name) (age))
I think that's a good idea. I would file a ticket in Trac to make sure this is not forgotten.
Nods. That should work. Better yet, submit a patch :-) Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
On 12/18/13, 9:35 AM, Damien Buhl wrote:
Hi dear Boost Fusion developers,
I was asking myself if there were already plan to improve BOOST_FUSION_ADAPT_STRUCT to benefit from C++11 features like decltype ? This would be interesting to avoid the risk encountered that the types definitions can get out-of-sync. And would avoid typing type declarations twice.
Currently there is BOOST_FUSION_DEFINE_STRUCT to avoid repeating the type information for each field. However this is something that makes most developer I know unhappy, as it obliges to modify the readable C++ aggregate types definition (i.e. Could be public headers) with this macro.
Then there is the nice choice of BOOST_FUSION_ADAPT_STRUCT which obliges retyping the type and adds the risk that some field type information could get out-of-sync between the struct definition and the BOOST_FUSION_ADAPT_STRUCT listing.
I think it would be valuable to add macros that would enable to select the fields that we want to adapt to a Random Access Sequence without requiring to repeat the type information. I would find more comfortable to write the example provided here http://www.boost.org/doc/libs/1_55_0/libs/fusion/doc/html/fusion/adapted/ada... as follow :
namespace demo { struct employee { std::string name; int age; }; }
// demo::employee is now a Fusion sequence BOOST_FUSION_ADAPT_STRUCT_EXT( demo::employee, (name) (age))
And a naïve implementation of BOOST_FUSION_ADAPT_STRUCT_EXT could be:
#include
#include #include #define ATTRIBUTE_DEFINITION(r, data, elem) \ (BOOST_TYPEOF(data::elem), elem) \
#define BOOST_FUSION_ADAPT_STRUCT_EXT(NAME, ATTRIBUTES) \ BOOST_FUSION_ADAPT_STRUCT(NAME, \ BOOST_PP_SEQ_FOR_EACH(ATTRIBUTE_DEFINITION, NAME, ATTRIBUTES))
#endif
The same could certainly be achieved for BOOST_FUSION_ADAPT_TPL_STRUCT, while I didn't check.
Thanks for the really great job done in Boost.Fusion.
Thanks, Damien. I like the idea. Could you 1) try it out and 2) submit a patch (or pull request). It would also be super if you can add in the doc patch. Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
On 12/19/2013 11:46 PM, Joel de Guzman wrote:
[...]
Thanks, Damien. I like the idea. Could you 1) try it out and 2) submit a patch (or pull request). It would also be super if you can add in the doc patch.
Regards,
Hi Joel, Thank you for the reply. :) What I proposed as implementation in the first mail works without any problem for my simple structs, I use it in a small project in combination with Boost.Spirit. It's however not so an elegant way of implementing it I believe (while I'm not a BOOST_PP_* expert). I'll submit a pull-request on github in the next days, I'll add a doc and an example to that. We could then discuss of an eventual better way of implementing it. I think I will also try to provide the equivalent for all the BOOST_FUSION_ADAPT_* macros. But I'm not sure if it will be possible and makes sense for each one. @Nathan Ridge: Thank you for taking notice of it. :) Did you already create the ticket ? I didn't find it on Boost Trac yet. Because I would put link to the pull-request on it as soon as I have my changes. Cheers, -- Damien Buhl
@Nathan Ridge: Thank you for taking notice of it. :) Did you already create the ticket ? I didn't find it on Boost Trac yet. Because I would put link to the pull-request on it as soon as I have my changes.
I was suggesting you create one :) Apologies if it wasn't clear. Anyways, I created one now: https://svn.boost.org/trac/boost/ticket/9516 Regards, Nate
On 12/20/13, 6:06 PM, Damien Buhl wrote:
On 12/19/2013 11:46 PM, Joel de Guzman wrote:
[...]
Thanks, Damien. I like the idea. Could you 1) try it out and 2) submit a patch (or pull request). It would also be super if you can add in the doc patch.
Regards,
Hi Joel,
Thank you for the reply. :)
What I proposed as implementation in the first mail works without any problem for my simple structs, I use it in a small project in combination with Boost.Spirit.
It's however not so an elegant way of implementing it I believe (while I'm not a BOOST_PP_* expert).
I'll submit a pull-request on github in the next days, I'll add a doc and an example to that. We could then discuss of an eventual better way of implementing it.
I think I will also try to provide the equivalent for all the BOOST_FUSION_ADAPT_* macros. But I'm not sure if it will be possible and makes sense for each one.
@Nathan Ridge: Thank you for taking notice of it. :) Did you already create the ticket ? I didn't find it on Boost Trac yet. Because I would put link to the pull-request on it as soon as I have my changes.
Wonderful! You can email me offline if you want to discuss things. Thank you very much! Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
On 12/21/2013 09:40 AM, Joel de Guzman wrote:
On 12/20/13, 6:06 PM, Damien Buhl wrote:
On 12/19/2013 11:46 PM, Joel de Guzman wrote:
[...]
Thanks, Damien. I like the idea. Could you 1) try it out and 2) submit a patch (or pull request). It would also be super if you can add in the doc patch.
Regards,
Hi Joel,
Thank you for the reply. :)
What I proposed as implementation in the first mail works without any problem for my simple structs, I use it in a small project in combination with Boost.Spirit.
It's however not so an elegant way of implementing it I believe (while I'm not a BOOST_PP_* expert).
I'll submit a pull-request on github in the next days, I'll add a doc and an example to that. We could then discuss of an eventual better way of implementing it.
I think I will also try to provide the equivalent for all the BOOST_FUSION_ADAPT_* macros. But I'm not sure if it will be possible and makes sense for each one.
@Nathan Ridge: Thank you for taking notice of it. :) Did you already create the ticket ? I didn't find it on Boost Trac yet. Because I would put link to the pull-request on it as soon as I have my changes.
Wonderful! You can email me offline if you want to discuss things. Thank you very much!
Regards,
Hi Joel, I just opened the pull-request, so that the discussion can continue there. I send this email to the list so that anyone can later find the related work on github : https://github.com/boostorg/fusion/pull/3 in case he would search the events following this discussion. I'm excited about your comments :) Regards, -- Damien Buhl
participants (3)
-
Damien Buhl -
Joel de Guzman -
Nathan Ridge