April 2004 - Boost - lists.boost.org

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

Some FC++ comments
by Vladimir Prus 09 Apr '04

09 Apr '04

I've just made a first attempt to read through FC++ docs, and have some comments. I haven't read all of the posts in the recent review, so apologies if some of the issues are already known. The docs I used are those at http://www.cc.gatech.edu/~yannis/fc++/boostpaper/fcpp.html First, a motivating example: I wanted to find a vertex in BGL graph which has in degree of zero. This should be something as simple as (using lambda): find(vertices(g).first, vertices(g).end(), bind(in_degree, _1, g) == 0); but in_degree happens to have several overloads, all of which are templates, so just 'in_degree' won't work, and selecting the right variant via cast has it's own problems. So, I though FC++ would allow me to declare 'in_degree_f' object that will work for all kinds of graph. The documentation starts with: FC++ is a library for doing functional programming in C++. The library provides a general framework to support various functional programming aspects, such as higher-order[1] polymorphic[2] functions, The issues with this are: 1. When this is in context of proposed Boost.FC++ docs, one immediately wonders how this is different from Boost.Lambda. 2. The footnotes always break the regular flow of reading, so it's better not use them in the first sentence new user is likely to see. 3. higher-order polymorphic functions exists even without FC++. I think boost::bind is such a function: it takes function as argument and returns a function. So, this statement does not indicate what new FC++ brings (btw, I agree it brings something new). 4. If you think that average reader will think that 'polymorphic' == 'with virtual functions' you might want to use the word 'generic'. Later, you define 'functiod' and the definition applies just nice to functional objects everybody was using for quite some time. Again, you don't explain what FC++ brings. Later, you describe changes made during boostification. I really don't think new user would be interested in that. The above comments might sound like nit-picking, but what I try to say is: the instroduction does not say absolutely anything about why FC++ is worth looking at. The only new term there is 'lazy_list' and if reader doesn't know what's that already, he might not get even that. In section 2, you say: Programming in this pure style ensures referential transparency. and I don't know what "transparency" here means. Now, to section 4, "Overview". What I'd expect in this section is a bunch of examples, showing what I can do with FC++ which is not easily done using other tools. What I see, though, is: We could define a polymorphic functoid add_self(), which adds an argument to itself: // add_self( x ) means x + x If we can define such thing, I'd really like to see the definition, not commented out code. The you talk about lazy list, again for someone who has no idea what they are, it's hard to understand usefullness. I think you should either explain this with an example, or at worst give some link. E.g. "Why functional programming matters" makes some use of lazy lists, IIRC. The overview does on in largely the same style. You list supported functoids but don't give any explanations or example. Last comment on this section: plus(3,4) // 3+4 also minus, multiplies, etc. This does not look impressive. Can't I do "std::plus<int>(3,4)". I think one of the points of FC++ is that you don't need to specify the exact type. If so, you need to explicitly state that fact (and preferrable, even in the introduction). Now to the Section 5. Direct functoids enable the creation of functions Hmm.. is it precisely "enable". I suspect that "direct functoid" *is* the function. Or is direct functoid is some device which produces functions? I think the example with 'map' is not really good. First you say map takes a list and function. Then you give Haskell syntax and describe that syntax. After that you explain what's high-order and what's polymorhic. IMO, the Haskell syntax is just not necessary here. Later you say: Representing such a function in C++ is non-trivial Then, what about std::transform? If we forget that it works on iterators, not sequences (which is just detail) then it does exactly what you're after. I think it would be better if you write down properties of the function you want to create (polymorphic, can be passed as argument *itself*, allows to inter return type) and then immediately give an example. And example could be more reabably you use split the definition of 'result_type' like this: template <class F, class L> struct sig { typedef F::template sig<typename L::value_type>::result_type function_return typedef list< function_return > result_type; }; It might be better to use 'type' instead of 'result_type' since MPL uses 'type'. When you talk about monomorphic direct functoids, I wonder why you need 'c_fun_type'. Is it possible to make std::unary_function work? The section 6, "Indirect Functoids", makes me wonder if they are usefull at all. boost::function works very nice with me, and it also works with boost:bind. The secton 7, "Full Functoids" looks ok to me, though some examples would be good. At this point I've stopped reading documentatation, tried to write some code and got my 'in_degree_f' in a short time. There are some additional questions: 1. Maybe it makes sense to provide a helper base class for a case where return type is fixed, but argument types are not. Something like: class xxx_in_degree : public ret_type2<unsigned> { ... } ; 2. Do we need intermediate typedef? Won't boost::fcpp::full2<xxx_in_degree> in_degree_f; work just fine? 3. I have std::find_if(vertices(g).first, vertices(g).second, in_degree_f(_, g)); but I want to compare the return from 'in_degree_f' with zero, as in thes example: find(vertices(g).first, vertices(g).end(), bind(in_degree, _1, g) == 0); How do I do that? When I try: std::find_if(vertices(g).first, vertices(g).second, lambda(X)[ in_degree_f[X, g] %equal% 0]); I get a lots of errors, starting with: fcpp/signature.hpp:114: error: invalid use of undefined type `struct boost::fcpp::impl::XEqual::sig<size_t, int>' The complete example is at http://zigzag.cs.msu.su:7813/bgl.cpp if needed. Also, it would be *really* nice if lambda syntax in FC++ and Boost.Lambda was compatible. I'll print and read your paper on syntax today, but no matter how big semantic differences are, learning/using two different syntaxes is a bad idea. These are all comments for now. Hope they make sense. - Volodya

