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

[iostreams] '.gnu.linkonce' errors when linking mapped_file code
by Bill Lear 24 Jun '06

24 Jun '06

When I use the Intel 9.0 compiler on 64-bit Linux, I get strange link errors that do not appear with gcc: `.gnu.linkonce.t._ZN5boost9iostreams6detail16direct_streambufINS0_18mapped_file_sourceESt11char_traitsIcEE7seekoffElSt12_Ios_SeekdirSt13_Ios_Openmode' referenced in section `.gnu.linkonce.d...1..TPK T.845_0.0.844.343222' of ./libnet_x64icco2a.a(BoostBinaryFanSerialization.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9iostreams6detail16direct_streambufINS0_18mapped_file_sourceE St11char_traitsIcEE7seekoffElSt12_Ios_SeekdirSt13_Ios_Openmode' of ./libnet_x64icco2a.a(BoostBinaryFanSerialization.o) I've been poring over linker docs, compiler output, preprocessor output, google searches, etc., all morning. I've installed the newest version of the GNU binutils package, to no avail. If anyone can shed light on this, I'd really appreciate it. Bill

1 0

function traits
by Ovanes Markarian 24 Jun '06

24 Jun '06

Hello! I do not really want to bother you all, but I have some issue, which I am not certain is possible to solve and this drives me crazy. I posted some similar question at this location: http://lists.boost.org/boost-users/2006/06/20309.php and got an interesting answer, but not really one which satisfies me. Does anyone know if it possible to determine if a class overloads a certain function _where_ the return type is unknown. An example is the -> operator. It can return any type. My question is: is it possible to determine at compile time if some type overloads the -> operator, without knowing the return type when this operator is overloaded? Many thanks, Ovanes

2 1

Re: [Boost-users] date_time microsec_clock::univeral_time() implementation
by Brian Neal 23 Jun '06

23 Jun '06

