String Concatenation Operator // Ignored

[saquatch]

Is there an issue with the string concatenation operator (//) getting ignored in Visual Studio FORTRAN compiler?  Perhaps its being seen as a C++ comment?

[Arjen_Markus]

Can you provide an example to reproduce this behaviour? I have always been able to use it, even with an overloaded version (that has little to do with strings, by the way).

[mecej4]

No, I have compiled tons of code with the Ifort compiler (various versions, Windows and Linux), and many of those codes did contain // .

Are you compiling a fixed form source file? Or a file with the suffix in its name .f or .for? If so, characters beyond column 72 may be ignored, unless you have used a compiler option or a directive to prevent truncation at columjn 72.

[jimdempseyatthecove]

Have you selected the C/CPP preprocessor or...

If you are using the Intel fpp (I haven't had issues using fpp and // concatenation) try adding as additional option: -B

usage: fpp [options] [input_file [output_file]]
Options:
-B                  Do not recognize C++ style comments.
-C                  Do not recognize C style comments.
...
-c_com=<yes|no>     Recognize or not C style comments. Default value -c_com=yes.
...
-noB                Recognize C++ style comments.
-noC                Recognize C style comments.
-noJ                Recognize F90 style comments in #define line .

Jim Dempsey

[saquatch]

Where in VS do I ensure these options are set?  I don't find these listed under VS Options dialog.  My files are .FOR.  Another .F project is working fine.

[saquatch]

OK, this is probably not related to // being ignored.

Is it related to FORTRAN processing strings as references?  This simple code is baffling me:

CHARACTER*100 S1, S2
CHARACTER*200 S12
CHARACTER*250 OTHER

!This looks fine: All three S1, S2 and S12 are padded correctly.  S12 is concatenated and padded: "C:\Development\Path\Filename.txt                               ..."

S1 = "C:\Development\Path\"
S2 = "Filename.txt"
S12 = TRIM(S1)//TRIM(S2)  

!OTHER is set elsewhere and displays as an unpadded value: "C:\Development\Path\": no pad.  Attempts to concatenate result in:
!S12 = TRIM(S1)//TRIM(S2) Results in "C:\Development\Path\": no concatenation, no pad.
!S12 = TRIM(S2)//TRIM(S1) Results in "Filename.txtC:\Development\Path\": concatenation, no Pad.

S1 = OTHER                           
S2 = "Filename.txt"
S12 = TRIM(S1)//TRIM(S2)
S12 = TRIM(S2)//TRIM(S1)

Is there some kind of reference size stuff going on?  Why first S12 can't concatenate when second S12 can?  Why no padding?

If strings are always references to fixed length char arrays, are assignments just assigning references not value copying?

If so, what does concatenation actually do?  Does it create space for both, then assign the reference to S12?  But it did not concatenate the first S12.

[jimdempseyatthecove]

I suspect the value of S1 contains:

"yourPathHere<Space><Space><Space>...<NULL>" (possibly more spaces here)

Then TRIM(S1) trims out to and including the NULL

IOW You cannot see NULL in the editor, thus you suspect that the remainder of S1 is all blanks/spaces

The // concatination will occur after the NULL, and if the NULL is at the last position of S1, you will/may not see S2 in the result.

Just prior to your S12 = TRIM(S1)//TRIM(S2) insert

if(INDEX(S1, ACHAR(0)) .gt. 0) STOP "NULL Found"

if(INDEX(S2, ACHAR(0)) .gt. 0) STOP "NULL Found"

If you stop, then you have to cleanup your input argument(s)

Jim Dempsey