November 2004 - Boost - lists.preview.boost.org

[aligned_storage] problem for GCC 3.2 and proposed solution
by Joaquín Mª López Muñoz 26 Nov '04

26 Nov '04

The following program: #include <boost/aligned_storage.hpp> struct foo { foo(int x){} private: boost::aligned_storage<sizeof(int)> a; }; int main() { foo f(5); return 0; } fails in GCC 3.2 20020927 with the error: /usr/local/boost_1_32_0/boost/aligned_storage.hpp: In function `int main()': /usr/local/boost_1_32_0/boost/aligned_storage.hpp:75: ` boost::aligned_storage<size_, alignment_>::aligned_storage(const boost::aligned_storage<size_, alignment_>&) [with unsigned int size_ = 4, unsigned int alignment_ = 0ffffffff]' is private Digging into aligned_storage.hpp, I find the following workaround: #if !BOOST_WORKAROUND(__GNUC__, <= 2) private: // noncopyable aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); #else // gcc2.x public: // _should_ be noncopyable, but GCC compiler emits error aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); #endif // gcc2.x workaround So, it seems like the problem was known but incorrectly assumed to affect GCC 2.x only. Anyone objects to extending the workaround to GCC 3.x? It remains to know whether this problem (that seems like an incorrect application of the copy ellision rules) persists in GCC 3.4.x, and in case it is fixed, which last version is for which we should have the workaround. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

date_time from HEAD
by Victor A. Wagner Jr. 26 Nov '04

26 Nov '04

I've gone back to running regression tests from CVS HEAD, but the results don't seem to be displayed anywhere online. I've discovered in compiling my own programs, that there appears to be me a missing #include <boost/shared_ptr> missing from time_clock.hpp (also microsocond_time_clock.hpp?? .. I don't use it so I cannot tell) Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

[patch] Fix for Boost.Test (bad XML format)
by Ferdinand Prantl 26 Nov '04

26 Nov '04

Hello, here we are yet another one fix for Boost.Test. Ending tangs of TestCase and TestSuite were accidentally extended with a dangling attribute value, e.g.: </TestSuite="UnicodeTest"> The fix for supplied_log_formatters.cpp is attached and it's quite clear. Apparently my former fixes did no get into 1.32; they help only HP compiler anyway, and maybe only the version I use. This one is more serious ;-) F. -----Original Message----- From: Ferdinand Prantl Sent: Friday, November 05, 2004 12:35 To: boost(a)lists.boost.org Subject: Compile fix for Boost.Test for aCC on HP-UX Hello, you can find a small fix for boost/test/detail/basic_cstring/basic_cstring.hpp attached and a dirty workaround for a compiler bug in aCC for boost/test/unit_test_suite.hpp. As of the latter; the compiler seems to get confused by equal names in different namespaces and classes; renaming Impl helps or making the previous structure friend helps too (this I chose to minimize the change). Ferda HP-UX B.11.11 U 9000/800 aCC: HP ANSI C++ B3910B A.03.37 <<basic_cstring.hpp.diff>>

1 0

Re: Boost Sandbox layout?
by Rene Rivera 26 Nov '04

26 Nov '04

