- Boost - lists.preview.boost.org

[Endian] Review / Comments
by Tim Blechmann 10 Sep '11

10 Sep '11

hi, documentation the documentation in general is pretty short, but sufficient: the concepts of the library are easy, so there is no need to go into more details. however i would prefer if the documentation uses quickbook/boostbook. most of the recent boost libraries have a very similar layout of the documentation, but the boost.endian docs do not follow these conventions. also the docs for `conversion functions' and for `integer types' are separate. personally i'd prefer if they could go into the same document, maybe having a structure like: introduction, integer types, conversion functions, examples, reference (preferably doxygen-generated). section `experience': this section gives no insights for people who use or read the code. it mainly tells: "we are not the first and the domain of the library is important.". imo this section can be removed (maybe the part that it is not related to any c library can go to the `design considerations' section "motivating use cases": this is more a marketing blurb/testimonial. maybe this could be changed to a section about possible use cases, listing `communicating between different devices' and `reading/writing of binary file formats'. provided files i suppose, the msvc project file will go away when the library is merged into trunk. besides, i'd suggest to move "boost/endian/support/timer.hpp" to "lib/endian/support", because it only seems to be used by the benchmarks. testsuite scoped_enum_emulation_test.cpp ... not related to boost.endian, please remove endian_operations_test.cpp and endian_in_union_test.cpp ... maybe rename from _test.cpp to _compile_test.cpp? they don't seem to do any run-time tests. they also should not include <cassert> since no assertion statement is needed, this might speed up the compilation time of the testsuite by something like 50ms ;) conversion functions personally, i find the interface for the conversion functions rather odd, as they don't actually return a value, but take a reference to the return value. so they cannot really be used in a functional style. if the reorder functions would have a signature like: int16_t reorder(int16_t x); it would be possible to use it as unary operator e.g. in with std::transform and the like. this would also avoid the need for both in-place and out-of- place functions. iac, i don't see a reason for the in-place functions. for the reason, see below. performance considerations the current implementation seems to perform horribly on x86_64 hardware. i ran phil's nice benchmark program inside the `perf' profiler on my core i7 920 ("g++-4.6 -O3 -std=gnu++0x -march=native"), where the algorithm takes MUCH more time than htonl, gcc's builtins or a mask/shift implementation. the main reason seems to be a huge amount of byte-wise load/stores, which lead to a huge number of stalls. a mask/shift implementation will be computed completely in registers, making use of instruction-level parallelism on out- of-order cpus and requiring less memory transfers. as a side effect, boost.endian will compose much better, when using the reorder functions on values, which are already in registers, or which need to be placed in registers later in the algorithm. modification for bitmasks: return (src<<24) | ((src<<8) & 0x00ff0000) | ((src>>8) & 0x0000ff00) | (src>>24); modification for boost.endian types (assuming little-endian hardware): uint32_t n; boost::detail::store_big_endian<uint32_t, sizeof(uint32_t)>(&n, src); return n; USE_GCC_BUILTIN: Performance counter stats for './a.out': 986.666145 task-clock # 1.000 CPUs utilized 0 context-switches # 0.000 M/sec 7 CPU-migrations # 0.000 M/sec 307 page-faults # 0.000 M/sec 2,637,245,698 cycles # 2.673 GHz 633,384,188 stalled-cycles-frontend # 24.02% frontend cycles idle 281,512,771 stalled-cycles-backend # 10.67% backend cycles idle 6,007,671,727 instructions # 2.28 insns per cycle # 0.11 stalled cycles per insn 1,001,451,092 branches # 1014.985 M/sec 31,112 branch-misses # 0.00% of all branches 0.987133571 seconds time elapsed USE_HTONL Performance counter stats for './a.out': 938.226124 task-clock # 1.000 CPUs utilized 0 context-switches # 0.000 M/sec 3 CPU-migrations # 0.000 M/sec 307 page-faults # 0.000 M/sec 2,507,753,527 cycles # 2.673 GHz 504,694,743 stalled-cycles-frontend # 20.13% frontend cycles idle 53,006,181 stalled-cycles-backend # 2.11% backend cycles idle 6,006,376,475 instructions # 2.40 insns per cycle # 0.08 stalled cycles per insn 1,001,180,324 branches # 1067.099 M/sec 23,212 branch-misses # 0.00% of all branches 0.938684989 seconds time elapsed USE_BEMAN Performance counter stats for './a.out': 7494.906291 task-clock # 1.000 CPUs utilized 0 context-switches # 0.000 M/sec 12 CPU-migrations # 0.000 M/sec 307 page-faults # 0.000 M/sec 20,033,609,533 cycles # 2.673 GHz 15,018,356,865 stalled-cycles-frontend # 74.97% frontend cycles idle 11,372,397,445 stalled-cycles-backend # 56.77% backend cycles idle 15,030,059,048 instructions # 0.75 insns per cycle # 1.00 stalled cycles per insn 1,005,600,935 branches # 134.171 M/sec 88,848 branch-misses # 0.01% of all branches 7.497572144 seconds time elapsed USE_BITMASK Performance counter stats for './a.out': 986.085196 task-clock # 0.999 CPUs utilized 0 context-switches # 0.000 M/sec 0 CPU-migrations # 0.000 M/sec 307 page-faults # 0.000 M/sec 2,635,658,193 cycles # 2.673 GHz 631,672,783 stalled-cycles-frontend # 23.97% frontend cycles idle 269,536,819 stalled-cycles-backend # 10.23% backend cycles idle 6,008,101,435 instructions # 2.28 insns per cycle # 0.11 stalled cycles per insn 1,001,523,773 branches # 1015.656 M/sec 31,020 branch-misses # 0.00% of all branches 0.986601856 seconds time elapsed USE_TYPES Performance counter stats for './a.out': 7121.796026 task-clock # 1.000 CPUs utilized 0 context-switches # 0.000 M/sec 12 CPU-migrations # 0.000 M/sec 307 page-faults # 0.000 M/sec 19,035,784,897 cycles # 2.673 GHz 15,019,771,466 stalled-cycles-frontend # 78.90% frontend cycles idle 1,182,185,735 stalled-cycles-backend # 6.21% backend cycles idle 14,032,012,033 instructions # 0.74 insns per cycle # 1.07 stalled cycles per insn 1,005,916,931 branches # 141.245 M/sec 84,751 branch-misses # 0.01% of all branches 7.124340206 seconds time elapsed What is your evaluation of the potential usefulness of the library? very important, very useful How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? roughly 3 hours, reading code, documentation, running some benchmarks. besides, i'm using an older version of the library for about 2 years without having any problems. Are you knowledgeable about the problem domain? yes Do you think the library should be accepted as a Boost library? the library should be accepted, if (a) the interface of the conversion functions is changed (b) the performance can be improved (c) the documentation integrates better with the rest of the boost documentation. cheers, tim

5 8

[Review] Boost.Endian - template requirements and scope
by Vicente J. Botet Escriba 10 Sep '11

10 Sep '11

Hi, I have not found the requiremenst of the endian class template parapeter T and conversion functions. What are they? Could them be added to the documentation? I have not found a tutorial on how to use the endian conversions. Could you give an example that shows how easy is to use them with UDT? Collections of UDT? Could the user overload the conversion functions for UDT? While the predefined endian types are useful I guess that the user could instantiate the endian class with a UDT, isn't it? Could you post a working example and add it to the documentation? The scope of Boost.Endian is integer types. Aren't floating point types and endianness related? If the scope of the library is limited to integers, maybe Integer.Endian could be a better name? Best, Vicente

3 5

[proto] proto::as_child potentially unsafe?
by John Maddock 09 Sep '11

09 Sep '11

Following the guide here: http://www.boost.org/doc/libs/1_47_0/doc/html/proto/users_guide.html#boost_… I fell into a nasty trap: as_child stores it's argument as a reference, and as far as I can tell there is no way to force it to store by value, unless you apply deep_copy to the whole expression tree (not just the one child created with as_child). I found this when trying to protoize a function that looked like: template <class Exp> some-return-type foo(const Exp&, int i); In which the value "i" was returned as a reference to a value on the stack which then went out of scope :-( Even if the function has a signature such as: template <class Exp> some-return-type foo(const Exp&, const int& i); There is still a potential trap, because you don't know where "i" came from and when it will go out of scope - OK so the result of the expression will *usually* be calculated before that happens - but you never know. IMO I think this trap needs better documenting, because the section in question (and text preceding it) read to me "as if" arguments to as_child were stored by value. I'm sure I'm reading that wrong.... but you know ;-) John.

2 1

[Endian] Proposed endian integer types
by Phil Endecott 09 Sep '11

09 Sep '11

Dear All, I have had a quick look at the proposed endian::big|littleN_t types. A couple of comments: - I was expecting to find that these types would use the conversion functions that I've already looked at at the lowest level, so that optimisations made to those functions would be useful here too. But instead, these classes seem to use their own byte-shuffling code. This seems like an odd design. - I'm not convinced that these types cause the conversion to happen at the optimum time. For example: struct file_header { big32_t n_things; .... }; int main() { file_header h; h.n_things = 0; while (....) { ++h.n_things; .... } write(h); .... } Here the conversion is happening twice every time that n_things is incremented. It would be better to instead do the conversion once, just before the file_header is written. The same thing applies in reverse when reading from a file. (Surely this is the most common use-case?) I have been wondering if there is a better design that can avoid this. If we had some sort of struct introspection, we could store the fields in native byte order and then template <typename T> T external_representation(const T& t) { T res(t); for each field of T { res.field.reorder(); } } ++h.n_things; // cheap write(external_representation(h)); // conversion happens once here. Of course we don't have introspection of structs so we can't do that. Maybe someone else has another idea. Regards, Phil.

3 2

[system] BOOST_ERROR_CODE_HEADER_ONLY undocumented
by Akira Takahashi 09 Sep '11

09 Sep '11

Hi, BOOST_ERROR_CODE_HEADER_ONLY macro is useful, but undocumented. Should not use this macro? And I think should move implementation (`libs/system/src/error_code.cpp`) to `boost/system` if formal provide this macro(example: `boost/chrono/detail/inlined`). Depending on the package manager is not provide below the `libs` directory (example: Portage of Gentoo Linux). Thanks, Akira >>======================== Akira Takahashi mailto:faithandbrave@gmail.com blog: http://d.hatena.ne.jp/faith_and_brave/

1 0

[Review] Boost.Endian
by john filo 08 Sep '11

08 Sep '11

- What is your evaluation of the design? For the original scope (i.e. integers), very good. However, I'd like to see additional support for float, double, and user defined types added. Without it, this library isn't very useful to me personally since a large percentage of the values that I have to deal with are either float or double. ---------------------------------------------------------------------- - What is your evaluation of the documentation? Excellent. Is a tutorial section going to be added? I'm not sure one is needed given the existing examples in the rest of the documentation, but the documentation's menu bar implies there will be one. ---------------------------------------------------------------------- - What is your evaluation of the implementation? Very good. At -O2, I was impressed with the performance relative to GCC's builtin byteswap routines. When I first saw the implementation, I honestly didn't think it would perform very well given its complexity compared to a naive implementation (e.g. the version used in the endian::reorder functions). I was pleasantly surprised. I guess that's a testament to the level of optimization compilers are capable of these days. On an Intel Core2, the performance penalty of the uint32 endian<> template and the reorder() function relative to GCC-4.4 builtins (i.e. runtime divided by runtime of builtin) is as follows: endian<> reorder() ------------------------ -O0 5.4 3.0 -O2 2.3 6.5 It seems like the reorder functions could be implemented in terms of the integer types for improved performance (and also maintainability). Something like: template<typename T> inline void reorder(T& x) { x = *reinterpret_cast< endian<endianness::nonnative, T, sizeof(T)/8> *>(&x); } template<typename T> inline void reorder(T source, T& target) { target = *reinterpret_cast< endian<endianness::nonnative, T, sizeof(T)/8> *>(&source); } Obviously the above requires extending the endianess enum with a "nonnative" value. Performance isn't that critical for me, but it does seem like providing platform specific implementations that take advantage of things like GCC's builtin byteswap functions should also be considered to get the performance up even further. Finally, for my last performance related comment, I was surprised to see that the native types had basically exact same performance as the nonnative types. Couldn't the native types be specialized to effectively be a no-op? Would "byteswap" or maybe "swapbytes" be a better name than "reorder"? ---------------------------------------------------------------------- - What is your evaluation of the potential usefulness of the library? For those who deal with non-native endian data, this library is extremely useful. It automatically eliminates a whole class of common programming errors when dealing with such data. ---------------------------------------------------------------------- - Did you try to use the library? With what compiler? Yes; gcc-4.4.3 on Linux ---------------------------------------------------------------------- - Are you knowledgeable about the problem domain? Yes. I've used a similar home-grown library for the past 10 years, and have been looking forward this being added to Boost for a long time. ---------------------------------------------------------------------- > - Do you think the library should be accepted as a Boost library? Absolutely. I'd like to see support for float and double, but even without those additions, I still vote yes.

4 5

Re: [boost] [optional] Thoughts on disallowing assignment for wrapped references.
by Stewart, Robert 08 Sep '11

08 Sep '11

Fernando Cacciola wrote: > > >> optional<T> > >> f() > >> { > >> optional<T> result; > >> // do stuff > >> return result; > >> } > > > > However, in the latter case, there is no loss of generality > > since the above would still be a no-no where T a reference > > type... > > Or did I miss something in your response? > > You totally missed his point. Indeed. > In Robert's example, it is easy to see--or should be easy to > see--that the fact that the optional<T> is being returned is > secondary, perhaps even irrelevant, to the point he is making > His point is about the shortcoming of lacking assignment, not > about object lifetimes (and BTW, is the same point Nevin and > I made earlier). I wouldn't go quite that far... > Perhaps a less distracting example would be: > > optional<T> o ; > > switch ( cond ) > { > case a : o = foo1(); break ; > case b : o = foo2(); break ; > case c : o = foo3(); break ; > case e : o = foo4(); break ; > case e : o = foo5(); break ; > > default : // o remains uninitialized > } > > Notice that is quite possible to encounter the above example > in real-life, as it is common that a variable remains > uninitialized in the default case of a switch (or, for that > matter, in any branch of a complex conditional). > > In fact, I even wonder if that example couldn't be considered > as the canonical use case for optional<>'s assignment > operation. The one thing you overlook in your example is that there are reasonable alternatives to using optional within a local scope. However, when returning a value from a function, ownership must be transferred to the caller, which reduces the safe options. Regardless, disallowing assignment for reference types which, in effect, "reseats a reference," is surprising in too many cases. A new, non-assignable optional type might gain traction, but removing assignment from optional<T&> is not acceptable. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 3

Boost.Endian comments
by tymofey 08 Sep '11

08 Sep '11

This is not a full review, but rather a few comments on the implementation of reorder(x) functions. What you are doing is casting pointers around and assigning individual bytes, which might not really effective: inline void reorder(int64_t source, int64_t& target) { const char* s (reinterpret_cast<const char*>(&source)); char * t (reinterpret_cast<char*>(&target) + sizeof(target) - 1); *t = *s; *--t = *++s; *--t = *++s; *--t = *++s; *--t = *++s; *--t = *++s; *--t = *++s; *--t = *++s; } it does eight increments, eight decrements, one addition, one substraction and eight assignments. maybe something like: inline void reorder(int64_t source, int64_t& target) { target = ((source << 0x38) & 0xFF00000000000000) | ((source << 0x28) & 0x00FF000000000000) | ((source << 0x18) & 0x0000FF0000000000) | ((source << 0x08) & 0x000000FF00000000) | ((source >> 0x08) & 0x00000000FF000000) | ((source >> 0x18) & 0x0000000000FF0000) | ((source >> 0x28) & 0x000000000000FF00) | ((source >> 0x38) & 0x00000000000000FF); } would be more efficient?

6 8

[Boost.spirit] How to use the Json/Spirit example found on codeproject site
by Demetrio Car 08 Sep '11

08 Sep '11

I am new in C++. I came from C# and Java world. I tried the example http://www.codeproject.com/KB/recipes/JSON_Spirit.aspx) and it`s working perfectly when I used that in Microsoft Visual Studio 2010. But, I expended two days and I couldn't do the same in Eclipse Indigo over Linux Ubuntu. I installed Boost in my Linux, included it in my project and some boost`s command (example BOOST_FOREACH) are working perfectly. But, I can't run the example I downloaded from codeproject and I believe that it's happening because I don't know how properly include libraries in Eclipse. I was able to include Boost and Curl because I followed some tutorials, but I don't know exactly what I have done. And, now, I couldn't run the codeproject example in Eclipse/linux as I've done in Visual Studio. If someone has already used this codeproject example on Eclipse/Linux and could give some suggestion about make the example work on Eclipse/Linux, it will be nice as well.

1 0

[serialization] or [spirit] JSON Archives
by Fernando Pelliccioni 08 Sep '11

08 Sep '11

Hi, After experimenting with Spirit.Qi to make a JSON parser, I had the need for a serializer. First, I thought I could serialize my model of JSON (json:: value, json: object, etc.), but that was not compatible with boost::serialization. I am currently writing a ARCHIVE for Boost Serialization, but I'm finding some problems in order to implement JSON correctly. The question is, does anyone know about some files to Boost Serialization already finished? I've seen the Archive made by Esteve Fernandez, but do not serve my purpose, because I just need JSON. I would like to develop a JSON parser which in turn is a compatible Boost Serialization serializer . Any ideas? Thanks and regards, Fernando Pelliccioni.

5 6

[integer] Type-safe and bounded integers with compile-time checking
by Leif Linderstam 07 Sep '11

07 Sep '11

Hi all, There are some integer libraries out there that improve on the fundamental integers; Boost.Integer, ACCU BoundedInt, part of The Boost Constrained Value library, and probably many other. They add the ability to specify an integer based on a range, they add bounds checking at runtime, or a combination of both. What I have not found yet though is a library that checks bounds at compile time. Me personally I would like to have the compiler check as much as possible. For instance, the compiler would complain about an assignment if the target's range is not a superset of the source's, unless an explicit conversion is made. Does anyone know of a library supporting this? If there is no such library I hope there is an interest in one and that this post will start a discussion about how it best can be done. The motivation for this kind of library is that its usage helps show the intent of the developer, and it can point out faults that otherwise even an extensive test suite might miss. That it forces the developer to thoroughly think about value ranges in computations I also regard as a point in favour. What about the type-safe part in the subject of this post? Even though most mistakes will be caught by the bounds checking, I believe there are situations where one wants to clearly state that an integer represents one specific concept and nothing else, for instance a numeric identifier. So I would like this kind of library to also support a kind of type-safety. I am not sure that that is the correct term for it, but what I mean is that when one declares a bounded integer it should be possible to state that it can not mix with other bounded integers regardless if the bounds are compatible. As I have been thinking about this for years now I of course have a lot of ideas on how to implement this. As a starting point for a discussion I would like to present some basic parts of what I have come up with. The integer type is declared as follows: template< typename Range, typename Tune = fast > struct integer; It takes a range type instead of taking the bounds directly. It also has a tuning parameter which is used when selecting the fundamental integer type to use for storage. The idea of having a separate range type is that it can be used for other types, see the array type below. The range type then: template< intmax_t Lower, intmax_t Upper, typename TypesafetyTag = defaultTypesafety > struct range_c; The bounds is no surprise, but here I add the type-safety part. I am not quit sure about this approach because the bounds and the type-safety mechanisms are orthogonal, but it works together quite well in practice I believe. Maybe it should not be named "range" but something else. The type-safety mechanism is fairly simple; two integers must have the same tag to be part of the same expression (unless a type-safety conversion is used). This means that they cannot be mixed with fundamental integers either. The default type-safety tag is special in that it allows for a mix with fundamental integers except that there is no implicit conversion or assignment to fundamental integers (this would otherwise provide a loophole). In practice fundamental integers do not work that well with the static bounded integers though, because most often the range is too big. Another type that seems fairly obvious is a static array (similar to Boost.Array): template< typename Range > struct array; The array of course is just as large as needed for the range. As subscript parameter it only accepts bounded integers with compatible ranges, i.e. with subset bounds and equal type-safety tag. Contrary to what is normal in C++ the array is not necessarily zero-based, it starts at the lower bound of the array. There is much more of course, for instance that the range type should take types instead of integers as bounds, but this post is getting too long already. As said before I hope this is going to be the start of a fruitful discussion. Sincerely, Leif Linderstam

4 12

[Boost][GSoC] Checks summary
by Pierre Talbot 07 Sep '11

07 Sep '11

Hello all, The Google summer of code gave me the opportunity to learn a lot, but overall I started to build another little part of the open-source world. This was a great experience for me. I'd like to thank my mentor, Paul A. Bristow for all the help he bestowed, Google and all the Boost members who gave me their opinions or advice. During this summer, I've started to build the foundation of a new library. It's only a prototype for the time being but I hope make it useful and powerful soon. The name of this library is "Checks", it currently implements one kind of check function: those used for catching human errors. For example, the famous ISBN has a check digit computed with all the characters. It exists few algorithms and a lot of number are based on well-known algorithm. This library should offer useful extending possibilities because there are so many that we can't implement every type of checks for a Boost library. I've implemented and written the following contents : * Basic check algorithms ( Luhn, Mod11, Verhoeff, ...). * Start to write a test suite that should facilitate the measurement of efficiency of the check algorithms (number of alterations, transposition, ... detected). * Write some sanity tests for the functions implemented (using Boot.Test). * Documented the functions already written and start a "global" documentation of the parameters that affect the efficiency of each algorithms. This library is absolutely not finished but can be used for simple verification or computation of check digit. I would like to improve and even-fuller-document this library before a Boost review. The code, tests and documentation can be found at https://svn.boost.org/svn/boost/sandbox/SOC/2011/checks/ and here are a direct links to the documentation in html https://svn.boost.org/svn/boost/sandbox/SOC/2011/checks/libs/checks/doc/htm… and as a single pdf file https://svn.boost.org/svn/boost/sandbox/SOC/2011/checks/libs/checks/doc/che… (Sadly the Doxygen comments documenting the (many) template parameters are not displayed correctly in the C++ reference section (due to a buglet in the toolchain), so for now you may need to consult the header files to read the C++/Doxygen \tparam comments. Meanwhile, you can also consult the Standalone Doxygen documentation at https://svn.boost.org/svn/boost/sandbox/SOC/2011/checks/libs/checks/doc/dox… Or you can rebuild the Standalone Doxygen documentation using the Doxywizard and https://svn.boost.org/svn/boost/sandbox/SOC/2011/checks/libs/checks/doc/dox… If you have any comments or suggestions, please do not hesitate to contact me. Cordially, Pierre Talbot.

1 0

Re: [boost] [interest] URL (John Ratcliffe)
by john＠firecrest.eclipse.co.uk 07 Sep '11

07 Sep '11

From: Dean Michael Berris Date: Tue, 6 Sep 2011 22:34:19 +1000 > This project (cpp-netlib) is already submitted for review to Boost, > but is still under heavy development. I've already had some offline > arrangements for a review manager, but now it's a matter of scheduling > for when the formal review should be held. > Needless to say it follows much of the Boost conventions and rely > mostly entirely on Boost libraries. And if I'm brave enough I just > might think about submitting the library interfaces to the ISO C++ > Committee through the Library Working Group. :D > I hope this clarifies things. Yes thanks. I noticed the boost namespace and wondered. It looks and sounds well advanced. I would like to get involved but is there anything a new hand can contribute at this stage? Cheers John Links: ------ [1] mailto:mikhailberis@gmail.com

2 1

Intel TBB or Microsoft PPL like Boost library
by Brendon Costa 07 Sep '11

07 Sep '11

Are there any libraries for boost proposed, accepted or in progress that are similar to the Intel Threaded Building Blocks library or the Microsoft Parallel Patterns Library? I did not see any in the official library list and dont remember hearing about any in this mailing list. Such a library could be very useful (well I could use it right now :-) )

2 1

Re: [boost] [Submission] RawMemory
by Joe Mucchiello 07 Sep '11

07 Sep '11

For a library designed to deal with the weirdness of binary file formats, I'm surprised it does not support 24-bit integers of arbitrary alignment/sign. > uint32_t x = raw_memory <uint32_t, big_endian>::peek (&vbBuffer [5]); Do you also support a non-template "endianness" parameter? Sometimes you don't know the endian-style of the file until you open it and read some value out of it. Joe

1 0

[chrono] Build Jamfile missing three source files
by Beman Dawes 06 Sep '11

06 Sep '11

--- c:\temp\Jamfile.v2-revBASE.svn000.tmp.v2 2011-09-06 15:23:30.000000000 -0400 +++ c:\boost\trunk\libs\chrono\build\Jamfile.v2 2011-09-06 15:23:19.000000000 -0400 @@ -74,16 +74,16 @@ <toolset>gcc-3.4.4:<linkflags>--enable-auto-import <toolset>gcc-4.3.4:<linkflags>--enable-auto-import <toolset>gcc-mingw-4.4.0:<linkflags>--enable-auto-import <toolset>gcc-mingw-4.5.0:<linkflags>--enable-auto-import ; -SOURCES = chrono thread_clock process_cpu_clocks ; +SOURCES = chrono thread_clock process_cpu_clocks run_timer run_timer_static process_clock ; lib boost_chrono : $(SOURCES).cpp : <link>shared:<define>BOOST_ALL_DYN_LINK=1 # tell source we're building dll's <link>static:<define>BOOST_All_STATIC_LINK=1 # tell source we're building static lib's ; OK to commit? --Beman

2 3

Re: [boost] [contract] syntax redesign
by Andrzej Krzemienski 06 Sep '11

06 Sep '11

> This use case is different then the above (more compelling). The > issues here is that when programming contracts you quickly start using > extra checks (and especially ==) which add additional requirements on > generic types. For example, in this case T does not have to be > EqualityComparable to program the body but you still want to program > and check the postcondition when T happens to be EqualityComparable. I > have been thinking to solve this issue by providing: > namespace contract { > temlate< typename T> > bool equal(T const& left, T const& right) ... > } > equal will return true if T is not EqualityComparable and left == > right if T is EqualityComparable. That way you can program the > contracts using contract::equal(x, y) without introducing additional > requirements on T at all but still checking the contract conditions > for EqualityComparable types. I will also expand equal to handle > containers (compare all elements of a vector, etc) and I will provide > similar functions for other operations. All of these contract helper > functions will be in a separate header <contract/utility.hpp>. I have > not started to implement this yet. To me, this problem with equality indicates that Boost.Concept already proves useful, as it explores practical aspects of implementing DbC in C++ and its interactions with other C++ features. > BTW, I am also wondering if it would be useful to implement a fully > contracted version of the STL probably in contract::std: > #include <contract/std/vector.hpp> > #include <contract/std/algorithm.hpp> > contract::std::vector<int> v; > contract::std::for_each(v.begin(), v.end(), ...); > I think Boost.Contract can essentially implement most/all of the > interface contracts (preconditions, postconditions, invariants, and > concepts) documented by the SGI: > http://www.sgi.com/tech/stl/<http://www.google.com/url?sa=D&q=http://www.sgi.com/tech/stl/&usg=AFQjCNHIn…> > Would such a contract::std be any useful? This is a fair question. And probably best answered by the authors of contract programming proposal for C++. What ISO C++ Committee did with nearly every new language feature (concepts, auto, noexcept, constexpr, initializer_list) was to also use it in library in order to (i) prove that the future is usable, (ii) give a solid example of how the feature should be used. So, along this reasoning, there are good reasons to do it. I can see, however, also valid reasons against it: Boost only recently approved STL containers library rewrite: Boost.Containers ( http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h…) It already has Boost.PointerContainer (although it serves a different purpose it may be distracting that they are defined and described separately). so now, each time I use a container I will have to decide if I am using std::vector or boost::container::vector. Now if I need to consider a third option boost::contract::stl::vector it really gets hard. And would they all interoperable with one another? Perhaps if the contracts were implemented in Boost.Container, but then... I expect that Boost.Contract syntax may discourage some Boost users, that just want to use (and perhaps debug) Container library. Overwhelming them with the new syntax might discourage them from using Boost.Container. If you implement your containers separately, it is likely that they will just not be used. Difficult to say... Regards, &rzej

2 1

Re: [boost] [interest] URL
by john＠firecrest.eclipse.co.uk 06 Sep '11

06 Sep '11

Hi Glyn Date: Mon, 5 Sep 2011 10:14:28 +0200 From: Glyn Matthews On 4 September 2011 21:36, John Ratcliffe wrote: > Is there any interest in a URL library along the lines of the Java one? > > http://download.oracle.com/**javase/1.5.0/docs/api/java/**net/URL.html [3] > > I'm currently working on a URI class as part of the cpp-netlib project: https://github.com/cpp-netlib [4] The parser already implements RFC 2396 and RFC 2732. There is still a lot of work to be done and, if you're interested, we'd be happy to accept contributions. Thanks for the response. I took a quick look and I am interested. I will take a closer look. What areas need attention? How does this project relate to boost? John Links: ------ [1] mailto:glyn.matthews@gmail.com [2] mailto:john@firecrest.eclipse.co.uk [3] http://download.oracle.com/**javase/1.5.0/docs/api/java/**net/URL.html%3Cht… [4] https://github.com/cpp-netlib

2 1

[Submission] RawMemory
by Adder 06 Sep '11

06 Sep '11

Dear Boost Community, I would like to submit a very modest addition to Boost... It is called "RawMemory": http://adder.iworks.ro/Boost/RawMemory/ <<It supports safe, efficient and portable (all in one) transfer of multi-byte integer values to/from "untyped memory" (also known as "arrays of bytes") (also known as "raw memory"). It handles the little endian and big endian representations and various memory transfer modes (e.g. to support aligned and unaligned data with good performance). Therefore, it can be useful to any application dealing with binary data formats (e.g.: bitmap images, network packets, serialized data structures).>> Thank you so... (-: -- Yours truly, Adder

3 3

painless currying
by Eric Niebler 06 Sep '11

06 Sep '11

After playing around with functional languages, I've come to envy how easy they make it to curry functions. Call a 2-argument function with 1 argument and you get a function that takes 1 argument. Pass another argument and it evaluates the function. Simple. In contrast, C++ users have to use binders, which are not as nice. On a lark, I implemented a wrapper that turns any TR1-style function object into a "curryable" function object (attached). Successive function call invocations bind arguments until enough arguments are bound to invoke the wrapped function. With it you can do the following: curryable<std::plus<int> > p; auto curried = p(1); int i = curried(2); assert(i == 3); Is there any interest in such a thing? -- Eric Niebler BoostPro Computing http://www.boostpro.com

26 93

[serialization] between 32 bit and 64 bit
by Jinqiang Zhang 06 Sep '11

06 Sep '11

I'm using boost.serialization for part of our messaging solution. Now here comes a problem: we want to communicate between 32bit and 64bit, is there a chance that using "text archive" would solve the problem ? jinqiang Zhang

3 3

[endian] comments
by Gordon Woodhull 05 Sep '11

05 Sep '11

Hi Beman, all, Couple of comments after scanning the documentation. It does look like a solid library but the Hello World example in the documentation appears to be out of synch with the code, and with Boost. None of its includes are correct (except iostream). It looks like the operator<= overloading (?) is intended to invoke some binary stream functionality which isn't yet in Boost. Unfortunately I wasn't able to get it to compile because I couldn't find <boost/binary_stream.hpp> anywhere. There appears to be some related detail::binary_data stuff in endian/boost/io/detail/bin_manip.hpp but I couldn't figure out how to connect it. An unrelated comment: on the "conversion functions" page of the documentation, there are some references to "indicated byte ordering" - which confuses me because I don't see where the byte ordering is indicated. Does this mean the ordering which Endian uses internally? Cheers, Gordon

2 1

[variant] Constructible/assignable from anything
by Agustín K-ballo Bergé 05 Sep '11

05 Sep '11

Boost variant has a constructor and an assignment operator that would take just anything. If it cannot be converted to any of its bounded types, it will result in an error within variant's internals. This, mixed with conversion operators, interferes with overload resolution (code that reproduces the issue attached). Would SFINAE'ing out the non-candidate constructors (and assignments) fix this? Agustín K-ballo Bergé.- http://talesofcpp.blogspot.com

2 2

[interest] URL
by John Ratcliffe 05 Sep '11

05 Sep '11

Is there any interest in a URL library along the lines of the Java one? http://download.oracle.com/javase/1.5.0/docs/api/java/net/URL.html John Ratcliffe

2 1

[review] Conversion review starts today
by Gordon Woodhull 04 Sep '11

