- 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 << " " << b << std::endl; } int main ( ) { int x = 10; boost::bind(f, 5, ::_1)(x); return 0; } >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