Topic: class black and white, separate interface
Author: mobi phil <mobi@mobiphil.com>
Date: Tue, 17 Feb 2015 10:54:54 +0100
Raw View
--089e0163391edea7e5050f45b144
Content-Type: text/plain; charset=UTF-8
>
> This is an attractive alternative to pointer-based PIMPL, though it would
> require sweeping modifications to be made across every compliant
> loader/toolset.
>
yes, but as usual, the classes without the additional keyword are supposed
to behave as earlier.
> That said, I still like it.
>
happy to hear that
However, it doesn't seem to address re-using the same interface for
> multiple implementations simultaneously (exposing "new" through the
> interface layer constrains it to a single implementation).
>
Does not address multiple implementations as you could have multiple
implementations exactly like for a usual cpp file that implements it's
header. This can be seen bad or good. You may provide for linking one or
other version, depending on your intentions.
> Another issue is version discrepancy: What metadata must be stored in
> external module containing all the "black" in order to ensure that the
> addition of new members to that layer do not cause undefined behavior when
> linked against an older "white" that doesn't know about them? There needs
> to be a way to verify a new "black" against an already compiled "white"
> during compilation, which seems to indicate the need for a large amount of
> metadata...
>
Not sure if I completely understand your concern, but let me add some
thoughts. Indeed I did not advise if there should be one black for the same
white interface. Allowing different "cumulative" blacks in different files
for the same white would allow much more flexibility at a very high cost
(complexity). Thus from the beginning I would discard that option, so only
one black for each white.
Also keep in mind, like above even now you can compile "foo.cpp" against
"foo.h" but "bar.cpp" against an older version of "foo.h". There may be
serious object misalligment that may cause crash. Thus similar care must be
taken for building, but build (dependency etc.) management discipline is
out of scope.
On the other side this black/white story would reduce such dangers, as
class layout information would be moved to only one place and that is the
black.
>
> These concerns stem from a number of problems I've been facing lately:
>
> Say we need to display the same dataset on a workstation monitor and
> through a projector.
>
> The monitor is connected through an Nvidia adapter, and the projector
> through an old ATI.
>
> We have to create one rendering context per adapter, as moving a window
> from the workstation display to the projector will crash or result in
> garbage (unless all rendering is done with GDI).
>
> Both contexts have different feature sets resulting in different "black"
> layers, however the "white" layer looks the same for both.
>
Do not have too much knowledge here, but my general idea abut it was that
such implementation details about rendering should be done in the graphics
card driver, and the user space program should not be aware if it is
displaying on one or other monitor.
Nevertheless this would go a bit out of the scope of the proposal.
Only related thing I can comment on is that at run-time there would be only
one black. Design patters like polymorphism/strategy would be implemented
like before.
> The obvious solution is PIMPL, though there is a lot of work involved in
> maintaining the parallel sets of types required to realize this.
>
Take it like that this black/white is at the end of the day PIMPL without
the pointer overhead and parallel set of types.
> After a small change in the interface, resolving version discrepancies for
> every affected module slows development to a crawl.
>
Still not clear. If you change the interface, your dependency system should
rebuild everything. One of the gains with with black/white is that you
reduce this rebuild risk to minimum.
Conclusion: I am afraid did not understand clearly your concerns. Perhaps
you did not understand completely the concept?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0163391edea7e5050f45b144
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">This is an attractive alternati=
ve to pointer-based PIMPL, though it=20
would require sweeping modifications to be made across every compliant=20
loader/toolset.<br></div></blockquote><div><br></div><div>yes, but as usual=
, the classes without the additional keyword are supposed to behave as earl=
ier.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
That said, I still like it.<br></div></blockquote><div>happy to hear that=
=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
However, it doesn't seem to address re-using the same interface for mul=
tiple implementations simultaneously (exposing "new" through the =
interface layer constrains it to a single implementation).<br></div></block=
quote><div>Does not address multiple implementations as you could have mult=
iple implementations exactly like for a usual cpp file that implements it&#=
39;s header. This can be seen bad or good. You may provide for linking one =
or other version, depending on your intentions.</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">Another issue is version discrep=
ancy: What metadata must be stored in external module containing all the &q=
uot;black" in order to ensure that the addition of new members to that=
layer do not cause undefined behavior when linked against an older "w=
hite" that doesn't know about them? There needs to be a way to ver=
ify a new "black" against an already compiled "white" d=
uring compilation, which seems to indicate the need for a large amount of m=
etadata...<br></div></blockquote><div><br></div><div>Not sure if I complete=
ly understand your concern, but let me add some thoughts. Indeed I did not =
advise if there should be one black for the same white interface. Allowing =
different "cumulative" blacks in different files for the same whi=
te would allow much more flexibility at a very high cost (complexity). Thus=
from the beginning I would discard that option, so only one black for each=
white.=C2=A0</div><div>Also keep in mind, like above even now you can comp=
ile "foo.cpp" against "foo.h" but "bar.cpp" a=
gainst an older version of "foo.h". There may be serious object m=
isalligment that may cause crash. Thus similar care must be taken for build=
ing, but build (dependency etc.) management discipline is out of scope.=C2=
=A0</div><div>On the other side this black/white story would reduce such da=
ngers, as class layout information would be moved to only one place and tha=
t is the black.</div><div><br></div><div>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><br>These concerns stem from a number of pro=
blems I've been facing lately:<br><br>Say we need to display the same d=
ataset on a workstation monitor and through a projector.<br><br>The monitor=
is connected through an Nvidia adapter, and the projector through an old A=
TI.<br><br>We have to create one rendering context per adapter, as moving a=
window from the workstation display to the projector will crash or result =
in garbage (unless all rendering is done with GDI).<br><br>Both contexts ha=
ve different feature sets resulting in different "black" layers, =
however the "white" layer looks the same for both.<br></div></blo=
ckquote><div>Do not have too much knowledge here, but my general idea abut =
it was that such implementation details about rendering should be done in t=
he graphics card driver, and the user space program should not be aware if =
it is displaying on one or other monitor.=C2=A0<br>Nevertheless this would =
go a bit out of the scope of the proposal.=C2=A0<br>Only related thing I ca=
n comment on is that at run-time there would be only one black. Design patt=
ers like polymorphism/strategy =C2=A0would be implemented like before.=C2=
=A0</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">The obvious solution is PIMPL, though there is a lot of work involved in=
maintaining the parallel sets of types required to realize this.<br></div>=
</blockquote><div>Take it like that this black/white is at the end of the d=
ay PIMPL without the pointer overhead and parallel set of types.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">After a small c=
hange in the interface, resolving version discrepancies for every affected =
module slows development to a crawl.<br></div></blockquote><div>Still not c=
lear. If you change the interface, your dependency system should rebuild ev=
erything. One of the gains with with black/white is that you reduce this re=
build risk to minimum.</div><div>=C2=A0<br></div><div>Conclusion: I am afra=
id did not understand clearly your concerns. Perhaps you did not understand=
completely the concept?=C2=A0</div><div><br></div><div><br></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0163391edea7e5050f45b144--
.
Author: Chris Gary <cgary512@gmail.com>
Date: Tue, 17 Feb 2015 05:15:03 -0800 (PST)
Raw View
------=_Part_2629_1662822959.1424178903346
Content-Type: multipart/alternative;
boundary="----=_Part_2630_1860773502.1424178903346"
------=_Part_2630_1860773502.1424178903346
Content-Type: text/plain; charset=UTF-8
If you don't mind me horribly abusing the terminology here...
From what I gather: "white" is the interface and "black" is the
implementation (duh). Instead of the pointer-to-PIMPL, this would work
kinda like partial classes in C#: The loader fills out offset/size details
at load time.
The display example is just one of several (Nvidia and ATI crap don't get
along, so everything breaks, but that's beside the point).
Rebuilding isn't the problem: Its validating changes that have to be made
on a per-implementation basis.
The problem, in general, is that there are numerous interfaces that the
"core" application is meant to work with, and those interfaces are backed
by implementations known only at runtime (plugins).
This is why I asked about re-using interfaces: All the "whites" would be in
a central codebase (in some cases, compiled and distributed to end-users
who write their own plugins), and all the "blacks" would be implemented on
a per-plugin/component basis. Multiple plugins that back the same interface
would need to be loaded simultaneously.
The problem with the distribution of the "white" binary is that users will
need/want to add members to the "black" halves they are writing, creating
part of the "version discrepancy" issue I was describing (this also happens
when a new "white" binary is distributed that must work with all existing
"blacks").
In the display example, we'd need two different graphics backends: Usually
the small vs. large display or comparing OpenGL and D3D with synchronized
resources (CAD shapes w/ optimized representations for each).
D3D is very, very different from OpenGL, so the "black" half of either
would need to be updated by hand. Add to that OpenGL's abomination of an
"extension" system, and you have a swampland of implementations to fill in.
If your proposal is supposed to work statically, then I've completely
missed the boat (wouldn't surprise me, I've been looking for a way to
simplify these messes for years)...
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2630_1860773502.1424178903346
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If you don't mind me horribly abusing the terminology here=
....<br><br>From what I gather: "white" is the interface and "black" is the =
implementation (duh). Instead of the pointer-to-PIMPL, this would work kind=
a like partial classes in C#: The loader fills out offset/size details at l=
oad time.<br><br>The display example is just one of several (Nvidia and ATI=
crap don't get along, so everything breaks, but that's beside the point).<=
br><br>Rebuilding isn't the problem: Its validating changes that have to be=
made on a per-implementation basis.<br><br>The problem, in general, is tha=
t there are numerous interfaces that the "core" application is meant to wor=
k with, and those interfaces are backed by implementations known only at ru=
ntime (plugins).<br><br>This is why I asked about re-using interfaces: All =
the "whites" would be in a central codebase (in some cases, compiled and di=
stributed to end-users who write their own plugins), and all the "blacks" w=
ould be implemented on a per-plugin/component basis. Multiple plugins that =
back the same interface would need to be loaded simultaneously.<br><br>The =
problem with the distribution of the "white" binary is that users will need=
/want to add members to the "black" halves they are writing, creating part =
of the "version discrepancy" issue I was describing (this also happens when=
a new "white" binary is distributed that must work with all existing "blac=
ks").<br><br>In the display example, we'd need two different graphics backe=
nds: Usually the small vs. large display or comparing OpenGL and D3D with s=
ynchronized resources (CAD shapes w/ optimized representations for each).<b=
r><br>D3D is very, very different from OpenGL, so the "black" half of eithe=
r would need to be updated by hand. Add to that OpenGL's abomination of an =
"extension" system, and you have a swampland of implementations to fill in.=
<br><br>If your proposal is supposed to work statically, then I've complete=
ly missed the boat (wouldn't surprise me, I've been looking for a way to si=
mplify these messes for years)...<br></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2630_1860773502.1424178903346--
------=_Part_2629_1662822959.1424178903346--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Tue, 17 Feb 2015 14:57:40 +0100
Raw View
--089e0111b8fa135476050f491627
Content-Type: text/plain; charset=UTF-8
>
> If you don't mind me horribly abusing the terminology here...
>
any abuse should be accepted as long as it helps to converge ;)
First let's fix your terminology a bit to avoid confusion. You mentioned
core. This may create confusion. Let's better call it internal world of the
class (both black and white) and the external world (consumer) of the
class.
Let me also resume something which may be spread in the original post and
subseqeunt comments. The external world, or core as you call.
It is only the black that knows about the size and layout of the class
(black). The outside world can have access to this layout through
setters/getters.
Implementation detail cannot be ignored for a successful design of the
abstraction. So far two approaches were identified how to solve the problem
of data member offset. (the sizeof for new() is similar, let's ignore for
the moment)
1. without overhead of pointer dereference or function call, but less
flexible
2. with this overhead, either with pointers or function call, but more
flexible.
for 1.) the setters/getters would be inlined at link time with
setters/getters automatically generated by the compiler for black members.
for 2.) any setter/getter in the white, thus public data member would be
solved at runtime as:
-> a non inlined method implemented in the black
-> a pointer to a global offset table that contains the offset.
At the end the both implementation could be provided depending on the
usage.
In your example you seem to focus rather on 2.) which again:
-> has advantage that allows dynamic loading of blacks from shared
libraries, or different versions of them etc.
-> has the disadvantage that any member reference will "cost" an extra
pointer dereferencing that often may be expensive due to cache incoherence.
From what I gather: "white" is the interface and "black" is the
> implementation (duh). Instead of the pointer-to-PIMPL, this would work
> kinda like partial classes in C#: The loader fills out offset/size details
> at load time.
>
se above... depends which implementation you would chose. If
setters/getters are inlined at link-time, the story at the end would be
exactly like with normal classes.
> The display example is just one of several (Nvidia and ATI crap don't get
> along, so everything breaks, but that's beside the point).
>
ok, let's forget this example, probably was not very relevant or confusing.
>
> Rebuilding isn't the problem: Its validating changes that have to be made
> on a per-implementation basis.
>
The problem, in general, is that there are numerous interfaces that the
> "core" application is meant to work with, and those interfaces are backed
> by implementations known only at runtime (plugins).
>
Again, based on the implementation one would choose, it can open the doors
for such mechanism like loading blacks as plugins.
> This is why I asked about re-using interfaces: All the "whites" would be
> in a central codebase (in some cases, compiled and distributed to end-users
> who write their own plugins), and all the "blacks" would be implemented on
> a per-plugin/component basis. Multiple plugins that back the same interface
> would need to be loaded simultaneously.
>
I think I understand what is your point. But you go one step further. One
could the same time say you "abuse" the feature or you "bulid on top" of
the feature. In my original proposal, again, there is one black to one
white. What you say can be implemented if the offsets are implemented by
pointers or setters/getters. At the end of the day a black will be a set of
functions towards the external world, so you can see it as plugin. But this
is out of the scope of the original proposal. Though it is a strong point
to support it.
>
> The problem with the distribution of the "white" binary is that users will
> need/want to add members to the "black" halves they are writing, creating
> part of the "version discrepancy" issue I was describing (this also happens
> when a new "white" binary is distributed that must work with all existing
> "blacks").
>
> Att the end you may add anything to the black, even at runtime. What is
important is that any object of the black or subclass once crceated with a
certain version ( sizeof/new), should use the same implementation for
referencing members.
> In the display example, we'd need two different graphics backends: Usually
> the small vs. large display or comparing OpenGL and D3D with synchronized
> resources (CAD shapes w/ optimized representations for each).
>
> D3D is very, very different from OpenGL, so the "black" half of either
> would need to be updated by hand. Add to that OpenGL's abomination of an
> "extension" system, and you have a swampland of implementations to fill in.
>
again, this example is bit two complex and unclear. But if you are refering
to a software system where some OpenGL or D3D class layuot changes often
during development cycles and lot of code is depending on it, then the
proposed system would allow you to add/remove private methods and data
without having to rebuild tons of files depending on the class layout.
> If your proposal is supposed to work statically, then I've completely
> missed the boat (wouldn't surprise me, I've been looking for a way to
> simplify these messes for years)...
>
again, see above. Probably both implementations should be supported (static
and dynamic)
it is on my TODO list to write a more formal version of the paper, where I
will take care to give more clear examples
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0111b8fa135476050f491627
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">If you don't mind me horrib=
ly abusing the terminology here...<br></div></blockquote><div>any abuse sho=
uld be accepted as long as it helps to converge ;)=C2=A0</div><div>=C2=A0</=
div><div>First let's fix your terminology a bit to avoid confusion. You=
mentioned core. This may create confusion. Let's better call it intern=
al world of the class (both black and white) and the external world (consum=
er) of the class.=C2=A0</div><div><br></div><div>Let me also resume somethi=
ng which may be spread in the original post and subseqeunt comments. The ex=
ternal world, or core as you call.=C2=A0</div><div><br></div><div>It is onl=
y the black that knows about the size and layout of the class (black). The =
outside world can have access to this layout through setters/getters.<br><b=
r>Implementation detail cannot be ignored for a successful design of the ab=
straction. So far two approaches were identified how to solve the problem o=
f data member offset. (the sizeof for new() is similar, let's ignore fo=
r the moment)</div><div><br></div><div>1. without overhead of pointer deref=
erence or function call, but less flexible</div><div>2. with this overhead,=
either with pointers or function call, but more flexible.</div><div><br></=
div><div>for 1.) the setters/getters would be inlined at link time with set=
ters/getters automatically generated by the compiler for black members.</di=
v><div>for 2.) any setter/getter in the white, thus public data member woul=
d be solved at runtime as:</div><div>-> a non inlined method implemented=
in the black=C2=A0</div><div>-> a pointer to a global offset table that=
contains the offset.</div><div><br></div><div>At the end the both implemen=
tation could be provided depending on the usage.=C2=A0</div><div><br></div>=
<div>In your example you seem to focus rather on 2.) which again:</div><div=
>-> has advantage that allows dynamic loading of blacks from shared libr=
aries, or different versions of them etc.</div><div>-> has the disadvant=
age that any member reference will "cost" an extra pointer derefe=
rencing that often may be expensive due to cache incoherence.</div><div><br=
></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">From =
what I gather: "white" is the interface and "black" is =
the implementation (duh). Instead of the pointer-to-PIMPL, this would work =
kinda like partial classes in C#: The loader fills out offset/size details =
at load time.<br></div></blockquote><div><br></div><div>se above... depends=
which implementation you would chose. If setters/getters are inlined at li=
nk-time, the story at the end would be exactly like with normal classes.=C2=
=A0</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">The display example is just one of several (Nvidia and ATI crap don'=
t get along, so everything breaks, but that's beside the point).<br></d=
iv></blockquote><div>ok, let's forget this example, probably was not ve=
ry relevant or confusing.=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><br>Rebuilding isn't the problem: Its validating changes that=
have to be made on a per-implementation basis.<br></div></blockquote><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">The problem, in general, is that=
there are numerous interfaces that the "core" application is mea=
nt to work with, and those interfaces are backed by implementations known o=
nly at runtime (plugins).<br></div></blockquote><div>Again, based on the im=
plementation one would choose, it can open the doors for such mechanism lik=
e loading blacks as plugins.=C2=A0</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">This is why I asked about re-using interface=
s: All the "whites" would be in a central codebase (in some cases=
, compiled and distributed to end-users who write their own plugins), and a=
ll the "blacks" would be implemented on a per-plugin/component ba=
sis. Multiple plugins that back the same interface would need to be loaded =
simultaneously.<br></div></blockquote><div>I think I understand what is you=
r point. But you go one step further. One could the same time say you "=
;abuse" the feature or you "bulid on top" of the feature. In=
my original proposal, again, there is one black to one white. What you say=
can be implemented if the offsets are implemented by pointers or setters/g=
etters. At the end of the day a black will be a set of functions towards th=
e external world, so you can see it as plugin. But this is out of the scope=
of the original proposal. Though it is a strong point to support it.</div>=
<div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>Th=
e problem with the distribution of the "white" binary is that use=
rs will need/want to add members to the "black" halves they are w=
riting, creating part of the "version discrepancy" issue I was de=
scribing (this also happens when a new "white" binary is distribu=
ted that must work with all existing "blacks").<br><br></div></bl=
ockquote><div>Att the end you may add anything to the black, even at runtim=
e. What is important is that any object of the black or subclass once crcea=
ted with a certain version ( sizeof/new), should use the same implementatio=
n for referencing members.</div><div><br></div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">In the display example, we'd need =
two different graphics backends: Usually the small vs. large display or com=
paring OpenGL and D3D with synchronized resources (CAD shapes w/ optimized =
representations for each).<br><br>D3D is very, very different from OpenGL, =
so the "black" half of either would need to be updated by hand. A=
dd to that OpenGL's abomination of an "extension" system, and=
you have a swampland of implementations to fill in.<br></div></blockquote>=
<div><br></div><div>again, this example is bit two complex and unclear. But=
if you are refering to a software system where some OpenGL or D3D class la=
yuot changes often during development cycles and lot of code is depending o=
n it, then the proposed system would allow you to add/remove private method=
s and data without having to rebuild tons of files depending on the class l=
ayout.</div><div>=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">If your proposal is supposed to work statically, then I&=
#39;ve completely missed the boat (wouldn't surprise me, I've been =
looking for a way to simplify these messes for years)...<br></div></blockqu=
ote><div>again, see above. Probably both implementations should be supporte=
d (static and dynamic)</div><div><br></div><div>it is on my TODO list to wr=
ite a more formal version of the paper, where I will take care to give more=
clear examples</div><div><br></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0111b8fa135476050f491627--
.
Author: Chris Gary <cgary512@gmail.com>
Date: Tue, 17 Feb 2015 09:02:21 -0800 (PST)
Raw View
------=_Part_2616_1222411147.1424192541679
Content-Type: multipart/alternative;
boundary="----=_Part_2617_88096780.1424192541679"
------=_Part_2617_88096780.1424192541679
Content-Type: text/plain; charset=UTF-8
Based on your explanation, I have some suggestions.
To avoid introducing new CSK, you can re-use "virtual" and "override" for
this purpose.
For example:
class white button
{
public:
// Speculative data members
// (roughly equivalent to properties)
string title;
visual_style &style;
};
class black button
{
public:
string title;
HWND hWnd;
visual_style &style;
// Etc...
};
Change "white" to "virtual", and "black" to "override":
// Speculative interface
class virtual button
{
public:
string title;
visual_style &style;
// Note: We can still have virtual methods.
};
// Concrete definition
class override button
{
public:
// At least "string title" and "visual_style &style"
// must be declared. Anything else is free game.
string title;
HWND hWnd;
visual_style &style;
};
Accessing a member through a speculative interface would merely involve
fetching an offset from a vtable. Much like static binding of a virtual
method call, it is also possible to deduce a member offset statically if
the concrete definition is available.
Inheriting from a virtual class makes the result virtual and requires that
the override inherit from the same bases (possibly in the same order). It
might be reasonable to automatically attach that inheritance to the
override when its definition is encountered.
As the override might inherit from additional bases, this makes chasing
down "repeated base" errors a bit more involved.
Unfortunately, using this model, it must be illegal to instantiate or apply
sizeof() to a "virtual" class if an "override" is not visible in the same
translation unit.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2617_88096780.1424192541679
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Based on your explanation, I have some suggestions.<br><br=
>To avoid introducing new CSK, you can re-use "virtual" and "override" for =
this purpose.<br><br>For example:<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> white button<br> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">public</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br><br> &nbs=
p; </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Spec=
ulative data members</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br> </span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// (roughly equivalent to properties)</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>  =
; </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">string</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> title</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
visual_style </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">style</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br> </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br><br> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> black button<br> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">public</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> title</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br> HWND hWnd</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>  =
; visual_style </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">style</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; <br> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// Etc...</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><br><br><br>Change "white" to "virtual", and "black" to "override":<br><b=
r><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250);=
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; =
word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpretty=
print"><span style=3D"color: #000;" class=3D"styled-by-prettify"> &nb=
sp; </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Spe=
culative interface</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">virtual</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
button<br> </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br> </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">public</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">string</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> title</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br> visual_style </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">style</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br> <br> &nbs=
p; </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// Note: We can still have virtual methods.</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br> </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">// Concrete definition<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">cla=
ss</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">override</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> button<br> &=
nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">publi=
c</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
<br> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// At least "string title" and "visual_style &s=
tyle"</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// must be declared. Anything else is free game.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>  =
; </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">string</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> title</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
HWND hWnd</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br> visual_style </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">style</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br> </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span></div></code></div><br><br> &nb=
sp; <br>Accessing a member through a speculative interface would mere=
ly involve fetching an offset from a vtable. Much like static binding of a =
virtual method call, it is also possible to deduce a member offset statical=
ly if the concrete definition is available.<br><br>Inheriting from a virtua=
l class makes the result virtual and requires that the override inherit fro=
m the same bases (possibly in the same order). It might be reasonable to au=
tomatically attach that inheritance to the override when its definition is =
encountered.<br><br>As the override might inherit from additional bases, th=
is makes chasing down "repeated base" errors a bit more involved.<br><br>Un=
fortunately, using this model, it must be illegal to instantiate or apply s=
izeof() to a "virtual" class if an "override" is not visible in the same tr=
anslation unit.<br></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2617_88096780.1424192541679--
------=_Part_2616_1222411147.1424192541679--
.
Author: Chris Gary <cgary512@gmail.com>
Date: Tue, 17 Feb 2015 09:16:36 -0800 (PST)
Raw View
------=_Part_5_1425931135.1424193396985
Content-Type: multipart/alternative;
boundary="----=_Part_6_1854569072.1424193396985"
------=_Part_6_1854569072.1424193396985
Content-Type: text/plain; charset=UTF-8
I would also like to add that, unless there is a reasonable way to combine
a "white" and "black" into the same definition, this actually *forces* the
two to be separated.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6_1854569072.1424193396985
Content-Type: text/html; charset=UTF-8
<div dir="ltr">I would also like to add that, unless there is a reasonable way to combine a "white" and "black" into the same definition, this actually <i>forces</i> the two to be separated.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_6_1854569072.1424193396985--
------=_Part_5_1425931135.1424193396985--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Tue, 17 Feb 2015 18:41:18 +0100
Raw View
--089e01184038d0909b050f4c3569
Content-Type: text/plain; charset=UTF-8
hi, as stated in the original post, personally do not care how the two
constructs will be named, thus if majority of folks would love
virtual/override do not care... However it is not really virtual and
override in my original concept. I would not force all the data members to
be virtual. I would allow part of data to be in white. The black would
complement it. This in my concept the title from white will be different
than the title from black, well, there should be no duplicates however.
What is also open for "vote" how one would link the data member from black
to the interface. One way would be sthg. you are mentioning, the other
through manually specified getter/setters.
>
> class white button
> {
> public:
>
> // Speculative data members
> // (roughly equivalent to properties)
> virtual string title; /* note I added here virtual */
> // // it would be equally possible string getTitle();
> /* note I added here virtual */
> visual_style &style;
> };
>
> class black button
> {
> public:
>
> string title; /* the linker will make this public through the
> virtual from white */
> HWND hWnd;
> visual_style &style;
>
> // Etc...
> };
>
>
>
> Accessing a member through a speculative interface would merely involve
> fetching an offset from a vtable. Much like static binding of a virtual
> method call, it is also possible to deduce a member offset statically if
> the concrete definition is available.
>
indeed, if you read through the thread vtable and other "synonims" were
mentioned. I used global offset table, but all is about accessing an offset
from a location that is known only at link time or load time versus the
"efficient" hard coded way.
Inheriting from a virtual class makes the result virtual and requires that
> the override inherit from the same bases (possibly in the same order). It
> might be reasonable to automatically attach that inheritance to the
> override when its definition is encountered.
>
well, I am afraid this would make things rather complicated and lower the
chance for acceptance. In the original concept the inheritance and lot of
things would be like in the normal classes to avoid complications. One
could translate the original proposal into: make invisible what is indeed
private, but keep the rest of the rules unchanged
> As the override might inherit from additional bases, this makes chasing
> down "repeated base" errors a bit more involved.
>
Hm... again... seems for me unnecessary complication unless you come with
example and use case.
> Unfortunately, using this model, it must be illegal to instantiate or
> apply sizeof() to a "virtual" class if an "override" is not visible in the
> same translation unit.
>
Indeed, this was mentioned in the original post if I am not wrong, and was
debated. For dynamic allocation the allocator should call a sizeof() member
function or will be a global variable calculated at link time.
--
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e01184038d0909b050f4c3569
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>hi, as stated in the original post, personally do not care how the two con=
structs will be named, thus if majority of folks would love virtual/overrid=
e do not care... However it is not really virtual and override in my origin=
al concept. I would not force all the data members to be virtual. I would a=
llow part of data to be in white. The black would complement it. This in my=
concept the title from white will be different than the title from black, =
well, there should be no duplicates however. What is also open for "vo=
te" how one would link the data member from black to the interface. On=
e way would be sthg. you are mentioning, the other through manually specifi=
ed getter/setters.<br></div><div><br></div><div><br></div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div style=3D"border:1px solid rgb(187,18=
7,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><div><=
span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or:rgb(0,0,136)">class</span><span style=3D"color:rgb(0,0,0)"> white button=
<br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(102,102,0)">{</span><span=
style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:r=
gb(0,0,136)">public</span><span style=3D"color:rgb(102,102,0)">:</span><spa=
n style=3D"color:rgb(0,0,0)"><br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><sp=
an style=3D"color:rgb(136,0,0)">// Speculative data members</span><span sty=
le=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color:rgb(136,0,0)">// (roughly equivalent to properties)</span><span s=
tyle=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 virtual=C2=A0</sp=
an><span style=3D"color:rgb(0,0,136)">string</span><span style=3D"color:rgb=
(0,0,0)"> title</span><span style=3D"color:rgb(102,102,0)">; /* note I adde=
d here virtual */</span><span style=3D"color:rgb(0,0,0)">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0//=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // it would be equally possible s</span><span =
style=3D"color:rgb(0,0,136)">tring</span><span style=3D"color:rgb(0,0,0)">=
=C2=A0getTitle()</span><span style=3D"color:rgb(102,102,0)">; /* note I add=
ed here virtual */</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0=
=C2=A0 =C2=A0 visual_style </span><span style=3D"color:rgb(102,102,0)">&am=
p;</span><span style=3D"color:rgb(0,0,0)">style</span><span style=3D"color:=
rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =
</span><span style=3D"color:rgb(102,102,0)">};</span><span style=3D"color:r=
gb(0,0,0)"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">=
class</span><span style=3D"color:rgb(0,0,0)"> black button<br>=C2=A0 =C2=A0=
</span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:r=
gb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">publ=
ic</span><span style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:=
rgb(0,0,0)"><br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color=
:rgb(0,0,136)">string</span><span style=3D"color:rgb(0,0,0)"> title</span><=
span style=3D"color:rgb(102,102,0)">; /* the linker will make this public t=
hrough the virtual from white */</span><span style=3D"color:rgb(0,0,0)"><br=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 HWND hWnd</span><span style=3D"color:rgb(102,1=
02,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 visual_style </span><span style=3D"color:rgb(102,102,0)">&</span=
><span style=3D"color:rgb(0,0,0)">style</span><span style=3D"color:rgb(102,=
102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:rgb(136,=
0,0)">// Etc...</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </=
span><span style=3D"color:rgb(102,102,0)">};</span><span style=3D"color:rgb=
(0,0,0)"><br></span></div></code></div><br><br>=C2=A0=C2=A0<br>Accessing a =
member through a speculative interface would merely involve fetching an off=
set from a vtable. Much like static binding of a virtual method call, it is=
also possible to deduce a member offset statically if the concrete definit=
ion is available.<br></div></blockquote><div>indeed, if you read through th=
e thread vtable and other "synonims" were mentioned. I used globa=
l offset table, but all is about accessing an offset from a location that i=
s known only at link time or load time versus the "efficient" har=
d coded way.</div><div>=C2=A0</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr">Inheriting from a virtual class makes the result virtual and requi=
res that the override inherit from the same bases (possibly in the same ord=
er). It might be reasonable to automatically attach that inheritance to the=
override when its definition is encountered.<br></div></blockquote><div><b=
r></div><div>well, I am afraid this would make things rather complicated an=
d lower the chance for acceptance. In the original concept the inheritance =
and lot of things would be like in the normal classes to avoid complication=
s. One could translate the original proposal into: make invisible what is i=
ndeed private, but keep the rest of the rules unchanged</div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex"><div dir=3D"ltr"><br>As the override might inherit from a=
dditional bases, this makes chasing down "repeated base" errors a=
bit more involved.<br></div></blockquote><div>Hm... again... seems for me =
unnecessary complication unless you come with example and use case.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr">Unfortunately, using this =
model, it must be illegal to instantiate or apply sizeof() to a "virtu=
al" class if an "override" is not visible in the same transl=
ation unit.<br></div></blockquote><div>Indeed, this was mentioned in the or=
iginal post if I am not wrong, and was debated. For dynamic allocation the =
allocator should call a sizeof() member function or will be a global variab=
le calculated at link time.</div><div>=C2=A0</div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex"><div dir=3D"ltr"></div><div class=3D""><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature">rgrds,<br>mobi phil<br><br>being mobile, but=
including technology<br><a href=3D"http://mobiphil.com">http://mobiphil.co=
m</a></div>
</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01184038d0909b050f4c3569--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Tue, 17 Feb 2015 18:42:19 +0100
Raw View
--089e01184038717647050f4c3970
Content-Type: text/plain; charset=UTF-8
>
> > To avoid introducing new CSK, you can re-use "virtual" and "override" for
> > this purpose.
>
> Hmm... not loving it. Anything wrong with:
>
> public class Foo /* white */ { ... };
> private class Foo /* black */ { ... };
>
> ...?
>
> On 2015-02-17 12:16, Chris Gary wrote:
> > I would also like to add that, unless there is a reasonable way to
> combine
> > a "white" and "black" into the same definition, this actually *forces*
> the
> > two to be separated.
>
> How would such a combination be different from a regular class?
sorry.. did you read the original post and the thread?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e01184038717647050f4c3970
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span class=3D"">> To avoid introducing new C=
SK, you can re-use "virtual" and "override" for<br>
> this purpose.<br>
<br>
</span>Hmm... not loving it. Anything wrong with:<br>
<br>
public class Foo /* white */ { ... };<br>
private class Foo /* black */ { ... };<br>
<br>
....?<br>
<span class=3D""><br>
On 2015-02-17 12:16, Chris Gary wrote:<br>
> I would also like to add that, unless there is a reasonable way to com=
bine<br>
</span>> a "white" and "black" into the same definit=
ion, this actually *forces* the<br>
> two to be separated.<br>
<br>
How would such a combination be different from a regular class?</blockquote=
><div><br></div><div>sorry.. did you read the original post and the thread?=
=C2=A0</div><div><br></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01184038717647050f4c3970--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Tue, 17 Feb 2015 18:52:51 +0100
Raw View
--001a113ec45a1c1d48050f4c5f4f
Content-Type: text/plain; charset=UTF-8
>
> > To avoid introducing new CSK, you can re-use "virtual" and "override" for
>> > this purpose.
>>
>> Hmm... not loving it. Anything wrong with:
>>
>> public class Foo /* white */ { ... };
>> private class Foo /* black */ { ... };
>>
>> ...?
>>
>> On 2015-02-17 12:16, Chris Gary wrote:
>> > I would also like to add that, unless there is a reasonable way to
>> combine
>> > a "white" and "black" into the same definition, this actually *forces*
>> the
>> > two to be separated.
>>
>> How would such a combination be different from a regular class?
>
>
> sorry.. did you read the original post and the thread?
>
probably not bad idea for keywoard.. though
class public Foo {
}
and
class private Foo {
}
the "public class Foo" would rather mean that the class is public, whereas
it is about the part that is being declared is public/private.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113ec45a1c1d48050f4c5f4f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><spa=
n>> To avoid introducing new CSK, you can re-use "virtual" and=
"override" for<br>
> this purpose.<br>
<br>
</span>Hmm... not loving it. Anything wrong with:<br>
<br>
public class Foo /* white */ { ... };<br>
private class Foo /* black */ { ... };<br>
<br>
....?<br>
<span><br>
On 2015-02-17 12:16, Chris Gary wrote:<br>
> I would also like to add that, unless there is a reasonable way to com=
bine<br>
</span>> a "white" and "black" into the same definit=
ion, this actually *forces* the<br>
> two to be separated.<br>
<br>
How would such a combination be different from a regular class?</blockquote=
><div><br></div></span><div>sorry.. did you read the original post and the =
thread? =C2=A0</div></div>
</div></div>
</blockquote></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail=
_extra">probably not bad idea for keywoard.. though=C2=A0</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">class public Foo {</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">}</div><=
/div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">and=C2=
=A0</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">cl=
ass private Foo {</div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">}</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail=
_extra">the "public class Foo" would rather mean that the class i=
s public, whereas it is about the part that is being declared is public/pri=
vate.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=
<br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113ec45a1c1d48050f4c5f4f--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Tue, 17 Feb 2015 19:25:45 +0100
Raw View
--001a113ed206d0d58d050f4cd405
Content-Type: text/plain; charset=UTF-8
>
> It's been a while, but I think I recall the general gist. I think one of
> us is missing something, however. I get the black/white concept when you
> separate the interface from the implementation (isn't that the point?).
>
exactly
> What I *don't* get is what it means to use this feature when the two are
> *not* separated.
sorry... really confused. If you do not separate the the feature is not
present. They are hand in hand.. or I miss what you miss ;)
(In particular, as per my question, what would be the
> use case for that and how would it differ from a "regular" class?)
>
Take it like that: they don't want to differ from a regular classe. They
want to solve few problems:
1. keep it simple (the interface)
2. avoid useless dependency between interface consumer and the interface,
thus reduce recompilation in development process when you change layout of
the class that is not affecting consumers
2. depending on the implementation, other "positive side effects" like
loading classes from shared library, dynamic patching of the source code
etc.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113ed206d0d58d050f4cd405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">It's been a while, but I think I recall the =
general gist. I think one of<br>
us is missing something, however. I get the black/white concept when you<br=
>
separate the interface from the implementation (isn't that the point?).=
<br></blockquote><div>exactly</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
What I *don't* get is what it means to use this feature when the two ar=
e<br>
*not* separated. </blockquote><div>sorry... really confused. If you do not =
separate the the feature is not present. They are hand in hand.. or I miss =
what you miss ;)=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(=
In particular, as per my question, what would be the<br>
use case for that and how would it differ from a "regular" class?=
)<br></blockquote><div>Take it like that: they don't want to differ fro=
m a regular classe. They want to solve few problems:</div><div><br></div><d=
iv>1. keep it simple (the interface)</div><div>2. avoid useless dependency =
between interface consumer and the interface, thus reduce recompilation in =
development process when you change layout of the class that is not affecti=
ng consumers</div><div><br></div><div>2. depending on the implementation, o=
ther "positive side effects" like loading classes from shared lib=
rary, dynamic patching of the source code etc.</div><div>=C2=A0</div><div><=
br></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113ed206d0d58d050f4cd405--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Thu, 19 Feb 2015 13:02:29 +0100
Raw View
--089e01184038ccabfc050f6fb5cd
Content-Type: text/plain; charset=UTF-8
>
> The idea would be that it would simultaneously define an interface and
> implementation, while allowing other implementations to be defined later.
> This would reduce repetition, as a separate "black" would not have to be
> defined right away.
>
Did not understand this entirely. One of the main objective is to keep
class interfaces thus "whites" untouched during development cycles. Thus
cannot see too much reason not to have separate black. can you give an
example pls.
> Unless there is some way to add a "pure" specifier, the absence of which
> would allow a "white" definition to double as "black".
>
again, I fail to see the point, but please develop, give example
> I still have a problem with needing to resolve sizeof() at link time:
> Using sizeof() is critical for templates that decide things like whether or
> not an instance will fit in a small aligned buffer versus needing heap
> allocation.
>
Well, for sure it is not easy. Maybe such templates will be forbidden to
use such constructs, unless adapted.
> Obviously, alignment becomes a problem, as we might have some member with
> larger than alignof(double) requirement (e.g. AVX tuple). I don't think
> this can be dealt with efficiently at link time, as it would basically
> require all template "algorithms" to be recorded as bytecode somehow. That,
> or simply forbidding sizeof() or alignof() to be used on an interface in
> the context of a template, which makes the idea incompatible with half the
> language...
>
Might be an issue, but do not understand it. I do not think allignment
would be an issue in places where it was not an issue, or it will be an
issue where it was an issue. In the class layout the alignment will be as
before, with same freedom and restrictions. Do you mean at runtime when the
members are referenced? Well... I need help there... did not study the
issue.
> Concerning keywords: I don't really care what is chosen, just as long as
> they don't turn nested definitions and the like into keyword soup or become
> easily confused with other commonly-defined symbols (such as color enums).
> My policy about keywords is that the result needs to be reasonably readable
> as monochrome text...
>
I am kind of convinced that so far the syntax should be
class private {... }
class public {...}
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e01184038ccabfc050f6fb5cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div>The idea would be that it =
would simultaneously define an interface and implementation, while allowing=
other implementations to be defined later. This would reduce repetition, a=
s a separate "black" would not have to be defined right away.<br>=
</div></div></blockquote><div>Did not understand this entirely. One of the =
main objective is to keep class interfaces thus "whites" untouche=
d during development cycles. Thus cannot see too much reason not to have se=
parate black. can you give an example pls.</div><div>=C2=A0<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div>Unless there is some way to =
add a "pure" specifier, the absence of which would allow a "=
white" definition to double as "black".<br></div></div></blo=
ckquote><div>again, I fail to see the point, but please develop, give examp=
le</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>I still have a problem with needing to resolve sizeof() at link time: Us=
ing sizeof() is critical for templates that decide things like whether or n=
ot an instance will fit in a small aligned buffer versus needing heap alloc=
ation.<br></div></div></blockquote><div><br>Well, for sure it is not easy. =
Maybe such templates will be forbidden to use such constructs, unless adapt=
ed.=C2=A0</div><div>=C2=A0</div><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>Obviously, alignment becomes a problem, as we might have some mem=
ber with larger than alignof(double) requirement (e.g. AVX tuple). I don=
9;t think this can be dealt with efficiently at link time, as it would basi=
cally require all template "algorithms" to be recorded as bytecod=
e somehow. That, or simply forbidding sizeof() or alignof() to be used on a=
n interface in the context of a template, which makes the idea incompatible=
with half the language...<br></div></div></blockquote><div><br></div><div>=
Might be an issue, but do not understand it. I do not think allignment woul=
d be an issue in places where it was not an issue, or it will be an issue w=
here it was an issue. In the class layout the alignment will be as before, =
with same freedom and restrictions. Do you mean at runtime when the members=
are referenced? Well... I need help there... did not study the issue.</div=
><div>=C2=A0<br></div><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>=
Concerning keywords: I don't really care what is chosen, just as long a=
s they don't turn nested definitions and the like into keyword soup or =
become easily confused with other commonly-defined symbols (such as color e=
nums). My policy about keywords is that the result needs to be reasonably r=
eadable as monochrome text...<br></div></div></blockquote><div><br></div><d=
iv>I am kind of convinced that so far the syntax should be</div><div><br></=
div><div>class private {... }</div><div>class public {...}</div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01184038ccabfc050f6fb5cd--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Thu, 19 Feb 2015 13:06:29 +0100
Raw View
--047d7bd6be0a1fce12050f6fc4ad
Content-Type: text/plain; charset=UTF-8
>
> I exaggerated a bit there... Let me clarify: If a "white" can double as a
> "black" (or there is a compatible "black" in the TU), then sizeof() and
> alignof() are well-defined, but it absolutely must be deduced at compile
> time.
>
what do you mean compatible? Same layout, same size? Well then we missed
the point of the full story. Again, I emphasize the reason of having chosen
the terms black and white. Black box is black box... thus it contains the
> The case where it can't be used in a template really isn't that different
> than applying sizeof() to an incomplete type (pure "white" is fundamentally
> incomplete)...
>
still needs to be analyzed.. but I tend to think the same. If alloca is
standard then class could be allocated on stack. I still fail to see how
call by value could be solved if sizeof is not known.
Not sure if I mentioned in my original post, but this black/white story is
mainly intended for "big classes" which will not be candidate for call by
value.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bd6be0a1fce12050f6fc4ad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div>I exaggerated a bit there.=
... Let me clarify: If a "white" can double as a "black"=
(or there is a compatible "black" in the TU), then sizeof() and =
alignof() are well-defined, but it absolutely must be deduced at compile ti=
me. </div></div></blockquote><div><br></div><div>what do you mean compatibl=
e? Same layout, same size? Well then we missed the point of the full story.=
Again, I emphasize the reason of having chosen the terms black and white. =
Black box is black box... thus it contains the=C2=A0</div><div><br></div><d=
iv>=C2=A0</div><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>The cas=
e where it can't be used in a template really isn't that different =
than applying sizeof() to an incomplete type (pure "white" is fun=
damentally incomplete)...<br></div></div></blockquote><div><br></div><div>s=
till needs to be analyzed.. but I tend to think the same. If alloca is stan=
dard then class could be allocated on stack. I still fail to see how call b=
y value could be solved if sizeof is not known.</div><div><br></div><div>No=
t sure if I mentioned in my original post, but this black/white story is ma=
inly intended for "big classes" which will not be candidate for c=
all by value.</div><div><br></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bd6be0a1fce12050f6fc4ad--
.
Author: Chris Gary <cgary512@gmail.com>
Date: Thu, 19 Feb 2015 04:22:16 -0800 (PST)
Raw View
------=_Part_1412_125514382.1424348536653
Content-Type: multipart/alternative;
boundary="----=_Part_1413_691276920.1424348536653"
------=_Part_1413_691276920.1424348536653
Content-Type: text/plain; charset=UTF-8
> still needs to be analyzed.. but I tend to think the same. If alloca is
> standard then class could be allocated on stack. I still fail to see how
> call by value could be solved if sizeof is not known.
The compiler has to reduce a 'sizeof(button)' or 'alignof(button)' to a
constant integer and fold any dependent constant expressions or templates
dependent thereupon before sending the whole thing to code generation. It
is not possible to know size or alignment if the precise content and layout
of a 'button' is only speculative or unspecified.
Not sure if I mentioned in my original post, but this black/white story is
> mainly intended for "big classes" which will not be candidate for call by
> value.
Classes are treated as general categories, regardless of size. This
proposal will need to work for classes of any size, even empty ones.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1413_691276920.1424348536653
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quo=
te">still needs to be analyzed.. but I tend to think the same. If alloca is=
=20
standard then class could be allocated on stack. I still fail to see how
call by value could be solved if sizeof is not known.</blockquote><div><br=
>The compiler has to reduce a 'sizeof(button)' or 'alignof(button)' to a co=
nstant integer and fold any dependent constant expressions or templates dep=
endent thereupon before sending the whole thing to code generation. It is n=
ot possible to know size or alignment if the precise content and layout of =
a 'button' is only speculative or unspecified.<br><br><blockquote style=3D"=
margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddi=
ng-left: 1ex;" class=3D"gmail_quote">Not sure if I mentioned in my original=
post, but this black/white story=20
is mainly intended for "big classes" which will not be candidate for=20
call by value.</blockquote><div><br>Classes are treated as general categori=
es, regardless of size. This proposal will need to work for classes of any =
size, even empty ones.<br></div></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1413_691276920.1424348536653--
------=_Part_1412_125514382.1424348536653--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Thu, 19 Feb 2015 14:05:59 +0100
Raw View
--089e0111b8fae47310050f709842
Content-Type: text/plain; charset=UTF-8
>
> still needs to be analyzed.. but I tend to think the same. If alloca is
>> standard then class could be allocated on stack. I still fail to see how
>> call by value could be solved if sizeof is not known.
>
>
> The compiler has to reduce a 'sizeof(button)' or 'alignof(button)' to a
> constant integer and fold any dependent constant expressions or templates
> dependent thereupon before sending the whole thing to code generation. It
> is not possible to know size or alignment if the precise content and layout
> of a 'button' is only speculative or unspecified.
>
I did not wake up on this idea few days ago. Had it in my mind for a while
and it was clear for me from the beginning the two main issues: sizeof()
and layout (offsets). This two problems were repeated through the thread,
but it is my fault that I did not write a more formal paper where these
things are described so nobody wastes time to re-iterate the same thing. In
current implementation indeed not easy to fill in this gap, but IMHO is
doable.
Not sure if I mentioned in my original post, but this black/white story is
>> mainly intended for "big classes" which will not be candidate for call by
>> value.
>
>
> Classes are treated as general categories, regardless of size. This
> proposal will need to work for classes of any size, even empty ones.
>
The point I tried to make is that not knowing sizeof() at compilation time
may may cause some implementation issues for for call by value or
reference. If it turns out that will be impossible to implement call by
value or by reference, it should not be considered as a catastrophe and the
proposal rejected for this reason. But this may be just a false alarm due
to my limited knowledge of how call by reference and by value is
translated. Once I have time will have a look on how code is generated for
different layouts etc.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0111b8fae47310050f709842
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><blockquote st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex" class=3D"gmail_quote">still needs to be analyzed.. but I tend=
to think the same. If alloca is=20
standard then class could be allocated on stack. I still fail to see how
call by value could be solved if sizeof is not known.</blockquote></span><=
div><br>The compiler has to reduce a 'sizeof(button)' or 'align=
of(button)' to a constant integer and fold any dependent constant expre=
ssions or templates dependent thereupon before sending the whole thing to c=
ode generation. It is not possible to know size or alignment if the precise=
content and layout of a 'button' is only speculative or unspecifie=
d.</div></div></blockquote><div><br></div><div>I did not wake up on this id=
ea few days ago. Had it in my mind for a while and it was clear for me from=
the beginning the two main issues: sizeof() and layout (offsets). This two=
problems were repeated through the thread, but it is my fault that I did n=
ot write a more formal paper where these things are described so nobody was=
tes time to re-iterate the same thing. In current implementation indeed not=
easy to fill in this gap, but IMHO is doable.=C2=A0</div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span class=3D""><blockq=
uote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex" class=3D"gmail_quote">Not sure if I mentioned in my or=
iginal post, but this black/white story=20
is mainly intended for "big classes" which will not be candidate =
for=20
call by value.</blockquote></span><div><br>Classes are treated as general c=
ategories, regardless of size. This proposal will need to work for classes =
of any size, even empty ones.<br></div></div></div></blockquote><div><br></=
div><div>The point I tried to make is that not knowing sizeof() at compilat=
ion time may may cause some implementation issues for for call by value or =
reference. If it turns out that will be impossible to implement call by val=
ue or by reference, it should not be considered as a catastrophe and the pr=
oposal rejected for this reason. But this may be just a false alarm due to =
my limited knowledge of how call by reference and by value is translated. O=
nce I have time will have a look on how code is generated for different lay=
outs etc.</div><div><br></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0111b8fae47310050f709842--
.
Author: Chris Gary <cgary512@gmail.com>
Date: Thu, 19 Feb 2015 05:06:47 -0800 (PST)
Raw View
------=_Part_4430_686243521.1424351207251
Content-Type: multipart/alternative;
boundary="----=_Part_4431_1707673057.1424351207251"
------=_Part_4431_1707673057.1424351207251
Content-Type: text/plain; charset=UTF-8
> *snip* Thus cannot see too much reason not to have separate black. can you
> give an example pls.
Consumer:
class public button
{
public:
string text;
drawing::color color;
};
[[dllimport]]
button *make_special_button();
void verb()
{
// WYSIWYG instantiation of button.
//
// sizeof(button) MUST reduce to a constant integer at compile time!
//
button btn{};
button *btn_ptr = make_special_button();
btn_ptr->text = "Press me!";
}
PIMPL producer:
// Problem:
//
// What if more than one of these are visible in the same TU?
// Use the most recent definition?
// If they all have the same layout and member ordering, don't complain?
//
class private button
{
public:
// To save typing, this automatically injects
// members that aren't explicitly declared
// in the same declaration order, before any
// member declared in "private"
// "text" implicitly declared before what follows.
HWND hWnd;
drawing::color color;
};
[[dllexport]]
button *make_special_button()
{
return new button{/*Create window, set text, blah...*/};
}
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4431_1707673057.1424351207251
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quo=
te">*snip* Thus cannot see too much reason not to have separate black. can =
you give an example pls.</blockquote><div><br>Consumer:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">public</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> button<br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">public</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br><br> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">string</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> text</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br> drawing</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">color color</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">dllimport</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">]]</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>button </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">make_special_button</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> verb</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br> </span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">// WYSIWYG instantiation of button.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">//</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">// sizeof(button) MUST reduce to =
a constant integer at compile time!</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">//</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br> button btn</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{};</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br> <br> but=
ton </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">btn_ptr </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> make_special_button</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> <br=
> btn_ptr</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">-></span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">text </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #080;" class=3D"styled-by-prettify">"Press me!"</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div><=
br>PIMPL producer:<br><br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled=
-by-prettify">// Problem:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">//</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Wh=
at if more than one of these are visible in the same TU?</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// Use the most recent definition?=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">// If they all h=
ave the same layout and member ordering, don't complain?</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">//</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">private</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> button<br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">pu=
blic</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br> =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
To save typing, this automatically injects</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br> </span><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">// members that aren't explicitly d=
eclared</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
> </span><span style=3D"color: #800;" class=3D"styled-by-prett=
ify">// in the same declaration order, before any</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// member declared in "priva=
te"</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; <br> </span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">// "text" implicitly declared before what follows.</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>  =
; <br> HWND hWnd</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br> drawing</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">color color</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">[[</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">dllexport</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">]]</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>button </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">make_special_button</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br> </span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">new</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> button</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">{</span><span style=3D"color: #800;" class=3D"styled-by-prett=
ify">/*Create window, set text, blah...*/</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span></div></code></div><br><br><br><br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4431_1707673057.1424351207251--
------=_Part_4430_686243521.1424351207251--
.
Author: Chris Gary <cgary512@gmail.com>
Date: Thu, 19 Feb 2015 05:19:21 -0800 (PST)
Raw View
------=_Part_302_1356560379.1424351961475
Content-Type: multipart/alternative;
boundary="----=_Part_303_2023893301.1424351961475"
------=_Part_303_2023893301.1424351961475
Content-Type: text/plain; charset=UTF-8
On Thursday, February 19, 2015 at 6:06:01 AM UTC-7, mobiphil wrote:
>
> *snip*
>
The point I tried to make is that not knowing sizeof() at compilation time
> may may cause some implementation issues for for call by value or
> reference. If it turns out that will be impossible to implement call by
> value or by reference, it should not be considered as a catastrophe and the
> proposal rejected for this reason. But this may be just a false alarm due
> to my limited knowledge of how call by reference and by value is
> translated. Once I have time will have a look on how code is generated for
> different layouts etc.
>
This is why I keep repeating "sizeof() must reduce to a constant at compile
time." As templates constitute what is basically a functional language of
categories and simple integer expressions, we would need a way to modify
already-compiled binaries to accept a type with an unknown layout and
alignment (want some more bytecode with your bytecode?). I believe similar
issues were encountered with "export templates"... Imagine some exported
dependent template that does not terminate for some odd size of a type; how
difficult it might be to isolate that kind of bug (unless we have a
solution to the halting problem somewhere). So, keeping things simple, we
either forbid sizeof(), new, etc.. without a visible PIMPL, or just invoke
WYSIWYG.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_303_2023893301.1424351961475
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, February 19, 2015 at 6:06:01 AM UTC-7=
, mobiphil wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><div>*snip* <br></div></div><=
/div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><div>The point I tried to make i=
s that not knowing sizeof() at compilation time may may cause some implemen=
tation issues for for call by value or reference. If it turns out that will=
be impossible to implement call by value or by reference, it should not be=
considered as a catastrophe and the proposal rejected for this reason. But=
this may be just a false alarm due to my limited knowledge of how call by =
reference and by value is translated. Once I have time will have a look on =
how code is generated for different layouts etc.</div></div></div></div></b=
lockquote><div><br>This is why I keep repeating "sizeof() must reduce to a =
constant at compile time." As templates constitute what is basically a func=
tional language of categories and simple integer expressions, we would need=
a way to modify already-compiled binaries to accept a type with an unknown=
layout and alignment (want some more bytecode with your bytecode?). I beli=
eve similar issues were encountered with "export templates"... Imagine some=
exported dependent template that does not terminate for some odd size of a=
type; how difficult it might be to isolate that kind of bug (unless we hav=
e a solution to the halting problem somewhere). So, keeping things simple, =
we either forbid sizeof(), new, etc.. without a visible PIMPL, or just invo=
ke WYSIWYG.<br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_303_2023893301.1424351961475--
------=_Part_302_1356560379.1424351961475--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Thu, 19 Feb 2015 15:40:37 +0100
Raw View
--001a113ed2065f0831050f71eb3b
Content-Type: text/plain; charset=UTF-8
try to find also my comments in your example
> *snip* Thus cannot see too much reason not to have separate black. can you
>> give an example pls.
>
>
> Consumer:
>
> class public button
> {
> public:
>
> string text; // MOBIPHIL: still needs to be decided if this means a
> "real" data that extends the interface or automatically a "virtual" one
> that needs to be resolved by a black
> drawing::color color;
> };
>
> [[dllimport]]
> button *make_special_button();
>
> void verb()
> {
> // WYSIWYG instantiation of button.
> //
> // sizeof(button) MUST reduce to a constant integer at compile time!
> MOBIPHIL: not necessarily! if behind the scene the compiler could generate
> sthg. like char *buffer = alloca(button_sizeof()); new (buffer) blahblah...
> //
> button btn{};
>
> button *btn_ptr = make_special_button();
>
> btn_ptr->text = "Press me!";
> }
>
> PIMPL producer:
>
> // Problem:
> //
> // What if more than one of these are visible in the same TU?
> // Use the most recent definition? MOBIPHIL: you will get duplicated
> symbol for symbols (either functions or globals, depending on the
> implementation) that are defining the sizeof and offsets of visible members
> // If they all have the same layout and member ordering, don't complain?
> //
> class private button
> {
> public:
>
> // To save typing, this automatically injects
> // members that aren't explicitly declared
> // in the same declaration order, before any
> // member declared in "private" MOBIPHIL: no real objections against
> injection... see further comment below
>
> // "text" implicitly declared before what follows.
>
> HWND hWnd;
> drawing::color color;
> };
>
> [[dllexport]]
> button *make_special_button()
> {
> return new button{/*Create window, set text, blah...*/};
> }
>
>
for me the black will define some symbols that need to be available at link
time, such symbols are black_sizeof(), and offsets of the attributes that
are accessed from consumers either as setter/getter or through this
"virtual member" mechanism that makes sense. Any "white" declaration will
create dependency on such symbols, thus if the black is not available then
these symbols would be not defined. Remember that I am still proposing two
approaches for symbol resolution
-> link time (link time inlining of setters/getters ... thus the virtual
data members)
-> load time with pointers
The injection you mention in your example can make sense but there are two
contradictory approaches, I was riding more the second:
1. what you mention here that the memebres get automatically injected from
the "public" (white) and a link should be made someway between the two.
This will not allow however the option to have "real" public members.
Nevertheless allowing "real" public members would make implementation even
more difficult.
2. The other way is to have a distinction between "virtual" and normal
members on the "white". Virtual ones would be linked with the one on the
black.
In the design I am envisaging you do not need the factory method
make_special_button. However it will work like a factory method.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113ed2065f0831050f71eb3b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">try to find also my comments in your example<br><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-le=
ft:1ex" class=3D"gmail_quote">*snip* Thus cannot see too much reason not to=
have separate black. can you give an example pls.</blockquote><div><br>Con=
sumer:<br><br><div style=3D"border:1px solid rgb(187,187,187);word-wrap:bre=
ak-word;background-color:rgb(250,250,250)"><code><div><span style=3D"color:=
rgb(0,0,136)">class</span><span style=3D"color:rgb(0,0,0)"> </span><span st=
yle=3D"color:rgb(0,0,136)">public</span><span style=3D"color:rgb(0,0,0)"> b=
utton<br></span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D=
"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(0,0,136)">public</sp=
an><span style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,=
0,0)"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">strin=
g</span><span style=3D"color:rgb(0,0,0)"> text</span><span style=3D"color:r=
gb(102,102,0)">; =C2=A0// MOBIPHIL: still needs to be decided if this means=
a "real" data that extends the interface or automatically a &quo=
t;virtual" one that needs to be resolved by a black</span><span style=
=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 drawing</span><span style=3D"color:=
rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">color color</span=
><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,=
0)"><br></span><span style=3D"color:rgb(102,102,0)">};</span><span style=3D=
"color:rgb(0,0,0)"><br><br></span><span style=3D"color:rgb(102,102,0)">[[</=
span><span style=3D"color:rgb(0,0,0)">dllimport</span><span style=3D"color:=
rgb(102,102,0)">]]</span><span style=3D"color:rgb(0,0,0)"><br>button </span=
><span style=3D"color:rgb(102,102,0)">*</span><span style=3D"color:rgb(0,0,=
0)">make_special_button</span><span style=3D"color:rgb(102,102,0)">();</spa=
n><span style=3D"color:rgb(0,0,0)"><br><br></span><span style=3D"color:rgb(=
0,0,136)">void</span><span style=3D"color:rgb(0,0,0)"> verb</span><span sty=
le=3D"color:rgb(102,102,0)">()</span><span style=3D"color:rgb(0,0,0)"><br><=
/span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb=
(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(136,0,0)">// WYS=
IWYG instantiation of button.</span><span style=3D"color:rgb(0,0,0)"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:rgb(136,0,0)">//</span><span styl=
e=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(13=
6,0,0)">// sizeof(button) MUST reduce to a constant integer at=C2=A0</span>=
<span style=3D"color:rgb(136,0,0);font-family:arial,sans-serif">compile tim=
e! MOBIPHIL: not necessarily! if behind the scene the compiler could genera=
te sthg. like char *buffer =3D =C2=A0alloca(button_sizeof()); new (buffer) =
blahblah...</span></div><div><span style=3D"color:rgb(0,0,0)">=C2=A0 =C2=A0=
</span><span style=3D"color:rgb(136,0,0)">//</span><span style=3D"color:rg=
b(0,0,0)"><br>=C2=A0 =C2=A0 button btn</span><span style=3D"color:rgb(102,1=
02,0)">{};</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 <br>=C2=
=A0 =C2=A0 button </span><span style=3D"color:rgb(102,102,0)">*</span><span=
style=3D"color:rgb(0,0,0)">btn_ptr </span><span style=3D"color:rgb(102,102=
,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> make_special_button</span>=
<span style=3D"color:rgb(102,102,0)">();</span><span style=3D"color:rgb(0,0=
,0)"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 btn_ptr</span><span style=3D"color=
:rgb(102,102,0)">-></span><span style=3D"color:rgb(0,0,0)">text </span><=
span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,=
0)"> </span><span style=3D"color:rgb(0,136,0)">"Press me!"</span>=
<span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0=
)"><br></span><span style=3D"color:rgb(102,102,0)">}</span></div></code></d=
iv><br>PIMPL producer:<br><br><div style=3D"border:1px solid rgb(187,187,18=
7);word-wrap:break-word;background-color:rgb(250,250,250)"><code><div><span=
style=3D"color:rgb(136,0,0)">// Problem:</span><span style=3D"color:rgb(0,=
0,0)"><br></span><span style=3D"color:rgb(136,0,0)">//</span><span style=3D=
"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(136,0,0)">// What if=
more than one of these are visible in the same TU?</span><span style=3D"co=
lor:rgb(0,0,0)"><br></span><span style=3D"color:rgb(136,0,0)">// Use the mo=
st recent definition? MOBIPHIL: you will get duplicated symbol for symbols =
(either functions or globals, depending on the implementation) that are def=
ining the sizeof and offsets of visible members</span><span style=3D"color:=
rgb(0,0,0)"><br></span><span style=3D"color:rgb(136,0,0)">// If they all ha=
ve the same layout and member ordering, don't complain?</span><span sty=
le=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(136,0,0)">//</s=
pan><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(0,=
0,136)">class</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D=
"color:rgb(0,0,136)">private</span><span style=3D"color:rgb(0,0,0)"> button=
<br></span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D"colo=
r:rgb(0,0,0)"><br></span><span style=3D"color:rgb(0,0,136)">public</span><s=
pan style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"=
><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(136,0,0)">// To save=
typing, this automatically injects</span><span style=3D"color:rgb(0,0,0)">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(136,0,0)">// members that=
aren't explicitly declared</span><span style=3D"color:rgb(0,0,0)"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:rgb(136,0,0)">// in the same decl=
aration order, before any</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0=
=C2=A0 </span><span style=3D"color:rgb(136,0,0)">// member declared in &qu=
ot;private" =C2=A0MOBIPHIL: no real objections against injection... se=
e further comment below</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =
=C2=A0 <br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(136,0,0)">// "=
;text" implicitly declared before what follows.</span><span style=3D"c=
olor:rgb(0,0,0)"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 HWND hWnd</span><span =
style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br=
>=C2=A0 =C2=A0 drawing</span><span style=3D"color:rgb(102,102,0)">::</span>=
<span style=3D"color:rgb(0,0,0)">color color</span><span style=3D"color:rgb=
(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><span styl=
e=3D"color:rgb(102,102,0)">};</span><span style=3D"color:rgb(0,0,0)"><br><b=
r></span><span style=3D"color:rgb(102,102,0)">[[</span><span style=3D"color=
:rgb(0,0,0)">dllexport</span><span style=3D"color:rgb(102,102,0)">]]</span>=
<span style=3D"color:rgb(0,0,0)"><br>button </span><span style=3D"color:rgb=
(102,102,0)">*</span><span style=3D"color:rgb(0,0,0)">make_special_button</=
span><span style=3D"color:rgb(102,102,0)">()</span><span style=3D"color:rgb=
(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">{</span><span styl=
e=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,=
0,136)">return</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(0,0,136)">new</span><span style=3D"color:rgb(0,0,0)"> button<=
/span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb=
(136,0,0)">/*Create window, set text, blah...*/</span><span style=3D"color:=
rgb(102,102,0)">};</span><span style=3D"color:rgb(0,0,0)"><br></span><span =
style=3D"color:rgb(102,102,0)">}</span></div></code></div><br></div></div><=
/blockquote></div><br>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">for m=
e the black will define some symbols that need to be available at link time=
, such symbols are black_sizeof(), and offsets of the attributes that are a=
ccessed from consumers either as setter/getter or through this "virtua=
l member" mechanism that makes sense. Any "white" declaratio=
n will create dependency on such symbols, thus if the black is not availabl=
e then these symbols would be not defined. Remember that I am still proposi=
ng two approaches for symbol resolution</div><div class=3D"gmail_extra">-&g=
t; link time (link time inlining of setters/getters ... thus the virtual da=
ta members)</div><div class=3D"gmail_extra">-> load time with pointers<b=
r><br>The injection you mention in your example can make sense but there ar=
e two contradictory approaches, I was riding more the second:</div><div cla=
ss=3D"gmail_extra"><br></div><div class=3D"gmail_extra">1. what you mention=
here that the memebres get automatically injected from the "public&qu=
ot; (white) and a link should be made someway between the two. This will no=
t allow however the option to have "real" public members. Neverth=
eless allowing "real" public members would make implementation ev=
en more difficult.</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra">2. The other way is to have a distinction between "virtua=
l" and normal members on the "white". Virtual ones would be =
linked with the one on the black.=C2=A0</div><div class=3D"gmail_extra"><br=
></div><div class=3D"gmail_extra">In the design I am envisaging you do not =
need the factory method make_special_button. However it will work like a fa=
ctory method.<br></div><div class=3D"gmail_extra"><br><br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113ed2065f0831050f71eb3b--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Thu, 19 Feb 2015 15:44:08 +0100
Raw View
--089e01184038e72e18050f71f7dc
Content-Type: text/plain; charset=UTF-8
>
> *snip*
>>
> The point I tried to make is that not knowing sizeof() at compilation time
>> may may cause some implementation issues for for call by value or
>> reference. If it turns out that will be impossible to implement call by
>> value or by reference, it should not be considered as a catastrophe and the
>> proposal rejected for this reason. But this may be just a false alarm due
>> to my limited knowledge of how call by reference and by value is
>> translated. Once I have time will have a look on how code is generated for
>> different layouts etc.
>>
>
> This is why I keep repeating "sizeof() must reduce to a constant at
> compile time." As templates constitute what is basically a functional
> language of categories and simple integer expressions, we would need a way
> to modify already-compiled binaries to accept a type with an unknown layout
> and alignment (want some more bytecode with your bytecode?). I believe
> similar issues were encountered with "export templates"... Imagine some
> exported dependent template that does not terminate for some odd size of a
> type; how difficult it might be to isolate that kind of bug (unless we have
> a solution to the halting problem somewhere). So, keeping things simple, we
> either forbid sizeof(), new, etc.. without a visible PIMPL, or just invoke
> WYSIWYG.
>
can we please someway agree that if sizeof has to reduce to a constant at
compile time is in serious contradiction what this proposal try to achive?
The point is that you add minimum to the header, you freeze it, and then
you do your development cycles in the cpp... Once the data layout is in the
black, you cannot have the sizeof.
About your argument above, do not say no, but one has to analyze how much
size is affecting templates and how much templates can do with the data
that stays in the white. Speculations in one direction or other do not
really help to much.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e01184038e72e18050f71f7dc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>*snip* <br><=
/div></div></div></div></blockquote><span class=3D""><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>The=
point I tried to make is that not knowing sizeof() at compilation time may=
may cause some implementation issues for for call by value or reference. I=
f it turns out that will be impossible to implement call by value or by ref=
erence, it should not be considered as a catastrophe and the proposal rejec=
ted for this reason. But this may be just a false alarm due to my limited k=
nowledge of how call by reference and by value is translated. Once I have t=
ime will have a look on how code is generated for different layouts etc.</d=
iv></div></div></div></blockquote></span><div><br>This is why I keep repeat=
ing "sizeof() must reduce to a constant at compile time." As temp=
lates constitute what is basically a functional language of categories and =
simple integer expressions, we would need a way to modify already-compiled =
binaries to accept a type with an unknown layout and alignment (want some m=
ore bytecode with your bytecode?). I believe similar issues were encountere=
d with "export templates"... Imagine some exported dependent temp=
late that does not terminate for some odd size of a type; how difficult it =
might be to isolate that kind of bug (unless we have a solution to the halt=
ing problem somewhere). So, keeping things simple, we either forbid sizeof(=
), new, etc.. without a visible PIMPL, or just invoke WYSIWYG.<br></div></d=
iv></blockquote><div><br></div><div>can we please someway agree that if siz=
eof has to reduce to a constant at compile time is in serious contradiction=
what this proposal try to achive?<br><br>The point is that you add minimum=
to the header, you freeze it, and then you do your development cycles in t=
he cpp... Once the data layout is in the black, you cannot have the sizeof.=
</div><div><br></div><div>About your argument above, do not say no, but one=
has to analyze how much size is affecting templates and how much templates=
can do with the data that stays in the white. Speculations in one directio=
n or other do not really help to much.</div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01184038e72e18050f71f7dc--
.
Author: Chris Gary <cgary512@gmail.com>
Date: Thu, 19 Feb 2015 07:11:54 -0800 (PST)
Raw View
------=_Part_73_1098763343.1424358714350
Content-Type: multipart/alternative;
boundary="----=_Part_74_703625248.1424358714351"
------=_Part_74_703625248.1424358714351
Content-Type: text/plain; charset=UTF-8
This should illustrate my argument a little more clearly:
namespace _impl{
using AnySmallBfr = uintptr_t[3];
struct _basic_any_blob
{
virtual void _destroy() noexcept = 0;
// Destructor not called!
};
template<
typename InnerType
bool isSmall = (
sizeof(InnerType) <= sizeof(AnySmallBfr)
)
>
struct _any_blob : _basic_any_blob
{
InnerType _that;
void _destroy() noexcept override
{this->_that->~InnerType();}
// Rest of implementation
};
template<typename InnerType>
struct _any_blob<InnerType, false>
{
// Too big, need to allocate separately
InnerType *_that_ptr;
void _destroy() noexcept override
{delete this->_that_ptr;}
// Rest of implementation
};
}// namespace _impl
class any
{
_impl::AnySmallBfr _small_bfr;
public:
template<typename ValueType>
any(ValueType &&value)
{
// Decides between small and large
// backing store.
//
// If sizeof(ValueType) <= sizeof(_small_bfr),
// placement-new into _small_bfr.
// This should compile statically, but...
//
// Are you suggesting we automate code generation
// to handle structures like _any_blob<> parameterized
// by "white" types?
//
new(this->_small_bfr) _impl::_any_blob<
decay<ValueType>
>{forward<ValueType>(value)};
}
~any() noexcept
{
reinterpret_cast<_impl::_basic_any_blob &>(
this->_small_bfr
)._destroy();
}
};
Consumer using an 'any':
class public thing
{
public:
string in_thing;
};
void verb()
{
// What happens if the resulting object's
// size depends on something loaded externally?
//
// Also: What if we have multiple implementations linked? Which 'thing'
is chosen?
//
any wut = thing{};
}
Producer with another thing:
// Too big for internal buffer of 'any'
//
class private thing
{
public:
string in_thing;
int hidden_int;
float hidden_float;
char hidden_chars[16];
};
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_74_703625248.1424358714351
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This should illustrate my argument a little more clearly:<=
br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">names=
pace</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> _impl=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br><br> &nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">using</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">AnySmallBfr</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> uintptr_t</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">3</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">];</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br> <br> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> _basic_any_blob<br> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
virtual</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> _destroy</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> noexcept </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> <br> &nb=
sp; </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Des=
tructor not called!</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">template</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">InnerType</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> isSmall </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> </span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">sizeof</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">InnerType</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">sizeof=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">AnySmallBfr</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> &n=
bsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">></=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &=
nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">stru=
ct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> _any_bl=
ob </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> _basic_any_blob=
<br> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">InnerType</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> _that</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br> <br> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> _destroy</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> noexcept </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">override</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">this</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">-></span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">_that</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">->~</span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">InnerType</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">();}</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br> <br> =
</span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// Rest of implementation</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br><br> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">InnerType</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> _any_blob</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">InnerType</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">false</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br> &n=
bsp; </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">// Too big, need to allocate separately</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br> </span><span=
style=3D"color: #606;" class=3D"styled-by-prettify">InnerType</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">_that_ptr</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> <br> &=
nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> _d=
estroy</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> noexcept </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">override</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #008;" class=3D"styled-by-prettify">d=
elete</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">this</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">-></span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">_that_ptr</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;}</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br> <b=
r> </span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">// Rest of implementation</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">}</span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// namespace _impl</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> any<br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> _impl</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">AnySmallBfr</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> _small_bfr</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> <br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">public</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br><br> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">template</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">ValueType</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br> any</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">ValueType</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">value</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nbs=
p; </span><span style=3D"color: #800;" class=3D"styled-by-prettify">=
// Decides between small and large</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// backing store.</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>//</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">// If sizeof(ValueType) <=3D sizeof(_small_bfr),</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br> &=
nbsp; </span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">// placement-new into _small_bfr.</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br> <br> =
</span><span style=3D"color: #800;" class=3D"styled-by-prett=
ify">// This should compile statically, but...</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br> </span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">//</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
Are you suggesting we automate code generation</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br> </span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">// to handle stru=
ctures like _any_blob<> parameterized</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br> </span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">// by "white" types?=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">//</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">new</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">this</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">-></span><span style=3D"color: #000;" class=3D"styled-by-prettify">_=
small_bfr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> _impl</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">_any_blob</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; decay</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify"><</span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">ValueType</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br> </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">>{</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">forward</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify"><</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">ValueType</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">>(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">value</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">)};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br> <br> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">~</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">any</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> noexcept<br> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">reinterpret_cast</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">_impl</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">_basic_any_blob </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&>(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br> &n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">this<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">-></span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">_small_bfr<br>&n=
bsp; </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">).</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">_destroy</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">};</span></div></code></div><br>Consumer using an 'any':<br><br><=
div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wor=
d-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">public</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> thing<br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">public</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br><br> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">string</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> in_thing</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">v=
oid</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> verb</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br> </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// What happens if the resu=
lting object's</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// size depends on something loaded externally?</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><=
span style=3D"color: #800;" class=3D"styled-by-prettify">//</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><=
span style=3D"color: #800;" class=3D"styled-by-prettify">// Also: What if w=
e have multiple implementations linked? Which 'thing' is chosen?</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> </s=
pan><span style=3D"color: #800;" class=3D"styled-by-prettify">//</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> any=
wut </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> thing</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Pro=
ducer with another thing:<br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D=
"styled-by-prettify">// Too big for internal buffer of 'any'</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">//</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">private</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> thing<br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">pu=
blic</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">str=
ing</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> in_thi=
ng</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> hidden_int</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> hidden_float</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> hidden_chars</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D=
"color: #066;" class=3D"styled-by-prettify">16</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">];</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span></div></code></div><br></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_74_703625248.1424358714351--
------=_Part_73_1098763343.1424358714350--
.
Author: Chris Gary <cgary512@gmail.com>
Date: Thu, 19 Feb 2015 07:17:17 -0800 (PST)
Raw View
------=_Part_1020_195081740.1424359037837
Content-Type: multipart/alternative;
boundary="----=_Part_1021_1086144808.1424359037845"
------=_Part_1021_1086144808.1424359037845
Content-Type: text/plain; charset=UTF-8
I need to point out the sample I gave was hacked together in a few minutes
and is riddled with bugs. The point here is illustrated in the constructor
of 'any'.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1021_1086144808.1424359037845
Content-Type: text/html; charset=UTF-8
<div dir="ltr">I need to point out the sample I gave was hacked together in a few minutes and is riddled with bugs. The point here is illustrated in the constructor of 'any'.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_1021_1086144808.1424359037845--
------=_Part_1020_195081740.1424359037837--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Thu, 19 Feb 2015 16:22:24 +0100
Raw View
--001a113ec45acbdc16050f7280d2
Content-Type: text/plain; charset=UTF-8
sorry, first before I try to understand the point you try to make with the
example, let's clarify one thing: you are intentionally using sizeof
(probably to explain your concern), whereas it is clear that what I am
proposing can be implemented if the dependency on the sizeof is eliminated
or can be delayed to link time or load time.
again: not all classes can be used in all situations. A class can be used
in a certain situation (template parameter etc.) if it implements a certain
protocol. In our case the class does not implement the compile time sizeof
protocol, thus it cannot be used in situation where this protocol is
needed. This does not mean that the proposal has no value etc. We are
playing with concept not with a universal machine, or theory of everything
:)
> This should illustrate my argument a little more clearly:
>
> namespace _impl{
>
> using AnySmallBfr = uintptr_t[3];
>
> struct _basic_any_blob
> {
> virtual void _destroy() noexcept = 0;
>
> // Destructor not called!
> };
>
> template<
> typename InnerType
> bool isSmall = (
> sizeof(InnerType) <= sizeof(AnySmallBfr)
> )
> >
> struct _any_blob : _basic_any_blob
> {
> InnerType _that;
>
> void _destroy() noexcept override
> {this->_that->~InnerType();}
>
> // Rest of implementation
> };
>
> template<typename InnerType>
> struct _any_blob<InnerType, false>
> {
> // Too big, need to allocate separately
> InnerType *_that_ptr;
>
> void _destroy() noexcept override
> {delete this->_that_ptr;}
>
> // Rest of implementation
> };
>
> }// namespace _impl
>
> class any
> {
> _impl::AnySmallBfr _small_bfr;
>
> public:
>
> template<typename ValueType>
> any(ValueType &&value)
> {
> // Decides between small and large
> // backing store.
> //
> // If sizeof(ValueType) <= sizeof(_small_bfr),
> // placement-new into _small_bfr.
>
> // This should compile statically, but...
> //
> // Are you suggesting we automate code generation
> // to handle structures like _any_blob<> parameterized
> // by "white" types?
> //
> new(this->_small_bfr) _impl::_any_blob<
> decay<ValueType>
> >{forward<ValueType>(value)};
> }
>
> ~any() noexcept
> {
> reinterpret_cast<_impl::_basic_any_blob &>(
> this->_small_bfr
> )._destroy();
> }
> };
>
> Consumer using an 'any':
>
> class public thing
> {
> public:
>
> string in_thing;
> };
>
> void verb()
> {
> // What happens if the resulting object's
> // size depends on something loaded externally?
> //
> // Also: What if we have multiple implementations linked? Which
> 'thing' is chosen?
> //
> any wut = thing{};
> }
>
> Producer with another thing:
>
> // Too big for internal buffer of 'any'
> //
> class private thing
> {
> public:
>
> string in_thing;
> int hidden_int;
> float hidden_float;
> char hidden_chars[16];
> };
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113ec45acbdc16050f7280d2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>sorry, first before I try to understand the point you try to make with the=
example, let's clarify one thing: you are intentionally using sizeof (=
probably to explain your concern), whereas it is clear that what I am propo=
sing can be implemented if the dependency on the sizeof is eliminated or ca=
n be delayed to link time or load time.</div><div><br></div><div>again: not=
all classes can be used in all situations. A class can be used in a certai=
n situation (template parameter etc.) if it implements a certain protocol. =
In our case the class does not implement the compile time sizeof protocol, =
thus it cannot be used in situation where this protocol is needed. This doe=
s not mean that the proposal has no value etc. We are playing with concept =
not with a universal machine, or theory of everything :)</div><div><br></di=
v><div><br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">This should illustrate my argument a little more clearly:<br><br=
><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,1=
87);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><s=
pan style=3D"color:#008">namespace</span><span style=3D"color:#000"> _impl<=
/span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br><br=
>=C2=A0 =C2=A0 </span><span style=3D"color:#008">using</span><span style=3D=
"color:#000"> </span><span style=3D"color:#606">AnySmallBfr</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> uintptr_t</span><span style=3D"color:#660">[</span><span s=
tyle=3D"color:#066">3</span><span style=3D"color:#660">];</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span><span style=3D"c=
olor:#008">struct</span><span style=3D"color:#000"> _basic_any_blob<br>=C2=
=A0 =C2=A0 </span><span style=3D"color:#660">{</span><span style=3D"color:#=
000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">virt=
ual</span><span style=3D"color:#000"> </span><span style=3D"color:#008">voi=
d</span><span style=3D"color:#000"> _destroy</span><span style=3D"color:#66=
0">()</span><span style=3D"color:#000"> noexcept </span><span style=3D"colo=
r:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#=
066">0</span><span style=3D"color:#660">;</span><span style=3D"color:#000">=
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><spa=
n style=3D"color:#800">// Destructor not called!</span><span style=3D"color=
:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">};</span><span s=
tyle=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008"=
>template</span><span style=3D"color:#660"><</span><span style=3D"color:=
#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">typ=
ename</span><span style=3D"color:#000"> </span><span style=3D"color:#606">I=
nnerType</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
/span><span style=3D"color:#008">bool</span><span style=3D"color:#000"> isS=
mall </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">(</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">sizeof</span>=
<span style=3D"color:#660">(</span><span style=3D"color:#606">InnerType</sp=
an><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#660"><=3D</span><span style=3D"color:#000"> </span><=
span style=3D"color:#008">sizeof</span><span style=3D"color:#660">(</span><=
span style=3D"color:#606">AnySmallBfr</span><span style=3D"color:#660">)</s=
pan><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span=
style=3D"color:#660">)</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =
</span><span style=3D"color:#660">></span><span style=3D"color:#000"><br=
>=C2=A0 =C2=A0 </span><span style=3D"color:#008">struct</span><span style=
=3D"color:#000"> _any_blob </span><span style=3D"color:#660">:</span><span =
style=3D"color:#000"> _basic_any_blob<br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0=
=C2=A0 </span><span style=3D"color:#606">InnerType</span><span style=3D"co=
lor:#000"> _that</span><span style=3D"color:#660">;</span><span style=3D"co=
lor:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
/span><span style=3D"color:#008">void</span><span style=3D"color:#000"> _de=
stroy</span><span style=3D"color:#660">()</span><span style=3D"color:#000">=
noexcept </span><span style=3D"color:#008">override</span><span style=3D"c=
olor:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#660=
">{</span><span style=3D"color:#008">this</span><span style=3D"color:#660">=
-></span><span style=3D"color:#000">_that</span><span style=3D"color:#66=
0">->~</span><span style=3D"color:#606">InnerType</span><span style=3D"c=
olor:#660">();}</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#800">//=
Rest of implementation</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =
</span><span style=3D"color:#660">};</span><span style=3D"color:#000"><br><=
br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">template</span><span sty=
le=3D"color:#660"><</span><span style=3D"color:#008">typename</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#606">InnerType</span><=
span style=3D"color:#660">></span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color:#008">struct</span><span style=3D"color:=
#000"> _any_blob</span><span style=3D"color:#660"><</span><span style=3D=
"color:#606">InnerType</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">false</span><span style=
=3D"color:#660">></span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </s=
pan><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#800">// Too big, need=
to allocate separately</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color:#606">InnerType</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">*</span><span style=3D"c=
olor:#000">_that_ptr</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 </span><span style=3D"color:#008">void</span><span style=3D"color:#0=
00"> _destroy</span><span style=3D"color:#660">()</span><span style=3D"colo=
r:#000"> noexcept </span><span style=3D"color:#008">override</span><span st=
yle=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"co=
lor:#660">{</span><span style=3D"color:#008">delete</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#008">this</span><span style=3D"colo=
r:#660">-></span><span style=3D"color:#000">_that_ptr</span><span style=
=3D"color:#660">;}</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#800=
">// Rest of implementation</span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:#660">};</span><span style=3D"color:#000"><=
br><br></span><span style=3D"color:#660">}</span><span style=3D"color:#800"=
>// namespace _impl</span><span style=3D"color:#000"><br><br></span><span s=
tyle=3D"color:#008">class</span><span style=3D"color:#000"> any<br></span><=
span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 _impl</span><span style=3D"color:#660">::</span><span style=3D"color:#6=
06">AnySmallBfr</span><span style=3D"color:#000"> _small_bfr</span><span st=
yle=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 <br=
></span><span style=3D"color:#008">public</span><span style=3D"color:#660">=
:</span><span style=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#008">template</span><span style=3D"color:#660"><</span><span =
style=3D"color:#008">typename</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#606">ValueType</span><span style=3D"color:#660">></spa=
n><span style=3D"color:#000"><br>=C2=A0 =C2=A0 any</span><span style=3D"col=
or:#660">(</span><span style=3D"color:#606">ValueType</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">&&</span><span style=
=3D"color:#000">value</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">{</span=
><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span st=
yle=3D"color:#800">// Decides between small and large</span><span style=3D"=
color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#80=
0">// backing store.</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color:#800">//</span><span style=3D"color:=
#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#800">// =
If sizeof(ValueType) <=3D sizeof(_small_bfr),</span><span style=3D"color=
:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#800">//=
placement-new into _small_bfr.</span><span style=3D"color:#000"><br>=C2=A0=
=C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D=
"color:#800">// This should compile statically, but...</span><span style=3D=
"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#8=
00">//</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </s=
pan><span style=3D"color:#800">// Are you suggesting we automate code gener=
ation</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </sp=
an><span style=3D"color:#800">// to handle structures like _any_blob<>=
; parameterized</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 </span><span style=3D"color:#800">// by "white" types?</sp=
an><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span =
style=3D"color:#800">//</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color:#008">new</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#008">this</span><span style=3D"colo=
r:#660">-></span><span style=3D"color:#000">_small_bfr</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"> _impl</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">_any_blob</span><span s=
tyle=3D"color:#660"><</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 decay</span><span style=3D"color:#660"><</s=
pan><span style=3D"color:#606">ValueType</span><span style=3D"color:#660">&=
gt;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 </span><span style=3D"color:#660">>{</span><span style=3D"color:=
#000">forward</span><span style=3D"color:#660"><</span><span style=3D"co=
lor:#606">ValueType</span><span style=3D"color:#660">>(</span><span styl=
e=3D"color:#000">value</span><span style=3D"color:#660">)};</span><span sty=
le=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">}</sp=
an><span style=3D"color:#000"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </span><s=
pan style=3D"color:#660">~</span><span style=3D"color:#000">any</span><span=
style=3D"color:#660">()</span><span style=3D"color:#000"> noexcept<br>=C2=
=A0 =C2=A0 </span><span style=3D"color:#660">{</span><span style=3D"color:#=
000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">rein=
terpret_cast</span><span style=3D"color:#660"><</span><span style=3D"col=
or:#000">_impl</span><span style=3D"color:#660">::</span><span style=3D"col=
or:#000">_basic_any_blob </span><span style=3D"color:#660">&>(</span=
><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
/span><span style=3D"color:#008">this</span><span style=3D"color:#660">->=
;</span><span style=3D"color:#000">_small_bfr<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#660">).</span><span style=3D=
"color:#000">_destroy</span><span style=3D"color:#660">();</span><span styl=
e=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">}</spa=
n><span style=3D"color:#000"><br></span><span style=3D"color:#660">};</span=
></div></code></div><br>Consumer using an 'any':<br><br><div style=
=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-=
style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#008">class</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">public</span><span style=3D"color:#000"> thing<br></span><s=
pan style=3D"color:#660">{</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#008">public</span><span style=3D"color:#660">:</span><spa=
n style=3D"color:#000"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:#0=
08">string</span><span style=3D"color:#000"> in_thing</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#660">};</span><span style=3D"color:#000"><br><br></span><span style=3D=
"color:#008">void</span><span style=3D"color:#000"> verb</span><span style=
=3D"color:#660">()</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span=
><span style=3D"color:#800">// What happens if the resulting object's</=
span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or:#800">// size depends on something loaded externally?</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#800">//</spa=
n><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:=
#800">// Also: What if we have multiple implementations linked? Which '=
thing' is chosen?</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </=
span><span style=3D"color:#800">//</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 any wut </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> thing</span><span style=3D"color:#660">{};</span><span sty=
le=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"><br></span></div></code></div><br>Producer with another thi=
ng:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb=
(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><co=
de><div><span style=3D"color:#800">// Too big for internal buffer of 'a=
ny'</span><span style=3D"color:#000"><br></span><span style=3D"color:#8=
00">//</span><span style=3D"color:#000"><br></span><span style=3D"color:#00=
8">class</span><span style=3D"color:#000"> </span><span style=3D"color:#008=
">private</span><span style=3D"color:#000"> thing<br></span><span style=3D"=
color:#660">{</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#008">public</span><span style=3D"color:#660">:</span><span style=3D"co=
lor:#000"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">string</s=
pan><span style=3D"color:#000"> in_thing</span><span style=3D"color:#660">;=
</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"c=
olor:#008">int</span><span style=3D"color:#000"> hidden_int</span><span sty=
le=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </sp=
an><span style=3D"color:#008">float</span><span style=3D"color:#000"> hidde=
n_float</span><span style=3D"color:#660">;</span><span style=3D"color:#000"=
><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">char</span><span style=
=3D"color:#000"> hidden_chars</span><span style=3D"color:#660">[</span><spa=
n style=3D"color:#066">16</span><span style=3D"color:#660">];</span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#660">};</span><span st=
yle=3D"color:#000"><br></span></div></code></div><br></div><div class=3D"HO=
EnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature">rgrds,<br>mobi phil<br><br>being mobile, but=
including technology<br><a href=3D"http://mobiphil.com">http://mobiphil.co=
m</a></div>
</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113ec45acbdc16050f7280d2--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 19 Feb 2015 12:18:51 -0800
Raw View
On Thursday 19 February 2015 14:05:59 mobi phil wrote:
> The point I tried to make is that not knowing sizeof() at compilation time
> may may cause some implementation issues for for call by value or
> reference. If it turns out that will be impossible to implement call by
> value or by reference, it should not be considered as a catastrophe and the
> proposal rejected for this reason. But this may be just a false alarm due
> to my limited knowledge of how call by reference and by value is
> translated. Once I have time will have a look on how code is generated for
> different layouts etc.
I can tell you right now: without knowing the size, passing by value in the
current way "pass-by-value" is understood will be impossible, period.
Passing by reference or by pointer should be possible, since those already
work even on incomplete types.
A solution for the by-value case is to treat it as passing by
pointer/reference in the ABI. That is, in most ABIs, the compiler will have to
reserve stack space for the dynamic size, copy the content, then pass the
address of that space.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: mobi phil <mobi@mobiphil.com>
Date: Thu, 19 Feb 2015 21:41:52 +0100
Raw View
--001a113ec45a4301d2050f76f772
Content-Type: text/plain; charset=UTF-8
>
> I can tell you right now: without knowing the size, passing by value in the
> current way "pass-by-value" is understood will be impossible, period.
>
> Passing by reference or by pointer should be possible, since those already
> work even on incomplete types.
>
> A solution for the by-value case is to treat it as passing by
> pointer/reference in the ABI. That is, in most ABIs, the compiler will
> have to
> reserve stack space for the dynamic size, copy the content, then pass the
> address of that space.
>
that was exactly my concern, however, without any intention to offend: do
you exactly know the implementation difference between call by reference
and call by value? I am afraid from the called function point of view that
is NO difference. On the caller side you will have the original object and
a copy of it will be created before the call. Now if the original object
can be created with alloca then the copy also can be created with alloca.
Do not see any difference here.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113ec45a4301d2050f76f772
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">I can tell you right now: without knowing the si=
ze, passing by value in the<br>
current way "pass-by-value" is understood will be impossible, per=
iod.<br>
<br>
Passing by reference or by pointer should be possible, since those already<=
br>
work even on incomplete types.<br>
<br>
A solution for the by-value case is to treat it as passing by<br>
pointer/reference in the ABI. That is, in most ABIs, the compiler will have=
to<br>
reserve stack space for the dynamic size, copy the content, then pass the<b=
r>
address of that space.<br></blockquote><div><br></div><div>that was exactly=
my concern, however, without any intention to offend: do you exactly know =
the implementation difference between call by reference and call by value? =
I am afraid from the called function point of view that is NO difference. O=
n the caller side you will have the original object and a copy of it will b=
e created before the call. Now if the original object can be created with a=
lloca then the copy also can be created with alloca. Do not see any differe=
nce here.</div><div><br></div><div><br></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113ec45a4301d2050f76f772--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 20 Feb 2015 11:55:22 -0800
Raw View
On Thursday 19 February 2015 21:41:52 mobi phil wrote:
> that was exactly my concern, however, without any intention to offend: do
> you exactly know the implementation difference between call by reference
> and call by value?
Yes.
Under certain constraints, even aggregates might be passed in registers. This
really depends on the ABI and the psABI in question, so YMMV quite a lot. You
can read more about this in my blog:
http://www.macieira.org/blog/2012/02/the-value-of-passing-by-value/
Any type that can't be passed in registers is passed by hidden reference: a
copy is spilled to the stack and its address is passed in place of the type
itself.
Black or white types will always need to be passed by hidden reference.
> I am afraid from the called function point of view that
> is NO difference. On the caller side you will have the original object and
> a copy of it will be created before the call. Now if the original object
> can be created with alloca then the copy also can be created with alloca.
> Do not see any difference here.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: mobi phil <mobi@mobiphil.com>
Date: Sat, 21 Feb 2015 04:24:05 +0100
Raw View
--001a1133201894b5cb050f90b317
Content-Type: text/plain; charset=UTF-8
>
>
> Black or white types will always need to be passed by hidden reference.
>
missing some optimization opportunities should not be interpreted as the
end of the world or as to say "period" like you stated earlier
>>I can tell you right now: without knowing the size, passing by value in
the
>>current way "pass-by-value" is understood will be impossible, period.
can you please tell me, why you said it would be impossible? Now you seem
to have reduced the "impossible" to the handicap of not being able to pass
in registers. I would love to have time to read your blog and other
millions of books, article on the topic. Best is to look at generated code,
no blog/book/video/etc. can tell me more than. What I see so far that it is
feasable. If some mini optimization opportunities are lost, well, you
always have to tread sthg. for sthg. else...
I am personally ok with this little "disadvantage". If I want to hunt for
that little piece of cake, then I will move my blacks to the white and get
it once the project reached a stable phase. I am also thinking about some
details on how to move black back if optimization is to be achieved.
Unfortunately most of the projects I worked on there was less worry about
such optimization opportunities like passing an object in registers rather
than on stack. Happened often that this brilliant managers did read in some
fancy local newspapers that was mad to tell "-O{1,2,3}" to the compiler. It
is also true that 15 years ago optimizer were often producing buggy code.
Do not forget that QT pimple object cannot be passed in registers...
Because he is still a pointer...
So, lets take things easy. Let's do not adventure to far, before we did not
fix simple things. Let's do not optimize before we agreed on basic stuff...
Would alloca knowing the size from a function or global variable solve the
problem of sizeof of black?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1133201894b5cb050f90b317
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><br>
Black or white types will always need to be passed by hidden reference.<br>=
</blockquote><div><br></div><div>missing some optimization opportunities sh=
ould not be interpreted as the end of the world or as to say "period&q=
uot; like you stated earlier</div><div><br></div><div><span style=3D"font-s=
ize:12.8000001907349px">>>I can tell you right now: without knowing t=
he size, passing by value in the</span><br style=3D"font-size:12.8000001907=
349px"><span style=3D"font-size:12.8000001907349px">>>current way &qu=
ot;pass-by-value" is understood will be impossible, period.</span><br>=
</div><div>=C2=A0</div><div>can you please tell me, why you said it would b=
e impossible? Now you seem to have reduced the "impossible" to th=
e handicap of not being able to pass in registers. I would love to have tim=
e to read your blog and other millions of books, article on the topic. Best=
is to look at generated code, no blog/book/video/etc. can tell me more tha=
n. What I see so far that it is feasable. If some mini optimization opportu=
nities are lost, well, you always have to tread sthg. for sthg. else...</di=
v><div><br></div><div>I am personally ok with this little "disadvantag=
e". If I want to hunt for that little piece of cake, then I will move =
my blacks to the white and get it once the project reached a stable phase. =
I am also thinking about some details on how to move black back if optimiza=
tion is to be achieved.</div><div><br></div><div>Unfortunately most of the =
projects I worked on there was less worry about such optimization opportuni=
ties like passing an object in registers rather than on stack. Happened oft=
en that this brilliant managers did read in some fancy local newspapers tha=
t was mad to tell "-O{1,2,3}" to the compiler. It is also true th=
at 15 years ago optimizer were often producing buggy code. =C2=A0</div><div=
><br></div><div>Do not forget that QT pimple object cannot be passed in reg=
isters... Because he is still a pointer...=C2=A0</div><div><br></div><div>S=
o, lets take things easy. Let's do not adventure to far, before we did =
not fix simple things. Let's do not optimize before we agreed on basic =
stuff... Would alloca knowing the size from a function or global variable s=
olve the problem of sizeof of black?</div><div><br></div><div><br></div></d=
iv>
</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1133201894b5cb050f90b317--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 20 Feb 2015 19:41:04 -0800
Raw View
On Saturday 21 February 2015 04:24:05 mobi phil wrote:
> > Black or white types will always need to be passed by hidden reference.
>
> missing some optimization opportunities should not be interpreted as the
> end of the world or as to say "period" like you stated earlier
I never meant that it was the end of the world. I wrote quite explicitly that
it could never be done as it is currently done, that's it.
> >>I can tell you right now: without knowing the size, passing by value in
>
> the
>
> >>current way "pass-by-value" is understood will be impossible, period.
>
> can you please tell me, why you said it would be impossible? Now you seem
How many registers do you reserve for the structure if you don't know its
size? Selecting the registers dynamically means all other parameters would be
dynamically determined, which seems to me to be horribly inefficient.
It's more efficient to allocate stack space, pass by hidden reference and keep
all the other parameters at fixed positions.
> to have reduced the "impossible" to the handicap of not being able to pass
> in registers. I would love to have time to read your blog and other
> millions of books, article on the topic.
Well, if you're not going to read up on the subject, how can we discuss the
subject?
> Best is to look at generated code,
> no blog/book/video/etc. can tell me more than. What I see so far that it is
> feasable. If some mini optimization opportunities are lost, well, you
> always have to tread sthg. for sthg. else...
How do you think I came up with the content of the blog? By compiling and
generating code, plus reading the ABI manuals.
> I am personally ok with this little "disadvantage". If I want to hunt for
> that little piece of cake, then I will move my blacks to the white and get
> it once the project reached a stable phase. I am also thinking about some
> details on how to move black back if optimization is to be achieved.
Once a black box, always a black box: as you don't know the other side, you
must assume the other side doesn't have access to the white box.
> Do not forget that QT pimple object cannot be passed in registers...
> Because he is still a pointer...
The Private class can't, but the outer, public class could be.
Though for Qt, classes that can be passed in registers are rare because most
are either ref-counted or non-copyable and neither of those types can be
passed in registers.
> So, lets take things easy. Let's do not adventure to far, before we did not
> fix simple things. Let's do not optimize before we agreed on basic stuff...
> Would alloca knowing the size from a function or global variable solve the
> problem of sizeof of black?
Yes. if the compiler can do:
ClassName object = otherObject;
It can pass by value.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: mobi phil <mobi@mobiphil.com>
Date: Sat, 21 Feb 2015 12:54:43 +0100
Raw View
--001a113fb70ab7b79d050f97d5cd
Content-Type: text/plain; charset=UTF-8
>
> How many registers do you reserve for the structure if you don't know its
> size? Selecting the registers dynamically means all other parameters would
> be
> dynamically determined, which seems to me to be horribly inefficient.
>
without pretending to be an assembler or code generation guru, I would say
one for the pointer and accept that no such optimisations are possible. If
such optimisations are desired in some cases, then don't use from the
beginnig black/white or move back to normal class at certain moment in the
development when the interface is stable.
> > to have reduced the "impossible" to the handicap of not being able to
> pass
> > in registers. I would love to have time to read your blog and other
> > millions of books, article on the topic.
>
> Well, if you're not going to read up on the subject, how can we discuss the
> subject?
>
My curiosity is there, but not the time unfortunately. Though the devil
often is hidden in details, I would like to know first at "high level" what
are the pitfalls and what are the possibilities. But at this stage we
clarified that both passing by value/reference and pointer would be
possible without knowing the size at compilation time.
If we agree that code-generation-time optimization decision like passing
through registrer depends on sizeof and sizeof is not available, do not see
the point for me to spend lot of time to understand the details.
> > Best is to look at generated code,
> > no blog/book/video/etc. can tell me more than. What I see so far that it
> is
> > feasable. If some mini optimization opportunities are lost, well, you
> > always have to tread sthg. for sthg. else...
>
> How do you think I came up with the content of the blog? By compiling and
> generating code, plus reading the ABI manuals.
>
great. Reading of your post is on my todo. Right now I am busy to finish
this mini project for gdb interface.
> I am personally ok with this little "disadvantage". If I want to hunt for
> > that little piece of cake, then I will move my blacks to the white and
> get
> > it once the project reached a stable phase. I am also thinking about some
> > details on how to move black back if optimization is to be achieved.
>
> Once a black box, always a black box: as you don't know the other side, you
> must assume the other side doesn't have access to the white box.
>
Sorry... did not understand this as a whole, but pb. not important
> > Do not forget that QT pimple object cannot be passed in registers...
> > Because he is still a pointer...
>
> The Private class can't, but the outer, public class could be.
>
Was talking indeed about the private. So far probably there were no serious
complaints about it. And qt is nice and fast.
> Though for Qt, classes that can be passed in registers are rare because
> most
> are either ref-counted or non-copyable and neither of those types can be
> passed in registers.
>
So, I am happy that we both come to the came conclusion. So I should not
worry too much that missing the registers would be a problem in case of
blacks.
> > So, lets take things easy. Let's do not adventure to far, before we did
> not
> > fix simple things. Let's do not optimize before we agreed on basic
> stuff...
> > Would alloca knowing the size from a function or global variable solve
> the
> > problem of sizeof of black?
>
> Yes. if the compiler can do:
>
> ClassName object = otherObject;
>
> It can pass by value.
>
Well, then this topic is rather clear.
What I still need to work out is how private data member access (inside
black) will be expressed (syntax) and implemented. The topic was touched in
earlier emails. It was proposed to use public/private keywords for
black/white and eventually the keyword virtual, for members in white that
are "implemented' in he black. The question is either one should go with :
-> functions or
-> pointers
Manually written or automatically generated (also to be decided) functions
could be inlined at link time (llvm lto, hopefully this technique will
catch-up). This would generate faster code but has the disadvantage that
will not be able to load classes from shared libraries which would be
another advantage of this proposal. Probably both implementations would
make sense, the question is how to make the distinction.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113fb70ab7b79d050f97d5cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">How many registers do you reserve for the struct=
ure if you don't know its<br>
size? Selecting the registers dynamically means all other parameters would =
be<br>
dynamically determined, which seems to me to be horribly inefficient.<br></=
blockquote><div><br></div><div>without pretending to be an assembler or cod=
e generation guru, I would say one for the pointer and accept that no such =
optimisations are possible. If such optimisations are desired in some cases=
, then don't use from the beginnig black/white or move back to normal c=
lass at certain moment in the development when the interface is stable.=C2=
=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">&=
gt; to have reduced the "impossible" to the handicap of not being=
able to pass<br>
> in registers. I would love to have time to read your blog and other<br=
>
> millions of books, article on the topic.<br>
<br>
</span>Well, if you're not going to read up on the subject, how can we =
discuss the<br>
subject?<br></blockquote><div><br></div><div>My curiosity is there, but not=
the time unfortunately. Though the devil often is hidden in details, I wou=
ld like to know first at "high level" what are the pitfalls and w=
hat are the possibilities. But at this stage we clarified that both passing=
by value/reference and pointer would be possible without knowing the size =
at compilation time.<br><br>If we agree that code-generation-time optimizat=
ion decision like passing through registrer depends on sizeof and sizeof is=
not available, do not see the point for me to spend lot of time to underst=
and the details.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
class=3D"">> Best is to look at generated code,<br>
> no blog/book/video/etc. can tell me more than. What I see so far that =
it is<br>
> feasable. If some mini optimization opportunities are lost, well, you<=
br>
> always have to tread sthg. for sthg. else...<br>
<br>
</span>How do you think I came up with the content of the blog? By compilin=
g and<br>
generating code, plus reading the ABI manuals.<br></blockquote><div><br></d=
iv><div>great. Reading of your post is on my todo. Right now I am busy to f=
inish this mini project for gdb interface.<br></div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><span class=3D"">> I am personally ok with this l=
ittle "disadvantage". If I want to hunt for<br>
> that little piece of cake, then I will move my blacks to the white and=
get<br>
> it once the project reached a stable phase. I am also thinking about s=
ome<br>
> details on how to move black back if optimization is to be achieved.<b=
r>
<br>
</span>Once a black box, always a black box: as you don't know the othe=
r side, you<br>
must assume the other side doesn't have access to the white box.<br></b=
lockquote><div>Sorry... did not understand this as a whole, but pb. not imp=
ortant</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"=
">> Do not forget that QT pimple object cannot be passed in registers...=
<br>
> Because he is still a pointer...<br>
<br>
</span>The Private class can't, but the outer, public class could be.<b=
r></blockquote><div>Was talking indeed about the private. So far probably t=
here were no serious complaints about it. And qt is nice and fast.</div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">Though for Qt, classes that ca=
n be passed in registers are rare because most<br>
are either ref-counted or non-copyable and neither of those types can be<br=
>
passed in registers.<br></blockquote><div><br></div><div>So, I am happy tha=
t we both come to the came conclusion. So I should not worry too much that =
missing the registers would be a problem in case of blacks.=C2=A0</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"">> So, lets =
take things easy. Let's do not adventure to far, before we did not<br>
> fix simple things. Let's do not optimize before we agreed on basic=
stuff...<br>
> Would alloca knowing the size from a function or global variable solve=
the<br>
> problem of sizeof of black?<br>
<br>
</span>Yes. if the compiler can do:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ClassName object =3D otherObject;<br>
<br>
It can pass by value.<br></blockquote><div><br></div><div>Well, then this t=
opic is rather clear.</div><div><br></div><div>What I still need to work ou=
t is how private data member access (inside black) will be expressed (synta=
x) and implemented. The topic was touched in earlier emails. It was propose=
d to use public/private keywords for black/white and eventually the keyword=
virtual, for members in white that are "implemented' in he black.=
The question is either one should go with :</div><div><br></div><div>->=
functions or</div><div>-> pointers</div><div><br></div><div>Manually wr=
itten or automatically generated (also to be decided) functions could be in=
lined at link time (llvm lto, hopefully this technique will catch-up). This=
would generate faster code but has the disadvantage that will not be able =
to load classes from shared libraries which would be another advantage of t=
his proposal. Probably both implementations would make sense, the question =
is how to make the distinction.=C2=A0</div><div><br></div><div><br></div><d=
iv><br></div><div><br></div><div><br></div><div><br></div><div>=C2=A0</div>=
</div><br>
</div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113fb70ab7b79d050f97d5cd--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Mon, 23 Feb 2015 23:44:21 +0100
Raw View
> I'm sorry to involve in this way, but could you please state what is/are the
> goals you want to achieve by this suggestion/proposal?
> I haven't read all the posts under this topic, I'll just summarize the goals
> I've noticed:
> 1) separate public interface from internal implementation details
> 2) enable change of internal implementation without the need of
> recompilation code that only uses the public interface of the class/struct.
> Please could you add other goals which I've missed? I'm sorry if I
> completely misunderstood your ideas.
>
> An old way to achieve goals 1&2: abstract interface with pure virtual
> methods:
> // white.h:
> class IWidget {
> public:
> virtual void set(int) = 0;
> virtual int get() const = 0;
> };
>
> // black.h:
> class WidgetImpl : public IWidget {
> public:
> virtual void set(int i) override { x = i; }
> virtual int get() const { return x; }
>
> private:
> int x;
> };
> ... now if you decide to change the implementation of WidgetImpl, there's no
> need to recompile code that uses only IWidget.
anybody is welcome to be involved. Nevertheless your example just
introduces a level the dependency but does note break it. The entity
that will create WidgetImpl will still be dependent on the layout of
the class and you are introducing a parallel hierarchy exactly like
PIMPL. Plus dependency wise this is worst IMHO that PIMLP as the the
code that creates WidgetImpl still depends on WidgetImpl, or you
introduce a third hierarchy of factories.
> I can't imagine setup where this same behavior would be achieved by using non-virtual methods.
Yes, PIMPL does sthg. similar, but not with virtuals but with
delegation. The proposal wants to simplify all this.
Let's consider code using the black/white keywords (I
> might missed the proposed syntax, please correct me if I'm wrong):
> // white.h:
> class white Widget {
> public:
> void set(int i) { setInternal(i); }
> int get() const { return getInternal(); }
> };
>
> // black.h:
> class black Widget {
> private:
> void setInternal(int i) { x = i; }
> int getInternal() const { return getInternal2(); }
>
> private:
> int getInternal2() const { return getInternal3(); }
> int getInternal3() const { return x; }
>
> private:
> int x;
> };
>
> Then let's assume a use of Widget:
> // foo.cpp:
> #include "white.h"
> void foo() {
> Widget w;
> w.set(2);
> std::cout << w.get() << endl;
> }
> ... here I think any reasonable compiler would inline the call of
> Widget::get to just reading directly the private member Widget::x (there is
> no virtual call, no obstacles (if not the black/white keywords)).
Did you check yourself that, or it is pure assumption. Such
assumptions are making discussions more difficult. You are practically
delegating the work to the other side to prove the opposite. The
proposal will contains reccomandation to do such inlining at link time
which in my opinion.
Sorry, I am afraid that the compiler cannot inline something it is not
aware about. When you compile a unit that includes white.h (above) is
not aware about black.h, unless you explicitly include it, which does
not result from your example! How does your foo.cpp know about
black.h? Just magically??
Please verify first your assumptions and come back with a cleaner example.
regards,
mobiphil
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: iskander508@gmail.com
Date: Tue, 24 Feb 2015 11:29:24 -0800 (PST)
Raw View
------=_Part_1974_634285004.1424806164630
Content-Type: multipart/alternative;
boundary="----=_Part_1975_319238520.1424806164630"
------=_Part_1975_319238520.1424806164630
Content-Type: text/plain; charset=UTF-8
>
>
> You're right, I must apologize for my confusion in what compiler and
linker does. The inlining is done in linker, not in compiler, so my
assumption about foo.cpp object file is completely wrong.
As I look at it, this proposal can cause a lot of work to be moved from
compiler to linker. I think it would be interesting to do some benchmarking
if a complete rebuild (compilation and linking) after an implementation
change is much faster then in current design.
If we move a lot of work out of compilation, then it's quite prospective,
that the compilation itself will be faster. -> there's a less difference if
the compilation actually happens or not.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1975_319238520.1424806164630
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br></blockqu=
ote><div>You're right, I must apologize for my confusion in what compiler a=
nd linker does. The inlining is done in linker, not in compiler, so my=
assumption about foo.cpp object file is completely wrong. </div><div>=
<br></div><div>As I look at it, this proposal can cause a lot of work to be=
moved from compiler to linker. I think it would be interesting to do some =
benchmarking if a complete rebuild (compilation and linking) after an imple=
mentation change is much faster then in current design.</div><div>If we mov=
e a lot of work out of compilation, then it's quite prospective, that the c=
ompilation itself will be faster. -> there's a less difference if the co=
mpilation actually happens or not.<br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1975_319238520.1424806164630--
------=_Part_1974_634285004.1424806164630--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Tue, 24 Feb 2015 20:59:20 +0100
Raw View
> You're right, I must apologize for my confusion in what compiler and linker
> does. The inlining is done in linker, not in compiler, so my assumption
> about foo.cpp object file is completely wrong.
As far as I know at the moment there is no inlining done in linker in
legacy compilation. Some new features of llvm lto allows link time
inlineing and the proposal among others will try to build on that
feature.
> As I look at it, this proposal can cause a lot of work to be moved from
> compiler to linker. I think it would be interesting to do some benchmarking
> if a complete rebuild (compilation and linking) after an implementation
> change is much faster then in current design.
Obviously no benchmarking will be possible till it is implemented.
Link time inlining is an option of the proposal, but I assume that the
link time inlining will be faster if it will not have to re-inline for
objects that did not change, so the build system itself will have an
impact on this.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: inkwizytoryankes@gmail.com
Date: Wed, 25 Feb 2015 09:37:20 -0800 (PST)
Raw View
------=_Part_510_1677496713.1424885840860
Content-Type: multipart/alternative;
boundary="----=_Part_511_1521937575.1424885840860"
------=_Part_511_1521937575.1424885840860
Content-Type: text/plain; charset=UTF-8
I think that is possible to benchmark 90% of this functionality today. Only
thing we lack is `sizeof` but this can be work around by using
`std::aligned_storage` that have size margin (you should be able add couple
of new members before you run out of space in it).
Another thing is that on C++ VLA committee reject runtime `sizeof`, do you
think they will allow it in your proposal? Even if we allow it you still
can't add members of that type to another class. Its because every access
of members declared after it will require function call for correct offset.
I think it would be better if we require that "black" declare max size of
"white" part. This will made it a lot of easer to implement (e.g. it will
be possible to do today with lot of boilerplate) and pass committee.
On Tuesday, February 24, 2015 at 8:59:23 PM UTC+1, mobiphil wrote:
>
> > You're right, I must apologize for my confusion in what compiler and
> linker
> > does. The inlining is done in linker, not in compiler, so my assumption
> > about foo.cpp object file is completely wrong.
>
> As far as I know at the moment there is no inlining done in linker in
> legacy compilation. Some new features of llvm lto allows link time
> inlineing and the proposal among others will try to build on that
> feature.
>
> > As I look at it, this proposal can cause a lot of work to be moved from
> > compiler to linker. I think it would be interesting to do some
> benchmarking
> > if a complete rebuild (compilation and linking) after an implementation
> > change is much faster then in current design.
>
> Obviously no benchmarking will be possible till it is implemented.
> Link time inlining is an option of the proposal, but I assume that the
> link time inlining will be faster if it will not have to re-inline for
> objects that did not change, so the build system itself will have an
> impact on this.
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_511_1521937575.1424885840860
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think that is possible to benchmark 90% of this function=
ality today. Only thing we lack is `sizeof` but this can be work around by =
using `std::aligned_storage` that have size margin (you should be able add =
couple of new members before you run out of space in it).<br><br><br>Anothe=
r thing is that on C++ VLA committee reject runtime `sizeof`, do you think =
they will allow it in your proposal? Even if we allow it you still can't ad=
d members of that type to another class. Its because every access of member=
s declared after it will require function call for correct offset.<br>I thi=
nk it would be better if we require that "black" declare max size of "white=
" part. This will made it a lot of easer to implement (e.g. it will be poss=
ible to do today with lot of boilerplate) and pass committee.<br><br>On Tue=
sday, February 24, 2015 at 8:59:23 PM UTC+1, mobiphil wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">> You're right, I must apologize for my co=
nfusion in what compiler and linker
<br>> does. The inlining is done in linker, not in compiler, so my assum=
ption
<br>> about foo.cpp object file is completely wrong.
<br>
<br>As far as I know at the moment there is no inlining done in linker in
<br>legacy compilation. Some new features of llvm lto allows link time
<br>inlineing and the proposal among others will try to build on that
<br>feature.
<br>
<br>> As I look at it, this proposal can cause a lot of work to be moved=
from
<br>> compiler to linker. I think it would be interesting to do some ben=
chmarking
<br>> if a complete rebuild (compilation and linking) after an implement=
ation
<br>> change is much faster then in current design.
<br>
<br>Obviously no benchmarking will be possible till it is implemented.
<br>Link time inlining is an option of the proposal, but I assume that the
<br>link time inlining will be faster if it will not have to re-inline for
<br>objects that did not change, so the build system itself will have an
<br>impact on this.
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_511_1521937575.1424885840860--
------=_Part_510_1677496713.1424885840860--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Wed, 25 Feb 2015 19:19:58 +0100
Raw View
> I think that is possible to benchmark 90% of this functionality today. Only
> thing we lack is `sizeof` but this can be work around by using
> `std::aligned_storage` that have size margin (you should be able add couple
> of new members before you run out of space in it).
sorry, how did you calculate this 90%? And bench marking what exactly?
The design is not yet even ready, we do not know what needs to be
changed in the compilers and linkers. Benchmarking which build? Can
you please make more clear statements?
> Another thing is that on C++ VLA committee reject runtime `sizeof`, do you
> think they will allow it in your proposal?
Did they reject in the past? Do they always reject? You assume they
are going to reject? Can you also pls. be more clear here?
> Even if we allow it you still
> can't add members of that type to another class. Its because every access of
> members declared after it will require function call for correct offset.
Sorry, this one not clear either? You mean function call to get the
offset? If you have the function to get the offset, why would it be a
problem. You are contradicting yourself in the same statement. Another
option to offset function is the link time inlining. Please read
through the thread, you may have some of the questions clarified.
> I think it would be better if we require that "black" declare max size of
> "white" part. This will made it a lot of easer to implement (e.g. it will be
> possible to do today with lot of boilerplate) and pass committee.
Max size is out of question. It is hack, I would personally downwoat
sthg. like that. How would you decide on max size? You will have 300
hundred classes and you will spend 30% of effort in adjusting the max
sizes? That would work in o toy application, but not on giant
projects. Would you just waste memory because design is bad and memory
is cheap?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: inkwizytoryankes@gmail.com
Date: Wed, 25 Feb 2015 11:26:05 -0800 (PST)
Raw View
------=_Part_863_64151477.1424892365804
Content-Type: multipart/alternative;
boundary="----=_Part_864_157083145.1424892365804"
------=_Part_864_157083145.1424892365804
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 25, 2015 at 7:20:03 PM UTC+1, mobiphil wrote:
>
> > I think that is possible to benchmark 90% of this functionality today.
> Only
> > thing we lack is `sizeof` but this can be work around by using
> > `std::aligned_storage` that have size margin (you should be able add
> couple
> > of new members before you run out of space in it).
>
> sorry, how did you calculate this 90%? And bench marking what exactly?
> The design is not yet even ready, we do not know what needs to be
> changed in the compilers and linkers. Benchmarking which build? Can
> you please make more clear statements?
>
> This is approximation, meaning of this was that is possible to recreate
most of this using current tools, but without any syntax support.
> > Another thing is that on C++ VLA committee reject runtime `sizeof`, do
> you
> > think they will allow it in your proposal?
>
> Did they reject in the past? Do they always reject? You assume they
> are going to reject? Can you also pls. be more clear here?
>
> All proposal that didn't have fixed size objects avoided declaring
`sizeof` for them. e.g.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3875.pdf
And I recall some discussion about it, that people form committee didn't
like it.
I tired find link to it but right now I dint find it, maybe someone els
remember this?
> Even if we allow it you still
> > can't add members of that type to another class. Its because every
> access of
> > members declared after it will require function call for correct offset.
>
> Sorry, this one not clear either? You mean function call to get the
> offset? If you have the function to get the offset, why would it be a
> problem. You are contradicting yourself in the same statement. Another
> option to offset function is the link time inlining. Please read
> through the thread, you may have some of the questions clarified.
>
> Consider this classes:
class black A1 { void foo(); };
class black A2 { void foo(); };
class B
{
int i;
A1 a1;
int c;
A2 a2;
int d;
};
int main()
{
B b;
b.c = 5; //require function call to get offset value.
b.d = 3; //2x call for A1 and A2
b.a2.foo();
temp<&B::d> something; //error, this require runtime values.
int i = sizeof(b); //runtime value too
}
> I think it would be better if we require that "black" declare max size of
> > "white" part. This will made it a lot of easer to implement (e.g. it
> will be
> > possible to do today with lot of boilerplate) and pass committee.
>
> Max size is out of question. It is hack, I would personally downwoat
> sthg. like that. How would you decide on max size? You will have 300
> hundred classes and you will spend 30% of effort in adjusting the max
> sizes? That would work in o toy application, but not on giant
> projects. Would you just waste memory because design is bad and memory
> is cheap?
>
No, I'm more concern with complexity of this when another objects depends
on run time size of another object.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_864_157083145.1424892365804
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Wednesday, February 25, 2015 at 7:20:03 PM UTC+1, m=
obiphil wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> I think tha=
t is possible to benchmark 90% of this functionality today. Only
<br>> thing we lack is `sizeof` but this can be work around by using
<br>> `std::aligned_storage` that have size margin (you should be able a=
dd couple
<br>> of new members before you run out of space in it).
<br>
<br>sorry, how did you calculate this 90%? And bench marking what exactly?
<br>The design is not yet even ready, we do not know what needs to be
<br>changed in the compilers and linkers. Benchmarking which build? Can
<br>you please make more clear statements?
<br>
<br></blockquote><div>This is approximation, meaning of this was that is po=
ssible to recreate most of this using current tools, but without any syntax=
support.<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> =
Another thing is that on C++ VLA committee reject runtime `sizeof`, do you
<br>> think they will allow it in your proposal?
<br>
<br>Did they reject in the past? Do they always reject? You assume they
<br>are going to reject? Can you also pls. be more clear here?
<br>
<br></blockquote><div>All proposal that didn't have fixed size objects avoi=
ded declaring `sizeof` for them. e.g.<br>http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2014/n3875.pdf<br>And I recall some discussion about it, t=
hat people form committee didn't like it.<br>I tired find link to it but ri=
ght now I dint find it, maybe someone els remember this?<br><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">> Even if we allow it you still
<br>> can't add members of that type to another class. Its because every=
access of
<br>> members declared after it will require function call for correct o=
ffset.
<br>
<br>Sorry, this one not clear either? You mean function call to get the
<br>offset? If you have the function to get the offset, why would it be a
<br>problem. You are contradicting yourself in the same statement. Another
<br>option to offset function is the link time inlining. Please read
<br>through the thread, you may have some of the questions clarified.
<br>
<br></blockquote><div>Consider this classes:<br><div class=3D"prettyprint" =
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, =
187); border-style: solid; border-width: 1px; word-wrap: break-word;"><code=
class=3D"prettyprint"><div class=3D"subprettyprint"><code class=3D"prettyp=
rint"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> black A1 </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> void foo(); </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></code><code clas=
s=3D"prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bla=
ck A2 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> void foo(); =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></code>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> B<br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> A1 a1</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br> </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br> A2 a2</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> d</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>int ma=
in()<br>{<br> B b;<br> b.c =3D 5; //</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">require funct=
ion call to get offset value.<br> b.d =3D 3; //2x call fo=
r A1 and A2<br> b.a2.foo();<br> temp<=
;&B::d> something; //error, this require runtime values.<br> &n=
bsp; int i =3D sizeof(b);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> //runtime value too<br> }<br><br></span></div></code>=
</div><br> <br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
> I think it would be better if we require that "black" declare max size=
of
<br>> "white" part. This will made it a lot of easer to implement (e.g. =
it will be
<br>> possible to do today with lot of boilerplate) and pass committee.
<br>
<br>Max size is out of question. It is hack, I would personally downwoat
<br>sthg. like that. How would you decide on max size? You will have 300
<br>hundred classes and you will spend 30% of effort in adjusting the max
<br>sizes? That would work in o toy application, but not on giant
<br>projects. Would you just waste memory because design is bad and memory
<br>is cheap?
<br></blockquote><div> No, I'm more concern with complexity of this wh=
en another objects depends on run time size of another object.<br><br></div=
></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_864_157083145.1424892365804--
------=_Part_863_64151477.1424892365804--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Wed, 25 Feb 2015 20:56:51 +0100
Raw View
>> sorry, how did you calculate this 90%? And bench marking what exactly?
>> The design is not yet even ready, we do not know what needs to be
>> changed in the compilers and linkers. Benchmarking which build? Can
>> you please make more clear statements?
>>
> This is approximation, meaning of this was that is possible to recreate most
> of this using current tools, but without any syntax support.
Still not clear what you want to measure. Even if it would be already
implemented you would have hard time to measure. You measure what
against what? Build times would be clearly 1000 times faster if you do
not have to recompile 1000 object files with same complexity each time
you change the definition of a class they are depending on. The same
time you can have a simple build where this will bring zero added
value, more it will be a little bit slower. About runtime performance
difference: there will be to solutions. link time inlining or "runtime
sizeof". The first will be a bit slower to build, the second will be
slower to run. How much slower? dependends on the situation. If you
have 50 times access to the same member inside one function the
compiler is supposed to cache the offset. So the degradation will not
be probaly that significant, but again will depend on the situation.
If getters/setters will be inlined by the linker, I expect almost zero
degradation.
Please define what and how you want to measure.
>> > Another thing is that on C++ VLA committee reject runtime `sizeof`, do
>> > you
>> > think they will allow it in your proposal?
>>
>> Did they reject in the past? Do they always reject? You assume they
>> are going to reject? Can you also pls. be more clear here?
>>
> All proposal that didn't have fixed size objects avoided declaring `sizeof`
> for them. e.g.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3875.pdf
> And I recall some discussion about it, that people form committee didn't
> like it.
> I tired find link to it but right now I dint find it, maybe someone els
> remember this?
Please do not confuse with some proposals that had as object
dynamically growing objects or anything in that direction. In this
proposal the size is not known at compile time, but it will not change
at runtime. The proposal however keeps it open dynamically loaded
classes and in that case offset and size have to be dynamic.
>> > Even if we allow it you still
>> > can't add members of that type to another class. Its because every
>> > access of
>> > members declared after it will require function call for correct offset.
>>
>> Sorry, this one not clear either? You mean function call to get the
>> offset? If you have the function to get the offset, why would it be a
>> problem. You are contradicting yourself in the same statement. Another
>> option to offset function is the link time inlining. Please read
>> through the thread, you may have some of the questions clarified.
>>
> Consider this classes:
> class black A1 { void foo(); };
> class black A2 { void foo(); };
>
>
> class B
> {
> int i;
> A1 a1;
> int c;
> A2 a2;
> int d;
> };
>
> int main()
> {
> B b;
> b.c = 5; //require function call to get offset value.
> b.d = 3; //2x call for A1 and A2
> b.a2.foo();
> temp<&B::d> something; //error, this require runtime values.
> int i = sizeof(b); //runtime value too
> }
Did you think how you would implement sizeof at runtime? Without being
a compiler or assembler guru, I see three solutions (all these details
were described already in this thread):
1. having the linker going through all the generated code and replace
occurences of some "markers" with the sizeof available at link time
from the black
2. indirect reference. The sizeof would be an offset in a global table
that is arranged by the dynamic loader
3. with function()
The same applies to offsets
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: inkwizytoryankes@gmail.com
Date: Thu, 26 Feb 2015 13:08:36 -0800 (PST)
Raw View
------=_Part_102_2074902638.1424984916618
Content-Type: multipart/alternative;
boundary="----=_Part_103_2049176880.1424984916618"
------=_Part_103_2049176880.1424984916618
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 25, 2015 at 8:56:53 PM UTC+1, mobiphil wrote:
>
> >> sorry, how did you calculate this 90%? And bench marking what exactly?
> >> The design is not yet even ready, we do not know what needs to be
> >> changed in the compilers and linkers. Benchmarking which build? Can
> >> you please make more clear statements?
> >>
> > This is approximation, meaning of this was that is possible to recreate
> most
> > of this using current tools, but without any syntax support.
>
> Still not clear what you want to measure. Even if it would be already
> implemented you would have hard time to measure. You measure what
> against what? Build times would be clearly 1000 times faster if you do
> not have to recompile 1000 object files with same complexity each time
> you change the definition of a class they are depending on. The same
> time you can have a simple build where this will bring zero added
> value, more it will be a little bit slower. About runtime performance
> difference: there will be to solutions. link time inlining or "runtime
> sizeof". The first will be a bit slower to build, the second will be
> slower to run. How much slower? dependends on the situation. If you
> have 50 times access to the same member inside one function the
> compiler is supposed to cache the offset. So the degradation will not
> be probaly that significant, but again will depend on the situation.
> If getters/setters will be inlined by the linker, I expect almost zero
> degradation.
>
> Please define what and how you want to measure.
>
>
I see I miss your point, because I think of runtime benchmarking for the
whole time.
> >> > Another thing is that on C++ VLA committee reject runtime `sizeof`,
> do
> >> > you
> >> > think they will allow it in your proposal?
> >>
> >> Did they reject in the past? Do they always reject? You assume they
> >> are going to reject? Can you also pls. be more clear here?
> >>
>
> > All proposal that didn't have fixed size objects avoided declaring
> `sizeof`
> > for them. e.g.
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3875.pdf
> > And I recall some discussion about it, that people form committee didn't
> > like it.
> > I tired find link to it but right now I dint find it, maybe someone els
> > remember this?
>
> Please do not confuse with some proposals that had as object
> dynamically growing objects or anything in that direction. In this
> proposal the size is not known at compile time, but it will not change
> at runtime. The proposal however keeps it open dynamically loaded
> classes and in that case offset and size have to be dynamic.
>
>
But in both behavior of `sizeof` will change. Probably biggest problem will
be using it in metaprograming simple code like that: `test<(sizeof(x) >
4)>`.
> >> Sorry, this one not clear either? You mean function call to get the
> >> offset? If you have the function to get the offset, why would it be a
> >> problem. You are contradicting yourself in the same statement. Another
> >> option to offset function is the link time inlining. Please read
> >> through the thread, you may have some of the questions clarified.
> >>
> > Consider this classes:
> > class black A1 { void foo(); };
> > class black A2 { void foo(); };
> >
> >
> > class B
> > {
> > int i;
> > A1 a1;
> > int c;
> > A2 a2;
> > int d;
> > };
> >
> > int main()
> > {
> > B b;
> > b.c = 5; //require function call to get offset value.
> > b.d = 3; //2x call for A1 and A2
> > b.a2.foo();
> > temp<&B::d> something; //error, this require runtime values.
> > int i = sizeof(b); //runtime value too
> > }
>
> Did you think how you would implement sizeof at runtime? Without being
> a compiler or assembler guru, I see three solutions (all these details
> were described already in this thread):
>
> 1. having the linker going through all the generated code and replace
> occurences of some "markers" with the sizeof available at link time
> from the black
> 2. indirect reference. The sizeof would be an offset in a global table
> that is arranged by the dynamic loader
> 3. with function()
>
> The same applies to offsets
>
I think only first one is good for this. But "markers" will probably don't
work, because multiple black can affect one `sizeof`.
Probably more possible implementation would be list of instruction address
that need added value of black size to const operand.
Second have two problems, one that require constant keeping this table in
cache when you use black objects another is that all offset instruction
will require couple step to calculate final offset.
Third one will probably not pass because of overhead compared to accessing
meber by const offset. Its posible to store value, but it will be
recalculated for each new context.
And if it done properly it probably end up as second point.
Overall most of my concerns could be avoided by first implementation, but
template problem is unfixable.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_103_2049176880.1424984916618
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, February 25, 2015 at 8:56:53 PM UTC+=
1, mobiphil wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">>> sor=
ry, how did you calculate this 90%? And bench marking what exactly?
<br>>> The design is not yet even ready, we do not know what needs to=
be
<br>>> changed in the compilers and linkers. Benchmarking which build=
? Can
<br>>> you please make more clear statements?
<br>>>
<br>> This is approximation, meaning of this was that is possible to rec=
reate most
<br>> of this using current tools, but without any syntax support.
<br>
<br>Still not clear what you want to measure. Even if it would be already
<br>implemented you would have hard time to measure. You measure what
<br>against what? Build times would be clearly 1000 times faster if you do
<br>not have to recompile 1000 object files with same complexity each time
<br>you change the definition of a class they are depending on. The same
<br>time you can have a simple build where this will bring zero added
<br>value, more it will be a little bit slower. About runtime performance
<br>difference: there will be to solutions. link time inlining or "runtime
<br>sizeof". The first will be a bit slower to build, the second will be
<br>slower to run. How much slower? dependends on the situation. If you
<br>have 50 times access to the same member inside one function the
<br>compiler is supposed to cache the offset. So the degradation will not
<br>be probaly that significant, but again will depend on the situation.
<br>If getters/setters will be inlined by the linker, I expect almost zero
<br>degradation.
<br>
<br>Please define what and how you want to measure.
<br>
<br></blockquote><div> <br> I see I miss your point, because I th=
ink of runtime benchmarking for the whole time.<br></div><div> </div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">>> > Another thing is =
that on C++ VLA committee reject runtime `sizeof`, do
<br>>> > you
<br>>> > think they will allow it in your proposal?
<br>>>
<br>>> Did they reject in the past? Do they always reject? You assume=
they
<br>>> are going to reject? Can you also pls. be more clear here?
<br>>>
<br>
<br>> All proposal that didn't have fixed size objects avoided declaring=
`sizeof`
<br>> for them. e.g.
<br>> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014=
/n3875.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2=
Fwg21%2Fdocs%2Fpapers%2F2014%2Fn3875.pdf\46sa\75D\46sntz\0751\46usg\75AFQjC=
NEChopvKzokcBuvG1_MNQPv6MEtFA';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%=
2Fdocs%2Fpapers%2F2014%2Fn3875.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEChop=
vKzokcBuvG1_MNQPv6MEtFA';return true;">http://www.open-std.org/jtc1/<wbr>sc=
22/wg21/docs/papers/2014/<wbr>n3875.pdf</a>
<br>> And I recall some discussion about it, that people form committee =
didn't
<br>> like it.
<br>> I tired find link to it but right now I dint find it, maybe someon=
e els
<br>> remember this?
<br>
<br>Please do not confuse with some proposals that had as object
<br>dynamically growing objects or anything in that direction. In this
<br>proposal the size is not known at compile time, but it will not change
<br>at runtime. The proposal however keeps it open dynamically loaded
<br>classes and in that case offset and size have to be dynamic.
<br>
<br></blockquote><div><br>But in both behavior of `sizeof` will change. Pro=
bably biggest problem will be using it in metaprograming simple code like t=
hat: `test<(sizeof(x) > 4)>`. <br></div><div> </div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;">>> Sorry, this one not clear eith=
er? You mean function call to get the
<br>>> offset? If you have the function to get the offset, why would =
it be a
<br>>> problem. You are contradicting yourself in the same statement.=
Another
<br>>> option to offset function is the link time inlining. Please re=
ad
<br>>> through the thread, you may have some of the questions clarifi=
ed.
<br>>>
<br>> Consider this classes:
<br>> class black A1 { void foo(); };
<br>> class black A2 { void foo(); };
<br>>
<br>>
<br>> class B
<br>> {
<br>> int i;
<br>> A1 a1;
<br>> int c;
<br>> A2 a2;
<br>> int d;
<br>> };
<br>>
<br>> int main()
<br>> {
<br>> B b;
<br>> b.c =3D 5; //require function call to get offset val=
ue.
<br>> b.d =3D 3; //2x call for A1 and A2
<br>> b.a2.foo();
<br>> temp<&B::d> something; //error, this requi=
re runtime values.
<br>> int i =3D sizeof(b); //runtime value too
<br>> }
<br>
<br>Did you think how you would implement sizeof at runtime? Without being
<br>a compiler or assembler guru, I see three solutions (all these details
<br>were described already in this thread):
<br>
<br>1. having the linker going through all the generated code and replace
<br>occurences of some "markers" with the sizeof available at link time
<br>from the black
<br>2. indirect reference. The sizeof would be an offset in a global table
<br>that is arranged by the dynamic loader
<br>3. with function()
<br>
<br>The same applies to offsets
<br></blockquote><div><br>I think only first one is good for this. But "mar=
kers" will probably don't work, because multiple black can affect one `size=
of`.<br>Probably more possible implementation would be list of instruction =
address that need added value of black size to const operand.<br><br>Second=
have two problems, one that require constant keeping this table in cache w=
hen you use black objects another is that all offset instruction will requi=
re couple step to calculate final offset.<br><br>Third one will probably no=
t pass because of overhead compared to accessing meber by const offset. Its=
posible to store value, but it will be recalculated for each new context.<=
br>And if it done properly it probably end up as second point.<br><br>Overa=
ll most of my concerns could be avoided by first implementation, but templa=
te problem is unfixable.<br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_103_2049176880.1424984916618--
------=_Part_102_2074902638.1424984916618--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Thu, 26 Feb 2015 23:31:47 +0100
Raw View
> I see I miss your point, because I think of runtime benchmarking for the
> whole time.
Even if we talk about runtime bench-marking, the measurement would be
complex. You cannot measure without defining the problem space. If you
have suggestions, please define what you would like to measure. Just
throwing in numbers and random ideas does not help.
> But in both behavior of `sizeof` will change. Probably biggest problem will
> be using it in metaprograming simple code like that: `test<(sizeof(x) >
> 4)>`.
May I kindly ask you to go through all emails. This problem was
already addressed. The proposal does not intend to replace all the
usage of all the classes in all the templates in all the world. There
are classes that do not provide other kind of protocols that make them
unusable in thousands of other templates. The proposal will not
satisfy the interface for sizeof at compiltime and with that this part
of topic is closed.
>> 1. having the linker going through all the generated code and replace
>> occurences of some "markers" with the sizeof available at link time
>> from the black
>> 2. indirect reference. The sizeof would be an offset in a global table
>> that is arranged by the dynamic loader
>> 3. with function()
>>
>> The same applies to offsets
>
>
> I think only first one is good for this. But "markers" will probably don't
> work, because multiple black can affect one `sizeof`.
> Probably more possible implementation would be list of instruction address
> that need added value of black size to const operand.
>
> Second have two problems, one that require constant keeping this table in
> cache when you use black objects another is that all offset instruction will
> require couple step to calculate final offset.
> Third one will probably not pass because of overhead compared to accessing
> meber by const offset. Its posible to store value, but it will be
> recalculated for each new context.
> And if it done properly it probably end up as second point.
>
> Overall most of my concerns could be avoided by first implementation, but
> template problem is unfixable.
did you ever heard of the term trading something against something?
Did you hear about the theory of relativity? If you get something then
often you have to give up something else. So it is with this proposal!
It does not pretend to make the word much better. It wants to be a
solution for a certain problem. During development if one realises
that the black/white means serious performance, it should be possible
to make the black/white into an original class
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.