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

Re: [Boost-users] [proto] a question on assignment operators
by Eric Niebler 25 Aug '09

25 Aug '09

(Public response to Maurizio's private follow-up. Hope Maurizio doesn't mind.) Maurizio Vitale wrote: >>>>>> "Eric" == Eric Niebler <eric(a)boostpro.com> writes: > > Eric> Maurizio Vitale wrote: > >> Hi Eric, while you were on vacation I posted the following on the > >> boost.users > Eric> <snip> > > Eric> Sorry for the delay; I missed your original message. I've > Eric> followed up on the boost-users list. In short: I don't > Eric> understand enough of what you're trying to do to help. Please > Eric> clarify and I'll help as best I can. > > Let me try to rephrase what I was trying to ask and see if I'm more > successful. > > The gist of the question is what happens when you have to add an > operator= to a proto extended expression. You normally wouldn't because > in general it doesn't make much sense to do things like: > > a+b = c-d; > > (although it could make sense in a DSL for linear algebra) > In my case something like: > > (a,b,c) = expression; > > would require to do (inside my_expr::operator=): > a = f (expression); > b = g (expression); > c = h (expression); > > where f,g,h depend on the semantics. In my case they would carve a > certain number of bits from expression. In a DSL dealing with tuples > they would select the appropriate component from expression. OK sure, that makes sense. > The problem I'm having is that expressions built by proto seem to be > const, forcing operator= to be const (or at least that's what happens in > my example). It's true, Proto's objects have a top-level const qualification. They are, after all, rvalues (temporaries) so they should not be modified. HOWEVER, the const-ness only applies at the top-level. The const-ness of child nodes is preserved. In particular, non-const lvalue terminals are held by reference and remain non-const. Consider: typedef proto::terminal<int>::type I; I i = {42}; I & refi = proto::left(i+i); The temporary object created by i+i is const, but each i is held by non-const reference, which is what is returned by proto::left. > If that's true, then my followup question was whether it is > ok to perform the assignment the way I was doing it, casting away const. In short, it shouldn't be necessary. You're using proto::flatten and fusion::fold. Somewhere in there the constness is getting messed up. You should file a bug. Proto's fold_tree transform gets the constness correct. See the attached code which is equivalent to yours, but doesn't require any ugly const_cast's. > The other question I had was on what was the reason for explicitely > disable assignment operators in grammars. This is something you do in > many of your examples I do? Which examples? I don't see it. > , but doesn't seem to make a difference in my code > (e.g. having an operator= in my expression seems to stop proto from > building a larger tree including the '=' anyhow, without needing to > disable it explicitly) I'm afraid you've lost me again. > The last question, which was the first, it is not very important. What > I'm really interesting in is how to use proto when you need to assign to > a proto expression, rather than a proto terminal. And I hope at least that much has been cleared up. HTH, -- Eric Niebler BoostPro Computing http://www.boostpro.com #include <iostream> #include <boost/mpl/plus.hpp> #include <boost/mpl/sizeof.hpp> #include <boost/proto/core.hpp> #include <boost/proto/transform.hpp> namespace mpl = boost::mpl; namespace proto = boost::proto; namespace fusion = boost::fusion; using proto::_; struct my_grammar : proto::or_< proto::terminal< int >, proto::binary_expr<_, my_grammar, my_grammar> > {}; template<typename Expr> struct my_expr; struct my_domain : proto::domain<proto::generator<my_expr>, my_grammar> {}; struct AssignTerminal : proto::callable { template<typename Sig> struct result; template<typename This, typename Terminal, typename Offset> struct result<This(Terminal &, Offset)> { typedef mpl::plus<mpl::sizeof_<Terminal>, Offset> type; }; template<typename Terminal, typename Offset> mpl::plus<mpl::sizeof_<Terminal>, Offset> operator()(Terminal & t, Offset) const { proto::value(t) = Offset::value; return mpl::plus<mpl::sizeof_<Terminal>, Offset>(); } }; struct AssignGroup : proto::fold_tree< proto::_, mpl::size_t<0>(), AssignTerminal(proto::_, proto::_state) > {}; template<typename Expr> struct my_expr : proto::extends<Expr, my_expr<Expr>, my_domain> { typedef proto::extends<Expr, my_expr<Expr>, my_domain> base_type; my_expr( Expr const & expr = Expr() ) : base_type( expr ) {} template<typename E> const my_expr& operator=(const E&) const { AssignGroup()(*this); return *this; } }; struct my_int : my_expr< proto::terminal< int >::type > { typedef my_expr< proto::terminal< int >::type > base_type; explicit my_int (int i = 0) : base_type (base_type::proto_base_expr::make (i)) {} operator int () { return proto::value (*this); } }; int main() { my_int i (1); my_int j (2); my_int k (3); (k,j) = (j,k); std::cout << j << std::endl << k << std::endl; } /// Local Variables: /// mode:c++ /// comment-column:60 /// fill-column:150 /// compile-command:"g++ -I. -I./boost -o testcase testcase.cpp" /// c-macro-cppflags:"-C -I. -I./boost" /// c-backslash-column:120 /// c-backslash-max-column:149 /// End:

3 3

Re: [Boost-users] Boost program_options
by Steve Nolen 25 Aug '09

25 Aug '09

Date: Sat, 22 Aug 2009 10:22:40 +0400 From: Vladimir Prus <vladimir(a)codesourcery.com> To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Boost program_options Message-ID: <h6o2r1$j2f$1(a)ger.gmane.org> Content-Type: text/plain; charset=us-ascii Steve Nolen wrote: > > in program_options::parse_command_line - why can't the the argument > > "argv" be of type 'const charT*' rather than 'charT*'? > > > > i ask because our unit tests were giving a bunch of errors because they > > were written like this.. > > > > vector< char* > cmdLine; > > cmdLine.push_back( "someExec" ); > > cmdLine.push_back( "--optflag1" ); > > cmdLine.push_back( "value1" ); > > etc. > > > > then... > > char ** argv = &cmdLine[ 0 ]; > > > > then passing this to parse_command_line. when we compile under g++ 4.x > > we get warnings that assigning string literals to char* is a deprecated > > conversion. Actually I agree with the rationale, but this leaves me > > with a problem calling parse_command_line. Is it going to change any of > > these values? > No, it's not actually changing anything. > > I know the c standard calls for the argv in main's prototype to be > > non-const, but why can't parse_command_line be more restrictive? > Because it that case, you won't be able to pass main's argv to parse_command_line. - Volodya --------------------- ok why not? you would be passing a non-const (main::argv) to a const qualified parameter. this would just guarantee that the function couldn't modify it (which is what you're telling me is the case here). i thought this was allowed. -steve

