- Boost - lists.boost.org

Triple change to Base-from-member
by Daryle Walker 28 Aug '04

28 Aug '04

I applied three changes for this library to CVS. (Three separate commits were done.) 1. Implemented a scheme to use the Pre-processor library to generate the various constructor templates. This allows the maximum number of constructors to be set at compile-time. It's a macro constant, so other headers can copy the exact number of constructors too. Changed "base_from_member.hpp" and "base_from_member.html". Shouldn't cause any problems unless your header can't work with the Pre-processor library. 2. Moved the default of the second template argument of base_from_member to the primary header. This removes the last component of "utility_fwd.hpp". Changed "base_from_member.hpp" and "base_from_member.html", and removed "utility_fwd.hpp". Shouldn't cause any problems unless your header directly #included "utility_fwd.hpp", which my check didn't pick up. 3. Forgot to update the copyright year list of "base_from_member.hpp" to add 2004. Changed that. Shouldn't cause any (additional) problems. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[type_traits] "member_function_pointer_traits" ?
by Tobias Schwinger 28 Aug '04

28 Aug '04

Dear Boosters, what is the reason for the absence of "member_function_pointer_traits" (or alike) in the type_traits library ? To be precise: is it a design decision or just something not yet implemented ? In the latter case I hereby volunteer for implementing it. I suggest an interface similar to the one of function_traits but with two additional constants for 'const' and 'volatile' qualification of the pointee method, because there is no member function type without the pointer thus making it impossible to use remove_pointer / is_[qualifier] or pass 'Class::member_function' (without the '&', that is) as an argument of parametrized type to a template function. Best regards, Tobias

5 7

RE: [boost] Re: [1.32 Plan] Stalled forever?
by Rozental, Gennadiy 28 Aug '04

28 Aug '04

> Gennadiy Rozental writes: > > I would like to second that. > > > > Two month ago I was told that I had to freeze any development yet > > another month ago. Now we still nowhere and I still couldn't move a > > finger. > > 1) Release or not, any major new development should happen on > the branch. I could do my own development anywhere, even keep files on my hard drive. How am I supposed to test it? > 2) At least please take care of the unmarked failures in > Boost.Test before > claiming that you've done your part for the release. Does it say anywhere that I am required to? All the failures either expected or too minor to jump to fixes now and disturb the release. I had enough unexpected headache with things I did decide to fix > > I understand that it may be caused by book preparation. But > should we > > necessarily need to use namely this release? > > Yes. We have to use a coherent set of sources that contains > the new version of the MPL, and this is what this release is > going to provide us with, in particular. We may've published this release month ago with MPL changes. And publish another one (may be patch release) month from now with new MPL. > > > > Let at least set a policy for open information: if for > whatever reason > > release needs to be postponed lets announce it and set a new date. > > There *was* announcement of the release delay. The new date is > going to be set as soon as MPL is in the main trunk. I don't believe "release postponed until further notice" is good enough. The same time new schedule needs to be proposed and agreed upon (or after discussion we may decide to go ahead with release on previously defined terms, ignoring issues causing release to postpone). Please, understand that I am not trying to find responsible. But I also don't find this uncertainty acceptable. Regards, Gennadiy.

3 2

[boost.thread] Thread local storage on Windows
by Roland 28 Aug '04

28 Aug '04

As everyone is currently busy preparing for the 1.32 release, I do not want to clutter up the list with discussion of new things too much. However, recently I posted some suggestions for improving the windows implementation of tls. Because noone yet had time to comment on it, (because there are lot of other things to be done) I decided to also post a reworked version to http://codeproject.com/useritems/tls.asp Anyone interested in my proposal, please refer to the above article, instead of going to the boost file section. I did this in the hope to get some feedback that could help to find out whether these improvements are worth considering to be implemented to the boost library as well. Regards, Roland

1 0

preprocessor question
by Arkadiy Vertleyb 28 Aug '04

28 Aug '04

Hi all, I am trying to find a way to implement something like a preprocessing-time map. As far as I understand, the task is trivial if "keys" contain only one token: #define FIND(x) BOOST_PP_CAT(FIND_, x) #define FIND_key1 val1 #define FIND_key2 val2 #define FIND_key3 val3 And then: FIND(key1) // evaluates to val1 FIND(key2) // evaluates to val2 FIND(key3) // evaluates to val3 However, this approach obviously brakes when keys contain more than one token, like "key 1" (or, to be closer to the real problem, "unsigned int"). So I am wonderring if there is any facility in the preprocessor (or in the Boost.Preprocessor) that would allow me to do this. Thanks in advance, Arkadiy

4 4