Any comments on this from the Boost Sandbox admins, or anyone? -------- Original Message -------- Subject: Re: Boost Sandbox layout? Date: Wed, 17 Nov 2004 18:41:58 -0600 David Abrahams wrote: > Rene Rivera <grafik.list(a)redshift-software.com> writes: > >>Was there ever a discussion as to the layout? (A cursory search did >>not reveal anything) > > I like what I _think_ you're suggesting we actually should do, but > would you mind spelling it out for everyone's benefit? I was trying not to prejudice the conversation if there was already reasons for the current layout... But since you ask :-) I think it would more beneficial to have each library in an individual sub directory of the boost-sandbox. Each library would still be required to follow the regular Boost layout within itself. For example I'm putting together the warnings submission and it would be nice to set it up like this: /boost-sandbox/warnings /boost/utility/warnings.hpp /libs/utility /docs/warnings.html /test /Jamfile /nowarn_unused_var_test.cpp Having the isolated subdir would remove the 3 drawbacks I mentioned. But itself has some drawbacks: 1) Some of the setup files would be duplicated. Like the boost.png, Jamfile, Jamrules, and boost-build.jam at the "top" level. But at the same time it means that the library would be truly standalone. 2) An eventual long list of directories right at the top. One advantage is the reduce complexity of management by the library authors. As it would be much easier to do things like remove a library from the sandbox after it's been accepted into Boost, a single recursive cvs remove and commit instead of finding all the files and dirs. It might even be possible to setup some form of script automation to make snapshots of the individual libraries automatically available (without CVS access). -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

5 7

[fsm] Adapted to 1.32
by Andreas Huber 25 Nov '04

25 Nov '04

Dear Boosters The fsm submission has been adapted to the 1.32 release. The zip can be found here: http://boost-sandbox.sf.net/fsm.zip The docs are also available online: http://boost-sandbox.sf.net/libs/fsm Feedback is highly welcome! Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

interest in a type_iterator (cast_iterator) ?
by troy d. straszheim 25 Nov '04

25 Nov '04

I'm wondering if there is any interest in a "type_iterator", built on top of the iterator_adaptor. If so I'll send it out. It is a kind of combination of transform_iterator and filter_iterator, where the transform is a cast, and the filter predicate is whether or not each entry in the container passes the cast. This you would want to do when iterating over heterogenous containers (where you are forced to reconstruct type information by downcasting) or containers of boost::any. I was going to call it downcast_iterator but the boost::any stuff isn't a downcast, so I came up with type_iterator. Maybe cast_iterator is better? Generally it looks like this type_iterator<TypeThatIWant, UnderlyingIterator> Here's an example: struct Base { virtual ~Base() {} }; struct Derived : public Base { virtual ~Derived(){}; virtual void OnlyDerivedHasThis(){} }; vector<Base*> v; // love boost::assign v += new Base, new Derived, new Base, ... etc. type_iterator<Derived,vector<Base*>::iterator> iter = make_type_iterator<Derived>(v.begin(), v.end()); while (iter.base() != iter.end()) { (*iter)->OnlyDerivedHasThis(); ++iter; } In order to cooperate with associative containers, containers of shared_ptr's and so forth, the type_iterator maps the type of the underlying iterator (and the cast used) like this: underlying iterator's type_iterator's cast reference_type reference_type ----------------------------------------------------------------------------- Base*& Derived*& dynamic_cast<> shared_ptr<Base>& shared_ptr<Derived>& dynamic_pointer_cast<> any& Derived*& any_cast<> pair<T,Base*>& pair<T,Derived*>& dynamic_cast<> pair<T,shared_ptr<Base> >& pair<T,shared_ptr<Derived> >& dynamic_pointer_cast<> pair<T,any>& pair<T,Derived*>& any_cast<> For instance: type_iterator< Derived, std::map<string,shared_ptr<Base> > > iter; *iter <= returns type pair<string,shared_ptr<Derived> >& I'm sure there are things that need changing, (for instance, should the "any" map to Derived* or just Derived? Should it incorporate the behavior of indirect_iterator and do an extra dereference? Dunno.) I'm just wondering if there is interest before I generalize too far beyond what my client needs. DISCLAIMER: it's widely believed that the need to iterate like this (or the need to downcast at all) indicates a lousy inheritance hierarchy and that in these cases the desire to downcast should be removed via improving the base classes. I hope I don't provoke any lectures on the evils of downcasting: this iterator is not intended to substitute for good class design... cheers, troy d. straszheim

1 0

Boost Shmem-Shared memory library first archive available
by Ion Gaztañaga 25 Nov '04

25 Nov '04

