- Boost - lists.boost.org

[lambda] Diff with Boost.Phoenix (for lambdas)
by lcaminiti 02 May '11

02 May '11

Hello all, Recently I used both Boost.Lambda and Boost.Phoenix to implement lambda functions. Why does Boost have two libraries that implement lambda functions? In my (limited) experience, Boost.Phoenix is more powerful than Boost.Lambda (and it has comparable run-times even if it has larger compile-times) plus Boost.Phoenix can do much more than "just" lambdas. * Is there anything that Boost.Lambda can do more than Boost.Phoenix? * Is there any application domain where using Boost.Lambda makes more sense than using Boost.Phoenix? Thank you. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-lambda-Diff-with-Boost-Phoenix-for… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[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

Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
by Ivan Le Lann 30 Apr '11

30 Apr '11

----- "Joachim Faulhaber" <afojgo(a)googlemail.com> a écrit : > Hi Frédéric, list, (snip) > > To save you some time, I have inserted my proposal as column D into > the Wiki at > https://svn.boost.org/trac/boost/wiki/GuideLines/Naming/OperatorTraitNames > I like those names, except "has_negate". I would have kept "has_unary_minus", in line with proposed "has_unary_plus". I also wonder if "has_negate" could be mistaken for "!" by some people. Regards, Ivan

4 4

[naming] standard: bitwise operations in the new standard (20.8.7)
by Joachim Faulhaber 30 Apr '11

30 Apr '11

Dear list, this posting is addressed specifically to those people who are involved in the standardisation process for c++. As far as I know Beman, Howard, Dave, Doug, ... On occasion of the Boost.TypeTraits extension we were discussing names for operators and operator call traits. As an important aspect, naming consistency with the standard and across boost libraries has been discussed. We have found that functors on bitwise operators // 20.8.7, bitwise operations: template <class T> struct bit_and; template <class T> struct bit_or; template <class T> struct bit_xor; are new in the upcoming standard and are named using prefix bit_ In contrast to that, within boost, entities referring to bitwise operators are almost consistently named using prefix bitwise_ This is done specifically in Boost.Proto but also Boost.MPI (boost/mpi/operations.hpp). bitwise_and, bitwise_or, bitwise_xor are declared and used at 95 lines in Boost Libraries currently. Since 20.8.7, bitwise operations are *new* in the standard and naming consistency would be great for users, do you think there is a chance that those 3 names can be changed to bitwise_and, bitwise_or, bitwise_xor ? If so, is there anything that can be done to help the process. I'd volunteer to write a paper, if necessary. This might be a tiny issue, but since operators are at the core of any language, a consistent naming around them might be of great value on the long run. Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

4 4

[Review] Boost.Convert library last 3 days
by Edward Diener 30 Apr '11

30 Apr '11

This is a reminder that formal review of the Boost.Convert library by Vladimir Batov has 3 more days and ends on May 2. There have only been a small number of reviews and this is the last weekend to review the library. I am hoping that programmers who may have been busy during the week in their work will find time this weekend for a review. The review period ends on Monday at midnight, so please get your review in before the review period ends. If you intend to do a review of the library but feel you would be late in doing so, please contact me about it. *************** * 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 * ******************* You can get the library, using Subversion, from https://svn.boost.org/svn/boost/sandbox/convert. 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

1 0

Re: [boost] boost] BoostLog: how to write log files into different folders named under Year/Month/Day
by edger 30 Apr '11

30 Apr '11

I have no experience with Boost.Log. But it seems the character "/" is reserved for the file system, thus not acceptable in file names. In you case, you are asking Boost,Log to creat 3 nested folders %Y, %m and %d, and then a file xxx_%N.log. Boost.Log may not support this as this function is supposed to be in Boost.Filesystem. HTH. 2011/4/29 <boost-request(a)lists.boost.org> > > Date: Fri, 29 Apr 2011 18:43:35 +1000 > From: Jinqiang Zhang <jasonzha(a)gmail.com> > Subject: [boost] BoostLog: how to write log files into different > folders named under Year/Month/Day > > e.g. like "%Y/%m/%d/xxx_%N.log" > > when I tried it, it created folder named %Y, ... but what I what is '2011' > instead. > > any idea ? > > Jinqiang >

1 0

[convert] Review
by Thomas Heller 29 Apr '11

29 Apr '11