[boost.move] move_ptr
by Thorsten Ottosen 28 Aug '04

28 Aug '04

Hi, I just wanted to hear if anybody had already made a move_ptr I could use? br Thorsten

9 24

Re: MPL vector size limit
by Arkadiy Vertleyb 28 Aug '04

28 Aug '04

Sorry to repeat this question, but I think I am missing somehing here: Do I understand correctly that it's not possible in the current version of MPL to use mpl::vector of a size larger than 50? If this is not correct, what exactly do I have to do to use, for example, mpl::vector97<...>? If this _is_ correct, I would like to make a feature request for it to be increased, since the limit of 50 doesnt seem to be high enough (I am making this statement in conjunction with the need of my typeof emulation lib, but I am kind of surprized this question hasn't yet popped up in other contexts, or has it?). In particular, isn't it possible to just get it fully controlled by BOOST_MPL_LIMIT_VECTOR_SIZE without any limitations whatsoever? Thanks, Arkadiy

2 1

Suggestion for a new class TextTableFormat
by AviadR 28 Aug '04

28 Aug '04

Hi, I am (shamefully) a newbie. I want to suggest a tiny library I've written that allows you to create "tables" of textual strings. What I mean is supposed you want to output rows of data that look like this FIELD1 (tab) FIELD2 (tab) .... FIELD-N Because many times the actual data that is written to the fields are of different lengths, You might get your output like this Field1_data field2_data field3_data Another_field1_data another_field2_data another_field3_data ... Which is not very readble or conveniet. The library I am proposing fixes this dire situation by defining a format, which states for each field: 1. its 'width' or how many columns it takes 2. its length, how many characters can it hold altogether. Data is written to a buffer using a special class which relies on the Format information. * Lines within a field are broken down in order for the column invariant to be preserved. * if data written to a field is too long for the field, the output of the field ends with "..." to indicate that the data was truncated. * the classes uses NO dynamic memory whatsoever and are very fast. If this is somehow interesting to someone I can spend the time 'boostfying' it And maybe factor some of the features stated above into Strategy classes. So how about it? I am attaching the relevant code here. IT WILL NOT COMPILE because it currently relies on My IO library, my string classes etc. of course if it is deemed interesting I will change it to use boost's classes. Thanks AviadR mailto:aviadr@pob.huji.ac.il

1 0

patch to kill warnings on boost-cvs
by Rodolfo Schulz de Lima 27 Aug '04

27 Aug '04

Hi, here's a patch to shut up the gcc-3.4.1 compiler with all warnings enable (-Wextra -Wall). That'll be nice if this was put in the main package. My projects usually have -Werror and those ones below doesn't help. It's all about harmless unused function parameters. I must point that I didn't check other libraries, just the ones I usually use. Thanks, rod diff -ur boost/date_time/date_names_put.hpp /usr/include/boost-1_32/boost/date_time/date_names_put.hpp --- boost/date_time/date_names_put.hpp 2004-07-17 19:20:18.000000000 -0300 +++ /usr/include/boost-1_32/boost/date_time/date_names_put.hpp 2004-08-23 17:35:05.000000000 -0300 @@ -142,10 +142,10 @@ default: {} //quiet compilers that want all cases covered here (eg: gcc 3.1) } } - virtual void do_put_weekday_short(iter_type& oitr, weekday_enum wd) const + virtual void do_put_weekday_short(iter_type&, weekday_enum) const { } - virtual void do_put_weekday_long(iter_type& oitr, weekday_enum wd) const + virtual void do_put_weekday_long(iter_type&, weekday_enum) const { } virtual bool do_has_date_sep_chars() const diff -ur boost/date_time/gregorian/greg_month.hpp /usr/include/boost-1_32/boost/date_time/gregorian/greg_month.hpp --- boost/date_time/gregorian/greg_month.hpp 2004-07-18 15:36:16.000000000 -0300 +++ /usr/include/boost-1_32/boost/date_time/gregorian/greg_month.hpp 2004-08-23 16:29:25.000000000 -0300 @@ -78,20 +78,20 @@ /* parameterized as_*_string functions are intended to be called * from a template function: "... as_short_string(charT c='\0');" */ - const char* as_short_string(char c) const + const char* as_short_string(char) const { return as_short_string(); } - const char* as_long_string(char c) const + const char* as_long_string(char) const { return as_long_string(); } #ifndef BOOST_NO_STD_WSTRING - const wchar_t* as_short_string(wchar_t c) const + const wchar_t* as_short_string(wchar_t) const { return as_short_wstring(); } - const wchar_t* as_long_string(wchar_t c) const + const wchar_t* as_long_string(wchar_t) const { return as_long_wstring(); } diff -ur boost/token_functions.hpp /usr/include/boost-1_32/boost/token_functions.hpp --- boost/token_functions.hpp 2004-08-19 12:23:46.000000000 -0300 +++ /usr/include/boost-1_32/boost/token_functions.hpp 2004-08-23 16:34:48.000000000 -0300 @@ -212,7 +212,7 @@ } template<class Token, class Value> - static void plus_equal(Token &t, const Value &v) { + static void plus_equal(Token &, const Value &) { } @@ -220,7 +220,7 @@ // the clear. // template<class Token> - static void clear(Token &t) { + static void clear(Token &) { } };

