- Boost - lists.boost.org

[Graph] Some help in trying to fix the broken leda wrapper
by Sandeep Gupta 12 Nov '08

12 Nov '08

Hi, This is a repost and I hope this time it gets someone attention. I have spend some time trying to make the leda wrapper work with the new version of leda. I had some success with it. However finally i got stuck with this error that I couldn't make any sense of boost_1_36_0/boost/concept_ > > check.hpp:91: error: request for member > 'error_type_must_be_a_signed_integer_type' in > '((boost::SignedInteger<leda::edge_struct* > const*>*)this)->boost::SignedInteger<leda::edge_struct* const*>::x', which > is of non-class type 'leda::edge_struct* const*' It is instantiated from eventually from boost/concept_check.hpp: In destructor 'boost::SignedInteger<T>::~SignedInteger() [with T = leda::edge_struct* const*]': /home/san/ArtOfLearning/boost_1_36_0/boost/concept/detail/general.hpp:29: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::SignedInteger<leda::edge_struct* const*>]' It doesn't seems like a big problem. I am sure the original author of leda wrapper or anybody well versed with the internals can point me in the right direction. Thanks sandeep On Mon, Nov 3, 2008 at 10:41 PM, Sandeep Gupta <gupta.sandeep(a)gmail.com>wrote: > Hi, > Not sure how much interest is in leda wrapper of BGL. But the new version > of leda broke the leda wrapper. I have made some quick fixes. However i got > stuck at this error: > > boost_1_36_0/boost/concept_check.hpp:91: error: request for member > 'error_type_must_be_a_signed_integer_type' in > '((boost::SignedInteger<leda::edge_struct* > const*>*)this)->boost::SignedInteger<leda::edge_struct* const*>::x', which > is of non-class type 'leda::edge_struct* const*' > > Hopefully its the last one. After this technically the wrapper should > compile. I have briefly tested it with connecte components routines. > If there is interest i will happy to post the changes.. > > thanks > sandeep > >

3 4

llvm anyone?
by Neal Becker 12 Nov '08

12 Nov '08

