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

[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

iterator adaptors and const correctness
by Neal D. Becker 11 Nov '04

11 Nov '04

I was struggling with const correctness and iterator adaptors. At first I was using iterator_facade. I found it difficult to get dereference to work correctly. After changing to iterator_adaptor I got things working. I'm wondering if the approach I used is "correct". I include the whole class here, because it isn't really very big. I was using a Ring class which contains an iterator, which is cycle_iterator<std::vector<Complex>::iterator>. If a Ring const& is passed I had problems with dereference. The changes I made to cycle_iterator fix this were: 1) Add templated conversion constructor to cycle_iterator, to allow implicit conversion of cycle_iterator -> const cycle_iterator. 2) Include both reference dereference() and const reference dereference() const (likewise for operator[]) So, do my changes constitute a "correct" approach to making interoperable iterators using boost::iterator_adaptor?

3 2

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

11 Nov '04

> Message: 7 > Date: Tue, 9 Nov 2004 13:16:05 -0500 > From: Caleb Epstein <caleb.epstein(a)gmail.com> > Subject: Re: [boost] Re: GUI Library Proposal for a Proposal > To: boost(a)lists.boost.org > Message-ID: <989aceac0411091016316d09bb(a)mail.gmail.com> > Content-Type: text/plain; charset=3DUS-ASCII > > On Tue, 9 Nov 2004 17:37:15 -0000, George van den Driessche > <grebe(a)bigfoot.com> wrote: > > > Date: Tue, 9 Nov 2004 09:38:35 -0500 > > > From: Caleb Epstein <caleb.epstein(a)gmail.com> > >=20 > > > I've been toying with using the properties library Reece Dunn recentl= > y > > > submitted (in the boost-sandbox CVS) for this purpose. I've got > > > something very sketchy, but it relies on a visitor pattern to "pass" > > > type information to client code in a manner similar to Boost.Variant. > > > > > > I'd prefer a way of storing the type information for each reflectable > > > class statically, and in a generic way, e.g. something like > > > std::map<std::string, property>. This would enable the reflection > > > code could be decoupled from the reflected classes entirely and just > > > operate on this property meta-data. It would also allow client code > > > to lookup individual properties (e.g. by name) instead of having to > > > visit all of them. > > > > > > I'm stumped by how to store this information in any sort of container > > > though, since the properties are of different types. Any thoughts, o= > r > > > is this madness? > >=20 > > The properties are of different types, but the type information for > > properties will always be of the same type :) So you can generate a pro= > perty > > 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. > > You lost me here. The property types each inherit from property_info, > but it is similarly templated on the type of object begin > stored/referenced/aliased. Are you suggesting another non-template > base class which all properties would inherit from? Spot on. Just as a property_set corresponds to a C++ type, the property_type_info entries in the property_set each correspond to a pointer-to-member (or a pair of pointer-to-member-function if you want to wrap your property with get/set methods). Just as you generate a unique property set for each reflected type, you generate a unique property_info for each of its properties. But since each property_info has a common base class, you can stick them all in the same property set. Take a peek into the Boost.Python stuff. It follows a similar pattern, I believe. > What might this > look like? I find myself unable to write an overview of it and not almost all of it. So I'll have to write the whole thing this evening when I have time :) > What mechanism would you use to keep track of the type > information? Type information of what? You can pass around a fat pointer class which is basically a pair< void*, property_set* > when you need to maintain knowledge of the type of a pointer. I'll try to get it all written up into an understandable form this evening. George

2 1

RE: [boost] boost::ref simple question
by Michiel Salters 11 Nov '04

11 Nov '04

The boost::function template works with boost::ref according to the docs, so try boost::function< int ( int ) > ( boost::ref( Op() ) ) HTH, Michiel Salters > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Neal D. Becker > Sent: maandag 8 november 2004 16:16 > To: boost(a)lists.boost.org > Subject: [boost] boost::ref simple question > > > This must be a common question. > > I want to use std::transform with a function object that is > expensive to > copy, so I want to pass by reference. I tried to use > boost::ref for this, > but this simple test doesn't work: > > struct Op { > int operator() (int x) { return 1 + x;} > Op() {} > private: > Op (const Op&); > > }; > > int main() { > vector<int> x (4); > vector<int> y (4); > Op o; > std::transform (x.begin(), x.end(), y.begin(), boost::ref(o)); > } > > Any suggestion? > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

5 9

License use for non-Boost projects
by Andrew Cox 11 Nov '04

11 Nov '04

Can I release my own non-Boost projects under the Boost license? Does the Boost organisation mind? Is the license valid if I use the standard application of it in src and header files as follows? // Copyright 2004 Joe Coder. // Distributed under the Boost Software License, Version 1.0. (See // accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) Thanks, Andrew Cox Programming projects: http://www.btinternet.com/~ahcox/index.html UCL work: http://www.cs.ucl.ac.uk/students/Andrew.Cox/

2 1

[fileststem]1.32: with serilization: visibility of m_path
by Francis ANDRE 11 Nov '04

11 Nov '04

Hi In order to serialize a derivative class of boost/filesystem/path, one cannot access the base class member m_path without changing its visibility from private to protected: I would suggest to change the visibility of this m_path member from private: to protected, or to add an implicit definition of the serialize method into the class boost::filesystem::path. #include <boost/filesystem/path.hpp> namespace boost { namespace serialization { class access; }} class OSD : public boost::filesystem::path { private: friend class boost::serialization::access; friend std::ostream & operator<<(std::ostream &os, const OSD&); template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & m_path; } }; Regards Francis ANDRE

9 25