04 Sep '11

Hi All, The review of Vicente Botet Escriba's Conversion library starts today and ends August 29. The Conversion library manages generic explicit conversion between unrelated types. It can be thought of as a substitute for overloading static_cast, or as an alternative to lexical_cast when conversion via text is unwanted. The code is available here: http://svn.boost.org/svn/boost/sandbox/conversion/ And the documentation is here: http://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/h… Alternately, you can download a compressed package here: https://github.com/viboes/TBoost.Conversion Reviews may answer the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Of course, "informal reviews" and discussion are also welcome. Cheers, Gordon Woodhull Espen Harlinn

6 12

[serialization] deserializing asynchronously serialized types
by Andrew Hundt 04 Sep '11

04 Sep '11

I have an unusual use case for boost.serialization, and I was wondering if it would be possible to adapt it to my needs: - I have a set of over 100 types, and instances of each are generated asynchronously then serialized to a file in that order. - The most interesting serialized data will be written just before the power is unexpectedly cut. - I need to load in and run on as much data as possible when reading the serialized data back, ignoring incomplete data at the end (due to a power cut). - The basic Boost serialization examples require you to know the type of the next piece of data to be loaded when reading. Since these types are generated asynchronously they are not known in advance. - I need to write the data out immediately when it arrives because of the power issue. - Files will be getting up to around 150GB in size for binary archives, so it can't be marshaled in memory, it needs to be written immediately even if it is redundant. Is there a way to read in that serialized file using the facilities provided in boost.serialization? Here are my current ideas: - I tried using boost.variant, but it loses its will to compile when I increase the typelist limit to around ~60 types on gcc 4.4, and I have more than a hundred. - Use preprocessor metaprogramming to do something equivalent to boost.variant, but I would very much prefer a more pleasant option. - Serialize an index or custom headers indicating the next type to appear - One way of achieving some of these goals is writing one piece at a time using a binary archive to an fstream, with the index mentioned above separating data types. I don't know what aspects of my requirements will prove to be a problem, so if anyone can provide advice that would help me avoid a major pitfall, it would be greatly appreciated. Thanks for your thoughts. Cheers! Andrew Hundt

2 1

[conversion] review
by Gordon Woodhull 03 Sep '11

03 Sep '11

Hi all, Here is my review of the Conversion library. I like the idea of a uniform configurable casting operator, whether it's called convert_to, static_cast, convert_cast, or extrinsic_cast. If I had to write a conversion function, I would rather write it as an overload of a general-purpose converter, rather than giving it some ugly typeA2TypeB name. And I would rather find out what header to include and use a generic function rather than using such some specific name. I vote to accept the library (although obviously as Review Manager I'll follow the wishes of all reviewers). Part of the reason I took on the challenge of managing this review is that the library is something people don't know they need. I think uniformity of interface is a good enough reason to use the library, but when would you need a truly generic conversion function as this library offers? Or more to the point, what does it mean to have a "shadow conversion space" for types that don't know about each other? We would hope that libraries are generic enough so that their types can be adapted to work with each other (prime example: Polygon & Geometry). But it's the sad truth that most libraries are not designed this way, and any non-header library can't be designed this way. So that's where Conversion steps in to make combining those libraries cleaner. As we've already discussed, the Achille's Heel of this library is that it requires all compilation units to agree on what conversions they will use, to avoid ODR violations. In practice this probably means that users would have to maintain their own conversion setup headers, which is annoying. But it's hard to imagine an openly configurable global utility that doesn't suffer from some version of this problem. John Bytheway's suggestion of tagging libraries with type keys is an interesting idea. I think Vicente also mentioned the possibility of a scheme that would cause linker errors instead of ODR violations, which would be an improvement. (FWIW I suggested something involving #error but of course that would only work within a CU.) In my mind it is very clear that a templated function<T>(x) will probably return a T and I don't find it necessary that the proposed function has to use the preposition "to". But that's because I'm very aware that the explicit template argument must be the return type, which is understandably not clear to everyone. While the recursive features of this library look interesting and useful, I wonder if there isn't a more general way to do this. I keep thinking it's an awful lot like fusion::copy or Marsden's Traversals. Well, that's enough for now. I hope later today to post summaries of some comments I received off-list and maybe get those people to join the conversion. (You know who you are!) Cheers, Gordon

7 16

[type traits] Extension to operator detection -> choose your preferred naming
by Frédéric Bron 03 Sep '11

03 Sep '11

It is time to include the type trait extension to the official boost trunk. These traits can detect if you can use a given operator with given arguments. For example: has_plus<double, int>::value is true because the following program compiles without error: double lhs; int rhs; lhs+rhs; We have come to three proposed lists of names (A, B and C): https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames I have included the corresponding names of standard keywords, standard function objects from <functional>, boost Proto and boost Operators. Please give your preference between A, B and C before Sept. 5th. Regards, Frédéric

15 17

[preprocessor]BOOST_PP_CHECK_2 with wrong number args
by Larry Evans 02 Sep '11

02 Sep '11

boost/preprocessor/detail/check.hpp in boost version 1.47.0 contains: # if ~BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MSVC() && ~BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_DMC() # define BOOST_PP_CHECK_D(x, type) BOOST_PP_CHECK_1(BOOST_PP_CAT(BOOST_PP_CHECK_RESULT_, type x)) # define BOOST_PP_CHECK_1(chk) BOOST_PP_CHECK_2(chk) # define BOOST_PP_CHECK_2(res, _) res # elif BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MSVC() The above shows BOOST_PP_CHECK_2 is called with 1 argument on rhs of BOOST_CHECK_1; yet, the arity is 2, as shown on the next line. This results in the errors reported here: http://article.gmane.org/gmane.comp.lib.boost.devel/222795 when that line is changed to: # define BOOST_PP_CHECK_1(chk) BOOST_PP_CHECK_2(chk,_) the reported error goes away; however, several other errors occur about too many instead of too few arguments passed to BOOST_PP_CHECK_2. Is this a BOOST_PP bug? If not; how can the errors reported in: http://article.gmane.org/gmane.comp.lib.boost.devel/222795 be avoided? TIA. -regards, Larry

2 8

[Boost.serialization] - Json Serialization (Marshalling and unmarshalling)
by Demetrio Car 02 Sep '11

02 Sep '11

I need some example of how to serialize/deserilize from Json format to Object and from Object to Json. I used this example http://www.boost.org/doc/libs/1_47_0/libs/serialization/doc/index.html, but it only serialize to a simple text. In my project, for other requirenments, I am using boost library with success. I am almost sure that I do need some other specific library like Json-Spirit or standard QT library (QScriptEngine). Any simple example will be very appreciate. This is an example of the Json files I must serialized to a class. [{"DscTipoEstrutura":"Unidade de Neg\u00f3cio","FlgAtivo":true,"IdDominio":1,"IdTipoEstrutura":1,"NroOrdem":0},{"DscTipoEstrutura":"Regi\u00e3o","FlgAtivo":true,"IdDominio":1,"IdTipoEstrutura":2,"NroOrdem":1},{"DscTipoEstrutura":"Distrito","FlgAtivo":true,"IdDominio":1,"IdTipoEstrutura":3,"NroOrdem":2}] Ps.: I found http://www.codeproject.com/KB/recipes/JSON_Spirit.aspx and http://boost-spirit.com/repository/applications/show_contents.php similiar to I need but, because I am C++ begnnier, I couldn't understand them neither run the example after some couple of hours. I need some simple example.

1 0

Acknowledgement for Certs 4 Less
by Dave Abrahams 02 Sep '11

02 Sep '11

All--- For some time now, Boost has been using the CA-signed wildcard SSL certificate that was very generously donated by Certs 4 Less. I promised them, in return, that Boost would acknowledge them on our website, as we have done in the past for other donors. We acquired the certificate so we could accept e-payments for BoostCon, but in the end we decided to pay EventBrite to take payments for us... so as far as I know, the cert is only being used at the moment for https://svn.boost.org Two questions: 1. Where does the acknowledgement belong? 2. Can someone who knows how put it there? P.S. I would be very happy not to get separate answers to those, if someone who knows how to edit the website *and* an appropriate placement for the acknowledgement could just take care of it ;-) Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

4 6

Version 10 of Boost.Algorithm available
by Marshall Clow 02 Sep '11

02 Sep '11

Changes since -009 * Predicate versions of the search functions have been removed. * Search functions now work for raw pointers * Now use tr1/unordered_map everywhere - this should make (most versions) of gcc happy. * Now including <climits> in search.hpp, which defines CHAR_BIT. * Fixed a bug in boyer_moore::create_suffix_table, which caused the search to fail sometimes. * The skip table is now templated on the value_type being searched on, rather than the iterator type. * Documentation has been updated (more to come here) Thanks to Mikhail Levin, TONGARI, and Sebastian for bug reports. Since the vault is gone, I've put the code here: http://dl.dropbox.com/u/11048326/Boost.Algorithm-010.zip -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

2 1

[review] conversion - Kevlin's comments
by Gordon Woodhull 02 Sep '11

02 Sep '11

Hi Vicente, all - I got this comment from Kevlin Henney, author of lexical_cast: On Sep 1, 2011, at 11:45 AM, Kevlin Henney <kevlin(a)curbralan.com> wrote: > I was looking through the docs and they seem to offer a solution to a common family of conversion problems. Based on casual reading, it feels a little more complex and requires a higher-entry level of knowledge than would be appropriate for many of the people who actually need this functionality. These are initial impressions only, so don't read too much into them. The eternal battle between power and simplicity. :-) Cheers, Gordon

2 2

[proto] Can't use functions in expressions?
by John Maddock 02 Sep '11

02 Sep '11

So.... I have a function that returns an expression template of proto::tag::function type, like so: template <class Exp>\ typename proto::result_of::make_expr<\ proto::tag::function\ , detail::BOOST_JOIN(func, _funct)<typename detail::backend_type<Exp>::type>\ , detail::big_number_exp<Exp>\ >::type const \ func(const detail::big_number_exp<Exp>& arg)\ {\ return proto::make_expr<proto::tag::function>(\ detail::BOOST_JOIN(func, _funct)<typename detail::backend_type<Exp>::type>() \ , arg \ );\ }\ and it all works fine, until I try and use the result of such a function call in an expression: sqrt(arg) + arg yeilds: 1>m:\data\boost\sandbox\big_number\libs\math\ide\extended_real\scrap\scrap.cpp(25): error C2893: Failed to specialize function template 'const boost::proto::detail::enable_binary<boost::proto::domainns_::deduce_domain,boost::proto::detail::not_a_grammar,boost::mpl::or_<boost::proto::is_extension<T>,boost::proto::is_extension<Right>>,boost::proto::tag::plus,const Left,const Right>::type boost::proto::exprns_::operator +(const Left &,const Right &)' 1> With the following template arguments: 1> 'boost::math::detail::big_number_exp<Expr>' 1> with 1> [ 1> Expr=boost::proto::exprns_::basic_expr<boost::proto::tag::function,boost::proto::argsns_::list2<boost::math::detail::big_number_exp<boost::proto::exprns_::basic_expr<boost::proto::tag::terminal,boost::proto::argsns_::term<boost::math::detail::sqrt_funct<boost::math::mpfr_real_backend<50>>>,0>>,boost::math::detail::big_number_exp<boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<boost::math::big_number<boost::math::mpfr_real_backend<50>> *>,0>>>,2> 1> ] 1> 'boost::math::mpfr_real_50' So I figured I needed to update my grammar, so I tried adding this case: template<> struct big_number_grammar_cases::case_<proto::tag::function> : proto::function< proto::_ > {}; But still no joy (same error message). Any ideas on what I'm doing wrong? BTW I couldn't find any examples of using proto::function in a grammar, it wasn't obvious to me what it's template arguments should be, or indeed whether this actually enabled the function call operator rather than my use case? Thanks, John.

4 6

Basic boost::mpl::max_element question.
by Yves Dolce 02 Sep '11

02 Sep '11

Hi everyone, Once past the basic understanding of C++ metaprogramming (factorial, vector/typeslist, .), I must confess I have a hard time using max_element in my particular scenario. And I have not found a lot of samples on the net. Consider this "repro" first: template <unsigned char L> struct Level { static const unsigned char value = L; }; template <class LEVEL> struct CTA { typedef LEVEL Level_t; }; typedef boost::fusion::vector<CTA1, CTA2, CTA3, CTA4> CTAS; Now, using max_element, I'd like to pick the one CTAn for which CTn::Level_t::value is the biggest. Can you enlighten me? Thanks! An MPL/FUSION beginner. J

2 1

[TypeTraits] A patch for clang's intrinsics (was: [type_traits] is_enum on scoped enums doesn't works as expected)
by Michel MORIN 01 Sep '11

01 Sep '11

John Maddock wrote: >> Boost.TypeTraits does not use intrinsics for clang yet. >> (c.f. https://svn.boost.org/trac/boost/changeset/72725) >> >> >> this explains why it is not working now. Is someone working on this issue? > > Not me, we need a Clang expert to look into it - or at least someone with > access to Clang to take care of the testing - someone did submit a patch to > enable intrinsic support for Clang, but it broke more things than it fixed > so it got reverted :-( Let's proceed step by step. As a first step, I made a patch to use clang's intrinsics except problematic intrinsics (i.e. `is_pod` and `is_empty`). All the tests run successfully on gcc-4.4, 4.5, 4.6, clang (trunk) and Mac OS X Lion's clang (Apple clang version 2.1). Regards, Michel

4 7

Re: [boost] [any] new version
by Martin Bidlingmaier 01 Sep '11

01 Sep '11

> Mathias Gaunard wrote: >> You could make next_id a function with weak extern linkage, which should >> be able to make it work. Thanks for the replies, I hope I fixed the linkage problems now, by making next_id() inline. There were other linker related issues, which are hopefully fixed now as well. The modified any.hpp header and a simple linker test are attached -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

2 2

[shared_ptr] Implicit 2 phase construction with enable_shared_from_this
by Sebastian Karlsson 01 Sep '11

01 Sep '11

There's been some discussion about solving the problem with shared_from_this() not being available in the constructor. This is fairly natural as shared_ptr ownership doesn't happen until after the constructor leaves, and we're not even guaranteed that the object enters shared_ptr ownership at all. What I'm suggesting is the addition of a private void enable_shared_from_this<T>::accepted_shared_ptr() {}. Then inside enable_shared_from_this<T>::_internal_accept_owner we add: const_cast< T* >( static_cast< const T* >( this ) )->accepted_shared_ptr(); Just beneath: weak_this_ = shared_ptr<T>( *ppx, py ); This allows clients of enable_shared_from_this to add their own accepted_shared_ptr() which will correctly be called while I believe not breaking any old code. I just added the const_cast because I'm not familiar with the rationale behind _internal_accept_owner being const. This change nets us: 1 ) Generic code dealing with construction of shared_ptrs ( in any of its forms ) does not need to bother themselves with 2 phase construction. 2 ) The distinction between construction & transfer of ownership to shared_ptr makes it easier to cope with both the case where T is not managed by a shared_ptr and the case where it is. One gotcha I've found is that for example: struct foo : enable_shared_from_this< foo > { foo() { boost::shared_ptr< foo > tmp( this, null_deleter() ); } // We might be allocated on the stack, so use a null_deleter for now void accepted_shared_ptr() { /* here we can patch it up with shared_from_this(), which will use our assigned deletion strategy */ } } Does not behave as one would want to. Basically in this case I'd want to use a shared_ptr<> which makes no assumptions about whether we're managed by a shared_ptr or not, we want a shared_ptr which acts as a plain pointer. The problem however is that the shared_ptr which we construct with the null_deleter will grab the enable_shared_from_this before even construction is complete. This can be solved by the following, as seen in boost::make_shared: ... boost::shared_ptr< foo > empty_with_deleter( static_cast< foo* >( 0 ), null_deleter() ); boost::shared_ptr< foo > tmp( empty_with_deleter, this ); // This one is safe to use ... Which doesn't enter boost::detail::sp_enable_shared_from_this. Would love some input from someone a bit more knowledgeable about shared_ptr. Kind regards, Sebastian Karlsson

1 0

[review] Conversion - About specialization, overloading and ODR
by Vicente J. Botet Escriba 01 Sep '11

01 Sep '11

Hi, during the Boost.Conversion review and pre-review it has been argued that as the user must provide specializations of the conversion function for other UDT's, it could promotr ODR violations as two independent libraries can provide the same specialization making them incompatible for an end user. This issue is present for any library for which the user could provide an overload or could specialize a class. The standard library protects itself from this issue saying that is undefined behavior any specializations of standard classes (except maybe numeric_traits that has a single parameters and it is intendeed to be specialized by the library providing the UDT). My question is: Should Boost (all the Boost libraries) document explicitly that any class specialization or overload of free fuctions could result in undefined behavior? Is this already implicitly acknowledged? Best, Vicente

3 7

[review] Conversion review ends today
by Gordon Woodhull 01 Sep '11

01 Sep '11

Folks, The review of Vicente's Conversion library ends today. Unfortunately there have only been four reviews, which is hardly enough to provide proper feedback. If you've considered writing a review or if you have any thoughts about the topic, please speak up now. Or if you'd like to submit a late review, just let me know. Thanks, Gordon

5 19

[boost/property_tree/json_parser] - Consuming a Json file returning from rest web service
by Demetrio Car 31 Aug '11

31 Aug '11

> > Could someone send me an example of how to use json_parser to read a Json > file? I will need to consume a Rest web service developed in Rails. This web > service will respond to my code using json, in other words, from my C++ code > running over linux I will access an url which will return to me a file in > Json format. The main point is: how do I access the url > http://my_gienah:3000/dominios/dominiosAll.json<http://gienah:3000/dominios/dominiosAll.json> or > the url > http://my_gienah:3000/Tipoestruturas/ObtemTipoEstrutura_IdDominio/1.json<http://gienah:3000/Tipoestruturas/ObtemTipoEstrutura_IdDominio/1.json> .In > the last url, I must set parameters. The return is something like this: > > [{"DscDominio":"Johnson Argentina"},{"DscDominio":"Johnson Brasil"},{"DscDominio":"Farmoqu\u00edmica"},{"DscDominio":"Dom\u00ednio Inativo"},{"DscDominio":"NIKKHO"},{"DscDominio":"teste"},{"DscDominio":"Dominio"},{"DscDominio":"teste"},{"DscDominio":"teste"},{"DscDominio":"Teste"},{"DscDominio":"Teste"},{"DscDominio":"Dom"},{"DscDominio":"teste"},{"DscDominio":"teste"},{"DscDominio":"Teste"},{"DscDominio":"descricao"},{"DscDominio":"DesccricaoTeste"},{"DscDominio":"teste"},{"DscDominio":"teste p"},{"DscDominio":"teste p 2"},{"DscDominio":"teste p 3"},{"DscDominio":"Teste Dominio Produto x"},{"DscDominio":"Teste Dominio Produto x"},{"DscDominio":"Teste Dominio Produto x"},{"DscDominio":"Dominio Produto 123"},{"DscDominio":"subdom2"},{"DscDominio":"teste"},{"DscDominio":"2"},{"DscDominio":"3d"},{"DscDominio":"X"}] > >

2 1

[review] conversion - Vladimir's comments
by Gordon Woodhull 31 Aug '11

31 Aug '11

Hi Vicente, all, I had hoped that Vladimir Batov, author of Boost.Convert reviewed earlier this year, would contribute an "informal review". Instead I hope he doesn't mind if I quote some correspondence he sent off-list, and perhaps get him to join us. (I normally would never quote off-list communication on-list, but I don't see how a review manager can use off-list contributions without quoting them, if there's no request for anonymity. I hope Vladimir agrees that I've been judicious. ;) On Aug 1, 2011, at 8:47 PM, Vladimir Batov wrote: > On the conceptual level it is far from clear to me if such a framework is needed to begin with. In the Scope section Vicente explicitly states that his library "is not particularly concerned with cases of...". Those "excluded" cases happen to be the most tricky/used/needed cases. With those string-to-type, etc. cases taken out of the picture from the set-go, the usefulness of the remainder was many times questioned during Convert discussions (well before the Convert review) ... I never had a need for such a generic type-to-type conversion framework. Obviously, it's my own limited experience and it can be vastly different for others. > Secondly, on the implementation level I raised a few concerns in our conversations with Vicente about his library ... I do not feel Vicente's implementation is sufficiently generic. In particular, I am under strong impression that having Target and Source together as in > > template< class Target, class Source > > Target explicit_convert_to( Source const & u ); > > does not really work on a bigger scale. That does indeed work for *concrete* Target and Source types. However, when one tries to generalize (partially specialize) for a range of similar types, then I feel the framework easily falters. Namely, if I decide to specialize the above for a range of related Target types (say, string-related types) *and* separately specialize for a range of related Source types. Then compilation will fail if these two separate specializations happen to overlap for some Target-Source pair. That is not an academic case but concrete issues I faced with Convert. I'd expect it to be as relevant with Vicente's library. I agree that it will take some careful shepherding to define a set of conversions without ambiguous overloads, which might be tricky to avoid if you're working with converters written by other people. Vicente, do you have any solutions for this? Cheers, Gordon

5 10

interprocess locks and move semantics compile problem [SEC=UNCLASSIFIED]
by Levy, Gabriel (Contractor) 31 Aug '11

31 Aug '11

UNCLASSIFIED Hi all, I'm having a problem getting this trivial couple of statements compile on VC9 SP1 (VS2008), specifically the "move" emulation. The sanitised snippet looks like this: using namespace boost::interprocess; interprocess_upgradable_mutex mMtx; sharable_lock<interprocess_upgradable_mutex> sherLock(mMtx); upgradable_lock<interprocess_upgradable_mutex> upgLock(move(sherLock)); The error message I'm getting is (nothing more, nothing less): 1>d:\experimental\notificationcentre.cpp(632) : error C2664: 'boost::interprocess::upgradable_lock<UpgradableMutex>::upgradable_lock( boost::interprocess::scoped_lock<Mutex> &)' : cannot convert parameter 1 from 'boost::interprocess::rv<T>' to 'boost::interprocess::scoped_lock<Mutex> &' 1> with 1> [ 1> UpgradableMutex=boost::interprocess::interprocess_upgradable_mutex, 1> Mutex=boost::interprocess::interprocess_upgradable_mutex 1> ] 1> and 1> [ 1> T=boost::interprocess::sharable_lock<boost::interprocess::interprocess_u pgradable_mutex> 1> ] 1> and 1> [ 1> Mutex=boost::interprocess::interprocess_upgradable_mutex 1> ] Strangely the compiler thinks that the best fit for the constructor overload (with the "move") is the one with "scoped_lock" parameter type instead of the "sharable_lock" version of it. The same is the problem combining lock's move across the other types (up or down grading the type of lock) I must be missing something since I can't see anyone else experiencing this problem. Could anyone advise and shad some light as to why the "move" doesn't work for me on the original interprocess locks? Thanks in advance for any help. Gabe Gabe Levy Senior Software Engineer, HiQ Systems Pty Ltd IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email.

1 0

[Conversion] Review
by Antony Polukhin 30 Aug '11

30 Aug '11

First of all, there is already a Boost.Conversion library (released in 1.20.0). Users will be confused, because two libraries have same names. * What is your evaluation of the design? It is simple and looks good. But consider the following situation: lexical_cast<char>(1) and numeric_cast<char>(1) will produce output. It must be documented, which cast will your library use in which cases. There must be some tags, to allow user to choose, which conversion is required. There are some dummy::type_tag tags in source code, but looks like they are not used, and not documented! * What is your evaluation of the implementation? Did not look very carefully trough the sources. * What is your evaluation of the documentation? There is no documentation about which conversion when used. convert_to<char>(1) will call numeric_cast or lexical_cast? * What is your evaluation of the potential usefulness of the library? Usually user just want to use lexical_cast or numeric_cast. Situations, when generic conversion is required are less often. * Did you try to use the library? With what compiler? Did you have any problems? I did not used it. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A quick reading. * Are you knowledgeable about the problem domain? I am knowledgeable about lexical conversions domain. Generic conversions are close enough to that domain. * Do you think the library should be accepted as a Boost library? Yes, it should. But only after the documentation will be updated and tags added. Until then, it is not clear which cast is when used and library is not as generic as possible. But such big changes to library design will require some new short review.

3 5

[Feedback] Towards a Better Boost.BloomFilter
by Alejandro Cabrera 30 Aug '11

30 Aug '11

Hello all, The GSoC coding period is over. However, I have every intent to continue to develop, improve, and maintain the Boost.BloomFilter package. Your feedback last time around was very useful, and made me think very carefully about the operations supported by each Bloom filter variant implemented. Thank you. Now, I could use feedback on at least the following aspects: - Are all the operations you need implemented by Boost.BloomFilter? Serialization support is still missing, though at least now it is possible to access the underlying storage for each structure implemented through the data() member function. - Are there are any particular variants you'd like to see implemented sooner? I've gathered together most Bloom filter literature on the bibliography page: http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/libs/bloom_filter… http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/libs/bloom_filter… (Note: twohash_ Bloom filters have been implemented.) - There is much talk of C++11 as of late on the mailing list: do you see anywhere in the implementation where taking advantage of C++11 features may produce a better Bloom filter package? - Regarding compiler support, this Bloom filter has been tested on several compiler suites (gcc-4.6, gcc-4.6 -std=c++0x, clang-2.9, clang-2.9-darwin), but has been primarily developed on Linux. Does the test suite compile and pass on your target compiler? My goal is to produce a review-ready Bloom filter library by the end of the year. Any feedback helps. Thank you for your time! A few links: - repository trunk: http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/ http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/ - documentation: http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/libs/bloom_filter… http://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/libs/bloom_filter… Cheers, -Alejandro Cabrera -- View this message in context: http://boost.2283326.n4.nabble.com/Feedback-Towards-a-Better-Boost-BloomFil… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 6

miscompilation: boost.mpi, gcc 4.6 and c++0x
by Christophe Prud'homme 30 Aug '11

30 Aug '11

Dear Boost Developers I created the ticket [1] several month ago regarding an issue between g++-4.6 with option -std=c++0x and boost.mpi I haven't had any feedback yet. Any idea wether boost or gcc is at fault here ? it is easy to fix this by adding the right member function. 1. https://svn.boost.org/trac/boost/ticket/5538 let me recap what is going on consider the following code in t.cpp: #include <boost/mpi.hpp> compile it with g++ -std=c++0x -c -I/usr/include/mpi t.cpp and you get in Debian unstable In file included from /usr/include/c++/4.6/memory:67:0, from /usr/include/boost/mpi/allocator.hpp:18, from /usr/include/boost/mpi.hpp:22, from t.cpp:1: /usr/include/c++/4.6/bits/stl_uninitialized.h: In function 'void std::__uninitialized_default_n_a(_ForwardIterator, _Size, _Allocator&) [with _ForwardIterator = char*, _Size = long unsigned int, _Allocator = boost::mpi::allocator<char>]': /usr/include/c++/4.6/bits/vector.tcc:474:8: instantiated from 'void std::vector<_Tp, _Alloc>::_M_default_append(std::vector<_Tp, _Alloc>::size_type) [with _Tp = char, _Alloc = boost::mpi::allocator<char>, std::vector<_Tp, _Alloc>::size_type = long unsigned int]' /usr/include/c++/4.6/bits/stl_vector.h:592:4: instantiated from 'void std::vector<_Tp, _Alloc>::resize(std::vector<_Tp, _Alloc>::size_type) [with _Tp = char, _Alloc = boost::mpi::allocator<char>, std::vector<_Tp, _Alloc>::size_type = long unsigned int]' /usr/include/boost/mpi/detail/packed_oprimitive.hpp:96:46: instantiated from here /usr/include/c++/4.6/bits/stl_uninitialized.h:576:6: error: no matching function for call to 'boost::mpi::allocator<char>::construct(char*)' /usr/include/c++/4.6/bits/stl_uninitialized.h:576:6: note: candidate is: /usr/include/boost/mpi/allocator.hpp:168:8: note: void boost::mpi::allocator<T>::construct(boost::mpi::allocator<T>::pointer, const T&) [with T = char, boost::mpi::allocator<T>::pointer = char*] /usr/include/boost/mpi/allocator.hpp:168:8: note: candidate expects 2 arguments, 1 provided note that if you remove -std=c++0x, it compiles fine. Best regards C. -- Debian Developer - member of Debian Science http://wiki.debian.org/DebianScience Prof. at Univ. Grenoble in Applied Math. http://ljk.imag.fr/membres/Christophe.Prudhomme/

2 1

[C++0x] ISO/IEC approves C++0x standard!
by Beman Dawes 30 Aug '11

30 Aug '11

The C++0x standard has been approved by ISO/IEC. The vote was unanimous; all 21 National Bodies voting were in favor. That means the dozen or so Boost libraries that were in TR1 are now part of the standard itself. Good work, Boosters! --Beman

10 12

BOOST_STRONG_TYPEDEF conflicting defs in 1.47
by Michael Goldshteyn 30 Aug '11

30 Aug '11

There seem to be conflicting definitions for the BOOST_STRONG_TYPEDEF macro: 11>e:\dev\devel\libs\boost\boost_1_47_0\boost\strong_typedef.hpp(45) : warning C4005: 'BOOST_STRONG_TYPEDEF' : macro redefinition 11> e:\dev\devel\libs\boost\boost_1_47_0\boost\serialization\strong_typedef.hpp(45) : see previous definition of 'BOOST_STRONG_TYPEDEF' They are slight different, but function identically (i.e., the one in serialization has an explicit default constructor call on the member variable t). Are both of these necessary, or should serialization just use the default one from the boost directory? Thanks, Michael Goldshteyn

2 2

[conversion] conversion domains
by Gordon Woodhull 30 Aug '11

30 Aug '11

Hi Vicente, all, I've been thinking a bit about Conversion's ODR problems and the annoyance of headers that customize something globally (using e.g. template specialization) when they are included. I think I would prefer a design that allowed to define sets of conversions, or conversion domains. When creating a converter, you would specify the list of conversions which you want. That way a conversion domain is specified in one place, and not because you #include something. Of course it also means there's no default domain, for better or worse. I tried a number of approaches but only found one way that would work. This uses function overloading over an inheritance chain of converter classes, each of which brings its parent's convert() function(s) into scope with 'using'. Yes, it is requires ugly, specific code to define a converter (and mpl::quoting the converters when specifying the domain yuk), and I wonder if anyone could find a better way to do this. (I would prefer if it were possible to use partial specialization of template classes, but I guess there is no way to combine specializations of a nested template using inheritance, and it invokes a weird bug in gcc [1] if you try to do so.) Vicente, have you considered similar approaches? Cheers, Gordon [1] http://stackoverflow.com/questions/1413158/partial-specialization-of-a-clas… This cites a claim that the bug was fixed in 4.5.0 but I am still seeing it in 4.5.3 - have not tried more recent. #include <iostream> #include <string> #include <boost/mpl/vector.hpp> #include <boost/mpl/fold.hpp> #include <boost/mpl/apply_wrap.hpp> #include <boost/lexical_cast.hpp> #include <boost/utility.hpp> #include <boost/numeric/conversion/cast.hpp> #include <boost/icl/type_traits/is_numeric.hpp> namespace mpl = boost::mpl; template<typename T> struct wrap {}; struct converter_start { struct dummy; dummy convert(dummy, wrap<dummy>); }; template<typename Tail> struct x2string : Tail { using Tail::convert; template<typename Source> std::string convert(Source const& x, wrap<std::basic_string<char> >) { return boost::lexical_cast<std::string>(x); } }; template<typename Tail> struct string2x : Tail { using Tail::convert; template<typename Target> Target convert(std::string const& s, wrap<Target>) { return boost::lexical_cast<Target>(s); } }; template<typename Tail> struct numeric : Tail { using Tail::convert; template<typename Target, typename Source> typename boost::enable_if_c<boost::icl::is_numeric<Target>::value && boost::icl::is_numeric<Source>::value, Target> ::type convert(Source const& x, wrap<Target>) { return boost::numeric_cast<Target>(x); } }; typedef mpl::vector<mpl::quote1<string2x>, mpl::quote1<x2string>, mpl::quote1<numeric> > my_conversions; struct my_converter : mpl::fold<my_conversions, converter_start, mpl::apply_wrap1<mpl::_2, mpl::_1> >::type { template<typename Target, typename Source> Target cast(Source const& source) { return convert(source, wrap<Target>()); } }; int main() { my_converter cvt; std::cout << cvt.cast<std::string>(1.7) << " " << cvt.cast<int>(std::string("17")) << std::endl; std::cout << cvt.cast<int>(1.7) << " " << cvt.cast<float>(17)/10.f << std::endl; return 0; }

2 2

The Lonely Song of the MPL Maintainer -- or Boost support for antediluvian compiler and the future supprot of C++11
by Joel falcou 30 Aug '11

30 Aug '11

This is meant to be a serious thread and not some trollfest about w/e compilers. I am currently fixing bugs and applying feature request in MPL and it just happens I spend more time deciphering the web of compatibility #ifdefs than doing actual code. A rough guestimate tells me that on a 100 lines MPL files, 80 of them are #ifdef for compatibility. It could fine and dandy if those #ifdefs where not, for a majority, targeted at compiler i didnt even knew hwere standard conformant (ICC 5, really) or still in serious use (Borland whatever). Some other are more debatable (like MSVC 6 or such). Considering such compilers are so broken that upgrading boost is out of question for these users and that C++11 and its new set of supporting compilers are around the corner, also taking into account my limited amount of sanity (IRC people can testify on this), can't we start some support clean up in this library ? <radical> Going further, shouldn't we start thinking at boost 2.0 which will definitevely let c++03 die its peaceful death and start, on a voluntary effort, move boost component toward C++11. I know we have a fully working Fusion for 0x only. mpl, proto and other strategic infrastructure libraries should benefit from that. Some are a trivial port like Boost.PP and all the TR1 boost library that will just either disappear or forward the C++11 version. </radical> Here is the status of the thingy. Letting Boost 2.0 aside, what should be the status of MPL and its sharazadian list of supported compiler ?

23 41

problems with grammar using spirit
by McJaml 30 Aug '11

30 Aug '11

Hi! I'm new using spirit and I'm having trouble with the parser. I already make this scanner and parser using CocoR but I have had no succes with spirit. Patito2011 is the main grammar but when I read the input file it doen't follows this grammar it goes directly to the Vars grammar. I don't know what is wrong help is appreciated. Patito2011 = tok.plan >> tok.id >> ';' >> -Vars >> Parvada >> tok.end_; Thanks in advance. Heres the code ************************************************ #include <boost/config/warning_disable.hpp> #include <boost/spirit/include/qi.hpp> #include <boost/spirit/include/lex_lexertl.hpp> #include <iostream> #include <fstream> #include <string> using namespace boost::spirit; using boost::phoenix::val; inline std::string read_from_file( const char* infile ) { std::ifstream instream( infile ); if( !instream.is_open() ) { std::cerr << "Could not open file: \"" << infile << "\"" << std::endl; exit( -1 ); } instream.unsetf( std::ios::skipws ); return( std::string( std::istreambuf_iterator< char >( instream.rdbuf() ), std::istreambuf_iterator< char >() ) ); } template<typename Lexer> struct LangLexer : lex::lexer<Lexer> { LangLexer() { id = "[a-zA-Z_][a-zA-Z0-9_]*"; cte_i = "[0-9]+"; cte_f = "([0-9]+)|([0-9]*\\.[0-9]+)"; cte_string = "\".\""; si = "if"; sino = "else"; plan = "plan"; end_ = "end"; junta = "junta"; quack = "quack"; variable = "variable"; int_ = "int"; float_ = "float"; notEqual = "<>"; this->self = lex::token_def<>('(') | ')' | '=' | ';' | '[' | ']' | ',' | '+' | '-' | '<' | '>' ; this->self += plan | si | sino | end_ | junta | quack | variable | int_ | float_ | notEqual; this->self += id | cte_i | cte_string | cte_f; this->self("WS") = lex::token_def<>("[ \\t\\n]+") | "\\/\\*[^*]*\\*+([^/*][^*]*\\*+)*\\/" ; } lex::token_def<> si, sino, plan, end_, junta, quack, variable, int_, float_, notEqual; lex::token_def<std::string> id, cte_string; lex::token_def<unsigned int> cte_i; lex::token_def<float> cte_f; }; template< typename Iterator, typename Lexer > struct LangGrammar : qi::grammar< Iterator, qi::in_state_skipper<Lexer> > { template< typename TokenDef > LangGrammar(TokenDef const& tok ) : LangGrammar::base_type(Patito2011) { Vars = tok.variable >> B >> C >> *( B >> C ); B = tok.id >> *(',' >> tok.id); C = ':' >> Tipo >> ';'; Tipo = tok.int_ | tok.float_; Parvada = '[' >> *Estatuto >> ']'; Estatuto = Copiar | Preguntar | Graznido | Juntar; Copiar = tok.id >> '=' >> Expresion >> ';'; Graznido = tok.quack >> '(' >> (Expresion | tok.cte_string) >> *(',' >> (Expresion | tok.cte_string)) >> ')'; Expresion = Exp >> -(('>' >> Exp) | ('<' >> Exp) | (tok.notEqual >> Exp)); Exp = Termino >> -(('+' >> Exp) | ('-' >> Exp)); Termino = Factor >> -(('*' >> Termino) | ('/' >> Termino)); Var_cte = tok.id | tok.cte_i | tok.cte_f; Factor = ('(' >> Expresion >> ')') | Var_cte | ('+' >> Var_cte | '-' >> Var_cte ); Preguntar = tok.si >> '(' >> Expresion >> Parvada >> -(tok.sino >> Parvada) >> ';'; Juntar = tok.junta >> '(' >> D >> ',' >> D >> ';'; D = Var_cte | tok.cte_string; Patito2011 = tok.plan >> tok.id >> ';' >> -Vars >> Parvada >> tok.end_; Patito2011.name("patito"); Vars.name("vars"); B.name("B"); C.name("C"); D.name("D"); Parvada.name("parvada"); Termino.name("termino"); Factor.name("factor"); Estatuto.name("est"); Copiar.name("copiar"); Graznido.name("graznido"); Juntar.name("juntar"); Preguntar.name("preguntar"); Expresion.name("expresion"); Exp.name("exp"); Var_cte.name("varcte"); Tipo.name("tipo"); debug(Patito2011); debug(Vars); debug(B); debug(C); debug(Tipo); debug(D); debug(Parvada); debug(Juntar); debug(Copiar); debug(Graznido); debug(Expresion); debug(Exp); debug(Preguntar); debug(Estatuto); debug(Var_cte); debug(Factor); debug(Termino); } qi::rule<Iterator, qi::in_state_skipper<Lexer> > Vars, B, C, Tipo, Parvada, Preguntar, Estatuto, Copiar, Expresion, Var_cte, Exp, Termino, Factor, Graznido, Juntar, D, Patito2011;; }; int main( int argc, char** argv ) { typedef std::string::iterator base_iterator_type; typedef lex::lexertl::token< base_iterator_type, boost::mpl::vector<float, unsigned int, std::string> > token_type; typedef lex::lexertl::lexer<token_type> lexer_type; typedef LangLexer<lexer_type> LangLexer; typedef LangLexer::iterator_type iterator_type; typedef LangGrammar<iterator_type, LangLexer::lexer_def> LangGrammar; LangLexer lexer; LangGrammar grammar(lexer); std::string str(read_from_file(argv[1])); base_iterator_type strBegin = str.begin(); iterator_type tokenItor = lexer.begin(strBegin, str.end()); iterator_type tokenItorEnd = lexer.end(); bool result = qi::phrase_parse( tokenItor, tokenItorEnd, grammar, qi::in_state("WS")[ lexer.self ] ); if( result ) { std::cout << "Parsing successful" << std::endl; } else { std::cout << "Parsing error" << std::endl; } return( 0 ); } ***************************** and here is a sample input file plan adsadsad; variable x,y,z : int; t,a,b,c : float; [ si ( 2 > 1) [ junta("string", "hola"; x = 1; t = 1.23; y = (1 - 2) < (1 + 3); y = (1 - 2) <> (1 + 3); y = (1 - 2) > (1 + 3); quack("quack", 1); quack("quack", "hola"); quack("quack", (1 + 2)); ] sino http://boost.2283326.n4.nabble.com/file/n3775416/patito.txt patito.txt http://boost.2283326.n4.nabble.com/file/n3775416/LexerParser.cpp LexerParser.cpp [ junta("string", "hola"; x = 1; t = 1.23; y = (1 - 2) < (1 * 3); y = (1 - 2) <> (1 / 3); y = (1 - 2) > (1 + 3); quack("quack", 1); quack("quack", "hola"); quack("quack", (1 + 2)); ]; ] end ************************************************** -- View this message in context: http://boost.2283326.n4.nabble.com/problems-with-grammar-using-spirit-tp377… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 3

[bcp] Typo in doc/bcp.qbk
by Brian Ravnsgaard Riis 29 Aug '11

29 Aug '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [article BCP [quickbook 1.4] [copyright 2209 John Maddock] ^^^^ Surely not! :-) /Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOWW/IAAoJEKd8gmwzkHPJwNoH/itm6+DnafcZGRoiz+jZleon QJ7S8oSYc59ljr2xsYm5c/S+2v/GWHT81NmMdSM9inwLJ+C3SZNQTouMTKJ1mUqg M9MqPbmL5GtGnWc8ZPDvu3J1eEm8KjX1jiSQHrUrxvTrW8cNQbDswrhJWL6elSCz 2TWcI++JQVgck8gnbQ8UE+shdHqiHFWq5Y8mNn6pdsTO8ULxZFX1gHDsAgyK8N+a tDtdvnq6U6vJWsEVNcrQgl//0nuLFtIepwb/ajahTtY/3uMhzEvUKq1EP0k+ag4U ZTm0byKBhNWJD2p8cHONbnZe3oidvM7En2Qm6g6Iwv85PzxHNbBtdbt6vFOQ9eo= =RyJL -----END PGP SIGNATURE-----

2 1

[Containers Review Result] Boost.Containers is accepted into Boost.
by John Maddock 29 Aug '11

29 Aug '11

This is to announce that the Containers library by Ion Gaztanaga has been accepted into Boost. There were 11 positive reviews and one negative, many making the same points (see summary below). Acceptance is therefore conditional on Ion improving the documentation as the reviewers requested. Review comments summary: ~~~~~~~~~~~~~~~~~~~~~~~~ * Needs a better introduction/overview/tutorial in the docs: # what are stateful allocators, what's currently supported in this area, how is it supported, does it have performance implications. # Needs overview of the new containers - stable_vector, flat_* etc. # Needs description of recursive containers and why this library supports them but not C++03 containers. # Needs to justify why this library and not the std one (probably by mention of the above). * Make clear in the docs (if not already) what the default allocator is. * Make allocator template parameter name consistent. * Add basic_string::shrink_to_fit member function (from C++11). * Typo in range insertion docs (first/last vs i/j) * vector<bool> behavior needs to be documented (and justified either which way). * Need to document conformance to C++0x container requirements, plus use (or not) of new C++0x features such as std::allocator_traits. * Missing documentation for some deque member functions. * Missing Returns/Effects,Complexity or Throws. (ex: after No.23 in basic_string) * The "Acknowledgements" page is currently empty. There are various (c) notices in the source referring to sources from which parts of the code may have come. This page should clarify these sources, including any cases where the original code has now all been replaced, and assert that the licenses are all in order. It should also point out the history of the code in Boost, i.e. that parts were previously in Boost.Interprocess, so that anyone with previous exposure to the Interprocess containers is not confused. * There are some comments that the organisation of the docs makes it unnecessarily hard to jump directly to the info you want. Requests for additional features: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Consider implementing std::forward_list from C++0x. * Consider Boost.Range interoperability and/or range insert support. * Make the flat_* containers container adapters - so that a) the user can choose the underlying implementation and b) they can shoot themselves in the foot if they want to by manipulating the underlying container (mostly for efficient loading of data). Alternatively, provide some other interface enhancements to try to meet most of the use cases given. * Efficient construction of ordered containers from already sorted data. * Investigate Clang's Libc++ std lib performance tests. John Maddock Containers review manager. PS: Ion: if you need any help with quickbook/docbook and AutoIndex ping me and I'll see what I can do to help - there are all sorts of parameters that can be used to tweak the appearance etc.

4 6

[move] Fix for clang.
by Daniel James 29 Aug '11

29 Aug '11

Hi Ion, Clang pretends to be gcc 4.2, but in c++0x mode has the correct c++0x rvalue reference rules introduced in gcc 4.5, so move is incorrectly configured. The attached patch fixes that. Only tested with llvm clang 2.9.. Daniel

2 1

[rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC
by Daniel Larimer 29 Aug '11

29 Aug '11

I have just recently completed my first alpha release of a generic RPC library designed to support different protocols (JSON, XML, Protocol Buffers) and different transports (UDP, TCP, HTTP) in a generic manner. Currently only JSON over TCP is implemented. This library builds on top of my Boost.Reflect library which provides simple reflection along with a generic type-erasure construct, boost::reflect::any_ptr<T> Lastly all of this builds on top of my Boost.CMT (Collaborative Multi-Tasking Library) which seems to be along the same lines as Oliver's Boost.Strand library, but with a simpler interface. It is built on top of Boost.Context. This allows the RPC to be asynchronous, thread-safe, and free of nasty completion handlers. I have documentation of all three libraries posted here. http://bytemaster.github.com/dev/modules.html I would like to know if I am barking up the right tree here and if anyone has any feedback. If someone has a real project they would like to see this code incorporated into I would be more than willing to focus my development effort toward those needs.

7 16

[MSM] event deferral and dispatching with base event
by Richard Szabo 28 Aug '11

28 Aug '11

Hi Christophe I'm running the attached test program it generates the following output : entering: Idle MS1_ leaving: Idle Action: MS1::onEvent1 entering: RunningStateMachine MS1_ entering: RunningStateMachine::PseudoEntry1 leaving: RunningStateMachine::PseudoEntry1 entering: Inner1 RunningStateMachine_ entering: InnerState11 FwdGuard: returns:0, event: event5 FwdGuard: returns:0, event: event1 FwdGuard: returns:0, event: event1 FwdGuard: returns:0, event: event5 FwdGuard: returns:0, event: event1 FwdGuard: returns:0, event: event1 FwdGuard: returns:0, event: event5 FwdGuard: returns:0, event: event1 FwdGuard: returns:0, event: event1 FwdGuard: returns:0, event: event5 I believe it is incorrect after state machine entered state InnerState11 . FwdGuard should have been called ones with event5 and than 3 times with event1 and event1 shall have triggered after the first dispatching a no transaction. But this case no trans was triggers on even1 and and the deferred event5 got dispatched even there was no state change for every event1 dispatching. this breaks our code execution completely :(. Br. Richard

2 4

Review Request: Singularity
by Ben Robinson 28 Aug '11

28 Aug '11

Hello, This is a request for a formal review of Singularity, for inclusion into Boost. The submission is attached as a compressed zip file, and is also publicly available for download from GitHub at https://github.com/icaretaker/Singularity. The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. I would like to thank the Boost community for their invaluable feedback regarding the features and implementation details of Singularity. I have compiled and run Singularity on 4 different compilers: GCC 4.5, MSVC++ 2010, the Texas Instruments CL2000 compiler targeting the 2803x processor, and the Green Hills compiler targeting the Cortex-A8 ARM processor. Thank you, Ben Robinson, Ph.D. P.S. I have also implemented Singularity in C++11 using variadic templates and rvalue references to achieve perfect function forwarding. These source files are located in the /cpp11 subdirectory, but that is not part of the submission, unless Boost is accepting C++11 libraries at this time.

10 22

[quickbook] Failure building on trunk
by Edward Diener 27 Aug '11

27 Aug '11

Trying to generate some documentation using the latest on Boost trunk, the build of quickbook works with gcc but failed using toolset-msvc-10.0 with: "compile-c-c++ C:\Programming\VersionControl\boost\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi\id_generator.obj id_generator.cpp C:\Programming\VersionControl\boost\boost/unordered/detail/buckets.hpp(220) : error C2668: 'boost::addressof' : ambiguous call to overloaded function C:\Programming\VersionControl\boost\boost/utility/addressof.hpp(51): could be 'T *boost::addressof<boost::unordered::detail::bucket<A>>(T &)' with [ T=boost::unordered::detail::bucket<std::allocator<std::pair<const std::string,quickbook::id_generator::id>>>, A=std::allocator<std::pair<const std::string,quickbook::id_generator::id>> ] C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xmemory(109): or '_Ty *std::addressof<boost::unordered::detail::bucket<A>>(_Ty &)' [found using argument-dependent lookup] with [ _Ty=boost::unordered::detail::bucket<std::allocator<std::pair<const std::string,quickbook::id_generator::id>>>, A=std::allocator<std::pair<const std::string,quickbook::id_generator::id>> ] while trying to match the argument list '(boost::unordered::detail::bucket<A>)' with [ A=std::allocator<std::pair<const std::string,quickbook::id_generator::id>> ] C:\Programming\VersionControl\boost\boost/unordered/detail/buckets.hpp(207) : while compiling class template member function 'void boost::unordered::detail::buckets<A,Unique>::delete_buckets(void)' with [ A=std::allocator<std::pair<const std::string,quickbook::id_generator::id>>, Unique=true ] C:\Programming\VersionControl\boost\boost/unordered/detail/table.hpp(564) : see reference to class template instantiation 'boost::unordered::detail::buckets<A,Unique>' being compiled with [ A=std::allocator<std::pair<const std::string,quickbook::id_generator::id>>, Unique=true ] C:\Programming\VersionControl\boost\boost/unordered/detail/unique.hpp(392) : see reference to class template instantiation 'boost::unordered::detail::types<K,V,H,P,A,E,Unique>' being compiled with [ K=std::string, V=std::pair<const std::string,quickbook::id_generator::id>, H=boost::hash<std::string>, P=std::equal_to<std::string>, A=std::allocator<std::pair<const std::string,quickbook::id_generator::id>>, E=boost::unordered::detail::map_extractor<std::string,std::pair<const std::string,quickbook::id_generator::id>>, Unique=true ] C:\Programming\VersionControl\boost\boost/unordered/unordered_map.hpp(63) : see reference to class template instantiation 'boost::unordered::detail::map<K,H,P,A>' being compiled with [ K=std::string, H=boost::hash<std::string>, P=std::equal_to<std::string>, A=std::allocator<std::pair<const std::string,quickbook::id_generator::id>> ] c:\programming\versioncontrol\boost\tools\quickbook\src\id_generator.hpp(52) : see reference to class template instantiation 'boost::unordered::unordered_map<K,T>' being compiled with [ K=std::string, T=quickbook::id_generator::id ] call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"C:\Programming\VersionControl\boost\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi\id_generator.obj.rsp" ...failed compile-c-c++ C:\Programming\VersionControl\boost\bin.v2\tools\quickbook\src\msvc-10.0\release\link-static\threading-multi\id_generator.obj..."

3 5

Re: [boost] [proto] Problems with operator <<
by John Maddock 27 Aug '11

27 Aug '11

> Folks, > > I'm having no end of problems with operator<< and proto. > > In the beginning, operator << was overloaded for stream output and > everything worked OK, then I added the left shift operator<< to the list > of protoized operators in the grammar and everything broke. The strange > thing is that: > > std::cout << a+b; > > correctly finds my stream out overload: > > template <class Exp> > inline std::ostream& operator << (std::ostream& os, const > big_number_exp<Exp>& r) > > But > > std::cout << a; > > no longer calls: > > template <class Backend> > inline std::ostream& operator << (std::ostream& os, const > big_number<Backend>& r) > > But calls the proto << operator instead. > > I'm at a complete loss to explain this, both of my overloads are in the > same namespace as their respective types, and as far as I can see both > should be preferred to the proto versions. To answer my own question - in case anyone else gets bitten by this - the answer is you need to provide overloads with both const and non-const reference RHS arguments to effectively hide the proto operator versions. Still some hair left yours.... John.

2 11

[program_options] Some methods take const char*, others take std::string
by Gabriel Redner 27 Aug '11

27 Aug '11

Hi all, Some methods in program_options accept const char*s (e.g. option_description constructor), while others take const std::string&s (e.g. option_description::key). This makes no difference to the user if he is passing string literals, but becomes annoying if he wants to pass strings, or expressions which return strings. Of course he can put (...).c_str() everywhere, but this is ugly and unnecessary, since program_options just takes its parameters and shoves them into string variables anyways. Since changing the parameter types to const std::string& should not break existing code, I do not see a downside to doing so (plus, it would allow me to get rid of .c_str()s everywhere :-). Does it seem reasonable for program_options public APIs to accept std::strings instead of const char*s? If so I would be happy to do the legwork and submit a patch. Thanks, -Gabe

6 16

Reg : Boost Error - any.hpp
by Vijay 27 Aug '11

27 Aug '11

Hi, We are using boost version 1.31.0 in our C++ code. Our OS is HP-UX 11.31 Itanium. We use aCC compiler. While compiling my code, I'm getting the below error. Can any one help me to fix this issue ? "/opt/app/q1app2c4/boost-1.31.0/boost/any.hpp", line 125: error #2070: incomplete type is not allowed ValueType held; ^ detected during: instantiation of class "boost::any::holder<ValueType> [with ValueType=Fcif]" at line 32 instantiation of "boost::any::any(const ValueType &) [with ValueType=Fcif]" at line 35 of "/opt/app/q1app2c4/src/share/incl/Fcif.h" Cheers, Vijay....(V2K) E-mail to : v2k.sweet(a)gmail.com Catch me @ 9962003328, 7871181610 Blackberry PIN : 259943F3 "Life is just one grand sweet song, so start the music."

2 1

accumulator serializable?
by Neal Becker 26 Aug '11

26 Aug '11

I have typedef accumulator_set<el_t,stats<tag::mean,tag::abs_sqr> > accum_t; What would I need to do to serialize an accum_t object?

2 1

[review] Conversion review continues through 8/29
by Gordon Woodhull 26 Aug '11

26 Aug '11

Folks, The review of Vicente Botet Escriba's Conversion library continues through this Monday. So far discussion has been light and there have been only a couple of reviews. I'll attempt to provoke some discussion by offering my own review and by bringing in some opinions made off-list. Your input would be greatly appreciated. Thanks, Gordon

1 0

[Containers] Marshalling deques
by Brian Wood 26 Aug '11

26 Aug '11

There's a thread here -- http://groups.google.com/group/comp.lang.c++/browse_thread/thread/0a6a19f83… that I'd like to mention. Does the deque in the Containers library have support for accessing the chunks it uses? Would you be willing to add a function that gives that? Tia. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

3 3

Subject: Re: [Boost-users] [Containers] Marshalling deques
by Brian Wood 26 Aug '11

26 Aug '11

Michael Goldshteyn: > I think that having a ?configurable? deque class template > is one of the best things that could be offered by a boost > Containers library. I have always wondered why noone > wrote a version of the deque class template that allowed > the configuration of such things as the page / block size, > rather than have it be determined by a compile time > formula based on the size of the data type being stored. > It would seem to me that the page / block size is one of > the more critical pieces affecting the size / speed > tradeoffs in a deque?s performance when there are many > insertions taking place. The thread I mentioned has a link to a segmented_array container which may be of interest. I agree that what you suggest would be an improvement. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 0

Lighweight header-only version of Boost.Filesystem?
by Mathias Gaunard 25 Aug '11

25 Aug '11

I use Boost.Filesystem in a C++ "script": I use C++ instead of Python or shell script in order to be portable across operating systems. That script is used in bootstrapping the build system of my C++ project, and people have complained that they need to build boost.filesystem just to be able to bootstrap the project. This is made worse by the fact than the rest of my C++ project requires very recent versions of Boost headers and the fact that the ABI of filesystem has changed relatively recently. I had instances of people having problems because they were linking old versions of the filesystem library but using recent filesystem headers. They had a lot of trouble compiling the correct versions of filesystem themselves. I would also like to ship the script at installation time. To do that I statically link filesystem to reduce dependencies. My pretty trivial program, however, is more than 650kB in release mode after stripping (2.2 MB before stripping). All it does is walk a directory recursively and create a few files. I think this is too big. Therefore, I would really like it if there was a lightweight header-only version of Boost.Filesystem. I don't need the full extent of features; I just need to have the ability to do the following portably: - read all files of a directory - create directories - remove files and directories - rename files and directories The first point being the most important.

8 11

[msm]intarnal_transition_table's behavior
by Takatoshi Kondo 25 Aug '11

25 Aug '11

Hello, When I was trying to answer an another thread, I encountered strange behavior. (Re: [boost] [msm]exit pseudo state and event) See 18_InternalTransitionTableTest.cpp. (attached file) I believe that internal_transition_table should work correctly without transition_table. Here is internal_transition_table. // Internal Transition table struct internal_transition_table : mpl::vector< // Event Action Guard msmf::Internal < Event1, Action1_1 ,Guard1_1 > > {}; But Event1 isn't dispatched. I don't understand why. When I add transition_table that includes the Event1, internal_transition_table works correctly. #if 1 // Why is it needed? // Transition table struct transition_table:mpl::vector< // Start Event Next Action Guard msmf::Row < State1_1, Event1, State1_2, msmf::none, msmf::none > // OK // msmf::Row < State1_1, Event2, State1_2, msmf::none, msmf::none > // NG > {}; #endif But if transition_table don't have Event1, internal_transition_table doesn't work correctly. msmf::Row < State1_1, Event2, State1_2, msmf::none, msmf::none > // NG I suspect it is bug. How do you think? Thanks, Takatoshi

3 6

[type_traits] is_enum on scoped enums doesn't works as expected
by Vicente J. Botet Escriba 25 Aug '11

25 Aug '11

Hi, The following file fails to compile under clang 2.9 c++0x #include <boost/static_assert.hpp> #include <boost/type_traits/is_enum.hpp> enum E {E_a,E_b,E_c}; BOOST_STATIC_ASSERT((boost::is_enum<E>::value)); enum class EC {a,b,c}; BOOST_STATIC_ASSERT((boost::is_enum<EC>::value)); //#include <type_traits> The command line and error is "/Users/viboes/clang/clang+llvm-2.9/bin/clang++" -x c++ -std=c++0x -O0 -g -Wextra -Wno-long-long -pedantic -O0 -fno-inline -Wall -pedantic -g -DBOOST_ALL_NO_LIB=1 -DBOOST_CONVERSION_DOUBLE_CP -DBOOST_ENABLE_WARNINGS -I"." -I"../../.." -c -o "../../../bin.v2/libs/enums/test/is_enum_pass.test/clang-darwin-2.9x/debug/is_enum_pass.o" "enum_class/is_enum_pass.cpp" enum_class/is_enum_pass.cpp:7:1: error: static_assert failed "(boost::is_enum<EC>::value)" BOOST_STATIC_ASSERT((boost::is_enum<EC>::value)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from enum_class/is_enum_pass.cpp:1: Am I missing something evident? Is this a known bug of is_enum? BTW, I have tried to use directly the type_traits standard file and my build configuration is unable to find it. enum_class/is_enum_pass.cpp:9:10: fatal error: 'type_traits' file not found #include <type_traits> Which is the default library when buildding with Boost.Build (bjam) and clang 2.9 c++0x? Best, Vicente

6 11

Re: [boost] Query for interest in including a shim class converting between char*, wchar_t*, string, wstring
by Zhi Tan 25 Aug '11

25 Aug '11

> > From: Yakov Galka <ybungalobill(a)gmail.com> > > On Thu, Aug 25, 2011 at 12:11, Tan, Tom (Shanghai) <TTan(a)husky.ca> wrote: > > > As a C++ programmer, often times there's a need to widen or narrow a > > string to match some 3rd APIs. After writing similar code again and > > again, I decided to have a wrapper to simplify this trivial but frequent > > work, hence the TR and TR2 class. Features include: > > > > If something fails to compile, there must be a reason. Just shutting up the > compiler doesn't make your code correct. What you're doing is like > reinterpret_casting an int to float... > no reinterpret_casting is involved here. it's just a wrapping of one of basic_string's standard constructors. template<class InputIterator> string (InputIterator begin, InputIterator end) template<class InputIterator> wstring (InputIterator begin, InputIterator end) and this usage is a distorted usage. > [...] > > - Many Boost libraries (e.g. Boost.Test) that output plain > > English (ASCII) message literals can be easily extended to support both > > wide-char version with this class. > > > > They don't have to support wide-char. Many programmers are not interested > in > any wide-char support at all. See > > http://programmers.stackexchange.com/questions/102205/should-utf-16-be-cons… > As explicitly stated below, it does not have anything to to with any encoding/decoding of UNICODE and the like. It only does widening and narrowing of *plain ACSII Engish text*, where the operation does not change the meaning and readability of the literals. I can understand how some people can live without wide-char all life by living in a culture where wide-char is not needed(e.g. English speaking countries), or in a tech culture where UTF8 is used(Linux). But I happen to live in a culture(Chinese language) where 16-byte wide-chars are a matter of fact and easier to use. The default on Windows(UTF16) is implemented on wide-char too. I believe there are many out there like me facing cases where *widening *the English text is only need and correct enough. While the scope is very specific, the need is real. Think of std::exception class exception {public: exception () throw(); exception (const exception&) throw(); exception& operator= (const exception&) throw(); virtual ~exception() throw(); virtual const char* what() const throw(); } exception::what() only returns narrow chars, many exception-derived classes only provide simple English message too, where widening is necessary my wide-char app. The same goes to Boost Informational Macros <http://www.boost.org/doc/libs/1_47_0/libs/config/doc/html/boost_config/boos…>, and compiler predefined macros. Do not mistake it as a solution to endcodings or locale, rather, it's a solution between char* and wchar_t*, when you know the operation is safe, which is usually the case of writing libraries, where messages are in short and plain ASCII English literals. > - The 2 classes do not involve any encoding/decoding. > > > > tr.hpp: > > > * N.B. it doe not do any code conversion like: MBCS <--> UNICODE > > > > This is just wrong. Your code is useless as it doesn't solve any real > problem. This is not going to be accepted to boost, especially since it > misguides programmers to write Unicode incorrect and *broken* code. Yes, > you > may find this library useful, and, say, half of non-expert programmers will > find this library useful. The sad thing is that most of them just don't > understand what Unicode is or what's text at all. > see above. This is NOT a code conversion solution, rather, a wrapping of standard C++ solution for a real need. > > Btw, you're not the first to propose some kind of tools for 'Unicode > support'. I can count at least 4 other proposals trying to solve different > aspects by different means. None of them was accepted to boost yet. > > -- > Yakov > > >

1 0

Re: [boost] Query for interest in including a shim class converting between char*, wchar_t*, string, wstring
by Zhi Tan 25 Aug '11

25 Aug '11

> > Date: Thu, 25 Aug 2011 11:24:59 +0200 > From: Sebastian Redl <sebastian.redl(a)getdesigned.at> > > On 25.08.2011 11:11, Tan, Tom (Shanghai) wrote: > > - The name TR is inspired from QT' tr() macro. > > > Qt's tr() stands for "translate" because that thing is the entry point > for Qt's localization/message catalog system. In other words, you use > tr() only for user-visible string that should get translated. That makes > it a poor inspiration for something that is concerned with encoding > conversion. > > Sebastian > I am aware this is not translation, but I like the shortness of tr(). One of the things I am expecting from the community is a proper naming. Vicente Botet renamed it to be adaptive_string, but it seems too long for me to type. Wile I am typing, it occurs to me as() might be a better name.

1 0

Query for interest in including a shim class converting between char*, wchar_t, string, wstring
by Tan, Tom (Shanghai) 25 Aug '11

25 Aug '11

As a C++ programmer, often times there's a need to widen or narrow a string to match some 3rd APIs. After writing similar code again and again, I decided to have a wrapper to simplify this trivial but frequent work, hence the TR and TR2 class. Features include: - Each class serves as a shim between wide-char and marrow-char string types. It accepts a std::basic_string type or C-style literal, returns a std::basic_string type or streamming to std::basic_ostream according to the context(e.g. type on the left side of '=' operator): - 2 classes o Non-template class TR: convenient and intuitive interface, e.g. std::string s = TR(L"hello"); std::wstring s = TR("hello"); o template class TR2<SourceRange>: more verbose but faster e.g. std::string s = TR2<const wchar_t*>(L"hello"); std::wstring s = TR2<const char*>("hello"); - Many Boost libraries (e.g. Boost.Test) that output plain English (ASCII) message literals can be easily extended to support both wide-char version with this class. - The 2 classes do not involve any encoding/decoding. - The name TR is inspired from QT' tr() macro. If there's enough interest, I am ready to improve the code, including renaming, style cleaning, documenting and compiler testing etc, for a final inclusion. And I also would like to have a mentor to guide me through as I've never submitted any code to boost before. This class started as some test code snippet for boost.chrono while exchanging ideas with Vicente J. Botet Escriba. One major improvement since then is that the conversion is bi-directional now..

3 2

[type traits] Extension to operator detection -> choose your preferred naming
by Brent Spillner 25 Aug '11

25 Aug '11

On 8/24/2011 07:23 Frederic Bron wrote: > Please give your preference between A, B and C before Sept. 5th. Of these three choices, I think C is easiest to live with. However, if you're going to have has_unary_plus I think the symmetry of has_unary_minus is preferable to has_negate, and I continue to believe that an additional has_operator<Tag, TypeA, TypeB> (or can_call_operator<>) should be provided for use in more generic code (e.g. forwarding ETs from a higher level without caring exactly which operators are involved.) Brent

1 0

[Conversion] Practical applications
by Phil Endecott 25 Aug '11

25 Aug '11

Dear Vicente & others, Would anyone like to share any practical or motivating applications for the proposed Boost.Conversion library? It seems to me that there are practical applications for particular types of conversion, e.g. T-to-string and string-to-T, and numeric casts, and serialisation. Apart from that, I am having trouble seeing practical reasons for generic conversion. A motivating case would be if a generic algorithm required conversion, but in the cases that I can think of either (a) the generic algorithm takes a functor, so the caller can pass the currently-required conversion as part of a lambda expression, or (b) you might need to select one of several possible conversions between a pair of types, which this library can't do, or (c) the algorithms are std:: ones which won't work with this library anyway. Example: struct person { string firstname; string surname; }; vector<person> people; // sorted by firstname // Try to find everyone with firstname "John": std::equal_range(people.begin(),people.end(),"John"); That doesn't work. Making it work has always struck me as more difficult than it should be. Can this library make it easier? If not, what similar problems can it help with? Regards, Phil.

6 12

[gsoc] Final evaluations
by Andrew Sutton 25 Aug '11

25 Aug '11

Mentors, Please don't forget to submit your final evaluations. You must submit the evaluation before August 26. Thanks, Andrew

1 0

Re: [boost] [Containers] Marshalling deques
by Brian Wood 24 Aug '11

24 Aug '11

Ion Gazta?aga: El 24/08/2011 20:06, Brian Wood escribi?: >> >> If I could get the number of elements in the first chunk and the >> size of the chunks, that would be sufficient. (I believe the size >> of the chunks is constant within a deque instance.) > > Not necessarily, but I think all implementations do that. The question > is whether we should have a standard-friendly and implementation > agnostic interface or an interface just for boost::deque implementation. How about both? First a boost::deque implementation and then if someone is inclined to delve into this further a more general implementation that might replace the earlier implementation. Since this wasn't addressed by C++11, I'm not sure how long it will take to get attention. If the interface we come up with has weaknesses, someone else will figure out how to improve upon it. Regards, Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

[interest] underlying type library
by Julian Gonggrijp 24 Aug '11

24 Aug '11

Dear Boost developers, std::swap is commonly implemented by copying the arguments. For non-POD types this can be very inefficient. Two solutions are available. The first option, which is commonly employed, is to manually override std::swap for every non-POD type, making use of the implementation details of the type. The other option is to provide a library which makes it possible to implement the swap algorithm once, in a way that is efficient for any type (POD or non-POD), and which works even if a type isn't copyable. The latter is what I'll be proposing here. Back in March, Vicente Botet posted a link to the highly inspiring 'Notes on Programming' by Alexander Stepanov [1]. Lectures 4 and 5 cover the (hypothetical) move_raw algorithm and the (hypothetical) UNDERLYING_TYPE type function, as well as their relevance to the swap algorithm. I'll try to reproduce the essential points of this discussion below. move_raw(s, t) moves the value of s to t. t is guaranteed to be left in a valid state but s isn't. In particular, the destruction of s might corrupt t because they point to the same additional resources. Another move operation into s, say, move_raw(r, s) will however restore s into a new valid state. UNDERLYING_TYPE(T) represents a type which is (conceptually speaking) a POD-type with the same member data (and hence the same alignment) as T. The underlying type can be used to allocate space for a T object and to temporarily store the state of a T object. Using move_raw and UNDERLYING_TYPE, a swap algorithm can be implemented which works and is efficient for any type: template <class T> void swap (T& x, T& y) { UNDERLYING_TYPE(T) temp; move_raw (x, temp); move_raw (y, x); move_raw (temp, y); } The benefits of an underlying type library go far beyond the swap algorithm. For a start, any algorithm which moves values around without an inherent need to copy them could use the same mechanism as the swap algorithm above. Apart from that, it can help to simulate rvalue references and move semantics in pre-C++11 compilers in an efficient way. Concluding, a library which provides these tools has an immense potential for improving efficiency and convenience anywhere C++ is used. After reading the lecture notes, I came up with an idea on how to realise such a library in a fully generic way. Alexander Stepanov and Sean Parent have been so kind to review my idea. The idea seemed feasible and they encouraged me to submit something to Boost. In the meanwhile I have successfully managed to implement my idea, so here I am. :-) Apart from its fundamental nature in general, my library might bear special relevance to Boost.Swap and Boost.Move. Is your interest piqued? Kind regards, -Julian [1] http://www.stepanovpapers.com/notes.pdf

16 72

[proto] Problems with operator <<
by John Maddock 24 Aug '11

24 Aug '11

Folks, I'm having no end of problems with operator<< and proto. In the beginning, operator << was overloaded for stream output and everything worked OK, then I added the left shift operator<< to the list of protoized operators in the grammar and everything broke. The strange thing is that: std::cout << a+b; correctly finds my stream out overload: template <class Exp> inline std::ostream& operator << (std::ostream& os, const big_number_exp<Exp>& r) But std::cout << a; no longer calls: template <class Backend> inline std::ostream& operator << (std::ostream& os, const big_number<Backend>& r) But calls the proto << operator instead. I'm at a complete loss to explain this, both of my overloads are in the same namespace as their respective types, and as far as I can see both should be preferred to the proto versions. Before I start tearing my hair out, anyone any ideas? Thanks, John.

2 1

Re: [boost] [Boost-users] [Containers] Marshalling deques
by Brian Wood 24 Aug '11

24 Aug '11

Ion Gazta?aga: > >El 22/08/2011 19:44, Brian Wood escribi?: >> Would you be willing to add a function that gives that? Tia. > > Yes, I think we need to think about a useful interface for that, maybe > something like local_iterator in unordered containers or something like > segmented iterator described by Matt Austern in his "Segmented Iterators > and Hierarchical Algorithms" paper If I could get the number of elements in the first chunk and the size of the chunks, that would be sufficient. (I believe the size of the chunks is constant within a deque instance.) I find it disappointing that the latest version of the standard doesn't have anything related to this and would rather just get something working than figuring out what would be a flexible, general interface. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

[Locale] On Mac OS X 10.6 fails to find iconv
by Artyom Beilis 24 Aug '11

24 Aug '11

Hello, I need a help from Mac OS X users, I have many faults on Darwin: http://beta.boost.org/development/tests/trunk/developer/locale.html Where all GCC's are related to inability to find iconv for some reason. On my darwin 8.01 x86 I have no problems to compile this simple program: has_iconv.cpp #include <iconv.h> int main() { iconv_t d = iconv_open(0,0); (void)(d); } With g++ has_iconv.cpp -liconv Also BBv2 script of Boost.Locale finds the iconv without a problem, so I'm quite lost. So if anybody that uses Boost from svn-trunk can check why has_iconv test fails (if it is on their machines) and see if ./bjam libs/locale/test prints ....... - iconv (libc) : no - iconv (separate) : no ....... And for what reason (if the sample code above compiles) I would be grateful. Because I have no idea what happens there and I don't have Mac only Darwin 8 which handles it properly. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

3 5

[Boost.Interprocess] Chronic performance on Win7
by Gav Wood 24 Aug '11

24 Aug '11

Hi, we're using the Boost Interprocess layer to do some shared-memory-based IPC and after getting awful performance characteristics out of sync primitives (in particular the condition variables, but similar results with semaphores) decided to do some profiling. Our platform is a (dual-core) Intel Core 2 Duo, running 64-bit Windows 7 and a 64-bit build environment in MSVC 10. One thing we wished to see was the performance of process hand-offs; i.e. getting one process to block as it unblocked a second symbiotic process and vice versa. To this aim we made a tight loop looking like: boost::interprocess::named_mutex m(boost::interprocess::create_or_open, "ProfileCache-Mutex"); boost::interprocess::named_condition c(boost::interprocess::create_or_open, "ProfileCache-Condition"); scoped_lock<named_mutex> l(m); for (int i = 0; i < 1024; ++i) { c.notify_all(); c.wait(l); } and another, running in another process with the wait & notify_all() reversed. It was checked to make sure that hand-offs were happened properly (no spurious wakeups &c.). I don't have any graphs to hand (though they would be quite easy to create), but as a rough figure, assuming a relatively unfettered execution environment - no browsers running/music playing - we were getting about 45 second run times. That's approximately 40ms per round-trip between the processes or 20ms per forced context switch. I suspect it's no mere coincidence that the Windows scheduling timeslice happens to be 20ms in duration; for Windows the sched_yield call is implemented by a Sleep(1); this, on Windows 7 at least, has the effect of putting the thread to sleep for the rest of its timeslice. Not ideal for low-latency IP-hand-offs. The obvious way to gain far higher performance is to Sleep(0). This has had the meaning since Vista of "run any other thread that's ready to run" (it used to mean any other thread of equal priority that's ready to run, hence priority inversion could ensue and people favoured the more aggressively passive Sleep(1)). Changing to a Sleep(0)-based sched_yield gave appropriately speedy results; of the order of 600us for the 1024 roundtrips, about 300ns per forced context switch. Though the loop around the Sleep(0) is a nice, yielding spin loop, if all processes are waiting (perhaps on an external event), then it will needlessly use 100% of each of the used cores. Also far from ideal. My proposed solution, for which I have attached a draft patch, introduces an argument to sched_yield ("_iteration"), in order to allow sched_yield to customise its behaviour depending on how long it has been waiting so far. All loops around sched_yield() (yield-loops) have been changed to track the number of iterations and pass it as an argument to sched_yield(). Ideally we would like to Sleep(0) in the case that the yield-loop's exit condition will be satisfied within the next 20ms and Sleep(1) in all other cases. As a completely unknown prior, we can use an exponential PDF with the 0.5 point occuring at the duration that we have already been waiting for. Optimising for this model, we Sleep(1) once we have already been waiting 20ms, which puts it at around 50000-100000 Sleep(0) calls. The was tested empirically and gave a simple Sleep(0)-yield performance, but while reducing the CPU consumption to near 0 on indefinite wait()s. We tested to make sure performance wasn't hindered should the threads be of unequal priorities; this indeed wasn't the case. Comments? Regards, Gavin -- Save Ferris!

4 7

Conversion review
by Jeroen Habraken 23 Aug '11

23 Aug '11

My review of the Conversion library: Please note that I'll be referring to the pre-review thread which can be found here: http://lists.boost.org/Archives/boost/2011/07/183525.php. * What is your evaluation of the design? Please refer to the section discussing the potential usefulness of this library. * What is your evaluation of the implementation? The code looks clean but I'm worried about the abundant use of boost::enable_if. While it is a useful tool SFINAE does make code fragile, possibly using something akin the following is an option: template <typename Target, typename Source, bool CA, bool EEC, bool A> struct assigner_impl { // No cookies BOOST_STATIC_ASSERT(sizeof(Target) == 0); }; template <typename Target, typename Source> struct assigner_impl<Target, Source, true, true, false> { // Copy-assignable, extrinsically explicitly convertible and not assignable ... }; template <typename Target, typename Source, bool CA, bool EEC> struct assigner_impl<Target, Source, CA, EEC, true> { // Assignable ... }; template <typename Target, typename Source> struct assigner : assigner_impl< Target, Source, is_copy_assignable<Target>::value, is_extrinsically_explicitly_convertible<Source, Target>::value is_assignable<Target, Source>::value > { }; (Note, this was written on the fly in this email, it may not actually compile.) * What is your evaluation of the documentation? Everything seems to be covered well, small comment though: template <> struct is_assignable<X&, X const&> : true_type { }; I initially missed that true_type is boost::true_type, this should be made more obvious. * What is your evaluation of the potential usefulness of the library? Let me tackle this in several parts: - type-to-string and string-to-type conversions In the pre-review we came to the following conclusions: "Coming back to the string to int conversion, if we can not have a default string-to-type or type-to-string, Boost.Conversion must remove these specializations." "I don't think that Boost.Conversion can provide a string-to-type conversion that is configurable. It could provide one if there is a consensus of a default. We should see Boost.Conversion customization as if we were adding some methods to one of the classes. For the string to float conversions, it is as if we were adding explicit operator float() const; to the std::string class. " I still maintain that this is the case, there is no sane way to let the user select between Convert or LexicalCast at the moment and possibly Coerce in the future and it's not something this library should be tackling. - STL conversions I believe these functions are of little use as when I would have to convert a list of integers to a list of doubles I'd simply write a loop (possibly aided by BOOST_FOREACH) instead of looking up a library (and reading the necessary documentation) to do it for me. With the offered customization points the cure seems to be worse than the disease, if I had to convert a std::pair<int, int> to a std::pair<double, double> I'd write a quick function to do so. The Conversion documentation however shows the following: template <typename Target1, typename Target2, typename Source1, typename Source2> struct implicit_converter_cp< std::pair<Target1,Target2>, std::pair<Source1, Source2> , typename enable_if_c< is_extrinsically_convertible<Source1, Target1>::value && is_extrinsically_convertible<Source2, Target2>::value >::type > : true_type { std::pair<Target1, Target2> operator()(std::pair<Source1, Source2>& v) { return std::pair<T1, T2>(implicit_convert_to<T1>(from.first), implicit_convert_to<T2>(from.second)); } }; This is a more generic solution but it seems like an awful lot of trouble for something this simple. - The Boost conversions These do seem very useful, but as discussed in the pre-review: "You are right and the same applies to any type-to-type conversion. And maybe this is the MAJOR flaw of Boost.Conversion: to think that we can define extrinsically THE conversion between two types. Every body admit that if a class T defines a constructor from a std::string THE conversion from std::string to T is the one defined by this constructor." I do believe that this library isn't the place for the conversions, they should be added to the specific libraries themselves in the form of constructors. * Did you try to use the library? With what compiler? Did you have any problems? I've tried several examples with GCC 4.2.1 (the default shipped with OS X), 4.5.3 and clang 2.9 on OS X. Both versions of GCC worked fine, clang however was unable to compile the examples with the following error: In file included from no_throw.cpp:13: In file included from ../../../boost/conversion/include.hpp:20: In file included from ../../../boost/conversion/convert_to.hpp:22: In file included from ../../../boost/conversion/explicit_convert_to.hpp:38: In file included from ../../../boost/conversion/implicit_convert_to.hpp:40: In file included from ../../../boost/conversion/type_traits/is_convertible.hpp:25: In file included from ../../../../library/boost-trunk/boost/fusion/tuple.hpp:10: In file included from ../../../../library/boost-trunk/boost/fusion/tuple/tuple.hpp:11: In file included from ../../../../library/boost-trunk/boost/fusion/container/vector/vector.hpp:11: In file included from ../../../../library/boost-trunk/boost/fusion/container/vector/detail/vector_n_chooser.hpp:14: In file included from ../../../../library/boost-trunk/boost/fusion/container/vector/vector10.hpp:14: In file included from ../../../../library/boost-trunk/boost/fusion/sequence/intrinsic/begin.hpp:17: In file included from ../../../../library/boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:11: In file included from ../../../../library/boost-trunk/boost/fusion/iterator/segmented_iterator.hpp:13: In file included from ../../../../library/boost-trunk/boost/fusion/container/list/cons.hpp:14: In file included from ../../../../library/boost-trunk/boost/fusion/sequence/intrinsic/end.hpp:17: ../../../../library/boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_end.hpp:33:70: error: invalid use of incomplete type 'fusion::nil' segmented_end_impl<Sequence, fusion::nil>::call(seq, fusion::nil())); ^~~~~~~~~~~~~ Not sure what's going on here exactly. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Something between a quick reading and an in-depth study. * Are you knowledgeable about the problem domain? As the author of Coerce I'm knowledgeable about the string-to-type and type-to-string domain, less so about the generic type-to-type domain though. * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. NO, the library should not be accepted as a Boost library in the current form. However the following should be done: - There are several type traits which can possibly be added to Boost.TypeTraits. This is not something I can judge, it is up to the auteurs of Conversion and TypeTraits to judge which are useful. - The conversions regarding Boost classes should be added to the respective libraries in the form of constructors if the respective auteurs believe this adds value to their library. Kind regards, Jeroen Habraken

3 4

[GSoC] Coerce summary and request for feedback
by Jeroen Habraken 23 Aug '11

23 Aug '11

Hi, As the Google Summer of Code has ended yesterday I'd like to thank Google and my mentor Hartmut Kaiser for the opportunity and guidance. Whilst Coerce is an on-going project (it's more than a year old already, time does fly when you're having fun) the GSoC sped up development significantly. To summarize Coerce for those not familiar with it, it's a type-to-string and string-to-type conversion library aiming at speed and extensibility. During the GSoC the following major things have happend: * Added tests, catching bugs and allowing me to prevent bugs in the future (hopefully). * Rewritten the tag system to be more flexible. * Added documentation, the latest version of which can be found over at http://vexocide.org/coerce/. In general the library matured, and while it's not done yet (the documentation in particular) I believe it's approaching production stability with the number of impacting changes dropping significantly over time. The current code can be found at http://svn.boost.org/svn/boost/sandbox/coerce/ and as usual I'd be grateful for any comments or critique. If you have questions do not hesitate to contact me. Kind regards, Jeroen Habraken P.S. If you're still using construe_cast (a previous incarnation of this project) please consider migrating to Coerce as I plan on removing https://github.com/VeXocide/construe_cast soon.

1 0

[Units] test_trig fails on Sandia-darwin-4.4 (caused by compile-time evaluation of math functions)
by Michel MORIN 23 Aug '11

23 Aug '11

The Units' test (libs/units/test/test_trig.cpp) fails on Sandia-darwin-4.4: http://tinyurl.com/3wherck The failure is caused by the fact that the results of `std::acos(0.2)` and `std::acos(d)` (double d = 0.2) are NOT equal on Sandia-darwin-4.4. On gcc-4.3 and newer versions, built-in math functions having constant arguments are evaluated at compile time using the MPFR (Multiple Precision Floating-Point Reliable) library. This happens even if optimization is disabled. So, the results of std::acos(0.2); // evaluated by the MPFR library at compile time and double d = 0.2; std::acos(d); // evaluated by the built-in function at run time are different. (If we compile with optimization enabled, the latter code is also evaluated by the MPFR library at compile time.) The solution to this problem is * Change BOOST_CHECK_EQUAL to BOOST_CHECK_CLOSE_FRACTION. or * Change `std::acos(0.2)` to `std::acos(d)` (with `double d = 0.2`) An interesting thing is that the test fails only on Sandia-darwin (x86-64) platform. On other platforms using gcc 4.3-4.6, the test runs successfully. I suspect that they have 80-bit registers and so the result of `std::acos(d)` is as accurate as the result of the MPFR library. Do you have any thoughts about this? Regards, Michel

3 3

[odeint] GSoC Summary and Feedback request
by Mario Mulansky 23 Aug '11

23 Aug '11

Hi, this is a summary of the progress of the odeint-library during this years GSoC. First of all I would like to thank Andrew for mentoring this project and also for the many fruitful comments and hints he gave during the past months. The aim of the project was to finalize odeint and prepare it for a boost review. This goal has been, more or less, achieved, I think. Although some work on docs and maybe some minor usability improvements are to be done we think we have reached a state of development ready for a review and we might try take this step in the near future. The puropose of odeint is to provide algorithms to numerically solve ordinary differential equations (ODEs) given as initial value problems: x'(t) = f(x,t) , x(0) = x0. It is written by Karsten Ahnert and myself. Please visit the docs to find out more about the features and abilities of odeint: http://headmyshoulder.github.com/odeint-v2/doc/index.html During the GSoC project, we switched from a svn branch in the boost sandbox to a new git project called odeint-v2: https://github.com/headmyshoulder/odeint-v2 In terms of code, I have made the following improvements to odeint: * Implementation and performance tests of a generic Runge-Kutta algorithm. * Implementation of several algorithms using the generic Runge-Kutta scheme (rk4, rk54ck, rk78) * Redesign of the construction/destruction of temporary states by use of a state_wrapper * Redesign of the resizing functionality by usage of boost::bind * Redesing of the algebra implementation to now use instances instead of static functions. * Creating mkl_operations to make use of Intel's MKL for optimal performance * major refactorings (e.g. renaming stepper classes) * Implementation of a Bulirsch-Stoer stepper with dense output * Improvement of integrate functions so they have consistent behavior * Adding integrate_times function to allow for observation at user defined time points * Adding unit tests for integrate functions Additionally, I worked on the documentation: * Created an overview over all implemented algorithms * Adding a resizing example to the tutorials section * Adding a description of the integrate functions * Adding a brief concept description of steppers, system and observer * Adding a brief overview on the Algebra/Operations and how they interact Besides his fruitful input and discussions related to my work presented above, Karsten also put quite some effort into odeint during the GSoC period, e.g. providing examples and tutorials in the docs section or adding multistep and implicit algorithms (adams-bashforth, rosenbrock4). We are very happy about any feedback on the work done within this GSoC or on odeint in general. If you have any further question please feel also invited to contact us. Finally, I want to thank the boost communtity for giving me the possibility to take part in this years GSoC as part of the boost organization. I have learned a lot during this time and I think odeint took a major step forward in terms of design and extent. Regards, Mario

4 5

Boost.Conversion review
by Gordon Woodhull 22 Aug '11

22 Aug '11

Hi all, The review of Vicente Botet Escriba's Conversion library starts this Saturday August 20 and continues through August 29. This library provides a general system for type-to-type conversion. As such, it can be thought of either as a substitute for overloading static_cast, or as an alternative to lexical_cast when the intermediate conversion to text is not wanted. The code is in the sandbox: http://svn.boost.org/svn/boost/sandbox/conversion/ And the docs are here: http://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/h… I'll send out a formal announcement when the review begins, but I wanted to send out this reminder because participation in summer months tends to be somewhat low. Your review and/or discussion would be greatly appreciated. As always, please post to the main Boost list if possible, or the boost-users list, or you can send your review directly to the Review Managers. Thanks, Gordon Woodhull, Review Manager Espen Harlinn, Review Manager Assistant

5 13

[containers] Templated map::find?
by Lars Viklund 22 Aug '11

22 Aug '11

Hi list. I was asked today why the std::map container didn't have templated versions of functions like find, lower_bound, and so on. I could not give a good answer on why there could not exist such a thing, assuming that the comparator had sufficient symmetric overloads for the real Key type and the FauxKey that the query would be performed with. Would something like this be possible to add to Boost.Containers, considering that going through the typical standard routes would have a latency of a couple years at best? I'm told that the Boost.Intrusive containers already supports this. Some use cases would be querying with a type that's convertible (in an expensive way) to the held key type, or querying with a key type that has only the fields that affect ordering in the case of a rich key type. -- Lars Viklund | zao(a)acc.umu.se

4 4

[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 19 Aug '11

19 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

[filesystem] Documentation error?
by John Maddock 17 Aug '11

17 Aug '11

The filesystem docs mention: #include <boost/filesystem> But of course no such file exists. John.

1 0

[vmd] Variadic Macro Data library updated to version 1.5 in the sandbox
by Edward Diener 17 Aug '11

17 Aug '11

I have updated the variadic_macro_data library in the sandbox 'variadic_macro_data' directory to version 1.5. The variadic_macro_data library, or VMD for short. adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. The changes in this version are: 1) The library now operates in one of two modes. The 'native' mode, which is the default, uses the library's own coding for various macros. The 'pplib' mode uses the code of the Boost PP library on the trunk for various macros. The documentation gives the equivalent Boost PP trunk macros for VMD macros. 2) Individual header files can be included instead of the vmd.hpp header file. 3) Macros have been added for detecting and removing beginning parens. 4) A macro has been added for testing for emptiness using variadic macros. 5) Macros have been added for verifying Boost PP data types. 6) Added control macros for controlling the variadic macro availability, mode, and data verification. There is a readme.txt in the top-level sandbox directory, for anyone browsing the sandbox. There is a build.txt file in the doc subdirectory for building the documentation and running the tests. The documentation is also included as part of the sandbox files for those who can not build the docs. The library has been tested and works with gcc 3.3.3, 3.4.2, 3.4.5, 4.3.0, 4.4.0, 4.5.0-1, 4.5.2-1, 4.6.0 and VC++ 8.0, 9.0, 10.0. It should also work with other compilers which support variadic macros. Questions, comments, suggestions, and bug reports are all welcome.

1 1

New version of Boost.Algorithm (proposed) in the vault
by Marshall Clow 17 Aug '11

17 Aug '11

<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! Thanks! -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

3 2

Help tracking down a GCC codegen issue
by Matt Fischer 17 Aug '11

17 Aug '11

Hi all. I'm trying to compile boost under GCC for ARM, and am running into an instance of some bad assembly code being generated. The actual problem seems likely to be an issue with GCC itself, or possibly some kind of modification that the vendor, CodeSourcery, made to it. I've contacted them about the problem [1], but in order to diagnose it, they need a reduced test case that doesn't involve the boost library. I'm attempting to dig out the relevant code and use it to construct a test case, but I'm having some trouble navigating the boost codebase, and was wondering if anybody could provide some assistance. A program that illustrates the problem is the following (compiled on Windows, using GCC 4.5.2 with Boost 1.40): ----------------------------------------------------------- #include <boost/signal.hpp> bool func() { return false; } int main(int argc, char *argv[]) { boost::signal<bool ()> sig; sig.connect(func); bool result = sig(); } ----------------------------------------------------------- Normally this works fine, but if I compile for GCC under ARM with -mthumb -Os, one of the instantiated template functions has some bogus assembly code in it (prepare for wall-of-text): 00000000 <boost::detail::postfix_increment_result<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, bool const&, boost::single_pass_traversal_tag>::type boost::operator++<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int (boost::iterator_facade<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>&, int)>: 0: b537 push {r0, r1, r2, r4, r5, lr} 2: 1c05 adds r5, r0, #0 4: ac01 add r4, sp, #4 6: 1c29 adds r1, r5, #0 8: 1c20 adds r0, r4, #0 a: f7ff fffe bl 0 <boost::detail::postfix_increment_result<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, bool const&, boost::single_pass_traversal_tag>::type boost::operator++<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>(boost::iterator_facade<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>&, int)> e: 1c28 adds r0, r5, #0 10: f7ff fffe bl 0 <boost::detail::postfix_increment_result<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, bool const&, boost::single_pass_traversal_tag>::type boost::operator++<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>(boost::iterator_facade<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>&, int)> 14: 7820 ldrb r0, [r4, #0] 16: bc37 pop {r0, r1, r2, r4, r5} 18: bc02 pop {r1} 1a: 4708 bx r1 The error is on line 14 and 16: we load up the return value from this function (a bool) into r0 in preparation for return, but then turn around and pop off a bunch of values from the stack, placing one into r0, which overwrites the return value and causes garbage to be returned to the caller. If I can produce a standalone test function that illustrates the problem, the compiler folks can probably figure it out. I've been trying to make one, but all of the template magic is making it difficult for me to track down where this function is coming from in the source code, and what a suitable standalone equivalent might be. Is there anybody who is familiar with all of the slot code that might be able to help out with this? Thanks, Matt 1. Original posting at http://www.codesourcery.com/archives/arm-gnu/msg04302.html

1 0

How to use BCP
by William Voorhees 17 Aug '11

17 Aug '11

I'm updating a small C program to take in a options from either environment variables, or a config file and having long heard of boost as a great resource decided to give the program_options module a try. Since the utility is small and I don't have any current plans for other boost functionality it doesn't make sense to include the full BOOST library, so I tried to use bcp to get only the files I'm interested in. I was able to get a subset of boost code that I should be able to use with bcp, however I don't know how to compile the program_options library for linking in my code. >From a bit of googling it looks like bjam is the build tool, but it doesn't seem to be included with the subset of files I have. How would I go about incorporating boost so that all of the necessary source and associated utilities are included for an end user to build from. I should be able to issue a series of simple commands (looks like ./bootstrap.sh and make) to build and install my library with statically linked in boost. -Will Voorhees

3 5

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

17 Aug '11

El 17/08/2011 12:20, Diederick C. Niehorster escribió: > Some performance tests might be nice here too (and the code for > generating them should be incorporated in the distribution), comparing > to std:: libraries shipped with the popular compilers. It'll help sell > your library and it'll serve as a nice benchmark later as vendors > update their standard library implementations. At least, I'd be > interested in such information and if test code is avaiable, I could > easily run the testcases myself. This is a good idea, but it'd require a huge amount of work if we think about an extensive benchamark framework. Maybe some basic tests?

1 0

[Containers Library Review] The review of the Containers library by Ion Gaztanaga starts today
by John Maddock 17 Aug '11

17 Aug '11

The review of the containers library by Ion Gaztanaga starts today, to summarize the library: "Boost.Container library implements several well-known containers, including STL containers. The aim of the library is to offers advanced features not present in standard containers or to offer the latest standard draft features for compilers that comply with C++03. In short, what does Boost.Container offer? * Move semantics are implemented, including move emulation for pre-C++0x compilers. * New advanced features (e.g. placement insertion, recursive containers) are present. * Containers support stateful allocators and are compatible with Boost.Interprocess (they can be safely placed in shared memory). * The library offers new useful containers: o flat_map, flat_set, flat_multiset and flat_multiset: drop-in replacements for standard associative containers but more memory friendly and with faster searches. o stable_vector: a std::list and std::vector hybrid with random-access iterators that offers iterator stability in insertions and erasures. o slist: the classic pre-standard singly linked list container." Documentation from the library may be viewed online here: file:///M:/data/boost/sandbox/move/libs/container/doc/html/index.html The source may be accessed from the "move" directory of the sandbox SVN or downloaded from http://www.drivehq.com/web/igaztanaga/boost_container.zip. Note that this download contains a copy of the accepted, but not yet release, Boost.Move library - extract the zip over a copy of Boost-1.47 to get a full working copy. Review comments might like to answer the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Regards, John Maddock.

10 18

Re: [boost] [containers review] A reminder that the containers review ends tomorrow
by John Maddock 17 Aug '11

17 Aug '11

The containers library review is now officially over. However, there are still a few drips a drabs of reviews coming in.... are there any more still pending? Thanks, John.

3 2

Re: [boost] [gsoc] Request Feedback for Boost.Ustr Unicode String Adapter
by Stewart, Robert 16 Aug '11

16 Aug '11

Yakov Galka wrote: > On Fri, Aug 12, 2011 at 15:04, Matus Chochlik > <chochlik(a)gmail.com> wrote: > > On Fri, Aug 12, 2011 at 1:08 PM, Yakov Galka > > <ybungalobill(a)gmail.com> rote: > > > On Fri, Aug 12, 2011 at 12:00, Matus Chochlik > > > <chochlik(a)gmail.com> wrote: > > >> On Fri, Aug 12, 2011 at 9:57 AM, Daniel James > > >> <dnljms(a)gmail.com> wrote: > > >> > On 11 August 2011 12:57, Artyom Beilis > > >> > <artyomtnk(a)yahoo.com> wrote: > > > >> // by default expect UTF8 > > >> text(const std::string& str) > > >> { > > >> assert(is_utf8(str.begin(), str.end())); > > >> store(str); > > >> } > > > > > > What you are doing is, in fact, forcing the assumed > > > encoding of std::string to UTF-8. You just said you > > > think it's a bad idea. > > > > No, I'm proposing to implement a *new* class that > > will store the text in UTF8 encoding and if during > > the construction no encoding is specified, then it > > is assumed that the particular std::string is already > > in UTF8. > > > This is *very* different from imposing > > an encoding on std::string which is already > > used in many situations with other encodings. > > i.e. my approach does not break any existing code. > > Sorry, your arguments start to look non-constructive to me. > Correct me where I'm wrong in the following reasoning. > > (1) You object to UTF-8 strings in boost interface because > someone may pass something other than UTF-8 there and it's > going to be undetected at compile time: > > namespace boost { void func(const std::string& a); } // UTF-8 > boost::func(non_utf_string); //oops > > You're proposing a `text` class that is meant to somehow > overcome this problem. So you change the boost interface > to accept `text` but user code is left unchanged...: > > namespace boost { void func(const text& a); } > boost::func(non_utf_string); //oops, the std::string default > constructor is called. > > Yes, you can make this constructor explicit, so the above code > stops compiling and the user must write explicitly: > boost::func(text(non_utf_string)); > > But then there is nothing in your proposal that makes > std::string utf-8 encoded by 'default'. Default == implicit. As soon as the client did a cast, the client made the claim that non_utf_string met the requirements of the text class' constructor. The problem is that of the client misusing the class by an ill-advised cast. What's more, I think Soares indicated a debug-build validation that the argument indeed was UTF-8. I don't see a problem in that design, once the constructor is explicit. > > Besided it does not harm you in any way > > It does. I already use UTF-8 for all my strings, even on > windows, and I don't want the code-bloat of all these > conversions (even if they're no-ops). What code bloat do you get from NOPs? Sure, there is more compilation time for the compiler to parse the text code and then for the optimizer to streamline it into a NOP, but even that is very likely negligible. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2

[Review] Lockfree review: today (July 28th) is the last day
by Hartmut Kaiser 16 Aug '11

16 Aug '11

All, Today is the last day of the review of Tim Blechmann's Lockfree library. If you're interested in this library, please consider contributing a review! If you need more time, please contact me privately. Please see the original (slightly corrected) announcement below: ----------------------------------------------------- About the library: Boost.Lockfree provides implementations of lock-free data structures. Lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. Lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. The following data structures are provided: - boost::lockfree::fifo, a lock-free fifo queue - boost::lockfree::stack, a lock-free stack - boost::lockfree::ringbuffer, a wait-free single-producer/single-consumer ringbuffer. The library is accessible from here: http://tim.klingt.org/boost_lockfree.tar.gz. Boost.Lockfree depends on C++0x atomics. They are not well supported with current compilers yet. For this reason Boost.Lockfree depends on the *unreviewed* Boost.Atomic library, that emulates C++0x atomics for C++98. This review is about Boost.Lockfree and not about Boost.Atomic, although it is included in the tarball and the git repository. If Boost.Lockfree will be accepted, it won't be merged into trunk before Boost.Atomic is accepted. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

6 7

Re: [boost] [gsoc] Request Feedback for Boost.Ustr Unicode String
by Joe Mucchiello 16 Aug '11

16 Aug '11

>> text t6(pq_some_func(), textenc::libpq()); >> > You don't need it. You're proposing a design that tries to solve a > non-existing problem. There is no such diversity of encodings in the > interfaces. I don't know what is libpq, but it either uses UTF-8 in which > case you write: > > string t6 = pq_some_func(); > I think the point here that you don't need to know the encoding of libpq. If the policy is that you use this text class and that to use it you convert it using the standard text constructor that takes the listed tag. For libraries that use UTF-8 the conversion is a no-op. Adapting a new library to the "boost way" just involves adding a new tag to the textenc namespace and, if necessary, writing a new pair conversion routines.

2 1

[1.44][serialization] Link error with polymorphic archives and BOOST_CLASS_EXPORT
by Ralph Tandetzky 15 Aug '11

15 Aug '11

Hi, I discovered a problem, that has been previously discussed in a post from 2011-01-21 which has the same title. No concluding answer was given there, so I post the problem again. Essentially, the following code compiles but doesn't link: -------------------------- #include <sstream> #include <boost/serialization/export.hpp> #include <boost/archive/polymorphic_binary_oarchive.hpp> class A { public: template<class Archive> void serialize(Archive & ar, const unsigned version) { } }; BOOST_CLASS_EXPORT(A) int main() { A a; std::ostringstream os; boost::archive::polymorphic_binary_oarchive oa(os); oa & a; } -------------------------- Removing the line with "BOOST_CLASS_EXPORT(A)" or turning the "polymorphic_binary_oarchive" into a "binary_oarchive" removes the linker error. With Visual Studio 10 the following error message occurs: main.obj : error LNK2001: unresolved external symbol "public: static void __cdecl boost::archive::detail::archive_serializer_map<class boost::archive::detail::polymorphic_oarchive_route<class boost::archive::binary_oarchive_impl<class boost::archive::binary_oarchive,char,struct std::char_traits<char> > > >::erase(class boost::archive::detail::basic_serializer const *)" (?erase@?$archive_serializer_map@V?$polymorphic_oarchive_route@V?$binary_oarchive_impl@Vbinary_oarchive@archive@boost@@DU?$char_traits@D@std@@@archive@boost@@@detail@archive@boost@@@detail@archive@boost@@SAXPBVbasic_serializer@234@@Z) 1>main.obj : error LNK2001: unresolved external symbol "public: static bool __cdecl boost::archive::detail::archive_serializer_map<class boost::archive::detail::polymorphic_oarchive_route<class boost::archive::binary_oarchive_impl<class boost::archive::binary_oarchive,char,struct std::char_traits<char> > > >::insert(class boost::archive::detail::basic_serializer const *)" (?insert@?$archive_serializer_map@V?$polymorphic_oarchive_route@V?$binary_oarchive_impl@Vbinary_oarchive@archive@boost@@DU?$char_traits@D@std@@@archive@boost@@@detail@archive@boost@@@detail@archive@boost@@SA_NPBVbasic_serializer@234@@Z) Is there something wrong with the serialization library? Regards, Ralph Tandetzky.

2 2

Review Request: Singularity
by Ben Robinson 15 Aug '11

15 Aug '11

Hello, I would like to thank the Boost community for their invaluable feedback regarding the features and implementation details of Singularity. Singularity has been greatly refined and I am now requesting a formal review. I have compiled and run Singularity on 4 different compilers: GCC 4.5, MSVC++ 2010, the CL2000 TI compiler targeting the 2803x processor, and the Green Hills compiler targeting the Cortex-A8 ARM processor. The documentation, implementation and Boost unittests are available on GitHub at https://github.com/icaretaker/Singularity. Please note, that I have also implemented Singularity in C++11 using perfect function forwarding in the /cpp11 subdirectory, but that is not part of the submission, unless Boost is accepting C++11 libraries at this time. I will now include an excerpt of the documentation file "singularity.htm" which is part of the GitHub download: Introduction<file:///C:/home/ben/workspace_boost/boost/source/common/libs/singularity/singularity.htm#singularity.introduction> The Singularity Design Pattern allows you to restrict any class to a single instance. Singularity gives you direct control over the lifetime of the object, and does not require you to grant global access to the object, nor limit you to a single constructor for that object. Motivation<file:///C:/home/ben/workspace_boost/boost/source/common/libs/singularity/singularity.htm#singularity.motivation> The ability to restrict a class to a single instance is an important technique. While the commonly used Singleton Design Pattern achieves the desired goal, it introduces three undesirable limitations, namely: 1. Lifetime: Singleton introduces lifetime management complexities. The undefined destruction order of multiple singletons is just one example. 2. Scope: Singletons are always globally accessible. Accessibility should be orthogonal to restrictions on the number of instances. 3. Initialization: Singletons typically restricts the class to the default constructor. This makes Singleton difficult for classes which require non-default constructors. Like Singleton, Singularity restricts a class to a single instance. However Singularity does not suffer from lifetime, scoping and initialization problems. The following are the advantages of Singularity over Singleton: 1. The lifetime of the single object is bounded by calls to create() and destroy(). This lifetime is managed similiarly to objects bounded by calls to new() and delete(). 2. Singularity does not force global access to the instance. If global access is required, then a globally accessible get_global() function can be enabled upon creation of the instance. 3. Singularities of objects can be created using any available constructor for that object. Thank you, Ben Robinson, Ph.D.

2 1

Re: [boost] [containers review] A reminder that the containers review ends tomorrow
by John Maddock 14 Aug '11

14 Aug '11

> Just a quick reminder that the containers lib review ends tomorrow - there > have been lots of good comments, but not so many reviews - so now's your > chance ;-) If there are any reviews pending that are likely to be late > please let me know so we can extend the review period. This review was sent to me privately, posted here for comment: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Review of Boost.Contianer by Zoltán Tóth I am not an expert of C++ containers topic, but use them daily in my algorithm programming job. C++ 1998 STL containers have serious deficiencies, I would say especially node-based STL containers are not usable at all for performance-critical algorithms due to their memory allocator treatment/requirements. I have written own implementations for STL vector, set, list, ., because I was not satisfied with STL containers. Therefore a replacement of those in Boost could be a terribly useful library. I did not try to use the library. I just quickly read the documentation, and found that it is very poor. Here are the deficiencies I have found in the documentation: 1. One of the most important reason to replace the STL containers is the treatment of custom memory allocators. However the documentation tells only a single sentence about it: "Containers support stateful allocators and are compatible with Boost.Interprocess (they can be safely placed in shared memory). " 1. It does not specify how the containers are swapped: are the allocators swapped with the container? 2. Most STL implementations have been supporting stateful allocators for years now. So it is not big news. However I am not satisfied with the way they might do it. For example Visual Studio's STL implementation require the allocator type to have a template copy constructor. Such allocator types are difficult to be implemented in efficient, threads-friendly way. (This is the reason I have implemented my own set implementation instead of STL::set) The documentation does not tell whether this library have a similar requirement. If no, that would be big news. 2. The documentation says: "All containers offered by Boost.Container can be used in recursive data structures, something that is not guaranteed by the standard". To understand the value of this feature better I as a user would like to know more about this topic. Please insert links or own text here that explain why does the standard not guarantee this. Is there any danger or difficulty in it? If yes: how does this library overcome them. IMHO Boost.Containers should not (yet) be accepted (because of the lack of a detailed documentation).

3 2

[locale] Slides for the lecture on Boost.Locale
by Artyom Beilis 14 Aug '11

14 Aug '11

Hello, I had given a lecture about the Boost.Locale library at the annual Israeli FOSS conference "August Penguin". The slides can be found there: - http://art-blog.no-ip.info/files/August-Pinguin-Boost-Locale.pdf - http://art-blog.no-ip.info/files/August-Pinguin-Boost-Locale.odp I hope the video would be available soon. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

2 2

Introduction
by Andrew Hundt 14 Aug '11

14 Aug '11

Hi everyone, I'm Andrew Hundt and I've been doing C++ development for about 3 years. I've also been following the boost mailing lists for about the last two years. I've occasionally asked questions on this list during that time, but I've never introduced myself. I'm at Carnegie Mellon University in a staff position, and I have some possible contributions based on my work there that I've been hoping to at least gauge interest on. However, I wanted to introduce myself first, so greetings! Cheers! Andrew Hundt

2 1

[uuid][release] Changelog for 1.47.0 does not properly warn about critical bug
by Eric Niebler 13 Aug '11

13 Aug '11

Cross-posting to the developers list, fixing the title. This sounds like a serious bug, possibly worthy of a point release. Can anybody confirm and chime in? On 8/5/2011 4:20 AM, Paul Harris wrote: > Hello, I discovered this bug by accident > https://svn.boost.org/trac/boost/changeset/68866 > which was only linked via the ticket mentioned below, > > The code below demonstrates that ANY wide-character string of the same > length resolves to the same UUID ! > > Thats pretty darn serious, I expected to see a much more serious mention > in the Changelog in boost 1.47.0... for UUID, there was only a mention > of a few tickets > including this one: > https://svn.boost.org/trac/boost/ticket/5145 > which only mentioned a WARNING in the description ! > "Fixed warning: use of logical && with constant operand; switch to > bitwise & or remove constant [-Wconstant-logical-operand]" > > Surely it should say something like "UUIDs for wide character strings > are totally wrong" > > Note also that the Changelog link for UUID goes to Utility, not UUID. > > > The code: > > > #include <boost/uuid/name_generator.hpp> > #include <boost/uuid/nil_generator.hpp> > #include <boost/uuid/uuid_io.hpp> > #include <iostream> > > using namespace boost::uuids; > using namespace std; > > int main() > { > { > cout << "WIDE" << endl; > const wchar_t* a = L"one long string that is something like this > and that blahh"; > const wchar_t* b = L"hello there you long long string that looks > nothing like t"; > > nil_generator nil; > name_generator na(nil()); > name_generator nb(nil()); > > uuid ua = na(a); > uuid ub = nb(b); > > cout << to_string(ua) << endl; > cout << to_string(ub) << endl; > } > > { > cout << "NARROW" << endl; > const char* a = "one long string that is something like this and > that blahh"; > const char* b = "hello there you long long string that looks > nothing like t"; > > nil_generator nil; > name_generator na(nil()); > name_generator nb(nil()); > > uuid ua = na(a); > uuid ub = nb(b); > > cout << to_string(ua) << endl; > cout << to_string(ub) << endl; > } > > return 0; > } > > > > the result: > > $ g++ main.cpp && ./a.out > WIDE > 4ffa48af-9685-5089-97ac-fe6627ead94c > 4ffa48af-9685-5089-97ac-fe6627ead94c > NARROW > 73030b72-a864-5c7b-9963-c0bedff1283e > da8943a6-26c9-5641-bd37-427b1b70d619 > $ > > > The two different wchar_t strings resolve to the same uuid !!! > > What am I doing wrong? > > thanks > Paul -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[serialization] overloading load_construct_data: no accessible constructor at all
by Griffin Howlett 13 Aug '11

13 Aug '11

Hey, so I'm using the boost::serialization library, and I'm trying to override how a class is constructed, since it has no default constructor. This is demonstrated here<http://www.boost.org/doc/libs/1_47_0/libs/serialization/doc/serialization.h…>. To me it appears the function ONLY takes the `class* t` and then sets it to point to a newly constructed object. If I'm wrong, this is definitely the source of my error. However, the only way to construct my class is by using another classes `create()` function, meaning I need to stray from the code in the example (this is stated in the boost::serialization namespace): `::new(t)my_class(attribute);` I tried simply calling the create function and setting `t` equal to the returned pointer, but this doesn't seem to work because right after the `load_construct_data function`, and in the `serialization function`, the given `myClass&` is not the same as what I set 't' to. *How do I do whatever ::new(t) is doing so the object created using the create function follows through into the serialize/other functions?* [1]: http://www.boost.org/doc/libs/1_47_0/libs/serialization/doc/serialization.h…

2 1

[thread] basic mutex problem
by Greg Rubino 13 Aug '11

13 Aug '11

Hi Boost.Thread maintainer(s)/expert(s)/user(s) like me, I'm having an issue with boost::mutex. I'm not really an expert in concurrency, and there's something wrong with my thread_db library, so I'm having some trouble debugging (for now). I tend to think it's something in my code, but I thought maybe someone on the list would take a look at it. The code is pretty minimal, but let me know if I should reduce it further. I'm leaving out the #includes, because I'm pretty sure those are ok: using namespace std; using namespace boost::phoenix; namespace phoenix_args = boost::phoenix::arg_names; namespace posix_time = boost::posix_time; boost::mutex g_mutex; struct random_activity_planner { random_activity_planner(vector<activity>& a, posix_time::ptime o) : activities(a) , origin(o) {} void operator()() { g_mutex.lock(); posix_time::ptime start(origin + posix_time::seconds(rand() % 1000)); posix_time::ptime end(start + posix_time::seconds(rand() % 1000)); activities.push_back(activity(start, end)); g_mutex.unlock(); } vector<activity>& activities; const posix_time::ptime& origin; }; int main(int argc, char** argv) { if(argc != 2) return 1; size_t activity_count = boost::lexical_cast<size_t>(argv[1]); vector<activity> activities; boost::thread_group random_activity_planners; posix_time::ptime origin(posix_time::second_clock::universal_time()); srand(time(NULL)); for(size_t i = 0; i < activity_count; ++i) { random_activity_planners.create_thread(random_activity_planner(activities, origin)); } random_activity_planners.join_all(); cout << "all activities: " << endl; for_each(activities.begin() , activities.end() , cout << phoenix_args::_1 << endl); vector<activity> schedule; greedy_activity_selector(activities.begin() , activities.end() , back_inserter(schedule)); cout << "scheduled activities: " << endl; for_each(schedule.begin() , schedule.end() , cout << phoenix_args::_1 << endl); return 0; } [END] The problem is that the last "activity" is not being pushed onto the shared vector in the . I'm sure there are some stylistic problems with the code, but its purpose is just to demonstrate an algorithm. At the following for_each() call: for_each(activities.begin() , activities.end() , cout << phoenix_args::_1 << endl); I find out, via a gregorian::bad_year exception, that the final activity has not been initialized. I have omitted the definition for activity, but it's pretty simple. It has only one member (a posix_time::duration that defaults to neg_infin => pos_infin ), which is why I suspect that the final call to random_activity_selector::operator() is not completing before the for_each() call that succeeds it in the source. I thought that join_all() would prevent this from happening. Is there something wrong with my code? I left some stuff out, because I didn't want to inundate the reader with irrelevant details, so please let me know if I left out anything crucial. Also, I am aware that I don't need to be using threads here, but I am, and I don't understand why it's not working. Thanks! Greg

4 6

enable_if and non-template member functions?
by John Maddock 13 Aug '11

13 Aug '11

Folks, I have a problem with enable_if: it works just dandy for template member functions in my class, but I have some *non-template* member functions and constructors that I want to enable only if the template is instantiated with template args that meet certain criteria. Seems like I can't do this with enable_if as it then generates an invalid class definition. I guess I could use base classes, and/or partial specialization, but both involve a lot of code duplication I'd rather not have. Anyone any ideas? Thanks, John.

11 21

[review] a mini-review of containers
by Thorsten Ottosen 12 Aug '11

12 Aug '11

Hi Ion & John, I apologize for not having time to do a full review. I base these comments mainly on the documentation. I have been using the flat_map/flat_set stuff for years, both in my own PhD work and in production code in my company. A. I find the motivation sufficient; I guess the new allocator concept in C++11 would allow one to use interprocess allocators, but as this won't work with older compiler, I can see the need. Also, since the standard does not e.g. guarantee nothrow of default constructors, this library provides an escape route if one wishes to have portable code. The recursive structure is also a nice feature. B. The new containers are very useful. I have not used stable vector before, but I note that boost::ptr_vector provides similar guarantees. C. slist should probably be called forward_list like in the new standard, and should probably be interface compatible with the standard design. D. I skimmed some of the unit-tests. I saw that some sections are commented out. Maybe a little more testing could be done. E. I didn't look at the map/set implementation; do you use the same optimization as Boost.MultiIndex that saves the color in the parent pointer (as a bit). F. I noticed that you use std::reverse_iterator. Why not use boost::reverse_iterator? IIRC, it has some minor benefits. G. flat_xxx. (a) We already discussed the issue of exposing the underlyng container. I think that would be most natural, and provides use with an escape hatch when they need it. (b) I think all these containers should allow one to decide the wrapped sequence. I have several types of sequences I would like to be able to use. Sure it takes some work to handle alocators and such, but it makes these much more useful IMO. (c) At some point, long time ago, I suggested that one should be able to construct a set/map with an already sorted sequence. This was based on actual use cases; one sometimes have access to an already sorted sequence. I think the most elegant way to support this would be to make a new constructor that forwards; that is, use the same approach as boost::optional such that we can say flat_xxx cont( boost::in_place(...) ); ------------------------------------- So, should this library be accepted into Boost? Yes. But I would like to see G.b and G.c addressed first. kind regards Thorsten

2 1

[iostreams] null_sink slower than array_sink
by Daniel Larimer 12 Aug '11

12 Aug '11

I was thinking about using boost::iostreams in place of my own 'array stream', but was surprised by the poor performance. When doing RPC calls, I often use the following pattern: a) calculate buffer space required to serialize arguments b) allocate buffer space c) serialize into buffer I use a stream type with an interface of write(),read(), putc(), getc() etc similar to iostreams. In doing some basic tests serializing a struct I get the following numbers: stringstream: 2.4e6 times/sec stream<array_sink>: 3.2e6 times/sec stream<null_sink>: 1.5e6 times/sec mystream<char*>: 8.7e6 times/sec (fixed size array) mystream<size_t>: 1.07e7 times/sec (similar to null_sink, but tracks bytes written) Perhaps this is the difference between polymorphic and static method calls? In any case, there is no reason for stream<null_sink> to take twice as long as array_sink as there are no memory copies, all write should be no-ops. It would probably be useful to add a size_sink that can be used to track the number of bytes written and thus avoid dynamically resizing buffers.

