- Boost - lists.boost.org

Re: [boost] [Boost-users] Maintenace Guidelines wiki page
by vicente.botet 23 Nov '08

23 Nov '08

----- Original Message ----- From: "Robert Ramey" <ramey(a)rrsd.com> To: <boost-users(a)lists.boost.org> Cc: <boost(a)lists.boost.org> Sent: Saturday, November 22, 2008 9:19 PM Subject: Re: [Boost-users] Maintenace Guidelines wiki page > > This is a laudable effort, Thanks. > but my guess is that it's doomed to failure. > > My own take on this was posted in > http://lists.boost.org/Archives/boost/2008/07/139893.php I remember your participation and your point of view on this long thread. > So far, no one else has endorsed such a pledge. Indeed, the responses > suggested that > the breaking interfaces was a normal, acceptable and unavoidable practice. I don't think this is the case. Breaking changes should be exceptional and taken because there is no better solution. I think that most of the Boost authors respect that. As every rule this one has its exceptions, there has been some library evolution that have break user and even Boost library code. This is regretable and we need to setup whatever is needed to make this exceptions more than exceptional. I really think that *we can* achieve this goal. > I think that differing points of view reflect different backgrounds of > different > developers. In my particular case, I work on relatively short term projects > under huge pressure to produce results. I absolutely depend upon boost > and other libraries (e.g. MFC) to get the job done. If a library changes, > then > I have to go back and re-visit something that was already considered > "finished". > The creates a big problem for me. I understand your concern. > In other environments, programmers work on huge projects which might > go on for years. In this constext, this is not such a huge problem as > things > are constantly evolving anyway. So continuing to break things and > having to fix them is a normal and in any event unavoidable. Even in this case breaking code is a inacceptable because there is a lot of code to modify and test. So if we want that the Boost library is used widely we need to *try* to provide backward compatible versions, and warm when this is no more possible. In my personal work, we use to do provide some scripts that either they are able to automaticaly do the complete transformation or they warm when automatic transformation is not possible. Usualy this let 20% of the code to be transformed manually. > Your "Maintainence Guidlines" presume a consensus > about what should be acceptable practice where no > such consensus actually exists. Which acceptable practice are you referring to for which there is no consensus? > As a practical matter what do I do. > > I need a facility. My experience would suggest that such > a facility might be already existing in some sort of library. > According to the situation, I will review a couple of candidates > and select one to try. It might be a commercial product or > it might be something like boost. Then I'll try to introduce > the library to my code. This has to be pretty easy or I'll discard it. > It needs to have good documentation and it needs to "just work" > I then copy the library in to my project. I try to avoid making > a big commitment to a library - or anyone else's code so > that I can drop one library if I have to in the future. > > With the serialization library, it has to include the latest > boost libraries that it uses. If I find that the library > author can't maintain a stable and relieable product, > I design that library out of the serialization library. This > has happened several times. Given the fact that > the serialization library is not my full time job > (though at times it seems that way), I don't feel > there is any real alternative. I hope that you are not proposing that to the end users. Are you? Please could you participate in the elaboration of this guidelines, your opinion is very important to the Boost community. Thanks, Vicente

2 2

[interprocess] A little gentle criticism
by Tom Brinkman 22 Nov '08

22 Nov '08

>> Please Boost developers, C++ programmers deserve not to deal with C-style strings anymore. With all respect, this is not a view that I share. I'm a c++ developer who prefers C-style strings. Most of the coding standards on C++ projects that I have been on over the last 10 years or so have discouraged using C++ string wrappers. This hasn't changed recently from what I can see. I rarely if ever use std::string or std::basic_string. Many C++ developers still prefer C style string handeling. Tom

2 1

Maintenace Guidelines wiki page
by vicente.botet 22 Nov '08

22 Nov '08

Hi, I have started the Maintenace Guidelines wiki page. You can access it directly https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines or via https://svn.boost.org/trac/boost/wiki Guidelines * Maintenance Guidelines There page need to be completed and surely reworked but this is an starting point. Please be free to improve the page directly or post your comments or suggestions to this list. Hopping this goes on the right direction, Vicente

1 0

[quickbook] Problem integrating doxygen style examples into quickbook
by Joachim Faulhaber 22 Nov '08

22 Nov '08

Hello, I successfully installed the quickbook toolchain and I am joyfully using the tool to write docs for my library. (Thank you, to the authors:-) One of the things I like is the doxygen integration. But I have encountered a problem here: I guess my problem is a typical one that other authors might share. I already have example files that are using doxygen style documentation. The documenting texts are in the example file so it's easy to maintain: ----------- boost_party.cpp --------------------- /** Example boost_party.cpp \file boost_party.cpp Text documenting this example using <em>doxygen</em> style formatting features. ... Finally there is an include command that allows to insert the example code to this introductory text: \include boost_party/boost_party.cpp */ #include <boost/.../some.hpp> class to_be_documented { ... } ... //more code -------------------------------------------------- Now I would like to recycle text and code for quickbook such that (1) Text and code can stay in the example file. (2) Text and code don't have to be replicated some place else (e.g. in example.qbk). (3) There is only a minimal additional formatting noise, so the example file itself stays readable. What I've learned so far is to bring the code (or snipplet parts of it) into quickbook: ... //[example_boost_party #include <boost/.../some.hpp> class to_be_documented { ... } ... //more code //] But how to handle the text part? Cheers Joachim

1 0

[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