hex constants and fortan 2003 standard

hex constants and fortan 2003 standard

I was looking at enforcing some standards on my application of many years standing (> 200,000 lines for fortran code) so did a trial build with Fortran 2003 (/stand:f03). 5000 warnings later....

It doesn't look like too big a job actually, after globally replacing a load of tabs with spaces and stuff like integer*n declarations with integer(n), 

I few things are causing some head scratching:

1] integer data constants in HEX in some module declarations (example as below): 

integer(4) :: Bright_Yellow =#00FFFF
integer(4) :: Dull_Blue =#800000

What is a valid syntax in f2003 if there is one? I have spend 20 minutes searching help and internet without success?

2] I am using fortran 2011.9.300 in vs2010 shell and I get some warnings regarding things like ifqwin /XYCOORD/ structure/record entities which are obsolete in 2003 and should be derived types. I am about to upgrade my fortran anyway, will that issue go away? I know the code will still work and I can switch off repoting of specific warning numbers but I prefer not to if I can. Having maximum checking and warnings for new code is definately my prefered way.

BTW I inadvertantly posted this to some other intel forum (Perhaps C++?) in error.

10 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

The new standard syntax for BOZ literals is

integer(4) :: Bright_Yellow = int(Z'00FFFF')

I would be a bit more cautious about using hard-wired KIND numbers like this. In Microsoft's original examples, 64-bit Windows was still a long way off so hard-wiring everything as INTEGER(4) looked OK, but pointers and handles, not to mention size_t got promoted in x64. So all those old examples that followed that style became invalid for 64-bit programs. My recommendation would be to look at the usage of integer variables, and if they are arguments to API functions use the appropriate named constants from ifwin instead of integer literals. Also many old examples tended to use LOGICAL(4) rather than INTEGER to interface to Windows BOOL; expect problems if your code does this.

Thanks I am aware of 64/32 bit issues, the bridge is still to be crossed (some pain is expected). That works with stand 2003, the key was the int around the boz constant.

OK with reference to point 2) I think there is an inconsitency, for example in the help file if I look at:

POLYGON, POLYGON_W (W*32) (a graphics function). The help says:

 ....wppoints (Input) Derived type wxycoord. Array of derived types defining the polygon vertices in window coordinates. The derived type wxycoord is defined in IFQWIN.F90 as follows: TYPE wxycoord REAL(8) wx REAL(8) wy END TYPE wxycoord

But if you have that you will get a compiler warning because if you look in  IFQWIN.F90 wxycoord is defined as a 'structure' not a 'type'. The code works, is this just an IFORT extension?

structure/record is an extension inherited from VAX Fortran.  As the warning states, it was obsoleted by Fortran standard features.  You'll have to put up with it (or disable the warning) until ifqwin is modernized.

There are some things in IFQWIN (and the Windows API modules) that can't be done in standard Fortran - UNION for example. My advice for those who want to standards-check their own code is to isolate use of non-standard modules to "worker" routines in a separate source file that is compiled without standards checking.

Steve - Intel Developer Support

Thanks for info TimP/Steve.

I had a look and the number of 'non-compliant' routines is not very large, I think I will (as you suggest) move all these into a single source file and switch of the relevant warning messages for that file. I didn't realise until a few minutes ago that it was possible to have different options for different files within the same project. 

The main objective was to 'force' as much good coding on myself as possibe!

....and one last point is there any compliant way of replacing sizeof of loc for example like the usage in the getopenfilename ifort example?

There's C_SIZEOF and C_LOC from module ISO_C_BINDING, but the latter would require use of TRANSFER to convert the resulr C_PTR to an integer. Does it really make sense to do standards checking for something as non-portable as this?

Steve - Intel Developer Support

In that example it doesn't make much sense I fully agree. It was more an academic question really. I will read up a bit more and might then have a go on that example as a learning activity as where possible I would preffer to have new code compliant where practical. Thanks for the info.

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui