- Boost - lists.boost.org

[locale] Premission to merge clang bugfix changeset to release tree
by Artyom Beilis 02 Nov '11

02 Nov '11

Hello, I'd like to ask a permission to merge a changeset 75174 from trunk to release tree. It is a fix of build issue under clang-2.9 and clang-3.0. See: https://svn.boost.org/trac/boost/changeset/75174 The changeset itself: ------------------------- Index: /trunk/libs/locale/src/posix/codecvt.cpp =================================================================== --- /trunk/libs/locale/src/posix/codecvt.cpp (revision 73382) +++ /trunk/libs/locale/src/posix/codecvt.cpp (revision 75174) @@ -135,5 +135,5 @@ // maybe illegal or may be double byte - char inseq[3] = {seq0 , begin[1], 0}; + char inseq[3] = { static_cast<char>(seq0) , begin[1], 0}; char *inbuf = inseq; size_t insize = 3; ------------------------- It solves build issues as I can see at trunk tests. Thanks, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

3 2

[atomic] comments
by Tim Blechmann 01 Nov '11

01 Nov '11

hi helge and others, ... has been rather quiet about the boost.atomic review, so i want to raise a view issues: shared memory support: the fallback implementation relies on the spinlock pool that also used by the smart pointers. however this pool is per-process, so the fallback implementation won't work in shared memory. can this be changed/fixed? atomic::is_lock_free(): is_lock_free is set to either `true' or `false'. however in some cases, there are alignment constraints (iirc, 64bit atomics on ia32/x86_64 require a 64bit alignment). afaict there are not precautions to take care of this, are there? compile-time vs run-time dispatching: some instructions are not available on every CPU of a specific architecture. e.g. cmpxchg8b or cmpxchg16b are not available on all ia32/x86_64 cpus. i would appreciate if these instructions would not be used before performing a CPUID check, whether these instructions are really available (at least in a legacy mode) cmpxchg16b: currently cmpxchg16b doesn't seem to be supported. this instruction is required for some lock-free data structures (e.g. there is a dequeue algorithm, that requires a pair of tagged pointers). maybe this can be a starting point to discuss boost.atomic ... cheers, tim

6 38

Re: [boost] [atomic] comments
by Helge Bahmann 01 Nov '11

01 Nov '11

> > > > > e.g. i would not trust on accessing sockets from a > > > > > real-time thread. > > > > > > > > what makes you believe that message channels in real-time systems > > > > were > > > > designed so dumb as to make them unusable for real-time purposes? > > > > > > life would be so much easier for me, if the users of my software would > > > not run on off-the-shelf operating systems ;) > > > > and what makes you believe that the performance characteristics of > > sockets in off-the-shelf operating systems is unsuitable for real-time, > > while the process scheduling characteristics of process scheduling in > > off-the-shelf operating systems is suitable for real-time? > > i cannot comment on windows, but both osx and linux provide ways to > schedule a thread at a priority that it won't be preempted by any other > thread, so the process scheduler won't interfere. that answers the second part but not the first (and is getting off-topic from atomic operations) > > > > right, but the standard implementation for gcc does not use a > > > > spinlock > > > > per object (see __atomic_flag_for_address) which turns all of this > > > > moot - there is NO guarantee for std::atomic to be safe > > > > interprocess, period> > > > > > > well, i'd say this is a problem of gcc's implementation of std::atomic. > > > this doesn't justify that boost.atomic does not follow the suggestion > > > of the standard. > > > > the standard says "should" not "must" -- the gcc guys have not made this > > decision without good reasons, and I agree with these reasons > > > > note that there is also trouble lurking with run-time selection of > > whether something like atomic<uint64_t> is atomic via cmpxchg8b: do you > > really want to make this at minimum 12 bytes in size (though effectively > > occupying 16 due to alignment) just to save the room for the > > rarely-if-ever used per-object spinlock? same with atomic<128> and > > cmpxchg16b ? > > i don't really care about the size of an atomic<>. but I *do* care and believe it or not there are people writing applications that are memory-bound (doubling the overhead of the reference count in each of several millions of objects is *not* funny) > one other point for > runtime selection is compatibility. e.g. you may have two binaries, one is > compiled with support for double-width CAS, the other one without. with > compile-time dispatching the behavior would be undefined, with run-time > selection, it would be handled gracefully ... I don't quite understand the point -- quite obviously nothing good will happen if the applications do not agree on a protocol, and there is nothing that can be salvaged if they do agree on the objects being lock-free, fine if they do agree on the objects not being lock-free, well then explicit locking is faster anyways and you should use your "locked" reference implementation of the data structure that you surely wrote to run suitable regression tests of your lock-free data structure > > 2. What is wrong with implementing boost::interprocess::atomic<T> that > > specializes to boost::atomic<T> when possible and uses an interprocess > > lock otherwise? > > will you provide an implementation? people were asking for > boost::interprocess support during the boost.lockfree review. the only > missing feature is the atomic<> implementation. no problem Best regards Helge

1 0

[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