Hi Christof,
I didn't realize I posted on the main list, so I add this thread to the dev list where I originally intended to ask ...
Changing 0 to A_NULL worked immediately. Curiously, I never noticed the impossibility to replace an enum by its int value in C++ before. That makes sense.
And as you said, it compiles with extern "C" surrounding only the setup function. In fact it even compiles without any extern "C" at all (but won't load, probably due to name mangling).
Thanks for the clear explanation. Joseph
Le 03/06/18 à 21:34, Christof Ressi a écrit :
- surround the whole code with extern "C" { ... }
I think you only have to do this with the setup function because that's the only function which gets exported (and therefore mustn't have namemangling).
candidate function not viable: no known conversion from 'int' to 't_atomtype' for 6th argument
EXTERN t_class *class_new(t_symbol *name, t_newmethod newmethod,
is you're 6th argument a '0'? looks like in C++ you can't pass an int where an enum (t_atomtype) is expected. try to pass 'A_NULL' instead.
Christof
Gesendet: Sonntag, 03. Juni 2018 um 09:40 Uhr Von: "Joseph Larralde" joseph.larralde@gmail.com An: pd-list@lists.iem.at Betreff: [PD] pd external c++ example
Hi list,
Some time ago I wrote a bunch of pd externals in C++, some using flext, some by tweaking xcode projects until they worked. Yesterday I've been trying the examples from the pure-data/externals-howto github repo, with the idea in mind to write my own clean pd library. The first example compiled right away, so I decided to tweak it to use C++ instead of C.
Here is what I did :
- rename helloworld.c to helloworld.cpp
- surround the whole code with extern "C" { ... }
- change class.sources = helloworld.c to class.sources = helloworld.cpp
in the Makefile.
And I got this error : /Applications/Pd-0.47-1-64bit.app/Contents/Resources/src/m_pd.h:476:17: note: candidate function not viable: no known conversion from 'int' to 't_atomtype' for 6th argument EXTERN t_class *class_new(t_symbol *name, t_newmethod newmethod,
I tried to add CXX = g++, then CXX = clang, then CXX = llvm in the Makefile, none of which changed anything. (I'm using OSX 10.11.6)
Before starting to play with more settings I don't fully understand everywhere, I thought I'd ask for help here. Any suggestions ? By the way, I think a basic C++ example in the repo would be useful.
Also, if some advanced user is able to give me a good reason to (cross-compatibility or whatever), I could consider switching back to C. But I don't see any reason to do so, except maybe for a small gain in size and/or performance ...
Thank you in advance for any replies, Joseph
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2018-06-04 13:05, Joseph Larralde wrote:
And as you said, it compiles with extern "C" surrounding only the setup function. In fact it even compiles without any extern "C" at all (but won't load, probably due to name mangling).
yes. you only need the 'extern "C" {}' clause to prevent name-mangling. the (unmangled) name is only important for Pd to find the setup function (the setup-function must be a well-known name that can be calculated from the library name).
so in order for Pd to bootstrap your library, you must make sure to prohibit name-mangling by protecting the entry-points with 'extern "C"'. as Pd doesn't need to resolve the name of the rest, you don't have to protect it.
fgasdrm IOhannes
That's awesome. Thank you both for shedding the light on the role of the setup function. I should definitely read pd's source someday to get a deeper understanding.
And I want to say bravo for the actual state of the github organization by the way.
Best, Joseph
Le 04/06/18 à 15:21, IOhannes m zmoelnig a écrit :
On 2018-06-04 13:05, Joseph Larralde wrote:
And as you said, it compiles with extern "C" surrounding only the setup function. In fact it even compiles without any extern "C" at all (but won't load, probably due to name mangling).
yes. you only need the 'extern "C" {}' clause to prevent name-mangling. the (unmangled) name is only important for Pd to find the setup function (the setup-function must be a well-known name that can be calculated from the library name).
so in order for Pd to bootstrap your library, you must make sure to prohibit name-mangling by protecting the entry-points with 'extern "C"'. as Pd doesn't need to resolve the name of the rest, you don't have to protect it.
fgasdrm IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev