- Boost - lists.boost.org

Re: [boost] [optional] Making optional more debugger friendly
by Matthew Herrmann 24 May '07

24 May '07

boost-request(a)lists.boost.org wrote: > Message: 12 > Date: Wed, 23 May 2007 16:39:56 -0700 > From: "Jeffrey Faust" <jefffaust(a)verizon.net> > Subject: Re: [boost] [optional] Making optional more debugger friendly > To: boost(a)lists.boost.org > Message-ID: <op.tssz0uxy5emtmi@goliath> > Content-Type: text/plain; format=flowed; delsp=yes; > charset=iso-8859-15 > > David Deakins wrote: > > >> Hi Jeff, >> >> We have a handful of VS2005 visualizers for boost types. Here's what we >> use for boost::optional. Try plugging this into the [Visualizers] >> section of your autoexp.dat and see if it is the kind of thing you are >> looking for: >> >> boost::optional<*>{ >> preview >> ( >> #if( !$c.m_initialized ) >> ( >> #( "Uninitialized" ) >> ) >> #else >> ( >> #( *($T1*)&$c.m_storage.dummy_.data[0] ) >> ) >> ) >> } >> > > Dave, you have made my day. This is exactly what I need. It works > perfectly! > > Now, how do people feel about an update to the documentation with this > debugger-specific nugget? Do other debuggers have similar facilities? > > Jeff > GDB has custom script support. On that note, anyone have a tip for how to (even manually) inspect in GDB? The version I am running (6.3.0.0) dumps internal core when I try to even print a boost::optional, let alone give readable output. Best Regards, Matthew Herrmann

1 0

Boost thread doesn't compile on windows if UNICODE is defined
by Krzysztof Kowalczyk 24 May '07

24 May '07

in mutex.inl: if (HMODULE kernel_module = GetModuleHandle(TEXT("KERNEL32.DLL"))) g_TryEnterCriticalSection = reinterpret_cast<TryEnterCriticalSection_type>(GetProcAddress(kernel_module, TEXT("TryEnterCriticalSection"))); The problem is that GetProcAddress() on windows only has ascii version and takes lpcstr as the name of the function to lookup, so if you define UNICODE to do windows unicode build, compiler complains that you're trying to pass WCHAR* as char*. A complication here is with wince, which is the opposite and only takes WCHAR* as the name of the function so the correct code should pass "TryEnterCriticalSection" on non-wince and L"TryEnterCriticalSection" on wince. It also means that successful windows unicode build of boost doesn't seem to be part of release criteria. -- krzysztof kowalczyk

2 1

[range_ex] Developer wanted!
by Marcus Lindblom 24 May '07

24 May '07

Hi all, About half a year ago, I took on the range_ex library from Thorsten Ottosen, aiming to make it ready for review and inclusion in boost. However, a few weeks later I found myself with a 'life' (i.e. girlfriend), so there hasn't been time for any outside-of-work hacking. I feel that range_ex deserves to be completed and would love to do it myself, but time just isn't there at the moment. range_ex is mostly just a range-ification of <numeric> and <algorithm> (i.e. versions of these functions taking Ranges rather iterator pairs) and I've been using a something similar at work. It really makes good sense to have it in boost. If anyone is willing to step up to this, let me or Thorsten know. There isn't much work really (most of it is there, just fill in the gaps, make it complete and edit a bit of the documentation). There are a few advanced features that definitely are worth pursuing in the future, but I believe a first barebone release would still improve the life of many c++ hackers. :) So, let us know if you're interested. Cheers, /Marcus

5 7

[pointer_container] documentation typo
by Michael Marcin 23 May '07

23 May '07

Hello On http://www.boost.org/libs/ptr_container/doc/ptr_container.html There is a type under Motivation #8. "The Clobable Concept" should be "The Clonable Concept" Thanks, Michael Marcin

1 0

[graph] zero based dense vertices?
by James 23 May '07

23 May '07

