X64 against WIN32

[JohnNichols]

Dear All:

I recently got a new Dell computer, put Windows7 64 bit and the Intel Fortran Compiler 64 bit onto the machine, after I updated my licence. I did not mean to do it. This is the latest IVF that is not beta.

I had not used this flavour, its telling me the following error upon running a program that has complied nicely before.

Warning 3 warning #6075: The data type of the actual argument does not match the definition. [LPARAM] B:\\Users\\John\\Documents\\Visual Studio 2010\\Projects\\CX1Reader4\\CX1Reader4\\CX1Reader4_mod.f90 539

cxClient = loword(lParam)

cyClient = hiword(lParam)

it is upset at the loword being a DWORD and the lParam is a long_ptr.

Is there a difference from WIN32 to WIN64 for these two types? Is there a fix?

Thanks

JMN

[Steven_L_Intel1]

That sort of change would make no difference. As we have made changes to the API modules we have used more standard syntax and features where we can (for example, IMPORT). But by their very nature, the API modules are non-portable so it makes little sense to rewrite them. Besides, we already use constants such as DWORD and LPVOID in the declarations.

In some cases, we can add as alternates interfaces that pass typed variables by reference rather than address by value, but we can't do that in all cases.

I'd rather put the effort into adding declarations for the new functions Microsoft added. We're working on that but it's slow progress.

[JohnNichols]

As I sit here looking at my Fortran not dead mug, I keep thinking - but not doing - we need a Dr. Fortran T shirt.

Something like:

Who needs TARDIS, we have Dr. Fortran!

Dr. Fortan designed a new TARDIS before lunch.

Chuck met the Doctor on the battlefield, Chuck's dead.

But really I got onto the web site and found a very old post had suddenly sprung to life again.

You know for a while I played with putting Fortran programs into a form with buzz and windows and then decided - LIFE IS TO FREAKING SHORT FOR THIS ________.

Although MKL is an interesting reading companion at night. 

Real question :  in the kind stuff, the number gets set as 1_long for instance, what exactly does 1_long mean?

JMN

[Steven_L_Intel1]

1_long means 1 of type INTEGER(long). This assumes that LONG has been declared as an integer named constant (PARAMETER) with a value that is acceptable to the processor an integer kind value. There is such a definition in module IFWINTY:

    integer, parameter :: LONG   = 4        ! INTEGER(4) 

[JohnNichols]

But where would you use it?

    integer, parameter :: LONG   = 4        ! INTEGER(4) 

given this - why say

1_long ?

Reid et al do it in their book, but there is no explanation

JMN

[mecej4]

You happened to pick a bad example since,with IFort, integers of kind=4 happen to be the same as default integers. Think about integers that you want to be of kind=2 or 8. Note, too, that kind numbers are not portable, as has been discussed in these forums. You may consider using SELECTED_INT_KIND to make your code completely portable.

[Steven_L_Intel1]

Also, explicitly specifying the kind insulates you from changes in the default kind, say with the /I8 option. It's just good practice. It's more important for things that may vary by platform, such as Windows API handles.

[JohnNichols]

consider using SELECTED_INT_KIND to make your code completely portable. - I am trying to

I will copy the section from the book - it is not easy to follow what the heck they are talking about

JMN

[JohnNichols]

Dear All:

I enclose the early page from Metcalf, Reid and Cohen on integer Literal Constants.

In their book this is the only place it is mentioned and the only sample. But why would I use a constant

1_k6 for example and where?

So is this the intended use:

integer, parameter :: k6 = selected_int_kind(6)

kind(2_K6)

Does that mean that the number kind(2_K6) is kind that will hold a 2 to the power k6 number?

Really weird syntax given the very limited machine types.

My wife says she used a VAX at Purdue in the 80's.

JMN

[Steven_L_Intel1]

selected_int_kind(6) returns the smallest kind (if any) that will hold a signed 6 decimal digit number (not 2**6). If you don't specify the kind on a constant you get the default kind, which may not be what you want.

[FortranFan]

John Nichols wrote:

.. why would I use a constant 1_k6 for example and where?

..

I think the unwritten rule (at least in my part of the world) is to use as few literal constants (i.e., avoid "magic" numbers) as possible and isolate them in appropriate "data" modules via named constants.  With that in mind, there might be a few occasions when one has to use them.  For example, say one is doing some chemical reaction analysis on molecules and needs to include elemental balance and may have code such as:

    ...
    USE, INTRINSIC :: ISO_FORTRAN_ENV, ONLY : INT32
    ..
    INTEGER, PARAMETER :: I4 = INT32
    ..
    TYPE :: Molecule
           ..
           INTEGER(I4), ALLOCATABLE :: Formula(:)
           ..
    END TYPE Molecule
    ..
    TYPE(Molecule) :: H2O
    ..
    H2O%Formula = [ 2_i4, 1_i4 ]
    ..
           

John Nichols wrote:

Does that mean that the number kind(2_K6) is kind that will hold a 2 to the power k6 number?

As explained by Metcalf et al., the number kind(2_k6) can generally hold values in the range -999999 to +999999 since Fortran doesn't have the concept of unsigned integers.

Really weird syntax given the very limited machine types.

I'm quite empathetic to Fortran Standards creators, starting with Fortran 90 where a lot of such syntax was first established - one can only imagine the kind of pressure they were under to please folks in so many quarters and with conflicting demands and so forth.  Considering how "beautiful" and "flexible" and remarkable modern Fortran is, I think a little bid of weirdness here and there only adds to the charm!

I think most coders can simply make do with ISO_FORTRAN_ENV (or ISO_C_BINDING) and the defined kinds therein, at least I do.  With a coding goal of no "magic" numbers and working with named constants only, the weird syntax need only appear in a few places.

[JohnNichols]

I'm quite empathetic to Fortran Standards creators, starting with Fortran 90 where a lot of such syntax was first established - one can only imagine the kind of pressure they were under to please folks in so many quarters and with conflicting demands and so forth.  Considering how "beautiful" and "flexible" and remarkable modern Fortran is, I think a little bid of weirdness here and there only adds to the charm!

I think most coders can simply make do with ISO_FORTRAN_ENV (or ISO_C_BINDING) and the defined kinds therein, at least I do.  With a coding goal of no "magic" numbers and working with named constants only, the weird syntax need only appear in a few places.

Creating standards is a nightmare - almost as bad as blind peer review, there are a few peer reviewers who are blind, deaf and dumb IMHO.

Now I understand - avoid magic numbers.

Thanks

JMN