December 2009 - Boost - lists.boost.org

Linking Errors in Boost Logging
by nsk＠umd.edu 31 Dec '09

31 Dec '09

Hi, I am a beginner in using the Boost Libraries. I came across them when I was trying to implement the Boost Logging Framework version2 from John Torjo's website. I tried implementing the starter project(http://torjo.com/log2/doc/html/starter_project.html) from Boost Log documentation using Visual Studios 2005 IDE. I got the following 2 errors: error C2440: '<function-style-cast>' : cannot convert from 'const char [13]' to 'boost::logging::formatter::tag::time' and error C2780: 'void boost::logging::writer::format_write<formatter_base,destinatio n_base,lock_resource,apply_format_and_write,router_type,format ter_array,destination_array>::add_formatter(formatter,const boost::logging::char_type *)' : expects 2 arguments - 1 provided So, I commented the formatter::tag::time line assuming that I don't need time to be displayed for the time being. The program complied properly but it gave me link errors: error LNK2019: unresolved external symbol "struct boost::logging::filter::use_tss_with_cache<10> * __cdecl g_l_filter(void)" (?g_l_filter@@YAPAU? $use_tss_with_cache@$09@filter@logging@boost@@XZ) referenced in function "void __cdecl `anonymous namespace'::`dynamic initializer for 'ensure_log_is_created_before_maing_l_filter''(void)" (?? __Eensure_log_is_created_before_maing_l_filter@? A0x6e6fd73c@@YAXXZ) my_app_log.obj and error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup MSVCRTD.lib Please let me know whether I am missing some linker dependencies. Please help! -Nik Kale

3 2

Major code changes deadline approaching
by Vladimir Prus 30 Dec '09

30 Dec '09

Boosters, The deadline for "major code changes" for 1.42 is Monday, January 4, 2010. Please try to get all big features merged to release branch by that date, and let the release team know if there are any issues. The next deadline will be Jan 11, when the release branch will be closed for all changes, except by explicit permission. -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

5 6

is_explicitly_convertible
by Daniel Frey 29 Dec '09

29 Dec '09

Just in case someone's interested: I implemented is_explicitly_convertible for GCC 4.4+ (4.3 doesn't work). Since it uses lots of C++0x-ish stuff, it is likely not a good addition to boost::type_traits, but I figured the people here might be interested anyway :) #include <type_traits> namespace boost { namespace impl { template< typename T > T make(); template< typename From, typename To > decltype( To( make< From >() ), make< std::true_type >() ) select( int ); template< typename, typename > std::false_type select( ... ); } template< typename From, typename To > struct is_explicitly_convertible : std::is_same< decltype( impl::select< From, To >( 0 ) ), std::true_type > { }; } struct X { X( double& ); explicit X( int& ); }; #define STATIC_ASSERT( X ) static_assert( X, #X ) int main() { STATIC_ASSERT(( boost::is_explicitly_convertible< double&, X >::value )); STATIC_ASSERT(( boost::is_explicitly_convertible< int&, X >::value )); STATIC_ASSERT(( !boost::is_explicitly_convertible< void*, X >::value )); } Regards, Daniel

1 0

boost::serialization, binary archive contents
by Dan 29 Dec '09

29 Dec '09

Hi All, Im not sure if this the correct mailing list or not.. in fact im not sure if i'm even going about this the right way.. forums are so much easier.. Im using the boost::serialization library, im attempting to serialize an image file from the freeimage library. It is working beautifully if i serialize to a text archive however, binary archives fail to load with a "stream error" exception. With the freeimage library i can save the image to memory and then retrieve the pointer to the start memory address and also retrieve the size. With this information I attempt the following (NOTE, "io" is the freeimage memory stream (fipMemoryIO) which is returning the memory pointer and the size): void save(Archive & ar, const unsigned int version) const { BYTE * pData; DWORD dwSize; io.acquire(&pData1, &dwSize); ar & dwSize; boost::serialization::array<BYTE> ao = boost::serialization::make_array<BYTE>(pData, dwSize); ar & ao; } void load(Archive & ar, const unsigned int version) { BYTE * pData; DWORD dwSize; ar & dwSize; pData = new BYTE[dwSize]; boost::serialization::array<BYTE> ao = boost::serialization::make_array<BYTE>(pData, dwSize); ar & ao; // <----------- This throws an exception } The above throws the exception.. even though it succeeds with a text archive. What is even more frustrating is that if (when saving) the contents pData1 points to are changed, when loading there is no exception. (Obviously the bitmap would be corrupt but thats beside the point). void save(Archive & ar, const unsigned int version) const { BYTE * pData; DWORD dwSize; io.acquire(&pData1, &dwSize); ar & dwSize; memset(pData1, 0xAB, dwSize); // <--- Add this line an no exception is thrown. boost::serialization::array<BYTE> ao = boost::serialization::make_array<BYTE>(pData, dwSize); ar & ao; } I am at a loss. If i want to write x number of bytes it should write x number of bytes no matter what those bytes are.. I must be doing something wrong because this just doesnt make sense. The exception is always thrown in basic_binary_iprimitve.hpp if(scount != s) boost::serialization::throw_exception( archive_exception(archive_exception::stream_error) ); Regards, Dan

