June 2006 - Boost-users - lists.boost.org

Re: [Boost-users] Boost Variant OutputStreamable
by Ovanes Markarian 26 Jun '06

26 Jun '06

Hi! Can you please to compile this code either with string in the variant or a vector. Not sure if it helps but the variant documentation at http://www.boost.org/doc/html/variant/reference.html states: namespace boost { template<typename T1, typename T2 = unspecified, ..., typename TN = unspecified> class variant; template<typename Sequence> class make_variant_over; template<typename T1, typename T2, ..., typename TN> void swap(variant<T1, T2, ..., TN> &, variant<T1, T2, ..., TN> &); template<typename ElemType, typename Traits, typename T1, typename T2, ..., typename TN> std::basic_ostream<ElemType,Traits> & operator<<(std::basic_ostream<ElemType,Traits> &, const variant<T1, T2, ..., TN> &); } Which means that the types are not zero-index based. So your T5 would be a string and not a vector. Make some tests like with simple integers, strings and finally a vector and see what happens. Best Regards, Ovanes -----Original Message----- From: Nindi [mailto:Nindi73@yahoo.co.uk] Sent: Sunday, June 25, 2006 15:36 To: boost-users(a)lists.boost.org Subject: [Boost-users] Boost Variant OutputStreamable I have started using Boost recently, and though I should switch my own variant to the Boost Variant . However I cannot compile the following code #include<iostream> #include<vector> #include<string> #include<boost/variant.hpp> std::basic_ostream<char> &operator<<(std::basic_ostream<char> &theostream,const std::vector<unsigned long> &theVector) { for(unsigned long i(0);i<theVector.size();i++) theostream << theVector[i] << "\n" ; return theostream; } struct TpTemplateVariant { typedef boost::variant< int, unsigned long, double, bool, std::string, std::vector<unsigned long> > BoostVariant; }; typedef TpTemplateVariant::BoostVariant Tpvariant; int main () { Tpvariant p(5); std::cout << p; return 0; } The error I get is error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'const T5'

1 0

[BGL] total newbie question
by pixelpusher＠cox.net 25 Jun '06

25 Jun '06

Sorry for the newbieishness of the question, but I'm just getting started with C++ templates in general and Boost.Graph in particular. It seems to me that, while there is plenty of it, the documentation assumes a level of understanding of templates and other OO principles that I simply don't have at this point. Normally, I'd start digging into the example programs and look for common points of reference with things I already know and use the comments in the code for guidance. However, the example programs for BGL are astonishingly devoid of comments. They seem to be written for folks who already know how BGL works, not for folks who are trying to learn it. Most of what I see in the examples leaves me scratching my head and wondering WTF am I getting myself into here. Anyway, what I was hoping to find was more of a tutorial in how to get started writing a path-finding program using BGL and (probably) the Dijkstra-shortest paths template. - I have a set of edges that I will read from a text file. I don't know in advance how many edges will be read, so I plan to use an std::vector to store each edge's id, nodes, and weight. (All of the examples construct an array of known size and use that to build the graph. None use variable sized structures to build the graph.) Unless, of course, I can load the graph without pre-constructing a storage scheme. - The edge weights have to be modified based on the user's preferences, which will change with every run. (None of the examples show how to change edge weights.) - I will have known starting and ending nodes. I don't need to know the paths from my source to every possible destination. I only need to extract the best one that leads to my destination. I'd be happy enough for now just to know how to get started on the first bullet. Can anyone provide any guidance here? I'd really appreciate it. Thanks, Thom -- ------------------------------------------------------- Man will occasionally stumble over the truth, but most of the time he will pick himself up and continue. -- Winston Churchill

3 2

Re: [Boost-users] Strange compiler behaviour with mpl::vector
by Ovanes Markarian 25 Jun '06

25 Jun '06

Sorry, in the error message you will read the type name discriminated_union. This is the real type name, think of it as my_class. Thanks and sorry again, Ovanes _____ From: Ovanes Markarian [mailto:om_boost@keywallet.com] Sent: Sunday, June 25, 2006 23:18 To: 'boost-users(a)lists.boost.org' Subject: Strange compiler behaviour with mpl::vector Hello all! I posted the following message http://lists.boost.org/boost-users/2006/06/20271.php a few days ago, but did not get any replies. I know there is an error in the const_ref class. But nevertheless the problem which occures is that my class accepts a vector of supported types as template parameter. It has two constructors (no default ctor): template<class Seq_> class my_class { public: typedef my_class<Seq_> this_type; explicit inline my_class(const this_type& copy_from) :... {...} template<class TypeFromVector> explicit inline my_class(typename const_ref<TypeFromVector>::type inst) :... {...} }; Now if I try to initialize my_class with type declared in vector I get an error: error C2664: 'discriminated_union<Seq_>::discriminated_union(const discriminated_union<Seq_> &)' : cannot convert parameter 1 from 't1' to 'const discriminated_union<Seq_> &' with [ Seq_=types_vector ] Reason: cannot convert from 't1' to 'const discriminated_union<Seq_>' with [ Seq_=types_vector ] No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called Ok, if I define the ctor param without typename const_ref<...>::type everything goes fine, if I use const_ref it fails. const_ref is defined as follows: template<class Ty> struct const_ref : boost::add_reference < typename boost::add_const < typename boost::remove_reference<Ty>::type >::type > {}; I can understand that the compiler is unable to make a decision which ctor to use, but I do not get an ambiguaty error. It seems like the compiler simply quits expanding templates and uses the last most successful ctor matched before the error. This happens only when I use mpl::vector templated type in conjunction with templated ctor. Other types like below work fine: template<int D_, class Ty_> struct my_pair : mpl::pair<mpl::int_<D_>, Ty_> { typedef my_pair<D_, Ty_> my_type; inline my_pair() {} explicit inline my_pair( typename const_ref<Ty_>::type ty) : second_(ty) {} explicit inline my_pair(const my_type& other) : second_(other.second_) {} inline my_type& operator =(const my_type& other) { second_=other.second_; return *this; } second second_; }; May be some of you have any suggestions. Thanks a lot, Ovanes Markarian

1 0

Boost Variant OutputStreamable
by Nindi 25 Jun '06

25 Jun '06

I have started using Boost recently, and though I should switch my own variant to the Boost Variant . However I cannot compile the following code #include<iostream> #include<vector> #include<string> #include<boost/variant.hpp> std::basic_ostream<char> &operator<<(std::basic_ostream<char> &theostream,const std::vector<unsigned long> &theVector) { for(unsigned long i(0);i<theVector.size();i++) theostream << theVector[i] << "\n" ; return theostream; } struct TpTemplateVariant { typedef boost::variant< int, unsigned long, double, bool, std::string, std::vector<unsigned long> > BoostVariant; }; typedef TpTemplateVariant::BoostVariant Tpvariant; int main () { Tpvariant p(5); std::cout << p; return 0; } The error I get is error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'const T5'

1 0

Re: [Boost-users] inspecting templates and boost::is_pointer
by Michael Nicolella 24 Jun '06

24 Jun '06

You passed has_xxx to the macro - It would make sense to only pass xxx (looks like an error in the example): BOOST_MPL_HAS_XXX_TRAIT_DEF(xxx) Also, you'll need to instantiate the has_xxx template: typedef has_xxx<test2> my_test; Mike -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Ovanes Markarian Sent: Saturday, June 24, 2006 12:22 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] inspecting templates and boost::is_pointer Dave, thanks for your answer. I think this should be definitely a part of FAQ, otherwise someone could spent endless hours on matters why some of boost classes do not work as expected. I have one more question. I tried the following code with VC 8.0: #include <boost/mpl/has_xxx.hpp> struct test2 { typedef int xxx; }; BOOST_MPL_HAS_XXX_TRAIT_DEF(has_xxx) typedef has_xxx my_test; And got a compiler error: main.cpp(22) : error C2146: syntax error : missing ';' before identifier 'my_test' Somehow the macro was not expanded. I replaced xxx with some other name before but end up in compiler errors, so that I decided to check if the standard example is compilable at all by using the typedef. Do you have any suggestions? Thanks, Ovanes -----Original Message----- From: David Abrahams [mailto:dave@boost-consulting.com] Sent: Saturday, June 24, 2006 04:51 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] inspecting templates and boost::is_pointer "Ovanes Markarian" <om_boost(a)keywallet.com> writes: > 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). First of all, don't do that. It's a really bad idea, and it will probably break some (Boost) library code. is_pointer is supposed to detect real pointers, and if you start changing what it does with other types, you'll break the expectations of every bit of code that currently uses is_pointer. This has come up before, so maybe it should be a FAQ (John?) > 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: http://www.boost.org/libs/mpl/doc/refmanual/has-xxx-trait-def.html -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[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