- Boost - lists.preview.boost.org

Standard/classic iostreams mess (was Re: Linux regressions)
by Rozental, Gennadiy 22 Sep '04

22 Sep '04

> > I added #include <ios>, which is apparently missing. > > > > Is there flag that separate standard/classic iostream (If I guess > > correctly - it should be enough) > > #ifndef BOOST_NO_STD_LOCALE > #include <ios> > #endif > > John. > (I also need to make the same fix!). It's quite obscure variable name for something very simple : switch classic/standard io. If you search through boost source you will see: 1. Check like "#if defined(__GNUC__) && (__GNUC__ < 3)" in boost/shared_ptr.hpp, boost/intrusive_ptr.hpp, boost/math/octonion.hpp boost/math/quaternion.hpp (which is incorrect BTW IMO since gcc2.95 could be using STLPort) 2. #ifndef BOOST_NO_TEMPLATE_STD_STREAM in boost/format/free_funcs.hpp and others Look also in boost/format/detail/workarounds_gcc-2.95.hpp that contains detailed workaround for gcc2.95 without STLPort 3. #if __GNUC__ < 3 in graph/detail/edge.hpp (the same comment applies as in 1.) 4. #ifdef BOOST_NO_TEMPLATED_STREAMS in boost/lambda/detail/operators.hpp and others, and Boost.Tuple headers 5. #ifdef BOOST_UBLAS_USE_BASIC_STREAM and #ifdef BOOST_UBLAS_USE_STREAM in ublas code 6. #ifndef BOOST_NO_STD_LOCALE in boost.random/detail/... several headers, Boost.Regex, 7. #if BOOST_WORKAROUND(__GNUC__, < 3) && !defined(__SGI_STL_PORT) && !defined(_STLPORT_VERSION) In Boost.Test headers 8. Boost.Variant present workarounds based on #if !defined(BOOST_NO_STD_LOCALE) in boost/detail/templated_streams.hpp 9. #ifdef BOOST_OLD_IOSTREAMS in boost/dynamic_bitset/dynamic_bitset.hpp 10. # if !defined(BOOST_IOFM_NO_BASIC_STREAM) in output formatters library currently under review. Also you could see that std::basic_ostream is used outside #ifndef BOOST_NO_STD_LOCALE and many other places where standard iostreams are used without any checks. I believe we need to put stop to this mess and force everybody use the same practice/variable(s). My vote is for BOOST_CLASSIC_IOSTREAMS, BOOST_STANDARD_IOSTREAMS. Regards, Gennadiy.

2 1

numeric_cast/MPL/vc6 conflict
by David Abrahams 22 Sep '04

22 Sep '04

The introduction of mpl::numeric_cast has caused a regression in libs\python\test\vector_indexing_suite.cpp for vc6. How shall we resolve this problem? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 4

python/detail/config.hpp bug?
by Aleksey Gurtovoy 22 Sep '04

22 Sep '04

