- Boost - lists.boost.org

[config] How to use on Mac with C++11 dialect?
by John M. Dlugosz 17 Jan '12

17 Jan '12

I've asked this on Boost-User and had no reply. Maybe someone here would know? Using the current Boost 1.48 and the current Clang for the Apple Macintosh, when the compiler is set to accept the C++11 dialect (that is, new "auto" usage, lambda functions, rvalue references, etc.) then Boost headers choke. So currently we can use either C++11 or Boost, but not both. I'm sure it's a matter of configuration, of telling Boost headers that the compiler is indeed supporting these constructs. Can someone please point out what needs to be done? Thanks, —John

3 2

Re: [boost] compile time parser generator
by Martin Bidlingmaier 16 Jan '12

16 Jan '12

I'm not sure it's possible to get a string literal in a template< char ... > class string; 'Literals transformation is redefined into two distinct phases: raw and cooked. A raw literal is a sequence of characters of some specific type, while the cooked literal is of a separate type. The C++ literal 1234, as a raw literal, is this sequence of characters '1', '2', '3', '4'. As a cooked literal, it is the integer 1234. The C++ literal 0xA in raw form is '0', 'x', 'A', while in cooked form it is the integer 10. Literals can be extended in both raw and cooked forms, with the exception of string literals, which can only be processed in cooked form. This exception is due to the fact that strings have prefixes that affect the specific meaning and type of the characters in question.' - source: wikipedia - http://en.wikipedia.org/wiki/C%2B%2B11#User-defined_literals . Parsing string literals with constexpr is described in this article: http://akrzemi1.wordpress.com/2011/05/11/parsing-strings-at-compile-time-pa… For building the parser generator I used compile time polymorphism. Each symbol in EBNF would be represented as a class. The interface each symbol defines looks like this: struct symbol { constexpr symbol( const_string str , unsigned int begin = 0 ); //for an implementation of const_string see the article I linked constexpr bool valid(); constexpr unsigned int end(); }; For example, a symbol that parses a single character 'a' looks like this: struct sym_a { constexpr sym_a( const_string str , unsigned int begin = 0 ) : m_end ( begin >= str.size() ? 0u - 1 : //invalid index str[ begin ] == 'a' ? begin + 1 : 0u - 1 ) { } constexpr bool valid() { return m_end != 0u - 1; } constexpr unsigned int end() { return m_end; } unsigned int m_end; }; constexpr sym_a s1( "a" ); constexpr sym_a s2( "b" ); static_assert( s1.valid() , "" ); static_assert( !s2.valid() , "" ); The source for my current version of the parser generator is appended. I've also created a simple calculator that can handle + and * (and will accept any digit sequence as number, including "00000"). Notice, that currently only char strings are completely supported, defining terminals and the opt< T > operator won't work with other literals. (I know I can improve this for terminals, but I'm not sure about opt< T >.) The source compiles with gcc 4.6 and c++11 turned on without errors. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

6 19

Re: [boost] boost threads: pthread mutex priority inheritance + patches
by Jason Newton 16 Jan '12

16 Jan '12

Ack, no discussion on this since I posted it back in July. In my opensuse packages, I apply the following patch to insure priority inheritence on mutexs. I had to go inside the mutex ctor to do the work. -Jason On Wed, Jul 27, 2011 at 5:40 PM, Jason Newton <nevion(a)gmail.com> wrote: > On Wed, Jul 27, 2011 at 4:48 PM, Jason Newton <nevion(a)gmail.com> wrote: > >> For the moment, the few lines that compose the mutex class are easily >> copied so that I can do my own business inside the constructor but I expect >> others will run into this problem down the line and this solution is a bit >> unsavory. Any better advice? >> > > Actually a private copy of mutex didn't work so well overall as pthread > conditions are hard coded to > void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) > > -Jason >

2 1

"protected" APIs
by Lorenzo Caminiti 16 Jan '12

16 Jan '12

