- Boost - lists.preview.boost.org

Re: [boost] scoped_ptr deleter
by Berserker 15 Sep '09

15 Sep '09

Andrey Semashev wrote: > I'd opt for this change if it wouldn't affect the interface in the breaking way. > Otherwise, I like the way it is. I just tested your sample and thanks to the default template value (boost::checked_deleter) it does compile. Are you sure it breaks the interface? _________________________________________________________________ Scopri tutti i servizi Windows Live, guarda i video http://www.windowslive.it/videoGallery.aspx

3 2

[lexical_cast] lexical_cast does not throw bad_lexical_cast
by Carlos Rafael Giani 15 Sep '09

15 Sep '09

Hi, I've noticed that sometimes lexical_cast does not throw bad_lexical_cast. Instead, it throws 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >'. A catch clause expecting a bad_lexical_cast fails here. What seems confusing to me is that the lexical_cast docs do mention "catch (bad_lexical_cast &)" as correct code (http://www.boost.org/doc/libs/1_39_0/libs/conversion/lexical_cast.htm) The solution that worked for me was to catch boost::exception instead. Am I missing something here? I consulted the documentation, but still have no answer. It also seems that I am not alone with this problem; http://www.nabble.com/Porting-from-boost_1_33-to-boost_1_36-exception-td197… and http://archives.free.net.ph/message/20090715.183116.374b4777.en.html at least indicate this for me. regards, Carlos Rafael Giani

2 1

enabling/disabling floating point exceptions
by Gennadiy Rozental 15 Sep '09

15 Sep '09

Hi guys, I am looking to complete cross platform implementation of enabling/disabling logic in boost::execution_monitor. It looks like there is no standard interface available. I'm using _controlfp interface now on Windows. I also found these non-standard extensions: * feenableexcep/fedisableexcept available with glib 2.2 * fesettrapenable avaialble in Dinkumware (implementation of STL?) and HP * sun has something called fex_set_handling. not sure when it's available though * header fpu_control.h. Not sure where it's available though. * MAC OS X has something called _MM_SET_EXCEPTION_MASK in xmmintrin.h It also seems that in some cases the switch is compile time only (using compilation option). Would anyone care to extend this list/comment on it's applicability and/or correctness? Another change I am considering is to split floating point exception catching from other system exceptions. It seems perfectly valid scenario to set catch_system_error to false (thus avoid catching access violations etc) but still willing to catch and process floating point exception. What do you think? Gennadiy

4 4

Re: [boost] scoped_ptr deleter
by Berserker 15 Sep '09

15 Sep '09

Stewart, Robert wrote: > I'm sorry, I read your post too quickly, seeing "shared_ptr" > where you wrote "scoped_ptr." No problem :) > That, of course, requires nothing more than a static member > function in the supplied deleter type as your proposal implies. I suggested a "deleter" (default boost::checked_deleter) instead of a static function because imho an operator()(T *p) is a preferable approach (it doesn't require a "specific" function name) and moreover boost::checked_deleter is already there :) I really hope this patch will be applied. _________________________________________________________________ Gossip, Sport, Notizie... Accendi la Messenger TV! http://www.messenger.it/messengerTV.aspx

1 0

scoped_ptr deleter
by Berserker 15 Sep '09

15 Sep '09

I know it has been asked in the past, but I still don't understand why scoped_ptr lacks this feature. The "noncopyable nature" of scoped_ptr allows to support deleters with simply an extra template parameter (default value is boost::checked_deleter): this change doesn't require extra memory overhead (like in shared_ptr) and it consists of 2 lines. template<class T, class D = boost::checked_deleter> // first patch line class scoped_ptr { // ... public: ~scoped_ptr() { // ... deleter()(ptr); // second patch line, instead of boost::checked_delete } }; Any hope to apply this patch? _________________________________________________________________ Gossip, Sport, Notizie... Accendi la Messenger TV! http://www.messenger.it/messengerTV.aspx

