namespace boost { namespace python
{
  class list : public
                                                        ^^^^

BTW, compare this with the HTML source for list.html and you'll see
one of the main reasons people hate HTML to be edited with WYSIWYG
tools.  Sticking 
 tags in a  block is just insane.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From dave at boost-consulting.com  Wed Jan 14 06:02:49 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 14 Jan 2004 00:02:49 -0500
Subject: [C++-sig] Re: New slice implementation
References: <1073361918.13426.31.camel@illuvatar> 
	<1073518393.1796.15.camel@illuvatar> 
	<1073595081.19758.430.camel@illuvatar> 
	<1073620180.19759.565.camel@illuvatar> 
	<1073665816.19758.775.camel@illuvatar> 
	<65fk1opl.fsf@boost-consulting.com>
	<1073970573.27246.67.camel@illuvatar>

	<1074047914.1215.43.camel@illuvatar>

Message-ID: 

David Abrahams  writes:

> BTW, compare this with the HTML source for list.html and you'll see
> one of the main reasons people hate HTML to be edited with WYSIWYG
> tools.  Sticking 
 tags in a  block is just insane.

Not that you're insane; it's your editor ;-)

Note also:

  slice::get_indicies(RandomAccessIterator const& begin, RandomAccessIterator const& end);

Is probably too wide and should be wrapped:

  slice::get_indicies(
      RandomAccessIterator const& begin, RandomAccessIterator const& end);

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From IJRICHARDS at mail.dstl.gov.uk  Wed Jan 14 12:52:23 2004
From: IJRICHARDS at mail.dstl.gov.uk (Richards Ian J)
Date: Wed, 14 Jan 2004 11:52:23 -0000
Subject: [C++-sig] GNU Problem 
Message-ID: <85AC030236CCD41182790002A52CFED90ADA4C86@mail.dstl.gov.uk>

Mike,

I saw of the web that you had a problem back in Nov 02 where you were
getting a SIGSEGV due to dyn-string.c (see link below). I know it was a long
time ago, but did you find a solution? I am getting the same error but can't
see what I am doing wrong, so I am thinking that it is deeper issue.

Best regards,

Ian Richards.

http://mail.python.org/pipermail/c++-sig/2002-November/002708.html

"This e-mail is intended for the recipient only.  If you are not the
intended recipient you must not use, disclose, distribute, copy, print,
or rely upon this e-mail. If an addressing or transmission error has
misdirected this e-mail, please notify the author by replying to this e-mail."

"Recipients should note that all e-mail traffic on MOD systems is
subject to monitoring and auditing."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dave at boost-consulting.com  Wed Jan 14 13:40:48 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 14 Jan 2004 07:40:48 -0500
Subject: [C++-sig] Re: gcc 3.4 pre-compiled header support?
References: <1073970247.27246.61.camel@illuvatar>
	<20040113125746.11413.qmail@web20209.mail.yahoo.com>
Message-ID: 

"Ralf W. Grosse-Kunstleve"  writes:

> Hi Janathan,
>
> Thanks for your detailed message!
>
> --- Jonathan Brandmeyer  wrote:
>> I'll be submitting bugreports for these to GCC tomorrow afternoon.
>> 
>> BTW, compiling life_support.cpp with PCH enabled (but not with it
>> disabled) resulted in this error @ line 35: "none is not a member of
>> boost::python::objects::detail".  Explicitly calling
>> ::boost::python::detail::none() fixed this error.
>  
> I'll try to check this into the main version and the 1.31 release candidate.
> David, please intervene if you don't like the idea.
>
>> I hope this is a decent starting point for you.
>
> It sounds like the PCH support is not yet fully mature. I think I'll wait a
> little while before trying it on my project. If you get a chance, could you
> please send the bug report numbers to this list? I'd like to be on the cc list
> (and maybe some other Boost.Python users, too).
>
> Ralf

If it's not yet fully mature and won't really work anyway, maybe we
should wait before uglifying Boost.Python sources to accomodate it.
The change mentioned above is arguably OK, but I'd hate to go any
further down that road.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

From mike at nospam.com  Wed Jan 14 23:24:07 2004
From: mike at nospam.com (Mike Rovner)
Date: Wed, 14 Jan 2004 14:24:07 -0800
Subject: [C++-sig] Re: GNU Problem
References: <85AC030236CCD41182790002A52CFED90ADA4C86@mail.dstl.gov.uk>
Message-ID: 

Ian,

Yes and no. AFAICR I dodge the problem by moving to another
platform/compiler;
nowadays I use MSVC7.1 on WinXPpro.

However the code fragment is just:
    class_("Obj").add_property("name", &Obj::Name);
and it's enough.

I'll try to recheck with more recent gcc and bpl on some solaris and or
linux platform
but for some reasons it may take time.

Regards,
Mike

"Richards Ian J"  wrote in message
news:85AC030236CCD41182790002A52CFED90ADA4C86 at mail.dstl.gov.uk...
Mike,

I saw of the web that you had a problem back in Nov 02 where you were
getting a SIGSEGV due to dyn-string.c (see link below). I know it was a long
time ago, but did you find a solution? I am getting the same error but can't
see what I am doing wrong, so I am thinking that it is deeper issue.

Best regards,

Ian Richards.

http://mail.python.org/pipermail/c++-sig/2002-November/002708.html
"The Information contained in this E-Mail and any subsequent correspondence"
"is private and is intended solely for the intended recipient(s)."
"For those other than the recipient any disclosure, copying, distribution, "
"or any action taken or omitted to be taken in reliance on such information
is"
"prohibited and may be unlawful."

_______________________________________________
C++-sig mailing list
C++-sig at python.org
http://mail.python.org/mailman/listinfo/c++-sig

From topology at eircom.net  Fri Jan 16 00:26:00 2004
From: topology at eircom.net (Brian Peters)
Date: Thu, 15 Jan 2004 23:26:00 +0000
Subject: [C++-sig] wrapping interfaces and supplied implementations
Message-ID: <40072187.CBC15DBF@eircom.net>

Hello All,

I'd like first to thank the Boost.Python team and commend them on their
creation. Dave Abrahams et.al. have implemented code the likes of which
I could not even have conceived, let alone writen. Boost MPL is not
something I could ever have thought up. My hope is simply that someone
some day finds my work as useful and impressive as I find theirs.

I am trying to wrap a library that implements a generic programming
approach to computational geometry and topology. To achieve this it
defines a number of interfaces it requires to do its job. For developers
who do not wish to code the details of these interfaces it also supplies
concrete implementations.

Having observed Dave Abrahams' penchant for a working test case I have
developed a sandbox representing a portion of the library. It has three
classes that are abstract base  classes: IFacade, IManager, and
IProduct. All their pure virtual methods are defined using raw pointers
to abstract base classes.

The idea is that an application asks the facade for a manager [
IManager* IFacade::manager() ] and then uses the manager to create
products [ IProduct* IManager::create(inti i) ]. The products have state
that may be changed by the client or other operations of the facade. The
manager can also store and retrieve products.

A simple user can use the concrete Manager and Product classes supplied
through these interfaces, but a more advanced user could derive their
own product and manager from the abc's and pass that into the facade [
void IFacade::setManager(IManager* manager) ]. The old addage applies:
"The simple should be easy, but the complex should be possible." i.e use
the supplied system if you want, but you can always over ride it with
something more complex.

