August 2004 - Boost - lists.boost.org

[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 28 Aug '04

28 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

typeof for vintage compilers
by Peder Holt 27 Aug '04

27 Aug '04

Hi. I started working on implementing remove_bounds for the VC 6.5 compiler, and found that the source had all the similarities of Arkadiys typeof implementation, so I have implemented typeof for compilers not supporting partial specialization. I took many ideas from Arkadiys implementation, but I had to rewrite the encoding part from scratch. The library (apart from being incomplete with respect to function types etc) has the following key elements in place: encoding/decoding of: -fundamental types -template types -modifiers (*&const volatile []) The library has a few improvements that could perhaps be implemented in Arkadiys typeof implementation as well: The max depth of an expression increased from the mpl limit of 60 to the preprocessor limit of 256 template expressions containing integral values are allowed The template: template<typename T,unsigned long V> struct X {}; can be exposed to typeof in the following way: BOOST_TYPEOF_DEFINE_TEMPLATE(X,2,(typename,unsigned long)) (VC 7.1 had some problems preprocessing the code needed to make this work.) The source is available at: http://groups.yahoo.com/group/boost/files/typeof_vintage.zip I have compiled the library for VC 6.5 and 7.0. They both fail when the depth of an expression gets too large, with the error message: fatal error C1045: compiler limit : linkage specifications nested too deeply. -- Peder Holt

2 3

Re: RE: [boost] [minmax] patch to solve issue in GCC 2.95
by JOAQUIN LOPEZ MU?Z 27 Aug '04

27 Aug '04

----- Mensaje original ----- De: "Rozental, Gennadiy" <gennadiy.rozental(a)thomson.com> Fecha: Viernes, Agosto 27, 2004 6:47 pm Asunto: RE: [boost] [minmax] patch to solve issue in GCC 2.95 > Which file? My bad :) The file is libs/algorithm/minmax/test/minmax_test.cpp > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > > [boost-bounces(a)lists.boost.org] On Behalf Of joaquin(a)tid.es > > Sent: Friday, August 27, 2004 4:14 AM > > To: boost(a)lists.boost.org > > Subject: [boost] [minmax] patch to solve issue in GCC 2.95 > > > > > > GCC 2.95 has problems supporting using declarations inside > > functions, as > > > > indicated by BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL. > > > > This affects a minmax test in this compiler. The following > > trivial patch moves a using directive to global scope and > > solves the issue. This would make it all green for minmax > > regression tests under every platform considered. > > > > OK to commit? > > > > Joaquín M López Muñoz > > Telefónica, Investigación y Desarrollo > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] [minmax] patch to solve issue in GCC 2.95
by Rozental, Gennadiy 27 Aug '04

27 Aug '04

Which file? > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of joaquin(a)tid.es > Sent: Friday, August 27, 2004 4:14 AM > To: boost(a)lists.boost.org > Subject: [boost] [minmax] patch to solve issue in GCC 2.95 > > > GCC 2.95 has problems supporting using declarations inside > functions, as > > indicated by BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL. > > This affects a minmax test in this compiler. The following > trivial patch moves a using directive to global scope and > solves the issue. This would make it all green for minmax > regression tests under every platform considered. > > OK to commit? > > Joaquín M López Muñoz > Telefónica, Investigación y Desarrollo >

1 0