Extending a TYPE and accessing character field causes compiler error

[Bryan_H_1]

Greetings,

I am trying to learn how to extended types.  It appears that accessing a character range in a character array causes an issue compiling depending if the field is defined in the ancestor or in the child (see below).  Please let me know if I am doing something wrong, or if this is an compiler issue.  Using VS 2010 shell with IVFC XE 2013 (w_fcompxe_2013.1.119).

Thanks!

Program Inheritance
      
      Type S_ANCESTOR_PASS
        Character*2 Str(5)
      End Type
      
      Type, Extends (S_ANCESTOR_PASS) :: S_CHILD_PASS
      End Type S_CHILD_PASS
      
      Type S_ANCESTOR_FAIL
      End Type
      
      Type, Extends (S_ANCESTOR_FAIL) :: S_CHILD_FAIL
        Character*2 Str(5)
      End Type S_CHILD_FAIL
      
      Type (S_CHILD_PASS) :: Struct_Pass(5)
      Type (S_CHILD_FAIL) :: Struct_Fail(5)
      
      Struct_Pass(1).Str(1) = 'AB' !Compiles
      Struct_Fail(1).Str(1) = 'AB' !Compiles
      
      Struct_Pass(1).Str(1)(2:2) = 'C' !Compiles
      Struct_Fail(1).Str(1)(2:2) = 'C' !Does not compile, see below
      
      !Error 1: error #6460: This is not a field name that is defined in the encompassing structure.   [STR] Line 24
      !Error 2: error #6514: A substring must be of type CHARACTER.   [STR] Line 24
      !Error 3: error #6158: The structure-name is invalid or is missing.   [STRUCT_FAIL] Line 24

      End Program Inheritance

[Steven_L_Intel1]

Well, other than using . instead of % as a component designator, I don't immediately spot a problem with the code. (Using the standard % doesn't affect the behavior here.)( We'll take a closer look.

[Steven_L_Intel1]

Escalated as issue DPD200380706. I will note that any fix will come in a future update or version and won't be put back to the old compiler you are using.

[Bryan_H_1]

Thanks Steve for the feedback!  Two quick questions:

1.  Is there a way I can follow the status of DPD200380706?

2.  Any recommended reference on understanding the impact of using . vs %.

Thanks again.

[Steven_L_Intel1]

I will update this thread when there is news.

My advice is to always use %, which is standard. The . separator is a DEC extension that not all compilers support and has been known to cause parsing errors in our compiler, though I haven't seen one of those for a while. I always recommend using standard-conforming syntax where available.

[Steven_L_Intel1]

This has been fixed for a release later this year.