Forward declaration doesn't seem to work

[srpgilles]

The following skeleton code using C++ forward declaration feature doesn't seem to work as expected:

import cppyy

code = """
#include <memory>
#include <string>
#include <vector>

class Child;
"""

cppyy.cppexec(code)

code = """
 class Father
{
    public:

        void AddChild(const std::shared_ptr<Child>& child);

    private:

        std::vector<std::shared_ptr<Child>> children_;      
};
"""

cppyy.cppexec(code)

code = """
class Child
{
    public:

        explicit Child(std::string&& name);

    private:

        std::string name_;

};
"""

cppyy.cppexec(code)

code = r"""
Child::Child(std::string&& name)
: name_(std::move(name))
{ }
"""

cppyy.cppexec(code)

code = """
void Father::AddChild(const std::shared_ptr<Child>& child)
{
    children_.push_back(child);
}
"""

This last block puzzles cppyy, with the following compilation error:

input_line_22:2:14: error: out-of-line definition of 'AddChild' does not match any declaration in 'Father'
void Father::AddChild(const std::shared_ptr<Child>& child)
             ^~~~~~~~
input_line_19:6:29: note: type of 1st parameter of member declaration does not match definition ('const std::shared_ptr<Child> &' vs 'const std::shared_ptr<Child> &')
        void AddChild(const std::shared_ptr<Child>& child);

This is likely not an issue related to cling itself (or if it is it is a really recent addition): same code works with Xeus-cling kernel which also uses up cling under the hood (albeit a less recent version of cling).

For reference same code in Coliru (with an additional main) which is working.

[wlav]

What platform/version of cppyy are you using? Works fine for me (Linux/latest).

Also, is there any reason you chose to use cppexec over cppdef? The former is for individual transactions, the latter for declarations as you seem to have here (or at least, I see no executable code in the example, maybe the original had some). In particular, since you reference it working in different uses of Cling, I'm willing to bet that cppdef is far closer to what these other projects do.

[srpgilles]

I am indeed using macOS, and for this specific feature I didn't check the behaviour in Linux. I'll ask to one of my colleague tomorrow.

Our use case is to write a metakernel for Jupyter notebooks that support C++ code; we were using Xeus-cling for some years now but the project seems to be stale now, so we were looking for an alternative and so far it seems like cppyy will be more than fine for that! 🙂

I wasn't the one in charge of writing the first draft of the kernel but we also want to execute some cells that produce outputs, hence the choice of cppexec.

Many thanks for your quick reply to our issues!

[wlav]

Oh, Mac ARM does not support exceptions returning from JITed code (Cling) back into compiled code (Python), so yes, information of the exception is lost there. In fact, an uncaught exception reaching compiled code results in a crash b/c there is no unwind information. To prevent a crash, cppyy adds a terminate handler that uses longjmp to restore the stack. That does mean that for any part of the stack that is compiled code before reaching cppyy, destructors will not be called. However, quite often (as-is in this case), there is no compiled code. There would be for e.g. Python functions that call C++ code that throws, installed as callbacks in a C++ framework. (Note that Mac Intel is fine.)

As for xeus-cling, I'm not tracking its development/state, but I presume https://github.com/compiler-research/xeus-cpp is where you'd want to be these days? @vgvassilev, can you comment here?

[vgvassilev]

Our use case is to write a metakernel for Jupyter notebooks that support C++ code; we were using Xeus-cling for some years now but the project seems to be stale now, so we were looking for an alternative and so far it seems like cppyy will be more than fine for that! 🙂

We have been working on a successor on xeus-cling that is more principled in both design and implementation called xeus-cpp. Xeus-cpp is based on cling's successor in llvm, clang-repl.

As part of our longer term vision is to be able to use multiple languages in the same notebook. You can check out this video https://youtu.be/be89sF0WLrc Our compiler-research.org group is pretty open to collaborate if that aligns with your interests.

[srpgilles]

OK, thanks a lot as I didn't know of xeus-cpp!

For me current issue can be closed: we will use the fact that it works using cppdef instead of cppexec.