3 4

[typeof] Determining if a type has been registered or not at compile time
by Edward Diener 27 Dec '09

27 Dec '09

Is there any way one can determine whether a type has been registered or not with Boost.Typeof at compile time so that the information can be used in TMP ? I am thinking, of course, of the use of typeof in a template, where a template parameter may or may not be aregistered type when the template has been instantiated. I would like to provide my own TMP fallback code if the type has not been registered rather than see an immediate compiler error generated. Something like: boost::mpl::eval_if < boost::typeof::registered<T>, // this would be nice to have boost::mpl::identity<BOOST_TYPEOF_TPL(some_expression)>, boost::mpl::identity</* use another facility to get the type I want into a metafunction*/> >

2 4

Interest check: Boost.Mock
by Peter Bindels 26 Dec '09

26 Dec '09

Hi all, Over the past three-quarters of a year I've been working (with three friends) on a mocking framework for C++. In our vision, it would be a good complement to Boost.Test for testing classes separate from interfaces required - it would improve the ability to unit-test the classes that tie others together and that implement higher-level algorithms. It does this by creating an object that is "derived" from a given class at runtime, and replacing the functions with functions that redirect to verifying logic. The verifying logic uses basic structures to record expectations and to verify they happened. These ways of creating an object at runtime and modifying it are highly compiler dependant but remarkably portable - as it runs on at least 3 different compiler series (GCC, MSVC, EDG-based) and 5 platforms (Windows XP, Windows CE, Linux, QNX, bare platform), with few modifications. The library has been released under the name "Hippo Mocks" already. I'm interested in submitting it to Boost for three reasons. First of all, I believe that there may be obvious or very interesting optimizations or expansions I do not notice. Second, as Christian has elaborated on already, having the Boost tag on the project makes it more noticed and more used. As it has taken quite a bit of time from me already I would like people to use it. Third, Boost.Test allows testing code but does not support mocking. In the environment of unit testing, anything that is not a base library benefits from mocking by abstracting away details that are irrelevant and that will break your test unnecessarily. For Boost the main changes would be superficial in the naming and in using more default libraries instead of a new implementation. For Hippo Mocks I've decided to make no assumptions in anything over C++98 so there's a full Tuple implementation and so on. If there's an interest I'll spend the evening porting the code to qualify for the Boost coding norms and upload it to the vault (if I can - but that should be OK). I would like you to take a look at the code and tell me what you think of it. Thanks for your time. Kind regards, Peter Bindels

8 10

Information about BMock
by Sterkin, Asher 24 Dec '09

24 Dec '09

Gennady, Recently I've came across discussion about extending the Boost.Test framework with a mocking capabilities: http://old.nabble.com/Interest-check:-Boost.Mock-td23958875.html I've even found a new header file mock_object.hpp within the 1_41 distribution, but not any documentation yet. There was a question about BMock library I developed and presented about at BoostCon09. The main differentiator of BMock from the rest of C++ frameworks I'm familiar with (except maybe MockItNow) is that it does not require neither classes, nor virtual methods. It does use heavily BOOST.Preprocessor and, at certain degree, boost meta-programming capabilities. Even though it has some historical quirks BMock has two major advantages, in my view, unsurpassable yet: a) Ability to dynamically mock ANY function or method. The function definition header needs to be wrapped with a special BMOCK_FUNCTION macro. Opposite to MockItNow this proves a fully portable solution, which does not depend on profiler API or any other low-level compiler capabilities. a) Deep integration with Boost.Test library, most importantly with its diagnostics. So far it proved itself as an extremely useful tool for embedded software development in C/C++. Attached you will find BMock documentation (sorry, not Boost standard :(). Not everything is relevant and not everything should remain, but hopefully you will get an adequate impression about how does it work from the user perspective. As I explained it to Dave during the BoostCon 09 I do not think that BMock in its current state is suitable to be a separate contribution to the Boost library, nor do I think it should be. From the beginning the BMock was conceived as a lightweight (well, as much as possible) extension to Boost.Test. If you find it interesting I will be happy to send you all sources (not too much) and to discuss how to proceed further. Regards, Asher Sterkin Asher [cid:image001.png@01CA84E9.267C30C0] <http://twitter.com/asterkin> [cid:image002.png@01CA84E9.267C30C0] <http://www.twitpic.com/photos/asterkin> [cid:image003.png@01CA84E9.267C30C0] <http://disturbingthoughts-asher.blogspot.com/> [cid:image004.gif@01CA84E9.267C30C0] <http://www.linkedin.com/pub/asher-sterkin/3/106/10a> ________________________________ This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster(a)nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. An NDS Group Limited company. www.nds.com Gennady, Recently I’ve came across discussion about extending the Boost.Test framework with a mocking capabilities: [1]http://old.nabble.com/Interest-check:-Boost.Mock-td23958875.html I’ve even found a new header file mock_object.hpp within the 1_41 distribution, but not any documentation yet. There was a question about BMock library I developed and presented about at BoostCon09. The main differentiator of BMock from the rest of C++ frameworks I’m familiar with (except maybe MockItNow) is that it does not require neither classes, nor virtual methods. It does use heavily BOOST.Preprocessor and, at certain degree, boost meta-programming capabilities. Even though it has some historical quirks BMock has two major advantages, in my view, unsurpassable yet: a) Ability to dynamically mock ANY function or method. The function definition header needs to be wrapped with a special BMOCK_FUNCTION macro. Opposite to MockItNow this proves a fully portable solution, which does not depend on profiler API or any other low-level compiler capabilities. a) Deep integration with Boost.Test library, most importantly with its diagnostics. So far it proved itself as an extremely useful tool for embedded software development in C/C++. Attached you will find BMock documentation (sorry, not Boost standard L). Not everything is relevant and not everything should remain, but hopefully you will get an adequate impression about how does it work from the user perspective. As I explained it to Dave during the BoostCon 09 I do not think that BMock in its current state is suitable to be a separate contribution to the Boost library, nor do I think it should be. From the beginning the BMock was conceived as a lightweight (well, as much as possible) extension to Boost.Test. If you find it interesting I will be happy to send you all sources (not too much) and to discuss how to proceed further. Regards, Asher Sterkin Asher [2]twitter [3]twitpic [4]favicon [5]Linkedin _________________________________________________________________ This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster(a)nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. An NDS Group Limited company. www.nds.com References 1. http://old.nabble.com/Interest-check:-Boost.Mock-td23958875.html 2. http://twitter.com/asterkin 3. http://www.twitpic.com/photos/asterkin 4. http://disturbingthoughts-asher.blogspot.com/ 5. http://www.linkedin.com/pub/asher-sterkin/3/106/10a