1 0

[iostreams] basic_buffer int usage
by Judson Weissert 12 Aug '11

12 Aug '11

Hello, I was working with some boost::iostreams code for compressing and uncompressing streams of data when I encountered an interesting type conversion warning. Within buffer.hpp in the iostreams library (boost/iostreams/detail folder), the constructors accept an int buffer_size and assign it to std::streamsize size_. Upon further investigation, I learned that this was intentional as of r27330 (Log msg: "made all buffer size params ints so that int literals can be used without interfering with overload resolution"). Here is some example code that triggers the same warnings I was receiving: // Tested with boost 1.46.1 // Compiler Microsoft VC2010 SP1. // Compiled with cl /EHsc /W3 repro.cpp #include <boost/iostreams/copy.hpp> #include <boost/iostreams/device/array.hpp> #include <boost/iostreams/filtering_streambuf.hpp> int main (int, char *[]) { static const char b[] = { 'A', 'B', 'C' }; boost::iostreams::array_source as (b, 3); boost::iostreams::filtering_streambuf <boost::iostreams::input> in; in.push (as); // This line generates a 'std::streamsize' to 'int' warning. // See also boost/iostreams/detail/buffer.hpp boost::iostreams::copy (in, std::cout); return 0; } I am not completely sure what overload resolution is taking place, I only see a default constructor and a constructor that takes a buffer size. What am I missing? I posted approximately a week ago on this topic, but I don't think it made it to the list. Forgive me if this is a repost, I modified the content of the message since I learned more about the subject in the meantime. Thanks, Judson Weissert

