November 2008 - Boost - lists.preview.boost.org

[interprocess] A little gentle criticism
by Edward Diener 22 Nov '08

22 Nov '08

First of all I really appreciate the interprocess Boost library for its rich set of synchronization primitives and shared memory techniques. Now to my gentle ( maybe not so gentle ) criticism. What was the reason for using C-style null-terminated strings in much of the functionality rather than std::basic_string ? Isn't it about time, in the advanced C++ libraries of today, that we should wean ourselves aay from C-isms, which no C++ programmer, unles on pain of supporting hopelessly legacy style code, has not used in years and years ? To see constructors taking C-style strings rather than std::basic_string in a modern C++ library like interprocess is a real psychological disappointment. At the very, very least, the author of the library should have also provided the equivalent functionality with std::basic_string. Please Boost developers, C++ programmers deserve not to deal with C-style strings anymore. Personally I do not think anything new coming out of the C++, including the C++ standard committee, should have any functionality taking a 'const charType *' from now to to the end of C++ eternity <g>. Other than the above I really enjoy using interprocess and say bravo to the author of the library for a well thought out implementation. But how this C-ism got by the reviewers I will never know.

2 1

[unicode] Interest Check / Proof of Concept
by James Porter 22 Nov '08

22 Nov '08

Over the past few months, I've been tinkering with a Unicode string library. It's still *far* from finished, but it's far enough along that the overall structure is visible. I've seen a bunch of Unicode proposals for Boost come and go, so hopefully this one will address the most common needs people have. The library is based on two (immutable) string types: ct_string and rt_string. ct_strings are _C_ompile _T_ime tagged with a particular encoding, and rt_strings are _R_un _T_ime tagged with an encoding. This is to allow for faster conversion when the encoding is known at compile-time, but to allow for conversion at run-time (useful for reading XML!). General usage would look something like this: ct_string<ct::utf8> foo("Hello, world!"); ct_string<ct::utf16> bar; bar.encode(foo); rt_string baz; baz.encode(bar,rt::utf8); Note the use of ct::utf8 and rt::utf8. As you might expect from the syntax, ct::utf8 is a type, and rt::utf8 is an object. Broadly speaking, to create an encoding, you create a class with read and write methods, and then you create an instance of an rt_encoding<MyEncoding>. Most of this is laid out in the comments of my code, so I won't go into too much detail here. There's still a lot missing from the code (most notably, dynamically-sized strings and string concatenation), but here's a rundown of what *is* present: * Compile-time and run-time tagged strings * Re-encoding of strings based on compile-/run-time tags * Uses simple memory copying when source and dest encodings are the same * Forward iterators to step through code points in strings If you'd like to take a look at the code, it's available here: http://www.teamboxel.com/misc/unicode.tar.gz . I've tested it in gcc 4.3.2 and MSVC8, but most modern compilers should be able to handle it. Comments and criticisms are, of course, welcome. - Jim

11 20

[lambda][test] _set_se_translator() requires /EHa
by David Walthall 22 Nov '08

22 Nov '08

I was looking at one of the failures on vc 7.1 and noticed that there was the following warning: ..\boost\test\impl\execution_monitor.ipp(825) : warning C4535: calling _set_se_translator() requires /EHa the command line options /EHc and /GX are insufficient See: http://beta.boost.org/development/tests/release/developer/output/daw-msvc71… or: http://tinyurl.com/5osfqr Is this a spurious warning, or is really an issue? Thanks, David

3 3

Re: [boost] Breaking existing libraries
by Tomas Puverle 21 Nov '08

21 Nov '08