Hi, Following is my review of the convert library proposed by Vladimir Batov. > - What is your evaluation of the design? I think the design is not good. After having read through the documentation, I think that the API is too convoluted. The use of operator>> feels misplaced. From the documentation it is not really clear what the relation between the target type, the nested result and the converter function object is. Additionally, the rational behind the non-throwing version isn't very clear to me. It feels like a step backwards: Weren't explicitly returned error codes obsoleted by exceptions? Moreover, I don't get how the design really is superior to boost::lexical_cast, and why it couldn't been implemented as an extension to that library. The use of this converter function object looks like a nice concept at first sight but, as mentioned above, in the end, probably adds more confusion and problems than anything else. I don't think that having everything hidden behind this static from function is wise and should be rethought. Different functions, for different purposes would be better suited. > - What is your evaluation of the implementation? Didn't take a look at the implementation. > - What is your evaluation of the documentation? The overall documentation is Okayish. There are some minor typos and misplaced words. Proofreading it again should fix this. What is std::u8string? The reference section feels like a bad joke. It is incomplete and doesn't really add value. After reading through the documentation I got the feeling that the library is incomplete and not really finished yet. Almost any feature is experimental. One feature is mentioned but not really documented: The extension of the converter. > - What is your evaluation of the potential usefulness of the library? There is no doubt that the features implemented in the library are useful. > - Did you try to use the library? With what compiler? Did you have any > problems? Didn't try to use it. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? Read through the documentation. > - Are you knowledgeable about the problem domain? No. > And finally: > Do you think the library should be accepted as a Boost library? No. I second that it feels more like a extension to boost::lexical_cast than anything else. Best regards, Thomas

2 4

[locale] Support of non US-ASCII character set for messages keys
by Artyom 29 Apr '11

29 Apr '11

Hello, After reviewing all the discussion I've decided to do following changes in the interface to provide better support for non-US-ASCII keys. The actual thing that convinced me is a requirement to be able to include chars like © into the text... Currently there are following classes: template<typename CharType> class message_format : public std::locale::facet { public: ... typedef CharType char_type; virtual char_type const *get(int domain_id,char const *context,char const *id) const = 0; ... }; class message { public: ... explicit message(char const *id); ... // convert message to localized message template<typename CharType> std::basic_string<CharType> str(std::locale const &locale) const; }; ... inline message translate(char const *id); inline std::string gettext(char const *id,std::locale const &loc=std::locale()); inline std::wstring wgettext(char const *id,std::locale const &loc=std::locale()); ... Basically message is created using narrow id only and can be converted to multiple output formats narrow, wide and so on. std::cout << translate("Hello") << std::endl std::wcout << translate("Hello") << std::endl; And you could call: message msg = translate("Hello"); std::string hello = msg.str<char>(); std::wstring whello = msg.str<wchar_t>(); Work together. I'll change it in following way: template<typename CharType> class message_format : public std::locale::facet { public: ... typedef CharType char_type; virtual char_type const *get(int domain_id,char_type const *context,char_type const *id) const = 0; ... }; template<typename CharType> class basic_message { public: typedef CharType char_type; typedef std::basic_string<char_type> string_type; ... explicit message(char_type const *id); ... // convert message to localized message string_type str(std::locale const &locale) const; }; typedef basic_message<char> message; typedef basic_message<wchar_t> wmessage; typedef basic_message<char16_t> u16message; typedef basic_message<char32_t> u32message; ... inline message translate(char const *id); inline wmessage translate(wchar_t const *id); inline std::string gettext(char const *id,std::locale const &loc=std::locale()); inline std::wstring wgettext(wchar_t const *id,std::locale const &loc=std::locale()); ... Now you would have to: std::cout << translate("Hello") << std::endl std::wcout << translate(L"Hello") << std::endl; And you should call: message msg = translate("Hello"); wmessage wmsg = translate(L"Hello"); std::string hello = msg.str(); std::wstring whello = msg.str(); Additionally you would be able to specify the encoding of the source strings when adding domain. boost::locale::generator gen; gen.add_messages_domain("myprogram","windows-936"); While the default would always be UTF-8. So if you write in the program: std::cout << translate("平和") << std::cout Under GCC using UTF-8 sources you have anythig to do. If you are using MSVC then you'll have to provide a charset name as shown above or use u8"平和" Of course this would break the API for users who currently use Boost.Locale (and I know at least several project who will suffer). But this would probably bring it so some logical point and prevent rising these questions. If course you should remember that untranslated non-US-ASCII strings would be converted in the run-time to current locale's encoding. Regards, Artyom Beilis P.S.: Of course the documentation will still discourage programmers from using non-US-ASCII keys as they may not be displayed properly in local character sets and may confuse users.

2 3

BoostLog: how to write log files into different folders named under Year/Month/Day
by Jinqiang Zhang 29 Apr '11

29 Apr '11

e.g. like "%Y/%m/%d/xxx_%N.log" when I tried it, it created folder named %Y, ... but what I what is '2011' instead. any idea ? Jinqiang

1 0