- Boost - lists.boost.org

[gil][io_ew] performance test
by Christian Henning 30 Jan '11

30 Jan '11

Hi there, I did a little performance test of io_new vs io2. The code is here. http://pastebin.com/eCeFZuMS On my machine io_new runs in 1.15sec for 2658 jpegs. IO2 run in 1.005sec. All jpegs are the same image but they are a different file. This way I'm sure I don't have to convert the image into a different color space. I did that since io2 doesn't support any_image, I believe. Thanks, Christian

3 5

[fiber] Mac OS X
by Daniel Larimer 30 Jan '11

30 Jan '11

I am attempting to use Boost.Fiber on Mac OS X, but it always crashes in makecontext() which is now deprecated on Mac OS X. Is there any plan to get asm working for OS X? include <boost/fiber.hpp> boost::fiber* fi; void fib() { for( int i = 0; i < 10; ++i ) fi->yield(); }; int main( int argc, char** argv ) { boost::fiber f( boost::bind(fib), boost::fiber::default_stacksize, boost::protected_stack_allocator()); fi = &f; f.run(); return 0; } Reason: KERN_INVALID_ADDRESS at address: 0x0000000000010fa0 0x00007fff80820f89 in makecontext () (gdb) bt #0 0x00007fff80820f89 in makecontext () #1 0x000000010001f3a3 in boost::contexts::context::impl_t::impl_t (this=0x100100210, fn=0x100016990 <boost::fibers::detail::trampoline(void*)>, vp=0x100100190, stacksize=65536, nxt=0x1001001c0, alloc_=<value temporarily unavailable, due to optimizations>) at libs/context/src/context_ucontext.cpp:58 #2 0x000000010001f183 in ~auto_ptr [inlined] () at /usr/include/c++/4.2.1/memory:59 #3 0x000000010001f183 in boost::contexts::context::init_ (fn=0x100016990 <boost::fibers::detail::trampoline(void*)>, nxt=0x1001001a0, vp=0x100100190, stacksize=65536, alloc=<value temporarily unavailable, due to optimizations>) at libs/context/src/context_ucontext.cpp:77 #4 0x00000001000017db in boost::contexts::context::create<boost::contexts::protected_stack_allocator> () #5 0x0000000100001a96 in boost::fibers::detail::fiber_base::fiber_base<boost::contexts::protected_stack_allocator> () #6 0x0000000100001b65 in boost::fibers::detail::fiber_object<boost::_bi::bind_t<void, void (*)(), boost::_bi::list0> >::fiber_object<boost::contexts::protected_stack_allocator> () #7 0x0000000100001bdd in boost::fibers::fiber::make_fiber_<boost::_bi::bind_t<void, void (*)(), boost::_bi::list0>, boost::contexts::protected_stack_allocator> () #8 0x0000000100001c54 in boost::fibers::fiber::fiber<boost::_bi::bind_t<void, void (*)(), boost::_bi::list0>, boost::contexts::protected_stack_allocator> () #9 0x00000001000010be in main () Boost 1.45 Boost.Fiber 0.7.0 from Valut i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664) Mac OS X 10.6.6

3 2

[CfP] Reminder: 5th Annual BoostCon, Aspen (CO, USA), May 15-20, 2011
by Hartmut Kaiser 30 Jan '11

30 Jan '11

