- Boost - lists.boost.org

Strange font settings on www.boost.org
by Jens Seidel 02 May '08

02 May '08

Hi, I noticed that headlines look very strange on the new website. I think the problem is #content h1, #content h2, #content h3, #content h4, #content h5, #content h6 { margin: 0em; color: #000000; font-family: "Times New Roman",serif; font-variant: small-caps; clear: both; } in http://www.boost.org/style/css_0/content.css. Why is a special font used? I do not have such a font and I would also prefer if the browser would be able to use a default. As far as I know it is save to use a few standard font aliases such as sans-serif or similar in HTML but "Times New Roman" is probably not one of these, right? Jens

4 3

[optional] boost::variant<T,nil_t> in docs
by Alexander Nasonov 02 May '08

02 May '08

Shouldn't it be boost::variant<T,none_t> (nil_t -> none_t) instead? Thanks, Alex

1 0

gcc-4.3.0, shared lib build problem?
by Neal Becker 02 May '08

02 May '08

After building boost (recent svn Revision: 44635 ) using: bjam -sICU_PATH=/usr -sEXPAT_INCLUDE=/usr -sEXPAT_LIBPATH=/usr/lib64 --layout=system threading=single stage Then when I tried to re-build my shared object against the boost libs, I got: /usr/bin/ld: mod/ldpc.os: relocation R_X86_64_32 against `__dso_handle' can not be used when making a shared object; recompile with -fPIC Did -fPIC flag go missing when building the boost libs? (Can someone refresh my memory which bjam flag to use to show the compile invocation)?

1 1

Another C++ puzzler
by Marco Costalba 02 May '08

02 May '08

After the great success of Eric's puzzle on the common type of a given types set here it is another puzzle for you C++ wizards. This one arise from the multi signature boost function implementation recently posted to this list. Let's have two boost.function objects, each one defined on a different function signature Sig_1, Sig_2 boost::function<Sig_1> boost_fun_1; boost::function<Sig_2> boost_fun_2; Then have two overloaded template functions called "set" to assign a function/functor to either one of the above boost.function objects template<typename Fun> void set(Fun const& fun, typename enable_if<is_compatible<Fun, Sig_1> >::type* = 0) { boost_fun_1 = fun; } template<typename Fun> void set(Fun const& fun, typename enable_if<is_compatible<Fun, Sig_2> >::type* = 0) { boost_fun_2 = fun; } To disambiguate between the two a SFINAE technique is used on the second (hidden) argument of "set" Where struct is_compatible is defined as: /* Check if a function/functor Fun has a given signature Sig */ template<typename Fun, typename Sig> struct is_compatible { /* Check for a function */ template<class U> static yes_type check(typename enable_if<is_same<U, Sig> >::type*); /* Check for a functor */ template<class U, Sig U::*> struct helper; template<class U> static yes_type check(helper<U, &U::operator()>*); /* Default */ template<class U> static no_type check(...); typedef typename boost::remove_pointer<Fun>::type F; static bool const value = (sizeof(check<F>(0)) == sizeof(yes_type)); }; Now the puzzle is: There is a way to remove struct is_compatible altogether ? or at least greatly simplify it ? Constrains are - Public API must be set(fun) where fun is any functor/function for which either expression "boost_fun_1 = fun" or "boost_fun_2 = fun" compiles. - If both "boost_fun_1 = fun" and "boost_fun_2 = fun" are not compilable then a compile error should raise Hint: an almost working solution could have been template<typename Fun> void set(Fun const& fun, bool = (boost::function<Sig_1>() == fun)) { boost_fun_1 = fun; } template<typename Fun> void set(Fun const& fun, bool = (boost::function<Sig_2>() == fun)) { boost_fun_2 = fun; } But unfortunately it is forbidden to refer to an argument (fun in this case) in the expression of the default value of another argument. Have fun Marco

4 7

[ptr_container]ptr_multimap difference in doc and code
by Sergei Politov 02 May '08

02 May '08

Hi, I have found some differences in documentation for ptr_multimap, and its real implementation. In code: template< class U > iterator insert( key_type& key, std::auto_ptr<U> x ) { return insert( key, x.release() ); } In documentation: template< class U > iterator insert( const key_type&, std::auto_ptr<U> x ); The difference is in first argument of this function. I don't known which way is right to submit the bug report. Could somebody please help me? Best Regards, Sergei

2 2

[parameter][serialization] VC 8/9 regression test failures
by Richard Webb 02 May '08

02 May '08

The trunk regression tests are showing a large number of failures for Parameter and Serialization (and several other libraries that use them). These seem to have appeared as a result of some recent type_traits changes. -parameter- The parameter tests are failing with: ..\boost/parameter/aux_/tagged_argument.hpp(173) : error C2504: 'is_convertible' : base class undefined This can be fixed by adding # include <boost/type_traits/is_convertible.hpp> to tagged_argument.hpp -serialization- The serialization tests are failing with: ..\boost/serialization/is_abstract.hpp(43) : warning C4005: 'BOOST_IS_ABSTRACT' : macro redefinition ..\boost/type_traits/intrinsics.hpp(99) : see previous definition of 'BOOST_IS_ABSTRACT' Due to a BOOST_IS_ABSTRACT that was just added to type_traits conflicting with one that already existed in serializtion. Thanks, Richard Webb

4 4

Help required in asynchronous I/O
by Suresh 02 May '08

02 May '08

Hello, I am working on incorporating async I/O in postgres. I had the foll. doubts in async operation. If I do for(i=0;i<MAX;i++){ bzero( (char *)&aiocb1[i], sizeof(struct aiocb) ); aiocb1[i].aio_fildes = fd; aiocb1[i].aio_nbytes = BUF_SIZE; aiocb1[i].aio_buf = malloc(BUF_SIZE+1); aiocb1[i].aio_offset = off+100; //next_offset; aiocb1[i].aio_lio_opcode = LIO_READ; sigemptyset(&sig_act[i].sa_mask); sig_act[i].sa_flags = SA_SIGINFO; sig_act[i].sa_sigaction = aio_completion_handler; aiocb1[i].aio_sigevent.sigev_notify = SIGEV_SIGNAL; aiocb1[i].aio_sigevent.sigev_signo = SIGIO; aiocb1[i].aio_sigevent.sigev_value.sival_ptr = &aiocb1[i]; ret = sigaction( SIGIO, &sig_act[i], NULL ); off+=100; list[i]=&aiocb1[i]; } void aio_completion_handler( int signo, siginfo_t *info, void *context ){ int i=0,ret; if (info->si_signo == SIGIO) { ..... } } It calls the aio_completion handler once when all the i/o requests are completed and we check the signal and proceed. The same method if I use for callback using threads, then it calls the aio_completion handler MAX times instead of calling it only once. aiocb1[i].aio_sigevent.sigev_notify = SIGEV_THREAD; aiocb1[i].aio_sigevent._sigev_un._sigev_thread._function = aio_completion_handler; .... void aio_completion_handler( sigval_t sigval ) { ... } How do I do something similar to signal mechanism whereing a check if the signal is mine and then only proceed. In short, how do I guarantee that aio_completion_handler is called only once in case of list AIO. Please help me out of this. Thanks and regards, Suresh --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

1 0

throw_exception rev. 44954 -> g++ warnings
by Ralf W. Grosse-Kunstleve 02 May '08

02 May '08

SVN rev. 44954 from yesterday introduces new g++ warnings (several g++ versions, incl. 4.1.2 Fedora 8). See below. Would it make sense to add the virtual destructors g++ want's to have? Ralf include_te.cpp: #include <boost/throw_exception.hpp> % svn update -r44953 Updated to revision 44953. % g++ -Wall -c -I$hot/boost include_te.cpp % svn update -r44954 U boost/throw_exception.hpp Updated to revision 44954. % g++ -Wall -c -I$hot/boost include_te.cpp boost/exception/detail/counted_base.hpp:17: warning: 'class boost::exception_detail::counted_base' has virtual functions but non-virtual destructor boost/exception/detail/cloning_base.hpp:19: warning: 'class boost::exception_detail::cloning_base' has virtual functions but non-virtual destructor boost/exception/enable_current_exception.hpp:24: warning: 'class boost::exception_detail::clone_base' has virtual functions but non-virtual destructor boost/exception/exception.hpp:27: warning: 'struct boost::exception_detail::error_info_container' has virtual functions but non-virtual destructor

2 1

[exception] exception_ptr for GCC
by Sebastian Redl 01 May '08

01 May '08

Hi, My quest for a general exception_ptr for GCC has reached its end, in the sense of, "I can't make it any better without modifying GCC." My current code is extremely fragile regarding code generation (it depends on the layout of the functions in the file) and there is one circumstance under which it leaks the exception object, but in general it works quite well. The header file, source file, and a file containing test cases are attached. Even though this can obviously not be used in production code, it's an interesting study of absurd things you can do in order to get around the limitations of a fixed ABI. Sebastian

2 2

[Concept Check] - Extending the BCCL with AllocatorConcept
by Michael Fawcett 01 May '08

01 May '08

I recently had the need to code up an AllocatorConcept, and it occurred to me that it might fit well within the BCCL. I noticed that Intrusive also had an allocator concept and wondered if other libraries did too (perhaps under a different name). Would this be of interest as an extension to BCCL? A quick Google search of boost.org shows that dynamic_bitset, multi_index, function, regex, shared_ptr (and I'm sure more) all have Allocator template parameters where it might make sense. For very generic concepts such as Allocator, do they belong in BCCL rather than coded in each library? I've pasted the code below. --Michael Fawcett -- code -- namespace boost { template <typename T> struct AllocatorConcept { typedef typename T::const_pointer const_pointer; typedef typename T::const_reference const_reference; typedef typename T::difference_type difference_type; typedef typename T::pointer pointer; typedef typename T::reference reference; typedef typename T::size_type size_type; typedef typename T::value_type value_type; // TODO: Do we need to do more here, e.g. char_allocator_type::rebind<value_type>::other == T? typedef typename T::template rebind<char>::other char_allocator_type; BOOST_CLASS_REQUIRE(T, boost, DefaultConstructibleConcept); BOOST_CLASS_REQUIRE(T, boost, CopyConstructibleConcept); BOOST_CLASS_REQUIRE(T, boost, EqualityComparableConcept); void constraints() { pointer p = 0; reference ref = *p; const_reference cref = *p; p = value.address(ref); const_pointer cp = value.address(cref); p = value.allocate(1); p = value.allocate(1, 0); value.construct(p, *p); value.deallocate(p, 1); value.destroy(p); size_type s = value.max_size(); } private: T value; }; }

2 3