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

[boost][test] - BOOST_FIXTURE_TEST_SUITE, BOOST_FIXTURE_TEST_CASE clarification
by Ed Johnson 09 May '06

09 May '06

In 1.33.1 release, is the following true? BOOST_FIXTURE_TEST_SUITE( suite_name, F ); //not supported BOOST_FIXTURE_TEST_CASE( test_name, F ); //not supported Thanks, Ed

2 6

Building boost on Mac OS 10.4
by Zokirov, Umed 08 May '06

08 May '06

Hi there, Has anyone successfully built Boot 1.33.1 on Moac OS X 10.4? In my case it fails to build test - related libs. I fugured out the issue with two-level namespacing, however waas not successful with specific linker settings to solve them Perhaps, boost-build mailing list is better to ask, nevertheless, I would suppose some of the users actually built boost. Umed

2 1

Inconsistency between boost::bind and boost::lambda::bind
by Gerardo Lamastra 08 May '06

08 May '06

Hello everybody, I've started to use the functional programming facilities offered by boost, and they're really impressive. To begin with, I've started using both; I've seen however, that when I #include both <boost/bind.hpp> and <boost/lambda/bind.hpp> I must use full namespace names to address lambda placeholders. In other words, instead of writing for_each(container.begin(), container.end(), cout << _1 << constant('\n')); I've to write for_each(container.begin(), container.end(), cout << boost::lambda::_1 << boost::lambda::constant('\n')); also if I've written a using boost::lambda declaration; I know, I can simplify this using a namespace alias, but I was trying to keep the code less clobber as I can, because it has to be used for teaching/example purposes. So, my first question would be: where could I find an exhaustive comparison between these two facilities? And, is there any indication on what to prefer, also related to future development and/or inclusion in C++ standards (If I remember well, boost::lambda has been proposed in tr1?) The second question points at a small inconsistency that I believe I've found while doing some experiments: boost::bind and boost::lambda::bind offer similar construct, but the former works while the latter fails in the example included below. I'm using boost_1_33_1, with g++ -v (provided below) Target: i586-mandriva-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-languages=c,c++,ada,f95,objc,java --host=i586-mandriva-linux-gnu --with-system-zlib --enable-long-long --enable-__cxa_atexit --enable-clocale=gnu --disable-libunwind-exceptions --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --disable-libjava-multilib Thread model: posix gcc version 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0) The situation is the following: if I try to create a nullary lamnda function with boost::lambda::bind() like this: generate_n(inserter(v, v.begin()), 10, boost::lambda::bind<Slave*>( boost::lambda::new_ptr<Slave>(),*this) ); the compiler fails to compile: it tries to pass the this pointer as a const reference somehow, and then it fails claiming that a Slave(const Master& m) cannot be found; If I try to add one, it fails with a similar error. If I substitute the boost::lambda::bind() with a boost::bind(), it compiles & works perfectly. Thanks for the attention, -Gerardo Lamastra ------------------------------------------------------------------------- #include <set> #include <algorithm> #include <iterator> #include <iostream> #include <boost/lambda/lambda.hpp> #include <boost/lambda/construct.hpp> #include <boost/lambda/bind.hpp> #include <boost/bind.hpp> using namespace std; using namespace boost::lambda; class Master; struct Slave { static int globalId; Master& master; int id; Slave(Master& m) : master(m), id(++globalId) {}; }; int Slave::globalId = 0; class Master { struct Builder { typedef Slave* result_type; Slave* operator()(Master& master) { return new Slave(master); }; }; static Slave* build(Master& master) { return new Slave(master); } public: void print(set<Slave*> s) { for_each(s.begin(), s.end(), (cout << constant("S: ") << (boost::lambda::_1) ->* &Slave::id) << '\n' ); } void f1() { /* This is the most trivial thing I've tried, but I need to write builder explicitely; */ set<Slave*> v; generate_n(inserter(v, v.begin()), 10, boost::bind(Builder(),*this) ); print(v); } void f2() { /* A more compact, but substantially identical form */ set<Slave*> v; generate_n(inserter(v, v.begin()), 10, boost::bind(&Master::build,*this) ); print(v); } void f3() { /* Does not work; it seems that the object passed to the compiler is a const Master& instead of just a Master&, it is like that the boost::lambda::bind() adds a const where that is not required... I tried to substitute the Master& in the Slave() constructor with a const Master& but it does not work either */ /* set<Slave*> v; generate_n(inserter(v, v.begin()), 10, boost::lambda::bind(&Master::build,*this) ); print(v); */ } void f4() { /* The same issue applies here... * This has been my original experiment, which * motivated all this trouble... */ /* set<Slave*> v; generate_n(inserter(v, v.begin()), 10, boost::lambda::bind<Slave*>( boost::lambda::new_ptr<Slave>(),*this) ); print(v); */ } void f5() { /* A work-around that I come up with, * mixing boost::bind && boost::lambda::new_ptr */ set <Slave*> v; generate_n(inserter(v, v.begin()), 10, boost::bind<Slave*>(boost::lambda::new_ptr<Slave>(),*this) ); print(v); } }; int main() { Master m; cout << "F1: " << endl; m.f1(); cout << "F2: " << endl; m.f2(); cout << "F5: " << endl; m.f5(); } -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster(a)telecomitalia.it. Thank you www.telecomitalia.it --------------------------------------------------------------------

