[Ns-developers] NS-3 PyBindGen again

[Gustavo Carneiro]

On 07/01/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>
>
> On Mon, 2008-01-07 at 13:52 +0000, Gustavo Carneiro wrote:
>
> >         >  but this code compiles which appears to indicate it can be
> >         done.  I
> >
> >         This is really weird because my c++ spec states clearly that
> >         it is not
> >         possible to copy std::type_info objects. i.e., their copy
> >         constructor
> >         and assignment operators are expected to be private.
> >
> > I ran into that problem, but then I changed the return type to "const
> > std::type_info &".  Returning by reference does not require copying,
> > so all is well.  Same could be done with TraceDoc, but TraceDoc offers
> > a list of  strings, with each parameter type, matching by a single
> > type name string is much easier.
>
> Are you sure that it is safe to assume that string equality of the
> type_info::name () value is equivalent to std::type_info equality ?


Yes.  Don't worry, I know what I'm doing :-)

Actually it's the reverse that can cause problems.   Two type_info instances
may compare different yet refer to the same type.  This happens when
comparing type_info's from two different shared libraries, where one
dlopen's another, and uses a RTLD_LOCAL flag (to make the loaded symbols
private scope).  Kind of hard to explain what triggers it, but it is not the
case of the python bindings, I'm sure.  And even if it were true, matching
by type name always works, although comparing strings is somewhat slower
than comparing type_info's (type_info's are compared by address, these
days).

>
> >
> >         > This API (template <typename T> bool GetElement (T &context)
> >         const) is
> >         > based on templated methods.  I need to generate all method
> >         template
> >         > instantiations, but then the method names have to be mangled
> >         with the
> >         > type names.  Again, adding dynamic introspection features to
> >         the C++
> >         > API would be most welcome for Python bindings, else user
> >         will have to
> >         > call methods with mangled names.
> >
> >         Clearly, asking the user to use mangled names is not a
> >         practical
> >         solution.
> >
> > Well, this is one more example among many where NS-3 is favouring C++
> > programming in detriment of language bindings.  I have known this for
> > a very long time, and accept it.  That's why it is perhaps prudent to
> > not wait until NS-3 API is finalized to start making language
> > bindings, because making these bindings will shed some light on what
> > needs to be improved in the API in order to better support them...
>
> This specific problem is quite similar to the problem of binding the
> Packet and Tags classes, I think. I don't have any specific solution to
> this problem but it is something which we need to addressed before the
> february release if you want to target that release for merging.


You are putting the stakes too high for me.  I don't mind spending some more
"background" time working on this, but I cannot commit to any specific
deadline.  Sorry.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert