- Boost - lists.preview.boost.org

[GSoC] Conservancy encourages member projects to apply for 2011
by Dave Abrahams 31 Jan '11

31 Jan '11

This message is forwarded from our umbrella nonprofit, the Software Conservancy:

1 0

[bind] class template 'value' can corrupt compilability of sound code: Ticket #5141
by Joachim Faulhaber 31 Jan '11

31 Jan '11

Hi Peter, list, two days ago I encountered the following situation For a new project I combined some code like: #include <boost/my_lib/my_robust_portable_code.hpp> with some other code #include <boost/malicious/side_effect_code.hpp> #include <boost/my_lib/my_robust_portable_code.hpp> with the effect, that 'my_robust_portable_code.hpp' did not compile anymore. Although I found a fix, applicable to 'my_robust_portable_code.hpp', I think that such a <boost/malicious/side_effect_code.hpp> should generally not be acceptable for independent components of boost. In the concrete case <boost/tread.hpp> has this malicious potential to confuse msvc-[8..10] when it preceded some of my boost/icl code. <boost/tread.hpp> has the potential to break the code of any other boost library and any user code, if those accidentally use certain legal expressions. As the example below shows the corrupted code is not extremely nuts and might occur else were. Fortunately I was able to locate the problem: It's at boost/bind/bind.hpp(112): namespace _bi{ ... template<class T> class value { ... }; ... } //namespace _bi This is a minimal program to demonstrate how 'class value' can confuse msvc: //========================================================= #include <boost/config.hpp> //--- from boost/bind/bind.hpp(112) namespace _bi{ template<class T> class value{}; } //--- affected code --------------------------------------- template <class Type> struct some_attribute { BOOST_STATIC_CONSTANT(int, value = 0); }; template <class Type> struct some_predicate { BOOST_STATIC_CONSTANT(bool, value = ( some_attribute<Type>::value < 0) //error C2059: syntax error : ')' //IF class template value defined before ); }; //========================================================= Although I frankly don't know, how exactly msvc is derailed, it seems to have problems with 'value' in some_attribute<Type>::value < 0 a construction that is extremely frequent due to meta programming conventions introduced by Dave's and Aleksey's boost::mpl. So for a fix I tried to rename 'class value' by something else like 'class _value'. Fortunately this is possible, because the class template is a local implementation object used in boost/bind/bind.hpp only. After renaming, I successfully ran all tests from boost/bind. Find the patch file attached. I have also filed a ticket https://svn.boost.org/trac/boost/ticket/5141 Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

4 9

Interest in a simple buffer abstraction?
by Boris Kolpackov 31 Jan '11

31 Jan '11

Hi, While working on the Boost profile for ODB C++ ORM[1], I was looking for a Boost type to map the database BLOB type to. I hoped to find something that would encapsulate the memory management and provide basic operations like copy (memcpy), append, set all bytes in a buffer to a specific value (memset), etc. Something that I could use like this: class packet { address to_; boost::buffer payload_; public: packet (const address& to, const void* data, std::size_t size) to_ (to), data_ (data, size) { } const boost::buffer& payload () const { return payload_; } }; class socket { public: void send (const packet& p) { ... s_.send (p.payload ().data (), p.payload ().size ()) } }; I found a number of buffer types in asio (asio/buffer.hpp) but they don't do memory management. I also found auto_buffer in implementation details of signal2 (signal2/detail/auto_buffer.hxx) and buffer in implementation details of iostream (iostream/detail/buffer.hxx). But they appear to be purpose-built for the libraries in question. So, unless I missed something obvious, I would like to propose a simple buffer abstraction for inclusion into Boost. Here are some additional motivations: - Seeing that there is a number of library-specific implementations, it is quite clear that such a class is often needed. - If we have a "top-level" buffer class, various i/o libraries could use it in their interfaces which would lead to better library interoperability (i.e., one could receive data from a socket into a buffer using asio and then pass that buffer to iostream or interprocess without any conversions). - A top-level buffer class will be fairly light-weight (perhaps even header-only). Right now, if I am to use a buffer implementation from say, asio, I need to install and potentially link to that library. If the community believes this is a good idea, I will next send the buffer interface for review/discussion. Let me know what you think. [1] http://www.codesynthesis.com/products/odb/ Boris