3 2

[date_time] What's the proper way to convert local to UTC?
by Scott 08 May '06

08 May '06

Note: Reposting in hopes of getting an answer. c_local_adjustor has the static method "utc_to_local" to easily convert to local time based on the machine TZ setting. So I figured it had a utc_from_local or local_to_utc method as well. Neither compiled, so I looked at the header file c_local_time_adjustor.hpp: //! Adjust to / from utc using the C API Yet there is only that one method in the class. Is the missing ability to convert from local to UTC an oversight or is it implemented somewhere else? What's the correct way to do it? Thanks, Scott

1 0

Re: [Boost-users] [shmem] New bugfix version in Boost Vault and sandbox cvs
by bwood 08 May '06

08 May '06

Ion Gaztañaga wrote: >Jan Stetka(e)k dio: >> Yes I understand that I can't use shmem::map and std::map if they are >> both on the global namespace. I've looked at the implementation of the >> std::map header from the STL implementation that is included in vc++ 7.2 >> and that doesn't forward declare std::list in <map>. This is a design >> issue rather than a bug. Why forward declare shmem::list by including it >> in map.hpp when it isn't used? > > >All classes in Shmem include shmem_fwd.hpp or container_fwd.hpp where >Shmem defines default arguments (for example default Less, or Allocator >template parameter). That's why you get the predeclaration of list >including map. Another alternative would be to declare a *_fwd.hpp for >each class defined in Shmem, but you would get a lot of extra headers, >and I would have a lot of work to maintain. > > >Even if I don't include list predeclaration with map, I'm free to use >any Shmem container in any Shmem class (for example, I can implement a >pooled allocator using a list container), so it's likely that a Shmem >class include will include more Shmem classes (predeclarations, or full >declarations). I don't consider it a design error, but a design choice. >What I see dangerous is pushing two namespaces, std, and shmem to the >same context because they have similar classes. An alternative would be >to rename shmem classes like "vector" to "shmem_vector", .... But >weren't namespaces born to allow that? I think this is their intended purpose, but I don't like using them that way. It gets confusing and brevity isn't attained as you have to qualify things. Namespaces support a "let's just agree to disagree" approach that isn't a resolution, but is the best that can be done at times. Do you think this shmem functionality should be integrated with the std containers? In the meantime, I think shmem_vector is better. Does shmem support multi_index_containers? Or, depending on how shmem fits into the picture, should B.MI take the lead in supporting shmem functionality internally? Y'all have more flexibility in the B.MI case as it isn't part of the standard. Brian www.webEbenezer.net

4 4

Re: [Boost-users] Thread-safe smart pointers, hashtables without locking
by Ray Whitmer 08 May '06

