- Boost - lists.boost.org

[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

BoostCon 2009 Early Registration Still Available
by David Abrahams 10 Apr '09

10 Apr '09

In recognition of the economic climate, and in order to make possible the maximum participation this year, we've extended the early registration deadline for BoostCon until April 26th, so BoostCon is still only $599. BoostCon has always been a great place to network, find out what is happening in the C++ community, and learn about the coolest C++ libraries being developed within and outside of Boost --- and this year will be better than ever. The official schedule is now live at http://www.boostcon.com/program. A few highlights of the "mouth-watering content" (in the words of one enrollee) are: * A keynote address from Andrei Alexandrescu called "Iterators Must Go." * Troy Straszheim's presentations on how high-energy physicists are using Boost to process massive datasets as they go "Icefishing for Neutrinos" and on Kamasu, his library for offloading computation to your machine's GPU. * Two hands-on sessions where we'll start recoding parts of Boost for C++0x, applying rvalue references, variadic templates, decltype, and advanced SFINAE capabilities using the latest GCC. * "Practical C++ Test-Driven Development with Boost.Test and Bmock," by Asher Sterkin * A session on compiler construction using Boost.Spirit v2, from Hartmut Kaiser and Joel de Guzman The complete list of sessions covers a wide range of other Boost and C++-related topics. Please have a look: http://www.boostcon.com/program/sessions. The quality of BoostCon has always depended on its diverse and interesting participants, so bring your ideas, questions, and experience, and sign up now! http://www.boostcon.com/registration See you in Aspen, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

Interest check: constant input matching manipulator
by Eugene Wee 10 Apr '09

10 Apr '09

Hi, Recently, I observed in an online community a question on whether C++ had a direct replacement for a call to scanf("a=%d", a) for some int a, using std::cin. The response given was to read the input as a string and then parse it. Another user noted that "iostreams would be more useful if it had the ability to match constant portions of the input". Looking at what already exists in the standard library and Boost, there does indeed seem to be no direct way to match such expected constant input. Boost.Regex and Boost.Tokenizer are indirect in this case (and possibly overkill), and Boost.Format is about output stream formatting only. Boost.Spirit appears to provide a way with file_iterator, but a manipulator seems more appropriate here considering that the functionality is quite simple. Does anyone think that adding such a manipulator to Boost would be desirable? I expect the syntax to be along these lines (names and namespaces to be decided): std::cin >> match("a=") >> a; where a failure to match would place the input stream in a failed state. It would also be possible to use a std::basic_string instead of a string literal converted to a pointer to its first element as the argument. I have already written such a manipulator, so if anyone is interested, I can provide my sample source. Regards, Eugene Wee

5 10

Re: [boost] [threads] making parts of Boost.Threads header-only
by Brian Wood 09 Apr '09

09 Apr '09

Anthony Williams writes: >Emil Dotchevski <emildotchevski(a)gmail.com> writes: >> >> I am against such a move. Boost Threads requires linking for other >> features which makes it one of the few libraries in Boost that can be >> properly designed to avoid unnecessary physical coupling. Unless >> something is proven to cause performance problems it should not be >> inlined, regardless of how simple it is. > >Wow, that's a hard line you've drawn there. I'm not sure I agree. The >only reason this matters is if you're going to be changing the >implementation and don't want to recompile the code that uses the >header. For boost users, the implementation only changes if they change >boost versions, and in that case I would expect people to recompile >anyway --- I wouldn't trust something compiled against boost 1.37 to >link against a 1.38 lib, for example. I'm sure you know more about Boost than I do, but I disagree that the implementation only changes when users change versions. There are fixes that have to be applied by users to libraries from time to time. I tend to agree with Emil's arguments here. Brian Wood Ebenezer Enterprises www.webEbenezer.net

6 6