- Boost - lists.boost.org

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

23 Sep '04

John Torjo <john.lists(a)torjo.com> wrote: > I just took your implementation > (http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp) for shared_ptr > and use it now in win32gui (upcoming v1.4.2). Using Interlocked* for > win32 totally rocks! > > From my tests - Interlocked* are very fast. They're about twice as > slow as a raw increment (or my tests are wrong;)). > > From what I see - I think you can certainly merge them into > boost::shared_ptr. > Maybe users can select the old version or this Interlocked* version > with a certain macro - like BOOST_SHARED_PTR_USE_INTERLOCKED. > > Also, why not including windows.h directly, like this: > #define WIN32_LEAN_AND_MEAN > #include <windows.h> <snip> "Lean" is a bit of a joke. A rather smaller set of Windows definitions can be included by defining an architecture-identifying macro (e.g. _X86_ for i386) followed by: #define NOMINMAX // inhibits definition of min and max macros in // <windef.h> #include <windef.h> #undef NOMINMAX #include <stdarg.h> // <winbase.h> requires definition of va_arg #include <winbase.h> Unfortunately this still defines quite a few macros. The MSDN Library documentation of Win32 functions will tell you about any additional headers that need to be included, even though it recommends you include <windows.h> instead.

2 1

Re:[boost] Re: Standard/classic iostreams mess
by Robert Ramey 23 Sep '04

23 Sep '04

> My vote is for BOOST_CLASSIC_IOSTREAMS, BOOST_STANDARD_IOSTREAMS. How about just BOOST_NO_STANDARD_IOSTREAMS This would be inline with other boost feature macros Robert Ramey

1 0

RE: [boost] Re: Proper threading (Was: Formal review of "Output F ormatters" library beginstoday )
by Rozental, Gennadiy 22 Sep '04

22 Sep '04

> > I use Outlook. In some cases it preserve "threading". In some not. > > Do you mean Outlook Express? > > Are you receiving emails or do you use the gmane news server? > > Jeff I mean Outlook. And it's the only client allowed in our company. Gennadiy.

4 6

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