08 May '06

> I'd also say the idea of moving a pointer out of the way, and then > using the > flip-gate-count-thing to wait for any 'potentially-using' readers > to finish, > definitely has 'potential'. You would need to show detailed code to > really > be sure. And not to us - to the guys on comp.programming.threads. Thanks. I will plan on pursuing it, then. > Anyhow, if you haven't already, take a look at memory barriers, > and, as a > canonical example, the broken 'double checked locking pattern'. You > can't > do lock free without understanding this stuff. I was somewhat aware of memory ordering and especially compiler reordering, but I need to take another look at it and find the proper set of macros for use in non-kernel code since volatile does not (yet) guarantee hardware behavior between processors. > And you are correct, you can't make { reading the > location of a shared_ptr + incrementing its ref-count } atomic, it > least not > on most processors. Actually, I was not concerned with incrementing the ref count. The flip-gate-count-thing solves, I believe, the problem of reference counts not being up to date all the time. I realize that I still have to prove this, but I do not think it is hard. What worries me more is whether the smart pointer has one or two fields in it, because this affects whether readers find an incomplete/ broken smart pointer as they whiz by. With a single pointer field in it, the load and store are atomic. > I don't think the boost implementation of intrusive_ptr's operator= > () is > atomic, but it could be made to be. shared_ptr has two pointers in it, (one to the shared count, one for the pointer) whereas intrusive_ptr has a single pointer in it (since the count is internal to the referenced class). This means that the shallow bits of shared_ptr are not atomically initialized, whereas those of intrusive_ptr are. An obvious way to solve this would be to make shared_ptr contain a single pointer to a wrapper class that contains both the shared count and a shared pointer, but this adds an unacceptable level of indirection to basic pointer operations. > Your wording of 'much less likely' is scary, and I think similar > wording > made James apprehensive as well. There is no grey - it is black or > white, > thread safe or not. I will have to adjust my language. I tend to use uncertain language both because I consider my knowledge incomplete and because of the lack of a generic standard that guarantees behavior, i.e. the fact that different Linux kernel architectures need different memory barriers, etc. is demonstration of the uncertainty of a general C solution. If I can rely on something like what the Linux kernel relies on, it should not be scary. Behavior needs to be guaranteed on supported platforms, and other platforms need to be detected and fail to compile lock-free or revert to a locking fallback implementation, etc. Ray Whitmer

2 1

Re: [Boost-users] [operators] loss of performance
by Victor A. Wagner Jr. 08 May '06

08 May '06

At 23:05 2006-05-07, you wrote: >Hi all - > >I just tried out the operators library for the first time today. I >was quite happy with how easily it helped me implement my test class. >Unfortunately, I'm running into some performance issues, in particular >with operator +. > >The interesting thing is that the new operator += is actually faster >than my old += by about a factor of 2, but my operator + is slower >than my old + by a factor of nearly 10! > >I'm new here, and not really sure how much code is appropriate to post >to the list, so here's a minimal rundown: > >-------------------------------------------------------------------------- >Old code: > >template<typename real> >Vector3<real> operator + (const Vector3<real> &a, const Vector3<real> &b); > >template<typename real> >class Vector3 { >protected: > real m_v[3]; >.. >.. > friend Vector3 operator +<> (const Vector3 &a, const Vector3 &b); >}; > >template<typename real> >inline Vector3<real> operator + (const Vector3<real> &a, const >Vector3<real> &b){ > Vector3<real> t; > t[0] = a[0] + b[0]; > t[1] = a[1] + b[1]; > t[2] = a[2] + b[2]; > return t; >} > >------------------------------------------------------------------------------------------------- >New code (note that the new code is templatized on size, and that my >instantiations >were of size 3 to match the above code): > >template<typename T, unsigned int S> >class vec > : boost::additive< vec<T, S> > , boost::multiplicative< vec<T, S>, T > > > >{ >private: > typedef unsigned int uint; > typedef const T &const_reference; > typedef T &reference; > >private: > boost::array<T,S> m_v; > > template<typename U> > vec &operator += (const vec<U,S> &t){ > for(uint i = 0; i < S; ++i){ > m_v[i] += t.m_v[i]; > } > return *this; > } >}; > >Any ideas how to increase the performance of the new code here? A >factor of 10 makes it seem like I am just missing something important. you showed us the code that you claim is faster, what do you want us to do? >Thanks, > Brian >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

