- Boost - lists.boost.org

boost regex build problem
by Qihong Wang 13 Apr '09

13 Apr '09

Hi, I feel awkward to post almost the same question again. But I really have a problem when I build 32 bits boost.regex with icu support on a 64 bits Linux machine. If I build 64 bits regex with icu support, they are fine. If I build 32 bits regex without icu support, they are fine. When I tried to build 32 bits regex with icu support, I used command for ICU building ./runConfigureICU Linux --disable-64bit-libs ./configure --prefix=/home/qhwang/mylibs_32/icu --disable-64bit-libs I checked icu libraries they are not dependent on 64bits libraries. So I'm confident they are 32bits. But when I use the command to build 32 bits regex ./bjam --prefix=/home/qhwang/mylibs/boost/ --with-regex --build-dir=/tmp/boost_build/ --build-type=complete --address-mode=32 --architecture=x86 -sHAVE_ICU=1 -sICU_PATH=/home/qhwang/mylibs/icu/ install Bjam showed ...failed updating 4 targets... ...skipped 12 targets... ...updated 7477 targets... there were only static libraries built. When I linked them to my program which were also compiled in 32 bits, the linker complained the libraries were incompatable. Could someone give me some help again? Thanks in advance. Qihong

3 6

[fusion] repetitive_view
by Stjepan Rajko 12 Apr '09

12 Apr '09

Hello, I just noticed `repetitive_view` in boost/fusion/view. It doesn't appear to be documented, but judging from the test, it appears that repetitive_view<Sequence> is an infinite repetition of the elements of the sequence. Is that correct? I would find this extremely useful, but I'm slightly put off by the lack of documentation and the fact that it results in a (not currently officially supported?) infinite sequence. What is the status of repetitive_view? Is it safe to use? Stjepan P.S. we have discussed infinite sequences before: http://archives.free.net.ph/message/20080716.025311.1b54b65e.da.html

2 3

boost/pool/pool.hpp why reinterpret_cast instead of static_cast?
by Philippe Vaucher 12 Apr '09

12 Apr '09

Hi, In the file https://svn.boost.org/trac/boost/browser/trunk/boost/pool/pool.hpp there's the following code: struct default_user_allocator_malloc_free { ... static char * malloc(const size_type bytes) { return reinterpret_cast<char *>(std::malloc(bytes)); } ... }; It is my understanding that void* to T* convertions should be done using static_cast and not reinterpret_cast. Is there a reason for using reinterpret_cast there? Thanks, Philippe

7 11

[filesystem] Version 3 request for comments
by Beman Dawes 12 Apr '09

12 Apr '09

A prototype implementation of version 3 of Boost.Filesystem is available for comment. The critical feature of this prototype is the replacement of the class basic_path template with a single class path that supports both narrow and wide character paths. It also supports user supplied types, and will support the new C++0x char16_t and char32_t character types as compiler and standard library support becomes available. There is still a lot of additional work before V3 could be added to the trunk and eventually released. For example, work so far has concentrated on the new functionality, and ignored breaking changes to existing code. But enough stuff is working to make requesting comments useful. See http://svn.boost.org/svn/boost/sandbox/filesystem-v3/libs/filesystem/doc/v3… for a fuller description of the prototype and links to the prototype implementation. I've got some specific issues I'd like opinions on, but would first like to hear comments from anyone interested. --Beman

11 21

Re: [boost] BoostCon 2009 Early Registration Extended to April 26th
by David Abrahams 12 Apr '09

12 Apr '09

The following message is a courtesy copy of an article that has been posted to comp.lang.c++.moderated,comp.std.c++,comp.lang.c++ as well. on Thu Apr 09 2009, woodbrian77-AT-gmail.com wrote: > Would you agree that recoding that takes advantage of C++ 1998 > should be higher priority than C++0x? In general, maybe. For BoostCon, no. > For example, Boost Serialization doesn't use hinted inserts with > (mulit)set or (multi)map. Have you submitted a ticket for that at http://svn.boost.org? > I believe Boost Multi Index does. In the > performance section here -- > http://webEbenezer.net/comparison.html -- there's a subsection > on Load/Receive tests that mentions this. I also mentioned > this subject twice in this thread: > http://lists.boost.org/boost-users/2009/03/45712.php > > If anyone cared or even noticed wasn't clear as there was > no response to that particular point. Different library maintainers take different approaches to responding to reports on the Boost list. Specific Trac tickets (especially with patches attached, as you seem to be able to provide) are a little harder to leave dangling because to make them go away you have to explicitly close them, so I suggest you try that approach with one ticket per issue. > For some reason I doubt the author or anyone else bothered to improve > the library in this way and the 1.39 version of the Serialization > library will have the same weak performance in this area. > > Additionally and more importantly, now the C++ Middleware > Writer has support for several boost::intrusive containers. > Neither Boost Intrusive nor Boost Serialization have > serialization support for any of the intrusive containers. > The Boost Instrusive containers are superior to the > standard containers in a number of ways, so this gap is > big. > > While working to update parts of Boost to be able to > take advantage of C++ 2010 (or 20110), makes sense to > me, I think the items I mentioned should be higher > priority than the C++0x work. A Boost bugfixing sprint sounds like a great idea, but that can happen in cyberspace (the way Ubuntu does it). I invite you to come to the Boost developers' list and kick one off. I would certainly be grateful for an excuse to focus on closing Boost Trac tickets. In fact, it sounds like a good thing to mull over at BoostCon At BoostCon I want to take advantage of the face-to-face time to do things that are a bit more educational, less critical-path, and that can really benefit from having a bunch of people in the same room. I think exploring how C++0x features interact in real C++ libraries is one of those. > It's not as cool or sexy though. That's an issue, too. To make it worthwhile for people to travel across the country to BoostCon, you need to put "cool" things on the program ;-). > The first item should be relatively easy to address, which makes it > all the more surprising that as the releases go by it doesn't get > addressed. Remember that addressing any given issue in a Boost library is basically up to one person: whoever is maintaining that library. Maintainers are volunteers, and each one arranges his priorities differently. But in the case of something posted on the -users mailing list whose thread sorta trailed off, I wouldn't be surprised if the issue has fallen off the maintainer's radar. I suggest getting it into the tracking system. > The second item, though is a different story. Anyway, > even if you are only able to address the first item by the time > BoostCon is over, I'll be impressed. Well, it's not really up to me, and I don't /think/ Robert Ramey is planning to come to BoostCon this year. > And since I'm able to point out two weaknesses like this with one > library, there may be other problem areas in other libraries. Definitely: https://svn.boost.org/trac/boost/report/1 Looks like we have 766 open issues right now :-( > This could be incorporated into the pricing of the conference: $499 > gets you into the C++98 "fixer" and $599 gets you into the C++0x > "fixer." :) Yeah, not very practical. Those sessions are just two 3-hour segments out of a whole week of material. We're not making the conference itself into one big sprint. Take a look at the program: http://www.boostcon.com/program Cheers, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