Please note the extended deadline: February 10th, 2011 ------------------ Please distribute. ------------------ 5TH ANNUAL BOOST CONFERENCE 2011 Aspen CO, USA, May 15 - 20, 2011, www.boostcon.com CALL FOR PARTICIPATION We invite you to submit session proposals to the 5th Annual Boost Conference: BoostCon 2011 (Aspen CO, USA, May 15 - 20, 2011). Traditionally the main face-to-face event for all things Boost (www.boost.org) BoostCon 2011 will present leading speakers from the whole C++ community. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and the new C++ Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at three constituencies: Boost end-users, hard-core Boost library and tool developers, and academics focusing on research. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. SESSION TOPICS Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it changes life for users and library writers * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS Presentations ------------- Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels ------------- Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials ------------- Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops ------------- Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations ------------- These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors Presentations ------------- We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10-20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon2011. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon website and will be available to attendees. For general information on the BoostCon 2011 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon2011(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. IMPORTANT DATES New proposal submissions due: January 10th, 2011. Proposals decisions sent (tentative program): February 17th, 2011. Fully scheduled program available: February 25th, 2011. Session materials due: April 15th, 2011. Hartmut Kaiser: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

type traits extension: progress status
by Frédéric Bron 30 Jan '11

30 Jan '11

I have been able to make the binary operator traits work with pointers. It has been a hard job but I think it is now working well (thank you Jeffrey for pointing to that particular issue). I still have to do the same for unary operators but this should be much easier. The current list of supported operators (35) is now: * 28 binary operators: . ==, !=, <, <=, >, >=, . +, -, *, /, %, +=, -=, *=, /=, %=, . &, |, ^, &=, |=, ^=, . <<, >>, <<=, >>=, . &&, ||, * 5 prefix unary operators: . ! . -, + . --, ++ * 2 postfix unary operators: . --, ++ Here are the links to the updated code and documentation: * http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… * http://svn.boost.org/svn/boost/sandbox/type_traits/ Frédéric

3 4

Re: [boost] [string] Realistic API proposal
by Joe Mucchiello 30 Jan '11

30 Jan '11

>> > // UTF validation >> > >> > bool is_valid_utf() const; >> >> See, that's what makes the whole thing pointless. > >Actually not, consider: > > socket.read(my_string); > if(!my_string.is_valid_utf()) > .... This, and many of these functions, work much better as standalone functions: // with a string-aware function socket.read(my_string); if (!is_valid_utf8(my_string.begin(),my_string.end())) .... // with a C interface std::vector<char> vec; vec.resize(MY_BUFSIZE); int len = recv(socket, vec.data(), MY_BUFSIZE, 0); if (len >= 0) { vec.resize(len); if (!is_valid_utf8(vec.begin(), vec.end())) .... } // conversion for Windows API std::vector<wchar_t> vec; vec.resize(count_codepoints<utf8>(mystring.begin(), mystring.end())); convert<utf8,utf16>(mystring.begin(), mystring.end(), vec.begin()); HRESULT hr = WriteFile(handle, vec.data(), vec.size(), &dwBytesWritten, NULL); ... Joe

6 5

One small step for mankind - was Re: What's happened to Ryppl?
by Robert Ramey 30 Jan '11

30 Jan '11

Dave Abrahams wrote: > Robert, great questions. Could you post them to the boost developers' > list? They really don't belong here. > > Thanks. > > On Sat, Jan 29, 2011 at 12:57 PM, Robert Ramey <ramey(a)rrsd.com> wrote: >> Dave Abrahams wrote: >>> On Fri, Jan 28, 2011 at 4:35 PM, Robert Ramey <ramey(a)rrsd.com> >>> wrote: >> >> In the interest of moving toward a better modularization of boost >> and decoupling of libraries, I would like to make a suggestion: >> >> Can we change library testing so that each library is tested against >> the current release branch of all the other libraries? >> >> When I test on my own machine, I don't test against the trunk. I >> test against the current release tree. Another way of saying this is >> that on my current machine I have my directory tree set to the >> the boost release branch. ONLY the serialization library directories >> are set to the trunk. So when I test on my local machine I KNOW that >> when I merge >> into the release branch I won't have any unexpected problems. >> >> a) I don't think this would be a huge change. >> b) It would better test what the user does >> c) It would isolate each library from another so that >> errors in the trunk (wild west) in one library don't impact >> on development of other libaries. >> d) It would promote decoupling of libraries. >> e) as an intermediate step, not all testers would have >> to make the change - some could use the old script. >> >> It would be a small, not too difficult step on the path >> we think we want to travel. >> >> Robert Ramey >>

2 1

Re: [boost] [string] proposal
by Ivan Le Lann 30 Jan '11

30 Jan '11

