Topic: Instantiation of default destructor
Author: Domen Vrankar <domen.vrankar@gmail.com>
Date: Mon, 28 Nov 2016 13:14:13 +0100
Raw View
--94eb2c06105c5269c405425b6b3d
Content-Type: text/plain; charset=UTF-8
Hi,
In this video [1] <https://www.youtube.com/watch?v=8AjRD6mU96s> (time
57:40) Jason 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::unique_ptr and include its declaration only in cpp file:
//a.h
....
class T;
struct A
{
A(T* ptr_); // intentionally before A() constructor - see the question below
A();
std::unique_ptr<T> ptr;
};
....
//a.cpp
#include "a.h"
#include "t.h" // declaration of T class
....
A::A() {}
A::A(T* ptr_) : ptr{ptr_} {}
....
This won't work since default destructor is (if I understood the reason why
Tomasz Wota's example in the comment worked: [2]
<http://melpon.org/wandbox/permlink/k8UpfCT8DlYv1hv3>) implemented at the
end of the compilation unit.
For me it's not a big deal to write A::~A() = default; in 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 standard would have to be
changed for that) so that implicit default destructor would 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?
Thanks,
Domen
[1] https://www.youtube.com/watch?v=8AjRD6mU96s
[2] http://melpon.org/wandbox/permlink/k8UpfCT8DlYv1hv3
--
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 email 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/CAKgx6B%2B8zzZ131-UZobmUvCgB4YeQ1%2BwTZadcuT6ieDCofDndg%40mail.gmail.com.
--94eb2c06105c5269c405425b6b3d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Hi,<br><br></div>In this video <a href=3D"https:=
//www.youtube.com/watch?v=3D8AjRD6mU96s">[1]</a> (time 57:40) Jason 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::unique_ptr a=
nd include its declaration only in cpp file:<br><br></div><div>//a.h<br>...=
<br></div><div>class T;<br><br></div><div>struct A<br></div><div>{<br>A(T* =
ptr_); // intentionally before A() constructor - see the question below<br>=
</div><div>A();</div><div>std::unique_ptr<T> ptr;<br></div><div>};<br=
></div><div>...<br><br></div><div>//a.cpp<br></div><div>#include "a.h&=
quot;<br></div><div>#include "t.h" // declaration of T class<br><=
/div><div>...<br></div><div>A::A() {}<br></div><div>A::A(T* ptr_) : ptr{ptr=
_} {}<br></div><div>...<br><br></div><div>This won't work since default=
destructor is (if I understood the reason why Tomasz Wota's example in=
the comment worked: <a href=3D"http://melpon.org/wandbox/permlink/k8UpfCT8=
DlYv1hv3">[2]</a>) implemented at the end of the compilation unit.<br><br><=
/div><div>For me it's not a big deal to write A::~A() =3D default; in c=
pp file but still since we've had that debate I was wondering if it wou=
ld be feasible to change the wording (don't know how much the standard =
would have to be changed for that) so that implicit default destructor woul=
d 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 fi=
le) and not at the end of the file where the class was declared?<br><br></d=
iv><div>Thanks,<br></div><div>Domen<br></div><div><br>[1] <a href=3D"https:=
//www.youtube.com/watch?v=3D8AjRD6mU96s">https://www.youtube.com/watch?v=3D=
8AjRD6mU96s</a><br>[2] <a href=3D"http://melpon.org/wandbox/permlink/k8UpfC=
T8DlYv1hv3">http://melpon.org/wandbox/permlink/k8UpfCT8DlYv1hv3</a><br></di=
v></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKgx6B%2B8zzZ131-UZobmUvCgB4YeQ1%2Bw=
TZadcuT6ieDCofDndg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6B%2B8zz=
Z131-UZobmUvCgB4YeQ1%2BwTZadcuT6ieDCofDndg%40mail.gmail.com</a>.<br />
--94eb2c06105c5269c405425b6b3d--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 28 Nov 2016 07:11:45 -0800 (PST)
Raw View
------=_Part_2244_1755540733.1480345905535
Content-Type: multipart/alternative;
boundary="----=_Part_2245_1163896384.1480345905535"
------=_Part_2245_1163896384.1480345905535
Content-Type: text/plain; charset=UTF-8
On Monday, November 28, 2016 at 7:14:55 AM UTC-5, Domen Vrankar wrote:
>
> Hi,
>
> In this video [1] <https://www.youtube.com/watch?v=8AjRD6mU96s> (time
> 57:40) Jason 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::unique_ptr and include its declaration only in cpp file:
>
> //a.h
> ...
> class T;
>
> struct A
> {
> A(T* ptr_); // intentionally before A() constructor - see the question
> below
> A();
> std::unique_ptr<T> ptr;
> };
> ...
>
> //a.cpp
> #include "a.h"
> #include "t.h" // declaration of T class
> ...
> A::A() {}
> A::A(T* ptr_) : ptr{ptr_} {}
> ...
>
> This won't work since default destructor is (if I understood the reason
> why Tomasz Wota's example in the comment worked: [2]
> <http://melpon.org/wandbox/permlink/k8UpfCT8DlYv1hv3>) implemented at the
> end of the compilation unit.
>
> For me it's not a big deal to write A::~A() = default; in 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 standard would have to be
> changed for that) so that implicit default destructor would 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 `unique_ptr::~unique_ptr`. And that
destructor will call `T::~T()`. The problem is that, unless `T` has been
*defined*, you cannot call its destructor.
If the compiler defines the destructor for `A`, then it will do so in the
class definition. That is, in the header. Which means that anyone who
includes this header who doesn't include the definition of `T` beforehand
will get a compile error.
By declaring the destructor of `A` in the header, then defaulting the
destructor in the .cpp, you force the compiler to only generate the class's
destructor in the .cpp file. Where you have presumably included the
definition of `T`. And thus, people can use `A` without necessarily having
the full definition of `T`.
--
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 email 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/1a7a1b18-c001-405e-8f7f-09c048c6ee14%40isocpp.org.
------=_Part_2245_1163896384.1480345905535
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, November 28, 2016 at 7:14:55 AM UTC-5, =
Domen Vrankar wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div>Hi,<br><br></div>In this video <a href=3D"https://www.yo=
utube.com/watch?v=3D8AjRD6mU96s" target=3D"_blank" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'https://www.youtube.com/watch?v\x3d8AjRD6mU96s'=
;;return true;" onclick=3D"this.href=3D'https://www.youtube.com/watch?v=
\x3d8AjRD6mU96s';return true;">[1]</a> (time 57:40) Jason Jurecka was t=
alking about the need to write empty/defaulted destructor in cpp file if yo=
u want to declare a class in header file, use it in std::unique_ptr and inc=
lude its declaration only in cpp file:<br><br></div><div>//a.h<br>...<br></=
div><div>class T;<br><br></div><div>struct A<br></div><div>{<br>A(T* ptr_);=
// intentionally before A() constructor - see the question below<br></div>=
<div>A();</div><div>std::unique_ptr<T> ptr;<br></div><div>};<br></div=
><div>...<br><br></div><div>//a.cpp<br></div><div>#include "a.h"<=
br></div><div>#include "t.h" // declaration of T class<br></div><=
div>...<br></div><div>A::A() {}<br></div><div>A::A(T* ptr_) : ptr{ptr_} {}<=
br></div><div>...<br><br></div><div>This won't work since default destr=
uctor is (if I understood the reason why Tomasz Wota's example in the c=
omment worked: <a href=3D"http://melpon.org/wandbox/permlink/k8UpfCT8DlYv1h=
v3" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fmelpon.org%2Fwandbox%2Fpermlink%2Fk=
8UpfCT8DlYv1hv3\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGRwN_bv7ckYmx-8tltD=
DU0KqJczw';return true;" onclick=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fmelpon.org%2Fwandbox%2Fpermlink%2Fk8UpfCT8DlYv1hv=
3\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGRwN_bv7ckYmx-8tltDDU0KqJczw'=
;return true;">[2]</a>) implemented at the end of the compilation unit.<br>=
<br></div><div>For me it's not a big deal to write A::~A() =3D default;=
in cpp file but still since we've had that debate I was wondering if i=
t would be feasible to change the wording (don't know how much the stan=
dard would have to be changed for that) so that implicit default destructor=
would be added to the code at the point of first constructor implementatio=
n (in the above example at the point of A::A(T* ptr_); implementation in .c=
pp file) and not at the end of the file where the class was declared?</div>=
<br></div></blockquote><div><br>You've misunderstood the nature of the =
problem.<br><br>The default destructor will call `unique_ptr::~unique_ptr`.=
And that destructor will call `T::~T()`. The problem is that, unless `T` h=
as been <i>defined</i>, you cannot call its destructor.<br><br>If the compi=
ler defines the destructor for `A`, then it will do so in the class definit=
ion. That is, in the header. Which means that anyone who includes this head=
er who doesn't include the definition of `T` beforehand will get a comp=
ile error.<br><br>By declaring the destructor of `A` in the header, then de=
faulting the destructor in the .cpp, you force the compiler to only generat=
e the class's destructor in the .cpp file. Where you have presumably in=
cluded the definition of `T`. And thus, people can use `A` without necessar=
ily having the full definition of `T`.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1a7a1b18-c001-405e-8f7f-09c048c6ee14%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1a7a1b18-c001-405e-8f7f-09c048c6ee14=
%40isocpp.org</a>.<br />
------=_Part_2245_1163896384.1480345905535--
------=_Part_2244_1755540733.1480345905535--
.
Author: Domen Vrankar <domen.vrankar@gmail.com>
Date: Mon, 28 Nov 2016 19:52:17 +0100
Raw View
--001a1140fadceb813b054260fa25
Content-Type: text/plain; charset=UTF-8
2016-11-28 16:11 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
>
>
> On Monday, November 28, 2016 at 7:14:55 AM UTC-5, Domen Vrankar wrote:
>>
>> Hi,
>>
>> In this video [1] <https://www.youtube.com/watch?v=8AjRD6mU96s> (time
>> 57:40) Jason 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::unique_ptr and include its declaration only in cpp file:
>>
>> //a.h
>> ...
>> class T;
>>
>> struct A
>> {
>> A(T* ptr_); // intentionally before A() constructor - see the question
>> below
>> A();
>> std::unique_ptr<T> ptr;
>> };
>> ...
>>
>> //a.cpp
>> #include "a.h"
>> #include "t.h" // declaration of T class
>> ...
>> A::A() {}
>> A::A(T* ptr_) : ptr{ptr_} {}
>> ...
>>
>> This won't work since default destructor is (if I understood the reason
>> why Tomasz Wota's example in the comment worked: [2]
>> <http://melpon.org/wandbox/permlink/k8UpfCT8DlYv1hv3>) implemented at
>> the end of the compilation unit.
>>
>> For me it's not a big deal to write A::~A() = default; in 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 standard would have to be
>> changed for that) so that implicit default destructor would 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 `unique_ptr::~unique_ptr`. And that
> destructor will call `T::~T()`. The problem is that, unless `T` has been
> *defined*, you cannot call its destructor.
>
I understand that but I always expected that it has to be known at the
point of destructor call like you would declare a variable before using it.
So having this structure:
//a.h
// guard & include memory
struct B;
struct A
{
A();
std::shared_ptr<B> ptr;
};
//a.cpp
#include "a.h"
#include "b.h"
A::A() : ptr{new B} {}
//b.h
// guard & include iostream
struct B{~B(){std::cout << "foo\n";}};
I would expect this to work:
// main.cpp
#include "b.h"
#include "a.h"
int main() {A a;}
But wouldn't expect this to work:
//main.cpp
#include "a.h"
int main() {A a;} // destructor chain called after the closing brace
#include "b.h" // B was not known until this point but the example still
works
But this wasn't the case that I was talking about (in this case you still
have to include b.h in the code where struct A is used).
> If the compiler defines the destructor for `A`, then it will do so in the
> class definition. That is, in the header. Which means that anyone who
> includes this header who doesn't include the definition of `T` beforehand
> will get a compile error.
>
> By declaring the destructor of `A` in the header, then defaulting the
> destructor in the .cpp, you force the compiler to only generate the class's
> destructor in the .cpp file. Where you have presumably included the
> definition of `T`. And thus, people can use `A` without necessarily having
> the full definition of `T`.
>
> And this was my question regarding the feasibility of a proposal. I'm not
a compiler writer so I might be talking nonsense (I remember something
regarding compilers not being happy about needing to remember stuff).
Current functionality is like you've described it above. What I was talking
about is this:
//a.h
// guard & include memory
struct B;
struct A
{
A();
// implicit declaration (not implementation as currently) of destructor
// same as writing ~A(); so compiler remembers this point and binds it to
the
// first constructor implementation
std::shared_ptr<B> ptr;
};
//a.cpp
#include "a.h"
#include "b.h"
A::A() : ptr{new B} {}
// since compiler comes across first constructor implementation
// it generates destructor implementation here - same as writing A::~A() =
default;
Also in such case I would expect writing ~A() = default; work the same way
(split between declaration in header and implementation generation at the
same location as the example above.
This would work the same way as if currently declaring destructor ~A(); in
class/structure and defaulting it on the location where the first
constructor is declared (in case of an implicit or defaulted constructor
that would still mean getting the same error as currently but in the case
of implementing/defaulting the constructor in .cpp file it would work as if
currently defaulting the destructor in .cpp file - which means not needing
to include the header file all over the place).
Alternatively the defaulting of all implicit/defaulted functions could be
deferred until compiler reaches the implementation of the first function
that was only declared inside of the class but not implemented (if it
exists or at the end of the class declaration if it doesn't) but that would
probably mean even greater compilation overhead.
The benefit of this that I see would be that less people would even stumble
on this issue but the drawback would probably be larger compiler memory
footprint and compilation time.
I'm guessing that it wouldn't be feasible and it's not worth pursuing this
but as I said I'm not familiar with compiler internals so I prefer to ask
here first instead of drawing guesswork conclusions.
Am I correct regarding not being feasible?
Also is this even the correct mailing list for something like this or
should I next time write it on std-discussion mailing list?
Thanks,
Domen
--
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 email 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/CAKgx6BL_cWfkySo-UpzTdJFHaQHj1Yyho2oyUUN2c2mhq%2BP0bA%40mail.gmail.com.
--001a1140fadceb813b054260fa25
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">2016-11-28 16:11 GMT+01:00 Nicol Bolas <span dir=3D"ltr">&=
lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail=
..com</a>></span>:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span=
class=3D"gmail-"><br><br>On Monday, November 28, 2016 at 7:14:55 AM UTC-5,=
Domen Vrankar wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
dir=3D"ltr"><div><div>Hi,<br><br></div>In this video <a href=3D"https://ww=
w.youtube.com/watch?v=3D8AjRD6mU96s" rel=3D"nofollow" target=3D"_blank">[1]=
</a> (time 57:40) Jason Jurecka was talking about the need to write empty/d=
efaulted destructor in cpp file if you want to declare a class in header fi=
le, use it in std::unique_ptr and include its declaration only in cpp file:=
<br><br></div><div>//a.h<br>...<br></div><div>class T;<br><br></div><div>st=
ruct A<br></div><div>{<br>A(T* ptr_); // intentionally before A() construct=
or - see the question below<br></div><div>A();</div><div>std::unique_ptr<=
;T> ptr;<br></div><div>};<br></div><div>...<br><br></div><div>//a.cpp<br=
></div><div>#include "a.h"<br></div><div>#include "t.h"=
// declaration of T class<br></div><div>...<br></div><div>A::A() {}<br></d=
iv><div>A::A(T* ptr_) : ptr{ptr_} {}<br></div><div>...<br><br></div><div>Th=
is won't work since default destructor is (if I understood the reason w=
hy Tomasz Wota's example in the comment worked: <a href=3D"http://melpo=
n.org/wandbox/permlink/k8UpfCT8DlYv1hv3" rel=3D"nofollow" target=3D"_blank"=
>[2]</a>) implemented at the end of the compilation unit.<br><br></div><div=
>For me it's not a big deal to write A::~A() =3D default; in cpp file b=
ut still since we've had that debate I was wondering if it would be fea=
sible to change the wording (don't know how much the standard would hav=
e to be changed for that) so that implicit default destructor would be adde=
d to the code at the point of first constructor implementation (in the abov=
e example at the point of A::A(T* ptr_); implementation in .cpp file) and n=
ot at the end of the file where the class was declared?</div><br></div></bl=
ockquote></span><div><br>You've misunderstood the nature of the problem=
.. <br></div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div><br>The default destructor will call `unique_pt=
r::~unique_ptr`. And that destructor will call `T::~T()`. The problem is th=
at, unless `T` has been <i>defined</i>, you cannot call its destructor.<br>=
</div></div></blockquote><div><br></div><div>I understand that but I always=
expected that it has to be known at the point of destructor call like you =
would declare a variable before using it.<br><br></div><div>So having this =
structure:<br><br></div><div>//a.h<br></div><div>// guard & include mem=
ory<br></div><div>struct B;<br><span class=3D"gmail-">struct A<br>{<br></sp=
an></div><div><span class=3D"gmail-">=C2=A0 A();<br></span></div><div><span=
class=3D"gmail-">=C2=A0 std::shared</span>_ptr<B> ptr;<br>};<br><br>=
</div><div>//a.cpp<br></div><div>#include "a.h"<br></div><div>#in=
clude "b.h"<br>A::A() : ptr{new B} {}<br></div><div><br></div><di=
v>//b.h<br>// guard & include iostream<br></div><div>struct B{~B(){std:=
:cout << "foo\n";}};<br><br></div><div>I would expect this =
to work:<br></div><div><br></div><div>// main.cpp<br></div><div>#include &q=
uot;b.h"<br></div><div>#include "a.h"<br>int main() {A a;}<b=
r><br></div><div>But wouldn't expect this to work:<br><br></div><div>//=
main.cpp<br></div><div>#include "a.h"<br></div><div>int main() {A=
a;} // destructor chain called after the closing brace<br></div><div>#incl=
ude "b.h" // B was not known until this point but the example sti=
ll works<br><br></div><div>But this wasn't the case that I was talking =
about (in this case you still have to include b.h in the code where struct =
A is used).<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div>If the compiler defines the destructor f=
or `A`, then it will do so in the class definition. That is, in the header.=
Which means that anyone who includes this header who doesn't include t=
he definition of `T` beforehand will get a compile error.<br><br>By declari=
ng the destructor of `A` in the header, then defaulting the destructor in t=
he .cpp, you force the compiler to only generate the class's destructor=
in the .cpp file. Where you have presumably included the definition of `T`=
.. And thus, people can use `A` without necessarily having the full definiti=
on of `T`.<span class=3D"gmail-HOEnZb"><font color=3D"#888888"><br></font><=
/span></div></div><span class=3D"gmail-HOEnZb"><font color=3D"#888888">
<p></p>
</font></span></blockquote></div>And this was my question regarding the fea=
sibility of a proposal. I'm not a compiler writer so I might be talking=
nonsense (I remember something regarding compilers not being happy about n=
eeding to remember stuff).<br><br></div><div class=3D"gmail_extra">Current =
functionality is like you've described it above. What I was talking abo=
ut is this:<br><br><div>//a.h<br></div><div>// guard & include memory<b=
r></div><div>struct B;<br><span class=3D"gmail-">struct A<br>{<br></span></=
div><div><span class=3D"gmail-">=C2=A0 A();<br></span></div><div><span clas=
s=3D"gmail-">=C2=A0 // implicit declaration (not implementation as currentl=
y) of destructor<br>=C2=A0 // same as writing ~A(); so compiler remembers t=
his point and binds it to the<br></span></div><div><span class=3D"gmail-">=
=C2=A0 // first constructor implementation<br></span></div><div><span class=
=3D"gmail-">=C2=A0 std::shared</span>_ptr<B> ptr;<br>};<br><br></div>=
<div>//a.cpp<br></div><div>#include "a.h"<br></div>#include "=
;b.h"<br>A::A() : ptr{new B} {}<br></div><div class=3D"gmail_extra">//=
since compiler comes across first constructor implementation<br>// it gene=
rates destructor implementation here - same as writing A::~A() =3D default;=
<br><br></div><div class=3D"gmail_extra">Also in such case I would expect w=
riting ~A() =3D default; work the same way (split between declaration in he=
ader and implementation generation at the same location as the example abov=
e.<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"=
>This would work the same way as if currently declaring destructor ~A(); in=
class/structure and defaulting it on the location where the first construc=
tor is declared (in case of an implicit or defaulted constructor that would=
still mean getting the same error as currently but in the case of implemen=
ting/defaulting the constructor in .cpp file it would work as if currently =
defaulting the destructor in .cpp file - which means not needing to include=
the header file all over the place).</div><div class=3D"gmail_extra"><br><=
/div><div class=3D"gmail_extra">Alternatively the defaulting of all implici=
t/defaulted functions could be deferred until compiler reaches the implemen=
tation of the first function that was only declared inside of the class but=
not implemented (if it exists or at the end of the class declaration if it=
doesn't) but that would probably mean even greater compilation overhea=
d.<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"=
>The benefit of this that I see would be that less people would even stumbl=
e on this issue but the drawback would probably be larger compiler memory f=
ootprint and compilation time.<br><br>I'm guessing that it wouldn't=
be feasible and it's not worth pursuing this but as I said I'm not=
familiar with compiler internals so I prefer to ask here first instead of =
drawing guesswork conclusions.<br></div><div class=3D"gmail_extra">Am I cor=
rect regarding not being feasible?<br></div><div class=3D"gmail_extra">Also=
is this even the correct mailing list for something like this or should I =
next time write it on std-discussion mailing list?<br></div><div class=3D"g=
mail_extra"><br></div><div class=3D"gmail_extra">Thanks,<br></div><div clas=
s=3D"gmail_extra">Domen<br></div><div class=3D"gmail_extra"><br><br></div><=
/div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKgx6BL_cWfkySo-UpzTdJFHaQHj1Yyho2oy=
UUN2c2mhq%2BP0bA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BL_cWfkyS=
o-UpzTdJFHaQHj1Yyho2oyUUN2c2mhq%2BP0bA%40mail.gmail.com</a>.<br />
--001a1140fadceb813b054260fa25--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 28 Nov 2016 13:03:35 -0600
Raw View
--001a114148c25bfb690542612368
Content-Type: text/plain; charset=UTF-8
On Mon, Nov 28, 2016 at 6:14 AM, Domen Vrankar <domen.vrankar@gmail.com>
wrote:
> For me it's not a big deal to write A::~A() = default; in 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 standard would have to be
> changed for that) so that implicit default destructor would 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?
>
Define "first constructor implementation".
Different constructors for the same class may be declared in different
compilation units (different .cpp files). Right now the implicit ones work
as if declared "inline", which is what allows class declaration headers to
be included by multiple .cpp files, as well as making it easier to inline.
IMHO, changing this is a non-starter.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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 email 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/CAGg_6%2BNkv4oNaA8FuA68VQCEzfqnVM3A1ZBSxt2NOtsUgDB1gQ%40mail.gmail.com.
--001a114148c25bfb690542612368
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On Mon, Nov 28, 2016 at 6:14 AM=
, Domen Vrankar <span dir=3D"ltr"><<a href=3D"mailto:domen.vrankar@gmail=
..com" target=3D"_blank">domen.vrankar@gmail.com</a>></span> wrote:<br><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>For me it'=
s not a big deal to write A::~A() =3D default; in 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 standard would have to be changed=
for that) so that implicit default destructor would be added to the code a=
t the point of first constructor implementation (in the above example at th=
e point of A::A(T* ptr_); implementation in .cpp file) and not at the end o=
f the file where the class was declared?<br></div></blockquote></div><br>De=
fine "first constructor implementation".</div><div class=3D"gmail=
_extra"><br></div><div class=3D"gmail_extra">Different constructors for the=
same class may be declared in different compilation units (different .cpp =
files).=C2=A0 Right now the implicit ones work as if declared "inline&=
quot;, which is what allows class declaration headers to be included by mul=
tiple .cpp files, as well as making it easier to inline.=C2=A0 IMHO, changi=
ng this is a non-starter.<br>-- <br><div class=3D"gmail_signature" data-sma=
rtmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=
=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-84=
7-691-1404</div></div></div></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNkv4oNaA8FuA68VQCEzfqnVM3A1Z=
BSxt2NOtsUgDB1gQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNkv4oN=
aA8FuA68VQCEzfqnVM3A1ZBSxt2NOtsUgDB1gQ%40mail.gmail.com</a>.<br />
--001a114148c25bfb690542612368--
.
Author: Domen Vrankar <domen.vrankar@gmail.com>
Date: Mon, 28 Nov 2016 20:17:12 +0100
Raw View
--001a114fce3a10dc91054261542d
Content-Type: text/plain; charset=UTF-8
2016-11-28 20:03 GMT+01:00 Nevin Liber <nevin@eviloverlord.com>:
> On Mon, Nov 28, 2016 at 6:14 AM, Domen Vrankar <domen.vrankar@gmail.com>
> wrote:
>
>> For me it's not a big deal to write A::~A() = default; in 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 standard would have to be
>> changed for that) so that implicit default destructor would 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?
>>
>
> Define "first constructor implementation".
>
//a.h
// guard & include memory
struct B;
struct A
{
A(int i); // first constructor as it is declared first
A();
std::shared_ptr<B> ptr;
};
//a_1.cpp
#include "a.h" // compiler sees the declaration and remembers that it needs
to generate a destructor implementation
#include "b.h"
A::A() {}
// end of file - compiler did not find the implementation of first
constructor so it just wasted space and time checking for the location
during compilation
//a_2.cpp
#include "a.h" // compiler sees the declaration...
#include "b.h"
A::A(int i) {} // implementation of the first constructor so destructor is
generated here as if writing A::~A() = default; after this line
> Different constructors for the same class may be declared in different
> compilation units (different .cpp files). Right now the implicit ones work
> as if declared "inline", which is what allows class declaration headers to
> be included by multiple .cpp files, as well as making it easier to inline.
> IMHO, changing this is a non-starter.
>
Hm forgot about no longer implicitly inlining drawback/change that my
proposal would cause... This started out as a possibly bad idea but now it
starts to look as a really bad idea :)
Thanks,
Domen
--
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 email 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/CAKgx6BK4yf6YexmGyFKPg2cyStMxdNp7-gJQy%3DcTehbw_xk%3DaQ%40mail.gmail.com.
--001a114fce3a10dc91054261542d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2016-11-28 20:03 GMT+01:00 Nevin Liber <span dir=3D"ltr"><<a href=3D=
"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a=
>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><span class=3D"gmail-">On Mon, Nov 28, =
2016 at 6:14 AM, Domen Vrankar <span dir=3D"ltr"><<a href=3D"mailto:dome=
n.vrankar@gmail.com" target=3D"_blank">domen.vrankar@gmail.com</a>></spa=
n> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div>For me it's not a big deal to write A::~A() =3D def=
ault; in 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=
standard would have to be changed for that) so that implicit default destr=
uctor would be added to the code at the point of first constructor implemen=
tation (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?<=
br></div></blockquote></div><br></span>Define "first constructor imple=
mentation".</div></div></blockquote><div><br><div>//a.h<br></div><div>=
// guard & include memory<br></div><div>struct B;<br><span class=3D"gma=
il-m_8521159510168511345gmail-">struct A<br>{<br></span></div><div><span cl=
ass=3D"gmail-m_8521159510168511345gmail-">=C2=A0 A(int i); // first constru=
ctor as it is declared first<br></span></div><div><span class=3D"gmail-m_85=
21159510168511345gmail-">=C2=A0 A();<br></span><span class=3D"gmail-m_85211=
59510168511345gmail-">=C2=A0 std::shared</span>_ptr<B> ptr;<br></div>=
};<br><br></div><div>//a_1.cpp<br></div><div>#include "a.h" // co=
mpiler sees the declaration and remembers that it needs to generate a destr=
uctor implementation<br></div><div>#include "b.h"<br><br></div><d=
iv>A::A() {}<br><br></div><div>// end of file - compiler did not find the i=
mplementation of first constructor so it just wasted space and time checkin=
g for the location during compilation<br></div><div><br></div><div>//a_2.cp=
p<br></div><div>#include "a.h" // compiler sees the declaration..=
..<br></div><div>#include "b.h"<br><br></div><div>A::A(int i) {} /=
/ implementation of the first constructor so destructor is generated here a=
s if writing A::~A() =3D default; after this line<br></div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra">Different constructors for the same class may be declar=
ed in different compilation units (different .cpp files).=C2=A0 Right now t=
he implicit ones work as if declared "inline", which is what allo=
ws class declaration headers to be included by multiple .cpp files, as well=
as making it easier to inline.=C2=A0 IMHO, changing this is a non-starter.=
<br></div></div></blockquote><div><br></div><div>Hm forgot about no longer =
implicitly inlining drawback/change that my proposal would cause... This st=
arted out as a possibly bad idea but now it starts to look as a really bad =
idea :)<br><br></div><div>Thanks,<br></div><div>Domen<br></div></div></div>=
</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKgx6BK4yf6YexmGyFKPg2cyStMxdNp7-gJQ=
y%3DcTehbw_xk%3DaQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BK4yf6Y=
exmGyFKPg2cyStMxdNp7-gJQy%3DcTehbw_xk%3DaQ%40mail.gmail.com</a>.<br />
--001a114fce3a10dc91054261542d--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 28 Nov 2016 11:42:25 -0800
Raw View
On segunda-feira, 28 de novembro de 2016 20:17:12 PST Domen Vrankar wrote:
> A::A(int i) {} // implementation of the first constructor so destructor is
> generated here as if writing A::~A() = default; after this line
Your comment makes an invalid assumption. The destructor is not generated
there.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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 email 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/2895021.stej6Iglf8%40tjmaciei-mobl1.
.
Author: Domen Vrankar <domen.vrankar@gmail.com>
Date: Mon, 28 Nov 2016 21:21:35 +0100
Raw View
--001a114fce3a5129f70542623af3
Content-Type: text/plain; charset=UTF-8
2016-11-28 20:42 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> On segunda-feira, 28 de novembro de 2016 20:17:12 PST Domen Vrankar wrote:
> > A::A(int i) {} // implementation of the first constructor so destructor
> is
> > generated here as if writing A::~A() = default; after this line
>
> Your comment makes an invalid assumption. The destructor is not generated
> there.
>
Lost me... Where then? Meaning 'not generated there currently' or 'not
generated there even if A::~A() = default; would be written there' as this
was not meant as how it works now but what I've proposed.
I always expected that that's the point where compiler prepares the
destructor is the point where it finds it in the code.
Regards,
Domen
--
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 email 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/CAKgx6BL5vumvSnaTPm2HW%3D72hGnEV4p%3DWBCZTSueWHOO6-_icA%40mail.gmail.com.
--001a114fce3a5129f70542623af3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">2016-11-28 20:42 GMT+01:00 Thiago Macieira <span dir=3D"lt=
r"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@maci=
eira.org</a>></span>:<br><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">On segunda-feira, 28=
de novembro de 2016 20:17:12 PST Domen Vrankar wrote:<br>
> A::A(int i) {} // implementation of the first constructor so destructo=
r is<br>
> generated here as if writing A::~A() =3D default; after this line<br>
<br>
</span>Your comment makes an invalid assumption. The destructor is not gene=
rated<br>
there.<br></blockquote><div><br></div><div>Lost me... Where then? Meaning &=
#39;not generated there currently' or 'not generated there even if =
A::~A() =3D default; would be written there' as this was not meant as h=
ow it works now but what I've proposed.<br></div><div>I always expected=
that that's the point where compiler prepares the destructor is the po=
int where it finds it in the code.</div><div><br></div><div>Regards,<br></d=
iv><div>Domen<br></div><div><br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKgx6BL5vumvSnaTPm2HW%3D72hGnEV4p%3D=
WBCZTSueWHOO6-_icA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BL5vumv=
SnaTPm2HW%3D72hGnEV4p%3DWBCZTSueWHOO6-_icA%40mail.gmail.com</a>.<br />
--001a114fce3a5129f70542623af3--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 28 Nov 2016 13:14:35 -0800
Raw View
On segunda-feira, 28 de novembro de 2016 21:21:35 PST Domen Vrankar wrote:
> 2016-11-28 20:42 GMT+01:00 Thiago Macieira <thiago@macieira.org>:
> > On segunda-feira, 28 de novembro de 2016 20:17:12 PST Domen Vrankar wrote:
> > > A::A(int i) {} // implementation of the first constructor so destructor
> >
> > is
> >
> > > generated here as if writing A::~A() = default; after this line
> >
> > Your comment makes an invalid assumption. The destructor is not generated
> > there.
>
> Lost me... Where then?
Wherever it is used.
Actually, this depends on the ABI and there could be an ABI that works like
you described. Except that the two major ABIs (Microsoft's and the IA-64 one)
don't operate like that: they operate like I described.
> Meaning 'not generated there currently' or 'not
> generated there even if A::~A() = default; would be written there' as this
> was not meant as how it works now but what I've proposed.
If you'd written A::~A() = default; there, you'd get a compilation error.
> I always expected that that's the point where compiler prepares the
> destructor is the point where it finds it in the code.
Right, now you know better.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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 email 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/4492941.84y7YFDmgl%40tjmaciei-mobl1.
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Mon, 28 Nov 2016 15:24:58 -0800 (PST)
Raw View
------=_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 <jmck...@gmail.com <javascript:>>:
>
>> On Monday, November 28, 2016 at 7:14:55 AM UTC-5, Domen Vrankar wrote:
>>>
>>>
>>> In this video [1] <https://www.youtube.com/watch?v=3D8AjRD6mU96s> (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<class T> struct Alpha {
T *ptr;
};
=3D=3Dbeta.h=3D=3D
#include "alpha.h"
struct Gamma;
struct Beta {
Alpha<Gamma> 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
<div dir=3D"ltr">On Monday, November 28, 2016 at 10:53:00 AM UTC-8, Domen V=
rankar wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
2016-11-28 16:11 GMT+01:00 Nicol Bolas <span dir=3D"ltr"><<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"_Eii-mzwBAAJ" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onc=
lick=3D"this.href=3D'javascript:';return true;">jmck...@gmail.com</=
a>></span>:<div><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><span>On Monday, November 28, 2016 at=
7:14:55 AM UTC-5, Domen Vrankar wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div><div><br></div>In this video <a href=3D=
"https://www.youtube.com/watch?v=3D8AjRD6mU96s" rel=3D"nofollow" target=3D"=
_blank" onmousedown=3D"this.href=3D'https://www.youtube.com/watch?v\x3d=
8AjRD6mU96s';return true;" onclick=3D"this.href=3D'https://www.yout=
ube.com/watch?v\x3d8AjRD6mU96s';return true;">[1]</a> (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:<br>[...snip example o=
f PImpl idiom with outer class "A" and impl class "T"..=
..]</div><div>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?</div></=
div></blockquote></span><div><br>You've misunderstood the nature of the=
problem. <br></div></div></blockquote><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div><br>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 <i>defined</i>, you cannot call its destruc=
tor.<br></div></div></blockquote><div><br></div><div>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.<br></div></div></div></di=
v></blockquote><div><br></div><div>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.</div><div>=C2=A0</div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>=3D=3Dalpha.h=3D=3D</div><div>template=
<class T> struct Alpha {</div><div>=C2=A0 =C2=A0 T *ptr;</div><div>};=
<br></div><div><br></div><div>=3D=3Dbeta.h=3D=3D</div><div>#include "a=
lpha.h"</div><div>struct Gamma;</div><div>struct Beta {</div><div>=C2=
=A0 =C2=A0 Alpha<Gamma> a;</div><div>=C2=A0 =C2=A0 void fbeta() { a.p=
tr->fgamma(); }</div><div>};</div><div><br></div><div>=3D=3Dgamma.h=3D=
=3D</div><div>struct Gamma {<br></div><div>=C2=A0 =C2=A0 void fgamma(); =C2=
=A0// defined somewhere else, or whatever; doesn't really matter</div><=
div>};</div><div><br></div><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.</div><div><br></div><div>You can do t=
he following transformations on this example:</div><div>- out-of-line a new=
member function Alpha::falpha() to hold the ptr->fgamma() call</div><di=
v>- replace fgamma() with ~Gamma()</div><div>- replace fbeta() with ~Beta()=
</div><div>- replace falpha() with ~Alpha()</div><div>- replace Gamma with =
T</div><div>- replace Beta with A</div><div>- replace Alpha with std::uniqu=
e_ptr</div><div><br></div><div>but none of those transformations change any=
of the core features of the example.</div><div><br></div><div>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.</div><div><br></div><div>HTH,</div><=
div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5af23587-d714-45bd-b04c-77592ba66e03%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5af23587-d714-45bd-b04c-77592ba66e03=
%40isocpp.org</a>.<br />
------=_Part_7830_1317441430.1480375498479--
------=_Part_7829_270404834.1480375498479--
.