7 29

Process discussions
by Christophe Henry 31 Jan '11

31 Jan '11

> As of recent, we had quite a lot of discussion about process. In true > open-source spirit, it was a fairly open discussion, with everybody > offering their perspectives and experience. However, while we surely > learned many things, it does not seem like we're going anywhere. > > For a quick experiment, I tried to assess whether the discussion actually > reflects the needs of Boost developers, so I created a table of Boost > developers sorted by the number of commits in 2010. It is here: > > http://tinyurl.com/5suwfbn > > It seems that 5 top Boost comitters did not participate much in recent > discussions. And going down the list, it seems like many of active developers > did not say anything, while most of discussions is fueled by folks who > don't commit much. > > Of course, everybody can offer valuable thoughts, but if the goal is to fix > things for Boost developers, it would make sense if developers say that needs > fixing, as opposed to other people doing it for them. > > Maybe I suggest that for some time, we outright ban freeform discussion about > process, and instead, we restrict them to threads started by a Boost developers > and saying this: "I am maintainer of X, and had N commits and M trac changes > in the last year. I most hate P1, P2 and P3. I would propose that we use T1, > T2, and T3 to fix that". Then, everybody could join to suggest better > way of fixing P1, P2 and P3 -- without making up other supposed problems. > > Thoughts? *sigh* I usually try to stay out of this kind of discussions like svn vs git for 3 reasons: - I very fast stop following what it is about as it goes into depth without explanations. Actually I have the feeling it is more about "being right" than explaining for dolts like me. - I have no problem with svn - I have no time. Really. I don't. But it seems I have to say my word to avoid being faced with a matter decided without me. So my situation is simple. I have no time (I might have mentioned that already ;-) ). And the time I have is costly because any distraction goes at the cost of MSM. I use all my free time to code or imagine cool new features I can add. So either someone can make me get what I'd gain by investing time in switching to git (I repeat, I have no problem with svn, it does what I need with little cost) or for all practical matters, count me against switching. Right now, all I do is commit my development changes into the trunk, then once every 3 months start a long merge operation (which I do in the background, so no cost). How simpler than that can it be? If all I gain is avoiding getting all of boost on my (big) hard disk, then I will happily prefer paying the 1$ / 10GB and keep the time, thanks.

3 3

template-defined regexp proposal
by Vit Stepanek 31 Jan '11

31 Jan '11

