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, -- 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