> Jeff Garland <jeff(a)crystalclearsoftware.com> wrote: > > Brian Neal wrote: > > We have an application that was using our own custom functions for > > getting the OS time. We were basically representing time as the number > > of milliseconds since the UNIX epoch in an unsigned long, or as the > > number of nanoseconds since the epoch in a 64-bit type. > > > > We later discovered boost, and cut everything over to > > boost::date_time. This has worked out very, very well and has > > uncovered several time related bugs in our old code. > > Glad it was helpful :-) > > > However, we do > > have a small percentage of code that is time critical, and we have > > noticed that calling microsec_clock::univeral_time() is 2.6 times > > slower than our old function, and for this one bit of code that is > > significant. > > Ok. > > > Looking at the implementation for UNIX like systems, I see that > > create_time() in microsec_time_clock.hpp is calling gettimeofday() > > followed by a call to gmtime() or localtime() as appropriate. I think > > it's this second call that is the difference between our old code and > > boost. > > Ok. > > > In our time critical chunk of code we are just time tagging events, > > and we aren't concerned about timezone. I was thinking about adding a > > function to our code that called clock_gettime() (which is what our > > old code did), but then constructing a time_type out of that using the > > UNIX epoch for the date part and the results of clock_gettime() for > > the time_duration part, i.e, in pseudo code: > > > > time_type our_get_time() { > > clock_gettime(CLOCK_REALTIME, &timespec); > > time_duration td = massage(timespec); > > return time_type(unix_epoch, td); > > } > > Looks like a solid approach. Of course you don't have to modify > Boost.date_time, you can simply extend it with your own clock implementation. I replied to myself about this to the list, but my messages seem to have gotten out of order, so I'll repeat my findings and amplify a bit below: It turned out, much to my surprise, that the above approach was much, much slower than the current implementation of universal_time(). I suppose that is because it's got an enormous amount of seconds to add onto a date that is 36 years ago, and thus you got all your leap year calculations and stuff. I dunno, I didn't pursue it further. But it was much worse performance. I was doing something like this: const date unixEpoch(1970, Jan, 1); ptime getTime() { struct ::timespec ts; ::clock_gettime(CLOCK_REALTIME, &ts); // error checking omitted const time_duration td(seconds(ts.tv_sec) + nanoseconds(ts.tv_nsec)); return ptime(unixEpoch, td); } So I went back and rethought about how I was using boost::date_time. In our pre-boost code, we were just getting these 32-bit numbers, essentially tick counts, from the OS. We were just using these tick counts for comparisons and deltas, timestamping and stuff. We certainly didn't need full dates, as our events last, at most, 10 seconds. If you think about it, these tick counts are just a duration from some OS specific epoch. Aha, time_duration! So in our time critical code, we replaced all of our ptimes with time_durations, and replaced all calls to universal_time() with a function of our own making (getTimeStamp()), which calls clock_gettime() and forms up a time_duration with the results. This worked perfectly and brought back our performance to the pre-boost levels. For our other, non-critical time code, we just left the ptimes in. > > I'm also curious why gettimeofday() was chosen over clock_gettime()? > > Is one more available than the other? > > Honestly, I don't remember why at this point. There is the issue with > timezone adjustment for the other cases. My guess is portability was a factor > since gettime_clock is only supported in the POSIX real-time spec, although > it's probably pretty widespread now. That said, I'd be willing to improve the > implementation of microsecond_clock with this change where it is possible -- > looks like we can tell by checking CLOCK_REALTIME. I would guess, also, that portability might have been a driver. I do not believe the clock_gettime() is available on cygwin, for example, but gettimeofday() is. > > If you send me a working implementation I can drop it in and try it out ;-) > Well, as I said, the current universal_time() is much faster than treating the results of clock_gettime() as a time_duration from the UNIX epoch. But again, after rethinking our porting to boost, we brought the overkill on ourselves for replacing our tick counts with ptimes. time_durations were a better fit for what we were doing for that one specific case. Thanks. Boost::date_time is a very useful and powerful library!

2 1

Re: [Boost-users] inspecting templates and boost::is_pointer
by Gottlob Frege 23 Jun '06

23 Jun '06

> From: "Ovanes Markarian" <om_boost(a)keywallet.com> > > Hello all, > > I am trying to specialize boost::is_pointer so, that it can determine if a > type is a pointer > wrapper (shared_ptr, auto_ptr, weak_ptr). > > Does anybody has ideas how this can be done? May be it would be possible > to handle if e.g. one can > determine if a class/struct has some typedef inside: > > > You can make a template to detect typedefs - I wrote a has_value_type<T> for value_type. In my case I needed to know if the underlying type was char or wchar_t, so I ended up with a recursive thing that would even resolve things like a 'list of vectors of strings', etc. > > Somehow I am not certain if I am on the right path. My problem is that I > have a variant container > type with different types. One could access a value using -> operator. The > operator returns the > pointer to the value. But if this value is a pointer (that can be > determined by boost::is_pointer > type trait) it should return the pointer and not pointer to pointer value. > Now what happens if I > store shared_ptr or any other type which overload -> operator? This will > result in compiler error, > because the compiler tries to access member of the pointer to pointer and > not of the pointer > instance. You can also write a has_specific_member_function<T>, and thus I suspect you could also do it for operator->(). I think it depends on whether you can take a member function pointer to an operator function. google for has_foo, or try http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/a6… Is there may be a way to determine if the member access operator is > overloaded? What if -> > operator is defined in the base? And what if child class inherits base as > protected or private? Haven't tried any variations on public/protected/private - I suspect that you need to have a template that checks publicly, then another that checks for protected (I suspect that version of has_arrow_op<T> would probably need to derive from T) and I doubt you could tell the difference between a class that doesn't have ->, and a class that has a private ->. But I doubt you would want to know - if it doesn't have a callable ->, then you should probably act like it doesn't have one at all - ie it doesn't want you to think of it as a pointer. The other solution would be to force every user to write a specialized class > is_pointer for every > type stored in variant, but this would be not so nice. > > > With Kind Regards, > > Ovanes Markarian Tony

2 1

Re: [Boost-users] 'standard' free functions for operators, etc
by Gottlob Frege 23 Jun '06

23 Jun '06

> > In other words, if you have an operation F, and two type aliases X and Y > that both resolve to 'int' and you want F to have different semantics when > applied to X and Y, you are effectively not using the C++ type system. You > have imposed your own "logical type system" that is based on names (X and > Y) > and not types. I understand, and to "effectively not using the C++ type system" I would add a subtle twist: "not effectively using the C++ type system" either :-). Yet there is lots of code out there that does this. So, with regards to intrusive_ptr, I guess the answer is that that kind of code is not worth considering when designing intrusive_ptr. Is it worth considering for the_next_boost_thing<T> ? Maybe it depends on the thing, but much of boost is generic, so I think it does make sense to talk about the_next_boost_thing, even out of context. Note also that things like map<> allow the predicate to be specified, instead of using a free map_less(T, T) and assuming map_less is always the same, for a given type. Now I understand that map is a different situation than intrusive_ptr - I'm definitely stretching things a bit. But I'm looking for reasons to use one technique over the other (and also instead of, say, virtual functions / runtime polymorphism, but I think I understand most of the differences there). Obviously passing in a predicate/policy is the way to go when it is reasonable to expect different policies/predicate used *on the same type*, and intrusive_ptr is probably a case where different policies don't make sense. Is that enough to make it better? ie: - a policy based add_ref for intrusive_ptr would allow it to be used in those rare cases where there is a 'type-overlap' or a 'lack of strong typing' HOWEVER, - a policy based approach would *also* allow different add_refs for a single type (ie 'logical' or 'strong' type), which would be senseless and *disasterous* when the type really only has one way of doing add_ref, THUS intrusive_ptr chooses free functions, over a policy-based approach ie we thought about a policy-based approach, but specifically wanted to *enforce* one-add_ref-per-type, or we didn't even think about it (at least not consciously), it was just the natural and obvious thing to do Anyhow, looking at it that way maybe teaches me something.... Tony

