Topic: local class member templates and stack distinction
Author: Noah L <duneroadrunner@gmail.com>
Date: Thu, 21 Apr 2016 05:38:05 -0700 (PDT)
Raw View
------=_Part_1177_680497174.1461242285123
Content-Type: multipart/alternative;
boundary="----=_Part_1178_913446079.1461242285123"
------=_Part_1178_913446079.1461242285123
Content-Type: text/plain; charset=UTF-8
Hello,
Two things. First, msvc gives me this error:
"Error C2892 local class shall not have member templates"
when I try to declare/define a class at function scope with a template
member function. Is there some intrinsic reason for this? Would it be
feasible to lift this restriction?
And second, any hope of being able to restrict a type to stack allocation
only?
The context is that I've developed yet another library and coding style
that makes all pointers/references safe. Uniquely though, this library
supports pointers to stack objects. Unfortunately, there's no way for my
library to know that an object is stack allocated (i.e. guaranteed to have
"scope lifetime"), so therefore, in order to guarantee safety, it has to
include runtime safety mechanisms that wouldn't be necessary if it knew the
object was stack allocated.
Also, the coding style reduces runtime overhead by "templatizing" (i.e.
making into templates) functions that take reference parameters, allowing
them to accept the optimal pointer/reference type for the situation.
I do feel somewhat uneasy about requesting a distinction between stack and
heap allocated objects. Like somehow that kind of discrimination is counter
to C/C++ principles. But I can't really articulate why. And I have a
situation where it would be of clear benefit to have such a distinction.
Noah
ps: If anyone's interested, here's an article that explains why the library
needs (or could really use) these features:
http://www.codeproject.com/Articles/1093894/How-To-Safely-Pass-Parameters-By-Reference-in-Cplu
--
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/0553ef67-5fc3-4cae-a9fa-6ec6717507f4%40isocpp.org.
------=_Part_1178_913446079.1461242285123
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div>Hello,</div><div><br></div><div>Two th=
ings. First, msvc gives me this error:</div><div><br></div><div>"Error=
<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>C2892<span=
class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>local class sha=
ll not have member templates"</div><div><br></div><div>when I try to d=
eclare/define a class at function scope with a template member function. Is=
there some intrinsic reason for this? Would it be feasible to lift this re=
striction?</div><div><br></div><div>And second, any hope of being able to r=
estrict a type to stack allocation only?</div><div><br></div><div>The conte=
xt is that I've developed yet another library and coding style that mak=
es all pointers/references safe. Uniquely though, this library supports poi=
nters to stack objects. Unfortunately, there's no way for my library to=
know that an object is stack allocated (i.e. guaranteed to have "scop=
e lifetime"), so therefore, in order to guarantee safety, it has to in=
clude runtime safety mechanisms that wouldn't be necessary if it knew t=
he object was stack allocated.</div><div><br></div><div>Also, the coding st=
yle reduces runtime overhead by "templatizing" (i.e. making into =
templates) functions that take reference parameters, allowing them to accep=
t the optimal pointer/reference type for the situation.</div><div><br></div=
><div>I do feel somewhat uneasy about requesting a distinction between stac=
k and heap allocated objects. Like somehow that kind of discrimination is c=
ounter to C/C++ principles. But I can't really articulate why. And I ha=
ve a situation where it would be of clear benefit to have such a distinctio=
n.</div><div><br></div><div><br></div><div>Noah<br></div><div><br></div><di=
v>ps: If anyone's interested, here's an article that explains why t=
he library needs (or could really use) these features: http://www.codeproje=
ct.com/Articles/1093894/How-To-Safely-Pass-Parameters-By-Reference-in-Cplu<=
/div><div><br></div><div><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/0553ef67-5fc3-4cae-a9fa-6ec6717507f4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0553ef67-5fc3-4cae-a9fa-6ec6717507f4=
%40isocpp.org</a>.<br />
------=_Part_1178_913446079.1461242285123--
------=_Part_1177_680497174.1461242285123--
.
Author: Ren Industries <renindustries@gmail.com>
Date: Thu, 21 Apr 2016 10:11:14 -0400
Raw View
--001a11c15c107c66ad0530ff48e3
Content-Type: text/plain; charset=UTF-8
You can already make a class stack only; make operator new private.
On Thu, Apr 21, 2016 at 8:38 AM, Noah L <duneroadrunner@gmail.com> wrote:
>
> Hello,
>
> Two things. First, msvc gives me this error:
>
> "Error C2892 local class shall not have member templates"
>
> when I try to declare/define a class at function scope with a template
> member function. Is there some intrinsic reason for this? Would it be
> feasible to lift this restriction?
>
> And second, any hope of being able to restrict a type to stack allocation
> only?
>
> The context is that I've developed yet another library and coding style
> that makes all pointers/references safe. Uniquely though, this library
> supports pointers to stack objects. Unfortunately, there's no way for my
> library to know that an object is stack allocated (i.e. guaranteed to have
> "scope lifetime"), so therefore, in order to guarantee safety, it has to
> include runtime safety mechanisms that wouldn't be necessary if it knew the
> object was stack allocated.
>
> Also, the coding style reduces runtime overhead by "templatizing" (i.e.
> making into templates) functions that take reference parameters, allowing
> them to accept the optimal pointer/reference type for the situation.
>
> I do feel somewhat uneasy about requesting a distinction between stack and
> heap allocated objects. Like somehow that kind of discrimination is counter
> to C/C++ principles. But I can't really articulate why. And I have a
> situation where it would be of clear benefit to have such a distinction.
>
>
> Noah
>
> ps: If anyone's interested, here's an article that explains why the
> library needs (or could really use) these features:
> http://www.codeproject.com/Articles/1093894/How-To-Safely-Pass-Parameters-By-Reference-in-Cplu
>
>
> --
> 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/0553ef67-5fc3-4cae-a9fa-6ec6717507f4%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0553ef67-5fc3-4cae-a9fa-6ec6717507f4%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMD6iD_vxRBLvQ%2BcWKe9qvudxnfN%3Dac%3DBBo2XKc16RbfgpBmsg%40mail.gmail.com.
--001a11c15c107c66ad0530ff48e3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You can already make a class stack only; make operator new=
private.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On=
Thu, Apr 21, 2016 at 8:38 AM, Noah L <span dir=3D"ltr"><<a href=3D"mail=
to:duneroadrunner@gmail.com" target=3D"_blank">duneroadrunner@gmail.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<br></div><div>Hello,</div><div><br></div><div>Two things. First, msvc give=
s me this error:</div><div><br></div><div>"Error<span style=3D"white-s=
pace:pre-wrap"> </span>C2892<span style=3D"white-space:pre-wrap"> </span>lo=
cal class shall not have member templates"</div><div><br></div><div>wh=
en I try to declare/define a class at function scope with a template member=
function. Is there some intrinsic reason for this? Would it be feasible to=
lift this restriction?</div><div><br></div><div>And second, any hope of be=
ing able to restrict a type to stack allocation only?</div><div><br></div><=
div>The context is that I've developed yet another library and coding s=
tyle that makes all pointers/references safe. Uniquely though, this library=
supports pointers to stack objects. Unfortunately, there's no way for =
my library to know that an object is stack allocated (i.e. guaranteed to ha=
ve "scope lifetime"), so therefore, in order to guarantee safety,=
it has to include runtime safety mechanisms that wouldn't be necessary=
if it knew the object was stack allocated.</div><div><br></div><div>Also, =
the coding style reduces runtime overhead by "templatizing" (i.e.=
making into templates) functions that take reference parameters, allowing =
them to accept the optimal pointer/reference type for the situation.</div><=
div><br></div><div>I do feel somewhat uneasy about requesting a distinction=
between stack and heap allocated objects. Like somehow that kind of discri=
mination is counter to C/C++ principles. But I can't really articulate =
why. And I have a situation where it would be of clear benefit to have such=
a distinction.</div><div><br></div><div><br></div><div>Noah<br></div><div>=
<br></div><div>ps: If anyone's interested, here's an article that e=
xplains why the library needs (or could really use) these features: <a href=
=3D"http://www.codeproject.com/Articles/1093894/How-To-Safely-Pass-Paramete=
rs-By-Reference-in-Cplu" target=3D"_blank">http://www.codeproject.com/Artic=
les/1093894/How-To-Safely-Pass-Parameters-By-Reference-in-Cplu</a></div><sp=
an class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div><br></div><=
/font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/0553ef67-5fc3-4cae-a9fa-6ec6717507f4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0553ef67-5fc3-=
4cae-a9fa-6ec6717507f4%40isocpp.org</a>.<br>
</font></span></blockquote></div><br></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/CAMD6iD_vxRBLvQ%2BcWKe9qvudxnfN%3Dac%=
3DBBo2XKc16RbfgpBmsg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_vxR=
BLvQ%2BcWKe9qvudxnfN%3Dac%3DBBo2XKc16RbfgpBmsg%40mail.gmail.com</a>.<br />
--001a11c15c107c66ad0530ff48e3--
.
Author: "'Johannes Schaub' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 21 Apr 2016 16:17:29 +0200
Raw View
2016-04-21 16:11 GMT+02:00 Ren Industries <renindustries@gmail.com>:
> You can already make a class stack only; make operator new private.
>
Do you want to make it "stack-only" or "not new"? These are different. Imagine
struct A {
B b;
};
void f() { new A; }
Your proposed workaround will not forbid the creation of "B" as
subobject on the heap. In my codesnippet, even though there was no use
of "new" on "B", it still ended up on the heap instead of on the
stack.
--
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/CANu6V4Wr-AfGk_fRXW34SFBm4MKEdg0_YsETqsdpj_Tcfy6CLQ%40mail.gmail.com.
.
Author: Noah L <duneroadrunner@gmail.com>
Date: Thu, 21 Apr 2016 07:53:53 -0700 (PDT)
Raw View
------=_Part_1321_216618832.1461250433428
Content-Type: multipart/alternative;
boundary="----=_Part_1322_1628129759.1461250433428"
------=_Part_1322_1628129759.1461250433428
Content-Type: text/plain; charset=UTF-8
I think Johannes is right. I basically want to know if there is any chance
that a function parameter passed by reference could be deallocated before
the function is finished using it (without evaluating the function's
particular implementation). For example, if the reference parameter is a
const std::shared_ptr (as opposed to a "const std::shared_ptr &"), then you
know the parameter object will survive the entire function call, right?
Alternatively, if you somehow knew that the object was allocated on the
stack, you would also know that it would survive the entire function call,
right?
On Thursday, April 21, 2016 at 7:17:31 AM UTC-7, Johannes Schaub wrote:
>
> 2016-04-21 16:11 GMT+02:00 Ren Industries <renind...@gmail.com
> <javascript:>>:
> > You can already make a class stack only; make operator new private.
> >
>
> Do you want to make it "stack-only" or "not new"? These are different.
> Imagine
>
> struct A {
> B b;
> };
>
> void f() { new A; }
>
> Your proposed workaround will not forbid the creation of "B" as
> subobject on the heap. In my codesnippet, even though there was no use
> of "new" on "B", it still ended up on the heap instead of on the
> stack.
>
--
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/2dc32fd2-4ef5-4aca-908f-be72fdf83e4c%40isocpp.org.
------=_Part_1322_1628129759.1461250433428
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div>I think Johannes is right. I basically=
want to know if there is any chance that a function parameter passed by re=
ference could be deallocated before the function is finished using it (with=
out evaluating the function's particular implementation). For example, =
if the reference parameter is a const std::shared_ptr (as opposed to a &quo=
t;const std::shared_ptr &"), then you know the parameter object wi=
ll survive the entire function call, right? Alternatively, if you somehow k=
new that the object was allocated on the stack, you would also know that it=
would survive the entire function call, right?</div><div><br></div><br>On =
Thursday, April 21, 2016 at 7:17:31 AM UTC-7, Johannes Schaub wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">2016-04-21 16:11 GMT+02:00 Ren Indust=
ries <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"TlW_RmmTBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;">renind...@gmail.com</a>>:
<br>> You can already make a class stack only; make operator new private=
..
<br>>
<br>
<br>Do you want to make it "stack-only" or "not new"? T=
hese are different. Imagine
<br>
<br>=C2=A0 =C2=A0struct A {
<br>=C2=A0 =C2=A0 =C2=A0B b;
<br>=C2=A0 =C2=A0};
<br>
<br>=C2=A0 =C2=A0void f() { new A; }
<br>
<br>Your proposed workaround will not forbid the creation of "B" =
as
<br>subobject on the heap. In my codesnippet, even though there was no use
<br>of "new" on "B", it still ended up on the heap inst=
ead of on the
<br>stack.
<br></blockquote></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/2dc32fd2-4ef5-4aca-908f-be72fdf83e4c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2dc32fd2-4ef5-4aca-908f-be72fdf83e4c=
%40isocpp.org</a>.<br />
------=_Part_1322_1628129759.1461250433428--
------=_Part_1321_216618832.1461250433428--
.
Author: Noah L <duneroadrunner@gmail.com>
Date: Thu, 21 Apr 2016 07:57:35 -0700 (PDT)
Raw View
------=_Part_1316_2110836995.1461250655130
Content-Type: multipart/alternative;
boundary="----=_Part_1317_1905885538.1461250655131"
------=_Part_1317_1905885538.1461250655131
Content-Type: text/plain; charset=UTF-8
Well, you know what I mean, assuming std::shared_ptr was being used
properly.
On Thursday, April 21, 2016 at 7:53:53 AM UTC-7, Noah L wrote:
>
>
> I think Johannes is right. I basically want to know if there is any chance
> that a function parameter passed by reference could be deallocated before
> the function is finished using it (without evaluating the function's
> particular implementation). For example, if the reference parameter is a
> const std::shared_ptr (as opposed to a "const std::shared_ptr &"), then you
> know the parameter object will survive the entire function call, right?
> Alternatively, if you somehow knew that the object was allocated on the
> stack, you would also know that it would survive the entire function call,
> right?
>
>
> On Thursday, April 21, 2016 at 7:17:31 AM UTC-7, Johannes Schaub wrote:
>>
>> 2016-04-21 16:11 GMT+02:00 Ren Industries <renind...@gmail.com>:
>> > You can already make a class stack only; make operator new private.
>> >
>>
>> Do you want to make it "stack-only" or "not new"? These are different.
>> Imagine
>>
>> struct A {
>> B b;
>> };
>>
>> void f() { new A; }
>>
>> Your proposed workaround will not forbid the creation of "B" as
>> subobject on the heap. In my codesnippet, even though there was no use
>> of "new" on "B", it still ended up on the heap instead of on the
>> stack.
>>
>
--
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/6a78e9d1-e53e-488d-a484-c30b63843502%40isocpp.org.
------=_Part_1317_1905885538.1461250655131
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div>Well, you know what I mean, assuming std::s=
hared_ptr was being used properly.<div><br><br>On Thursday, April 21, 2016 =
at 7:53:53 AM UTC-7, Noah L wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><br></div><div>I think Johannes is right. I bas=
ically want to know if there is any chance that a function parameter passed=
by reference could be deallocated before the function is finished using it=
(without evaluating the function's particular implementation). For exa=
mple, if the reference parameter is a const std::shared_ptr (as opposed to =
a "const std::shared_ptr &"), then you know the parameter obj=
ect will survive the entire function call, right? Alternatively, if you som=
ehow knew that the object was allocated on the stack, you would also know t=
hat it would survive the entire function call, right?</div><div><br></div><=
br>On Thursday, April 21, 2016 at 7:17:31 AM UTC-7, Johannes Schaub wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex">2016-04-21 16:11 GMT+02:00 Ren Indus=
tries <<a rel=3D"nofollow">renind...@gmail.com</a>>:
<br>> You can already make a class stack only; make operator new private=
..
<br>>
<br>
<br>Do you want to make it "stack-only" or "not new"? T=
hese are different. Imagine
<br>
<br>=C2=A0 =C2=A0struct A {
<br>=C2=A0 =C2=A0 =C2=A0B b;
<br>=C2=A0 =C2=A0};
<br>
<br>=C2=A0 =C2=A0void f() { new A; }
<br>
<br>Your proposed workaround will not forbid the creation of "B" =
as
<br>subobject on the heap. In my codesnippet, even though there was no use
<br>of "new" on "B", it still ended up on the heap inst=
ead of on the
<br>stack.
<br></blockquote></div></blockquote></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/6a78e9d1-e53e-488d-a484-c30b63843502%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6a78e9d1-e53e-488d-a484-c30b63843502=
%40isocpp.org</a>.<br />
------=_Part_1317_1905885538.1461250655131--
------=_Part_1316_2110836995.1461250655130--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 21 Apr 2016 18:25:23 +0300
Raw View
On 21 April 2016 at 17:57, Noah L <duneroadrunner@gmail.com> wrote:
>
> Well, you know what I mean, assuming std::shared_ptr was being used
> properly.
I don't know what you mean. What parameter (or object referenced by a
reference parameter)
would not "survive the entire function call"?
>
>
> On Thursday, April 21, 2016 at 7:53:53 AM UTC-7, Noah L wrote:
>>
>>
>> I think Johannes is right. I basically want to know if there is any chance
>> that a function parameter passed by reference could be deallocated before
>> the function is finished using it (without evaluating the function's
>> particular implementation). For example, if the reference parameter is a
>> const std::shared_ptr (as opposed to a "const std::shared_ptr &"), then you
>> know the parameter object will survive the entire function call, right?
>> Alternatively, if you somehow knew that the object was allocated on the
>> stack, you would also know that it would survive the entire function call,
>> right?
>>
>>
>> On Thursday, April 21, 2016 at 7:17:31 AM UTC-7, Johannes Schaub wrote:
>>>
>>> 2016-04-21 16:11 GMT+02:00 Ren Industries <renind...@gmail.com>:
>>> > You can already make a class stack only; make operator new private.
>>> >
>>>
>>> Do you want to make it "stack-only" or "not new"? These are different.
>>> Imagine
>>>
>>> struct A {
>>> B b;
>>> };
>>>
>>> void f() { new A; }
>>>
>>> Your proposed workaround will not forbid the creation of "B" as
>>> subobject on the heap. In my codesnippet, even though there was no use
>>> of "new" on "B", it still ended up on the heap instead of on the
>>> stack.
>
> --
> 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/6a78e9d1-e53e-488d-a484-c30b63843502%40isocpp.org.
--
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/CAFk2RUau8bzO6WOpK20h157hKmxVWaCag7EuTicdf8CnE9XU9g%40mail.gmail.com.
.
Author: Noah L <duneroadrunner@gmail.com>
Date: Thu, 21 Apr 2016 08:44:32 -0700 (PDT)
Raw View
------=_Part_32_927625900.1461253472240
Content-Type: multipart/alternative;
boundary="----=_Part_33_1573242275.1461253472240"
------=_Part_33_1573242275.1461253472240
Content-Type: text/plain; charset=UTF-8
Yeah, the vast majority of referenced parameter objects "survive the entire
function call", but for example:
int foo(const int& int1_cref, std::list<int>& intlist1_ref) {
intlist1_ref.clear();
if (7 == int1_cref) {
return 7;
} else {
return int1_cref;
}
}
void main(int argc, char* argv[]) {
std::list<int> intlist1;
intlist1.push_back(5);
foo(intlist1.front(), intlist1);
}
So foo()'s "int1_cref" parameter is going to get "clear()"ed and is not
going to survive the entire function call, right?
It's contrived, but the article in the link I gave has a more plausible
example.
On Thursday, April 21, 2016 at 8:25:24 AM UTC-7, Ville Voutilainen wrote:
>
> On 21 April 2016 at 17:57, Noah L <duneroa...@gmail.com <javascript:>>
> wrote:
> >
> > Well, you know what I mean, assuming std::shared_ptr was being used
> > properly.
>
> I don't know what you mean. What parameter (or object referenced by a
> reference parameter)
> would not "survive the entire function call"?
>
> >
> >
> > On Thursday, April 21, 2016 at 7:53:53 AM UTC-7, Noah L wrote:
> >>
> >>
> >> I think Johannes is right. I basically want to know if there is any
> chance
> >> that a function parameter passed by reference could be deallocated
> before
> >> the function is finished using it (without evaluating the function's
> >> particular implementation). For example, if the reference parameter is
> a
> >> const std::shared_ptr (as opposed to a "const std::shared_ptr &"), then
> you
> >> know the parameter object will survive the entire function call, right?
> >> Alternatively, if you somehow knew that the object was allocated on the
> >> stack, you would also know that it would survive the entire function
> call,
> >> right?
> >>
> >>
> >> On Thursday, April 21, 2016 at 7:17:31 AM UTC-7, Johannes Schaub wrote:
> >>>
> >>> 2016-04-21 16:11 GMT+02:00 Ren Industries <renind...@gmail.com>:
> >>> > You can already make a class stack only; make operator new private.
> >>> >
> >>>
> >>> Do you want to make it "stack-only" or "not new"? These are different.
> >>> Imagine
> >>>
> >>> struct A {
> >>> B b;
> >>> };
> >>>
> >>> void f() { new A; }
> >>>
> >>> Your proposed workaround will not forbid the creation of "B" as
> >>> subobject on the heap. In my codesnippet, even though there was no use
> >>> of "new" on "B", it still ended up on the heap instead of on the
> >>> stack.
> >
> > --
> > 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-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>
> > To view this discussion on the web visit
> >
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6a78e9d1-e53e-488d-a484-c30b63843502%40isocpp.org.
>
>
--
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/6c9972fd-07d3-454c-b793-ac43a0db92c0%40isocpp.org.
------=_Part_33_1573242275.1461253472240
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div>Yeah, the vast majority of referenced =
parameter objects "survive the entire function call", but for exa=
mple:</div><div><br></div><div>int foo(const int& int1_cref, std::list&=
lt;int>& intlist1_ref) {</div><div><span class=3D"Apple-tab-span" st=
yle=3D"white-space:pre"> </span>intlist1_ref.clear();</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>if (7 =3D=3D int1_cre=
f) {</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> <=
/span>return 7;</div><div><span class=3D"Apple-tab-span" style=3D"white-spa=
ce:pre"> </span>} else {</div><div><span class=3D"Apple-tab-span" style=3D"=
white-space:pre"> </span>return int1_cref;</div><div><span class=3D"Apple-=
tab-span" style=3D"white-space:pre"> </span>}</div><div>}</div><div><br></d=
iv><div>void main(int argc, char* argv[]) {</div><div><span class=3D"Apple-=
tab-span" style=3D"white-space:pre"> </span>std::list<int> intlist1;<=
/div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>=
intlist1.push_back(5);</div><div><span class=3D"Apple-tab-span" style=3D"wh=
ite-space:pre"> </span>foo(intlist1.front(), intlist1);</div><div>}</div><d=
iv><br></div><div><br></div><div>So foo()'s "int1_cref" param=
eter is going to get "clear()"ed and is not going to survive the =
entire function call, right?</div><div><br></div><div>It's contrived, b=
ut the article in the link I gave has a more plausible example.</div><div><=
br></div><br>On Thursday, April 21, 2016 at 8:25:24 AM UTC-7, Ville Voutila=
inen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 21 April 2016 at=
17:57, Noah L <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"_UJijx2XBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'j=
avascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">duneroa...@gmail.com</a>> wrote:
<br>>
<br>> Well, you know what I mean, assuming std::shared_ptr was being use=
d
<br>> properly.
<br>
<br>I don't know what you mean. What parameter (or object referenced by=
a
<br>reference parameter)
<br>would not "survive the entire function call"?
<br>
<br>>
<br>>
<br>> On Thursday, April 21, 2016 at 7:53:53 AM UTC-7, Noah L wrote:
<br>>>
<br>>>
<br>>> I think Johannes is right. I basically want to know if there i=
s any chance
<br>>> that a function parameter passed by reference could be dealloc=
ated before
<br>>> the function is finished using it (without evaluating the func=
tion's
<br>>> particular implementation). For example, if the reference para=
meter is a
<br>>> const std::shared_ptr (as opposed to a "const std::shared=
_ptr &"), then you
<br>>> know the parameter object will survive the entire function cal=
l, right?
<br>>> Alternatively, if you somehow knew that the object was allocat=
ed on the
<br>>> stack, you would also know that it would survive the entire fu=
nction call,
<br>>> right?
<br>>>
<br>>>
<br>>> On Thursday, April 21, 2016 at 7:17:31 AM UTC-7, Johannes Scha=
ub wrote:
<br>>>>
<br>>>> 2016-04-21 16:11 GMT+02:00 Ren Industries <<a>renind...=
@gmail.com</a>>:
<br>>>> > You can already make a class stack only; make operato=
r new private.
<br>>>> >
<br>>>>
<br>>>> Do you want to make it "stack-only" or "not=
new"? These are different.
<br>>>> Imagine
<br>>>>
<br>>>> =C2=A0 =C2=A0struct A {
<br>>>> =C2=A0 =C2=A0 =C2=A0B b;
<br>>>> =C2=A0 =C2=A0};
<br>>>>
<br>>>> =C2=A0 =C2=A0void f() { new A; }
<br>>>>
<br>>>> Your proposed workaround will not forbid the creation of &=
quot;B" as
<br>>>> subobject on the heap. In my codesnippet, even though ther=
e was no use
<br>>>> of "new" on "B", it still ended up on =
the heap instead of on the
<br>>>> stack.
<br>>
<br>> --
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an
<br>> email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"_UJijx2XBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">std-proposal...@<wbr>isocpp.org</a>.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"_UJijx2XBgAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hr=
ef=3D'javascript:';return true;">std-pr...@isocpp.org</a>.
<br>> To view this discussion on the web visit
<br>> <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/6a78e9d1-e53e-488d-a484-c30b63843502%40isocpp.org" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/6a78e9d1-e53e-488d-a484-c30b63843502%40i=
socpp.org';return true;" onclick=3D"this.href=3D'https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/6a78e9d1-e53e-488d-a484-c30b6384=
3502%40isocpp.org';return true;">https://groups.google.com/a/<wbr>isocp=
p.org/d/msgid/std-<wbr>proposals/6a78e9d1-e53e-488d-<wbr>a484-c30b63843502%=
40isocpp.org</a><wbr>.
<br></blockquote></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/6c9972fd-07d3-454c-b793-ac43a0db92c0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6c9972fd-07d3-454c-b793-ac43a0db92c0=
%40isocpp.org</a>.<br />
------=_Part_33_1573242275.1461253472240--
------=_Part_32_927625900.1461253472240--
.