1 0

Lambda regression with GCC-3.4
by Michael Stevens 09 Apr '04

09 Apr '04

Hi All, (particularly Jaakko!) While working on using BLL's operator return type mechanism in uBLAS I stumbled on the problem the recent (snapshot) GCC-3.4 has with BLL. I noticed Jaakoo checked in the following patch a few days ago as a workaround. #if BOOST_WORKAROUND(__GNUC__, == 3) && __GNUC_MINOR__ >=4 #include <vector> #else namespace std { template <class T, class Allocator> class vector; } #endif >From my own research the problem is not just restricted to 'std::vector'. It certainly also occurs with 'std::map'. I assume (have not verified) that the problem is related to hidden template parameters in the gcc-3.4 implementations of the std containers. OR is the problem simply a bug (an regression) in gcc 3.4 Too late for gcc 3.4 but I will submit a bug report if no one else has already done so. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://www.sf.net/Bayes++ ___________________________________

3 2

Re: [boost] Formal Review: Assignment Library
by Vladimir Prus 09 Apr '04

09 Apr '04

Tom Brinkman wrote: > The review of Assignment Library library, written by > Thorsten Ottosen 2003 (nesotto(a)cs.auc.dk) starts > today(April 1, 2004)and runs for 10 days. I think the library should be accepted, though I have some suggestions. The review below is based on reading the documentation for about an hour. First off, I think such a library is usefull. Besides stl container initialization, it would be usefull for other libraries which want to provide convenient initialization syntax. Now, to the suggestions 1. The library expects the user to overload 'make_insertion' for his types. Now suppose I have 'class Email' which list of 'to' and 'cc' addresses.I want to initialize both using the assign library, e.g Email e; e.add_to("Winnie-the-Pooh")("Ia"); e.add_cc("Story writer"); The problem is that I can have only one 'make_insertion' for the 'Email' class. Exposing the real containers used for storing addresses is not good idea. And there might be 'add_to_address' function which does additional handling of argument, before pushing it into the container. So, it would be nice if the library allowed to specify a *function* which will do the actual insertion. 2. The library examples contain using namespace assignment; which is likely to burn users in a subtle way. Suppose: // some header namespace email { class Email {}; std::ostream& operator<<(std::ostream& os, const Email& e); } // some source #include "some header" namespace email { using namespace assignment; void internal_function() { vector<int> v; .... v << 1, 2, 3; } } The operator<< declared in the namespace will hide the one from "using namespace", and unless user is aware about this problem he might spend a lot of time trying to understand why the right operator<< is not selected. I know it costed me about 1 hour some time ago. 3. While the += operator is fine with me, I don't like the << operator. I cannot associate the conventional meaning of the operator with 'assign all' semantic, so I suggest that this operator is dropped completely. You can provide alternative syntax for assign_all: assign(v) = 1, 2, 3, 4, 5; if assignl(v)(1)(2)(3)(4)(5) has too many paranthethis. (Since comma has lower predecence than =, the first syntax will really work). 4. The operator() and other operators in insert_assigner are declared inline. Suppose vector<some_type> v; assign(v)("first", "")("second", ""); This involves call to constructor of 'some_type' and possible calls to additional constructors needed to converted char* into types that 'some_type' excepts. If operator() is inline, those calls will be inlined as well, increasing code size. Similiar problem exists because single-argument operator() accepts a fixed type, possible requiring convertion on the caller's side. I'd suggest the declare the operators outside of class declaration. This will give the compiler more freedom -- e.g. inlining only if maximum optimization level is requested. 4. Just like other revievers, I'm not comfortable with monolitic stl.hpp 5. Operator += which is declared for all possible types makes me nervous. IIRC, stl formatiing library by Terje Sletteb used some trick to avoid exposing all those operators. Something like template<template<class T, class Alloc> sequence> class helper { friend std::ostream& operator<<(std::ostream&, const Sequence& s) { ... } } // in vector.hpp template helper<std::vector>; Terje said the explicit instantination bring the friend declaration into namespace. I'm somewhat rusty on friend lookup rules, so further investigation is needed. Documentation issues 1. The example for maps uses: map<const char*, int> month; which is a bit strange, even for example, given that comparison for "const char*" does not compare string values 2. In the graph example, I'm not sure how you add edge between vertices 4 and 6, in a graph with only 5 vertices. If new vertices are automatically added, this should be documented. And BTW, what about graph which don't use ints for vertex_descriptor? 3. I did not really understoon 'tuple_insert_assigner' role. Why is it needed? - Volodya

2 6