February 2009 - Boost - lists.boost.org

[geometry] gtl review pre-announcement
by Simonson, Lucanus J 25 Feb '09

25 Feb '09

Fellow geometry authors and interested reviewers, My abstract for gtl has recently been accepted to boostcon. I was unable to put together a geometry panel discussion, however. I am also working on completing documentation for the library by April. I would like the gtl library to be under review during boostcon because I may get the opportunity to meet and talk to some of the reviewers in person. To that end I'd like to ask for volunteers to be review manager and reviewers of the library now so that it isn't a surprise and things can proceed smoothly when the documentation is ready in a few weeks. I especially want other geometry authors to be aware of my plans and schedule. I have the utmost respect for the authors of the other two serious geometry proposals. It is my hope that we can work together during the review process and after to improve and converge our libraries toward the ideal boost::geometry library that all of us can feel proud of. Eventually it is my hope that algorithms in boost::geometry come for a variety of sources selected based upon quality such that there is no single owner of the library, but rather a community. I look forward to your reviews. Thanks, Luke

1 0

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

25 Feb '09

> The keywords are decoupled. > ... > Did you read through the Boost.Parameter tutorial? OK, I admit before I only glanced over the docs a couple of times. I thought I got the idea. Obviously not. :-( Now I printed it out and set down reading. Now I see the registration is all by itself and not coupled with anything. That's good. So, convert() can take those parameters in. Given we do not know how many parameters there might be I'd suggest we set those parameters with operator(). Like convert<string, int>(str)(default_ = -1)(throw_ = false)(some_other_parameter_ = ...) Given, convert() does not know and does not understand "some_other_parameter_" somebody else will need to do something with it. Who would that be and what would it do? I presume we could come up with a Boost.Parameter-based manipulator analog... or... no, I admit I am out of ideas. How can all that work? Thanks, Vladimir.

6 7

[utility] value_initialized fix causes Intel-linux 9.0 compile error
by Niels Dekker - mail address until 2010-10-10 24 Feb '09

24 Feb '09

My fix of the "const incorrectness" of boost::value_initialized (changeset [51355]), committed to the trunk last Friday, has passed the value_init_test tests successfully on most compilers, including intel-linux 10.0 and 10.1: www.boost.org/development/tests/trunk/developer/utility_.html Unfortunately it has a compile time regression failure on intel-linux 9.0, when trying to compare a value_initialized<NonPOD*> and a NonPOD*: error: more than one operator "==" matches these operands: built-in operator "pointer == pointer" built-in operator "pointer == pointer" operand types are: boost::value_initialized<NonPOD *> == NonPOD *const www.boost.org/development/tests/trunk/output/Sandia-intel-9-0-boost-bin-v2-… I don't have access to an Intel compiler, but it looks like the compile error is specific to pointers, as it doesn't seem to occur when comparing value_initialized<T> and T for other types T (int, double, POD, NonPOD). Is this a known compiler bug of the Intel 9.0? Apparently it's fixed by Intel 10.0. The fix of changeset [51355] replaced the existing conversion operator by a pair of them, overloaded for const and non-const. See also https://svn.boost.org/trac/boost/ticket/2548 Would it be okay to just mark the regression failure as "expected", and leave the implementation of boost::value_initialized as it is, including the const-fix? Otherwise, do you have any suggestion for a workaround? Note that the compile error is specific to the implicit use of the conversion operator. value_initialized also provides "get" functions and data() member functions to retrieve its value, which should still work fine on Intel 9.0. Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 0

DynObj - Library for C++ runtime plugin objects
by Arne Steinarson 24 Feb '09

24 Feb '09

I'm the developer of DynObj - a C++ library for cross platform plugin objects/components. In short, the approach of the library is to exploit the underlying compiler representation of virtual function tables. Since the VTable of any type occupies a unique place in memory, the VPTR forms a valid runtime type ID. With the help of this type ID, DynObj (in a host application) can then access type information emitted by the plugin compiler. In effect, we get a cross compiler variant of dynamic_cast<>: * U* do_cast<U*>( T *pt )* This cast operation then takes the role of *QueryInterface(...)* in COM or xpCOM. The difference is that we're not forced into using a specific base class for plugin capable types. We also get a meaningful type system shared across host/plugin, not just isolated interfaces. To go about all of this, the library relies on quite a bit of template code, effectively tracking down object and interface offsets inside classes, and then exporting them in a well defined, binary safe structure. However, to simplify this (there is a bit of 'boiler plate code' needed for each plugin type), DynObj uses a preprocessor that generates most of this, based on a few preprocessing tags embedded in C++ comments. So it is not a 100% compile-time library. Also when using plugins, a fair bit of template code is used, for instantiating objects, smart pointers, executing functions on foreign interfaces and so on. Using plugin objects becomes almost transparent in many cases. More information is available here: http://dynobj.sourceforge.net Now, I wonder if there is any interest from Boost in this type of library. At this time, I'm not eager to do a complete rewrite, since it fills our needs pretty much as it is. If there is some interest, and the basic approach and design is found useful to Boost, I'd be willing to take this some steps further, time permitting. Also, general feedback and experience with the library is appreciated. Best Regards Arne Steinarson, Z-Soft

1 0

[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