- Boost - lists.preview.boost.org

Re: [boost] Silly Boost.Locale default narrow string encoding in Windows
by Daniel James 29 Oct '11

29 Oct '11

On Saturday, 29 October 2011, Peter Dimov wrote: > > > The "dir" command has no problem displaying arbitrary file names directly > to the console (presumably via WriteConsoleW), but once it has to write to > a file, it needs to convert to narrow and no code page other than 65001 can > express the above file name. > This is not that relevant to the wider issue, but wide streams will work for console output if you first do this: if (_isatty(_fileno(stdout))) _setmode(_fileno(stdout), _O_U16TEXT); if (_isatty(_fileno(stderr))) _setmode(_fileno(stderr), _O_U16TEXT); i.e. set the output mode to UTF-16 when writing to the console. This only works for recent versions of Visual C++. Obviously doesn't fix piped output.

3 2

[1.48.0.beta 1][interprocess] detail namespace
by Jan Boehme 28 Oct '11

28 Oct '11

Hi, is the change of the name of the namespace 'detail' to 'ipcdetail' intended to be in the release? Isn't it over-qualified as it is located in the the namespace 'boost::interproces' anyway?. Btw it breaks our code and should mentioned in the release notes of the library. Thanks for reading, Jan.

4 6

[filesystem and beyond] Narrow strings be UTF-8
by Yakov Galka 28 Oct '11

28 Oct '11

On Wed, Oct 26, 2011 at 22:13, Beman Dawes <bdawes(a)acm.org> wrote: > (2) V3 may work OK with the Microsoft 65001 UTF-8 codepage, although > I've never used it myself and you would have to pass in a UTF-8 > encoded narrow character name. > If it had been possible, it would simplify everything. Unfortunately, you cannot set UTF-8 codepage for windows API functions (you can for the console though). Microsoft isn't interested in making portability easier, so I don't see them adding the support in the nearest future. But they could. UTF-8 should be considered as the only default narrow encoding on windows, because all other ANSI encodings are not unicode-aware. On Wed, Oct 26, 2011 at 22:47, Beman Dawes <bdawes(a)acm.org> wrote: > On Wed, Oct 26, 2011 at 6:24 AM, Yakov Galka <ybungalobill(a)gmail.com> > wrote: > > [...] > > Even if you fix the Unicode problems, > > What Unicode problems are you running into? Although there are some > locale related tickets outstanding, I'm not aware of any Unicode > issues. > 1) The one that was brought up in the previous thread. 2) The complexity of writing portable unicode-aware code: currently you're forcing me to a) use wstring on windows, or if I prefer to use my favorite portable UTF-8 encoded strings b) write all the boilerplate code that passes codecvt everywhere as a parameter (see below why ¬imbue()). In both cases you're shifting the complexity to the higher-level code. It's not a kind thing for you as a low-level library developer to do, The library is expected to ℍ𝕚𝕕𝕖 the platform differences by providing a uniform interface. ⇒ Myth: Using the native encoding on each platform results in portable code. ‽ In some definition of 'portable' definitely yes. But not when things are shared among different platforms. It starts with files transferred between different systems and ends with the source code itself (there is a different between "" and L""). Uniformity == simplicity. Consider a simple case of loading a path from some project file and loading the referenced file: The project file is encoded in UTF-8 making it portable among all systems with CHAR_BIT == 8. // Option a) #include "codecvt_implementation.h" std::basic_ifstream<native_char> fin("project.file"); std::basic_string<native_char> str; fin.imbue(locale(fin.getloc(), new utf8_to_native_codecvt())); getline(fin, str); fs::ifstream fin2(project_path/str); // Option b) #include "codecvt_implementation.h" std::ifstream fin("project.file"); std::string str; getline(fin, str); fs::ifstream fin2(fs::path(project_path).append(str, utf8_to_native_codecvt())); // c) How it could be done std::ifstream fin("project.file"); std::string str; getline(fin, str); fs::ifstream fin2(project_path/str); ⇒ Use boost⸬filesystem⸬imbue to convert b to c. ‽ Who is responsible for calling imbue()? I'm writing library code. I'm not allowed to change the global-state. ⇒ This code will break: int main(int argc, char* argv[]) { fs::ifstream fin(argv[1]); } ‽ It works fine for ASCII characters on all sane platform. For non-ASCII, I don't care. It's already not unicode-aware if the native encoding is not UTF-8 (which can't be so on Windows). If the writer of this code really cares about internationalization, she can use boost⸬program_options (assuming it's also changed to follow the UTF-8 convention). Otherwise she's a hypocrite. ⇒ UTF-8 is slow. ‽ Compared to what? You haven't measured this. On windows: we must do complicated operations on paths before we pass them to the OS anyway (system_complete, prepend \\?\). Most of the strings contain ASCII characters so std::strings take less memory, thus decreasing cache thrashing in other parts of the program. On other OSes: the encoding is already almost always UTF-8. Experience shows that the small overhead (if it's an overhead at all) is not the bottleneck. Many cross-platform libraries already switched to UTF-8 for narrow-chars (see one of the previous discussion for a list), and I don't see a reason why boost can't be the next. -- Yakov

2 1

Making Boost.Filesystem work with GENERAL filenames with g++ in Windows (a solution)
by Alf P. Steinbach 28 Oct '11

28 Oct '11

First, apologies if I'm posting to the wrong group/list; if so then please redirect me. IMHO access to files is a crucial part of Boost.Filesystem. However, with Boost 1.47, and using g++ 4.4.1 in Windows 7, boost::filesystem::ifstream etc. fail to open or create files with non-ANSI characters. It works fine with Visual C++; it FAILS with g++ 4.4.1, which is the one bundled with the Code::Blocks IDE. The failure probably has nothing to do with the g++ version: it's due to g++ not offering the Visual C++ wchar_t oriented extensions to the standard iostreams (Boost.Filesystem uses these Visual C++ extensions). I stumbled onto this while I was writing about using Unicode in C++ programming in Windows. I wrote up a technical solution in section 5, starting on page 16, of that work-in-progress document, available on Google Docs at: https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B2oiI2re… Essentially, the fix I ended up with, full source code given in the above doc, uses Windows short file names if (1) there is no wide character support and if furthermore (2) the filename can't be perfectly translated to ANSI. The C++ implementation's support for wide chars is automatically detected using C++98-compatible code. I do not know what to do with this. But considering that Boost.Filesystem is slated for later inclusion in the C++ standard library (or at least into TR2), I think it would be nice if it is able to give access to all accessible files in Windows, also with g++, so that we don't end up with a file handling part of the standard library that can't handle files in general; hence this posting and plea for advice -- what more should I do, if anything? Cheers, - Alf

10 24

Re: [boost] [1.48.0] Beta 1 is now available from SourceForge
by Martin Elzen 28 Oct '11

28 Oct '11

Okay, I gave compiling the beta 1 another shot, as follows: ./bootstrap.sh --prefix=/home/martin/app/boost/installation --with-icu=/home/martin/app/icu/installation ./b2 -sICU_PATH=/home/martin/app/icu/installation install >out.b2.install 2>&1 & the b2 output then does start as follows: Performing configuration checks - has_icu builds : yes warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - iconv (libc) : yes - icu : yes ... but then later on there are compilation errors in Boost.Locale, such as: > In file included from libs/locale/src/icu/formatter.cpp:25:0: > libs/locale/src/icu/predefined_formatters.hpp: In member function ‘icu_48::NumberFormat* boost::locale::impl_icu::icu_formatters_cache::number_format(boost::locale::impl_icu::icu_formatters_cache::fmt_type) const’: > libs/locale/src/icu/predefined_formatters.hpp:127:61: error: ‘URBNF_SPELLOUT’ was not declared in this scope > libs/locale/src/icu/predefined_formatters.hpp:127:61: note: suggested alternative: > /home/martin/app/icu/installation/include/unicode/rbnf.h:49:5: note: ‘icu_48::URBNF_SPELLOUT’ > libs/locale/src/icu/predefined_formatters.hpp:130:61: error: ‘URBNF_ORDINAL’ was not declared in this scope > libs/locale/src/icu/predefined_formatters.hpp:130:61: note: suggested alternative: > /home/martin/app/icu/installation/include/unicode/rbnf.h:50:5: note: ‘icu_48::URBNF_ORDINAL’ > > "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_LOCALE_DYN_LINK=1 -DBOOST_LOCALE_NO_WINAPI_BACKEND=1 -DBOOST_LOCALE_WITH_ICONV=1 -DBOOST_LOCALE_WITH_ICU=1 -DBOOST_THREAD_NO_LIB=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -I"." -I"/home/martin/app/icu/installation/include" -c -o "bin.v2/libs/locale/build/gcc-4.6.1/release/threading-multi/icu/formatter.o" "libs/locale/src/icu/formatter.cpp" The above errors are probably caused because I did what ICU recommends you do (for the first time ever), which is: -# define U_USING_ICU_NAMESPACE 1 + // Set to 0 to force namespace declarations in ICU usage. +# define U_USING_ICU_NAMESPACE 0in the ICU unicode/uversion.h file The above is advised in ICU 's readme.html in the How To Build And Install ICU / Recommended Build Options section... Has that advice become incorrect in recent ICU versions, perhaps?

1 0

[1.48.0] Beta 1 is now available from SourceForge
by Beman Dawes 27 Oct '11

27 Oct '11

Boost release 1.48.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost/1.48.0.beta.1/ This release includes 3 new libraries (Container, Locale and Move), an extension to TypeTraits to support operator detection as well as updates to many existing libraries. For partial details of what's in the release, see http://beta.boost.org/users/history/version_1_48_0.html. This page is still in process of being updated, and there are some known issues with links. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

4 5

[1.48.0] Beta 1 release candidates available
by Martin Elzen 27 Oct '11

27 Oct '11

Beman Dawes <bdawes(a)acm.org> wrote: > Release candidate files for 1.48.0 beta 1 are available at > http://boost.cowic.de/rc/ > > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. On Ubuntu 11.10 amd64 with g++ (and gcc) 4.6.1, I built ICU 4.8.1 with almost all default options except for specifying a non-default installation dir. Then I created the LD_LIBRARY_PATH environment variable and set it to the lib dir of that new ICU installation *but did not* also create an ICU_PATH environment variable. Then I ran the boost bootstrap.sh script with a '--with-icu=/home/martin/app/icu/installation' parameter. The output of the b2 contained (among other things) the following bits about ICU: - has_icu builds : yes ... - icu : no - icu (lib64) : no Which led me to expect that the boost regex libs would end up referencing the Ubuntu default ICU libs (which was not what I wanted to do). But they didn't, instead they *did* correctly reference the newly built ICU libraries (or at least that's how I'm interpreting the output of ldd against libboost_regex.so ). Which is nice, but doesn't that also mean that the docs in Boost regex about the ICU_PATH environment variable might need some revision? Or did I just luck out somehow?

4 3

[interprocess] native Windows cond_var + mutex
by Dan Brown 27 Oct '11

27 Oct '11

Informed the previous patch was removed. Attaching patch without .zip.

1 0

[parameter] non-type template params
by lcaminiti 26 Oct '11

26 Oct '11

Hello all, Does Boost.Parameter support named parameters for non-type template parameters? For example, can I use Boost.Parameter on all the template parameters below including default_value? template< typename Value, Value default_value = Value() > class none { ... }; >From the docs, it seems that this is not possible but I might be missing something: http://www.boost.org/doc/libs/1_47_0/libs/parameter/doc/html/index.html#par… Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-parameter-non-type-template-params… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[atomics] Short review
by Phil Endecott 26 Oct '11

26 Oct '11

Dear All, Apologies for not having time to write a proper review for this important library. However, I have previously looked at this code in some depth, and I am using it in a number of shipping products. Based on that, I am reasonably confident that it is useful and functional. As others have said, the documentation needs some attention. In particular, I missed information about supported platforms and types. Users can reasonably ask whether a particular type is supported natively or whether a fallback is used, and what the fallback is. A link to the std::atomic spec (or a freely-downloadable draft of it) would also be useful. I believe that this is a vitally important and long-overdue library that should be accepted without delay. Regards, Phil.

1 0

Re: [boost] [interprocess] submission
by Stewart, Robert 25 Oct '11

25 Oct '11

Dan Brown wrote: > Christian Holmquist wrote: > > > > I have a question about submissions. I have an > > > enhancement, not a fix, for boost::interprocess (win32 > > > native mutex and condition variables as an alternative to > > > emulation). Ok to just submit the zip or should I open a > > > ticket first? > > > > see: > > http://www.boost.org/community/policy.html#effective > > > > i.e., include [Interprocess] in the email topic so maybe the > > maintainer will read it. > > Helpful, thank you. Another question. Not only is it helpful, it just might get you a useful answer to your query, which I'll leave to Ion. Consequently, I added it for you. > I may not be able to justify to my employer completing the work > to the satisfaction of all tests. For example, I don't have a > working win32 native implementation of sharable and sharable- > upgradable mutexes (aka read-write locks, I believe). Is it > worth submitting in such a state in hopes others might be able > to contribute, or should I hold off until I have time implement > these and get all tests working? I suspect the answer will be that offering something, even if not everything, will be helpful. Nevertheless, you need Ion to respond. _____ 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 1

[signals2] 'static initialisation fiasco' issues
by elpidio valdez 25 Oct '11

25 Oct '11

I am trying to build a modular system in which independently compilable cpp files communicate by signals, but otherwise know nothing about each other at compile time. e.g. #include "TheRangeFinderSignals.h" #include "TheProximitySensorSignals.h" class TerrainMap { ....connect to signals and send signals.... } TheSingletonTerrainMap; This all works very well except that TerrainMap needs to connect to signals from its constructor. The signals are static global objects which serve to exchange data between the independent modules. Unfortunately I have fallen foul of C++ static initialisation problems. I cannot be certain that the static signal objects will be created before the modules that use them. The C++ FAQ recommends wrapping the static variables in a function: e.g. EventSignal<void (Gray16Image)> &OnNewDepthFrameAvailable() { static EventSignal<void (Gray16Image)> *zzz = new EventSignal<void(Gray16Image)>; return *zzz; } This works but it is syntactically messy to use. All uses of OnNewDepthFrameAvailable must be replaced with OnNewDepthFrameAvailable(). i.e OnNewDepthFrameAvailable().connect(...) OnNewDepthFrameAvailable()(theNewFrame); Is there any way to avoid this ? It is not easy to hide the detail. I wanted to define a template class to encapsulate the idiom and eliminate the need for the extra parenthesis. e.g. SafeStatic< EventSignal<void (Gray16Image)> > OnNewDepthFrameAvailable; template<type T> class SafeStatic { T *obj; void operator()(theArgsToSignal) { if (!obj) obj = new T; obj(theArgsToSignal); } }; The problem is that the Signal template defines a variable arity and signature operator(). I have no idea how to provide the same signature on the function call operator of SafeStatic Any other way around this problem ?

2 1

submission
by Dan Brown 25 Oct '11

25 Oct '11

Hi, I have a question about submissions. I have an enhancement, not a fix, for boost::interprocess (win32 native mutex and condition variables as an alternative to emulation). Ok to just submit the zip or should I open a ticket first? Thanks. Dan Brown

3 3

[bind] placeholders in namespace ::
by lcaminiti 25 Oct '11

25 Oct '11

Hello all, Do you know in which namespace Boost.Bind placeholders are actually defined? #include <boost/bind.hpp> #include <iostream> void f ( int a, int b ) { std::cout << a << " " <From the example above, the docs, and the source code, I am pretty sure Boost.Bind placeholders are defined in the unnamed namespace :: ... why? Isn't it a bad practice for a library to pollute the unnamed namespace? Thanks for the clarification. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-bind-placeholders-in-namespace-tp3… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

Status of boost::make_shared_array
by Olaf van der Spek 24 Oct '11

24 Oct '11

Hi, What's the status of boost::make_shared_array? I've seen some discussion from 2009, but it's almost 2012 now and it doesn't appear to be available. Greetings, Olaf

2 11

[atomic] [review] Atomic Review
by Stewart, Robert 24 Oct '11

24 Oct '11

Boost.Atomic should be included in Boost. - What is your evaluation of the potential usefulness of the library? Providing C++03 support for the new atomics functionality will prove immensely useful. It would be even more useful if it could be provided as a portability layer for environments with both C++03 and C++11 compilers. That is, if one could use boost::atomic to get Helge's implementation on C++03 compilers and std::atomic on conforming C++11 compilers, without needing to change code, this library would be ideal. That might require changes to the current implementation, but seems unlikely to break code using the current release. - What is your evaluation of the design? The design is largely fixed since it is standardized. I was put off initially that the names appear in namespace boost rather than, say, boost::atomics, but since this is intended to provide *the* Boost implementation of C++11 functionality, I don't expect there to be any competitors. That said, s/boost::atomic/std::atomic/ is no simpler a change than s/boost::atomics::atomic/std::atomic/ to make in the future. - What is your evaluation of the implementation? I'll leave most comments on this to those with more experience. However, I'm positive that any issues will be addressed quickly as more eyes are drawn to the implementation, so even if there are present issues, they should not preclude acceptance. I think the fallbacks, in lines 22-77 of atomic.hpp, would be better in a separate file such as boost/atomic/fallbacks.hpp or even just at the end of boost/atomic/platform.hpp. It would remove clutter from atomic.hpp. I would expect a different conditional compilation structure in platform.hpp would be easier to follow and maintain: // Compiling with GCC #if defined __GNUC__ # if defined __i386__ || defined __x86_64 # include <boost/atomic/detail/gcc-x86.hpp> // etc. # else # include <boost/atomic/detail/gcc-cas.hpp> # endif // How about ARM on Linux? #elif defined __linux__ && defined __arm__ # include <boost/atomic/detail/linux-arm.hpp> // Use Windows Interlocked* APIs? #elif defined BOOST_USE_WINDOWS_H || defined _WIN32_CE... # include <boost/atomic/detail/interlocked.hpp> #endif Shouldn't BOOST_ATOMIC_ADDRESS_LOCK_FREE be named "BOOST_ATOMIC_POINTER_LOCK_FREE"? The directory layout is a little odd. I'd have expected boost/atomic/platform.hpp to be boost/atomic/detail/platform.hpp. That, of course, leaves nothing in boost/atomic. However, if namespace atomics is added, then boost/atomic.hpp, if retained, can just include boost/atomics/atomic.hpp, the latter containing the content presently in boost/atomic.hpp. - What is your evaluation of the documentation? As usual, I have numerous detailed comments which I've addressed at the end. The documentation should include some links to suitable background material for those not "already...familiar with concurrency in general, as well as elementary concepts such as 'mutual exclusion'". Information on the section(s) of the C++11 standard that are and aren't part of the library would be beneficial. Generally, the explanations assume too much familiarity with the material with no pointers to resources to bridge the gap. I've given one, specific suggestion in my detailed comments below on what I'd like to see in the Usage examples section. It may be that more thorough descriptions are the province of books and that it is fair for Boost.Atomic to assume a good deal -- as does the C++11 standard. Nevertheless, I'd prefer to see more in the documentation. I was hoping that Boost.Atomic would provide a bridge to C++11 by engaging platform-supplied atomic support when available so that I wouldn't have to do that work. However, since that is not available, the documentation should make that clear. - Did you try to use the library? With what compiler? On which platform? Did you have any problems? I wish I could say yes, but the team I was hoping to get to use the library opted for a safer, more expedient solution to their present issues than adopting a new library. I haven't had an independent opportunity. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a lot of time reviewing the documentation and a little looking over the code. - Are you knowledgeable about the problem domain? Sadly, I'm not nearly as knowledgeable as I should be. I'm working on that and Helge has actually been very helpful in answering specific issues I've had with other's code, so I'm comfortable trusting his knowledge. ___________________________________ Detailed Documentation Comments _________________________ Introduction _______________ Presenting Boost.Atomic s/these data types/them/ s/"emulating"/emulating/ _______________ Purpose The following change avoids the non-word "sequentialized" and should prove clearer: s/each operation behaves as if it were strictly sequentialized/the operation is executed as if no other thread were attempting to do the same/ The bulleted list would read better as follows. I eliminated, "custom coordination protocols", because that confuses rather than helps. "Atomic variables are useful as: - a means to coordinate multiple threads - faster alternatives to lock-based access to simple variables" _________________________ Thread coordination using Boost.Atomic s/accesses of threads to shared variables/threads accessing shared variables/ s/the cache hierarchies /cache hierarchies/ s/above one/above/ Presumably, a "fully formalized definition" of "happens-before" is in the C++11 standard, so the reader should be referred to the appropriate section thereof. The structure of this page seems broken. I'd expect the following: Coordination using happens-before Using mutual exclusion Using release and acquire Using fences Coordination of dependent data access Coordination using sequential consistency _______________ Enforcing happens-before through mutual exclusion s/If this is be thread1/If thread1 succeeds first/ s/Obviously cannot state/There is no way to determine/ s/either one/either option/ _______________ happens-before through release and acquire s/semantic/semantics/ s/the value this value/the value/ s/the same atomic/the *same* atomic/ s/avenues for/orders of/ s/hold: thread2/hold because thread2/ The presentation of the possible outcomes is not as clear as it could be. I suggest something like the following: "There are two possible orders in which the atomic operations can occur: "1. thread1 stores a new value in a before thread2 loads a's value. Since a has been incremented to 1, thread2 will execute B. All of the listed criteria are satisfied, so 'A _happens-before_ B' holds. "2. thread2 loads a's value before thread1 stores a new value. Given that a is initially zero, thread2 will execute C. Since thread1 did not first store a new value in a with release semantics, the criteria listed above are not satisfied, so 'A _happens-before_ C' does *not* hold." _______________ Fences The phrasing in the first paragraph is a bit less clear than it could be. Try the following: "...in conjunction with preceding (for acquire or consume), succeeding (for release), or both (for seq_cst) atomic operations." The use of memory_order_relaxed, in the example, should be called out. s/in the case C is executed/when C is executed/ _______________ happens-before through release and consume s/uses release and consume/uses release and consume semantics/ s/coordination: If/coordination. If/ s/semantic/semantics/ s/the value this value/the value/ s/the same atomic/the *same* atomic/ s/value of the atomic variable/value of that atomic variable/ s/avenues for/orders of/ s/hold: thread2/hold because thread2/ s/accesses (presumable writes) to/accesses of (presumably writes to)/ s/accesses (presumably reads) to/accesses of (presumably reads from)/ s/by thread2: Lacking/by thread2. Lacking/ s/Note that in this example, the fact that/Note that/ The following would be clearer for the explanation: "There are two possible orders in which the atomic operations can occur: "1. thread1 stores a new value in a before thread2 loads a's value. In this case, since a has been set to 1, thread2 will use 1 as the value of index to execute B. All of the listed criteria are satisfied, so 'A _happens-before_ B' holds. "2. thread2 loads a's value before thread1 stores a new value. In this case, thread2 will execute B with index set to 0, which is not the value (yet to be) set by thread1. Since thread1 did not first store a new value in a with release semantics, the criteria listed above are not satisfied, so 'A _happens-before_ B' does *not* hold." Your statement that the second example in this section is erroneous lacks an explanation. Presumably, the problem stems from the conditional branch, but an explanation is needed. _______________ Sequential consistency s/coordination: If/coordination. If/ This section deserves example code and an explanation: thread1: ...; /* A */ atomic_thread_fence(memory_order_seq_cst); ...; /* B */ thread2: ...; /* C */ atomic_thread_fence(memory_order_seq_cst); ...; /* D */ "There are two possible orders of execution of that code: "1. thread1 assigns to a before thread2 assigns to b. A _happens-before_ D. Whether A _happens-before_ C is not known. "2. thread2 assigns to b before thread1 assigns to a. C _happens-before_ B. Whether C _happens-before_ A is not known. "The fences could have been operations on the same or different atomic variables. All that matters is that memory_order_seq_cst be the memory order in each case." _________________________ Programming interfaces This section would be better formatted as in, for example, http://www.boost.org/doc/libs/1_47_0/libs/regex/doc/html/boost_regex/ref.ht…. _______________ Memory order The table formatting is confusing, at least without any borders between the cells. Add internal borders or align the constants to the top of their cell. Using a table may be faulty anyway. It would probably be simpler to define each in a separate paragraph. s/informally speaking/informally/ memory_order_relaxed: The description is hard to read. This should be better: "Informally, operations following the atomic operation may be ordered before it and operations preceding it may be ordered after it. This constraint is only suitable in two cases: when further operations do not depend upon the outcome of the atomic operation or ordering is enforced separately by atomic_thread_fence operations." (Notice that the final period is missing in your version.) memory_order_release: Rephrasing would add a bit of clarity: "Informally, all memory operations preceding the atomic operation may be reordered after, but not before, it." memory_order_acquire: s/succeeding/following/ (for consistency). Rephrasing would be helpful: "Informally, all memory operations following the atomic operation may be reordered before, but not after, it." memory_order_consume: s/restrictive/limited/. Rephrasing: "Similar to memory_order_acquire, except that only memory operations following the atomic operation that are _computationally-dependent_ (this should link to a definition!) on the value retrieved from the atomic variable, are order restricted." memory_order_acq_rel: s/operation/operations./ memory_order_seq_cst: s/additional enforces/additionally enforces a/, s/such qualified/so qualified/ s/section happens-before for explanation/happens-before for explanations/ _______________ Atomic objects s/template class/class template/ _____ boost::atomic<T> template class s/objects supports/objects support/ s/new value to atomic variable/new value/ The descriptions are weak, since they don't refer to the order argument(s). Describing the three- versus four-argument compare_exchange function differences in a subsequent paragraph is less helpful. A footnote reference, with a link, to that explanation would be fine, however. Also note that the success/failure ordering behavior deserves more explanation. Why is it useful or important? Who should care? Even if you think the assignment and conversion operators should be avoided, they should be documented. What's more, I disagree with your rationale. Those operators imply memory_order_seq_cst. If that's what a user wants -- and that's usually the case -- why not use the syntactic sugar? You can state your case as, "When specifying memory ordering, other than memory_order_seq_cst, for some atomic operations, specify them for all, rather than using the assignment and conversion operators, to make all of the operations clear." No mention of the default for the order argument. _____ boost::atomic<integral> template class The descriptions are inconsistent with those of the previous section. For example, a consistent description for fetch_add() would be, "Add v to current value, returning current value." Bitwise operations are typically capitalized. Thus, "bitwise AND". s/always has memory_order_seq_cst as default parameter/is defaulted to memory_order_seq_cst in each case/ Same argument regarding the operators as for the previous section. _____ boost::atomic<pointer> template class s/all atomic object/boost::atomic<integral> objects/ The descriptions are inconsistent with those of the initial section. s/always has memory_order_seq_cst as default parameter/is defaulted to memory_order_seq_cst in each case/ Same argument regarding the operators as for the previous section. _______________ Feature testing macros s/detection whether/detection of whether/ s/"true"/lock-free/ s/operations, or whether/operations or whether/ s/"lock"/lock/ s/signed\/unsigned/unsigned/ (except for BOOST_ATOMIC_CHAR_LOCK_FREE) _________________________ Usage examples There should be an introductory paragraph for this section. Try the following: "This section shows non-trivial examples of using Boost.Atomic to implement common mechanisms using atomics. These might be considered advanced tutorials or, perhaps, reference implementations." _______________ Reference counting You should reference some external source to discuss the idea behind and uses of reference counting, such as http://en.wikipedia.org/wiki/Reference_counting. s/reference counter/reference count/ You should clarify what you mean by, "passing an existing reference from one thread to another must already provide any required synchronization." I presume you mean that the old thread must not release its reference count on the object, so it won't be released, before the new thread can increment the reference count. s/must obviously happened/obviously must have happened/ You don't explain why the acquire fence is needed. I started to write why the release semantics were needed for the decrement, but found I couldn't figure out how to say it, which means I'm not entirely sure I understand it either. Every time I think I get the details of these things, I find that I'm somehow not quite clear. Thus, your explanation needs to be clearer. However, after thinking things over at some length, I think I have it and will give the explanation a try anyway: "If a thread is trying to increment the reference count, there's no contention. The increment is atomic and doesn't need to impose ordering on intrusive_ptr_release(), because there must be a valid, existing reference, thereby ensuring the reference count will be at least zero, regardless of the order between intrusive_ptr_release() and intrusive_ptr_add_ref() calls. That's why intrusive_ptr_add_ref() uses memory_order_relaxed. "If a thread is trying to decrement the reference count, it might be decrementing the value to something greater than zero. In that case, all that's important is that the decrement be atomic to prevent races between threads. However, if the reference count is decremented to zero, then no other thread can have a valid, outstanding reference. That implies that there can be no race in comparing the value returned by fetch_sub() (which returns the original value) with 1. If fetch_sub() returns 1 (meaning the reference count is now zero), then, and only then, must x be deleted. Thus, a memory_order_acquire fence is used to ensure that the delete expression is not reordered ahead of the fetch_sub() call." That sort of analysis, in which each of the various execution orders and use cases are examined and discussed, is necessary to grasp this stuff. Perhaps you'd rather that be left to book authors, but I don't think it's too much to ask in this context. _______________ Spinlock You should reference external information on spinlocks to guide readers to their appropriate uses, particularly in light of your warning to understand the consequences of their use. s/"happens before"/_happens-before_/ This example deserves a good explanation of the busy-wait loop and why acquire and release semantics are used in each case. Last paragraph: punctuation and wording problems. I suggest this instead: "This 'optimization' is actually useless and may be harmful. Since threads can be spinning busily on a locked spinlock, it doesn't matter whether CPU cycles are wasted with 'exchange' and 'acquire' operations or with just 'exchange' operations. Furthermore, a tight 'exchange' loop, without any memory-synchronizing instruction introduced by an 'acquire' operation will, on some systems, monopolize the memory subsystem which degrades the performance of other activities." _______________ Singleton with double-checked locking pattern This section should refer to external references on the Singleton Pattern and the Double-checked Locking Pattern, particularly with details on the problems with the DCLP. 1st para, 2nd sentence: change to read, "instance must ensure that creating the instance in one thread _happens-before_ any dereferences of the pointer in other threads." That avoids referring to "happens after" which you've not discussed in the documentation. The explanation of the implementation should be more detailed. _______________ Wait-free ring buffer s/one single/one/ or s/one single/a single/ s/without any locks/without locks/ s/"wait-free" which/"wait-free", which/ The code requires a great deal more explanation. Each ordering constraint should be discussed. Places where others have made mistakes might be worth mentioning as "anti-examples". Avoid the use of "happens after" since you don't discuss it anywhere. _______________ Wait-free ring buffer s/"happens before"/_happens-before_/ The code requires a great deal more explanation. Each ordering constraint should be discussed. Places where others have made mistakes might be worth mentioning as "anti-examples". _________________________ Limitations s/Advise/Advice/ or s/Advise/Recommendation/ In the second bullet, you assume that the reader understands "computation-dependency" and "control-dependency" but I doubt that fits within the expected knowledge claimed in the Introduction. _________________________ Porting _______________ Unit tests "For example" and, consequently (to my mind, anyway) "e.g." should be set off by a comma. (This probably applies elsewhere.) s/returing/returning/ s/behave atomic as appropriate/behave atomically as expected/ _____ 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.

1 0

[1.48] Release notes
by Daniel James 24 Oct '11

24 Oct '11

Hi, Sorry this is a bit late, I would normally have mostly sorted out the release notes by now. You can add your changes to the release notes by editting the file in the beta repository at: http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost_… I've added a few libraries already, but feel free to change them if I've got them wrong. Most of the links don't work because the beta documentation will only be uploaded after the beta release. If you want to update the site (if you don't, I'll do it so this is optional), you need to check out the whole site and a quickbook executable in your path. Then run the script at 'site-tools/update.py' using python 2.5 to 2.7. Check in the changes to the site (including rss feeds and changes to 'site-tools/state/feed-pages.txt'). If anything goes wrong, just check in your changes to the quickbook file and let me know - the site update script has only been used by me, so I'm not sure how well it'll work for others. If it works well, the idea is to put the beta notes on the live site for future release - I'll make their status a bit clearer before doing that. Alternatively, you can just email me your changes and I'll make them. thanks, Daniel

5 6

[math] potentian bug: iround throws, given double( numeric_limits<int>::min() )
by Krzysztof Czainski 24 Oct '11

24 Oct '11

Hello, The docs of the Rounding Functions say: If the argument v is either non-finite or else outside the range of the result type, then returns the result of rounding_error: by default this throws an instance of boost::math::rounding_error. So the example shown below seems to show a bug, since std::numeric_limits<int>::min() is *not* outside the range of int. Or did I miss something? <code> #include <boost/math/special_functions/round.hpp> #include <cassert> #include <limits> int main() { int const i = std::numeric_limits<int>::min(); double const x = i; assert( i == boost::math::iround(x) ); } </code> Regards Kris

3 16

[gil][io_new] Image Reading and Writing Iterator
by Christian Henning 24 Oct '11

24 Oct '11

Hi there, one of the requirements for the acceptance of io_new as the new io extension for gil is the ability to read and write images in more then one step. For that the current state of an operation has to be cached. I have created some meta functions that give access to io_new's reader and writer classes. Right now, it still is very preliminary. I would like to ask the community how I could create an read_iterator and write_iterator classes which users could use to iterate over very large images. I know there are some specific iterator libs in boost but I'm just clueless in how to use let alone be able to come up with an implementation that will be released by boost. Any help would be very welcome! Thanks, Christian

3 3

[1.48.0] Schedule heads up
by Beman Dawes 24 Oct '11

24 Oct '11

branches/release for 1.48.0 is long since closed for new libraries. October 10: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. October 17: branches/release closed for all library changes except when specific permission given by release manager(s). October 24: Beta target date. Further betas and/or release candidates as feedback dictates. November 7: Release target date View Boost calendar: http://tinyurl.com/4xacpyj --Beman

11 45

[Review] Boost.Atomic review starts today, October 17th 2011
by Tim Blechmann 24 Oct '11

24 Oct '11

Hi all, The review of Helge Bahmann's Boost.Atomic library starts today, October 17th 2011. It will end on October 26th. I encourage everyone to participate the the discussion on the Boost mailing list about this very important library. In addition the code can be reviewed line-by-line in code collaborator (http://demo.smartbear.com/boost/) About Boost.Atomic: Boost.Atomic is a library that provides atomic data types and operations on these data types, as well as memory ordering constraints required for coordinating multiple threads through atomic variables. It implements the interface as defined by the C++11 standard, but makes this feature available for platforms lacking system/compiler support for this particular C++11 feature. Tarball: http://www.chaoticmind.net/~hcb/projects/boost.atomic/boost.atomic.tar.gz Documentation: http://www.chaoticmind.net/~hcb/projects/boost.atomic/doc/index.html 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? On which platform? 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? Cheers, Tim Review Manager

6 11

Re: [boost] [property_tree] include directive for non-info files
by Ivan Le Lann 24 Oct '11

24 Oct '11

----- "Sebastian Redl" <sebastian.redl(a)getdesigned.at> a écrit : > On 29.09.2011 16:18, Ivan Le Lann wrote: > > Hi, > > > > In Boost.PropertyTree, INFO format has the nice #include directive. > > But it seems you cannot include other formats. > > Typically such INFO file, > > > > key > > { > > #include_xml "my.xml" > > } > > > > with "my.xml" :<root><child>kid</child></root> > > > > could give : get<std::string> ("key.root.child") == "kid" > > > > A very quick look at info parser makes me think that > > it would be easy to implement. Any comment ? > > > This is a strange request. What is your use case? > Thanks for your answer and sorry for the delay. Some part of my configuration are XML files given by third parties and, being particularly lazy, I did not want to write the few lines needed to handle the indirection. :-) > I'm rather disinclined to implement it, since it would create > cross-dependencies between the various parsers. > Yeah, I kind of exspected this answer. It probably makes sense. Regards, Ivan

1 0

[Review] Boost.Atomic review period extended
by Tim Blechmann 24 Oct '11

24 Oct '11

