[
https://issues.apache.org/jira/browse/AVRO-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17943869#comment-17943869
]
Gerrit Birkeland edited comment on AVRO-3730 at 1/30/26 7:43 PM:
-----------------------------------------------------------------
bq. AvroBaseStruct, which has a pure virtual destructor
Doing this would cause the empty base class optimization not to apply, it's not
empty anymore, it requires a vtable.
was (Author: JIRAUSER305666):
.bq AvroBaseStruct, which has a pure virtual destructor
Doing this would cause the empty base class optimization not to apply, it's not
empty anymore, it requires a vtable.
> avrogencpp generated structs do not inherit from a common base class and so
> cannot be generically destructed
> ------------------------------------------------------------------------------------------------------------
>
> Key: AVRO-3730
> URL: https://issues.apache.org/jira/browse/AVRO-3730
> Project: Apache Avro
> Issue Type: Improvement
> Components: c++
> Affects Versions: 1.11.1
> Environment: This applies to all environments but was spotted on
> RHEL8 using gcc 8.5.0.
> Reporter: Andrew Peter Marlow
> Assignee: Mikhail Koviazin
> Priority: Minor
>
> Objects of the type generated by avrogencpp are structs which might not be
> PODs, since they might contain std::string and/or std::any. This means that
> when they are constructed by a custom allocator they have to be destructed by
> the compiler-generated destructor otherwise the non-POD memory remains
> allocated. This requires that the type is known. A more flexible approach
> would be for all these structs to inherit from a common base class with a
> virtual destructor. This would allow any such object to be destructed by
> invoking that common destructor.
> This issue was brought to light on a project that uses a custom allocator
> that hands out object from a pool and requires that they are returned to the
> pool when they are finished with. The code is generic, the avro message is
> just a block of bytes so there is no type information. That works ok for many
> of the messages which just contain various integers. It even works ok in some
> cases where the structs have std::string and/or std::any when the data fits
> into the small buffer optimisation. However, it leaks when the struct has
> used the heap.
> One fix would be to add a base class, let's call it AvroBaseStruct, which has
> a pure virtual destructor. It would be declared in the avro namespace in the
> header Specific.hh since the generated code already includes that header. The
> base class destructor would have an inline implementation in the header file.
> All generated headers would publically inherit from that class.
> The size of derived classes should not change due to the empty base class
> optimisation. There will need to be documentation to let people know that
> avro objects can be deleted polymorphically. So AvroBaseStruct will have to
> be documented somehow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
