0

I cannot understand how these two functions produce ambiguation. If the types are changed to integer or real, the compiler does not flag any ambiguation.

Function split_to_str_unidim  &
  (                           &
    a, delim, mold,           &
    pos                       &
  )                           &
    Result (bn)

  Character (len=*), Intent (in) :: a, delim, mold
  Character (len=*), Intent (in), Optional :: pos

  Character (len=65), Allocatable :: bn(:)

End Function


Function split_to_str        &
  (                          &
    a, delim, b1, b2,        &
    b3, b4, b5, b6, b7, b8,  & 
    pos                      &
  )                          &
    Result (b)

  Character (len=*), Intent (in) :: a, delim
  Character (len=*), Intent (in), Optional :: pos

  Character (len=*), Intent (out) :: b1, b2
  Character (len=*), Intent (out), Optional :: b3, b4, b5, b6, b7, b8
  Logical :: b

End Function
Zeus
  • 1,485
  • 1
  • 17
  • 33

1 Answers1

1

A call such as

split_to_str(a,b,c,d)

where a,b,c,d are all strings can't be unequivocally identified with only one of your two functions. That's ambiguous.

To disambiguate you'll have to make the signatures (the non-optional, intent(in) argument list) unique. From your recent trail of Qs and As you've already discussed this with others, I have nothing to add to what has gone before.

I'm surprised that changing the type from character(len=*) to real or integer doesn't have the same problem.

High Performance Mark
  • 77,191
  • 7
  • 105
  • 161
  • Any suggestion how this ambiguation can be resolved? – Zeus Nov 12 '14 at 15:58
  • 2
    Don't put the two functions in an interface (which I assume you've done). Just call the appropriate one depending on the context. – bdforbes Nov 12 '14 at 20:43