1 0

[optional] Strict Aliasing Warnings on Trunk
by Dean Michael Berris 24 Dec '09

24 Dec '09

I've recently been seeing this error more and more especially on GCC with -Wall: /home/dean/boost/boost/optional/optional.hpp:407: warning: dereferencing pointer ‘<anonymous>’ does break strict-aliasing rules /home/dean/boost/boost/optional/optional.hpp:427: note: initialized from here and: /home/dean/boost/boost/function/function_base.hpp:321: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/dean/boost/boost/function/function_base.hpp:325: warning: dereferencing type-punned pointer will break strict-aliasing rules This is on Linux and GCC 4.4.1. I'm not an expert in this regard but is there a way to either silence or avoid these warnings? Anything you want me to try from my end? Thanks in advance and I hope this helps. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

12 40

Using Boost.Atomic for shared_ptr
by Phil Endecott 24 Dec '09

24 Dec '09

Dear All, I have just had a quick look at how easily shared_ptr could be adapted to use Helge's proposed Boost.Atomic. To me it looks very simple, but maybe someone who knows more about all this could have a look? I took the non-threaded implementation in sp_counted_base_nt.hpp as a starting point, and simply changed the two counts from long to boost::atomic<long> : boost::atomic<long> use_count_; // #shared boost::atomic<long> weak_count_; // #weak + (#shared != 0) Then, the majority of the methods don't need to change since the atomic template provides atomic versions of e.g. operator++. The one that does need more work is add_ref_lock, which I've implemented as follows: bool add_ref_lock() // true on success { while (1) { long c = use_count_; if (c == 0) return false; if (use_count_.compare_exchange_weak(c,c+1)) return true; } } There is also the question of memory barriers. I understand that things like operator++ provide the most pessimistic memory barriers, so ideally these should be replaced with calls that use the right barriers. Does anyone have any thoughts about how this would compare with the current custom assembler implementations? Cheers, Phil.

4 5

[fusion] change on trunk breaking proto
by Eric Niebler 23 Dec '09

23 Dec '09

Hi Fusion gurus. I'm chasing an elusive bug that the following Proto test has exposed: http://beta.boost.org/development/tests/trunk/developer/output/RW_WinXP_VC-… All is well on the release branch, but on trunk, Proto's examples.cpp test is failing -- but only on MSVC! I suspect Fusion because if I replace the version of Fusion on trunk with the one on release all is well. (Caveat: when I do this, I also need to make a corresponding change to the as_callable function object in proto/transform/fold.hpp to accommodate the changed argument order of fusion::fold's functor.) It seems something is causing MSVC to prematurely instantiate a template used in a Proto transform, but I can't see what. I first suspected the recent changes to fusion::fold, but that seems not to be the case. If I just take the release version of fusion::fold, the problem still manifests. The problem must be elsewhere. Does anyone from Fusion team want to give this a crack? I'll be happy to help. -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 7