Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Public Generic TBP with Private TBP Resolution

7 views
Skip to first unread message

Andrew Baldwin

unread,
Apr 28, 2011, 1:33:17 PM4/28/11
to
I'm trying to create a generic type-bound procedure that resolves to a private type-bound procedures. Here is a short sample code that does just that:

program quicktest
use qtest

type (foobar) :: foo
integer :: bar
bar = foo%getx()

end program quicktest

module qtest

type foobar
integer :: x
contains
private
procedure :: gimmex
generic, public :: getx => gimmex
end type foobar

contains
function gimmex(foo)
class (foobar) :: foo
integer :: gimmex
gimmex = foo%x
end function gimmex
end module qtest

However, when compiling with gfortran 4.7.0 20110409 I receive the error:

bar = foo%getx()
1
Error: 'gimmex' of 'foobar' is PRIVATE at (1)

This code is a little silly, but ultimately I want the generic TBP to resolve to one of two PRIVATE procedures (so that they can only be called through the generic TBP). My understanding of the PRIVATE attribute and an example in "fortran 95/2003 explained" (page 281) leads me to believe that this was once possible. I have difficulty parsing the standard directly, but I would expect it should still be possible.

Is this code non-conforming? If so, is there a way I can change it to be conforming with similar functionality?

Richard Maine

unread,
Apr 28, 2011, 2:09:42 PM4/28/11
to
Andrew Baldwin <klaus...@gmail.com> wrote:

> I'm trying to create a generic type-bound procedure that resolves to a
private type-bound procedures. Here is a short sample code that does
just that:

[code elided]

> Is this code non-conforming? If so, is there a way I can change it to be
conforming with similar functionality?

The code looks fine to me. F90 had some queer restrictions on the
private attribute. Those restrictions arise from people on the committee
failing to understand what private was really about; they then tried to
press it into roles where it just didn't fit. I recall spending quite a
lot of time elaborating why the queer restrictions did not and could not
reasonably say quite what many people (including some compiler writers)
were reading into them. That got sort of addressed in a convoluted
published interpretation.

That interpretation left the queer restrictions in place for f90, but at
least kept them from being read in a way that completely destroyed the
utility of the private attribute.

It took until f2003 to do the much better fix of removing the
restrictions. If they weren't removed, they would have done further
damage to some of the object oriented stuff, all to no constructive end.

So if you were talking about f95, I'd have to go back and carefully
check in detail what the misguided restrictions said. But type-bound
procedures are an f2003 feature and you just can't reasonably answer
questions about them based on f95, even though gfortran is still an f95
compiler with some f2003 features. (Insert here and emphasize my usual
rant about what an important difference there is between having isolated
f2003 features and having an f2003 compiler; you never know exactly what
things got included as part of the isolated features).

One of the big advantages of using type-bound procedures in f2003, even
for non-polymorphic types, is that you *CAN'T* accidentally "drop" them
like you can with non-type-bound generics. You don't need them to be
public. You don't have to access them via USE or do anything to make
them available. They are automatically available wherever there is an
object of a relevant type. With non-type-bound procedures, it is all too
easy to accidentally invoke intrinsic assignment on a type that you
intended to always use a defined assignment.

At least in f2003, the PRIVATE attribute is "clean" and pretty easy to
explain. *ALL* that it does is avoid making the name available via USE
association. If you don't see the actual name (ok, identifier in
general, but the case here is a name, as are most cases) spelled out
somewhere that is accessing it via USE, then the PRIVATE attribute
doesn't matter. It doesn't matter whether you reference the thing by any
other means. In some sense, the PRIVATE attribute doesn't actually
attach to the entity, but only to the name of the entity.

I think it would have been more clear to name PUBLIC/PRIVATE something
like EXPORT/NOEXPORT. Those aren't great names either, though. In any
case, it is over 2 decades too late for that to change. PRIVATE is just
abysmal as a keyword because it doesn't actually mean that the entity is
private. The standard itself says as much. It says that PUBLIC means
that the entity is public, but where you might expect it to simillarly
say that PRIVATE means private, it doesn't say that (because it isn't
so). Yukk. That gets into some of the messy part of that old f90/f95
interp.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

Tobias Burnus

unread,
Apr 28, 2011, 3:05:14 PM4/28/11
to
Richard Maine wrote:
> Andrew Baldwin<klaus...@gmail.com> wrote:
>> I'm trying to create a generic type-bound procedure that resolves to a
> private type-bound procedures. Here is a short sample code that does
> just that:
>
> [code elided]
>
>> Is this code non-conforming? If so, is there a way I can change it to be
> conforming with similar functionality?
>
> The code looks fine to me.

It also looks fine to gfortran 4.5. I add it to the list of things which
regressed in GCC 4.6/4.7 :-(

See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48810 for the problem
report. The plan is to fix all (known) 4.6/4.7 regressions before 4.6.1
is released end of May ...

Thanks for reporting the issue - and sorry for breaking this feature.

Tobias

Andrew Baldwin

unread,
May 3, 2011, 8:34:24 PM5/3/11
to
Thank you both for your fast and thorough responses, and for getting it fixed so quickly!
0 new messages