February 2011 - Boost - lists.preview.boost.org

shared_from_this() fails from boost.serialization load()
by Allan Johns 18 Feb '11

18 Feb '11

Hi, Consider class A, which contains an instance of class B, which in turn contains a weak reference to its parent A instance (note: pseudocode): class A; class B { weak_ptr<A> m_parent; } class A { shared_ptr<B> m_child; } I have a case where I am boost-serializing class A, and its load() method looks like so: template<class Archive> void A::load(Archive& ar, const unsigned int) { ar & m_child; m_child->m_parent = shared_from_this(); } Note that B does *not* serialize its m_parent member (this is by design). The problem I have is that the shared_from_this() call in A::load() fails, even though I am guaranteeing that A is serialized via a shared_ptr. Presumably boost.serialize is not placing the default-constructed instance of A into its containing shared_ptr<A>, before calling A::load(). My question is, is there any reason why boost.serialize couldn't deal with this special case, which would allow me to call shared_from_this() from load()? I don't have a workaround for this in my code, other than to resort to a raw ptr for B::m_parent. ps - I suppose you could argue that since you can't do this in A's constructor, you shouldn't be able to do it in its load() function either. However I do have a legitimate case where I need to do this... I can extrapolate on the whole situation if necessary, but I've left it out here in the interests of simplicity). Thanks boosters, Allan

1 1

BOOST_NOEXCEPT macro?
by Beman Dawes 18 Feb '11

18 Feb '11

Should we add a BOOST_NO_NOEXCEPT config macro, and then provide a header with something like: #ifdef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT throw() #else # define BOOST_NOEXCEPT noexcept #endif --Beman

7 9

[interprocess] named_mutex issues
by Sam Partington 17 Feb '11

17 Feb '11

Hello, I recently found a bug in my own implementation of named_mutex (which uses record locking) and thought that it was high time that I investigated the boost implementation to replace my own version. Unfortunately I found the documentation extremely unclear about what guarantees named_mutex makes under certain circumstances. e.g. 1) What happens if I call boost::named_mutex::remove whilst I have it opened or locked in another process. 2) What happens if the process terminates when a mutex is locked without calling the destructors? (e.g. Ctrl-C or seg fault) 3) The docs describe the mutex as "A mutex with a global name, so it can be found from different processes", what about other users? Is this intended to work or not? 4) Does ~named_mutex unlock the mutex if it is still locked? 5) What names are valid? Slashes, spaces, etc? To find these out I had to follow the implementation right down through many layers of indirection and compile time switches to discover what the underlying synchronisation mechanism was (POSIX Semaphore on linux). And of course write a couple of examples to test my interpretations. The answers on linux at least are 1) It removes the semaphore, but as it's link count is not 0 it remains and the other process keeps it's lock. Meanwhile another process can then create a new named_mutex of the same name AND lock it. Essentially messing up the whole mutual exclusion policy as two processes lock the same mutex. I don't think there is a (reasonable) solution to this and IMO this potential pitfall needs to be made clear in the docs. 2) If the process does not shutdown cleanly whilst the mutex is locked it doesn't release the lock. Another process could in theory create the lock again and unlock it again. But I don't know how it could detect this situation, unless some process is the 'master' and can initialise all state to a known state. (This doesn't apply in my use case for example) 3) This doesn't really work because the process umask means that the semaphore is likely to be created 0755 and can't be opened by other users. They get permission denied even if the mutex is not locked. a simple { int oldmask = umask(0); ... umask(oldmask); around the sem_open would solve this. 4) No the mutex is not unlocked if destroyed when locked. I thought this was a bit surprising. Unfortunately I don't suppose you can really change that now, but it should de documented. 5) slashes must not be used to conform with POSIX, and it must not be longer than MAX_PATH other platforms I don't know. I appreciate with so many platforms and different implementations it must be very difficult to document these things. But at least it should not be so hard to find out what the underlying mechanism is. Ultimately though the whole point of an abstraction library like this is to make it so that you don't have to worry about the specifics of the implementation or the platform, but to provide a common set of guarantees and specifications. Without those the abstraction layer is kind of missing the point. Another thing I found on the way is that strictly speaking the call to sem_open is undefined behaviour (at least according to POSIX.4. Programming for the real world by Bill O. Gallmeister). As you should not pass any of O_RDONLY O_WRONLY or O_RDWR. See http://books.google.co.uk/books?id=4Kb_1sKprCMC&lpg=PA432&ots=v7mIM0xVHS&dq… http://preview.tinyurl.com/5slzcu6 Although another reference I found suggested that it would be merely unspecified not undefined. I guess I will have to stick with my own implementation because 2) is incompatible with my requirements. Sam PS I tested this on boost 1.45 with the following code : #include <boost/interprocess/sync/named_mutex.hpp> #include <iostream> #include <string> using namespace boost::interprocess; int main() { named_mutex m(open_or_create, "named_mutex_test"); m.lock(); std::cout << "Lock obtained, type something + press enter:"; std::string s; std::cin >> s; m.unlock(); named_mutex::remove("named_mutex_test"); }

