User talk:Zmi007: Difference between revisions

Content added Content deleted
Line 127: Line 127:


I'm still uncomfortable about the unlimbering of memory re-allocation on every change to a string. There are ploys, such as the obvious "do nothing" if the new size is the same as the old size. Presuming that this memory churning would be mixed in with the other memory churning of arrays of floating-point numbers, etc. this means that the precise state of the memory depends now not just on the churn of number storage, but also of text twiddling. Still, given that modern computers have plenty of memory and that there are no mistakes in the memory manipulation, this shouldn't matter... I have from time-to-time mused on a half-way house, wherein a string has a length ''and'' a maximum size: any manipulations up to the size limit incur no re-allocation and so can be done in-place. This would offload some of the demand for cunning in the memory re-allocation routines but of course means that the string manipulation procedures become even more complex. [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 08:28, 12 December 2015 (UTC)
I'm still uncomfortable about the unlimbering of memory re-allocation on every change to a string. There are ploys, such as the obvious "do nothing" if the new size is the same as the old size. Presuming that this memory churning would be mixed in with the other memory churning of arrays of floating-point numbers, etc. this means that the precise state of the memory depends now not just on the churn of number storage, but also of text twiddling. Still, given that modern computers have plenty of memory and that there are no mistakes in the memory manipulation, this shouldn't matter... I have from time-to-time mused on a half-way house, wherein a string has a length ''and'' a maximum size: any manipulations up to the size limit incur no re-allocation and so can be done in-place. This would offload some of the demand for cunning in the memory re-allocation routines but of course means that the string manipulation procedures become even more complex. [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 08:28, 12 December 2015 (UTC)

== Call a foreign-language function ==

I don't quite agree with your comment, on two points.

First, the definition. Quoting [[Foreign function interface]]:

''Foreign function interface, or FFI, is a common name for a facility in a programming language (especially a high-level one that does not usually work in terms of pointers, raw structure layout, etc.) to invoke functions and access data structures defined using another one (especially C).''

Calling C from Fortran qualify obviously as FFI. The only difference with, say, a Common Lisp FFI to C, is that it's specified by the standard. C is nevertheless ''foreign'' to Fortran. It's rather rare for standardized languages, but not unique: Ada has interfaces to C, COBOL and Fortran, for instance.

Second point, you write that you should write a C wrapper. But C has no standard way to call another language. If you can do it with standard C, then you will be able to do it with Fortran and ISO_C_BINDING and if you need nonstandard C features, then the Fortran vendor may provide the same nonstandard feature. And often it's what happens. A classic example is calling a ''STDCALL'' function on Windows, while, usually, C programs (and Fortran programs, at least with BIND(C)), use the ''CDECL'' convention. But, this is not really a language concern, it's on the ABI level. And, as C compiler provide the nonstandard __stdcall keyword, Fortran compilers provide either a STDCALL keyword (Absoft Pro Fortran), or another nonstandard way to declare the function: Intel Fortran has "DEC! ATTRIBUTES STDCALL :: fun", while GNU Fortran has the same (replace DEC with GNU). All in all, in all cases I know off, if you can do it in C, you can do it in Fortran without a wrapper. I may be simpler with a wrapper though.

There are other cases for which one must use nonstandard features. Another example is calling a function that needs arguments with a special memory alignment. Intel has "DEC$ ATTRIBUTES ALIGN" for this. Even in pure Fortran, this allows the compiler to optimize better with SIMD instructions.

Notice that even before ISO_C_BINDING, Fortran compiler vendors used to provide some way to interface with C. There are DEC extensions, for instance. Incidentally, Intel still uses these extensions instead of the new standard bindings, for interface modules to the Windows API. I guess it's so that older programs don't break. It's also often easier to use integer variables holding pointers, than the c_f_pointer and c_f_procpointer subroutines.

On the other hand, there are languages for which a wrapper is mandatory. An example is VBA, in 32 bit applications. Since VBA can only call STDCALL functions, a CDECL function can't be called without a wrapper (which may be written in C, Pascal or Fortran for instance).

[[User:Arbautjc|Arbautjc]] ([[User talk:Arbautjc|talk]]) 18:27, 24 November 2016 (UTC)