Hi all, Since there has been only rather limited discussion about the Boost.Atomic library and only one full review, the review period will be extended until next Sunday, October 30th. I encourage everyone with an interest in this library to participate in the remaining days of the review. If someone wants to do a review, but won't find the time during the review period, please let me know how much time you need. Cheers, Tim Review Manager

1 0

trouble with find() in property_tree
by Bernd Prager 23 Oct '11

23 Oct '11

Hi, I am experiencing trouble with the find() function in boost::property_tree. It doesn't seem to catch nested entries. Statement (1) below finds the child tree, but statement (2) prints unexpectedly "false". That was not what I was expecting. How do I find nested children? Thanks for any help. -- Bernd #include <iostream> #include <boost/property_tree/ptree.hpp> namespace pt = boost::property_tree; int main(void) { pt::ptree props; pt::ptree const empty; props.add("pi", 3.14159); props.put("name.first", "bernd"); std::cout << "find(none): " << (props.find("none") == props.not_found() ? "false" : "true") << std::endl; std::cout << "find(pi): " << (props.find("pi") == props.not_found() ? "false" : "true") << std::endl; std::cout << "find(name): " << (props.find("name") == props.not_found() ? "false" : "true") << std::endl; // (1) std::cout << "find(name.first): " << (props.find("name.first") == props.not_found() ? "false" : "true") << std::endl; // (2) return EXIT_SUCCESS; }

2 1

odeint feedback request
by Karsten Ahnert 23 Oct '11

23 Oct '11

Dear community, odeint is a library for solving ordinary differential equations and has been discussed several times on this list. After successfully fulfilling the GSOC 2011 we continued working on odeint and we published two papers which are available at the arxiv: http://arxiv.org/abs/1110.3397 http://arxiv.org/abs/1110.3233 We would like to request feedback and/or comments on the implementation and the current status of odeint. The library and the documentation are available at the github: https://github.com/headmyshoulder/odeint-v2 http://headmyshoulder.github.com/odeint-v2/doc/index.html Thank you, Mario and Karsten

1 0

[atomic] Initial comments
by Grund, Holger 23 Oct '11

23 Oct '11

Hi everyone, It's been awfully quiet on the list regarding the atomic review. The atomic operations library is an invaluable tool for higher level concurrent data structures and algorithms. While toolchain vendors have already or starting to support <atomic>, many people are stuck on compiler where there is currently no support at all. Building these libraries yourself is tedious and prone to error and errors that are hard to spot. I am in this situation and therefore very much appreciate Helge's effort and think the lack of review comments so far should not be taken as a lack of interest. Now, I haven't had the time to look on things in any detail yet. I ignored the docs (~~) and only locked at the atomic header and some of x86 implementation so far. I haven't tried to build anything, but I intend to do a proper review though it's unlikely I'll manage to get to it on the official time line. I would have put some of the comments of the review tool site, but I can't login right now: - The fallback atomic_thread|signal_fence in boost/atomic.hpp seem to have external linkage, but no inline. Doesn't that give a ODR violation when included from more than on TU? - The copy-assignment operators seem to always return atomic&. IIRC, the earlier working drafts said return value_type. Has this changed? - The primary base_atomic is not aligned at all, AFAICT. I take it because you explicit need to extract bits anyhow and that means a memcpy. Does this have a performance impact? - Inline asm is the preferred way to build instructions. Did you consider intrinsics where available (e.g. ICC and GCC4+)? - atomic_flag is not statically initialized: I guess, there is some tradeoff with uniform-initialization syntax and member functions on most (all?) current production compilers. However, it seems to me that static initialization guarantees are atomic_flag's primary if not sole raison d'etre. Did you consider to make it a statically initializable type? - What's the point of the fences around cmpxchg in x86? - I'm not a GNU inline assembly expert and it's probably fairly unlikely to really affect codegen, but shouldn't clobbered flags be mentioned? Also the EBX handling for 32-bit Linux code may deserve some additional comment. I take it you can't mention ebx in the clobber list because the register allocator would complain for -fPIC, right? Does the impact unwinding? - I seem some of the *LOCK_FREE macros are defined involving sizeof. I've always assumed these macros (or the corresponding standard ones) would be suitable for use in #if processing. Wouldn't that be one of the main use cases? Thanks! -hg Holger Grund, Vice President Morgan Stanley | Cross-Technology Services 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.

2 1

[boost threads] threadid copy constructor
by Jason Newton 21 Oct '11

21 Oct '11

The following patch adds a copy constructor to threadid. There seems to be no reason why they shouldn't be copyable. Comments? -Jason

2 2

difference_type size()?
by Olaf van der Spek 21 Oct '11

21 Oct '11

Hi, iterator_range returns a signed size. Is this correct? IMO it should return size_t. boost\range\iterator_range_core.hpp: difference_type size() const { return m_End - m_Begin; } Olaf

6 28

Using trac for boost-sandbox?
by Paul A. Bristow 21 Oct '11

21 Oct '11

Is it permitted to use the Boost Trac system for libraries under development at boost-sandbox? This would be very helpful. (especially if a history could refer to the Trac in Quickbook, as done in Boost.Pool new docs at pool.qbk [section:tickets Appendix E: Tickets] Report and view bugs and features by adding a ticket at [@https://svn.boost.org/trac/boost Boost.Trac]. Existing open tickets for this library alone can be viewed [@https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=reopened&component=pool&c ol=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority here]. Existing tickets for this library - including closed ones - can be viewed [@https://svn.boost.org/trac/boost/query?status=assigned&status=closed&status=new&status=reopened&co mponent=pool&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority here]. [endsect] [/section:tickets Appendix E: Tickets] This removes a boring burden on authors on updating the history of features and bugs. (There isn't an option to use sandbox in the drop-downs - only trunk, release, 1.n ...). Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 0

Fwd: Re: [Boost-announce] [Review] Boost.Atomic review starts today, October 17th 2011
by Tim Blechmann 21 Oct '11

21 Oct '11

---------- Forwarded Message ---------- Subject: Re: [Boost-announce] [boost] [Review] Boost.Atomic review starts today, October 17th 2011 Date: Friday 21 October 2011, 10:20:42 From: Darren Cook <snip> CC: Tim Blechmann <tim(a)klingt.org> > Boost.Atomic ... implements the > interface as defined by the C++11 standard, but makes this feature available > for platforms lacking system/compiler support for this particular C++11 > feature. Hello, (I wanted to cc Helge Bahmann but couldn't find an email address) As the library is a stand-in until compilers catch-up, I think it would be useful to have a page in the documentation that shows the minimum compiler versions where it is no longer needed, for at least the major compilers. (I skimmed the docs but couldn't see this covered.) Darren P.S. No need to reply, and sorry I won't be able to take part in the review. (I'm also not on boost-devel list currently.)

1 0

Throws exception while deserializing large no object
by Bikas Tanti 21 Oct '11

21 Oct '11

I'm using vs 2010 and getting memory leaks when deserializing objects with binary archive . #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> class ElementResultData { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar,const unsigned int version) { ar & m_pass; ar & m_fail; ar & m_units; ar & m_result_no; ar & m_outof_tolerance; ar & m_iPartNo; ar & m_iActualValue; ar & m_iMeasurement1; ar & m_iMeasurement2; ar & m_iMeasurement3; } public: std::string m_pass; std::string m_fail; std::string m_units; std::string m_result_no; std::string m_outof_tolerance; unsigned long m_iPartNo; double m_iActualValue; double m_iMeasurement1; double m_iMeasurement2; double m_iMeasurement3; public: ElementResultData(){}; ElementResultData(std::string ps,std::string fl,std::string unit,std::string rno,std::string tol, int n,double av,double m1,double m2, double m3) : m_pass(ps),m_fail(fl),m_units(unit),m_result_no(rno),m_outof_tolerance(tol),m_iPartNo(n), m_iActualValue(av),m_iMeasurement1(m1),m_iMeasurement2(m2),m_iMeasurement3(m3) {} }; //DataResultDlg.h class CDataResultDlg { // Construction public: std::map<int, ElementResultData> m_mElemResDatafirst; std::map<int, ElementResultData> m_mElemResDataSecond; std::map<int, ElementResultData> m_mElemResultData; }; //DataResultDlg.cpp #define NUM_ELEMENTS 50000 // works fine when NUM_ELEMENTS is 1 class CDataResultDlg { for(unsigned long i=0;i<NUM_ELEMENTS;i=i+2) { m_mElemResDatafirst.insert(std::make_pair(i, ElementResultData("Pass","No", "MM","PartA","O",i,1.6020,1.0400,1.320,1.1010))); m_mElemResDatafirst.insert(std::make_pair(i+1,ElementResultData("Fail","Yes","MM","PartB","O",i+1,1.085,1.0004,2.320,1.1010))); } //Saving Data std::ofstream ofs("ResultData"); // save data to archive { boost::archive::binary_oarchive oafirst(ofs,std::ios::app); //write instance to archive int no_of_map = 2; oafirst<< no_of_map; oafirst << m_mElemResDatafirst; oafirst << m_mElemResDataSecond; } //Loading Data std::ifstream ifs("ResultData",std::ios::binary); { // create and open an archive for input boost::archive::binary_iarchive ia(ifs); // read class state from archive int no_of_Element; ia>>no_of_Element; for(int i =0;i<no_of_Element;i++) ia >>m_mElemResultData; *// Out Of Memory * }; Same code works fine for text_archive.I have to serialize huge amount of data to a file . Any help will be appreciated . -- View this message in context: http://boost.2283326.n4.nabble.com/Throws-exception-while-deserializing-lar… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[msm] state machine construction / destruction
by Jinsong Huang 21 Oct '11

21 Oct '11

MSM enthusiasts, I have done a performance profiling with a simple parser with 3 implementations, plain C++, SMC and Boost MSM. I was happy to learn that the MSM implementation was very efficient. I'm having some questions about MSM space allocation, please let me know if my understanding of things are wrong (very likely). I work in a high performance computing environment so I will try to minimize unnecessary object constructions. Is it possible for the data in the state machine backend live somewhere else external to the state machine? If that's possible then I can put the state machine's internal states close to the data that needs to be manipulated and the state machine itself is data-less and I can have a single copy of the state machine and each data item carries everything. I know this breaks encapsulation but I'm just wondering. The state machine has a events queue (std::deque?), can I choose to not have this and other data structures I don't think I will need? Thanks, -jh

2 1

enable_if : how to make it work in the case of templated method of a template base inherited several times
by nico 20 Oct '11

20 Oct '11

I hope the subject didn't make you run away ;-) Let me be clearer (I'll try at least): If I have a template base class with a template method : template <typename T> class S { public: template <typename U> void f(U p, typename enable_if<is_same<T, U> >::type*dummy = 0) { std::cout < {}; Then I have what I want: int i = 1; A a; a.f(i); compiles, but double d = 2.0; a.f(d); doesn't compile : error: no matching function for call to ‘A::f(double&)’ It is the expected behavior. Now let's A inherit from S<double> also : class A : public S<int>, public S<double> {}; Then the following code doesn't compile : int i = 1; A a; a.f(i); error: request for member ‘f’ is ambiguous error: candidates are: template<class U> void S::f(U, typename boost::enable_if<boost::is_same<T, U>, void>::type*) [with U = U, T = double] error: template<class U> void S::f(U, typename boost::enable_if<boost::is_same<T, U>, void>::type*) [with U = U, T = int] I expected there is no ambiguity : f<int> exists only for S<int> In the compiler error, we can notice that T is known when this piece of code is compiled, but not U (U = U). Any explanation or "workaround" ? Thanks. Nicolas.

4 3

[Re:Opaque Typedef] observations on opaque typedef
by Robert Ramey 20 Oct '11

20 Oct '11

Vicent - I saw your post on this subject some months ago and I've reviewed the thread. I didn't look at the code though. I also looked at the C++0x document and I have something to say about this. a) as you know I'm the author of BOOST_STRONG_TYPEDEF which lets one assign a unique type to some primitive integer type. I did this to permit overloads on integers used for different purposes. The new types created had all the properties of integer types but they were all different types. So far so good. b) I eventually found the BOOST_STRONG_TYPEDEF did too much - what I really wanted to not to inherit all the interoperations but only some of them. So I've reduced or eliminated usage of BOOST_STRONG_TYPE from the serialization library implementation. Never the less, I do see it useful in other contexts so your efforts to create and opaque typedef seem useful to me. c) BUT now I really want something else. I want the ability to assign a new type to an existing type. The current typedef has the feature that if two different names are used for the same type, a new type is NOT created. That is typedef creates a synonym rather than a new type. I thought that C++0x template alias would do this. But a careful reading of the standard document that I have leads me to believe that if two names are aliased to the same underlying type - a new type is not created - just like the current typedef. So what we have in the new C++ is basically a templated typedef. d) what I really need is the equivalent to #define OPAQUE_TYPEDEF(name, t) \ struct name : public t {}; so I can say struct dollar_amount { ... operator *(const & rhs) const {..} // don't include this operator - makes no sense }; OPAQUE_TYPEDEF(debit, dollar_amount); OPAQUE_TYPEDEF(price, dollar_amount) and then say void f(debit, t){...} void f(price t){...} Notice in my example, I don't want debit and price types to be true types and not just synonyms for dollar_amount. I realize that this is whole different kettle of fixh than BOOST_STRONG_TYPE or OPAQUE_TYPE. So this might be considered off topic. or maybe not. Comments welcome. Also anyone can feel free to correct my understanding of the template alias feature of C++0x to create new types. Robert Ramey

5 7

missing locale/info.hpp
by markus.rauber＠bluewin.ch 20 Oct '11

20 Oct '11

Hi in your documentation you mention the availability of info.hpp (located in /boost/locale) I've just downloaded the latest 1.47 release and there's no such "locale" subdirectory and no info.hpp file containing a <locale> include statement. I'd like to use the language settings provided with this header file. Where can it be found? Where can the corresponding library be found? Thanks for your feedback Markus

2 1

using nabble to read/write on Boost ML
by lcaminiti 20 Oct '11

20 Oct '11

Hello all, I use Nabble to read/write Boost emails but it puts special HTML instead of the template parenthesis: template<typename T> Other Nabble users (if any), is there a way to configure Nabble to not do this? If not, is there another web-based tool (a side from my personal gmail) I can use to view and reply Boost emails? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-using-nabble-to-read-write-on-Boos… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] [utility] How can I contribute?
by Stewart, Robert 20 Oct '11

20 Oct '11

Andrzej Krzemienski wrote: > > I am not well familiar with Boost procedures, so I apologize > if my question is silly. There's a good deal published on the web site (see Community). > I found a bug (or a missing feature) in template > boost::value_initialized. I found that a bug report and the > proposed resolution are already there in BoostTrac: > https://svn.boost.org/trac/boost/ticket/5483. Is there a way I > could help speed the process of getting it fixed up? Can people > from outside commit changes to Boost trunk? Outsiders may not commit changes. Adding "[utility]" to your subject would have helped to focus attention on the affected library. Boost.Utility has no single maintainer, so adding that to the subject will attract attention from the interested parties and your asking about the bug reported six months ago will help to increase attention. You might want to add your own details to the Trac report, including whether the proposed patch fixes your problem. (If it did, it should encourage the maintainers to accept the patch.) _____ 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.

1 0

Re: [boost] [locale] missing locale/info.hpp
by Stewart, Robert 20 Oct '11

20 Oct '11

markus.rauber(a)bluewin.ch wrote: > > in your documentation you mention the availability of info.hpp > (located in /boost/locale) I've just downloaded the > latest 1.47 release and there's no such "locale" subdirectory > and no info.hpp file containing a <locale> include statement. > > I'd like to use the language settings provided with this > header file. > Where can it be found? > Where can the corresponding library be found? Boost.Locale was accepted into Boost this past spring (see http://www.boost.org/community/review_schedule.html for details). It has not yet been made part of a release (as can be seen from http://www.boost.org/doc/libs/, which you can access from boost.org's Libraries link.) FYI: It is also helpful to include the library name in square brackets in your subject to ensure the library author/maintainer discovers it (see http://www.boost.org/community/policy.html#subject-line) Conventionally, the library name is rendered in lower case. I have done so in my reply, so Artyom may well have more details to offer you. _____ 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.

1 0

RFC: A better shared_array
by Olaf van der Spek 19 Oct '11

19 Oct '11

Hi, The current shared_array doesn't keep track of size. This greatly decreases it's usefulness. So I wrote a variant that does: http://pastebin.com/wkdLVqM1 Any interest in such a variant? Olaf

3 14

How can I contribute?
by Andrzej Krzemienski 19 Oct '11

19 Oct '11

Hi, I am not well familiar with Boost procedures, so I apologize if my question is silly. I found a bug (or a missing feature) in template boost::value_initialized. I found that a bug report and the proposed resolution are already there in BoostTrac: https://svn.boost.org/trac/boost/ticket/5483. Is there a way I could help speed the process of getting it fixed up? Can people from outside commit changes to Boost trunk? Regards, &rzej

1 0

Re: [boost] Interest in StaticVector - fixed capacity vector
by Nevin Liber 19 Oct '11

19 Oct '11

On 14 October 2011 05:32, Dave Abrahams <dave(a)boostpro.com> wrote: > Use-cases, please! I worked on a messaging system that created messages via serialization (that took iterators) and delivered them via UDP. Most messages were small (<100 bytes) with occasional messages 1K-2K in size. To give ourselves breathing room, we allowed messages up to, say, 32K, as it would be a non-trivial effort to implement splitting/reassembly of messages. > How could it ever be a "drop-in replacement for vector" For over a decade, the mental model for calling push_back, insert, resize, etc. is that it they have no preconditions to check. This is true *for every standard container* (which supports the corresponding operation, of course). You want to *silently* break that consistency. That will lead to buffer overrun bugs, which we know are hard to debug and I'm not saying we don't need the unchecked functionality. I'm saying it should never be spelled p-u-s-h-_-b-a-c-k, i-n-s-e-r-t, r-e-s-i-z-e, etc. (which is one of the reasons I'm arguing against making it policy based). I'm strongly opposed to any solution that uses the same function signatures as the standard containers that isn't as safe and easy to call as the ones in the standard containers. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

3 7

[context] interface to query remaining stack space
by Charlls Quarra 19 Oct '11

19 Oct '11

Hi All, is there a easy way to query the remaining stack space in a given context? assuming the context is running, i can check the address of a stack dummy variable, but i don't see a way to query the top address of the stack. One could do this by storing that top address before creating the context, but i was wondering if there is already an interface that i'm missing? thanks

1 1

Interest in StaticVector - fixed capacity vector
by Andrew Hundt 19 Oct '11

19 Oct '11

On Sun, Aug 14, 2011 at 5:55 AM, Andrew Hundt <athundt(a)gmail.com> wrote: > I've implemented a small companion class to boost.array that functions > like a stack allocated vector with fixed capacity. The motivation for this > class came when I was using boost.array in an interprocess library, when I > realized that I actually desired an adjustable size boost.array, without the > complexity of the vector class in the interprocess library. The result is > StaticVector, which is boost.array directly modified with a size in front of > the array, and added facilities to match std::vector. > > The Implementation is available at: > https://github.com/ahundt/Boost.StaticVector > > Sample Code: > StaticVector<std::size_t,3> three; > three.push_back(5); > three.push_back(2); // size: 2 capacity: 3 > three.push_back(3); > > three.push_back(1); // throws std::out_of_range exception indicating the > capacity has been exceeded > > So here is the big question: > Is there any interest in the class? > > Cheers! > Andrew Hundt > > On Mon, Aug 15, 2011 at 5:20 PM, Nevin Liber <nevin(a)eviloverlord.com> wrote: > On 15 August 2011 16:05, Andrew Hundt <athundt(a)gmail.com> wrote: > > > Good point. I've modified elems to be a char array, and I now > > reinterpret_cast to the class T as necessary. Elements should only be > > constructed when they are added now. > > > > What are you doing about alignment? Take a look at Synyhesizing Types with > Specific Alignments in the Type Traits library for a start. > -- > Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404 > Phil Endecott wrote: > In the case of StativVector<char,N> where N<256, you should consider using > uint8_t to store the size - and similar variations. Boost.Integer makes it > possible to select a suitable type. Sorry for the duplicate email, but my other email seemed to get lost in the shuffle. I know its been a while since I sent my first emails regarding StaticVector, but I have fixed some of the issues others pointed out. - I added a benchmark based on a move benchmark found on C++Next, that shows StaticVector outperforming vector by about 30%, which seems reasonable since there is no dynamic allocation. - I believe I've resolved the StaticVector alignment using type_traits' aligned_storage, as suggested by Nevin Liber. - I've also added the use of Boost.Integer to select the smallest possible type to track the size of the vector given its capacity, as suggested by Phil Endecott. The Implementation is available at: https://github.com/ahundt/Boost.StaticVector Anyone still have additional thoughts or interest in this? Cheers! Andrew Hundt

27 129

range: strided unused parameter 'first' [PATCH]
by Shaun Jackman 18 Oct '11

18 Oct '11

Hi, When using boost::strided I get the following error: boost/range/adaptor/strided.hpp:52: error: unused parameter 'first' The following patch should fix this error. Cheers, Shaun --- boost/range/adaptor/strided.hpp (revision 75052) +++ boost/range/adaptor/strided.hpp (working copy) @@ -49,7 +49,7 @@ namespace boost { } - strided_iterator(base_iterator first, base_iterator it, base_iterator last, difference_type stride) + strided_iterator(base_iterator, base_iterator it, base_iterator last, difference_type stride) : super_t(it) , m_last(last) , m_stride(stride)

1 0

[review] request date change for Local review
by Jeffrey Lee Hellrung, Jr. 18 Oct '11

18 Oct '11

I'm manager for the review of Lorenzo Caminiti's Local library. After a brief discussion with Lorenzo and Greg Crosswhite (review manager assistant), we've decided it would be prudent to push the Local review back to November 10th - 20th (originally scheduled for October 24th - November 2nd), given its overlap with the Atomic review and it being likely that several possible review contributors could be tied up getting 1.48.0 shipped out during the original review time frame. Is it not too late to reschedule? It looks like Local is the last library scheduled for review, and I don't see any conflicts in the calendar. If this is problematic for anyone for any reason, please let me know. Thanks, - Jeff

1 0

[Review:Algorithms] - Review by Neil Groves
by Neil Groves 18 Oct '11

18 Oct '11

*Evaluation of the design.* The design is pleasingly consistent with other algorithms with the exception of clamp_range. The clamp_range function copies, which is inconsitent with the other Boost string algorithms that have the _copy suffix. The clamp_range feature would be better designed as a clamped range adaptor. *Evaluation of the implementation* Generally, the algorithms would benefit from concept checking. In particular the iterator traversals, and range concept requirements should be checked. The implementation of the functions in all.hpp and clamp.hpp are correctly implemented. The clamp function does not provide the usual guarantees about NaN values that most of the floating-point operations do. That is any one argument being NaN does not guarantee a NaN result. This is probably intended, if so a note should be made in the documentation.The argument types may benefit from using call_traits to optimally chose between constant reference and value types. It might be worth considering an assertion that p(lo,hi) is true in the clamp function. The mixing of differing integer types makes the search algorithms defective. The int type is signed, and typically <= the size of std::size_t yet these are mixed. The skip table uses ints, but std::size_t values are inserted. Certainly there should not be any c style casts. It would seem logical to use the boost::iterator_difference<Iterator>::type instead. Currently these algorithms are defective albeit under unusual conditions. There are numerous invocations of non-member functions that should use qualified calls to avoid accidental argument-dependent lookup. range_const_iterator<Rng> has been deprecated in favour of range_iterator<const Rng> The Range versions of the functions should provide a non-const reference version since there are no requirements for the interoperability of range_iterator<const Range> and range_iterator<Range> although they normally exist.. The tests have some defects with respect to dereferencing end iterators. As others have mentioned there should be range versions of all of the functions. *Evaluation of the documentation* The documentation should make very clear that the result for empty ranges into all_of, any_of, none_of as this is currently ambiguous. The documentation should provide more clear performance guarantees about the number of predicate evaluations where this is possible eg. any_of can and does early exit. The documentation should also provide the exception guarantees. *Evaluation of usefulness* If corrected and properly documented these functions will be very useful. The functions any_of etc. are extremely useful for runtime assertions of pre- and post-conditions. *Did I try to use the library?* I used the library with GCC 4.6.1. I had no problems, although I did defect the defects noted above. *How much effort did I put into my evaluation?* I reviewed the code for a couple of hours which was sufficient for the small amount of code under review. *Am I knowledgeable about the problem domain?* Yes, I maintain Boost.Range hence my comments with respect to ranges are reasonably well informed. I have long been a fan of Design by Contract and hence I have experience using my own versions of the functions all_of etc. I vote for inclusion into Boost if and only if: 1. the defects in the search functions and test are resolved 2. clamp_range is removed or replaced. Regards, Neil Groves

9 15

[multi_array] swap
by Maxim Yanchenko 18 Oct '11

18 Oct '11

Hi, The swap support for multi_array was under discussion from the very beginning. A multi_array is quite a heavy object so having light-weight and no-throw swap would be really great. In 2009 a patch was proposed (https://svn.boost.org/trac/boost/ticket/1045) and Ronald Garcia generally liked it, but planned to do some extra work before adding swap to multi_array (see the comments for the ticket above). What is the current status? Thanks, Maxim

2 1

[msm]Event convert at exit point
by Takatoshi Kondo 17 Oct '11

17 Oct '11

Hello, I have a question about Boost.Msm event conversion at exit pseudo state. (Version 1.47.0) http://www.boost.org/doc/libs/1_47_0/libs/msm/doc/HTML/ch03s02.html#d0e942 Exit pseudo states struct event6 { event6(){} template <class Event> event6(Event const&){} }; //convertible from any event Above document said that we can convert the event using the template constructor. This exmaple doesn't access the constructor's parameter. I want to propagate some value of the event. Event2 is a source event. And Event3 is a target event like this.(see attached file) struct Event2 { Event2(int val_):val(val_) {} int val; }; struct Event3 { Event3(int val_):val(val_) {} template <class T> Event3(T const& e):val(e.val) {} // error Event3(Event2 const& e):val(e.val) {} // OK int val; }; // Transition table struct transition_table:mpl::vector< // Start Event Next Action Guard msmf::Row < SubState1, Event2, Exit, msmf::none, msmf::none > > {}; struct Exit :msm::front::exit_pseudo_state<Event3> {}; But compile error occurred. The compiler said Event1 doesn't have a member 'val'. I'm not sure why Event3's constructor instantiate from Event1. This is the question. If I define the constructor that has a parameter Event2 instead of template parameter, compile error doesn't occur. exit_pt_convert.cpp(attached file) is a source code that reproduces this error. Thanks, Takatoshi

3 4

Extra files in release branch
by Marshall Clow 17 Oct '11

17 Oct '11

As of revision #74996, the following files and directories exist only in the release branch - not in the trunk. Is this on purpose? boost/smart_ptr/enable_shared_from_this2.hpp boost/test/detail/unit_test_parameters.hpp boost/test/exception_safety.hpp boost/test/impl/unit_test_suite.ipp boost/test/interaction_based.hpp boost/test/logged_expectations.hpp boost/test/mock_object.hpp boost/test/test_observer.hpp boost/test/unit_test_suite_impl.hpp boost/test/utils/callback.hpp libs/phoenix/doc/html/phoenix-doc_HTML.manifest libs/test/example/cla/Jamfile libs/test/example/unit_test_example_011.cpp libs/test/example/unit_test_example_012.cpp libs/test/src/unit_test_suite.cpp libs/test/test/CMakeLists.txt libs/geometry/test/ranges (empty directory) libs/phoenix/doc/html/phoenix (not empty directory) libs/spirit/doc/html/spirit (not empty directory) libs/spirit/repository/doc/html/spirit_repository (not empty directory) libs/test/doc/html/utf/usage-recomendations (not empty directory) -- 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

4 5

Adding a --log_level="message" runtime option to a Boost.test test-suite
by Paul A. Bristow 16 Oct '11

16 Oct '11

Can anyone tell me how to add a --log_level="message" runtime option to a Boost.Test test-suite. Running using VS project I have a Custom Build Step command line "$(TargetDir)$(TargetName).exe" --log_level="message" I'd like to replicate this in a jamfile : ... test-suite "multiprecision EFX numerical test" : [ run numerical_test.cpp ] ; but adding --log_level="message" (and perhaps other Boost.test options as well). (I want this for all compilers of course, so placing in compile options doesn't seem right.) Suggestions most welcome. Thanks Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

2 6

Unittest capability for meta-programs feedback request
by Ben Robinson 16 Oct '11

16 Oct '11

This submission would make it possible to write a complete set of unit tests for meta-programs, to test both the positive, compiling statements, and the negative, non-compiling statements. These tests will all compile, and the negative tests can throw an exception instead of failing to compile. The submission source is available at https://github.com/icaretaker/Metatest. The provided examples are based on the factorial metafunction from Chapter 8 of "C++ Template Metaprogramming" by David Abrahams and Aleksey Gurtovoy - http://www.boostpro.com/mplbook/. Chapter 8 explains the rational behind the BOOST_MPL_ASSERT_* macros. This submission complements these macros by allowing the writing of regression unit tests, to ensure the user will encounter the mpl formatted compiler error, if the library types are incorrectly instantiated. Currently, many meta-programs are written using one of the BOOST_MPL_ASSERT_* macros. Unit tests for these metaprograms must of course compile, therefore unittests for these programs can verify that valid types produce the correct run-time behavior. This submission provides the following four complementary macros: BOOST_METATEST(pred) BOOST_METATEST_NOT(pred) BOOST_METATEST_RELATION(x, rel, y) BOOST_METATEST_MSG(cond, msg, types) Meta-program authors can use these macros to assert predicates/relations/conditions exactly as done with BOOST_MPL_ASSERT_*. In shipped library code, these four macros exactly forward to their BOOST_MPL_ASSERT_* counterparts, since the BOOST_MPL_ASSERT_* macros do an excellent job of providing maximally informative compiler error messages. In unit test code (where BOOST_METATEST_RUNTIME will need to be defined), these macros will instead instantiate an object, which will throw a runtime exception if the predicate/relation/condition fails. Now meta-program authors can write unittests like the following: BOOST_AUTO_TEST_CASE(factorials_should_not_be_negative) { BOOST_CHECK_THROW( factorial<mpl::int_<-1> > instance;, metatest_exception ); } As you can see, this unit test validates that the factorial meta-function will in fact fail to compile. All exceptions are subclassed from boost::metatest_exception. If the user would instead like to supply their own exception types for individual assertions, one of the following four macros can be used alternatively: BOOST_METATEST_EXP(pred, exp) BOOST_METATEST_NOT_EXP(pred, exp) BOOST_METATEST_RELATION_EXP(x, rel, y, exp) BOOST_METATEST_MSG_EXP(cond, msg, types, exp) Another feature of this library, is that it is independent of any unit testing framework, provided the framework can catch exceptions by type. The examples provided show how this is done with Boost Test. The submission files also show how to use try/catch directly should your unit test framework not have such a capability. I look forward to your feedback. Thank you, Ben Robinson, Ph.D.

16 40

[test] Still having issues
by John Maddock 16 Oct '11

16 Oct '11

I'm still having a lot of issues with the latest Boost.Test not building: On Win32 with Intel's 11.1 and 12.1 compilers I see: ..\..\..\boost/test/impl/execution_monitor.ipp(104): error: invalid redeclaration of type name "_invalid_parameter_handler" (declared at line 228 of "C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\stdlib.h") typedef void* _invalid_parameter_handler; And on Ubuntu Linux with gcc I see: gcc.compile.c++ /home/john/bin/boost/bin.v2/libs/test/build/gcc-4.4.3/debug/link-static/unit_test_main.o In file included from ../../../libs/test/src/unit_test_main.cpp:16: ../../../boost/test/impl/unit_test_main.ipp: In function 'int boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int, char**), int, char**)': ../../../boost/test/impl/unit_test_main.ipp:97: error: 'getchar' is not a member of 'std' "/usr/local/gcc/4.4.3/bin/g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -DBOOST_ALL_NO_LIB=1 -I"../../.." -c -o "/home/john/bin/boost/bin.v2/libs/test/build/gcc-4.4.3/debug/link-static/unit_test_main.o" "../../../libs/test/src/unit_test_main.cpp" Probably a missing <cstdio> include? John.

3 13

[1.48] Reminder: merge fixes by Monday!
by Eric Niebler 14 Oct '11

14 Oct '11

Just a reminder that as of Monday, the release branch will be closed except for permission by a release manager. If you have fixes to merge to the release branch, please try to get them in over the weekend. Here's the schedule: October 10: The release branch was closed for major code changes. It is still open for serious problem fixes and docs changes. October 17: branches/release closed for all library changes except when specific permission given by release manager(s). October 24: Beta target date. Further betas and/or release candidates as feedback dictates. November 7: Release target date View Boost calendar: http://tinyurl.com/4xacpyj Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Is Boost interested in the Boost-based Base64 library
by Denis Shevchenko 14 Oct '11

14 Oct '11

Hi all! Not so long ago I was looking for a solution to Base64 encoding/decoding. In this page - http://www.boost.org/doc/libs/1_46_1/libs/serialization/doc/dataflow.html - I found example of such solution, with 'base64_from_binary' and 'transform_width' iteartors. But it is just a "blank", not ready-to-use solution. I created solution. But I definitely know many developers looking for a simple, ready-to-use, header-only and 'real C++' solution for Base64. So I want to offer you such solution. Some examples: int main() { std::string my_text = "My text for encoding!"; std::string encoded_text = boost::base64().encode( my_text ); std::string my_text_again = boost::base64().decode< std::string >( encoded ); } For binary data: int main() { typedef std::vector< unsigned char > binary_string; binary_string my_bin = list_of( 0xFF )( 0xAA )( 0x01 ); std::string encoded_bin = boost::base64().encode( my_bin ); binary_string my_bin_again = boost::base64().decode< binary_string >( encoded ); } For streams: int main() { boost::filesystem::ifstream my_jpeg( "/some/path/to/my/image" ); // fstream checking omitted... std::string encoded_jpeg = boost::base64().encode( my_jpeg ); boost::filesystem::ofstream my_jpeg_again( "/some/path/to/decoded/image" ); // fstream checking omitted... boost::base64().decode( encoded_jpeg, my_jpeg_again ); } This is first variant. IMHO such solution will be useful for Boost users. What you think about it? - Denis

7 27

[date_time] performance tests
by Greg Rubino 13 Oct '11

13 Oct '11

Hi all, Does anyone know of/have an open source suite of performance tests for Boost.Date_Time? If not, I'll post back with whatever I come up with. Thanks, Greg

1 0

Checking interest in to_string functions
by Antony Polukhin 13 Oct '11

13 Oct '11

As was mentioned in `[boost] to_string(v)` 1) Functions to_string and to_wstring are part of the upcoming C++0x standard. However, there are no functions for char16_t and char32_t conversions. 2) Some users can't use C++11 in some projects for quite some time, but can use boost. 3) "to_string(5)" is a lot shorter than "lexical_cast<std::string>(5)". Some users would like to use a shorter form. Is there interest in stoi, stoll, stof, to_string, to_wstring, to_u16string, stod and other functions for char, wchar_t, char16_t and char32_t conversions? Shall I add them to lexical_cast library, or as a separate conversion library? Best regards, Antony Polukhin

8 15

[ASIO] tcp::socket::async_connect() connections count
by Jim Xochellis 13 Oct '11

13 Oct '11

Hi list, I am testing a slightly modified version of the chat_client/chat_server ASIO examples and I have noticed that, immediately after the tcp::socket::async_connect() call from inside the chat_client constructor, the client is creating and establishing not one, but three TCP connections, only one of which is targeting to the server-port. Furthermore, calling repeatedly the async_connect() seems to constantly create three connections per call. I have also noticed that other programs in my system, which also communicate via TCP (ie the hyper-terminal), only open one connection at the client side. Is this async_connect() behavior, which I have mentioned above, the expected/natural behavior, or maybe I am doing something wrong? If this behavior is expected, is there a reason for it? Do I have a choice to change it? Please note that there is a near-4000 outbound concurrent connections default limit in many Windows-XP installations, hence this question has a practical meaning. Configuration informations: OS: Windows XP Pro SP3 Boost version: 1.46.1 IDE: MVS 2005 Thank you in advance, Jim Xochellis ----- Homepage: https://sites.google.com/site/xochellis/ -- View this message in context: http://boost.2283326.n4.nabble.com/ASIO-tcp-socket-async-connect-connection… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[filesystem] scoped_file feature request?
by Beman Dawes 13 Oct '11

