- Boost - lists.preview.boost.org

boost threads and linking boost statically into a DLL
by Carlos Empujon 13 Nov '12

13 Nov '12

Recently I had some trouble to linking boost statically into a DLL. After searching around I found that there has been a discussion on http://boost.2283326.n4.nabble.com/Fwd-Thread-Solution-to-conflict-with-MFC… However it seems that the patch proposed there (see below) did not make it into the trunk. Has there been a special reason why this has not been included into the normal distribution? Cheers, Carlos /** * tss.cpp * * This file is intended to correctly build a dll using boost::thread * It is taken from * * http://boost.2283326.n4.nabble.com/Fwd-Thread-Solution-to-conflict-with-MFC… * * $Id$ */ #include <windows.h> #include <boost/thread/detail/tss_hooks.hpp> extern "C" BOOL WINAPI RawDllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID); namespace { BOOL WINAPI dll_callback(HANDLE h, DWORD dwReason, LPVOID p) { #ifdef _DLL if(!RawDllMain(static_cast<HINSTANCE>(h),dwReason,p)) return false; #endif // _DLL switch (dwReason) { case DLL_THREAD_DETACH: boost::on_thread_exit(); break; case DLL_PROCESS_DETACH: boost::on_process_exit(); break; } return true; } } extern "C" { extern BOOL (WINAPI * const _pRawDllMain)(HANDLE, DWORD, LPVOID)=&dll_callback; } namespace boost { void tss_cleanup_implemented() {} }

1 0

Release branch now open for merging
by Marshall Clow 12 Nov '12

12 Nov '12

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging *does not* require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Release Managers, Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

1 0

[iostream] Bug in indirect_streambuf::seek_impl
by Jorge Lodos Vigil 12 Nov '12

12 Nov '12

Hi Currently indirect_streambuf::seek_impl always modifies input and output pointers with code: setg(0, 0, 0); setp(0, 0); See detail/indirect_streambuf.hpp. However, this is incorrect for dual seekable streams buffers which only modifies one set of pointers on each seek (in or out). As a consequence, dual seekable devices cannot be correctly seek. Those 2 lines should be replaced by: if (is_convertible<category, dual_seekable>::value) { if (which == BOOST_IOS::in) { setg(0, 0, 0); } if (which == BOOST_IOS::out) { setp(0, 0); } } else { setg(0, 0, 0); setp(0, 0); } I have created ticket https://svn.boost.org/trac/boost/ticket/7681 Thanks, Jorge

1 0

enable_if quirk? bug?
by Gennadiy Rozental 12 Nov '12

12 Nov '12

Hi, While working on some portability for Boost.Test I found this weird behavior. Abstracting out Boost.Test specific staff it goes like this: template<typename T> inline typename boost::enable_if_c<!boost::is_float<T>::value, int>::type foo( T&& v ); template<typename T> inline typename boost::enable_if_c<!boost::is_float<T>::value, int>::type foo( T&& v ) { return 1; } ... foo(1); MSVC 10 producing this error: error C2668: 'foo' : ambiguous call to overloaded function test.cpp(31): could be 'int foo<int>(T &&)' with [ T=int ] test.cpp(27): or 'int foo<int>(T &&)' with [ T=int ] while trying to match the argument list '(int)' Now change boost::enable_if_c with seemingly equivalent std::enable_if: template<typename T> inline typename std::enable_if<!boost::is_float<T>::value, int>::type foo( T&& v ); template<typename T> inline typename std::enable_if<!boost::is_float<T>::value, int>::type foo( T&& v ) { return 1; } and MSVC 10 is happy to accept this code. This is somewhat unfortunate since I hoped to use boost::enable_if across compilers. Gennadiy

4 5

[mpl] Strange error using boost::mpl::eval_if
by Edward Diener 12 Nov '12

12 Nov '12

