- Boost - lists.boost.org

[documentation] help - SFINAE confuses doxygen
by Simonson, Lucanus J 24 Feb '09

24 Feb '09

I have noticed after attempting to document my overloaded template functions in doxygen that is simply doesn't work. Doxygen appears to consider all SFINAE overloads of a templated function as a single function, but doxygen's treatment of them is quite erratic. It seems to generally have a bunch of assumptions built into its internal logic about what can't happen in C++ code that aren't valid in my case. Does anyone have any suggestions for how to deal with these issues? I notice that doxygen is used with BoostBook, and I know this must have come up in other libraries. How is it solved? Thanks, Luke

8 14

Re: [boost] Boost.Convert+Boost.Parameter
by Vladimir.Batov＠wrsa.com.au 24 Feb '09

24 Feb '09

Trying to use Boost.Parameter as Daniel showed. Wow, that's truly hairy stuff. Obviously I get it wrong somewhere as matching Parameters constructor cannot be found. I am trying to call int ii = convert_to<int>("1", boost::convert_parameters::default_ = -1); when I have declarations below as (I think) Daniel indicated. namespace convert_parameters { BOOST_PARAMETER_NAME((from_, tag) from_) BOOST_PARAMETER_NAME((default_, tag) default_) } template<class TypeOut, class ArgumentPack> TypeOut test(ArgumentPack const& args) { return TypeOut(); } template< class TypeOut, class TypeIn, class A0> convert<TypeIn, TypeOut> convert_to(TypeIn const& value_in, A0 const& a0) { typedef parameter::parameters<parameter::required<convert_parameters::tag::from_> > Parameters; return test<TypeOut>(Parameters(value_in, a0)); } Any help? Please? Thanks, Vladimir.

3 2

[Phoenix2] nothing is not an actor
by Francois Barel 24 Feb '09

24 Feb '09

Hi, In core/nothing.hpp, "nothing" is defined as: null_actor const nothing = null_actor(); which doesn't make it an actor, rather an "actor base". Shouldn't it rather be defined as something like: actor<null_actor> const nothing = null_actor(); Thanks, François

3 2

Re: [boost] wiki.boost.org Ancient
by David Abrahams 24 Feb '09

24 Feb '09

on Mon Feb 23 2009, DongInn Kim <dikim-AT-osl.iu.edu> wrote: > Hi David, > > Can you setup the DNS of wiki.boost.org to just point to 129.79.245.252 without > aliasing for svn.boost.org? > This cause me difficult to setup its vhost properly. > > For example, > > [root@wowbagger wiki.boost.org]# host wiki.boost.org > wiki.boost.org is an alias for svn.boost.org. > svn.boost.org has address 129.79.245.252 > [root@wowbagger wiki.boost.org]# host beta.boost.org > beta.boost.org has address 129.79.245.252 > [root@wowbagger wiki.boost.org]# I could, but --- and I'm no www expert --- I think there ought to be a redirect so that there's a canonical web address for the wiki. Otherwise you get search engines spidering it twice, etc, no? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 2

Re: [boost] Formal Review Request: Boost.Convert
by Vladimir.Batov＠wrsa.com.au 23 Feb '09

23 Feb '09

Stewart, Robert wrote... > I assume that's a reference to me. My suggestion of "conversion" was as a namespace name. > Were you referring to my suggestion of using "converter" for the function object and "convert" > for the function template that would deduce template parameters? Yes, I was referring to that latter suggestion of yours: >> namespace boost >> { >> ...class convert; > s/convert/converter/ ... > template <class TypeOut, class TypeIn> > TypeOut const > convert(TypeIn _input, TypeOut const & _default) > { > return converter<TypeIn,TypeOut>(_input, _default); > } I've essentially implemented function wrappers as you suggested. Only I called them convert_to() and convert_from() that I am hoping many people will be happy with (remembering string_to/from et al) as the names could not be any clearer: int i = convert_to<int>(str); int i = convert_from(str, -1); int i = convert_from<string, double>(str, -1); That allowed me to keep the function object as "convert" and, say, apply it to algorithms as std::transform( strings.begin(), strings.end(), std::back_inserter(integers), convert<string, int>(string(), -1) >> std::hex); which is kinda nice as well. Do you agree? Thanks, Vladimir.

1 0

Re: [boost] Formal Review Request: Boost.Convert
by Vladimir.Batov＠wrsa.com.au 23 Feb '09

23 Feb '09

I've implemented the functionality as I described (convert as a class) and uploaded it as v0.21. I feel it is a considerable step forward in many respects as now it is more of a conversion 'framework' as users can create their specific specializations of boost::convert for their specific needs (as I did with lexical_cast). At the same time it feels reconciliatory as fighting over names could be put to rest (I hope) as we or the users might write simple and generic wrappers to boost::convert. In particular, I added boost::convert_to and boost::convert_from. It's just a suggestion. We might decide to keep them or remove or rename them. I am not fussy about it. So, the deployment loos as follows: // Explicitly specified 'from' and 'to' types. My personal preference int i = boost::convert<string, int>(str, -1); string s = boost::convert<int, string>(-1, "conversion failed"); // Deduced 'from' type. int i = boost::convert_to<int>(str); string s = boost::convert_to<string>(-1); // Both types are deduced. int i = boost::convert_from(str, -1); string s = boost::convert_from(-1, "conversion failed"); Robert suggested renaming 'convert' to 'conversion' but I am not warming up to that (yet, you might have noticed I am slow) as I essentially see 'convert' as a functor, i.e. encapsulating as an action, i.e. a verb is more appropriate. For that reason the code itself looks readable (to me) as "boost::convert<int, string>" reads as 'convert int to string". Thanks, Vladimir.

