- Boost - lists.boost.org

[BGL] A Question
by Wang Weiwei 11 Jul '06

11 Jul '06

Hello everyone, I'm starting to make use of the BGL in one of my projects. It was learnt from the documentation that there were basically 2 forms of representations of a graph: - adjacency-list, and - adjacency-matrix The latter is normally more suitable for denser graphs. My question is, Is ther any function that can shift the graph from between these two forms of data structure? Thanks Max

2 1

Boost.Test: automatic test cases inside a static library
by Joe Van Dyk 11 Jul '06

11 Jul '06

I'm trying to get something like the following to work: test_case1.cpp and test_cast2.cpp are compiled into a static library (libtest.a). They use BOOST_AUTO_TEST_CASE for test cases. test_main.cpp contains: #define BOOST_AUTO_TEST_MAIN #include <boost/test/auto_unit_test.hpp> However, when I compile test_main.cpp and link libtest.a into it, none of the test cases run. The test cases do run if test_main.cpp #includes test_case1.cpp and test_case2.cpp, but I'd rather not do that if it's not necessary. Any ideas? Thanks! Joe Van Dyk

3 8

Re: [boost] Please don't define a fake "operator <" justfororderedcontainers
by Sohail Somani 11 Jul '06

11 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of me22 > Sent: Monday, July 10, 2006 5:07 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Please don't define a fake "operator <" > justfororderedcontainers > > On 7/10/06, Sohail Somani <s.somani(a)fincad.com> wrote: > > Isn't shared_ptr<T> is supposed to be like T* which has ordering? In > > this case, it's a non-issue no? > > > My understanding is that < is only well-defined for pointers into the > same array and that < between to arbitrary pointers is otherwise some > sort of UB. > > It's less<T*> that provides a full ordering for arbitrary T*s. (By > specialising std::less.) This is true.

1 0

Re: [boost] Please don't define a fake "operator <" justfor orderedcontainers
by Sohail Somani 11 Jul '06

11 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov > Sent: Monday, July 10, 2006 2:58 PM > To: boost(a)lists.boost.org > >>> Looking at <http://www.boost.org/libs/smart_ptr/shared_ptr.htm>, > >>> i.e. the Boost version, it seems that the authors fell into the > >>> "fake operator <" trap. If any of those authors are reading this, > >>> can you tell us why you added the fake operator instead of a > >>> custom-named comparison class? > >> > >> shared_ptr defines operator< for map<shared_ptr<>, V> to work. What > >> do you mean by "fake"? > > > > I know what I did, but this still doesn't tell me what "fake" > means in this > context. What objective properties make an operator< "fake"? Isn't shared_ptr<T> is supposed to be like T* which has ordering? In this case, it's a non-issue no?

2 1

Comment on operator <
by Sean Parent 11 Jul '06

11 Jul '06