3 2

Re: [boost] scoped_ptr deleter
by Berserker 15 Sep '09

15 Sep '09

A fix to my previous post, the first patch line should be: class D = boost::checked_deleter<T> instead of: class D = boost::checked_deleter Obvously the same implementation is applicable to boost::scoped_array using boost::checked_array_deleter _________________________________________________________________ Le tue Emoticon ti sembrano poche? Scaricane di nuove! http://intrattenimento.it.msn.com/emoticon/

1 0

fixed documentation
by Frank Birbacher 14 Sep '09

14 Sep '09

Hello! I made two small changes to docs: https://svn.boost.org/svn/boost/sandbox-branches/birbacher/fix_documentation c56200 spelling in docs for graph c56201 enhancement for asio docs ip v4 and v6 to_bytes() I will notify the maintainers of the projects. Frank

1 0

non-branching min()
by DE 14 Sep '09

14 Sep '09

i'd like to present some kind of micro optimization towards pipelined cpus traditionaly min() has an implementation like template<typename type> inline type min(type a, type b) { return a<b ? a : b; } this function (even if inlined) introduces a branch in a sequence of instructions though branch prediction algorithms do exist they will guess at most 50% of them because routine input is arbitrary since a wrong branch prediction causes pipeline stall i thought that such a useful routine like min() MUST have non-stalling (read 'non-branching') implementation i thought hard and in the end recalled a simple implementation which is called LUT (for 'look-up table') here's what i finally got: template<typename type> inline type min(type a, type b) { const type c[2] = {a, b}; return c[b<a]; } intuitively this implementation should work slower than the first one but in real life it runs faster (roughly by a factor of 2 for 4 byte types on core2duo) here's a test code: #include <vector> int main() { typedef int type; const int n = 1000000; std::vector<type> v1(n), v2(n); //filling v1 and v2 somehow type min = BIG_VALUE; for (size_t i = 0; i<n; ++i) a = min(a, min(v1[i], v2[i])); //searching minima of v1 and v2 return 0; } however for 'double' it runs ~2% slower (i think it's because creating a lut for 2 elements 8 bytes each is slower than a branch on c2d) nevertheless i think it's a great approach at least for ints also max() can implemented very similar you may skip the rest example of usage imagine we want to implement a symmetric matrix that stores only half of its elements (say upper triangle) a00 a01 a02 --- a11 a12 --- --- a22 then access requests to the lower triangle elements would be redirected to upper triangle ones here we have a constraint that actually we only have access to elements a(i, j) where i<=j must always be true (look at indices above) if we use a branch like //... return i<=j ? a(i, j) : a(j, i); we get a pipeline stall almost every time we want to access an arbitrary element however if we rewrite it carefully as //... const size_t m = min(i, j); //non-branching min() here return a(m, m + abs(int(i) - int(j))); //abs() is also //non-branching we get rid of branches at all! and we can hope a pipelined cpu will handle it better than the other (branched) implementation -- pavel

9 14

Re: [boost] Are warnings acceptable artifacts from builds?
by Vinnie 14 Sep '09

14 Sep '09

>From http://sqlite.org/testing.html#coverage "Static analysis means analyzing code at or before compile-time to check for correctness. Static analysis consists mostly of making sure SQLite compiles without warnings, even when all warnings are enabled. SQLite is developed primarily using GCC and it does compile without warnings on GCC using the -Wall and -Wextra flags. There are occasional reports of warnings coming from VC++, however. Static analysis has not proven to be helpful in finding bugs. We cannot call to mind a single problem in SQLite that was detected by static analysis that was not first seen by one of the other testing methods described above. On the other hand, we have on occasion introduced new bugs in our efforts to get SQLite to compile without warnings. Our experience, then, is that static analysis is counter-productive to quality. In other words, focusing on static analysis (being concerned with compiler warnings) actually reduces the quality of the code. Nevertheless, we developers have capitulated to pressure from users and actively work to eliminate compiler warnings. We are willing to do this because the other tests described above do an excellent job of finding the bugs that are often introduced when removing compiler warnings, so that product quality is probably not decreased as a result."