2 1

[numeric] Adding numeric_cast_traits.hpp on 08/11 (today) breaks trunk
by Edward Diener 12 Aug '11

12 Aug '11

The addition and integration of numeric_cast_traits.hpp to boost numeric is breaking compiles on the trunk which use numeric. I am attempting to compile quickbook, only to see: gcc.compile.c++ ..\..\bin.v2\tools\quickbook\src\gcc-mingw-4.6.0\release\link-st atic\quickbook.o gcc.compile.c++ ..\..\bin.v2\tools\quickbook\src\gcc-mingw-4.6.0\release\link-st atic\actions.o In file included from ..\../boost/numeric/conversion/numeric_cast_traits.hpp:28: 0, from ..\../boost/numeric/conversion/cast.hpp:34, from ..\../boost/lexical_cast.hpp:40, from src\actions.cpp:19: ..\../boost/numeric/conversion/detail/numeric_cast_traits.hpp:77:31: error: miss ing binary operator before token "(" ..\../boost/numeric/conversion/detail/numeric_cast_traits.hpp:82:31: error: miss ing binary operator before token "(" etc. The same errors occur with msvc-10.0. These changes need to be fixed or reverted. Too many things depend on numeric_cast for this to remain broken.

4 8

[fusion] pop_back doesn't work on fwd sequences
by Eric Niebler 12 Aug '11

12 Aug '11

The documented requirement of pop_back are wrong. The docs say that pop_back works on Forward Sequences, however the following does not compile: // ERROR fusion::list<int, int> l(1, 2); fusion::pop_back(l); The problem is that the implementation of pop_back uses prior, which only works on Bidirectional Sequences. That's merely a doc problem, but this is a more serious problem: // ERROR fusion::pop_back(fusion::pop_back( fusion::push_back(fusion::push_back(fusion::nil(), 1), 2))); A sequence created by push_back is a Forward Sequence, which means you can't call pop_back on it. I think that's a serious shortcoming. Fusion needs something like MPL's Back Extensible and Front Extensible concepts. http://www.boost.org/doc/libs/1_47_0/libs/mpl/doc/refmanual/back-extensible… Unfortunately, this would likely require a redesign of the whole (push|pop)_(front|back) mechanism. -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 21

[Containers] Review
by Phil Endecott 12 Aug '11

12 Aug '11

