December 2010 - Boost - lists.preview.boost.org

Re: [boost] [SQL-Connectivity] Is Boost interested in CppDB?
by Artyom 15 Dec '10

15 Dec '10

> >Hi, >I will only refer to complain on the slow SOCI release schedule. >So, instead of deciding to join an existing project, which N.B. you have used >with some degree of success, and help >to speed its release process, help with fixing bugs and propose to add features >you are missing, you decide to fork it, tweak it and release it. CppDB is not a fork of SOCI, it is totally different library that does things very differently that does not share a single line of code with SOCI. I admit that I had took many general ideas from SOCI and made them more suitable for my vision how SQL library should look, and this is very logical since SOCI was the best SQL library I used so far (till CppDB was released :-) ). And as you know (and you are as you on soci's mailing list) that I still do my small contributions to SOCI - each time I find some issue I try to fix it, report it and even send a patch. As FOSS project developer and leader I know how valuable it is. Now I'll explain the decision more deeply: ------------------------------------------ I was considering join the SOCI project and bring some improvements, however my vision of how the stuff should work and SOCI's vision was quite different, and the internal structure of the SOCI project and class relationships did bringing new and significant features to SOCI was not as simple as I was thinking. So basically I had two options: 1. Fork SOCI and rewrite it - very bad idea, for several reasons: a. forking is bad! b. it still requires from me rewriting its internals c. I'm still not pleased with imlementation level of SOCI's sqlite3 and mysql backends. 2. Push new things to SOCI fighting to explain my vision of things, missing some of them and finally not getting what I need. 3. Create my own library that provides the vision I need. So I had chousen the 3rd. However I had **another** reason to do this as well. As you probably know I'm developer of CppCMS framework, and I need a good database connectivity solution for my customers, and what is most important I need it to be stable, useable with fast upstream bug fixes, optimized for performance and I need it **now**. SOCI couldn't do this for me, as it is still stuck in version 3.0.0 released in 2008 with no bug fixes. And I can't say to my customers - take a git version of SOCI it is very nice (that 9 hours ago was broken and probably still broken now - I've send a patch to SOCI's list) So beleive me I do like soci, I think it is great project but, it does not suit my and my customers needs. And for the last record, I still mention SOCI as one of the libraries that can be sucessefully used with CppCMS: http://art-blog.no-ip.info/wikipp/en/page/sql_connectivity > >This is not how FOSS works to make a project healthy and sustainale in long >term. Your observable disappointment about > >software here makes me asking, what's next? Boost libraries forked? > >Anyways, I'm just disappointed how much FOSS is ego-driven >where it should mean collaboration. Just pity. > Mateusz, as I explained above it is not about the ego, even thou there are many things I can be proud of. It is about having a solution. Beleive me I prefer spending my time of fixing bugs and providing new features in CppCMS then writing an SQL library. Best Regards and I hope your undersand the resasons I had. Artyom

3 3

Re: [boost] [SQL-Connectivity] Is Boost interested in CppDB?
by Mateusz Loskot 14 Dec '10

14 Dec '10

Hi, I will only refer to complain on the slow SOCI release schedule. So, instead of deciding to join an existing project, which N.B. you have used with some degree of success, and help to speed its release process, help with fixing bugs and propose to add features you are missing, you decide to fork it, tweak it and release it. This is not how FOSS works to make a project healthy and sustainale in long term. Your observable disappointment about software here makes me asking, what's next? Boost libraries forked? Anyways, I'm just disappointed how much FOSS is ego-driven where it should mean collaboration. Just pity. Regards, -- Mateusz Łoskot, http::/mateusz.loskot.net (Sent from my mobile)

1 0

[GIL] locator and cached_location_t
by fabien 14 Dec '10

14 Dec '10

Hi, I like the idea of cached_location, but I have some questions about it. //// a simple usage example: // get a temporary locator from the view const SLocator loc_ref = srcView.xy_at(0,0); // from this locator we can extract a cached_location typename SLocator::cached_location_t LT( loc_ref.cache_location(-1,-1) ); DPixel func( const SLocator& src ) { // now instead of doing this: return src(-1, -1); // we can directly retrieve the pixel // from the locator using this cached location return src[LT]; } I have 2 questions: 1) Why can't we directly get a cached_location from a view (without using a locator) ? We have all informations in the view to build it, isn't it ? typename SLocator::cached_location_t LT( srcView.cache_location(-1,-1) ); 2) Is there a good reason to not allows to get a locator from another locator using cached_location ? DLocator func( const SLocator& src ) { // we can do this return src.xy_at(-1, -1); // return a new locator // we can't do the same thing with cached_location return src.xy_at(LT); //< it can be interesting to do this ! } Same remark to get an x_iterator from a locator: src.x_at(-1, -1); //< we can do this src.x_at(LT); //< we can't do this Best regards, Fabien Castan

3 2

Re: [boost] Boost.Locale (was Re: [SQL-Connectivity] Is Boost, interested in CppDB?)
by Anders Dalvander 14 Dec '10

14 Dec '10

On 14 Dec 2010 10:08, Eric Niebler<eric(a)boostpro.com> wrote: > Please, no. std::string is not an appropriate holder for a UTF-8 string. > It encourages random-access mutation of any byte in a UTF-8 sequence, > pretty much guaranteeing data corruption. And std::wstring is not an appropriate holder for a UTF-16 string. It encourages random-access mutation of any code unit in a UTF-16 sequence, pretty much guaranteeing data corruption. // Anders Dalvander -- WWFSMD?

1 0

boost::tasks::static_pool< boost::tasks::unbounded_fifo > crashes when poolsize > 1
by Joseph Winston 14 Dec '10

14 Dec '10

I've attached a program that reproduces the problem for me. The system this is running on is the following (Yes, I know it is old but I have very little control over the OS and compiler): Distribution: RHEL 4 $ uname -a Linux jwhp8400.houston.lgc.com 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 x86_64 x86_64 GNU/Linux Compiler: g++ 3.4.6 boost: 1.39.0 boost.context: 0.2.0 boost.fiber: 0.5.1 boost.task: svn revision 67209 The code of interest is: void f1() { std::cout << "\t" << "f1" << std::endl; } void f2() { std::cout << "\t" << "f2" << std::endl; } void demo() { typedef boost::tasks::static_pool< boost::tasks::unbounded_fifo > pool_type; pool_type pool(boost::tasks::poolsize(4), boost::tasks::stacksize(1024 * 128)); std::cout << "Starting" << std::endl; boost::tasks::async(boost::tasks::make_task(f1), pool); boost::tasks::async(boost::tasks::make_task(f2), pool); pool.shutdown(); std::cout << "Done" << std::endl; } Whenever poolsize is greater than 1, I sometimes receive the following sigsegv: (gdb) where #0 0x0000002a95d7d8db in boost::fibers::detail::trampoline (vp=0xffffffff96400ac0) at libs/fiber/src/detail/info_base.cpp:25 #1 0x0000003c0203e960 in __correctly_grouped_prefixwc () from /lib64/tls/libc.so.6 #2 0x0000000000000000 in ?? () (gdb) print *self Cannot access memory at address 0xffffffff96400ac0 Am I missing a fundamental concept with the way that boost::tasks::static_pool works or is there something else going on? Thanks

2 1

Re: [boost] pimpl library proposal
by Michael Bailey 14 Dec '10

14 Dec '10

On Dec 3, 2010, at 8:26 PM, Phil Endecott wrote: > which really isn't much different in terms of the amount of typing, > except for the forwarding. Can you show what your BOOST_PIMPL_METHOD > expands to? I can't immediately guess how you manage to not tell it > all the argument and return types. First of all, thanks for your input. I appreciate it. I will post the source below, so as to not clutter the conversation. > Re using the shared_ptr, this mainly gains the safety of otherwise > forgetting to implement the dtor, and has speed and space > disadvantages. I'm not convinced that is really useful, and so I would > decouple it from the concise forwarding feature. I think that the value comes in avoiding the pitfall of forgetting to free the pointer, as per all smart pointer implementations. That said, you're right in pointing out that shared_ptr just adds overhead. I think a preferable method, after taking in your considerations, is to just have the boost::pimpl<> class manage the allocating and freeing directly with new/delete. This does not add any overhead, but still gives the same safety of shared_ptr. You actually bring up an interesting idea. Perhaps the forwarding should be decoupled (which would not be hard at all) and generalized, rather than pushing the user into the pimpl paradigm. The user could easily use the forwarding for pimpl implementations or for something completely different. > Generally, I think that implementing pimpls falls more into the > category of stuff that's best done with some sort of tool, e.g. a > "pimpl wizzard" in your IDE, rather than a library. ---- boost/pimpl.hpp ---- #include <boost/typeof/typeof.hpp> #include <boost/type_traits/function_traits.hpp> #include <boost/preprocessor/repetition/enum_trailing_params.hpp> #include <boost/preprocessor/repetition/enum_shifted_params.hpp> #include <boost/preprocessor/repetition/enum_params.hpp> #include <boost/preprocessor/repetition/enum_shifted.hpp> #include <boost/preprocessor/arithmetic/inc.hpp> namespace boost { template <typename T> class pimpl { public: typedef T* ptr_type; pimpl( ptr_type p = new T() ) : m_impl( p ) {} ~pimpl() { delete m_impl; } protected: T& impl() { return *m_impl; } const T& impl() const { return *m_impl; } private: ptr_type m_impl; }; template <typename T> struct method_traits; #ifndef BOOST_METHOD_TRAITS_LIMIT # define BOOST_METHOD_TRAITS_LIMIT 10 #endif #define BOOST_METHOD_TRAITS(z,n,data) \ template <typename C, typename R \ BOOST_PP_ENUM_TRAILING_PARAMS_Z(z,n,class T) > \ struct method_traits< R(C::*)( BOOST_PP_ENUM_PARAMS_Z(z,n,T) ) data > \ : public function_traits< R( BOOST_PP_ENUM_PARAMS_Z(z,n,T) ) > { \ typedef data C class_type; \ }; BOOST_PP_REPEAT(BOOST_METHOD_TRAITS_LIMIT,BOOST_METHOD_TRAITS,) BOOST_PP_REPEAT(BOOST_METHOD_TRAITS_LIMIT,BOOST_METHOD_TRAITS,const) BOOST_PP_REPEAT(BOOST_METHOD_TRAITS_LIMIT,BOOST_METHOD_TRAITS,volatile) BOOST_PP_REPEAT(BOOST_METHOD_TRAITS_LIMIT,BOOST_METHOD_TRAITS,const volatile) } #define BOOST_PIMPL_CTOR( cls ) \ cls::cls() {} #define BOOST_PIMPL_DEFINE_METHOD_M( z, n, data ) \ BOOST_JOIN(BOOST_JOIN(data::arg,n),_type) BOOST_JOIN(a,n) #define BOOST_PIMPL_METHOD( args, cls, meth, ... ) \ ::boost::method_traits< BOOST_TYPEOF(&cls::meth) >::result_type \ cls::meth( \ BOOST_PP_ENUM_SHIFTED( BOOST_PP_INC(args), \ BOOST_PIMPL_DEFINE_METHOD_M, \ ::boost::method_traits<typeof(&cls::meth)> \ ) \ ) __VA_ARGS__ { \ return impl().meth( \ BOOST_PP_ENUM_SHIFTED_PARAMS(BOOST_PP_INC(args),a) \ ); \ }

3 7

static boost::barrier - do I need a mutex here ?
by Vokuba 14 Dec '10

14 Dec '10

Hi, Just a short question: Do you think I need a mutex for the 'static boost::barrier(nThreads)' lines in the sample code snippet below ? I always thought that static data in a function has to be protected by a mutex. But even with 16 running threads in parallel everything seems to be fine (it's a machine with 8 hardware cores, no HT). Thanks in advance - Hans int nThreads; // initialized later in main() void testing() { static boost::barrier barrier_one(nThreads); // mutex needed for 'local static' ? log("waiting on barrier_one"); barrier_one.wait(); do_complicated_stuff_simulaneously(); log("passed barrier_one"); static boost::barrier barrier_two(nThreads); // mutex needed for 'local static' ? log("waiting on barrier_two"); barrier_two.wait(); do_more_complicated_stuff_simulaneously(); log("passed barrier_two"); }

2 1

wfopen
by Christian Henning 14 Dec '10

14 Dec '10

Hi there, one of the requirements for me to fix before I include io_new to boost is to support opening files with unicode filenames. As far as I can see there is _wfopen on Windows platforms. What's the one for Linux and co? I'm a bit puzzled that no boost lib seems to use _wfopen. I searched all files. Is there something better? Thanks, Christian

7 7

[date_time] Could that be a bug in greg_month.hpp?
by Vladimir Batov 13 Dec '10

13 Dec '10

greg_month.hpp includes files in the following order: #include "boost/date_time/constrained_value.hpp" #include "boost/date_time/date_defs.hpp" #include "boost/shared_ptr.hpp" #include "boost/date_time/compiler_config.hpp" Should not compiler_config.hpp come first? As it is the date_time library fails to compile on Interix (sigh) as <time.h> is included before boost/config/user.hpp is sourced with a few function signatures omitted as a result. Best, V.

1 0

[Documentation] Does Boost-Build support Doxygen documentation for tutorials (rather then quickbook)
by Artyom 13 Dec '10

13 Dec '10

Hello, I would like to know if boost-build supports writing tutorials using Doxygen rather that using HTML or its own "quickbook" tool. At this point I have Boost.Locale documentation written with Markdown and I want to transfer it to other tool. I want to use Doxygen for it as Boost.Locale reference is already documented using Doxygen so converting the tutorials from markdown to Doxygen format seems to me much better idea then using "internal" boost documentation format. Rationale: - Doxygen is more widely available tool then quickbook. - It is independent from boost itself. - It is useful for non-boost project - Documentation generation is much simpler (requires running Doxygen) rather then using complicated tool-chain of boost-build. Thanks, Artyom

5 7