16 31

[pool] Thread specific pool allocator
by James Bremner 14 Sep '09

14 Sep '09

I develop code to run on multiple processor machines. Moderate use of the standard template library (STL) containers cause programs to slow down when the work is split between threads running on different processors. This is because the STL default memory allocator is a thread-safe singleton and causes contention between the threads. The memory allocator provided by boost::pool_allocator is also a thread safe singleton. I have coded a thread specific memory allocator based on boost::pool and boost:thread_specific_pointer. My allocator creates a new instantiation for each thread it is used in, and so avoids contention between threads. The containers created with this allocator must be used carefully, not written to by more than one thread, because the allocator is not thread-safe ( that is the point! ) - however they provide dramatic performance improvements when my code runs on multiple processors. I do not expect my coding is to the high standard of the boost libraries, but I do believe it shows that something very useful can be done with a few lines of code. Any chance of a boost:thread_specific_pool_allocator in the near future? James Bremner

7 11

[serialization] Calling basic_streambuf::sync in basic_binary_iprimitive destructor
by Andrey Upadyshev 14 Sep '09

14 Sep '09

Hi, All! Anybody knows, does we really need to call std::basic_streambuf::sync in boost::archive::basic_binary_iprimitive destructor? Is it possible to not call it? I ask it because the call of sync with file stream buffer leads to skipping of the unreaded input data. I think it is not good, or al least it must be clear described in documentation, that binary_iarchive when used with file stream skips to the end of a stream. Andrey Upadyshev P.S. Sorry for my English

2 2

Re: [boost] C++ Manifesto
by christophe henry 13 Sep '09

13 Sep '09

> Why is there no Boost.ANTLR? Good question. I mean, if Spirit seems to you such a disservice to the community that you write the xth post about it, why not show how to do it right? I'm sure we would all benefit from it, because right now, I haven't read anything constructive in this post. At least Joel spent lots of time to offer a great library to the C++ community and I think he deserves better than such unconclusive criticism as "I think that it represents a disservice to the C++ community". Seeing from his user base, I respectfully allow myself some to disagree on that point. Now the challenge is simple: Make it better and you'll earn yourself some respect. Don't provide any alternative and land from now on in my spam box. Regards, Christophe _________________________________________________________________ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx

2 1

[thread] Obtaining thread id on Windows
by Agustín K-ballo Bergé 13 Sep '09

13 Sep '09

I've found a need to retrieve a thread id rather than a thread handle on Windows. There is no documented way to get it from the handle on XP (see http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/89728ee1-d9d… ). Would it make sense to add a get_native_id member function? Thank you. Agustín K-ballo Bergé.-

2 3

[variadic_templates][mpl]announcement:sandbox now has variadic_templates directory
by Larry Evans 12 Sep '09

12 Sep '09