2 1

gcc + stlport + boost 1_33_0
by William Deegan 22 Jun '06

22 Jun '06

Greetings, We're using gcc 3.2.3 stlport 4.61 and boost 1_33_0. When compiling some code which uses scoped_ptr, it was necessary to remove the explicit call to std::auto_ptr and change it to use just plain auto_ptr. I've attached the diffs below. Is there a boost configuration or other change I would need to make to allow this combination to compile without the below changes. So std::auto_ptr<> would be resolvable? Thanks, Bill These are the files I had to modify: M boost/intrusive_ptr.hpp diff -r1.2 intrusive_ptr.hpp 210c210 < return std::less<T *>()(a.get(), b.get()); --- > return less<T *>()(a.get(), b.get()); 257c257,258 < template<class E, class T, class Y> std::basic_ostream<E, T> & operator<< (std::basic_ostream<E, T> & os, intrusive_ptr<Y> const & p) --- > using _STL::basic_ostream; > template<class E, class T, class Y> basic_ostream<E, T> & operator<< (basic_ostream<E, T> & os, intrusive_ptr<Y> const & p) M boost/scoped_ptr.hpp diff -r1.2 scoped_ptr.hpp 63c63 < explicit scoped_ptr(std::auto_ptr<T> p): ptr(p.release()) // never throws --- > explicit scoped_ptr(_STL::auto_ptr<T> p): ptr(p.release()) // never throws M boost/shared_array.hpp diff -r1.2 shared_array.hpp 160a161 > using _STL::less; 163c164 < return std::less<T*>()(a.get(), b.get()); --- > return less<T*>()(a.get(), b.get()); M boost/shared_ptr.hpp diff -r1.2 shared_ptr.hpp 197c197 < explicit shared_ptr(std::auto_ptr<Y> & r): px(r.get()), pn() --- > explicit shared_ptr(_STL::auto_ptr<Y> & r): px(r.get()), pn() 221c221 < shared_ptr & operator=(std::auto_ptr<Y> & r) --- > shared_ptr & operator=(_STL::auto_ptr<Y> & r) 437c437,438 < template<class E, class T, class Y> std::basic_ostream<E, T> & operator<< (std::basic_ostream<E, T> & os, shared_ptr<Y> const & p) --- > using _STL::basic_ostream; > template<class E, class T, class Y> basic_ostream<E, T> & operator<< (basic_ostream<E, T> & os, shared_ptr<Y> const & p) M boost/detail/shared_count.hpp diff -r1.2 shared_count.hpp 138c138 < explicit shared_count( std::auto_ptr<Y> & r ): pi_( new sp_counted_impl_p<Y>( r.get() ) ) --- > explicit shared_count( _STL::auto_ptr<Y> & r ): pi_( new sp_counted_impl_p<Y>( r.get() ) ) 213c213 < return std::less<sp_counted_base *>()( a.pi_, b.pi_ ); --- > return _STL::less<sp_counted_base *>()( a.pi_, b.pi_ ); 307c307 < return std::less<sp_counted_base *>()(a.pi_, b.pi_); --- > return _STL::less<sp_counted_base *>()(a.pi_, b.pi_);

1 0

[Review results][PQS]
by fred bertsch 22 Jun '06

22 Jun '06

The Physical Quantities System review has ended, and, unfortunately, we are going to have to turn it down at this time. However, it is clear from the reviews that there is an enormous amount of interest in the library. I'm really hoping that that Andy Little will continue his work on it and resubmit it for review. Andy has been following the large discussion of PQS, so I will not enumerate the more minor criticisms included there. Some of the major criticisms that influenced my difficult decision include the following: * Many of the reviews liked the documentation, but improvements there would help out for a large number of reviewers. * If the library were more flexible about the type system used, several reviewers would have been happier. However, I would suggest that as long as a plan is in place for improving the flexibility, this should not prevent an initial version of the library from being accepted. * Since the library includes a large number of compile-time type manipulations, it would be great if the library included standard metafunctions to query these types. In addition, following other template metaprogramming conventions established within Boost such as documenting the concepts used would be a great help. I'd like to thank Andy Little for the work done so far on PQS and also for responding rapidly to the prolific discussion on the developer's list. -Fred Bertsch

4 5

Re: [Boost-users] 'standard' free functions for operators, etc
by Gottlob Frege 22 Jun '06

22 Jun '06

