- Boost - lists.boost.org

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

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Puverle, Tomas (IT) 22 Sep '04

22 Sep '04

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? I have implemented this for our internal managed pointer class, and our code needs to run on a few different platforms (At the moment I am discussing the posibility of contributing to boost with our legal dept - note that it wasn't until recently that I was allowed to even post to an external mail group. Before that I used to follow boost quite closely) > 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. 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. > 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. The ones that come with Linux in sys/atomic.h tend to be quite inconsistent, not to mention that many are implemented in such a way that they don't return the new/old value. On Solaris, sys/atomic.h ops are not available in user space anyway, not to mention that they are declared as extern - so they can't be inlined. > 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. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

1 0

RE: [boost] 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: > > [] > > > There's one possible problem I noticed, which is that an allocated > > buffer will be aligned properly for boost::detail::atomic_count but > > perhaps might not be aligned properly for char_t (or to whatever > > buffer_storage_alignment specifies). Let me apply the James Kanze > > test [*]: is it safe to create a const_string<double> on a SPARC? > > > > [*] See <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670> if you > > don't know what I'm talking about. > > I fixed it using the union trick. > > 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. The default allocator's allocate() member function uses ::operator new(std::size_t) so any specialisation could be used to allocate memory aligned for any type. 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.

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: > > Also, why not including windows.h directly, like this: > > #define WIN32_LEAN_AND_MEAN > > #include <windows.h> > > I believe WIN32_EXTRA_LEAN may be even better. > > > <side-note> > > From my tests it seems your version as is now fails to link > > for gcc (unresolved external > > _InterlockedIncrement/_InterlockedDecrement). > > However, if #including <windows.h> and use > > InterlockedIncrement/Decrement - they work. > > </side-note> > > That is not suprising - Interlocked* are parts of the Win32 API. > > In fact, it has been a complete mistery to me as to why boost doesn't > use atomic operations for its ref counting. The mutex on the counter > was one of the big reasons why people here decided not to use > shared_ptr. 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. Second, shared_ptr has two counters and updating them safely without using a lock requires some subtlety. 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 don't think they are really public though, so this might be a bad idea.

1 0

Multimethods Design
by Jesse Jones 22 Sep '04

22 Sep '04

There seems to be some interest in my multimethod library so I thought I'd post a message describing the design in more detail. In this message I'll focus on the API and ignore the implementation except when it affects the API. I may post another message later focusing on the implementation. The vault is still full, so if you want to look at the code go to <https://sourceforge.net/projects/multimethods/>. The draft proposal to add multimethods as a core feature is also interesting: <http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1529.html#1.1.1>. Also <http://www.op59.net/accu-2003-multimethods.html> has some info on why multimethods are a Good Thing. The design is actually quite simple. Function objects (aka methods) may be added to a generic function object. Then the generic function can be called with a set of actual arguments. It will then dispatch to the most specialized method using the dynamic type of the actual arguments. One way to think of this is as a form of runtime overloading. The API for generic functions looks like this (using an arity 2 function as an example): template <typename Result, typename Formal1, typename Formal2> class generic_function2 : public detail::base_generic_function< Result > { When this is instantiated it creates a function object. Currently the arity is encoded in the class name, but presumably boost::preprocessor could be used to allow users to instantiate the classes in the way that boost:;function does. base_generic_function is a helper class that does all of the heavy lifting. Method formal arguments and actual argument types must be compatible with Formal1 and Formal2 (this is checked at compile time). The formal argument types may also be any_type which means that the formal argument in the methods for that position may be of any type. The API is as follows. First there are some standard typedefs: typedef Result result_type; typedef typename Formal1 first_argument_type; typedef typename Formal2 second_argument_type; A default ctor (and compiler provided copy ctor/assignment op): generic_function2(); Members to add methods: template <typename R, typename T1, typename T2> generic_function2& operator<<(R (*method)(T1, T2)); template <typename Functor> generic_function2& operator<<(Functor method); If the method has the same arguments as an existing method a std::runtime_error exception is thrown. If the Functor version is used the functor must have result_type, first_argument_type, and second_argument_type typedefs. A member used to invoke the generic function: template <typename T1, typename T2> RESULT operator()(const T1& arg1, const T2& arg2) const; This works by building a list of the applicable methods and then sorting this list from most to least specific using the dynamic type of the actual arguments. A method A is more specific than another method B if, for a given set of actual argument, for each argument, A has a better match for the actual argument than B in at least one slot and the other arguments are no worse than B's (this is similar to the rule used for overloaded functions). Argument matching follows the usual C++ rules so derived types are better matches than base types and promotions are better matches than conversions. If no applicable methods or a most specific method cannot be found a runtime_error exception is thrown. When a method is called it may call the next most specific method using one of the following methods: RESULT next_method(); template <typename T1, typename T2> RESULT next_method(const T1& arg1, const T2& arg2); The second overload calls the next method using a new set of actual arguments, but the types of those arguments don't affect which method is called. The first overload calls the next method with the last set of actual arguments that were used. If there are no more methods or the next method is ambiguous a runtime_error exception is thrown. The only missing piece is that clients of the library must register polymorphic types if they want them to be treated polymorphically. This is done with a macro that looks like this: #define DECLARE_SUBTYPE(type, base) This seems like a simple yet flexible API, but there's probably room for improvement. For example: 0) The names "generic function" and "method" seem potentially confusing in a C++ context (they're from Dylan and (I think) CLOS). 1) There's no support for removing methods. This seems like a good idea, but it's not possible to compare arbitrary function objects so we'd probably have to add an add_method member which returned a cookie that a remove_method member would take to determine which method to remove (similar to the way boost::signal works). 2) Policy decisions like type compatibility and ordering are hardwired into the code. It might make sense to refactor these into policy classes although I'm not sure what they'd be used for. Maybe special casing smart pointers. 3) The library allows lossy conversions like floats to chars. This was done so that it world work as much like normal C++ code as possible, but it's a pretty evil thing. Maybe an option could be added that would reject such conversions. 4) boost::bind is a bit annoying because it doesn't provide the typedefs that the library requires. This is a known issue with bind and, as far as I know, isn't fixable. The workaround is to assign the result of boost:;bind to a boost:;function and add that to the generic function. 5) Method formal arguments can't be non-const reference types. The problem here is that typeid(const T&) == typeid(T&) == typeid(T). It might be possible to work around this, but the type code is already full of hacks working around typeid and type_info limitations... 6) It might be a good idea to add a member that will return a function pointer or boost:;function to the most specific method for a given set of types. This would allow users to skip the overhead of dispatching when using multimethods inside loops in some cases. -- Jesse

1 0