- Boost - lists.boost.org

[Report] 0 regressions on RC_1_34_0 (2007-05-16)
by Douglas Gregor 16 May '07

16 May '07

Boost Regression test failures Report time: 2007-05-14T23:41:53Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… No failures! Yay!

1 0

[proto] problem w/ context
by Maurizio Vitale 16 May '07

16 May '07

I'm not sure whether what I'm trying is possible, but I'm asking anyhow, that's cheap. I have a context like the following, which overloads operator() for a bunch of terminals and a predefined mask(left,right) and mask(what, left, right): template<typename Expr, typename Target, typename Source> struct meta_context : proto::callable_context<const meta_context<Expr,Target,Source> > { typedef meta_context<Expr, Target, Source> self; typedef unsigned int result_type; meta_context (const Target& target, const Source& source) : m_target (target), m_source (source) {} #define RESULT_FOR(NAME, EXPR) result_type operator () (proto::tag::terminal, NAME##_tag NAME) const { return EXPR; } RESULT_FOR (source, proto::arg(m_source).m_data) RESULT_FOR (source_left, proto::arg(m_source).left ()) RESULT_FOR (source_right, proto::arg(m_source).right ()) RESULT_FOR (target, proto::arg(m_target).m_data) RESULT_FOR (target_left, proto::arg(m_target).left ()) RESULT_FOR (target_right, proto::arg(m_target).right ()) template<typename What, typename Left, typename Right> result_type operator () (mask_tag, const What& what, const Left& left, const Right& right) const { std::size_t what_value = proto::eval (what, *this); std::size_t left_value = proto::eval (left, *this); std::size_t right_value = proto::eval (right, *this); if (left_value == sizeof (unsigned long long)*8) return what_value & (~0ULL << right_value); else return what_value & (~(~1ull << (left_value-1) | ~(~0ull << right_value))); } template<typename Left, typename Right> result_type operator () (mask_tag, const Left& left, const Right& right) const { std::size_t left_value = proto::eval (left, *this); std::size_t right_value = proto::eval (right, *this); if (left_value == sizeof (unsigned long long)*8) return ~0ULL << right_value; else return ~(~1ull << (left_value-1) | ~(~0ull << right_value)); } #undef RESULT_FOR const Target& m_target; const Source& m_source; }; This is find and does its job, delegating most of the work to inherithed defaults. Now I'd like to shortcut the run-time evaluation when a value can be determined solely from the type. Let's assume I have a transform that returns either an mpl::int_<> giving the compile time value or the special type run_time when no compile time result can be computed. I know (haven't tried, so it's just a semi-educated guess) that I could just overload everything, check whether none of the arguments returns run_time, rebuild the original expression type (because I think once I'm in one of the operator() overloads the expression is decomposed in tag and arguments, with the complete one available nowhere), call the transform on the newly created expression and return the compile time value. If any of the arguments evaluate to run_time, do the run-time processing. But this overloading everything is not what I'd like. What I'd like is to leave the few overloads that do something special in the context and in addition overload eval like this: template<typename Expr1> struct eval { typedef typename self::result_type result_type; result_type operator()(Expr1 const &expr, self &ctx) { ... do compile time evaluation ... ... if known, return value, otherwise: return proto::default_eval<Expr1, self>()(expr, ctx); } }; Except that this doesn't quite do it, default_eval knows nothing about the semantics of my terminals and non-terminals. But I cannot simply call proto::eval either. Is there a way to do this in proto already, so that some additional behaviour can be spliced in before the normal (but not the default) behaviour? Thanks, Maurizio

4 5

[string algorithm] Missing documentation for join
by Joe Gottman 16 May '07

16 May '07

The string algorithm documentation still hasn't been fully updated to include information on join. You need to edit the front page under "usage" (http://www.boost.org/doc/html/string_algo.html) and the usage page (http://www.boost.org/doc/html/string_algo/usage.html) Joe Gottman

2 1

Re: [boost] [lexical_cast] doc update
by Alexander Nasonov 16 May '07

16 May '07

16.05.07, 11:48, John Maddock <john(a)johnmaddock.co.uk>: > Just noticed what look like a couple of missing links [tuning] for example, All links are in References section. Do you mean to add anchor links that jump right to the references section? > and was [N1973] supposed to be a quickbook template that links to the doc? Sorry, I don't follow you. Neither N1973 nor lexical_cast.htm have any relations with quickbook (well, N1973 may be related, I don't own this document but anyway it's not a part of boost). -- Alexander Nasonov

2 1

Re: [boost] [lexical_cast] doc update
by Alexander Nasonov 16 May '07

16 May '07

16.05.07, 13:28, Phil Endecott <spam_from_boost_dev(a)chezphil.org>: > Q: What does lexical_cast<string> of an int8_t or uint8_t not do what I expect? > A: As above, note that int8_t and uint8_t are actually chars and are > formatted as such. To avoid this, cast to an integer type first: lexical_cast<string>(static_cast<int>(n)). Looks good. I'll add it. > Following are some minor edits to your text: > Q: Why does lexical_cast<int8_t>("127") throw bad_lexical_cast? > commitee --> committee > greate --> great Thanks. -- Alexander Nasonov

1 0

stlport.jam error?
by rasmus ekman 16 May '07

16 May '07

It doesn't seem right that stlport.jam should force linking to dll when <runtime-debugging> is on? See [boost-path] \tools\build\v2\tools\ stlport.jam:220-24 Some other <feature> should control this flag, docs at top of stlport.jam suggest so. re

1 0

Re: [boost] Improving Boost Build?
by Matthew Herrmann 15 May '07

15 May '07

> > Date: Tue, 15 May 2007 19:15:41 +0100 > From: "John Maddock" <john(a)johnmaddock.co.uk> > Subject: [boost] Improving Boost Build? > > 2) Better docs. Yes, I know it's been said before, but we really must get > the existing toolsets and their options documented. This need not take too > long if someone would step up and volunteer to do it. > I would like to add my vote to continuing the active maintenance of Boost Build V2. I've only ever used V2, and found it to have the best syntax for expressing hierarchies of libraries out of any of the tools I reviewed. The fact that there is no middle-man is a great guarantee that you will never get an unexpected interaction between this and makefiles, where both sides blame each other. Better Docs: The biggest documentation hole for me is in the programming "primitives" of boost build. To put it in perspective of a language, there are descriptions of some commonly used functions (exe, lib, alias) and some common arguments to those functions. But there is no description of what valid types there are, or what a function _is_. How does the "<variant>debug" trick work? Is it a map entry, or a single-element dictionary? How, precisely, does adding a new type of variant work? Is there language magic, or is the rule referring to a global variable? How do I make a list of things? How do I take the first one? How do I make a rule call another rule? How does module import work? Can you import a module twice? How do exceptions work? If these areas were better documented, a lot of people (including myself) would be able to "teach themselves to fish", and hopefully submit well-written patches to do things like add timeouts to unit test invocation. I can do the big stuff with bjam, like massively nested library builds, but just trying to pass an argument to a rule was an huge and ultimately fruitless exercise. Regards, Matthew Herrmann

