- Boost - lists.boost.org

Filename length limit for Boost library
by Edward Diener 28 Feb '11

28 Feb '11

In the "Boost Library Requirements and Guidelines Page" in the "Directory Structure and Filenames" topic, it says: 'The maximum length of directory and file names is 31 characters.' and the rationale is: 'We had to draw the line somewhere, and so the limit imposed by a now obsolete Apple file system was chosen years ago. It still seems a reasonable limit to aid human comprehension.' I do not think that there are any real OSs that impose such a limit anymore and would like to see this limit lifted. I have already hit this limit many times, especially in naming test files for my sandbox libraries. I would rather create filenames which described well what a file is about rather than have a 31 character limit for a filename, which is not only highly arbitrary, but almost certainly obsolete in this day and age.

2 2

Rave for proposed Boost.Local (functions)
by Gregory Crosswhite 27 Feb '11

27 Feb '11

Hey everyone, The purpose of this e-mail is to rave about Lorenzo's proposed Boost.Local library in the hopes of inspiring people to start the review process for it. :-) I have been experimenting with using this library in my own code, and it has been a godsend for me. In one of the projects I have been working on I ran into many situations where I needed to call a higher-order function with a closure, and the closure was just complicated enough that I couldn't use Boost.Lambda. Before using this library I frequently found myself either writing a lot of extra code to work-around the need for a higher-order function, or writing a lot of boilerplate to create classes that would only be used by a single function in order to create a function object. This library has let me write the closures that I need in a fairly painless fashion and so has made my life a lot easier! At first I thought that the interface needed to use it was ugly, but as I have gotten used to it I have changed my mind. Part of why I thought it was ugly was because of the way that whitespace was used in the example included in the original e-mail: BOOST_LOCAL_FUNCTION( (void) (add)( (double)(num) (const bind)((factor)) (bind)((&sum)) ) ) { sum += factor * num; std::clog<< "Summed: "<< sum<< std::endl; } BOOST_LOCAL_FUNCTION_END(add) add(100.0); To my mind this example looks a lot clearer if you reformat it as follows: BOOST_LOCAL_FUNCTION( (void) (add)( (double)(num) (const bind)((factor)) (bind)((&sum)) ) ) { sum += factor * num; std::clog<< "Summed: "<< sum<< std::endl; } BOOST_LOCAL_FUNCTION_END(add) add(100.0); I would be happy to volunteer to be the review manager if one is needed to move the process along, but since I am new to the community and personally biased in favor of the library (though I would endeavor to be unbiased as a reviewer) I recognize you all will presumably want someone that you all know better and who is more neutral. Regardless, I hope that we can start down the road of incorporating this library into boost because I believe it would be of great benefit to the C++ community at large. Cheers, Greg

13 59

Boost release 1.46.0 available
by Beman Dawes 27 Feb '11

27 Feb '11

Release 1.46.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release includes 1 new library (Interval Container Library) as well as updates to many existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_46_0 The release can also be downloaded directly from SourceForge. See http://sourceforge.net/projects/boost/files/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team

8 14

[Phoenix V3] for_each name conflict
by Mathieu - 27 Feb '11

27 Feb '11

Hi everyone, While reviewing phoenix V3 I encountered a bug while using mpl::for_each with a phoenix lambda, because of a name conflict (lazy phoenix for_each with mpl::for_each). The following code reproduces the bug : #include <boost/mpl/for_each.hpp> #include <boost/mpl/vector_c.hpp> #include <boost/phoenix/phoenix.hpp> #include <iostream> using boost::phoenix::arg_names::arg1; int main(int argc, const char *argv[]) { typedef boost::mpl::vector_c<int,0,1,2,3> vec; boost::mpl::for_each<vec>(std::cout << arg1); return 0; } which fails to compile with the error : In file included from main.cpp:1: dev/phoenix3/boost/phoenix/stl/algorithm/iteration.hpp: In function ‘void boost::mpl::for_each <snip irrelevant long mpl / phoenix types> main.cpp:25: instantiated from here dev/phoenix3/boost/phoenix/stl/algorithm/iteration.hpp:91: error: ‘boost::phoenix::for_each’ is not a function, /usr/include/boost/mpl/for_each.hpp:109: error: conflict with ‘template<class Sequence, class F> void boost::mpl::for_each(F, Sequence*)’ /usr/include/boost/mpl/for_each.hpp:111: error: in call to ‘for_each’ The mpl code does an unqualified call to for_each here : void for_each(F f, Sequence* = 0) { for_each<Sequence, identity<> >(f); // this is line 111 } and phoenix provides : function<impl::for_each> const for_each = impl::for_each(); The (silly) change to mpl::for_each<Sequence, identity<> >(f); obviously unbreak the build. The problem seems to be that ADL kicks in and as f (in the mpl call of for_each) is a phoenix type. I don't have a patch (yet) as I don't really know the best strategy here, nor I'm sure that my diagnostic is accurate (the ADL part that is). Mathieu- :wq