So now I want to be able to do the same thing in Python. I want to wrap
everything so that a simple user can:
* see the abstract base classes in python;
   i.e. the interfaces, their doc strings, etc.
* use the supplied implementation of manager and product
* derive their own products and manager if they want/need to in python

Well, I got it all working! Not only working, but doing cool python
stuff too. Being new to python I have found it interesting that
arbitrary attributes and methods can be added to any object regardless
of its class.

I think of a wrapped Product passed out to python from the supplied
Manager class as a python envelope containing the C++ Product. I can
scribble on that envelope. Spill coffee on it. Crumple it up a bit. I
can store it in the manager and throw it away. When I later retrieve
from the manager, not only is it the same C++ Product (i.e same
address), but it is the same PyObject (i.e. same address, or "id" as
they call it in the interpreter), AND it even has the same note
scribbled on it and the coffee stain! Its like decorating C++ classes
dynamically at run time.

I thought the article about C++/Python integration was cool when I read
it a few months ago, but now I really see it. The line between Python
and C++ is very fluid. (
http://www.cuj.com/documents/s=8188/cuj0307abrahams )

The code is attached below. For reference I am using the following
(admittedly somewhat dated) environment:
*  Python 2.2.2
*  Boost 1.30.0
*  Windows NT4 with MSVC6
*  RH linux 2.4.2-2 with g++ 1.96

I am offering this example to anyone that finds it useful. It is more
complex than the examples I found in the documentation and code, yet
still simple enough to examine in detail.

I am hoping that those in the know will tell me if I have done anything
terribly wrong. I will gladly explain why I have done things the way I
have and/or share the verbose version of this sandbox that contains a
lot more testing functions and cout's. This message is already too long
to do so here.

thanks,
bfp

======================
> Brian Peters
>  topologyeircomnet

===============================================================================

============ abcdf_ext.cpp
====================================================

#include 
#include 
#include 

using namespace boost::python;

// --- component code -----------------------------------------------
// published interfaces
struct IProduct
{
  virtual ~IProduct() {}
  virtual int value() const = 0;
  virtual void set(int i) = 0;
  virtual int other(IProduct* product) const = 0;
};

struct IManager
{
  virtual ~IManager() {}
  virtual IProduct* create(int i) = 0;
  virtual IProduct* modify(IProduct* product) = 0;
  virtual int store(IProduct* product) = 0;
  virtual IProduct* retrieve(int index) = 0;
};

struct IFacade
{
  static IFacade* instance();
  virtual ~IFacade() {}
  virtual IManager* manager() = 0;
  virtual void setManager(IManager* manager) = 0;
  virtual void update(int i) = 0;
  virtual std::string notice() const = 0;
};

// supplied implementation of interfaces.
// only exposed through pointers to the above interfaces.
#define MANAGER_CAPACITY 10
struct Product : IProduct
{
  Product(int i): _i(i) {}
  virtual ~Product() {}
  virtual int value() const
    {
    return _i;
    }
  virtual void set(int i)
    {
    _i = i;
    }
  virtual int other(IProduct* product) const
    {
    int v = -10; // TODO Should I throw if NULL == product???
    if (product)
      v = product->value();
    return _i*1000 + v;
    }
  int _i;
};

struct Manager : IManager
{
  Manager(): mCount(0)
    {
    memset(mProducts, 0, sizeof(mProducts));
    }
  virtual ~Manager() {}
  virtual IProduct* create(int i)
    {
    return new Product(i);
    }
  virtual IProduct* modify(IProduct* product)
    {
    product->set(2 * product->value());
    return product;
    }
  virtual int store(IProduct* product)
    {
    int index = -1;
    if (MANAGER_CAPACITY > mCount)
      {
      index = mCount;
      mProducts[mCount++] = product;
      }
    return index;
    }
  virtual IProduct* retrieve(int index)
    {
    IProduct* product = NULL;
    if (MANAGER_CAPACITY > index)
      product = mProducts[index];
    return product;
    }
  int mCount;
  IProduct* mProducts[MANAGER_CAPACITY];
};

struct Facade : IFacade
{
  Facade(): mManager(new Manager) {}
  virtual ~Facade() {}
  virtual IManager* manager()
    {
    return mManager;
    }
  virtual void setManager(IManager* manager)
    {
    // TODO Deleting the old manager will cause trouble if it has
    // already been sent out to python. How do I want to handle this?
    //if (mManager)
    //  delete mManager;
    mManager = manager;
    }
  virtual void update(int delta)
    {
    // TODO get a product iterator from IManager here.
    IProduct* product;
    for (int i=0; i < MANAGER_CAPACITY; i++)
      {
      if (NULL != (product = mManager->retrieve(i)))
        product->set(product->value() + delta);
      }
    }
  virtual std::string notice() const
    {
    return "IFacade::notice() message: hello world!";
    }
  IManager* mManager;
};

// the singleton
IFacade* theFacade = NULL;
IFacade* IFacade::instance()
  {
  if (NULL == theFacade)
    theFacade = new Facade();
  return theFacade;
  }

// --- B.P.L. wrapper code -------------------------------------------
// rudimentary exception class
struct error
{
  error(std::string message): _msg(message) {}
  std::string const _msg;
};

// ProductProxy provides abc methods to pass IProduct* to python.
struct ProductProxy : IProduct
{
  ProductProxy(IProduct* product) : mProduct(product) {}
  virtual ~ProductProxy() {}
  virtual int value() const
    {
    if (!mProduct)
      throw error("Bad proxy");
    return mProduct->value();
    }
  virtual void set(int i)
    {
    if (!mProduct)
      throw error("Bad proxy");
    mProduct->set(i);
    }
  virtual int other(IProduct* product) const
    {
    if (!mProduct)
      throw error("Bad proxy");
    return mProduct->other(product);
    }
  // this virtual function is overridden in ProductBase
  virtual int otherWrap(object& product) const
    {
    if (!mProduct)
      throw error("Bad proxy");
    ProductProxy* proxy =
arg_from_python(product.ptr())(product.ptr());
    return mProduct->other(proxy);
    }
  IProduct* mProduct;
};

// ProductBase is the heldtype for ProductProxy to let python derive
from IProduct.
struct ProductBase : ProductProxy
{
  ProductBase(PyObject* pyobject): ProductProxy(NULL), mSelf(pyobject)
{}
  virtual ~ProductBase() {}
  virtual int value() const
    {
    return call_method(mSelf, "value");
    }
  int default_value() const
    {
    std::ostringstream msg;
    msg << mSelf->ob_type->tp_name << " missing implementation of
function 'value'";
    throw error(msg.str());
    }
  virtual void set(int i)
    {
    call_method(mSelf, "set", i);
    }
  void default_set(int i)
    {
    std::ostringstream msg;
    msg << mSelf->ob_type->tp_name << " missing implementation of
function 'set'";
    throw error(msg.str());
    }
  virtual int other(IProduct* product) const
    {
    ProductProxy proxy(product);
    return call_method(mSelf, "other", ptr(&proxy));
    }
  // this virtual function is overridden from ProductProxy
  virtual int otherWrap(object& product) const
    {
    return call_method(mSelf, "other", product);
    }
  int default_other(object& product) const
    {
    std::ostringstream msg;
    msg << mSelf->ob_type->tp_name << " missing implementation of
function 'other'";
    throw error(msg.str());
    }
  PyObject* mSelf;
};

// ManagerProxy provides abc methods to pass IManager* to python.
struct ManagerProxy : IManager
{
  ManagerProxy(IManager* manager): mManager(manager), mCount(0) {}
  ManagerProxy(ManagerProxy& manager)
  : mManager(manager.mManager), mCount(manager.mCount)
    {
    for (int i=--mCount; 0 <= i; --i)
      mProducts[i] = manager.mProducts[i];
    }
  virtual ~ManagerProxy() {}
  virtual IProduct* create(int i)
    {
    if (!mManager)
      throw error("Bad proxy");
    return mManager->create(i);
    }
  // this virtual function is overridden in ManagerBase
  virtual object createWrap(int i)
    {
    if (NULL == mManager)
      throw error("Bad proxy");
    return object(ptr(new ProductProxy(mManager->create(i))));
    }
  virtual IProduct* modify(IProduct* product)
    {
    if (NULL == mManager)
      throw error("Bad proxy");
    return mManager->modify(product);
    }
  // this virtual function is overridden in ManagerBase
  virtual object modifyWrap(object& product)
    {
    if (NULL == mManager)
      throw error("Bad proxy");
    ProductProxy* proxy =
arg_from_python(product.ptr())(product.ptr());
    mManager->modify(proxy);
    return product;

    // IManager::modify returns its argument, but if another function
might not, do this:
    //IProduct* value = mManager->anotherFunction(proxy);
    //return value == proxy ? product : object(ptr(new
ProductProxy(value)));
    }
  virtual int store(IProduct* product)
    {
    return mManager->store(product);
    }
  virtual int storeWrap(object& product)
    {
    ProductProxy* proxy =
arg_from_python(product.ptr())(product.ptr());

    // make sure side effects will happen
    mManager->store(proxy->mProduct);

    int index = -1;
    if (MANAGER_CAPACITY > mCount)
      {
      index = mCount;
      mProducts[mCount++] = product;
      }
    return index;
    }
  virtual IProduct* retrieve(int index)
    {
    return mManager->retrieve(index);
    }
  virtual object retrieveWrap(int index)
    {
    // make sure side effects will happen
    mManager->retrieve(index);

    if (MANAGER_CAPACITY > index)
      return mProducts[index];
    else
      return object(); // python's None
    }
  IManager* mManager;

  // just mirror the Manager approach to storage for sandbox
  int mCount;
  object mProducts[MANAGER_CAPACITY];
};

// ManagerBase is the heldtype for ManagerProxy to let python derive
from IManager.
struct ManagerBase : ManagerProxy
{
  ManagerBase(PyObject* pyobject): ManagerProxy(NULL), mSelf(pyobject)
{}
  virtual ~ManagerBase() {}
  virtual IProduct* create(int i)
    {
    object product = call_method