Anyone testing on llvm compiler? (I'm trying it now on linux F9 x86_64 llvm-2.4)

2 1

Re: [boost] [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st
by vicente.botet 12 Nov '08

12 Nov '08

----- Original Message ----- From: "Fabio Fracassi" <f.fracassi(a)gmx.net> To: <boost-users(a)lists.boost.org> Cc: <boost(a)lists.boost.org> Sent: Monday, November 10, 2008 11:30 AM Subject: Re: [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st > I have a tendency to yes, because even now it is better than what we have > now (which is not saying that signals1 was bad!), on the other hand I > think that the missing documentation is crucial. I think that a mini review would ensure that the documentation is updated as we expect. Vicente

1 0

Fw: [Boost-users] [signals2][review] The review of the signals2library (formerly thread_safe_signals) begins today, Nov 1st
by vicente.botet 12 Nov '08

12 Nov '08

forwarding to boost(a)list.boost.org ----- Original Message ----- From: "Frank Mori Hess" <frank.hess(a)nist.gov> To: <boost-users(a)lists.boost.org> Sent: Monday, November 10, 2008 4:25 PM Subject: Re: [Boost-users] [signals2][review] The review of the signals2library (formerly thread_safe_signals) begins today, Nov 1st > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 10 November 2008 05:30 am, Fabio Fracassi wrote: >> * Automatic connection management: >> This is great, even if it wasn't required for thread safety reasons, I >> prefer using shared_ptr based connection tracking over boost::trackable, >> since it enables me to track (and thus safely use) 3d party classes. > > One issue that has occurred to me with the shared_ptr use, is it requires > the > use of boost::shared_ptr. So, if someone's program is instead always > using > std::shared_ptr for example, that could be a bit of an annoyance. One > solution would be to make it support anything that provides the > shared_ptr/weak_ptr interface by making slotN::track() a template and > doing > some type erasure inside the library. Unfortunately, neither the > shared_ptr > or weak_ptr interface provides a typedef for it's associated > weak_ptr/shared_ptr type, and I would need to get both the weak_ptr and > shared_ptr type from the single argument passed to slotN::track(). So, > I'd > have to add some template traits classes that could determine if a class > is a > shared_ptr or weak_ptr, and the type of its associated weak_ptr or > shared_ptr. I could provide specializations of the traits classes for the > shared_ptr/weak_ptr implementations I know about (boost, std, tr1, etc), > otherwise the user would have to provide a specialization. > > The other option would be to add yet another template parameter to the > signal > class for the shared_ptr type, but it has too many parameters already. > >> I haven't done a comparison, but the Docu seems to be mostly the same as >> the original signals. Thus for the usecases that are documentated there >> its high quality, but I miss the same for the new features: >> >> * I miss tutorial quality examples for some of the new features: >> ** Howto use boost::threads with signals2 >> ** Howto use postconstructors/predestructors (and what for?) >> ** An example using signal::extended_slot_type > > Yes, it seems clear I'm not going to get away with the minimal porting job > I > did on the Boost.Signals documentation. Speaking of the postconstructor > stuff, I'm not entirely happy with the deconstruct_ptr interface. Maybe > I'd > like it better if it looked more like make_shared/allocate_shared and had > a > helper for declaring it as a friend, as has been recently proposed on > boost-devel for make/allocate_shared. > >> * The class reference pages (e.g. >> doc/html/boost/signals2/connection.html) are missing from the TOC > > That's just how boostbook does it. The TOC links to the header synopsis, > and > the class names in the header synopsis link to the class reference pages. > I > do remember having a little trouble navigating through it myself initially > though. > >> * Do the portable syntax examples need to be supported (... so >> prominently)? Maybe they could be moved to an appendix? > > I agree they don't, although most of the other additions to the docs > people > have been asking for would seem to take precedence. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFJGFJu5vihyNWuA4URAsUpAJ0TVggC9K9Zy76p1AxtfnxA1VomsgCeL1Z8 > TrXkG8+WbKkBDS7SiUF+0+Y= > =zb8l > -----END PGP SIGNATURE----- > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

1 0

[thread] thread_group::size complexity
by vicente.botet 12 Nov '08

12 Nov '08

Hi, The current implementation could have O(n) complexity due to the use of std::list. Even if we would have thread_group with no too mant threads, it sounds extrange to me to have a function size without constant complexity. As your implementation do not needs splice, what do you think about having a thread_group::size with constant complexity by adding an internal counter for example? Regards, Vicente

1 0

[thread] at_thread_exit move overloading
by vicente.botet 12 Nov '08

12 Nov '08

Hi, What do you think about adding move support for at_thread_exit? template<typename F> void at_thread_exit(F&& f); and be emulated with the following prototypes? template<typename F> void at_thread_exit(detail::thread_move_t<F> f); template<typename F> void at_thread_exit(F f, typename disable_if<boost::is_convertible<F&,detail::thread_move_t<F> >, dummy* >::type=0); BTW, could you tell us why this function is not included on the C++0x proposal? Best, Vicente

1 0

Fwd: [signals2][review] little REVIEW
by Stjepan Rajko 12 Nov '08

12 Nov '08

I am forwarding the review below: ---------- Forwarded message ---------- From: <Jean-Christophe.BENOIST(a)fr.thalesgroup.com> Date: Tue, Nov 4, 2008 at 8:43 AM Subject: [signals2][review] The review of the signals2 library (formerly t hread_safe_signals) begins today, Nov 1st : little REVIEW To: stjepan.rajko(a)gmail.com (first of all please excuse my weak english, I am not a native english speaker) I am a regular user of boost::signals, so I am very interested by signals2. I'll review from a user standpoint. * On the documentation : - I am surprised to find very little information or rationale about multi-threading in documentation. We know the library is now "thread safe" but we don't know exactly what it means. There is only one MT use case (just) detailed in "tutorial" : what happens when a thread disconnect a slot from a signal, while another thread calls it. But there are another interesting MT use cases : - what if 2 threads simultaneously calls the same signal ? How to mutex slots in this case ? Are slots automatically excluded by an hidden mutex ? - What if a thread adds a slot to a signal while another calls it ? Is the slot added after signal call ? There should be tutorials and explanations for these cases, IMO. - About rationale : why is there special signals2::mutex ? May we use boost::thread::mutex for mutex template ? What are advantages/drawbacks of choosing signals2::mutex or boost::thread::mutex ? - Use of "postconstructible" or "predestructible" classes is rather obscure, and should be tutorialized / better documented. * On interface : - Very close from original signals interface : no particular comment. * On test suite / test cases : - I cannot see any MT test case (from the documentation, in "acceptance tests" section at least). It's rather surprising. I cannot imagine there is no test case for MT (calling a signal while disconnecting slot etc..). In particular, I'd whish to see if this library is robust in a multi-core environment and run test cases in this environment (I know cases where a library is perfectly thread safe on mono-core, even hyperthreading, but fails on multi-core). At least, there should be a rationale explaining why this library should be robust in a multi-core environment (especially with a proprietary signals2::mutex). * Final statement : All in all, I think this library is very close to be accepted as a Boost library, but without MT test cases and MT documentation, I can't give a total agreement for now. I have little doubt this library is MT tested and robust, even in a multi-core environment, but I have no real clue to assert it. Feel free to ask me further details. Best regards Jean-Christophe BENOIST Software Engineer THALES Communications France

3 2

Re: [boost] boost signals2 review
by Stjepan Rajko 12 Nov '08

12 Nov '08

Thank you, Andy, for the review. Stjepan On Mon, Nov 10, 2008 at 9:18 AM, Andrew Webber <andy(a)aligature.com> wrote: > For this review, I have focused on the usability and documentation of the > new signals2 library. I haven't really probed into the implementation and > so I'm assuming that the code is adequate and mostly bug free. > > In general, I think that this library should be accepted as a boost > library. Other than a few questions and annoyances, I think the library is > an extremely welcome addition to the boost libraries. > > I think that the interface changes required to guarantee thread safety are > understandable. I've seen some discussion on the mailing list about > retaining the trackable interface for backwards compatibility. While I > understand the desire to keep the changes required by switching to signals2 > to a minimum, I think signals2 provides a clean break. I understand > boost::signals is going to be maintained for the time being. This way, if > people don't want to change, they don't need to for the time being. If they > want thread safe signals, they should switch to the new library, its new > techniques and its clean interface. > > Here are my specific comments: > * Why the change to boost::optional for signal return values. Maybe I > missed a discussion about the motivation on the mailling list, but this is > an interface change that appears to be unnecessary. > > * I would like to see examples provided to explain the use of > postconstructable, predestructable, and deconstruct_ptr. I think a concrete > example might clear up some people's confusion over when it's appropriate to > use these. > > * I'd also like to see a concrete example shown of switching out the mutex > class used. I think three examples would be best: built-in, dummy_mutex, > and boost::mutex. > > * I'm not very happy about the tendancy of the slot disconnect exceptions > to show up in Visual Studio output. For instance, I built a test program > where several tracked objects were destroyed from different threads, based > on a random timer, while the slot was being invoked over and over. The > program worked well except for a great deal of repeated output like the > following: > > First-chance exception at 0x7c812a5b in SignalsTest.exe: Microsoft C++ > exception: > boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_weak_ptr> >> at memory location 0x0012dc0c.. > First-chance exception at 0x7c812a5b in SignalsTest.exe: Microsoft C++ > exception: boost::signals2::expired_slot at memory location 0x0012df58.. > > > I did several experiments with this library on Microsoft Visual Studio > 2005. I did not encounter any bugs or problems during my testing. I have a > decent amount of experience in this problem domain. In the past, I have > implemented a (limited) thread safe wrapper around the boost::signals > library. The signals2 library would very effectively replace my wrapper. I > spent a couple of hours on my evaluation, I would consider it moderately > in-depth without evaluating the signals2 implementation. > > Best, > Andy Webber > >

2 1

[utility/swap] Internal compiler error Siliconman borland-6.10.0 (CodeGear?)
by Niels Dekker - mail address until 2010-10-10 11 Nov '08

11 Nov '08

The 21 unit tests of the boost::swap utility (at the trunk) are doing very well: http://www.boost.org/development/tests/trunk/developer/utility-swap_.html But unfortunately, the rather simple specialized_in_std.cpp test gets an internal compiler error (Fatal F1004) from borland-6.10.0. I guess this is a CodeGear issue, right? Is it a known issue? And is there any workaround? Nicola, do you have a clue? :-) The test is at http://svn.boost.org/svn/boost/trunk/libs/utility/swap/test/specialized_in_… Siliconman borland-6.10.0 says: > > Test output: siliconman - utility/swap - specialized_in_std / > borland-6.10.0 > Rev 49647 / Sat, 8 Nov 2008 10:04:09 +0000 > Report Time: Sat, 8 Nov 2008 22:56:26 +0000 > > Compile [2008-11-08 12:52:34 UTC]: fail > > "C:/BuildAgent/work/17d82d291b38a658/cb2009/bin/bcc32" -j5 -g255 -q > -c -P -Ve -Vx -a8 -b- -v -Od -tWC -tWR -tWC -WM- -DBOOST_ALL_NO_LIB=1 > -DBOOST_TEST_NO_AUTO_LINK=1 -I".." -I"C:/BuildAgent/work/17d82d291b38a658/cb2009/include/" > -o"C:\BuildAgent\work\17d82d291b38a658\results\boost\bin.v2\libs\utility\swap\test\specialized_in_std.test\borland-6.10.0\debug\specialized_in_std.obj""..\libs\utility\swap\test\specialized_in_std.cpp">> ..\libs\utility\swap\test\specialized_in_std.cpp:> Fatal F1004 ..\libs\utility\swap\test\specialized_in_std.cpp 20:Internal compiler error at 0x44b20b with base 0x400000> Fatal F1004 ..\libs\utility\swap\test\specialized_in_std.cpp 20:Internal compiler errorhttp://www.boost.org/development/tests/trunk/developer/output/siliconm… regards,--Niels Dekkerhttp://www.xs4all.nl/~nd/dekkerwareScientific programmer at LKEB, Leiden University Medical Center

1 2

brandes centrality example
by Matthew Galati 11 Nov '08

11 Nov '08

Newbie... Does anyone have a small hand example of using http://www.boost.org/doc/libs/1_37_0/libs/graph/doc/betweenness_centrality.… on a weighted graph? I am having trouble creating one. Thanks, Matt

1 0