On 17 Dec 2019, at 16:04, Johanna Amann wrote: >>> Is there some way to use an IntrusivePtr in this case - or is is >>> just >>> not possible to use it in cases where it is not possible to use >>> complete >>> types? >> >> You should be able to get away with forward declarations as long as >> you provide matching prototypes for Ref and Unref. > > If I do that I get linking errors: > > "Ref(Expr*)", referenced from: > Expr::Ref() in IdentifierInfo.cc.o > Expr::Ref() in Expr.cc.o > Expr::Ref() in ID.cc.o > WhenStmt::Exec(Frame*, stmt_flow_type&) const in Stmt.cc.o > Expr::Ref() in Type.cc.o > Expr::Ref() in Val.cc.o > make_var(ID*, BroType*, init_class, Expr*, List<Attr*>*, > decl_type, int) in Var.cc.o > ... > "Unref(Expr*)", referenced from: > zeekygen::IdentifierInfo::Redefinition::~Redefinition() in > IdentifierInfo.cc.o > Attr::~Attr() in Attr.cc.o > UnaryExpr::~UnaryExpr() in Expr.cc.o > BinaryExpr::~BinaryExpr() in Expr.cc.o > CondExpr::~CondExpr() in Expr.cc.o > ScheduleExpr::~ScheduleExpr() in Expr.cc.o > CallExpr::~CallExpr() in Expr.cc.o > ... > > Which makes sense, because Ref/Unref(Expr*) never exist - they only > exist for BroObj*. I could implement a forward function that does > nothing besides calling Ref(BroObj) in Expr.cc - but that seems… not > really elegant/worth using anymore in this case. Unless I an declare > them in another way that I am missing.
For completeness - the forward declaration/prototype in Val.h is: class Expr; void Ref(Expr*); void Unref(Expr*); Johanna _______________________________________________ Zeek-Dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