13 Oct '11

There is a long outstanding feature request, #1090 from Marcus Lindblom, requesting the following be added to Boost.Filesystem: class scoped_file { public: explicit scoped_file(const boost::filesystem::path& file) : m_path(file) {} ~scoped_file() { boost::filesystem::remove(m_path); } private: boost::filesystem::path m_path; }; My weakly held opinion is that this request should be rejected. Rationale: Easy enough for users to do themselves, so it doesn't justify the additional surface area it would add to of the library. Does anyone have a killer argument for adding it? --Beman

5 12

Dennis Ritchie passed away
by Nevin Liber 13 Oct '11

13 Oct '11

<https://plus.google.com/101960720994009339267/posts/ENuEDDYfvKP> via Rob Pike - 8:02 PM - Public I just heard that, after a long illness, Dennis Ritchie (dmr) died at home this weekend. I have no more information. I trust there are people here who will appreciate the reach of his contributions and mourn his passing appropriately. He was a quiet and mostly private man, but he was also my friend, colleague, and collaborator, and the world has lost a truly great mind. -- Nevin Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

2 1

BGL: labelled edge graph
by Shaun Jackman 12 Oct '11

12 Oct '11

Hi, I have a directed acyclic word graph (DAWG) [1] for which the fundamentally efficient operation takes a vertex descriptor and an edge label and returns an edge descriptor (if that edge exists). An out_edge_iterator can be used to iterate over the edges to find the edge with the specified label, but it's not very efficient. I plan to extend the BGL API to add the needed functionality. I wanted to check first that this function doesn't already exist, and if it doesn't, ask for suggested names. I was thinking of... pair<edge_descriptor, bool> out_edge( vertex_descriptor u, edge_label i, Graph g); The type of edge_label would depend on the graph. For me, it's a char. This sort of labelled edge navigation also applies to a de Bruijn graph [2]. Cheers, Shaun [1] http://en.wikipedia.org/wiki/Directed_acyclic_word_graph [2] http://en.wikipedia.org/wiki/De_Bruijn_graph

2 1

[numeric][interval] clang support patch
by Jürgen Hunold 12 Oct '11

12 Oct '11

Hi, I've been running into the (in-)famous clang bug http://llvm.org/bugs/show_bug.cgi?id=6907 which prevents detail/c99sub_rounding_control.hpp from working. Boost contains workaround code in <boost/detail/fenv.hpp> which is used by the patch attached. Ok to commit? Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

3 3

[thread] How to return a lazy future ?
by Ivan Le Lann 12 Oct '11

12 Oct '11

Hi, Boost.Thread documentation has a section regarding the creation of lazy futures. http://www.boost.org/doc/libs/1_47_0/doc/html/thread/synchronization.html#t… The code on this page runs fine, but I can't find a way to return such future. Naïve code below exits with a boost::broken_promise in unique_future::get(). boost::unique_future <int> create_future() { boost::packaged_task<int> task(calculate_the_answer_to_life_the_universe_and_everything); task.set_wait_callback(invoke_lazy_task); return task.get_future(); } int main() { assert(create_future().get()==42); } Exceptional finish is marked in packaged_task destructor. And regardless of exceptions, since set_wait_callback want something that operates on packaged_task and not on pointed task_base, the code is doomed to do an access violation. So, is there any way to return lazy futures ? Regards, Ivan

1 0

Disable_if_type / is_pair
by Olaf van der Spek 12 Oct '11

12 Oct '11

Hi, I've got a find wrapper (returning a pointer instead of an iterator) that works for map, unordered map, ptr map, etc. I'd like to extent it to set and mult_index. What is the recommended way to disable the second overload? I didn't find a is_pair type_trait or disable_if_type. I call the find() member, which for example vector doesn't have. How should I use the free find() if a member find() isn't available? template <class T, class U> typename T::value_type::second_type* find_ptr(T& c, U v) { typename T::iterator i = c.find(v); return i == c.end() ? NULL : &i->second; } template <class T, class U> typename iterator_traits<typename T::iterator>::pointer find_ptr(T& c, U v) { typename T::iterator i = c.find(v); return i == c.end() ? NULL : &*i; } Greetings, Olaf

2 6

[chrono][system] Make possible to don't provide hybrid error handling.
by Vicente J. Botet Escriba 11 Oct '11

11 Oct '11