operator < should be defined anytime an objects of type can be totally ordered and the comparison has average constant complexity with worst case complexity proportional to the area of the object (the complexity guarantees are why we don't provide a less-than- operator for hash containers - we could just as we do for vector, but the cost is prohibitive). In the absence of a better choice, a lexicographical comparison of the members should be provided. The ordering must be total because !(a < b) && !(b < a) => a == b [trichotomy law]. The reason for the allowing comparison functions is containers is to allow for other orderings, including partial ones. Recommended reading - lecture 7 of <http://www.stepanovpapers.com/ notes.pdf>. Alex asserts in his notes that even when the less than operator has no meaning other than to provide a runtime ordering (such as for iterators on linked lists) it should be provided. In the case of linked list iterator - I also think that in the presence of increment that a < b should imply that [a, b) is a valid range and b is reachable from a through increment (which would not be the case using pointer ordering for linked list iterators). Limiting the application of operator < to relationships which survive serialization (that is, ones which do not depend on accidental relationships of object identity) would be my preference. Sean

1 0

Shmem named semaphore issue on linux
by Ryan, Paul L. 11 Jul '06

11 Jul '06

Ion, The named semaphore on linux seems to never increment the initial count when creating. Looking into the posix implementation a sem_init is never called if create is given and it just returns true. bool operator()(const shared_memory::segment_info_t * info, bool created) const { mp_sem = reinterpret_cast<sem_t *>(info->get_user_ptr()); switch(m_create){ case open_only: mp_sem = reinterpret_cast<sem_t *>(info->get_user_ptr()); break; case open_or_create: if(created){ if(sem_init(mp_sem, 1, m_initialCount) == 0){ return true; } else{ mp_sem = 0; return false; } } break; case create_only: return true; break; default: return false; break; } return true; } I think this method should be bool operator()(const shared_memory::segment_info_t * info, bool created) const { mp_sem = reinterpret_cast<sem_t *>(info->get_user_ptr()); switch(m_create){ case open_only: mp_sem = reinterpret_cast<sem_t *>(info->get_user_ptr()); break; case open_or_create: if(created){ if(sem_init(mp_sem, 1, m_initialCount) == 0){ return true; } else{ mp_sem = 0; return false; } } break; case create_only: if(sem_init(mp_sem, 1, m_initialCount) == 0){ return true; } else{ mp_sem = 0; return false; } break; default: return false; break; } return true; } Paul Ryan SAIC - Tactical Systems

2 1

Re: [boost] Boost.Test: automatic test cases inside a static library
by Sohail Somani 10 Jul '06

10 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennadiy Rozental > Sent: Monday, July 10, 2006 2:47 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Boost.Test: automatic test cases inside > a static library > >> Hm, I've never heard of that option. I'll look into it. > > > > Any chance you could tell me what flags the GNU GCC > compiler would do > > the trick? I can't find anything that resembles "avoid > unused static > > files discard". > > Looks like these may work: > > -fkeep-static-consts > -fno-toplevel-reorder > -fno-unit-at-a-time (?) On Linux, I believe there is also a linker flag -Wl,-whole-archive. There is also an equivalent on solaris but it escapes me...

1 0

Trying to get Boost.Python to build on Solaris 10 using SUN Studio 11
by Timo Geusch 10 Jul '06

10 Jul '06

Good afternoon, I've so far managed to make decent progress on building RC 1.34's Boost.Python on this OS/Compiler combination using jam v1 with the patches I submitted earlier. Unfortunately I now seem to have hit a brick wall in file pickle_support.cpp. The offending lines of code are line 57, which reads: static object result(&instance_reduce); If I replace this line with plain static object result; the file will compile, however the above line produces the following error message from the compiler: sunpro-C++-action bin/boost/libs/python/build/libboost_python.so/sunpro/debug/pickle_support.o "./boost/python/converter/arg_to_python.hpp", line 215: Error: Could not find boost::python::converter::detail::arg_to_python_base::arg_to_python_base(boost::python::tuple(*)(boost::python::api::object), const boost::python::converter::registration) to initialize base class. "./boost/python/object_core.hpp", line 309: Where: While instantiating "boost::python::api::object_base_initializer<boost::python::tuple(*)(boost::python::api::object)>(boost::python::tuple(*const)(boost::python::api::object)&)". "./boost/python/object_core.hpp", line 309: Where: Instantiated from non-template code. 1 Error(s) detected I think I'm missing something obvious here but I'm not familiar enough with the Boost.Python code to work out what it is. I'd appreciate if someone who is would be able to have a closer look as this is the last file that doesn't build here. Regards, Timo

2 2

[function] Internal compiler error on VC 7.1 with default parameter
by Allen Bierbaum 10 Jul '06

10 Jul '06

The following code snippet: #include <boost/function.hpp> class TestClass { public: void doSomethingDefault(boost::function2<void, bool, bool> cb=boost::function2<void,bool,bool>()) {;} }; int main() { TestClass test; test.doSomethingDefault(); return 1; } Gives an internal compiler error on vc 7.1: cl /nologo /Od /Ob0 /Z7 /W1 /MDd /EHsc /GR /TP /Ic:\Software\boost\boost_1_33_1 /DWIN32 /D_WINDOWS /D_DEBUG /c test.cpp /Fotest.obj test.cpp test.cpp(6) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2701) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information scons: *** [test.obj] Error 2 scons: building terminated because of errors. (line 6 is the method declaration with the default value). If I remove the use of the default value, the code compiles with no errors. I know this code compiles and works correctly on gcc 4.0 and I believe I have used it with older versions of gcc. Is there something incorrect with my usage? If not, is this an known issue? I searched through the bug tracker and the mailing lists but did not see anything about this bug. Does anyone have any ideas on how to work around this bug? Thanks, Allen

2 2

Preliminary release of clone_ptr library
by Kevin Spinar 10 Jul '06

10 Jul '06

(this will be the first and last "progress update" message until it comes time to summit for a review to boost) For better or for worse (it seems there's much debate on clone_ptr) I have started on the clone_ptr library and have a working preliminary clone_ptr class. Details can be found at the following URL and I will update the website as my work progresses: http://www.peltkore.net/~alipha/clone_ptr.html If anyone is interested in receiving email updates or would like to collaborate on the project (which could just simply be someone I could bounce ideas off of) email me. To contribute some to the discussion: It has been noted that the Boost.pointer_container library could be used instead of having a container of clone_ptr. However, what if you want to use non-standard containers? Yes, Boost.pointer_container has ptr_*_adapter classes, but they can't be used for containers which don't follow the container requirements set by the C++ standard. Secondly, even if a third party container class follows the container requirements, it is still unnecessary work to create your own pointer container. Consider this generic tree class: http://www.aei.mpg.de/~peekas/tree/ http://www.aei.mpg.de/~peekas/tree/doxygen/html/functions.html There's dozens of functions in the tree class that would have to be wrapped in a ptr_tree class that the boost::ptr_sequence_adapter class doesn't wrap for you. Compare this to: tree<clone_ptr<T> > foo; The clone_ptr solution seems a lot easier. The same argument could be made with boost::graph, etc. Also, I've decided to give clone_ptr clone-on-write semantics instead of clone-on-copy. This should alleviate any concerns about performance when inserting into a std::vector or copying containers (copying clone_ptr would give similar performance to boost::shared_ptr). Kevin Spinar

4 10