- Boost - lists.preview.boost.org

boost::weak_ptr
by Dirk Gregorius 12 Nov '04

12 Nov '04

Is it possible to reset a boost::shared_ptr without all associated boost::weak_ptr become invalid? -Dirk

2 1

boost::function feature request?
by Peter Dimov 12 Nov '04

12 Nov '04

When using boost::function<bool()> to implement event callbacks such as is_visible or is_enabled, it's very convenient to pass 'true' or 'false' directly, instead of going through bind( identity<bool>(), true ). An UI button I recently did even had separate bool properties in addition to the callback events for these reasons. I wonder whether it's reasonable to add this_type& operator=( T const & t ); to function<T()> that does the obvious thing. Of course f = t; is merely a shorthand way of spelling f = boost::lambda::constant(t), but a dependency on lambda isn't always desirable. Thoughts? -- Peter Dimov http://www.pdimov.com

4 10

Re: Generalised reflection
by George van den Driessche 12 Nov '04

12 Nov '04

> Message: 4 > Date: Thu, 11 Nov 2004 17:08:53 -0500 > From: David Abrahams <dave(a)boost-consulting.com> > Subject: [boost] Re: Generalised reflection > To: boost(a)lists.boost.org > Message-ID: <uoei4kphm.fsf(a)boost-consulting.com> > Content-Type: text/plain; charset=us-ascii > > "George van den Driessche" <grebe(a)bigfoot.com> writes: [snip] > > Yes, but in Boost.Python you're really saying two things for each type: > > (a) Here's my type's internal structure. > > Emphatically no. In Boost.Python you describe a new Python type's > public interface. Its interface doesn't have to have any relationship > to that of the C++ type. > > > (b) Here's how to present the internal structure to Python. > > I think this fact is slightly disguised because the two steps are both > > performed by the def() function. > > Believe me, I understand that there are two things happening there, > and the Langbinding project aims to separate those two things. But > when doing language binding you are definitely *not* describing > internal structure. The two things are: > > i. Describe the external interface to the new type. > ii. Turn that interface description into an actual Python type. Yes. I shouldn't have used the phase 'internal structure' here. A better indication of what I'm getting at comes later in my message, but was cut from your reply: > > What I'm suggesting amounts to factoring out the common first step. Let's > > suppose that we do in fact have a general reflection library, which allows > > you to list the properties of your class and attach arbitrary bits of data > > to them. So allow me to revise the description of the two stages: (a) Enumerate the runtime-accessible properties of a C++ type and associate names with them. (b) Turn that interface description into an actual Python type. > > But the fact that it takes > > pointers-to-members is a giveaway. > > The fact that you are generally binding member functions (and only > public ones) is also a dead giveaway. What Rene said may be true > (that most types can be serialized and reconstructed through their > public interface), but it's not a foregone conclusion. I agree. In the case where you need to provide two different reflections, you write two different descriptions. In the common case where you can use the same one for both purposes, you've saved yourself a bunch of work. This is just the same as Python providing default pickling support to cover the common cases - you still have to customise it sometimes, but it does the bulk of the work for you. > > Part (b) here corresponds to the extra > > data that you attach to exposed members, such as return_internal_reference. > > In a serialisation library, you're saying two things too: > > (a) Here's my type's internal structure. > > (b) Here's how to write the structure to a file, and read it back. > > In fact, if your classes are appropriately exposed to Python, you could just > > pickle them in Python and you'd be done. > > *If* they expose enough information to be picklable. >>> And note > that Boost.Python has explicit support for pickling, which rather > strongly hints that the information you supply it for ordinary class > wrapping is usually not sufficient for serialization. <<< Yes. Now imagine that I've got some helper functions for use with Boost.Python's pickling suite. But I want to use them with a C++ serialisation library. I'm going to have to factor a bunch of code out of those helper functions so that I can invoke them without using boost::python::tuple, and then write wrappers to use the factored-out code with the Boost.Python pickling suite. Instead, I want to write just the C++ serialisation code, and have that automatically wrapped up for use with Boost.Python pickling. It's a similar separation of layers. > > Maybe it would help to describe how I arrived at the idea I'm > > suggesting. > > No offense, but probably not; you're not the first one to think that > the ideas behind Boost.Python could be used to build a generalized > reflection library. Of course not. However, since you agree with my premises but you disagree with my conclusion, it follows that you must disagree with my reasoning at some stage. So by describing my reasoning, I'm hoping that you'll be able to pinpoint that stage and then we can discuss that instead :) > If you search this mailing list's history and > that of the Python C++-sig I think you'll find some other > conversations along these lines. It's a fine idea; I just have a > hard time believing that the information you need to expose for > serialization is normally the same as what you need to expose for > language binding. Maybe the same front-end interface code can be > used to do the exposing, but whatever the user writes for one is not > going to magically work for the other. I completely agree. In my message I did write: > > The major architectural problem I foresee with hanging different categories > > of information (scripting, serialisation, UI &c) off the same reflection > > objects is that people might want to define how to serialise an object in > > one place, but how to script it in another. Now, even if this cannot be resolved, the many reflection-based tasks still have a common step (a), namely building a reflection of a type. You can find yourself providing several reflections of a type for different purposes, but nonetheless the mechanism of reflection is the same: bind properties to names. In other words, even if you must have different reflections of a type for different purposes, the means of generating those reflections is the same, and the underlying structure of each reflection is the same. (Note: I'm *not* saying here that each reflection reflects the same properties of the type, but that each reflection is a set of tuples of (name, property, reflection-specific-extra-data.) So one could factor out the definition of the reflection structure. What does one gain from that? Well, in the cases where you really could use the same reflection for several purposes, you only need to provide one (as in the Langbinding case). In other cases, you write several reflections, but they all use the same syntax (probably similar to boost::python::class_ definitions) which means: i) you can plug the same helper/accessor functions into any of them. ii) if you can read one, you can read them all. George

2 1

Can anyone please give me advice on regression test building?
by Roland Schwarz 12 Nov '04

12 Nov '04

This is my second attempt to get some help on regression test build. If I should post this to another list, please anyone give me advice to where I should post instead. Here is my question: I try to invoke bjam in subdirectory .....\boost\status (After having set TOOLS=vc-7_1 ) The last line I see is: Unknown suffix on <@boost!libs!spirit!test>./select_p_with_rule.cpp<template>normal - see UserObject rule in Jamfile(5). Obviously nothing has been built (no tests have been run?) Is this an error in the test Jamfile of spirit, or am I trying to do something stupid? Thank you for any help on this. Roland

2 3

boost::shared_ptr: Changing raw pointer for all instances
by Dirk Gregorius 12 Nov '04

12 Nov '04

My boost::shared_ptr objects hold pointees to interfaces. It might happen that these raw pointees might become invalid or that I like to change the implementation. Is it possible to change the raw pointee of all boost::shared_ptr objects in an application due to some kind of event? Example: I have one singleton class that provides several factory functions: class Factory { public: boost::shared_ptr<IFoo> CreateX( void ); // ... more factory functions private: // Events - void OnChangeImplementationX( void ); // Data members typedef std::vector< boost::shared_ptr<IFoo> > MasterColl; MasterColl m_FooObjects; } boost::shared_ptr<X> Factory::CreateX( void ) { // Create a new foo object boost::shared_ptr<IFoo> pFoo( new FooImpl ); // Save a "master" instance m_FooObjects.push_back( pFoo ); // Return the object return pFoo; } void Factory::OnChangeImplementationX( void ) { // Iterate over all "master" objects and change the underlying pointee } Can this be implement using the boost::shared_ptr class? Regards, -Dirk

1 0

[format] problem with special floating point values
by Vyacheslav E. Andrejev 12 Nov '04

12 Nov '04

Hello All, Thare is a problem in boost::format to treat infinity floating point values. Compare output of the two following lines of code: cout << numeric_limits<double>::infinity(); cout << boost::format("%f\n") % numeric_limits<double>::infinity(); The first one on my machine outputs 1.#INF which denotes infinity. The code with boost::format outputs 1/5000 zeroes/.#INF000 It's not what I can expect in any way. It's strange, but quiet NaN is outputed well. -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC

1 0

[range] warnings on vc7.1
by Jonathan Turkanis 12 Nov '04

12 Nov '04

Hi Thorsten, The program at the end of this message produces twenty C4224 Warnings ("nonstandard extension used : formal parameter 'array' was previously defined as a type") on VC7.1 and VC8.0 beta. Since Boost.Array and Boost.Range will be used together with some frequency, it might be a good idea to disable warning 4224 locally within the range headers. Best Regards, Jonathan ---------- #include <boost/array.hpp> #include <boost/range/begin.hpp> #include <boost/range/end.hpp> #include <boost/range/iterator.hpp> int main() { }

2 3

boost::shared_ptr
by Dirk Gregorius 12 Nov '04

12 Nov '04

I have four easy questions regarding boost::shared_ptr: 1.) How do I pass a boost::shared_ptr to a function - via value or reference? void ByValue( boost::shared_ptr<Foo> pFoo ); void ByReference( boost::shared_ptr<Foo>& rFooPtr ); 2.) When passing a raw pointee to a function you can declare the pointee const. How do I pass a const boost::shared_ptr? void ConstRaw( const Foo* pFoo ); void ConstSharedPtr( ??? ); 3.) Does anything speak against passing a reference to a factory function instead of returning the boost::shared_ptr? boost::shared_ptr<Foo> Create( void ) { return boost::shared_ptr<Foo>( new Foo ); } bool Create( boost::shared_ptr<Foo>& foo ) { // Make some validations and return false on error. // ... // Everyting is ok. Reset the pointee and return a success foo.reset( new Foo ); return true; } 4.) Can I test a boost::shared_ptr against NULL like a raw pointee? Regards, -Dirk

2 1

[admin]
by Jonathan Turkanis 11 Nov '04

11 Nov '04

Hi, Is there any plan to restore old messages to the server at gmane ( I realize this takes significant space)? I find it much easier to search for old messages on my hard drive than using the web interfaces. Unfortunately, my newsreader wiped out my archive of old messages yesterday when the server came back up. Jonathan

2 2

Generalised reflection (was: Re: GUI Library Proposal for a Proposal)
by George van den Driessche 11 Nov '04

11 Nov '04

> Message: 15 > Date: Wed, 10 Nov 2004 20:52:24 -0500 > From: David Abrahams <dave(a)boost-consulting.com> > Subject: [boost] Re: GUI Library Proposal for a Proposal > To: boost(a)lists.boost.org > Message-ID: <uwtwtnodj.fsf(a)boost-consulting.com> > Content-Type: text/plain; charset=us-ascii > > "George van den Driessche" <grebe(a)bigfoot.com> writes: > > >> I'm stumped by how to store this information in any sort of container > >> though, since the properties are of different types. Any thoughts, or > >> is this madness? > > > > The properties are of different types, but the type information for > > properties will always be of the same type :) So you can generate a > > property set for your class, that includes the dictionary that maps > > names to property_type_info structures. Each property_type_info > > would be automatically generated from the static type of the > > property. > > > > The thing that's bugging me is that all the reflection mechanism is > > covered by Boost.Python because it relies on the same principles. I > > *think* the boost-langbinding list seems to know this, since you > > also need the reflection capabilities in order to support languages > > that aren't Python. But that list doesn't seem to have much traffic > > so I haven't much to go on. > > We did some work on that project recently and presented it at the > Boost workshop at OOPSLA. See > http://boost-consulting.com/writing/oopsla04.html > http://boost-consulting.com/writing/langbinding.ppt > > > In order to avoid too many reinvented wheels, I'd like to see > > Boost.Python split neatly into two stages: > > > > (a) Reflect C++ types into C++ objects. Each type for which you provide a > > reflection map will correspond to exactly one property_set object, which > > would contain a set of property_type_info objects. > > (b) Expose the types to Python using the objects created by (a). > > > We do have a front-end/back-end architecture, but I'm not sure whether > we're doing what you want. > > > Once you've made that split, then you can add: > > (c) Expose the types to Lua using the objects created by (a). > > (d) Expose the types to <language-of-your-choice> using the objects created > > by (a). > > (e) Serialise the types, using results of (a). > > This I have serious doubts about. What you'd expose for Python/Lua > binding would be an object's public interface: its abstraction. In > order to do serialization in that way, you'd likely have to expose an > object's guts: its implementation details. Yes, but in Boost.Python you're really saying two things for each type: (a) Here's my type's internal structure. (b) Here's how to present the internal structure to Python. I think this fact is slightly disguised because the two steps are both performed by the def() function. But the fact that it takes pointers-to-members is a giveaway. Part (b) here corresponds to the extra data that you attach to exposed members, such as return_internal_reference. In a serialisation library, you're saying two things too: (a) Here's my type's internal structure. (b) Here's how to write the structure to a file, and read it back. In fact, if your classes are appropriately exposed to Python, you could just pickle them in Python and you'd be done. But as was pointed out a couple of days ago (by Beman I think), not everyone wants to use Python in their project. Maybe it would help to describe how I arrived at the idea I'm suggesting. I wanted to construct a serialisation library in C++, that would be used from C++. I quickly realised I needed to separate the description of which elements of an object should be serialised, from the description of how the serialisation should happen. That way, a single class description could be processed in many different ways, so I could use it to write XML, or plain debug text, or a compact binary version, without changing the class definition. Once I'd set about it, I realised I was duplicating the structure that I saw in Boost.Python, but instead of attaching to each property a description of how to interface with Python, I was attaching the description of how to serialise that property. And I thought, I wish I could just use class_ instances to describe the data to serialise. But of course, Boost.Python class_ instances are designed to be used from Python, not from C++ :) Obviously, this train of thought is very similar to that which gave rise to Boost.Langbinding. And looking at the usage examples for John Torjo's Win32GUI framework, I saw the same pattern arising yet again: lists of properties (that is, pairs of member functions), with attached data (in this case, about bindings to specifc UI elements, input validation routines, and so on). What I'm suggesting amounts to factoring out the common first step. Let's suppose that we do in fact have a general reflection library, which allows you to list the properties of your class and attach arbitrary bits of data to them. Then the data that you attach to a property can be: - things from Boost.Langbinding about how to get at it from script (or simply the fact that script shouldn't be able to get at it) - things about how to serialise that property (or simply the fact that it shouldn't be serialised) - hints about how to present the property in a UI (e.g. if you attached some object that says "this integer's range shouldn't exceed [0,60)" then a slider or number control could pick that up and limit itself to that range). - probably some other things I haven't thought of. > > (f) Bind types to GUI objects, using results of (a). > > What does it mean to bind a type to a GUI object? > > > (g) ... you get the point. > > I'm not sure. A couple of other people have tried to explain what I meant, and I hope the above example makes it clear. The major architectural problem I foresee with hanging different categories of information (scripting, serialisation, UI &c) off the same reflection objects is that people might want to define how to serialise an object in one place, but how to script it in another. This could arise, for example, if someone supplies a library that only includes scripting information for its types, but the library's user also wants to add serialisation support. I think you encountered a related problem in the Boost.Langbinding development where two libraries that each supply bindings for one type could conflict if both used in the same executable. Possibly it's too ambitious to try to bring all these related, but different, activities under the same umbrella. Maybe multiple property maps really are the best solution. But it's certainly worth considering, because even in that case I suspect they could share a common set of base templates. For instance, if you attach range information to a scalar property, that could automatically be used for validation by serialisation code, UI code, and scripting code. George

2 1