Boost.Python fails to build with MSVC 6.x/STLPort (see http://tinyurl.com/4nl7l) due to the following (incorrect) configuration logic in "boost/python/detail/config.hpp": // The STLport puts all of the standard 'C' library names in std (as far as the // user is concerned), but without it you need a fix if you're using MSVC or // Intel C++ # if defined(BOOST_MSVC_STD_ITERATOR) # define BOOST_CSTD_ # else # define BOOST_CSTD_ std # endif The issue, as explained in "boost/config/stdlib/stlport.hpp" is that: // STLport does a good job of importing names into namespace std::, // but doesn't always get them all, define BOOST_NO_STDC_NAMESPACE, since our // workaround does not conflict with STLports: Is there a reason why we are not using BOOST_NO_STDC_NAMESPACE here? -- Aleksey Gurtovoy MetaCommunications Engineering

2 5

CW 9.3: uBlas is in a very bad state
by Stefan Slapeta 22 Sep '04

22 Sep '04

The ublas tests 1-3 are currently not compiling with cw 9.3. Tests 4 and 6 compile but do not execute (they throw a GPF), which is, because of what seems to be a defect in the build system, not reflected in the results (a general cw 9.3 problem, see http://tinyurl.com/5mlxs) Shall we mark the library unusable for this compiler (as for cw 8.3)? Stefan

2 1

Re: CW 9.3: uBlas is in a very bad state
by Michael Stevens 22 Sep '04

22 Sep '04

Stefan, > The ublas tests 1-3 are currently not compiling with cw 9.3. Interesting. This is due to a commit last night which add these swap functions to some closures. cw 9.3 seems to have multiple problems with this. The swap function should never be instantiated in test1-3. Also the instantiation is for a const type which is odd. Sadly the error message that produced do not give sufficient context to indicate where the template was instantiated like this. > Tests 4 and 6 compile but do not execute (they throw a GPF), which is, > because of what seems to be a defect in the build system, not reflected > in the results (a general cw 9.3 problem, see http://tinyurl.com/5mlxs) OH. I wondered why cw 9.3 results were so good! > Shall we mark the library unusable for this compiler (as for cw 8.3)? I will wait and gather a bit more information. Thanks. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Ben Hutchings 22 Sep '04

22 Sep '04

Tomas Puverle <Tomas.Puverle(a)morganstanley.com> wrote: > > It means that it's hard to write portable lock-free algorithms. > > Not necessarily. > Presumably you are thinking of not allowing lock-free algorithms to > compile if the primitives used are not available on the > target platform? Yes. If a lock-free algorithm depends on an atomic operation which the processor does not support natively, that operation can presumably only be implemented using a hidden global (possibly per-type) mutex - or, even worse, an "unimplemented instruction" processor exception and fix-up in the kernel. This could make the lock-free algorithm far slower than a locking algorithm that uses a very specific mutex and locks and unlocks it only once. > Presumably we could use template traits to indicate whether or not a > particular atomic operation is available on a given platform, and > then use if<>s to decide whether or not to use a lock in shared_ptr. > > Speaking of which, are there any plans to include lock-free algos in > boost? That would be something I would be very interested in... There are plans afoot to include atomic operations in the standard. I dare say Boost may be the testing ground for them, but I don't know. <snip> > > Perhaps I could put #define BOOST_STDLIB_LIBSTDCPP3 in > > <boost/config/stdlib/libstdcpp3.hpp> and then guard any use of > > <bits/atomicity.h> with #ifdef BOOST_STDLIB_LIBSTDCPP3. > > I think it would be preferable to distinguish between HW/OS > combinations as opposed to C++ lib implementations. I'm talking about using atomic operations that are included in libstdc++. I only mentioned Linux because most C++ programs built for Linux will use libstdc++ and so could take advantage of a lock- free shared_ptr implementation that depends on libstdc++. It would be less significant for other operating systems on which most people are using other libraries. > > Making shared_ptr lock-free wherever possible is indeed a great idea > > and will hopefully become a great reality! > > Yes. What release are we looking at here? I believe only bug fixes can now be committed to 1.32 so improvements to shared_ptr will have to wait for 1.33.

1 0

RE: [boost] Re: Re: immutable string
by Ben Hutchings 22 Sep '04

22 Sep '04

Maxim Yegorushkin <e-maxim(a)yandex.ru> wrote: > Ben Hutchings <ben.hutchings(a)businesswebsoftware.com> wrote: > > [] > > >> But I think there might be another solution. The standard states in > >> 5.3.4.10 that arrays of char's allocated with new expression are > >> always properly aligned for types whose size is no greater than the > >> size of the array. Does allocator<char>::allocate() have the same > >> requirement? I could not find it in my copy of the standard. <snip> > > However, the requirements for > > allocators in general (table 32 in subclause 20.1.5) say only that > > "[m]emory is allocated for n objects of type T" by the allocate() > > function. > > So, that means that there is no requirement and thus it is not > guarantied that any custom_allocator<char> returns a pointer > properly aligned for any type, right? Right.

1 0

program_options: configuring array-like objects
by Maurizio Vitale 22 Sep '04

22 Sep '04

Hi all, I'm trying to somewhat abuse the boost program_options library for configuring large simulations of digital systems. One feature that I need is the initialization of arrays (and any object supporting an operator []). For instance for a block containing a register file I'd like to be able to say things like: [block] regs[10] = 0 even nicer if the index was not contrained to be an integer. For instance [block] regs[0..5] = 1 would be an handy way for initializing a range of locations. Now, as far as I can tell, both these uses are not supported by the library. Having to modify the library itself, a quick (and obviously dirty) change would be to check for [] when parsing the option name and stuffing it as prefix to the value so that user defined parsers can take care of it. Just for clarity, what I mean is to turn: [block] regs[0..5] = 1 into: [block] regs = [0..5]1 With an appropriate type declaration for regs we can cause the appropriate user defined parser for doing the validation. So I guess I have three questions: - would be an extension to program_options to take care of the initialization of array-like object considered of general enough interest to deserve a place in the library? - if not, does the quick-and-dirty approach outlines seem viable to people familiar with the program_options library? - any other suggestions for a cleaner/more general implementation? Thanks a lot for any suggestions. Best regards, Maurizio

2 1

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Ben Hutchings 22 Sep '04

22 Sep '04

Tomas Puverle <Tomas.Puverle(a)morganstanley.com> wrote: > Ben, > > > Atomic operations are highly platform-dependent, with > > different platforms having different capabilities and many > > requiring use of assembly language rather than providing an > > API for atomic operations. > > Would that be a problem? It means that it's hard to write portable lock-free algorithms. However I don't think this is a problem for shared_ptr because it already has a portable mutex-based implementation of the counter operations which can be used as a fallback where a lock-free implementation is impracticable. <snip> > > Second, shared_ptr has two counters and updating them safely > > without using a lock requires some subtlety. > > On ia32, ia64 and amd64 you can always use DCAS. That isn't available on all IA32; it was introduced with the Pentium. Worse, on a 386SX even 32-bit atomic operations are unavailable. (This is why Windows 95 requires a 386DX and why there have been some binary compatibility problems with glibc and libstdc++ built for 386+ vs 486+.) > On Ultrasparc you could restrict the counter to 32-bits and use CAS > (64-bit). > You can add other platforms as the implementation becomes available, > but use a lock by default. Right. > > It's something > > I meant to implement but hadn't quite got round to. Perhaps > > I could make it work on g++ (and hence most Linux > > configurations) by using libstdc++'s atomic primitives? I > > No. This is not portable enough. > The problem is that libstdc++'s atomic ops come with libstdc++ which > precludes you from using other standard library implementations. Perhaps I could put #define BOOST_STDLIB_LIBSTDCPP3 in <boost/config/stdlib/libstdcpp3.hpp> and then guard any use of <bits/atomicity.h> with #ifdef BOOST_STDLIB_LIBSTDCPP3. <snip> > > don't think they are really public though, so this might be a > > bad idea. > > I think this would be a great idea, and it would make shared_ptr a lot > more acceptable at our company. I meant that using libstdc++'s atomic operations might be a bad idea. Making shared_ptr lock-free wherever possible is indeed a great idea and will hopefully become a great reality!

3 2

platform specific structures
by Matt Hurd 22 Sep '04

22 Sep '04

I'm interested in getting something like "needs_lock" below into the normal traits, perhaps as part of boost thread. It informs you whether of not an operation on such a contiguous block needs a lock to be atomic. For example, on ia32 32 bit aligned ops are atomic, on ia64 it is 64 bit. doubles on ia32 need locking to be atomic, on ia64 they don't. sizeof(void*) works generically for these two platforms as is included in the code below. A default, safety first implementation might return true always for needs lock, or perhaps, true for all sizeof's greater than a byte. "Ifdef" hell for platforms can read to readability problems and big config.hpp equivalents. An alternative is to redirect headers to generic, where possible, or platform specific headers, where necessary, but this may lead to a bit of a maintenance nightmare due to supporting similar code for different platforms even though the code is typically much more readable. Another often intertwined approach is to include a platform independent api/function layer that is then used by the library, e.g. ACE's os.h. Any suggestions on best practice for this? Regards, Matt Hurd matthurd(a)acm.org www.hurd.com.au /*_____________________________________________________________________ created: 2004-6-7 16:20 filename: needs_lock.hpp author: Matt Hurd _______________________________________________________________________*/ #ifndef NEEDS_LOCK_HPP_200467 #define NEEDS_LOCK_HPP_200467 #include <boost/type_traits.hpp> #include "boost/type_traits/is_integral.hpp" #include "boost/type_traits/is_float.hpp" #include "boost/type_traits/detail/ice_or.hpp" #include "boost/config.hpp" // should be the last #include #include "boost/type_traits/detail/bool_trait_def.hpp" namespace boost { namespace detail { template< typename T > struct needs_lock_impl { BOOST_STATIC_CONSTANT(bool, value = (sizeof(T) > sizeof( void *)) ); }; } // namespace detail BOOST_TT_AUX_BOOL_TRAIT_DEF1(needs_lock,T,::boost::detail::needs_lock_impl<T>::value) } // namespace boost #include "boost/type_traits/detail/bool_trait_undef.hpp" #endif

5 17