- Boost - lists.boost.org

Re: [boost] [boost.build] should we not define _SECURE_SCL=0bydefault for all msvc toolsets
by raindog＠macrohmasheen.com 20 Dec '08

20 Dec '08

I read about people running into them frequently enough on internal discussion aliases at microsoft (where I work) and recall just last week I believe someone who ran into a perf issue on this newgroup while writing a sorting algorithm ------Original Message------ From: Emil Dotchevski Sender: To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Sent: Dec 20, 2008 12:13 AM Subject: Re: [boost] [boost.build] should we not define _SECURE_SCL=0bydefault for all msvc toolsets On Fri, Dec 19, 2008 at 10:34 PM, <raindog(a)macrohmasheen.com> wrote: > The checks are however a huge performance hit that people tend to be caught by surprise with. Not my experience. The checks do affect performance, but rarely enough to get on my radar. I do like having them on by default. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

2 1

[Test] should we consider to turn off argument deduction for 2nd template parameter
by Thorsten Ottosen 20 Dec '08

20 Dec '08

Hi Genndiy, When I write code like BOOST_CHECK_CLOSE( a->conditionals().sum(), 2., 0.001f ); I tend to get a compilation error the first time, because I wrote BOOST_CHECK_CLOSE( a->conditionals().sum(), 2, 0.001f ); I think that many users are not helped very much by the resulting error messages deep inside the test library. Maybe we should consider to turn off deduction for the second argument with template< class T > bool operator()( T l, mpl::identity<T>::type r, ... ); ? Any thoughts. -Thorsten

5 6

Boost Inter-Project Dependencies: Graphs Generated
by Christoph Heindl 20 Dec '08

20 Dec '08

Dear developers and members, I'm using boost for quite a while now and it helped me a LOT in my daily work! I wanted to give something back to the community and started a boost inter-project dependency parser project. The aim of the project is to generate boost inter-project dependencies by parsing boost header files and aggregate them in managable images. First results can be found at http://picasaweb.google.com/christoph.heindl/BoostDependencies1370# Please find the code, additional information and limitations at http://cheind.blogspot.com/2008/12/generic-dependency-parser-boost.html I hope this is useful to somebody :) Best regards, Christoph

3 4

Re: [boost] interest in properties library
by Daniel Oberhoff 20 Dec '08

20 Dec '08

Hi, On Fri, Dec 19, 2008 at 5:50 AM, Daniel Oberhoff < daniel.oberhoff_at_[hidden]> wrote: > Hi, > > I am thinking about submitting a library proposal and would like to query > wether there is any interest in such a library and chance of success of such > a proposal. > > The basic idea is to implement the possibility to decorate a class with > named properties, such that given a pointer to an instance properties can be > accessed by name rather than using set/get methods. Also the type of the > instance should not need to be known at compile time, other than that it > derives from a suitable base class describing the property mechanisms. > > There is a rough implementation existing and used in a product environment. > Setting and getting is done using appropriate boost functions. Type > resolution is done using RTTI (especially dynamic cast). Complex inheritance > hierarchies are supported through virtual inheritance from the base class, > such that several classes along the hierarchy can contribute property slots. > CRTP and static initialization is used to register properties. Convenient > setter/getter function generators are provided as is a mechanism to access > nested properties using dot notation. I'm not sure I follow exactly what you mean, could you give a small example of the interface and usage? It sounds like you are referring to something along the lines of C# properties though I don't immediately see what you are using dynamic casting for or what exactly this provides as a benefit over get/set methods. Thanks. Well, yes, it is in one way like c# (or ObjC 2.0) properties, in that you can have direct access to the variables first, and then override setters/getters later. But the difference is, that properties are accessed by name, and the type of the object does not need to be known. That is set/get methods of the object would never be visible. You only need to know, that the object derives from a HasPropertiesBase class. That is also where dynamic cast comes in, in order to hand the right pointer to the setter method (you may be surprised, but in the case of virtual inheritance the pointer returned by dynamic cast actually points to a different address). I use it in a setting where I generate objects from a factory, and they are returned as pointers to an abstract base class, and the actual type is never exposed. Also accessing properties by name makes scripting very easy. btw, I hope I got this reply addressed right. the problem is I thought this list is identical to boost.users on gmane, so I turned of mail reply, but it seems this is a different list. anyhow, is there general interest in such a library? Daniel -- -Matt Calabrese

1 0

tweaking the review process (was: signals2 review results)
by Stjepan Rajko 20 Dec '08

20 Dec '08

