Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-11 17:08:53

"George van den Driessche" <grebe_at_[hidden]> writes:

>> > Once you've made that split, then you can add:
>> > (c) Expose the types to Lua using the objects created by (a).
>> > (d) Expose the types to <language-of-your-choice> using the objects
> created
>> > by (a).
>> > (e) Serialise the types, using results of (a).
>> This I have serious doubts about. What you'd expose for Python/Lua
>> binding would be an object's public interface: its abstraction. In
>> order to do serialization in that way, you'd likely have to expose an
>> object's guts: its implementation details.
> Yes, but in Boost.Python you're really saying two things for each type:
> (a) Here's my type's internal structure.

Emphatically no. In Boost.Python you describe a new Python type's
public interface. Its interface doesn't have to have any relationship
to that of the C++ type.

> (b) Here's how to present the internal structure to Python.
> I think this fact is slightly disguised because the two steps are both
> performed by the def() function.

Believe me, I understand that there are two things happening there,
and the Langbinding project aims to separate those two things. But
when doing language binding you are definitely *not* describing
internal structure. The two things are:

  i. Describe the external interface to the new type.
  ii. Turn that interface description into an actual Python type.

> But the fact that it takes
> pointers-to-members is a giveaway.

The fact that you are generally binding member functions (and only
public ones) is also a dead giveaway. What Rene said may be true
(that most types can be serialized and reconstructed through their
public interface), but it's not a foregone conclusion.

> Part (b) here corresponds to the extra
> data that you attach to exposed members, such as return_internal_reference.
> In a serialisation library, you're saying two things too:
> (a) Here's my type's internal structure.
> (b) Here's how to write the structure to a file, and read it back.
> In fact, if your classes are appropriately exposed to Python, you could just
> pickle them in Python and you'd be done.

*If* they expose enough information to be picklable. >>> And note
that Boost.Python has explicit support for pickling, which rather
strongly hints that the information you supply it for ordinary class
wrapping is usually not sufficient for serialization. <<<

> Maybe it would help to describe how I arrived at the idea I'm
> suggesting.

No offense, but probably not; you're not the first one to think that
the ideas behind Boost.Python could be used to build a generalized
reflection library. If you search this mailing list's history and
that of the Python C++-sig I think you'll find some other
conversations along these lines. It's a fine idea; I just have a
hard time believing that the information you need to expose for
serialization is normally the same as what you need to expose for
language binding. Maybe the same front-end interface code can be
used to do the exposing, but whatever the user writes for one is not
going to magically work for the other.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at