3 2

Linking fails to Boost_system (cannot open shared object file: No such file or directory)
by stationx 25 Aug '09

25 Aug '09

Hi all, I have linked my simple program that uses boost.filesystem as follows: accesstimer: acctime.o bentimer.o g++ -L/usr/local/boost/boost_1_39_0/stage/lib -lboost_system-gcc41-mt -lboost_filesystem-gcc41-mt acctime.o bentimer.o -o accesstimer acctime.o: acctime.cpp bentimer.h g++ -I /usr/local/boost/boost_1_39_0 -c acctime.cpp bentimer.o: bentimer.cpp bentimer.h g++ -c bentimer.cpp This compiles fine, but when I execute I get the following error: ./accesstimer: error while loading shared libraries: libboost_system-gcc41-mt-1_39.so.1.39.0: cannot open shared object file: No such file or directory I have looked in the .../stage/lib directory and the file does exist there. Can anyone see what I've done wrong? thanks -- View this message in context: http://www.nabble.com/Linking-fails-to-Boost_system-%28cannot-open-shared-o… Sent from the Boost - Users mailing list archive at Nabble.com.

1 1

copy constructor for derived boost::multi_array
by HweeKuan Lee 25 Aug '09

25 Aug '09

i am having problems compiling class derived from boost::multi_array. the copy constructor does not compile. as i understand, the usual copy constructor for derived class can be implemented as in line 12 in the code below. however, can't do the same for boost::multi_array at line 21. lots of compile error, i extracted a small part of it below 1 #include <boost/multi_array.hpp> 2 3 // ------------------------------------------ 4 template<class V> struct base { 5 base(int y) : u(y ) { } 6 base(const base<V>& b) : u(b.u) { } 7 int u; 8 }; 9 10 template<class V> struct derived : public base<V> { 11 derived(int y) : base<V>(y) { } 12 derived(const derived<V>& d) : base<V>(d) { } 13 }; 14 // ------------------------------------------ 15 template<class V, unsigned int D> 16 struct my_multi : public boost::multi_array<V,D> { 17 18 template<class extent_type> 19 my_multi(const extent_type& e) : boost::multi_array<V,D>(e) { } 20 21 my_multi(const my_multi<V,D>& t) : boost::multi_array<V,D>(t) { } 22 }; 23 // ------------------------------------------ 24 int main () { 25 derived<int> d(1.0); 26 derived<int> e(d); // ok 27 28 my_multi<int,2> mm0(boost::extents[3][4]); 29 mm0[0][0] = 6; // ok 30 my_multi<int,2> mm1(mm0); 31 } -------------- extracted compile error: bmulti.C:21: instantiated from 'my_multi<V, D>::my_multi(const my_multi<V, D>&) [with V = int, unsigned int D = 2u]' bmulti.C:30: instantiated from here /opt/local/include/boost/multi_array/collection_concept.hpp:44: error: 'struct my_multi<int, 2u>' has no member named 'swap' bmulti.C:21: instantiated from 'my_multi<V, D>::my_multi(const my_multi<V, D>&) [with V = int, unsigned int D = 2u]' bmulti.C:30: instantiated from here /opt/local/include/boost/multi_array/algorithm.hpp:56: error: cannot convert 'boost::detail::multi_array::const_sub_array<int, 1ul, const int*>' to 'long unsigned int' in assignment

