- Boost - lists.boost.org

RE: [boost] Re: Assignment library: review
by Glen Knowles 11 Apr '04

11 Apr '04

From: Keith Burton [mailto:kb@xtramax.co.uk] >I trust that you are aware of the following quoted, from >MSDN for all Microsoft C++ compilers <snip> >See Knowledge Base article Q242192 for more information. The article says that it applies to MSVC 6, not "all". Glen Knowles Centor Software Corporation

1 0

test lib bugs
by David Abrahams 11 Apr '04

11 Apr '04

I am seeing these errors when compiling with como-win32: "c:\boost\libs/test/src/execution_monitor.cpp", line 42: error #735: using-declaration of function "strlen(const char *) C" conflicts with function "std::strlen(const char *)" (declared at line 30 of "c:/tools/como433\libcomo\cnames/cstring") namespace std { using ::strlen; using ::strncat; } ^ "c:/tools/como433\libcomo\cnames/cstring", line 30: error #247: function "std::strlen" has already been defined extern "C++" inline size_t strlen(const char *arg) { return ::strlen(arg); } ^ -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Placeholder in boost.lambda/boost.function
by Stefan Slapeta 10 Apr '04

10 Apr '04

Sorry it this has been asked yet, I didn't find anything. Currently placeholders are ambigous if you include boost/bind.hpp and boost/lambda/bind.hpp in the same translation unit. The compiler finds the _1 of the function library and the one of the lambda library. Could this be resolved (without specifying an explicit namespace for the placeholder?) Stefan

1 0

Generic non-derivable base class
by Matthew Vogt 10 Apr '04

10 Apr '04

Is there any interest in creating a generic base class to encapsulate the non-derivable class idiom, as recently discussed wrt Reece Dunn's error check component? Since the the idiom is on a similar complexity level to that of noncopyable, I feel it would be appropriate to encapsulate it, if a general solution is possible. The following simple base class implements the mechanism as dicussed on Stroustrup's FAQ page, and encapsulates the virtual inheritance so that the class can be non-virtually inherited, removing the most obvious chance of implementation error. Will this code work on multiple platforms? I have only tested on gcc 3.2... //------------------------------- namespace boost { template <typename T> struct nonderivable; namespace detail { template <typename T> class nonderivable_base { private: template <typename X> struct identity { typedef X type; }; friend typename identity<T>::type; friend class nonderivable<T>; nonderivable_base() {} nonderivable_base(const nonderivable_base&) {} }; } //namespace detail template <typename T> struct nonderivable : public virtual detail::nonderivable_base<T> { }; } // namespace boost // ------------------------ struct A : public boost::nonderivable<A> {}; struct B : public A {}; A a; // Ok B b; // Error - cannot be instantiated // ------------------------ Matt

3 4

RE: [boost] Re: Formal Review: Assignment Library
by Powell, Gary 10 Apr '04

10 Apr '04

Finally I have some more time to look at this library. My first complaint is that by default it links in the world. I think for something like this, we need to not link in every standard container and graph and tuple etc include file. I'm glad that the library handles it but the dependency graph is ridiculous. And yes I know that I can link in just the necessary sub include files, but my complaint is that it will trap the unwary user by default. I think if the basic file boost/assign.hpp only linked the minimum necessary I'd be much happier. Of course who is to say what is the minimum? So how about changing the name to boost/assign_to_anything.hpp (blech!) or something similar with the name being more of a warning. The file boost/assign/stl.hpp also unnecessarily includes every std container. At a minimum the use of BOOST_NO_FUNCTION_TEMPLATE_ORDERING shows that only <queue>, and <stack> are required. The define should also be around the unnecessary include files. There also appear to be two useless files in the distribution, make.hpp and template.hpp that should be removed. (minor cleanup) I did a cursory look at the docs, and will try and get back to them. I ran the tests with gcc 3.2 and they all compiled fine and ran fine. I vote for acceptance with the qualification that the stl.hpp header be reorganized into sub headers. I may come back with more stuff about the docs but it won't be to change my vote. (Dang standard for not splitting out <vector_fwd> et.al. ) Yours, -Gary- powellg(a)amazon.com

2 1

spirit docs (was regex ease-of-use)
by Dave Gomboc 10 Apr '04

10 Apr '04

> Subject: Re: [boost] Re: Regex ease-of-use ideas > > Hmmph. I have to say that while I love what Spirit is > doing, actually > > using it with confidence requires way too much use of the source, > > Luke. Reference docs are annoying to write, but neccessary. > > Point well taken. Formal documentation is high on the TODO list. It'd also be great to have documentation on what would need to be changed to Spirit to enable full backtracking and cut points. Dave

3 2

Spirit Documentation
by Stephan T. Lavavej 10 Apr '04

10 Apr '04

The background on the Spirit doc pages makes text difficult to read on the right hand side. It would be better if the background were changed to be smooth, rather than interrupted by horizontal lines. Example of the mischief the current background causes: http://stl.nuwen.net/spirit.png Stephan T. Lavavej http://nuwen.net

4 3

Errors compiling a boost-based app using VC7.1
by Steve Dussinger 09 Apr '04

09 Apr '04

HELP!!!! I'm trying to compile an application which contains boost threads and I can't seem to get it to work. Whenever I try to compile, I get the following two types of messages from the compiler: warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' or warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::thread_group' Obviously, these have something to do with the mixing of DLL and non-DLL classes, but since Windows is not my preferred OS I have no clue about what to do to get this to compile. I used boost (v 1.28) on a prior project (using VC6) with no problems, but I'm just stumped here.... Can anyone give me a clue? Thanx, Steve

2 2

RE: [boost] regex lib: regex_grep w/ match_posix broken?
by Benzinger, Ralph 09 Apr '04

09 Apr '04

Actually, now that I look at the code, should it simply be < if(((m_match_flags & match_not_null) == 0) && (m_presult->length() == 0)) --- > if(((m_match_flags & match_not_null) == 0) && (m_result.length() == 0)) just below the original patch? That _seems_ to work. Ralph

2 2

RE: [boost] regex lib: non-greedy repeats w/ match_posix
by Benzinger, Ralph 09 Apr '04

09 Apr '04

> > I noticed that the newest regex version no longer supports > > non-greedy repeats "+?" in match_posix mode. What was the > > rationale for this? > > It is deliberate, non-greedy repeats don't really fit into the POSIX > matching philosophy, where repeats are neither greedy not > non-greedy, rather it's parenthesis that determine what the best match > is. John, I'm not sure I understand what you're saying. A regular expression either (completely) matches a given text, or it doesn't; if we ignore parentheses for a moment, then there's no room for different "matching strategies" (like, say, POSIX or not). When searching for (i.e., grepping) a regular expression, POSIX states "left-most longest", so it shouldn't be ambiguous to determine the left-most longest match among all possible matches (with parenthesis indices breaking ties), even if the RE contains a non-greedy repeat. Do you have a specific example at hand why you think non-greedy repeats are inappropriate for POSIX-style greps? Personally, I find it very convenient to write REs like "<b>.*?</b>", especially in POSIX mode. Ralph

2 1