Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Ankündigungen
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
29286 Diskussionen

Best practice for sharing derived type among code and DLLs

OP1
Neuer Beitragender III
462Aufrufe
Hi,

I have a project made of a console application and multiple DLLs called by this application (all in Fortran). I want to define a structure type that will be used in both the executable and the DLLs.

What is the best practice for defining this type, and have it in the scope of the executable and all the DLLs that need it? I could create a module in each project with a duplicate of the type definition, but then that means having multiple copies to maintain in parallel - an obvious source of non-obvious bugs.
Another solution is possibly to have the module defined in the main executable source, then adding the same module source to the DLL projects.

Maybe there is a better way to achieve this? It almost sounds like I need to create a project (say, an *empty DLL) that only contains this module.

Thanks,

Olivier
0 Kudos
3 Antworten
Steven_L_Intel1
Mitarbeiter
462Aufrufe
Is it just the structure (that is, the TYPE definition) that is shared? Yes, a static library project containing the module source which is depended on by the other projects is the approach I would recommend. Note that an object file is also created - in some instances it would be necessary to link this in and this will happen automatically for dependent projects.

New in version 12 (Composer XE 2011), the output folder of the dependent project will be added automatically as an additional INCLUDE folder, so no more manually specifying the dependent project for INCLUDE.
bmchenry
Neuer Beitragender II
462Aufrufe

when you mention a 'project' you don't mention a 'solution'.
Areyouusing asolution which contians themany projects from the many locations?
To add to what Steve has said i would suggest using a solution with all the DLLs in them and create a separate 'your_shared_data' dll which contains the structure/data (and also any other stuff you want to exchange).
Then set the output directory for the projects in the solution to $(SolutionDir)$(ConfigurationName)
and output files from each project to $(SolutionDir)$(ConfigurationName)\EACHDLLNAME.dll
where EACHDLLNAME is the DLL name for each project
and don't forget to export your DLL names
!DEC$ ATTRIBUTES DLLEXPORT :: YOURDLLNAME
and of course the shared_data DLL elements
!dec$ attributes dllexport :: YOUR_SHARED_DATA

OP1
Neuer Beitragender III
462Aufrufe
Steve,

Yes, it is just the structure definition which is shared. I will follow your suggestion of creating a dummy library containing the module source.

Thanks again!

Olivier
Antworten