220 29569 <5af23587-d714-45bd-b04c-77592ba66e03@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Instantiation of default destructor Date: Mon, 28 Nov 2016 15:24:58 -0800 (PST) Lines: 265 Approved: news@gmane.org Message-ID: <5af23587-d714-45bd-b04c-77592ba66e03@isocpp.org> References: <1a7a1b18-c001-405e-8f7f-09c048c6ee14@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7829_270404834.1480375498479" X-Trace: blaine.gmane.org 1480375503 10608 195.159.176.226 (28 Nov 2016 23:25:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 23:25:03 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIMX6PSYECRUBCJ42TPA@isocpp.org Tue Nov 29 00:24:57 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f200.google.com ([209.85.213.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cBVI8-0001St-Kd for gclcip-std-proposals@m.gmane.org; Tue, 29 Nov 2016 00:24:57 +0100 Original-Received: by mail-yb0-f200.google.com with SMTP id v78sf127155141ybe.0 for ; Mon, 28 Nov 2016 15:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=DCS6J013wP31q9ffBrDHsV1VGvh0iLAF1TJOZePGorM=; b=fP8eao9wKieeVQWxlaQz8vSfbBeofALgFsFPNuVHjJwH3V973Ks5ytIHP74ekvWjIy wYI6Ac4SMD90JfArdj/RprSrOmqmm2dNWgxeoEtE+CQAkajDHx+ApYe50V75bXXmRZo1 V8Mvc2JEd9WuKrBol93SdXptST+vkFAfT8TWt4nadMcEbWvOng4xq10iAqmdV9FOepzz HVSgZh56yTuF98CrDRnhyP2/j+r27DZSZMjo1pn2j1QIEogXgHM/syKBRsqfDvBhVRWG 6Bvrskc0rE7qDTwRg943LtRW0i6PmbgB/jsRY1eC6J2tTkfV3kfXl6LAzWZiyrfkftpl 2wiw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to: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=DCS6J013wP31q9ffBrDHsV1VGvh0iLAF1TJOZePGorM=; b=eX0mGABlvvoSXjuUudqF25a/BtDT34lLm9RVzzb1PbcUQAy/HLMLU9JT8zeUpODsAw 85Krf1z/lSVq3IJ9qlTV+CBALL3qG9hwlNCY8Hi441CEWTKPTtLWVDyjtoIgm7MAYa2E f5QDnxf0GL9r/RRlrugZiIztB7qtdA1x8Uaji9QCdkg8Z9oPUH/GldsfHZss0ng4v2vi miwh0pMSbHYC8mcNCkOp+z2Yjb0RnP9DbtycfhlqhSrqBOoh6w9vJD/QklInOfixIgwm cfD+9O5oIr18w5QhYvBjbZJnhrpLAZjdtB8hIKay6aTUUiqt4WxcaD1zUYwczZftyFQW K0Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to: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=DCS6J013wP31q9ffBrDHsV1VGvh0iLAF1TJOZePGorM=; b=LoZqeg+Q8gJnxto9OC+t9n/S5TiDWXKfILDGnOeKVUzrVRZgvnDAwBeIMrIIcXboHI KNIrm5aHZPZFfzpHEi0ssjWDQOaRnfJ0aTF54W749PqOhrgW1UT4zWfEVWAnT44/GxDb LxykLoC04l0mjsWh8TiF7ImemTMupvZZkk46DrqQI62zeIM6xGBIhY7JmmvK1jU/EYYy ciIpEsUc4RDy2hll4MmM+o/y9M4hGv2VjzA3fp/5Mo14yKTDfmPgPlanO4dagXeQ1pZc iZeFi5Mkb9Qg1nMbr6pvzG7jfMGOdOEpTWz+MrDVhQ8kMgYsvSLCzzCoIaQMckbnyhoo hJ7g== X-Gm-Message-State: AKaTC00+AidyBIjHi5M0wRaOp6ymDdq9a9G24PXI63r4XUyEmlY6VF0m5En2LOewyhBjOQ== X-Received: by 10.129.32.4 with SMTP id g4mr5584420ywg.20.1480375499783; Mon, 28 Nov 2016 15:24:59 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.11.242 with SMTP id 105ls11700098oth.30.gmail; Mon, 28 Nov 2016 15:24:59 -0800 (PST) X-Received: by 10.157.39.129 with SMTP id c1mr743040otb.15.1480375498959; Mon, 28 Nov 2016 15:24:58 -0800 (PST) In-Reply-To: X-Original-Sender: arthur.j.odwyer@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:29569 Archived-At: ------=_Part_7829_270404834.1480375498479 Content-Type: multipart/alternative; boundary="----=_Part_7830_1317441430.1480375498479" ------=_Part_7830_1317441430.1480375498479 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, November 28, 2016 at 10:53:00 AM UTC-8, Domen Vrankar wrote: > > 2016-11-28 16:11 GMT+01:00 Nicol Bolas >: > >> On Monday, November 28, 2016 at 7:14:55 AM UTC-5, Domen Vrankar wrote: >>> >>> >>> In this video [1] (time= =20 >>> 57:40) Jason Jurecka was talking about the need to write empty/defaulte= d=20 >>> destructor in cpp file if you want to declare a class in header file, u= se=20 >>> it in std::unique_ptr and include its declaration only in cpp file: >>> [...snip example of PImpl idiom with outer class "A" and impl class=20 >>> "T"...] >>> For me it's not a big deal to write A::~A() =3D default; in cpp file bu= t=20 >>> still since we've had that debate I was wondering if it would be feasib= le=20 >>> to change the wording (don't know how much the standard would have to b= e=20 >>> changed for that) so that implicit default destructor would be added to= the=20 >>> code at the point of first constructor implementation (in the above exa= mple=20 >>> at the point of A::A(T* ptr_); implementation in .cpp file) and not at = the=20 >>> end of the file where the class was declared? >>> >> >> You've misunderstood the nature of the problem.=20 >> > >> The default destructor will call `unique_ptr::~unique_ptr`. And that=20 >> destructor will call `T::~T()`. The problem is that, unless `T` has been= =20 >> *defined*, you cannot call its destructor. >> > > I understand that but I always expected that it has to be known at the=20 > point of destructor call like you would declare a variable before using i= t. > You're forgetting that there are two different classes here. Outer class=20 "A" has a constructor and a destructor; impl class "T" also has a=20 constructor and a destructor. The problem is that at the point where you're= =20 trying to define A's destructor, the nature (e.g. the signature) of T's=20 destructor is not known. =20 Forget about "where" A's destructor is "defined" in terms of lines of the= =20 source file. That doesn't matter (or make sense) at all. There is no=20 "defined at the beginning of the file, defined at the end of the file"; or= =20 at least, not that matters here. All that matters is which scopes can=20 actually see the signature (and existence) of T's destructor, and which=20 ones can't. The problem will probably get a lot clearer if we avoid talking about=20 constructors and destructors, and just talk about plain old member=20 functions =E2=80=94 since the specialness of these member functions doesn't= =20 actually affect the core issue at all. The issue is the following: =3D=3Dalpha.h=3D=3D template struct Alpha { T *ptr; }; =3D=3Dbeta.h=3D=3D #include "alpha.h" struct Gamma; struct Beta { Alpha a; void fbeta() { a.ptr->fgamma(); } }; =3D=3Dgamma.h=3D=3D struct Gamma { void fgamma(); // defined somewhere else, or whatever; doesn't really= =20 matter }; Notice that "beta.h" WILL NOT COMPILE because the compiler has no way of=20 knowing that (*a.ptr) actually has a member function named fgamma =E2=80=94= because=20 there is no class definition for struct Gamma in scope. This is NOT FIXABLE= =20 by moving around function definitions, since the root cause has nothing to= =20 do with function definitions; it has to do with class definitions. The=20 appropriate fix is either to #include "gamma.h" in "beta.h" (thus pulling a= =20 class definition into scope), or else move the definition of member=20 function fbeta() from "beta.h" into some other translation unit where=20 "gamma.h" has already been #included. You can do the following transformations on this example: - out-of-line a new member function Alpha::falpha() to hold the=20 ptr->fgamma() call - replace fgamma() with ~Gamma() - replace fbeta() with ~Beta() - replace falpha() with ~Alpha() - replace Gamma with T - replace Beta with A - replace Alpha with std::unique_ptr but none of those transformations change any of the core features of the=20 example. Sure we *could* introduce a bunch of special cases for when the problem=20 *does* involve constructors and destructors (incidentally, notice that my= =20 example does not have any analogues for the constructors in your original= =20 code), but that would just obfuscate the issue and make it harder to teach.= =20 Look =E2=80=94 I was able to show the core issue to you in a single forum p= ost,=20 precisely because all the things you brought up turned out to be=20 distractions. Imagine how hard it would be to teach the core issue if all= =20 those things (constructors, destructors, locations in source files...)=20 *were* to be made significant! The core issue wouldn't go away; it would= =20 just get a heck of a lot more confusing to teach anyone. HTH, =E2=80=93Arthur --=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/5af23587-d714-45bd-b04c-77592ba66e03%40isocpp.or= g. ------=_Part_7830_1317441430.1480375498479 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Monday, November 28, 2016 at 10:53:00 AM UTC-8, Domen V= rankar wrote:
= 2016-11-28 16:11 GMT+01:00 Nicol Bolas <jmck...@gmail.com>:
On Monday, November 28, 2016 at= 7:14:55 AM UTC-5, Domen Vrankar wrote:

In this video [1] (time 57:40) Jaso= n Jurecka was talking about the need to write empty/defaulted destructor in= cpp file if you want to declare a class in header file, use it in std::uni= que_ptr and include its declaration only in cpp file:
[...snip example o= f PImpl idiom with outer class "A" and impl class "T"..= ..]
For me it's not a big deal to write A::~A() =3D default; i= n cpp file but still since we've had that debate I was wondering if it = would be feasible to change the wording (don't know how much the standa= rd would have to be changed for that) so that implicit default destructor w= ould be added to the code at the point of first constructor implementation = (in the above example at the point of A::A(T* ptr_); implementation in .cpp= file) and not at the end of the file where the class was declared?

You've misunderstood the nature of the= problem.

The default destructor will call `u= nique_ptr::~unique_ptr`. And that destructor will call `T::~T()`. The probl= em is that, unless `T` has been defined, you cannot call its destruc= tor.

I understand that but = I always expected that it has to be known at the point of destructor call l= ike you would declare a variable before using it.

You're forgetting that there are two= different classes here. Outer class "A" has a constructor and a = destructor; impl class "T" also has a constructor and a destructo= r. The problem is that at the point where you're trying to define A'= ;s destructor, the nature (e.g. the signature) of T's destructor is not= known.
=C2=A0
Forget about "where" A's d= estructor is "defined" in terms of lines of the source file. That= doesn't matter (or make sense) at all. There is no "defined at th= e beginning of the file, defined at the end of the file"; or at least,= not that matters here. All that matters is which scopes can actually see t= he signature (and existence) of T's destructor, and which ones can'= t.

The problem will probably get a lot clearer if = we avoid talking about constructors and destructors, and just talk about pl= ain old member functions =E2=80=94 since the specialness of these member fu= nctions doesn't actually affect the core issue at all. The issue is the= following:

=3D=3Dalpha.h=3D=3D
template= <class T> struct Alpha {
=C2=A0 =C2=A0 T *ptr;
};=

=3D=3Dbeta.h=3D=3D
#include "a= lpha.h"
struct Gamma;
struct Beta {
=C2= =A0 =C2=A0 Alpha<Gamma> a;
=C2=A0 =C2=A0 void fbeta() { a.p= tr->fgamma(); }
};

=3D=3Dgamma.h=3D= =3D
struct Gamma {
=C2=A0 =C2=A0 void fgamma(); =C2= =A0// defined somewhere else, or whatever; doesn't really matter
<= div>};

Notice that "beta.h" WILL NOT COM= PILE because the compiler has no way of knowing that (*a.ptr) actually has = a member function named fgamma =E2=80=94 because there is no class definiti= on for struct Gamma in scope. This is NOT FIXABLE by moving around function= definitions, since the root cause has nothing to do with function definiti= ons; it has to do with class definitions. The appropriate fix is either to = #include "gamma.h" in "beta.h" (thus pulling a class de= finition into scope), or else move the definition of member function fbeta(= ) from "beta.h" into some other translation unit where "gamm= a.h" has already been #included.

You can do t= he following transformations on this example:
- out-of-line a new= member function Alpha::falpha() to hold the ptr->fgamma() call
- replace fgamma() with ~Gamma()
- replace fbeta() with ~Beta()=
- replace falpha() with ~Alpha()
- replace Gamma with = T
- replace Beta with A
- replace Alpha with std::uniqu= e_ptr

but none of those transformations change any= of the core features of the example.

Sure we *cou= ld* introduce a bunch of special cases for when the problem *does* involve = constructors and destructors (incidentally, notice that my example does not= have any analogues for the constructors in your original code), but that w= ould just obfuscate the issue and make it harder to teach. Look =E2=80=94 I= was able to show the core issue to you in a single forum post, precisely b= ecause all the things you brought up turned out to be distractions. Imagine= how hard it would be to teach the core issue if all those things (construc= tors, destructors, locations in source files...) *were* to be made signific= ant! =C2=A0The core issue wouldn't go away; it would just get a heck of= a lot more confusing to teach anyone.

HTH,
<= div>=E2=80=93Arthur

--
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/5af23587-d714-45bd-b04c-77592ba66e03= %40isocpp.org.
------=_Part_7830_1317441430.1480375498479-- ------=_Part_7829_270404834.1480375498479-- .