- Boost - lists.preview.boost.org

RE: [boost] seiralization of shared_ptr
by Rozental, Gennadiy 19 May '04

19 May '04

> Some time ago the question was raised on this list as to why > it was necessary to access share_count in order to implement > serialization of shared_ptr. At the time I didn't have an answer. > > So I went back and tried to re-implement it and have come to > the following point beyond which I can't proceed without > manipulating shared_count directly. > > ///////////////////////////////////////////////////////////// > // implement serialization for shared_ptr<T> > > template<class Archive, class T> > inline void save( > Archive & ar, > const shared_ptr<T> & t, > const unsigned int /* file_version */ > ){ > ar << boost::serialization::make_nvp("px", t.get()); > } > template<class Archive, class T> > inline void load( > Archive & ar, > shared_ptr<T> & t, > const unsigned int /* file_version */ > ){ > // object tracking guarantees that pointers are not replicated > // on loading. > T * t_new; > ar >> boost::serialization::make_nvp("px", t_new); > // if its not the first time, it should be equal to the current pointer > assert(0 == t.use_count() || t.get() == t_new); > // assign new pointer or bump reference count as appropriate > // ???? - what goes here? > } > > Can anybody tell me "what goes here?" > > Robert Ramey I don't see problem where you see it. I ses problem in different place. How is it possible that t.use_count() != 0? My understanding that before loading all data is empty and you never actually load the same variable twice. struct A { shared_ptr<int> member; load(...) { ar >> member; } }; A a1, a2 ar >> a1; ar >> a2; Now the real problem lies IMO in a fact that you need to keep map raw ptr -> corresponding shared_ptr. IOW when you got raw ptr and you need to create shared ptr for it you need to figure out somehow whether you already did it. If yes you need to make a copy to that shared_ptr. If not create new and register it. Gennadiy.

1 0

python 'in' syntax mini-lib RFC
by Max Khesin 19 May '04

19 May '04

