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

newbie here. can't get anywhere with the regex search example
by suzanne 16 Oct '02

16 Oct '02

hi all. i'm brand new with this and just trying to figure everything out. i build the regex search example using VC++ 5, but i can't seem to make it 'go'. in debug mode, my argv (the name of a .cpp file) is blank! argc is incremented properly, so it's seeing something. but no value at all for the argv i'm feeding it - just a good old "". i've got to take this thing apart & learn it so i can implement it in a tool i'm building - can anyone help me get started? i want to step through the various examples to learn it. thanks, suzanne

1 0

RE: boost vs. The Lawyers (non-technical)
by Brian Neal 16 Oct '02

16 Oct '02

Thanks for the input so far. I too would like to call for some blanket license that all boost developers agree to (if possible). It looks like I'll be contacting developers individually and trying to get them to sign something for us. Not fun for either side I guess. Thanks, Brian Neal

3 2

[random] Known problems compiling random lib with Dinkumware STL?
by Chris Russell 16 Oct '02

16 Oct '02

I'm using the Intel 6.0 compiler under MS Visual Studio 6.0 SP6 and just attempted to plug the Dinkumware STL distribution into the mix. I ran into a slew of compile-time errors in the random library and am wondering if anyone has seen this before I ride into battle. Thanks - Chris

3 4

RE: [Boost-Users] Re: Type traits direct compiler support
by Beman Dawes 15 Oct '02

15 Oct '02

At 11:11 AM 10/15/2002, scleary(a)jerviswebb.com wrote: >> It is the vagueness of the term "compiler support", which you did not >> alleviate in your answer, which I am trying to clarify. > >"Compiler support" means "anything the compiler can give us so that we can >implement that class correctly". > >It could be a specially-recognized preprocessor define, a quasi-class >(e.g., >SGI's type traits), a pragma, a keyword, or anything else that the compiler >provides. Yes. "Compiler support" can be seen as a courtesy by library experts, so they aren't trying to tell core language experts exactly how to do something. --Beman

2 1

RE: [Boost-Users] Re: Type traits direct compiler support
by Mark Storer 15 Oct '02

15 Oct '02

What exactly can't you do with existing techniques? I was Most Impressed by Modern C++ Design, and I don't recall any limits stated on what was possible... the whole concept is relatively new to me --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard;

1 0

RE: [Boost-Users] Re: Running the Boost_1_29_0 regression tests
by Beman Dawes 15 Oct '02

15 Oct '02

At 12:02 PM 10/15/2002, Arjun Bijanki wrote: >"David Abrahams" writes: > >> "Arjun Bijanki" <arjunb(a)microsoft.com> writes: > >> > Hi, I'm having trouble running the Boost_1_29_0 regression tests. A >lot >> > >> >> Arjun, >> >> What are you doing to compile/link the tests? >> The supported method uses bjam. Have you tried that? >> If you use the -d+2 option you can look at the command-lines used and >> replicate them in whatever environment you like. >> >> -Dave > >Thanks. Previously, I was using /status/regression.cpp to generate the >status table; I'll try using bjam instead. We probably should have removed regression.cpp from the 1.29.0 release. The thought occurred to me, but that was before we decided to include all the new regression test components in the current CVS main trunk. Now that the main trunk has everything needed for the new tests, there is no reason to keep regression.cpp around. I'll remove it. --Beman

1 0

RE: [Boost-Users] Re: Running the Boost_1_29_0 regression tests
by Arjun Bijanki 15 Oct '02

15 Oct '02

"David Abrahams" writes: > "Arjun Bijanki" <arjunb(a)microsoft.com> writes: > > Hi, I'm having trouble running the Boost_1_29_0 regression tests. A lot > > > > Arjun, > > What are you doing to compile/link the tests? > The supported method uses bjam. Have you tried that? > If you use the -d+2 option you can look at the command-lines used and > replicate them in whatever environment you like. > > -Dave Thanks. Previously, I was using /status/regression.cpp to generate the status table; I'll try using bjam instead. Arjun

1 0

RE: [Boost-Users] Re: Type traits direct compiler support
by scleary＠jerviswebb.com 15 Oct '02

15 Oct '02

> -----Original Message----- > From: Edward Diener [mailto:eddielee@tropicsoft.com] > > > > From: Edward Diener [mailto:eddielee@tropicsoft.com] > > > > > > What does it mean in the type_traits documentation that "direct compiler > > > support for that traits class is required" ? I do not see that terminology > > > explained anywhere and am lost as far as to what it refers. > > > > It means that there is no known way to implement that class (in a > > Standard-compliant, portable manner). > > > > The type traits library is in a rather uncomfortable position, since it is > > essentially trying to add reflection to the C++ language after the fact. > > > > As currently implemented, the type traits library bends over backwards to > > try to provide as much as possible to as many different compilers as > > possible. But the simple fact is that it should not really be a library, > > but a part of the supplied language. > > > > Some type traits classes technically require compiler support. However, > > those classes will all try to take their "best guess" at the correct answer > > -- sometimes defaulting to a "safe" default if they can't figure out the > > correct answer. > > What sort of compiler support is being talked of here, since you mention > that it can't be done in a standard-compliant manner ? Does this mean > looking at preprocessor defines to determine the correct results, or what ? > It is the vagueness of the term "compiler support", which you did not > alleviate in your answer, which I am trying to clarify. "Compiler support" means "anything the compiler can give us so that we can implement that class correctly". It could be a specially-recognized preprocessor define, a quasi-class (e.g., SGI's type traits), a pragma, a keyword, or anything else that the compiler provides. -Steve

1 0

Returning a tokenizer by value
by Brian_X7 15 Oct '02

15 Oct '02

Is there a problem with returning a tokenizer from a function? Here's what I've got: typedef boost::tokenizer< boost::char_separator<char> > tokenizer; tokenizer getTokens( istream& is ) { boost::char_separator<char> sep(",","", boost::keep_empty_tokens); std::string str; getline(is,str,'\n'); tokenizer toks( str, sep ); return toks; } .. tokenizer tokens = getTokens(input); tokenizer::iterator it = tokens.begin(); (*it) now contains garbage, interesting enough, iterating through the rest of the container works. when I move the processing of getTokens into the main code body the first token (*it) is then correct. Am I missing something fundamental here?

1 0

RE: [Boost-Users] Type traits direct compiler support
by scleary＠jerviswebb.com 15 Oct '02

15 Oct '02

> -----Original Message----- > From: Edward Diener [mailto:eddielee@tropicsoft.com] > > What does it mean in the type_traits documentation that "direct compiler > support for that traits class is required" ? I do not see that terminology > explained anywhere and am lost as far as to what it refers. It means that there is no known way to implement that class (in a Standard-compliant, portable manner). The type traits library is in a rather uncomfortable position, since it is essentially trying to add reflection to the C++ language after the fact. As currently implemented, the type traits library bends over backwards to try to provide as much as possible to as many different compilers as possible. But the simple fact is that it should not really be a library, but a part of the supplied language. Some type traits classes technically require compiler support. However, those classes will all try to take their "best guess" at the correct answer -- sometimes defaulting to a "safe" default if they can't figure out the correct answer. -Steve

2 2