Robert Dailey | 1 Oct 01:00
Picon

Re: [python] Setting a pointer into an object

On Tue, Sep 30, 2008 at 4:05 PM, Robert Dailey <rcdailey <at> gmail.com> wrote:
> On Tue, Sep 30, 2008 at 3:14 PM, David Abrahams <dave <at> boostpro.com> wrote:
>> Just wrap the class without exposing any of its interesting parts and
>> you should be fine:
>>
>>    class_<SomeClassOfMine>("SomeClassOfMine");
>
> Thanks David.
>
> After I posted my original inquiry I found out through PyErr_Print()
> that it needed the class to be exposed to Python. However, I no longer
> wish to expose the class, but instead I want to define a global
> function in a python script that I'm loading.
>
> For example, I would add this function to the namespace that I pass
> into exec_file().
>
> The C++ function I want to expose looks like:
>
> static Rocket::Core::Context* GetContext( std::string const& context_name );
>
>
> All I'm doing is this:
>
> boost::python::object MyNewFunction( &GetContext );
>
> However, when I compile this I get:
>
> error C2027: use of undefined type
> 'boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<T>'
(Continue reading)

Joel de Guzman | 1 Oct 05:32
Picon
Favicon

Re: phoenix::bind

Peter Dimov wrote:

 >>> With boost::bind and a suitably defined f, one can do
>>>
>>>    boost::bind( f, 0, 0, _1 )
>>>
>>> to approximate a lambda with two local variables, initially 0, and 
>>> one argument.
>>
>> That's a nice trick! That can be quite useful on certain occasions.
> 
> If you manage to include both Phoenix and boost::bind, you can do a 
> generator function that returns 1, 2, 3... with:
> 
>    boost::bind<int>( ++arg1, 0 )
> 
> Of course if you have Phoenix you should be able to do the same with
> 
>    lambda( _a = 0 )[ ++_a ]
> 
> but it doesn't seem to work. Maybe I'm doing something wrong. :-)

Maybe you want:

     let(_a = 0)[ ++_a ]

and herein I think lies the general misconception about Phoenix
lambda (and possibly a flaw in the general API).

The bottom line is that lambda introduces a new scope. It is
(Continue reading)

Phil Bouchard | 1 Oct 06:26

Re: [simple_segregated_storage] segfault


"Chris Newbold" <Chris.Newbold <at> mathworks.com> wrote in message 
news:6F6A2FC198A0F943ACC2259C38A2E30B6B6FB4BD92 <at> EXCHANGE-AH.ad.mathworks.com...
>> From: boost-bounces <at> lists.boost.org 
>> [mailto:boost-bounces <at> lists.boost.org]
>> On Behalf Of Phil Bouchard
>> Sent: Tuesday, September 30, 2008 4:04 AM
>
>> I just tried the same problem today on Linux but using the latest Boost
>> 1.36
>> and I had the exact same crash.
>
> Hmm. What version of GCC are you using?
>
> One thing I found is that your shifted_ptr_test2 would not compile with 
> the version of GCC I'm using (4.1.2) unless I moved the patches to 
> list.tcc and stl_list.h out of the way.
>
> Are those patches "required"?

I'm using version 3.4.5.  The patches are required to make the pool crash, 
yes.  All allocations end up using order_malloc() so this function causes 
problems.

I will try out GCC 4...

-Phil

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Joel de Guzman | 1 Oct 06:28
Picon
Favicon

Re: Phoenix and perfect forwarding

David Abrahams wrote:
> on Tue Sep 30 2008, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
> 
>> Compilers are starting to support rvalue references.
>> Wouldn't it be pertinent to use that to implement perfect forwarding, if available?
>>
>> Phoenix could surely benefit from that.
> 
> Not to mention varargs templates.

Agreed.

Regards,
--

-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net

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

Joel de Guzman | 1 Oct 06:54
Picon
Favicon

Re: [Phoenix] review

Giovanni Piero Deretta wrote:
> - Please always state in your review, whether you think the library should be
>   accepted as a Boost library!
> 
> Having to review a library that is already expected to change is hard,
> OTOH functional programming in c++ need to go beyond boost.lambda
> (which has been basically in maintenance mode for a long time), and I
> think that Phoenix is the way to the future. Thus I think that Phoenix
> should be accepted.

Thank you.

> I support having an extra mini review after the implementation has
> been updated, but my vote is not under this condition.
> 
> I think that the review plan proposed by Eric is great.
> 
> - What is your evaluation of the documentation?
> 
> I think that documentation of Phoenix is probably the most important
> part of the library and I consider it of high quality: I've been an
> happy lambda user for a couple of years. I went beyond its documented
> interface and started to play with its internal. I've been able to add
> lazy functions to lambda and other nice additions. But I would never
> even have attempted that if I hadn't been exposed to the Phoenix
> documentation.
> 
> I've never really used the phoenix library, but I've read its
> documentation many times (starting maybe 4 years ago, I think it was
> the old V1 documentation). I remember that the first time I read it I
(Continue reading)