1 0

Adding libc++ support to boost.
by Christopher Jefferson 17 Feb '11

17 Feb '11

Hello, I want to add support for libc++, the c++ standard library attached to clang, to boost. Fixes required should not be attached to clang, as clang can use various standard libraries. Is there a standard way I should add the library, or just add the macro where needed. The best macro to use for detecting libc++ is _LIBCPP_VERSION. Hopefully the changes required will be minimal. One place where libc++ needs to be mentioned in is detail/container_fwd.hpp, as forward declarations simply don't work. Can I just attach _LIBCPP_VERSION to: #if defined(BOOST_DETAIL_NO_CONTAINER_FWD) \ || ((defined(__GLIBCPP__) || defined(__GLIBCXX__)) \ && (defined(_GLIBCXX_DEBUG) || defined(_GLIBCXX_PARALLEL))) \ || BOOST_WORKAROUND(__BORLANDC__, > 0x551) \ || BOOST_WORKAROUND(__DMC__, BOOST_TESTED_AT(0x842)) \ || (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) Or is there a better / more offical way libc++ should be worked in? Chris

4 7

[Boost-interest] C++ library for runtime-concepts (type-erasure)
by Germán Diago 17 Feb '11

17 Feb '11

Hello all. My name is Germán Diago and I'm been implementing a library for runtime concepts that I would like to submit to boost someday. It's a library that is targeting a way to be able to play well with boost.concept_check library, complementing it with the ability to hold those concepts in a runtime fashion. The target of the library is: -100% nonintrusive: -Being able to specify that a class models a concept without touching the class (via traits, not done yet). -Adapt via adl names of functions which don't match a concept for a class to be able to use that class as a concept. -Feel natural: being able as much as possible to convert from concept hierarchies as it's done for base and derived types. -Playing nicely with boost.concept_check. -Being able to specify that a class models more than one unrelated concept (via mpl::vector maybe). The features for the library, for now, just target movable and noncopyable objects, but I'll make it more general over time. I would like to hear feedback from all of you. Currently, the library can specify a runtime type that can hold objects modeling a concept. It's better to explain the workings of the library with an example, so here it goes: //Compile-time concepts namespace Concepts { template <class T> std::size_t getCapacityInMB(const T & t) { return t.getCapacityInMB(); } template <class T> void onOpen(T & t) { t.onOpen(); } template <class T> void onRemove(T & t) { t.onRemove(); } template <class T> struct Device { BOOST_CONCEPT_USAGE(Device) { t.getCapacityInMB(); } T t; static std::size_t getCapacityInMB(const T & v) { using Concepts::getCapacityInMB; return getCapacityInMB(v); } }; template <class T> struct PlugableDevice : Device<T> { BOOST_CONCEPT_USAGE(PlugableDevice) { plug_dev.onOpen(); plug_dev.onRemove(); } T plug_dev; static void onRemove(T & t) { using Concepts::onRemove; onRemove(t); } static void onOpen(T & t) { using Concepts::onOpen; onOpen(t); } }; } First, I must explain my runtime concept implementation as of now. We have a model and an interface class for each runtime concept we want to model. A concept is a class that is templated like this: template <class ConceptInterface, template <class> class Model, class BaseConcept = EmptyType, template <class> class ConceptCheckingClass = EmptyConcept> When we template this class with the ConceptInterface and with the model class, we can hold instances modeling that concept. Besides that, we can (optionally) enforce the compilance of our types with the compile-time concepts if we provide the concept checking class in the last template parameter. The template parameter BaseConcept specifies wether the concept refines another concept. This way it plays nicely with implicit conversions from derived-to-base. If a class inherits a concept, that concept will be inherited by the typedef. The storage for the class is held in the root of the hierarchy, and it always holds models for the most derived concept that a class models (though you have to tell the compiler which Concepts a class models) These are two classes covering two concepts (compile-time). We want to be able to hold unrelated instances modeling those concepts at runtime, so we can do something like this for both instances. //Runtime Concepts layer class IDeviceC { public: virtual std::size_t getCapacityInMB() const = 0; }; template <class T> class DeviceCModel : public MovableModelBase<T>, public IDeviceC { public: IMPLEMENT_MODEL_DEFAULT_MEMBERS(DeviceCModel) virtual std::size_t getCapacityInMB() const { return Concepts::Device<T>::getCapacityInMB(this->getData()); } }; typedef MovableConceptBase<IDeviceC, DeviceCModel, EmptyType, Concepts::Device> DeviceC; //Refined concept class IPlugableDeviceC : public IDeviceC { public: virtual void onOpen() = 0; virtual void onRemove() = 0; }; template <class T> class PlugableDeviceCModel : public MovableModelBase<T>, public IPlugableDeviceC { public: IMPLEMENT_MODEL_DEFAULT_MEMBERS(PlugableDeviceCModel) virtual void onOpen() { Concepts::PlugableDevice<T>::onOpen(this->getData()); } virtual std::size_t getCapacityInMB() const { Concepts::PlugableDevice<T>::getCapacityInMB(this->getData()); } virtual void onRemove() { Concepts::PlugableDevice<T>::onRemove(this->getData()); } }; //Create concept class that refines DeviceC, The 3rd parameter is the concept it refines typedef MovableConceptBase<IPlugableDeviceC, PlugableDeviceCModel, DeviceC, Concepts::PlugableDevice> PlugableDeviceC; Now we can provide a program with classes that model those concepts and try a little: class LegacyDevice : NonCopyable { public: //This class models DeviceC concept typedef DeviceC ModelOfType; std::size_t getCapacityInMB() const { return 10; } }; class IpodDevice : NonCopyable { public: //This class models PlugableDeviceC concept typedef PlugableDeviceC ModelOfType; void onOpen() { std::cout << "Opening Ipod device" << std::endl; } void onRemove() {} std::size_t getCapacityInMB() const { return 32 * 1024; } }; int main(int argc, char * argv[]) { std::vector<DeviceC> devices; IpodDevice ipod; LegacyDevice legacy; //devices.push_back(move(legacy_device)); devices.push_back(move(ipod)); devices.push_back(move(legacy)); DeviceC & dev_ref = devices[0]; std::cout << dev_ref->getCapacityInMB() << std::endl; for (auto & device : devices) { //device->onOpen(); std::cout << device->getCapacityInMB() << std::endl; } //TODO: Doesn't work downcasting because of the lvalue reference, buf dev_ref is actually holding a model that inherits the most-derived //PlugableDeviceC & pd = dynamic_cast<PlugableDeviceC&>(dev_ref); //pd->onOpen(); std::shared_ptr<DeviceC> dev_sptr(new PlugableDeviceC(IpodDevice())); std::cout << "Shared pointers:\n"; std::cout << (*dev_sptr)->getCapacityInMB() << std::endl; auto derived_ptr = dynamic_pointer_cast<PlugableDeviceC>(dev_sptr); (*derived_ptr)->onOpen(); IpodDevice & ipod_device = static_cast<IpodDevice&>(*derived_ptr); std::cout << "Ipod device back to concrete type: " << ipod_device.getCapacityInMB() << std::endl; std::cout << "Size of DeviceC " << sizeof(DeviceC) << std::endl; std::cout << "Size of PlugableDeviceC " << sizeof(PlugableDeviceC) << std::endl; std::cout << "The end" << std::endl; } You can see that conversions work, except for downcasting. The downcasting does not work because of an lvalue-ness problem, but if you instantiate a class like this: IpodDevice dev; DeviceC device(move(dev)); It will be holding an object modeling the PlugableDevice concept. The problem is that I cannot convert to a PlugableDeviceC because it's being held in a DeviceC, but the most-derived model is correctly instantiated. There are still things to do, but I feel they can be accomplished: -Downcasting: I can make a special type View<PlugableDeviceC> which can point to instances held in a DeviceC (maybe, don't know). -Generalize MovableConceptBase and MovableModelBase classes, so that you can use classes that are copyable, equality_comparable, etc. With these two pieces and maybe some improvements, I think I can provide a library that plays well with Boost.concept_check library and which is the runtime counterpart of it. Feedback is very welcome.

