------- Comment #6 from burnus at gcc dot gnu dot org 2010-05-04 16:10 ------- Created an attachment (id=20557) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20557&action=view) First draft patch
(In reply to comment #5) > (In reply to comment #4) > > What a horrible rule... What do you mean? Allowing "name()" as (generic) constructor (function)? Why not? That matches the natural use. If you mean the constraint in comment 3: That just ensures that one cannot have use a structure constructor and generic function simultaneously. > Intel has promised to support it in its next release. Well, I can also promise that _one_ of the next releases will have it :P At least there are plans to improve OOP and there is also a Summer of Code projects for OOP, cf. http://gcc.gnu.org/wiki/SummerOfCode * * * Attached is a draft patch which should work in simple cases. TODO: * Call structure constructor if no generic function matches; that means: Converting the actual arguments into a constructor and do the checking (cf. FIXME in resolve.c) * Add a is-function check: "A generic name may be the same as a derived-type name, in which case all of the procedures in the interface block shall be functions." (Note: That's not a constraint thus one does not need to catch all cases.) * Fix the case of first defining the generic name and then the type: interface t procedure t2 end interface t type t end type t * Add a new "%X" (X = some letter) to finally solve the "@" printing problem in error messages for PPC and for constructors (this PR): gfc_error should then simply strip the @... from the message for arguments to %X while for %s no extra stripping is done as it is currently done. One then only needs to change all relevant %s to %X and one is done. (using a more-intuitive different latter than %X would be helpful; maybe %S = Symbol String?.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
