- Boost - lists.boost.org

Re: [boost] [Review][PQS] Review deadline
by Michael Fawcett 11 Jul '06

11 Jul '06

On 6/8/06, Andy Little <andy(a)servocomm.freeserve.co.uk> wrote: > Hi Michael, > > > -----Original Message----- > > From: Michael Fawcett [mailto:michael.fawcett@gmail.com] > > Sent: 08 June 2006 15:49 > > To: andy(a)servocomm.freeserve.co.uk > > Subject: Re: [boost] [Review][PQS] Review deadline > > > > A goal of pqs is to be useable in that sort of situation. To be > > really effective > > > it will need a lot of supporting classes ( matrix, vector, quat) though. > > > > Did you plan on using Boost::uBLAS for this, along with > > Boost::quaternion? This seemed tangential enough to the PQS > > discussions that I didn't want to clutter up the mailing list, but I > > am defeinitely curious. > > FWIW Its extremely important. I think it would be worth asking on the list. > I dont think many people realise! I have discussed it in various replies but > no one has asked me the direct question: > > Neither of those libraries above will work with other than numeric types > AFAIK. IOW where T is a type (simplifying and ignoring e.g floating point > promotion etc), it must satisfy: > > T result = T() + T(); > T result = T() * T(); > > (among others) > > If T is a physical quantity, the second requirement never can be true. > Quantity Compatible library must be written something like: > > Where Op is +,-,*,/, ==, etc ... > > typeof( T1() Op T1() ) result = T1() Op T2(); This was a private e-mail discussion but Andy thought it important to be bruoght up on the list. FWIW, my own current matrix/vector/quaternion code does what you are asking for (with boost's help), but I had been looking at changing all my stuff over to uBLAS/quaternion for some time. As an example: blas::vec3<float> a(1, 0, 0); blas::vec3<double> b(0, 1, 0); blas::vec3<double> result = cross_product(a, b); // returns vec3<double>! I accomplished this using what I think never became a boost library (from the sandbox maybe? Did MPL::transform consume this functionality?) result_of which was used something like: template <typename LHS, typename RHS> typename boost::result_of_plus<LHS, RHS>::type operator +(const LHS &lhs, const RHS &rhs) { typename boost::result_of_plus<LHS, RHS>::type nrv(lhs); nrv += rhs; return nrv; } I would hope some solution could be found where you didn't have to implement all new matrix/vector/quaternion classes and their corresponding functionality, rather, just ensure the return type from the operation follows normal promotion rules (this is actually what I thought the promotion traits library was going to do). --Michael Fawcett

24 132

[Boost-bugs] [ boost-Bugs-1520489 ] significantly different timer class behaviour on Win and Lin
by SourceForge.net 11 Jul '06

11 Jul '06

Bugs item #1520489, was opened at 2006-07-11 15:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1520489&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: timer Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sukhonosenko Kirill (skv) Assigned to: Beman Dawes (beman_dawes) Summary: significantly different timer class behaviour on Win and Lin Initial Comment: clock() function used in implementation of boost::timer behaves differently on Windows (MS XP Pro, MSVC 7.1) and Linux (FC3, gcc 3.4.2). Windows: clock measures elapsed time (wall clock). And this comply with boost::timer interface description. Example: boost::timer t; double sec = 1; ::Sleep(sec*1000); double d = t.elapsed(); assert(abs(d-sec) < 0.1); Linux: clock() function returnes process CPU time. The above code will fail. This difference makes boost::timer a bad candidate for cross-platform development. I can propose alternative implementation with simalar right behaviour. ------------------------------------------ #ifndef _Timer_h_dlfkgh9384ytdflg9045uhy0823475mgd385uyn0v68uy c0n4c5 #define _Timer_h_dlfkgh9384ytdflg9045uhy0823475mgd385uyn0v68uy c0n4c5 #include <time.h> namespace Timer { /* Measures intervals of wall clock time, but not process CPU time. Resolution & accuracy depends on time function abilities. */ class timer { public: // setup reference time point timer() { restart(); } // reset reference time point void restart() { ::time(&m_ref_time); } // report difference between current time and reference point double elapsed() const { time_t curr_time; ::time(&curr_time); double diff = difftime (curr_time, m_ref_time); return diff; } // forbidden private: timer(const timer &); timer & operator=(const timer &); private: time_t m_ref_time; }; } // namespace Timer #endif //_Timer_h_dlfkgh9384ytdflg9045uhy0823475mgd385 uyn0v68uyc0n4c5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1520489&group_… ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

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