Question

I tried making a struct with classes in it like:

struct my_struct
{
    NSString *string;
    // more fields
};

To my surprise, Objective-C++ allowed this with ARC enabled.
How will it manage the string?
It can easily retain in each assignment but release is the problem.
It can add a destructor with release in it, but this will make the struct non-trivial.
It can also make this not retain or release, but to do so there should be unsafe_unretained.

From my observation nothing crashes when using this, but I would like to know what really happens here.

Answer 1

See 4.3.5 of the ARC docs:

4.3.5. Ownership-qualified fields of structs and unions

A program is ill-formed if it declares a member of a C struct or union
to have a nontrivially ownership-qualified type.

Rationale: the resulting type would be non-POD in the C++ sense, but C
does not give us very good language tools for managing the lifetime of
aggregates, so it is more convenient to simply forbid them. It is
still possible to manage this with a void* or an __unsafe_unretained
object.

This restriction does not apply in Objective-C++. However, nontrivally
ownership-qualified types are considered non-POD: in C++11 terms, they
are not trivially default constructible, copy constructible, move
constructible, copy assignable, move assignable, or destructible. It
is a violation of C++’s One Definition Rule to use a class outside of
ARC that, under ARC, would have a nontrivially ownership-qualified
member.

Rationale: unlike in C, we can express all the necessary ARC semantics
for ownership-qualified subobjects as suboperations of the (default)
special member functions for the class. These functions then become
non-trivial. This has the non-obvious result that the class will have
a non-trivial copy constructor and non-trivial destructor; if this
would not normally be true outside of ARC, objects of the type will be
passed and returned in an ABI-incompatible manner.

If you read through all the caveats, I would strongly recommend against doing this in ObjC++. I strongly recommend against extensive use of ObjC++ in any case. It is a bridging language to help pure ObjC and pure C++ talk to each other. It has many problems. Combining ObjC++ with ARC introduces both time and space performance costs that do not occur in ObjC in order to make it exception-safe. Defining these kinds of ObjC++-specific data structures makes it hard to interact with non-ObjC++ code and non-ARC code (note the caveat that you cannot use this outside of ARC). Much of what you should get for free from ARC suddenly becomes hard as you have to worry again about memory management (as you’ve already discovered).

Build a pure-ObjC layer. Build a pure C++ layer. Build a thin ObjC++ layer to tie the two together. Do not put ObjC objects in structs, and definitely not in any public structs (i.e. visible outside of the single ObjC++ object that defines it).