Dear All, Following are some comments about Ion's proposed Boost.Containers. I have not really reviewed the code, but frankly that doesn't seem necessary: Ion knows what he's doing, much of this code has already been in Boost for a while as part of Interprocess, and much of it is designed to implement standard interfaces. I'll confine my comments to a few words about the documentation, and some observations about the "flat" containers. Regarding the documentation, I believe that it would benefit from: - The "Acknowledgements" page is currently empty. There are various (c) notices in the source referring to sources from which parts of the code may have come. This page should clarify these sources, including any cases where the original code has now all been replaced, and assert that the licenses are all in order. It should also point out the history of the code in Boost, i.e. that parts were previously in Boost.Interprocess, so that anyone with previous exposure to the Interprocess containers is not confused. - A few lines of rationale for stateful allocators would be useful, i.e. pointing out that although the std::allocator has a typedef for pointer the containers can assume it is T*, and the implications of that. (I dealt with all this back in about 2004, and it took me a long time to get up-to-speed with the issues.) - Similarly, some rationale for string (and pointing out how it differs from std::string in the common implementations) would be useful. (Now, I can't even find where it says that it is non-COW. I know that I've seen that written somewhere. A page specifically about string shown on the top-level table of contents would be appropriate.) - The Doxygen reference docs seem to jump to the header docs from the table of contents; I think it would be more useful to jump primarily to the classes. Is this the same issue that I saw in the last review? Regarding the "flat" containers, I've previously posted about this in a couple of threads on this list. I have used this sort of structure in two applications recently: - In the first case, I store read-only (key,value) data in a binary file. I have a utility that prepares this file offline by inserting into a vector<pair<>>. I then sort it, and save the contents of the vector in the file. In the program that uses the data, I memory-map the file. I then have an adaptor class that takes a pair of pointers to the begin and end of the mapped data and permits read-only access like Ion's flat_multimap<>. - In the second case, I have an insert-only key-value data structure. New data is inserted in batches. I have a vector<pair<>> and insert new data at the end; at the end of each batch, I sort the new values and merge them into the body of the vector using std::inplace_merge. Neither of these cases can be implemented efficiently using the current containers. Doing so would need: - Access to the underlying container, at least for reading. - An "adaptor" version that could wrap a pair of pointers to raw memory, or more generally a pair of iterators, at least for reading. - Some sort of efficient batched insert mode. Regarding the batched insert, we have previously discussed the complexity of inserting a range. Fundamentally, however, I don't think it is acceptable to have efficient insertion ONLY in the case of the insert(begin,end) method: it is too common to want to insert several values in a loop without creating a temporary container. I'm not aware of any established (i.e. std:: or boost::) pattern for doing this: class flat_container { void insert(val); // appends at the end of the vector void commit(); // merges new values into the body of the vector }; - Between calling insert() and calling sort(), what do lookups do? Undefined? Only look at old values? Sort-on-demand? - Is there also an "insert one" method? How are the variants named? - What about erase()? - How about a "batch" or "transaction" object?: flat_container c; { flat_container::insert_batch b(c); b.insert(data1); b.insert(data2); } // b's dtor merges new values. A further interesting case is when the new values are already sorted, because insertion can be more efficient in this case: void insert_sorted(iter first, iter last) { resize vector to make space for new items for each new item in reverse order { find the position where it should be inserted using binary chop move old items after that point forward move the new item in behind them } } I could imagine a general insert_batch and a specialised insert_sorted_batch, for example. Anyway, this is all just food for thought really. It would be interesting to hear from other people who have used data structures like this. In my own code I have taken a rather ad-hoc approach, but that is the nature of custom vs. library development: to be useful, a library needs to try to second-guess the requirements of all potential users, yet do so without becoming too complex for anyone to learn. Hopefully there will be some more discussion about some of this, but as far as the review is concerned we should allow Ion to decide what he eventually commits. Regards, Phil.

6 8

[containers] remarks and questions
by Pierre Morcello 12 Aug '11

12 Aug '11

Hello Ion, This is not a review. I took 3 hours to read the docs, checks some tests, try to check some sources, but I am still not used to read so few comments in the code. I played a little with the library then, tried to encapsulate some std::auto_ptr<X> in the new containers and things like that. Based on that very little experience, I would like to share some thoughts and ask a few questions on the proposed boost.containers library. 1/ I would really appreciate that the docs were more complete, at least for the technical part. => ex : "flat_map : more memory friendly and with faster searches" => In what way? is the algorithm complexity lesser than previous systems? or do you mean that contiguous memory is more cache-friendly? => do you provide different kernel implementations? => is there a paper on the subject? => Is there an evaluated algorithm complexity for the stable_vector? => is memory contiguous like a std::vector? can I use memcpy on several elements? These are just examples of questions that I expect to be answered by the docs. EDIT : I read proposition to embed elements of Joaquin M Lopez Munoz's blog. This is exactly that kind of informations I am looking for. => For the tree class, I can't remember any tree interface in the std. Could you point me to some informations ? Sorry If I miss something obvious. 2/ I was surprised (in a good way) to see some Andrei Alexandrescu's code in the library. Will the Loki licence be shipped now with boost? (This is not a problem for me). 3/ A few tests might be added. ex: Test the fact the vector usually are contiguous in memory. I can write this one if you are interested. 4/ The 'move aware' containers are nice to use but as a drawback We are forced to use macro to define the types using the 'move' semantics. What other container libraries can this work be related to? There are some examples of containers requiring the value_type to support only the "defaut constructor + a swap() function". This is a concept I would really appreciate to see in boost.containers. In that case, I would very happily use this library. Otherwise I think I will stick with other containers classes. 5/ "The aim of the library is to offers advanced features" Is the proposed Boost.containers also an effort towards development of new features for containers? If that is the case, then what are the plans for the future ? Is there a roadmap? To sum up : I am surprised that such a container library was not already integrated in boost. This should be a nice addition. But at the moment I don't think I would use it: my main interest would be for the value_type supporting "defaut constructor + a swap() function" to be added to the library. I also would like more detais in the documentation. In my humble opinion, it would also be easier for exterior people to learn from and to contribute to your library if there were more comments in the code. I congratulate you and the other authors for your work and efforts, and wish you the best for the review. Best regards, Pierre Morcello -- View this message in context: http://boost.2283326.n4.nabble.com/boost-containers-remarks-and-questions-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[preprocessor] ifdef equivalent inside a macro, is it possible?
by damien benoist 12 Aug '11

12 Aug '11

Hi all, Would there be a way to do some "ifdef" inside a macro? Could be in the form of a macro taking 3 args, - 1st being the macro to test the existance of, - 2nd being the value to expand in case 1st arg is a defined macro - 3rd being the value to expand in case 1st arg is not a defined macro Exemple: #define DUMMY_MACRO1 foo1 // next is commented out and not defined // #define DUMMY_MACRO2 foo2 PP_IFDEF(DUMMY_MACRO1, DUMMY_MACRO1, bar1) // would expand to foo1 PP_IFDEF(DUMMY_MACRO2, DUMMY_MACRO2, bar2) // would expand to bar2 Seems impossible to me, but boost/preprocessor does so many things that seemed impossible to me. Maybe someone will have some more magic... Thanks. Damien.

4 11

[proto] RValue reference support?
by John Maddock 12 Aug '11

12 Aug '11

Does proto have any support for rvalue references in terminals? I'm thinking that if you know that you're assigning an expression involving an rvalue-reference as a terminal, then there are some optimizations that can be performed that aren't otherwise possible. Thanks, John.

5 11

[interprocess] detail/move.hpp macros conflict with boost/move/move.hpp
by Daniel Larimer 11 Aug '11

11 Aug '11

I am attempting to include my own <boost/move/move.hpp> header, but the macros conflict with <boost/interprocess/detail/move.hpp>. It would seem to me that boost interprocess should 'namespace' the macros like it did the types so that when boost/move is included there are no conflicts. When will Boost.Move be included in an official release? Dan

1 0

[tti] Changes will go on Boost trunk
by Edward Diener 11 Aug '11

11 Aug '11

For interested parties, I have put TTI on the Boost trunk and will be making changes there in getting TTI ready for a Boost release. I will keep the reviewed copy in the sandbox until TTI is officially part of a Boost release, after which I will remove the sandbox version.

1 0

[tti] compiler error: shadows template param `class T`
by Lorenzo Caminiti 11 Aug '11

11 Aug '11

Hello, The TTI library macros expand to code that uses naive template parameter names like "T", "F", "U", etc. The library implementation should be changed to use library reserved names to avoid clashing with user template parameter names. For example, the library use a name like boost_tti_aux_T (or even better BOOST_PP_CAT(boost_tti_aux_T_, __LINE__)) instead of T and state in the documentation that any name prefixed by boost_tti_aux (in any namespace) is reserved for the library implementation. The same should be done for any other implementation symbol defined by the TTI library. This is an issue if the macros are expanded for example within a class (which is and should be possible after changing them not to expand in the boost::tti namespace). For example, assuming BOOST_TTI_HAS_COMP_MEMBER_FUNCTION is fixed not to expand in boost::tti then the following: template< typename T > struct myvector { BOOST_TTI_HAS_COMP_MEMBER_FUNCTION_TRAIT(has_push_back, push_back) // expand to code using a template parameter naively named T ... }; Will generate a compiler error on GCC "error: shadows template param class T". --Lorenzo

3 3

[containers review] A reminder that the containers review ends tomorrow
by John Maddock 11 Aug '11

11 Aug '11

Just a quick reminder that the containers lib review ends tomorrow - there have been lots of good comments, but not so many reviews - so now's your chance ;-) If there are any reviews pending that are likely to be late please let me know so we can extend the review period. Documentation from the library may be viewed online here: http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h… The source may be accessed from the "move" directory of the sandbox SVN or downloaded from http://www.drivehq.com/web/igaztanaga/boost_container.zip. Note that this download contains a copy of the accepted, but not yet release, Boost.Move library - extract the zip over a copy of Boost-1.47 to get a full working copy. Regards, John.

1 0

[Autosave] Re: [math][accumulators] Empirical distribution function
by Simon West 11 Aug '11

11 Aug '11

Hi, On Sun, June 19, 2011 22:36, er wrote: > Hope this can serve as a basis for a conversation: > > > https://svn.boost.org/svn/boost/sandbox/acc_ecdf/ > I'm assisting Eric with the maintenance of Accumulators. I've had a look through the code at the above link, and would like to offer the following comments (if I have misunderstood anything, please let me know). My basic concern with the code is that a map is used to store the counts of data-points that have been added (the map keys are the data-points, the map values are the counts). In real-world floating point data it is rare for two data-points to be exactly the same, so in practice the map would have a single key-value pair for each data-point q_i, of the form (key=q_i,value=1). This is inefficient, because all the key values will be 1. Also, the memory usage will grow linearly with the number of data-points accumulated, which doesn't seem to be in keeping with the spirit of the Accumulators library. For these reasons, I'm not convinced that the code should be added to the library in its current state. Simon.

3 2

[tti] getting write access to Boost trunk
by Edward Diener 11 Aug '11

11 Aug '11

I sent a message a few days ago to the Boost moderators at boost-owner(a)lists.boost.org to get write access to the Boost trunk so I could work on my TTI library there, since it has been accepted into Boost, but I have not received any response. Is anybody at home ? Edward Diener

2 1

[move] [variant] Some problems with VC++10
by Antony Polukhin 10 Aug '11

10 Aug '11

There are some problems with VC10 libraries and move implementations in Boost,Variant and Boost.Move. The problem is that VC10 uses move() in it's STL implementation without directly specifying namespace. That leads to ambiguity, when VC10 containers are used with boost classes. I can not exactly reproduce the bug, because I have no VC at home, but thats how it looked like: std::vector< my_variant > vec; vec.push_back( my_variant(some_data) ); // ERROR: Leads to ambiguity. Compiler can not choose between std::move that is defined in the same namespace and boost::variant::detail::move(), which is found via ADL. I think, that the same thing can happen with Boost.Move library, if some class defined in namespace boost will be used in VC++ STL containers. Most generic way to get rid of such ambiguity, is to import std::move in namespace boost (if we have std::move). Best regards, Antony Polukhin

4 5

[move] Pathscale and Sun
by Daniel James 09 Aug '11

09 Aug '11

Hi Ion, Boost.Move seems to work okay with Pathscale (at least the unordered container tests pass), but you've marked it as not supported. IIRC it used to have some configuration problems which were fixed a little while ago. Have you got any plans to fix the issue with 'boost::rv' on Sun C++ or should I work around it? Daniel

2 2

[containers] reviewette
by Gregory Crosswhite 09 Aug '11

09 Aug '11

Hey everyone, I don't know if I will get the chance to perform a full review within the review window, but I just wanted to share my limited experience with the library. Back in February I wrote (or more precisely, rewrote in C++) a production numerical simulation code [1] that makes extensive use of Boost.Move because move-but-not-copy semantics were the most natural fit for most of my data objects. (The rationale for this was that in nearly all cases I only wanted one entity to hold a given data object, and in the remaining cases few I could just wrap the data object in a shared_ptr.) Since I wanted to have vectors containing these objects, I made use of the containers::vector class that was bundled with Boost.Move, so the headers for Boost.Move and at least the vector class of the proposed Boost.Containers library have lived in my code for a few months now. Being able to return a vector without having to worry about whether it would be copied was so nice that I eventually just started using boost::containers::vector everywhere I would normally have used std::vector; it was also very nice to be able to use the .emplace* methods to construct elements in place because this saved both some overhead *and* additional typing on my part. (Of course, I will eventually get these things by default in std::vector as soon as C++0x is available everywhere, but it is really nice to have them now! :-) ) The code has been stable enough that I never encounter any problems using it. Now, I don't know what has changed since I coped the Boost.Move+Boost.Container headers into my tree in Febrary so hopefully nothing has been broken, but based on my personal experience using the library I can say that it at least boost::containers::vector seems to work just fine in production code and I would really like to see it be a part of Boost. Cheers, Greg [1] Nutcracker, a matrix product state based quantum simulation code, available at: http://github.com/gcross/Nutcracker

2 1

[lockfree] Review
by Grund, Holger 09 Aug '11

09 Aug '11

Hi everyone, I'm sorry for the late review -- things have been busy as usual. I've briefly gone over the code and think Tim's Lockfree library would make an excellent addition to Boost and should be accepted, provided some points are addressed. First and foremost, I don't think the library can be called ready when it doesn't support Visual C++/x86 in a meaningful way -- which I believe it doesn't right now. What is your evaluation of the design? -------------------------------------- The library seems well-designed. As I believe has been discussed in a separate thread, naming is somewhat inconsistent. The failure modes are not clear to me (e.g. does enqueue/push return false or throw an exception when there is no more memory), but overall I think Tim did an excellent job. What is your evaluation of the implementation? ---------------------------------------------- As mentioned, it would appear that bundled atomic implementation has a lot of shortcomings, but one is particularly bad: atomic<tagged_ptr> is not actually lock-free for Visual C++. The DCAS implementation should be straightforward, but seems to be absent . in case you wonder I did an initial implementation of <(cstd)atomic> and added all required intrinsics for a simple implementation to the compiler. These made it all into VC++2010 RTM (IIRC, there was only one 64-bit, most where 8 & 16-bit variants) There are a few points that make me a bit nervous. Specifically, the alignment story is a bit weak. It seems there is only one use of BOOST_LOCKFREE_CACHELINE_ALIGNMENT and that's for fifo<>::node. Older compilers (GCCs and VC at least) don't dynamically align the stack with __declspec(align)/__attribute__((aligned). Other classes do not use alignment at all. It seems somewhat inconsequent to add internal padding to move members to different cachelines, but at the same time not ensuring alignment (which means potential cacheline overlaps at back and front of the object). Also the code seems to assume that compilers will use an empty base class optimization for noncopyable -- I guess, that's fine for most major compilers. Also it is not clear how it is ensured that nodes allocated are actually aligned. Allocators can and usually do ignore alignment requirements greater than intmax_t types. Some may just fail to instantiate. likely/unlikely are often defined as macros as in the Linux kernel. People probably shouldn't do that for C++, but I have seen it quite a bit. It probably doesn't help that many compilers' inlining oracles don't do very well for modern code. The name freelist_t is somewhat confusing for a template parameter and while I'm not sure what harm it could do it should probably follow the general convention of CamelCase. What is your evaluation of the documentation? --------------------------------------------- This is a bit of a weak point right now. There isn't much documentation to begin with. The definition of wait-free and lock-free is a bit weird. Specifically, the term concurrent operations is a bit vague. I think it's easier to grasp if you say something along the lines of at least one thread makes forward progress at any given point in time. With the current definition in the docs (and most others I know of), it may not be immediately clear why a mutex-based implementation wouldn't be lock-free. There's a paragraph: > The synchronization is done completely in user-space with no interaction without any direct interaction with the operating system [1] . > This implies that they are not prone to issues like priority inversion (a low-priority thread needs to wait for a high-priority thread). I think there's some duplication in the first sentence. I'm not sure what lock-free has to do with priority inversion and I would think that priority inversion means priorities are -- well, inverted. I.e. a high-priority thread is not scheduled, because a lower priority thread owns a resource needed by the high-priority thread. This also makes it sound a bit like lock-free is superior to OS mechanisms, but that really depends. A standard lock-free list is not fair for writers, but an implementation making use of OS facilities can be. On the other hand ticket lockets can provide some fairness. fifo<> and ringbuffer::empty says it is not thread-safe. I would assume that means the value returned is potentially stale, but it can't break class invariants, or can it? What is your evaluation of the potential usefulness of the library? ------------------------------------------------------------------- I think the library addresses a very important use-case and could therefore be a very useful addition to Boost. But to reiterate, I would expect Lockfree to actually be lock-free on all mainstream platforms. Did you try to use the library? With what compiler? Did you have any problems? ------------------------------------------------------------------------------ I don't have Boost libs built here, so only tried some simple tests with VC++ 10 SP1. No problems. I'm planning to run some perf tests with GCC 4.1 on AS5 x86_64. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? -------------------------------------------------------------------------------------------- I spent about four hours mostly going over the code and the docs. Are you knowledgeable about the problem domain? ----------------------------------------------- I have done quite a lot of lock-free work over the last the last 8 years. I did an initial implementation of <atomic> for Microsoft and my current job involves a lot of tweaking of very low latency code, where we very much care about upper limits for execution time (but also about throughput). While I'm still constantly surprised by modern CPUs, I do consider myself to be quite knowledgeable about this area. -hg Holger Grund, Vice President Morgan Stanley | MS Strats and Modeling 25 Cabot Square | Canary Wharf | Floor 03 London, E14 4QA Phone: +44 20 7677-4095 Holger.Grund(a)morganstanley.com -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

5 16

Re: [boost] [math][accumulators] Empirical distribution function
by Denis Arnaud 09 Aug '11

09 Aug '11

On 8/8/11, er wrote: > Thanks, but it was just, I quote, a "basis for a conversation" at the > request of a user (Denis Arnaud), but it failed to go anywhere at the time. Note that I am still interested in using such a component/library. The difficulty I had was the integration with the rest of Boost and, therefore, the build of that component. Indeed, I use CMake (from the Ryppl initiative) rather than bjam, for the Boost sandbox components, and the integration is therefore a little bit different. AFAIU, Daniel Pfeifer is now close to have a CMake-ified Boost able to integrate Boost sandbox libraries. One of the first such use case would be to integrate and to test your Empirical CDF component. Nevertheless, thanks for having proposed a solution, even though I understand it is still not perfect. Best Denis

1 0

[tti] Write access to Boost
by Edward Diener 09 Aug '11

09 Aug '11

For my TTI library I need write access to the Boost repository si I can check the library into the trunk and maintain it there. Eddie Diener

2 2

[function][bind] Crash with g++ 4.5.0 -O[23]
by Daniel Larimer 08 Aug '11

08 Aug '11

I recently wrote some code that only crashes with g++ 4.5.0 -O[23] and am not sure whether it is a g++, boost::bind, or boost::function bug. I have prepared a minimum test case that crashes every time: 0 test 0x00000001000016ba Private::method_name(std::string const&) + 26 1 test 0x0000000100001348 boost::detail::function::function_obj_invoker1<boost::_bi::bind_t<void_t, boost::_mfi::mf1<void_t, Private, std::string const&>, boost::_bi::list2<boost::_bi::value<Private*>, boost::arg<1> > >, void_t, std::string const&>::invoke(boost::detail::function::function_buffer&, std::string const&) + 24 2 test 0x00000001000027bb boost::detail::function::void_function_obj_invoker2<functor<std::string, boost::function<void_t ()(std::string const&)> >, void, std::string const&, std::string&>::invoke(boost::detail::function::function_buffer&, std::string const&, std::string&) + 59 3 test 0x0000000100003893 Private::test() + 2723 4 test 0x00000001000012d8 main + 56 5 test 0x0000000100001250 start + 52 Mac OS X 10.6 Snow Leopard g++-4.5.0 -O3 or -02 crashes g++-4.5.0 -O1 works. g++-4.2 -O3 works. g++-4.0 -O3 works llvm-g++-4.2 -O3 works The odd thing is that if I replace boost::bind() with my own custom functor then it does not crash. If I include both working and non-working functors (uncomment code) then they both work. Because older versions of g++ work (pre C++0x support) it could be a bug in how boost::function or boost::bind use rvalue references. Because replacing boost::bind() with my own custom functor also fixes it, I suspect that the problem, if not g++, lies in boost::bind. If I remove boost::function from the equation by creating functor<Seq,Functor> with Functor = TYPEOF( boost::bind( ... ) ) via the use of a helper method, then it also does not crash. Thus some combination of creating a boost::function<...> from a boost::bind() functor on g++4.5 causes the crash.

2 2

[Containers] Should flat_* expose implementation vector?
by Phil Endecott 08 Aug '11

08 Aug '11

Dear All, Should Ion's proposed flat_set, flat_map etc. expose the underlying vector that they use as their implementation? Pros: it lets the user efficiently load and save the content, and implement algorithms that cannot be done via the flat_* interface. Cons: it lets the user break the invariants. Const access to the impl is another possibility. Related to that: could the implementation type be a template parameter? Example: could one implement a flat_set on top of a stable_vector? (Is that useful?) And/or: should flat_* actually be adaptors that take a reference to their underlying implementation? Regards, Phil.

8 10

[gsoc] mentor summit
by Andrew Sutton 08 Aug '11

08 Aug '11

Mentors, If you are interested in attending the mentor summit (Mountain View, CA Oct 22-24 -- check the calendar that might be wrong), please let me know. We send 2 people to represent Boost. I will not be one of them since I have a prior engagement. The reimbursement scheme looks like it's going to change this year. Essentially, Boost (actually the SFC) will submit a single purchase order for mentored projects + the cost of mentor summit air travel. That means that actual reimbursement for your flight costs may not happen until... I don't know. June 2012? The process is ridiculously slow, and I never got word that Boost received mentor payments from last summer. Andrew

1 0

[Date Time] bug in documentation example (Localization Demonstration)
by Frédéric Bron 08 Aug '11

08 Aug '11

In "Localization Demonstration": http://www.boost.org/doc/libs/1_47_0/doc/html/date_time/examples.html#date_… 11 should be 12 and 6 should be 7 in the following lines: std::copy(&de_short_month_names[0], &de_short_month_names[11], std::back_inserter(short_months)); std::copy(&de_long_month_names[0], &de_long_month_names[11], std::back_inserter(long_months)); std::copy(&de_short_weekday_names[0], &de_short_weekday_names[6], std::back_inserter(short_weekdays)); std::copy(&de_long_weekday_names[0], &de_long_weekday_names[6], std::back_inserter(long_weekdays)); Regards, Frédéric

1 0

Boost.Atomic, pushing forward and a little request for help
by Helge Bahmann 07 Aug '11

07 Aug '11

Hi folks, from the comments to Boost.Lockfree I understand that you consider a non-reviewed Boost.Atomic as a "blocker"? I apologize that I have not pushed forward for review (considering that "it just works for me", and considering the length of the review queue...), but if you consider it blocking please just let me know what I would need to do to clear the path. What I will do shortly is to provide and uptodate package containing several fixes, several contributed by others (they are in the repo, but not in any release archive) as well as some missing bits to more closely match latest C++0X draft. The big sore point is still support for the various flavours of VC -- I know that there are (especially older) versions for which it is not working, but I am lacking test systems, so if you are affected please let me know and I will do my best to resolve the issues. Cheers, Helge

10 14

[interprocess::file_mapping] Please add resize method
by Dmytro Ovdiienko 07 Aug '11

07 Aug '11

Hello, Could you please add resize method to the file_mapping class? Also please don't fill file with zeros by default? This functionality increases latency spikes. Make it as quick as possible. Thanks. Best regards. Dima -- Dmytro Ovdiienko e-mail: dmitriy.ovdienko(a)gmail.com skype: dmitriy.ovdienko(a)gmail.com mobile: +38050-1909731

2 5

[containers] review
by Gordon Woodhull 07 Aug '11

07 Aug '11

Hi Ion, John, all, I apologize that I don't have time for a full review, as I'm going offline hiking for the rest of the review period. Obviously the library should be accepted. Move emulation, stateful allocators, emplace, recursive containers, ... so many excellent features. And this code has been tested as part of Interprocess for years. However, I do find the documentation lacking. While the Doxygen reference looks very complete, I want to see the overview documentation expanded, including covering the following topics: Stateful allocators seem to be unmentioned. Do they affect performance or behavior? I know this might be a big topic; links are okay. My understanding is that these are fully supported but other allocator improvements are not yet present? Out of curiosity I'd like to see a bit of text about the future directions, mentioning N1953 & N2045. Could the contents of Joachin's blog post http://bannalia.blogspot.com/2008/08/stable-vectors.html go into an overview section for stable_vector? Recursive container is not defined, also maybe link to http://en.wikipedia.org/wiki/Recursive_data_type What is it used for: directed graph. Some guideline about when it's better to use flat_*. I figure you would use such a structure when you're not doing a lot of inserts or when there are few elements. The advice can be somewhat handwavy and instruct the user to do measurements, but it should be there. Silly question, but I'm not clear how to use this ordered_unique_range_t that's in the Doxygen - is there a constant or do you default construct it or what? As earlier pointed out, a lot of the Doxygen parameters and descriptions have gotten out of sync k/x first/i etc. Well, I've run out of time. Hope this helps a little. Cheers, Gordon

3 3

[Container] boost::container::vector<bool>
by Joel falcou 07 Aug '11

07 Aug '11

It is not clear from the doc but does the vector from boost::container *don't* do the so not useful bool optimization ? Aka can I finally take a pointer to vector<bool> element ? Thanks

2 1

[Containers] Complexity of flat_*::insert(first,last)
by Phil Endecott 07 Aug '11

07 Aug '11

Hi Ion, This library looks great. A quick comment about range-insertion in the flat containers, e.g.: template<typename InputIterator> void insert(InputIterator first, InputIterator last); Requires: i, j are not iterators into *this. Effects: inserts each element from the range [i,j) . Complexity: N log(size()+N) (N is the distance from i to j) search time plus N*size() insertion time. (Note typo: i,j vs, first,last) What implementation are you assuming to get that complexity? It seems to me that it is worse than it could be if you implement it something like this (PSEUDO-CODE): template<typename InputIterator> void insert(InputIterator first, InputIterator last) { iterator m = end(); insert(end(), first, last); sort(m,end()); inplace_merge(begin(),m,end()); } (I've only ever done this with multi* containers. For set and map you'll need something to avoid duplicates.) Regards, Phil. p.s. Having typed that I have developed a feeling of deja vu. Have I asked you this before?

4 11

[fusion] joint_view bug?
by Eric Niebler 07 Aug '11

07 Aug '11

The following code asserts at compile time for me. Am I doing something wrong? typedef fusion::vector2<int,int> pair; pair p(1,2); fusion::joint_view<pair, pair> x(p, p); auto begin = fusion::begin(x); auto end = fusion::end(x); int i = fusion::distance(begin, end); The assert is on line 39 of fusion/iterator/distance.hpp: template <typename Tag> struct distance_impl { // default implementation template <typename First, typename Last> struct apply : distance_detail::linear_distance<First, Last> { BOOST_MPL_ASSERT_NOT((traits::is_random_access<First>)); BOOST_MPL_ASSERT_NOT((traits::is_random_access<Last>)); }; }; In this case, First is a joint_view iterator and Last is a vector iterator, which is indeed random-access. If I simply comment out the compile-time asserts, the code compiles and works as expected. I think these asserts are bogus. OK to remove them? -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2

[log] Documentation improvement suggestions - was :how to set attributes under multi-threaded application
by Klaim - Joël Lamotte 06 Aug '11

06 Aug '11

Hi, Andrey Semashev said: I think the common formula "library design + tutorial + features description > + reference" is the golden middle for medium-sized projects, like Boost.Log. > Also, quite a few common case examples will help to get things started. The > rest will come with experience. > > I would like to give my limited feedback with the log docs about this very point : What I think might be a bit overhelming and don't help beginners with boost.log is the library design page itself. http://boost-log.sourceforge.net/libs/log/doc/html/log/design.html I mean the content organisation of the page, not the fact that it exists and I agree with you that it should be up front. The main problems with the page : A. there is a BIG bloc of text with almost no apparent hierarchy - that's a showstopper for a lot of people that will just click the "tutorial" link to see what it's really about; B. the scheme is clear technically but might be easier to read if it was to be read from left to right instead of right to left (at least because it uses english text); an alternative would have been from top to bottom : reading the scheme should follow the way data goes from loggers to sinks (in fact the current scheme looks like an inverted comics page to me...) Here are some suggestions to improve this page : 1. Structure the big block of text in several distinct parts, with titles. I think those parts already exists but they just lack obvious separations like just big titles. 2. Add links in the text to definitions from the previous page (Definitions). Reading the definitions first doesn't always make things really clear immediately. Often you read them used in context and then understand...or not if your forgot what it was. There are 9 definitions with several having the same beginning. It might be easier to the user to link to those simple definitions when they need them, when reading the library design text (might not be necessary after that?). 3. Invert the reading sens of the scheme or make it top to bottom. Obviously I'm an humble user, not an authority in the matter, but I hope it helps getting more users not stop at this page. Joël Lamotte

3 4

boost::iostreams::detail::basic_buffer int usage
by Judson Weissert 05 Aug '11

05 Aug '11

Hello, I believe there is a type conflict in boost/iostreams/detail/buffer.hpp. ------ Snippet from buffer.hpp ------ class basic_buffer { ... basic_buffer (int buffer_size); ... std::streamsize size_; }; ------ End snippet ------ Here is some example code that triggers the same warnings I was receiving: // Tested with boost 1.46.1 // Compiler Microsoft VC2010 SP1. // Compiled with cl /EHsc /W3 repro.cpp #include <boost/iostreams/copy.hpp> #include <boost/iostreams/device/array.hpp> #include <boost/iostreams/filtering_streambuf.hpp> int main (int, char *[]) { static const char b[] = { 'A', 'B', 'C' }; boost::iostreams::array_source as (b, 3); boost::iostreams::filtering_streambuf <boost::iostreams::input> in; in.push (as); // This line generates a 'std::streamsize' to 'int' warning. // See also boost/iostreams/detail/buffer.hpp boost::iostreams::copy (in, std::cout); return 0; } Perhaps the fix is as simple as s/int/std::streamsize/g within buffer.hpp. Any thoughts? Thanks, Judson

1 0

[type trait extension] I hate volatile...
by Frédéric Bron 05 Aug '11

05 Aug '11

I am still working on the implementation of the traits to detect operators. I have an issue with operators returning a volatile object (being a reference or not). This breaks the code I wrote to detect if the return type is void or not. In particular, the following code compiles with RET=int but not with RET=ret. Can somebody tell me why? It seems that any volatile object (reference or not) cannot be bound to a const reference apart for fundamental types. So is there any useful case to return a volatile object? If not, I can maybe just ignore those cases or it becomes to be a nightmare. By the way, it is 1:30am. I am going to bed! Frédéric struct ret { }; #define RET int RET result; RET r() { return result; } RET const rc() { return result; } RET volatile rv() { return result; } // fails to compile RET const volatile rcv() { return result; } // fails to compile RET & rr() { return result; } RET const & rcr() { return result; } RET volatile & rvr() { return result; } // fails to compile RET const volatile & rcvr() { return result; } // fails to compile int main() { RET x; x=r(); x=rc(); x=rv(); // fails with RET=ret x=rcv(); // fails with RET=ret x=rr(); x=rcr(); x=rvr(); x=rcvr(); return 0; }

4 13

[Containers] String performance and compatibility
by Phil Endecott 05 Aug '11

05 Aug '11

Hi Ion, I see that your string implementation has a small buffer optimisation (SBO). Have you tried to benchmark this, and/or any of the other design decisions? I vaguely recall that libc++ may have done some measurements but I can't find anything now. Also, have you considered adding e.g. a ctor that takes a std::string, for interoperability? (I guess the same could be asked for the other types.) Phil.

4 4

Re: [boost] [rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC
by Brian Wood 05 Aug '11

05 Aug '11

Daniel Larimer: On Jul 30, 2011, at 7:16 PM, Brian Wood wrote: > Daniel Larimer <dlarimer(a)gmail.com> > >> 1) No code generation required (best for C++ to C++, but with a proper > JSON interface can communicate with any language) > > Code generation is being done by something here. In this case it is > probably being done by a C++ compiler that starts from scratch for > every file it has to compile. > > I think there is a big difference between using the pre-processor / templates and > using another program, another language, another dependency, another build step. Yes, there's another dependency and build step, but at least if you're using the approach I advocate you are rewarded with a cleaner build. I've been comparing the differences (between Boost.Serialization and the C++ Middleware Writer) for a number of years now. The most recent comparison using Boost 1.47.0 shows the Boost executables are between 1.7 and 2.8 times larger than the functionally equivalent Ebenezer executables. I haven't compared the build times though so can't say which is faster, but obviously it takes more time to produce a chubby file than a svelte file. > Besides, even if you use a 3rd party tool like google protocol buffers, ICE, etc that does > code generation, the C++ compiler still must start from scratch every time one of the > generated headers is included. Only a fraction of the code is in headers. As much as possible is in source files that don't have to be processed again and again. > Often times you end up deriving from the generated interface and your code breaks if you > change the interface file, etc. Furthermore, now you must maintain the code for the > generator, find bugs, bootstrap by building the generator, etc. I don't think there is any more maintaining the code or finding bugs involved with this approach than with the approach you are describing. The code is just in an executable form as opposed to in a library. With most serialization libraries you bootstrap by building a large library. What I advocate takes 1/10 as long to get bootstrapped as the Boost Serialization library. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

3 5

[containers] Implement std::forward_list?
by Lars Viklund 05 Aug '11

05 Aug '11

Hi. Will there be any analogous type in the proposed containers library for the C++0x std::forward_list [23.3.4 in n3290]? It's essentially a slist but without any of the costly operations like size(). -- Lars Viklund | zao(a)acc.umu.se

2 1

Documentation (was Re: [log] how to set attributes under multi-threaded application)
by Dean Michael Berris 04 Aug '11

04 Aug '11

On Fri, Aug 5, 2011 at 3:13 AM, Sean Chittenden <sean(a)chittenden.org> wrote: > > > This is a general comment about the documentation across the boost project and isn't entirely specific to the boost-log project, but wisdom such as this "the application of XYZ feature is ideally suited for the situation ABC" doesn't exist frequently in much of the boost documentation. I don't know if it's in some style guideline someplace, but having been a boost user for ~5yrs now and having forced boost on other developers for a few years now, this is one of the things that I acutely notice/get push back on regarding the boost project (especially when referencing its documentation). > > I actually just made this comment to Boris, the author of the "Boost Libraries" that one of the things that I like about his book is it actually distills practical examples because the boost docs are more geared toward other Boost developers vs consumers of the libraries. The biggest piece of feedback I get is summed up as, "Boost is high quality, but it requires a high degree of skill to apply. A lot of this is because the docs are frequently very dense and assume equivalent levels of STL competency to decipher what's written. Nine times out of ten, I don't need to customize boost or extend it, I just need to use it and there isn't something that I can easily reference and get what I'm looking for within 15-30min." And I'll admit, it took a good year of hammering away at examples and stubbing out little bits of code here and there before I became familiar and comfortable with implementing boost. Call it a byproduct of the PHP-ization of developers, I dunno, but I think there > 's a nugget of truth to be had in there (maybe add a quickbook type called "Implementors" with tips/hints? *shrug*). > FWIW, I try to do this in cpp-netlib and I have to agree with Andrey's assertion that this is not practical nor sustainable. It's actually one of the things that I'm thinking of "fixing" as far as the documentation is concerned. I think a library's documentation should surface three things in general: 1) Why the library exists. 2) How to use the library. 3) Expose important details that may not otherwise be obvious in the API. I think if #1 and #2 are done properly then I'd say examples of usage would be mere gravy. Because all if not most of Boost libraries tend to be fairly generic or broad (sometimes both) I'd say explicitly saying "This library can be used in <insert situation X>" greatly limits the applicability and/or perceived utility of the library. Just my $0.02. -- Dean Michael Berris http://about.me/deanberris

1 0

Invitation to connect on LinkedIn
by Gautam Sewani via LinkedIn 04 Aug '11

04 Aug '11

LinkedIn ------------ Gautam Sewani requested to add you as a connection on LinkedIn: ------------------------------------------ Yuriy, I'd like to add you to my professional network on LinkedIn. - Gautam Accept invitation from Gautam Sewani http://www.linkedin.com/e/bv6hcz-gqy2wc24-30/uV9CsZkavY-uKU5A7C-1JbkavY-u5P… View invitation from Gautam Sewani http://www.linkedin.com/e/bv6hcz-gqy2wc24-30/uV9CsZkavY-uKU5A7C-1JbkavY-u5P… ------------------------------------------ DID YOU KNOW LinkedIn can help you find the right service providers using recommendations from your trusted network? Using LinkedIn Services, you can take the risky guesswork out of selecting service providers by reading the recommendations of credible, trustworthy members of your network. http://www.linkedin.com/e/bv6hcz-gqy2wc24-30/svp/inv-25/ -- (c) 2011, LinkedIn Corporation

1 0

Re: [boost] [log] how to set attributes under multi-threaded application
by Sean Chittenden 04 Aug '11

04 Aug '11

>> In boost::log documentation, there's some code as following: >> >> * typedef attrs::mutable_constant< int> int_constant_t; >> boost::shared_ptr< int_constant_t> attr(new int_constant_t(-5)); >> lg.add_attribute("MyInteger", attr); >> BOOST_LOG(lg)<< "This record has MyInteger == -5"; >> >> **// Change the attribute value >> attr->set_value(100); >> BOOST_LOG(lg)<< "This record has MyInteger == 100"; >> * >> Now I have a situation in my multi-threading app: >> the 'attr->set_value()' could be called in different threads, so the >> following 'BOOST_LOG(lg)...' could access wrong attributes that is set by >> another thread. If I use a mutex to protect this, it would be stupid, >> because the log line might be filtered out, that means the 'locking mutex' >> is not neccessary. > > If thread synchronizaion is what bothers you, mutable constant has > internal locking ability, you can specify mutex and lock types in the > mutable_constant template parameters. You can find an example in the docs: > > <http://boost-log.sourceforge.net/libs/log/doc/html/log/detailed/attributes.…> > > So, when internal locking is used, you don't have to externally > synchronize access to this attribute, neither when you update its value > nor when you write log records involving it. > > > On the other hand, if you simply try to tag a specific log record with > an attribute (e.g. you want to make sure that a particular record has > MyInteger value -5 attached) then thread-specific attributes would be a > better option. You can add a scoped thread-specific attribute for this > record, this will not affect log records generated by other threads and > will not require any synchronization either. You can read more about > scoped attributes here: > > <http://boost-log.sourceforge.net/libs/log/doc/html/log/detailed/utilities.h…> This is a general comment about the documentation across the boost project and isn't entirely specific to the boost-log project, but wisdom such as this "the application of XYZ feature is ideally suited for the situation ABC" doesn't exist frequently in much of the boost documentation. I don't know if it's in some style guideline someplace, but having been a boost user for ~5yrs now and having forced boost on other developers for a few years now, this is one of the things that I acutely notice/get push back on regarding the boost project (especially when referencing its documentation). I actually just made this comment to Boris, the author of the "Boost Libraries" that one of the things that I like about his book is it actually distills practical examples because the boost docs are more geared toward other Boost developers vs consumers of the libraries. The biggest piece of feedback I get is summed up as, "Boost is high quality, but it requires a high degree of skill to apply. A lot of this is because the docs are frequently very dense and assume equivalent levels of STL competency to decipher what's written. Nine times out of ten, I don't need to customize boost or extend it, I just need to use it and there isn't something that I can easily reference and get what I'm looking for within 15-30min." And I'll admit, it took a good year of hammering away at examples and stubbing out little bits of code here and there before I became familiar and comfortable with implementing boost. Call it a byproduct of the PHP-ization of developers, I dunno, but I think there's a nugget of truth to be had in there (maybe add a quickbook type called "Implementors" with tips/hints? *shrug*). Anyway, Andrey, it'd be keen if you could include a note along these lines in the docs. Maybe a quickbook type for "Implementors." Cheers. -sc -- Sean Chittenden sean(a)chittenden.org

2 1

[trac] trac/boost/browser/ no longer available?
by joaquin＠tid.es 04 Aug '11

04 Aug '11

Say I'm having a look at some changeset such as: https://svn.boost.org/trac/boost/changeset/73525 The names of modified files are displayed with a link to a full-code browsing page, for instance: https://svn.boost.org/trac/boost/browser/sandbox/variadic_macro_data/boost/… yet this page fails with No handler matched request to /browser/sandbox/variadic_macro_data/boost/variadic_macro_data/vmd.hpp I think this trac/boost/browser has been missing for some months now. I seem to remeber there was a link to it also from the trac home page, now also missing. Any clue about this? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

4 4

[network] Bagged, Tagged, New Release 0.9.1
by Dean Michael Berris 04 Aug '11

04 Aug '11

Good day everyone! If you're not interested in cpp-netlib's progress, please stop reading now. :) I'm happy to announce that cpp-netlib (the library that's hoping to be Boost.Network someday) is now available for general availability. You can get the latest from https://github.com/cpp-netlib/cpp-netlib/downloads and find out what's new at http://cpp-netlib.github.com/0.9.1/whats_new.html . This is an updated release that's inching closer to the "1.0" release that's going to be up for review. I've also written a more detail-filled announcement that you can read over at http://cplusplus-soup.com/2011/08/04/cpp-netlib-0-9-1-released/ -- please feel free to comment and share as you see fit. I'm looking to work with Michael Caisse who has agreed to be the review manager for Boost.Network to hopefully have a review at a convenient time for both of us. Right now I'm gunning for Q4 of 2011, but that's still fairly a ways away so things may still change. Cheers everyone, I do hope this helps! -- Dean Michael Berris http://about.me/deanberris