----- "Artyom" <artyomtnk(a)yahoo.com> a écrit : > > From: Dean Michael Berris <mikhailberis(a)gmail.com> > > > > On Sat, Jan 29, 2011 at 11:25 PM, Artyom <artyomtnk(a)yahoo.com> > wrote: > > >> From: Dean Michael Berris <mikhailberis(a)gmail.com> > > >> On Sat, Jan 29, 2011 at 8:06 PM, Artyom <artyomtnk(a)yahoo.com> > wrote: > > >> > > >> No, it's not obvious. Here's why: > > >> > > >> fd = creat(file.c_str(), 0666); > > >> > > >> What does c_str() here imply? It implies that there's a buffer > > >> somewhere that is a `char const *` which is either created and > > >> returned and then held internally by whatever 'file' is. > > > > > > It implies that const file owns const buffer that holds null > terminated > > > string that can be passed to "char const *" API. > > > > > > > Yes, which is the problem in the first place. Every instance of > string > > would then need to have that same buffer even if that string is > just a > > temporary or worse just a copy. > > > > It would not happen if it holds the data as linear single chunk :-) > > > >> Now let's say > > >> what if file changed in a different thread, what happens to the > buffer > > >> pointed to by the pointer returned by c_str()? Explain to me > that > > >> because *it is possible and it can happen in real code*. > > > > > > I'm sorry but string as anything else has value semantics > > > that is: > > > > > > - safe for "const" access from multiple threads > > > - safe for mutable access from single thread > > > > > > I don't see why string should be different from > > > any other value type like "int" because following > > > > > > x+=y + y > > > > > > is not safe for integer as well. > > > > > > The code I had shown is **perfectly** safe with > > > string has has value semantics (which std::string has) > > > > > > > Now the point I was making was, in the case of a string that is > > immutable, you don't worry about the string changing *ever*, don't > > need a contiguous buffer for something that isn't explicitly > required. > > It's value semantics *plus* immutability. > > > > So you either should forbid > > your_string const &operator=(your_string const &) > > Which makes it even more useless (IMHO) > > Or your statement is wrong because assignment > can happen for example from other thread like > > str = str + " suffux" > > And this would change the string in run time. > Think str as a shared_ptr<const string_beast> with wrappers. This line does not mutate the structure previously pointed to, just like assigning a shared_ptr does not mutate the object previously pointed to. It makes str points to a newly created chain, which here happens to share data with the original chain but that's another story. Of course, this suppose that you got str by value. If you got it by non-const reference, you can have race issues with other threads, just like any assignment, regardless of the type. Ivan

1 0

[string] proposal
by Matus Chochlik 30 Jan '11

30 Jan '11

