- Boost - lists.boost.org

RE: [boost] Re: Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 18 May '05

18 May '05

> -----Original Message----- > From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: 16 May 2005 16:30 > To: boost(a)lists.boost.org > Subject: [boost] Re: Re: Non-intrusive serialization with VC2003 (7.1) > > Note the "long int hack" isn't used with vc 7.1 as it support > correct partial template ordering. Interesting. Still doesn't explain why the compiler is trying to use the intrusive stuff, rather than the non-intrusive layer, at least to my relatively unschooled C++ mind. Is there anything I should do, or should I try something like writing wrapper classes for everything? > Marcin Tustin wrote: > >> -----Original Message----- > >> From: Robert Ramey [mailto:ramey@rrsd.com] > >> Sent: 13 May 2005 15:51 > >> To: boost(a)lists.boost.org > >> Subject: [boost] Re: Non-intrusive serialization with VC2003 (7.1) > >> > >> Try putting your function inside the namespace D2 > > > > I did. I also tried putting it in the global namespace. Same error. > > > >> Robert Ramey > >> > >> Marcin Tustin wrote: > >>> I'm trying to use the serialization and archive > libraries, and I'm > >>> having a bit of trouble getting non-intrusive serializaton > >> to work; I > >>> keep getting the error > >>> "c:\boost_1_32_0\boost\serialization\access.hpp(106): error C2039: > >>> 'serialize' : is not a member of 'D2::Message'". My guess > >> is that for > >>> some reason the "long int" hack isn't working properly. I have > >>> serialize methods in the boost::seralization namespace like this: > >>> > >>> namespace boost { > >>> namespace serialization { > >>> template<class Archive > > >>> static void serialize(Archive & ar, const > >> D2::Message& g, const > >>> unsigned int version) > >>> { > >>> //... > >>> } > >>> > >>> } }; > >>> > >>> Which are textually before any use of the library, as far > as I can > >>> tell. > >>> > >>> Any help would be much appreciated. > >>> > >>> Marcin Tustin > >>> IT Innovation Centre > >>> 2 Venture Road > >>> Chilworth Science Park > >>> Southampton, SO16 7NP, UK > >>> > >>> tel: +44 23 8076 0834 > >>> fax: +44 23 8076 0833 > >>> > >>> mailto:mt@it-innovation.soton.ac.uk > >>> http://www.it-innovation.soton.ac.uk > >>> > >>> _______________________________________________ > >>> Unsubscribe & other changes: > >>> http://lists.boost.org/mailman/listinfo.cgi/boost > >> > >> > >> > >> > >> > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > >

2 4

[python] Patch for Tru64/cxx
by Markus Schöpflin 18 May '05

18 May '05

Attached patch allows the python library to successfully build on Tru64/cxx65. Ok to commit? Markus Index: registry.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/python/src/converter/registry.cpp,v retrieving revision 1.28 diff -u -w -r1.28 registry.cpp --- registry.cpp 16 May 2005 03:31:12 -0000 1.28 +++ registry.cpp 18 May 2005 09:41:25 -0000 @@ -161,11 +161,13 @@ assert(slot == 0); // we have a problem otherwise if (slot != 0) { - std::string msg( - "to-Python converter for " - + lexical_cast<std::string>(source_t) - + " already registered; second conversion method ignored." - ); + std::string msg("to-Python converter for "); +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590042)) + msg += source_t.name(); +#else + msg += lexical_cast<std::string>(source_t); +#endif + msg += " already registered; second conversion method ignored."; if ( ::PyErr_Warn( NULL, const_cast<char*>(msg.c_str()) ) ) {

2 2

Why protect()?
by alex 18 May '05

18 May '05

I test the sample in the section "Nesting STL algorithm invocations": -------------------------------------- int a[100][200]; int sum = 0; std::for_each(a, a + 100, bind(ll::for_each(), _1, _1 + 200, protect(sum += _1))); ------------------------------------------------If I remove the protect function, and I will get a complie error.Thx!

2 1

program_options version
by Janusz Piwowarski 18 May '05

18 May '05

Hi, I think that BOOST_PROGRAM_OPTIONS_VERSION should be incremented in 1.33 release. Regards, Janusz

1 0

[serialization] problems in Comeau
by Joaquín Mª López Muñoz 18 May '05

18 May '05

Boost.Serialization is currently failing to build in Comeau 4.3.3, apparently for legitimate reasons: http://tinyurl.com/adv2g The detail type helper_type in libs/serialization/src/basic_oarchive.cpp contains the following member: const boost::serialization::extended_type_info * const m_eti; whose constness prevents the compiler from generating a default assignment operator for helper_type. Hence helper_type is not Assignable and thus cannot be used in a STL container like attempted at line 164 in the same archive: std::set<helper_type, helper_compare> m_helpers; I guess removing the const qualifier of m_eti would suffice to make this error go away. Any objection to me applying the attached patch (confirmed to work on MSVC, yet untested in Comeau)? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 143c143 < const boost::serialization::extended_type_info * const m_eti; --- > const boost::serialization::extended_type_info * m_eti; 146c146 < const boost::serialization::extended_type_info * const eti --- > const boost::serialization::extended_type_info * eti