Hello to all, As promised two weeks ago, I have a first rough version of shared memory library in Yahoo Files. I've renamed and reenginered the classes from my STL in shared memory article and boostified almost all parts. The file is in: http://groups.yahoo.com/group/boost/files/boost.shmem.zip Shared memory mutex interface is taken from Boost Threads and scoped locks are needed to lock the mutexes. Since thread scoped locks can't be used from single threaded processes due to header checks, I've cloned them in Boost Shmem, but I would want to reuse thread locks if this library goes on. The offset smart pointer takes much of its interface from boost smart pointers. Boost config is used to build the different dll versions with auto-link and some boost utilities are used (noncopyable for example). This version uses templatized shared memory front-end so that a new shared memory management allocation can be used without changing existing code. In general, I've tried to all that I think it was necessary to adapt to boost, although surely there are many flaws here. The boost shmem jamfile builds for VC-7_1 in WinXP and gcc 3.4.1 in Mandrake 10.1. I've put several test and example files, although my poor jam knowledge makes that tests can only be build for windows using bjam (i don't know how to pass -l link specific options when building in linux to link with librt.a, sorry). Under proj directory there are some VC .NET IDE files to build the library, examples and tests and also a Makefile to build all under linux). I've also documented almost all files using doxygen style and the reference can be build using bjam --v2. If this library goes on, I plan to build a complete boostbook, since I've been reading all the documentation from boost utils. For now, there is a single page help as a tutorial/internal explanation. I would to know if those people that saw the library idea as interesting need any more features for this first version. Francis Andre needs some more sofisticated options and I would like to work with him for a more elaborated version if this library is accepted for boost. Francis suggested compatibility with boost.serialization and I would need some help with that. For this first and surely far from acceptable version I would like receive any comment you like regarding dessign, interface, etc... Help with bjam for building all correctly will be appreciated. I've put some attention in exception handling but surely there will be some problems due to my lack of experience in this area. If anyone wants to colaborate in any aspect of this library, please let me know, I'm totally open for this. Regards, Ion Gaztañaga

3 2

[signals] Replacing a connected slot
by Jody Hagins 25 Nov '04

25 Nov '04

I have a class that needs to react to a particular signal. However, the manner in which it handles the signal is state dependent. I would, therefore, like to change the connected slot when necessary. In general, this is not a problem. However, changing the connection inside another slot is problematic. For example, assume that Foo::bar() is already connected to signal_, and signal_() is called... void Foo:: bar() { std::cout << "Foo::bar()\n"; current_connection_.disconnect(); current_connection_ = signal_.connect( boost::bind(&Foo::bar1, this)); } void Foo:: bar1() { std::cout << "Foo::bar1()\n"; } What I want to happen is that bar() will be called, then it will be disconnected, and bar1 will then be connected in its place. For example, given this calling sequence... signal_(); signal_(); I expect to see... Foo::bar() Foo::bar1() However, sometimes I may see... Foo::bar() Foo::bar1() Foo::bar1() because bar1() MAY get connected AFTER the place where bar() used to be connected, resulting in it also being called for the same signal invocation. What I think I want is a way to "replace" a connected slot, without disturbing anything else... void Foo:: bar() { std::cout << "Foo::bar()\n"; current_connection_.replace_slot(&Foo::bar1, this); } This is especially important if the slot is originally connected with... signal_.connect( invocation_level, boost::bind(&Foo::bar1, this)); because I see no way to retrieve the ordering information from the connection. In any event, how do you suggest I "replace" a conected slot, while still guaranteeing that the "connection" is invoked exactly once? Thanks!!!

2 3

Re: Boost Shmem-Shared memory library first archiveavailable
by ION_G_M 25 Nov '04

25 Nov '04