On Thu, Nov 20, 2008 at 11:40 PM, vicente.botet <vicente.botet(a)wanadoo.fr> wrote: > > I would like to make some suggestion to improve the review management: > Thank you for starting this discussion. > * I had notice only at the end of the the review that the review tokes place on two mailing lists (devel ans user). Maybe this is usaual on Boost reviews but I was not aware. It will be more transaparent if all the reviews were posted to the same mailing list, maybe a specific one should be created. Yes, this is a bit of an issue. I mentioned that both lists are used in my post that opened the review (in my notes to first-time reviewers) to try to give people a heads-up (but... I often get long-winded and I'm sure it's easy to miss parts of my posts :-)). Having a dedicated, or at least recommended mailing list (either dev or user) might be a good thing. The only problem I see regarding a completely separate mailing list is that it requires active effort to sign-up for and follow. I think that for many people (even those that are genuinely interested in the library), the fact that the review is happening at time X-Y very easily slips off the radar. Having the e-mails constantly appear in the common lists also serves to remind everyone of the ongoing review, and I suspect it leads to many valuable impromptu comments and even full reviews from people that perhaps weren't originally planning on participating in the review, but end up following the review because it happens on the list (I recall being in this situation myself several times). > > * From the 5 committing reviewers making this review possible only 3 made a review and 2 of them late. I'm wondering if this new rule must be preserved as the review can be accepted without the commiting reviewers review. Trying to use committed reviewers was a new thing for this review (it was proposed by others in http://tinyurl.com/48tdjs) Now that it has been tried out, it would be good to reflect on how things went. For the reviews that were late, the reviewers were very diligently contacting me about their changing time constraints and offered times that would work for them, and I found those times acceptable. Out of the two committed reviewers that did not submit, one also diligently worked with me on setting up an alternative timeline, but in the end contacted me saying that a full review would not be possible after all, and offered a brief report of looking into the library and a brief rationale for acceptance (as the points matched those of other reviewers, I didn't forward it to the list). I was not able to contact the final reviewer after a certain point. I think the major benefit of the committed reviewers is the high probability that they actually will submit a review. Things always happen, and boost contributions are all volunteer time, but I found that overall the committed reviewers *very responsibly* succeeded in keeping their commitment as well as they could. Were they not committed reviewers, I suspect many of them would have considered giving up. In addition, the extensions that the committed reviewers negotiated gave other reviewers a chance to contribute. So, I feel that committed reviews are a good way of reasonably making sure that a certain number of reviews will be submitted. I'm not sure that the library acceptance / rejection should be influenced by the number of committed reviews (reviews from others are a perfectly good substitute). While we're on this topic... The one thing that the number of committed reviewers should definitely influence is whether the review happens in the first place. We were fortunate to get 5 people sign up, which was the only threshold proposed, so we followed through with the review. I was wondering what to do if the threshold wasn't crossed, and I think what I would have proposed is some sort of a holding pattern, where the review schedule page is updated to say something like "signals2 - reviewers needed, contact review manager to sign up as a reviewer". Once the threshold is crossed, the reviewers, manager and author can schedule a time. Another thing... many of the committed reviewers reported that they were first time reviewers (and the reviews they submitted were impressively detailed and very valuable). Personally, I was thrilled by this, since getting new participation in boost is critical to sustaining its quality . Perhaps some combination of allowing reviewers to commit beforehand, and explicitly encouraging reviews focused on the user perspective (another suggestion from the http://tinyurl.com/48tdjs thread), helped in getting first-time reviewers (perhaps the reviewers can comment on this?). > > * There were some reviews that came into this list by the intermediation of the review manager with a delay between the posting of the reviwer and forward from the RM. One negative review posted the 4th and reveived in this list the 11th other positive posted the 2nd and received in this list 3rd. I think that the review manager should not encourage the reviewers to send the reviews to himself. This will avoid this kind of delays. So I purpose that only the reviews sent to this single mailing list must be taken in account. Yes, this particular delay is entirely my fault. I can't explain why I didn't notice this email until so late (which is the point where I contacted the poster notifying him I would like to forward the mail, and forwarded it the following morning). Allowing reviews to be sent to the review manager is straight from http://www.boost.org/community/reviews.html (Introduction paragraph). There are two valid reasons for this, IMO: * the reviewer is only subscribed to one of {boost, boost-user, boost-announce} lists, and would like the reviewer to be forwarded to both boost and boost-user lists (if there was a dedicated review list, like you suggest, that was also open to all posters, then this reason would go away) * the reviewer would like to remain anonymous to the list (granted, this could also be accomplished by sending from an anonymous e-mail). If this stays as it is, the RM should be more diligent about monitoring her personal mail, which I apparently wasn't. > > * Even if the review was over the 10th there were 2 accepting reviews comming from the commiting reviewers just some hours before the review result annoncement 19th. I think that the review manager must state clearly when the review is over and do not accept any review after. This do not means that the RMcannot change this date, but annnce it clearly. I tried to keep my timeline as transparent as possible. In my review-closing email, I asked people to let me know if they were considering writing a review. Those that contacted me were informed of the timeline of pending reviews. When the last promised review was submitted, I set a hard deadline. Given the uncertainty in people's schedules, I decided to approach this in a flexible way. That was just my personal preference - I'm sure setting a hard deadline earlier would have been a fine choice as well. > > I hope this will help to improve future reviews, > Thanks again for starting this discussion and for your suggestions - I also hope good improvements will come out of it. Stjepan

5 8

Re: [boost] Asking for feedback for book (in German) about the Boost C++ libraries
by Boris 19 Dec '08

19 Dec '08

On Mon, 15 Dec 2008 02:30:16 +0100, Jeff Dunlap <jeff_j_dunlap(a)yahoo.com> wrote: > Wow, you cover alot of libraries and I like the examples! Will it be > written in English too? Thank you! Currently I've no plan to translate the book. I'll add more chapters to cover more Boost libraries though. As this is already quite a lot of work another volunteer needs to translate. ;) Boris > [...]

