220 38944 article Path: news.gmane.org!.POSTED!not-for-mail From: Bengt Gustafsson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allow forward class declarations to match a type alias. Date: Sat, 30 Jun 2018 13:23:41 -0700 (PDT) Lines: 221 Approved: news@gmane.org Message-ID: References: <49cde8d1-312f-4c4c-a26e-91bbb1c56a2d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_24170_978999686.1530390221524" X-Trace: blaine.gmane.org 1530390096 4361 195.159.176.226 (30 Jun 2018 20:21:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 30 Jun 2018 20:21:36 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCRIRSPDTQIRBTWN37MQKGQEO3FVV5Q@isocpp.org Sat Jun 30 22:21:32 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fZMNA-00012A-E3 for gclcip-std-proposals@m.gmane.org; Sat, 30 Jun 2018 22:21:32 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id v6-v6sf6835224ywg.10 for ; Sat, 30 Jun 2018 13:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=PsZz8k0FswKU5b/kI2MOQw6LzbmvoM61zcJ0NR/BkFs=; b=b4gko3qCruMqm+P904moLrPKWCN/60fkt6/pBIZhsl/iMonwC60GyZPB8yuad/DI1Y 8vivSohhq4d+oReVOo737pFR8ug8WV9bPe/jYCXOlEAb/qjIiKmWgIp9e/BjMVyu0COl mirmw3eg7akVWZo0OETW1d+vgqdMBeodY4pz7+E60w5cZhqSoLrLN8bf+0DCx9toiO8P kaQFvTXrXhr4NM8oHHMlyxBZlwoiK+njedhBDaBJGelZ3ItfSnaj+8a0qlKIH5S7723D VXEaYIOLnvvqdoHJCiOnw5JRWBg1kFyBtWIudif8rLYolDRqUwNf3LWrMcZSS9mvHz0Y fMkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=PsZz8k0FswKU5b/kI2MOQw6LzbmvoM61zcJ0NR/BkFs=; b=XQt9sk7SSV5ICDLLkR0wtOsEzn7c0685BVgQGjFhucHB6grr77AWrxZAs7/CPTf+R7 z4XzxvbVeUQK74vL3jn6Rzv+AVF7UulTQleymGFB53Gs879Aw56n4Bj+OH/K+RaMP+tU WF3HMdsxC7v2gBGX7EX5dzbVYSqCisrLg9WaGEelWMgakCQ/PrPvSbvLVgJIaUlJTIh4 1BnsXNDsGcpylwJ5YECC8meTXZSZGLaolSgnj/NgaEnLcDaKp/5wc7xN/Cc9gdebiSMD Nvm+0PYyzUqduNpiePmsshplGRzdmP3d13APC27EYTv6Ck1iSOXYGxDFriDDFlT5pg5D k67g== X-Gm-Message-State: APt69E3vkz9iPPZ26sU9lcoanwZi4QdUvXUjBc7zzYQl9PljCbN3t600 EWkS4H3fdto0EBe+fX7OMcSvLw== X-Google-Smtp-Source: AAOMgpeBh2B0Y2DUKRBaH3PXxmk4Qw3rOZNk0NYN9GSSBR8GOAJWb2qScwlGOFF0wsspR3ncm0O4KA== X-Received: by 2002:a5b:187:: with SMTP id r7-v6mr3594220ybl.85.1530390223483; Sat, 30 Jun 2018 13:23:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:6dd1:: with SMTP id i200-v6ls2498727ywc.3.gmail; Sat, 30 Jun 2018 13:23:42 -0700 (PDT) X-Received: by 2002:a0d:d386:: with SMTP id v128-v6mr1900453ywd.1.1530390222039; Sat, 30 Jun 2018 13:23:42 -0700 (PDT) In-Reply-To: <49cde8d1-312f-4c4c-a26e-91bbb1c56a2d@isocpp.org> X-Original-Sender: bengt.gustafsson@beamways.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:38944 Archived-At: ------=_Part_24170_978999686.1530390221524 Content-Type: multipart/alternative; boundary="----=_Part_24171_587172068.1530390221525" ------=_Part_24171_587172068.1530390221525 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In my previous response I acknowedged the explanation that this has to do= =20 with name mangling, where ultimately the class name would be mangled=20 according to its real identity, i.e. CudaImage and thus that a=20 forward declaration "class FloatImage;" would be natural to reject. However, on second thought, FloatImage just as any class name is not an=20 entity in itself that is known to the linker. And as you can't call methods= =20 on a class without seeing its full definition there is no risk that=20 references to erroneously mangled method names sneak in to an object module= =20 compiled only seeing the forward declaration, right? With this in mind, is= =20 there a technical reason that=20 my initial construct must be forbidden? I don't see that Nicol's=20 explanation holds "FloatImage turns out eventually to be a type alias and= =20 not a class". But the very reason for having a type alias is to give a=20 class another name, so why can't it be forward declared under this=20 alternate name? Of course, if it was eventually a non-class type (or a=20 variable or a function) the forward declaration would be erroneous, but=20 that's the peril we have with allowing forward declarations at all... if=20 they are in error there is no way to catch it... until modules, I guess. I'm also considering this in the context of the proposed extension of alias= =20 declarations to other types of entities such as functions and variables.=20 This has been touted as a way to avoid backwards compatibility issues, but= =20 if we can't extern declare functions and variables under their now=20 deprecated names the utility of this feature is reduced as we would in some= =20 cases have to "tamper" with the untouchable code base that made the aliases= =20 necessary in the first place. This said, it seems appropriate to ask if it would be possible to make the= =20 alias names known to the linker so that function calls to the alias name=20 (allowed by a forward declaration of the function under its old name) can= =20 be resolved. I don't think this would be a problem with any contemporary=20 linker/object file format, but maybe the language specification's concept= =20 of a linker does not include such facilities. At least this consideration and a chosen strategy should be part of a=20 generalized alias declaration proposal. Either such a strategy must mandate= =20 that the linker knows of the function/global variable under both names or= =20 it must show why this is not important even when claiming that the main=20 motivation for the feature is being able to deprecate old names without=20 having to change code using the entities under their old names. I guess=20 this is a matter of having to compile with new headers or having to link=20 with new libraries. Den l=C3=B6rdag 30 juni 2018 kl. 09:52:31 UTC+2 skrev mihailn...@gmail.com: > > > > On Saturday, June 30, 2018 at 9:49:52 AM UTC+3, Bengt Gustafsson wrote: >> >> I got one good answer: it is not possible due to name mangling having to= =20 >> know that FloatImage will resolve to a template instance. I used the=20 >> proposed solution but it unfortunately had me change the forward=20 >> declarations of FloatImage.=20 > > > What solution did you use?=20 > I did update the forward declaration to the proposed: template class CudaImage; using FloatImage =3D CudaImage; =20 > Did you try the concrete class solution - it is not as na=C3=AFve as it s= ounds,=20 > not as hard as it sounds (in C++11+) and has many protentional side=20 > benefits. > No, I didn't. This would have worked with some amount of boilerplate, but I= =20 wanted to see if I could do without this extraneous class. =20 > > Otherwise the classical solution is not to forward declare a class but to= =20 > have xxxfrw.h header instead, where you can put all "leakage of=20 > implementation detail". > Sure, that would have been a possibility. =20 --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/abdf6051-28fa-48e6-81c6-20eff0a2d4de%40isocpp.or= g. ------=_Part_24171_587172068.1530390221525 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In my previous response I acknowedged the explanation that= this has to do with name mangling, where ultimately the class name would b= e mangled according to its real identity, i.e. CudaImage<float> and t= hus that a forward declaration "class FloatImage;" would be natur= al to reject.