I have been playing around with a library to emulate Python 'in' syntax if(a in [x1, x2]): stuff the main motivation for this is the annoyance of repeating the || operator with the same value in C++ if(val==v1 || val==v2 || val==v3){ ^^^ ^^^ ^^^ } I figured I would use tuple for the list to allow membership test for a list of heterogeneous types (just like python). The rough results are included below. I am interested in your feedback: 1) how useful would you find this in general 2) there are 3 variations on syntax in the main() 1st is native(no macros) with more typing, 2 is less typing with macros, 3d is even less but does not compile :) (coule use a language lawer here). Do you like any of these? Alternative suggestions? 3) implementation - is it correct (I know it's not since is_convertible is used to mean is_comparable, any suggestion), can it be simplified internally or by using other boost libs? thanks, max ///////////////////////////////////////////////////////////////// #include <boost/tuple/tuple.hpp> #include <boost/tuple/tuple_io.hpp> #include <boost/type_traits/is_convertible.hpp> #include <iostream> using std::cout; // compare the values is they are comparable (is_convertible is not // good enough for all cases, suggestions?) template<bool> struct compare_convertible; template<> struct compare_convertible<false> { template<class T1, class T2> bool operator()(const T1&, const T2& ){return false;} }; template<> struct compare_convertible<true> { template<class T1, class T2> bool operator()(const T1& val1, const T2& val2){return val1==val2;} }; template<class T1, class T2> bool compare_if_convertible(const T1& val1, const T2& val2) { return compare_convertible<boost::is_convertible<T2, T1>::value>()(val1, val2); } template<class T, class TupleT> bool contains(const T& val, const TupleT& the_tuple) { return (compare_if_convertible(val, the_tuple.get_head()) // check head || (boost::tuples::length<TupleT::tail_type>::value// not empty && contains(val, the_tuple.get_tail()))); // check tail } // value wrapper, provides the -- part of the --> syntax template<class T> struct Element { const T& val; const Element& operator--(int)const {return *this;} Element(const T& val_):val(val_){} }; template<class T> Element<T> element(const T& val) { return Element<T>(val); } // provides the '>' part of the '-->' syntax template<class ElemT, class T1, class T2> bool operator>(const Element<ElemT>& element, const boost::tuples::cons<T1, T2> the_tuple) { return contains(element.val, the_tuple); } #define in -->boost::make_tuple #define in2 >boost::make_tuple int main(int argc, char* argv[]) { if(element(1.4) --> boost::make_tuple(1, "aa", 1.2)) { std::cout<<"yahuuu\n"; } if(element(1.0) in (1, "aa", 1.2)) { std::cout<<"yahuuu\n"; } #if 0 // will not compile due to // test.cpp(92) : error C2784: 'bool operator >(const Element<ElemT> &,const boost: // :tuples::cons<T1,T2>)' : could not deduce template argument for 'const Element<T // > &' from 'double' // test.cpp(73) : see declaration of 'operator`>'' // test.cpp(92) : error C2677: binary '>' : no global operator found which takes ty // pe 'boost::tuples::detail::make_tuple_mapper<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9>::ty p // e' (or there is no acceptable conversion) // with // [ // T0=int, // T1=const char [3], // T2=double, // T3=boost::tuples::null_type, // T4=boost::tuples::null_type, // T5=boost::tuples::null_type, // T6=boost::tuples::null_type, // T7=boost::tuples::null_type, // T8=boost::tuples::null_type, // T9=boost::tuples::null_type // ] // if(1.0 in2(1, "aa", 1.2)) { std::cout<<"yahuuu\n"; } #endif return 0; } This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

RE: [boost] [test library patch for como]
by Rozental, Gennadiy 19 May '04

19 May '04

> Rozental, Gennadiy wrote: > > Does it incorrect from standard standpoint: > > > > class A { > > int member; > > }; > > > > class B : A { > > public: > > using A::member; > > }; > > > > If it is allowed why so many compilers having issues with it? > > I don't see why you think it should be allowed. A::member is > private, not protected. It's not accessible from B. Sorry I meant protected of course. class A { protected; int member; }; class B : A { public: using A::member; }; Gennadiy

1 0

RE: [boost] [test library patch for como]
by Rozental, Gennadiy 19 May '04

19 May '04

Does it incorrect from standard standpoint: class A { int member; }; class B : A { public: using A::member; }; If it is allowed why so many compilers having issues with it? Gennadiy.

3 2

Re: [boost] [preprocessor] math macros
by Cromwell Enage 19 May '04

19 May '04

--- Paul Mensonides <pmenso57(a)comcast.net> wrote: > Hi Cromwell, Hello! > FYI, these macros don't belong in the preprocessor > library (pp-lib). That library is a set of macros > (etc.) designed to be used to generate C and C++ > code. They don't actually generate that code > themselves. Ah, understood. > That isn't saying anything about whether your > implementation is good or bad or whether it belongs > in Boost. Only that it doesn't properly belong in > the pp-lib. Instead, your macros are clients of the > pp-lib. They should probably go with the rest of > the math stuff (<boost/math/...>) and use a plain > BOOST_ or BOOST_MATH_ prefix (but definitely not > BOOST_PP_). Okay, I'll reorganize everything. > In order to be part of the pp-lib, the macros would > have to calculate their results at preprocessing > time. For example, BOOST_PP_ADD(5, 5) expands to 10 > (the single token), not (5 + 5). Does that make > sense? Gotcha. I don't see how I can do that with my lib without an inordinate amount of work, so unless someone else can see how, I'll stop trying. Thanks for clearing things up! I'll try not to be so presumptuous next time. Cromwell Enage __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/

1 0

RE: [boost] [Test] Test library failing to build on MetaComm inte l-win32-7.1-vc6
by Rozental, Gennadiy 19 May '04

19 May '04

> On Friday 14 May 2004 01:20 pm, Rozental, Gennadiy wrote: > > Do you have any suggestions? > > I've fixed it on Borland, and tried to fix it on Intel 7.1, > Comeau, and Sun > based on the error messages (but I don't have those compilers > handy to test). > > Doug This is not a fix I am looking for. What you did makes whole facility useless on affected compiler. I look for solution that will retain functionality. Gennadiy.

3 2

[test library patch for como]
by Thorsten Ottosen 19 May '04

19 May '04

Hi, I have no idea what the number (second argument) should be. But it worked. br Thorsten begin 666 class_properties.hpp.diff M+2TM(&-L87-S7W!R;W!E<G1I97,N:'!P"3(P,#0M,#4M,C @,# Z,CDZ,3@N M-S,P-34R,# P("LQ,# P#0HK*RL@8VQA<W-?<')O<&5R=&EE<RYH<' N;VQD M"3(P,#0M,#4M,C @,# Z,C8Z,#DN,3 W.#@X,# P("LQ,# P#0I 0" M-38L M-R K-38L-R! 0 T*( T*(" @(" O+R!$871A(&UE;6)E<G,-"B -"BTC:68@ M0D]/4U1?5T]22T%23U5.1"A?7T)/4DQ!3D1#7U\L(#P](#!X-3<P*2!\?"!" M3T]35%]73U)+05)/54Y$*"!?7T-/34]?7RP@/#T@,'@T,S,@*0T**R-I9B!" M3T]35%]73U)+05)/54Y$*%]?0D]23$%.1$-?7RP@/#T@,'@U-S I#0H@(" @ M("\O($)O<FQA;F0@8V%N)W0@9&5A;"!W:71H('1H92!U<VEN9R!D96-L87)A M=&EO;B!I;B!D97)I=F5D(&-L87-S97,-"B C96QS90T*('!R;W1E8W1E9#H- !"@`` ` end

1 0

Re: [boost] Re: BUG: mpl and iso646.h in vc7
by Aleksey Gurtovoy 19 May '04

19 May '04

Ken Hagan writes: > > Ian Baxter wrote: > >> Boosters, > >> > >> Microsoft's macro hacks in the iso646.h header unfortunately kills > >> the current MPL implementation. The headers or.hpp, and.hpp are > >> substituted as ||.hpp, &&.hpp! > > Eric Niebler wrote: > > > > I don't think changing the header names is the right solution. Since > > you're on VC7, you can use the push_macro and pop_macro pragmas to > > work around the issue. > > > > // file: or_.hpp > > #pragma once > > #pragma push_macro("or") > > #include <boost/mpl/or.hpp> > > #pragma pop_macro("or") > > Nice workaround, but it won't help you much if you are using a library > that uses MPL. Renaming the header will upset everyone's sense of > aesthetics, but resolves the problem once and for all. > > Incidentally, I assume VC7 is looking at > > #include <boost/mpl/or.hpp> > > and macro expanding the "or". The standard text for preprocessing phase > 4 does indeed begin "Preprocessing directives are executed and macro > invocations are expanded.", but the text for phase 3 begins "The source > file is decomposed into preprocessing tokens..." and I would have > thought that "boost/mpl/or.hpp" (without the quotes) was a single > h-char-sequence in this context so there is no invocation of the "or" > macro here. > Clearly at least one of "me" and "VC" must be wrong here. You are both right :). In #include <boost/mpl/or.hpp> 'boost/mpl/or.hpp' *is* a single h-char-sequence and MSVC does *not* perform macro substitution here. The problem Ian reported was caused by the code that roughly looked like this: # define HEADER or.hpp # include BOOST_PP_STRINGIZE(boost/mpl/aux_/preprocessed/HEADER) Fixed in the CVS now. No changes are required on user part. Thanks to everybody, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

bug in Wave/flex_string with VC7+dinkumware
by Reece Dunn 19 May '04

19 May '04

BOOST_NO_STD_ITERATOR_TRAITS does not work for VC7 + Dinkumware when using it to identify whether std::reverse_iterator is C++98 or an older/broken implementation. BOOST_NO_STD_ITERATOR does work, however. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

2 1

RE: [boost] Re: basic_string interface generator
by Reece Dunn 19 May '04

19 May '04

Pavel Vozenilek wrote: >"Max Khesin" <MKhesin(a)liquidnet.com> wrote: > > > Just curious: > > what do you think of Andrei's work on policy-based strings: > > http://www.cuj.com/documents/s=7994/cujcexp1906alexandr/alexandr.htm > > http://moderncppdesign.com/code/flex_string.zip I have only previously come across it in passing and have not had a chance to take a look at it. I am studying it at the moment: a very good library! > > - does it do what you want (or leave flexibility to do what you want) > > - if so why not just use it > > - if not what doesn't it do >From what I understand thus far, usage would be like this: boost::flex_string< char, std::char_traits< char >, std::allocator< char >, VectorStringPolicy< char > > vecstr; which is too weildy. It would be possible to use the template typedef concept to have something like: template< typename CharT, template< typename C, class A > class Storage, class Traits, class AllocT > struct cust_string { typedef boost::flex_string< CharT, Traits, AllocT, Storage< CharT, AllocT > > type; }; cust_string< char, VectorStringPolicy >::type vecstr; If you want a special string type, you will need to do something like this: template< typename CharT, class A = std::allocator< CharT > > class MyCustStorage{ ... }; template< typename CharT, class Traits > class mybasic_string: public boost::flex_string< CharT, Traits, std::allocator< CharT >, Storage< CharT > > { public: mybasic_string(){} // ... }; Where you are essentially having to write more code. What I am ideally looking for is something similar to what the iterator adaptors do, allowing: template< typename CharT, class Traits > class mybasic_string: public boost::string_adaptor< mybasic_string, CharT, Traits > { public: const CharT * c_str(){ ... } // ... public: mybasic_string(){} // ... }; Another minor point is that the policy classes do not meet the standard/Boost naming convention. Also: what if you want to use a different string type for substrings than the type being used? As an example, I have a fixed-capacity string fixed_string< n, CharT > that is equivalent to CharT[ n ], and guards against buffer overflow on the string operations (as a safe replacement for the equivalent C operations). In order to write code generically on them without using template code, I have an abstract class: class char_string { public: virtual const char * c_str() = 0; virtual size_t length() = 0; // ... }; template< size_t n, typename CharT = char, ... > class fixed_string: public char_string // note: MPL code to select char or wchar_t version { CharT str[ n ]; size_t len; public: inline const CharT * c_str(){ return( str ); } inline size_t length(){ return( len ); } // ... }; inline void printme( const char_string & s ) { std::cout << s.c_str(); } With this, you can't use char_string as a standard type (it needs to be a reference or pointer) because you'd get an error about instantiating an abstract base class. >Just remark: Andrei's flex_string is already included in Wave, (future) >Boost library. :) Regards, Reece _________________________________________________________________ Get a FREE connection, FREE modem and one month's FREE line rental, plus a US or European flight when you sign up for BT Broadband! http://www.msn.co.uk/specials/btbroadband

1 0