2 3

Re: [boost] [uuid] Interface
by Vladimir Batov 19 Dec '08

19 Dec '08

>> ... > No. The input iterator constructs from the raw octets, expecting them > as in 4.1.2. Layout and Byte Order Well, I obviously confused the construction from a string and the construction from the raw octets. Quite embarassing. My mind is obviously already chasing that Christmas goose. > I'm still not convinced that that providing the default constructor is > such a bad thing, so I would still like Andy's #define to allow it. I'd like the default constructor as well. Very much in fact. The problem is that our expectations of what that constructor needs to do are quite different. The behavior of the default constructor that you'd like to see (apologies if I got it wrong) is to create an invalid uuid. I feel that is not the canonical use of the default constructor. Indeed, that usage of the default constructor *not* to actually create an object has become quite popular. It does not make it right though. I find it unfortunate and hackish. I feel that the default constructor should indeed construct... with all the default "parameters"... as the language prescribes... as other constructors do. In uuid context it'd be to let the OS/infrastructure decide what is best. That way we'd achieve the best portability without sactificing the quality and I am sure for that reason it'll be the most popular deployment. That's why I'd like that behavior assigned to the simplest available (default) constructor. I do not want to be forced to choose a certain generator just to discover it is not supported on another platform. Having said that I do not see my view getting far. In that case, I'd prefer not to have the default cnstr at all as IMHO it sends the wrong message and enforces the wrong programming practice. Just my view, of course. OK, I guess, it is indeed time for me to tune out and get into that Christmas spirit. Happy Christmas and Happy New Year everyone (pick whichever appropriate). Best, Vladimir.

3 2

accumulators + complex
by Neal Becker 19 Dec '08

19 Dec '08

I'm interested in 2nd order stats for complex numbers. typedef std::complex<double> complex_t; typedef accumulator_set<complex_t, stats<tag::mean, tag::moment<2> > > acc_t; 2 issues: 1) Need template<typename flt_t> inline std::complex<flt_t> operator/ (std::complex<flt_t> const& a, unsigned long int b) { return std::complex<flt_t> (real (a)/b, imag (a)/b); } 2) What do I get for moment<2> in the case of complex (and does this match the usual mathematical definition?)

2 3

[accumulators] misprint in accumulators users guide
by Neal Becker 19 Dec '08

19 Dec '08

The example under 'Defining a New Feature' says: typedef impl::mean_accumulator< mpl::_1 > impl; I think it needs to say: typedef accumulators::impl::mean_accumulator< mpl::_1 > impl;

2 1

interest in properties library
by Daniel Oberhoff 19 Dec '08

19 Dec '08

Hi, I am thinking about submitting a library proposal and would like to query wether there is any interest in such a library and chance of success of such a proposal. The basic idea is to implement the possibility to decorate a class with named properties, such that given a pointer to an instance properties can be accessed by name rather than using set/get methods. Also the type of the instance should not need to be known at compile time, other than that it derives from a suitable base class describing the property mechanisms. There is a rough implementation existing and used in a product environment. Setting and getting is done using appropriate boost functions. Type resolution is done using RTTI (especially dynamic cast). Complex inheritance hierarchies are supported through virtual inheritance from the base class, such that several classes along the hierarchy can contribute property slots. CRTP and static initialization is used to register properties. Convenient setter/ getter function generators are provided as is a mechanism to access nested properties using dot notation. I would very much like to put this work into the community as I think it will only make it better, plus I want to give back to boost since it has been a lot of help to me and still is. Best Daniel Oberhoff Fraunhofer FIT Schloss Birlinghoven St. Augustin Germany

2 1