- Boost-users - lists.boost.org

drop-dead simple example of custom Boost.Range?
by John 08 Apr '08

08 Apr '08

I'm trying to get boost range and iterator to work. I've got so many questions, I don't know where to start. So, rather than post a specific compiler error, let's go back to square one. How about a concrete example of fitting a UDT with Boost.Range? Say I have a class with a non-trivial iterator type (not a pointer!) I'd like to modify the class so that Boost.Range is happy. At some point, I feel as though I just end up arbitrarily copying snippets from the docs in the hope that it will all work. Is there something I'm not "getting" about boost.range? The code below is an attempt to create a working skeleton example. Obviously, the author lacks whatever magic spell book is required to put it all together -- "it" being a user-defined type, plus Boost.Range. Seems like something as simple as a modeling a range should be easier than breathing, so I'm hoping it actually is, and that I'm just missing something totally obvious to everyone else. So, is the following skeleton correct? Where does it go awry? Can we perhaps clean it up, make it perfect, and introduce it (or something like it) to the Boost.Range docs? // An arbitrary container-esque class. class Foo { public: class iterator : public boost::iterator_facade < iterator, Foo::value_type, boost::random_access_traversal_tag, Foo::value_type, ptrdiff_t // Difference type? > { public: iterator (); // no-arg ctor required by boost? private: iterator (internal_stuff); // "real" ctor friend class boost::iterator_core_access; friend class Foo; // Required by iterator_facade? void increment(); void decrement(); void advance (ptrdiff_t); ptrdiff_t distance_to (const iterator&) const; bool equal (const iterator&) const; Foo::value_type dereference() const; }; // Required by Boost.Range? iterator end() const; iterator begin() const; // Blatant shot in the dark here... typedef boost::sub_range< Foo > range_type; // Walking blindfolded, with earplugs, and wearing mittens. range_type produce_a_range_somehow () const { iterator a = this->begin(); iterator b = this->begin(); some_algorithm_here (a, b, this->end()); return range_type (a, b); } // Now it gets bad. void use_a_range_somehow (range_type r) { // Starting to feel as though Kansas is far, far away. // Wondering where the past 4 hours went. // Wondering why I don't just use a custom std::pair-like range. // Am I cursed or blessed by the commitment to Boost? } };

2 1

[boost][lexical_cast] simple example doesn't work with vector<T>
by Andy Stevenson 08 Apr '08

08 Apr '08

Hi, Sorry trivial questions I'm sure. Why doesn't the lexical_cast work below? I think it meets the concept description. * Source is OutputStreamable, meaning that an operator<< is defined that takes a std::ostream or std::wostream object on the left hand side and an instance of the argument type on the right. * Target is InputStreamable, meaning that an operator>> is defined that takes a std::istream or std::wistream object on the left hand side and an instance of the result type on the right. * Target is CopyConstructible [20.1.3]. * Target is DefaultConstructible, meaning that it is possible to default-initialize an object of that type [8.5, 20.1.4]. >>>>> play.cpp >>>> #include <vector> #include <iostream> #include <algorithm> #include <boost/bind.hpp> #include <boost/lexical_cast.hpp> #include <boost/filesystem.hpp> #include <sstream> using namespace std; using namespace boost; using namespace boost::filesystem; template<class T> ostream& operator<< (ostream& os, const vector<T>& v) { copy(v.begin(), v.end(), ostream_iterator<T>(os, ";")); return os; } template<class T> string v2s(const vector<T>& v) { stringstream ss; copy(v.begin(), v.end(), ostream_iterator<T>(ss, ";")); return ss.str(); } int main(int argc, char* argv[]) { vector<string> v; v.push_back("hello"); v.push_back("world"); cout << v << endl; cout << v2s(v) << endl; cout << lexical_cast<string>(v) << endl; // XXX doesn't compile...XXX return 0; } Any help greatly appreciated. Andy

5 12

installing the math toolkit
by e r 08 Apr '08

08 Apr '08