There is now a sandbox directory for variadic templates: https://svn.boost.org/trac/boost/browser/sandbox/variadic_templates The tests in variadic_templates/libs/mpl/test/Jamfile have all passed. Some of those tests have been slightly modified to accommodate the variadic template version of mpl sequences. BTW, it's important to apply the gcc patch mentioned here: https://svn.boost.org/trac/boost/browser/sandbox/variadic_templates/README.… All sequences have been changed to use a new template: foldr_pack whose last argument is a parameter pack. That change also required a new binary template for each sequence: X_item_fold where X is one of: v l s m One reason for that change was to highlight the similarites of the sequences. Some other fold additions were: foldr_iter.hpp foldl_iter.hpp The foldr and foldl correspond roughly to iter_fold and reverse_iter_fold (or the other way around, I can't remember which). The reason for these additions is that they reflect more closely the way foldr and foldl are done in haskell, as indicated by the comments in the .hpp files. One useful application of the pattern expansion mentioned in section 3.6.1 of: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf is their use to easily define SEQ_c in terms of SEQ, where SEQ is any sequence. For example: template < typename Integral , Integral... Values > struct list_c : list < integral_c<Integral,Values>... > { typedef Integral value_type; }; Another addition is package_range_c.hpp which can be used to do something similar to range_c. The main motivation for this was the make_indexes on p. 16 of: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2080.pdf It was used in a prototype tuple implementation in: variadic_templates/libs/mpl/sandbox/tuple_non_recur.package_range_c.cpp Package_range_c was also useful in the implementation of unpack_args. A really interesting application of these pattern expansions might be another implementation of the cross_product template: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?CPPTM_Answer… The reason I think it would be useful is because the expansion of: integral_c<Integral,Values>... results in: integral_c<Integral,Value1> integral_c<Integral,Value2> ... integral_c<Integral,ValueN> where ValueI is the i-th element in Values... Now this is a cross product of a single element, Integral, with each element in Values...; hence, I would think that it would be a simple matter to just repeat this for any number of elements. IOW, instead of integral_c, there could be: template<typename Left, typename...Rights> struct pair_rights : pair<Left,Rights>... {}; and then that, somehow, could be done for each element in some list of Left's. Would somebody like to try this? Hope somebody else finds this useful. -regards, Larry

1 0

[iterators] zip_iterator requires random_access_iterator?
by Dean Michael Berris 12 Sep '09

12 Sep '09

