- Boost - lists.boost.org

[config] clang.hpp is not up-to-date
by Michel Morin 01 Nov '11

01 Nov '11

boost/config/compiler/clang.hpp is not up-to-date. For example, BOOST_NO_AUTO_DECLARATIONS is *always* defined (even if clang supports this feature). Is it worth fixing this on the release branch? P.S. I can make a patch, but before doing that I'd like to confirm whether __has_feature(cxx_auto_type) means that multi-declarator auto is supported or not. The following page says nothing about multi-declarator auto. http://clang.llvm.org/docs/LanguageExtensions.html Doug? Regards, Michel

3 4

Silly Boost.Locale default narrow string encoding in Windows
by Alf P. Steinbach 01 Nov '11

01 Nov '11

When I engage the compiler-in-my-mind to the example given at http://cppcms.sourceforge.net/boost_locale/html/ namely <code> #include <boost/locale.hpp> #include <boost/filesystem/path.hpp> #include <boost/filesystem/fstream.hpp> int main() { // Create and install global locale std::locale::global(boost::locale::generator().generate("")); // Make boost.filesystem use it boost::filesystem::path::imbue(std::locale()); // Now Works perfectly fine with UTF-8! boost::filesystem::ofstream hello("שלום.txt"); } </code> then it fails to work when the literal string is replaced with a `main` argument. A conversion is then necessary and must be added. It breaks the principle of least surprise. It breaks the principle of not paying for what you don't (want to) use. I understand, from discussions elsewhere, that the author(s) have chosen a narrow string encoding that requires inefficient & awkward conversions in all directions, for political/religious reasons. Maybe my understanding of that is faulty, that it's no longer politics & religion but outright war (and maybe that war is even over, with even Luke Skywalker dead or deadly wounded). However, I still ask: why FORCE INEFFICIENCY & AWKWARDNESS on Boost users -- why not just do it right, using the platforms' native encodings. Cheers, - Alf

9 43

[unordered] 1.48 beta1 fails to compile with MSVC 2010 SP 1, error C2027: use of undefined type 'boost::type'
by Johan Lindvall 01 Nov '11

01 Nov '11

After trying out beta 1, I am seeing some failures with unordered containers, see attached file. Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 The code compiles without problems under 1.47.0. Unfortunately, I cannot yet publish the source code that triggers this problem. Any hints where to start investigating this? -- /Johan.

2 5

[multi_array] typed subarray from raw memory
by Maxim Yanchenko 01 Nov '11

01 Nov '11

Hi, While using multi_array, I found I frequently need a way to view some memory which is a multi-dimensional array and I don't know the type of the element, but I know its size and I know that this element has a member of the type I need (and I know the offset). So I need to be able to write something like struct A { double x, y; }; void* p = mmap(...); size_t el_size = size_of_element_in_p; size_t offset = offset_of_A_inside_element; boost::multi_array_typed_view<A, NumDims> my_view(p, extents, el_size, offset ); and have a standard multi_array-compatible interface. Also, with existing multi_arrays of known types, this feature will give a way to create views of element's members (the closest we have now is a strided view but it only works if the element size is a multiple of the member size). I filed a Feature Request for multi_array (https://svn.boost.org/trac/boost/ticket/6073) but I wonder if there are any other possibilities around, and I'd also like to know what the community think of necessity of this feature. Thanks, Maxim

1 0

Re: [boost] [Tokenizer] Compile error with lots of missing binary operator statments
by Collin Day 31 Oct '11

31 Oct '11

Previously, I had posted what I thought was a bug. I did not think to do this originally, but I just tried a simple Hello World program that included boost/tokenizer.hpp. It compiled fine. I then looked at where the sample code was pulling headers from, and it appears that the download included old boost headers it was including instead of 1.47.0. I completley missed this. I apologize - and take back the error - there is none :) Thanks!

1 0

[Tokenizer] Compile error with lots of missing binary operator statments
by Collin Day 31 Oct '11

31 Oct '11