1 0

Boost program_options
by Steve Nolen 24 Aug '09

24 Aug '09

in program_options::parse_command_line - why can't the the argument "argv" be of type 'const charT*' rather than 'charT*'? i ask because our unit tests were giving a bunch of errors because they were written like this.. vector< char* > cmdLine; cmdLine.push_back( "someExec" ); cmdLine.push_back( "--optflag1" ); cmdLine.push_back( "value1" ); etc. then... char ** argv = &cmdLine[ 0 ]; then passing this to parse_command_line. when we compile under g++ 4.x we get warnings that assigning string literals to char* is a deprecated conversion. Actually I agree with the rationale, but this leaves me with a problem calling parse_command_line. Is it going to change any of these values? I know the c standard calls for the argv in main's prototype to be non-const, but why can't parse_command_line be more restrictive?

3 2

[tuple] [serialization] serialize a tuple
by Dmitry Vinogradov 24 Aug '09

24 Aug '09

How to serialize a tuple? Where are no boost/serialization/tuple.hpp, nor boost/tuple/tuple_serialization.hpp...

4 4

[boost] Formal Review: Boost.Polygon starts today August 24, 2009
by Fernando Cacciola 24 Aug '09

24 Aug '09

Dear Developers, The formal review of the Boost.Polygon library by Lucanus Simonson starts today, August 24, 2009 and will finish September 2, 2009. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! --------------------------------------------------- About the library: The boost polygon library provides algorithms focused on manipulating planar polygon geometry data. Specific algorithms provided are the polygon set operations (intersection, union, difference, disjoint-union) and related algorithms such as polygon connectivity graph extraction, offsetting and map-overlay. These so-called Boolean algorithms are of significant interest in GIS (Geospatial Information Systems), VLSI CAD as well al other fields of CAD, and many more application areas, and providing them is the primary focus of this library. The polygon library is not intended to cover all of computational geometry in its scope, and provides a set of capabilities for working with coordinates, points, intervals and rectangles that are needed to support implementing and interacting with polygon data structures and algorithms. Specifically, 3d and non-Cartesian/non-planar geometry is outside of the scope of the polygon library The design philosophy behind the polygon library was to create an API for invoking the library algorithms it provides on user geometry data types that is maximally intuitive, minimally error-prone and easy to integrate into pre-existing applications. C++-concepts based template meta-programming combined with generic operator overloading meets these design goals without sacrificing the runtime or memory efficiency of the underlying algorithms. This API makes the following code snippet that operates on non-library geometry types possible: void foo(list<CPolygon>& result, const list<CPolygon>& a, const list<CPolygon>& b, int deflateValue) { CBoundingBox domainExtent; using namespace boost::polygon::operators; boost::polygon::extents(domainExtent, a); result += (b & domainExtent) ^ (a - deflateValue); } The source is available at http://svn.boost.org/svn/boost/sandbox/gtl/boost/polygon/ And the documentation is at http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Best Regards Fernando Cacciola Review Manager _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[proto] extended expressions and assignment operator
by Maurizio Vitale 24 Aug '09