2 1

Re: [boost] Re: Re: Re: char[] support in Boost.Range
by dan marsden 18 May '05

18 May '05

> Anyway, that wasn't my point. My point was that > it is really easy to get the array behavior if you > want it. > > The only part missing is direct support in the range > library > to trigger array behavior for range arguments, say > as_array(). It seems strange to need to force the more basic behaviour of an unconstrainted array of chars with zero cost for establishing the bounds, and default to higher level behaviour implying a delimiter and a linear cost to calculate the bounds. Some of this depends on what you perceive as the common case, but the differing behaviour between char[N] and MyType[N] presents a lack of uniformity that could hurt generic code developers and confuse users. Dan ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

4 5

operators.hpp bugs
by Søren Lassen 17 May '05

17 May '05

I have found a couple of "undocumented features" in operators.hpp: 1) The return values from a lot of the binary operators should be declared const, so that it is not possible to assign to the temporary object that results from the operation. An example: if(!(a/b=c/d))... This statement is obviously a typo. The assignment operator= should have been a comparison operator==. With the current definition of operator/ in operators.hpp, the compiler will not recognize this as an error. Instead, the following will happen: first, the values of a/b and b/c are calculated and placed in temporary objects. Then, the result of a/b is overwritten by the result of c/d. Finally, operator! converts that to a boolean and the if statement acts on it (in other words, the statement is probably interpreted as "if(!c)..."). If, on the other hand, the return value from operator/ is declared constant, the compiler will catch the error, and probably say something like "lvalue required". Much better. 2) I think the "Named Return Value Optimization" code is a misunderstanding. The way I read the excerpts from the C++ standard quoted in the documentation (see http://www.boost.org/libs/utility/operators.htm#symmetry) is as follows: The standard places some limits on when NAMED objects may be optimized away. From this follows implicitly that UNNAMED objects may always be optimized away. Or, to quote from Scott Meyers' "More Effective C++", page 109-110: "However, the fact remains that unnamed objects have historically been easier to eliminate than named objects, so when faced with a choice between a named object and a temporary object, you may be better off using the temporary. It should never cost you more than its named collegue, and, especially with older compilers, it may cost you less". In other words: some compilers may not have Named Return Value Optimization, but most of them have (Unnamed) Return Value Optimization, which means that temporary, unnamed objects are optimized away where possible. So, I think, a better way of writing e.g. operator+ is the good old-fashioned: template <class T> inline const T operator+(const T& lhs,const T& rhs) {return T(lhs) += rhs;}; 3) When using compilers that do not support operators in namespaces (#ifdef BOOST_NO_OPERATORS_IN_NAMESPACE), the operator templates are first placed in the global namespace, and then copied to the boost namespace. The consequence of this is that it is not possible to access the templates with a "using namespace boost;" declaration - trying to do so creates an ambiguity between the stuff in boost and the stuff in the global namespace. Also, of course, the global namespace is "polluted" with quite a lot of extra names. The solution to this problem is to declare all the templates inside a "pseudo-namespace" struct in the global namespace - this also makes it easier to import the templates into boost, as even the Borland compiler now recognizes a "using" declaration. I have uploaded a new version of "operators.hpp" with fixes for above-mentioned problems to the sandbox vault. It has been tested with "rational.hpp" on the Borland 5.5 compiler and the Microsoft version 13.10.3077 compiler (the one that comes with the free Visual Toolkit 2003, and also (I think) with Visual C++ 7.1). I hope that some of you have time to test my new version with other programs and compilers. --- Søren

5 20

char[] support in Boost.Range
by Pavol Droba 17 May '05

17 May '05

Hi Boosters, There was a discussion about char[] support in the Boost.Range library. The issue seems important and I'd like to express my ideas about a possible solution. First lets sumarize problems and goals. The problems: char[] and possibly any other type that can be used as a c-string (this includes wchar_t, but also int, long and etc when used as a unicode code-point) might represent two different things: 1.) c-string literal 2.) arbitrary c-array Both views differ in lenght calculation, which is totaly incompatible and what's worse, it can lead to casual access violation when used improperly. An example: char str[] = "Hello"; // typeof(str) is char[6], str=={'h','e','l',l','o',0} In the c-string view, str have 5 letters and ends at the 'o'. So the range should be <'H','o') In c-array view str is 6 elements long and ends with '\0' The range is <'H','\0') From the user perspective, both views are equaly important, however according to the usage scenarion, one might be preferable over the other one. Important aspect to keep in mind is this strict relativnes. For example for string algorithms c-string literal is obvious default, while for a data processing library the second choice is better. Current implementation is not ideal. First of all, there is a difference between char,wchar_t[] and the rest of the types. This brings some confusion. Secondly, it is not possible to use char[] as an ordinary array. The goals: From the problem analysis above, following goals can be implied 1. we need to support both views equaly 2. a user must be always able to explicitly specify what type of view he requires 3. it should be possible for a library writer to select default view for his library. However point (2) must hold, so the user must be able to override this default. 4. Support must be present in the Boost.Range library. It is not feasible to ask library writer to provide specific workarounds/hacks. It would simply break the idea of Boost.Range library as a unified interface to range-like data structures. The solution: I propose to have two free-standing functions as_string() and as_array() (naming is not important now). Both should have the same generic signature: template<typename RangeT> boost::sub_range<RangeT> as_string(RangeT& aRange); template<typename RangeT> boost::sub_range<RangeT> as_array(RangeT& aRange); By default, the functions only copy the input range to the target. However for the types like char[], the result will differ. For as_string() will create a sub_range delimiting string literal (using char_type<char>::length for instance), while as_array() will use compile-time boundaries. In addition we might consider to open this interface for user-defined type, even if I'm not sure how it can be used. Please note, that once any of these manipulators is applied to a range following application will have no effect. Lets see how this faicility can be used: A library writer can set the default by writting algorithm like this: template<typename RangeT> ... AnAlgorithm(const RangeT& aRange) { boost::sub_range<RangeT> StrRange=as_string(aRange); // Do something with StrRange } If a user calls AnAlgorithm directly: char str[]="hello"; AnAlgorithm(str); str will be converted to a range, delimiting a string_literal. However he can alse use as_array(): char str[]={'h', 'e', 'l', 'l', 'o'}; AnAlgorithm(as_array(str)); This time no conversion will take place, since as_array() returns sub_range. Note, that for the AnAlgorithm it does not matter what default is used in the Range library. Open questions: - I have intentionaly not included a proposal for the default view that the Range library should provide. Goal of this solution is to provide a way, that is not dependant on this. I'd like to leave it for the discussion. Right now it seems, that most of the people that entered discussion prefer c-array view. I would prefer c-string view, but I'm probably biased by the fact that I'm the author of StringAlgo library. - There is a space for possible extentions to the basic proposal. For instance, as_string() migh have the second parameter that will identify a terminator. - String literal lenght can be calculated in two ways. Either by using strlenght() (or alike), or using compile-time size (N) decreased by 1 (N-1). Later approach is faster and allows to specify literals like this: char str[]="hello\0bye"; But it is different from char* handling and therefor it might be confusing. Best Regards, Pavol

6 15

[preprocessor] What syntax to present to the user
by Loïc Joly 17 May '05

17 May '05

Hello everybody, I'm trying to use the boost preprocessor library to allow the user to define "rich" enums, for instance enums that cannot be converted to int, whose values can be displayed in human readable form on a stream... I think I have to use macro to ease the writing of such enums, and I decided it was a good occasion to learn boost::preprocessor. My first impression : Wow ! You guys really use magic when programming ! Now, I have to decide what will be the interfaces for such rich enums. My (unreachable) goal would be something like that : RichEnum Type{Val1, Val2, Val3}; A little bit more reasonnable (but still unacheivable, I believe) goal would be : RICH_ENUM(Type, Val1, Val2, Val3); I think I can come up with several possible writing : 1/ RICH_ENUM(Type, (Val1)(Val2)(Val3)); 2/ RICH_ENUM(Type, 3, (Val1,Val2,Val3)); 3/ #define NAME Type #define VALUES (Val1)(Val2)(Val3) #include "RichEnum.h" #undef NAME #undef VALUES 4/ same as 3/, but with tuple syntax for VALUES With 1/ and 2/, all the class declaration is on the same line, which could decrease debugability. With 3/ and 4/, I can write it one several lines. And now, the questions : Which writing do you think would be best ? Why ? Are there other possibilities I overlooked ? Is is possible to have a syntax like 1/ and 2/ with good debugability ? Regards, -- Loïc

2 3

Re: [boost] Re: char[] support in Boost.Range
by brangdon＠cix.compulink.co.uk 17 May '05

17 May '05

In-Reply-To: <20050516205339.GW11789(a)lenin.felcer.sk> droba(a)topmail.sk (Pavol Droba) wrote (abridged): > In addition I would suggest to remove direct support for pointer types > like char* from the range library and provide it only via as_string() > construct to definitely remove any kind of confusion. Sounds like a good idea. Are we going to generalise it to allow any (compile-time constant) terminator? If so, is as_string() the best name? -- Dave Harris, Nottingham, UK.

3 2