Hello all, Boost.Closure (formerly, Boost.Local) needs to use some macros, types, etc that are currently marked private in Boost.ScopeExit: BOOST_SCOPE_EXIT_AUX_TAG boost::scope_exit::aux::undeclared ... So I will move these symbols from AUX/aux to another prefix/namespace. How shall the new prefix/namespace be named? These symbols should not go into the public API of ScopeExit because they should never be used by the end user. These symbols are only meant to be used by other parts of Boost so they should use some sort of "protected" prefix/namespace. For example, I could use "detail": "aux" for ScopeExit private API and "detail" for ScopeExit API that can be used within Boost but not by general users: BOOST_SCOPE_EXIT_DETAIL_TAG boost::scope_exit::detail::undeclared However, other Boost components already use "detail" for their private API (synonymous of "aux"). So, I could use "protected" instead: BOOST_SCOPE_EXIT_PROTECTED_TAG boost::scope_exit::protected_::undeclared What's the best convention to follow here? Thanks a lot. --Lorenzo

8 8

build error in Release branch
by Barend Gehrels 15 Jan '12

15 Jan '12

Hi, I get a build error in the release branch: .../release/tools/build/v2/build/project.jam:266: unbalanced parentheses I just looked for differences in Trunk and Release and indeed that line differs. I updated the file conform trunk, locally, and I can build now. I then get the message: warning: mismatched versions of Boost.Build engine and core warning: Boost.Build engine (bjam) is 2011.12.00 warning: Boost.Build core (at /home/barend/svn/boost/release/tools/build/v2) is 2011.04-svn So this might be my problem (not sure). However I'm normally using only one bjam, copying it to /usr/local/bin, but this time I cannot do that... Should I use different bjam's for Trunk/Release versions? Is this a known problem / will this be solved? Regards, Barend

2 2

[scope_exit] improvements
by Lorenzo Caminiti 15 Jan '12

15 Jan '12

Hello all, I've been working with Alex to make the following improvements to Boost.ScopeExit (as they were discussed during Boost.Local's review). The update docs: https://svn.boost.org/svn/boost/sandbox/closure/libs/scope_exit/doc/html/in… 1) It is possible to use variadic macros on compilers that support them: int r = 0, v = 0; BOOST_SCOPE_EXIT(&r, v) { r = v; } BOOST_SCOPE_EXIT_END To support compilers without variadics and for backward compatibility with previous ScopeExit versions, all macros also accepts pp-sequences: BOOST_SCOPE_EXIT( (&r) (v) ) { r = v; } BOOST_SCOPE_EXIT_END 2) It is possible to capture no variable using `void`: BOOST_SCOPE_EXIT(void) { std::cout << "cout is a global variable << std::endl; } BOOST_SCOPE_EXIT_END This same syntax works on compilers with and without variadics. 3) From within member functions, it is possible to capture the object this using `this_`: BOOST_SCOPE_EXIT(&r, v, this_) { r = this_->f(v); } BOOST_SCOPE_EXIT_END On C++11, you can also (but you don't have to) use `this`: BOOST_SCOPE_EXIT(&r, v, this) { // C++11 only. r = this->f(v); } BOOST_SCOPE_EXIT_END 4) On C++11, you can (but you don't have to) use `;` instead of BOOST_SCOPE_END. 5) On C++11, there is an additional macro that allows to capture all variables using lambda-style `&` or `=`: BOOST_SCOPE_EXIT_ALL(&, v, this) { // C++11 only. r = this->f(v); }; Or equivalently: BOOST_SCOPE_EXIT_ALL(=, &r) { // C++11 only. r = this->f(v); }; I still have to move these changes from the sandbox into trunk. Comments are welcome. Thanks, --Lorenzo

2 1

[typeof] TYPEOF(this) on MSVC 7.1 and 8.0
by Lorenzo Caminiti 14 Jan '12

14 Jan '12

