- Boost - lists.boost.org

fusion::for_each question: Why const operator in the fctor?
by Brian Braatz 03 Jun '05

03 Jun '05

I am using the fusion code in 1.32 with the vc 71. compiler. My question is, considering the following unit test (for_each_tests.cpp) struct print { template <typename T> void operator()(T const& v) const { std::cout << "[ " << v << " ] "; } }; { typedef tuple<int, char, double, char const*> tuple_type; tuple_type t(1, 'x', 3.3, "Ruby"); for_each(t, print()); std::cout << std::endl; } (this code runs correctly for me) If I change the function to: struct print { template <typename T> void operator()(T & v) const { std::cout << "[ " << v << " ] "; } }; It still works, but changing it to struct print { template <typename T> void operator()(T & v) { std::cout << "[ " << v << " ] "; } }; Does not work. Why does the functor need to have a const operator()? I have been trying to take a tuple<> and touch each node in the tuple (ala for_each in fusion), which I was *very* happy to find fusion has this as working functionality. But, the next step for me is to have the functor write to its local member variables. I.e. requiring const here really limits the usefulness of the fusion::for_each. I look in my compilers header and noticed that stl::for_each does not have a const requirement on the functor. Is this a mistake? Is there a reason I am not seeing why for_each would have this limitation? Thanks for any help and guidance. Brian "Remember, there are no stupid questions. Only stupid people....."

2 1

RE: [boost] Re: Probing interest in fixed dimension matrix class
by Martin Bonner 03 Jun '05

03 Jun '05

----Original Message---- From: Deane Yang [mailto:deane_yang@yahoo.com] Sent: 02 June 2005 16:57 To: boost(a)lists.boost.org Subject: [boost] Re: Probing interest in fixed dimension matrix class > Andy Little wrote: >> >> eg to find the point 1/3 rd way from the start of line(A , B) one >> could calculate 2/3 *A +1/3 * B. >> > > I think it is more natural to compute this as > > A + (1/3)*(B - A), > > where A and B are points and B - A is a vector. So you're really still > just adding a vector to a point to get a new point. There is never a > need to add or rescale points. Hmm. To me that looks a very UNnatural recasting of the original in order to satisfy the rule. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Sunday: Mailing list outage
by David Abrahams 02 Jun '05

02 Jun '05

-- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

set arithmetic proposal
by Dominic Herity 02 Jun '05

02 Jun '05

I've often wished that STL sets supported set arithmetic operations. Addition, multiplication and subtraction operators could be overloaded with set union, intersection and difference respectively. For example: set<char> s1; // s1 <- {} s1 += 'a'; // s1 <- {a} set<char> s2 = s1 + 'b'; // s2 <- {a,b} set<char> s3 = s2 - s1; // s3 <- {b} set<char> s4 = s1 * s2; // s4 <- {a} Achieving the above results with the existing STL library is by comparison cumbersome, error-prone and unclear. Although this proposal does not follow the STL design philosophy, it meets a real developer need. It can be implemented using global operator overloads, which should avoid conflicts with other uses of STL sets. Comments and suggestions welcome. Best Regards Dominic Herity Red Plain Technology (www.redplain.com) T:+353-87-2208233 F: +1-603-909 6570 E: dominic.herity(a)redplain.com

6 7

Re: Typeof: Review result
by Tom Brinkman 02 Jun '05

02 Jun '05

>> >> I am pleased to formally announce that the Typeof library has been accepted into >> Boost. > > Congratulations Arkadiy and Peder. > >> There were 3 reviews, all in favour of accepting the library. > > While I'm not questioning the value of accepting this library > specifically, doesn't it seem less than ideal to accept a library > that -- for whatever reasons -- garnered only three reviews? >> Yes. > While the library was truly peer reviewed, and the reviews were > by knowledgeable folk, the base of input is narrow as a result. > Should this be the norm? >> No. Not sure what we can do about it. I think the review wizard > should weigh in here. Three positive reviews is not sufficient in my opinion. However, the precedent has already be set, as other libraries have been approved on a similar limited number of reviews. I'm sure most would agree that the review situation is not ideal and could be improved. However, it has worked to some extent and the boost c++ libraries, are arguably among the best available. One easy improvement would be to require that each approved library be endorsed/sponsered by a least one prominent boost member, such as Dave Abrahms, Jeff Garland or Thorsten Ottosen. Another easy improvement would be to add accepted libraries under a probation or beta period of say six months. The library would remain beta until its stable enough and has additional time for more user scrutiny. A prominent boost member would make the judgement about when to remove the library from its beta period. During the beta period, the library author would be asked to complete the libraries documentation, examples and requested changes from the additional user scrutiny. If there are no objections, I will start requesting that libraries under review be sponsered by at least prominent boost member. This would ensure that accepted libraries meet the approval of a least one prominent boost member. Review Wizard, Tom Brinkiman