I am a new user of boost::graph. It appears from my experimentation with it that bgl requires a dense index set for the vertices. In other words, if the vertices have indexes 5, 7, 8 then the graph automatically pads indices from 0 to 8. Is this required, or may the vertex index set be arbitrary? Thanks for any feedback, James

2 1

[Daniel Frey][Trac Policy] #979: ::boost::detail::empty_base could be improved
by David Abrahams 23 May '07

23 May '07

I need to assign this ticket to Daniel Frey, who is the maintainer of the operators library. Does he have a Trac account? I don't know who "daniel" is in the list of Trac users. Maybe, for a project this size, we ought to be using userids that we can definitively associate with a person. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

7 6

Slots and signals: Listening to a value
by Johan Torp 23 May '07

23 May '07

I developed some classes which had similar functionality to slots and signals and now I want to transition to using slots and signals. I often find myself in the situation of wanting to listen to changes of a value type variable. I had a templated class called ConcreteObservable which encapsulated a get/set-able value and provided ways of listening to changes in the value. I.e. ConcreteObservable<bool> was a bool which you could get, set and listen to. I couldn't find anything corresponding in slots and signals so I wrote a small class - see end of post - which provides this functionality. I have a few questions regarding this: 1. Does the idea of a listenable value seem sound to you or do you see any problems? 2. Is there any existing boost code that already provides this functionality? 3. Do you see any problems with my implementation? 4. Do you have a better naming suggestion? Is signalling (user code would read signalling<bool>), listenable or signal_value perhaps better? template <class T> class signalling_value { public: signalling_value() : mValue(boost::value_initialized<T>()) {} signalling_value(const T& t) : mValue(t) {} void set(const T& value) { if (value != mValue) { mValue=value; mSignal(mValue); } } const T& get() const { return mValue; } template<class Slot> boost::signals::connection connect(const Slot& slot) const { return mSignal.connect(slot); } template<class Slot> boost::signals::connection connect(int order, const Slot& slot) const { return mSignal.connect(order, slot); } template<class Slot> void disconnect(const Slot& slot) const { mSignal.disconnect(slot); } private: T mValue; mutable boost::signal<void (const T&)> mSignal; };

3 2

Boost-bugs mailing list is open
by Doug Gregor 23 May '07

23 May '07

We have created a Boost-bugs mailing list, which will receive updates each time a ticket in Boost's Trac system is created, modified, or closed. To subscribe to the Boost-bugs mailing list, please go to: http://lists.boost.org/mailman/listinfo.cgi/boost-bugs - Doug

5 6

[bimap] user defined names
by Matias Capeletto 23 May '07

23 May '07

Thorsten propose to change the way the library works with tags. Suppose we have a bimap with user defined names: struct name {}; struct id{}; typedef bimap< tagged<std::string,name>, tagged<int> > People; People people; Instead using free functions like this: iterator_type_by<name,People>::type iter = map_by<name>(people).find("Peter"); the library now use templated member functions: People::map_by<name>::iterator iter = people.by<name>().find("Peter"); I think that this is a big improvement. Thanks Thorsten to point it. What do you think about it? John Maddok state that the section that describe how to use tags in the docs was not clear. The section is here: http://tinyurl.com/2swjyg Is it clearer now? Thank you all Best regards Matias

1 0

[bimap] convenience header
by Matias Capeletto 23 May '07

23 May '07

In the review Jeff Garland suggested a top level <boost/bimap.hpp> header. I have added this header to the library. It put the bimap class in the boost namespace. It is not an "include all" header, it only allow the basic case in which both collection types are sets ( bimap<X,Y> ). I think that this is the best approach because lows the barrier to use the library without damaging compile time by including stuff that the user will not use. If he wants other features, he will have to include the appropriate headers. In its minimal form, the library can be used now like: #include <boost/bimap.hpp> int main() { typedef boost::bimap< std::string, int > bm_type; bm_type bm; bm.insert( bm_type::value_type("one",1) ); assert( bm.left.find("one")->second == 1 ); } Do you think this is the correct approach? Regards Matias

1 0