- Boost - lists.boost.org

[Locale] Request to merge to release branch
by Artyom Beilis 22 Aug '11

22 Aug '11

Hello, I want to request a permission to merge Boost.Locale to the release branch. Testing Status: =============== Link:http://beta.boost.org/development/tests/trunk/developer/locale.html Fully tested and pass 100% compilers/platforms: ----------------------------------------------- Compilers: - MSVC-8,9,10 with native libraries - GCC all versions - Intel - on Linux - Visual Age on Linux Current major faults: --------------------- - Sun Studio - reported bug in Boost.Thread - Intel on Darwin - seems to be general compiler regression for all libraries (not related to Boost.Locale) - MSVC for Windows Mobile - not supported, will not be supported due to lack of standard library functionality - Visual Age/AIX - iconv has poor implementation on AIX and ICU not provided on the testing machine so, there is no way to test. Minor faults: ------------- - GCC prior to 4.5 on Windows - will not work with dynamic build (dll) due to lack of linking with dynamic runtime (libstdc++6.dll) - Pathscale-4 and MSVC-9 with STL-Port: minor fults in wide file I/O where invalid UTF-8 prevents reading valid part. Can't debug it due to lack of access to platform and compiler. Thank you very much, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

2 6

[fusion] segmented fusion 2.0
by Eric Niebler 22 Aug '11

22 Aug '11

