Prev: Problems matching between FORTRAN COMMON and C struct defined in a ?dll
Next: Problems matching between FORTRAN COMMON and C struct definedin a dll
From: Richard Maine on 30 Mar 2010 18:27
yaqi <yaqiwang(a)gmail.com> wrote:

> I guess it depends on the compiler.
>
> With IVF, the following does not work:
>
> type mytype
> integer, pointer, dimension(:) :: ptr => null()
> end type mytype
> integer, target :: a(2) = (/1, 2/)
> type(mytype) :: c = mytype(a)
>
> The error message is "error #6592: This symbol must be a defined
> parameter, an enumerator, or an argument of an inquiry function that
> evaluates to a compile-time constant. [A]".

That's because it is an initialization, which has some extra
requirements. I haven't checked the fine print to figure out whether
that ought to work. You wouldn't be able to use "a" for initialization
of a data component (for the reasons cited in the message). One might
think pointers would have a different set of restrictions, but maybe
they don't (even though maybe they should). As I said, I didn't check
the fine print on that. But I bet that if instead of

type(my_type) :: c = mytype(a)

you do

type(my_type) :: c
c = mytype(a)

it should work because then it is not in an initialization.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: yaqi on 30 Mar 2010 18:37
On Mar 30, 4:27 pm, nos...(a)see.signature (Richard Maine) wrote:
> yaqi <yaqiw...(a)gmail.com> wrote:
> > I guess it depends on the compiler.
>
> > With IVF, the following does not work:
>
> > type mytype
> >   integer, pointer, dimension(:) :: ptr => null()
> > end type mytype
> > integer, target :: a(2) = (/1, 2/)
> > type(mytype) :: c = mytype(a)
>
> > The error message is "error #6592: This symbol must be a defined
> > parameter, an enumerator, or an argument of an inquiry function that
> > evaluates to a compile-time constant.   [A]".
>
> That's because it is an initialization, which has some extra
> requirements. I haven't checked the fine print to figure out whether
> that ought to work. You wouldn't be able to use "a" for initialization
> of a data component (for the reasons cited in the message). One might
> think pointers would have a different set of restrictions, but maybe
> they don't (even though maybe they should). As I said, I didn't check
> the fine print on that. But I bet that if instead of
>
>   type(my_type) :: c = mytype(a)
>
> you do
>
>   type(my_type) :: c
>   c = mytype(a)
>
> it should work because then it is not in an initialization.
>
> --
> Richard Maine                    | Good judgment comes from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle           |  -- Mark Twain

Then it has to been explicitly done during run-time, which is what I
am try to avoid.

I do want an initialization taken care of by the compiler.
From: Ian Harvey on 30 Mar 2010 22:03
On 31/03/2010 9:37 AM, yaqi wrote:
> I do want an initialization taken care of by the compiler.

Why do you care about the runtime initialisation? It's hardly likely to
be expensive in terms of clock cycles.

What are you trying to do with these pointers? One reason for using
pointers is that they can point to different things. Previously you had
the pointer as a component in a parameter (a compile time constant), so
at best it could only ever "point" to one thing. I don't see the point
to that, even if you could express it in Fortran...
First  |  Prev  | 
Pages: 1 2 3
Prev: Problems matching between FORTRAN COMMON and C struct defined in a ?dll
Next: Problems matching between FORTRAN COMMON and C struct definedin a dll