> I have no problem with any of that. However, I would like you to > acknowledge that I *did* in fact address what you wrote, whether or not > it was what you wanted to hear. I acknowledge that you addressed what I wrote. > I'm not sure how. Would the "new" code that results from reviews have > more immediate relevance to you than it does now, in such a scheme? Yes - that's the whole point! People are not afraid to beta test when they know the code is beta/pre-release. People will be more likely to review code and participate if they know they can use it in the near-term future. People who save themselves the effort of having to invent their own (probably inferior) version of a library from scratch will also be more likely tolerate changes in the early stages. At the end of the day, most of our users are library users, not library writers. They just want to get their app up and running. Increasing your pre-release user and test base can only make the library better and applicable to more domains. One of the best things for me when working in library development was learning how people use my libraries in scenarios I haven't even thought about. Also, more participation early in the development process will give the user base a stronger sense of ownership and hence more desire to be involved. I can't tell you how often people here ask for the new libraries, only to be shot down because they are only available from release X onwards, where X > where we are now. And when I say people ask for the new libraries, I do really mean ALMOST EVERY SINGLE library that came in since 1.33.1. > >> > However, it seems that once a library is accepted, the maintainer > is > >> > pretty much free to do what they please. > >> > >> Yes. > > > > I hope behind this simple "Yes" there are alarm bells going off. > > Not really. I understand the risks and tradeoffs of that arrangement, > and I think Boost made the right choices there. IMO what's needed is > more structure to support the maintainer in making good decisions. But you also need the maintainer to actively engage the system when deciding to make drastic changes. In the Boost.Range case, it wasn't the failure of the boost.devel mailing list. The changes seem to have been made without any communication whatsoever. > I know at least one instance where breaking changes were discussed > (handling of NTBS's): > http://www.nabble.com/-Range--Expected-complexity-constraints- > tt4279749.html#a4279749 And that's the right thing to do. However, I can't find any references to indicate that the behavior of ranges is about to change in 1.35. > Yes. And as as I said, such policies often are used for *all* > dependencies because people have been burnt by *something* that may or > may not have been Boost in the past. Sure - but most other libraries we use are not the basic building blocks of most C++ applications and our entire software stack! Almost every C++ app will have use for things such as Boost.SharedPtr and Boost.Iterators but they don't all need e.g. a rule based engine. As such, boost tends to be a global dependency while other libraries are much more localized. Breaking and backing out a single application because of a broken dependency is not a big deal. Backing out and rebuilding all of the applications in the firm is a big deal. > <snaps head around> What proposal? I don't know if you're just playing with words here or not. It wasn't a "proposal" in the sense of a written document which is suitable for submission to the C++ committee. I was referring to the idea of the different release cycles for the "core" and "new" components. Tom

1 0

Re: [boost] Breaking existing libraries
by Tomas Puverle 21 Nov '08

21 Nov '08

-----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of boost-request(a)lists.boost.org Sent: Thursday, November 20, 2008 5:42 PM To: boost(a)lists.boost.org Subject: Boost Digest, Vol 2373, Issue 4 > Yes, this is an unfortunate situation. If you indeed want to try to > make sure this kind of silent breakage doesn't happen again, there's > something you can do about it: write a page of library maintenance > guidelines on the wiki at http://svn.boost.org. We are sorely missing a > policy on this, and when less-experienced library authors come along, > they often don't hew to the same standards that many of us take for > granted. If you don't have write permission for the wiki, please let us > know and we'll send you an invitation. Hello Dave, This is a good answer but not the one I was looking for. It's a politician's answer, in that it doesn't really answer my original query. Let me just put a few of my thoughts here: What was described in my original email are bad practices in any project, not just boost. Given that the boost developers are presented frequently as "the best", it isn't unreasonable to expect that they would understand that causing silent breakage (and the other points I made) is bad. It takes a lot of work for a library to get accepted and the library has to meet very high standards. However, it seems that once a library is accepted, the maintainer is pretty much free to do what they please. I think it may be wise to apply the same level of rigour to the continued development. Do you think that a boost library that was broken should be rolled back? About the wiki: The desire to solve this problem has to come from within, not from without. Given how big some of the personalities are on this mailing list, do you think it's likely they would listen to someone who has not contributed a complete library to boost? Finally, I'd like to mention that within a large organisation, it's not possible to upgrade to the latest version of boost as soon as it comes out. The difficulty of rebuilding all of the internal systems just makes this impractical. As you are aware, a lot of people avoid the .0 releases. What does this say to you? I understand (and applaud) boost's efforts to try to to eliminate this notion with tighter release cycles etc but the problem is that it's much harder to lose people's confidence than to regain it. I like using boost and am very grateful to all the developers who make it happen. Having said that, SNAFUs such as the current Boost.Range or the MT problem with Boost.Function in 1.34 threaten to make it irrelevant in "serious" development and relegate it to the position of a great "toy library" you can see how C++ standard compliant your compiler is. Kind regards, Tom

2 3

[test] minor spelling problem in docs
by Thorsten Ottosen 21 Nov '08

21 Nov '08

Look at http://www.boost.org/doc/libs/1_37_0/libs/test/doc/html/tutorials/new-year-… It is full of BOOST_AUTO_EST_CASE( constructors_test ) ^^^^ -Thorsten

2 1

[test] test tools for ranges - where are they?
by Thorsten Ottosen 21 Nov '08

21 Nov '08

Hi G, I couldn't find these in trunk anywhere. I thought these where added long time ago. Am I looking the wrong place? Thanks -Thorsten

2 1

Re: [boost] Breaking existing libraries
by Tomas Puverle 21 Nov '08

21 Nov '08

> The key issue is: You did not pay for what you use. I am sorry to disagree but this will not solve anything. The fact is that we use other open source projects where we pay for support and the supporting organization still doesn't guarantee that nothing will break. The moment they tried, the other people would branch off the code. There has to be an agreement among the developers themselves and commitment to quality of implementation. >> The Good News (TM) is that you can pay for it now: People at >> boost-consulting can help you with your problem within a week or so >> (middleman fees to me, please ;-)). > I'll see if there's something we can do ;-) So can we pay you to roll back Boost.Range? ;) (This doesn't constitute an offer to buy or sell or do anything) >> But let us go back on the we-do-not-pay-for-it path: >> IMHO it is a severe error of your development process that you do not >> check your code with new versions of all compilers and all libraries on a >> *regular* basis. >I agree that testing needs to be made more regular and thorough. >However, IMO the universe of compilers and libraries is much too large >--- and in some cases, the software is too expensive --- for us to check >code with new versions of *all* compilers and *all* libraries. We need >to select a subset against which we'll test. Agreed. I think in general boost is very good at this and I feel developers are fairly happy to contribute back any changes to make boost work on a particular compiler. This issue is not about my code not compiling - my code compiles, it just does something completely different. No amount of compiler testing will show up this bug. As a potential middle-road (and given the size of boost now), one possible way forward would be to break up boost into a "stable" and "new" branches. Our developers frequently want to use some new library from boost. Unfortunately, since boost is always rolled out as a big package, this is not possible because as I've mentioned before, doing an entire re-release of all internal libraries built on new boost is non-trivial, along with the fear that some major component (such as boost::function) was been broken. However, if there was a "stable" boost platform to which we could add new libraries without worrying about breakage/incompatibility, we would be far more likely to bring in new libs. In return, boost would get additional testers, not to mention that I think some of the preconceptions about instability would be alleviated. Furthermore, it may become unnecessary to have frequent point releases, as people could just get "stable" and then a "latest tested" snapshot of the libraries they need or of the "new" branch. It would be necessary to decide what "new" and "stable" means; I'm sure the core could be decided fairly easily (and the fringes will be argued forever). Then what is needed is a policy on how a component becomes "stable" as opposed to "new" (e.g. 1/2 years in production). All changes to "stable" have to go through a review and cannot be brought in a single release - they must be deprecated and a migration path provided. I'm not saying this is easy. Just a few thoughts I'm having. Tom