Hi Everyone, According to the documentation (http://www.boost.org/doc/libs/1_40_0/libs/iterator/doc/zip_iterator.html) All iterator types in the argument IteratorTuple shall model Readable Iterator. When I use a BidirectionalIterator (list<...>::iterator) zip_iterator fails to compile, while when I use a RandomAccessIterator (vector<...>) it compiles just fine. I have a nesting like this: make_filter_iterator( filter(), make_zip_iterator( make_tuple( container.begin(), make_transform_iterator( container.begin(), function() ) ) ) The first line in the error logs is: /home/dean/boost/boost/iterator/detail/minimum_category.hpp: In instantiation of ‘boost::detail::minimum_category_impl<false, false>::apply<boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::bidirectional_traversal_tag>, boost::random_access_traversal_tag> I'm using Boost SVN trunk updated to revision 56153 -- did I find a bug? HTH -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

1 0

Build files locations, try 2
by Vladimir Prus 12 Sep '09

12 Sep '09

Some time ago, I have raised the concern that CMakeList.txt files violate directory structure requirements. See: http://thread.gmane.org/gmane.comp.lib.boost.devel/189496/ Back then, the discussion did not lead anywhere, and no further progress was made for 2.5 months. So, let me try to phrase this a bit differently. Is it fine with everybody if I move Jamfiles out of 'build' folder of every library one level higher? Thanks, Volodya

4 4

MSVC decorators still in autoconfig?
by Stephan Menzel 11 Sep '09

11 Sep '09

Hi, I am just about to migrate to 1.40 and I noticed the changed naming scheme. So the TOOLSET and BOOST_LIB_VERSION defines are missing when I build the libs (even when using layout=tagged in bjam) but the autoconfig, specifically auto_link.hpp, still includes this in MSVC's autolink feature. So as far as I can see autolink will not work in Windows, right? At least, it doesn't for me unless I change auto_link.hpp line 312 so skip this. Is this a bug or am I overlooking something important? Cheers, Stephan

3 4

C++ Manifesto
by Christian Schladetsch 11 Sep '09

11 Sep '09

I wrote: A problem seems to be that we are trying to be meta-meta when meta- alone suffices. > The GCC frontend hasn't been integrated into mainline GCC, the LLVM > frontend is beta and similarly lives out of tree. A substantial, > incompatible, rewrite of the language is currently in progress. > The same can be said for C++0x. And LLVM is not in beta w.r.t Apple. > > I've used D for some fun side projects, it is a nicer language than C++. > However, would I suggest using it at work, and risking a major, long-living > software project on it? Unfortunatly not yet, and most people I've > personally spoken to agree. > I am speaking out of my backside when I say anything on this matter, as I have not written anything substantial in D. But my original point remains: why not? There are no tablets written in stone stating Thou Shalt Write In C++. Sure, there are many people that are "language lawyers" and understand the finer intricacies of ADL and that is their livelihood. Great for them. Most of us understand (or could understand) most of boost. It isn't that hard - most of the "chicanery" is to do with xplat systems creating code-paths that even the original authors don't understand. The rest of the magic is in Spirit and similar expression-template-based systems that are only hard to understand because of their working domain. If they were written procedurally, they would be fine, or if they were written in ML they would be fine but because they are written in a strange mixture of bastardised C++ they are esoteric and deemed to be "excellent C++". I'm sorry. I don't think that Spirit is excellent C++. I think it is terribly clever C++ and I think that it represents a disservice to the C++ community. Further, I think it has singularly set back language development by years. The damage is untold - if only there was active C++ support for a system like ANTLR for the past few years rather than Spirit then maybe we wouldn't be in the mess we are in now. To be clear, I don't mean any disrespect to Joel or to the Spirit2 code-base per se. I just don't think that the C++ compiler was ever meant to be a language tool. I personally have witnessed at least two groups of coders reject a DSL-based solution because they thought that to do so "correctly" would mean using Boost.Spirit, which was beyond them. Meanwhile, ANTLR has no C++ support. It's a crying shame. Why is there no Boost.ANTLR? The question then stands: why stick with C++ for everything? What can D do in similar circumstances? (I know the immediate answer is "we don't use D" but can we please put that aside for a year). I don't know. I haven't used it. I have nothing to do with Digital Mars or Alex. I care only about writing effective code. I feel that C++?? is becoming just that. It doesn't matter that I can (eventually) understand the latest boost library, or the latest boost technique. What matters is what is the best way to write efficient code? Because I can agree with you, when you think that you are writing a lot of boilerplate nonsense to get basic things done. Move semantics and the problems that Ion is having is a case in point. I don't mean to be a misery-guts, but after having looking deeply at the issues I really don't see a way that it can be done without a language change. C++ is a fine language, but seriously, the authors didn't have any idea on how we'd use it and the differences are compounding exponentially. When C++ is no longer the best way (and yes, that is a "when" not an "if"), I would like to think that I am open-minded enough to be on that wave. Is that time sooner rather than later? Say you want to write a parser/AST walker/executor for a basic language with scoped variables and continuations. Is Boost.Spirit the best way to do so? Is it *really*? Say you want to write an object factory with persistent objects. Is Boost.Serialisation and Boost.Function the best way forward? How will you you store the functions? Say you want automatic resource management. shared_ptr<> doesn't cut it. It is too slow for single-threaded and at the same time doesn't deal with cycles. Say you want to write a geometry library. Ok, stop right there.... Is Boost.Graph the best way to make a basic DAG? I've tried all these systems. They work, there is no doubt. Do they work well, in practice? Has there been any real-world review of the efficacy of boost libraries in general? I'm sure there has, as many here could attest, but this is a biased sample set. I wonder how much and what aspects of boost are used in the wider community? I for one use foreach, shared_ptr, unordered, mpl, some fusion, and other bits and pieces. No-one in my team uses anything other than foreach and shared_ptr - and there is a lot of confusion I have to deal with relating to their use of weak_ptr<> and locking etc with that. It seems that 5 years ago I had to argue that boost was Ok to use, and I still feel like I am saying the same things. I am approaching the stage where I wonder why I continue to apologise for it. What do you use? Which parts of boost are good to use with least impact? This has turned into a manifesto against boost. I didn't mean that to be the case when I started, but so be it. I come from the real world, and there are real programmers that just don't know and don't want to deal with problems they can't solve. As a lead, I have to make technology decisions and I am clearly frustrated with the potential of both boost and C++ in general. Sometimes I think that it would be easier to just change language completely to C#/asm or D/C++/asm. I am in the position now to decide what will be the language for the next game made in company A. I am strongly tempted to make the core in C# with callouts to C++ libs for physics and render. Personally, after 20-odd years and still seeing the likes of Lucanus swing on the rope with his geometry lib, it makes me wonder if C++ is really what the real-time world needs. Regards, Christian.

9 10

scoped_allocator_ptr
by Felipe Magno de Almeida 11 Sep '09

11 Sep '09

Hi, Is there an interest in a scoped_ptr that receives a Allocator parameter? I've been needing this in some libraries I've been developing. It could use EBO for the Allocator parameter to have the same size as scoped_ptr for empty Allocators. I need a move_ptr with a Allocator parameter too. But I rather let somebody else write for now. Thanks, -- Felipe Magno de Almeida

3 6

Control of the file location for the boost::interprocess::managed_shared_memory object
by Michael Watkins 11 Sep '09

11 Sep '09

Is it possible to control the exact location of the file that is backing the shared memory created by boost::interprocess::managed_shared_memory? The issue occurs under Windows (it has not been tried yet under Linux). The problem is two processes attempting to connect to the same shared memory segment between two accounts, in specific from a program running as a service (using the system account) and a program running under a user account. The user account is running a program that needs to interface to the database that the service created. Everything seems to work fine, but the service will open the shared memory backing file in the global temp directory while the user account will open the file in their local settings temporary directory. Therefore two different segments are opened. The interim solution is to use boost::interprocess::managed_windows_shared_memory to create the shared memory, but the desire is to use the generic version for cross-platform compatibility. If the full file path could be specified when creating the memory segment, it would solve the problem. Michael Watkins _________________________________________________________________ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=PID23384::T:WLMTAGL:ON:WL:en-US:NF_BR_s…

2 4

[multi_index][serialization][Huang-Vista-x86_32_intel] Help with weird test failure
by joaquin＠tid.es 11 Sep '09

11 Sep '09

Huang-Vista-x86_32_intel toolset, which runs Intel 11.1 for Window, has this weird error on the serialization test for Boost.MultiIndex: Running 1 test case... ../libs/multi_index/test/test_serialization_template.hpp(82): error in "test_main_caller( argc, argv )": check all_indices_equal(m,m2) failed unknown location(0): fatal error in "test_main_caller( argc, argv )": std::exception: invalid signature (http://tinyurl.com/nd89x2) What I find weird is the throwing of invalid_signature, a Boost.Serialization exception that, according to docs, indicates that the beginning of a serialization file is not correct. I can't see how a problem with serializing multi_index_containers can lead to a file signature error. Any clue? Maybe the toolset maintainer can run this manually and provide more info? Thank you in advance, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[warnings] Are warnings acceptable artifacts from builds?
by Sid Sacek 11 Sep '09

11 Sep '09

Just curious, when I use certain libraries, I get compiler warnings. Are these simply acceptable during a build, or should they be reported to somebody ? The latest warning I'm seeing are: Warning 4 warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<8>::least', signed/unsigned mismatch C:\Trunk.3.1\ThirdParty\boost\crc.hpp 377 Warning 5 warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<16>::least', signed/unsigned mismatch C:\Trunk.3.1\ThirdParty\boost\crc.hpp 400 Regards, -Sid Sacek

13 52

[Boost.Breakable] Any interest in a Boost Breakable library?
by Pierre Morcello 11 Sep '09

11 Sep '09

Hello, I propose a set of macros that allow to break anywhere. Example of use of the main macro : // do something... BOOST_BREAKABLE { if (test1) { break; } if (test2) { break; } std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } // here the program continues ... Is there any interest in such a library? Best regards, Pierre Morcello

20 44

Re: [boost] non-branching min()
by Phil Endecott 10 Sep '09

10 Sep '09

DE wrote: > template<typename type> inline > type min(type a, type b) > { > const type c[2] = {a, b}; > return c[b<a]; > } How well this performs compared to the conventional ?: implementation will depend on how the arguments are distributed. If the outcome is skewed, then branch prediction will make the conventional implementation faster. If the outcome is 50/50 (and not correlated with some other branch), then your code may do better. > here's a test code: > > #include <vector> > int main() > { > typedef int type; > const int n = 1000000; > std::vector<type> v1(n), v2(n); > //filling v1 and v2 somehow > type min = BIG_VALUE; > for (size_t i = 0; i<n; ++i) > a = min(a, min(v1[i], v2[i])); //searching minima of v1 and v2 > return 0; > } So the min(v1[i],v2[i]) is 50/50 (assuming that you fill the arrays with random values), while min(a,...) will be skewed to normally prefer the second arg after the first few cycles. Perhaps you can confirm that your code does better for the former and worse for the latter by testing e.g. a = std::min(a, my::min(v1[i], v2[i])); Is there some reason why a compiler cannot do your optimisation automatically when you write ?: expressions? Regards, Phil.

1 0

[Test] Memory leak with boost v1.40 under gcc 4.2 for x86_64 in Snow Leopard
by S Roderick 10 Sep '09

10 Sep '09

[First time poster to boost] Compiling for the default x86_64 produces a memory leak in the test framework, but the same program compiled for i386 does not. Mac OS X Snow Leopard gcc 4.2 with macports boost 1.40.0 (same memory leak seen in v1.39 macports also). The memory leak only occurs with multiple test cases or test suites. Set the define in my test program to remove the extra test case, and the leak dissappears. Could not find this problem on the list, nor the 'net. Output is: <code> sroderick@mp tmp $ g++ -o boost-test-i386 -arch i386 /opt/code/tmp/ boost-test.cpp -I/opt/local/include -g sroderick@mp tmp $ g++ -o boost-test -arch x86_64 /opt/code/tmp/boost- test.cpp -I/opt/local/include -g sroderick@mp tmp $ ./boost-test Running 2 test cases... *** No errors detected boost-test(75819) malloc: *** error for object 0x3000100300780: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap sroderick@mp tmp $ ./boost-test-i386 Running 2 test cases... *** No errors detected </code> gdb backtrace for x86_64 program is: <code> (gdb) bt #0 0x00007fff83180096 in __kill () #1 0x00007fff832210c2 in abort () #2 0x00007fff83138215 in free () #3 0x000000010006979e in boost::unit_test::framework_impl::clear (this=0x1000d99c0) at framework.ipp:133 #4 0x000000010006989c in boost::unit_test::framework_impl::~framework_impl (this=0x1000d99c0) at framework.ipp:122 #5 0x000000010006ae0e in __tcf_1 () at framework.ipp:225 #6 0x00007fff831443f4 in __cxa_finalize () #7 0x00007fff8314430c in exit () #8 0x0000000100009703 in start () at unit_test_parameters.ipp:172 </code> Program is: <code> #define BOOST_TEST_MODULE example #include <boost/test/included/unit_test.hpp> BOOST_AUTO_TEST_SUITE( test_suite ) BOOST_AUTO_TEST_CASE( test_case1 ) { // BOOST_ERROR( "some error 1" ); BOOST_CHECK( true ); } BOOST_AUTO_TEST_SUITE_END() #if 1 BOOST_AUTO_TEST_CASE( test_case_on_file_scope ) { BOOST_CHECK( true ); } #endif </code>

1 0