Hi, I've implemented the basic regexp functionality using few simple template classes. Any regexp can be created by inserting the template classes one into another in the required order. Although it's in the design state, I'd like to find out if there's any interest in providing this functionality. Let me present you some short introduction to the topic. Some basic classes include - String Match (full string matching) - Is-in Match (matches any character in the list) - Or Match - Quantity and so on. These are the "building blocks" of the regexp. Each class does a very little bit but when combined in the specific order, you gain a clearly defined string matching algorithm of any kind and any complexity. In addition, it's quite simple to add any missing functionality. You just need to define you're desired algorithm and mix it with the others. I add few examples that should describe how's it all done. Regexp: ^[a-z]+ is implemented as: Quantity< Range< char_a, char_z >, 1 > re; (sorry if you don't like the indentation, but that's just to ease the reading) Regexp: ^0(x|X)[a-fA-F0-9]+ (matching the hexadecimal number) The required strings are hardcoded using macro "STRHOLDER", which generates a simple struct containing the given string (to avoid the need of pushing strings in the runtime and thus splitting the matching logic into two levels). STRHOLDER( 0, "0" ); STRHOLDER( xX, "xX" ); MultiTie< StrMatch< StringHolder_0 >, IsIn< StringHolder_xX >, Quantity< OrMatch< DigitChar, OrMatch< Range< char_a, char_f >, Range< char_A, char_F > > >, 1 > > re; The "MultiTie" ties the match parts to the consecutive sequence. Some other examples I tested include - email address regexp - quoted string matching (containing escaped quoting chars) Currently the implementation counts 21 template classes, which are enough to implement (I hope) almost any regular expression. Each "brick" is called using operator ()(). That allows to pass it as an argument to the standard algorithms (like std::replace_if etc). I've already implemented the availability to push parameters to the regexp in the runtime (but that's not the major feature). Some rationale for the defense: String matching is widely applied part of the coding. Often it's also one of the problematic domains (especially when using self-implemented matching functions without any general solution). Once it's done, it can be hard to change it, because all what can be seen is HOW is the match done, but not WHAT does it do. Even when using some higher-level methods, it still isn't self-descriptive. Template-defined regexp provides one solution for this issue by hiding the HOW under the mask of WHAT, and taking the advantage of compile-time check. Only to mention that - the performance is not touched by any kind of interpreting - everything is prepared after compilation (but I don't want to touch anybody's baby here!). Please don't look at: - the proposed name "template-defined regexp", I use it as the temp. name - the naming of the classes - implementation details (yes, they aren't here, because it's not necessary for now) - term "regexp" - I'm not sure if this can be called so... Your opinions are welcomed! Vit Stepanek ------------

3 7

[date_time] Active Maintainer? Patches on Trac, Cleaned-up, and Tested.
by Dean Michael Berris 31 Jan '11

31 Jan '11

I don't know where to look for this kind of information -- anybody maintaining Boost.Date_Time now? There are a few patches that have been languishing which might be good to look at and/or apply to trunk: https://svn.boost.org/trac/boost/ticket/1574 https://svn.boost.org/trac/boost/ticket/1674 https://svn.boost.org/trac/boost/ticket/1726 I've verified these locally to not cause any regressions with GCC 4.5 on Ubuntu 10.10 64-bit Linux locally. /me doesn't have commit powers on trunk (yet); maybe someone can apply? TIA, HTH -- Dean Michael Berris about.me/deanberris

1 0

Immutable data structure survey results
by Gregory Crosswhite 31 Jan '11

31 Jan '11

Hey everyone, Here are the results of the survey that I ran for the name of a potential immutable byte sequence data structure; each line contains the name that was entered and the number of times that it appeared: chain: 9 boost::text: 3 sequence: 2 string: 2 atomic_buffer: 1 blob: 1 buffer: 1 bytes: 1 chord (from the Latin chorda meaning string): 1 const_buf: 1 const_string: 1 data_block: 1 fixed_sequence<char>: 1 frame: 1 immutable::string: 1 immutable_sequence: 1 imstring: 1 rod: 1 rope: 1 sequence<char>: 1 strand: 1 tier: 1 whole_buffer: 1 wire: 1 yarn: 1 TOTAL: 37 To be transparent, I have also attached the script that I used to generate the above, which includes the raw results pasted inside a multi-line string. (Yes Artyom I included your vote in the tally.) I apologize for any problems you might have had with this service. I considered using another free service online which would be better suited for this purpose, but I wasn't sure of how many responses there would be and most services put a cap on 100 responses for their free services, whereas the service I have access to through my university has no such restriction. Since the actual number of responses was less than half of 100 I will know for future reference that one of the other free services should work just fine for this purpose. Thanks to everyone who responded! Cheers, Greg

3 2

[1.46.0 beta 1] Release candidate files available
by Beman Dawes 31 Jan '11

31 Jan '11

Release candidate files for the 1.44.0 beta are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers

6 7

[string] Realistic API proposal
by Artyom 31 Jan '11

31 Jan '11

Hello All, I'd like to provide a realistic string API proposal: 1. It is Unicode aware extension of std::string 2. It is fully compatible with std::string giving an ability to be included in C++XYZ 3. It can be implemented today! Basically it extends std::string with a) const_code_point_iterator - for iterating over string - bidirectional b) code_point_iterator - back inserter c) provides Unicode and Locale functionality: - normalization - case handling - comparison - search d) marks non const operator[],at() as deprecated Advantages: ----------- 1. It can be implemented easily (when boost.locale is given) 2. It **is** compatible replacement of std::string 3. It allows to use std::string meanwhile under the hood as storage giving high efficiency when assigning boost::string to std::string when the implementation is COW (almost all implementations with exception of MSVC) 4. It is full unicode aware 5. It pushes "UTF-8" idea to standard C++ 6. You don't pay for what you do not need. Proposed API: ------------- namespace boost { // Fully bidirectional iterator template<typename UnitsIterator> class const_code_point_iterator { public: const_code_point_iterator(UnitsIterator begin,UnitsIterator end); // begin const_code_point_iterator(UnitsIterator begin,UnitsIterator end,UnitsIterator location); // current pos const_code_point_iterator(); // end #ifdef C++0x typedef char32_t const_code_point_type; #else typedef unsigned const_code_point_type; #endif const_code_point_type operator*() const; ... }; /// Output iterator template<typename BackInserter> class code_point_iterator { public: code_point_iterator(BackInserter out); // begin code_point_iterator(); // end #ifdef C++0x typedef char32_t code_point_type; #else typedef unsigned code_point_type; #endif code_point_type operator*() const; ... }; template<typename Char,typename Traits=std::char_traits<Char>, typename Alloc=std::allocator<Char> > class basic_string { public: // { boost specific typedef std::basic_string<Char,Traits,Alloc> std_string_type; // } boost specific // All std::string standard functions based // Deprecated interfaces that exist for backward compatibility // as they not Unicode aware value_type &at(size_type indx); value_type &operator[](size_type indx); iterator begin(); iterator end(); // { boost specific compatibility functions with std::string, they would go // as std::string becode extended with boost::string new interfaces // basic_string(std_string_type const &other) : data_(other) {} basic_string(std_string_type const &other,size_type index,size_type len) : data_(other,index,len) {} ... operator std_string_type() const { return data_; } // } boost specific compatibility functions // // Unicode Support // // ------------------------ // // // UTF Codepoint iteration // #ifdef C++0x typedef char32_t code_point_type; #else typedef unsigned code_point_type; #endif typedef boost::const_code_point_iterator<const_iterator> const_code_point_iterator; const_code_point_iterator code_point_begin() const { return const_code_point_iterator(begin(),end()); } const_code_point_iterator code_point_end() const { return const_code_point_iterator(begin(),end(),end()); } typedef boost::code_point_iterator<std::back_inserter<basic_string> > code_point_iterator; code_point_iterator back_inserter() { return code_point_iterator(std::back_inserter<basic_string>(*this)); } basic_string &operator+=(code_point_type code_point); basic_string operator+(code_point_type code_point) const; void append(code_point_type code_point); // // Lexical operations on string // // Case handling basic_string upper_case(std::locale const &l=std::locale()) const; basic_string lower_case(std::locale const &l=std::locale()) const; basic_string title_case(std::locale const &l=std::locale()) const; basic_string fold_case() const; // locale independent // Unicode normalization typedef enum { nfc, nfkc, nfd, nfkd } normalization_mode; basic_string normalize(normalization_mode mode = nfc) const; // normalized string constructor basic_string(basic_string const &,normalization_mode mode); basic_string(Char const *,normalization_mode mode); basic_string(Char const *,size_t n,normalization_mode mode); template<Iterator> basic_string(Iterator begin,Iterator end,normalization_mode mode); void append_normalized(basic_string const &other,normalization_mode mode = nfc); void append_normalized(Char const *,normalization_mode mode = nfc); void append_normalized(Char const *,size_t n,normalization_mode mode = nfc); basic_string concat_normalized(basic_string const &other,normalization_mode mode = nfc) const; basic_string concat_normalized(Char const *,normalization_mode mode = nfc) const; basic_string concat_normalized(Char const *,size_t n,normalization_mode mode = nfc) const; // Unicode validation bool valid_utf() const; typedef struct validate_utf{}; // Unicode validation tag // Create string validating it basic_string(basic_string const &,validate_utf const &); basic_string(Char const *,validate_utf const &); basic_string(Char const *,size_t n,validate_utf const &); template<Iterator> basic_string(Iterator begin,Iterator end,validate_utf const &); // Create string validating and normalazing it basic_string(basic_string const &,validate_utf const &,normalization_mode mode); basic_string(Char const *,validate_utf const &,normalization_mode mode); basic_string(Char const *,size_t n,validate_utf const &,normalization_mode mode); template<Iterator> basic_string(Iterator begin,Iterator end,validate_utf const &,normalization_mode mode); // Search and comparison typedef enum { primary = 0, ///< 1st collation level: base letters secondary = 1, ///< 2nd collation level: letters and accents tertiary = 2, ///< 3rd collation level: letters, accents and case quaternary = 3, ///< 4th collation level: letters, accents, case and punctuation identical = 4 ///< identical collation level: include code-point comparison } level_type; // // search(...) return pair of index and size as string you search for may have different size // std::pair<size_type,size_type> search(basic_string const &other) const; std::pair<size_type,size_type> search(basic_string const &other,level_type level) const; std::pair<size_type,size_type> search(basic_string const &other,std::locale const &l) const ; std::pair<size_type,size_type> search(basic_string const &other,level_type level,std::locale const &l) const; std::pair<size_type,size_type> search(basic_string const &other,size_t index,size_t size) const; std::pair<size_type,size_type> search(basic_string const &other,size_t index,size_t size,level_type level) const; std::pair<size_type,size_type> search(basic_string const &other,size_t index,size_t size,std::locale const &l) const; std::pair<size_type,size_type> search(basic_string const &other,size_t index,size_t size,level_type level,std::locale const &l) const; std::pair<size_type,size_type> search(Char const *) const; std::pair<size_type,size_type> search(Char const *,level_type level) const; std::pair<size_type,size_type> search(Char const *,std::locale const &l) const ; std::pair<size_type,size_type> search(Char const *,level_type level,std::locale const &l) const; std::pair<size_type,size_type> search(Char const *,size_t size) const; std::pair<size_type,size_type> search(Char const *,size_t size,level_type level) const; std::pair<size_type,size_type> search(Char const *,size_t size,std::locale const &l) const; std::pair<size_type,size_type> search(Char const *,size_t size,level_type level,std::locale const &l) const; int compare_to(basic_string const &other) const; int compare_to(basic_string const &other,level_type level) const; int compare_to(basic_string const &other,std::locale const &l) const ; int compare_to(basic_string const &other,level_type level,std::locale const &l) const; int compare_to(basic_string const &other,size_t index,size_t size) const; int compare_to(basic_string const &other,size_t index,size_t size,level_type level) const; int compare_to(basic_string const &other,size_t index,size_t size,std::locale const &l) const; int compare_to(basic_string const &other,size_t index,size_t size,level_type level,std::locale const &l) const; int compare_to(size_t index,size_t size,basic_string const &other) const; int compare_to(size_t index,size_t size,basic_string const &other,level_type level) const; int compare_to(size_t index,size_t size,basic_string const &other,std::locale const &l) const ; int compare_to(size_t index,size_t size,basic_string const &other,level_type level,std::locale const &l) const; int compare_to(size_t index,size_t size,basic_string const &other,size_t index,size_t size) const; int compare_to(size_t index,size_t size,basic_string const &other,size_t index,size_t size,level_type level) const; int compare_to(size_t index,size_t size,basic_string const &other,size_t index,size_t size,std::locale const &l) const; int compare_to(size_t index,size_t size,basic_string const &other,size_t index,size_t size,level_type level,std::locale const &l) const; int compare_to(Char const *) const; int compare_to(Char const *,level_type level) const; int compare_to(Char const *,std::locale const &l) const ; int compare_to(Char const *,level_type level,std::locale const &l) const; int compare_to(Char const *,size_t size) const; int compare_to(Char const *,size_t size,level_type level) const; int compare_to(Char const *,size_t size,std::locale const &l) const; int compare_to(Char const *,size_t size,level_type level,std::locale const &l) const; int compare_to(size_t size,Char const *) const; int compare_to(size_t size,Char const *,level_type level) const; int compare_to(size_t size,Char const *,std::locale const &l) const ; int compare_to(size_t size,Char const *,level_type level,std::locale const &l) const; int compare_to(size_t size,Char const *,size_t size) const; int compare_to(size_t size,Char const *,size_t size,level_type level) const; int compare_to(size_t size,Char const *,size_t size,std::locale const &l) const; int compare_to(size_t size,Char const *,size_t size,level_type level,std::locale const &l) const; // UTF validation bool is_valid_utf() const; private: std_string_type data_; }; } // boost

4 8

Re: [boost] [1.46.0 beta 1] Release candidate files available
by Cromwell Enage 30 Jan '11

30 Jan '11

When running "bjam --toolset=gcc stage" on the command line, I get the following message: tools/build/v2/build/configure.jam:145: in builds-raw *** argument error * rule UPDATE_NOW ( targets * : log ? : ignore-minus-n ? ) * called with: ( <pbin.v2/libs/regex/build/gcc-4.2.1/debug>has_icu : : ignore-minus-n : ignore-minus-q ) * extra argument ignore-minus-q (builtin):see definition of rule 'UPDATE_NOW' being called It's the same error that's been preventing me from building auto-index. Cromwell D. Enage

3 4

Boost-1.46.0-beta1 fails to build in tools/regression/
by Philipp Reh 30 Jan '11

30 Jan '11

tools/regression expects boost::filesystem to be version 2 but version 3 is now the default. The attached patch fixed the build for me.

1 0

Re: [boost] RE process (prospective from a retired FreeBSD committer)...
by Brian Wood 30 Jan '11

30 Jan '11

Dave Abrahams wrote: >At Sun, 30 Jan 2011 16:43:17 +0300, > Vladimir Prus wrote: > > >> whereas most of the core (which is half-zillion times bigger than >> Boost), lives in two modules, which contain wildly different >> functionality, are updated by multiple people, and then built and >> used and tested by users all the time. So, this proves that Boost >> has a lot of grows ahead before having all code in place place will >> becomes, even in theory, a problem. > > The problem isn't where the code is located, it's: > > a. how much coordination is required to get things done > > b. the mental drag of having to deal with all the parts of Boost that > simply aren't relevant to you. > I've recommended to "chew the meat and spit the bones," when it comes to Boost since at least 2007. This approach sounds like it will make it easier to produce a tasty Boost according to one's understanding. So I'm in favor of it, though I rather expect achieving it will be difficult. This *less taxing* approach (in terms of hard drives, download times, ...) will be a breath of fresh air. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

1 0

Stack-based vector container
by Gregory Crosswhite 30 Jan '11

30 Jan '11

Hey everyone, In the course of my work as a computational scientist I have written a container that emulates std::vector, but which is backed by an array whose size is fixed at compile time. Concretely, the class looks something like the following: template<typename T,unsigned int buffer_size> class static_vector { ... protected: T data[buffer_size]; T* end_ptr; size_t current_size; } where in the [...] there are methods that emulate (at this time, partially) the interface of std::vector, save that the size of the static_vector is not allowed to grow beyond the buffer_size. The advantage of using a static_vector over vector is performance. In my code I have performed benchmarks that show up to a 30% performance boost of static_vector over vector; the benefit occurs most stongly when working with lots of arrays of small objects, so that the use of dynamic memory rather than stack memory appears to add significant overhead to the computation. (Note that I when running these benchmarks I would use std::vector::reserve() to pre-allocate the array so that std::vector would not perform multiple allocations as the container grew, so that should not have been a source of overhead.) It seems to me that it would be useful to have this functionality generally available as a library, and in particular it might be a good fit for the boost family of libraries. Is there any interest out there for having such a library in boost? If so, I would be happy to do the work of taking what I have and fleshing it out so that it can function as a drop-in replacement for vector, which means modeling the Random Access Container and Back Insertion Sequence concepts as well as adding capacity() and reserve(size_t) (no-op) methods. Thoughts? Cheers, Gregory Crosswhite

17 53

GIL io_new review
by Phil Endecott 30 Jan '11

30 Jan '11

Back in 2006 I had some code that used ImageMagick's Magick++ library to read and write images in various formats and do some basic processing. That library works well and is very feature-full, but is not what you would call "Boost like", so I was excited when GIL came along. I looked at it at the time of its review, and I thought at first that I must have missed a big chunk of the documentation where all the algorithms were described! Of course, it has no image processing algorithms; it's just a layer; if you want to scale or rotate or merge images, you have to do that yourself. I don't think I wrote a review in the end; my feeling was - in comparison with ImageMagick - "come back when you've finished" - but I didn't want to say that in public. So it's great that now, 4 years later!, we are finally getting some GIL extensions. Thank you Christian for - I hope! - getting the ball rolling. I hope we'll see more. Having said that, I suspect that even with lots of extensions GIL might not really be what I need. Here's a typical problem that I will have to address in the next few weeks: I have a 1e12 pixel image - a map - which is supplied as a few thousand 5000x5000 TIFF tiles; I have to join them together, tweak the colours, draw some lines on top, and re-chop it into a few million 256x256 PNG tiles. The issue of course is that that image can't be held in RAM. I will do this with my own wrappers around libtiff and libpng, in rows or chunks. So, do the image concepts (and concrete classes) that GIL defines accommodate that sort of problem? Even if they do, is a "virtual image" of some sort a good way of doing it? I suspect not. But even if the image concept is not useful, presumably other GIL concepts like pixel formats and algorithms in future extensions (pixel format conversion, blending) could still be useful. So, along comes Christian's IO extension. Wrapping the "legacy" image libraries is something that I have done a few times now and it can be painful, not least because of the need to read a lot of documentation; the libraries all differ and it would be great to get a unified set of wrappers that provide a sane C++ interface. But as you can see, I don't really want something that reads and writes complete GIL images, and that is what Christian's extension does. Ideally, this extension would have separated out the wrapping of the libraries from the actual GIL image integration, with the GIL image integration just being a layer on top of the image library wrappers. Since it doesn't do that, it's not much use to me. It is, however, better than what GIL currently has. So for that reason I suggest that it should be accepted. > - What is your evaluation of the design? In addition to my comments above, I note that it's necessary to jump through hoops (using Boost.IOStreams) just to read an image from memory. Surely this should be a fundamental operation; it would be much better to have a ctor that takes begin and end pointers for the encoded image data. > - What is your evaluation of the implementation? When I first looked at the library I noticed that the error handling was clearly broken. Although that seems to have been resolved, it has given me a poor impression of the quality (i.e. likely correctness) of the implementation. It seems that this error handling has received almost no testing. Thorough testing will be difficult for this library because as well as all the usual permutations of platform features, compilers etc. the variations in the image libraries must also be considered. The library version and compiler settings could both affect the correct operation of this code. I have some concerns about the likely performance of the code due to excessive copying of the data both in and out of the image library. Although I've not measured the performance impact, I feel it would be very desirable (and is certainly possible) for this library to have zero copying. > - What is your evaluation of the documentation? Satisfactory. (As a meta-comment - I think libraries being reviewed really should have their docs available online somewhere, and preferably also their source code in a source browser of some sort. In fact, I thought this was already a requirement. Can it be added to the review managers' checklist for future reviews?) > - What is your evaluation of the potential usefulness of the extensions? It's better than what was there before. > - Did you try to use the extensions? With what compiler? Did you have > any problems? No, I've not compiled anything. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? Probably half a day during the review, and a similar amount of time a few months ago. > - Are you knowledgeable about the problem domain? I've written a few wrappers for libjpeg, libpng and libtiff. I've never used GIL though I've read extensively about it. > And finally, every review should answer this question: > - Do you think the extensions should be accepted as a part of Boost.GIL > library? On the grounds that this is better than what is currently there, and on the assumption that Domagoj Saric is not imminently going to post something else that would supersede this, I believe that it should be accepted. (I have not looked at the "toolbox" at all, and I've not seen it mentioned in any other reviews yet. My "yes" is just for the io_new functionality.) Regards, Phil.

7 39

[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

[network] Bagged, Tagged, New Release 0.8.1
by Dean Michael Berris 29 Jan '11

29 Jan '11

Hi Everyone, Just a quick note, there's an update to the 0.8 line which addresses issues that have been identified with the previous 0.8 release. It's recommended that people using the 0.8 release upgrade to 0.8.1. This release is still a header-only release, with some features back-ported from the 0.9-devel branch. You can get the 0.8.1 release at https://github.com/cpp-netlib/cpp-netlib/downloads Have a good day everyone and I hope this helps. PS. The 0.9 release should come out soon, final documentation updates are just getting done; the 0.9 line will be the version that shall be submitted for review, looking for interested review managers at this time. -- Dean Michael Berris about.me/deanberris

1 0