From owner-sc22wg5@open-std.org Fri Jul 30 10:21:07 2010 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 9A35EC3BA0E; Fri, 30 Jul 2010 10:21:07 +0200 (CEST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mk-filter-4-a-1.mail.uk.tiscali.com (mk-filter-4-a-1.mail.uk.tiscali.com [212.74.100.55]) by www2.open-std.org (Postfix) with ESMTP id 959A5C3BA06 for ; Fri, 30 Jul 2010 10:21:03 +0200 (CEST) X-Trace: 452956381/mk-filter-4.mail.uk.tiscali.com/B2C/$b2c-THROTTLED-DYNAMIC/b2c-CUSTOMER-DYNAMIC-IP/88.106.87.100/None/d.muxworthy@bcs.org.uk X-SBRS: None X-RemoteIP: 88.106.87.100 X-IP-MAIL-FROM: d.muxworthy@bcs.org.uk X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Apple Mail (2.753.1) X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMBABaQHkxYaldk/2dsb2JhbAAHklzNJoJRAYJJBA X-IronPort-AV: E=Sophos;i="4.53,450,1272841200"; d="scan'208";a="452956381" Received: from 88-106-87-100.dynamic.dsl.as9105.com (HELO [192.168.1.2]) ([88.106.87.100]) by smtp.tiscali.co.uk with ESMTP; 30 Jul 2010 09:21:03 +0100 Mime-Version: 1.0 (Apple Message framework v753.1) References: <4C51AC7D.2000805@lrz.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4681C640-44F9-4AED-8184-6A1457CAB6E3@bcs.org.uk> Content-Transfer-Encoding: 7bit From: David Muxworthy Subject: Re: (SC22WG5.4305) Executing a type-bound procedure on a coindexed object Date: Fri, 30 Jul 2010 09:21:36 +0100 To: sc22wg5@open-std.org X-Mailer: Apple Mail (2.753.1) Sender: owner-sc22wg5@open-std.org Precedence: bulk Forwarded on behalf of Reinhold. The message was sent to owner-sc22wg5@open-std.org rather than sc22wg5@open-std.org Begin forwarded message: From: Reinhold Bader Date: 29 July 2010 17:29:49 BST To: owner-sc22wg5@open-std.org Cc: j3@j3-fortran.org Subject: Re: (SC22WG5.4305) Executing a type-bound procedure on a coindexed object Hello, Micki St. James schrieb: > It does look as though what the standard gives with one hand it takes > away with the other. > [...] > > As I recall the discussions from November 2008 when the cited > paragraph > was added to 12.5.2.4, > the basic problem with polymorphic actual corresponding to polymorphic > dummy is that the actual might have > allocatable components of arbitrary size and at compile-time > there's no > telling how many bytes > would have to be copied from the image where the polymorphic coindexed > object lives to the local storage > where the procedure call is happening. (That's if you're doing > copyin/copyout I guess.) This does not seem to make sense. The case you mention can also happen in a non-polymorphic scenario, but there are no restrictions there. I agree that there is no possibility to resolve this at compile-time. Similarly, intrinsic assignments to local objects seem to be allowed (which is technically not that different): a = b[i] ! a with allocatable component, which is auto-allocated. whether or not a is polymorphic, while of course b[i] = a is not since that would require remote allocation. The overhead for the polymorphic case would appear to me to only be the additional metadata required for performing typed allocation. So presently the added restriction appears to me to be rather ill- advised ... Regards Reinhold > So even if the NOTE tells you how to avoid visiting a distant image > to find > the dynamic type of the actual argument, that isn't enough to let the > compiler set up the call at compile-time. > > Not sure I remembered all this right. > > Micki End forwarded message