1 0

numeric_cast
by Brandon Kohn 03 Aug '11

03 Aug '11

Hello, Recently I was creating a new numeric type which I wanted to use along with boost::numeric_cast. I read over the docs and examples and found that it seemed to support (at least partially) the notion of policy driven casting operations. I was unable to figure out how one might use a custom conversion or overflow policy along with the actual boost::numeric_cast<N>(x) function. In the end I created a workaround which seemed to work nicely: template <typename ConversionTraits, typename EnableIf = void> struct numeric_cast_traits { typedef def_overflow_handler overflow_handler; typedef UseInternalRangeChecker range_checker; typedef Trunc < typename ConversionTraits::source_type > rounding_policy; }; template <typename Target, typename Source> inline Target numeric_cast( Source arg ) { typedef boost::numeric::conversion_traits<Target, Source> conv_traits; typedef numeric_cast_traits< conv_traits > cast_traits; typedef boost::numeric::converter < Target , Source , conv_traits , typename cast_traits::overflow_handler , typename cast_traits::rounding_policy , boost::numeric::raw_converter< conv_traits > , typename cast_traits::range_checker > converter; return converter()(arg); } This change allowed me to easily customize the numeric_cast function for individual conversion types. Did I miss something in the official library? If not, would this change be something good to go in? Regards, Brandon Kohn

9 29

[log] how to set attributes under multi-threaded application
by Jinqiang Zhang 03 Aug '11

03 Aug '11

In boost::log documentation, there's some code as following: * typedef attrs::mutable_constant< int > int_constant_t; boost::shared_ptr< int_constant_t > attr(new int_constant_t(-5)); lg.add_attribute("MyInteger", attr); BOOST_LOG(lg) << "This record has MyInteger == -5"; **// Change the attribute value attr->set_value(100); BOOST_LOG(lg) << "This record has MyInteger == 100"; * Now I have a situation in my multi-threading app: the 'attr->set_value()' could be called in different threads, so the following 'BOOST_LOG(lg)...' could access wrong attributes that is set by another thread. If I use a mutex to protect this, it would be stupid, because the log line might be filtered out, that means the 'locking mutex' is not neccessary. Who can help ? Jinqiang *btw, the boost::log documentation isn't too good, when I read it, I felt I lost in a juggle.*

2 1

Move on Sandia intel
by Ion Gaztañaga 03 Aug '11

03 Aug '11

Hi, A test is failing for Move in Sandia-darwin-intel-11.1 (and 12.0): http://www.boost.org/development/tests/release/developer/output/Sandia-darw… and I don't know why, since Intel 11.0 in windows seems to work fine. Anyone with access to that compiler can help me? Thanks! Ion

4 6

Boost.Process progress
by Boris Schaeling 03 Aug '11

03 Aug '11

There haven't been much news on Boost.Process lately which doesn't mean though that nothing is happening. I've been working on a Boost.Asio extension which can be used to wait asynchronously for Windows processes - see https://github.com/BorisSchaeling/asio. This was already supported by Boost.Process 0.4 but the implementation was heavily criticized. The code has been moved now to Boost.Asio (or at least I hope it will - I'm in contact with Chris :) and provides a new Windows I/O object called object_handle. The implementation is now based on the Windows function RegisterWaitForSingleObject(). The new I/O object can not only be used to wait for processes. It can also be used to wait for events, mutexes, semaphores etc. As it's not process-related anymore, it makes sense to ship the code with Boost.Asio (where we have already similar Windows I/O objects called random_access_handle and stream_handle - object_handle fits in nicely). Once I'm done with this, a major critical point should have been resolved. I'll go back then to Boost.Process code and help Jeff to finish https://github.com/JeffFlinn/boost-process. I'm not sure how far we are there. But as I don't remember any major obstacles, I'm confident that there are none. :) Boris

2 2

[TTI] Review Result
by Joel falcou 02 Aug '11

02 Aug '11

This is the result summary for the Type Traits Introspection library by Edward Diener. The review have been on going from July 1st to july 17th and had generated a large amount of very interesting design discussion. The library received 5 Positive reviews and a few positive comments next to that. **The verdict is that, the TTI Library is ACCEPTED into Boost.** However, a few comments and concerns have been raised but are rather simple changes to perform and I am sure Edward will take these comments into account before releasing the library. Such comments include: * The main comment is the fact that Boost.TTI force the definitions of its meta-functions into the boost::tti. Concerns have been raised and requests made that the macro don't specify any namespace and let users bring the generated meta-functions in the namespace of their own liking. * The number of macros handling various corner cases has been raised as potentially too high. Effort to streamline the macro based interface has been requested. * Support for more compiler is needed. Some issues on ICC has been raised but are currently being looked upon (or fixed). * Naming scheme of the macro and of the generated meta-functions have to be refined to be 1/ more clear 2/ avoid some non-standard name starting with __ * Some more detailed and entry-level examples may be beneficial to the library * Pre-made macro for classical typedef like value_type or other std components has been proposed Thanks to all the participants and to Edward for this review.

2 1

[Boost] [GSoC] [Checks] Issue with the design
by Pierre Talbot 02 Aug '11

02 Aug '11

Hello everyone. We talked a few days ago about the design of the check library (about the compile or run-time weight parameter.) Reminder : the weights are the contribution to the running sum of a digit in a number. I used and followed your ideas and suggestions that bring me to the policies class. I tried to extract the characteristics of a "generic" check and the weight is one of these. So I tried to implement the weight policy class : #define _WEIGHT_factory(z,n,unused) \ template<BOOST_PP_ENUM_PARAMS(n, int weight)> \ struct weight_policy \ { typedef typename boost::mpl::vector_c<int BOOST_PP_COMMA_IF(n) BOOST_PP_ENUM_PARAMS(n, weight)> weight ; } ; \ BOOST_PP_REPEAT_FROM_TO(1,BOOST_CHECK_LIMIT_WEIGHTS,_WEIGHT_factory,~) #undef _WEIGHT_factory But the compiler doesn't like the "struct template parameter overloading". Is a limit of the language ? Or am I doing it in the wrong way ? If it's impossible, I though that we could passed the weights to a function that aimed to "build" the vector_c type. While we speak about the design, what do you think about the policies class ? There are useful because the core of the algorithm is the same for every checks. Every critics or suggestions are welcomed, thank you, Pierre Talbot.

3 3

GSoC Doc Camp
by Boris Schaeling 01 Aug '11

01 Aug '11

Google sent an email to the GSoC mentors list to invite to a GSoC Doc Camp - see https://sites.google.com/site/docsprintsummit/. It's five days in October just before the GSoC Mentor Summit starts. Those wishing to attend do not need to be from a GSoC project. As the application deadline is this Friday, hurry up if you are interested. Boris

1 0

Article on Boost.Asio in German computer magazine c't
by Boris Schaeling 01 Aug '11

01 Aug '11

I submitted today an article on Boost.Asio which will be published in the German computer magazine c't. I don't know yet in which edition but will tell on http://www.highscore.de/feed.atom. There may be more articles on Boost in c't in the future which I'll announce on my RSS feed then only (not to spam these lists). All of this hopefully helps to increase media coverage of Boost in the longterm. This again could help if for example BoostCon grows into something bigger. For now the article on Boost.Asio is a small step-stone. :) Boris

1 0

Book "The Boost C++ Libraries" available at Amazon, Barnes and Noble and others
by Boris Schaeling 01 Aug '11

01 Aug '11

A new edition of my book "The Boost C++ Libraries" has been published. It's not (yet) online at http://en.highscore.de/cpp/boost/ as some may expect. Instead it is available at Amazon, Barnes and Noble and others as a print book. What's new: * Several chapters were updated (to Boost.Spirit 2.x, Boost.Signals 2, Boost.Filesystem 3...) * Many new libraries are covered (Boost.CircularBuffer, Boost.Intrusive, Boost.MultiArray...) * The book has now an index (12 pages with class/function/object names used in the book) * The English has been greatly improved :) The book is based on Boost 1.47.0. It covers 38 libraries which I would describe as general purpose libraries (no libraries like Boost.Quaternions for example). It's based on C++98 and ignores C++0x (in a new edition of the book, I can for example probably drop Boost.Lambda). It has 262 pages and about as many examples. Every example is complete - it can be built and run as is (helpful if my explanations are not good enough and you want to see what an example really does :). One should be able to read the book in one or two days and know then what those 38 libraries do, when to use them and how to use them. To keep this email short - please see http://xmlpress.net/publications/boost for more information. If you read the book and have any comments or questions - please tell me! The book was written by someone part of this community, so I'm interested in what the community thinks. I also hope that I could paint a picture of the community everyone can identify with. I got a lot of feedback on my online book in the past and try to improve the book accordingly. So drop me a line if you like! Boris

1 0

what happened to context mini-review?
by Nathan Ridge 01 Aug '11

01 Aug '11

Hello, Up until a few days ago, the Review Schedule contained an entry for the mini-review of the Context library (which has previously been accepted provisionally) starting from July 28. Now the entry is gone and there is no sign of a mini-review on the list. What is the status of the library? Has the mini-review been postponed? Or will the library be accepted without a mini-review? Thanks, Nate

2 1

Re: [boost] [rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC
by Brian Wood 31 Jul '11

31 Jul '11

Daniel Larimer <dlarimer(a)gmail.com> > 1) No code generation required (best for C++ to C++, but with a proper JSON interface can communicate with any language) Code generation is being done by something here. In this case it is probably being done by a C++ compiler that starts from scratch for every file it has to compile. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net "The heavens declare the glory of G-d; and the firmament shows His handiwork." Psalm 19:1

2 1

[proto] Error with Proto Domains in 1.45
by Fernando Pelliccioni 30 Jul '11

30 Jul '11

Hi Eric, hi all, I'm getting the following errors when I try to compile the example in the atteched file. test_proto_145.cpp: In function ‘int main()’: test_proto_145.cpp:91: error: no match for ‘operator<<’ in ‘emergency << 1’ I am using Boost 1.45 and GCC 4.4.5 This works fine in 1.46.0 and above. Is there a patch ? Thanks and regards. Fernando Pelliccioni.

2 2

[fusion] mpl::clear doesn't work on fusion views
by Eric Niebler 30 Jul '11

30 Jul '11

Today I ran into a limitation in Fusion/MPL interoperability. I couldn't use an mpl algorithm on a Fusion sequence because mpl::clear wasn't defined on it. The sequence was a joint_view. I see that fusion::detail::clear is only defined for Fusion cons, map, set, vector and deque. Can we get it defined for all Fusion sequences? I think for everything else, an empty Fusion vector would do. That is all fusion::clear does, btw. (Aside: it seems strange to me that mpl::clear of a fusion::set gives an empty set, but that fusion::clear of an empty set gives an empty vector. This should probably be made consistent.) -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 4

[Review] TTI
by Noah Roberts 29 Jul '11

29 Jul '11

What is your evaluation of the design? Except for the namespace issue, which seems resolved, it seems to be what it needs to be. I don't know that there are a lot of design options here. It seems to offer a complete set of needs, from metafunction or trait to metafunction class. This is good. What is your evaluation of the implementation? Again, I don't see a lot of room to be innovative here. It's as clean as it can be I think. One thing that I think is missing is the option to check for a named callable within a type. For example, one might want to use enable_if style concept checking. So long as a type has function 'xxx' that takes arguments of type x,y,and z, and returns something convertible to type A, the concept is obeyed. I don't believe this can be done with C++03, but with C++1X I was able to do something using decltype. What is your evaluation of the documentation? Could probably use some more tutorials. What is your evaluation of the potential usefulness of the library? VERY. Having to write all these things by hand is a PITA. Most people who would have use for this library have probably already devised similar sets of macros. It would be nice to have something somewhat standardized. Did you try to use the library? No. How much effort did you put into your evaluation? Quick reading. Are you knowledgeable about the problem domain? I think I can say yes. I've had to write my own such SFINAE and overload metafunction objects numerous times. Do you think the library should be accepted as a Boost library? Yes, so long as the namespace issue is indeed fixed. For thoroughness, the namespace issue is that the current implementation places traits and metafunction objects within the boost namespace. The library would be more useful if the macro declared objects within the scope the macro is used. It's an important feature that I often declare such objects within class scope. Since they aren't providing specializations, it shouldn't be necessary to place them in the boost namespace and the author has agreed to discontinue this policy.

6 23

Is there any possibility that get VC6 support of C++11 tuple?
by 罗勇刚(Yonggang Luo) 29 Jul '11

29 Jul '11

Such as by using of Variadic Macro Data -- 此致礼罗勇刚 Yours sincerely, Yonggang Luo

2 2

[msm]exit pseudo state and event
by Takatoshi Kondo 29 Jul '11

29 Jul '11