Hello all, BOOST_TYPEOF(this) generates error C2355 on MSVC 7.1 and 8.0 because of a MSVC bug. The code below was suggested to workaround the problem but it only works with native typeof. Is there a way to make BOOST_TYPEOF(this) work on MSVC 7.1 and 8.0 with Boost.Typeof in emulation mode? // Adam Butcher's workaround to deduce `this` type on MSVC revision < 10. // Boost.Typeof for VC71's typeid-based workaround does not work to determine // `this` type due to error C2355 being incorrectly reported. The typical // avoidance strategy implemented below is to make an indirect compile-time // constant by assigning an enum and use that as type-index-- this only works // with the sizeof() approach and not with the typeid() approach. This does not // work in typeof emulation mode. #if BOOST_WORKAROUND(BOOST_MSVC, >= 1300) && /* MSVC 7.1 */ \ BOOST_WORKAROUND(BOOST_MSVC, <= 1400) && /* MSVC 8.0 */ \ !defined(BOOST_TYPEOF_EMULATION) /* doesn't work in typeof-emu mode */ namespace boost { namespace scope_exit { namespace aux { namespace msvc_typeof_this { template<int Id> struct msvc_typeid_wrapper { typedef typename boost::type_of::msvc_extract_type<boost::mpl::int_<Id> >::id2type id2type; typedef typename id2type::type type; }; template<> struct msvc_typeid_wrapper<4> { typedef msvc_typeid_wrapper<4> type; }; template<typename T> struct encode_type { BOOST_STATIC_CONSTANT(unsigned, value = boost::type_of::encode_counter<T>::count); typedef typename boost::type_of::msvc_register_type<T, boost::mpl::int_<value> >::id2type type; BOOST_STATIC_CONSTANT(unsigned, next = value + 1); }; template<class T> struct sizer { typedef char(*type)[encode_type<T>::value]; }; template<typename T> typename boost::disable_if< typename boost::is_function<T>::type , typename sizer<T>::type >::type encode_start(T const&); template<typename T> typename boost::enable_if< typename boost::is_function<T>::type , typename sizer<T>::type >::type encode_start(T&); template<typename Organizer, typename T> boost::type_of::msvc_register_type<T, Organizer> typeof_register_type(const T&, Organizer* = 0); } } } } #define BOOST_SCOPE_EXIT_AUX_TYPEDEF_TYPEOF_THIS_INDEX_(id) \ BOOST_PP_CAT(boost_se_thistype_index_, id) #define BOOST_SCOPE_EXIT_DETAIL_TYPEDEF_TYPEOF_THIS(id, new_type) \ enum { \ BOOST_SCOPE_EXIT_AUX_TYPEDEF_TYPEOF_THIS_INDEX_(id) = sizeof( \ *::boost::scope_exit::aux::msvc_typeof_this::encode_start(this)) \ }; \ typedef ::boost::scope_exit::aux::msvc_typeof_this::msvc_typeid_wrapper< \ BOOST_SCOPE_EXIT_AUX_TYPEDEF_TYPEOF_THIS_INDEX_(id) \ >::type new_type; #else // typeof(this) on other compilers are OK. #define BOOST_SCOPE_EXIT_DETAIL_TYPEDEF_TYPEOF_THIS(id, new_type) \ typedef BOOST_TYPEOF(this) new_type; #endif // typeof(this) For example: // within a member function BOOST_SCOPE_EXIT_DETAIL_TYPEDEF_TYPEOF_THIS(__LINE__, this_type); this_type obj = this; Thanks. --Lorenzo

1 0

[context] mini-review comments
by Jeffrey Lee Hellrung, Jr. 14 Jan '12

14 Jan '12

