What is the difference between aggregate_of and aggregate_of_instance?

[RickBrice]

I'm implementing the requirements of IFC 4.1.4.1.1 "Every IfcAlignment must be related to IfcProject using the IfcRelAggregates relationship" and IFC 4.1.5.1 CT where IfcAlignment is referenced into the spatial structure of IfcSite with IfcRelReferencedInSpatialStructure.

Both relationships relate something (Project or Site) with a list of alignments. IfcRelAggregates uses aggregate_of and IfcRelReferencedInSpatialStructure uses aggregate_of_instance.

Reviewing the aggregate_of_instance.h header, both classes are basically adaptors for std::vector.

What is the difference between these two classes? And more importantly, why is there a difference?

[aothms]

I think you haven't pulled changes since Jun 21, because I think as of c72f960 #2805 they both use aggregate_of

aggregate_of< ::Ifc4x3_add1::IfcSpatialReferenceSelect >::ptr RelatedElements() const;

aggregate_of< ::Ifc4x3_add1::IfcObjectDefinition >::ptr RelatedObjects() const;

For history on why this difference existed, maybe see #1714 Proper select implementation

basically adaptors for std::vector.

Yes, the plan originally was to embed more of the semantics of express in these aggregates, enabling them to behave as when needed sets/bags. But this was never prioritized because honestly in IFC the distinction between these types is often rather arbitrary. Exemplified by the fact for example that a IfcPropertySet is a list of properties.

Also to add more convenience methods for dealing with aggregates of selects for example to apply visitors to them. But frankly the C++ API is lagging behind in terms of ergonomics. But we have good plans for v0.8 :)

What is the difference between these two classes?

aggregate_of<> is a template class to statically constrain the type elements. aggregate_of_instance is general, you can see it as aggregate_of<IfcBaseClass> (and maybe it should become that with some SFINAE to hide a couple of member functions).

[RickBrice]

Thanks - I pulled and updated all my code.

What is the vision for v0.8? Would you replace boost::shared_ptr and boost::optional with std::shared_ptr and std::optional?

[aothms]

What is the vision for v0.8? Would you replace boost::shared_ptr and boost::optional with std::shared_ptr and std::optional?

I wouldn't mind. I think it's a good idea. I think I also use boost::variant in quite a few less-noticable places. So we can replace those with std::variant too.

C++17 is a reasonable basis for v0.8 I would say.

Other than that the vision is to have a consistent, user-friendly and well documented C++ API.