6 19

Re: [boost] [Boost-commit] svn:boost r68912 - in branches/release: boost libs/utility
by Steven Watanabe 17 Feb '11

17 Feb '11

AMDG On 2/15/2011 6:54 AM, bdawes(a)acm.org wrote: > Author: bemandawes > Date: 2011-02-15 09:54:16 EST (Tue, 15 Feb 2011) > New Revision: 68912 > URL: http://svn.boost.org/trac/boost/changeset/68912 > > Log: > Merge trunk BOOST_ASSERT_MSG additions > Properties modified: > branches/release/boost/static_assert.hpp (contents, props changed) > branches/release/libs/utility/assert.html (contents, props changed) > branches/release/libs/utility/assert_test.cpp (contents, props changed) > Text files modified: > branches/release/boost/static_assert.hpp | 10 ++++- > branches/release/libs/utility/assert.html | 74 ++++++++++++++++++++++++++++++++++----- > branches/release/libs/utility/assert_test.cpp | 44 +++++++++++++++++++++++ > 3 files changed, 116 insertions(+), 12 deletions(-) > First of all, this breaks the tests because it merges the tests for BOOST_ASSERT_MSG, but not the header. Second, this is a new feature. Shouldn't it wait till after 1.46 goes out? In Christ, Steven Watanabe

