- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I've been experimenting with parameterized derived types and got a question regarding building libraries with MODULEs containing PDTs; is it possible to distribute (compiled) libraries containing PDT? I guess it's trivial for PDTs with parameters of LEN type, but what about for KIND type parameters? their values have to be known at compile-time, right?
I've read somewhere that in C++ templates are written in header files which are distributed in textual form or some intermediate/precompiled form along with libraries, and that the actual templated entities are instantiated when they are "USEd" in Fortran terms. (Luckily) Fortran doesn't have header files (AFAIK) but use MODULEs instead; in the case that the answer to the above question is negative, would it be possible to include some (processor dependent) code in a MODULE that makes it possible?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
KIND parameters don't introduce any link-time dependency, but LEN parameters do. Of course, if you are distributing libraries the user of your library needs to have the Intel Fortran redistributables from the same version or newer in any event.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So if I create a library containing only a single PDT with one or more KIND type parameters and give that library (in compiled form) to a user (that has the same or newer compiler than the one I used to compile the library) who writes a generic procedure for this PDT (where one or more of the parameters are used for generic resolution), he could declare a variable with the parameter set to some value that his procedures will accept and compile his program or library just fine?
PS: the KIND type parameters may very well be of length type, e.g. a DIMENSION spec, but I want to be able to use it for generic resolution and therefore need to declare it with the KIND attribute
edit: the user of my library may not necessarily want to write procedures for this PDT, just declare variables and access their components
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You don't have to worry about using PDTs of any type in a library as long as you follow the normal rule of the end user having the link libraries of at least the same version. But your case would also require you to provide modules, so the end user would need the same or later compiler version installed, no matter what kind of PDT. This is the standard rule for modules.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Excuse me for being slow here: by "provide modules" do you mean the module source files, the .mod files, or someting other?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Espen M. wrote:
Excuse me for being slow here: by "provide modules" do you mean the module source files, the .mod files, or someting other?
Thanks
It is the compiled .mod files created by the compiler of the module source files (.f90) that contain the derived types.
In our experience, for the users who statically link their programs with our libraries that are packaged as DLLs, they require 3 things from us:
- *.mod files during their code compilation stage: These mod files are similar to C/C++ .h files and they go in an include path on the user's development/build environment,
- *.lib files during their linking stage. These lib files go in a LIB path on the user's link environment,
- *.dll files for use during their run-time. These files go in a Windows DLL search path which can be in the same folder as their executable or one common location.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Right.In particular, for the end user to be able to declare a variable with (or extend) a type, they need the module that declares the type.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, both of you :)
A follow-up question: How much info is in the mod-files? I'm guessing at least the procedure interfaces and the PUBLIC entities..? Anything else?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
See this for more information on mod files.
You may also want to look into submodules (http://fortranwiki.org/fortran/show/Submodules ), a feature recently introduced in Intel Fortran with 16.0 Beta (a simple example in https://software.intel.com/en-us/forums/topic/549513)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for the link on mod files FortranFan. I was just a bit confused by the mod files being referred to as the module; as I've never given them much thought I didn't realise that they are in fact precompiled header files.
Regarding submodules, I'm quite familiar with that feature (to the extent possible without actually using them;) and very much looking forward to give them a try!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page