- Boost - lists.preview.boost.org

[bind][phoenix] Compliance with function template bind
by Vicente J. Botet Escriba 19 Dec '11

19 Dec '11

Hi, Boosthas Boost.Bind and Boost.Phoenix that provides a bind function. Are them compliant with C++11 for 20.8.9 Function template bind (in particular move semantics)? If yes, how they work for C++03 compilers? If not, is there any plan to adapt them to support move semantics? Best, Vicente

2 3

[Concept Checking] function_requires
by Jens Müller 18 Dec '11

18 Dec '11

Hi all, as far as I understand http://www.boost.org/doc/libs/1_48_0/libs/concept_check/reference.htm#depre…, function_requires() is deprecated. However, the documentation does not mention very clearly how to replace it. Is the BOOST_CONCEPT_ASSERT macro the replacement? E.g., does function_requires< VertexListGraphConcept<Graph> >(); now become BOOST_CONCEPT_ASSERT((VertexListGraphConcept<Graph>)); function_requires still appears in a lot of test cases of the Graph library. So if it is that easy to change, I would hand in a patch. Best regards, Jens

2 7

[math.special_functions] broken in trunk
by Tim Blechmann 18 Dec '11

18 Dec '11

it seems, there is a problem in boost.math in trunk. the boost.heap testsuite originally used boost.random, but the test farm reports some issues: In file included from ../boost/math/special_functions.hpp:32, from ../boost/random/generate_canonical.hpp:22, from ../boost/random.hpp:52, from ../libs/heap/test/mutable_heap_tests.hpp:1, from ../libs/heap/test/fibonacci_heap_test.cpp:12: ../boost/math/special_functions/expint.hpp: In function ???void boost::math::detail::expint_i_imp_113a(T&, const T&)???: ../boost/math/special_functions/expint.hpp:1028: error: expected primary- expression before ???(??? token (compare http://tinyurl.com/bqfputx) for now, i've reverted to the libc random() function to work around this issue, but it would be great, if someone with insights in boost.math could have a look. thanks, tim

2 2

Add macros for the "enum class" concept?
by Daryle Walker 18 Dec '11

18 Dec '11

Should we add preprocessor stuff to conditionally use the C++11 "enum class" construct? #if Whatever #define BOOST_HAVE_ENUM_CLASS #endif //... #if BOOST_HAVE_ENUM_CLASS #define BOOST_ENUM_CLASS( Name ) enum class Name #define BOOST_ENUM_CLASS_BASE( Name, Type ) enum class Name : Type #define BOOST_ENUM_CLASS_REFER( Type, Enumerator ) (Type :: Enumerator) #else #define BOOST_ENUM_CLASS( Name ) enum Name #define BOOST_ENUM_CLASS_BASE( Name, Type ) BOOST_ENUM_CLASS( Name ) #define BOOST_ENUM_CLASS_REFER( Type, Enumerator ) (Enumerator) #endif I'm not sure that the second version of BOOST_ENUM_CLASS_BASE is the best alternative. Nor do I know if the parentheses around enumerators are best. You can use BOOST_ENUM_CLASS in an enum definition header and BOOST_ENUM_CLASS_BASE as a header or a forward declaration. Since enumerators can be scoped, BOOST_ENUM_CLASS_REFER encapsulates the need to add the enum type's name.

5 9

[parameter] type predicates vs. concepts
by Lorenzo Caminiti 18 Dec '11

18 Dec '11

Hello all, What's the difference between using a Boost.Parameter type predicate and using a concept? I think parameter type predicates are unary metafunctions used to resolve the function call, concepts are asserted on the type after the call has been resolved... Is there more? Can I always do with type predicates what I can do with concepts? Is there ever a reason to use/need both? For example here has_equal_to is the type predicate while DefautlConstructible is the concept. Could/should I have used has_[...]_default_constructor in and_ the type predicate instead of the DefaultConstructible concept? #include <boost/parameter.hpp> #include <boost/concept/requires.hpp> #include <boost/concept_check.hpp> #include <boost/type_traits/has_equal_to.hpp> #include <iostream> template< typename X > BOOST_CONCEPT_REQUIRES( ((boost::DefaultConstructible<X>)), (bool) ) is_default_impl ( X const& x ) { return x == X(); } BOOST_PARAMETER_NAME(x) BOOST_PARAMETER_FUNCTION( (bool), is_default, tag, (required (x, *(boost::has_equal_to<tag::x::_>)) ) ) { return is_default_impl(x); } struct no_equal {}; struct no_default { no_default(int) {} }; bool operator== ( no_default const&, no_default const& ) { return true; } int main ( void ) { std::cout << is_default(123) << std::endl; // ok // parameter error: cannot resolve is_default() call // std::cout << is_default(no_equal()) << std::endl; // concept error: no default constructor // std::cout << is_default(no_default(1)) << std::endl; return 0; } Thanks a lot. --Lorenzo

4 7

Boost Iterator Library - small extension proposal
by Detlef Wilkening 18 Dec '11

18 Dec '11

Hello Boostler, at first, excuse my english - I am not a native speaker. I used sometimes the Boost.Iterator library - especially the filter iterators. I like them much, but I don't like the work to create the iterator objects. --- Example: struct IsEven { inline bool operator()(int n) const { return n%2==0; } }; vector<int> v; IsEven iseven; filter_iterator<IsEven, vector<int>::iterator> filter_iter_begin(iseven, v.begin(), v.end()); filter_iterator<IsEven, vector<int>::iterator> filter_iter_end(iseven, v.end(), v.end()); --- My first problem is, that I need 3 times "v.end()" and 2 times "iseven". And the type is very long. I don't think, that the "make" functions makes it much better. I use "auto" from C++11 in this example, to make it a little bit shorter. --- Example: struct IsEven { inline bool operator()(int n) const { return n%2==0; } }; vector<int> v; IsEven iseven; auto filter_iter_begin2 = make_filter_iterator<IsEven>(v.begin(), v.end()); auto filter_iter_end2 = make_filter_iterator<IsEven>(v.end(), v.end()); --- Again I need 3 times "v.end()" and 2 times the type "IsEven". And the type is again very long - thanks to "auto" in C++11. My second problem is, that both use cases don't work well with lambda expressions in C++11. For "make" I need the type of the lambda, which I don't have - and I need it 2 times. And in the first solution I must write the lambda expression 2 times, which is not good. Perhaps there are some other solutions, wich I don't see - than please explain them to mee. ----- My proposal is a new "make" function, which is easer to use (only 1 time "v.end()") and works well with lambda expressions, but has furthermore a stupid type - but in C++11 with "auto" that doen't matter. --- template<class Iter, class Fct> pair<filter_iterator<Fct, Iter>, filter_iterator<Fct, Iter>> make_filter_iterators(Iter begin, Iter end, Fct fct) { filter_iterator<Fct, Iter> filter_iter_begin(fct, begin, end); filter_iterator<Fct, Iter> filter_iter_end(fct, end, end); return pair<filter_iterator<Fct, Iter>, filter_iterator<Fct, Iter>> (filter_iter_begin, filter_iter_end); } Usage: vector<int> v; auto iters = make_filter_iterators( v.begin(), v.end(), [](int n){ return n%2==0; }); copy(iters.first, iters.second, ostream_iterator<int>(cout, " ")); --- You see, with "auto" easy to use, and work well with lambda expressions. My proposal is to add such a "make" function to all iterator adaptors in Boost.Iterator. Thank you for reading my idea. Greetings Detlef Wilkening

3 3

[Math.Constants] Help needed with the preprocessor
by John Maddock 18 Dec '11

18 Dec '11

Folks we have a problem: rather late in the day I've discovered that our Math.Constants code doesn't compile on anything except VC++, and the problem is preprocessor token pasting. So I'm hoping we have some experts around here that can help! The issue is we currently construct the constants from a macro invocation such as: BOOST_DEFINE_MATH_CONSTANT(half, 5.000000000000000000000000000000000000, 00000000000000000000000000000000000000000000000000000000000000000000000000, -01); But the "-01" part (the exponent) isn't a valid pp-token, so trying to token-paste it fails on GCC (compiler error). Does anyone know if there's a way to overcome this? As an alternative, I've considered something like: BOOST_DEFINE_MATH_CONSTANT(ln_two, 6.931471805599453094172321214581765680e-001, "6.93147180559945309417232121458176568075500134360255254120680009493393621969694715605863326996418687542001481021e-001"); But this would still require token pasting of the 6.931471805599453094172321214581765680e-001 part. But is this now a valid pp-token if the "-" is internal to the token? It works on the compilers I've tried, but I don't want to be skewered by this again down the line.... Truly hating the preprocessor yours, John.

6 8

Re: [boost] New libraries implementing C++11 features in C++03
by Brent Spillner 18 Dec '11

18 Dec '11

On 24 Nov 2011 09:11:19 Joel de Guzman wrote: >Man! Of course you should use the examples in 1.45. Those examples >are for 1.48 and uses new features implemented in 1.48! Sheesh! I fully understand that. The point is that the Phoenix interface is evolving much more quickly than that of probably any other Boost library. Even apart from the fact that there already have been two bottom-up rewrites, there are enough significant changes between point releases that even small example programs are tied to a particular version of the library. Why is the optimal way to write a small calculator example today so different from the optimal way to write it six months ago? I'm not disputing that you're making forward progress, just highlighting this as another barrier to entry that Local likely won't have. >Double Sheesh! If you've spent even a few seconds looking into the >error (beyond fault-finding), you will see that a simple textual >search of "error" will reveal this: Yes, it's possible to wade through the error messages and figure out what went wrong. And Qi is clearly trying to help out with traceable assertions; that may well be the best we can do. But no reasonable person would claim that hundreds of lines of error message, mostly filled with types that the user never directly constructed, are the most desirable way to report a simple syntax error. This problem is endemic to all ET libraries and compilers, and it would be very, very hard to do much better. Again, though, I think you're underselling this as a barrier to entry. How many people would ever learn C++ if all libraries did this? >Now having said that, and before I leave this thread, let me remind >everyone that **you can also have statement syntax in Phoenix** if you >have a complex statement and you fear writing complex phoenix lambda >expressions. It's called phoenix::functions. The important issue here isn't just statement /syntax/, it's that we have options available that don't turn what looks like an ordinary C++ statement into a massive AST with its own mini-compiler behind the scenes.

18 38

Boost.Math and Math Constants
by Paul A. Bristow 17 Dec '11

17 Dec '11

Boost.Math has always had an inconspicuous collection of useful math constants, mainly those that are used internally. The presentation of these was as a function-template, called for example, as pi<double>(). using namespace boost::math::constants; return pi<Real>() * r * r; This leads to some rather ugly equations and is most unpopular with scientific and engineering users. John Maddock has now added a new cunning feature that allows the vast majority of users who just want a built-in double to get the constants quickly as plain variables. So in non-template code, users can write using boost::math::double_constants; double area = pi * r * r; and users can read the equations easily. (Float and long double are similarly available in their own namespaces). The original mechanism which can be used for higher multiprecision user-defined floating-point types appears unchanged but has been improved to work better with UDTs and high precision types. Some draft detailed docs about just these new proposals are at http://boost-sandbox.sourceforge.net/libs/math_constants/doc/html/index.html We would like to be sure that 1 This additional mechanism of presenting constants is acceptable. 2 It is acceptable to add more constants (current new list is about 60 constants). Are there important constants that you think we have missed? Do we need a mini-review? Other views? Paul PS 1 Are there important constants that you think we have missed? 2 Please tell me of mistakes and typos in the draft docs. --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

9 24

Standard library Technical Report 2 proposals for Boost libraries
by Beman Dawes 17 Dec '11

17 Dec '11

The C++ committee hasn't decided whether to do a TR2 or to move directly on to the next standard. Either way, there will be a call for library proposals, but the details will be up in the air at least until the next meeting, which will be in Kona, Hawaii, in February. For the moment, the term "TR2" is being used as a surrogate for moving the standard library forward regardless of exact details. In discussions, library working group (LWG) members have made it clear they want a filesystem library based on Boost.Filesystem, and a networking library based on Boost Asio. Individual members of the committee have voiced interest in other Boost libraries, large and small. If you are a Boost developer (or user), and there is a Boost library you would like to see proposed for TR2, now is a good time to start thinking about writing a preliminary proposal to the committee. The point of such a proposal is to gauge interest before putting in a lot of work on a full-blown proposal only to find the LWG isn't interested. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html for the original TR2 call for proposals. While the details will change, it is still a reasonable introduction to what is required. A preliminary proposal would just say "To be supplied" for the "Proposed Text for the Standard" section. It is very helpful to do at least the initial presentation of such a proposal in person. That said, John Maddock and Peter Dimov had many proposals accepted for TR1 without ever attending a standards committee meeting. If you don't plan to present a proposal in person, the best bet is to ask someone who is familiar with the library to present it. Feel free to contact me publicly or privately with questions about proposals or information about attending committee meetings, --Beman

7 18

Slow Bugs Tracker
by Olaf van der Spek 17 Dec '11

17 Dec '11

Hi, Trac, the bugs tracker used, is really slow. Using it is a bad experience, every single time. Would it be possible to use a better bugs tracker? -- Olaf

5 14

Submitting patches
by Pedro Larroy 17 Dec '11

17 Dec '11

Hi What's the proper way to submit patches for boost trunk? Regards.

3 4

[thread] 5351 interrupt a future get boost::unknown_exception
by Vicente J. Botet Escriba 17 Dec '11

17 Dec '11

Hi, I have reached to compile the example with some variants. See the attached file in http://svn.boost.org/trac/boost/ticket/5351. It seems the problem comes from the fact that packaged_task catch every exception void do_run() { try { this->mark_finished_with_result(f()); } catch(...) { this->mark_exceptional_finish(); } } and store it to rethrow in the wait() function using boost::rethrow_exception. if(rethrow&& exception) { boost::rethrow_exception(exception); } As thread_interrupted doesn't inherits from std/boost::exception the thrown exception is translated as boost::unknown_exception. A solution could be to catch specifically thread_interrupted and store this fact. catch(thread_interrupted& it) { this->mark_interrupted_finish(); } void mark_interrupted_finish() { boost::lock_guard<boost::mutex> lock(mutex); thread_was_interrupted=true; mark_finished_internal(); } When wait is called, a test if the thread has been interrupted is done so that the exception thread_interrupted is thrown. if(rethrow && thread_was_interrupted) { throw boost::thread_interrupted(); } The single problem I see is that the this new exception doesn't contains from where the initial thread_interrupted was thrown. Could the interested parties inspect the patch attached to http://svn.boost.org/trac/boost/ticket/5351 and check it, please? Is there something I forgot or a simple or more robust way to solve this missing feature? Best, Vicente

1 1

[local] "true" lambdas without C++11 but only on GCC
by Lorenzo Caminiti 17 Dec '11

17 Dec '11

Hello all, A curiosity: On GCC compilers (but _only_ on GCC compilers) it is possible to combine Boost.Local and the non-standard GCC "expression statements" feature to implement lambda functions. In other words, it is possible to define a Boost.Local closure within a GCC expression statement: std::vector<int> v(3); v[0] = 1; v[1] = 2; v[2] = 3; int factor = 10; std::for_each(v.begin(), v.end(), LAMBDA(int x, const bind& factor) { std::cout << x * factor << std::endl; } LAMBDA_END ); This is just a curiosity because it is NOT standard C++03 and it will ONLY work with GCC compilers. #include <boost/local/function.hpp> #include <vector> #include <algorithm> #include <iostream> // WARNING: This macros only work on GCC!!! #define LAMBDA_WITH_RESULT(result_type, ...) \ ({ /* open GCC statement expression */ \ result_type BOOST_LOCAL_FUNCTION_PARAMS(__VA_ARGS__) #define LAMBDA(...) \ LAMBDA_WITH_RESULT(void, __VA_ARGS__) #define LAMBDA_END \ BOOST_LOCAL_FUNCTION_NAME(BOOST_PP_CAT(lambda, __LINE__)) \ BOOST_PP_CAT(lambda, __LINE__); \ }) /* close GCC statement expression */ int main() { std::vector<int> v(3); v[0] = 1; v[1] = 2; v[2] = 3; int factor = 10; std::for_each(v.begin(), v.end(), LAMBDA(int x, const bind& factor) { std::cout << x * factor << std::endl; } LAMBDA_END ); return 0; } I might mention this code example as a curiosity in Boost.Local docs, currently it's not mentioned there. Thanks. --Lorenzo

2 3

[log] sourceforge trunk broken with clang
by Michael Caisse 17 Dec '11

17 Dec '11

Changeset 633 fails to compile with clang. The trivial logger example in tutorial will trigger multiple errors. My guess is that simply including trivial.hpp will do the same. -- Michael Caisse Object Modeling Designs www.consultomd.com

2 1

New libraries implementing C++11 features in C++03
by Jeffrey Lee Hellrung, Jr. 17 Dec '11

17 Dec '11

Within the discussion for the review of the proposed Boost.Local library, Hartmut Kaiser raised a concern that I think should be addressed more broadly by the community, if possible. I quote Hartmut: > Ok. However this raises a more serious question. Should we as the > Boost community still encourage solutions and libraries solely for > portability with ancient compilers? I'd say no, but YMMV. Boost will > be still around 2, 5, or 10 years from now. What's the utility of > adding such a _solely_ backwards oriented library from this POV? Indeed, I ask the community, do such libraries belong in Boost? If so, is the bar for acceptance of such libraries automatically and necessarily higher than libraries that introduce genuinely new capabilities in C++11? If so, what additional criteria must such a library meet? I add two additional notes to help put the discussion in context: - Within the proposed Boost.Local review discussion, several individuals pointed out that they will likely have to work professionally on C++03 compilers for at least a few more years. - Recall that Boost has several (recent) libraries that could easily be labelled as "transitional" libraries: Move, Atomic (at least proposed, not sure if accepted), Container. Further, several older libraries are now part of the C++11 standard (e.g., Thread (right?)). - Jeff

20 45

Speeding up set and map insertion
by Tweety 16 Dec '11

16 Dec '11

Hi, I think it would speed up inserting range of elements into set and map, when in tree.hpp we replace: template <class InputIterator> void insert_equal(InputIterator first, InputIterator last) { //Insert with end hint, to achieve linear //complexity if [first, last) is ordered const_iterator end(this->cend()); for( ; first != last; ++first) this->insert_equal(end, *first); } with: template <class InputIterator> void insert_equal(InputIterator first, InputIterator last) { //Insert with hint, to achieve linear //complexity if data is even partially ordered const_iterator it(this->cend()); for( ; first != last; ++first) it = this->insert_equal(it, *first); } I will make almost linear complexity when data is ordered ascending, descending, and even partially ordered. Because when inserting with end hint (btw. wasn't here a bug? because "end" wasn't updated) it's only linear if we insert elements in ascending order.

2 1

[crc] Does anyone know who did issue #2492?
by Daryle Walker 16 Dec '11

16 Dec '11

I ask because I don't see any bug; his/her example works just fine for me. I need a complete (minimal!) program that shows the error. See more at [https://svn.boost.org/trac/boost/ticket/2492]

1 0

[graph] running test leda_graph_cc.cpp fails - header not found
by Jens Müller 15 Dec '11

15 Dec '11

Hi all, I tried to run the tests for the LEDA adapter in the Boost Graph library. I checked out the latest trunk from SVN. I made the Boost.Build v2, works fine. When running ./../../tools/build/v2/bjam in libs/graph/test, all tests run fine. I installed LEDA (free version) in /home/jens/devel/leda-free/LEDA-6.3-free-fedora-core-8-64-g++-4.1.2-mt After successfully running all other tests, the one for LEDA fails: $ ../../../tools/build/v2/bjam -s LEDA=/home/jens/devel/leda-free/LEDA-6.3-free-fedora-core-8-64-g++-4.1.2-mt/ Performing configuration checks - has_icu builds : yes ...patience... ...patience... ...patience... ...found 6503 targets... ...updating 2 targets... gcc.compile.c++ ../../../bin.v2/libs/graph/test/leda_graph_cc.test/gcc-4.6.1/debug/leda_graph_cc.o In file included from leda_graph_cc.cpp:10:0: ../../../boost/graph/leda_graph.hpp:20:30: fatal error: LEDA/graph/graph.h: No such file or directory compilation terminated. "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC -DBOOST_ALL_NO_LIB=1 -I"../../.." -c -o "../../../bin.v2/libs/graph/test/leda_graph_cc.test/gcc-4.6.1/debug/leda_graph_cc.o" "leda_graph_cc.cpp" ...failed gcc.compile.c++ ../../../bin.v2/libs/graph/test/leda_graph_cc.test/gcc-4.6.1/debug/leda_graph_cc.o... ...failed updating 1 target... ...skipped 1 target... Note that I edited boost/graph/leda_graph.hpp, fixing a syntax error and making it point to the now location of the LEDA header files (which contains an additional "graph" sub-directory). But the problem seems to be that the include directory is not at all passed to the compiler. What is going wrong here? Best, Jens

2 2

[graph] LEDA adapter
by Jens Müller 15 Dec '11

15 Dec '11

Hi all, are there still people who want to use the LEDA adapter in the Graph library? Back in 2007, I contributed adapters for some property maps. The checkin unfortunately introduced a typo (let's call it a transmission error ...) which is still there. So apparently no-one used it since then?! There also have been some discussions on removing the support, and patch requests were denied due to a lack of maintainer ... If there is _any_ interest in still maintaining leda_graph.hpp, I'd do it, as Douglas had already offered to me in 2007. I have more time and a better understanding now, and I'd really like to dive a bit more into Boost development. Besides, there apparently now is a free (as in beer) version of LEDA available, which should facilitate more widespread testing. Regards, Jens

3 5

Request: sanity check for a jamfile
by Daryle Walker 15 Dec '11

15 Dec '11

I just added a new test file for Boost.CRC on the SVN trunk. I also tried to adapt the test jamfile to accommodate two test programs. I'm not sure that I did it right, so can anyone check that it works. (I use XCode to build and test my programs.) The new file, "crc_test2.cpp", uses the unit-testing apparatus. The old file, "crc_test.cpp", uses the header-only minimal Testing facility. (I'm not sure that its link to the Test Execution monitor, in the jamfile, is needed.) I added a new testing file because I want to add a test case for a bug and Boost.Test has advanced so much that the first file is way too obsolete to be safely extended. It's change #75959 on the trunk, a.k.a. [https://svn.boost.org/trac/boost/changeset/75959]

2 1

[python] [concept] CallPolicies implementation
by Lorenzo Caminiti 15 Dec '11

15 Dec '11

Hello all, Does Boost.Python implement the CallPolicies concept? I couldn't find it... http://www.boost.org/doc/libs/1_48_0/libs/python/doc/v2/CallPolicies.html If not, would something like this be OK?? template<class P> struct CallPolicies { BOOST_CONCEPT_ASSERT((ResultConverterGenerator<P::result_converter>)); BOOST_CONCEPT_ASSERT((Metafunction<P::extract_return_type>)) BOOST_CONCEPT_USAGE(CallPolicies) { bool b = x.precall(a); // convertible to bool PyObject* o = x.postcall(a, r); // convertible to PyObject* } private: P x; PyObject* a; PyObject* r; }; I'd have to implement ResultConverterGenerator and Metafunction as well. Thanks. --Lorenzo

2 1

[parameter] compiler errors with operators
by Lorenzo Caminiti 15 Dec '11

15 Dec '11

Hello all, Does Boost.Parameter support operators? The following example is from the docs but it doesn't compile. Looking at the preprocessed code /EP, the errors seem to be because the macro defines a struct template postfixing it with the operator name and symbol "template <class Args> struct boost_param_result_11operator() { ... };". Maybe this worked once before and it's now broken? #include <boost/parameter.hpp> #include <iostream> BOOST_PARAMETER_NAME(arg1) BOOST_PARAMETER_NAME(arg2) struct callable2 { BOOST_PARAMETER_CONST_MEMBER_FUNCTION( (void), operator(), tag, (required (arg1,(int))(arg2,(int)))) { std::cout << arg1 << ", " << arg2 << std::endl; } }; int main ( void ) { callable2 c; c(1, 2); return 0; } On MSVC 8 with latest Boost trunk: c02.cpp c02.cpp(11) : error C2988: unrecognizable template declaration/definition c02.cpp(11) : error C2059: syntax error : 'type' c02.cpp(11) : error C2334: unexpected token(s) preceding '{'; skipping apparent function body c02.cpp(11) : error C2988: unrecognizable template declaration/definition c02.cpp(11) : error C2059: syntax error : 'type' c02.cpp(11) : error C2334: unexpected token(s) preceding ':'; skipping apparent function body c02.cpp(11) : error C2143: syntax error : missing ';' before '<' c02.cpp(11) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int c02.cpp(11) : error C2238: unexpected token(s) preceding ';' c02.cpp(11) : error C2143: syntax error : missing ';' before '<' c02.cpp(11) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int c02.cpp(11) : error C2238: unexpected token(s) preceding ';' c02.cpp(11) : error C2988: unrecognizable template declaration/definition c02.cpp(11) : error C2059: syntax error : '<' c02.cpp(11) : error C3861: 'boost_param_parameters_11operator': identifier not found c02.cpp(11) : error C2039: 'type' : is not a member of '`global namespace'' c02.cpp(11) : error C3861: 'boost_param_parameters_11operator': identifier not found c02.cpp(11) : error C2039: 'type' : is not a member of 'boost::parameter::aux::match' ..\..\..\..\..\boost\trunk.windows\boost/parameter/preprocessor.hpp(99) : see declaration of 'boost::parameter::aux::match' c02.cpp(11) : error C2039: 'type' : is not a member of '`global namespace'' c02.cpp(11) : error C2334: unexpected token(s) preceding '{'; skipping apparent function body c02.cpp(14) : error C2270: 'boost_param_default_11operator' : modifiers not allowed on nonmember functions c02.cpp(14) : error C2091: function returns function c02.cpp(20) : error C2064: term does not evaluate to a function taking 2 arguments Thanks. --Lorenzo

2 1

[multiprecision] Docs missing the basics
by Beman Dawes 15 Dec '11

15 Dec '11

Looking at http://boost-sandbox.sourceforge.net/libs/multiprecision/doc/html/multiprec… http://boost-sandbox.sourceforge.net/libs/multiprecision/doc/html/multiprec… I see a lot of details and commentary, but nothing about the big picture. * Needs an explanation of what "multiple precision" means. I would expect the first sentence to be something like "The multiprecision library, like other multiple precision libraries, provides arithmetic types that are not limited to the precision of the built-in C++ arithmetic types." * Needs an early explanation of what kinds of arithmetic types are supported. I would expect the second sentence to be something like "Integer, floating, and user defined types are supported." (I can't even tell from the current intro whether integers and UDTs are supported!) * Needs an early "Hello World" level example. The third sentence might begin a new paragraph, something like "Here is a simple example of muliprecision use: ..." Please remember that the point of a "Hello World" example is to introduce the simplest possible use of the library, not to demonstrate its power! * Although, not as critical as the previous issues, a bullet list of key features would be easier to read than plowing through a bunch of dense text. Once you've done that, the reader can make a quick blink decision as to whether to read on. A reader who isn't interested with thank you for not wasting their time plowing through a lot of text only to discover the library isn't of interest to them. Once docs provided the above view from 30,000 feet, then the remaining introductory details you've provided become interesting and the reader has enough orientation to absorb them. Good luck with this library! --Beman

4 3

Andriod development using boost
by Jan Stetka 14 Dec '11

14 Dec '11

Anyone done any andriod development. I'm interested on how much you can use boost for andriod development. Also JNI looks like the way of using C++ code, does anyone have experience of using JNI?

3 2