- Boost - lists.boost.org

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

11 Jul '06

>> Hello everyone, > >Hello. > >> 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? > >Try boost::copy_graph. ><http://www.boost.org/libs/graph/doc/copy_graph.html> > > HTH, > Cromwell D. Enage > > Thanks.

1 0

[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 10 Jul '06

10 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. 10 Jul '06

10 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