11 14

Boost/SourceForge statistics
by Beman Dawes 02 Jun '05

02 Jun '05

SourceForge has markedly improved project statistics reporting. See http://sourceforge.net/project/stats/index.php?group_id=7586&ugn=boost I found the pages viewed numbers interesting. Looks like www.boost.org has been serving an average of about 22,000 page views a day in recent months. I suppose some sites serve up that many pages in a minute or a second, but 22,000/day doesn't seem too bad for a C++ library effort. --Beman

2 1

Pointers to member function templates as template arguments
by Jonathan Turkanis 02 Jun '05

02 Jun '05

Hi, Consider the following code: template<typename T, void (T::*) (int)> struct MemFn; struct Foo { template<typename Int> void bar(Int) { } }; typedef MemFn<Foo, &Foo::bar> type; This compiles with VC7.1, GCC 3.4, Intel 8.0 and Comeau 4.3.3 in strict mode, but CodeWarrior 9.4 fails with the message: Error : illegal implicit member pointer conversion example.cpp line 9 typedef MemFn<Foo, &Foo::bar> type; Looking at 14.3.2/1, I notice while the third bullet, on function pointers, explicitly mentions templates, the fourth bullet, on pointers to members, doesn't. But perhaps pointers to function templates are covered implicitly. Looking at 14.3.2/5, bullet 6, I see that no conversions are applied to pointers to members. But no conversions are needed in the above example. What's needed is overload resolution, which is explicitly allowed. So who's right -- Metrowerks or everyone else? Jonathan

2 5

[iostreams] failure do build zlib.cpp in cvs HEAD
by pedro.lamarao＠mndfck.org 02 Jun '05

02 Jun '05

It seems the declaration of zlib_base::reset in zlib.hpp doesn't agree with the definition in zlib.cpp. After applying the following trivial patch everything compiles fine. -- Pedro Lamarão Index: boost/iostreams/filter/zlib.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/iostreams/filter/zlib.hpp,v retrieving revision 1.18 diff -r1.18 zlib.hpp 194c194 < void reset(bool compress); --- > void reset(bool compress, bool realloc);

2 1

PyQt and Boost.Python working together
by thor.arne.johansen＠ibas.no 02 Jun '05

02 Jun '05

I found a long thread discussing this topic, but the conclusion escaped me... Is it possible to use an extension created with BPL in a program using PyQt to provide a GUI? -- Thor Arne Johansen Technical Director Ibas AS

2 1

[Boost-bugs] [ boost-Support Requests-1213620 ] Configure options (CCFLAGS, LDFLAGS) ignored in build ?
by SourceForge.net 02 Jun '05

02 Jun '05

Support Requests item #1213620, was opened at 2005-06-02 09:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1213620&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Configure options (CCFLAGS, LDFLAGS) ignored in build ? Initial Comment: Hi, on our Red Hat Enterprise Linux 3.0 Opteron Machine the g++ is configured to produce 64-bit binaries. When trying to build 32-bit objects via the "-m32" compiler and linker options, the boost build mechanism simply seems to ignore the option provided. Interestingly one can provide this option to the configure script but in it's output (the user.hpp file) the option only appears as a comment. It seems to get completely ignored in the subsequent build and test stages ! Is this true or am I missing some way to configure things here ? How can I supply special compile/link options to the build/test stages of the boost build process ??? Thanks in advance Frank-Oliver ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1213620&group_… ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0