![](https://secure.gravatar.com/avatar/008ec2a5b8431756507d3ef61eda3e97.jpg?s=120&d=mm&r=g)
Hi Tobias,
unknown type code: P 1 unknown type code: ??? -178968160 77
that falls in the category "should never happen." Arguments are passed as a patch of memory, with a type code indicating how the individual arguments should be treated. The only way this can be wrong, is if the offset is wrong. I don't understand how that can happen: the offset is provided at run-time by the backend, where it is compiled in. The pypy-side module then uses that offset, so there should be only one value throughout. Still, is pypy-c build with a different compiler than the pip? Not that I think that's the problem, but maybe it provides some clues. Also, can you try the following (this is not a public interface): % pypy-c
import cppyy cppyy.gbl.gInterpreter.Declare("""class MyClass { .... public: .... MyClass(int i = -99) : m_myint(i) {} .... .... int GetMyInt() { return m_myint; } .... void SetMyInt(int i) { m_myint = i; } .... .... public: .... int m_myint; .... };""") True from cppyy.gbl import MyClass m = MyClass(42) print m.m_myint 42
(The reason this is not a public interface, is b/c I want to hide all this behind an interface that mimics cffi, call it cppffi. Lacking time, though, so if anyone is interested? :) ) Anyway, I expect it to give the same problem, but if it does, it excludes one other place where the bug could hide. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net