Thank you Pavel for your comments, I would like to comment on some things >1. The HTML documentation does't allow to change font in browser. >2. End of document can be marked so it doesn't > look like cut in half during transmission. >3. docs 3.2: Sorry for errors and bad html. It was generated from MS Word so I will try to rewrite it using plan html. I'll change that shortly. >4. Example in 3.2: the "alignement" parameter in > segment.create() isn't found in code. I can't find the error you mention, I've just downloaded the zip file and 3.2 does not have any example. In 4.2 segment.create is missing a ",". >5. Example in 4.2: > segment.named_new<MyType> > ("MyType instance", /*name of the object*/ > 10 /*number of elements*/, > false /*if previously present, return error*/, > 0 /*ctor first argument*/, > 0 /*ctor second argument*/); a.It returns false. Exceptions are used only to indicate memory errors throwing bad_alloc. You are right there is info missing here. I will add more documentation in examples. b.If you find this approach more useful, I have no problem. I really don't like the boolean parameter, but I wanted to have a "find or create" functionality. If you like a find_or_named_new<>() additional function to indicate that approach I find it more clear than with a boolean parameters. c.The syntax you propose is better, no doubt. I don't have experience with it so to implement this I suppose named_new<> should return an proxy object with overloaded operator()() functions. Is that right? If you want to help me I'm open. If boosters prefer throwing exceptions instead or returning false no problem here. A problem I see is that my interface allows creating an array like new[]. Do you consider this necessary? You prefer a different function? Maybe the proxy object should have an operator[] that can be used to specify array allocation? > std::pair< MyType *, std::size_t> res = > segment.find_named_new< MyType > ("MyType instance"); >Why do I need the "size"? Doesn't a type have >always the same size regardless? Size contains the number of elements in case you allocate an array. with segment.named_new<MyType> ("MyType instance", /*name of the object*/ 10 /*number of elements*/, ... you allocate an array of 10 elements. so it will return 10. >6. Could you use namespace shmem_detail or so > instead of "detal" to avoid possible clashes? No problem. I've seen detail namespace in some projects so I thought it was not a problem. detail namespace is inside boost::shmem namespace so it wouldn't be necessary. You find it necessary even if detail namespace is really boost::shmem::detail? >7. exceptions.hpp: >a) file name should be shmem_exceptions.hpp or so No problem >b) does it make sense to have common base > for both exceptions there? My exception handling experience is null, so I based all in thread exception examples, where lock_error inherits from thread_exception. No problem changing this is you find it necessary. >8. offset_ptr.hpp: full_offset_ptr class >a) using char as de-facto bool class has usually > no practical advantage and may be actually slowe. No problem. You are right, with all platforms using 4 byte alignment bool and char use the same space and it can be slower I suppose due to mask operations. >b) The flag could be eliminated completely. > If m_offset == 0 it is NULL pointer and > no data allocated in shmem will starts > on the beginning. This would also eliminate > need for min_offset_ptr. The offset indicates the distance between the pointee and the this pointer of offset_ptr, so m_offset == 0 indicates a pointer pointing to itself and this is quite common in STL containers when empty, since next pointer in the end node points to end node, resulting in a m_offset = 0. Obviously this is different from a null pointer. If I change the meaning of m_offset to offset from the beginning of the segment I need the base address stored somewhere (and the base address is different in each process), so that I can convert from offset_ptr<A> to A* using get() or the constructor. Using my approach I can convert between A* and offset_ptr<A> without any additional data. Obviously, your approach is more performance friendly since m_offset does not need to be changed with each assignment and constructor. If boost people find the additional member as a waste comparing to A* <-> offset_ptr<A> conversions I would change it but I find my approach quite useful, since I don't want to deal with base addresses stored somewhere for each process when building a offset_ptr. >c) swap() could be added and other operators. Ok. I will add it. Which other operator you miss? >9. Maybe the protection of mutext from shared ptr > lib could be worked around I don't understand your point. Could you give me an example please? >10. The example in 4.3 uses very dirty C-like > approach with casts. Cannot it be rewritten > in C++ way with overloaded new? If you refer to (list_node*)segment.allocate(...) line, segment in this case is a low-level void* returning function. If you prefer an allocate<Type> approach, I don't have any problem, but remember that this segment object is of type shmem_alloc which allocs raw memory, something like when writing your own void* operator new(size_t size) for a class. If you have I workaround in mind, please let me know. >11. Some source files use Unix line ends, > some DOS line ends. Just bit strange. It's because I've tested and changed things in both windows and linux. I'll try to convert all to a common line feed. >12. The simple algorithm to find fitting memory > block may not be adequate for high-performance > apps (who are most likely to use shared > memory). You are right. The default algorithm is space-friendly, which I thought it was more important than performance for fixed size segments. You can write your own algorithm and use it since shmem_alloc is a typedef of basic_shmem_alloc<default_algo>. If you prefer another algo like segregated lists, I can try to write it, so that the user can choose the allocation algorithm. I've written the pooled allocator due to default algorithm slowness. >13. Can be be possible to identify named objects > with something else than C string? Say > wchar_t* or numeral or other templated type? Well, I've chosen a c string as an universal name, but other types could be used. Do you think that the key type should be templatized? I think that an integer key can speed up a lot searches but I have to think about which classes should be templatized. When storing other type of strings (for example std::string, I would need to build an allocator for strings in shared memory but also a std::string since it's probable that current STL won't work with Shemem STL allocator). The key meaning would be different since right now, I copy the string to shared memory but with configurable key type things are more complicated. >14. What I would like to see: >a) avoiding shmem specific containers/mutexes/etc > as much as possible. I think you can't avoid mutexes if you want to guarantee atomic memory allocation, since I have no skills to write a lock-free memory allocator. Regarding to containers, it was no my intention to write them, but I needed some of them to store name-buffer mappings and a node container to test the pooled allocator in several systems. For now, I have only succeed using shmem STL allocators in a modified Dinkum STL. STLport and libstc++ use suppose allocator::pointer to be a raw pointer, so I can't use STL containers. I've chosen internal containers to be public because I find them very useful, but if this is not accepted they can be used only for internal uses and removed from documentation. Regarding mutexes and etc... can you be more explicit? I propose mutexes to be general. If boost want to implement process-shared mutexes in other way, say in another library, I would use them, but for the moment, this is all that I have. >b) ability to "equalize" shared memory features I would need some help in this because my operating system knowledge is very limited. Mimic-ing UNIX way in windows can be very difficult, I think, unless you use a mapped file. I would need some serious help here. >c) support for inheritance in shmem using object > factories, e.g. like one in Classloader > http://s11n.net/papers/classloading_cpp.html I'll check it. Thanks for the url. >d) support for "transactions": I would like to My knowledge in transaction world is null so I can't help you with that. I suppose that a shared memory condition variable should be very interesting to notify events to other processes, but I'm afraid this is a work for more skilled programmers than me (people from boost::threads, perhaps?). As far as I know in windows is difficult to implement a shared memory condition variable, pthreads-win32 does no support it and I don't know how cygwin solves this. Thank you again for all your comments. I would like to make some changes you've suggested, so I will wait your response regarding open issues and comments from other boosters before doing any change. Regards, Ion

3 4

[iostreams(jonathan)] - using with 1.32
by Jeff Flinn 24 Nov '04

24 Nov '04

Jonathan, Do you have a version that works with the 1.32 release? If not any suggestions on modifications for use with 1.32? The two main items I see are mpl/apply_if.h and utility/select_by_size.hpp. I've change the includes for ...mpl/apply_if.h to mpl/eval_if.h and occurences of apply_if to mpl::eval_if. Is that sufficient? I've copied boost_1_31_0/utility/select_by_size.hpp to boost_1_32_0/utility/select_by_size.hpp . Is this sufficient? I've got some other compile errors but I'm not sure if they are just downstream errors caused by these issues. Thanks, Jeff

3 7