I took the liberty of rewriting all my old broken segmented fusion code and checked in something (hopefully) a bit more maintainable and friendly. Along with the changes, I added an algorithm called segmented_fold_until. Many of the existing algorithms have segmented versions that can be implemented trivially in terms of this one. (Recall that the biggest problem with the old implementation was the need to write a separate implementation of every algorithm for segmented data structures, which was very complicated. Now that's almost trivial.) I hope in the coming weeks and months to produce segmented versions of most of the existing fusion algorithms. Once that's done, I hope to "bake it in" by making the existing algorithms select the segmented flavors automatically. Also, some containers and views are naturally segmented, like joint_view. Practically all of joint_view's implementation, including its iterator, would vanish if it just advertised itself as segmented. Thoughts? Objections? -- Eric Niebler BoostPro Computing http://www.boostpro.com

7 26

[intrusive] Move constructors
by Rei Thiessen 21 Aug '11

21 Aug '11

Could we add move constructors to all intrusive containers? Rei

2 2

[enums] Request for comments on an enum-oriented library
by Beren Minor 21 Aug '11

21 Aug '11

Hi all, I'm currently writing a C++ library to add some functionalities to enums, and am looking for comments and feedbacks. Boost is a reference, and I would be glad if some C++ expert here could take a moment to look at what I've written and tell me his thoughts. I know that there was already some discussions about enums here, and some early implementations of enum libraries at Boost, but I couldn't find any that fitted my requirements, or any that was in an stable enough stage. My goal wasn't to submit another one to Boost (although I would be really proud of it, I'm not thinking about it yet, just looking for comments), but to implement something usable for some of my specific needs. Initially I was only looking for enum (de)serialization, however I think that these needs can be quite common, and that the library could be used by others as well. That's why I'm trying to find some comments and to share my work. My goal was to implement a library following these requirements : - Extend the enum concept with different flavors. - Scope the enum constants out of namespace scope. - Do not get rid of implicit integer cast, or at least, try to provide enum/integer interoperability so we don't have to cast all the time. - No overhead, keep the enum constants as light as they are natively. For the first requirement, I wanted to add three new flavors to enums, that I've called "static enums", "dynamic enums" and "bit fields". The main difference between them is the way these enums are (de)serialized and the available enum / enum and enum / integer operators when this is meaningful (only when using C++0x, with scoped enums). - Static enums only allow explicitly defined constants (with specified or implicit integer values), any other value will result in a (de)serialization to special value "unknown". - Dynamic enums allow explicitly defined constants and offsets from these constants, within a given global range (from the first constant to the specified upper integer limit). Every value within the range will be serializable, any other will result in "unknown". An integer value between two enum constants will be (de)serialized as the nearest lower enum constant plus an offset. For example, if the enum is defined as { value1 = 1, value2 = 5..., unknown = 10 }, the available range would be from 1 to 9, and the integer 4 will be serialized as "value1#3" which means (value1 + 3). - Bit fields enums only allow combination of explicitely defined constants. These will be (de)serialized as a combination of every defined enum constants, any other value will be (de)serialized as "unknown". This flavor restricts constants values to bitwise distinct integers, and to values different from 0 in order to be able to decompose the enum into the specified enum constants. 0 being the special "unknown" value for this flavor. For example, for an enum defined as { bit1 = 0b001, bit2 = 0b010, bit3 = 0b100... }, an instance of this enum with an integer value of 3 will be serialized as "bit1+bit2", and "bit1+bit3" will be deserialized as an enum instance of integer value 5. As I said, the library obviously uses Boost, and in an extensive way Boost Preprocessor macros, and tries to integrate nicely with Boost libraries. Serialization, for example, is done through stream template operators, and should be usable with the Boost Lexical Cast library. These isn't any real documentation yet, except from doxygen (although not yet complete, I've tried to be verbose), but I think that the library is simple enough to be understood by reading the source code, and I've got some unit tests to help getting the genereal idea. Lastly, I still have some issues about some points, mostly because of the use of macros and boilerplate code, but I hope to be able to fix them. - No namespace support. - Enum declaration comes with the serialization code. I would like to be able to separate definition and declaration of this code, but I'm not sure how to do that properly without overhead for the developer. I'll have to think about it. - The writing overhead of the enum declaration (compared to plain old enum) is still a little bit too much for my taste, but I don't know if I'll be able to do much better without introducing some obscure and meaningless helper macros. This is mainly because of the need of declaring the enum constants in a Boost Preprocessor sequence, in order to be able to use it at various places to generate the enum declaration as well as the serialization code. - Also, the declaration could be cleaner if I could find a way to implement optional parameters in macros, but that seems like difficult to do (or I haven't found out yet how to do). - I don't have any other environment available except from my Debian Linux box, so I couldn't test on anything else than gcc. I don't really expect it to work with anything else. Actually, my main build scripts themselves are probably broken on anything else than my computer. [1] That said, if anyone wants to take a look at it and share his thoughts, the library can be found here : https://github.com/berenm/libtenum Best regards, Beren Minor Notes: [1] I've added a "portable-build" branch to my git repo if anyone want to try running the tests cases somewhere else. Build is done with bjam.

3 3

Intel compiler and Boost libraries
by Edward Diener 20 Aug '11

20 Aug '11

I normally do not mind paying for software that much but because of the tight economic times for myself I am a bit loth to pay for a version of the Intel C++ compiler, which is not exactly cheap, in order to just test out my Boost libraries. Ordinarily I can use gcc in Linux and Windows, clang on Linux, or VC++ on Windows. But I am aware that the more compilers I can test my libraries with, the better off my library will be and in the review of my TTI library one of the points made is that I need to test it and guarantee that it will work on a wider variety of C++ compilers. I am wondering how others have come by their copies of Intel C++ ? Have you bought it, have you gotten it on some sort of academic pricing, have you acquired a license as part of your job, does Intel offer an inexpensive or free version of their compiler for C++ experts like Boost developers who are helping to test their compiler against the most rigorous C++ code as Boost libraries usually are, or what is the situation for others who test their libraries using Intel C++ ? I realize there is a 30-day free trial but after that 30 days one can not use the compiler for a particular OS without having a valid license for it.

3 3

Re: [boost] [Containers Library Review] The review of the Containers library by Ion Gaztanaga starts today
by Ion Gaztañaga 20 Aug '11

20 Aug '11

El 19/08/2011 23:55, Dave Abrahams escribió: > Find the performance tests being used by clang's libc++ and try those? Thanks, is that code license-compatible with Boost license? Best, Ion

1 0

[UUID] seed_rng.hpp contains invalid forward declaration of random_device
by Johan Lindvall 19 Aug '11

19 Aug '11

The following fails to compile with 1.47.0: #include <boost/uuid/seed_rng.hpp> #include <boost/random/random_device.hpp> It used to work with 1.46.1 (using nondet_random.hpp) Filed as https://svn.boost.org/trac/boost/ticket/5794 -- /Johan.

1 0

[random] uniform_smallint
by Agustín K-ballo Bergé 19 Aug '11

19 Aug '11

boost::uniform_smallint<> distribution defaults its min and max constructor arguments to 0 and 9 respectively. While arbitrary, this may make sense for default constructed distributions. However, its easy to trigger an assert at runtime by calling its constructor with a single value (min > 9). Could this constructor be splitted into a default constructor and one that takes *both* min and max? I tried to check whether the standard mandates this, but couldn't find the FDIS online anymore (on a separate note, anyone knows where to find it?). Agustín K-ballo Bergé.- http://talesofcpp.blogspot.com

1 0

[gsoc] Request Feedback for Boost.Ustr Unicode String Adapter
by Soares Chen Ruo Fei 19 Aug '11

19 Aug '11

Hi all, A while ago I gave some previews of my Unicode String Adapter library to the boost community but I didn't receive much feedback. Now that GSoC is ending I'd like you all to take a look at my project again and provide feedback on the usefulness of the library. Following are the links to my project repository and documentation: GitHub repository: https://github.com/crf00/boost.ustr Documentation: http://crf.scriptmatrix.net/ustr/index.html Recently there was some threads in the mailing list mentioning about Unicode issues and forcing the use of UTF-8 encoding in std::string again. I feel certain that few of the key people involving in the debates should have at least read my project proposal before and understand what Boost.Ustr was trying to achieve, however it seems like my approach is not much favored by anyone. So here I'd also like to know from these people why my approach on using Unicode string adapter is not the best way to solve the Unicode problem in C++. I understand that the requirement to alter existing APIs might be the biggest barrier to make Boost.Ustr adopted by everyone, but I think here is the key question: if you have the chance to go back in time and restart your project from scratch, are you willing to use Boost.Ustr in your library APIs and do you think that it could have solved the Unicode problems you're having right now? Thanks. Best Regards, Soares Chen

14 61

Re: [boost] New version of Boost.Algorithm (proposed) in the vault
by TONGARI 17 Aug '11

17 Aug '11

2011/8/18 Marshall Clow <mclow.lists(a)gmail.com> > > On Aug 17, 2011, at 9:28 AM, TONGARI wrote: > > > 2011/4/19 Marshall Clow <mclow.lists(a)gmail.com> > > > >> < > >> > http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Boost.… > >>> > >> > >> Changes since -008: > >> > >> * Better documentation all around - including doxygen. > >> * Fixed typo-style bugs in all.hpp, and added tests to make sure they > stay > >> dead. > >> * Better comments in clamp.hpp, and better tests. > >> * The search algorithms now deal correctly with zero-length patterns and > >> corpuses, and have tests for that. > >> * The search algorithms now have tests for the compile-time assertions. > >> * MSVC 10 compatibility > >> > >> Please download, try it out, and let me know! > >> > > > > I was trying to use KMP and got some errors: > > * No CHAR_BIT declared. > > * template boost::algorithm::knuth_morris_pratt does not accept plain > > pointer type. > > What compiler and version (and OS)? > g++4.5.2/MinGW, on XP SP3, compiled with c++0x enabled. But I don't think it's compiler specific, I can locate the errors...

2 1