[Late, I know] [I'm going off http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html] [Apologies if these are just repeating previous comments!] How do you store the function and function arguments passed to the context constructor? Are they bundled into memory allocated by the stack allocator? I couldn't find it in the documentation, and whatever the answer, seems like something that should be mentioned. "The maximum number of arguments of *context-function* is defined by BOOST_CONTEXT_ARITY (default is 10) and might be changed." Hopefully you mean, more specifically, that BOOST_CONTEXT_ARITY might be *increased*. Also, consider using variadic templates if available? Great examples! Would it be possible to also show the expected output, just so the reader can verify that he or she understands what should be happening? Given that void pointers are used to communicate between contexts, I almost would've expected the context constructor to simply take a void (*)( void* ) argument and context::start to take a void* argument which would be passed to the function pointer. Can you elaborate on the rationale for the low-level interface for communicating between contexts while still providing a relatively high level interface for specifying the context function? The documentation for the stack allocator concept doesn't completely define the semantics of the size parameter of stack_allocator::allocate/deallocate. I presume it is the stack size in bytes, but that should be explicit in the documentation. And I presume allocate is only required to return a pointer to *at least* size bytes of free memory. Also, you don't mention alignment requirements; what are they? I'm somewhat surprised default_stacksize() always returns 256*1024. I think it might be safer to make this implementation-defined, but some minimum size (as with everything else in C++...). Also, strictly speaking, the documentation is incorrect. It reads "Defines a default stack size of 256 kB", but defalt_stacksize() doesn't define anything, it just returns a number. And this description is inconsistent with the remaining function descriptions. I would do: "Returns the default stack size, which is implementation-defined but at least 256 kB." In "Low level API (boost_fcontext_t)", s/stated/started/. Also, what's the magic number 262144? Oh, I see, 262144 = 256 * 1024...maybe the latter expression would be more intuitive? Again, I can guess what the output of the example would be, but would be helpful to have the expected output handy. Just a nitpick on member variable names. boost_fcontext_stack::ss_base/ss_limit: what does "ss" mean? boost_fcontext::fc_stack/fc_link: I presume the prefix "fc" is short for "fcontext", in which case, isn't it redundant? Normally I wouldn't be picky about member variable names but these are precisely the documented API. In "Rationale", you give "[o]ther low level APIs and their caveats"; I'm guessing these are, specifically, alternatives to boost_fcontext_t but are *deficient* in some respect. It might clear things up if you make that explicit, and further group "setjump()/longjmp()", "ucontext_t", and "Windows fibers" into a common heading. Overall, I think the documentation and interface are good. I didn't look at the implementation, but I did see that someone else did, so...I'm not too worried about a correct implementation. As long as there's a full suite of tests. I also didn't try to use the library, but now I'll have to find an excuse :) These are all relatively minor comments, and although I hope Oliver will address them, it won't hold up my approval of Boost.Context. - Jeff

3 7

[fusion] Getting the adapted structure's member names
by Andy Venikov 14 Jan '12

14 Jan '12

struct alien { std::string color_; std::string planet_; bool benevolent_; }; BOOST_FUSION_ADAPT_STRUCT( alien, (std::string, color_) (std::string, planet_) (bool, benevolent_) ) I know how I can get to the actual member values, i.e. I could check at<2>(anAlien) to see if I should run away or not. But what if I wanted to get to the member names? (In this example it would be "color_", "planet_" and "benevolent_") It could be very useful for example for serialization that stores not just values but also the names of the values. Printing structures to stdout for inspection would be a breeze too. Since BOOST_FUSION_ADAPT_STRUCT is a macro, surely the member names could be strigized and stored somewhere. Thanks, Andy.

2 1

__COUNTER__ vs __LINE__
by lcaminiti 13 Jan '12

13 Jan '12

Hello all, Many of Boost macro APIs PP_CAT symbols with either __LINE__ or __COUNTER__ to make them unique (MPL_STATIC_ASSERT, SCOPE_EXIT, etc). AFAIK, __LINE__ is C++03 standard while __COUNTER__ is only a MSVC extension. I think using __COUNTER__ instead of __LINE__ might allow to expand a macro multiple times on the same line... but a part from that: What's the reason for using __COUNTER__ on MSVC instead of just using __LINE__ for all compilers? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-COUNTER-vs-LINE-tp4286398p4286398.… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 6