Hi, Boost.Chrono provides by default an hybrid error handling for the Clock::now() function, implementing the following prototype Clock::now(system::error_code&= boost::throws()); Now that the standard has accepted the prototype Clock::now() noexcept; and set as NAD-Future the Beman proposal (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3314.html#935) The hybrid prototype can not be noexcept, as the use of boost::throws() force to throw an exception on error. We need to overload the function as follows: Clock::now() noexcept; Clock::now(system::error_code&); This lost the advantages of the announced by the hybrid error handling design (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html) as we are forced to have two implementations. In addition, while most of the uses of now(ec) expect that there is no exception, the prototype can not state it using noexcept, if the boost::throws() semantic is taken in account. Due to this split, we can now make Boost.Chrono a real header-only library if we admit to renounce to use the hybrid interface. The library could add a macro that prevent the inclusion of these prototype, as e.g. BOOST_CHRONO_DONT_PROVIDE_HYBRID_ERROR_HANDLING. The experience while using these hybrid approach and mixing all these semantics has shown me that this doesn't promotes good design and doesn't compose well. Split the prototypes is cleared. system_clock::time_point system_clock::now() noexcept { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) // Note that this call is used only when the platform provides this interface. { BOOST_ASSERT(0 && "Boost::Chrono - Internal Error"); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } system_clock::time_point system_clock::now(system::error_code & ec) { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { if (BOOST_CHRONO_IS_THROWS(ec)) //[1] { boost::throw_exception( system::system_error( errno, BOOST_CHRONO_SYSTEM_CATEGORY, "chrono::system_clock" )); } else { ec.assign( errno, BOOST_CHRONO_SYSTEM_CATEGORY ); return time_point(); } } if (!BOOST_CHRONO_IS_THROWS(ec)) // [2] { ec.clear(); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } Note how the test on whether the ec is thows() in [1] to throw and in [2] see if the ec can be cleared are obscuring what in principle was simple. It will be maybe better to add yet a 3rd prototype that forces the throw_on_error. Clock::now() noexcept; Clock::now(system::error_code&) noexcept; Clock::now(throw_on_error_t&); system_clock::time_point system_clock::now() BOOST_CHRONO_NOEXCEPT { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { BOOST_ASSERT(0 && "Boost::Chrono - Internal Error"); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } system_clock::time_point system_clock::now(system::error_code & ec) { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { ec.assign( errno, BOOST_CHRONO_SYSTEM_CATEGORY ); return time_point(); } ec.clear(); return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } system_clock::time_point system_clock::now(throw_on_error_t & /*tag*/) noexcept { timespec ts; if ( ::clock_gettime( CLOCK_REALTIME, &ts ) ) { boost::throw_exception( system::system_error( errno, BOOST_CHRONO_SYSTEM_CATEGORY, "chrono::system_clock" )); } return time_point(duration( static_cast<system_clock::rep>( ts.tv_sec ) * 1000000000 + ts.tv_nsec)); } While these functions are quite simple and repeating the code is not an issue, when the logic is more complex, this could become a maintenance issue that should be resolved other techniques, as using internal functions, policies, ... I see three alternatives: A- Standard Clock::now() noexcept; B- Standard+Hybrid Clock::now() noexcept; Clock::now(system::error_code&); // takes care of boost::throw() C-Standard+EC+TOE Clock::now() noexcept; Clock::now(system::error_code&) noexcept; Clock::now(throw_on_error_t&); A breaks code using the error_code. C breaks code using the boost::throws() Yet another temporary alternative: D- Clock::now() noexcept; Clock::now(system::error_code&); // takes care of boost::throw() but it is deprecated Clock::now(throw_on_error_t&); We can start by providing D and let the user using boost::throws to move to throw_on_error, and the move to C. In addition the library must provide the user the possibility to don't include the extensions. Which way do you prefer? What do you think? Best, Vicente

4 6

Re: [boost] [filesystem] scoped_file feature request?
by Andrzej Krzemienski 11 Oct '11

11 Oct '11

> There is a long outstanding feature request, #1090 from Marcus > Lindblom, requesting the following be added to Boost.Filesystem: > class scoped_file { > public: > explicit scoped_file(const boost::filesystem::path& file) > : m_path(file) {} > ~scoped_file() { boost::filesystem::remove(m_path); } > private: > boost::filesystem::path m_path; > }; > > My weakly held opinion is that this request should be rejected. > Rationale: Easy enough for users to do themselves, so it doesn't > justify the additional surface area it would add to of the library. > Does anyone have a killer argument for adding it? > --Beman Hi, I would add to the rationale for rejection, that scoped_file's destructor performs an operation that might throw an exception, which is counter to well established practices in C++. You could use the error_code version, but that would hide the error if any occurs. Regards, &rzej

1 0

BOOST_FORCE_INLINE
by Mathias Gaunard 11 Oct '11

11 Oct '11

I would like a BOOST_FORCE_INLINE macro to be added to boost/config/suffix.hpp Who do I need to contact to make this happen?

16 31

Problems with proto and /clr
by Jorge Lodos Vigil 11 Oct '11

11 Oct '11

Hi In boost 1.47 proto stopped compiling with /clr in VS2008 and VS2010. Take the calc3 example, for instance. The root problem is that /clr is instantiating templates that normally are not. The change in proto is the new is_applyable metafunction. In normal compilation, when the received parameter is not callable mpl::and_ ensures that there is no need to fully instantiate the is_transform metafunction parameter. Apparently when using /clr it gets instantiated any way. You may verify this commenting out the 3 BOOST_MPL_ASSERT_RELATION lines in calc3 sample (so it will compile) and adding the following in the main function: // This is an instantiation of is_applyable that causes problems typedef boost::mpl::max<CalculatorGrammar,boost::proto::_state> is_applyable_parameter_t; // This is why it normally compiles BOOST_MPL_ASSERT_NOT((boost::proto::is_callable<is_applyable_parameter_t>)); // The following correctly fails to compile, the is_transform metafunction must never be instantiated //bool is_tranform = boost::proto::is_transform<is_applyable_parameter_t>::value; // This is the line that does not compile with /clr but normally does typedef mpl::and_<mpl::false_, boost::proto::is_transform<is_applyable_parameter_t> > problem_t; This code fails to compile with /clr, because is_applyable_parameter_t is instantiated and CalculatorGrammar is not comparable. Before I continue to dig in proto code, try workarounds and create tickets, I thought I might ask these questions here: 1. In case a workaround can be found (decomposing is_applyable in 2 metafunctions, for instance) is it of interest to support /clr? 2. Is this situation a compiler bug, a proto bug or just bad luck + undefined behavior? I'll appreciate any comment you may have on this. Please note that this causes xpressive and probably spirit to fail compilation with /clr. On a side note note, if there is interest to support /clr, it should not be a problem to modify MSVC test scripts. Only the /clr parameter must be added to the command line, nothing else. Apparently there is no big demand for C++ with /clr, but if there is interest I could try to modify tests scripts and correct any problem that may surface. Thank you in advance for your time. Best regards Jorge

2 1

[serialization] Technique used for registration of derived through base ( Abrahams wizardy )
by Sebastian Karlsson 11 Oct '11

11 Oct '11

A good while ago I got interested in how the registration process works in boost::serialization, I was never able to understand how the technique works, even if the gist of it is contained in 2 fairly small headers ( boost/serialization/export.hpp & boost/archive/detail/register_archive.hpp ). It would seem the creator of the technique is David Abrahams, so I'm hoping he or anyone else which understands how the registration process works could explain the technique used. >From my understanding it solves the problem of having 2 different sequences of types, and then being able to operate on all the combinations. All the techniques I've seen used previously for this requires the maintenance of some sort of compile time vector of one of the sequences. This is very cumbersome, not only does it needs to manually managed, but the file that defines the vector turns into a large dependency bottleneck. From my understanding the technique used in boost::serialization currently one sequence simply adds an overload to a free function, then at the registration point of the other sequence just having the overloads considered at compile time causes the magic to happen when the return type needs to instantiated. Unless I'm missing something obvious I think it would make for a very interesting subject of an article or discussion on the mailing list. Kind regards, Sebastian Karlsson

1 0

operator traits: ready for addition
by Frédéric Bron 11 Oct '11

11 Oct '11

Dear John, Included is are 2 patches vs trunk with operator traits additions: - boost_type_traits.patch.bz2 to be applied in boost/type_traits - libs_type_traits.patch.bz2 to be applied in libs/type_traits I have also updated the sandbox: :http://svn.boost.org/svn/boost/sandbox/type_traits/ This new version addresses all review comments. Tested with gcc 4.6.1 and intel-linux 12.0. Could be nice if somebody could run the tests with msvc. Hope everything is fine. What would be the best way to add it to the trunk? Regards, Frédéric PS: sorry for the long delay but it is very hard to find some free time with a job and a family.

2 2

Re: [boost] [proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Eric Niebler 11 Oct '11

11 Oct '11

On 10/10/2011 4:50 PM, Joel de Guzman wrote: > Everything's green now, Eric. The problem was not pervasive after > all; just a couple of fixes solved everything. Whew! > There's no need to revert. It makes me wonder though if we've missed > something that will blow up in the future. I'll probably have to > scrutinize classes that use proto::extends and check for overloads. The problem is that Spirit defines its own operator overload(s) that compete with Proto's. The officially sanctioned way of doing this with Proto is to use a grammar to restrict Proto's overloads, and then define your own. Admittedly, Proto's docs could be more clear about best practice here. > You might want to warn other proto users of this potential > breaking change. This will need to be mentioned in the release notes, yes. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] Boost.Algorithm design question
by Joe Mucchiello 11 Oct '11

11 Oct '11

On 10 Oct 2011 10:32:53 +0200, Thorsten Ottosen <thorsten.ottosen(a)dezide.com> wrote: > Den 07-10-2011 20:45, Joe Mucchiello skrev: >> On Fri, 07 Oct 2011 10:30:26 +0200, Thorsten > Ottosen<thorsten.ottosen(a)dezide.com> wrote: >> >>> Den 06-10-2011 18:27, Phil Endecott skrev: >>>> Thorsten Ottosen wrote: >>>>> Even better, don't use vector<const char*>. What o > you need that for? >>> [snip] >>>> >>>> Here's a real motivating example where I want to use > vector<const >>>> char*>. I have a large file containing null-terminated strings > which I >>>> memory map. After opening the file, I construct some sort of index > of >>>> those strings in a sorted vector. Then I search for things using >>>> std::equal_range, std::lower_bound, or similar. >>> >>> That's a good example, I grant you. >> >> >> I actually have a helper class for this called cstrptr which is a typedef > for the template class >> >> basic_cstrptr<char>. It is a "dumb" wrapper around const > char * that provides some std::string >> > > Also, something like iterator_range<const char*> might be somewhat more > handy to store in the vector. Perhaps in the generic case, but as I said, my class is for magic text found in programs and you practically never need to run generic algorithm against lists of magic text. The value in my class is that it is basically the same size as a pointer to char and has a near nop constructor. But my class might be too specific for boost based on the lack of any reaction to the concept. It is just a little fluff class. Joe

1 0

Re: [boost] [proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Eric Niebler 10 Oct '11

10 Oct '11

On 10/10/2011 2:08 AM, Joel de Guzman wrote: > On 10/10/2011 1:52 PM, Joel de Guzman wrote: >> On 10/10/2011 12:38 PM, Eric Niebler wrote: >>> >>> Bummer. I suggest adding an rvalue ref overload of operator%= that >>> shares an implementation with the const lvalue one. Should just be a few >>> lines of code. Is that a problem? >> >> Not really a problem. But, %= is just an example of the problems >> (plural with an s). We suspect that it is more widespread. I'll >> see how pervasive the changes need to be and get back to you. > > Ok, adding the %= for rvalue refs for Qi and Karma fixed a lot of > the failing tests. However, I am not sure how to fix the tests > involving Lex (crashes on VC10 but OK on GCC). The compiler > tutorial I am working on also got broken. I am not sure what else > in the examples got broken. It's quite difficult to ascertain > where the problem is because the code builds without errors > but either crashes or does not work as expected at runtime. > This is an insidious critter. > > Hartmut, I committed the fix for Qi and Karma. Can you please > take a look at the Lex regressions? There's a good chance > that the problem with the examples is also related to the Lex > problem. I just ran the spirit_v2/lex and spirit_v2/lex_regressions test suites on msvc-10.0, and everything passed for me. Is this fixed already? Let me know asap so I know whether to revert my Proto changes. (Note: If they don't make it in this time, these Proto changes will eventually go back in for next release, so Qi/Karma/Lex will need to be fixed eventually.) -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Mathias Gaunard 10 Oct '11

10 Oct '11

On 10/10/2011 11:08, Joel de Guzman wrote: > Ok, adding the %= for rvalue refs for Qi and Karma fixed a lot of > the failing tests. However, I am not sure how to fix the tests > involving Lex (crashes on VC10 but OK on GCC). The compiler > tutorial I am working on also got broken. I am not sure what else > in the examples got broken. It's quite difficult to ascertain > where the problem is because the code builds without errors > but either crashes or does not work as expected at runtime. > This is an insidious critter. Does it work without errors when enabling optimizations? It could be a problem with the lifetime of references.

1 0

multi_index bug?
by Olaf van der Spek 10 Oct '11

10 Oct '11

Hi, I've got this container: typedef boost::multi_index_container< torrent_t, boost::multi_index::indexed_by< // boost::multi_index::hashed_unique<boost::multi_index::member<torrent_t, int, &torrent_t::id>>, boost::multi_index::ordered_unique<boost::multi_index::member<torrent_t, int, &torrent_t::id>>, boost::multi_index::sequenced<> > > torrents_t; I'm using the find() member to find elements. When I use hashed_unique, it seems to be unable to find some elements, while it finds all if I use ordered_unique. This is with Boost 1.46.1.1 (Debian) and gcc version 4.6.1 (Debian 4.6.1-4) Is this a known issue? Olaf

2 2

Re: [boost] Boost.Algorithm design question
by Joe Mucchiello 10 Oct '11

10 Oct '11

On Fri, 07 Oct 2011 10:30:26 +0200, Thorsten Ottosen <thorsten.ottosen(a)dezide.com> wrote: >Den 06-10-2011 18:27, Phil Endecott skrev: >> Thorsten Ottosen wrote: >>> Even better, don't use vector<const char*>. What o you need that for? >[snip] >> >> Here's a real motivating example where I want to use vector<const >> char*>. I have a large file containing null-terminated strings which I >> memory map. After opening the file, I construct some sort of index of >> those strings in a sorted vector. Then I search for things using >> std::equal_range, std::lower_bound, or similar. > >That's a good example, I grant you. I actually have a helper class for this called cstrptr which is a typedef for the template class basic_cstrptr<char>. It is a "dumb" wrapper around const char * that provides some std::string functions to the normally even dumber bare pointer to char. It's designed for holding those magic strings that creep into production code all the time. sizeof cstrptr == sizeof const char* is always true so the constructor has very little overhead. The calling code is responsible for ensuring the lifetime of the ptr exceeds the lifetime of the cstrptr instance. It implements all the comparison operators against std::basic_string and const char*. It implements a const operator[] and an O(N) length() function. It only implements assignment and copy constructor to allow containers to hold them. I've wondered whether it was worth submitting to boost. It is so small I can't imagine it sitting on its own as a "library".

2 1

[test] backward compatibility issue
by Jürgen Hunold 10 Oct '11

10 Oct '11

Hi Gennadiy, I'm getting some compiler errors when using the new trunk version of Boost.Test with our sources. I'm getting error: ‘global_fixture_impl’ in namespace ‘boost::unit_test::ut_detail’ does not name a type when using BOOST_GLOBAL_FIXTURE and only #including "boost/test/unit_test_suite.hpp" This file #defines at line 179: static boost::unit_test::ut_detail::global_fixture_impl<F> BOOST_JOIN( gf_, F ) ; a simple #include <boost/test/tree/global_fixture.hpp> fixes this. Patch attached. Okay to commit? yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

2 2

Boost.Algorithms request
by Zoltán Tóth 10 Oct '11

10 Oct '11

I ask to change the name of function is_ordered(). The "is_" prefix suggests that it is a boolean function which it is not. Also, there are other functions there with prefix "is_" and which are boolean functions, and this non-uniformity hurts the eye. I suggest the name "first_misordered".

4 3

Re: [boost] vsix - template_profiler extension, Templight
by József Mihalicza 09 Oct '11

09 Oct '11

Hello, From: Domagoj Saric: ...you might want to try the Templight route. A couple of years back the Hungarian team behind it tried to do the same thing as you (a "meta program debugger and profiler" Visual Studio add-in, only it was written in C++ rather than in C#). The source for an alpha-ish version was also available somewhere... The biggest problem with our tools is that they are rather prototypes than tools for everyday use. As none of the authors have had enough time to maintain them, they more or less remained in an alpha state. Fortunately this seems to change soon, a team with dedicated resources is being formed to make these tools usable and presumably public domain. What we have so far: * Templight framework: a set of command line utilities, based on Xerces and boost.{wave,spirit}. Supports g++ and VC (patches and warning message interpretation). * Visual Studio add-in, where the user can place breakpoints in templates, view template stack, instantiation history, debug step by step. * Standalone debugger application with the same features as of the VS add-in. C++, Qt, mainly tested on Windows. * Templar: standalone visualizer application: can load previously generated (with the cpp2trace tool) trace files and draws the instantiation forest allowing step by step debugging. C++, Qt, graphviz. The latest binary for Windows is available here: http://people.inf.elte.hu/pocok/ * Ad-hoc solutions for profiling: modified g++, also had some patches for VC to print timestamp at each warning. * A not-yet-implemented approach to cope with inheritance. If B inherits A, currently the reported order is Abegin,Aend,Bbegin,Bend instead of the expected Bbegin,Abegin,Aend,Bend. As we used handcrafted makefiles (on linux) and projects files (VC) with absolute paths to installed libraries, it is not trivial to make the source compilable. This is why we decided not to publish it in its current form. Still, if anyone is interested in any of them, feel free to contact me, I can send the current version. Regards, Jocó

1 0

Re: [boost] [1.46.0] Compilation Issues
by Lars Viklund 08 Oct '11

08 Oct '11

On Sat, Oct 08, 2011 at 11:34:02AM +0530, ranganaths wrote: > Hello, > trying to compile on MSVC 6.0, but the same works well in Cygwin. Most of > Pls let me know how to overcome the same. All the > redefinitions are the clashes with that of the MSVC compiler includes. VC6 is a pre-standard compiler. As such, it has lots of quirks and templates are pretty much unusable on it. I strongly recommend either upgrading the compiler (there's free Express editions and reasonably cheap business and academic versions through BizSpark and DreamSpark), or using older Boost versions who accidentally care more about legacy toolchains. Strong words, but it's not feasible maintaining workarounds for legacy toolchains, not to mention actively fixing things for them. There's a huge thread on what to do with dysfunctional toolchains a few months ago. It's an amusing read. -- Lars Viklund | zao(a)acc.umu.se

1 0

[1.46.0] Compilation Issues
by ranganaths 08 Oct '11

08 Oct '11

Hello, I am new to this forum. I am using the Boost Library in my open source application and I am facing lot of compilation issues when trying to compile on MSVC 6.0, but the same works well in Cygwin. Most of the compilation errors are based on the redefinition. The errors is as below error C2371: 'XXX' : redefinition; different basic types Pls let me know how to overcome the same. All the redefinitions are the clashes with that of the MSVC compiler includes. Eg: Boost has definition for 'round_toward_zero' in e:\Application \boost\detail\limits.hpp(58) : see declaration of 'round_indeterminate' c:\program files\microsoft visual studio\vc98\include\limits(28) : error C2371: 'round_toward_zero' : redefinition; different basic types Regards, Ranganath

1 0

fusion - reverse_view on maps
by Brandon Kohn 07 Oct '11

07 Oct '11

Hello, Awhile back I was using fusion.reverse_view on a fusion.map sequence (I think it was ~<=1.37 or thereabouts.) In later upgrades this became broken as a bidirectional concept was enforced on the reverse_view (quite sensible.) To work around this I made a minor change to my version which allowed reverse_view to work on both bidirectional sequences and those meeting the is_associative trait. Anyway, it got me wondering if there is a good reason that the map type doesn't model a bidirectional sequence? Cheers, Brandon

2 2

[interprocess] Mixed 32bit/64bit processes shared memory current status
by Pete Bartlett 07 Oct '11

07 Oct '11

I wrote about: >http://lists.boost.org/Archives/boost/2011/02/177696.php >https://svn.boost.org/trac/boost/ticket/5230 What was obvious to the contributors to the above discussion, but dawned on me only slowly, was that mixed bitness shared memory only stands a chance of working if ones uses offset_ptr< void , boost::int64_t , boost::uint64_t > rather than the default offset_ptr< void > (which is possible on current trunk). I've now begun testing this in my own app and it is looking promising so far. Hope this helps someone googling for the same thing. Pete

2 1

[Containers] How about a list with O(1) splice?
by Phil Endecott 07 Oct '11

07 Oct '11

In another thread, Stephan T. Lavavej wrote: > Two-list partial-splice is now linear time. FDIS 23.3.5.5 > [list.ops]/14: "Complexity: Constant time if &x == this; > otherwise, linear time." Is there an opportunity here for Boost.Containers to provide a std::list replacement that keeps the old O(1) splice and O(N) size? I can imagine a lot of demand for this once people discover that their old splicing code is trashed by a std library upgrade... [OT: does anyone know of a list of "C++1x nasties" like this? It's easy to find lists of new features, but harder to find lists of misfeatures...] Regards, Phil.

8 19

[Review] Review results for Lockfree
by Hartmut Kaiser 07 Oct '11

07 Oct '11

All, The review for the Lockfree library written by Tim Blechman started July 18th 2011 and ended on July 28th. I counted 8 votes, none of which were NO. All authors votes YES, some made additional requests. Overall, the verdict of the community was clear: Tim Blechmann's Lockfree library is ACCEPTED The discussion was lively and it touched on several points. Design ------ The design of the library is sound, the API is usable. Except for naming issues (discussed below) almost no comments have been made on how to change it. People reviewing the library would like to see a more modular approach to lockfree data structures in general, possibly by exposing building blocks or by utilizing policies. The general interest was to have a more diverse set of data structures available, such as a lock-free linked list or bounded and fixed-sized data structures. Atomics Library --------------- As the initial review announcement stated, Lockfree depends on an external Atomics library, which has to be separately reviewed in order to get into Boost as a first class library. There has been some discussions whether Lockfree could be accepted without Atomics being reviewed. Others suggested Lockfree may be reviewed and added to Boost SVN only after Atomics got reviewed (this was mentioned in the review announcement as well). After all those discussions and based on the wide interest Lockfree data structures have, I'd suggest to add the current Atomics library as an implementation detail to Lockfree. Special handling of compilers which already have implemented std::atomics would be good if added to Lockfree, though. Naming ------ The consensus was that the naming of the reviewed data structures has to be changed. The names should be either fifo and lifo or queue and stack. AFAIK, Tim already addresses this point. Documentation ------------- The consensus of almost everybody referring to the documentation was that it needs more work. Here is a short (but non-exhaustive) list of things being mentioned: - It lacks rationale and information about the implementation - The class synopsis of the data structures should be accessible from the "Reference" page. - Make non-thread-safe parts more explicit (fifo::empty is described as non-thread-safe) - Document exception guarantees - More information needed on internals, the design, and rationale I would like to thank all who participated in the discussions. Regards Hartmut --------------- http://boost-spirit.com

5 8

[boost.program_options] another constructor for option_description
by Guilherme Maciel Ferreira 07 Oct '11

07 Oct '11

Hi list, Through options_description_easy_init::operator()(const char* name, const char* description), I can create an option_description with just the option name and description, without the value_semantic. However, all option_description class constructors require this value_semantic. Checking the code, I saw that options_description_easy_init uses untyped_value to create an option_description without type. Why not providing a set of constructors consistent with the options_description_easy_init::operator() operators? Kind regards, Guilherme -- Guilherme Maciel Ferreira Gtalk: guigasurf MSN: guigasurf(a)hotmail.com Mobile Brazil: +55 48 9904 3728 e +55 48 9134 4651 Skype: guilherme.maciel.ferreira

1 0

[property_tree] include directive for non-info files
by Ivan Le Lann 07 Oct '11

07 Oct '11

Hi, In Boost.PropertyTree, INFO format has the nice #include directive. But it seems you cannot include other formats. Typically such INFO file, key { #include_xml "my.xml" } with "my.xml" : <root><child>kid</child></root> could give : get<std::string> ("key.root.child") == "kid" A very quick look at info parser makes me think that it would be easy to implement. Any comment ? Regards, Ivan

2 1

[filesystem] New operational function added: canonical()
by Beman Dawes 06 Oct '11

06 Oct '11

A canonical() function has been added at the suggest of David Svoboda from CERT. Boost.Filesystem's class path had such a function at one time, but it was deprecated because it didn't handle symlinks correctly. The new canonical() free function walks the path resolving symlinks, so now works correctly even when symlinks are present. For the curious, David's rationale for the function follows. --Beman Canonicalized pathnames are an important security measure when you want to do validity checking on your path (eg does this path live in /home/goodguy or /home/badguy?). There are several implementations of canonicalization functions, ranging from POSIX's realpath() function, to the GNU library's canonicalize_file_name(). For platform-independent implementations, Java provides the File.getCanonicalFile() method. CERT advocates the use of canonicalized filenames in its Secure Coding rules for both C FIO02-C. Canonicalize path names originating from untrusted sources https://www.securecoding.cert.org/confluence/x/EAY and Java IDS02-J. Canonicalize path names before validating them https://www.securecoding.cert.org/confluence/x/S4EVAQ

1 0

Interest in Boost.Array companion: StaticVector - A statically allocated fixed capacity vector
by Andrew Hundt 06 Oct '11

06 Oct '11

I've implemented a small companion class to boost.array that functions like a stack allocated vector with fixed capacity. The motivation for this class came when I was using boost.array in an interprocess library, when I realized that I actually desired an adjustable size boost.array, without the complexity of the vector class in the interprocess library. The result is StaticVector, which is boost.array directly modified with a size in front of the array, and added facilities to match std::vector. The Implementation is available at: https://github.com/ahundt/Boost.StaticVector Sample Code: StaticVector<std::size_t,3> three; three.push_back(5); three.push_back(2); // size: 2 capacity: 3 three.push_back(3); three.push_back(1); // throws std::out_of_range exception indicating the capacity has been exceeded So here is the big question: Is there any interest in the class? Cheers! Andrew Hundt

7 12

[Review:Algorithms] all.hpp vs std::count
by Andrew Hundt 05 Oct '11

05 Oct '11

What is the advantage of the functions in all.hpp over std::count? I feel like one could simply call (in pseudocode) std::count == 0, std::count == 1, std::count == class.size() to achieve the same effect. Cheers! Andrew Hundt Robotics Engineer National Robotics Engineering Center Carnegie Mellon University 908-720-5501

5 11

[website] URL for most recent version of BoostBook docs?
by Beman Dawes 05 Oct '11

05 Oct '11

http://www.boost.org/doc/libs/1_47_0/doc/html/boostbook.html is the URL for 1.47.0. What URL always points to the most recent version? --Beman

4 4

[functional/hash] integer hash function
by Tim Blechmann 05 Oct '11

05 Oct '11

i was quite amazed that the default hash function for integers seems to be the identity function: from boost/functional/hash/hash.hpp: inline std::size_t hash_value(int v) { return static_cast<std::size_t>(v); } while this is probably the most efficient hash function, it is also the worst possible. is this done intentionally? tim

5 6

[operators] The future
by Daniel Frey 04 Oct '11

04 Oct '11

Hello, I would like to gather some feedback on my plan for the future of the Boost.Operators library. As the maintainer, I have to admit it was a pretty easy job for the last years, as not much has happened. The codebase is full of work-arounds, but it seems to be pretty stable. Another member of the list recently suggested an enhancement, see <https://svn.boost.org/trac/boost/ticket/5929>, which I think shows the first of two points that I would like to straighten out in the future: 1) The library currently mixes two domains, arithmetic operators and iterator helpers 2) No rvalue-support The first point, as already mentioned in the above ticket, could be solved by separating the two parts. I imagine the future Boost.Operators library to concentrate on arithmetic operators, while another, new library could concentrate on iterator and container helpers. Maybe there is an overlap with other libraries (Boost.Iterators), but I'll leave that to others. The (new) Boost.Operators library could provide a base for implementing the iterator helpers just like the current Boost.Operators library does - while there is no dependency in the reversed direction, i.e., the Boost.Operators library does not depend on iterators. The second point is actually a strong argument for a rewrite and a different interface. I have an implementation ready and as it turns out, rvalue-support could be used to optimize some cases *only* if the type itself is commutative. This property of a type is not taken into account in the current Boost.Operators library, which is why the new implementation has different bases, including a new set of grouped operators. See the end of this post for a list of the proposed bases. Note that the new grouped operators are also a consequence of taking commutativity into account, i.e., a field as a commutative_ring+dividable. Dropping some of the old grouped operators should not be a big deal, since grouped operators are more-or-less convenience only, the real functionality is in the "Simple Arithmetic Operators" (see current documentation). If there is a strong need, we could also preserve the old implementation as <boost/legacy/operators.hpp>, but I think it's also practical to drop it completely - old Boost versions are still available for those who need them. To sum up the plan: - Concentrate on arithmetic operators - Add rvalue-support - New set of convenience/grouped operators due to rvalue-support - Drop the old implementation, iterator support Someone else (Olaf?) then takes care of the iterator helpers. So, what do you think? Regards, Daniel ----------------------------- Proposed new base classes: equality_comparable less_than_comparable totally_ordered equivalent partially_ordered addable commutative_addable subtractable subtractable_left multipliable commutative_multipliable dividable dividable_left modable modable_left ring commutative_ring field andable andable_left commutative_andable orable orable_left commutative_orable xorable xorable_left commutative_xorable bitwise bitwise_left commutative_bitwise left_shifttable right_shiftable shiftable incrementable decrementable unit_steppable

10 18

[interprocess] Mixed 32bit/64bit processes shared memory current status
by Pete Bartlett 04 Oct '11

04 Oct '11

Dear Ion and Boost.Interprocessors, I'm very interested in the status of support for using shared memory across processes of mixed bitnesses particularly on Windows. I see from the thread here: http://lists.boost.org/Archives/boost/2011/02/177696.php and the trac here https://svn.boost.org/trac/boost/ticket/5230 that this has been looked at before. The ticket is marked as fixed in 1.47, but I believe the changes are actually only on trunk at the moment? I appreciate Ion saying in that Trac ticket that support is experimental and requires feedback from real-world users. I'd be happy to be such a guinea pig user. But to help me along the way, I have a couple of queries: - with trunk, what features from Boost.Interprocess are intended to work across bitness? (I'd plan to build both the 32-bit and 64-bit with the same version of MSVC). For instance, might interprocess::managed_shared_memory, interprocess::vector and interprocess::basic_string be expected to work? - Is it possible to back port the changes from trunk to 1.47 or 1.46.1? If so what would I need to copy? AlignedStorage, Move and Interprocess? Many thanks for any help on this, Pete Bartlett

1 0

Build trunk 1.46 libraries problems
by Paul A. Bristow 04 Oct '11

04 Oct '11

I've just updated trunk, and note that version.hpp has been updated to 1.46. When I try to link previous tests, I get messages like LINK : fatal error LNK1104: cannot open file 'libboost_test_exec_monitor-vc100-mt-sgd-1_46.lib' But when I try to rebuild the libraries, they are all still *1.45.* :-( my log file is attached. I also note some config failures that suggest something else may be wrong? ...updating 1 target... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_gcc_visibility.obj has_gcc_visibility.cpp libs\math\config\has_gcc_visibility.cpp(7) : fatal error C1189: #error : "This is a GCC specific test case". call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-mul ti\has_gcc_visibility.obj.rsp" ...failed compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_gcc_visibility.obj... ...failed updating 1 target... Performing configuration checks - ../config//has_gcc_visibility builds : no ...found 47 targets... ...updating 1 target... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_long_double_support.obj has_long_double_support.cpp ...updated 1 target... - ../config//has_long_double_support builds : yes ...found 15 targets... ...updating 4 targets... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-multi \has_icu_test.obj has_icu_test.cpp libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti\has_icu_test.obj.rsp" ...failed compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-multi \has_icu_test.obj... ...skipped <pi:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti>has_icu.exe for lack of <pi:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti>has_icu_test.obj... ...failed updating 1 target... I've tried changing boost_root and boost-build environment variables to 1.46 but makes no difference. Suggestions. Thanks. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

4 7

Interest in simple unformatted binary stream I/O?
by Beman Dawes 04 Oct '11

04 Oct '11

There have been many requests on Boost and various C++ newsgroups for unformatted binary I/O. For example, in 2003 Neal Becker wrote: I wonder if anyone has code for implementing unformatted I/O? What I have in mind is for the simple case where the application that reads data knows the data types, so this is not as complicated as the general marshalling situation. This proposal provides a very simple solution that works with standard library input and output streams. The one caveat is that the stream must be opened with filemode std::ios_base::binary to avoid certain data values being treated as line endings. int main() { fstream f("binary_stream_example.dat", std::ios_base::trunc | std::ios_base::in | std::ios_base::out | std::ios_base::binary); int32_t x = 0x01020304; int32_t y = 0; f << bin(x); // write 4 bytes f.seekg(0); f >> bin(y); // read 4 bytes BOOST_ASSERT(x == y); return 0; } For docs, header, and example code, see http://mysite.verizon.net/beman/binary_stream/binary_stream.html http://mysite.verizon.net/beman/binary_stream/binary_stream.hpp http://mysite.verizon.net/beman/binary_stream/binary_stream_example.cpp Is there interest in this for Boost? It seems way too small and simple to be a whole library itself. Are there any ideas where it should live and what namespace it should be in? --Beman

15 26

[accumulator] no type named 'result_type' in 'boost::fusion::void_'
by Vicente J. Botet Escriba 04 Oct '11

04 Oct '11

Hi, I'm getting this error on trunk ../../../boost/accumulators/framework/extractor.hpp:36:74: error: no type named 'result_type' in 'boost::fusion::void_' typedef typename mpl::apply<AccumulatorSet, feature_type>::type::result_type type; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~ I'm including #include <boost/accumulators/framework/accumulator_set.hpp> #include <boost/accumulators/statistics/count.hpp> If I add the following include everything is OK. #include <boost/accumulators/accumulators.hpp> Is this a know issue? Best, Vicente

2 4

[optional] Thoughts on disallowing assignment for wrapped references.
by Mostafa 04 Oct '11

04 Oct '11

Boost.Optional seems to really have a lot of potential for what I want to do, but one thing about it has been nagging me, specifically it's assignment semantics for wrapped references being different from the semantics of bare C++ references (see http://tinyurl.com/4yna643) Has/have the author(s) of the library or anyone considered disallowing assignment for Boost.Optional types that wrap references, and if so, what would the consequences of this entail? I rather disallow assignment in this case, then have what's basically a wrapper class behave partially differently than the type it's supposed to emulate. Thanks in advance, Mostafa

6 34

help with boost::property_tree erasing nested entries please
by Bernd Prager 04 Oct '11

04 Oct '11

All, I would appreciate some help with erasing a nested node entry in property_tree. Below is my example. (2) works, but only erases an entire tree. (1) doesn't but it's really what I want. Thank you for any help. (I'm sorry, the documentation is not very verbose on this topic.) -- Bernd #include <iostream> #include <string> #include <boost/property_tree/ptree.hpp> using namespace std; namespace pt = boost::property_tree; int main(void) { pt::ptree props; props.put("db.name", "Sesame"); props.put("user.name", "Ali Baba"); cout << props.erase("db.name") << " children erased. " << endl; // (1) cout << props.erase("db")<< " children erased. " << endl; // (2) }

2 2

Re: [boost] [Review:Algorithms] My review
by Brent Spillner 04 Oct '11

04 Oct '11

Also late! My apologies. On Mon, 03 Oct 2011 00:46 Phil Endecott wrote: >implementation. Furthermore, the amount of discussion of a proposal >seems to be in inverse proportion to its complexity! To avoid getting ...which probably tells us more about the number of people who take the time to fully understand more complex submissions than it does about anything else... >bogged down in endless discussions of trivia we should set a lower >bound on the complexity of submissions, and these functions are below >that threshold. I disagree... these algorithms are certainly trivial, but also frequently used by most programmers. A high-quality implementation has the potential to eliminate (well, reduce) the need for every C++ programmer to maintain medium-quality versions in a personal toolkit, saving a tremendous number of aggregate man-hours (initial development, maintenance, and reading others' versions as a possible source of defects in unfamiliar code) worldwide. Note that the original submission has already been substantially improved based on reviewer feedback--- how many of the tens of thousands of one-off versions out there have the same issues, or worse? Anyway, my own review: > * What is your evaluation of the design? Overall design is fine--- these algorithms are simple and should be kept so. Like several other reviewers, I believe some of the function and header names are suboptimal (increasing() should be nondecreasing(), any.hpp should be any_of.hpp, etc.), and as much as I abhor a boat shed argument I do honestly believe that they be reevaluated before release. There does seem to be a lot of redundant code that could be refactored out of the individual search algorithms, but that's an internal issue. > * What is your evaluation of the implementation? Adequate. I filed several issues on GitHub, and others contributed more. Marshall has been extremely responsive, and I think it's clear that the library will be top-notch before release. > * What is your evaluation of the documentation? Incomplete, but what library is in version 1? Certainly adequate for release. > * What is your evaluation of the potential usefulness of the library? Quite. Actually, I think the search algorithms are hindered a bit in this respect by their documentation (strengths and weaknesses in given situations, which to use, caveats, etc.), but that's been beaten to death here and on GitHub and is already being remedied by Marshall. > * Did you try to use the library? With what compiler? Did > you have any problems? No. > * How much effort did you put into your evaluation? A glance? > A quick reading? In-depth study? I carefully read the code and skimmed the docs, and logged my detailed comments as GitHub issues (almost all of which have already been addressed.) > * Are you knowledgeable about the problem domain? Fairly, although I'm not sure I'd ever seen the BMH search before. In summary, I think Algorithms should certainly be accepted, and like Phil and many other reviewers I think it's a good framework for other small submissions that would be useful to the community at large but don't justify a separate library.

1 0

where to go to with libraries for a narrow problem domain?
by Thijs (M.A.) van den Berg 03 Oct '11

03 Oct '11

I'm part of a community that work in financial mathematics, and every now and then there are ideas to start library development on narrow sub-fields. A thing missing is a centralized place -exactly like boost- where people can submit and acquire high quality *narrow* C++ source code libraries. There are a lot of fragmented initiatives in mathematical finance: there is overlap between projects, quality may vary a lot, etc. The landscape resembles a bit the pre uBlas era for matrices. It there a place just like boost (good quality C++ source code libs with a large community) for narrow libraries? If not, wouldn't it be possible to create a subsection at boost for narrow libraries? Something like the Matlab toolboxes for C++ source libraries?

3 2

Tokenizer docs: bug?
by Olaf van der Spek 03 Oct '11

03 Oct '11

Hi, > explicit char_separator() Explicit? Doesn't explicit only apply to one argument constructors? > The function std::isspace() is used to identify dropped delimiters and std::ispunct() is used to identify kept delimiters. In addition, empty tokens are dropped. std::string s("[1][3][5][]9"); BOOST_FOREACH(auto i, boost::tokenizer<>(s)) std::cout << i << std::endl; This outputs only numbers. Shouldn't the brackets be included too? Olaf

1 0

[chrono] now() performance on several clocks
by Vicente J. Botet Escriba 03 Oct '11

03 Oct '11

Le 28/09/11 13:29, Vicente J. Botet Escriba a écrit : > Le 28/09/11 13:12, Stewart, Robert a écrit : >> Vicente J. Botet Escriba wrote: >>> Le 27/09/11 17:42, Stewart, Robert a écrit : >>> >>>>> - There's no information on Boost.Timers overhead relative >>>>> to timing the target code. >>>>> >>>> Are you asking for the overhead of the time computations or >>>> the reporting? >>> The former. >>> >>> > I will add some performance tests in Boost.Chrono to measure the time > spent by the now functions and the difference between two time_points > for each one of the clocks, so we can be fixed. > > Hi, I have measured the cost of calling Clock::now for some clocks and platforms. All the test are run with variant=release. The measured code stores on a vector the result of Clock::now() 10000000 times. /// for (int i=size-1; i>=0; --i) { vec[i]=Clock::now(); //vec[i]=typename Clock::time_point(typename Clock::time_point::duration(i)); } /// On iMac 3.06 GHz Inter Core i3. clang2.9 system_clock around 44 nanoseconds. steady_clock/high_resolution_clock around 24 nanoseconds. process_real_cpu_clock more than 600 nanoseconds. process_user_cpu_clock more than 1000 nanoseconds. Currently process_real_cpu_clock uses clock() and process_user_cpu_clock uses times(). On MinGw Windows msvc.10 system_clock around 32 nanoseconds. steady_clock/high_resolution_clock more that 2400 nanoseconds. process_real_cpu_clock around 84 nanoseconds. gcc-4.6 system_clock around 38 nanoseconds. steady_clock/high_resolution_clock more that 2500 nanoseconds. process_real_cpu_clock around 110 nanoseconds. Clearly I need to make more measures for the Windows based steady_clock code. The program is available on the trunk under the libs/chrono/perf directory. Could someone run the program on a posix platform? Please let me know if you think there is a better way to make these measures. Best, Vicente

1 0

[Interprocess] an XSI message queue
by Matthieu Dorier 03 Oct '11

03 Oct '11

Hello, I recently had to work with XSI shared memory objects using Boost, and I noticed that their is no implementation of the message_queue class on top of XSI shared memory objects. So I have created a new file xsi_message_queue.hpp (attached) defining this type of message queue. It is mostly based on the structures and classes defined in message_queue.hpp (in particular the messages, message headers, etc. and the mutex mechanism used in message_queue). It works fine in my project, but should certainly be more extensively tested if you want to integrate it in a future release. I noticed that contrary to other structures of the Interprocess library, message_queue is not very generic: you cannot simply change a template argument to make it work properly with XSI or Windows shared memory objects. Maybe a good step forward to improve it would be to make it more generic. -- Matthieu Dorier ENS Cachan, antenne de Bretagne Département informatique et télécommunication http://perso.eleves.bretagne.ens-cachan.fr/~mdori307/wiki/

1 0

[test] more files missing
by Jürgen Hunold 03 Oct '11

03 Oct '11

Hi Gennadiy, it seems you forgot to add at least the following files to svn: On Monday, 3. October 2011 08:59:48 gennadiy.rozental(a)thomson.com wrote: > +#include <boost/test/tree/observer.hpp> > +#include <boost/test/tree/test_unit.hpp> > +#include <boost/test/tree/visitor.hpp> > +#include <boost/test/tree/traverse.hpp> > +#include <boost/test/tree/test_case_counter.hpp> And btw. could you please update your email on svn.boost.org? Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

2 2

the 'not' keyword
by Lorenzo Caminiti 03 Oct '11

03 Oct '11

Hello all, This might not be a "pure" Boost question but do you know if compilers portably support the 'not' keyword? int main ( ) { if(not false) return 0; return 1; } This compiles on GCC but not on MSVC... Why? If you look at the C++ standard, it says that 'not' is part of the language... Thanks a lot. --Lorenzo -- Sent from my mobile device Lorenzo

7 6

[accumulator] A lot of unused "parameter" warnings
by Vicente J. Botet Escriba 03 Oct '11

03 Oct '11

Hi, I'm getting a lot of warnings while using Boost.Accumulators. Would you accept a patch that resolve them by commenting the parameter name? Best, Vicente In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:12: In file included from ../../../boost/accumulators/framework/accumulator_set.hpp:19: In file included from ../../../boost/parameter/parameters.hpp:45: ../../../boost/parameter/aux_/tagged_argument.hpp:123:60: warning: unused parameter 'x' [-Wunused-parameter] reference operator[](default_<key_type,Default> const& x) const ^ ../../../boost/parameter/aux_/tagged_argument.hpp:129:58: warning: unused parameter 'x' [-Wunused-parameter] reference operator[](lazy_default<key_type,F> const& x) const ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:12: In file included from ../../../boost/accumulators/framework/accumulator_set.hpp:23: In file included from ../../../boost/accumulators/framework/depends_on.hpp:39: In file included from ../../../boost/fusion/include/mpl.hpp:11: In file included from ../../../boost/fusion/mpl.hpp:23: In file included from ../../../boost/fusion/mpl/has_key.hpp:11: ../../../boost/fusion/sequence/intrinsic/has_key.hpp:71:29: warning: unused parameter 'seq' [-Wunused-parameter] has_key(Sequence const& seq) ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:12: In file included from ../../../boost/accumulators/framework/accumulator_set.hpp:29: In file included from ../../../boost/fusion/include/any.hpp:10: In file included from ../../../boost/fusion/algorithm/query/any.hpp:13: ../../../boost/fusion/algorithm/query/detail/any.hpp:112:36: warning: unused parameter 'it' [-Wunused-parameter] static bool call(It const& it, F f) ^ ../../../boost/fusion/algorithm/query/detail/any.hpp:112:42: warning: unused parameter 'f' [-Wunused-parameter] static bool call(It const& it, F f) ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:14: In file included from ../../../boost/accumulators/statistics/sum.hpp:14: ../../../boost/accumulators/numeric/functional.hpp:188:5: warning: unused variable 'plus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(plus, +, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:188:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(plus, +, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:189:5: warning: unused variable 'minus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(minus, -, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:189:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(minus, -, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:190:5: warning: unused variable 'multiplies' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(multiplies, *, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:190:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(multiplies, *, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:191:5: warning: unused variable 'divides' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(divides, /, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:191:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(divides, /, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:192:5: warning: unused variable 'modulus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(modulus, %, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:192:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(modulus, %, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:194:5: warning: unused variable 'greater_equal' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(greater_equal, >=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:194:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(greater_equal, >=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:196:5: warning: unused variable 'less_equal' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(less_equal, <=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:196:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(less_equal, <=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:197:5: warning: unused variable 'equal_to' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(equal_to, ==, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:197:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(equal_to, ==, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:198:5: warning: unused variable 'not_equal_to' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(not_equal_to, !=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:198:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(not_equal_to, !=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:200:5: warning: unused variable 'assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(assign, =, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:200:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(assign, =, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:201:5: warning: unused variable 'plus_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(plus_assign, +=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:201:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(plus_assign, +=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:202:5: warning: unused variable 'minus_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(minus_assign, -=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:202:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(minus_assign, -=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:203:5: warning: unused variable 'multiplies_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(multiplies_assign, *=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:203:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(multiplies_assign, *=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:204:5: warning: unused variable 'divides_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(divides_assign, /=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:204:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(divides_assign, /=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:205:5: warning: unused variable 'modulus_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(modulus_assign, %=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:205:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(modulus_assign, %=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:207:5: warning: unused variable 'unary_plus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(unary_plus, +) ^ ../../../boost/accumulators/numeric/functional.hpp:207:46: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(unary_plus, +) ^ ../../../boost/accumulators/numeric/functional.hpp:208:5: warning: unused variable 'unary_minus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(unary_minus, -) ^ ../../../boost/accumulators/numeric/functional.hpp:208:46: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(unary_minus, -) ^ ../../../boost/accumulators/numeric/functional.hpp:209:5: warning: unused variable 'complement' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(complement, ~) ^ ../../../boost/accumulators/numeric/functional.hpp:209:46: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(complement, ~) ^ ../../../boost/accumulators/numeric/functional.hpp:210:5: warning: unused variable 'logical_not' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(logical_not, !) ^ ../../../boost/accumulators/numeric/functional.hpp:210:46: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(logical_not, !) ^ ../../../boost/accumulators/numeric/functional.hpp:414:28: warning: unused variable 'average' [-Wunused-variable] op::average const &average = boost::detail::pod_singleton<op::average>::instance; ^ ../../../boost/accumulators/numeric/functional.hpp:417:28: warning: unused variable 'as_zero' [-Wunused-variable] op::as_zero const &as_zero = boost::detail::pod_singleton<op::as_zero>::instance; ^ ../../../boost/accumulators/numeric/functional.hpp:418:27: warning: unused variable 'as_one' [-Wunused-variable] op::as_one const &as_one = boost::detail::pod_singleton<op::as_one>::instance; ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:14: In file included from ../../../boost/accumulators/statistics/sum.hpp:16: ../../../boost/accumulators/framework/parameters/weight.hpp:17:1: warning: unused variable 'weight' [-Wunused-variable] BOOST_PARAMETER_KEYWORD(tag, weight) ^ ../../../boost/accumulators/framework/parameters/weight.hpp:17:30: note: instantiated from: BOOST_PARAMETER_KEYWORD(tag, weight) ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:18: In file included from ../../../boost/accumulators/accumulators.hpp:21: ../../../boost/accumulators/framework/parameters/weights.hpp:17:1: warning: unused variable 'weights' [-Wunused-variable] BOOST_PARAMETER_KEYWORD(tag, weights) ^ ../../../boost/accumulators/framework/parameters/weights.hpp:17:30: note: instantiated from: BOOST_PARAMETER_KEYWORD(tag, weights) ^

4 5

[Review:Algorithms]
by Edward Diener 03 Oct '11

03 Oct '11

This is my late review of the Boost Algorithms library. First a minor irritation. I am used to downloading a library in its own directory separate from a Boost tree, and then being able to generate docs and tests by running the bjam files with a line such as: 'bjam --boost=C:/Programming/VersionControl/boost toolset=msvc-10.0' where I point to a Boost tree with the --boost parameter. This works if the bjam root file has the canonical search for BOOST_ROOT given in the sandbox example library's jamroot.jam. It's really simple just to copy over that jamroot.jam into the root directory of the library before distribution, but almost no one seems to do this automatically. So I always have to do it myself. This is a PITA. So I wonder if we can not put on some web page for library developers this simple jamroot.jam and tell developers to use it. * What is your evaluation of the design? Clean and clear. * What is your evaluation of the implementation? I did not look. * What is your evaluation of the documentation? Very good. My only suggestion is that soem sort of extended discussion of advantages and disadvantages of search algorithms would be possible in the docs which would allow an end-user to decide what search algorithm would be optimal for particular practical situations. * What is your evaluation of the potential usefulness of the library? Very useful and very much needed. There is a little overlap with some other Boost libraries as mentioned in Dave Abrahams initial introduction to the library in his post about the start of the review, but I very much like the general nature of the algorithms where other libarries are more specific to their domain. * Did you try to use the library? With what compiler? Did you have any problems? I tried quickly with MSVC-10.0 and gcc-4.6.0, neither with any problems. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A very quick evaluation but a thorough reading. * Are you knowledgeable about the problem domain? Aside from the search algorithms I have used various forms of nearly all the other algorithms in my programming career so I understand what they are about and how useful they can be. I vote for the Boost Algorithms library to be accepted into Boost and I look forward to other general purpose algorithms being added to it in the future. Boost should be leading the way in introducing general purpose algorithms that work on C++ sequences, via range or iterators, given the fact that the C++ standard library changes as slowly as the C++ standard and new algorithms can be quite useful, as these are. Kudos to Marshall Clow for a clean and effective design and keeping the initial algorithms focused on usefulness and end-user simplicity, both of which I value very highly.

2 1

[Review:Algorithms] My review
by Phil Endecott 03 Oct '11

03 Oct '11

Here is my review of the proposed Boost.Algorithm library. A problem with Boost in the past has been that the contributions have primarily been larger projects, while smaller things have not been submitted despite their potential usefulness because of the effort required to prepare and review them (real or perceived). I therefore very much welcome the idea of a library to which smaller contributions can be submitted - though we have yet to find out how such submissions will be processed, and perhaps some discussion of this would be helpful now. (I have an implementation of an edit distance / edit script "diff" algorithm that could probably be contributed.) Regarding the particular algorithms initially included: Search algorithms: These are certainly worth having and the implementations look satisfactory. Jim Xochellis has made some comments about relaxing the iterator requirements and this would be worth doing if possible. Reducing the size of the tables by storing uint8_t for short patterns (especially on 64-bit systems where 7/8 of the space is currently wasted) might be worthwhile, though it could conflict with the idea of relaxing the iterators. Perhaps something can be done with the traits class to make it easier for the user to tweak this, e.g. passing the skip-distance type as a defaulted template parameter to the traits class. Documentation needs to be improved as previously discussed, especially to guide the user to select the correct algorithm. Other algorithms i.e. Ordering & clamping: I have come to the conclusion that these algorithms are too trivial to be included in Boost. Anyone who wants one of these functions can easily implement their own in a "personal utility library" or similar; they are trivial to code and there are no subtle issues or portability problems. The difficulty with putting them in Boost is that there are different possibilities for naming and aspects of the behaviour and there is no one version that will suit everyone - for example, I would not want to use a version of clamp that is three times slower than my preferred implementation. Furthermore, the amount of discussion of a proposal seems to be in inverse proportion to its complexity! To avoid getting bogged down in endless discussions of trivia we should set a lower bound on the complexity of submissions, and these functions are below that threshold. > * What is your evaluation of the design? Straightforward. > * What is your evaluation of the implementation? Satisfactory. > * What is your evaluation of the documentation? Needs some work, but I'm confident this will happen. > * What is your evaluation of the potential usefulness of the library? Search algorithms useful. Other stuff not sufficiently useful. > * Did you try to use the library? With what compiler? Did > you have any problems? I did some simple tests and benchmarks with gcc on ARM Linux. I do recall some "unused argument" warnings that could be suppressed by removing or commenting the arg name. > * How much effort did you put into your evaluation? A glance? > A quick reading? In-depth study? I've read all of the docs and much of the code, written some test / benchmark programs, and taken part in discussions. > * Are you knowledgeable about the problem domain? Not especially. In summary, my opinion is that the library should be accepted in part. Regards, Phil.

2 1

[Review:Algorithms] Boost.Algorithms Review
by Stewart, Robert 02 Oct '11

02 Oct '11

Boost.Algorithms should be accepted into Boost. Many issues have been raised during the review and during the pre-review using Code Collaborator. I have confidence that Marshall will carefully weigh all of the ideas and concerns that have been raised and apply those that are sensible and appropriate. __________ Design I have a problem with the physical design. all.hpp is not the file I'd expect to find any_of or none_of. I'd prefer to see them moved to any.hpp and none.hpp. I realize that none_of must test all elements in a range in the case when no element matches the predicate, but that doesn't make me think of all.hpp as the place to find it. I think "is_ordered_until" is a better name than "is_ordered" for the reasons previously elucidated. As to your dislike of "is_ordered_until", just read it as "the range is ordered until the element referenced by the return value". As there may well be other search algorithms than those you've provided thus far, I think each should be in a separate header and documented separately. Otherwise, search.hpp may grow to be ridiculously large. __________ Implementation I find the naming of your formal parameters to be inconsistent: first, last, p, lo, hi, val, and range. A more consistent set of names would be first, last, predicate, low, high, value, and range. I'd even accept "pred" in that list. Likewise, the template parameter names are inconsistent: InputIterator, Predicate, R, V, Pred, FI, patIter, and corpusIter. A more consistent set of names would be InputIterator, Predicate, Range, Value, ForwardIterator, PatternIterator, CorpusIterator. If you'd prefer to abbreviate "Iterator" with "It" or "Iter", then I'd abbreviate the categories, too: InIt, FwdIt, RandomIt, etc. You presume that all C++ implementations with a specific value of __cplusplus provide std::all_of, std::any_of, and std::none_of. Is that portable? Indentation is inconsistent. The use of mpl::identity for clamp's arguments should be documented for future maintainers. is_ordered() uses a one-line if/return and a two-line for no apparent reason. That inconsistency increases the chances of a maintainer failing to notice one or the other. search.hpp uses BOOST_ALGO_DEBUG. "ALGO" should be spelled out. Many of the functions controlled by that manifest constant use camelcase and should be all lower case. I was expecting more algorithm documentation in search.hpp. The code is not overly complex, but there should at least be pointers to literature on the implementation of each algorithm. However, as such literature may not always be accessible, copying pertinent information to the header would be helpful to future maintainers. __________ Documentation Specific notes and corrections are listed at the end of this message. I'd like to see the complexity, behavioral, and iterator information be documented for each algorithm separately rather than for a group, such as you've done in paragraphs 3 and 4 of all.html. Note that the complexity is described below the clamp algorithms and above the all_of, any_of, and none_of algorithms. This should be consistent. The algorithms are all function templates, so "the function <algorithm-name>" is incorrect. Thus, instead of "the function all_of", write "all_of". Look for other uses of "function" and "functions" for similar terminology issues. While is_increasing, is_decreasing, is_strictly_increasing, and is_strictly_decreasing are implemented using is_ordered, that is by no means a requirement. Consequently, I'd prefer that each was documented separately. Complexities written as should be written in all upper case: O(N), O(M x N), etc. The treatment of the two internal tables used by the search algorithms is inconsistent ("first", "second", "skip", etc.). I'm not even sure they should be mentioned as you do. I realize that you want to document memory usage and customization options, but perhaps the better approach is to clearly document the traits class and its usage as well as the memory usage in terms of the pattern and corpus character sets. For example, K-M-P allocates N bytes per element in the pattern. The Reference section for each algorithm should include "#include <boost/algorithm/foo.hpp>", to permit copying and pasting, plus complexity and template parameter requirements. Template parameters should be documented just as function parameters. Thus, for example, in the reference page for knuth_morris_pratt_search(), there should be a section that describes the two iterator types including their iterator category as well as their relationship (which elsewhere you mention requiring that their value_types be identical). The boyer_moore_search() and boyer_moore_horspool_search() algorithms do not have reference pages. There are no examples in the text. There should be an example for each algorithm. The search algorithms' traits classes are not documented. __________ Usefulness This library, in its current state has certain utility. As a place to incorporate future algorithms that don't deserve a library of their own, it has enormous utility. __________ Usage I did not try to use the library due to time constraints. __________ Effort I spent many hours studying and commenting on the code during the pre-review and now, reading the documentation, etc. __________ Domain Knowledge I have no experience designing string search algorithms. I have used many algorithms. I have designed a good deal of generic code. Thus, I have broad domain knowledge, but nothing extraordinary. __________ Documentation Issues _____ Description and Rationale 2nd para, 3rd sent: missing "and" from "tested, reviewed, documented" _____ Future plans Written with this review in mind, this section is fine, but for an accepted library, it isn't right. I suggest something like this: "This library will be extended by algorithms submitted or suggested by Boost developers and users. The Adobe Source Library (http://stlab.adobe.com/) for example, contains many useful algorithms with documentation and test cases that might be culled for inclusion in this library. Knuth's _The Art of Computer Programming_ is full of algorithm descriptions, too. Various algorithms have been created and documented in magazines, online forums, etc., or even just for personal use. All of these sources, and more, can provide fodder for algorithms to add to this library. "Adding new algorithms will require some form of review, but will not be subject to the usual Boost review process. The Boost.Algorithm maintainer would have the ability to add algorithms without review, but this will not be the case for non-trivial algorithms. Non-trivial algorithms, and possibly even trivial algorithms, will be subjected to a mini-review. This will be a call for Boost developers to study the proposed algorithms with the goal to get more minds to consider their design and utility to ensure their broad utility." _____ Header: 'all.hpp' The heading can just be "all.hpp". 1st para, 1st sent: Strike "The header file". 1st para, 2nd sent: any_of does not verify that every element has a particular property. 2nd para: All three of these algorithms is in C++11. Try this wording: "The iterator-based versions are part of the standard library in C++11 (§25.2 Non-modifying sequence operations). Boost.Algorithms will use the standard library versions of these algorithms when available." 4th para: The algorithms will not work on output iterators. Therefore, you should indicate that they require input iterators. _____ Header: 'clamp.hpp' The heading can just be "clamp.hpp". 1st para, 1st sent: Strike "The header file". The description is insufficient, which you seem to understand since you quoted "clamp". I suggest this instead: "clamp.hpp contains function templates to constrain a value to be within the inclusive range formed from supplied boundary values." 2nd para, bullets: s/iff/if. "iff" is overly proscriptive on the implementation. That is, lo could be returned if v == lo without affecting the result. 3rd para: "also" this sentence refers the previous paragraph, which uses < in the bullets, but this is a bit awkard. It would be better to describe each version of clamp separately. The second would have the same bulleted list, but would use p(v, lo) and p(hi, v). _____ Header: 'ordered.hpp' The heading can just be "ordered.hpp". 1st para, 1st sent: Strike "The header file". Strike the parentheses. 2nd para, 4th sent: Surely is_ordered returns the end iterator for sequences of less than two elements. 3rd para: s/are will not/will not/ 5th para, 1st sent: I'd prefer, "There are also a number of function templates that use is_ordered to determine whether an entire sequence satisfies a particular ordering." _____ Header: 'search.hpp' The heading can just be "search.hpp". ___ Overview 1st para, 1st sent: Strike "The header file". 3rd para: merge with the 2nd para 4th para: Change from first person and quoting to "For each of these search algorithms, the sequence being searched is referred to as the pattern, and the sequence being searched as the corpus." 5th para, 1st sent: Change to "These search algorithms generate tables to make searches faster." 5th para, 3rd sent: s/To help with this/To provide control over the overhead/ 5th para, 3rd sent: s/;/:/ 5th para, 4th sent: s/the search/the search, thereby using the same generated table(s) for multiple searches./ 7th para: s/and here are/and here is/ 8th para, last sent: Must I1::value_type be the same as I2::value_type or must they merely be comparable? ___ Boyer-Moore 1st para: The wording at the end is confusing. I think you mean, "benchmark used in the literature on practical string searching." 2nd para: merge with the 1st para s/target string (pattern) that is being search for/pattern/ s/algorithm, while still...can have/algorithm has O(N) complexity, where N is the corpus length, but can have/ s/algorithms; it doesn't/algorithms because it doesn't/ s/gets faster as the key being search for becomes longer/is faster for longer patterns/ Note: s/skip table (the second one) as stored as an/skip table (the second one); it is stored as a/ s/are (say) UTF-16 text; in that case, the/are UTF-16 text, for example, since the/ s/The B-M and B-M-H objects take a 'traits' template parameter which lets/The traits template parameter of the B-M and B-M-H class templates allow/ s/paramater/parameter/ ___ Boyer-Moore-Horspool 1st para: s/Boyer-Moore, and has/Boyer-Moore, but has/ 2nd para: s/algorithm an internal/algorithm uses an internal/ You should mention that the traits template parameter allows using a different container to store that data so the memory usage can change. Unless this reference is to the "first" table. ___ Knuth-Morris-Pratt 2nd para: s/looking for the match - instead of just at the next entry/looking next for a match rather than just advancing to the next element/ _____ Reference I don't think the all.hpp content should be in reference.html. It should be found by a link like the other three headers. The declarations for all.hpp are compressed too much. Some vertical whitespace would be helpful. Why is "Marshall Clow" in the "Header <boost/algorithm/all.hpp>" section? It also appears in the clamp.hpp reference page. _____ Function template clamp (both) Returns: Could be improved: "lo if p(val, lo) returns true, hi if p(hi, val) returns true, and val otherwise." _____ Header <boost/algorithm/ordered.hpp> The declarations are compressed too much. Some vertical whitespace would be helpful. _____ Function template is_ordered (iterators) Returns: Could be improved: "the iterator it, in the range [first, last), for which p(*it) returns false, or last if there is no such iterator." _____ Function template is_ordered (range) Returns: Could be improved: "the iterator it, in range, for which p(*it) returns false, or boost::end(range) if there is no such iterator." _____ Function template is_increasing (iterators) Returns: "true if each element in [first, last) is greater than or equal to the previous element or [first, last) has fewer than two elements." _____ Function template is_increasing (range) Returns: "true if each element in range is greater than or equal to the previous element or range has fewer than two elements." _____ Function template is_decreasing (iterators) Returns: "true if each element in [first, last) is less than or equal to the previous element or [first, last) has fewer than two elements." _____ Function template is_decreasing (range) Returns: "true if each element in range is less than or equal to the previous element or range has fewer than two elements." _____ Function template is_strictly_increasing (iterators) Returns: "true if each element in [first, last) is greater than the previous element or [first, last) has fewer than two elements." _____ Function template is_strictly_increasing (range) Returns: "true if each element in range is greater than the previous element or range has fewer than two elements." _____ Function template is_strictly_decreasing (iterators) Returns: "true if each element in [first, last) is less than the previous element or [first, last) has fewer than two elements." _____ Function template is_strictly_decreasing (range) Returns: "true if each element in range is less than the previous element or range has fewer than two elements." _____ Header <boost/algorithm/search.hpp> The declarations are compressed too much, though the horizontal whitespace does help in the latter half. Some vertical whitespace would be helpful. _____ Class template boyer_moore The constructor deserves information on memory allocated, what exceptions might be emitted, etc. The function call operator should include information on its behavior, complexity, etc. The private member functions should not be listed. _____ Class template boyer_moore_horspool Ditto _____ Class template knuth_morris_pratt Ditto _____ 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.

4 7

Is someone interested in container CompressedVector, a vector-like storage for integer types
by Alexander Bulovyatov 02 Oct '11

02 Oct '11

Hi! Assume you want an interface as for vector<unsigned int>, but know that elements have only N significant bits, say 17. In this case the container will save 46% memory compared to vector<unsigned int>. CompressedVector internally stores elements as a dynamic bitset (vector<size_t>) and uses bitshift ops to put/get significant bits into one or two size_t elements. It's similar to vector<bool> and dynamic_bitset, and has the same drawback, it's not a proper STL container. Anyway, the container is simple, efficient and quite fast. It will work best for very long arrays of indexes. Since its storage is continuous, it can also be used to speed up IO (load/store to disk, network transfers) acting as a very fast compression.

2 4

metatest interface update, better Boost.Test integration
by Ábel Sinkovics 02 Oct '11

02 Oct '11

Hi, Thank you for the feedback about my library so far. I've done changes to the interface of the metatest library (currently part of mpllibs - https://github.com/sabel83/mpllibs) The purpose of the changes was to improve compatibility with Boost.Test. They make it easy to embed assertions of compile-time predicates in runtime test functions. The result and pretty-printed reason of a compile-time predicate is represented by an object of type test_result (http://abel.web.elte.hu/mpllibs/metatest/test_result.html) at runtime. These objects can be built using a template function, test_result::build. It evaluates the predicate and does the pretty-printing. operator<< is overloaded for test_result, thus one can easily display these objects in output streams. This is useful for passing the results of compile-time tests to runtime unit testing frameworks. I've implemented the metaprogramming equivalent of the BOOST_<level>() macros as template functions (meta_<level>). One can use them the following way: meta_check< equal_to<int_<13>, metafunction_to_test<int, char> > >(MPLLIBS_HERE); meta_warn< equal_to<int_<13>, metafunction_to_test<int, char> > >(MPLLIBS_HERE, "Some message"); // ... I've used a template function instead of a macro to improve the error messages about syntax errors in the predicates. The template function takes a location (http://abel.web.elte.hu/mpllibs/metatest/location.html) object as argument and metatest provides a macro, MPLLIBS_HERE, that constructs a location object with the current filename:line values. The template functions call BOOST_<level>_MESSAGE. A disadvantage of this solution is that the error reports contain two filename:line locations: the location of BOOST_<level>_MESSAGE in the integration function and the location of MPLLIBS_HERE (which is the one the user will be interested in). I've added a new example demonstrating these integration functions. You can find it in libs/metatest/example/boost_test_assertion in the source tree. I've tested the new interface with the same three compilers I've been testing the libraries with (gcc 4.5, clang 2.8, Visual C++ 10). I'm happy to receive feedback about the new interface. I'm interested if people find it useful. Regards, Abel

2 3

[contract] the volatile issue
by Lorenzo Caminiti 01 Oct '11

01 Oct '11

Hello all, N1962 does not indicate that contracts for volatile members should be handled in any special way (in fact, volatile is not discussed at all in N1962). My library does the following for volatile members: 1) The object `this` is const volatile (and not just const) while checking preconditions, postconditions, and invariants for a volatile member. 2) By default, class invariants of volatile members are the same as for non-volatile members. However, programmers can specify a different set of class invariants for volatile and non-volatile members if they wish to do so. The reason for 2) is that when programming a volatile member that overloads a non-volatile member, programmers can already specify a different set of preconditions and postconditions. Therefore, it seemed reasonable to give the option to also specify a different set of class invariants for volatile and non-volatile members (otherwise why would the pre/postcondition of a volatile member be different from the ones of its non-volatile version while the class invariants are forced to remain the same?). For example, consider a very strange number class which is non-negative (>= 0) when used in non-volatile context but it is non-positive (<= 0) when used in volatile context (probably not a real-life example but still...). The contracts could read: #include <contract.hpp> CONTRACT_CLASS( class (num) ) { CONTRACT_CLASS_INVARIANT( get() >= 0, // (1) volatile class( get() <= 0 ) // (2) ) public: CONTRACT_FUNCTION( public void (set) ( int x ) precondition( x >= 0 ) // 3) postcondition( get() == x ) ) { x_ = x; } CONTRACT_FUNCTION( public void (set) ( int x ) volatile precondition( x <= 0 ) // (4) postcondition( get() == x ) ) { x_ = x; } CONTRACT_FUNCTION( public int (get) ( void ) const ) { return x_; } CONTRACT_FUNCTION( public int (get) ( void ) const volatile ) { return x_; } num ( ) : x_(0) {} private: int x_; }; int main ( ) { num p; p.set(3); num volatile v; v.set(-3); return 0; } Note that via function overloading it is automatically possible to specify a different set of preconditions (and eventually postconditions) for the volatile member (4) than for the non-volatile member (5). Therefore, my library also allows to specify a different set of class invariants for volatile members (2) than for non-volatile members (1) so that the entire contract (including class invariants) can be programmed differently for volatile members if programmers wish to do so. However, if `volatile class(...)` is not used (default) the class invariants: CONTRACT_CLASS_INVARIANT( get() >= 0 ) are applied by the library to all members volatile and non-volatile. (In this case, this invariant is compiled in const volatile context iff the class has one or more volatile functions so a volatile verion of get() is only requirement if a volatile version of set() is introduced.) What do you think? Thanks, --Lorenzo

2 2

[Review:Algorithms] My review of Boost.Algorithm
by dpxguard-boost＠yahoo.gr 01 Oct '11

01 Oct '11

Hello list, First of all I have to clarify that I have only studied the three search algorithms and I can only speak about this part of the library. Furthermore my review was by no means exhaustive, I have only emphasized in few things which I had the time to notice. However I have noticed at least two showstoppers, one in documentation of the search algorithms and the other in the design of the KMP algorithm. Hence my vote for now is "no". I personally believe that the search algorithms should not be accepted, unless these issues are addressed, (or unless I am proved wrong of course) although it would be undoubtedly a good idea to have such a library in Boost. Specifically in the design issue of the KMP algorithm I am willing to help if this becomes necessary. A. Documentation issue The three search algorithms of this library does not offer any additional functionality compared to the standard std::search of the STL. On the contrary these algorithms are less generic than std::search. Consequently the only single reason that will make a developer to choose one of them instead of the std::search can be their performance superiority. (In the most notable STL implementations std::search is implemented using straightforward (brute-force) searching.) However in the documentation I have not found anything (no benchmarks, measurements, etc) that would help the user of the library to understand how fast each algorithm is and in which situations it is advisable to use it. (I believe Phil Endecott has mentioned this issue as well) This is especially important because of the following reasons: - Boyer-Moore and Boyer-Moore-Horspool have identical average time complexity, hence it is not easy for the user to choose among them based on their complexities. - Although KMP has much better worst-case complexity than a typical std::search implementation, their average complexities are practically the same. - The straightforward (brute-force) sequence searching is known to frequently outperform some KMP implementations. For all these reasons I believe that some performance analysis and performance guidelines should be added to the documentation, before this library becomes a part of Boost. For example it would be very nice to have a graphical performance comparison of these three algorithms together with the std::search, in different pattern and alphabet sizes. B. Design issue The fact that the KMP implementation of this library requires random-access iterators for both the pattern and the corpus, seems like a major design drawback to me. I also believe that this drawback virtually cripples the usefulness of the algorithm, for reasons I have already mentioned in previous posts. Best regards Jim Xochellis Homepage: https://sites.google.com/site/xochellis/

2 1

[timer] Boost Timer Library Version 2
by Beman Dawes 30 Sep '11

30 Sep '11

Version 2 of Boost.Timer is about ready to move to trunk. The original version 1 timers are deprecated, but not changed in any way. Besides deciding to keep the version 2 timers in Boost.Timer, many suggestions and corrections from the "Boost.Timer replacement" thread have been applied. See http://lists.boost.org/Archives/boost/2011/09/185820.php The docs can be viewed at http://beman.github.com/timer/ The code is available at https://github.com/Beman/timer Thanks to all who posted comments, corrections, and suggestions in response to the original posting. Special thanks to Rob Stewart - many of his suggestions have been incorporated - and to Vicente Botet for his work on Boost.Chrono which now is used to implement much higher resolution for wall-clock time. While additional comments are always welcome, unless someone comes up with a showstopper I'm planning to move Version 2 to trunk and get on with other projects. --Beman

3 15

Re: [boost] property tree find no match for 'operator=='
by Ivan Le Lann 30 Sep '11

30 Sep '11

----- "Bernd Prager" <bernd(a)prager.ws> a écrit : > All, > > This is likely to be a silly question. > I am trying to check for the existence of a value in a property tree. > > Reading the docs I assumed the easiest way would be: > > namespace pt = boost::property_tree; > static pt::ptree pt; > > bool has(const std::string key) { > if (pt.find(key) == pt.end()) return false; // (1) > return true; > } > > The compiler complains about "error: no match for 'operator=='" in > line > (1) though. > What am I missing? > For your problem, the two iterators are not of the same type. Don't know the exact reason, but I know that ptree uses multi_index. Might be related. Anyway : - you have a get_optional() method. - you can try replacing end() with not_found() Regards, Ivan

1 0

property tree find no match for 'operator=='
by Bernd Prager 30 Sep '11

30 Sep '11

All, This is likely to be a silly question. I am trying to check for the existence of a value in a property tree. Reading the docs I assumed the easiest way would be: namespace pt = boost::property_tree; static pt::ptree pt; bool has(const std::string key) { if (pt.find(key) == pt.end()) return false; // (1) return true; } The compiler complains about "error: no match for 'operator=='" in line (1) though. What am I missing? Thank you for any help, -- Bernd

2 1

[Review:Algorithms] My review of Boost.Algorithm
by Lorenzo Caminiti 30 Sep '11

30 Sep '11

Review of Boost.Algorithm 2011-09-29 - Lorenzo Caminiti ============================== Do you think the library should be accepted as a Boost library? ------------------------------ Yes, in my opinion Boost.Alrogithm should be accepted as a Boost library. Key points are: a) I would find the library usefull as is, especially for all_of_equal and for the search algorithms. b) I would like to see more algorithms supported into the library in the (near) future (IMO the "only" non-trivial algorithms currently offered are the 3 search algorithms). c) The documentation (which is clear and straightforward) should list more examples. My comments below are all numbered an marked as: [MUST] If these comments are not addressed, I would no longer recommend this library for addition to Boost. [WANT] I would like to see these comments addressed (at least replied to) but I would recommend this library for addition to Boost regardless. [NOTE] I do not feel strongly about these comments and they can be ignored. What is your evaluation of the design? ------------------------------ 1) [WANT] Could all/any/none/one_of_equal be made more general and merged with all/any/none/one_of by accepting a binary predicate via overloading? template<typename InputIterator, typename UnaryPred> bool all_of ( InputIterator first, InputIterator last, Pred p ); template<typename InputIterator, typename BinaryPred, typename V> bool all_of ( InputIterator first, InputIterator last, BinaryPred p, V const& v ); // could even overload for ternary, etc predicates bool BOOST_LOCAL_FUNCTION_PARAMS(int x) { return x > 0; } BOOST_LOCAL_FUNCTION_NAME(positive) int a[3] = {2, 2, 2}; all_of(a, a + 3, positive); // existing form all_of(a, a + 3, std::equal_to<int>(), 2); // instead of all_of_equal all_of(a, a + 3, std::less<int>(), 10); // can also do this now :) not just equal BTW, you can use Boost.Local to define the predicate functions at local scope ;) 2) [NOTE] Is there a (run-time) cost with the destruction of the tables used by Boyer-Moore and the other search algorithms? If so, is the same cost encountered by both the object and functional version of the algorithms? (BTW, it made sense to me to have both an object and function version of the algorithms.) 3) [MUST] There should be a range version for all search algorithms (unless it's not possible for some reason that I can't foresee). 4) [WANT] When using the object interface, is the caller responsible to keep the pattern in scope until the search object is destructed? Either way, this requirement should be clearly documented. 5) [NOTE] I'd be OK with any renaming of is_order based on other's opinions-- I'd follow C++11 if at all possible (is_sorted_until?). (No comment on clamp's argument ordering ;) .) What is your evaluation of the implementation? ------------------------------ 6) I very quickly read through the code. It looks clean and well organized... the iterator algorithms made sense. I did not study the search algorithm implementation close enough to comment on it. What is your evaluation of the documentation? ------------------------------ 7) [WANT] Please add more examples to the docs (you can take a few from the ones you already have in examples and tests). 8) [WANT] Always state complexity guarantees (they are mentioned in docs section but not in the code reference section). 9) [WANT] Are these examples from the docs incorrect? (What's 3, 9, etc?) one_of ( c.begin (), c.end (), 3 ) --> true one_of ( c, 3 ) --> true none_of ( c, 9 ) --> true any_of ( c.begin (), c.end (), 9 ) --> false 10) [WANT] Typos that I noted in the docs: * "are will" in "Since they have to return a place in the input sequence, input iterators are will not suffice". * check indentation of close `};` for `class boyer_moore`. * "and here are the corresponding procedural interface:" should say and "here is". 11) [WANT] Extend document of Boyer-Moore-Horspool and/or Knuth-Morris-Pratt with class code, etc to match docs of Boyer-Moore (interface is listed in the code reference section but not in the search algorithm section). What is your evaluation of the potential usefulness of the library? ------------------------------ 12) I would find the library useful as is (especially, for the handy all_of_equal and faster searches) but I would like to see more algorithms supported by the library in the near future. IMO, any/none/one/all and clamp are nice utilities, same goes for the ordered stuff, but at the end I got the sense that the search algorithms were the "only" real meat of the library. Did you try to use the library? With what compiler? Did you have any problem? ------------------------------ 13) Yes, I compiled all examples and tests on GCC 4.3.4 under Cygwin (BTW, in all_example.cpp rename all_of_val to all_of_equal). I got some warnings on MVSC 10 under Windows (see attached file). How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ------------------------------ 14) I'd say a quick reading, I spent about 7 hours on it. I red all the docs and compiled all the examples (at least on GCC). Are you knowledgeable about the problem domain? ------------------------------ 15) Thankfully, not anymore ;) but reading the docs reminded of my class work on Boyer-Moore and variations-- it was a while ago. I'd say I am marginally familiar with the problem domain. --Lorenzo

3 3

[Review:Algorithms]
by Riccardo Marcangelo 30 Sep '11

30 Sep '11

Hi Marshall Firstly, I think the documentation is quite good. I like that there is a description of what each algorithm does, its return type and complexity. Maybe one example of each algorithm would be a nice addition. I think one_of complements the C++11 algorithms all_of, any_of and none_of well. is_increasing, is_strictly_increasing, is_decreasing and is_strictly_decreasing are useful, especially for statistical ranges. These are rolled fairly often so this is a welcome addition. is_ordered() seems to be similar to the C++11 algorithm is_sorted_until() with a comparison function. For consistency I would recommend using the behaviour of is_sorted_until() and renaming the function to is_sorted_until(). If this change were made I think there would also be a strong case for including the C++11 algorithm is_sorted(). I'm a bit sceptical on passing the arguments to clamp() by value, except for the predicate. I think (actually I'm totally convinced for myself) that clamp() should be overloaded, one version passing the arguments by const reference and the other passing the arguments by reference. Otherwise it's doing unnecessary copying in some cases. If V is large the overhead of the unneeded copies could be a lot. Another reason to not pass the arguments by value is that comparing objects should not raise any exceptions but copying usually can. The return types for the two overloaded versions would be "const V &" and "V &" respectively. Sadly, I was unable to use the search algorithms, boyer_moore_search(),boyer_moore_horspool_search() and knuth_morris_pratt_search(). All failed with a "string iterators incompatible" error during runtime using Visual C++ 2010. At first I thought it was my usage but the examples provided also had this problem. Overall, I like the library and vote "yes" for it to be included into Boost although I hope the issues I raised can be addressed. Kind regards Riccardo P.S Sorry if I haven't followed the protocol properly with this review, I'm fairly new to the Boost mailing list. -- View this message in context: http://boost.2283326.n4.nabble.com/Review-Algorithms-tp3859590p3859590.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[Boost][Asio] Linker error when compiling serialization example
by jamesa 30 Sep '11

30 Sep '11

I receive a 2019 linker error when attempting to compile the asio serialization example: error LNK2019: unresolved external symbol "public: void __thiscall connection::async_read<class std::vector<struct stock,class std::allocator<struct stock> >,class boost::_bi::bind_t<void,class boost::_mfi::mf1<void,class networkConnection,class boost::system::error_code const &>,class boost::_bi::list2<class boost::_bi::value<class networkConnection *>,struct boost::arg<1> > > >(class std::vector<struct stock,class std::allocator<struct stock> > &,class boost::_bi::bind_t<void,class boost::_mfi::mf1<void,class networkConnection,class boost::system::error_code const &>,class boost::_bi::list2<class boost::_bi::value<class networkConnection *>,struct boost::arg<1> > >)" (??$async_read@V?$vector@Ustock@@V?$allocator@Ustock@@@std@@@std@@V?$bind_t@XV?$mf1@XVnetworkConnection@@ABVerror_code@system@boost@@@_mfi@boost@@V?$list2@V?$value@PAVnetworkConnection@@@_bi@boost@@U?$arg@$00@3@@_bi@3@@_bi@boost@@@connection@@QAEXAAV?$vector@Ustock@@V?$allocator@Ustock@@@std@@@std@@V?$bind_t@XV?$mf1@XVnetworkConnection@@ABVerror_code@system@boost@@@_mfi@boost@@V?$list2@V?$value@PAVnetworkConnection@@@_bi@boost@@U?$arg@$00@3@@_bi@3@@_bi@boost@@@Z) referenced in function "public: void __thiscall networkConnection::handle_connect(class boost::system::error_code const &,class boost::asio::ip::basic_resolver_iterator<class boost::asio::ip::tcp>)" (?handle_connect@networkConnection@@QAEXABVerror_code@system@boost@@V?$basic_resolver_iterator@Vtcp@ip@asio@boost@@@ip@asio@4@@Z) The client class from the example has been renamed to network connection and all the references corrected in the code, the client and stock files have not been changed and I'm still getting this error. Can anyone give me some insight has to what exactly I'm doing wrong here? using: Windows 7 64 bit Microsoft visual studio 2008 boost Ver. 1.47 -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Asio-Linker-error-when-compiling-s… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] to_string(v)
by Olaf van der Spek 30 Sep '11

30 Sep '11

Some time ago (2002) there was talk about a to_string function. Did this ever materialize? http://lists.boost.org/Archives/boost/2002/01/23585.php "to_string(5)" is a lot shorter than "lexical_cast<std::string>(5)". Likewise for "to_int("5")". Greetings, Olaf

3 5

[type_traits] copy constructor
by Lorenzo Caminiti 30 Sep '11

30 Sep '11

Hello all, What's the most portable way to detect if a type T is CopyConstructible? Actually, I would need a metafunction that is true_ iff a type T has a const-correct copy construct: T::T( T const& other) { /* copy this T from the other T */ } (I've been looking at boost::has_trivial_copy and boost::has_nothrow_copy but I wanted to double check with the ML.) Thanks a lot. --Lorenzo

4 6

Would Unicomm be interesting for Boost?
by Dmtitry Timoshenko 30 Sep '11

30 Sep '11

Hello, I finished developing the communication library based on STL, Boost. The communcation is implemented by using Boost.Asio. The library is engine that allows to build any network protocols based on TCP transport. Unicomm hides communication details and makes focus on business logic. I read the requirements for the library submission. The Unicomm is close to them. But there is still some work to make it possible it to join Boost. please, see http://libunicomm.org for details. (Smart library is also mine). So, before I start final preparations, I have the question. Would the library be interesting for Boost and compatible to it's concepts? Regards, Dmitry.

4 5

[algorithm] a unified (but unreadable?) alternative
by Lorenzo Caminiti 30 Sep '11

30 Sep '11

Hello all, I just sent my review of Boost.Algorithm. I am sending this email separately because these are just some ideas for "fun" which should not clutter the actual review of the library. I was wondering if it could be possible/useful to combine all the any/all/one/none_of and any/all/one/none_of functions into 1 single overloaded check function. Plus and minuses: - C++11 already uses all/any/none_of - Can't really read the check() code better... + I can pass any predicate, not just equal. + I can check for any count of elements that match the predicate not just for any, all, one, or none (but also for 10, etc). For example: #include <functional> #include <iostream> template< typename InIter, typename UnaryPred > // any bool check ( InIter first, InIter last, UnaryPred p ) { std::clog << "unary check count any" << std::endl; for(InIter i = first; i != last; ++i) if(p(*i)) return true; return false; } template< typename InIter, typename UnaryPred > // none/one/all/etc bool check ( unsigned count, InIter first, InIter last, UnaryPred p ) { std::clog << "unary check count " << count << std::endl; unsigned c = 0; for(InIter i = first; i != last; ++i) { if(p(*i)) c++; if(count) return false; } return c == count; } template< typename InIter, typename BinaryPred, typename V > // any bool check ( InIter first, InIter last, BinaryPred p, V const& v ) { std::clog << "binary check count any" << std::endl; for(InIter i = first; i != last; ++i) if(p(*i, v)) return true; return false; } template< typename InIter, typename BinaryPred, typename V > // none/one/all/etc bool check ( unsigned count, InIter first, InIter last, BinaryPred p, V const& v ) { std::clog << "binary check count " << count << std::endl; unsigned c = 0; for(InIter i = first; i != last; ++i) { if(p(*i, v)) c++; if(count) return false; } return c == count; } // could implement predicate ternary, etc bool less10 ( unsigned x ) { return x < 10; } int main ( ) { int a[3] = { 1, 2, 3}; int o[3] = {12, 2, 35}; int y[3] = { 1, 2, 35}; int n[3] = {10, 20, 30}; // unary predicate std::cout << check(y, y + 3, less10) << std::endl; // any std::cout << check(0, n, n + 3, less10) << std::endl; // none std::cout << check(1, o, o + 3, less10) << std::endl; // one std::cout << check(3, a, a + 3, less10) << std::endl; // all // binary predicate std::cout << check(0, a, a + 3, std::equal_to<unsigned>(), 22) // none_equal << std::endl; }; I think I can't easily understand what check() is supposed to do here... while any/one/none/all are more readable... Just some ideas :) --Lorenzo

1 0

Re: [boost] Problem static linking with boost.thread during cross-compilation
by Victor Leschuk 29 Sep '11

29 Sep '11

https://svn.boost.org/trac/boost/ticket/5964 On Wed, Sep 28, 2011 at 3:43 PM, Victor Leschuk <vleschuk(a)gmail.com> wrote: > Hello all, > > I have just met the following problem: I am cross-compiling boost 1.47 > using > > $ x86_64-w64-mingw32-g++ --version > > x86_64-w64-mingw32-g++ (GCC) 4.5.4 20110822 (prerelease) > > On Linux box with the following command: > > ./b2 -a toolset=gcc target-os=windows threading=multi threadapi=pthread > runtime-link=static --layout=versioned --build-type=complete install > > user-config.jam contains the following: > > using gcc : mingw : x86_64-w64-mingw32-g++ ; > > > After that a linkage failed when building my project. I reproduced it with > simple test program: > > #include <boost/thread.hpp> > #include <iostream> > > using namespace std; > > struct test > { > void operator()() { cout << "Called" << endl; } > }; > > int main() > { > test test_obj; > boost::thread thr(test_obj); > thr.join(); > } > > The output looks like > > $ x86_64-w64-mingw32-g++ -Wall test_boost.cpp -I ./3rdparty/boost/include/boost-1_47 -L ./3rdparty/boost/lib -lboost_thread-mgw-mt-s-1_47 -o test_boost.exe > In file included from ./3rdparty/boost/include/boost-1_47/boost/thread/win32/thread_data.hpp:12:0, > from ./3rdparty/boost/include/boost-1_47/boost/thread/thread.hpp:15, > from ./3rdparty/boost/include/boost-1_47/boost/thread.hpp:13, > from test_boost.cpp:2: > ./3rdparty/boost/include/boost-1_47/boost/thread/win32/thread_heap_alloc.hpp:59:40: warning: inline function ‘void* boost::detail::allocate_raw_heap_memory(unsigned int)’ declared as dllimport: attribute ignored > ./3rdparty/boost/include/boost-1_47/boost/thread/win32/thread_heap_alloc.hpp:69:39: warning: inline function ‘void boost::detail::free_raw_heap_memory(void*)’ declared as dllimport: attribute ignored > /tmp/ccSmsBnO.o:test_boost.cpp:(.text+0xde): undefined reference to `__imp__ZN5boost6thread4joinEv' > /tmp/ccSmsBnO.o:test_boost.cpp:(.text+0xfb): undefined reference to `__imp__ZN5boost6threadD1Ev' > /tmp/ccSmsBnO.o:test_boost.cpp:(.text+0x1c3): undefined reference to `__imp__ZN5boost6threadD1Ev' > /tmp/ccSmsBnO.o:test_boost.cpp:(.text$_ZN5boost6threadC1I4testEET_NS_10disable_ifINS_14is_convertibleIRS3_NS_6detail13thread_move_tIS3_EEEEPNS0_5dummyEE4typeE[boost::thread::thread<test>(test, boost::disable_if<boost::is_convertible<test&, boost::detail::thread_move_t<test> >, boost::thread::dummy*>::type)]+0xd5): undefined reference to `__imp__ZN5boost6thread12start_threadEv' > collect2: ld returned 1 exit status > > The same scenario works fine when linking with dynamic libboost_thread. > Both static and dynamic builds work fine for Linux. > > What could be the cause of the problem and where to look? Does it worse > posting a defect in bug-tracker? > > Thanks! > -- > Victor > > > > > >

1 0

Reminder: Algorithms library review ends Saturday
by Dave Abrahams 29 Sep '11

29 Sep '11

The official end date of the review of the proposed Boost.Algorithms is this coming Saturday, October 1st. Please submit your review by then, and please vote on its acceptance! Thanks, Dave ,----[ Important Notes ] | - Please do not post your review or discussion as a reply to this ...<schnipp 1>... | message. | - Please begin your review's subject line with "[Review:Algorithms]" | - Please feel free to note any individual issues in the GitHub issue | tracker and make reference to them from your review. | - Please see below for *further* important notes `---- You can find the library at https://github.com/mclow/Boost.Algorithm. If you don't want to use Git, you can get a .zip or tarball snapshot at https://github.com/mclow/Boost.Algorithm/archives/master Description =========== The Boost Algorithms library is a work in progress; it is not meant to be a complete set of general purpose algorithms for C++ programming; but rather a small collection of useful algorithms, and a structure for adding more over time. The algorithms here fall into three basic categories: 1. Searching - Boyer-Moore Search - Boyer-Moore-Horspool Search - Knuth-Morris-Pratt search 2. Sequence properties - Tests to see if a sequence is ordered - Tests for the elements of a sequence 3. Miscellaneous - Constrain a value between two 'boundaries' (minmax) Potential Interactions with Existing Boost Libraries ==================================================== This submission potentially interacts with all of the following existing Boost libraries: * foreach - http://boost.org/libs/foreach * minmax - http://boost.org/libs/algorithm/minmax * range - http://boost.org/libs/range * string_algo - http://boost.org/libs/algorithm/string_algo Reviewers should consider these potential interactions. What to include in Review Comments ================================== - Keep your criticism constructive. Constructive criticism usually comes with specific suggestions for improvement. - If you identify problems along the way, please note if they are minor, serious, or showstoppers. - Please *do* vote on whether the library should be accepted. Everyone who takes the time to look at the library is qualified to vote, and every vote is valuable. - Other questions you might want to answer in your review: * 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? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

[contract] extra type requirements for contracts
by lcaminiti 29 Sep '11

29 Sep '11

Hello all, Andrzej and I have been discussing off-line the following issue: How to program contract assertions without adding extra type requirements. I would like to get Boosters' input on possible solutions for this problem. THE PROBLEM Consider the following contract for vector::push_back: CONTRACT_CLASS( template( typename T ) class (myvector) ) { ... CONTRACT_FUNCTION_TPL( public void (push_back) ( (const T&) value ) precondition( size() < max_size(), ) postcondition( auto old_size = CONTRACT_OLDOF size(), auto old_capacity = CONTRACT_OLDOF capacity(), back() == value, // (1) size() == old_size + 1, capacity() >= old_capacity, ) ) ; }; Postcondition (1) introduces the extra requirement EqualityComparable<T>. This is not ideal because this requirement is only needed to check the contract but not to implement the push_back functionality (body). For example: struct pod {}; // not EqualityComparable std::vector<pod> v; v.push_back(pod()); // ok, does not require EqualityComparable<pod> myvector<pod> w; w.push_back(pod()); // complier-error, can't find operator== for type pod... Because of postcondition (1), myvector cannot be used on pod while the std::vector can! This is a general issue with contracts. In general, an arbitrary complex (const) expression can be used to assert preconditions, postconditions, or invariants. Such a complex assertion might introduce an arbitray set of extra requirements on the types used, requirements that might not be necessary to implement the function body. The extra type requirements introduced by the contracts are especially problematic when programming templates because the used types are generic and it is not know a priori to the function programmer if the generic types will or not satisfy the requirements. POSSIBLE SOLUTIONS A possible solution is to specify the type requirements that a given assertion introduces. If the type requirements are met, the assertion will be compiled and checked at run-time. If the type requirements are not met, the assertion will not be compiled (so not compiler-error "missing operator== for type ...") and not checked at run-time for that specific type. For example: CONTRACT_FUNCTION_TPL( // Option 1 public void (push_back) ( (const T&) value ) precondition( size() < max_size(), requires has_less<size_type>::value ) postcondition( auto old_size = CONTRACT_OLDOF size(), requires const_copy_constructor<size_type>::value auto old_capacity = CONTRACT_OLDOF capacity(), requires const_copy_constructor<size_type>::value back() == value, requires has_equal_to<T>::value // assertion type requirements size() == old_size + 1, requires has_equal_to<size_type>::value && has_plus<size_type>::value capacity() >= old_capacity, requires has_greater_equal<size_type>::value ) ) ; Here I have specified assertion type requirements using `requires` for each assertion. However, size_type is known a priori to be essentially an unsigned int for which all these type requirements will always be met so the type requirements on size_type could have been omitted. That said, you can easily imagine an example for a different template class or function where size_type is also a generic type for which const copy constructor, +, ==, etc might not always be available. Another option would be would be to specify the type requirements for precondition/postcondition instead than for each assertion: CONTRACT_FUNCTION_TPL( // Option 2. public void (push_back) ( (const T&) value ) precondition( size() < max_size(), ) requires has_less<size_type>::value // pre/postcondition type requirements postcondition( auto old_size = CONTRACT_OLDOF size(), auto old_capacity = CONTRACT_OLDOF capacity(), back() == value, size() == old_size + 1, capacity() >= old_capacity, ) requires const_copy_constructor<size_type>::value && has_equal_to<T>::value && has_plus<size_type>::value && has_greater_equal<size_type>::value ) ; Options 2 is less verbose and it does not specify the same type requirements multiple time for the different assertions. However, I prefer Option 1 because if T is not equality comparable, only the postcondition `back() == value` is not checked but all the other postconditions are still checked. With Option 2 if one type requirement is not met, then all preconditions/postconditions are not checked causing more bugs to go unobserved. If the re-use of the preprocessor "keyword" `requires` was found confusing because of its different semantics when used with concepts, a different preprocessor "keyword" like `unless` could be used instead: CONTRACT_FUNCTION( // Option 3 template( typename InIter1, typename InIter2, typename OutIter, typename BinOp ) requires( boost::InputIterator<InIter1>, boost::InputIterator<InIter2>, typename CONTRACT_IDENTITY_TYPE(( boost::OutputIterator<OutIter, typename boost::InputIterator<InIter1>::value_type > )), typename CONTRACT_IDENTITY_TYPE(( boost::BinaryFunction<BinOp, typename boost::InputIterator<InIter1>::value_type, typename boost::InputIterator<InIter1>::value_type, typename boost::InputIterator<InIter2>::value_type> )) ) (OutIter) (mytransform) ( (InIter1) first1, (InIter1) last1, (InIter2) first2, (OutIter) result, (BinOp) op ) precondition( contract::trivial::range(first1, last1).valid() ) postcondition( auto return_value = return, return_value == result, unless !has_equal_to<T>::value // use unless ) ) { return std::transform(first1, last1, first2, result, op); } Reflections: a) All these solutions require extensive type traits support to write the contract type requirements (I cannot use concepts because they greedily generate compiler-errors when they are not met). However, I see no way around this: I must be able to check the type requirements (extensively using type traits) in order to disable the assertion compilation and their run-time check. b) All these solutions leave the assertions in the contracts so the contract code retains its self-documentation value even then the assertion checking is disabled because the type requirements are not met. c) N1962, Eiffel, D, A++, and all other Contract Programming references that I have seen do not address the issue of the extra type requirements. I am not sure why... Eiffel has generic types but you can always compare them for equality, for non Void, etc. d) In practice, this might not be a big deal because most of the times old-of is applied to counters (int) and postconditions are the ones introducing the extra requirement but only of EqualityComparable. However, in general I think I need to provide a solution for this issue. What do you think? Thanks a lot! --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-contract-extra-type-requirements-f… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 12

Re: [boost] [Review:Algorithms] Comments about search algorithms
by dpxguard-boost＠yahoo.gr 29 Sep '11

29 Sep '11

> Phil Endecott wrote: > > - A user faced with these three (or four) algorithms will need to > > choose one. The docs should offer some guidance, e.g. benchmarks or > > rules-of-thumb, about which to use. > In particular, I've not yet found a case where KMP is the best choice. > BM seems better in all the cases that I've tried and has the same or > better complexity bounds. (Well, it might perform slightly better when > the pattern length is 1 but in that case, std::find could be used.) > Does anyone know of any cases where KMP is likely to be better than > BM? (If we can't find any, is it worth including it?) I will try to give a complete answer... The most notable (and common) techniques for improving the sequence searching performance are the bad-character shift (occurrence shift) and the good-suffix shift (matching shift). The Boyer-Moore algorithm implements both these techniques, while the Boyer-Moore-Horspool only implements the bad-character shift and the KMP is merely based on the good-suffix shift. (Although the Boost.algorithm documentation only states that Horspool "is a refinement of the Boyer-Moore algorithm that trades space for time", this is by no means the most notable difference between these two algorithms.) In general, bad-character shift performs very good when the search-pattern is relatively small and the alphabet relatively large. On the other hand, good-suffix shift helps more when the pattern is relatively large and the alphabet small. In the most common cases of text searching, the patterns are usually small and the alphabets large, (> 255) hence the KMP (which is only using good-suffix shift) will almost never outperform BM in usual text-searching situations. (Note that KMP has not been used in the original std::search implementation of the STL, because even the straightforward (brute-force) algorithm has been considered to be superior in the average case!) The only practical case that I could think of, where the KMP could possibly outperform the BM are the DNA searches, where the patterns can be very long and the alphabet has only four characters. And even then, I would recommend careful performance testing, in order to ensure that KMP can be significantly faster than BM. However, in my opinion the most interesting and useful property of the KMP algorithm is not its performance, but its ability to help in building very generic sequence searching algorithms. In fact KMP has helped me to build an efficient generic sequence searching algorithm, which actually works with ranges accessed by single-pass (input) iterators. (See http://www.codeproject.com/KB/stl/single_pass_search.aspx and also in boost-vault/Algorithms) Needless to say that I would be more than happy to submit this work to boost, whenever there is an interest. Best regards Jim Xochellis Homepage: https://sites.google.com/site/xochellis/

3 7

[threads] Problem static linking with boost.thread during cross-compilation
by Victor Leschuk 29 Sep '11

29 Sep '11

Hello all, I have just met the following problem: I am cross-compiling boost 1.47 using $ x86_64-w64-mingw32-g++ --version x86_64-w64-mingw32-g++ (GCC) 4.5.4 20110822 (prerelease) On Linux box with the following command: ./b2 -a toolset=gcc target-os=windows threading=multi threadapi=pthread runtime-link=static --layout=versioned --build-type=complete install user-config.jam contains the following: using gcc : mingw : x86_64-w64-mingw32-g++ ; After that a linkage failed when building my project. I reproduced it with simple test program: #include <boost/thread.hpp> #include <iostream> using namespace std; struct test { void operator()() { cout << "Called" << endl; } }; int main() { test test_obj; boost::thread thr(test_obj); thr.join(); } The output looks like $ x86_64-w64-mingw32-g++ -Wall test_boost.cpp -I ./3rdparty/boost/include/boost-1_47 -L ./3rdparty/boost/lib -lboost_thread-mgw-mt-s-1_47 -o test_boost.exe In file included from ./3rdparty/boost/include/boost-1_47/boost/thread/win32/thread_data.hpp:12:0, from ./3rdparty/boost/include/boost-1_47/boost/thread/thread.hpp:15, from ./3rdparty/boost/include/boost-1_47/boost/thread.hpp:13, from test_boost.cpp:2: ./3rdparty/boost/include/boost-1_47/boost/thread/win32/thread_heap_alloc.hpp:59:40: warning: inline function ‘void* boost::detail::allocate_raw_heap_memory(unsigned int)’ declared as dllimport: attribute ignored ./3rdparty/boost/include/boost-1_47/boost/thread/win32/thread_heap_alloc.hpp:69:39: warning: inline function ‘void boost::detail::free_raw_heap_memory(void*)’ declared as dllimport: attribute ignored /tmp/ccSmsBnO.o:test_boost.cpp:(.text+0xde): undefined reference to `__imp__ZN5boost6thread4joinEv' /tmp/ccSmsBnO.o:test_boost.cpp:(.text+0xfb): undefined reference to `__imp__ZN5boost6threadD1Ev' /tmp/ccSmsBnO.o:test_boost.cpp:(.text+0x1c3): undefined reference to `__imp__ZN5boost6threadD1Ev' /tmp/ccSmsBnO.o:test_boost.cpp:(.text$_ZN5boost6threadC1I4testEET_NS_10disable_ifINS_14is_convertibleIRS3_NS_6detail13thread_move_tIS3_EEEEPNS0_5dummyEE4typeE[boost::thread::thread<test>(test, boost::disable_if<boost::is_convertible<test&, boost::detail::thread_move_t<test> >, boost::thread::dummy*>::type)]+0xd5): undefined reference to `__imp__ZN5boost6thread12start_threadEv' collect2: ld returned 1 exit status The same scenario works fine when linking with dynamic libboost_thread. Both static and dynamic builds work fine for Linux. What could be the cause of the problem and where to look? Does it worse posting a defect in bug-tracker? Thanks! -- Victor

2 3

Re: [boost] Gauging interest in patch submissions
by Hongli Lai 29 Sep '11

29 Sep '11

GMan wrote: > My only concern with this is in a case like this, for example: > > while (/* reading lines from file, parsing integers, otherwise ignoring*/) > { > try > { > myInts.push_back(boost::lexical_cast<int>(currentLineStr)); > } > catch (const boost::bad_lexical_cast&) // (has stack trace) > {} > } > > Will the stack trace make such an operation noticeably slower? I know it's > easy to retort with "don't use exceptions for flow control" but I believe my > concern is valid, even if it's a bit contrived of a situation. > > Perhaps we'd like to make it opt-in, like BOOST_THROW_EXCEPTION_TRACED or > something. I don't know what one considers "noticeably slower", but there will be overhead for sure. In our implementation, the creation of a tracable_exception object copies the current stack trace into itself. This may or may not be large depending on how many stack traces are defined. We've done our best to optimize our implementation but it's still an O(n) operation. There is one concern that I have with BOOST_THROW_EXCEPTION_TRACED. Will it affect the ABI? Suppose I compile against a Boost library that's installed on the system, and it was compiled without BOOST_THROW_EXCEPTION_TRACED. If I define BOOST_THROW_EXCEPTION_TRACED now will this change the exception hierarchy, and thus, the ABI? - Hongli -- Phusion | Ruby & Rails deployment, scaling and tuning solutions Web: http://www.phusion.nl/ E-mail: info(a)phusion.nl Chamber of commerce no: 08173483 (The Netherlands)

1 1

[any] new version
by Martin Bidlingmaier 28 Sep '11

28 Sep '11

Hi, I've written a new version of boost::any. It does not depend on rtti and uses a static integer value instead of std::type_info to store type information. My version passed the unit tests included in boost 1_47_0 on vc++2010 express and gcc 4.5.(mingw) . With this mail, I'm sending the source and a small quick-and-dirty benchmark. On gcc, moving and copying performance seems to be roughly the same, any_cast however is about 400% faster. On msvc++, moving and copying times rise by ca. 50%, while any_cast is about 50.000% faster (although I guess the speed boost measured in a real benchmark would be in the order of magnitude of the gcc speed up). I would appreciate if somebody measured the performance with proper tools and tested it on more platforms. Sincerely, Martin Bidlingmaier -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

26 87

[Review:Algorithms]
by Thorsten Ottosen 28 Sep '11

28 Sep '11

Hi Marshall, Some minor comments based on reading the docs only. A. xxx_of_val should be named xxx_of_equal or something IMO, or the name should simply be overloaded. B. Documentation for clamb: I dislike the "iff". Just say "if", because this doesn't clash with the case v==lo/hi. Use the names low/high or lower_bound/upper_bound. The "High point" terminology may be replaced with "upper bound" IMO. C. (ordered) I think the cannonical way is to use range_iterator<const R> instead of range_const_iterator<R> D. write #include <boost/algorithm/search.hpp> instead of Header 'search.hpp' (and similar for other names) in the documentation. E. A small code example on each page would be nice. F. Why is there no range-based versions of Boyer-Moore etc.? G. You could consider to present the iterator version and the range version of all algorithms on the same page. H. I couldn't fine any details about detail::BM_traits<>. Do I need to know about these? That's it. I think this is a useful, minor addition to Boost. I vote "yes" for inclusion. regards Thorsten

6 8

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

27 Sep '11

> I think option B (current) is still better than option A because A requires > (1) more parenthesis and (2) the extra assertion word spelled out all the > times but A doesn't require the trailing `,` which is a plus. > Do you have a strong opinion about which one is better between A and B? I'd > say B is better but I'm quite biased at this point ;) Hi Lorenzo, Since you ask about personal preference, I think mine is option A. I can think of the following reasons: * Given the fairly complicated syntax for Boost.Concepts, option A appears to me to add more structure to the declaration, and makes parsing it easier. Especially that I imagine you could further simplify it: instead: var(auto old_size = CONTRACT_OLDOF size()) could be: var( old_size = CONTRACT_OLDOF size() ) * Since you put each assertion (or declaration) in a separate line anyway option B appears also elegant, but if someone starts putting multiple assertions in the same line, I think option A would be clearer. Compare: postcondition( x - 1 == y + 2, y - 1 == z + 2 ) postcondition( assert(x - 1 == y + 2) assert(y - 1 == z + 2) ) * If anyone writes a tool for generating documentation from Contracts, I think parsing would be easier with option A. * In option A, it is easier to tell assertions from declarations, I can easily count how many things are asserted * I suspect that you can use commas more freely inside assertion(), which reduces the necessity of using "identity" function workaround. But I could hardly call it a strong opinion. It is just my preference, and I will like Boost.Contract with either syntax. Regards, &rzej

1 0

[Review:Algorithms] Order of args to clamp
by Phil Endecott 27 Sep '11

27 Sep '11

Dear All, Some quick comments about the proposed clamp() function: template<typename V> V clamp ( V val, V lo, V hi ); I have a clamp function that orders the args low - middle - high, which seems like a more natural ordering to me. Is there some rationale or precedent for this middle - low - high ordering? I think the confusion matters in this case because type checking won't help to detect mistakes, and in the most obvious applications (e.g. sanitising input) it might be hard to spot an error. (In contrast, max(low,min(mid,high)) is unambiguous and not much more typing...) I note that this function takes its args by value, while std::min & max take const references. What is the rationale for this? Like min & max, clamp has a single type template parameter; what are the implications of this? For example, if I pass a mixture of std::string and const char* arguments, what will happen? Ideally, (a) all combinations would compile, and (b) conversions from const char* to std::string will only happen when necessary, not unconditionally for all of the arguments. (Maybe that is asking too much, though.) Regards, Phil.

17 91

[signals1/2] Alternative approach
by Sebastian Karlsson 27 Sep '11

27 Sep '11

A while back we evaluated signals 1 & 2 and came to the conclusion that the performance is to poor for it to be viable for our use. I have an idea which nets very close to the same invocation performance as std::vector< boost::function< > > ( an extra shared_ptr<> per ), with the caveat that ordering within a priority group is unspecified. Another downside compared to the implementation used now is that it needs extra bookkeeping per distinct priority group ( although from the docs for signals1 it would seem it does the same ). The gist of it is that we maintain a vector< > ( preferably we let the storage be parameterized ) in addition to a separate map for the priority groups. The map is keyed on the priority type, and the bookkeeping is: vector offset, group length & shift. Offset & length gives us the region in the vector. Shift tells us how much the group is shifted from its start offset since it was created. So each area is maintained as a sort of sliding window meets circular buffer. With this information we need touch no more than the either the last or first element ( depending on connect / disconnect ) of the groups with a lower priority than the one the element belongs to. Our vector contains a std::pair< function< signature >, shared_ptr< unsigned int > >, the unsigned int is used both as a cookie for the signals::connection to make sure that the connection is still valid, as well as a shared offset in regards to the shift of the group. The arithmetic is very light weight and shouldn't pose a bottleneck. Although I haven't implemented blocking & consistent disconnect / connect behavior during invocation yet I'm fairly certain they can be done in the following way: For blocking we can either use an additional bool which we branch on when invoking, or we can simply let the connection temporarily remove itself from the vector and insert itself once it's not blocking anymore, second solution probably preferred. Disconnect / connect during invocation is a trickier one. The way I'm thinking is to let the signal maintain the iterator as a member. When we disconnect / connect we can see if it equals end ( we're not invoking ), or if it doesn't then we know both the position as well as we're in the middle of an invocation. This way we can let the disconnect / connect logic modify the "cursor" in order to make sure that we get the desired behavior while not polluting our invocation loop. Pros: More cache friendly Very close to ideal case for invocation Cons: Using std::vector<> as a base naturally means we'll suffer from the usual growth caveats. However, if this matters the user could use a paged container with a decent growth strategy and come extremely close to the ideal case anyway. Thread safety within an invocation seems like it might be costly to implement, especially for vector<>. Slower connect / disconnect. All in all I think it's a big win for what I personally believe to be the most common usage of the signals library. I've attached a proof of concept along with a fairly primitive benchmark. There's a fragmented list version which can be enabled by a def, but it's naturally slow as hell to setup so it's disabled by default. The fragmented versions does not use exactly the same random sequence as the others, but hopefully it's somewhat fair. The vector variants somewhat "cheats" in that they reserve the space straight up, this is something which I personally feel should be exposed in the interface in someway anyway however. Here's some results: i5-2500k @ 3.3 ghz, decent mem etc: Using numConnections = 100000 numCalls = 100 numGroups = 200 rndSeed = 0 fragSpread = 10 Generating random sequence takes: 0.002 seconds Connecting to unfrag list:< function<> >: 0.008 seconds Connecting to vector< function<> >: 0.007 seconds Connecting to unfrag signals2< function<> >: 0.051 seconds Connecting to unfrag signals1< function<> >: 0.166 seconds Connecting to test::signals< function<> >: 1.38 seconds ... ... ... vector< function<> > invocation: 0.026 signals< function<> > unfragmented invocation: 1.632 signals2< function<> >unfragmented invocation: 1.404 list< function<> > unfragmented invocation: 0.03 test::signals< function<> > invocation: 0.023 signals< function<> > fragmented invocation: 9.97 signal2< function<> > fragmented invocation: 15.04 PS3 @ PPU ( Power PC ): Using numConnections = 100000 numCalls = 100 numGroups = 200 rndSeed = 0 fragSpread = 10 Generating random sequence takes: 0.001942 seconds Connecting to unfrag list:< function<> >: 0.060645 seconds Connecting to vector< function<> >: 0.034558 seconds Connecting to unfrag signals2< function<> >: 0.367024 seconds Connecting to unfrag signals1< function<> >: 2.02785 seconds Connecting to test::signals< function<> >: 10.0817 seconds ... ... ... vector< function<> > invocation: 0.695916 signals< function<> > unfragmented invocation: 5.91057 signals2< function<> >unfragmented invocation: 4.90188 list< function<> > unfragmented invocation: 1.03532 test::signals< function<> > invocation: 0.952999 signals< function<> > fragmented invocation: 33.4202 signal2< function<> > fragmented invocation: 47.0125

1 1

Rationale for shared_ptr/array including both ptr to control and ptr to data in class
by Olaf van der Spek 27 Sep '11

27 Sep '11

Hi, I was wondering why shared_ptr/array include both a ptr to the control block and a ptr to the data (ptr) in the class itself. I assume it's for performance reasons, but I didn't find anything about that in the docs. Greetings, Olaf

7 13

[Review:Algorithms] - Small review
by Christian Holmquist 26 Sep '11

26 Sep '11

Hi Marshall and others, I vote Yes to accept the library. Comments follows as I've encountered them in the documentation. - Description and rationale- "Boost.Algorithm is a collection of general purpose algorithms. While Boost contains many libraries of data structures, there is no single library for general purpose algorithms" boost/algorithm has existed for a while, but only the algorithm/string is properly documented (I think). Will boost/algorithm/minmax.hpp boost/algorithm/minmax_element.hpp be incorporated in the documentation? - Future plans- "My goal is to run regular algorithm reviews, similar to the Boost library review process, but with smaller chunks of code." Maybe a short summary on how a submission should work? Email subject tags etc, and what is required by the programmer (docs, code and tests). Since the library is at git (great!), maybe proposals could be done as push requests, or submitters share a link to their github repo or so. Having even a rough outline on the process would be better than none at all :) Do you intend to maintain the library at git? * I think the style linking to the algorithm sections from the main page is not optimal (i.e. Header: 'all.hpp' ). Maybe <Suggestion> Algorithms All Clamp Ordered Search </Suggestion> will read easier. - Reference section * Complexity is missing on each algorithm's page. * I would like if the page for each algorithm contains a small example like in the SGI's STL docs. They can be very trivial, but to me they are always reassuring that I've understood the docs correctly. Example assert(boost::clamp(0, 1, 2) == 1); * Every algorithm in the ordered section, has their iterator typename spelled FI. It would read easier as ForwardIterator. Dito for R -> Range. - General - Is it necessary to have both Range and free Iterator support? all.hpp use #pragma mark, probably not portable. (indeed, MSVC 2005 complains..) all.hpp could use std::begin() if available from std, unless there's a specific reason to always use the Boost version (?) search.hpp checks for a macro B_ALGO_DEBUG. It should read BOOST_ALGORITHM_DEBUG or similar to avoid name clashes. *** What is your evaluation of the design? Straight forward. Only worries a bit on the Range vs Iterator interfaces. It's probably impossible to satisfy everyone without providing both interfaces as has been done though. *** What is your evaluation of the implementation? Looks good to me. Well commented code with easy to read style. I can't comment on the correctness of the search.hpp algorithms though, but the tests are not passing here. *** What is your evaluation of the documentation? Everything needed is in the package, but the examples needs to be linked into the docs. *** What is your evaluation of the potential usefulness of the library? Immediately useful. good potential to evolve further. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 2.5 hours reading the docs, reading the code, running some examples and some of the tests. * Are you knowledgeable about the problem domain? Somewhat. *** Did you try to use the library? With what compiler? Did you have any problems? Visual Studio 2005 with native std (Dinkumware), Windows XP 64, 32 bit target, boost 1.46. All examples starting with int main ( int /*argc*/, char */*argv*/ [] ) { gives a warning on this compiler. search_example.cpp: d:\code\tests\tests\clamp.cpp(23) : warning C4138: '*/' found outside of comment int main ( int /*argc*/, char */*argv*/ [] ) { ^--------------------- add space here between * and / to make MSVC happy. d:\code\boost.algorithm\boost\algorithm\search.hpp(238) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data There are few similar warnings, the warning log is about 75 lines so would be good to get rid of. Running search_example.cpp in debug mode gives assertion failure in MSVC's Debug iterator code. I've not investigated further, all_example.cpp d:\code\tests\tests\clamp.cpp(23) : warning C4138: '*/' found outside of comment warning C4068: unknown pragma clamp_example.cpp error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'std::string' (or there is no acceptable conversion) #include <string> fixes this search_test1.cpp Running 1 test case... Pattern is 8, haysstack is 37 chars long; unknown location(0): fatal error in "test_main_caller( argc, argv )": c:\program files (x86)\microsoft visual studio 8\v c\include\xstring(111) : Assertion failed: string iterator not dereferencable In Release mode, the output is Running 1 test case... Pattern is 8, haysstack is 37 chars long; unknown location(0): fatal error in "test_main_caller( argc, argv )": Invalid parameter detected by C runtime library .\clamp.cpp(71): last checkpoint *** 1 failure detected in test suite "Test Program" d:\code\tests\tests\clamp.cpp(71): last checkpoint *** 1 failure detected in test suite "Test Program" All tests pass except those related to search.hpp. I should point out that I just copied the source from each test into a toy visual studio project, but I've not had any troubles with that before. Sorry for a bit unorganized output of the tests, will take some time this evening to sort it out. Thanks to Marshall and Dave for the library and for managing the review - Christian

2 1

[property_tree] Primitive types for data not supported?
by Boris Schaeling 26 Sep '11

26 Sep '11

I just noticed that Boost.PropertyTree doesn't support primitive types for data (Boost 1.47.0). For example, this doesn't compile: boost::property_tree::basic_ptree<std::string, int> pt, pt2; pt.swap(pt2); The reason is this code in <http://svn.boost.org/svn/boost/trunk/boost/property_tree/detail/ptree_imple…>: template<class K, class D, class C> inline void basic_ptree<K, D, C>::swap(basic_ptree<K, D, C> &rhs) { m_data.swap(rhs.m_data); // Void pointers, no ADL necessary std::swap(m_children, rhs.m_children); } Primitive types like int obviously don't have a member function swap(). Is this an oversight or are primitive types intentionally not supported? Boris

2 2

[Review:Algorithms] Comments about search algorithms
by Phil Endecott 26 Sep '11

26 Sep '11

Dear All, Here are some observations about the proposed search algorithms: - I was confused as to whether the caller must keep the pattern pointed to by the iterators passed to the constructor after the constructor returns. My guess was that once the internal tables were built the pattern would not be needed any more - but that turns out to be wrong. At the least, the docs need to explain this. - The three algorithms have very similar interfaces. The docs could perhaps define a "searcher" concept and explicitly declare these algorithms' classes to be models of that concept. - std::search is similar to the three algorithms' free function versions (congratulations on getting the arguments in the same order!). For completeness, how about adding a searcher class that uses std::search? - A user faced with these three (or four) algorithms will need to choose one. The docs should offer some guidance, e.g. benchmarks or rules-of-thumb, about which to use. - It would sometimes be useful to have a variant of the constructor that takes a const char* pattern. - The tables store ints. For patterns shorter than 256 characters I think that uint8_t would be sufficient, and would reduce the size of a table from 1024 or 2048 bytes to only 256 bytes. Similarly uint16_t or uint32_t could be used for larger patterns. It is not obvious how to implement this, though; perhaps an optional max_pattern_length template parameter, making it the user's responsibility to ensure the supplied pattern is not too long. - The docs describe some methods that are private to the implementation; why? Regards, Phil.

3 5

Introduction : Being a Newbie to the Boost community
by avishek banerjee 26 Sep '11

26 Sep '11

Hi everyone, I am Avishek Banerjee.. I work as a software engineer at Google.. I graduated last year from college. I am quite passionate about coding in c++, but never got the chance earlier to be a community developer. I guess, thats why I am here. I want to be a part of this community and make contributions to the libraries.. I would be keeping track of the posts to see if I can associate myself on some existing project. Besides, it would really help if someone can give me certain pointers on some project(not so immediately important) that I can take up as starter to begin with and familiarize. thank you so much, Avishek -- Avishek Banerjee, Software Engineer, Google-BLR

2 1

Re: [boost] Persistency library
by Lifshitz, Yair 26 Sep '11

26 Sep '11

Message: 10 Date: Sun, 25 Sep 2011 22:53:12 +0200 From: Oliver Kowalke <oliver.kowalke(a)gmx.de> To: boost(a)lists.boost.org Subject: Re: [boost] Persistency library Message-ID: <4E7F94B8.7030706(a)gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > I assume resuming from a checkpoint would also require to restore the > registers, flags, stack (pointer), instruction pointer etc. - I'd like > to know if your lib supports only intel or some other architectures too. > > Oliver Your assumption is correct. However, the actual implementation is done via getcontext()/setcontext(), so it is not hard-wired to a specific hardware architecture. We use assembly only in one case, and that is to avoid a glibc issue. PID is being cached in user-space and therefore isn't correct after restore, and glibc does not provide a simple way to invalidate this. Right now, the library has only been validated on x86-64, but I can of course validate it on other architectures (given the right hardware :)). Yair --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 5

Re: [boost] Persistency library
by Lifshitz, Yair 26 Sep '11

26 Sep '11

Date: Sat, 24 Sep 2011 14:29:44 -0400 From: Dave Abrahams <dave(a)boostpro.com> To: boost(a)lists.boost.org Subject: Re: [boost] Persistency library Message-ID: <m2litdrdyf.fsf(a)pluto.luannocracy.com> Content-Type: text/plain on Sat Sep 24 2011, "Lifshitz, Yair" <yair.lifshitz-AT-intel.com> wrote: > > Hi, > > > > Object-based persistency/serialization libraries often require > > significant modifications to the code. Would Boost consider adding a > > process-level checkpointing library to boost? > > > > This is obviously not easily portable, so I understand this is a long shot. > > If it is relevant, we might contribute a package used by my team that > > support multiple Linux platforms. > Can it, in principle, be ported to other known platforms? Yes, it can be ported. However, the porting requires low-level understanding of the target OS/architecture. While our Linux solution is rather portable, porting can (in theory) be non-trivial and require more than just recompilation on another platform. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 1

configuring the clang toolset
by Eric Niebler 25 Sep '11

25 Sep '11

I'm trying to get bjam and clang to play nice. I have Ubuntu linux running in an VM with boost trunk and the llvm+clang sources also from svn. I've built clang as described here: <http://clang.llvm.org/get_started.html>. I added the following line to my user-config.jam: using clang : : /home/eric/build/Debug+Asserts/bin/clang++ ; Now when I try to build, say, the Foreach tests, I get: In file included from cstr_byref.cpp:11: In file included from ../../../boost/test/minimal.hpp:37: In file included from ../../../boost/test/impl/execution_monitor.ipp:170: In file included from /usr/include/errno.h:36: In file included from /usr/include/bits/errno.h:25: /usr/include/linux/errno.h:4:10: fatal error: 'asm/errno.h' file not found #include <asm/errno.h> ^ 1 error generated. "/home/eric/build/Debug+Asserts/bin/clang++" -c -x c++ -O0 -g -fno-inline -Wall -g -fPIC -DBOOST_ALL_NO_LIB=1 -I"../../.." -o "../../../bin.v2/libs/foreach/test/cstr_byref.test/clang-linux-3.0/debug/cstr_byref.o" "cstr_byref.cpp" What have I done wrong? -- Eric Niebler BoostPro Computing http://www.boostpro.com

6 6

Re: [boost] Persistency library
by Lifshitz, Yair 25 Sep '11

25 Sep '11

From: Edward Diener <eldiener(a)tropicsoft.com> > On 9/24/2011 10:31 AM, Lifshitz, Yair wrote: > > Hi, > > > > Object-based persistency/serialization libraries often require significant modifications to the code. > > Would Boost consider adding a process-level checkpointing library to boost? > Why not explain what you mean by a "process-level checkpointing library" > and then others can comment if they might find it useful ? Process-level checkpointing is an approach where an entire process' memory image is dumped in binary format. The checkpointing library does not require any understanding of the saved application - it works by traversing the entire memory image and directly dumping that to disk. On Linux for example, this can be done by traversing all memory segments described in /proc/self/maps. This approach is highly robust, and generally considered good for very large applications where serialization is a challenge. Some examples can be seen here - http://checkpointing.org/ - though we had little luck with most of them when starting to work on persistency (~6 years ago). --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 1

Re: [boost] [Review:Algorithms] About a static clamp function
by Ahmed Charles 25 Sep '11

25 Sep '11

C++11 constexpr would handle the function case while also working for user defined types. This suggests that the template version is less generic. My phone doesn't allow bottom posting. :( From: Vicente J. Botet Escriba Sent: Sunday, September 25, 2011 7:13 AM To: boost(a)lists.boost.org Subject: [boost] [Review:Algorithms] About a static clamp function Hi, Sometimes the bound values are know at compile time. Could we ensure that the compiler could optimize the following code auto res = clamp(val, 1, 100); If this is not the case, I was wondering if it is worth adding a static clamp function that has its bounds defined as template parameters. auto res = static_clamp<1,100>(val); Best, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[Review:Algorithms] About a static clamp function
by Vicente J. Botet Escriba 25 Sep '11

25 Sep '11

Hi, Sometimes the bound values are know at compile time. Could we ensure that the compiler could optimize the following code auto res = clamp(val, 1, 100); If this is not the case, I was wondering if it is worth adding a static clamp function that has its bounds defined as template parameters. auto res = static_clamp<1,100>(val); Best, Vicente

1 0

[system] Boost.Timer replacement
by Beman Dawes 25 Sep '11

25 Sep '11

"The best is the enemy of the good." Voltaire's famous bon mot applies to a replacement for Boost.Timer. I've had a "good", although not "best", replacement ready since circa 2006. It has always been set aside waiting for something better. The data-time, std::chrono, boost::chrono, boost::stopwatch, and probably others, were all candidates. I'm tired of waiting. http://beman.github.com/timer/ documents a useful replacement for Boost.Timer. The full library has been in the sandbox for years, but current development is on GitHub. See https://github.com/Beman/timer I'd like to move the header into boost/system/pending or boost/system/detail, and the rest into the appropriate libs/system subdirectories. The library will be proposed for a full review, or a mini-review if enough other Boost libraries start using it. If Endian gets accepted, for example, it certainly needs timing benchmarks. Comments? --Beman

7 13

[preprocessor] PP_CAT with symbols
by lcaminiti 25 Sep '11

25 Sep '11

Hello all, I just want to confirm that the following: BOOST_PP_CAT(old_size =, =) correctly (and always) expands to: old_size == I tested it on MSVC and GCC and it works. Plus from GCC documentation says about ##: Usually both will be identifiers, or one will be an identifier and the other a preprocessing number. When pasted, they make a longer identifier. This isn't the only valid case. It is also possible to concatenate two numbers (or a number and a name, such as 1.5 and e3) into a number. Also, multi-character operators such as += can be formed by token pasting. http://gcc.gnu.org/onlinedocs/gcc-3.2.3/cpp/Concatenation.html I am asking because ## has some limitation (x ## = is not valid, etc) so I want to confirm my understanding is correct. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-preprocessor-PP-CAT-with-symbols-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

Overload resolution speed
by Mathias Gaunard 25 Sep '11

25 Sep '11

As part of the Boost.SIMD effort, another library was developed, Boost.Dispatch, which relies heavily on overload resolution. Before submitting this library for review, however, I did some compile-time benchmarking, and it's not looking very good. I'm therefore asking the Boost community if 1) this is expected, 2) if there is a workaround to this problem and 3) if compilers should be made to deal with this better. Boost.Dispatch essentially overloads a single free function, with, as arguments, a tag identifying the function followed by tags identifying properties/categories of the arguments (in an attempt to make a transparent tag dispatching system). The scripts from the link below [1] (the shell script is POSIX/GCC-only but should be easily adaptable) performs two tests: - Resolving a call with 1,000 function tags, overloaded 10 times each, everything implemented by overloading the same function as described above, - Resolving a call with 1,000 function tags, overloaded 10 times each, but with each function tag using a different functon. It takes 30s in the first case, 160ms in the second one. Unfortunately, the second solution is very restrictive and doesn't play very nice with generic programming. C++ apparently lacks a mechanism to define overloadable free functions with template parameters in their name. Back to the benchmark, making the number of functions vary show an apparent exponential increase in compile time. It's reasonably fast for 100 functions, but not at all for 1,000. On the other hand, changing the depth of the inheritance tree used for the category tags doesn't seem to affect it much. Any suggestions? [1] http://dl.dropbox.com/u/26902324/dispatching_bench.tar.gz

6 14

Persistency library
by Lifshitz, Yair 24 Sep '11

24 Sep '11

Hi, Object-based persistency/serialization libraries often require significant modifications to the code. Would Boost consider adding a process-level checkpointing library to boost? This is obviously not easily portable, so I understand this is a long shot. If it is relevant, we might contribute a package used by my team that support multiple Linux platforms. Thanks, Yair --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

3 2

Re: [boost] [Review:Algorithms] is_ordered name
by Brent Spillner 24 Sep '11

24 Sep '11

On Sat, 24 Sep 2011 09:34:59 joaquin wrote: >>Isn't this the same as the C++11 is_sorted_until? > >Yes! C+11 had is_sorted_until and is_sorted (equivalent to is_sorted_until(first,last)==last). I think the names here should be the same for >consistency reasons, and probably the functions should be just aliases to the c++11 ones where applicable. With the RV convention change that I proposed on github (always point before the first element that is out-of-order with respect to its predecessor, rather than the first that is out-of-order with respect to its successor), it would be exactly the same, so I think we may be stuck with this name, even though I agree that it sounds like it should return a bool. If we were starting from scratch my first impulse would be end_of_ordered_prefix(), but that too seems wordier than the ideal.

5 8

XInt library primality test
by Jorge Lodos Vigil 24 Sep '11

24 Sep '11

Hi The recently reviewed (and rejected) XInt library includes prime number functionality. To evaluate primality it uses Miller-Rabin test iterating 5 times. For "small" primes this is way insufficient, while for "large" primes it is more than needed. This last case have an important speed impact for numbers with more than 1024 bits . In its current state the library cannot correctly evaluate primality for numbers with less than 400 bits. You may consult "Damgaard, Landrock, Pomerance: Average case error estimates for the strong probable prime test. Math. Comp. 61 (1993)". Additionally, it seems that efficiency may be gained using boost/math/special_functions/prime.hpp instead of calculating the first 2000 primes. If there will be any further work on this library I'm willing to provide patches and tests. Thank you. Best regards Jorge

2 3

[Review:Algorithms] is_ordered behaviour for singleton input, and name
by Phil Endecott 24 Sep '11

24 Sep '11

Dear All, The docs for the proposed is_ordered say: The function is_ordered(sequence, predicate) returns the point in the sequence where the predicate does not hold. It does that by comparing adjacent pairs of elements in the sequence to see if the predicate is satisfied. If all adjacent pairs satisfy the predicate, then it will return one past the last element of the sequence. OK. If the sequence has less than two elements, it returns the last element of the sequence. In other words, sequences of length zero and one are considered to be ordered - using any possible criteria. Shouldn't that say "it returns one past the last element"? Also, regarding the name: I would expect any "is_something" function to return a boolean. Since this returns an iterator I would have called it something like find_disorder. (There is a good chance that an iterator is convertible to bool, so one could mistakenly write "if (is_ordered(begin,end)) { ... }".) Regards, Phil.

7 10

Boost.Algorithms Review Begins today
by Dave Abrahams 24 Sep '11

24 Sep '11

The review period for the proposed Boost.Algorithms library, by Marshall Clow, begins today (September 22) and runs through Oct 1. I'm pleased to act as review manager. ,----[ Important Notes ] | - Please do not post your review or discussion as a reply to this | message. | - Please begin your review's subject line with "[Review:Algorithms]" | - Please feel free to note any individual issues in the GitHub issue | tracker and make reference to them from your review. | - Please see below for *further* important notes `---- You can find the library at https://github.com/mclow/Boost.Algorithm. If you don't want to use Git, you can get a .zip or tarball snapshot at https://github.com/mclow/Boost.Algorithm/archives/master Description =========== The Boost Algorithms library is a work in progress; it is not meant to be a complete set of general purpose algorithms for C++ programming; but rather a small collection of useful algorithms, and a structure for adding more over time. The algorithms here fall into three basic categories: 1. Searching - Boyer-Moore Search - Boyer-Moore-Horspool Search - Knuth-Morris-Pratt search 2. Sequence properties - Tests to see if a sequence is ordered - Tests for the elements of a sequence 3. Miscellaneous - Constrain a value between two 'boundaries' (minmax) Potential Interactions with Existing Boost Libraries ==================================================== This submission potentially interacts with all of the following existing Boost libraries: * foreach - http://boost.org/libs/foreach * minmax - http://boost.org/libs/algorithm/minmax * range - http://boost.org/libs/range * string_algo - http://boost.org/libs/algorithm/string_algo Reviewers should consider these potential interactions. What to include in Review Comments ================================== - Keep your criticism constructive. Constructive criticism usually comes with specific suggestions for improvement. - If you identify problems along the way, please note if they are minor, serious, or showstoppers. - Please *do* vote on whether the library should be accepted. Everyone who takes the time to look at the library is qualified to vote, and every vote is valuable. - Other questions you might want to answer in your review: * 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? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

4 5

Re: [boost] [contract] extra type requirements for contracts
by Brent Spillner 23 Sep '11

23 Sep '11

On Fri, 23 Sep 2011 06:45:10 lcaminiti wrote: >In this case T = val has an operator== which is private. This causes both >the methods (1) using dummy::operator== and (2) the traits requirement >can_call_equal<val> to fail :( Exactly (at least for the default implementation of can_call_equal<>). This is in general the behavior you want (can't accidentally apply a generic operator== to a type with special semantics for which that wouldn't make sense), but in a contract-checking context I think most users would rather at least have the option to silently ignore the untestable constraint. >Ideally, can_call_equal<val>::value will return false instead of generating >a compiler-error when val::operator== is private or protected. A part from >such an (impossible?) improvement to can_call_equal, I have no solution for Hardly impossible... If you really want the constraint to be tested, you obviously have to friend the constraint checker class (which may not always be permissible.) If you're content to ignore it, just specialize can_call_equal<perverse_type> to make the nested ::value false. Note that some user intervention is still required (adding a friend to perverse_type, or adding a specialization of can_call_equal<>), so your contracts won't be silently compiling to no-ops, but the library user has full control with minimal effort. As far as I know, there's no way to offer both options without naming the test predicate something other than operator==. Along the same lines, I recognize that test_equality() isn't the only operation required or supported by the contract mechanism (although I'll bet it's the most common.) However, I still believe that a few test_equality(), test_not_equal(), test_less_than_or_equal(), operator_add(), etc. stubs, and perhaps a HAS_MEMBER_FUNC() macro to generate other custom stubs, would enable more readable code than a postN() method for each constraint. On the other hand, there is something to be said for straightforward mechanical generation, and if you already create 4 other member functions per constraint it's probably not a big deal. >What do you think? Honestly, I think it's a great library, and I hope I can be disciplined enough to make a habit of using it.

1 0

Cross-compiling: linux host, qnx target. Perhaps it's a bug?
by Félix Robles 23 Sep '11

23 Sep '11

Hi, I've got KUbuntu 64bits installed: Linux findeton-PC 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux I want to compile boost using qcc toolset (qcc versión 4.4.2) for a qnx target-os from a linux host, and I'm unable to compile python,serialization and test libs (the rest of them are fine). This is how I do it: $ ./bootstrap.sh And it goes fine, it uses the gcc compiler, not qcc, because I want to execute b2 in my linux machine. Then I use the following command: $ ./b2 --build-dir=/home/findeton/boost_1_47_0/ toolset=qcc target-os=qnx --build-type=complete -a And this is the kind of output I get: qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/numeric.o In file included from ./boost/integer_fwd.hpp:17, from ./boost/integer.hpp:18, from ./boost/function/function_base.hpp:21, from ./boost/function/detail/prologue.hpp:17, from ./boost/function/function_template.hpp:13, from ./boost/function/detail/maybe_include.hpp:13, from ./boost/function/function0.hpp:11, from ./boost/python/errors.hpp:13, from ./boost/python/handle.hpp:11, from ./boost/python/converter/arg_to_python_base.hpp:7, from ./boost/python/converter/arg_to_python.hpp:14, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object.hpp:9, from ./boost/python/tuple.hpp:10, from ./boost/python/numeric.hpp:10, from libs/python/src/numeric.cpp:6: ./boost/cstdint.hpp:74: error: 'intleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:75: error: 'intfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:76: error: 'uintleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:77: error: 'uintfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:79: error: 'intleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:80: error: 'intfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:81: error: 'uintleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:82: error: 'uintfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:84: error: 'intleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:85: error: 'intfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:86: error: 'uintleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:87: error: 'uintfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:91: error: 'intleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:92: error: 'intfast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:93: error: 'uintleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:94: error: 'uintfast64_t' in namespace '::' does not name a type cc: /opt/qnx650/host/linux/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 "QCC" -Wc,-ftemplate-depth-128 -gstabs+ -O0 -Wc,-fno-inline -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_STATIC_LIB -I"." -I"/usr/include/python2.7" -c -o "/home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/numeric.o" "libs/python/src/numeric.cpp" ...failed qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/numeric.o... qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/list.o In file included from ./boost/integer_fwd.hpp:17, from ./boost/integer.hpp:18, from ./boost/function/function_base.hpp:21, from ./boost/function/detail/prologue.hpp:17, from ./boost/function/function_template.hpp:13, from ./boost/function/detail/maybe_include.hpp:13, from ./boost/function/function0.hpp:11, from ./boost/python/errors.hpp:13, from ./boost/python/handle.hpp:11, from ./boost/python/converter/arg_to_python_base.hpp:7, from ./boost/python/converter/arg_to_python.hpp:14, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object.hpp:9, from ./boost/python/list.hpp:10, from libs/python/src/list.cpp:5: ./boost/cstdint.hpp:74: error: 'intleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:75: error: 'intfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:76: error: 'uintleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:77: error: 'uintfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:79: error: 'intleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:80: error: 'intfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:81: error: 'uintleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:82: error: 'uintfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:84: error: 'intleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:85: error: 'intfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:86: error: 'uintleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:87: error: 'uintfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:91: error: 'intleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:92: error: 'intfast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:93: error: 'uintleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:94: error: 'uintfast64_t' in namespace '::' does not name a type cc: /opt/qnx650/host/linux/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 "QCC" -Wc,-ftemplate-depth-128 -gstabs+ -O0 -Wc,-fno-inline -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_STATIC_LIB -I"." -I"/usr/include/python2.7" -c -o "/home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/list.o" "libs/python/src/list.cpp" ...failed qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/list.o... [ And after some of those, then I get some of this kind : ] qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_iarchive.o In file included from ./boost/serialization/extended_type_info_typeid.hpp:34, from ./boost/archive/detail/iserializer.hpp:47, from ./boost/archive/detail/interface_iarchive.hpp:22, from ./boost/archive/detail/common_iarchive.hpp:23, from ./boost/archive/basic_binary_iarchive.hpp:31, from ./boost/archive/binary_iarchive_impl.hpp:22, from ./boost/archive/binary_iarchive.hpp:20, from libs/serialization/src/binary_iarchive.cpp:14: ./boost/serialization/factory.hpp:28: error: '::va_list' has not been declared cc: /opt/qnx650/host/linux/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 "QCC" -Wc,-ftemplate-depth-128 -O3 -Wc,-finline-functions -Wc,-Wno-inline -shared -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I"." -c -o "/home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_iarchive.o" "libs/serialization/src/binary_iarchive.cpp" ...failed qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_iarchive.o... qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_oarchive.o In file included from ./boost/serialization/extended_type_info_typeid.hpp:34, from ./boost/archive/detail/oserializer.hpp:38, from ./boost/archive/detail/interface_oarchive.hpp:23, from ./boost/archive/detail/common_oarchive.hpp:22, from ./boost/archive/basic_binary_oarchive.hpp:34, from ./boost/archive/binary_oarchive_impl.hpp:23, from ./boost/archive/binary_oarchive.hpp:21, from libs/serialization/src/binary_oarchive.cpp:14: ./boost/serialization/factory.hpp:28: error: '::va_list' has not been declared

1 0

FW: Boost.Units problem with user-defined units and dimensionless quantities
by Pieter 23 Sep '11

23 Sep '11

Thanks Steven. I now see the problem arises from using si::dimensionless with nautical::length (The error message I get depends on the included header files but is related to the operator+ (when absolute.hpp is included) or the lack of a specialized add_typeof_helper in case that for example si/area.hpp is included). I guess my misconception was that I silently assumed that the 'dimensionless' type was acting as a normal double, reinforced by the fact that the line with the pure multiplication (nm1 = d*nm2;) does compile OK. The documentation says that " Because dimensionless quantities have no associated units, they behave as normal scalars, and allow implicit conversion to and from the underlying value type or types that are convertible to/from that value type". I intended to use my TDimless type as a 'generic' type for dimensionless quantities, but I now understand these quantities still need to be related to a 'system' and every system would need its own dimensionless type, even though there is no relation to the base units that define the system. Would I need to explicitly define conversions (e.g. BOOST_UNITS_DEFINE_CONVERSION_FACTOR(nautical::dimensionless, si::dimensionless, double, 1.0); or is there a more elegant way to use dimensionless quantities across systems? Thanks again, Pieter -----Original Message----- From: Steven Watanabe [mailto:watanabesj@gmail.com] Sent: Friday, September 23, 2011 17:06 To: boost(a)lists.boost.org Subject: Re: [boost] Boost.Units problem with user-defined units and dimensionless quantities AMDG On 09/21/2011 12:29 PM, Pieter wrote: > I am having some trouble using user-defined units and dimensionless once. > Consider the example (taken straight from the documentation) that > defines nautical miles (added at the bottom). > > When I do the following on VS2010: > > typedef quantity<boost::units::nautical::length> TDistanceInNMI; > typedef quantity<dimensionless> TDimLess; > > TDistanceInNMI nm1,nm2,nm3; > TDimLess d; > > nm1 = nm2 + nm3; // compiles OK > nm1 = d*nm2; // compiles OK > nm1 = nm2 + d*nm3; // does not compile, claims there is no operator+ > defined > > I suppose I might have to add a dimensionless type to the 'nautical' > system, or have some misconceptions on how this should work. I tried > adding the following line (mimicking some of the internal stuff) but > that did not due to trick: > > typedef unit<dimensionless_type,system> dimensionless; > I'm surprised that this doesn't work. It seems to work when I try it. The attached compiles with MSVC 2010. > Could anyone tell me whether there is there anything I need to define > to make this work? > In Christ, Steven Watanabe

1 0

Re: [boost] More tests running with Boost.Test than registered
by Jon Black 23 Sep '11

23 Sep '11

On 23-9-2011 7:42, boost-request(a)lists.boost.org wrote: >> So I put a print statement in the test in each DLL and ran it again, and > You could have used --log_level=all to see what is being tested Thanks. That's much nicer. >> > The project for MyDll1 depends on the other projects. That can't be a >> > coincidence! I'm confused though, why is the console_test_runner >> > executing tests in other DLL's when I've only specified MyDll1 on the >> > command line? Each DLL has its own unit_test_init() function declared in > You probably are using automatically registered test units. These are registered > in single shared test framework as soon as you load these libraries and they are > loaded in memory as they are dependencies of the library you want to test. Thus > you end up with all test units in all loaded libraries. Yes, they are automatically registered tests. In the init_unit_test() method I also give the master test suite a unique name for each DLL. If there is on shared test framework, does this mean I'm just renaming the same master test suite each time? > You can specify the test case belonging to the Mydll1 using --run=TestMyDll1 and > you'll get only 1 test case being executed. Perfect! I've used run_test to limit to a test suite which I've auto registered per project. > I think this is correct behavior overall. What you got here is implicit > dependency between test units you can't be sure TestMyDll1 working until you > tested all of it's dependent test cases which are in this case reside in > corresponding libraries. Agreed. I'm running it as a post build step. Adding the run_test option to limit what is executed solves my problem. Thanks. > Gennadiy

2 1

Boost.Units problem with user-defined units and dimensionless quantities
by Pieter 23 Sep '11

23 Sep '11

LS, I am having some trouble using user-defined units and dimensionless once. Consider the example (taken straight from the documentation) that defines nautical miles (added at the bottom). When I do the following on VS2010: typedef quantity<boost::units::nautical::length> TDistanceInNMI; typedef quantity<dimensionless> TDimLess; TDistanceInNMI nm1,nm2,nm3; TDimLess d; nm1 = nm2 + nm3; // compiles OK nm1 = d*nm2; // compiles OK nm1 = nm2 + d*nm3; // does not compile, claims there is no operator+ defined I suppose I might have to add a dimensionless type to the 'nautical' system, or have some misconceptions on how this should work. I tried adding the following line (mimicking some of the internal stuff) but that did not due to trick: typedef unit<dimensionless_type,system> dimensionless; Could anyone tell me whether there is there anything I need to define to make this work? Any help is appreciated, Many thanks, Pieter --- The example --- namespace boost { namespace units { namespace nautical { struct length_base_unit : base_unit<length_base_unit, length_dimension, 1000> { static std::string name() { return "nautical mile"; } static std::string symbol() { return "nmi"; } }; typedef make_system<length_base_unit>::type system; typedef unit<length_dimension,system> length; // 'typedef unit<dimensionless_type,system> dimensionless'; static const length mile,miles; } } } // helper for conversions between nautical length and si length BOOST_UNITS_DEFINE_CONVERSION_FACTOR(boost::units::nautical::length_base_uni t, boost::units::si::meter_base_unit, double, 1.852e3); Pieter

2 1

Re: [boost] [contract] extra type requirements for contracts
by Brent Spillner 23 Sep '11

23 Sep '11

On Thu, 22 Sep 2011 08:03:09 lcaminiti wrote: >For example, the following code asserts back() == value only when >can_call_equal<T>::value is true. However, is there a better way to do this >that does not require the extra function call to post1? Unless I'm missing something, you should be able to replace the post1() calls with assert(boost::can_call_equal<T>::value && std::clog << "actual assertion\n" == std::clog && back() == value || std::clog << "trivial assertion\n" == std::clog);

3 5

structured exceptions for UNIXs -- the hard way
by Peter Foelsche 23 Sep '11

23 Sep '11

On UNIXs one does not get around signals. They are used for everything. E.g. using memory mapped io is impossible without dealing with signals. E.g. somebody may edit the file which is mapped into your process thereby truncating it and invalidating some part of the memory. Or one may be writing into a sparse file via memory mapped io and the result of "out of disk space" is also a signal. Then there are such sick solutions as setjmp()/longjmp(). Could they be packed into some class to enable some kind of structured exceptions on UNIXs? #include <setjmp.h> #include <vector> static std::vector<jmp_buf> s_sStack; static void signalHandler(void) { if (s_sStack.size()) { jmp_buf s = s_sStack.back(); s_sStack.pop_back(); longjmp(s); } } struct CSetLongJmp { CSetLongJmp(void) { s_sStack.push_back(jmp_buf()); if (setjmp(s_sStack.back())) throw "something"; } ~CSetLongJmp(void) { s_sStack.pop_back(); } }; This class would need to be part of anything which needs to be protected against signals: std::string s; CSetLongJmp s1; useString(s); Peter Foelsche

9 12

Re: [boost] Bugs in regression/library_status.cpp on Windows
by Robert Kawulak 22 Sep '11

22 Sep '11

Hi, Since there was no response to my emails with patches for two months now and the code is still broken as it was, should the tool be considered abandoned? If so, would it be acceptable if I apply the patches by myself? Best regards, Robert > -----Original Message----- > From: Robert Kawulak [mailto:Robert.Kawulak@gmail.com] > Sent: Monday, July 25, 2011 12:18 AM > To: 'boost(a)lists.boost.org' > Subject: RE: Bugs in regression/library_status.cpp on Windows > > Hi, > > Could anybody please apply that patch or suggest what can I do (or whom > to contact directly) to get this fixed? BTW, I wonder how it's possible > that most of the bugs were introduced in one commit half a year ago and > nobody even noticed - it would suffice to run this app on any platform > to get obvious errors while on Windows it wouldn't even compile. Am I > really the only person using this tool? :P > > I've also found another minor problems: > - when building it, "$(BOOST_ROOT)\tools\regression\build\bin" > directory is created but it's not marked with "ignore" in SVN; > - char_xlate functor only translates '/' character in URLs while on > Windows the character used is '\' (and it also causes problems in some > browsers). The solution is very simple - add "|| c = '\\'" in line 75. > > I'm attaching a patch file combining the previous fixes and the '\' > translation. > > Best regards, > Robert > > > > > -----Original Message----- > > From: Robert Kawulak [mailto:Robert.Kawulak@gmail.com] > > Sent: Saturday, July 09, 2011 11:35 PM > > To: 'boost(a)lists.boost.org' > > Cc: 'bdawes(a)acm.org'; 'blelbach(a)cct.lsu.edu' > > Subject: Bugs in regression/library_status.cpp on Windows > > > > Hello, > > > > I've stumbled upon several bugs in > > tools/regression/src/library_status.cpp when compiling on Windows > with > > gcc 4.5 and msvc 10.0. I'm attaching a patch file with all necessary > > fixes. The bugs are: > > > > - using path::native() instead of path::string() - the former is > > wstring on Windows, > > - calling path::string() twice to obtain begin() and end() iterators > - > > on Windows path::string() returns a temporary, so the iterators point > > to different objects, > > - using whole path for each node in build_node_tree() instead of only > > the directory name, > > - using whole path instead of only the test name in do_table_body(), > > - the link to links file is relative to test directory, not to the > > results output directory, > > - generation of closing "</a>" without opening "<a>". > > > > Best regards, > > Robert

1 0

More tests running with Boost.Test than registered
by Jon Black 22 Sep '11

22 Sep '11

I have a large solution in Visual Studio (100+) projects, of which most are dll's. The test code is in the DLL's and the tests are run using the provided console_test_runner. At the moment, each DLL has a single passing test. However, when I run the console_test_runner on a single dll, the output indicates that there are more tests. For example: D:\Projects\MyProject\console_test_runner.exe --test MyDll1.dll Running 5 test cases... *** No errors detected So I put a print statement in the test in each DLL and ran it again, and here's what happened: D:\Projects\MyProject\console_test_runner.exe --test MyDll1.dll Running 5 test cases... TestMyDll5 TestMyDll4 TestMyDll3 TestMyDll2 TestMyDll1 *** No errors detected The project for MyDll1 depends on the other projects. That can't be a coincidence! I'm confused though, why is the console_test_runner executing tests in other DLL's when I've only specified MyDll1 on the command line? Each DLL has its own unit_test_init() function declared in the pre-compiled header, so I'm really lost on what is happening here. Is it possible that the other dll tests are getting registered as well?

2 1

preprocessor programming challenge
by Eric Niebler 22 Sep '11

22 Sep '11

I have a PP interface such as the following: #define MACRO(x) \ typedef x type; \ typedef x::nested nested; struct D { struct nested {}; }; It is intended to be used as follows: struct foo { MACRO(D) }; Now the problem comes when x is a dependent type, because "typedef x::nested" needs a "typename" in there. I would like to additionally support the following syntax (or something like it): template<class DD> struct bar { MACRO(typename DD) }; The above doesn't work as is because "typedef typename DD type;" is ill-formed (although msvc eats it). Constraints are i/ the interface must be backwards compatible to avoid breaking existing clients, ii/ it should be done with PP only. No templates should be instantiated here, and iii/ it should be standard C++03. No PP variadics. Is this possible? I think not, but my PP-foo is weak. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2

Name and Namespace for Potential Boost Extended Floating-Point
by Christopher Kormanyos 22 Sep '11

22 Sep '11

Hello, We are seeking a good name for a potential boost extended precision floating-point library. This is a multiple precision floating-point type which *behaves* well in C++. The original thread announcing this potential library is here: http://lists.boost.org/Archives/boost/2011/06/182334.php Some very helpful boosters are assisting me with the preparation of this potential library. We've still got a lot to do, but are making good progress. In order to continue, we need a good name for a potential boost multiple-precision floating-point type. For the multiple-precision real type we have names like: * multiprecision_real * mp_real * extended_float_tOur current favorite is the second:mp_real. For namespaces, we have: 1. boost::mp::mp_real 2. boost::multiprecision::mp_real 3. boost::multiple_precision::mp_realOur current favorite namespace is number 2: boost::multiprecision. This new data type behaves like a drop-in replacement for a POD. It also has a collection of transcendental functions and a complex data type. So we are proposing: namespace boost { namespace multiprecision { class mp_real { ... }; // The real data type. class mp_complex { ... }; // The complex data type. mp_real sin(const mp_real&); // The sin function for the real data type. class mp_uint { }; // A potential future multiple-precision unsigned integer type. class mp_int { }; // A potential future multiple-precision signed integer type. } } We would appreciate comments (negative or positive) and/or alternative suggestions for names. Thank you. Sincerely, Chris.

15 56

[type_traits] has_member_function_callable_with
by Ion Gaztañaga 21 Sep '11

21 Sep '11

Hi to all, Trying to port C++11 code (allocator_traits) to C++03 (without decltype support), I needed to check at compile time if a member function can be called with some given parameters. Typical solutions I found on the net were based on specific signatures, say: const bool value = HAS_MEMBER_FUNCTION_FUNCNAME_WITH_SIGNATURE(MyClass, (int, char*)); However, it is not feasible to know the exact signature as I want to deal with conversions, const references, etc. Luckily, I found a very interesting explanation in Proto documentation: http://www.boost.org/doc/libs/1_47_0/doc/html/proto/appendices.html#boost_p… Based on this, I've tried to write my solution and I'd like to share it here with type traits experts, in case someone knows a better solution (see attached example). I know I don't take into account many issues for a truly generic utility (const member functions, etc.) but please let me know if you find this example interesting. Best, Ion

4 6

[BGL] container_gen
by Cromwell Enage 21 Sep '11

21 Sep '11

Hi, all. After a bit of a programming hiatus, I've managed to follow up on our container_gen discussion we had last May, archived here: <http://article.gmane.org/gmane.comp.lib.boost.devel/219238> I've created a branch in the sandbox called utility-container_gen that places the metafunction in Boost.Utility, changes detail::is_random_access to is_random_access_selector, provides an is_unique_associative_selector metafunction, and changes adjacency_list and parallel_edge_traits to use said utilities. Plus, there's Quickbook documentation. I've tested a few example programs in the BGL to make sure they still work, but I feel that's far from being thorough. No selectors for Boost.Intrusive have been implemented, yet. Feedback welcome! Cromwell D. Enage

2 2

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

21 Sep '11

> Comments are always welcome :) Hi Lorenzo, The number of examples is impressive. It is a pleasure to observe your library growing at this pace. I would like to suggest two things. I could not see from the examples, if the library is capable of supporting "function try blocks" in constructor and destructor definitions. This is what I mean. http://msdn.microsoft.com/en-us/library/e9etx778%28v=vs.71%29.aspx http://www.gotw.ca/gotw/066.htm Second, I have seen #ifndef pragmas in some of the examples, e.g., in the body of function myadvance_dispatch you have: { #ifndef CONTRACT_CONFIG_NO_LOOP_VARIANTS Distance n_max = n; #endif CONTRACT_LOOP( while(n++) ) { CONTRACT_LOOP_VARIANT( const( n_max, n ) n_max - n ) --i; } } I am not sure if the necessity to use this conditional code would occur often, but if so, perhaps the code would be slightly more clear if instead the conditional code would be wrapped in an additional macro, like MFC did with DEBUG_ONLY macro: { CONTRACT_CONFIG_LOOP_VARIANT_ONLY( Distance n_max = n ); CONTRACT_LOOP( while(n++) ) { CONTRACT_LOOP_VARIANT( const( n_max, n ) n_max - n ) --i; } } That is, macro CONTRACT_CONFIG_LOOP_VARIANT_ONLY is defined as: #ifndef CONTRACT_CONFIG_NO_LOOP_VARIANTS #define CONTRACT_CONFIG_LOOP_VARIANT_ONLY(ARG) ARG #else #define CONTRACT_CONFIG_LOOP_VARIANT_ONLY(ARG) #endif Although I am not sure if a similar trick would be possible with the definition like: CONTRACT_FUNCTION( template( typename T ) requires( Addable<T> #ifndef CONTRACT_CONFIG_NO_POSTCONDITIONS // Equality only for postconditions. , boost::EqualityComparable<T> #endif ) (T) (add) ( (T) x, (T) y ) postcondition( auto result = return, result == x + y ) ) { return x + y; } Regards, &rzej

3 2

[exception] get_error_info with dynamic libraries
by Pavel Lebedev 19 Sep '11

19 Sep '11

Hi, I believe there is a problem with boost::get_error_info when used to retrieve error info objects added to exceptions in a module (exe/dll) different from the one making the call to this function under MSVC++ 2010 SP1. The problem appears to be introduced in SVN revision 68792 with a fix for ticket #5178 that changed struct boost::exception_detail::type_info_ from storing a reference to type info to a pointer in member type_. There's an assertion in function boost::exception_detail::error_info_impl_container::get that checks these members for equality which now does pointer comparison instead of calling std::type_info::operator== (for the case of enabled RTTI). This fails when used on error info added in the different module from the one trying to access it because each module gets its own copy of std::type_info object for the same type with different addresses, even though std::type_info::operator= does string comparison of class names and would have returned true, as it did before this change. Other compilers/platforms that don't provide process-unique type info objects are most likely affected too. The following patch appears to fix this problem for me by reverting to compiler-provided way of comparing type info objects. Index: info.hpp =================================================================== --- info.hpp (revision 74465) +++ info.hpp (working copy) @@ -97,7 +97,7 @@ { shared_ptr<error_info_base> const & p = i->second; #ifndef BOOST_NO_RTTI - BOOST_ASSERT( BOOST_EXCEPTION_DYNAMIC_TYPEID(*p).type_==ti.type_ ); + BOOST_ASSERT( *BOOST_EXCEPTION_DYNAMIC_TYPEID(*p).type_==*ti.type_ ); #endif return p; } Is this fix correct? Thanks in advance. Pavel Lebedev

2 2

[utility] rvalue support in value_initialized
by "Claas H. Köhler" 19 Sep '11

19 Sep '11

Hi everybody! Recently I encountered a problem using the std:::unique_ptr within boost::spirit. The reason is apparently that value_initialized does not support rvalue assignment. Are there any plans to implement move semantics into value_initialized? Mainly I would be interested in making something like this work: std::unique_ptr<T> a= boost::get( boost::value_initialized< std::unique_ptr<T> >() ); Currently this fails due to the fact, that unique_ptr can be moved but not copied. Regards Claas

8 9

[move] [optional] Move constructors support
by Antony Polukhin 19 Sep '11

19 Sep '11

There is a feature request https://svn.boost.org/trac/boost/ticket/1841 with some patch. I'm just curious, when will be it applied? Shall this patch be applied, or some integration with Boost.Move must be done instead? Best regards, Antony Polukhin

1 0

Template metaprogramming libraries
by Ábel Sinkovics 19 Sep '11

19 Sep '11

Hi Boost developers, I am a PhD student at Eotvos Lorand University, Budapest. My research area covers C++ template metaprogramming. As part of my research I have developed four template metaprogram libraries based on Boost.MPL. On my conference appearances I was encouraged to submit my libraries to the Boost sandbox. Here is a short summary of the libraries: metaparse A tool for building embedded DSLs in C++. This is a compile-time parser generator library. Using it one can build parsers that take compile-time strings as input text and parse them as part of the C++ compilation process. One can think of it as using Spirit at compile-time. safe_printf Typesafe printf implementation using metaparse. It provides printf (sprintf, fprintf) functions taking the format string as a template argument and type-checking it at compile-time. It is a practical application of the metaparse library. metamonad Monad implementation for C++ template metaprograms. The library provides a framework for using monads in C++ at compile-time. The library provides an embedded language for C++ template metaprogramming similar to Haskell's do-notation. Using it, template metaprograms can be written with a syntax that resembles procedural code. Unlike the approach presented at this year's Boostcon, my library focuses on monads evaluated completely at compile-time. The library contains implementations for a number of monads available in Haskell (Maybe, Either, Reader, Writer, State, etc.). As an addition, the library contains a monad for error propagation in C ++ template metaprogramming. Based on the similarities of monadic error propagation and exception handling in runtime C++, the library provides an embedded language that resembles to exception handling. Using it, one can throw and catch "exceptions" at compile-time. metatest Unit testing library for C++ template metaprograms. If a metaprogram test case fails, it does not produce compilation error, but makes the result information available at runtime. Using this one can generate advanced reports and integrate the results into unit testing frameworks for runtime C++ code. The library contains code that integrates it with Boost.Test. The source code, unit tests and examples for the library are available at http://github.com/sabel83/mpllibs I've tested the libraries with the following compilers: - gcc 4.5 - clang 2.8 - Visual C++ 10 Full documentation of the libraries can be found at http://abel.web.elte.hu/mpllibs. Publications related to the libraries: http://abel.sinkovics.hu/?mod=kutat I would like to ask you for access to the Boost sandbox and I would appreciate all feedback from the Boost community. Best regards, Abel Sinkovics

13 31

De Brujin Bind and nested bind calls (was: Re: Template metaprogramming libraries)
by Thomas Heller 19 Sep '11

19 Sep '11

On Fri, Sep 16, 2011 at 7:09 PM, David Sankel <camior(a)gmail.com> wrote: > On Fri, Sep 16, 2011 at 6:30 AM, Thomas Heller > <thom.heller(a)googlemail.com>wrote: >> On Friday, September 16, 2011 06:17:00 AM David Sankel wrote: >> > On Fri, Sep 16, 2011 at 4:51 AM, Thomas Heller >> > <thom.heller(a)googlemail.com>wrote: >> > > On Thursday, September 15, 2011 12:31:50 PM David Sankel wrote: >> > <snip> >> > > <rant> >> > <snip> >> > > It should be noted though that phoenix users can get around >> > > > this somewhat by using _identifier syntax. >> > > > </rant> >> > > #include <boost/phoenix.hpp> >> > <snip> >> > auto flip = lambda(_a = _1)[bind(_a, _2, _1)]; >> > <snip> >> > > Thanks for your unqualified rant, David. >> > huh? >> >> Is this not what you were saying wasn't possible with phoenix? >> Having a De Brujin style syntax is perfectly possible in phoenix. It just >> hasn't been done yet cause, as you saw in my example, can be expressed by >> using phoenix local variables. > > Oh, my bad. When I said "_identifier syntax", I was referring to phoenix > local variables. I should have double-checked my phoenix vocab before I > wrote. > > Phoenix locals definitely help fill the coverage problem I referred to. I > don't know for sure, but I'd expect phoenix to cover all functions that can > be defined in lambda calculus. > > The reason I said that phoenix "somewhat" gets around the bind heritage > problems, which was obscure I admit, was because phoenix's use of > traditional bind syntax still leaves a semantic hole. Ok, misunderstanding on both sides, no offense intended. > If someone writes the following: > > template< typename F > > auto doSomething( F f ) -> decltype(...) > { > return bind( f, 15, _1) > } > > And then I call doSomething elsewhere like this, > > doSomething( bind( g, 12, _1, _2 ) ) > > , then the result is something most likely unexpected for the user who knows > what doSomething means (it returns a version of f that has 15 filled in as > its first argument (λx. λy. x(15,y))), but hasn't read its implementation. Now you got me interested, can you tell me how the DBB syntax solves this problem? Or is it just that your particular implementation solves it? FWIW, phoenix provides everything to introspect the given F and decide which action to take (wrap it into a lambda, "unlambda" it, leave it alone, etc.). One of the main design goals of the phoenix bind module was to be compatible to bind. So unlikely "bind" in its form will be changed. > Don't get me wrong, I think phoenix is an impressive feat. I'm just > advocating that we stop perpetuating the troubles caused by basing new > libraries on the traditional bind syntax. P.S.: I also like the DBB style syntax and think it would be a great addition, as JdG already mentioned, it is all implemented, what's missing is the frontend.

2 1

C++ Standards
by Jarrad Waterloo 19 Sep '11

19 Sep '11

What is the status of and where can one go for current information on TR2, decimal type and modules? Are these dead? Is the C++ standards body taking a 3-10 years siesta before starting on any of these or the next standard? Has there been any recent discussion on "stack trace", reflection, dll(s), overloading -> and other operators. There was a list of items in which there was not enough time to consider for this standard but potential for the next standard. I ask these questions because I found about the link to the C++ standards from the main page of the boost website. However that link has been rather quiet.

2 1

[fusion] boost::fusion::nil bug
by Jeroen Habraken 18 Sep '11

18 Sep '11

Hi, Clang 2.9 just pointed out what's probably an error in fusion in boost-trunk, the same one I ran into during the Conversion review yesterday it seems. Note that GCC doesn't complain even with -Wall -Wextra -pedantic. The error: In file included from fusion.cpp:1: In file included from boost-trunk/boost/fusion/include/vector.hpp:10: In file included from boost-trunk/boost/fusion/container/vector.hpp:11: In file included from boost-trunk/boost/fusion/container/vector/vector10.hpp:15: In file included from boost-trunk/boost/fusion/sequence/intrinsic/begin.hpp:17: In file included from boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:11: In file included from boost-trunk/boost/fusion/iterator/segmented_iterator.hpp:13: In file included from boost-trunk/boost/fusion/container/list/cons.hpp:14: In file included from boost-trunk/boost/fusion/sequence/intrinsic/end.hpp:17: 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())); ^~~~~~~~~~~~~ In file included from fusion.cpp:1: In file included from boost-trunk/boost/fusion/include/vector.hpp:10: In file included from boost-trunk/boost/fusion/container/vector.hpp:11: In file included from boost-trunk/boost/fusion/container/vector/vector10.hpp:15: In file included from boost-trunk/boost/fusion/sequence/intrinsic/begin.hpp:17: In file included from boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:10: In file included from boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin_impl.hpp:11: boost-trunk/boost/fusion/container/list/cons_fwd.hpp:13:12: note: forward declaration of 'boost::fusion::nil' struct nil; ^ 1 error generated. The code to reproduce the error: #include <boost/fusion/include/vector.hpp> int main(int, char*[]) { return 0; } It seems nil is either only forward-declared or the include with the declaration is missing. Kind regards, Jeroen Habraken

4 6

Is there interest in unit testing both passing and failing BOOST_MPL_ASSERTs?
by Ben Robinson 17 Sep '11

17 Sep '11

This submission would make it possible to write a complete set of unit tests for meta-programs, to test both the positive, compiling statements, and the negative, non-compiling statements. These tests will all compile, and the negative tests can throw an exception instead of failing to compile. After reading the recent interest submission from Abel Sinkovics, it occurred to me that it should be possible to modify the four existing BOOST_MPL_ASSERT_* macros to achieve this capability. This behavior would only be enabled if a specific compile flag was defined. Here is a sample code fragment which I have compiled and tested to work as described: // This definition shuts off the BOOST_MPL_ASSERT compile errors, and enables the run-time errors. #define BOOST_MPL_UNITTEST_ASSERTS defined BOOST_AUTO_TEST_CASE(ordinary_passing_test_cases) { BOOST_CHECK_NO_THROW( integers_only<char> passing0; ); BOOST_CHECK_NO_THROW( integers_only<short> passing1; ); BOOST_CHECK_NO_THROW( integers_only<int> passing2; ); BOOST_CHECK_NO_THROW( integers_only<unsigned int> passing3; ); } // These test cases now actually compile, but then throw at runtime, which is unit-testable. BOOST_AUTO_TEST_CASE(fantastic_failing_test_cases) { BOOST_CHECK_THROW( integers_only<float> failing0;, boost::mpl_assert_false); BOOST_CHECK_THROW( integers_only<double> failing1;, boost::mpl_assert_false ); } As you can see, existing code which uses the four BOOST_MPL_ASSERT_* macros, can now be unit tested, without modification, for both positive, and negative use cases. Is anybody interested in this capability, and/or my modifications to the single file boost/mpl/assert.hpp which have enabled this capability? Regards, Ben Robinson, Ph.D.

8 32

Re: [boost] [Boost-docs] Getting CVS read/write access boost-sandbox.cvs.sourceforge.net
by Paul A. Bristow 16 Sep '11

16 Sep '11

> -----Original Message----- > From: boost-docs-bounces(a)lists.boost.org [mailto:boost-docs-bounces@lists.boost.org] On Behalf Of > Daniel James > Sent: Saturday, September 10, 2011 10:06 AM > To: Discussion of Boost Documentation > Subject: Re: [Boost-docs] Getting write access to boost-sandbox.cvs.sourceforge.net I would like to get read and write access to boost-sandbox.cvs.sourceforge.net (to put up some html docs)' I have tried to follow the instructions on Sourceforge.net and believe that I have stored a SSH key because I can login thus using PuTTY "login as: pbristow pbristow(a)boost-sandbox.cvs.sourceforge.net's password: Last login: Thu Sep 15 12:58:36 2011 from 53-133.radnet-kendal.kencomp.net Welcome to *.cvs.sourceforge.net This is a restricted Shell Account You cannot execute anything here." PuTTY Window says "Connection closed by remote host." If I repeat I get login as: pbristow pbristow(a)boost-sandbox.cvs.sourceforge.net's password: Last login: Thu Sep 15 12:59:41 2011 from 53-133.radnet-kendal.kencomp.net Welcome to *.cvs.sourceforge.net This is a restricted Shell Account You cannot execute anything here. whose changed last login date suggests that I am logging in OK - so I know my username and password OK. (or does the fact that I am asked for a password mean that my SSH authentication is wrong?) When I try to CVS checkout, (using a variety of module names (fetch modules list option is not available?) I get PuTTY Fatal error "Network error: connection timed out." cvs [checkout aborted] : end of file from server (consult above messages if any) - and there are no messages :-( Please can any Sourceforge CVS users advise? Thank you. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

2 6

[chrono][stopwatches] Request for interest in NEW stopwatch/timer reporting facilities
by Vicente J. Botet Escriba 16 Sep '11

16 Sep '11

Hi, I has been reconsidering the reporting facilities of proposed Boost.Stopwatches. I have started to make some examples that make use Boost.Format to make the reports. Default reporting stopclock<> sw; prints the duration 29308.350 µs You can make a boost::format and pass it to the stopclock. void f1(long j) { boost::format fmt("%1%[%2%] f1(%3%) - Elapsed time: %4%"); fmt % __FILE__ % __LINE__ % j; stopclock< > sw(fmt); // burn some time } ../example/scoped_stopwatch_example.cpp[42] f1(1000000) - Elapsed time: 29834.769 µs ../example/scoped_stopwatch_example.cpp[51] void f2(long int) - Elapsed time: 0.979 µs You can change the precision, the output stream, the units and the unit text using a specific formatter. For example typedef elapsed_formatter<milli > formatter; formatter fmt("Elapsed time: %1%", std::cerr); fmt.set_duration_style(text); fmt.set_precision(6); stopclock<high_resolution_clock, formatter> sw(fmt); could print Elapsed time: 87.829801 milliseconds This formatter could be shared between several stopclocks (thread unsafe however). Even if the reporting facilities will not be completly 'localizable', I think that this interface goes one step towards in this direction. Before continuing the adaptation of the whole library I would like to hear some comments from you. Do you think this is an acceptable interface? What are the parameters that do you want to manage? procession, unit, short/long units, ... Best, Vicente

2 4

[iostreams] #5904: Patch to suppress "unreachable code" warning from Visual Studio 2008/2010 (VC90/VC100)
by Sylvester-Bradley, Gareth 16 Sep '11

16 Sep '11

I've added ticket #5904 with a patch to suppress a warning in Boost.Iostreams. Please would someone apply this for Boost 1.48.0? Ticket URL: <https://svn.boost.org/trac/boost/ticket/5904> Many thanks, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

1 0

utility-container_gen in the sandbox
by Cromwell Enage 16 Sep '11

16 Sep '11

Hi, all. After a bit of a programming hiatus, I've managed to follow through on the container_gen discussion we had last May. I've created a branch in the sandbox called utility-container_gen that places the metafunction in Boost.Utility, changes detail::is_random_access to is_random_access_selector, provides an is_unique_associative_selector metafunction, and changes adjacency_list and parallel_edge_traits to use said utilities. Plus, there's Quickbook documentation. I've tested a few example programs in the BGL to make sure they still work, but I feel that's far from being thorough. No selectors for Boost.Intrusive have been implemented, yet. Feedback welcome! Cromwell D. Enage

1 0

[Review] Boost.Endian by BEman Dawes starts today
by Joel Falcou 15 Sep '11

15 Sep '11

According to the schedule, the review of the Boost.Endian library by Beman Dawes starts today. =========== What is it? =========== Boost.Endian provides facilities to manipulate the byte ordering of integers. * The primary use case is binary I/O of integers for portable exchange with other systems, via either file or network transmission. * A secondary use case is to minimizing storage size via integers of sizes and/or alignments not supported by the built-in types. Integers 1, 2, 3, 4, 5, 6, 7, and 8 bytes in length are supported. * Two distinct approaches to byte ordering are provided. Each approach has a long history of successful use, and each approach has use cases where it is superior to the other approach. * The explicit approach provides explicit functions to reorder bytes. All four combinations of non-modifying or modifying, and unconditional or conditional, functions are provided. * The implicit approach provides integer classes that mimic the built-in integers, implicitly handling all byte reordering. =================== Getting the Library =================== Docs are available at http://boost.cowic.de/rc/endian/doc/index.html A zip file is available at http://boost.cowic.de/rc/endian/endian-rc1.zip INSTALL instructions at http://boost.cowic.de/rc/endian/INSTALL Alternately, the whole library can be checked out of the sandbox: svn co http://svn.boost.org/svn/boost/sandbox/endian endian ================ Writing a Review ================ The reviews and all comments should be submitted to the developers list, and the email should have "[Endian] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - 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.

4 6

[container] Issues with non-copyable mapped-types
by onlyone＠senet.com.au 15 Sep '11

15 Sep '11

Hi, I have been trying to use Boost.Container to make a map<copyable_but_not_moveable, moveable_but_not_copyable>. Unfortunately I have been unable to do this because the value_type of boost::container::map is std::pair, which does not support move semantics (in C++03). This causes problems for the moveable_but_not_copyable type. It means that, for example: myMap[copyable_but_not_moveable()]; does not compile. This behaviour is fully supported in C++11 mode, and I see no reason why a custom C++03 pair class would be unable to use the Boost.Move emulation to achieve the same effect. Regards, Evan Wallace

3 3

[boost/filesystem] Access to a shared folder on other computer
by Demetrio Car 15 Sep '11

15 Sep '11

Can someone send me a example of how to copy a file from a remote folder to other remote folder? For example: I am running MyProgram on MyComputer and this program has to copy a file from a folder inside OtherComputer. This folder need user and password to allow MyProgram to copy the file. I am using the following sample. The main point in this example is to make my program to work both in linux and windows, but locally. Now I want to do the same with a path like this: \\192.168.x.x\mySharedFolder\fileToBeCopied.text . Maybe I need another library but I don't know. //***http://www.ibm.com/developerworks/aix/library/au-boostfs/ #include <stdio.h> #include <boost/filesystem.hpp> int main() { boost::filesystem::path path("/usr/local/include"); bool result = boost::filesystem::is_directory(path); return 0; }

1 0

[Review] Boost.Endian Review
by joel falcou 15 Sep '11

15 Sep '11

A gentle reminder that the Boost.Endian review is scheduled to end today. Any participant that wish to submit review can do so before tonight Regards

1 0

[signals2] Problem compiling with Intel V12.1 (Windows)
by Hartmut Kaiser 15 Sep '11

15 Sep '11

Compiling code using Boost.Signals2 fails using Intel V12.1 on Windows. The reason is a forward declaration of std::weak_ptr and std::shared_ptr in the signals2 code which creates a problem as Intel seems to import std::tr1::weak_ptr into namespace std. This patch fixes the issue: --- forei-revBASE.svn002.tmp.hpp Wed Oct 07 15:56:56 2009 +++ boost/boost/signals2/detail/foreign_ptr.hpp Thu Sep 15 06:10:24 2011 @@ -12,16 +12,19 @@ #define BOOST_SIGNALS2_FOREIGN_PTR_HPP #include <algorithm> +#include <boost/config.hpp> #include <boost/assert.hpp> #include <boost/scoped_ptr.hpp> #include <boost/smart_ptr/bad_weak_ptr.hpp> #include <boost/utility/swap.hpp> +#if !defined(BOOST_INTEL_STDCXX0X) namespace std { template<typename T> class shared_ptr; template<typename T> class weak_ptr; } +#endif namespace boost { Ok to commit? Regards Hartmut --------------- http://boost-spirit.com

1 0

[phoenix] compile-time performance
by Eric Niebler 15 Sep '11

15 Sep '11

On 9/12/2011 4:06 AM, Thomas Heller wrote: > On Monday, September 12, 2011 02:57:21 PM Joel de Guzman wrote: >> For example, here is the current CT status of Phoenix2 vs Phoenix3 >> comparing the elapsed (CT) time for the phoenix2 vs. phoenix3 >> lambda_tests.cpp (**): >> >> MSVC 10: >> Phoenix2: 00:04.5 >> Phoenix3: 00:29.9 >> >> G++ 4.5: >> Phoenix2: 00:02.6 >> Phoenix3: 00:04.7 > > I wasn't aware that Phoenix3 was so bad under MSVC 10. Me neither. If that's the case, we have work to do. >> You all know that Phoenix2 uses Fusion exclusively. Phoenix3 uses >> proto, which according to Eric does not use Fusion, although IIRC >> the core of Phoenix3 uses some Fusion still (quick check: Thomas >> uses an optimized-PP version of fusion:: vector for phoenix3). >> >> Heller did a helluva perf-tweaks for Phx3 to get that number for >> g++ (alas, not MSVC). In fairness, I did absolutely no CT >> perf-tweaks for both Phoenix2 and Fusion. >> >> (** I made sure both tests have exactly the same code, so I removed >> the last test. I can post the exact code if need be) OK, I retract everything I said. Fusion rulez, and Proto needs help. Sorry for the blind accusation. Let's stop this and figure out what needs to be fixed. > FWIW, there are some unit tests that outperform the compile times of > Phoenix2 (with gcc), the current bad hit on compile times seem to > only occur with let, lambda and switch/case expressions. This /suggests/ to me that the core of Phx3 is sound, but that the implementation of let, lambda, and switch are heavy. But I'm not blaming Thomas. I'm just suggesting a logical place to begin an investigation. And regardless, we should point Steven's template profiler at the code and see what it says. Thomas, do you want to give that a shot? -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 9

[concept] EqualityComparable metafunction
by Lorenzo Caminiti 14 Sep '11

14 Sep '11

Hello all, What is the best way to check if a type T is EqualityComparable? Essentially, I would need a is_equality_comparable<> metafunction: struct mytype {}; is_equality_comparable<int>::value // true is_equality_comparable<mytype>::value // false Can I re-use the boost::EqualityComparable concept to implement is_equality_comparable<>? Or, shall I just try to use introspection-SFINAE techniques? Thanks in advance. --Lorenzo

7 11

intrusive_ptr to a map containing intrusive_ptr object
by shri kumar 14 Sep '11

14 Sep '11

Hi, I am facing a problem while making the raw pointer to an intrusive_ptr inside a map whose pointer is already an intrusive pointer so typedef goes like: typedef boost::intrusive_ptr< protocolLibraryLoader> ProtocolLibraryLoaderPtr; typedef std::pair<ProtocolLibraryLoaderPtr, ProtocolRecognizer_type*> ProtocolLibEnginePair; typedef boost::intrusive_ptr<ProtocolLibEnginePair> ProtocolLibEnginePairPtr; Now inside code when I try creating map and assign with ptr as given in below: .. *boost::intrusive_ptr<protocolLibraryLoader> libraryLoader = getProtoLoader();* .. m_activeRecEnginePtr = ProtocolLibEnginePairPtr(libraryLoader,newRecognizer); .. I get the following error: ProtocolManager.cpp: In member function 'void ProtocolManager::InitializeProtocolsLibrary(ProtocolManager*)': ProtocolManager.cpp:234: error: no matching function for call to 'boost::intrusive_ptr<std::pair<boost::intrusive_ptr<protocolLibraryLoader>, ProtocolRecognizer_type*> >::intrusive_ptr(boost::intrusive_ptr<protocolLibraryLoader>&, ProtocolRecognizer_type*&)' ../../../include/boost/intrusive_ptr.hpp:94: note: candidates are: boost::intrusive_ptr<T>::intrusive_ptr(const boost::intrusive_ptr<T>&) [with T = std::pair<boost::intrusive_ptr<protocolLibraryLoader>, ProtocolRecognizer_type*>] ../../../include/boost/intrusive_ptr.hpp:70: note: boost::intrusive_ptr<T>::intrusive_ptr(T*, bool) [with T = std::pair<boost::intrusive_ptr<protocolLibraryLoader>, ProtocolRecognizer_type*>] ../../../include/boost/intrusive_ptr.hpp:66: note: boost::intrusive_ptr<T>::intrusive_ptr() [with T = std::pair<boost::intrusive_ptr<protocolLibraryLoader>, ProtocolRecognizer_type*>] ../../../include/boost/intrusive_ptr.hpp: In constructor 'boost::intrusive_ptr<T>::intrusive_ptr(T*, bool) [with T = protocolLibraryLoader]': ProtocolManager.cpp:225: instantiated from here ../../../include/boost/intrusive_ptr.hpp:72: error: cannot convert 'protocolLibraryLoader*' to 'Tracker*' for argument '1' to 'void intrusive_ptr_add_ref(Tracker*)' ../../../include/boost/intrusive_ptr.hpp: In destructor 'boost::intrusive_ptr<T>::~intrusive_ptr() [with T = protocolLibraryLoader]': ProtocolManager.cpp:225: instantiated from here ../../../include/boost/intrusive_ptr.hpp:101: error: cannot convert 'protocolLibraryLoader*' to 'Tracker*' for argument '1' to 'void intrusive_ptr_release(Tracker*)' ../../../include/boost/intrusive_ptr.hpp: In copy constructor 'boost::intrusive_ptr<T>::intrusive_ptr(const boost::intrusive_ptr<T>&) [with T = protocolLibraryLoader]': ProtocolManager.cpp:225: instantiated from here ../../../include/boost/intrusive_ptr.hpp:96: error: cannot convert 'protocolLibraryLoader*' to 'Tracker*' for argument '1' to 'void intrusive_ptr_add_ref(Tracker*)' make: *** [FREEBSD_6_i686/ProtocolManager.o] Error 1 Basically worrying part is "no matching function for call to 'boost::intrusive_ptr<std::pair<boost::intrusive_ptr<protocolLibraryLoader>, ProtocolRecognizer_type*> >::intrusive_ptr(boost::intrusive_ptr<protocolLibraryLoader>&, ProtocolRecognizer_type*&)' I wonder if it is kind of limitation or do I have to do something else to achieve? Actually I am dealing with legacy code so I don't want to remove the intrusiveness on the pair which actually increases/decreases ref_count of ProtocolRecognizer_type and not on protocolLibraryLoader. Please help me as I am kind of stuck with this. Thanks Shri

2 1

[endian] Review
by Stewart, Robert 14 Sep '11

14 Sep '11

Herewith is my review of Beman's Boost.Endian library. ____________________ ____________________ What is your evaluation of the design? _____ The two-argument overloads of the [un]conditional swapping functions seem awkward at first blush, but are really the best interface for those operations. Changing to value returning functions opens the door to mistakes like the following: uint32_t const in(123); int32_t const out(reorder(in)); There might be a warning, but many programmers routinely ignore such. As is, the compiler will complain about the conditional functions: uint32_t const in(123); int32_t out; native_to_big(in, out); // Error: ambiguous The unconditional functions do not provide that benefit because they aren't function templates: uint32_t const in(123); int32_t out; reorder(in, out); _____ An interesting variation that I've used in the past is a set of cast-style function templates that permit byte swapping one type and returning the result as a different type, after verifying that the resulting value is in range of the target type. Thus, uint32_t const in(std::numeric_limits<uint32_t>::max()); int32_t const out(to_host<int32_t>(in)); // throws TMP allows streamlining the range checks done, of course. _____ Another variation I've used is a checked, two-argument function template with each potentially having a different type: template <class T, class U> void to_host(T & _result, U _value); (I always prefer output parameters to be first because their position is consistent and it leaves open the possibility of defaulted parameters in the general case. I'd prefer that in Boost.Endian, but not everyone likes that convention.) There are two possibilities for dealing with the case when T and U are different. One is that they be required to have the same, supported size and that they are both signed or both unsigned. The other is to do a runtime check that the swapped value is within the range of the target type. _____ I like that the aligned integer types have the longer names because they incur padding and are non-portable. _____ The overhead implied by the comments in the "Comment on naming" section of the Endian Integer Types page is an excellent reason for splitting the endian class template into endian_buffer and endian_integer as previously suggested. For C++11, the latter can derive from the former. For C++03, if POD-ness is important, you'll need to duplicate the former's code in the latter, but it's worthwhile. ____________________ ____________________ What is your evaluation of the implementation? There's already been a good deal of discussion on efficiency and reuse during the review, so I won't rehash it. The 64b reorder(), for example, looks like a lot of code for an inline function. I haven't compiled it to inspect the resulting assembly to see how much or little results. My concern is for the possibility of code bloat arising from the desire to keep this a header-only library. If those were function templates, then the compiler can choose whether to inline or not, despite the definition being in a header. The implementation of class endian is uncommented, yet non-trivial. A future maintainer, even Beman, will benefit from some helpful information inserted now. The implementation of class endian would be simplified, it appears to me, by passing the endianness along to a detail::store() function template and letting it select the big/little endian store logic. ____________________ ____________________ What is your evaluation of the documentation? It's incomplete. There are no examples of the conversion functions. There is no tutorial. There is no guidance on selecting between the alternatives. There is no comparison with traditional htnol()-style code. __________ Endian Home _____ Introduction to endianness s/modern Apple, Linux, or Windows computer/computer/ (the OS doesn't matter) s|a[sic] Oracle/Sun Solaris computer| (the OS doesn't matter) s/CPU's/CPUs/ (plural, not possessive) _____ Introduction to the Boost.Endian library The first and last sentences should be merged: "Boost.Endian is a header only library providing facilities for managing integer endianness." Endian conversions for native integers: The last sentence makes both absolute and relative statements. The relative statements are, presumably, relative to endian integer types, but that's not made clear. I suggest rewording as, "This approach is simple and efficient, but when compared to endian integer types, is less flexible regarding size and alignment, can be harder to manage, is more error prone because of the need to apply endian conversions in unrelated logic paths, all of which can lead to logic errors that are difficult to debug." Endian integer types: The second sentence has a similar problem, and the last sentence could be combined to correspond with the list of the previous paragraph. Try this variation: "This approach is simple and, while it can be less efficient than endian conversions, it avoids strict alignment requirements allowing opportunities to pack data more tightly." I'd follow with this variation of the third sentence: "Furthermore, types of length from 1 to 8 bytes are supported, rather than just the usual 1, 2, 4, and 8 byte lengths." __________ Conversion Functions This page is odd. The synopsis does not include links to the description of the functions. When I first saw the page, I thought there simply was no documentation for using the various functions. That documentation does appear in the latter part of the page, but it isn't obvious. There should be information explaining why conditional and unconditional functions are useful and each should refer to its counterpart. That is, reorder(uint16_t &) should note that if the intent is not to reorder the bytes regardless of the platform, that bit_to_native(uint16_t &), for example, is appropriate. The unconditional nature or reorder() escaped me until I realized that these functions always swap bytes, unlike the htonl() family, which I'd never before encountered as necessary. Thus, use cases for unconditional byte swapping are warranted. __________ Endian Integer Types The Conversion Functions page links to the description of big and little endian on the Endian Home page, but the Integer Types page does not. The example shown on the Integer Types page should be recreated using the Conversion Functions to show the difference in usage. That example should use sizeof(h) rather than sizeof(header) since that is a safer practice. _____ Limitations This section, while important, should not appear so soon on the page. s/compilers do layout memory/compilers lay out memory/ s/C++0x/C++11/ s/it will be possible to specify the default constructor as trivial/the default constructor is marked as trivial/ s/will no longer disqualify/do not disqualify/ s/will no longer be relying/does not rely/ _____ Feature set s/Big endian | little endian | native endian byte ordering./Big, little, and native endian byte ordering/ s/Signed | unsigned/Signed and unsigned/ s/Unaligned | aligned/Data may be aligned or unaligned/ s/1-8 byte (unaligned) | 2, 4, 8 byte (aligned)/2, 4, and 8 byte aligned types and 1-8 byte unaligned types/ _____ Typedefs The column order should correspond with the order of information in the typedef names: alignment, sign, endianness, size. The discussion of the difference between aligned and unaligned types should not be "buried" in the Typedefs section. _____ Comment on naming s/these type grows/these types grows/ Why does "the realization creep in" that the endian integer types are lousy arithmetic integers? Only profiling would reveal that. Consequently, you should call that out, perhaps in a "Design Details" section along with the aligned/unaligned discussion, thereby explicitly stating rather than leaving to each library user the discovery of the overhead of these types. _____ Synopsis The link from "cover_operators" to a header is surprising. _____ Members The description of the default constructor fails to indicate whether the value is left uninitialized, which I presume to be the case. The description of the conversion operator mixes T and value_type. While those two are the same, one has to examine the class definition to see that. Either s/T/value_type/ or s/value_type/T/. _____ FAQ s/and both speed and/plus both speed and/ s/disk records/records/ (applies to networking, too) s/Yes, for sure, compared/There is overhead compared/ s/are usually be faster/are usually faster/ s/types POD's?/types POD?/ s/endian integer types not being POD's/of endian types not being POD/ s/data files are portable/data files that are portable/ The "These types are really just byte-holders" entry should not be a FAQ. That information, along with a discussion of the overhead of the simple syntax, should be part of the "Design Details" section suggested above. _____ Design considerations for Boost.Endian integers Only "Design" is underlined in the section heading. s/memcpyable/memcpy-able/ _____ Experience s/used very successful/used very successfully/ _____ Compilation s/This is ensures that , and/This ensures that class endian is POD, even in C++03, and/ s/POD's/POD/ ____________________ ____________________ What is your evaluation of the potential usefulness of the library? Highly useful, but could be more so. ____________________ ____________________ Did you try to use the library? No. Sorry. ____________________ ____________________ How much effort did you put into your evaluation? I spent about an hour reading the documentation plus a lot of time on the mailing list participating in endian discussions. ____________________ ____________________ Are you knowledgeable about the problem domain? Yes. I've used the old standby functions, htonl(), ntohl(), and friends over many years. I've created template functions to automatically select the right function based upon the size of the type being swapped, etc. ____________________ ____________________ Do you think the library should be accepted as a Boost library? There are issues that keep me from saying yes at this time. There are too many suggested variations and ideas under consideration to accept the library in its present state. However, a mini-review should be sufficient to evaluate the final form, once Beman determines a course of action, and determine whether to accept it or not. _____ 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 1

[proto] Looong compile times and other issues
by John Maddock 14 Sep '11

14 Sep '11

So.... I thought I had all the expression template stuff pretty much done, and then I tried some real world use cases (compiling all the students_t distribution functions with my extended-precision FP type) and everything fell apart: * VC10 wouldn't compile the code at all - more or less runs the system out of swap space (takes about 10 minutes or more!), then exits with an internal compiler error (if I break the code down into it's parts and instantiate each part separately it does compile though - that's not a solution though!). * GCC-4.4.x fails to compile the code due to clashes between boost::math::complement (a function) and boost::proto::complement (a class). I suspect this is an old gcc bug (finding structures via ADL) - I guess the solution is to not derive my number type from a proto-type so ADL can't find proto:: classes? Or will I hit this from some other unforeseen lookup? * GCC-4.5.0 Fails with an internal compiler error :-( * GCC-4.6.0 Builds the code OK, but takes a long time - though possibly just barely acceptable. I suspect this is a "triple template" problem: * proto is complex template library. * my number class is a fairly large/complex template in it's own right. * the code above gets instantiated from deep within Boost.Math's internals. Other than using proto::switch in the grammar (which I'm doing already), is there anything I can do to reduce the template load on the proto side of things? Otherwise since I'm only using a tiny fraction of proto's capabilities, the only other option I can see is to rip it out and replace with a mini-proto designed to minimalize template instantiations within this particular use case. Thanks in advance, John.

7 26

[C++11 Feature List]
by Sid Sacek 13 Sep '11

13 Sep '11

Does boost have a spec (document) where it mentions which new language features in C++11 are permitted to be used in new libraries? -Sid Sacek

2 2

[Endian] Performance
by Phil Endecott 13 Sep '11

13 Sep '11

Dear All, I've just done some quick benchmarks of Beman's proposed byte-swapping code using the following test program: #include <cstdint> #include <iostream> #include <arpa/inet.h> // for htonl() using std::uint32_t; static inline uint32_t byteswap(uint32_t src) { #if defined(USE_GCC_BUILTIN) return __builtin_bswap32(src); #elif defined(USE_HTONL) return htonl(src); #elif defined(USE_REV_INSTR) uint32_t target; __asm__ ( "rev %0, %1\n" : "=r" (target) : "r" (src) ); return target; #elif defined(USE_BEMAN) const char* s (reinterpret_cast<const char*>(&src)); uint32_t target; char * t (reinterpret_cast<char*>(&target) + sizeof(target) - 1); *t = *s; *--t = *++s; *--t = *++s; *--t = *++s; return target; #else #error "Define USE_*" #endif } int main() { uint32_t s = 0; for (uint32_t i = 0; i < 1000000000; ++i) { s += byteswap(i); } std::cout << s << "\n"; // Expect 506498560 } I've tested this on two systems: (A): Marvell ARMv5TE ("Feroceon") @ 1.2 GHz, g++ 4.4 (B): Freescale ARMv7 (i.MX53, Coretex A8) @ 1.0 GHz, g++ 4.6.1 Compiled with: --std=c++0x -O4 Execution times in seconds are: A B USE_GCC_BUILTIN 29.4 3.0 USE_HTONL 12.6 3.0 USE_REV_INSTR n/a 3.0 USE_BEMAN 17.6 8.0 ARM architecture version 6 (IIRC) introduced a "rev" byte-swapping instruction. On system B, which supports this, it is used by the gcc builtin and glibc's htonl() giving better performance than Beman's code. On system A which does not support this instruction, the gcc builtin makes a library call; I've not looked at what htonl() does. What do people see on other platforms? How important do we consider performance to be for this library? Regards, Phil.

11 37

[stopwatches] About reducing the scope of the library
by Vicente J. Botet Escriba 13 Sep '11

13 Sep '11

Hi, I'm not completly satisfied with the reporting interface/design I did for Boost.Stopwatches. I need to think more about the design so it can provide Locale facilities to the user. Do you think that it is worth proposing an addition to Boost.Chrono that provides only stopwatches (without reporting)? Best, Vicente

4 9

Re: [boost] [Submission] RawMemory (24-bit integers and runtime-dispatch)
by Adder 13 Sep '11

13 Sep '11

Hi there ! And thank you for your time and for your questions. Before I answer the first question regarding 24-bit integers, etc., please allow me to kindly ask you: Where are you going to store the 24-bit integer that you read from "raw memory" (= untyped memory = array of bytes) ? Or where is the 24-bit integer that you plan to write to "raw memory" stored ? (In what type of variable ?) Regarding the second question, regarding run-time dispatching of operations (as opposed to compile-time dispatching), I will start with a couple of examples that supports your question even more: It is not just the endian-ness that might not be known at compile-time. The alignment of data might also not be known before explicitly checking it at run-time. Let me quote from the ugly documentation that I have written (http://adder.iworks.ro/Boost/RawMemory/#UsersManual) "When we are dealing with an array of values (i.e. contiguous values) and performance is critical, we might want to check whether the data is aligned and specifically demand unchecked_memory_xfer if it is." Ultimately, the number of bytes that are used to represent the integer may be variable. Such is the case with the "mapping pair offsets" used by NTFS to locate the contiguous runs of clusters that make up the (non-MFT resident portion of the) file. In order to save precious MFT (Master File Table) entry space, signed offsets are stored in variable-sized (1 to 8-byte long) integers. My answer is probably obvious by now. I am thinking about letting the programmer use the ultimate weapon she has in her toolchest: The mighty "if" instruction. For the specific example you kindly gave, I am thinking that the following syntax might be useful for reading UCS-2 characters from a file saved with Notepad (in "Unicode" or "Unicode Big Endian" format): const uint16_t nByteOrderMask = raw_memory <uint16_t, little_endian>::peek (pFileBuffer); const bool bBigEndian = nByteOrderMask == 0xFEFF; ... // The loop: { const uint16_t cCurrent = bBigEndian ? raw_memory <uint16_t, big_endian>::peek (pCurrent) : raw_memory <uint16_t, little_endian>::peek (pCurrent); ... } I await your thoughts... Thank you again ! (-: -- Yours truly, Adder On 9/7/11, Joe Mucchiello <jmucchiello(a)yahoo.com> wrote: > 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 > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 5

[Endian] Review
by Tomas Puverle 12 Sep '11

12 Sep '11

Hi Beman, > - What is your evaluation of the design? The design of the integer types seems reasonable to me, even though I would prefer not to have the overloaded operators on them. I feel that having the operators has the potential to break the boundary between program input and the program's processing. What do you I mean by that? Typically, I try to structure my programs as follows: 1) Read input data 2) Verify input invariants, construct internal representation 3) Process internal representation 4) Output result The problem with having operators in the endian types is that they encourage the user to continue using them past the point 2). However, as I said, that's my personal preference and last year plenty of people wanted to see the operators included. Perhaps they could be a policy? endian<..., bool EnableOperators_ > ? As for the rest of the library, I have the following comments: - As many other people have mentioned, floating point support and user defined types are a must. - I am happy that the "conversion functions" have been added, Unfortunately, I find them lacking in several departments: - (Note: I am going to try very hard not to get drawn into another naming discussion. That's pretty much what ended my efforts last year - 50 people commenting, each proposing a different set of names :D ) - While the endian types support unaligned data, the endian functions don't appear to do so. I don't see how the endian types could be implemented using them. - No support for user defined types, arrays/ranges of user defined types etc. This is extremely useful. A frequent example I come across is the following (using our syntax): //load a file into memory //... swapInPlace<BigToNative>(data.begin(), data.end()); Depending on the platform, that last statement may get compiled out to a no-op. This is also the big reason why our version of "reorder()" is not unconditional but depends on the "swap type". - reorder(x) will work fine for integral types, however, has potential to cause issues for e.g. floating types. This has been discussed extensively during my proposal last year. Also, from my practical experience, having a floating point number as an input, I find the assembly typically includes (unncecessary) floating point load/store instructions. Something along the lines of e.g.: template<typename T_> T_ big_to_native(raw_memory<T_>) and template<typename T_> swapped_data<T_> native_to_big(T_) might be better and result in better performance. Of course, those two function signatures don't solve the "reorder" signature, but that could be changed correspondingly. - reorder() should use platform specific instructions (such as bswap) for doing endian swapping, otherwise falling back on one of the (many) variants which are currently being discussed. - I think the alternatives such as little_to_big() and big_to_little() are also needed. - I would like to see a few standard traits/typedefs so that I don't have to keep checking pre-processor macros, such as typedef boost::mpl::true_/false_ platform_is_big_endian; or something similar. - While I haven't needed this myself, last year someone mentioned the need for a "general reorder" functionality. Rather than simply dealing with little/big endianness, allow the user to specify ANY byte ordering for the specific data size. - I would like to see an endian_swap_iterator (and a raw_endian_iterator, which can iterate over unaligned data, too) > - What is your evaluation of the implementation? Other than the implementation of reorder() and its performance, which is already being discussed on the list, (and the inclusion of platform specific instructions, as per above) I would like to see endian<> to be implemented in terms of the "free" functions. It seems strange to have two implementations of the same task. > - What is your evaluation of the documentation? Fine. > - What is your evaluation of the potential usefulness of the > library? Very useful, long overdue in boost. > - Did you try to use the library? With what compiler? Did you > have any problems? Tried the integer types last year, no problems. Didn't try the "new" swapping functions. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? I spent a fair bit of time looking through the docs, the code and reading the followup posts etc. > - Are you knowledgeable about the problem domain? Reasonably. > And finally, every review should answer this question: > > - Do you think the library should be accepted as a Boost library? I see the library as having two pieces, both useful to different people. I would say conditionally accept the endian<> class if floating point support is added. I would vote no for the inclusion of the free function interfaces in their current form. Thanks! Tom

6 14

[graph][iterators] csr graph and reverse iterator problem
by Takatoshi Kondo 11 Sep '11

11 Sep '11

Hi, All I'm using Boost.Graph and Boost.Iterators. When I use the compressed_sparse_row_graph with reverse_iterator, I ran into a problem. When I dereference the reverse_iterator of compressed_sparse_row_graph's iterator, invalid memory access occurs. On g++ version 4.6.0 with -Os option, The output is below. 0 1 1 0 0 1 134526756 3218710936 1 0 And I also checked where the invalid memory access occurred using valgrind. ==2341== Invalid read of size 4 ==2341== at 0x8048DE7: test_csr_graph() (rev_iter.cpp:45) ==2341== by 0x8048FB3: main (rev_iter.cpp:59) ==2341== Address 0xbe825f88 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes ==2341== 1 ==2341== Invalid read of size 4 ==2341== at 0x8048E31: test_csr_graph() (rev_iter.cpp:46) ==2341== by 0x8048FB3: main (rev_iter.cpp:59) ==2341== Address 0xbe825f88 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes ==2341== This result indicates the code below is suspicious. std::cout << *rib++ << std::endl; // NG Why? Line 45 std::cout << *rib++ << std::endl; // NG Why? Line 46 But... boost::tie(ib, ie) = boost::vertices(g); std::cout << *--ie << std::endl; // OK std::cout << *--ie << std::endl; // OK It is OK. Here is the source code that reproduces the problem. ------------ begin ------------- #include <boost/iterator/reverse_iterator.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/compressed_sparse_row_graph.hpp> #include <iostream> #include <cassert> void test_graph() { typedef boost::adjacency_list<> graph_type; graph_type g(2); boost::graph_traits<graph_type>::vertex_iterator ib, ie; { boost::tie(ib, ie) = boost::vertices(g); std::cout << *ib++ << std::endl; // OK std::cout << *ib++ << std::endl; // OK assert(ib == ie); } { boost::tie(ib, ie) = boost::vertices(g); boost::reverse_iterator<boost::graph_traits<graph_type>::vertex_iterator> rib(ie); boost::reverse_iterator<boost::graph_traits<graph_type>::vertex_iterator> rie(ib); std::cout << *rib++ << std::endl; // OK std::cout << *rib++ << std::endl; // OK assert(rib == rie); } } void test_csr_graph() { typedef boost::compressed_sparse_row_graph<> graph_type; std::pair<int, int> e(0, 1); std::pair<int, int> es[] = { e }; graph_type g(boost::edges_are_unsorted, &es[0], &es[1], 2); boost::graph_traits<graph_type>::vertex_iterator ib, ie; { boost::tie(ib, ie) = boost::vertices(g); std::cout << *ib++ << std::endl; // OK std::cout << *ib++ << std::endl; // OK assert(ib == ie); } { boost::tie(ib, ie) = boost::vertices(g); boost::reverse_iterator<boost::graph_traits<graph_type>::vertex_iterator> rib(ie); boost::reverse_iterator<boost::graph_traits<graph_type>::vertex_iterator> rie(ib); std::cout << *rib++ << std::endl; // NG Why? Line 45 std::cout << *rib++ << std::endl; // NG Why? Line 46 assert(rib == rie); } { boost::tie(ib, ie) = boost::vertices(g); std::cout << *--ie << std::endl; // OK std::cout << *--ie << std::endl; // OK assert(ib == ie); } } int main() { test_graph(); test_csr_graph(); } ------------ end ------------- Why does the invalid memory access occur? Am I misusing the libraries? Thanks, Takatoshi

5 10

[type_erasure] ODR violation promotion
by Vicente J. Botet Escriba 10 Sep '11

10 Sep '11

Hi Steven, I'm interested in your TypeErasure library. Where can I find the on going version? The example for concept map seams not complete, as the specialization for less_than_comparable<std::type_info> is not used in any type erasure type. Could you complete it? Before the Boost.Conversion review someone signaled that the Boost.Conversion review was promoting ODR violations as two libraries could specialize a conversion for types S and T and make them incompatible for an end user as the ODR is violated. I think that your library suffer from the same issue, when two libraries need to specialize a concept provided by the library for a 3rd part concrete class using the proposed concept map mechanism. Do you agree? If not, how do the library avoids this kind of issue? Best, Vicente

3 10

[fusion] Algorithm/auxillary documentation
by Daniel James 10 Sep '11

10 Sep '11

Hi, The generated documentation for the algorithm/auxillary section hasn't been checked in. It should be at: http://svn.boost.org/svn/boost/trunk/libs/fusion/doc/html/fusion/algorithm/… http://svn.boost.org/svn/boost/trunk/libs/fusion/doc/html/fusion/algorithm/… Daniel

4 10

[Review] Boost.Endian i/o
by Vicente J. Botet Escriba 10 Sep '11

10 Sep '11

Hi, previous releases of Boost.Endian included a binary stream. Is there something else that can be used to get the same behavior? Best, Vicente

2 1

[Endian] Unaligned fields in packed structs
by Phil Endecott 10 Sep '11

10 Sep '11

Dear All, One of my all-time worst bugs was due to calling htonl() on an unaligned field in a packed struct. It worked in debug mode but not in production code, and there were no compiler warnings about the broken alignment requirement. So I thought I'd try this: inline void inplace_byteswap(uint32_t& val) { val = (val>>24) | ((val>>8) & 0x0000ff00) | ((val<<8) & 0x00ff0000) | (val<<24); } struct S { uint16_t a; uint32_t b; } __attribute__ ((packed)); int main() { S s; s.b = 0x12345678; byteswap(s.b); } This fails to compile: "error: cannot bind packed field ‘s.S::b’ to ‘uint32_t& {aka unsigned int&}’". So it's good that it doesn't just fail unpredictably at runtime like my old nightmare, but it's not ideal. If instead I write: inline uint32_t byteswap(uint32_t val) { return (val>>24) | ((val>>8) & 0x0000ff00) | ((val<<8) & 0x00ff0000) | (val<<24); } ... s.b = byteswap(s.b); ... then of course it does work; the unaligned accesses don't "escape" from where the compiler knows about them and can apply fixups. Anyway, before I tried this I was already wondering about the choice of function signatures: void endian::reorder(T&); // in-place byteswap void endian::reorder(T src, T& dest); // out-of-place byteswap What is the rationale (or precedent) for these and not T endian::reorder(T); ? If sin(theta) returns its result, why shouldn't reorder(val) do so too? Regards, Phil.

3 4

[boost/foreach] What is wrong with BOOST_FOREACH(const std::string &name, m_modules)?
by Demetrio Car 10 Sep '11

10 Sep '11

I am trying to compile this example http://www.boost.org/doc/libs/1_42_0/doc/html/boost_propertytree/tutorial.h… and I am getting the error "/usr/local/boost_1_47_0/boost/property_tree/detail/ptree_implementation.hpp:795:54: error: request for member ‘put_value’ in ‘tr’, which is of non-class type ‘bool’" in this line: BOOST_FOREACH(const std::string &name, m_modules){ pt.put("debug.modules.module", name, true); } My full error message is: make all Building file: ../src/Boost_property_tree.cpp Invoking: GCC C++ Compiler g++ -I/home/mori/Demetrio/WSs/Test/VanManagerParser/json_spirit -I/usr/local/boost_1_47_0/ -I/usr/local/boost_1_47_0/boost/spirit -I/usr/local/curl-7.21.7/ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/Boost_property_tree.d" -MT"src/Boost_property_tree.d" -o "src/Boost_property_tree.o" "../src/Boost_property_tree.cpp" ../src/Boost_property_tree.cpp: In member function ‘void debug_settings::save(const std::string&)’: ../src/Boost_property_tree.cpp:80:5: error: invalid initialization of reference of type ‘std::string&’ from expression of type ‘const std::basic_string<char>’ In file included from /usr/local/boost_1_47_0/boost/property_tree/ptree.hpp:516:0, from ../src/Boost_property_tree.cpp:4: /usr/local/boost_1_47_0/boost/property_tree/detail/ptree_implementation.hpp: In member function ‘void boost::property_tree::basic_ptree<Key, Data, KeyCompare>::put_value(const Type&, Translator) [with Type = std::basic_string<char>, Translator = bool, Key = std::basic_string<char>, Data = std::basic_string<char>, KeyCompare = std::less<std::basic_string<char> >]’: /usr/local/boost_1_47_0/boost/property_tree/detail/ptree_implementation.hpp:817:13: instantiated from ‘boost::property_tree::basic_ptree<K, D, C>& boost::property_tree::basic_ptree<Key, Data, KeyCompare>::put(boost::property_tree::basic_ptree<Key, Data, KeyCompare>::path_type&, const Type&, Translator) [with Type = std::basic_string<char>, Translator = bool, Key = std::basic_string<char>, Data = std::basic_string<char>, KeyCompare = std::less<std::basic_string<char> >, boost::property_tree::basic_ptree<Key, Data, KeyCompare>::path_type = boost::property_tree::string_path<std::basic_string<char>, boost::property_tree::id_translator<std::basic_string<char> > >]’ ../src/Boost_property_tree.cpp:81:50: instantiated from here /usr/local/boost_1_47_0/boost/property_tree/detail/ptree_implementation.hpp:795:54: error: request for member ‘put_value’ in ‘tr’, which is of non-class type ‘bool’ make: *** [src/Boost_property_tree.o] Error 1 **** Build Finished ****

4 5