hi all, please, I'm looking for some directions for installing the math toolkit: 1) downloaded math toolkit headers: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… 2) As per instructions in http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… i.e. Extract to a directory separate from your boost tree, then set the environment variable BOOST_ROOT to point to a copy of boost-1.34 (release branch cvs) or to 1.35 (cvs HEAD). I now have in my directory structure: /usr/local/boost_1_34_1 /usr/local/boost/math and in ./bashrc I added export BOOST_ROOT="/usr/local/boost_1_34_1" 3) I have added "/usr/local/boost/math" in the include path of the compiler (I use eclipse cdt) 4) in main.cpp: #include <boost/math/fpclassify.hpp>//warning: boost/math/fpclassify.hpp: No such file or directory int main() { using namespace boost::math; /*...*/ return 0; }

2 2

[Proto] Review result
by Hartmut Kaiser 07 Apr '08

07 Apr '08

Hi all, initially I was hoping to find some time over the last weekend to go through the reviews in great detail to put together a proper review report. Well, as things happen, I was not able to find the time :-( To avoid further delays, here is the short version of the review result: Proto got 16 reviews (That's well above average! Thanks to all for participating), out of which 15 have been positive. The one 'No' essentially stated that the library, even if doubtless very useful, shouldn't be accepted yet, mainly because there has to be done more work in the area of formalizing the problem domain. In my opinion this is an overwhelming result and I'm whole heartily agreeing with the majority of the voters. Proto is accepted as a Boost library. The discussions have been very detailed and there have been raised a lot of (mostly minor) issues, but Eric is aware of the problems and is working on solving them. I'll try to put together a summary as soon as possible. Regards Hartmut Review Manager

1 0

Network Attached Memory
by James Board 07 Apr '08

07 Apr '08

With Java, there exists something called Network Attached Memory (a Terracotta product). It basically increases the effective RAM of any single machine by allowing it to use RAM on another machine. But that's Java. Is there an equivalent thing for C++? Specifically, I have a cluster of nodes with a moderate amount of memory (8 gbytes each) and a very fast network (10 microsecond small message latency and 750 mbytes/second large message bandwidth). I have a C++ application that needs tens of gbytes of RAM. Is there some kind of product, or library, that would allow the C++ application to seemlessly use the memory on other nodes as if it had a much larger RAM? James --------------------------------- You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.

1 0

Linking boost libraries under visual c++ 2008
by Germán Diago 07 Apr '08

07 Apr '08

Hello. I compiled boost successfully for windows xp with visual c++ 9 toolchain. But when I try to link the regex example, visual studio looks for 'libboost-regex...' but the file produced for that file is 'boost-regex...' without the lib prefix. I don't know if this is a boost problem or a visual studio configuration problem. Anyway, do you know how can I solve this problem and link libraries with visual studio? I googled a lot but found no answer. Thanks in advance.

5 7

[boost][multiarray]Creating multi arrays on shared memory
by sankar lingam 07 Apr '08

07 Apr '08

I was working with boost multiarray and I found that multi arrays cannot be created in shared memory using boost interprocess..Will this be done in the future releases of boost?? Regards, sankar

2 3

Patch for boost-1_35 to remove compile warnings
by Lothar Werzinger 07 Apr '08

07 Apr '08

Attached is a patch for boost-1_35 to remove compile warnings in date_time/time.hpp Lothar

2 1

Re: [Boost-users] [smart_ptr] Sole ownership of shared_ptr?
by Richard L. Aurbach 07 Apr '08

07 Apr '08

On Apr 7, 2008, at 11:00 AM, Joseph Thomson wrote: > Actually, I think I have a better way which uses auto_ptr (or the > boost ptr > containers) as you suggested. It still isn't thread safe, but this > isn't of > immediate concern, and there are other methods for this anyway. > > Before, I was storing a map of shared_ptrs in the ObjectManager and a > weak_ptr reference in any ObjectHandles to check if the object is > still > valid. Instead: > > - A map of auto_ptrs (or a ptr_map of Objects) would be stored in the > ObjectManager. > - On its creation, Object would create and store a > shared_ptr<ObjectHandle>, > passing a raw pointer to it in the process (don't worry, this is still > safe). > - Any user wanting to get access to the Object would request an > ObjectHandle > from ObjectManager, which would in turn request a copy of Object's > shared_ptr<ObjectHandle>. > - On its destruction (by ObjectManager), Object would inform its > ObjectHandle of its destruction, and ObjectHandle would set an > internal flag > to indicate that it is expired. > - ObjectHandle would handle any requests from the user by first > checking the > expiry flag, and then forwarding the call to Object using its stored > raw > pointer. The expiry flag is set by the Object itself, so there is > no chance > of the pointer being invalid when called. > > Any advice/thoughts are appreciated. > > Cheers, > > Joe Joe, Suppose that: (a) ObjectManager uses shared_ptrs, not auto_ptrs, and (b) the base class of all Objects derives from boost::tr1::enable_shared_from_this. Then suppose the logic of ObjectHandle was something like: shared_ptr<Object> ptr = Object->shared_from_this(); if (ptr) { ptr->perform-requested-action(); } // shared ptr is reset when it goes out of scope Wouldn't this: >> preserve the single point of deletion (since the shared_ptr above is local). >> be thread-safe (because 'ptr' prevents the object from being deleted until the operation is complete. Or am I overlooking something really obvious in my (perhaps overly-)quick response? Cheers, Rick

1 0

Re: [Boost-users] [smart_ptr] Sole ownership of shared_ptr?
by Richard L. Aurbach 07 Apr '08

07 Apr '08

On Apr 6, 2008, at 5:48 PM, Joseph Thomson wrote: > Hi everyone, > > Over the past few days I have been trying to integrate Boost smart > pointers > into my system, which is basically a manager (ObjectManager) class > which > creates, destroys, and keeps track of instances of another class > (Object). > > The manager keeps a std::map of instances of type shared_ptr. The > manager > has a createObject() method which returns a shared_ptr instance to > the user, > thus the user becomes an owner of the object, alongside the > manager. My > problem arises because I want objects to _always_ be destroyed when > the > manager method destroyObject() is called. I realise that part of > the reason > to use smart pointers is to prevent data from being deleted while a > reference to it still exists, but I figure they are still worth > using just > for the safety aspect. I am also in the position of attempting to integrate shared_ptr into my application framework, so I am definitely a neophyte in this area. (So please take my comments with a grain of salt.) However, I have a couple of thoughts. (1) Your idea of storing both a weak_ptr and a true pointer to the object strikes me as dangerous. Any time you use the true pointer instead of locking the weak_ptr, you run the risk that the true pointer is not valid. This would, of course, invalidate one of the major points in using the shared_ptr/weak_ptr mechanism in the first place. I don't think that the overhead of converting the weak_ptr via lock() is sufficiently high to forego the advantages of the mechanism. But of course, only performance testing can verify that. [My own bias is to build a safe mechanism first, then only weaken it if performance measurements verify that this step is necessary.] (2) If you have, in fact, built a mechanism where you *know* that it is safe to use the true pointer instead of converting the weak_ptr, then I wonder if starting with a shared_ptr strategy is the best way to go in the first place. Since you only want one lock on the file (rather than shared ownership), wouldn't it be better to use auto_ptr? That pattern seems better suited to your overall approach -- if (and only if) you can be sure that a user will never use a deleted true pointer. Cheers, Rick Aurbach, Ph.D. President and Chief Engineer Aurbach & Associates, Inc. 8233 Tulane Avenue, Suite B St. Louis, MO 63132 www: http://www.aurbach.com/ eMail: support(a)aurbach.com [business] rick(a)aurbach.com [personal] Fax: 314/678-0869 Phone: 800/774-7239 314/726-1321 "If it ain't broke and you haven't fixed it recently, it probably needs to be rewritten." - Richard Aurbach (1948- ) "Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth, computer scientist (1938- ) "If in the last few years you haven't discarded a major opinion or acquired a new one, check your pulse. You may be dead." - Gelett Burgess (1866-1951) "A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing." - George Bernard Shaw (1856-1950) "It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong." - Richard Feynman (1918-1988) "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." - Nathaniel Borenstein (1957-)

2 2