April 2011 - Boost - lists.preview.boost.org

[config] Macro BOOST_NO_NOEXCEPT is required
by Takaya Saito (SubaruG) 05 May '11

05 May '11

http://thread.gmane.org/gmane.comp.lib.boost.devel/214978 I think the macro BOOST_NO_NOEXCEPT ( or BOOST_NO_0X_NOEXCEPT ) is required soon. How's the status now?

5 7

[Block Pointer] make_block
by Phil Bouchard 04 May '11

04 May '11

Hi, I just disabled the constructor and the assignment operator having a raw pointers as a parameter and I added the make_block factory function. We can see it in action in the following example: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/bl… Is it time for a review? -Phil

7 23

[atomic] Status?
by vicente.botet 04 May '11

04 May '11

Hi, There are some libraries that would prefer to be reviewed after Boost.Atomic is reviewed, otherwise them should move the library as an internal detail of the implementation. Could the people working on Boost.Atomic tell us what is the state of the library? Which platforms have been handled? Which part of the standard has been implemented? Could others having knowledge in assembler participate in this project? When we can expect the library to be ready for review? Best, Vicente

10 20

[Review] Boost.Convert library, new subversion URL
by Edward Diener 03 May '11

03 May '11

This is a reminder that formal review of the Boost.Convert library by Vladimir Batov starts today, April 23, and is scheduled to last through May 2. *************** * Its Purpose * *************** The library builds on the past boost::lexical_cast experience, then takes those conversion-related ideas further to suit better today's applications and programing needs. It still offers simple, minimal interface, familiar conversion behavior and additionally provides: * throwing and non-throwing conversion-failure behavior; * support for the default/fallback value to be returned when conversion fails; * two types of the conversion-failure check - basic/simple and better/safe; * formatting support based on the standard std::streams and std::stream-based manipulators (like std::hex, std::scientific, etc.); * support for different locales; * support for boost::range-compliant char and wchar_t-based containers; * no DefaultConstructibility requirement for the Target/Destination type; * consistent framework to uniformly incorporate any type-to-type conversions, extensibility and additional room to grow. With its present support for string-to-type and type-to-string conversions it is an essential tool for applications making extensive use of configuration or MS-Windows-Registry-style files or having to process/prepare considerable amounts of data in, say, XML, etc. More so, it is easily extendable to accommodate, specialize and uniformly deploy new user-defined type-to-type conversions. ******************* * Where to get it * ******************* Normally you can find Boost.Convert here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… However because the boostpro web site is having problems and will likely be down for the weekend, I have put the library into the Boost sandbox temporarily, since the Boost sandbox is up. So you can get the library, using Subversion, from https://svn.boost.org/svn/boost/sandbox/convert. This is exactly the same as the vault with the files unzipped. The HTML documentation is part of the distribution and can be found at libs/convert/index.html in the distribution above. ******************** * Writing a review * ******************** The reviews and all comments should be submitted to the developers list, and the email should have "[convert] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - 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? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Edward Diener, Review Manager

12 19

Checking interest: reflectable types
by Noah Roberts 03 May '11

03 May '11

In my work I've developed a sort of reflection library for C++. There are still many problems to solve before it could near real reflection but I don't believe they are insoluble. It works much like fusion maps except that you can extend them through inheritance. In fact, my current implementation uses fusion to do its thing and with some minor changes to fusion::map it could provide the base. There is a boost.reflection proposal out there that is meant to work with boost.extension. This one is a bit different in that you're not additionally defining data; instead you declare your reflection as you declare your reflectable type through the instantiation of and inheritance from template metafunctions. It's primarily a static/compile-time kind of reflection but can be extended into runtime simply by making your field types a little smarter. Fields describe the data and provide access identifiers. Since they are general types that simply have to have an internal typedef you can attach whatever information is useful. We've done such things as attach valid value ranges, labels, etc... I currently use it do auto-construct property trees for user editing. I plan to use it for scripting/extension. I've had a look at boost.python and it looks like it would be possible, without too much difficulty, to automate python exposure of these types. A coworker with 0 experience in metaprogramming found it fairly easy to feed the types into a structure meant for a report design and printing library. This isn't a promise to actually do anything. I'm just gauging how much, if any interest there is to decide if I want to go to the trouble of hobby developing a publicly available and usable version.

4 11

[website] Suggestions
by Stephan T. Lavavej 02 May '11

02 May '11