3 3

[functional] [shared_ptr] boost::hash<shared_ptr<T>> Returns Only Two Values
by Stewart, Robert 27 Feb '11

27 Feb '11

The following is a program that demonstrates that a null shared_ptr<int> produces a hash value of zero and that (ostensibly) all non-null instances produce a hash value of one. I expected that there'd be a shared_ptr specialization of hash_value to make it work right, but I don't find one. Shouldn't there be one? #include <iostream> #include <map> #include <vector> #include <boost/shared_ptr.hpp> #include <boost/functional/hash.hpp> int main() { typedef boost::shared_ptr<int> ptr_type; typedef std::map<std::size_t, int> hashes_type; std::vector<ptr_type> v(25); hashes_type hashes; boost::hash<ptr_type> hasher; ptr_type null_ptr; ++hashes[hasher(null_ptr)]; for (int i(0); i < 25; ++i) { v[i] = ptr_type(new int(i)); std::size_t const hash(hasher(v[i])); ++hashes[hash]; } for (hashes_type::iterator it(hashes.begin()), end(hashes.end()); it != end; ++it) { std::cout << it->first << ": " << it->second << '\n'; } } _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 7

[typeof] GCC error: expression not defined in this scope
by Lorenzo Caminiti 27 Feb '11

27 Feb '11

On Mon, Feb 7, 2011 at 5:29 PM, Steven Watanabe <watanabesj(a)gmail.com> wrote: > On 2/7/2011 1:52 PM, Lorenzo Caminiti wrote: >> >> void *result_ptr; // Plus append __LINE__... >> typedef typeof(*result_ptr) result_type; > > That's almost what we did. > > void deduce_result(); > typedef boost::function_traits< > typeof(&deduce_result)>::result_type result_type; > > is a little better. (It can handle references.) Hello all, Why the following TYPEOF code does not compile on GCC but it does on MSVC? Is this a GCC bug? If so, is there a workaround for it? #include <boost/typeof/typeof.hpp> int f() { return -1; } template<typename T> void g(T x) { int (deduce_func)(); typedef BOOST_TYPEOF_TPL(deduce_func) func_type; // error also if TYPEOF is used instead of TYPEOF_TPL struct s { void call(func_type func) { func(); } // line 12 } ss; ss.call(f); // line 14 } int main() { g(1); // line 18 return 0; } $ g++ -Wall -Werror -I../../.. r03.cpp r03.cpp: In member function ‘void g(T)::s::call(__typeof__ (boost::type_of::ensure_obj(deduce_func))) [with T = int]’: r03.cpp:14: instantiated from ‘void g(T) [with T = int]’ r03.cpp:18: instantiated from here r03.cpp:12: error: ‘deduce_func’ was not declared in this scope What is this error? I don't understand it because with the local struct at line 12 I am just accessing the type generated by the typedef and not the actual expression that was used to deduce such a type... $ g++ --version g++ (GCC) 4.3.4 20090804 (release) 1 The same error raises even also if TYPEOF is used instead of TYPEOF_TPL. However, no error if g() is not a template so GCC compiles this just fine: #include <boost/typeof/typeof.hpp> int f() { return -1; } void g(int x) { // no template, no error -- why? int (deduce_func)(); typedef BOOST_TYPEOF(deduce_func) func_type; struct s { void call(func_type func) { func(); } } ss; ss.call(f); } int main() { g(1); return 0; } Both examples (template and not) compile instead just fine on MSVC. Do these examples compile on compilers other than GCC and MVSC? Thank you very much! -- Lorenzo

2 2

[function] Merge to release
by Daniel James 27 Feb '11

27 Feb '11

Function hasn't been merged to release for some time. There are a number of fixes on trunk which look okay to me. If no one objects I'll merge once the release branch opens. Daniel

1 0

[phoenix 3] Missing file?
by Michael Caisse 27 Feb '11

27 Feb '11

Tests are complaining about : include/core/mem_obj_ptr.cpp:1:46: error: boost/phoenix/core/mem_obj_ptr.hpp: No such file or directory michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

Phoenix v3 review
by Mathias Gaunard 26 Feb '11

26 Feb '11