2 1

tweaking the review process (was: signals2 review results)
by Stjepan Rajko 21 Nov '08

21 Nov '08

On Fri, Nov 21, 2008 at 2:06 AM, Robert Jones <robertgbjones(a)gmail.com> wrote: > On Fri, Nov 21, 2008 at 6:40 AM, vicente.botet <vicente.botet(a)wanadoo.fr> > wrote: >> >> * 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. >> > > A specific maillist for reviews strikes me as an excellent idea. In Joels' > review > of his Phoenix 2.0 library there were some outstanding contributions from > people I don't see posting very often, but who apparently feel moved to do > important stuff like reviewing. These comments did much to give me some > historical context, and understanding of structure, alternatives and > implementation > decisions. These will inevitably be lost in the general background noise of > on going developments, and it would be nice to have a clear place for these > review comments. > Perhaps it would be sufficient to *strongly stress* that any post related to the ongoing review should have [review] in the subject line? (although that doesn't address the problem of having the review on both the dev and user lists...) Stjepan

1 0

Re: [boost] Breaking existing libraries
by Tomas Puverle 21 Nov '08

21 Nov '08

Hey Stephen, This is a extremely well written and reasoned post and I can't help but I agree with every point you made. > As for breaking existing use cases, this will cause us to stay at the > last release that meets our needs until the beginning of a new major > release cycle on our side, unless there's some other feature that > compels us to deal with the breaking change mid-cycle. In my previous position, I worked in the firm's infrastructure group, where we wrote and maintained libraries that were the "standard library" of the firm on which other apps/libraries were built. Given the size of the user base (in the thousands), it is simply unthinkable to rebuild the world because of a new release of boost. The current version is 1.33.1 and that's unlikely to change for a while. Finding debilitating bugs/changes in a new release makes people even less likely to want to move. This is bad for boost, too, as you lose not only direct boost users/testers, but also the feedback that developers send back to their compiler/standard library vendors. > Open-source status gives you champions in the development pit > but it doesn't change management's priorities. Nor should it make one forget that even though grateful for your efforts, there's only as much pain as people are willing to go through. Tom

1 0