However, on second thought, FloatImage just as any cl= ass name is not an entity in itself that is known to the linker. And as you= can't call methods on a class without seeing its full definition there= is no risk that references to erroneously mangled method names sneak in to= an object module compiled only seeing the forward declaration, right? With= this in mind, is there a technical reason that=C2=A0
my ini= tial construct must be forbidden? I don't see that Nicol's explanat= ion holds "FloatImage turns out eventually to be a type alias and not = a class". But the very reason for having a type alias is to give a cla= ss another name, so why can't it be forward declared under this alterna= te name? Of course, if it was eventually a non-class type (or a variable or= a function) the forward declaration would be erroneous, but that's the= peril we have with allowing forward declarations at all... if they are in = error there is no way to catch it... until modules, I guess.

=
I'm also considering this in the context of the proposed ext= ension of alias declarations to other types of entities such as functions a= nd variables. This has been touted as a way to avoid backwards compatibilit= y issues, but if we can't extern declare functions and variables under = their now deprecated names the utility of this feature is reduced as we wou= ld in some cases have to "tamper" with the untouchable code base = that made the aliases necessary in the first place.

This said, it seems appropriate to ask if it would be possible to make th= e alias names known to the linker so that function calls to the alias name = (allowed by a forward declaration of the function under its old name) can b= e resolved. I don't think this would be a problem with any contemporary= linker/object file format, but maybe the language specification's conc= ept of a linker does not include such facilities.

= At least this consideration and a chosen strategy should be part of a gener= alized alias declaration proposal. Either such a strategy must mandate that= the linker knows of the function/global variable under both names or it mu= st show why this is not important even when claiming that the main motivati= on for the feature is being able to deprecate old names without having to c= hange code using the entities under their old names. I guess this is a matt= er of having to compile with new headers or having to link with new librari= es.




Den l=C3=B6rdag 30= juni 2018 kl. 09:52:31 UTC+2 skrev mihailn...@gmail.com:


On Saturday, June 30, = 2018 at 9:49:52 AM UTC+3, Bengt Gustafsson wrote:
I got one good answer: it is not possible due to name manglin= g having to know that FloatImage will resolve to a template instance. I use= d the proposed solution but it unfortunately had me change the forward decl= arations of FloatImage.

=C2=A0What solutio= n did you use?=C2=A0
I did update the forward = declaration to the proposed:


tem= plate<typename T> class CudaImage;
using FloatImage = =3D CudaImage<float>;


=C2=A0
Did you try the concrete class solution - it is not as = na=C3=AFve as it sounds, not as hard as it sounds (in C++11+) and has many = protentional side benefits.
No, I didn'= ;t. This would have worked with some amount of boilerplate, but I wanted to= see if I could do without this extraneous class.
=C2=A0
=
Otherwise the classical solution is not to forward declare a= class but to have xxxfrw.h header instead, where you can put all "leakage of imp= lementation detail".
Sure, that wo= uld have been a possibility.
=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/abdf6051-28fa-48e6-81c6-20eff0a2d4de= %40isocpp.org.
------=_Part_24171_587172068.1530390221525-- ------=_Part_24170_978999686.1530390221524-- .