public methods lacking DLL_IMPORT_OR_EXPORT

[trebahl]

Is your feature request related to a problem? Please describe. Some public non inlined methods don't have a DLL_IMPORT_OR_EXPORT. This prevents from using them in windows.

The cases I stumbled upon are:

• in AbstractGridRepresentation: COMMON_NS::DataObjectReference getParentGridDor() const; std::vector<RESQML2_NS::AbstractGridRepresentation *> getChildGridSet() const; void loadTargetRelationships();

• AbstractLocal3dCrs::getArealRotationUom

• the free functions in Trigonometry.h.

Describe the solution you'd like

Removing the existing DLL_IMPORT_OR_EXPORT, then adding DLL_IMPORT_OR_EXPORT to the classes, like:

class DLL_IMPORT_OR_EXPORT AbstractGridRepresentation { .... }

Describe alternatives you've considered Adding the missing DLL_IMPORT_OR_EXPORT one by one.

[philippeVerney]

Hi @trebahl,

Thanks for raising this issue.

"Public" does not mean "exported". FESAPI does have public methods which are not intended to be exported/used by final users. I agree that FESAPI public methods are by default all exported on Linux system and not on Windows system which may create some inconsistencies.

• DORs are not intended to be used by the final users since they can directly get the referenced dataobject (which may be partial in some cases). This is more for FESAPI internal usage (we probably would have to revisit our architecture to better encapsulate it).
• getChildGridSet() looks to be a mistake on our side. Good catch!
• loadTargetRelationships is not intended to be exported. This is more for FESAPI internal usage (we probably would have to revisit our architecture to better encapsulate it)
• AbstractLocal3dCrs::getArealRotationUom looks to be a mistake on our side. Good catch!
• the free functions in Trigonometry.h are not intended to be exported. This is more for FESAPI internal usage.

Initially, whole FESAPI classes were exported but it had created a lot of warnings. We have thought cleaner (even if more work for us) and more granular to selectively put DLL_IMPORT_OR_EXPORT on each method. I think the warnings were related to this : https://stackoverflow.com/questions/767579/exporting-classes-containing-std-objects-vector-map-etc-from-a-dll I am not telling that we cannot put DLL_IMPORT_OR_EXPORT on classes but it does not look to us that this would be cleaner, that this would be more precise.

[trebahl]

Thanks for your quick answer. I understand that dors and loadTargetRelationships don't need to be exported (I just mentionned them because I saw them not exported, but getChildGridSet was the method on this class that I was trying to use).

However, regarding Trigonometry.h, I think at least convertToRadians should be exported. This function seems important to me in order to make use of AbstractLocal3dCrs;;getArealRotation.

[philippeVerney]

I think I am going to make Trigonometry a header file only. This would :

• solve your issue I think
• be quite clean since this is often to design util class as header only
• not show that FESAPI intends to export such functionality (even if it would allow)

About the third bullet above, FESAPI would really like to provide such functionality i.e. uom conversion but it is not done yet and would require a significant amount of time. Indeed, we could convert plane angle to radian, but also to angle degree and to so much other uom. If we would provide such functionality for plane angle, why not to provide it for lenght, weight, volume, etc... ? Though we really would like to work on that, I don't think we currently have the resources for it.