[date_time] strange warning
by george 08 May '06

08 May '06

hello! try { boost::gregorian::date date_start(boost::gregorian::from_string(start)); boost::gregorian::date date_end(boost::gregorian::from_string(end)); boost::gregorian::date today(boost::gregorian::day_clock::local_day()); if(date_start > date_end || date_start < today || date_end.year() > today.year()) return false; period_=new boost::gregorian::date_period(date_start,date_end); return true; } catch(...) { return false; } .../boost/date_time/constrained_value.hpp: In member function ‘virtual bool Reservation::validation(std::string&)’: .../boost/date_time/constrained_value.hpp:64: warning: ‘year$D34041$value_’ is used uninitialized in this function .../date_time/constrained_value.hpp:64: warning: ‘year$D34041$value_’ is used uninitialized in this function why I get this warning? any idea? thanks

2 2

Re: [Boost-users] [multi_index] const mem_fun serialization bug.
by JOAQUIN LOPEZ MU?Z 08 May '06

08 May '06

----- Mensaje original ----- De: Julien Pervillé <julien.perville(a)free.fr> Fecha: Sábado, Mayo 6, 2006 9:15 pm Asunto: [Boost-users] [multi_index] const mem_fun serialization bug. > Hello boost-users. > > I am writing to report an annoying serialization bug encountered > while developing a project with Boost.multi_index, which is a > wonderfully useful data structure. Thank you Joaquín! > > First a fast overview of my project: [...] > After hunting through the headers, I located the triggered > exception to line 1080 of boost/multi_index/ordered_index.hpp > (line number from boost 1.33) > > Here is the context from the "rearranger" method where the > exception is thrown: > > > 1080 if(position!=x){ In Boost 1.33, tis is actually line 1088. Maybe a typo in your post? Anyway, I don't think this is important. [...] > I am looking forward to test patches and offer my help testing, > so that this little quirk gets solved. Hello Julien, thank you very much for using Boost.MultiIndex and for providing such a detailed bug report, with reproducible test case and all --actually, having the test case has made it easy to spot the problem. This is a bug in B.MI, but it has nothing to do with const_mem_fun. Rather it lies in the serialization loading algorithm. I'd like you to make the following changes in your local copy of B.MI (I'm assuming you've got 1.33 as per what you say in the post): 1. Replace line 80 in boost/multi_index/detail/duplicates_iterator.hpp: if(pred(begin_chunk->value,node->value))advance(); with the following: if(node!=end&&pred(begin_chunk->value,node->value))advance(); This bug was previously spotted by Toby Smith, and it's currently fixed in the CVS version of B.MI, soon to be shipped with Boost 1.34. More details at: http://lists.boost.org/boost-users/2006/01/16710.php 2. Replace the beginning of rearranger() at line 1076 of boost/multi_index/ordered_index.hpp: void rearranger(node_type* position,node_type *x) { node_type* before; if(!position){ ... with the following: void rearranger(node_type* position,node_type *x) { node_type* before; if(!position||comp(key(position->value),key(x->value))){ ... 3. Undo your previous hack which bypassed the archive_exception throw. That's it. I can confirm this makes seri-bug.cpp work OK. Could you please verify whether it also solves the problems in your real project? I'll devote some days to carefully study the issue and, if nothing weird shows, will commit the fix in the CVS HEAD and 1_33_4 branches next week. Please comment your results back. Thanks for reporting, best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

a problem on boost::asio
by 李慧霸 08 May '06

08 May '06

I'm trying asio on WindowsXPSP2 + VS2003, and I found that there are always some connections established from 127.0.0.1:xxxx to 127.0.0.1:yyyy, is it a bug?

1 0