5 5

zip iterator misbehaving
by Antonio Piccolboni 27 Aug '04

27 Aug '04

Hi everyone, I have the following problem. I need to apply the same permutation to two sequence collections. The following code for the single permutation works like a charm: random_shuffle(TGraphRowVectorIterator<Identifier>(theGraph.begin()), TGraphRowVectorIterator<Identifier>(theGraph.end())); (only, I haven't figured out how to random seed random_shuffle, but I guess this is a question for another forum) TGraphRowVectorIterator<Identifier> is a projection iterator. Unfortunately when I wrote it I didn't know about boost so I wrote it by hand and I hate that code now (attached at the end) but it seems to work ok in many contexts. Now to the simultaneous permutation of two: random_shuffle (boost::make_zip_iterator (boost::make_tuple (TGraphRowVectorIterator<long>(firstGraph.begin()), TGraphRowVectorIterator<long>(secondGraph.begin()) ) ), boost::make_zip_iterator (boost::make_tuple (TGraphRowVectorIterator<long>(firstGraph.end()), TGraphRowVectorIterator<long>(secondGraph.end()) ) ) ); (I think if this is going to work I will make it my favorite example of generic programming. Isn't it a thing of beauty? Can this be solved in C without duplicating and uglyfying the shuffle code?). This unfortunately doesn't return a permutation. The resulting vector has repetitions in it. I debugged the code all the way inside iter_swap and it looks like the side effects of the swap are propagated only to one of the arguments, to my astonishment because they have THE SAME TYPE. So if I screwed with the iterator definition, which is totally a possibility, it should simply not permute anything. I am not yet ready to claim there is a bug in zip_iterator, but this is very suspicios. Thanks for anyone's help Antonio ----Ugly iterator code, is there anythng wrong with the signatures? Thank God for the <iterator>!------- template<class Identifier> class TGraphRowVectorIterator : public iterator<random_access_iterator_tag, vector<double>, long> { typename TGraph<Identifier>::iterator rowIterator; public: TGraphRowVectorIterator<Identifier> (typename TGraph<Identifier>::iterator rowI) { rowIterator = rowI; } TGraphRowVectorIterator<Identifier> () { } vector <double> & operator *() const { return rowIterator->values; } vector <double> * operator ->() { return &(operator*()); } bool operator == (const TGraphRowVectorIterator<Identifier> & that) const { return rowIterator == that.rowIterator; } bool operator != (const TGraphRowVectorIterator<Identifier> & that) const { return !(*this == that); } bool operator < (const TGraphRowVectorIterator<Identifier> & that) const { return rowIterator < that.rowIterator; } bool operator >= (const TGraphRowVectorIterator<Identifier> & that) const { return !(*this < that); } bool operator >(const TGraphRowVectorIterator<Identifier> & that) const { return (*this >= that) && (*this != that); } bool operator <= (const TGraphRowVectorIterator<Identifier> & that) const { return !(*this > that); } TGraphRowVectorIterator<Identifier> operator ++ (){ rowIterator ++; return *this; } TGraphRowVectorIterator<Identifier> operator -- (){ rowIterator --; return *this; } TGraphRowVectorIterator<Identifier> operator ++ (int){ TGraphRowVectorIterator<Identifier> tmp(*this); rowIterator ++; return tmp; } TGraphRowVectorIterator<Identifier> operator -- (int){ TGraphRowVectorIterator<Identifier> tmp(*this); rowIterator --; return tmp; } TGraphRowVectorIterator<Identifier> operator + (long drow) { return TGraphRowVectorIterator<Identifier> (rowIterator + drow); } TGraphRowVectorIterator<Identifier> operator += (long drow) { rowIterator += drow; return *this; } TGraphRowVectorIterator<Identifier> operator - (long drow) const{ return (*this + (-drow)); } long operator - (TGraphRowVectorIterator<Identifier> that) const { return rowIterator - that.rowIterator; } Identifier position() { return rowIterator->position(); } }; -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

1 0