4 4

Serialization of std::shared_ptr
by Loïc Joly 16 Feb '11

16 Feb '11

Hello, I'm using the std::shared_ptr provided with MSVC 2010. I'd like to be able to use boost.serialization to serialize some of those shared_ptrs. I could find an old thread stating that std::tr1::shared_ptr were not handled (and it looked impossible to make them work). Is the situation the same with std::shared_ptr? I thought of the "solution" of using boost::shared_ptr instead of std::shared_ptr, but it is currently not the prefered option: We have parts of our program independant from boost that use std::shared_ptr, we would like those parts to remain independant from boost. And we have other parts of our program where shared_ptr is used without qualification, and where a "using namespace std" directive is active. Switching to boost would incur either qualifying all shared_ptr uses, or adding a "using namespace boost" but that would introduce ambiguities. Thank you for your help! -- Loïc

2 3

[1.46.0] Final release procedure this Sunday?
by Beman Dawes 16 Feb '11

16 Feb '11

I'd like to start the final release procedure for 1.46.0 on Sunday, the 20th. That's mostly for personal reasons; next week is going to be very busy for me, so its either this Sunday or not until the following Sunday. Starting final release on Sunday means Friday is really the last day to merge fixes. Otherwise there isn't time for enough tests to cycle. Is that schedule OK? --Beman

