September 2009 - Boost - lists.preview.boost.org

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

Iterators Must Go (Ahead)
by Andrei Alexandrescu 10 Sep '09

10 Sep '09

Hello, I wrote an article about D's ranges, contrasting them to other iteration idioms. Those who'd be interested in reviewing the article, please send me email. (I may not be able to reply to all requests.) Bear in mind that the article is rather long - about the size of two usual magazine articles. Thanks, Andrei

7 6

[unordered] please don't allocate memory in the default constructor
by Thorsten Ottosen 10 Sep '09

10 Sep '09

Hi Jeremy, I think this a really bad idea to allocate in the default construtor. The user can always call rehash() on the empty container, just like when we call reserve() for vector. Thanks -Thorsten

5 8