- Boost - lists.boost.org

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

[build]Can't build libboost_unit_test_framework-vc90-mt-gdp-1_44.lib with msvc-9 and stlport
by Joachim Faulhaber 12 Dec '10

12 Dec '10

Hi all, sorry for posting this twice. But on boost-build I have to wait for moderator approval and, well, I'm a little impatient :-/ which is probably normal for little nasty problems like this one: I have built stlport-5.2 and tried to compile and link projects with it using msvc-9. Now the linker wants to see libboost_unit_test_framework-vc90-mt-gdp-1_44.lib instead of libboost_unit_test_framework-vc90-mt-gd-1_44.lib It wants the gd*p* version. So I tried to build it using bjam toolset=msvc-9.0~stlport5.2 --with-test --build-type=complete stage This generated new lib files but not the desired one. Could someone explain what the gd*p* suffix stands for and how I can build this lib-file with bjam. Thanx, Joachim

2 4