1 0

[UTF String] UTF String library 1.5 ready for perusal
by Chad Nelson 16 Feb '11

16 Feb '11

It's a little later than I'd planned, but the second version of the UTF String library is now available for download, at <http://www.oakcircle.com/toolkit.html>. I'd appreciate comments or (constructive) criticisms on it. This version is substantially better than the original. The design has been somewhat simplified, removing extraneous features like null-string emulation. Each of the classes now contain as many of the std::string functions as I could efficiently add (essentially all of them in utf32_t), including I/O stream functions, and also features code-point iterators. It includes conversion classes for many common code-pages too. (I have not yet added true *character* iterators. That's going to require more study. But the code-point iterators should be pretty useful even without that.) There may well be bugs in it. I've only just completed it, I haven't used this version in anything but test code yet. It's also still *not* ready for submission... it's closer, but at the very least I'd like to add a few more code-pages to it first (so it can handle any code-page that Windows is likely to throw at it), and break up the code-page cpp files. Artyom, it might interest you to note that its capabilities are very similar to those outlined in your "realistic API proposal" (<http://lists.boost.org/Archives/boost/2011/01/176046.php>), though the design itself is different. It doesn't handle Unicode normalization, case handling, comparison, or search, but all the other capabilities are there. Your API could be implemented on top of utf8_t fairly easily. -- Chad Nelson Oak Circle Software, Inc. * * *

12 34

[C++0x] Emulation of scoped enums
by Beman Dawes 16 Feb '11

16 Feb '11

The improved type safety of the C++0x scoped enum feature is attractive, so I'd like to start using it as it becomes available in compilers. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a description. Note that the committee changed the name from strongly typed enums to scoped enums. See the attached for a boost/detail header that provides macro wrappers that use scoped enums if available, otherwise fall back on C++03 namespaces and unscoped enums. It lets a library write: BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END ... BOOST_SCOPED_ENUM(algae) sample( algae::red ); void func(BOOST_SCOPED_ENUM(algae)); and then a user can write: sample = algae::green; func( algae::cyan ); Comments or suggestions appreciated, --Beman // scoped_enum_emulation.hpp ---------------------------------------------------------// // Copyright Beman Dawes, 2009 // Distributed under the Boost Software License, Version 1.0. // See http://www.boost.org/LICENSE_1_0.txt // Generates C++0x scoped enums if the feature is present, otherwise emulates C++0x // scoped enums with C++03 namespaces and enums. The Boost.Config BOOST_NO_SCOPED_ENUMS // macro is used to detect feature support. // // Caution: only the syntax is emulated; the semantics are not emulated and // the syntax emulation doesn't include being able to specify the underlying type. // // See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a // description of the feature. Note that the committee changed the name from // strongly typed enums to scoped enums. // // Sample usage: // // BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END // ... // BOOST_SCOPED_ENUM(algae) sample( algae::red ); // void foo( BOOST_SCOPED_ENUM(algae) color ); // ... // sample = algae::green; // foo( algae::cyan ); #ifndef BOOST_SCOPED_ENUM_EMULATION_HPP #define BOOST_SCOPED_ENUM_EMULATION_HPP #include <boost/config.hpp> #ifndef BOOST_NO_SCOPED_ENUMS # define BOOST_SCOPED_ENUM_START(name) enum class name # define BOOST_SCOPED_ENUM_END # define BOOST_SCOPED_ENUM(name) name #else # define BOOST_SCOPED_ENUM_START(name) namespace name { enum enum_t # define BOOST_SCOPED_ENUM_END } # define BOOST_SCOPED_ENUM(name) name::enum_t #endif #endif // BOOST_SCOPED_ENUM_EMULATION_HPP

14 27