Re: HELP ME - HOW THIS ERROR?



In article <XsUwe.30358$yM4.457964@xxxxxxxxxxxxxxxxxx>,
"WindCina" <windcina@xxxxxxxxx> wrote:

> error 250 - You cannot assign an expression of type REAL(KIND=1) to a
> variable of type TYPE(LISTA)
>
> h = RicercaParola(vett(k),parola); <-error is here

You haven't shown enough context to know with absolute certainty... but
there is enough for me to make a pretty good guess.

It probably isn't known *IN THE SCOPE OF THE ABOVE STATEMENT* that
function RicercaParola returns something of type Lista. If the function
is an external function, that information isn't "magically" known to
anything that references the function. There are lots of ways to make
this known. I generally recommend making all procedures module
procedures, in which case the USE statement for the module brings this
information in.

You also have other problems here. I didn't take the time to study this
carefully, but 2 things jump right out at me.

1. The function requires an explicit interface (because it returns a
pointer, which is one of the many things that can trigger such a
requirement). Just declaring the return type won't be enough. This is
yet further argument for making it a module function.

But, *MOST IMPORTANTLY*

I strongly recommend against using functions that return pointers. Use
subroutines instead. I've had to repeat this advice several times
recently. I don't think you were one of the people I formerly gave it to.

Functions that return pointers are *VERY* error prone. Even experts are
likely to get them wrong. Your code has one of the more common major
errors. I'm not even going to bother to point it out because I feel that
this would be counter-productive - it would just encourage you to try to
fix the one case... and you'd make another error elsewhere. This is not
intended as a personal aspersion - as I said, experts make these errors.
The best solution is to use subroutines, which aren't as prone to the
same errors. (Of course, one can make errors with about anything, but
functions that return pointers are especially prone to it).

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.



Relevant Pages

  • Re: Function returning derived data type
    ... that return pointers (use subroutines instead). ... derived type objects that have components that need to be freed after ... just have to avoid that situation. ...
    (comp.lang.fortran)
  • Re: Passing pointers to subroutines in other modules
    ... Håkan Lane wrote: ... completely impossible to pass private arrays (pointers or allocatable) ... to subroutines in other modules in a large application. ...
    (comp.lang.fortran)
  • Re: getting wrong answers
    ... inv is a pointer to B, and then B is immediately deallocated, ... I also note that these are functions that return pointers. ... If you need to return pointers, use subroutines. ... that is my only advice on the subject. ...
    (comp.lang.fortran)
  • Re: Mercedes WIS programme
    ... yes got it going but it took a few goes and it is prone to shutting down ... Any other pointers as to how to get it running? ... Compaq presario 2100 running ...
    (alt.auto.mercedes)
  • Functions returning pointers considered harmful (was: HELP ME - HOW THIS ERROR?)
    ... > I strongly recommend against using functions that return pointers. ... > subroutines instead. ... Richard, ...
    (comp.lang.fortran)