It would be wonderful if: 1. On the main page, there was a direct link to the current version's documentation. Currently, you have to click Documentation, then "1.46.1 - Current Release". (Actually, I just noticed that a direct link does exist - Libraries under Welcome. I was hoping for a big blue button saying GET DOCS.) 2. There was a terse list of links to each library's documentation. The master list currently mentions 6 additional pieces of information for each library (Summary, Authors, First Release, Standard, Build, and Categories). That's nice, but it makes finding library X's documentation significantly more tedious than it has to be (I count 105 libraries in 1.46.1 - that's a lot of scrolling!). I suspect that even beginners don't need information other than the Summary 99% of the time. The current info should be preserved somewhere, but clicking on a release's documentation should bring up a terse list first. http://cid-e66e02dc83efb165.office.live.com/self.aspx/docs/boost.html is a horribly ugly preview of what I'm suggesting (because some libraries have long summaries, I've arbitrarily truncated them; ideally, each library would have a single-line summary at reasonable browser widths). 3. http://boost.org didn't redirect to http://www.boost.org . Even better, if the reverse happened ("Class B", according to http://no-www.org/faq.php ). Clearly, this is the most important issue of all. :-> Stephan T. Lavavej Visual C++ Libraries Developer

5 4

[locale] Review results for Boost.Locale library
by Chad Nelson 02 May '11

02 May '11

The formal review of Artyom Beilis' Boost.Locale library, originally scheduled to run from April 7th through the 16th and extended through the 22nd, is now finished. Fifteen people cast votes on it, ten for acceptance and five against. Though not overwhelming, the two-to-one majority clearly indicates the consensus of the list. As such: The Boost.Locale library IS ACCEPTED into Boost. The details follow, starting with the voters in favor, in the order their reviews were received: * John Bytheway * Steven Watanabe * Sebastian Redl * Fabio Fracassi ("possibly conditional") * Noah Roberts * Steve Bush * Volker Lukas * Paul A. Bristow * Matus Chochlik * Gevorg Voskanyan Those opposed: * Ryou Ezoe * Phil Endecott (but "borderline") * Edward Diener * Mathias Gaunard * Vincente BOTET ("count my vote as 1/2 or 1/4 vote") There was also an early off-list review from Darren Cook which did not include a vote, only listing issues. There was a great deal of discussion around the library, and a number of issues detailed. The major ones (and some less major ones that were repeated by several reviewers) are summarized below, along with the initials of the reviewer(s) who brought them up and Artyom's responses. Note that although I followed the discussions closely, these are only the issues brought up in the formal reviews themselves. * Issue: date_time interface uses enums for periods, which is error prone and inconsistent with other date/time libraries. (JB) * Response: Will be addressed. * Issue: Reference documentation needs more detail or some things not clear; some terms used in the documentation are not defined or are defined too briefly; can't find headers that items are defined in from the documentation. (JB, SW, FF, PE, ED, MC) * Response: Will be addressed. * Issue: There are no prev/next links in the documentation, or tutorial can't easily be navigated. (DC, JB, SR, FF, MC) * Response: Looking into it. * Issue: Few examples include output. (JB) * Response: Will be addressed. * Issue: No examples in Asian languages; the library may have design flaws that are not apparent without them. (DC) * Response: [Artyom has indicated to me (privately) that he's adding such examples. -- CN] * Issue: The translation system requires narrow-character tags, making it English-centric. (RE, ED) * Response: The library implements the most popular and most widely used message-catalog format. It is not perfect, but it is the best system currently available. There may be a work-around if you really must use wide-character languages under Windows. * Issue: Support for wchar_t/UTF-16 is unclear. (RE, ED) * Response: Wide characters are fully supported. * Issue: Doesn't support Win32 API as a backend. (RE) * Response: Misunderstanding, Win32 API backend is fully supported. * Issue: boost::locale::format is not compatible with boost::format. (FF, NR) * Response: boost::format is too limited for use in localization, and throws on any error, which means that a translator error could crash the program. * Issue: boost::locale::date_time is not compatible with boost::date_time. (FF) * Response: An unavoidable consequence of the differences between them, which are necessary due to support for locale independence and non-Gregorian calendars. * Issue: Boundary analysis is only available when using ICU. (FF) * Response: At present, only the ICU backend supports proper boundary analysis. * Issue: Little documentation on the toolchain needed to extract strings and translate them, or the versions required. (FF, NR) * Response: Will be addressed. * Issue: Concerns about relying on GPL/LGPL-licensed tools, or their availability on all platforms, or recommendations to write a Boost version of these tools. (NR) * Response: Reimplementing these is non-trivial and unnecessary; the licensing for these tools does not affect the programs developed with them. All are available for all platforms; will add explicit instructions for getting the latest versions for Windows. * Issue: Use of strings instead of symbols for language and encoding makes run-time errors that could be compile-time errors. The most common ones should be symbols. (PE) * Response: There are dozens of character encodings, and even more locales, and no way to determine which ones are the most common. Not all encodings are supported by all backends or OS configurations. Names ignore case and non-alphanumeric characters, which should minimize errors that could be generated from them. utf_to_utf transcoding will be added. * Issue: Error handling (in conversions) is very basic. (PE) * Response: An unavoidable limitation of the backends. * Issue: Code could use more commenting. (PE, VL) * Response: Noted, will be addressed in the future. * Issue: Some documentation phrasing is confusing, or could use a native English speaker's input. (SR, VL) * Response: Will be addressed as discovered. * Issue: There are no lists of valid language, country, encoding, or variant strings. (ED) * Response: Listed in standards ISO-639 and ISO-3166, which are referenced in the library's documentation. These standards are updated occasionally, and should be referred to directly for the latest information. * Issue: Only works on contiguous, entirely-in-memory strings. (MG) * Response: All current backends require this, and it satisfies the vast majority of use-cases. * Issue: Boundary analysis goes through the entire string and returns a vector of positions. (MG) * Response: Not perfect, but given the limitations of the existing backends, it is reasonable. * Issue: The library's interface is not generic enough, or independent enough of the libraries that it wraps. (VB) * Response: The interface is similar to that of every other i18n library, and should make as few assumptions as possible. It should not be changed. * Issue: The date-time code should be merged into Boost.DateTime. (VB) * Response: Date-time code is locale-dependent by its nature, and is more natural in Boost.Locale. Updating Boost.DateTime to do everything that Boost.Locale's library does would require a lot of work, and in all the time it has existed, only the Gregorian calendar has been implemented. There are Boost libraries that overlap others, so this is not a novelty. -- Chad Nelson Oak Circle Software, Inc. * * *

18 71

[BOOST CORE C++ Feature] The super or base keyword for C++
by Max Hölzer 02 May '11

02 May '11

Hello, i was wondering if it makes sens to add the well known super or base keyword to the C++ language in a generic way. Here I have a simple example on how it would make inherited base or super class overloaded function calls easier. Example 1: class A { public: virtual void print() { std::cout << "A" << std::endl; } }; class B : public A { public: virtual void print() { std::cout << "B" << std::endl; std::cout << "super call "; A::print(); } }; class C : public B { public: virtual void print() { std::cout << "C" << std::endl; std::cout << "super call "; B::print(); } }; int main(int argc, char* argv[]) { A a; B b; C c; a.print(); // Prints A b.print(); // Prints B and super call A c.print(); // Prints C and super call B super call A return 0; } Adding a template class superable would avoid one to write the explicit base or super class name. Example 2: namespace boost { template<typename T> class superable : public T { public: typedef T super; // C++ and java style typedef T base; // C# style }; } class A { public: virtual void print() { std::cout << "A" << std::endl; } }; class B : boost::superable<A> { public: virtual void print() { std::cout << "B" << std::endl; std::cout << "super call "; super::print(); // C++ and java style call } }; class C : boost::superable<B> { public: virtual void print() { std::cout << "C" << std::endl; std::cout << "super call "; base::print(); // C# style call } }; int main(int argc, char* argv[]) { A a; B b; C c; a.print(); // Prints A b.print(); // Prints B and super call A c.print(); // Prints C and super call B super call A return 0; } If somebody could add this to the core boost library, that would be great. Sincerely yours, Max

2 1

[filesystem] Decomposition of filenames beginning with period?
by Beman Dawes 01 May '11

01 May '11

Boost.Filesystem class path views filenames as being made up of a stem and an extension. My Windows Users directory includes files ".gitconfig" and ".netrc". The current class path implementation views these as having extensions of ".gitconfig" and ".netrc", respectively, and empty stems. To me, that's a bit counter intuitive. I guess I view filenames as always having stems, but extensions being optional. But I don't view that as a strong enough argument to change anything. Does anyone have a stronger argument than intuition for changing or retaining the current behavior? --Beman

13 20

Re : [Block Pointer] make_block
by Pierre Morcello 01 May '11

01 May '11

Hi Phil, >>> Phil Bouchard <philippe(a)fornux.com> wrote : >>> We can see it in action >>> in the following example: >>> https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/bl… A detail : I think you could improve your sample by replacing __FUNCTION__ by BOOST_CURRENT_FUNCTION (which is more portable), or by writing directly the name of the function. >>>Is it time for a review? I looked for automated tests in the sandbox directory (not examples) and I did not find any. Instead of doing "cout", you could use a class like that : class ForTests { static int counter; // incremented at each construction int id; // id = current value of the counter in the constructor static std::vector<int> destructionOrder; }; Each destruction pushes the id in the destructionOrder vector. Then at the end of the program you just need to compare the content of destructionOrder with what you should expect (and return 1 or 0). Also the same might be done for construction. Good job BTW, and good luck for the review, Pierre Morcello

2 4