Hi all, make[1]: Entering directory `/home/collin/projects/Cpp/plugins/PluginFramework/projects/plugin_framework' mkdir -p build/Debug/GNU-Linux-x86 g++ -c -g -DPF_PLATFORM_LINUX -DAPR_DECLARE_STATIC -DAPU_DECLARE_STATIC -I../../include/ -I../../include/darwin86 -I.. -o build/Debug/GNU-Linux-x86/Path.o Path.cpp In file included from ../../include/boost/mpl/apply.hpp:23:0, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token "(" ../../include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token "(" In file included from ../../include/boost/mpl/bind.hpp:27:0, from ../../include/boost/mpl/lambda.hpp:18, from ../../include/boost/mpl/apply.hpp:25, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token "(" ../../include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token "(" In file included from ../../include/boost/mpl/lambda.hpp:18:0, from ../../include/boost/mpl/apply.hpp:25, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/bind.hpp:364:31: error: missing binary operator before token "(" ../../include/boost/mpl/bind.hpp:531:31: error: missing binary operator before token "(" In file included from ../../include/boost/mpl/lambda.hpp:22:0, from ../../include/boost/mpl/apply.hpp:25, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/aux_/full_lambda.hpp:230:31: error: missing binary operator before token "(" In file included from ../../include/boost/iterator/iterator_facade.hpp:34:0, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/apply.hpp:138:31: error: missing binary operator before token "(" make[1]: *** [build/Debug/GNU-Linux-x86/Path.o] Error 1 make[1]: Leaving directory `/home/collin/projects/Cpp/plugins/PluginFramework/projects/plugin_framework' make: *** [.build-impl] Error 2 I looked on the web, and everything that looks remotley like this said it was a problem with GCC > 4.4, but was fixed in boost 1.37. I have tried with both gcc 4.4.6 and 4.5.3. I don't think I am missing anything since it is just an include file, but I could be wrong. any help would be appreciated. I tried the boost users mailing list with no luck after a couple of days. This is a more detailed example - it looks as though the same problem repeats for many files. Would it be appropriate to file a bug if I can't find any answers here? Thanks!

1 1

[math][distributions] superfluous checking of parameters?
by Thijs (M.A.) van den Berg 31 Oct '11

31 Oct '11

