Am 19.12.2010 04:05, schrieb Mateusz Loskot: > On 19/12/10 01:56, Mateusz Loskot wrote: >> On 18/12/10 22:07, Maciej Sobczak wrote: >>> On 18/12/2010 18:07, Mateusz Loskot wrote: >>> >>>> I have decided to apply it to the repository because as far as I see >>>> it is not intrusive and it should not affect other users. >>>> It's neat and makes the relevant code shorter. >>> Thanks for applying the patch, but I was thinking about a possible >>> increase in compile time. >> I've measured compilation time of the postgresql/test including old and >> new version of boost-fusion.h and the times are ~12 sec for both. >> I don't see any noticeable difference, but I have no problem with >> improving it. >> >>> Note that if the macro is not defined, it is set to 10 by default, which >>> provides the same functionality as before the patch, just compiling >>> longer. So, for those who accept 10 as the default limitation, things >>> get worse in terms of longer compile time. >> Good point. >> >>> What about this: >>> >>> #ifndef SOCI_MAX_FUSION_SEQUENCE_LENGTH >>> >>> // here old implementation >>> >>> #else >>> >>> #include<boost/preprocessor...> >>> >>> // ... new implementation >>> >>> #endif >>> >>> With this code structure those who accept the default limitation get >>> fast compilation and those who want to tinker with the macro get more >>> flexibility at the price of longer compile. >>> >>> This also means some code duplication (same functionality implemented in >>> two different ways), so I'm not entirely sure if this is perfect. I will >>> therefore ask for opinion those who use this more heavily. >>> >>> So? Does this dual-implementation make sense? >> I'm fine with this solution. >> >> Jeff, Henning, are you happy with that too? > Folks, > > I've just noticed running some last tests today, the boost fusion > support is somewhat screwed up. > > This simple test: > > boost::tuple<double, int, std::string> t1(3.5, 7, "Joe Hacker"); > sql<< "insert into soci_test(a, b, c) values(:d,:i,:s)", use(t1); > > will lead to doubled "uses" it is 3 x 2 and eventually backend, e.g. > PostgreSQL, will complain number of parameters 6 is invalid for number > of placeholders 3 > > The problem is with doubled convert_to_base() calls: > 1) in ctor of conversion_use_type > 2) in use_type<values>::bind > > The 1) has been added recently in: > > http://soci.git.sourceforge.net/git/gitweb.cgi?p=soci/soci;a=commitdiff;h=c166625a28f7c907318134f625ff5acea7d9a1f8 > > I guess it needs to go but with extra care. > > Best regards, Hi,
don't know about this. But why has that call been added? Was there a problem which that call should solve? Regards Henning ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
