Handling Integer Kind within my project

[alexos_kiel]

Hi, I have some difficulties in handling the kind of INTEGER variables within my project.

Up to now I worked with the old Compaq Visual Fortran Developer Studio 6.6: this problem did not occur.

My project includes dialog routines as well as Graphics QuickWin facilities.

First problem: when compiling my files including dialog routines the following message was generated by the compiler:

error #6284: There is no matching specific function for this generic function reference. [DLGINIT]

The same with DLGSET.

While checking this problem I found out that it might be caused by a wrong INTEGER kind definition concerning the

parameters of the dialog and the respective control ID's. I changed the default INTEGER kind from 2 to 4 in

my project settings: the error message did no longer occur.

Unfortunately the INTEGER kind of the dialog and control ID's is not automatically defined

within the resource.fd file while creating it by deftofd. (I hope that I correctly enabled the developer studio

to create the resource.fd from resource.h: I followed the steps in Your documentation - the automatic generation of

resource.fd works, and changes in my resource file are updated). So, this problem can be solved by default setting of

ALL integer variables of my project to Kind=4.

Second problem: there are many other routines of QuickWin which NEED integer parameters of kind=2,

for example: rectangle(....). Compilation ist o.k. when I make sure that EVERY variable kind is correctly

defined. Otherwise the compiler treats it as kind=4 which causes the warning:

warning #6075: The data type of the actual argument does not match the definition.

I am a little unhappy that I need to check a lot of integer variables meticulously with view to their kind and that there

is obviously no automatism which ensures a right handling of them.

(This was not necessary in Compaq 6.6 and did work without any problems).

Is there a possibility to avoid this?

How can I understand the passage in the documentation:

"If a kind parameter is specified, the integer has the kind specified. If a kind parameter is not specified, integer constants are interpreted as follows:

If the integer constant is within the default integer kind range, the kind is default integer.

If the integer constant is outside the default integer kind range, the kind of the integer constant is the smallest integer kind which holds the constant.

The default kind can also be changed by using the INTEGER directive or compiler options specifying integer size."

Thank you for an answer!

[mecej4]

The last CVF compiler was released almost a decade ago. The current Intel Fortran compiler has seen seven major releases since then, and the CVF compiler cannot even be installed on some versions of Windows 7.

Migrating old code should be expected to take a little work. I would not expect GUI code written for CVF to work without change with a current compiler.

However, once you find the changes necessary (if any) for one project, with regard to project settings as well as source code, those changes can be applied easily to other projects.

It would make things easier and providing support more feasible if you were to take one specific QuickWin project and ask about the problems you run into with that.

The quotation from the documentation strikes me as very clear. Just state what part of it you find hard to understand.

[Jugoslav_Dujic]

Well, you can turn off the argument checking at Fortran/Diagnostics/Check routine interfaces (/warn:interfaces).

However, I strongly advise against it, and recommend fixing the code instead. So far, you were crawling through bushes with an unlocked gun: such kind of mismatches are a disaster waiting to happen.

Let us assume that your default integers are 2-byte, and you're passing them to a routine expecting 4-byte integers (such as DlgSet). If you pass, say, 2-byte number 1000 (3E8 hexadecimal), it will be stored in memory as:

E8 03 ?? ??

where "??"s are random adjacent bytes in memory. When you pass the address of that argument, if you're "lucky" (most of the time, apparently), those random bytes will be zero, giving:

E8 03 00 00

so, when it is read as 4-byte integer, the value is 000003E8 hex = 1000, as intended. However, if the "??"s are something else, the interpreted number is something else, and the routine silently fails. You don't even have much clue in the debugger: apparently, you send 1000, but read something entirely different.

Generally, changing the default integer or real kind is a big sledgehammer, which should be used only in extreme situations such as compiling dusty decks written in Fortran IV. I strongly recommend against it.

If I were you, I would compile with default integer kind (4), and fix the calls to QuickWin routines instead by explicitly specifying INTEGER(2) where it's due. I would go as far as declaring the integer kind as a compile-time constant, and use it for both variables and literals:

[fortran]INTEGER, PARAMETER:: QW = 2
...
INTEGER(QW):: x, y

CALL MOVETO(0_QW, 0_QW, coord)
ret = LINETO(x, y, coord)[/fortran]