24 Aug '09

Hi Eric, I'm trying to have proto allow me to do things like: (a,b,c) = expr; where a, b, c are integers of different width and they should be assigned the appropriate slice of expr. For instance: | variable | width | value | |----------+-------+-----------| | a | 2 | expr[6:7] | | b | 4 | expr[2:5] | | c | 2 | expr[0:1] | width are compile-time constants and I need to keep them so (they'll be used to compute masks and shifts at compile time). First problem is that I do not know of a good way for doing this. As you'll see in the code attached, right now I'm using fusion::fold and proto::flatten, but this does the width part at run-time (in the example I'm using sizeof () instead of real widths to keep things simple). The second problem is that operator= needs to be const. I think I've an idea of why, but I'd appreciate if you could tell me. Assuming this is what it should be, is it safe to cast away the constness in struct assign? Last question, I've seen in some of your examples that you explicitly disable all assignment operators. It doesn't seem to make a difference here. What is the story? Thanks a lot in advance, Maurizio --

4 3

commandline args
by Shaolin 24 Aug '09

24 Aug '09

Hi Guys Below is my current code used to retrieve commandline arguments: int i = 1; while (i < argc) { if (strcmp(argv[i], "-f") == 0) { for (++i; i < argc && strcmp(argv[i], "-s") != 0; ++i) { filearr.push_back(argv[i]); } } else if (strcmp(argv[i], "-s") == 0) { for (++i; i < argc && strcmp(argv[i], "-f") != 0; ++i) { searchtext = argv[i]; } } else { ++i; } } As you can see, its not very scalable. I am thinking of adding another feature args but it'll become difficult to manage. Is there anything on boost which does the same thing albeit with alot less code ?

9 34

boost.m4 checks correct header but detects wrong header version
by Peter Schueller 24 Aug '09

24 Aug '09

(posting to the boost-users list and to the boost.m4 maintainer) I'm using autotools with the newest boost.m4 from http://repo.or.cz/w/boost.m4.git and have the following problem: I have several boost installations, among others a 1.34.1 in /usr/include and several in my homedir in /home/staff/ps/include/boost-1_36/ /home/staff/ps/include/boost-1_37/ /home/staff/ps/include/boost-1_39/ Calling configure with --with-boost=/home/staff/ps/include/boost-1_37/ I get the following information: checking for Boost headers version >= 103300... /home/staff/ps/include/boost-1_37/include checking for Boost's header version... 1_34_1 The first check finds the correct headers, the second one uses the wrong ones. configure.log says: ==== configure:20676: checking for a sed that does not truncate output configure:20755: result: /usr/bin/sed configure:20787: checking for Boost headers version >= 103300 configure:20841: g++ -c -g -O2 -I/home/staff/ps/include/boost-1_37/include conftest.cpp >&5 configure:20847: $? = 0 configure:20876: result: /home/staff/ps/include/boost-1_37/include configure:20886: checking for Boost's header version configure:20907: result: 1_34_1 configure:20938: checking boost/scoped_ptr.hpp usability configure:20955: g++ -c -g -O2 -I/home/staff/ps/include/boost-1_37/include conftest.cpp >&5 configure:20961: $? = 0 configure:20975: result: yes configure:20979: checking boost/scoped_ptr.hpp presence configure:20994: g++ -E -I/home/staff/ps/include/boost-1_37/include conftest.cpp configure:21000: $? = 0 configure:21014: result: yes ==== So only the one check does not use the newly found CPPFLAGS. I also saw that the header check is done WITHOUT using _AC_DO_STDERR so the actual g++ call for the header check is not shown. Unfortunately I did not succeed in changing the check to use _AC_DO_STDERR so I'm writing this mail instead of sending a patch suggestion. Regards, Peter Schüller -- Peter Schüller Institute of Information Systems, Vienna University of Technology Favoritenstrasse 9-11/1843, A-1040 Vienna, Austria T: +43 (1) 58801-18470 E: ps AT kr DOT tuwien DOT ac DOT at Homepage: http://www.kr.tuwien.ac.at/staff/ps/ TU Wien DVR: 0005886

1 0