- Boost-users - lists.preview.boost.org

Tokenizer
by macrodisk 05 Apr '02

05 Apr '02

I have a question about boost::tokenizer. I have a Semicolon separated string, something like: "All;;;;;;Bus;;;;;;BRT;;;;;;All" When I use boost tokenizer, I get "All", "Bus", "BRT",and "All". I want to get the the empty string between the semicolons, seems like the tokenizer takes consecutive semicolons as a single token; is there any way I can change this to represent different strings? boost::char_separator<char> sep(";"); typedef boost::tokenizer<boost::char_separator<char> > tokenizer; tokenizer Id_tokens(IdString, sep); for(tokenizer::iterator Id_tok_iter= Id_tokens.begin(), End_Id_tok_iter = Id_tokens.end(); Id_tok_Iter != End_Id_tok_iter) { //Do Something } Another question, is there some way to assign a different string once a tokenizer is constructed? tokenizer Id_tokens(IdString,sep); Id_tokens.assign(NewString,sep); //Is this possible with the boost tokenizer? I couldn't find any examples to this end in the places I searched. Thank you, Vijay

3 4

Sun WorkShop assertion failed when compiling with -g
by the_d.geo 05 Apr '02

05 Apr '02

FYI, the following piece of code is an excerpt from boost/type_traits/composite_traits.hpp (boost version 1_27_0). Using sun's CC (Sun WorkShop 6 update 2 C++ 5.3. Patch 111685-05 2002/02/03) and debug on (-g), it fails compilation with the following message >> Assertion: (../links/dbg_cstabs.cc, line 611) while processing test.cpp at line 0. I'd assume that it is a bug in the compiler since it compiles fine without the -g flag. --- start code #include <boost/type_traits/ice.hpp> template <typename T> struct is_pointer { BOOST_STATIC_CONSTANT(bool, value = (::boost::type_traits::ice_and< ::boost::detail::is_pointer_helper<T>::value, ::boost::type_traits::ice_not< ::boost::is_member_pointer<T>::value >::value >::value)); }; --- end code

1 0

preprocessor bug
by jkharris01 04 Apr '02

04 Apr '02

Using MSVC6, SP5: BOOST_PP_LIST_AT() doesn't work in a transform function, but BOOST_PP_LIST_FIRST() and BOOST_PP_LIST_REST() work fine I expected the following code to expand to: a , b but instead it expands to BOOST_PP_TUPLE3_ELEM0 BOOST_PP_TUPLE2_ELEM0 BOOST_PP_WHILE0(BOOST_PP_LIST_REST_N_C,BOOST_PP_LIST_REST_N_F,((a,(7,(_,_,0),1),1),0)) , BOOST_PP_TUPLE3_ELEM0 BOOST_PP_TUPLE2_ELEM0 BOOST_PP_WHILE0(BOOST_PP_LIST_REST_N_C,BOOST_PP_LIST_REST_N_F,((b,(8,(_,_,0),1),1),0)) If I change the definition of F to use BOOST_PP_FIRST(X), it works ************* Example code*************** #define F(a,b,X) BOOST_PP_LIST_AT(X,0) #define LST BOOST_PP_TUPLE_TO_LIST(2,( \ BOOST_PP_TUPLE_TO_LIST(2,(a,7)), \ BOOST_PP_TUPLE_TO_LIST(2,(b,8)))) BOOST_PP_LIST_ENUM(BOOST_PP_LIST_TRANSFORM(F,dummy,LST))

1 0

Re: Compiling CRC
by Daryle Walker 04 Apr '02

04 Apr '02

on 4/3/02 3:54 PM, David Brownell at david_brownell(a)hotmail.com wrote: > Daryle, thanks for your response. The code does work on VC6. Here is > the crc.hpp related errors I get when I compile with VC7. [TRUNCATE] I think the first error means that VC7 is choking on the forward declaration of crc_optimal. The other errors cascade from that one. What does "BOOST_CRC_PARM_TYPE" expand to on VC7? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com

2 1

preprocessor lists question
by jkharris01 04 Apr '02

04 Apr '02

I want to have some way to automatically put the right number of close parentheses on a list (using boost/preprocessor.hpp). For instance, given this list: #define _THE_LIST \ BOOST_PP_LIST_CONS(red, \ BOOST_PP_LIST_CONS(orange, \ BOOST_PP_LIST_CONS(yellow, \ BOOST_PP_LIST_CONS(green, \ BOOST_PP_LIST_CONS(blue, \ BOOST_PP_LIST_CONS(violet, \ BOOST_PP_LIST_CONS(gray, \ BOOST_PP_LIST_CONS(white, \ BOOST_PP_LIST_NIL )))))))) is there a way to automatically generate the eight close parentheses?

1 0

Re: Compiling CRC
by Daryle Walker 03 Apr '02

03 Apr '02

on 3/29/02 11:05 AM, David Brownell at david_brownell(a)hotmail.com wrote: > I have the following code that doesn't compile using VC 7.0. I am > getting many errors in crc.hpp. Am I missing something simple here? I > have just glanced at the manual, so please be gentle with the RTFM > responses :) > > TIA, > David Brownell > > #include<iostream> > #include "boost\crc.hpp" > > int main(void) > { > const unsigned char DATA[] = { 1, 2, 3, 4, 5 }; > > boost::crc_32_type crc; > > crc.reset(); > crc.process_bytes(DATA, sizeof(DATA) / sizeof(*DATA)); > > std::cout << crc.checksum() << std::endl; > return(true); > } I ran it just fine (and got "1191942644" printed). There may be some VC++ 7 quirks. Did you try it with VC++ 6? What error messages did you get? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com

2 1

Building graphviz under VC6
by Wolf, Frank 03 Apr '02

03 Apr '02

Has anyone succesfully build the graphviz libs under VC6? I tried to do so, but ran into fatal error LNK1179 I really would be grateful for any help Thanks. Frank

2 1

Non-scoped mutex's with Boost.Threads
by Dale Peakall 02 Apr '02

02 Apr '02

I believe it is possible to use Boost.Threads mutexes without the need to use a scoped_lock style guard. I vaguely recall it being something to do with a mutex_traits class or something (but I can't find any documentation). Can anyone help me out. Thanks. - Dale.

2 1

suggestion: harness destructor in scoped_ptr<>::reset
by jlehrer 02 Apr '02

02 Apr '02

Before I propose this to main boost mailing list, I wanted to see what others thought of this idea. I propose changing the following method on scoped_ptr<>: void reset(T* p=0) {if(ptr!=p) {checked_delete(ptr); ptr=p;}} to void reset(T* p=0) {if(ptr!=p) {scoped_ptr<T>(p).swap(*this);}} void swap(scoped_ptr<T>& other) {std::swap(ptr,other.ptr);} Of course, we would then have global methods for std::swap, as there are for the other smart pointers, to map to this method. Finally, the same change should be made to scoped_array<>. shared_ptr<> and shared_array<> already have these semantics. The idea is to harness the destructor of the scoped_ptr in order to delete the pointer, rather than calling checked_delete in two places. This has a few advantages over the old code: 1- destruction is handled in one place, the destructor. This seems natural, and gives developers one place to look to see what happens when a pointer is deleted 2- I have had occasion to specialize the destructor of the scoped_ptr<> class to do something other than delete. In that case, I needed to specialize the destructor AND the reset method. With this change, one would only need to specialize the destructor and reset would harness that specialization as well. Comments?

2 1

Fw: Boost.Threads thread_specific_ptr and more
by Philip Ashmore 02 Apr '02

02 Apr '02

Oops! I didn't know I had to join the group! Regards, Philip Ashmore ----- Original Message ----- From: "Philip Ashmore" <philip_ashmore(a)hotmail.com> To: "William Kempf" <williamkempf(a)hotmail.com> Cc: <Boost-Users(a)yahoogroups.com> Sent: Wednesday, March 20, 2002 12:29 PM Subject: Re: Boost.Threads thread_specific_ptr and more > Hi there. > > Rather than respond to your points directly, I've written a document > outlining my ideas on how static data could be managed more clearly. This > obviously relates to thread_specific_ptr as instances are global, hence > static, but is quite general and therefore hopefully more useful. > > Regards, > Philip Ashmore. > ----- Original Message ----- > From: "William Kempf" <williamkempf(a)hotmail.com> > To: <philip_ashmore(a)hotmail.com> > Sent: Friday, March 15, 2002 3:13 PM > Subject: Re: Boost.Threads thread_specific_ptr and more > > > > >From: "Philip Ashmore" <philip_ashmore(a)hotmail.com> > > >To: <williamkempf(a)hotmail.com> > > >Subject: Boost.Threads thread_specific_ptr and more > > >Date: Fri, 15 Mar 2002 14:37:39 -0000 > > > > > >Hi there. > > > > > >first of all, I'm assuming that it's appropriate to contact you directly > regarding some queries I have regarding the Boost.Threads > thread_specific_ptr<T>. > > > > Yes, though if you'd send it to the Boost Users list on Yahoo Groups > (Boost-Users(a)yahoogroups.com) instead others could benefit from the answer > as well. > > > > >As it happens I developed something similar before I became aware of > Boost.Threads thread_specific_ptr<T>, but with the following extra features > you might consider discussing or adding. > > > > > >1. Automatic construction of new instances of T as needed when > dereferenced. > > > > I considered this and rejected it, mostly because this behavior may be > surprising to users. Another issue is that this would require T to be > default constructable, which will limit the usefulness at least somewhat. > > > > >2. Assignment to thread_specific_ptr<T> of a local variable of type T. > This is basically already there with reset() but an explicit template class > could handle connection and disconnection, coping with exceptions. > > > > Could you elaborate? I'm not sure I understand why you think an > assignment operator would be better then reset(). > > > > >3. An optional Structor class template argument. Here the Structor would > know how to create and destroy instances of T, useful when T can be used in > different contexts. > > > > This sounds like an Allocator, and if it wasn't a standard Allocator then > it could be used to eliminate one of the problems I referred to in (1), but > beyond this I don't see any benefit. > > > > >4. Automatic cleanup of instances of T when the thread_specific_ptr<T> > goes out of scope. These would be useful when you aren't in control of the > thread creation or destruction. > > > > To be portable, thread_specific_ptr<> must be used only to instantiate > global variables (or the equivalent static variants). So, this one can't be > done (or more specifically adds 0 benefit). > > > > > This relates to static instance management. As you may know, some > compilers (or maybe it's C++ itself) have problems if you have static > instances of classes that have non-trivial static data members. The idiom of > clients and managers is one solution - manager lifetimes enclose client > lifetimes. I've implemented this and it works. > > > > I'm not sure that I'm aware of the problem you're alluding to. Can you > elaborate? > > > > >A more general idiom is a dependency tree, where wrapper objects declare > their dependency explicitly and a functor tree is created that is > independent of the order of static construction (a map would work here). > This tree is traversed during start-up and shutdown (using a scoping object) > to ensure correct instantiation and destruction. > > > > Are you referring to issues with the order of construction/destruction for > global data? If you are, there is no universal solution to this problem and > I'm not about to try and address it. > > > > >It takes over work that the compiler should do correctly but doesn't (at > least not on Visual C++ 6.0 sp5). > > >This would effectively solve all > static-object-dependency-across-libraries issues in a portable way. > > >Maybe this merits a file of its own in Boost.Utility. What do you think? > > > > I think I need more explanation and possibly code examples. > > > > Bill Kempf > > williamkempf(a)hotmail.com > > > > > [Non-text portions of this message have been removed]

2 2