Here is my review of Phoenix v3. First, let me say that I am a big user of Phoenix v2, Spirit and Proto, and that I therefore envision myself a big user of Phoenix v3 as well. It is a great improvement on top of Phoenix v2 (in particular, no strange bugs due to broken type deduction and correct usage of result_of), and for that reason alone it warrants my approval. So here it is: I vote yes for inclusion. I however have concerns about its compatibility with Phoenix v2. I tried to see how Spirit fared if I symlinked its underlying phoenix directory to that of Phoenix v3, and it just doesn't work. Mixing Phoenix v3 with Spirit doesn't work either. I believe this is a very important issue. I'm not sure it needs to be fixed before the first release of Phoenix as a first-class Boost citizen, but it certainly needs to be fixed ASAP by porting Spirit to use the new version. Apart from that, the library is pretty satisfying: - As I said, usage of result_of has been a great improvement, and bind for example is now polymorphic and fully compatible with boost/std::bind. - it supports perfect forwarding up to a limit - It uses Proto in a minimalistic and modular way - It is reasonably fast to compile, thanks to the instrumentation of wave to preprocess headers. Compiling the STL module could be made faster by using free functions instead of global objects (which should be the recommended way to define lazy functions!). - The docs haven't changed much, a few rectifications here and there plus the addition of the new internals. It still contains typos and some things that need to be updated. Let's start on with more detailed remarks: Misc ---- Phoenix v3 is missing a phoenix.hpp header file that includes all modules, which Phoenix v2 had (but in the parent directory). Lazy functions -------------- Using phoenix::function to turn a PFO into a lazy function is the most basic way to extend Phoenix with new functionality, and clearly the recommended way to do so according to the docs. [1] [2] It is directly inherited from Phoenix v2, and only the result type deduction mechanism changed. This approach has several problems, at least in the way it is presented in the documentation. - global objects potentially increase binary size - those objects are not PODs and therefore requires runtime initialization, adding some runtime overhead at application startup - instantiation happens regardless of whether the function is used or not, which affects compilation time negatively. This method is massively used to define a whole lot of lazy functions that forward to standard algorithms and container functions [3], which suggests that this is indeed the recommended way to proceed. It should however be avoided; prefer defining a template function that constructs and applies the adapted function object, if the function object can stay a POD that's better too. I think it would also be valuable to add a "lazy" function (or some other name) that takes a PFO and returns its lazy version, that could be used inline in lambda expressions in a way similar to bind. [1] <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> [2] <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> [3] <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> Phoenix as a Proto-based library -------------------------------- Extension of Phoenix is very nice: you can plug custom subgrammars and subnodes non-intrusively, making it very modular. Phoenix expressions are also refinements of Proto expressions, so I can use Proto transforms to alter the tree. It is also possible to specify custom evaluation strategies on a per-node basis, which paves the way for many exotic applications. Terminals can also be customized for evaluation within the default strategy. I'm not entirely sure this feature is not redundant, but I'm not familiar enough with the code to tell. Phoenix as Proto with statements -------------------------------- One thing I was hoping Phoenix v3 would be is Proto extended to support statements. While it comes pretty for some uses, it still fails one one point: the ability to define custom languages that embed Phoenix statements. The missing piece is handling of domains (extends are missing too, but I don't think they make sense at the statement level). I think that area needs some research though, so it's not relevant to acceptance at all. Documentation ------------- <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> says that bind is monomorphic. I thought it was polymorphic now? <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> doesn't talk about perfect forwarding. <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> Actor cannot be both a concept and a model, it's a concept and a refinement. It would also be nice to highlight the difference with the PFO concept. "The problem is that given an arbitrary function F, using current C++ language rules, one cannot create a forwarding function FF that transparently assumes the arguments of F. " That's wrong. It's not impossible, it just requires an exponential number of overloads. C++0x rvalue references allow to reduce this to a linear amount. <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/h…> spurious ] at the end. The layout of this section is weird, by the way. The macros appear on top but are not explained until a later page. I remember I saw a couple other typos and similar but I can't find them anymore. Anyway it needs some proofreading. Features I would like to see in a future version ------------------------------------------------- Ok, this has little to do in a review, but here it is anyway. I would like to have an adapter to turn a PFO into a monomorphic function object (i.e. a function object with a result_type) that can be passed to legacy algorithms. This can be done two ways: either by giving the return type or the type of the arguments explicitly. This could also be used to define variant visitors with lambdas. I would like it if Phoenix could detect function objects that are monomorphic and automatically propagate that monomorphism (but that's probably hard to do). I would like it if the polymorphic function objects generated by Phoenix were masked out using SFINAE if their body-expression would result in a hard error. Essentially, to do this, one needs to be able to test whether the default Proto transform of an expression leads to an error. While this should be possible with compilers supporting extended SFINAE, I haven't been able to grok the Proto internals well enough to do it yet myself.

5 19

type traits not in boost.type_traits
by Frédéric Bron 26 Feb '11

26 Feb '11

I found the following files in 1.46.0 that could be either removed or moved to type_traits: * graph/detail/is_same.hpp -> already existing type traits library comment in the file: Deprecate the use of this header. TODO: Remove this file from trunk/release in 1.41/1.42. by the way, it seems that the file is never included so that we could safely remove it. Can we do that and run the tests to see if everything is still working? * iostreams/detail/is_dereferenceable.hpp -> could be moved to type traits but I should have a look to see if I cannot implement it in the extension If it is straightforward, I will implement it. The following will be part of the type trait extension (so let's review the extension first...): * detail/is_incrementable.hpp -> has_operator_increment<T> * exception/detail/is_output_streamable.hpp -> has_operator_left_shift<std::ostream, T> Frédéric

6 12