boost::interprocess mixing heap and shared memory ?
by Oncaphillis 11 Apr '09

11 Apr '09

Working with boost::interprocess I came across the following question. using namespace boost::interprocess; // ... Assume that I've declared all the necessary allocators // ... for chars and std::pair<my_string,my_string> here typedef basic_string<char,my_char_allocator_t> my_string; typedef map<my_string,my_string,std::less<my_string>,my_string_string_allocator> my_map; managed_shared_memory shm(open_or_create,"BogusMemory",0x1000) my_map *the_map = some_how_construct_map_in_shared_memory(shm); // So now I have a map residing in shared memory // The only way to search within this map I could // find was the following. my_map::iterator i = the_map->find(my_string("BOGUS",my_char_allocator_t(shm))); This might throw since the search string is constructed within shared memory although it is only needed temporary and destructed right after the statement. Is there a way to use heap or stack memory for thinks like that ? Thank you very much O.

2 1

Default variants on windows
by Vladimir Prus 11 Apr '09

11 Apr '09

Per: https://svn.boost.org/trac/boost/ticket/2899 we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later. Note that I can add arbitrary explanation messages into the build process -- both to warn the user that a scary pile of things will be built, and to warn the user that only couple of variants will be built. - Volodya

10 18

How to open parallel port
by master master 11 Apr '09

11 Apr '09

Is there any library exist for opening parallel ports? I know for serial it is "serial_port". I worked with it and it is working fine. For parallel communication; which class(library) is needed. -Rahul Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

1 0

Thread-safety issue with Boost Function?
by Sohail Somani 11 Apr '09

11 Apr '09

Hi, I was just looking through the Boost Function source and noticed the following in assign_to: // Note: it is extremely important that this initialization use // static initialization. Otherwise, we will have a race // condition here in multi-threaded code. See // http://thread.gmane.org/gmane.comp.lib.boost.devel/164902/. static vtable_type stored_vtable = { { &manager_type::manage }, &invoker_type::invoke }; However, my copy of the C++ standard seems to say this regarding local statics in section 6.7: The zero-initialization (8.5) of all local objects with static storage duration (3.7.1) is performed before any other initialization takes place. A local object of POD type (3.9) with static storage duration initialized with constant-expressions is initialized before its block is first entered. An implementation is permitted to perform early initialization of other local objects with static storage duration under the same conditions that an implementation is permitted to statically initialize an object with static storage duration in namespace scope. I read this to mean that an implementation may decide to initialize stored_vtable statically or the first time the block is entered. So I think that this means we cannot rely on static initialization behaviour. If you agree, then a simple fix for this might just be: template<typename VTable, typename Invoker, typename Manager> struct vtable_static_constructor { static VTable vtable; }; template<...> VTable vtable_static_constructor<V,I,M>::vtable = { {&Manager::manage, &Manager::invoke } }; assign_to() { ... vtable_type & stored_vtable = vtable_static_constructor<vtable_type,invoker_type,manager_type>::vtable; ... } If not, could you please point me to where in the standard this is guaranteed to be statically initialized? It would help me decide whether or not to fix some other code that has a similar pattern, if nothing else. Thanks in advance! -- Sohail Somani http://uint32t.blogspot.com

1 0

Re: [boost] [#pragma once]
by jbosboom＠uci.edu 10 Apr '09

10 Apr '09

> If unrecognized pragmas are ignored, then I don't see why boost > developers should jump > through a hoop to satisfy the "el-cheapo" compilers. In other words, if > a compiler gives > a warning about the #pragma-once, then let the programmer turn off the > warning locally > for the build, which is usually done in a single location within a > makefile. Well, what about the compilers that recognize #pragma once but don't implement it correctly? Or implement it as well as they can on their platform but somehow differ from other compilers? Also, there was once a version of GCC that would launch nethack or rogue when it encountered #pragma once. That's a perfectly legal thing for it to do (if not all that helpful). My point is that since we can't depend on the semantics of #pragma once, we ought not to use it. --Jeffrey Bosboom

1 0