Hello, Boost.Msm supports the UML2.0 feature "exit pseudo state". Here is a description about exit pseudo state in the document. > exit_pseudo_state > > Basic type for exit pseudo states. Exit pseudo states are an > predefined exit from a submachine and connect two transitions. > The first argument is the name of the event which will be > "thrown" out of the exit point. This event does not need to > be the same as the one sent by the inner region but must be > convertible from it. The second argument is needed if you > want your state (and all others used in a concrete state machine) > to inherit a basic type for logging or providing a common behavior. > > template<class Event,class Base = > default_base_state, { > } > class SMPtrPolicy = no_sm_ptr> > exit_pseudo_state { > } Why the 1st template parameter "Event" is needed? Consider the attached diagram "11_ExitPointEvent.png". IMHO, the Exit2 is typical usecase of exit pseudo state. Outgoing transition from exit pseudo state shouldn't have any events and guards. The point is how to divide the concerns. When we design the Sm1, we can depend only State1, State1::Exit1, State1::Exit2 and State2. And we shouldn't depend on which event triggers the transition to pseudo exit state. It's State1's concern. To implement that, I pass the "none" as 1st template parameter. namespace msmf = boost::msm::front; struct Exit2:public msm::front::exit_pseudo_state<msmf::none> {}; (See the attached file 11_ExitPointEvent.cpp) I think it is suitable for the default template parameter. The example in the Boost.Msm tutorial document, the usage of exit pseudo state is similar as Exit1 in "11_ExitPointEvent.png". The behavior that I understand is below. In State1 1. Event1 is occurred, 2. Transition to Exit1. 3. Event1 is converted to Event2 (Exit1's template argument). In Sm1 4. Dispatch Event2. 5. Transition to State2. (Entry, Exit action is omitted) Is that right? I'd like to know why such complicated mechanism is needed? Is the purpose to propagate the event parameter? Thanks, Takatoshi

3 17

Python-extension: Linker options
by Sergiy Nazarenko 29 Jul '11

29 Jul '11

Hi everyone! I'm begginers to use bjam and boost. I've built python-extension. I successfully compiled it by bjam. My Jamroot file like this: use-project boost : ../../.. ; project : requirements <library>/boost/python//boost_python ; python-extension myext : myext.cpp ; And I have custom shared library with extra functions . Now I'm trying to use extra functions in python library. My questions is how put linker options in bjam project? Something like this: -L/path/to/my/library/lib64/ -lmylib.0.1 If I append include options for a file, my MyLib.h is found but linker does not find library itself. I append like this: python-extension myext : myext.cpp <include>/path/to/my/library/include; I've tried to use following # <library-path>/path/to/my/library/lib64/ # <library-file>mylib.0.1.so but with these options my extension is not compiled. Cheers,

1 0

Lockfree review
by Phil Endecott 28 Jul '11

28 Jul '11

Dear All, Here is a quick review of the proposed Boost.Lockfree library. Utility ------- For some proposed libraries their utility is beyond doubt because they are already being used in some significant application. In contrast most GSoC projects are developed more in the "hope that they will be useful" without a motivating application. So we have to ask ourselves, does this library meet a need? To me, lock free algorithms and data structures have always seemed appealing at first sight but, apart from some trivial cases like counters, on close inspection they turn out to be too complicated to bother with. (They also lack required features, i.e. waiting for non-empty; I don't think I've ever written a producer-consumer application that didn't need the consumer to block on empty.) The author acknowledges that these structures will typically be slower than conventional implementations using mutexes, but claims that their benefit comes in terms of better worst-case latency. Specifically, if a thread is pre-empted while it holds a lock, another thread will have to wait until the first thread is re-scheduled and can unlock before it can itself lock. But this case is exactly the one that priority inversion is supposed to address: when the second thread tries to lock, the kernel immediately re-schedules the first thread. Yes, because of the kernel involvement this will probably still be slower than the lock-free approach, but perhaps not by much. It seems to me that the author should present benchmarks to demonstrate the actual worst-case latency difference between this code and a lock-based implementation. Design ------ I am happy with the design of the interface, as far as it goes; there are a few things that could be added though: - Debug modes that check the thread requirements. - Other combinations of single/multiple producer/consumer. Implementation -------------- I have looked only at the implementation of the ringbuffer class template. It lacks comments. There are some oddities like this: size_t ret = read_index - write_index - 1; if (write_index >= read_index) ret += max_size; return ret; Here, a negative value may be assigned to the unsigned size_t. I think this is actually safe, but it looks odd. I have not found any bugs. It looks like every call to enqueue() and dequeue() will access both the read and write indexes. Won't this cause poor performance due to cache issues? I would have been tempted to avoid this by keeping local 'available' counts: (PSEUDO_CODE) private: atomic<size_t> read_index_; atomic<size_t> write_index_; size_t read_available_; size_t write_available_; public: bool enqueue(...) { if (write_available_==0) { // In this case, we access read_index_ which is probably cached by the consumer thread, // which is expensive. But this is rare. write_available_ = (read_index_ + max_size - write_index_ - 1) % max_size; } if (!write_available_) return false; // full buffer[write_index_.load(memory_order_relaxed)] = data; write_index_.store((write_index_+1)%max_size); --write_available_; } // dequeue similarly... Documentation ------------- I'm not impressed by the documentation. It lacks rationale and information about the implementation. It has some formatting issues and typos (e.g. lose/loose). Platform requirements (i.e. the Boost.Atomic and/or std::atomic requirements and supported architectures) should be explained. The reference documentation involves more clicks than I would expect to reach the actual content. Some functions are marked as "for debugging only", e.g. the empty() and reset() [which should probably be called clear()] methods. It's not clear to me why these methods must be unsafe; for example, for the ringbuffer, I would expect the consumer thread to safely be able to call empty() and the producer to safely be able to call full() (which is not provided). Rationale for these restrictions (or relaxations of them) would be useful. - Did you try to use the library? With what compiler? Did you have any problems? I considered exercising the library on my ARM systems, but I realised that it requires 64-bit atomics; currently, Boost.Atomic only provides 32-bit atomics on ARM. (This raises the whole issue of the Boost.Atomic dependency. I'm presuming that Tim intends not to bundle a Boost.Atomic snapshot with the library if approved. If that changes, we really need another review.) - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours reading the docs and code. - Are you knowledgeable about the problem domain? I know a certain amount about atomics and lock-based concurrent programming, but not much about lock-free data structures. - Please always state in your review, whether you think the library should be accepted as a Boost library! I think it should be accepted provided that: * The author demonstrates some measurable benefit over lock-based data structures. * The documentation is improved to describe the implementation and to provide rationale for design decisions. * The library is not added to Boost until Boost.Atomic has been reviewed and approved (or, available std::atomic implementations work with it). Regards, Phil.

2 1

sandbox or boost vault
by Sean Farrow 28 Jul '11

28 Jul '11

Hi: Given that the boost vault has been down for quite a few months, where are all new bosot libraries going for review, in the boost vault-with a different url, or in the boost sandbox in the svn repository? Any help appreciated. Regards Sean.

11 34

[Lockfree review] Meta-comments
by Phil Endecott 28 Jul '11

28 Jul '11

Dear all, I have a few meta comments about the Lockfree review and reviews in general: 1. I know a lot of people read this list via gmane.org. A bug in gmane.org means that when a message is posted to more than one list - for example, a review announcement sent to this list and announce@ - then it appears only in one, and follow-ups are lost. So gmane.org readers will have missed most of this review. Of course a valid answer would be "they should fix it", but considering how few reviews have been written recently I think we should do everything possible to increase discussion. I don't know if review managers get a "how to run your review" document, but assuming that they do, I suggest adding "please post separate announcements to each list, not one message to all". 2. I think every candidate library should have an online copy of its documentation. Again, I think this should be on the review manager's checklist. Yes, you could say that people should be able to download and unzip and/or build their own copy of the docs, but again, we need more reviews and we need to remove as many obstacles (real or imagined) as possible. (In the last review I asked "Where are the online docs?" and it turned out that they were available but I had missed them; oops. If I have once again missed them, oops again.) 3. This has already been discussed to some extent, but why are we reviewing this before Boost.Atomic? I think Boost.Atomic is an urgently-required library. What can we all do to help it get submitted and accepted as soon as possible? Regards, Phil.

8 19

[Lockfree] Tagged pointers
by Phil Endecott 28 Jul '11

28 Jul '11

Tim & others, I understand that your implementation uses tagged pointers to avoid ABA problems. An issue with tagged pointers is that naively they will be 2*sizeof(T*) and systems may not have atomic operations that operate on things of that size. Looking at the code, I see that you also have a "compressed" tagged pointer that is enabled for some architectures. Having found this code, I now vaguely recall some previous mailing list discussions about this. Sometimes it may be possible to claim that users (& reviewers?) of a library do not need to know about details of this sort because the library "just works", and that if they are curious they can read the source. I don't think this is one of those cases. The documentation should explain in outline how this works, and provide rationale for why it is how it is. IIRC, ARM has 64-bit atomics only from architecture version 6k onwards, and my Boost.Atomic ARM code doesn't use them. This could be fixed. Regards, Phil.

2 1

boost threads: pthread mutex priority inheritance
by Jason Newton 28 Jul '11

28 Jul '11

Hi, I just discovered today that pthread mutex's aren't guaranteed to do priority inheritance unless PTHREAD_PRIO_INHERIT is set. I'm doing a bunch of soft-rt work with SCHED_RR so priority inheritance on shared resources is a given necessity. But how should this be worked into boost mutex? There's no way of constructing a boost mutex from an existing object, nor anyway of setting mutex attributes used inside the ctor. There's also no way of manipulating the mutex attributes after pthread_mutex_init. For the moment, the few lines that compose the mutex class are easily copied so that I can do my own business inside the constructor but I expect others will run into this problem down the line and this solution is a bit unsavory. Any better advice?

1 1

[context] MinGW support?
by Nathan Ridge 27 Jul '11

27 Jul '11

Hello, I would like to play around with the (provisionally accepted) Boost.Context library, and I'm wondering: does it support MinGW? First, I should mention, I am using the source from http://ok73.ok.funpic.de/boost.context-0.7.4.zip, but I'm not sure whether this is the latest version - the link to the source at http://www.boost.org/community/review_schedule.html is broken (it points to the Boost Vault, which is down, and I can't find it at https://github.com/boost-vault) I tried to compile it both in 64-bit mode using: toolset=gcc architecture=x86 instruction-set=yorksfield address-model=64 and in 32-bit mode using: toolset=gcc architecture=x86 instruction-set=i686 address-model=32 but in both cases I get errors (pasted below). Am I doing something wrong, or does this library not support MinGW? If the latter, is MinGW support planned at some point? Thanks, Nate 64-bit errors: gcc.compile.c++ bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instruction-set-york sfield\link-static\protected_stack_windows.o libs\context\src\protected_stack_windows.cpp:1:0: sorry, unimplemented: 64-bit mode not compiled in "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -m64 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c - o "bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instruction-set-yorksfield\link-s tatic\protected_stack_windows.o" "libs\context\src\protected_stack_windows.cpp" ...failed gcc.compile.c++ bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instructio n-set-yorksfield\link-static\protected_stack_windows.o... common.mkdir bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instruction-set-yorksfi eld\link-static\asm gcc.compile.asm bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instruction-set-york sfield\link-static\asm\fcontext_x86_64_ms_pe_masm.o libs\context\src\asm\fcontext_x86_64_ms_pe_masm.asm:1:0: sorry, unimplemented: 64-bit mode not compiled in "g++" -x assembler-with-cpp -O3 -finline-functions -Wno-inline -Wall -m64 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instruction-set-yorksfield\link-sta tic\asm\fcontext_x86_64_ms_pe_masm.o" "libs\context\src\asm\fcontext_x86_64_ms_pe_masm.asm" ...failed gcc.compile.asm bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instructio n-set-yorksfield\link-static\asm\fcontext_x86_64_ms_pe_masm.o... gcc.compile.c++ bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instruction-set-york sfield\link-static\stack_helper_windows.o libs\context\src\stack_helper_windows.cpp:1:0: sorry, unimplemented: 64-bit mode not compiled in "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -m64 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c - o "bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instruction-set-yorksfield\link-s tatic\stack_helper_windows.o" "libs\context\src\stack_helper_windows.cpp" ...failed gcc.compile.c++ bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instructio n-set-yorksfield\link-static\stack_helper_windows.o... gcc.compile.c++ bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instruction-set-york sfield\link-static\seh.o libs\context\src\seh.cpp:1:0: sorry, unimplemented: 64-bit mode not compiled in "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -m64 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c - o "bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instruction-set-yorksfield\link-s tatic\seh.o" "libs\context\src\seh.cpp" ...failed gcc.compile.c++ bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instructio n-set-yorksfield\link-static\seh.o... ...skipped <pbin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instruction-set-yorksfi eld\link-static>libboost_context-mgw46-1_46_1.a(clean) for lack of <pbin.v2\libs\context\build\gcc-mingw-4.6.0\release\a ddress-model-64\architecture-x86\instruction-set-yorksfield\link-static>protected_stack_windows.o... ...skipped <pbin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-64\architecture-x86\instruction-set-yorksfi eld\link-static>libboost_context-mgw46-1_46_1.a for lack of <pbin.v2\libs\context\build\gcc-mingw-4.6.0\release\address- model-64\architecture-x86\instruction-set-yorksfield\link-static>protected_stack_windows.o... ...skipped <pstage\lib>libboost_context-mgw46-1_46_1.a for lack of <pbin.v2\libs\context\build\gcc-mingw-4.6.0\release\a ddress-model-64\architecture-x86\instruction-set-yorksfield\link-static>libboost_context-mgw46-1_46_1.a... ...failed updating 4 targets... ...skipped 3 targets... ...updated 9 targets... 32-bit errors: cc.compile.c++ bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-32\architecture-x86\instruction-set-i686 link-static\protected_stack_windows.o ibs\context\src\protected_stack_windows.cpp: In constructor 'boost::contexts::protected_stack::protected_stack(std::siz _t)': ibs\context\src\protected_stack_windows.cpp:60:16: warning: unused variable 'result' [-Wunused-variable] ommon.mkdir bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-32\architecture-x86\instruction-set-i686\li k-static\asm cc.compile.asm bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-32\architecture-x86\instruction-set-i686 link-static\asm\fcontext_i386_ms_pe_masm.o ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm: Assembler messages: ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:2: Error: no such instruction: `copyright Oliver Kowalke 2009.' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:3: Error: no such instruction: `distributed under the Boost Software L cense,Version 1.0.' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:4: Error: junk at end of line, first unrecognized character is `(' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:7: Error: junk at end of line, first unrecognized character is `-' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:8: Error: junk at end of line, first unrecognized character is `|' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:9: Error: junk at end of line, first unrecognized character is `-' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:10: Error: junk at end of line, first unrecognized character is `|' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:11: Error: junk at end of line, first unrecognized character is `-' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:12: Error: junk at end of line, first unrecognized character is `|' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:13: Error: junk at end of line, first unrecognized character is `-' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:14: Error: junk at end of line, first unrecognized character is `-' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:15: Error: junk at end of line, first unrecognized character is `|' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:16: Error: junk at end of line, first unrecognized character is `-' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:17: Error: junk at end of line, first unrecognized character is `|' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:18: Error: junk at end of line, first unrecognized character is `-' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:19: Error: junk at end of line, first unrecognized character is `|' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:20: Error: junk at end of line, first unrecognized character is `-' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:21: Error: junk at end of line, first unrecognized character is `-' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:22: Error: junk at end of line, first unrecognized character is `|' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:23: Error: junk at end of line, first unrecognized character is `-' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:24: Error: junk at end of line, first unrecognized character is `|' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:25: Error: junk at end of line, first unrecognized character is `-' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:26: Error: junk at end of line, first unrecognized character is `|' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:27: Error: junk at end of line, first unrecognized character is `-' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:29: Error: unknown pseudo-op: `.386' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:30: Error: unknown pseudo-op: `.xmm' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:31: Error: unknown pseudo-op: `.model' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:32: Error: no such instruction: `_exit PROTO,value:SDWORD' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:33: Error: no such instruction: `boost_fcontext_seh PROTO,except:DWORD frame:DWORD,context:DWORD,dispatch:DWORD' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:34: Error: unknown pseudo-op: `.code' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:36: Error: no such instruction: `boost_fcontext_jump PROC EXPORT' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:37: Error: invalid char '[' beginning operand 2 `[esp+04h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:37: Error: no such instruction: `load address of the first fcontext_t rg' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:38: Error: invalid char '[' beginning operand 1 `[eax]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:38: Error: no such instruction: `save EDI' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:39: Error: invalid char '[' beginning operand 1 `[eax+04h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:39: Error: no such instruction: `save ESI' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:40: Error: invalid char '[' beginning operand 1 `[eax+08h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:40: Error: no such instruction: `save EBX' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:41: Error: invalid char '[' beginning operand 1 `[eax+0ch]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:41: Error: no such instruction: `save EBP' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:43: Error: no such instruction: `assume fs:nothing' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:44: Error: too many memory references for `mov' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:44: Error: no such instruction: `load NT_TIB' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:45: Error: no such instruction: `assume fs:error' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:46: Error: invalid char '[' beginning operand 2 `[edx]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:46: Error: no such instruction: `load current SEH exception list' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:47: Error: invalid char '[' beginning operand 1 `[eax+02ch]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:47: Error: no such instruction: `save current exception list' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:48: Error: invalid char '[' beginning operand 2 `[edx+04h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:48: Error: no such instruction: `load current stack base' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:49: Error: invalid char '[' beginning operand 1 `[eax+020h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:49: Error: no such instruction: `save current stack base' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:50: Error: invalid char '[' beginning operand 2 `[edx+08h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:50: Error: no such instruction: `load current stack limit' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:51: Error: invalid char '[' beginning operand 1 `[eax+024h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:51: Error: no such instruction: `save current stack limit' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:52: Error: invalid char '[' beginning operand 2 `[edx+010h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:52: Error: no such instruction: `load fiber local storage' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:53: Error: invalid char '[' beginning operand 1 `[eax+030h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:53: Error: no such instruction: `save fiber local storage' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:55: Error: invalid char '[' beginning operand 1 `[eax+018h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:55: Error: no such instruction: `save SSE2 control word' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:56: Error: invalid char '[' beginning operand 1 `[eax+01ch]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:56: Error: no such instruction: `save x87 control word' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:58: Error: invalid char '[' beginning operand 2 `[esp+04h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:58: Error: no such instruction: `exclude the return address' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:59: Error: invalid char '[' beginning operand 1 `[eax+010h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:59: Error: no such instruction: `save as stack pointer' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:60: Error: invalid char '[' beginning operand 2 `[esp]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:60: Error: no such instruction: `load return address' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:61: Error: invalid char '[' beginning operand 1 `[eax+014h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:61: Error: no such instruction: `save return address' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:64: Error: invalid char '[' beginning operand 2 `[esp+08h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:64: Error: no such instruction: `load address of the second fcontext_t arg' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:65: Error: invalid char '[' beginning operand 2 `[eax]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:65: Error: no such instruction: `restore EDI' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:66: Error: invalid char '[' beginning operand 2 `[eax+04h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:66: Error: no such instruction: `restore ESI' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:67: Error: invalid char '[' beginning operand 2 `[eax+08h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:67: Error: no such instruction: `restore EBX' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:68: Error: invalid char '[' beginning operand 2 `[eax+0ch]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:68: Error: no such instruction: `restore EBP' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:70: Error: no such instruction: `assume fs:nothing' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:71: Error: too many memory references for `mov' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:71: Error: no such instruction: `load NT_TIB' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:72: Error: no such instruction: `assume fs:error' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:73: Error: invalid char '[' beginning operand 2 `[eax+02ch]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:73: Error: no such instruction: `load SEH exception list' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:74: Error: invalid char '[' beginning operand 1 `[edx]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:74: Error: no such instruction: `restore next SEH item' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:75: Error: invalid char '[' beginning operand 2 `[eax+020h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:75: Error: no such instruction: `load stack base' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:76: Error: invalid char '[' beginning operand 1 `[edx+04h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:76: Error: no such instruction: `restore stack base' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:77: Error: invalid char '[' beginning operand 2 `[eax+024h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:77: Error: no such instruction: `load stack limit' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:78: Error: invalid char '[' beginning operand 1 `[edx+08h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:78: Error: no such instruction: `restore stack limit' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:79: Error: invalid char '[' beginning operand 2 `[eax+030h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:79: Error: no such instruction: `load fiber local storage' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:80: Error: invalid char '[' beginning operand 1 `[edx+010h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:80: Error: no such instruction: `restore fiber local storage' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:82: Error: invalid char '[' beginning operand 1 `[eax+018h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:82: Error: no such instruction: `restore SSE2 control word' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:83: Error: invalid char '[' beginning operand 1 `[eax+01ch]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:83: Error: no such instruction: `restore x87 control word' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:85: Error: invalid char '[' beginning operand 2 `[eax+010h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:85: Error: no such instruction: `restore ESP' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:86: Error: invalid char '[' beginning operand 2 `[eax+014h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:86: Error: no such instruction: `fetch the address to return to' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:88: Error: too many memory references for `xor' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:88: Error: no such instruction: `set EAX to zero' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:89: Error: no such instruction: `indirect jump to context' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:90: Error: no such instruction: `boost_fcontext_jump ENDP' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:92: Error: no such instruction: `boost_fcontext_make PROC EXPORT' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:93: Error: invalid char '[' beginning operand 2 `[esp+04h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:93: Error: no such instruction: `load address of the fcontext_t arg0' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:94: Error: invalid char '[' beginning operand 1 `[eax]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:94: Error: no such instruction: `save the address of current context' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:95: Error: invalid char '[' beginning operand 2 `[esp+08h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:95: Error: no such instruction: `load the address of the function supp sed to run' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:96: Error: invalid char '[' beginning operand 1 `[eax+014h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:96: Error: no such instruction: `save the address of the function supp sed to run' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:97: Error: invalid char '[' beginning operand 2 `[eax+020h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:97: Error: no such instruction: `load the stack base' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:98: Error: invalid char '[' beginning operand 2 `[edx-014h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:98: Error: no such instruction: `reserve space for last frame on stack (ESP+4)% 16==0' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:99: Error: invalid char '[' beginning operand 1 `[eax+010h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:99: Error: no such instruction: `save the address' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:101: Error: too many memory references for `mov' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:101: Error: no such instruction: `set ECX to exception-handler' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:102: Error: invalid char '[' beginning operand 1 `[edx+0ch]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:102: Error: no such instruction: `save ECX as SEH handler' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:103: Error: too many memory references for `mov' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:103: Error: no such instruction: `set ECX to -1' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:104: Error: invalid char '[' beginning operand 1 `[edx+08h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:104: Error: no such instruction: `save ECX as next SEH item' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:105: Error: invalid char '[' beginning operand 2 `[edx+08h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:105: Error: no such instruction: `load address of next SEH item' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:106: Error: invalid char '[' beginning operand 1 `[eax+02ch]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:106: Error: no such instruction: `save next SEH' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:108: Error: invalid char '[' beginning operand 2 `[eax+028h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:108: Error: no such instruction: `load the address of the next context ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:109: Error: invalid char '[' beginning operand 1 `[eax+04h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:109: Error: no such instruction: `save the address of the next context ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:110: Error: invalid char '[' beginning operand 2 `[esp+0ch]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:110: Error: no such instruction: `load the address of the void pointer arg2' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:111: Error: invalid char '[' beginning operand 1 `[edx+04h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:111: Error: no such instruction: `save the address of the void pointer onto the context stack' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:112: Error: invalid char '[' beginning operand 1 `[eax+018h]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:112: Error: no such instruction: `save SSE2 control word' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:113: Error: invalid char '[' beginning operand 1 `[eax+01ch]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:113: Error: no such instruction: `save x87 control word' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:114: Error: too many memory references for `mov' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:114: Error: no such instruction: `load helper code executed after fn() eturns' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:115: Error: invalid char '[' beginning operand 1 `[edx]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:115: Error: no such instruction: `save helper code executed adter fn() eturns' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:116: Error: too many memory references for `xor' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:116: Error: no such instruction: `set EAX to zero' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:118: Error: no such instruction: `boost_fcontext_make ENDP' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:120: Error: no such instruction: `boost_fcontext_link PROC' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:121: Error: invalid char '[' beginning operand 2 `[esp-0ch]' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:121: Error: no such instruction: `adjust the stack to proper boundarie ' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:122: Error: too many memory references for `test' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:122: Error: junk `a next context was given' after expression ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:122: Error: number of operands mismatch for `test' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:123: Error: no such instruction: `jump to finish' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:125: Error: junk `address of the next context on the stack' after expr ssion ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:126: Error: junk `address of the current context on the stack' after e pression ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:127: Error: no such instruction: `install next context' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:130: Error: too many memory references for `xor' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:130: Error: no such instruction: `set EAX to zero' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:131: Error: no such instruction: `exit code is zero' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:132: Error: no such instruction: `exit application' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:134: Error: no such instruction: `boost_fcontext_link ENDP' ibs\context\src\asm\fcontext_i386_ms_pe_masm.asm:135: Error: no such instruction: `end' "g++" -x assembler-with-cpp -O3 -finline-functions -Wno-inline -Wall -march=i686 -m32 -DBOOST_ALL_NO_LIB=1 -DNDEBUG I"." -c -o "bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-32\architecture-x86\instruction-set-i686\li k-static\asm\fcontext_i386_ms_pe_masm.o" "libs\context\src\asm\fcontext_i386_ms_pe_masm.asm" ..failed gcc.compile.asm bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-32\architecture-x86\instructio -set-i686\link-static\asm\fcontext_i386_ms_pe_masm.o... cc.compile.c++ bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-32\architecture-x86\instruction-set-i686 link-static\stack_helper_windows.o cc.compile.c++ bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-32\architecture-x86\instruction-set-i686 link-static\seh.o ibs\context\src\seh.cpp: In function 'char* exception_description(const _EXCEPTION_RECORD*, char*, size_t)': ibs\context\src\seh.cpp:21:40: error: '_TRUNCATE' was not declared in this scope ibs\context\src\seh.cpp:21:100: error: '_snprintf_s' was not declared in this scope ibs\context\src\seh.cpp:24:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:25:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:26:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:27:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:28:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:29:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:30:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:31:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:32:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:33:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:34:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:35:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:36:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:37:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:38:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:39:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:40:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:41:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:42:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:43:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:44:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] ibs\context\src\seh.cpp:47:36: error: '_TRUNCATE' was not declared in this scope ibs\context\src\seh.cpp:47:71: error: '_snprintf_s' was not declared in this scope ibs\context\src\seh.cpp: At global scope: ibs\context\src\seh.cpp:52:1: error: 'EXCEPTION_DISPOSITION' does not name a type ibs\context\src\seh.cpp:9:15: warning: 'char* exception_description(const _EXCEPTION_RECORD*, char*, size_t)' defined b t not used [-Wunused-function] "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -march=i686 -m32 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-32\architecture-x86\instruction-set-i686\ ink-static\seh.o" "libs\context\src\seh.cpp" ..failed gcc.compile.c++ bin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-32\architecture-x86\instructio -set-i686\link-static\seh.o... ..skipped <pbin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-32\architecture-x86\instruction-set-i686\li k-static>libboost_context-mgw46-1_46_1.a(clean) for lack of <pbin.v2\libs\context\build\gcc-mingw-4.6.0\release\address model-32\architecture-x86\instruction-set-i686\link-static>asm\fcontext_i386_ms_pe_masm.o... ..skipped <pbin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model-32\architecture-x86\instruction-set-i686\li k-static>libboost_context-mgw46-1_46_1.a for lack of <pbin.v2\libs\context\build\gcc-mingw-4.6.0\release\address-model- 2\architecture-x86\instruction-set-i686\link-static>asm\fcontext_i386_ms_pe_masm.o... ..skipped <pstage\lib>libboost_context-mgw46-1_46_1.a for lack of <pbin.v2\libs\context\build\gcc-mingw-4.6.0\release\a dress-model-32\architecture-x86\instruction-set-i686\link-static>libboost_context-mgw46-1_46_1.a... ..failed updating 2 targets... ..skipped 3 targets... ..updated 7 targets...

3 12

BOOST_CLASS_EXPORT in C++
by Eric Maes 27 Jul '11

27 Jul '11

Hello all, I am new to the boost community and libraries and need some help. I am taking over a small project which uses boost serialization. We are having trouble using the BOOST_CLASS_EXPORT macro with version 1.39. We are in the process of upgrading to v1.47, but have not yet complete the transition on our other supporting DLLs. My question is this: When we include the macro in our CPP file, it builds ok and appears to be ready to rock, however when we attempt to serialze the object, an exception is thrown. after stepping deeply, we see that the derived class load_construct_data and save_construct_data methods are not getting called. We have followed the documentation and it appears we have it implemented properly. Shown here are code snippets of what we are doing... When the macro use was in the HPP files, the serialization worked, but then an exception was thrown when the application ends. Either way, there is an issue. From what I can tell in boost docs, the macro use needs to be in the CPP and not in the HPP If anyone can give assistance that would be great. I am so new to Boost that I'm not sure I am using the right nomanclature to describe what is occuring. Any help that I can get will be much appreciated. Eric emaes(a)miengsrv.com // ************ derived class (Calculator) load/save definition ********* // template inline void save_construct_data (Archive& ar, const LpsTktMDO::Calculator* t, const unsigned int file_version) { // save data required to construct instance Lps::CharString name; Lps::CharString expression; name=t->getName (); expression=t->getExpression (); ar << boost::serialization::make_nvp ("name", name); ar << boost::serialization::make_nvp ("expression", expression); } //! //! Serialization method for loading a Calculator object //! //! \return None //! template inline void load_construct_data (Archive& ar, LpsTktMDO::Calculator* t, const unsigned int file_version) { // retrieve data from archive required to construct new instance Lps::CharString name; Lps::CharString expression; ar >> boost::serialization::make_nvp ("name", name); ar >> boost::serialization::make_nvp ("expression", expression); // invoke inplace constructor to initialize instance of my_class ::new(t)LpsTktMDO::Calculator (name, expression); } // ************ base class (Function) serialize definition ********* // template void serialize (Archive & ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP (theNameM); ar & BOOST_SERIALIZATION_NVP (thePmmIdM); ar & BOOST_SERIALIZATION_NVP (theDataMgrM); }; // ************ call to serialize the map of calculator/function objects (which is a member of a PreDef object) ********* // template void serialize (Archive & ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP (theDesignVariablesM); // <<-------- this works ar & BOOST_SERIALIZATION_NVP (theVariablesM); // <<-------- this works ar & BOOST_SERIALIZATION_NVP (theFunctionsM); // <<-------- this call issues the exception! ar & BOOST_SERIALIZATION_NVP (theDataMgrM); // <<-------- this works }; // ************ call to serialize the PreDef object ********* // BOOST_CHECK_NO_THROW(theOa << BOOST_SERIALIZATION_NVP(thePreDefM)); -- View this message in context: http://boost.2283326.n4.nabble.com/BOOST-CLASS-EXPORT-in-C-tp3696005p369600… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[lockfree] review
by Artyom Beilis 27 Jul '11

27 Jul '11

Hello, Please consider it as a 1/2 or 1/3 review as I hadn't much time to review this library: I'd start answering the questions in little bit different order: ------------------------------------------------------ - What is your evaluation of the design? Basically it looks quite simple and straight forward. As the data structures are based (according to the author) on the current papers and studies; it uses quite standard features and seems fine. ------------------------------------------------------ - What is your evaluation of the implementation? It seems to be clear, however I miss following: As it is virtually impossible to test concurrent data structures I expect that every critical part in the code that describes concurrent operation would have a reference to specific article or book and include full description and even a small proof that it is right taken from the resources. I think it is very critical for maintenance of the library and in ensuring the fact that it can be maintainable. Finally it looks like a solid code written with good knowledge of what is going on. ------------------------------------------------------ - What is your evaluation of the documentation? I think it is too brief and misses important parts. For example: html/boost/lockfree/ringbuffer.html Should include in the reference general requirements like it should be single writer single reader and not mentioned in some other places. In the first glance I assumed that it was multiple-readers-writers ring buffer. ------------------------------------------------------ - Did you try to use the library? With what compiler? Did you have any problems? I've tested it with gcc-4.3 on cygwin using CMake scripts,no particular problems. ------------------------------------------------------ - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've spend 2-3 hours reading the code, comparing my own "ringbuffer" with a provided ring buffer and fifo. ------------------------------------------------------ - What is your evaluation of the potential usefulness of the library? ok... This is probably the biggest problem with this library. I understand that Linked List, Stack, Ring are actually the implementable data structures (most of others are much harder to do if possible at all, even thou there are few that can be implemented: hash tables and some others) I understand that this is "lock-free" library not generic-concurrent-data-structures library but this is why I think that it may not be as useful as it seems. I'd like to see more: 1. Queues with OS support like waiting - non-waiting with lock-free access when the queue not-empty and not-full 2. Queues with different optimization for different cases. 3. There are several ways to optimize stacks to reduce contention. 4. Some transactional memory blocks that allow to implement optimistic strategies 5. Combination of locking and lock-free parts. 6. Hash tables And more. ------------------------------------------------------ - Are you knowledgeable about the problem domain? Yes: - I had implemented several concurrent data structures for professional needs. - I had took Prof. Nir Shavit's course in concurrent programming (The author of the The Art of Multiprocessor Programming) ------------------------------------------------------ Should the library be accepted into Boost? I have doubts, mostly because my considerations about the usability of the library in the real applications. I'd expect the author to provide more data structures more available policies, for example there are several ways to optimize stack object see "The Art of Multiprocessor Programming" chapter 11 section 4. Also I'd like to see some more helpful objects in the interface: Tagged ptr is something that would be seen for many data structures I don't think should it be in details? I really hesitate between "Conditional YES" and "YES" - Finally it seems to be doing what it does - It is not concurrent data structures library but lock-free one. So I vote "Yes" but I strongly recommend and expect from the author: - Make some building blocks available in detains to library interface allowing users to implement other data-structures easier. - Improve documentation about what and how it should be done - Provide more data structures in future and provide data structures with different policies Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

3 2

Boost.Locale 'Status'?
by Joshua Boyce 27 Jul '11

27 Jul '11

I was wondering what the 'status' of the Boost.Locale library is now that it has been accepted into Boost. I can't see it on the SVN, what are the current plans for its integration into mainline Boost? Thanks.

4 12

[chrono] gcc visibility support patch
by Jürgen Hunold 27 Jul '11

27 Jul '11

Hi, I've found some missing patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for Boost.Chrono For more information, please see http://gcc.gnu.org/wiki/Visibility Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

[Opaque] Request for interest in Opaque typedefs library emulation
by vicente.botet 27 Jul '11

27 Jul '11

Hi, I have started to play with a class to define opaque typedefs on funcdamental types. It is based on the C++ proposal " Progress toward Opaque Typedefs for C++0X" by Walter E. Brown http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1706.pdf Please take a look on the preceding links to understand the motivation. Boost.Sericalization provide a BOOST_STRONG_TYPEDEF already, but in my opinon the implementation is not complete,as only the order operators are defined (But maybe I'm wrong). Evidently it can not provide everything we can have with a language approach, but IMO this could yet be useful. The library include two class templates (CRTP) to define opaque types: * public_opaque_type<OT,UT> : implicit conversion from OT to UT * private_opaque_type<OT,UT> : no conversion from OT to UT An opaque type (OT) is a new type, different from the underlying type (UT) and other OT. It defines explicit constructor from the UT, and defines all the operators the UT support but this time applied to the OT. To define a new OT with this mixin classes struct serial_number: public_opaque_type<serial_number, unsigned> { BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned); }; struct game_score: private_opaque_type<game_score, unsigned> { BOOST_OPAQUE_PRIVATE_FORWARD_CONSTRUCTORS(game_score,unsigned); }; In addition, defines macros that make this simpler BOOST_OPAQUE_PUBLIC_TYPEDEF(unsigned, serial_number); BOOST_OPAQUE_PRIVATE_TYPEDEF(unsigned, game_score); Next follows the definition of the public_opaque_type template <typename Final, typename T> class public_opaque_type : boost::totally_ordered< Final , boost::integer_arithmetic< Final , boost::bitwise< Final , boost::unit_steppable< Final , boost::totally_ordered< T, Final // public specific conversions , boost::integer_arithmetic< T, Final // public specific conversions , boost::bitwise< T, Final // public specific conversions > > > > > > > { protected: T val_; typedef public_opaque_type opaque_type; public: typedef T underlying_type; explicit public_opaque_type(const T v) : val_(v) {}; public_opaque_type() {}; public_opaque_type(const opaque_type & rhs) : val_(rhs.val_) {} public_opaque_type & operator=(const opaque_type & rhs) { val_ = rhs.val_; return *this; } public_opaque_type & operator=(const T rhs) { val_ = rhs; return *this; } T const& underlying() const { return val_; } T& underlying() { return val_; } operator const T & () const { return val_; } operator T & () { return val_; } #if 0 bool operator==(const opaque_type & rhs) const { return val_ == rhs.val_; } #endif bool operator<(const Final & rhs) const { return val_ < rhs.val_; } Final& operator+=(const Final & rhs) { val_ += rhs.val_; return static_cast<Final&>(*this); } Final& operator-=(const Final & rhs) { val_ -= rhs.val_; return static_cast<Final&>(*this); } ... }; I have started to make some tests and it works well for the moment. Limitations: * As we can not specialize the behaviour of static_cast/dynamic_cast the library sould provide two specific casts opaque_static_cast and opaque_dynamic_static_cast (Not yet implemented). * As operator.() can not be overloaded, it works transparently only for underlying types that don't defines member functions (C++ fundamental types, as int, char, ...). For the others an explicit use of the underlying() member function is needed :( * Others I have not catched yet :( Do you think it is worth continuing? Please, let me know if you see a error on the design. _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 8

[1.48.0] Proposed Release Schedule
by Beman Dawes 27 Jul '11

27 Jul '11

Give we are already in the middle of July, I feel strongly 1.48.0 should target the first Monday in November, thus putting us back on our usual quarterly cycle. In our earlier schedule discussion, there was some interest in a three times a year release schedule, but the arguments were not convincing to me, so I really think we should keep to our quarterly schedule. The current formula for intermediate dates goes like this: * One week after prior release ships: branches/release opens for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. * Seven weeks before release: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * Six weeks before release: QA checks on snapshot doc builds, inspect status, getting started guide, and install. * Four weeks before release: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * Three weeks before release: branches/release closed for all library changes except when specific permission given by release manager(s). * Two weeks before release: Beta target date. Further betas and/or release candidates as feedback dictates. I propose that the Beta be scheduled for *Four* weeks before the release target date. All the other intermediate dates would thus be two weeks earlier. That's more or less what we did for 1.47.0 and it allowed enough time to fix a bunch of bugs in the beta that were bothering users. --Beman

10 13

Lockfree impl comment - does not seem to be compatible with Boost::Interprocess (shared memory) [SEC=UNCLASSIFIED]
by Levy, Gabriel (Contractor) 27 Jul '11

27 Jul '11

UNCLASSIFIED Hi, Since Lockfree library (by Tim Blechmann) is in the review stage I have a comment to make. I only looked at the code just at a glance to check if it would be able to be used with Boost::Interprocess library, especially to be placed in the shared memory and to me it definitely doesn't seem to deduce the pointer types from the Allocation supplied as a template argument. For any container implementation to be useable with Interprocess shared memory the requirement is that any internal pointer types are not explicitly stated - instead they aggregate the pointer types from the Allocator's internal pointer typedefs. By this the container will use "smart" or plain pointers, whichever the Allocators specify/define. Good place to look at for how this should be done is <boost/interprocess/containers/map.hpp> and other containers' implementation in that location. Also the Interprocess documentation explains why, for instance, the std::map or std::vector containers are incorrectly (not generically enough) implemented and suggests a possibility of potential future corrections in STL implementations (that part is only speculative, of course). While in its current form it is already very useful in intra-process applications, I would consider the incompatiblity with Interprocess' shared memory a hugely missed opportunity. My recommendation would be to first to address this issue before accepting it for inclusion. Thank you all so much for the Boost - the best thing that happened to C++. Kindest regards Gabe Gabe Levy Senior Software Engineer, Contractor, Estrings Pty Ltd IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email.

2 1

shared_ptr<>: why no operator[] ?
by dgwsoft 27 Jul '11

27 Jul '11

boost::shared_ptr<int> p(new int(42)); To access elements of the array I can do: p.get()[10] = 7; But wouldn't it be nicer to do: p[10] = 7; // ? So: why is no T& operator[](int) defined for shared_ptr ? I'm just interested in the design reasons for this. cheers Gareth -- View this message in context: http://boost.2283326.n4.nabble.com/shared-ptr-why-no-operator-tp3697208p369… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 5

[Review] Lockfree review: two more days left
by Hartmut Kaiser 26 Jul '11

26 Jul '11

Hi all, We have two more days left for the review of Tim Blechmann's Lockfree library. If you're interested in this library, please consider contributing a review! Please see the original (slightly corrected) announcement below: ----------------------------------------------------- About the library: Boost.Lockfree provides implementations of lock-free data structures. Lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. Lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. The following data structures are provided: - boost::lockfree::fifo, a lock-free fifo queue - boost::lockfree::stack, a lock-free stack - boost::lockfree::ringbuffer, a wait-free single-producer/single-consumer ringbuffer. The library is accessible from here: http://tim.klingt.org/boost_lockfree.tar.gz. Boost.Lockfree depends on C++0x atomics. They are not well supported with current compilers yet. For this reason Boost.Lockfree depends on the *unreviewed* Boost.Atomic library, that emulates C++0x atomics for C++98. This review is about Boost.Lockfree and not about Boost.Atomic, although it is included in the tarball and the git repository. If Boost.Lockfree will be accepted, it won't be merged into trunk before Boost.Atomic is accepted. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

3 2

[range] Should ranges really propagate constess to the data ?
by Samuel Debionne 26 Jul '11

26 Jul '11

Hello everyone, Here is an example code that motivates my question : typedef std::vector<int> vector_t; boost::sub_range<vector_t> three_first(vector_t& _v) {return boost::make_iterator_range(_v.begin(), _v.begin() + 3); } int main(int argc, char* argv[]) { vector_t v; boost::fill(three_first(v), 1); // Fail : you cannot assign to a variable that is const return 0; } Taken from Boost.GIL documentation, the definition of image views is : An image view is a generalization of STL's range concept to multiple dimensions. Similar to ranges (and iterators), image views are shallow, don't own the underlying data and don't propagate their constness over the data. For example, a constant image view cannot be resized, but may allow modifying the pixels. For pixel-immutable operations, use constant-value image view (also called non-mutable image view). I expected the range concept to follow these lines regarding constness, but I'm not very sure anymore... for instance sub_range have : iterator begin() { return base::begin(); } *const_iterator* begin() const { return base::begin(); } and boost::begin() is : inline range_iterator<T>::type begin( T& r ) {...} inline range_iterator<*const* T>::type begin( const T& r ) {...} which means that I'm probably wrong. Am I missing something ? Regards, Samuel

7 15

[regex] How robust are the <boost/regex/pending/unicode_iterator.hpp> adapters?
by Beman Dawes 26 Jul '11

26 Jul '11

Boost.Filesystem needs the UTF-32 to UTF-16 and UTF-16 to UTF-32 adapters to implement char16_t and char32_t support. Do they have any known bugs or other outstanding problems? TIA, --Beman

7 20

Re: [boost] [range] Should ranges really propagate constess to the data ?
by Brian Wood 25 Jul '11

25 Jul '11

Date: Mon, 25 Jul 2011 10:01:09 +0200 From: Thorsten Ottosen <thorsten.ottosen(a)dezide.com> To: boost(a)lists.boost.org Subject: Re: [boost] [range] Should ranges really propagate constess to the data ? Message-ID: <4E2D22C5.7050701(a)dezide.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Thorsten Ottosen: >Den 24-07-2011 16:04, Mathias Gaunard skrev: >> >> I thought that was the point of sub_range: to be the same as >> iterator_range, except the template parameter it takes is a range rather >> than an iterator, simplifying things when only ranges and not iterators >> are involved. >> > > + propagation of constness. > > Consider using sub_range<T> as the type of a member variable. > > It would be very annoying in some cases that we cannot return a view > that is const-correct and which requires us to construct a temporary > view instead of just returning a reference to the existing view. > The divergent opinions on sub_range in this thread convinced me to add marshalling support for iterator_range to the code generator I'm working on and I've now done so. Previously I had only added support for sub_range. Regards, Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

[quickbook] Revision 73337 doesn't compile with msvc-10.0
by Robert Kawulak 25 Jul '11

25 Jul '11

Here's the relevant part of the output: S:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\deque(795) : error C202 7: use of undefined type 'quickbook::id_generator::placeholder' s:\program files\boost_trunk\tools\quickbook\src\id_generator.hpp(36) : see declaration of 'quickbook::id_generator::placeholder' s:\program files\boost_trunk\tools\quickbook\src\id_generator.hpp(40) : see reference to class template instantiation 'std::deque<_Ty>' being compiled with [ _Ty=quickbook::id_generator::placeholder ] Best regards, Robert

1 0

[quickbook] Template issues
by Robert Kawulak 25 Jul '11

25 Jul '11

Hi, I have some problems using QuickBook templates. This code: [article test [quickbook 1.5]] [template link_example[name] [@[name] [name]] ] [link_example some_link] Generates: <ulink url="[name">[name</ulink> some_link] Which is obviously not what's expected. The second issue is with the code: [article test [quickbook 1.5]] [template import_example[name] [import ../temp/[name].cpp] [[name]] ] [import_example example] This generates the following error: Generating Output File: test.xml ../temp/[name: error: Could not open input file. Error: Error count: 1. Are these the fault of QuickBook or am I doing something wrong? (I'm using trunk revision 73337.) Thanks and best regards, Robert

1 0

[ggl] Congratulations
by Simonson, Lucanus J 25 Jul '11

25 Jul '11

Barend, I wanted to congratulate you on the release of your library as a part of boost. I know how hard and how long you've worked for this and your efforts are commendable. The community you have built around the library is healthy, vibrant and growing. I wish you the best continuing success. Regards, Luke

2 1

[lexical_cast] broken for std::vector<char> since last updates
by Jürgen Hunold 25 Jul '11

25 Jul '11

Hi, the last patches to lexical_cast broke some of my code which uses lexical_cast to parse values from std::vector<char> Something as simple as std::vector<char> buffer; return boost::lexical_cast<int>(&buffer[0]); fails with BOOST_ROOT/boost/lexical_cast.hpp:1091:43: error: no matching constructor for initialization of 'std::basic_ostream<char>' std::basic_ostream<CharT> stream(&stringbuffer); ^ ~~~~~~~~~~~~~ this is the start of the clang diagnostic. Both gcc (Ubuntu 4.6.0-3~ppa1) 4.6.1 20110409 (prerelease) and clang version 3.0 (trunk 135897) output contained in attached testcase. Btw. are there any lexical tests in Boost? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

3 4

[locale] UTF Iteration and conversion
by Artyom Beilis 25 Jul '11

25 Jul '11

Hello All, Following this discussion: [regex] How robust are the <boost/regex/pending/unicode_iterator.hpp> adapters? http://thread.gmane.org/gmane.comp.lib.boost.devel/221643 Boost.Locale will ship **header-only** utf_to_utf conversion functions and provide operations that would allow implementing iteration over UTF-XX sequences. This was one of the review requests and it will be integrated in few days into trunk. Functions: namespace boost { namespace locale { namespace conv { template<typename CharOut,typename CharIn> std::basic_string<CharOut> conv::utf_to_utf(CharIn const *begin,CharIn const *end,method_type how=skip); template<typename CharOut,typename CharIn> std::basic_string<CharOut> conv::utf_to_utf(CharIn const *str,method_type how=skip); template<typename CharOut,typename CharIn> std::basic_string<CharOut> conv::utf_to_utf(std::basic_string<CharIn> const &str,method_type how=skip); }}} // boost::locale::conv Also it would provide basic utf encoding/decoding operations that would allow to create iterators over generic streams namespace boost { namespace locale { namespace utf { typedef uint32_t code_point; static const code_point illegal = ... ; static const code_point incomplete = ... ; // Get one code point from UTF stream template<typename InputIterator> code_point decode(InputIterator &p,InputIterator e); // Write one code point to UTF stream template<typename OutputIterator> Iterator encode(code_point u,OutputIterator e); // Get size of code point in basic unit template<typename CharType> int units_in_code_point(code_point u); }}} // boost::locale::utf It should be ready very soon... Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

1 0

[asio] gcc visibility support patch
by Jürgen Hunold 25 Jul '11

25 Jul '11

Hi, I've found some missing patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for Boost.Asio For more information, please see http://gcc.gnu.org/wiki/Visibility Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

3 5

[lockfree review] rfc: naming and interface
by Tim Blechmann 25 Jul '11

25 Jul '11

hi all, i am starting a new thread, because i want to start a new discussion on one aspect of boost.lockfree: the naming of the data structure and the interface naming: the current names of the data structures are fifo, stack and ringbuffer. during the pre-review some people suggested to use different names, lifo instead of stack or queue instead of fifo. in general i think it is a good idea to use a consistent naming (probably fifo should be renamed to queue), but how does the ringbuffer come in? it is a queue as well, but with different characteristics (spsc and wait-free). data structure configuration: stack and fifo currently use 3 template arguments: T for the managed type, freelist_t as a tag to select the underlying freelist and Alloc as the allocator which is used for the internal nodes: template<typename T, typename freelist_t = caching_freelist_t, typename Alloc = std::allocator<T> > class fifo/stack; however i have been thinking about replacing it with a boost.parameter interface, something like: template<typename T, ... Options> class fifo/stack; with the options: boost::lockfree::freelist_can_allocate<true/false> to disable memory allocation during enqueue/push boost::lockfree::allocator<> to specify the allocator ringbuffer size: the ringbuffer currently has the signature: template<typename T, size_t max_size> class ringbuffer; if max_size is 0, the size of the ringbuffer can be configured at run-time with a constructor. this is not really the cleanest interface, but i would like to provide an interface, which supports both compile-time and run-time setting of the size. i would apprechiate a discussion about these points during the review. thanks, tim

7 10