This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran, F03] PR 40869: PPC assignment checking


>> I'd very much prefer to leave these units intact and follow an
>> OOP-like approach, where both data structures would have common base
>> type, or one would be the parent type of the other, containing a
>> subset of its components. (This is actually a point where the gfortran
>> source could benefit a bit from C++.)
>>
>> One may think about trying something like this in C (but I guess it
>> would be rather dirty). At a minimum, the common components of
>> gfc_symbol and gfc_component would have to be aligned to each other,
>> so that pointers could be recast from one type to the other.
>
> This I don't like at all -- I think casting pointers even if the members are
> aligned is something one should be very careful with.

Yeah, right, that's why I called it 'dirrrty' ;)
I was not really proposing we should do this, just mentioning the possibility.


> BTW, I'm not sure C++ would help here much; you said you'd like to make
> gfc_component a super-type of gfc_symbol, so the common stuff could be
> accessed. ?But I think you could have this cheaply in plain C without C++ at
> all -- just remove all common fields from gfc_symbol and make it have a
> gfc_component member. ?The real problem here is working with existing code,
> isn't it?

Sure, you could do this. But it would trigger an enormous amount of
(mechanical) changes, since you're changing the structure of
gfc_symbol, which is probably the most prominent data structure in
gfortran.

These changes would not be necessary if you use a C++-style
inheritance mechanism, because you can access all the members of
gfc_symbols as before (and I think it would have some more
advantages).

But let's not argue about this too much. GCC probably won't switch to
C++ in the very near future anyway (though I personally don't think it
would be such a bad idea). I was basically just dreaming up some ideas
here, like: "If gfortran was written in C++, we could do this and that
...." :)

Cheers,
Janus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]