> From: "Peter Dimov" <pdimov(a)mmltd.net> > intrusive_ptr_add_ref is passed a pointer to a class with an embedded > reference count. It doesn't matter how many typedefs resolve to X*, X > still > has its reference count that needs to be incremented. > > You only run into the problem when "assign" is underspecified and > overloaded > to mean different things in different contexts. I understand your point, and maybe it is not a problem for intrusive_ptr in all pratical cases, but intrusive_ptr_add_ref is passed a T *. T may or may NOT be a class. ie T could be an int or an HWND (which is often just void *, depending on #define STRICT) or some other handle, or whatever. Maybe all those examples are a bit ugly - ie the int would have to be something like an index into a global array, or something like that. But it is not necessarily a distinct 'class' that holds its refcount intrinsicly. Or maybe it is necessarily that, but only because of how intrusive_ptr_add_ref was done, not for any other reason. So intrusive_ptr is ever so slightly more restrictive than it need be. Probably not a big deal. Note also, that for those few strange cases, you could also just wrap the HWND or whatever into a class, but then of course, intrusive_ptr could have just required the class to have a specific add_ref member function (and then you might need to wrap all classes). So maybe intrusive_ptr is just an example and not necessarily the best one, but I still wonder 1. if policy based could have been the same for 95% of the cases, and better for the last 5%, 2. there are any other techniques to consider. Either for intrusive_ptr or boost iterators or other places where I want to use the same techniques. I think that's the real question - if I am going to borrow some idioms for boost or wherever, I'd like to borrow the right ones for the right situations. Tony

2 1

linking
by Tamas Hegedus 22 Jun '06

22 Jun '06

Hi, I am newbie to c/cpp and I have linking and/or loading shared library problem. I can not link with dynamic libraries. Thanks for your help in advance, Tamas *** 1 *** [violin]$ ldconfig -p | grep libboost_program_options libboost_program_options.so.1 (libc6) => /usr/lib/libboost_program_options.so.1 *** 2 *** As I do not have the file /usr/lib/libboost_program_options.so.1 I created a link: libboost_program_options.so.1 -> libboost_program_options-gcc-1_33_1.so.1.33.1 *** 3 *** Compiling my src file [violin]$ g++ -Wall -I /usr/local/include/boost-1_33_1 -c test.cpp *** 4A *** [violin]$ g++ -Wall -o test test.o /usr/local/lib/libboost_program_options-gcc-1_33_1.so.1.33.1 [violin]$ ./test ./test: error while loading shared libraries: libboost_program_options-gcc-1_33_1.so.1.33.1: cannot open shared object file: No such file or directory *** 4B *** [violin]$ g++ -Wall -o test test.o /usr/local/lib/libboost_program_options.so.1 [violin]$ ./test ./test: error while loading shared libraries: libboost_program_options-gcc-1_33_1.so.1.33.1: cannot open shared object file: No such file or directory *** 4C *** [violin]$ g++ -Wall -o test test.o /usr/local/lib/libboost_program_options-gcc-1_33_1.a [violin]$ ./test Compression level was not set. -- Tamas Hegedus, PhD | phone: (1) 919-966 0329 UNC - Biochem & Biophys | fax: (1) 919-966 5178 6107 Thurston-Bowles Bldg | mailto:hegedus@med.unc.edu Chapel Hill, NC, 27599-7248 | http://biohegedus.org

3 2

Re: [Boost-users] Trap in regex library (help requested)
by Marty Eaves 22 Jun '06

22 Jun '06

Hi John, When I attempted to isolate the code and make a simple VC7 project, I did not have the problem any longer either. I think I have found a solution to the problem I was trying to solve, so I will continue to work in that direction and get back with you if I have any issues... Thanks for the update on the regression test. Marty ________________________________ Marty Eaves STAFF SOFTWARE ENGINEER CALL PROCESSING & MEDIA SERVICES RESEARCH AND DEVELOPMENT INTERVOICE, INC. P: (972) 454-8348 marty.eaves(a)intervoice.com ________________________________ Intervoice: Connecting People and Information. -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Friday, June 16, 2006 6:58 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Trap in regex library (help requested) Marty Eaves wrote: > John, > > Thanks, I'll look into the STL compatibility. We were using STL port > with VC6, but I think we are using the Microsoft STL with VC7. I'll > double check. > The test case failing is using the above grammar with the value of > into > the "inputValue" parameter set to "2" in the code snippet below: If you want me to look at that further you'll need to break it down into a nice easy test case, that I can just compile and test right off. BTW I've just run the main regression test programs with VC7.1 and managed code, and captures enabled, and everything checks out OK. John. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are the intended recipient, you must treat the information in confidence and in accordance with all laws related to the privacy and confidentiality of such information. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies of this email, including all attachments.

1 0