Phil Bouchard | 1 Oct 08:53

Re: [simple_segregated_storage] segfault


"Chris Newbold" <Chris.Newbold <at> mathworks.com> wrote in message 
news:6F6A2FC198A0F943ACC2259C38A2E30B6B6FB4BD92 <at> EXCHANGE-AH.ad.mathworks.com...
>> From: boost-bounces <at> lists.boost.org 
>> [mailto:boost-bounces <at> lists.boost.org]
>> On Behalf Of Phil Bouchard
>> Sent: Tuesday, September 30, 2008 4:04 AM
>
>> I just tried the same problem today on Linux but using the latest Boost
>> 1.36
>> and I had the exact same crash.
>
> Hmm. What version of GCC are you using?
>
> One thing I found is that your shifted_ptr_test2 would not compile with 
> the version of GCC I'm using (4.1.2) unless I moved the patches to 
> list.tcc and stl_list.h out of the way.
>
> Are those patches "required"?

I have compiled the application using GCC 4.3.0 with Boost 1.35 and I got a 
similar crash:

#0  0x0041ca66 in boost::simple_segregated_storage<unsigned 
int>::try_malloc_n (start=@0x22fd9c, n=15, partition_size=4)
        at simple_segregated_storage.hpp:234
#1  0x0041cb58 in boost::simple_segregated_storage<unsigned int>::malloc_n 
(this=0x48d030, n=16, partition_size=4)
        at simple_segregated_storage.hpp:256
#2  0x00420a4d in 
(Continue reading)

John Maddock | 1 Oct 13:32
Picon

Re: Win64 and abi_prefix.hpp/abi_suffix.hpp warnings

Juergen Hunold wrote:
> Could you please add the sentence as comment to prefix.hpp ? This
> would make things much clearer for the reader ;-))

Done, also committed the fix to trunk.

> It seems the x64 fix is the right way. Simply disabling the warning
> is a bad thing. But disabling and reenabling the warning in every
> place is a tedious job. Please find my try at this attached.

Can you file Trac-tickets for these and assign to the appropriate library 
authors?

Many thanks, John. 

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

Chris Newbold | 1 Oct 13:58
Picon
Favicon

Re: [simple_segregated_storage] segfault

> From: boost-bounces <at> lists.boost.org [mailto:boost-bounces <at> lists.boost.org]
> On Behalf Of Phil Bouchard
> Sent: Wednesday, October 01, 2008 2:53 AM

> I have compiled the application using GCC 4.3.0 with Boost 1.35 and I got
> a
> similar crash:

With your latest updates to the shifted_ptr code I've been able to compile w/ GCC 4.1.2 and reproduce a
crash; it looks a little different than the one you posted, but at least now I've got something to dig into.
Stay tuned.

#0  0x000000000040378a in boost::details::PODptr<unsigned long>::next (this=0x7fff6e0ff760) at /mathworks/devel/sandbox/cnewbold/boost-trunk/boost/pool/pool.hpp:121
#1  0x0000000000404194 in boost::pool<boost::default_user_allocator_new_delete>::find_POD
(this=0x52fe60, chunk=0x531470)
    at /mathworks/devel/sandbox/cnewbold/boost-trunk/boost/pool/pool.hpp:576
#2  0x00000000004041f5 in boost::pool<boost::default_user_allocator_new_delete>::is_from
(this=0x52fe60, chunk=0x531470)
    at /mathworks/devel/sandbox/cnewbold/boost-trunk/boost/pool/pool.hpp:276
#3  0x000000000040ee85 in boost::detail::sh::shifted_ptr<node>::operator=<node>
(this=0x7fff6e0ff8b0, p=0x533490) at ../../../boost/shifted_ptr.hpp:217
#4  0x00000000004108fc in list::insert (this=0x7fff6e0ff8a0) at shifted_ptr_test2.cpp:49
#5  0x00000000004017c0 in main () at shifted_ptr_test2.cpp:85

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

Hartmut Kaiser | 1 Oct 14:30
Picon
Gravatar

[Phoenix] Review ended September 30th

Hi all,

just a (last) reminder for all of you still wanting to submit a review. The
official review period is over, but since I'm going prepare the review
summary this weekend only anyway - you still have a day or two.

Regards Hartmut
Review Manager
Picon

Re: Final report of GSOC project 'Spatial Indexes'

>
> This is a very interesting project, it's filling an huge gap and soo many
> projects need to reimplement these structures.
>
> I have one early question, have you considered pushing the quadtree and
> rtree classes into boost::intrusive, or designing them in the spirit of
> boost::intrusive?
> The audience who's in need of large spatial databases (the ones who doesn't
> need it are fine with linear scans) is likely to hunt for performance. IMO
> boost::intrusive has given a flexibility to c++ containers not available
> elsewhere, it'd be a clear winner if your quadtree and rtree can be
> implemented in generic terms.
>

Christian,

I don't have experience with boost::intrusive, but I'll check it out to see
if it fits with the spatial indexes.

Thanks for your suggestion!

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


Gmane