1 0

The migration to svn & Spirit's release plans
by Nicola Musatti 15 May '07

15 May '07

Hallo, I'd like to know what are the current plans for the migration of the Boost CVS repository to Subversion. I'm asking because I volunteered to handle the release of Spirit 1.6.4 & 1.8.5, which basically means tagging the appropriate subset of Boost 1.34.0 . As I'm still not as familiar with Subversion as I am with CVS, I'd rather do it in the current repository. On the other hand this isn't going to happen before some time next week and I do not want to alter anybody's plans. Thank you, Nicola Musatti

4 6

boost::mem_fn suggestion/question
by Piyo 15 May '07

15 May '07

Hello, I was using boost::mem_fun and noticed that only with the 1 or 2 argument form of boost::mem_fun exposes the arguments types (first_argument_type and second_argument_type) for "compatibility" purposes. I was wondering if it were possible to expose in general all argument types just like boost::function does ( arg1_type, arg2_type, etc..). Any ideas/comments about this? Thanks!

3 7

RC_1_34_0 is still frozen
by Thomas Witt 15 May '07

15 May '07

The subject says it all. Please do not check in to RC_1_34_0 without prior talking to me. RC_1_34_0 is and will be frozen until I say otherwise. Thanks Thomas -- Thomas Witt witt(a)acm.org

1 0