Another option is to use the PIMPL idiom, where part of the structure's implementation is a pointer to another type. Most users of the class will just include the normal header file, where the implementation is an opaque pointer. Classes that need access to the private data can include the header defining the other type, and use the interface it provides.
This a common pattern for C programmers wanting friend-like functionality. In my opinion it also hews more closely to thinking about separation of concerns (a generally good design principle that leads to reusable, orthogonal code) rather than encapsulation (an OO-specific technique that is useful for implementing separation of concerns, but also often misused to overcomplicate things).
It has an advantage over friend that it doesn't couple the friend-er to the friend-ee at all. Some people might claim that's a disadvantage, since now anyone can "friend" your class. I think that's an unwarranted fear, since you're still making the relationship explicit (by including the header). If you're afraid of that, you're afraid of your (or your coworker's) ability to make smart architectural decisions. But if you can't make those decisions properly later, why are you trusting yourself with friend
now?
It has a disadvantage of runtime cost. By storing the data in a pointer you have worse cache coherency and more allocation counts, and you also need a destructor to clean it up.