gmane.comp.lib.boost.devel

[1.50] [Config] Enhancing support of -fno-rtti on clang

Michel Morin — 2012-05-25T22:59:26

When using clang with -fno-rtti, the use of `typeid` results in
either compile-time errors or run-time errors.

But Boost.Config did not define BOOST_NO_TYPEID for that case.
So, for example, including any client header of BOOST_SP_TYPEID
produced compiler errors on clang trunk with -fno-rtti.

This was fixed in r78510 about a week ago:
(http://svn.boost.org/trac/boost/changeset/78510)

    -#if !__has_feature(cxx_rtti)
    +#if !__has_feature(cxx_rtti) && !defined(BOOST_NO_RTTI)
     #  define BOOST_NO_RTTI
     #endif

    +#if !__has_feature(cxx_rtti) && !defined(BOOST_NO_TYPEID)
    +#  define BOOST_NO_TYPEID
    +#endif

If Boost would like to enhance the support of -fno-rtti on clang,
it would be good to merge the fix into the release branch.

I ran the test runner (clang trunk with -fno-rtti) for
unpatched release branch and patched release branch.
There was no regression and more than 1000 test results got
improved.


Regards,
Michel

_______________________________________________
Unsubscribe & othe

Re: [python] incorrect use of keywords and, or, etc

Jeffrey Lee Hellrung, Jr. — 2012-05-25T18:21:46


Sounds like a legitimate issue (as far as working around MSVC
deficiencies); file a trac ticket and attach a patch?

- Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[python] incorrect use of keywords and, or, etc

lcaminiti — 2012-05-25T15:37:45

Hello all,

Boost.Python uses operator keywords in macro expansion. This is a bad idea
because on some compilers like MSVC that implement and, or, etc using macros
#define to &&, ||, these macros will not expand correctly when ciso646 is
included before including python.hpp.

#include <ciso646>

// boost/python/operators.hpp
BOOST_PYTHON_BINARY_OPERATOR(and, rand, &)
BOOST_PYTHON_BINARY_OPERATOR(or, ror, |)
...

This will actually expand to:

BOOST_PYTHON_BINARY_OPERATOR(&&, rand, &)
BOOST_PYTHON_BINARY_OPERATOR(||, ror, |)

And then expand the macro causing a compiler error because the operator code
will have names like op_&&, op_||, etc instead of the intended op_and,
op_or, etc.

An easy and safe fix should be to change the macro to move the _ to the
macro call:

BOOST_PYTHON_BINARY_OPERATOR(_and, rand, &)
BOOST_PYTHON_BINARY_OPERATOR(_or, ror, |)

Now _and, _or, etc are no longer keywords so it's safe to use them.

--Lorenzo


--
View this message in context: http://boost.2283326.n4.nabble.com/boost-pyth

[python] run python script from bjam

lcaminiti — 2012-05-25T14:18:50

Hello all,

I build a Boost.Python module and install it using bjam as follow:

    python-extension pydef : deduced_params_pydef.cpp
        :   <library>/boost/python//boost_python
            <library>/boost/regex//boost_regex
            <link>shared:<define>BOOST_REGEX_DYN_LINK=1
        ;
    install pydef_install : pydef
        :   <install-dependencies>on
            <install-type>SHARED_LIB
            <install-type>PYTHON_EXTENSION 
            <location>. 
        ;

I the same dir I have a python script deduced_params_pydef.py which will
import the module and test it.

How do I run the python script automatically from bjam so to fully compile
and test the module that my code generates?

Something like (this doesn't work of course):

# Make sure pydef target is built first, then runs python
deduced_params_pydef.py
run-py pydef_install : deduced_params_pydef.py ;

Thanks a lot.
--Lorenzo



--
View this message in context: http://boost.2283326.n4.nabble.com/boost-python-run-python-script-from-bjam

Re: [range] Boost.Range induced regression, is there somewhere a change?

Barend Gehrels — 2012-05-25T12:19:53

Hi again,

On 25-5-2012 13:46, Barend Gehrels wrote:


Found the answer myself. We compare id.ring_index < 
boost::size(interior_rings(polygon), where ring_index can be -1.

boost::size's result changed from signed to unsigned. Therefore the 
assertion is triggered.

The change on itself is fair, done at April 15: 
https://svn.boost.org/trac/boost/changeset/77990

I can fix Boost.Geometry for it, of course, now that we know this. But 
it might break other code as well.

Besides this "breaking", it also can cause new warnings about 
signed/unsigned comparisons (which is very useful).

Regards, Barend



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[range] Boost.Range induced regression,is there somewhere a change?

Barend Gehrels — 2012-05-25T11:46:14

Hi,

Is there something changed in Boost.Range?

Background: I just noticed that there appeared many failing issues 
(yellow squares) in the Boost.Geometry regression matrix here:

http://www.boost.org/development/tests/trunk/developer/geometry.html

I checked the assemble square and it gives me an assertion: Assertion 
`id.ring_index >= -1 && id.ring_index < 
boost::size(interior_rings(polygon))'

Because this did not use to be the case, I did run the test on my local 
machine and it was OK. Then I updated some Boost libraries (manually, 
separately) and as soon as I updated Boost.Range this exception did appear.

So the regression is somehow caused by a change in Boost.Range. I did 
not yet research it further, it might be that we do something wrong here 
that was previously accepted but now is not, but it still stays an 
unexpected regression...

Is there someone who has any idea what introduced this?

Thanks, Barend



_______________________________________________
Unsubscribe & other changes: http://li

Re: C++ Standards Committee membership for Boost?

Dave Abrahams — 2012-05-25T10:31:16

on Thu May 10 2012, Nathan Ridge <zeratul976-AT-hotmail.com> wrote:


And there's some indication that said nature may be changing.  Stay
tuned...

[msm] orthogonal region and event consume

Takatoshi Kondo — 2012-05-25T08:48:54

Hello Christophe,

I'm using Boost.MSM version 1.49.0. I bumped on a suspicious behavior.
See the attached diagram and code. When Event1 occurs in State1,
Action1 is invoked.

I think the event isn't consumed correctly.

If the transition from State1 to State2 connect State2 directly
instead of Entry1, the event seems to be consumed.

What do you think?

Thanks,
Takatoshi

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Formal Review Request: TypeErasure

Steven Watanabe — 2012-05-25T02:16:45

AMDG

On 05/24/2012 04:21 PM, Jeremy Maitin-Shepard wrote:

The situation is one that isn't even
allowed with C++ references:

int & const ref = i; // error

The problem with
const any<Concept, _self&> xx;
is that anything that isn't specially
designed to handle it will see the
const and treat it as const.  Some
parts of the library will work with
it, but in others it was just too
difficult.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Formal Review Request: TypeErasure

lcaminiti — 2012-05-25T00:29:25

Steven Watanabe-4 wrote

Even somethings a bit more complex but printable is OK too. I will use the
lib in some use cases that I ran into the past and let you know if I find a
nice example not too complex (I don't remember what the use cases were but
they were about type erasure).




Got it. I missed that from the docs...




Maybe I used the wrong term in saying "arbitrary". I meant it looks
arbitrary to users because it essentially just exposes a library
implementation detail (but it's clear it's a "special" base that the lib
needs you to put there for the implementation to work). There is probably no
way for getting rid of Base, Enable, etc but to use macros. I think macros
would be a nice addition as an alternative to define concepts in your lib.
I'll see what macro syntax could be implemented (especially with variadic
macros, we can do a lot of nice stuff).




Thanks.
--Lorenzo


--
View this message in context: http://boost.2283326.n4.nabble.com/Formal-Review-Request-TypeErasure-tp4630373p4630477.ht

Re: Formal Review Request: TypeErasure

Jeremy Maitin-Shepard — 2012-05-24T23:21:19


This library is indeed very interesting.  From a quick look at some of the
documentation, I have just one initial comment: I believe it is a mistake to
"propagate constness" for "any"s that capture references, as that is
inconsistent with normal C++ semantics and it leads to a situation of trying to
fight the C++ type system rather than work with it.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Formal Review Request: TypeErasure

Daniel Larimer — 2012-05-24T17:11:59

On May 24, 2012, at 12:48 PM, Steven Watanabe wrote:

- does yours support member variables? 
- or are you referring to more general concepts (operators, free functions, etc)

- not quite, you would have to extend the macro to enumerate the signature of each method.  I did this in prior versions of the code.  

that would be difficult.

What does the number 2 mean?   I think this would be great.

Good work, I will probably find use for your library in my own projects.

Dan



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Formal Review Request: TypeErasure

Steven Watanabe — 2012-05-24T16:48:22

AMDG

On 05/23/2012 11:27 PM, Daniel Larimer wrote:

It isn't as bad as you might think and I
know how to change the library to keep the
template instantation depth for the most
common errors down to 3 or 4.


It's fairly slow.  I've made no attempt to
optimize the metaprogramming at this point.


The cost is one call through a function pointer.


I'd say that this is out of scope for my
library currently.


Reflection is really a separate issue.


This is a nice interface, but it has several
limitations that I see no way around:

a) It supports member functions only
b) Overloading is impossible

Some problems can be solved with difficulty:

c) there's no way to know the number of arguments
   at preprocessing time, so you can't declare
   a regular function.

I think it would be possible to have a macro
that acts something like this for simple cases, though.


I did use macros in the implementation.
Something like this wouldn't be very
hard to implement:

BOOST_TYPE_ERASURE_MEMBER(push_back, 2)
BOOST_TYPE_E

Re: Release notes for 1.50

lcaminiti — 2012-05-24T15:24:58

Daniel James-3 wrote

I've committed release notes for ScopeExit (new features), LocalFunciton
(new library), Functional/OverloadedFunction (new library),
Utility/IdentityTtpe (new library).

I did not generate the HTML so please fix my QuickBook entries in case
there's any error (but they should be OK).




Thanks.
--Lorenzo


--
View this message in context: http://boost.2283326.n4.nabble.com/Release-notes-for-1-50-tp4630401p4630461.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

regression tests fail with no error?

lcaminiti — 2012-05-24T12:35:15

Hello all,

Some of my library regression tests occasionally fail like this:

http://www.boost.org/development/tests/release/developer/Sandia-darwin-intel-11-1-local_function-intel-darwin-11-1-add_except_seq-variants_.html

If you follow the link, there is no actual error. Plus the tests sometimes
it fails (with no actual error) and other times it passes (as it should).

Is this just a problem with the regression test parsing script?

Thanks a lot.
--Lorenzo


--
View this message in context: http://boost.2283326.n4.nabble.com/boost-regression-tests-fail-with-no-error-tp4630458.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Formal Review Request: TypeErasure

Daniel Larimer — 2012-05-24T06:27:13

I read the docs as this library is very impressive and does some of the same things I do with Boost.Reflect so I can appreciate the problem domain.

http://bytemaster.github.com/boost_reflect/group__boost__reflect__quickstart.html#boost_reflect_erasures

I would like to make comments / ask some questions:

1) More motivating examples would be useful.   Given the difficulty (verbosity/boiler plate) of implementing 'push_back', I cannot imagine using this library as an 'end coder' for custom interfaces.  The only place I could see using anything other than the built in concepts would be to simplify the development of my own APIs for my users sake, not mine. 

1.1) better documentation on what all of the template parameters mean and why they are used would be helpful.

2) I cannot begin to imagine the template errors generated by using such a complex type.  But this is par for the course with Boost.

3) How does using such an erasure effect compile times?

4) It is difficult to tell from the documentation, but

Re: Release notes for 1.50

Daniel James — 2012-05-24T04:58:50

They're up now. We used to try to avoid changing the release notes
after they'd gone live because it caused a lot of noise in people's
rss feeds. But that's less of a problem since I added link and guid
elements to feed items.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Formal Review Request: TypeErasure

Simonson, Lucanus J — 2012-05-24T04:52:30


It seems the library is a little more than that.  Have you considered naming it Boost.DuckTyping?  I think TypeErasure doesn't really capture the full scope of what you've done.

A much longer example where you use the library to implement something with some explanation of why you would want to use the library in such a case would be very helpful in the docs.  Something like Sean's value semantics document example.  For that matter, you could reimplement his document example using your library and provide draw concept and copy on write concept for types used instead of relying on inheritance.

Regards,
Luke




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Formal Review Request: TypeErasure

Steven Watanabe — 2012-05-24T03:53:19

AMDG

On 05/23/2012 07:12 PM, lcaminiti wrote:

It sounds good to me.  You're a library author,
so I'm sure the Review Wizard will be okay with it.


What about something based on any_printable?

typedef any<
  mpl::vector<
    copy_constructible<>,
    typeid_<>,
    ostreamable<> > > any_printable;

I believe that this has come up somewhere.
("Why can't I print boost::any to std::cout?")
Is this about the level of complexity
that you're thinking?


Because they represent named arguments, not
positional arguments.  I used _1, _2, etc.
in an earlier version of the library, and
some people were confused about how they
related to _1, _2 in Boost.Bind and Boost.MPL


Did you look at the doxygen/boostbook reference
for concept_interface?  Is that sufficiently clear?

I realize that my descriptions in the examples
are often a bit sparse.  Would something like
this be clearer?  Do you think it's too verbose?

in custom.cpp:
    This works, but we'd really like to call `c.push_back(10)`.
    We can add members to _

Re: Formal Review Request: TypeErasure

Nathan Ridge — 2012-05-24T02:26:44


Because Bind has dibs on _1, _2, ..., and no one wants to write
boost::type_erasure::_1?

Regards,
Nate
       

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Formal Review Request: TypeErasure

lcaminiti — 2012-05-24T02:12:54

Steven Watanabe-4 wrote

Hello Steven,

I quickly read the docs (see a couple of minor comments below). I'll compile
and play with the examples this weekend.

I'm interested in the library. If you are looking for a Review Manager, I'd
like to volunteer if that's OK with you and the Review Wizards.

Minor Comments

1) It'd be nice to have a motivating example up front (something not trivial
but not as complex as the range formatter either).

2) Why placeholders _a, _b, ... instead of _1, _2, ...?

3) I found the syntax of concept_interface difficult to understand... for
example, Base looks arbitrary. But then it's very nice to be able to
c.push_back(10) instead of call(...)

4) Same for overloaded concept_interface where both Base and Enable look
arbitrary. (I wonder if macros could generate some of the boiler-plate code
for the overload.)

5) There's a FIXME in the Reserved Identifier section.

--Lorenzo


--
View this message in context: http://boost.2283326.n4.nabble.com/Formal-Review-Request-TypeErasure-