2 1

[proto] lazy functions in custom domains
by Dean Michael Berris 23 Feb '09

23 Feb '09

Hi Guys, I've recently tried to play around with Boost.Proto and I think I've run into a wall. I was trying to figure this (relatively simple) case out for a while already but it I'm at my wits end not seeing why the implementation doesn't work. I'm pasting the contents of the file (unmodified) which I've tried to follow from the Getting Started document. I was trying to get the custom domain approach working, but I never seem to get the lazy function to be called. The expected result from the code below would be to have multiple lines of output that says "Getting the friends of user # ;)" but I don't see those. There are no compilation errors, and I don't see anything obviously wrong from the implementation and how I understand Lazy functions. I'm just not sure about how lazy functions though can be made part of a domain though -- didn't find anything in the Getting Started guide about it. Help would be very much appreciated (BTW I'm using Proto that's in Boost 1.38.0, building with GCC 4.0 in Mac OSX 10.5.6): ---->8-- #include <iostream> #include <boost/proto/proto.hpp> #include <vector> namespace mpl = boost::mpl; namespace fusion = boost::fusion; namespace proto = boost::proto; using proto::_; using std::vector; using std::cout; using std::endl; struct user_tag; template <class Tag> struct placeholder {}; struct friendster_action_context : proto::callable_context<friendster_action_context const> { uint32_t user_id; friendster_action_context(uint32_t id) : user_id(id) {} friendster_action_context(friendster_action_context const & other) : user_id(other.user_id) {} friendster_action_context & operator= (friendster_action_context other) { other.swap(*this); return *this; } void swap(friendster_action_context & other) { std::swap(user_id, other.user_id); } typedef uint32_t result_type; result_type operator() (proto::tag::terminal, placeholder<user_tag>) const { return this->user_id; } }; template <class Expr> struct friendster_action; struct friendster_action_domain : proto::domain<proto::pod_generator<friendster_action> > {}; template <class Expr> struct friendster_action { BOOST_PROTO_EXTENDS(Expr, friendster_action<Expr>, friendster_action_domain); typedef void result_type; result_type operator()(uint32_t id) const { friendster_action_context ctx; ctx.user_id = id; return proto::eval(*this, ctx); } }; friendster_action<proto::terminal<placeholder<user_tag> >::type> const user = {{}}; struct friend_fun { typedef vector<uint32_t> result_type; template <class T> result_type operator() (T id) const { cout << "Getting the friends of user " << id << " ;)" << std::endl; return result_type(); }; }; template <class Arg> typename proto::result_of::make_expr< proto::tag::function, friend_fun, typename proto::result_of::as_child<Arg const>::type >::type friends(Arg const & arg) { return proto::make_expr<proto::tag::function>( friend_fun(), proto::as_child(arg) ); } #include <algorithm> using namespace std; int main(int argc, char * argv[]) { uint32_t users[] = { 1, 2, 3, 4 }; uint32_t * begin = users; uint32_t * end = users + 4; cout << "Here they are: " << endl; for_each(begin, end, friends(user)); string input; cin >> input; return 0; } ---->8-- -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

2 2

[gil][ublas] Point2DConcept and ublas vector concept
by Christoph Heindl 23 Feb '09

23 Feb '09

Hi, I'd like to use my boost::ublas::bounded_vector types interchangeable with boost::gil::point2 which from my point of view makes totally sense: A convex hull algorithm for 2D would only need to be implemented once (for world coordinates and pixel coordinates) for example. This, however, seems impossible right now because of the differences in their concepts. Is it possible to somehow make a bridge between them (without copying structures)? Any plans to unify those concepts and reuse ublas types? Best regards, Christoph

1 0

Trac tickets: fixed in trunk vs. fixed in release
by Steve M. Robbins 22 Feb '09

22 Feb '09

Hi, For each bug, there are really two levels of "fixed": roughly speaking, the developer considers the issue fixed when it is committed to trunk, while the user considers the issue fixed when it is commited to the release branch. At present, the trac ticket is closed at the first gate. Unfortunately, sometimes the second gate gets forgotten. Could another state be added to the ticket lifecycle to track when it gets merged to release? My aim is to be able to identified "fixed" tickets that are not actually released and, hopefully, to decrease them in number. Maybe there are other ways to achieve this? Regards, -Steve

5 10

[Iterator] Two sets of docs?
by John Maddock 22 Feb '09

22 Feb '09

The iterator library seems to have two sets of docs: one in quickbook format and one in restructured text. Which is the correct up-to-date version, and can we get rid of the other to avoid confusion? Thanks, John.

2 2