The boost math distributions check validity of distribution the same parameters multiple times. E.g. in normal.hpp, class normal_distribution, the constructor, normal_distribution(RealType mean = 0, RealType sd = 1) : m_mean(mean), m_sd(sd) { // Default is a 'standard' normal distribution N01. static const char* function = "boost::math::normal_distribution<%1%>::normal_distribution"; RealType result; detail::check_scale(function, sd, &result, Policy()); detail::check_location(function, mean, &result, Policy()); } however, those are *again* checked in e.g. the pdf() non member function inline RealType pdf(const normal_distribution<RealType, Policy>& dist, const RealType& x) { ... if(false == detail::check_scale(function, sd, &result, Policy())) { return result; } ... } Why is that? It's done in a consistent way across all distributions. Can we remove the check inside the non member functions that are already checked in the constructor?

3 7

[proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Joel de Guzman 31 Oct '11

31 Oct '11

Hi, This code: #include <boost/spirit/include/qi.hpp> int main() { namespace qi = boost::spirit::qi; qi::rule<char const*> r; r %= (+qi::char_); return 0; } no longer works as expected. r %= (+qi::char_) becomes a no-op. Before it calls either: template <typename Expr> friend rule& operator%=(rule& r, Expr const& expr); // non-const version needed to suppress proto's %= kicking in template <typename Expr> friend rule& operator%=(rule& r, Expr& expr); Both defined in the rule class. Correct me if I'm wrong, but it seems the changes in proto forces us to support rvalue refs, but we are not ready for that yet and it's too late in the release cycle. Thoughts? Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com

4 4

[c++1] BOOST_NOEXCEPT macros?
by Beman Dawes 31 Oct '11

31 Oct '11

Since Boost already has BOOST_NO_NOEXCEPT and at least one compiler (GCC) supports C++11 noexcept, I'd like to start using it in Boost code. So how about a <boost/detail/noexcept.hpp> header with the usual boilerplate and this: #ifndef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT # define BOOST_NOEXCEPT_IF(Predicate) #else # define BOOST_NOEXCEPT no_except # define BOOST_NOEXCEPT_IF(Predicate) no_except(Predicate) #endif As was pointed out in a previous thread, there isn't any reliable C++03 alternative for either of these two, so nothing is attempted, and that's OK in C++03 code. We could also define BOOST_NOEXCEPT_OPERATOR(Predicate), and have it fall back to true in C++03 code. I'm not expert enough to know if that is reliable or even useful, so am not proposing it. Comments? --Beman

12 37

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

31 Oct '11

Hi, Attached is a patch to implement interprocess_condition and interprocess_mutex natively on Windows. Following are some detailed notes. I hope this isn't too awkward of a time for a submission like this - I realize there's a lot of 1.48 activity going on. One more note about the patch - IIRC, some patch utils won't create directories. This patch is intended to be applied to boost/interprocess and relies on a new directory boost/interprocess/sync/win32. Background I started out by looking at http://www.cs.wustl.edu/~schmidt/win32-cv-1.html. This appears to be from the late '90s and is the basis for ACE's cond_var implementation. The solution in section 3.4 is arguably the most correct implementation. However, this solution relies on the atomicity of SignalObjectAndWait(). SOAW() may have been atomic for unicore systems common at the time but from what I've read is not atomic for multicore (it prevents context switches on a single core but ignores concurrent threads on other cores), and win32 documentation backs this up. While the paper argues that this leads to unfairness, I don't think the solution is correct without this atomicity. Wait/signal/wait problem One problem that I came across is what I'll call the wait/signal/wait problem. Setting the state, thread 1 is waiting on a condition and thread 2 has just completed cond_signal. Without an atomic SOAW(), thread 1 may release the external mutex without obtaining the associated semaphore. Another thread, thread 3, may obtain the external lock and find the cond_var signaled and behave correspondingly. This I believe is incorrect - a waiter which obtains the external mutex after the signaler has exited signal()should not find cond_var signaled. This situation is unlikely but it makes assumptions about the scheduler that I am not comfortable with. If there's a flaw in my reasoning hopefully someone will point that out. This solution This solution is structurally somewhat similarly to the paper's solution. One point to note is that notify_one()/signal() blocks on an event in the same manner as notify_all()/broadcast(). There may be a solution which does not block the signaler while wake-processing is occurring, but I saw additional complexity on that path and decided to forgo it for the time being. I hope the solution is correct but have only testing to validate. I haven't used any formal methods to back it up. Maybe I'll construct a Petri net sometime. That's always .. fun. I throw this solution on the mercy of the court. External mutex I have yet to see production examples of cond_var use where signalers do not hold the external mutex while they signal, but this use case is allowed by POSIX. My original solution (if it is in fact a solution) relies on some particular external mutex being held by all waiters and signalers for some particular condition variable. I recently added two mutexes to solve that situation but I have only minimal testing experience with that recent addition. Use of these new locks is demarcated with WIN32_POSIX_SEMANTICS. Interprocess vs. Intraprocess I'm not sure if there is support for process-specific synchronization objects in boost.interprocess, but if support is present or was added at some future time this could help optimize things for win32. At the moment win32 interprocess mutexes rely on assigning random names to mutexes (only named mutexes can cross platform boundaries in win32), and all mutex operations have to look up the mutex by this name. Interprocess seems to have been designed primarily with pthreads in mind, and things get a little awkward on Windows in this regard. Similarly, it would be nice to be able to use the native condition variables that win32 added for Vista+, but these can't be used across processes according to the documentation, and so can't be used AFAICT for inteprocess_condition. Correspondingly, an intraprocess_mutex would be able to forgo the win32 mutex name lookups. Miscellaneous Not all interprocess tests currently pass. There are some additional variations of mutex like the upgradable/sharable, etc., that I haven't looked at in detail. I'm hoping that this patch goes far enough that it'll have some momentum. I'm happy to either complete this work in the future or help whoever undertakes the task, but I may not be able to justify much of my time to the task in the short term to my employer. I realized a little too late that I didn't keep formatting entirely consistent with the existing code. Apologies. Hopefully it's only the opening block curlies. Thanks. Dan

3 13