Dear list, following the whole string encoding discussion I would like to make some suggestions. >From the whole debate it is becoming clear, that instant switch from encoding-agnostic/platform-native std::string to UTF-8-encoded std::string is not likely to happen. Then it was proposed that we create a utf8_t string type that would be used *together* (for all eternity) with the standard basic_string<>. While I see the advantages here, I (as I already said elsewhere) have the following problem with this approach: Using a name like utf8_t or u8string, string_utf8, etc. at least to me (and I've consulted this off the list, with several people) suggests, that UTF-8 is still something special and IMO also sends the message that it is OK to remain forever with the various encodings and std::string as it is today. We should *IMO* endorse the opposite. My suggestion is the following: Let us create a class called boost::string that will have all the properties that a string handling class in 2011+ A.D. should have, basically what std::string should have been. Then there are two alternatives: a) When all the zillions lines of legacy code in FORTRAN, COBOL, BASIC, LOGO, etc. :) are fixed / ported / abandoned, and UTF-8 becomes a true standard for text encoding widely accepted by the whole IT industry and markets, and all the issues that prevent us from doing the transition now are resolved, this string becomes the standard, like many other things from Boost in the past, and replaces the current std::string. b) As some (having much more insight into how the standardizing comitee works than I do) have pointed out, it will never become a true standard. But with the Boost's influence it at least becomes a de-facto standard for strings and it is (hopefully) adopted by the libraries that currently feel the need to invent string-classes themselves (with a good reason). Also I've uploaded into the vault file string_proposal.zip containing my (naive and un-expert-ly) idea what the interface for boost::string and the related-classes could look like (it still needs some work and it is completelly un-optimized, un-beautified, etc.). /me ducks and covers :) The idea is that, let std::string/wstring be platform-specifically- -encoded as it is now, but also let the boost::string handle the conversions as transparently as possible so if in case the standard adopts it, std::string would become a synonym for boost::string. It is only partially implemented and there are two examples showing how things could work, but the real UTF-8 validation, transcoding, error handling, is of course missing. Remember it is aimed at the design of the interfaces at this point. If you have the time, have a look and if my suggestions and/or the code looks completely wrong, please, feel free to slash it to pieces :), and if you feel up to it, propose something better. If this or something completely different and much better that comes out of it, will be agreed upon, we could set up a dedicated git repository for Boost.String and maybe try if the new suggested collaborative development in per-boost-component repositories really works. :) If some of the people that are skilled with unicode would join or lead the effort it would be awesome. Best, Matus

28 233

Re: [boost] [string] proposal
by Artyom 30 Jan '11

30 Jan '11

> From: Dean Michael Berris <mikhailberis(a)gmail.com> > > On Sat, Jan 29, 2011 at 11:25 PM, Artyom <artyomtnk(a)yahoo.com> wrote: > >> From: Dean Michael Berris <mikhailberis(a)gmail.com> > >> On Sat, Jan 29, 2011 at 8:06 PM, Artyom <artyomtnk(a)yahoo.com> wrote: > >> > >> No, it's not obvious. Here's why: > >> > >> fd = creat(file.c_str(), 0666); > >> > >> What does c_str() here imply? It implies that there's a buffer > >> somewhere that is a `char const *` which is either created and > >> returned and then held internally by whatever 'file' is. > > > > It implies that const file owns const buffer that holds null terminated > > string that can be passed to "char const *" API. > > > > Yes, which is the problem in the first place. Every instance of string > would then need to have that same buffer even if that string is just a > temporary or worse just a copy. > It would not happen if it holds the data as linear single chunk :-) > >> Now let's say > >> what if file changed in a different thread, what happens to the buffer > >> pointed to by the pointer returned by c_str()? Explain to me that > >> because *it is possible and it can happen in real code*. > > > > I'm sorry but string as anything else has value semantics > > that is: > > > > - safe for "const" access from multiple threads > > - safe for mutable access from single thread > > > > I don't see why string should be different from > > any other value type like "int" because following > > > > x+=y + y > > > > is not safe for integer as well. > > > > The code I had shown is **perfectly** safe with > > string has has value semantics (which std::string has) > > > > Now the point I was making was, in the case of a string that is > immutable, you don't worry about the string changing *ever*, don't > need a contiguous buffer for something that isn't explicitly required. > It's value semantics *plus* immutability. > So you either should forbid your_string const &operator=(your_string const &) Which makes it even more useless (IMHO) Or your statement is wrong because assignment can happen for example from other thread like str = str + " suffux" And this would change the string in run time. Your statement is false unless I miss something or you want to put a mutex inside a string or some other atomic variable. I don't see any reason to not to treat a string as any other value. > > > > I think we both and 95% of C++ programmers that use STL > > know what is the semantics of std::string::c_str() > > > >> I like this better: > >> > >> char * filename = (char *)malloc(255, sizeof(char)); // I know I > >> want 255 characters max > >> if (filename == NULL) { > >> // deal with the error here > >> } > >> linearize(substr(file, 0, 255), filename); > >> fd = creat(filename, 0666); > >> > > > > Sorry? Is this better then: > > > > fd=create(filename.substr(0,256).c_str(),O_EXCL...) > > > > Which by the way is 100% thread safe as well (but still may throw). > > Even thou I can't see any reason to cut 256 bytes before create > > > > No, not better because std::string's substr() will return a temporary, > which means it will be a copy -- meaning another allocation and a call > to memcpy(...). You don't get the benefit of COW on this one because > you need to cut the string down to a "maximum size". > Actually small notice you will have to copy because C API expects NULL terminated string, so you can't avoid memory copy if the last byte is not NULL. So no difference there > I don't know if you know, but them C APIs from OSes have a defined > maximum on the lengths of filenames and things like that... > Not exactly maximal length is something much more complicated, run-time and specific OS dependent, but this is other story. > >> And then the problem is not addressed then of the unnecessary contiguous > >>buffer. > >> > > > > There is good idea to have some non-linear data storage but > > it should used in very specific cases. > > > > Also what is really large string for you that would have > > performance advantage not being stored lineary. > > > > Talk to me in numbers? > > > > Say on a machine+OS combo that has 4kb pages, a large string would be > something that spans more than one memory page -- i.e. >4kb. > > Now a "short" string is one that can fit within a page. For > concatenated strings, it's fine to compact/copy the substrings into a > growable/shrinkable block. The overhead for a short string would be > constant, as the concatenation tree would be a pointer and a length > with a reference count integer. Actually I actually mean benchmarks how long string should be that it would be more efficient to use as chunks. So you suggest 4k Which: 1. Covers almost all full file path names on every operating system 2. Covers almost all messages in text dialogs around 3. Covers all possible user data etc. So basically a single memory chunk is efficient for 99% of use cases. Now lets take it to extreme: - Longest Wikipedia article: 388k = ~ 39 pages - Book: War and Peace: text size... 3.1MB = 800 pages. How frequent this case? Very rare. See text is basically something quite short, long books were successfully written in days where 640K was more then enough. So the real benefits of non-linear data structure are rare, on the other had they add too much complexity for every day use. So basically: 1. 99% of use cases fit to single page. 2. Very few cases would actually make a use of multi-page architecture. 3. The extreme cases that may benefit of this data structure are very rare and probably should use their own structures. Just to clean up all the things 1. I do think that what you suggest is interesting and fine data structure. 2. I do think that in certain cases it would be very useful. 3. I do think that you have good experience with situations were such structure may be very useful. 4. I know your works (netlib) and I really appreciate what you do . However I still think: 1. Such structure does not give much benefits in main stream cases for string data structure in its text meaning (which what string for 99% programmers is). I mean non-linear memory is not really so useful for common use case. 2. I think you should take a look on major string use cases to decide what is better for "next C++ string" if you want to develop some. Also as you probably know I'm author of several projects most of them are strongly tied to text processing and handing: 1. Boost.Locale - strongly text and Unicode oriented. 2. CppCMS - C++ web framework that deals with strings and networking in most of its code. That by the was was the reason for Boost.Locale to be developed. 3. BidiTeX - bidirectional support for LaTeX/Hebrew which is mostly deals with text. So I do have some basic view on what are the use cases of strings, I don't say I know them all but I developed some "feeling" about what text processing needs and in my opinion you just miss the major use case. I think I'll stop trying to convince you that it is wrong way to look at string just because I think that users would know what to pic in real applications. Best Regards and Good Luck, Artyom

1 0

[1.46] Last few merges needed?
by John Maddock 29 Jan '11

29 Jan '11

I've been sifting through what needs to change on the release branch (for 1.46) in Boost.Config to revert some of the changes made by Bryce which have already been reverted in Trunk. Specifically: The patches to the pathscale config need to be merged to Release (unfortunately it took until now to get these working on Trunk): --- boost/config/select_compiler_config.hpp 2011-01-24 18:05:13.486000000 +0 000 +++ ../branches/release/boost/config/select_compiler_config.hpp 2011-01-17 15:59 :34.498000000 +0000 @@ -52,7 +52,7 @@ // Comeau C++ # define BOOST_COMPILER_CONFIG "boost/config/compiler/comeau.hpp" -#elif defined(__PATHSCALE__) && (__PATHCC__ >= 4) +#elif defined __PATHSCALE__ // PathScale EKOPath compiler (has to come before clang and gcc) # define BOOST_COMPILER_CONFIG "boost/config/compiler/pathscale.hpp" And also the Boost.Config docs need to be merged to release so that the new BOOST_*_NIX macros that were added and then removed are no longer documented in 1.46 (the actual changed headers can wait till 1.47 for merging). Is there likely to be a window when these changes can be merged - maybe between beta and release? Also are there any other pending reverts in Trunk but not release? Regards, John.

7 22