[Zeek-Dev] Question about IntrusivePtr and incomplete types

Johanna Amann johanna at corelight.com
Tue Dec 17 07:06:22 PST 2019


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


More information about the Zeek-Dev mailing list