No doubt I have had some sort of C++ brain blockage but the following code using boost::mpl::eval_if gives an error and I cannot see how this would be. This is a simplified case of a more serious problem. --------------------------------------------------------------- #include <boost/mpl/bool.hpp> #include <boost/mpl/eval_if.hpp> template<class T,class C> struct AAA { static const bool value=true; typedef boost::mpl::bool_<value> type; }; template<class T> struct CCC { static const bool value=true; typedef boost::mpl::bool_<value> type; }; template<class T> struct BBB : CCC<T> { }; template<class T1,class T2,class T3,class T4> struct DDD : boost::mpl::eval_if < boost::mpl::false_, BBB<T1>, AAA<int,int> > { }; template < class T1, class T2 = int, class T3 = int, class T4 = int > struct EEE : DDD<T1,T2,T3,T4> { }; int main() { bool result = EEE<int,int>::value; return(result ? 1 : 0); } ----------------------------------------------------------------------- Compiling with gcc 4.6.0 in MingW under Windows I get: test_has_mem_fun.cpp: In function 'int main()': test_has_mem_fun.cpp:50:17: error: 'value' is not a member of 'EEE<int, int>' "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -Wno-variadic-macros -std=c++0x -DBOOST_ALL_NO_LIB=1 -I"..\..\.." -c -o "..\..\..\bin.v2\libs\tti\test\test_has_mem_fun.test\gcc-mingw-4.6.0\debug\test_has_mem_fun.o" "test_has_mem_fun.cpp" ----------------------------------------------------------------------- I must be overlooking something obvious but I cannot see it. Any help showing me what is wrong would be appreciated.

3 3

[iterator] [property_map] Enhancement proposals
by Louis Dionne 12 Nov '12

12 Nov '12

Dear boost, First of all, let me quickly introduce myself as this is my first post here: I am a 20 years old programming enthusiast with interest for metaprogramming, functional programming and library design. I also have a strong will to contribute to open source projects since I love the philosophy behind it and it is a great way to develop new skills and to work with talented people. The object of this message is to collect feedback on several enhancement proposals I have prepared for two existing libraries: [boost.iterator] [boost.iterator.accessor_iterator] The accessor_iterator is an iterator adaptor that returns a reference to a member of its pointee when dereferenced. I see it as another step in the direction of easier iterator composition, which has helped me writting less code in the past. [boost.iterator.chained_output_iterator] The chained_output_iterator is an iterator adaptor allowing to apply a functional transformation to a value before outputing it into another output iterator. It is much like a function_output_iterator that would forward its result to another output iterator. It allows for cool stuff like creating a pipeline of operations without having to create temporary storage. [boost.property_map] [boost.property_map.accessor_property_map] The accessor_property_map is a property map returning a reference to a member of the key it is given. It is much like the accessor_iterator for property maps. [boost.property_map.chained_property_map] The chained_property_map is a tool for property map composition. It takes two property maps and uses a value in the first one as a key in the second one to perform its put, get, and operator[] operations. [boost.property_map.property_traits] I feel like the boost/property_map/property_map.hpp header is a little bit bloated and not quite as modular as it could be. For now, I propose that we move the code dealing with property_traits into the boost/property_map/property_traits.hpp header and that we provide metafunctions to check for adherence to property map types. By providing an include in the boost/property_map/property_map.hpp header, backward compatibility is maintained and we simply increase modularity. All the code is available on github: https://github.com/ldionne/boost-submissions To see how each class can be used, you may look at the unit tests for the corresponding class. If anything is accepted, I will be pleased to write documentation and examples for the concerned feature and to integrate it into the existing documentation. Looking forward to your feedback, Louis Dionne

2 11

Re: [boost] hierarchy_tree container
by Morgan Freeberg 10 Nov '12

10 Nov '12

Okay thanks Jose, that helps. My search through the libraries did not pick up on these. By the time I did that I already had the application behavior I wanted, so on my end this has been a refactoring process; I can take a look at these and see if I did that the right way, or if perhaps these could've provided the functionality I need. >From skimming over the documentation, my initial impression is that they're both very cool implementations which might help me in future work, but some of what I did here is falling somewhat outside of that is provided by these. If you're still interested, I can provide an approximation of the challenges met here: 1. From a rather large not-quite-completely-standard XML file, I needed to parse from top to bottom, understanding the structure being created as containers are declared, sub-containers & leafs are added in, and each construct is eventually terminated. The process that does this would need to store not only the instantiation of the tree container, but a vector/array of references to the ancestors of some "current node" being built. That is so that, as it encounters terminating tags, the internal logic can say...this is ended, now this is ended, now this is ended...essentially so that it can "outdent" again. I can see with treetree and st_tree this is do-able if I write some level of intermediate code that builds such an array and maintains it, as I know lots of "standard" XML readers already do. (This I know from my attempts to find one I could actually use in my project.) The issue that would arise here is, I'd still need to write and test that code, and the result would in turn be redundant with what I did here...so it seems these two libraries recognize the same structure mine does, but the scope of purpose is a little bit different. My container internalizes all this parentage information so that when you're reading data sequentially in this way, the client code only needs to track the depth by way of counting the opening and closing tags, then make a call to the container that essentially says "add this, at this depth." Implication being: As a child of whatever. The container internally tracks the concept of "we are currently defining children of so-and-so." 2. In a configuration file of my own making, I needed to pre-declare what the tree should look like. This is not XML, it's a list of statements that say "that class we already defined on line 3, here on line 9 we are defining a class that is a child of that." The method described above that is good for reading these pseudo-XML files, it would not work for that. What is needed here is either a sequential or random-access search by name...In this case you need to write code on top of my container, as well as on top of treetree and s_tree. So in this requirement, all three provide the same functionality. 3. I chose an enumerator/callback interface that works by way of numeric return codes, because I needed it for a variety of commands to be executed on the trees -- some do searches, some validate, some filter (search without terminate after find), et al. The point to dynamically constructing a tree was to be able to do integrity checks on it, and then execute some different application behavior on each node within what I could be sure was the same tree as what I had seen before. So for my particular implementation this is a big benefit, because I can use a chain-of-responsibility design pattern to associate each command with a name, an invoker, some help text, and then a callback routine that defines the behavior. Again, it seems those other two containers can meet the requirement, after intermediate code has been written to adapt them to this application-specific purpose, which in turn has been internalized in my container. Much shorter version: Enum/callback pair for listing the contents of the tree, with numeric return codes; two distinctly separate methods for getting the data in at run-time, one method for reading a streaming mechanism such as XML, the other method for specifically identifying the parent of a new node -- "child of that guy, you made before, over there." The test program I provided mixes those two methods up, so that it is demonstrated they can both work on the same container once it is instantiated. I'll run some tests with these and, if you're interested, provide you with a more fully-informed report on where there may & may not be full redundancy.

1 0

filesystem::path passed to GTest's assertion leads to stack overflow because of infinite recursion
by Andrey Upadyshev 10 Nov '12

10 Nov '12

Hi all, I found an interesting bug with 'filesystem::path' used with GTest: https://svn.boost.org/trac/boost/ticket/7564 I just want to discuss the design of 'path' class which iterator contains the 'path' itself. Don't you think it's nice to fix thing? Best regards, Andrey Upadyshev P.S. Sorry if this is wrong mailing list. Just let me know and I'll repost the message to boost-users <boost-users(a)lists.boost.org> mailing list.

2 5

[type_traits] templated type traits?
by Lorenzo Caminiti 10 Nov '12

10 Nov '12

Hi, Is there a way to inspect if a type is a template instantiaton (is_templated) and the type of the instantiated template parameters (arg1_type)? is_templated< std::vector<int> >::value // true is_templated< int >::value // false template_traits< std::vector<int> >::arg1_type // int Thanks, --Lorenzo

5 5

[wave] add_macro_definition("TEST=") behaves different than #define TEST
by Klaus Gütter 10 Nov '12

10 Nov '12

Test1 posted below produces: INT SPACE EOF SPACE IDENTIFIER SEMICOLON NEWLINE EOF While Test2 produces: INT SPACE IDENTIFIER SEMICOLON NEWLINE EOF The EOF in the third line of Test1 output is produced by the TEST macro expansion. If this expected behaviour? I found this surprising. (MSVC10, Boost 1.51) Regards, Klaus ---- Code: typedef cpplexer::lex_token<> token_type; typedef context< string::iterator, cpplexer::lex_iterator<token_type> > lexer_context_type; void Test1() { string instring("int TEST x;\n"); lexer_context_type ctx(instring.begin(), instring.end(), ""); ctx.set_language(language_support(support_c99)); ctx.add_macro_definition("TEST="); for (lexer_context_type::iterator_type it = ctx.begin(); it != ctx.end(); ++it) cout << get_token_name(token_id(*it)) << endl; } void Test2() { string instring("#define TEST\nint TEST x;\n"); lexer_context_type ctx(instring.begin(), instring.end(), ""); ctx.set_language(language_support(support_c99)); for (lexer_context_type::iterator_type it = ctx.begin(); it != ctx.end(); ++it) cout << get_token_name(token_id(*it)) << endl; }

2 2