On 19/12/10 11:47, Henning Basold wrote: > 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. > > Hi, > > don't know about this. But why has that call been added? Was there a > problem which that call should solve?
I've tracked the problem down and removed the convert_to_base calls from the constructors, only bind calls it now. I've tested with PostgreSQL for now and it works. If anyone will notice problems, let me know please. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ------------------------------------------------------------------------------ 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
