February 2007 - Boost-users - lists.preview.boost.org

[property map] copying dynamic_properties
by gavinband＠tiscali.co.uk 18 Feb '07

18 Feb '07

Dear all, I have boost 1.33.0. It looks to me like boost::dynamic_properties (in dynamic_property_map.hpp) does not have a supplied copy-constructor, and so it has a default copy-constructor. However, since dynamic_properties allocates dynamic_property_map objects on the heap, and holds them by pointer, this is not sufficient. This is causing a segfault in the code pasted below. Either dynamic_properties should be given a copy constructor and assignment operator (which seems useful to me) or it should be noncopyable. Or perhaps it could use shared_ptrs instead of regular pointers to avoid this problem? Thanks, Gavin. #include <boost/dynamic_property_map.hpp> int main() { std::map<long,long> my_map; boost::associative_property_map<std::map<long,long> > apm(my_map); boost::dynamic_properties dp; dp.property("property",apm); boost::dynamic_properties dp2(dp); // crash occurs when dp is destructed. return 0; } ___________________________________________________________ Tiscali Broadband only 9.99 a month for your first 3 months! http://www.tiscali.co.uk/products/broadband/

1 0

[iterator] make_zip_iterator
by Erik Åldstedt Sund 18 Feb '07

18 Feb '07

Hi, just a short question: Why does not the zip_iterator header have the following (or something along the lines of the following) creator function: template <typename Iter1Type, typename Iter2Type> boost::zip_iterator<boost::tuple<Iter1Type, Iter2Type> > make_zip_iterator(Iter1Type i, Iter2Type j) { return boost::make_zip_iterator(boost::make_tuple(i, j)); } That would make creating a zip_iterator much simpler. Instead of writing the following: std::set<double> s; std::vector<int> v; // populate s and v.... std::for_each(boost::make_zip_iterator(boost::make_tuple(s.begin(), v.begin())), boost::make_zip_iterator(boost::make_tuple(s.end(), v.end())), my_functor_that_does_something_useful()); you could write the following: std::set<double> aSet; std::vector<int> aVector; // populate aSet and aVector.... std::for_each(boost::make_zip_iterator(aSet.begin(), aVector.begin()), boost::make_zip_iterator(aSet.end(), aVector.end())), my_functor_that_does_something_useful()); Regards, Erik Åldstedt Sund

5 5

[bimap] Review of the Bimap library begins today Feb 15
by Ion Gaztañaga 18 Feb '07

18 Feb '07

Hello everyone, The review of the proposed Boost Bimap library written by Matias Capeletto starts today (February 15th, 2007) and ends after 10 days (February 25, 2007). Documentation for the library can be found online here: http://tinyurl.com/e2os3 The library can be downloaded from Boost.Vault/Containers: URL: http://www.boost-consulting.com/vault/index.php?directory=Containers Tiny URL: http://tinyurl.com/ysfclr Online documentation and the documentation package can be found here: http://tinyurl.com/y95qng --------------------------------------------------- Context: The library has been developed by Matias Capeletto with the mentoring of Joaquín M López Muñoz in the context of the Google SoC 2006. You can find more information about SoC projects here: http://code.google.com/soc/boost/about.html You can read an overview of Boost participation in Google Summer of Code 2006 written by Joaquín M López Muñoz here: http://boost.org/more/boost_soc_06_overview.html --------------------------------------------------- About the library: With Boost.Bimap you can create associative containers in which both types can be used as key. A bimap<X,Y> can be thought of as a combination of a std::map<X,Y> and a std::map<Y,X>. The learning curve of bimap is almost flat if you know how to use standard containers. A great deal of effort has been put into mapping the naming scheme of the STL in Boost.Bimap. The library is designed to match the common STL containers. Boost.Bimap offers also advanced features: -> Boost.Bimap offers much more than just a one-to-one ordered unique bidirectional map. It is possible to control the set type of each side of the relationship that the bimap represents, giving one-to-many containers, hashed bidirectional containers and others that may be more suitable to the the task at hand. -> The types of a bimap can be tagged so that each side is accessible by something closer to the problem than left and right. This leads to more readable, self-documenting code. -> The extended mapping framework allows to disable a view of a bimap, including the standard mapping containers as a particular case. Bimap has been tested in the following platforms: GCC 3.4/Linux GCC 4.0/Linux, Mac VS 7.1/Windows VS 8.0/Windows ICC 7.1/Windows ICC 8.0/Windows --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Ion Gaztañaga Review Manager

2 1

Building Universal Boost Libraries on MacOS
by Finley Lee 18 Feb '07

18 Feb '07

Greetings, list! I'm trying to compile the boost libraries on an Intel based Macintosh. On my Intel Mac, I was able to build an Intel based version of bjam, which happily builds libraries for the Intel architecture. I want to link them to a universal app, though. Is there a way to instruct bjam to build universal versions of the libraries instead? I guess I could build the PowerPC libraries on my PowerPC Mac and them lipo them together, but I am hoping there is an easier way! Best regards, Finley

3 2

Re: [Boost-users] [typeof] Typo in Acknowledgements page
by Cromwell Enage 18 Feb '07

18 Feb '07

> In the header, "Acknowledgements" is spelled > as "Acknoledgements" Self-correction: according to most dictionaries, it should actually be "Acknowledgments". Cromwell D. Enage ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367

1 0

[typeof] Typo in Acknowledgements page
by Cromwell Enage 17 Feb '07

17 Feb '07

In the header, "Acknowledgements" is spelled as "Acknoledgements" Cromwell D. Enage ____________________________________________________________________________________ We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265

1 0

Printable documentation
by Seweryn Habdank-Wojewódzki 17 Feb '07

17 Feb '07

Hi all I have just one simple question. In the book of Bjorn Karlson there are described just main Boost libraries. And I am interesting about printable version of some others. Especially interesting for me is Program Option. How can I reach printer friendly issue of it? Regards. -- |\/\/| Seweryn Habdank-Wojewódzki `\/\/'

1 0

[signals] threading_model.hpp locking bug?
by Frank Mori Hess 17 Feb '07

17 Feb '07

Timmo, In looking over signals/detail/threading_model.hpp, it looks like signals::mutli_threaded isn't thread-safe due to the way it uses scoped_lock. That is, scoped_lock is not thread-safe. I used a slightly different approach in thread_safe_signals/single_threaded.hpp (which provides a null mutex type) and multi_threaded.hpp (which provides real mutexes and is not included by default to prevent default inclusion of boost.thread headers). -- Frank

2 1

[signals] status of signals::scoped_connection::release?
by Frank Mori Hess 17 Feb '07

17 Feb '07

scoped_connection provides an undocumented release() function. What is the status of this, should I implement it in thread_safe_signals? -- Frank

1 0

[signals] slot_call_iterator caching bug?
by Frank Mori Hess 16 Feb '07

16 Feb '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It seems to me the purpose of the cache in the slot_call_iterator is to prevent the slot from being run multiple times if the combiner does multiple dereferences on an iterator. However, since the cache is shared, if a copy of an already dereferenced iterator is made and incremented, then the original iterator will run the slot a second time when dereferenced. So is this a bug, or is it just unspecified what will happen if you dereference a slot iterator more than once? - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF1eBV5vihyNWuA4URAiOHAKDIqGjobUlH40+TIZ6pmD3s7E4aSgCfRIEZ +R0rr1t3upDKhxVPdy9x0uo= =jELp -----END PGP SIGNATURE-----

2 5