Topic: Forward declaring names
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Sat, 10 May 2014 00:15:52 +0200
Raw View
Hello.
One thing that have annoyed me for a while is that I can't declare that a
name refers to a type unless I know if the name is a class-name or a
typedef-name when all I want to say is that the name is something I can form
a pointer or a reference to.
I can say
class foo;
void f1(foo&);
and I can also say
using bar = int;
void f2(bar&);
but I lack the ability to say
<typename or something> gaz;
void f3(gaz&);
where all that I tell the compiler is that gaz is a type, but don't have to
say if it is a typedef-name or a class-name.
Now, I do understand the reason for this since f2(bar&) should mangle like
f2(int&) so this suggests some kind of "strong" typedef that introduces a
new name for an existing type, and this is also an often requested feature.
Would it be feasible to introduce a strong typedef in order to allow general
forward declaration of types, or is this an utterly stupid idea?
The strong typedef should introduce a new type and place it in the same
namespace as class-names.
So the proposal is something along the lines of
// Declare two types, say nothing of what they contain
strong typedef aType;
strong typedef aClass;
// Actually define the types
strong typedef int aType; // possibly allow ommitting strong here?
class aClass { };
/MF
--
---
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: David Krauss <potswa@gmail.com>
Date: Sat, 10 May 2014 13:41:59 +0800
Raw View
--Apple-Mail=_70F7F4C1-FDA6-43DC-8948-6B9C099361A3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-05-10, at 6:15 AM, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> The strong typedef should introduce a new type and place it in the same
> namespace as class-names.
Is your intent to "bite off" a piece of the strong typedef proposal and imp=
lement it in anticipation of a more complete feature?
> So the proposal is something along the lines of
>=20
> // Declare two types, say nothing of what they contain
>=20
> strong typedef aType;
> strong typedef aClass;
>=20
> // Actually define the types
>=20
> strong typedef int aType; // possibly allow ommitting strong here?
> class aClass { };
I don't think transforming a typedef-name to a class-name should be allowed=
; you would need
strong typedef class aClass_class {
...
} aClass;
I suspect your problem may be solved with metaprogramming, namely a templat=
e alias mapping from a set of tag classes ("strong typedef-names") to a set=
of mapped types (which may or may not be classes) via a set of explicit sp=
ecializations ("strong typedef declarations"). If that's too much, simply o=
rganizing the forward declarations might do.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_70F7F4C1-FDA6-43DC-8948-6B9C099361A3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;05–10, at 6:15 AM, Magnus Fromreide <<a href=3D"mailto:magfr=
@lysator.liu.se">magfr@lysator.liu.se</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><blockquote type=3D"cite">The strong typedef should =
introduce a new type and place it in the same<br>namespace as class-names.<=
br></blockquote><div><br></div><div>Is your intent to “bite off&rdquo=
; a piece of the strong typedef proposal and implement it in anticipation o=
f a more complete feature?</div><br><blockquote type=3D"cite">So the propos=
al is something along the lines of<br><br>// Declare two types, say nothing=
of what they contain<br><br>strong typedef aType;<br>strong typedef aClass=
;<br><br>// Actually define the types<br><br>strong typedef int aType; // p=
ossibly allow ommitting strong here?<br>class aClass { };<br></blockquote><=
div><br></div><div>I don’t think transforming a typedef-name to a cla=
ss-name should be allowed; you would need</div><div><br></div><div><font fa=
ce=3D"Courier">strong typedef class aClass_class {</font></div><div><font f=
ace=3D"Courier"> …</font></div><div><font face=3D"Couri=
er">} aClass;</font></div></div><br><div><br></div><div>I suspect your prob=
lem may be solved with metaprogramming, namely a template alias mapping fro=
m a set of tag classes (“strong typedef-names”) to a set of map=
ped types (which may or may not be classes) via a set of explicit specializ=
ations (“strong typedef declarations”). If that’s too muc=
h, simply organizing the forward declarations might do.</div><div><br></div=
></body></html>
<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 />
--Apple-Mail=_70F7F4C1-FDA6-43DC-8948-6B9C099361A3--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Sat, 10 May 2014 18:41:34 +0200
Raw View
On Sat, May 10, 2014 at 01:41:59PM +0800, David Krauss wrote:
>
> On 2014-05-10, at 6:15 AM, Magnus Fromreide <magfr@lysator.liu.se> wrote:
>
> > The strong typedef should introduce a new type and place it in the same
> > namespace as class-names.
>
> Is your intent to "bite off" a piece of the strong typedef proposal and
> implement it in anticipation of a more complete feature?
Not really - I was edging for the ability to forward declare the strong
typedef and n3741 explicitly forbids that.
> > So the proposal is something along the lines of
> >
> > // Declare two types, say nothing of what they contain
> >
> > strong typedef aType;
> > strong typedef aClass;
> >
> > // Actually define the types
> >
> > strong typedef int aType; // possibly allow ommitting strong here?
> > class aClass { };
>
> I don't think transforming a typedef-name to a class-name should be allowed;
> you would need
>
> strong typedef class aClass_class {
> ...
> } aClass;
Fair enough.
> I suspect your problem may be solved with metaprogramming, namely a
> template alias mapping from a set of tag classes ("strong typedef-names")
> to a set of mapped types (which may or may not be classes) via a set of
> explicit specializations ("strong typedef declarations"). If that's too
> much, simply organizing the forward declarations might do.
I also suspect that it could be done using template metaprogramming but that
have a tendency to end up beeing more complex than the original problem.
What I wanted to solve was to make it possible to say that 'aType' refers to
a type, but it is not yet specified which type it is.
I suppose this one could go in as an extension of n3741 but then the problem
is that the proposed syntax of n3741 prevents forward declaration of typedefs.
/MF
--
---
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: Jean-Marc Bourguet <jm.bourguet@gmail.com>
Date: Sat, 10 May 2014 11:06:30 -0700 (PDT)
Raw View
------=_Part_5_8674420.1399745190674
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le samedi 10 mai 2014 18:41:34 UTC+2, Magnus Fromreide a =C3=A9crit :
One issue you don't seem to be aware of, if that to be useful, forward=20
declarations of typedef implies that all pointers have the same=20
representation. That's not the case currently for fundamental types. That=
=20
possibility has been used in C compilers for word addressable machines=20
(people tend to forget the importance of such machines at the time C was=20
developed, C was designed on a PDP-11, but the first ports were for the=20
IBM360 and the Honeywell 635 -- word addressable, 36 bits words, 9 bits=20
byte, but it was 2's complement). I don't know of a C++ implementation=20
using the possibility -- my impression is that nowadays implementers prefer=
=20
to use a char which has the word system on such systems -- but that's an=20
area where C++ usually keep the C model.
Yours,
--=20
Jean-Marc
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_5_8674420.1399745190674
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le samedi 10 mai 2014 18:41:34 UTC+2, Magnus Fromreide a =
=C3=A9crit :<br><br>One issue you don't seem to be aware of, if that t=
o be useful, forward declarations of typedef implies that all pointers have=
the same representation. That's not the case currently for fundamental typ=
es. That possibility has been used in C compilers for word addressabl=
e machines (people tend to forget the importance of such machines at the ti=
me C was developed, C was designed on a PDP-11, but the first ports were fo=
r the IBM360 and the Honeywell 635 -- word addressable, 36 bits words=
, 9 bits byte, but it was 2's complement). I don't know of a C++ implementa=
tion using the possibility -- my impression is that nowadays implementers p=
refer to use a char which has the word system on such systems -- but that's=
an area where C++ usually keep the C model.<br><br>Yours,<br><br>-- <br>Je=
an-Marc<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_5_8674420.1399745190674--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Sat, 10 May 2014 20:56:07 +0200
Raw View
On Sat, May 10, 2014 at 11:06:30AM -0700, Jean-Marc Bourguet wrote:
> Le samedi 10 mai 2014 18:41:34 UTC+2, Magnus Fromreide a =E9crit :
>=20
> One issue you don't seem to be aware of, if that to be useful, forward=20
> declarations of typedef implies that all pointers have the same=20
> representation. That's not the case currently for fundamental types.
Yes, you are right, and there are also function and member pointers for mor=
e
recent odd pointers so that kills the idea rather nicely.
Thanks.
/MF
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Stack Machine <stackmachine@hotmail.com>
Date: Fri, 16 May 2014 14:41:22 -0700 (PDT)
Raw View
------=_Part_673_12554989.1400276483106
Content-Type: text/plain; charset=UTF-8
Forward declarations are a stupid idea to begin with and should not be
expanded on. The solution to this should be Modules.
--
---
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_673_12554989.1400276483106
Content-Type: text/html; charset=UTF-8
<div dir="ltr">Forward declarations are a stupid idea to begin with and should not be expanded on. The solution to this should be Modules.<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_673_12554989.1400276483106--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 16 May 2014 15:36:44 -0700
Raw View
--bcaec547c49b52dff104f98c0cf9
Content-Type: text/plain; charset=UTF-8
On Fri, May 16, 2014 at 2:41 PM, Stack Machine <stackmachine@hotmail.com>wrote:
> Forward declarations are a stupid idea to begin with and should not be
> expanded on. The solution to this should be Modules.
>
I generally agree, but with just a pinch of caution: forward declarations
serve two purposes: reducing include dependencies and breaking cycles.
Modules only helps with the first problem; we still need forward
declarations for the second problem.
--
---
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/.
--bcaec547c49b52dff104f98c0cf9
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">On F=
ri, May 16, 2014 at 2:41 PM, Stack Machine <span dir=3D"ltr"><<a href=3D=
"mailto:stackmachine@hotmail.com" target=3D"_blank">stackmachine@hotmail.co=
m</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Forward declarations are a =
stupid idea to begin with and should not be expanded on. The solution to th=
is should be Modules.</div>
</blockquote><div><br></div><div>I generally agree, but with just a pinch o=
f caution: forward declarations serve two purposes: reducing include depend=
encies and breaking cycles. Modules only helps with the first problem; we s=
till need forward declarations for the second problem.</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 />
--bcaec547c49b52dff104f98c0cf9--
.
Author: gmisocpp@gmail.com
Date: Fri, 16 May 2014 16:16:17 -0700 (PDT)
Raw View
------=_Part_1178_1030324.1400282177354
Content-Type: text/plain; charset=UTF-8
On Saturday, May 17, 2014 10:36:44 AM UTC+12, Richard Smith wrote:
>
> On Fri, May 16, 2014 at 2:41 PM, Stack Machine <stackm...@hotmail.com<javascript:>
> > wrote:
>
>> Forward declarations are a stupid idea to begin with and should not be
>> expanded on. The solution to this should be Modules.
>>
>
> I generally agree, but with just a pinch of caution: forward declarations
> serve two purposes: reducing include dependencies and breaking cycles.
> Modules only helps with the first problem; we still need forward
> declarations for the second problem.
>
How about:
auto HANDLE;
void (HANDLE& x);
Meaning: "Hey compiler HANDLE might be a class, struct, typedef, or
whatever, but if you don't need to know, just go with it knowing it's not a
spelling mistake."
Is that what the OP wanted, and would it work?
--
---
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_1178_1030324.1400282177354
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Saturday, May 17, 2014 10:36:44 AM UTC+12, Richard =
Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Fri, May 16, 2014 at 2:41 PM, Stack Machine <span dir=
=3D"ltr"><<a onmousedown=3D"this.href=3D'javascript:';return true;" oncl=
ick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"lsoDjKnicDYJ">stackm...@hotmail.com</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div dir=3D"ltr">Forward declarations are a st=
upid idea to begin with and should not be expanded on. The solution to this=
should be Modules.</div>
</blockquote><div><br></div><div>I generally agree, but with just a pinch o=
f caution: forward declarations serve two purposes: reducing include depend=
encies and breaking cycles. Modules only helps with the first problem; we s=
till need forward declarations for the second problem.</div></div></div></d=
iv></blockquote><div><br></div><div>How about:</div><div><br></div><div>aut=
o HANDLE;</div><div>void (HANDLE& x); </div><div><br></div><d=
iv><div>Meaning: "Hey compiler HANDLE might be a class, stru=
ct, typedef, or whatever, but if you don't need to know, just go with =
it knowing it's not a spelling mistake."</div><div><br></div><div>Is that w=
hat the OP wanted, and would it work?</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_1178_1030324.1400282177354--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 16 May 2014 16:37:23 -0700
Raw View
--047d7b6dc67a3bc16204f98ce5bd
Content-Type: text/plain; charset=UTF-8
On Fri, May 16, 2014 at 4:16 PM, <gmisocpp@gmail.com> wrote:
>
> On Saturday, May 17, 2014 10:36:44 AM UTC+12, Richard Smith wrote:
>
>> On Fri, May 16, 2014 at 2:41 PM, Stack Machine <stackm...@hotmail.com>wrote:
>>
>>> Forward declarations are a stupid idea to begin with and should not be
>>> expanded on. The solution to this should be Modules.
>>>
>>
>> I generally agree, but with just a pinch of caution: forward declarations
>> serve two purposes: reducing include dependencies and breaking cycles.
>> Modules only helps with the first problem; we still need forward
>> declarations for the second problem.
>>
>
> How about:
>
> auto HANDLE;
>
Something like 'typename HANDLE;' would probably be more appropriate, since
this is a type, not a variable.
void (HANDLE& x);
>
> Meaning: "Hey compiler HANDLE might be a class, struct, typedef, or
> whatever, but if you don't need to know, just go with it knowing it's not a
> spelling mistake."
>
> Is that what the OP wanted, and would it work?
>
I can't answer the first half of this question =)
Yes, this could work, but the type would need to be properly-declared
before you could define or call this function, so it's not clear to me how
useful this would be. (This level of opaqueness goes beyond being a merely
incomplete type, since you don't even know how to represent a pointer or
reference to the type.)
--
---
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/.
--047d7b6dc67a3bc16204f98ce5bd
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">On F=
ri, May 16, 2014 at 4:16 PM, <span dir=3D"ltr"><<a href=3D"mailto:gmiso=
cpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>></span> wrote:<b=
r><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>On Saturday, May 17, 2014 10:36:44 AM UTC+12, Richard =
Smith wrote:<div class=3D""><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, May 16, 2014 at 2:=
41 PM, Stack Machine <span dir=3D"ltr"><<a>stackm...@hotmail.com</a>>=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">Forward declarations are a stupid idea to=
begin with and should not be expanded on. The solution to this should be M=
odules.</div>
</blockquote><div><br></div><div>I generally agree, but with just a pinch o=
f caution: forward declarations serve two purposes: reducing include depend=
encies and breaking cycles. Modules only helps with the first problem; we s=
till need forward declarations for the second problem.</div>
</div></div></div></blockquote><div><br></div></div><div>How about:</div><d=
iv><br></div><div>auto HANDLE;</div></div></blockquote><div><br></div><div>=
Something like 'typename HANDLE;' would probably be more appropriat=
e, since this is a type, not a variable.</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"><div>void (H=
ANDLE&=C2=A0x);=C2=A0</div><div><br></div><div><div>Meaning: "Hey =
compiler=C2=A0HANDLE=C2=A0might be=C2=A0a class, struct, typedef, or whatev=
er, but=C2=A0if you don't need to know, just go with it knowing it'=
s not a spelling mistake."</div>
<div><br></div><div>Is that what the OP wanted, and would it work?</div></d=
iv></div></blockquote><div><br></div><div>I can't answer the first half=
of this question =3D)</div><div><br></div><div>Yes, this could work, but t=
he type would need to be properly-declared before you could define or call =
this function, so it's not clear to me how useful this would be. (This =
level of opaqueness goes beyond being a merely incomplete type, since you d=
on't even know how to represent a pointer or reference to the type.)</d=
iv>
</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 />
--047d7b6dc67a3bc16204f98ce5bd--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Sat, 17 May 2014 03:22:29 +0200
Raw View
On Fri, May 16, 2014 at 04:16:17PM -0700, gmisocpp@gmail.com wrote:
>
> On Saturday, May 17, 2014 10:36:44 AM UTC+12, Richard Smith wrote:
> >
> > On Fri, May 16, 2014 at 2:41 PM, Stack Machine <stackm...@hotmail.com<javascript:>
> > > wrote:
> >
> >> Forward declarations are a stupid idea to begin with and should not be
> >> expanded on. The solution to this should be Modules.
> >>
> >
> > I generally agree, but with just a pinch of caution: forward declarations
> > serve two purposes: reducing include dependencies and breaking cycles.
> > Modules only helps with the first problem; we still need forward
> > declarations for the second problem.
> >
>
> How about:
>
> auto HANDLE;
> void (HANDLE& x);
>
> Meaning: "Hey compiler HANDLE might be a class, struct, typedef, or
> whatever, but if you don't need to know, just go with it knowing it's not a
> spelling mistake."
>
> Is that what the OP wanted,
Yes.
> and would it work?
No - see the original thread. Some pointers and references ain't like other
pointers and references. Examples include member pointers.
/MF
--
---
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: Thiago Macieira <thiago@macieira.org>
Date: Fri, 16 May 2014 19:27:03 -0700
Raw View
Em sex 16 maio 2014, =E0s 16:16:17, gmisocpp@gmail.com escreveu:
> How about:
>=20
> auto HANDLE;
> void (HANDLE& x);=20
>=20
> Meaning: "Hey compiler HANDLE might be a class, struct, typedef, or=20
> whatever, but if you don't need to know, just go with it knowing it's not=
a=20
> spelling mistake."
>=20
> Is that what the OP wanted, and would it work?
Can you enumerate what those cases "without knowing" you'd like the standar=
d=20
to support?
You can rule out:
- calling a function taking HANDLE by value, by pointer or by reference
- using HANDLE in a template parameter
- declaring a variable of type cv-qualified HANDLE, HANDLE* or HANDLE&
- using HANDLE in a structure
What's left?
--=20
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
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: gmisocpp@gmail.com
Date: Sat, 17 May 2014 20:01:44 -0700 (PDT)
Raw View
------=_Part_66_17844243.1400382104409
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi
On Saturday, May 17, 2014 2:27:03 PM UTC+12, Thiago Macieira wrote:
>
> Em sex 16 maio 2014, =C3=A0s 16:16:17, gmis...@gmail.com <javascript:>esc=
reveu:=20
> > How about:=20
> >=20
> > auto HANDLE;=20
> > void (HANDLE& x);=20
> >=20
> > Meaning: "Hey compiler HANDLE might be a class, struct, typedef, or=20
> > whatever, but if you don't need to know, just go with it knowing it's=
=20
> not a=20
> > spelling mistake."=20
> >=20
> > Is that what the OP wanted, and would it work?=20
>
> Can you enumerate what those cases "without knowing" you'd like the=20
> standard=20
> to support?=20
>
I'm not sure, that's why I was asking would it work. I was just querying if=
=20
that was the kind of open declaration the OP was looking for.
You can rule out:=20
- calling a function taking HANDLE by value, by pointer or by reference=20
- using HANDLE in a template parameter=20
- declaring a variable of type cv-qualified HANDLE, HANDLE* or HANDLE&=20
- using HANDLE in a structure=20
What's left?=20
I don't see that anything is left. I have sometimes wanted to say "hey I=20
don't know if this is a "struct or a class name, but this is a pointer=20
or reference to that". But that was being lazy. It seems the goal of the OP=
=20
was something like that.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
Software Architect - Intel Open Source Technology Center=20
PGP/GPG: 0x6EF45358; fingerprint:=20
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_66_17844243.1400382104409
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi<br><br>On Saturday, May 17, 2014 2:27:03 PM UTC+12, Thi=
ago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">Em sex 16 maio 2014, =C3=A0=
s 16:16:17, <a onmousedown=3D"this.href=3D'javascript:';return true;" oncli=
ck=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"BSmveGxeBN4J">gmis...@gmail.com</a> es=
creveu:
<br>> How about:
<br>>=20
<br>> auto HANDLE;
<br>> void (HANDLE& x);=20
<br>>=20
<br>> Meaning: "Hey compiler HANDLE might be a class, struct, typedef, o=
r=20
<br>> whatever, but if you don't need to know, just go with it knowing i=
t's not a=20
<br>> spelling mistake."
<br>>=20
<br>> Is that what the OP wanted, and would it work?
<br>
<br>Can you enumerate what those cases "without knowing" you'd like the sta=
ndard=20
<br>to support?
<br></blockquote><div><br></div><div>I'm not sure, that's why I was as=
king would it work. I was just querying if that was the kind of open d=
eclaration the OP was looking for.</div><div>
<br>You can rule out:
<br> - calling a function taking HANDLE by value, by pointer or by ref=
erence
<br> - using HANDLE in a template parameter
<br> - declaring a variable of type cv-qualified HANDLE, HANDLE* or HA=
NDLE&
<br> - using HANDLE in a structure
<br>
<br>What's left?
</div><div><br></div><div>I don't see that anything is left. I have so=
metimes wanted to say "hey I don't know if this is a "struct or a class nam=
e, but this is a pointer or reference to that". But that was bein=
g lazy. It seems the goal of the OP was something like that.</div><div><br>=
</div><div><br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\07=
51\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" href=3D"http:/=
/macieira.info" target=3D"_blank">macieira.info</a> - thiago (AT) <a onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org\46=
sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;=
" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.or=
g\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return t=
rue;" href=3D"http://kde.org" target=3D"_blank">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<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_66_17844243.1400382104409--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Sun, 18 May 2014 17:47:22 +0430
Raw View
--f46d044402f4d79d5904f9ac78a9
Content-Type: text/plain; charset=UTF-8
2014-05-10 23:26 GMT+04:30 Magnus Fromreide <magfr@lysator.liu.se>:
> Yes, you are right, and there are also function and member pointers for
> more
> recent odd pointers so that kills the idea rather nicely.
>
I should respectfully object that this one is irrelevant. Normal pointers
have the same size and representation - regarding the compilation platform.
And they are implicitly statically cast-able to void*; static_cast back
from this result to the original type is also well-defined behavior.
In contrast to normal pointers, member pointers have diverse sizes and
representations even on the same platform -regarding their type. These
types are not statically cast-able to void* and casting from void* to such
types is Undefined-Behavior.
In short words : the only common feature between member pointers and normal
pointers is the term pointer while they are 2 different categories of
built-in types.
Back to the OT: I think from a library creator sight this could be good
idea for hiding the implementation of a type from the final programmer. The
type is to be used in either ref or pointer form in user code and the
client program does not need to know anything about its memory layout.
Side note : Someone else used the term 'stupid'; whether or not some idea
looks practical to SB, the term used in that post does not sound
respectful to - maybe only - me.
regards,
FM.
--
how am I supposed to end the twisted road of your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!
--
---
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/.
--f46d044402f4d79d5904f9ac78a9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div dir=3D"ltr">2014-05-10 23:26 GMT+04:30 Magnus Fromreide <span =
dir=3D"ltr"><<a href=3D"mailto:magfr@lysator.liu.se" target=3D"_blank">m=
agfr@lysator.liu.se</a>></span>:</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 style=3D"direction:ltr">Yes, you are right, and there=
are also function and member pointers for more</div>
<div style=3D"direction:ltr">recent odd pointers so that kills the idea rat=
her nicely.</div></blockquote></div><div style=3D"direction:ltr"><br></div>=
<div dir=3D"ltr">I should respectfully object that this one is irrelevant. =
Normal pointers have the same size and representation - regarding the compi=
lation platform. And they are implicitly statically cast-able to void*; sta=
tic_cast back from this result to the original type is also well-defined be=
havior.=C2=A0</div>
<div dir=3D"ltr"><br></div><div dir=3D"ltr">In contrast to normal pointers,=
member pointers have diverse sizes and representations even on the same pl=
atform -regarding their type. These types are not statically cast-able to v=
oid* and casting from void* to such types is Undefined-Behavior.=C2=A0</div=
>
<div dir=3D"ltr"><br></div><div dir=3D"ltr">In short words : the only commo=
n feature between member pointers and normal pointers is the term pointer w=
hile they are 2 different categories of built-in types.</div><div dir=3D"lt=
r">
<br></div><div dir=3D"ltr">Back to the OT: I think from a library creator s=
ight this could be good idea for hiding the implementation of a type from t=
he final programmer. The type is to be used in either ref or pointer form i=
n user code and =C2=A0the client program does not need to know anything abo=
ut its memory layout.</div>
<div dir=3D"ltr"><br></div><div dir=3D"ltr">Side note : Someone else used t=
he term 'stupid'; whether or not some idea looks practical to SB, t=
he term used in that post =C2=A0does not sound respectful to - maybe only -=
me.</div>
<div dir=3D"ltr"><br></div><div dir=3D"ltr" style=3D"direction:rtl">regards=
,</div><div dir=3D"ltr" style=3D"direction:rtl">FM.</div><div style=3D"dire=
ction:ltr"><br></div>-- <br><div dir=3D"ltr">how am I supposed to end the t=
wisted road of=C2=A0 your hair in the dark night??<br>
unless the candle of your face does turn a lamp up on my way!!!<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 />
--f46d044402f4d79d5904f9ac78a9--
.
Author: Stack Machine <stackmachine@hotmail.com>
Date: Sun, 18 May 2014 07:06:09 -0700 (PDT)
Raw View
------=_Part_2028_21439149.1400421969260
Content-Type: text/plain; charset=UTF-8
I don't see how cycles are a problem at all. Other languages don't need
forward declarations either. I'm sure they've come up with some viable
solutions.
Am Samstag, 17. Mai 2014 00:36:44 UTC+2 schrieb Richard Smith:
>
> On Fri, May 16, 2014 at 2:41 PM, Stack Machine <stackm...@hotmail.com<javascript:>
> > wrote:
>
>> Forward declarations are a stupid idea to begin with and should not be
>> expanded on. The solution to this should be Modules.
>>
>
> I generally agree, but with just a pinch of caution: forward declarations
> serve two purposes: reducing include dependencies and breaking cycles.
> Modules only helps with the first problem; we still need forward
> declarations for the second problem.
>
--
---
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_2028_21439149.1400421969260
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't see how cycles are a problem at all. Other languag=
es don't need forward declarations either. I'm sure they've come up with so=
me viable solutions.<br><br>Am Samstag, 17. Mai 2014 00:36:44 UTC+2 schrieb=
Richard Smith:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote">On Fri, May 16, 2014 at 2:41 PM, Stack Ma=
chine <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"lsoDjKnicDYJ" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">stackm...@=
hotmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Forward declarations are a =
stupid idea to begin with and should not be expanded on. The solution to th=
is should be Modules.</div>
</blockquote><div><br></div><div>I generally agree, but with just a pinch o=
f caution: forward declarations serve two purposes: reducing include depend=
encies and breaking cycles. Modules only helps with the first problem; we s=
till need forward declarations for the second problem.</div>
</div></div></div>
</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_2028_21439149.1400421969260--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Sun, 18 May 2014 20:36:11 +0430
Raw View
--089e013d175a93345904f9aed4ad
Content-Type: text/plain; charset=UTF-8
Cyclic referencing types? with header+module design of C++ I can not
imagine any better solution than forward declarations. If cyclic refers to
recursion, then I can see no better solution than forward declaration in
any strongly typed language.
2014-05-18 18:36 GMT+04:30 Stack Machine <stackmachine@hotmail.com>:
> I don't see how cycles are a problem at all. Other languages don't need
> forward declarations either. I'm sure they've come up with some viable
> solutions.
>
> Am Samstag, 17. Mai 2014 00:36:44 UTC+2 schrieb Richard Smith:
>
>> On Fri, May 16, 2014 at 2:41 PM, Stack Machine <stackm...@hotmail.com>wrote:
>>
>>> Forward declarations are a stupid idea to begin with and should not be
>>> expanded on. The solution to this should be Modules.
>>>
>>
>> I generally agree, but with just a pinch of caution: forward declarations
>> serve two purposes: reducing include dependencies and breaking cycles.
>> Modules only helps with the first problem; we still need forward
>> declarations for the second problem.
>>
> --
---
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/.
--
how am I supposed to end the twisted road of your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!
--
---
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/.
--089e013d175a93345904f9aed4ad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div style dir=3D"ltr">Cyclic referencing types? with head=
er+module design of C++ I can not imagine any better solution than forward =
declarations. If cyclic refers to recursion, then I can see no better solut=
ion than forward declaration in any strongly typed language.=C2=A0</div>
<div class=3D"gmail_extra"><div dir=3D"ltr"><br><br><div class=3D"gmail_quo=
te">2014-05-18 18:36 GMT+04:30 Stack Machine <span dir=3D"ltr"><<a href=
=3D"mailto:stackmachine@hotmail.com" target=3D"_blank">stackmachine@hotmail=
..com</a>></span>:<br>
<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">I don't see how cycles are a problem at all. Other lan=
guages don't need forward declarations either. I'm sure they've=
come up with some viable solutions.<br>
<br>Am Samstag, 17. Mai 2014 00:36:44 UTC+2 schrieb Richard Smith:<div><div=
class=3D"h5"><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"><div><div class=3D"gmail_quote">On Fri, May 16, 2014 at 2:=
41 PM, Stack Machine <span dir=3D"ltr"><<a>stackm...@hotmail.com</a>>=
</span> wrote:<br>
<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">Forward declarations are a stupid idea to=
begin with and should not be expanded on. The solution to this should be M=
odules.</div>
</blockquote><div><br></div><div>I generally agree, but with just a pinch o=
f caution: forward declarations serve two purposes: reducing include depend=
encies and breaking cycles. Modules only helps with the first problem; we s=
till need forward declarations for the second problem.</div>
</div></div></div>
</blockquote></div></div></blockquote></div><div class=3D""><div class=3D"h=
5">
<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></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr">=
how am I supposed to end the twisted road of=C2=A0 your hair in the dark ni=
ght??<br>unless the candle of your face does turn a lamp up on my way!!!<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 />
--089e013d175a93345904f9aed4ad--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Sun, 18 May 2014 19:37:11 +0200
Raw View
On Sun, May 18, 2014 at 05:47:22PM +0430, Farid Mehrabi wrote:
> 2014-05-10 23:26 GMT+04:30 Magnus Fromreide <magfr@lysator.liu.se>:
>
> > Yes, you are right, and there are also function and member pointers for
> > more
> > recent odd pointers so that kills the idea rather nicely.
> >
>
> I should respectfully object that this one is irrelevant. Normal pointers
> have the same size and representation - regarding the compilation platform.
> And they are implicitly statically cast-able to void*; static_cast back
> from this result to the original type is also well-defined behavior.
What about far, near and huge pointers on dos?
What about char pointers on word-addressable machines?
> In contrast to normal pointers, member pointers have diverse sizes and
> representations even on the same platform -regarding their type. These
> types are not statically cast-able to void* and casting from void* to such
> types is Undefined-Behavior.
>
> In short words : the only common feature between member pointers and normal
> pointers is the term pointer while they are 2 different categories of
> built-in types.
>
> Back to the OT: I think from a library creator sight this could be good
> idea for hiding the implementation of a type from the final programmer. The
> type is to be used in either ref or pointer form in user code and the
> client program does not need to know anything about its memory layout.
That was the use I intended for them :-)
> Side note : Someone else used the term 'stupid'; whether or not some idea
> looks practical to SB, the term used in that post does not sound
> respectful to - maybe only - me.
Yes. That was me, referring to my own idea; one can't use such language when
talking about the ideas of others.
I am sorry if I offended you.
/MF
--
---
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: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 18 May 2014 11:58:07 -0700
Raw View
--047d7b67377234f20c04f9b13a5f
Content-Type: text/plain; charset=UTF-8
On Sun, May 18, 2014 at 6:17 AM, Farid Mehrabi <farid.mehrabi@gmail.com>wrote:
>
>
>
> 2014-05-10 23:26 GMT+04:30 Magnus Fromreide <magfr@lysator.liu.se>:
>
>> Yes, you are right, and there are also function and member pointers for
>> more
>> recent odd pointers so that kills the idea rather nicely.
>>
>
> I should respectfully object that this one is irrelevant. Normal pointers
> have the same size and representation - regarding the compilation platform.
>
This is true on common platforms, but not in general, and the standard has
no such requirement.
> And they are implicitly statically cast-able to void*; static_cast back
> from this result to the original type is also well-defined behavior.
>
Yes, void* must be able to represent any object pointer, but some pointer
types might be smaller than void*. For instance, on a word-addressable
machine, the ABI might say that all class types have a size that is a
multiple of one word, and all class pointers are the "normal" size for the
machine, but char* and void* are represented as a pair of (word pointer,
byte index).
--
---
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/.
--047d7b67377234f20c04f9b13a5f
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">On S=
un, May 18, 2014 at 6:17 AM, Farid Mehrabi <span dir=3D"ltr"><<a href=3D=
"mailto:farid.mehrabi@gmail.com" target=3D"_blank">farid.mehrabi@gmail.com<=
/a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"rtl"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">2014-05-10 23:26 GM=
T+04:30 Magnus Fromreide <span dir=3D"ltr"><<a href=3D"mailto:magfr@lysa=
tor.liu.se" target=3D"_blank">magfr@lysator.liu.se</a>></span>:</div>
<div class=3D"">
<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 style=3D"direction:ltr">Yes, you are right, and there=
are also function and member pointers for more</div>
<div style=3D"direction:ltr">recent odd pointers so that kills the idea rat=
her nicely.</div></blockquote></div></div><div style=3D"direction:ltr"><br>=
</div><div dir=3D"ltr">I should respectfully object that this one is irrele=
vant. Normal pointers have the same size and representation - regarding the=
compilation platform. </div>
</div></div></blockquote><div><br></div><div>This is true on common platfor=
ms, but not in general, and the standard has no such requirement.</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">
<div dir=3D"rtl"><div class=3D"gmail_extra"><div dir=3D"ltr">And they are i=
mplicitly statically cast-able to void*; static_cast back from this result =
to the original type is also well-defined behavior.=C2=A0</div></div></div>=
</blockquote>
<div><br></div><div>Yes, void* must be able to represent any object pointer=
, but some pointer types might be smaller than void*. For instance, on a wo=
rd-addressable machine, the ABI might say that all class types have a size =
that is a multiple of one word, and all class pointers are the "normal=
" size for the machine, but char* and void* are represented as a pair =
of (word pointer, byte index).</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 />
--047d7b67377234f20c04f9b13a5f--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 18 May 2014 11:59:38 -0700
Raw View
--047d7bd6aea298c54b04f9b13fbb
Content-Type: text/plain; charset=UTF-8
On Sun, May 18, 2014 at 7:06 AM, Stack Machine <stackmachine@hotmail.com>wrote:
> I don't see how cycles are a problem at all. Other languages don't need
> forward declarations either. I'm sure they've come up with some viable
> solutions.
>
Other languages that do without forward declarations (such as Java) are
parseable without knowing what identifiers refer to types and non-types.
C++ is not; this solution is not viable for C++.
Am Samstag, 17. Mai 2014 00:36:44 UTC+2 schrieb Richard Smith:
>
>> On Fri, May 16, 2014 at 2:41 PM, Stack Machine <stackm...@hotmail.com>wrote:
>>
>>> Forward declarations are a stupid idea to begin with and should not be
>>> expanded on. The solution to this should be Modules.
>>>
>>
>> I generally agree, but with just a pinch of caution: forward declarations
>> serve two purposes: reducing include dependencies and breaking cycles.
>> Modules only helps with the first problem; we still need forward
>> declarations for the second problem.
>>
> --
>
> ---
> 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/.
>
--
---
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/.
--047d7bd6aea298c54b04f9b13fbb
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">On S=
un, May 18, 2014 at 7:06 AM, Stack Machine <span dir=3D"ltr"><<a href=3D=
"mailto:stackmachine@hotmail.com" target=3D"_blank">stackmachine@hotmail.co=
m</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I don't see how cycles =
are a problem at all. Other languages don't need forward declarations e=
ither. I'm sure they've come up with some viable solutions.<br>
</div></blockquote><div><br></div><div>Other languages that do without forw=
ard declarations (such as Java) are parseable without knowing what identifi=
ers refer to types and non-types. C++ is not; this solution is not viable f=
or C++.</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">Am Samstag, =
17. Mai 2014 00:36:44 UTC+2 schrieb Richard Smith:<div class=3D""><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, May 16, 2014 at 2:=
41 PM, Stack Machine <span dir=3D"ltr"><<a>stackm...@hotmail.com</a>>=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Forward declarations are a =
stupid idea to begin with and should not be expanded on. The solution to th=
is should be Modules.</div>
</blockquote><div><br></div><div>I generally agree, but with just a pinch o=
f caution: forward declarations serve two purposes: reducing include depend=
encies and breaking cycles. Modules only helps with the first problem; we s=
till need forward declarations for the second problem.</div>
</div></div></div>
</blockquote></div></div>
<p></p>
-- <br><div class=3D"HOEnZb"><div class=3D"h5">
<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></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 />
--047d7bd6aea298c54b04f9b13fbb--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Mon, 19 May 2014 19:35:03 +0430
Raw View
--047d7bb03f60b0867304f9c2177a
Content-Type: text/plain; charset=UTF-8
2014-05-18 22:07 GMT+04:30 Magnus Fromreide <magfr@lysator.liu.se>:
> On Sun, May 18, 2014 at 05:47:22PM +0430, Farid Mehrabi wrote:
> > 2014-05-10 23:26 GMT+04:30 Magnus Fromreide <magfr@lysator.liu.se>:
> >
> > > Yes, you are right, and there are also function and member pointers for
> > > more
> > > recent odd pointers so that kills the idea rather nicely.
> > >
> >
> > I should respectfully object that this one is irrelevant. Normal pointers
> > have the same size and representation - regarding the compilation
> platform.
> > And they are implicitly statically cast-able to void*; static_cast back
> > from this result to the original type is also well-defined behavior.
>
> What about far, near and huge pointers on dos?
>
they are different families of pointers on the same platform. And far/near
are not properties of the referenced type. An object pointer is still
cast-able to&from void* of the same family - irrelevant of the specifier
used to declare the type(struct,class,enum ...).
regards,
FM.
> What about char pointers on word-addressable machines?
>
> > Side note : Someone else used the term 'stupid'; whether or not some idea
> > looks practical to SB, the term used in that post does not sound
> > respectful to - maybe only - me.
>
> Yes. That was me, referring to my own idea; one can't use such language
> when
> talking about the ideas of others.
> I am sorry if I offended you.
>
Oops! I should call myself the same.
--
---
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/.
--047d7bb03f60b0867304f9c2177a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div dir=3D"ltr">2014-05-18 22:07 GMT+04:30 Magnus Fromreide <span =
dir=3D"ltr"><<a href=3D"mailto:magfr@lysator.liu.se" target=3D"_blank">m=
agfr@lysator.liu.se</a>></span>:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On Sun, May 18, 2014 at 05:4=
7:22PM +0430, Farid Mehrabi wrote:<br>
> 2014-05-10 23:26 GMT+04:30 Magnus Fromreide <<a href=3D"mailto:magf=
r@lysator.liu.se">magfr@lysator.liu.se</a>>:<br>
><br>
> > Yes, you are right, and there are also function and member pointe=
rs for<br>
> > more<br>
> > recent odd pointers so that kills the idea rather nicely.<br>
> ><br>
><br>
> I should respectfully object that this one is irrelevant. Normal point=
ers<br>
> have the same size and representation - regarding the compilation plat=
form.<br>
> And they are implicitly statically cast-able to void*; static_cast bac=
k<br>
> from this result to the original type is also well-defined behavior.<b=
r>
<br>
</div>What about far, near and huge pointers on dos?<br>
</blockquote><div><br></div><div><br></div><div style=3D"text-align:left" d=
ir=3D"ltr">they are different families of pointers on the same platform. An=
d far/near are not properties of the =C2=A0referenced type. An object point=
er is still cast-able to&from void* of the same family - irrelevant of =
the specifier used to declare the type(struct,class,enum ...).</div>
<div style=3D"text-align:left" dir=3D"ltr"><br></div><div style=3D"text-ali=
gn:left" dir=3D"ltr">regards,</div><div style=3D"text-align:left" dir=3D"lt=
r">FM.</div><div style=3D"text-align:left"><br></div><div style=3D"text-ali=
gn:left">=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">What about char pointers on word-addressable=
machines?<br>
<div class=3D""><br></div><div class=3D"">
> Side note : Someone else used the term 'stupid'; whether or no=
t some idea<br>
> looks practical to SB, the term used in that post =C2=A0does not sound=
<br>
> respectful to - maybe only - me.<br>
<br>
</div>Yes. That was me, referring to my own idea; one can't use such la=
nguage when<br>
talking about the ideas of others.<br>
I am sorry if I offended you.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><span style=3D"color:rgb(34,34,34)"=
></span></div></div></blockquote><div><br></div><div style=3D"text-align:le=
ft" dir=3D"ltr">=C2=A0Oops! I should call myself the same.</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 />
--047d7bb03f60b0867304f9c2177a--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Mon, 19 May 2014 19:38:55 +0430
Raw View
--001a11c23ff688748004f9c2255c
Content-Type: text/plain; charset=UTF-8
2014-05-18 23:28 GMT+04:30 Richard Smith <richard@metafoo.co.uk>:
> On Sun, May 18, 2014 at 6:17 AM, Farid Mehrabi <farid.mehrabi@gmail.com>wrote:
>
>>
>>
>>
>> 2014-05-10 23:26 GMT+04:30 Magnus Fromreide <magfr@lysator.liu.se>:
>>
>>> Yes, you are right, and there are also function and member pointers for
>>> more
>>> recent odd pointers so that kills the idea rather nicely.
>>>
>>
>> I should respectfully object that this one is irrelevant. Normal pointers
>> have the same size and representation - regarding the compilation platform.
>>
>
> This is true on common platforms, but not in general, and the standard has
> no such requirement.
>
>
I used to consider this as the de facto standard.
And they are implicitly statically cast-able to void*; static_cast back
>> from this result to the original type is also well-defined behavior.
>>
>
> Yes, void* must be able to represent any object pointer, but some pointer
> types might be smaller than void*. For instance, on a word-addressable
> machine, the ABI might say that all class types have a size that is a
> multiple of one word, and all class pointers are the "normal" size for the
> machine, but char* and void* are represented as a pair of (word pointer,
> byte index).
>
I need a concrete practical example please. PC mainframe micro??
A machine + OS + tool chain + relative pointer-sizes .
regards,
FM.
--
---
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/.
--001a11c23ff688748004f9c2255c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><br><div class=3D"gmail_extra"><div dir=3D"ltr"><br><br><d=
iv class=3D"gmail_quote">2014-05-18 23:28 GMT+04:30 Richard Smith <span dir=
=3D"ltr"><<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">ric=
hard@metafoo.co.uk</a>></span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-ri=
ght-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;=
padding-left:1ex;padding-right:1ex">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"">On Su=
n, May 18, 2014 at 6:17 AM, Farid Mehrabi <span dir=3D"ltr"><<a href=3D"=
mailto:farid.mehrabi@gmail.com" target=3D"_blank">farid.mehrabi@gmail.com</=
a>></span> wrote:<br>
<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"rtl"><br><div class=3D"gmail_extra"><br><br><d=
iv class=3D"gmail_quote">
<div dir=3D"ltr">2014-05-10 23:26 GMT+04:30 Magnus Fromreide <span dir=3D"l=
tr"><<a href=3D"mailto:magfr@lysator.liu.se" target=3D"_blank">magfr@lys=
ator.liu.se</a>></span>:</div>
<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 style=3D"direction:ltr">Yes, you are right, and there=
are also function and member pointers for more</div>
<div style=3D"direction:ltr">recent odd pointers so that kills the idea rat=
her nicely.</div></blockquote></div></div><div style=3D"direction:ltr"><br>=
</div><div dir=3D"ltr">I should respectfully object that this one is irrele=
vant. Normal pointers have the same size and representation - regarding the=
compilation platform. </div>
</div></div></blockquote><div><br></div></div><div>This is true on common p=
latforms, but not in general, and the standard has no such requirement.</di=
v><div class=3D""><div>=C2=A0</div></div></div></div></blockquote><div><br>=
</div>
<div>I used to consider this as the de facto =C2=A0standard.</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;bor=
der-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:=
solid;padding-left:1ex;padding-right:1ex">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""><bloc=
kquote 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;paddin=
g-left:1ex">
<div dir=3D"rtl"><div class=3D"gmail_extra"><div dir=3D"ltr">And they are i=
mplicitly statically cast-able to void*; static_cast back from this result =
to the original type is also well-defined behavior.=C2=A0</div></div></div>=
</blockquote>
<div><br></div></div><div>Yes, void* must be able to represent any object p=
ointer, but some pointer types might be smaller than void*. For instance, o=
n a word-addressable machine, the ABI might say that all class types have a=
size that is a multiple of one word, and all class pointers are the "=
normal" size for the machine, but char* and void* are represented as a=
pair of (word pointer, byte index).</div>
</div></div></blockquote><div><br></div><div>=C2=A0</div><div>I need a conc=
rete practical example please. PC mainframe micro??=C2=A0</div><div>A machi=
ne + OS + tool chain + relative pointer-sizes .</div><div><br></div><div>re=
gards,</div>
<div>FM.</div><div>=C2=A0</div></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 />
--001a11c23ff688748004f9c2255c--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Mon, 19 May 2014 19:56:40 +0430
Raw View
--089e013d175a38c46b04f9c265a0
Content-Type: text/plain; charset=UTF-8
2014-05-19 19:38 GMT+04:30 Farid Mehrabi <farid.mehrabi@gmail.com>:
>
>
>
> 2014-05-18 23:28 GMT+04:30 Richard Smith <richard@metafoo.co.uk>:
>
> On Sun, May 18, 2014 at 6:17 AM, Farid Mehrabi <farid.mehrabi@gmail.com>wrote:
>>
>>>
>>>
>>>
>>> 2014-05-10 23:26 GMT+04:30 Magnus Fromreide <magfr@lysator.liu.se>:
>>>
>>>> Yes, you are right, and there are also function and member pointers for
>>>> more
>>>> recent odd pointers so that kills the idea rather nicely.
>>>>
>>>
>>> I should respectfully object that this one is irrelevant. Normal
>>> pointers have the same size and representation - regarding the compilation
>>> platform.
>>>
>>
>> This is true on common platforms, but not in general, and the standard
>> has no such requirement.
>>
>>
>
> I used to consider this as the de facto standard.
>
> And they are implicitly statically cast-able to void*; static_cast back
>>> from this result to the original type is also well-defined behavior.
>>>
>>
>> Yes, void* must be able to represent any object pointer, but some pointer
>> types might be smaller than void*. For instance, on a word-addressable
>> machine, the ABI might say that all class types have a size that is a
>> multiple of one word, and all class pointers are the "normal" size for the
>> machine, but char* and void* are represented as a pair of (word pointer,
>> byte index).
>>
>
>
> I need a concrete practical example please. PC mainframe micro??
> A machine + OS + tool chain + relative pointer-sizes .
>
>
Even if any platform with such design exists, the forward declared type can
use pointers/references with void* layout. This is sub-optimal but yet
easily implementable.
And IMHO the 'typename' keyword is a good candidate for the purpose. It
clearly expresses the intention.
regards,
FM.
--
how am I supposed to end the twisted road of your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!
--
---
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/.
--089e013d175a38c46b04f9c265a0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><br><div class=3D"gmail_extra"><div dir=3D"rtl"><br><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr">2014-05-19 19:38 GMT+04:30 Farid =
Mehrabi <span dir=3D"ltr"><<a href=3D"mailto:farid.mehrabi@gmail.com" ta=
rget=3D"_blank">farid.mehrabi@gmail.com</a>></span>:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 .8ex;border-left:1px #c=
cc solid;border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex"><b=
r><div class=3D"gmail_extra"><div dir=3D"ltr"><br><br><div class=3D"gmail_q=
uote">
2014-05-18 23:28 GMT+04:30 Richard Smith <span dir=3D"ltr"><<a href=3D"m=
ailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>>=
;</span>:<div class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-ri=
ght-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;=
padding-left:1ex;padding-right:1ex">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>On Sun, May 18, =
2014 at 6:17 AM, Farid Mehrabi <span dir=3D"ltr"><<a href=3D"mailto:fari=
d.mehrabi@gmail.com" target=3D"_blank">farid.mehrabi@gmail.com</a>></spa=
n> wrote:<br>
<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"rtl"><br><div class=3D"gmail_extra"><br><br><d=
iv class=3D"gmail_quote">
<div dir=3D"ltr">2014-05-10 23:26 GMT+04:30 Magnus Fromreide <span dir=3D"l=
tr"><<a href=3D"mailto:magfr@lysator.liu.se" target=3D"_blank">magfr@lys=
ator.liu.se</a>></span>:</div>
<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 style=3D"direction:ltr">Yes, you are right, and there=
are also function and member pointers for more</div>
<div style=3D"direction:ltr">recent odd pointers so that kills the idea rat=
her nicely.</div></blockquote></div></div><div style=3D"direction:ltr"><br>=
</div><div dir=3D"ltr">I should respectfully object that this one is irrele=
vant. Normal pointers have the same size and representation - regarding the=
compilation platform. </div>
</div></div></blockquote><div><br></div></div><div>This is true on common p=
latforms, but not in general, and the standard has no such requirement.</di=
v><div><div>=C2=A0</div></div></div></div></blockquote><div><br></div>
</div><div>I used to consider this as the de facto =C2=A0standard.</div><di=
v class=3D""><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,20=
4);border-right-style:solid;padding-left:1ex;padding-right:1ex">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
>
<div dir=3D"rtl"><div class=3D"gmail_extra"><div dir=3D"ltr">And they are i=
mplicitly statically cast-able to void*; static_cast back from this result =
to the original type is also well-defined behavior.=C2=A0</div></div></div>=
</blockquote>
<div><br></div></div><div>Yes, void* must be able to represent any object p=
ointer, but some pointer types might be smaller than void*. For instance, o=
n a word-addressable machine, the ABI might say that all class types have a=
size that is a multiple of one word, and all class pointers are the "=
normal" size for the machine, but char* and void* are represented as a=
pair of (word pointer, byte index).</div>
</div></div></blockquote><div><br></div><div>=C2=A0</div></div><div>I need =
a concrete practical example please. PC mainframe micro??=C2=A0</div><div>A=
machine + OS + tool chain + relative pointer-sizes .</div><div><br></div><=
/div>
</div></div></blockquote></div></div><div dir=3D"ltr"><br></div><div dir=3D=
"ltr">Even if any platform with such design exists, the forward declared ty=
pe can use pointers/references with void* layout. This is sub-optimal but y=
et easily implementable.</div>
<div dir=3D"ltr"><br></div><div dir=3D"ltr">And IMHO the 'typename'=
keyword is a good candidate for the purpose. It clearly expresses the inte=
ntion.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">regards,</div><div =
dir=3D"ltr">
FM.</div>-- <br><div dir=3D"ltr">how am I supposed to end the twisted road =
of=C2=A0 your hair in the dark night??<br>unless the candle of your face do=
es turn a lamp up on my way!!!<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 />
--089e013d175a38c46b04f9c265a0--
.
Author: Jean-Marc Bourguet <jm.bourguet@gmail.com>
Date: Mon, 19 May 2014 08:42:23 -0700 (PDT)
Raw View
------=_Part_175_19629993.1400514143631
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le lundi 19 mai 2014 08:08:55 UTC-7, Farid Mehrabi a =C3=A9crit :
>
>
> 2014-05-18 23:28 GMT+04:30 Richard Smith <ric...@metafoo.co.uk<javascript=
:>
> >:
>
>> On Sun, May 18, 2014 at 6:17 AM, Farid Mehrabi <farid....@gmail.com<java=
script:>
>> > wrote:
>>
>>>
>>> This is true on common platforms, but not in general, and the standard=
=20
>> has no such requirement.
>> =20
>>
>
> I used to consider this as the de facto standard.
>
But we are in a group discussing proposals for the formal standard.
=20
> And they are implicitly statically cast-able to void*; static_cast back=
=20
>>> from this result to the original type is also well-defined behavior.=20
>>>
>>
>> Yes, void* must be able to represent any object pointer, but some pointe=
r=20
>> types might be smaller than void*. For instance, on a word-addressable=
=20
>> machine, the ABI might say that all class types have a size that is a=20
>> multiple of one word, and all class pointers are the "normal" size for t=
he=20
>> machine, but char* and void* are represented as a pair of (word pointer,=
=20
>> byte index).
>>
>
> =20
> I need a concrete practical example please. PC mainframe micro??=20
> A machine + OS + tool chain + relative pointer-sizes .
>
I know of none. I'm pretty sure it is allowed because it was the case for=
=20
some C implementations (mainframe or embedded systems are the suspects, I=
=20
know again none, the two unusual implementations for C I know which target=
=20
word-addressable machines -- KCC for PDP-10 and unysis C compiler for OS=20
2200 -- are using the same pointer size for all data pointers).=20
You could propose to make what you think the de factor standard official,=
=20
but this is an area where the C++ committee usually defers to the C one.
Yours,
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_175_19629993.1400514143631
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le lundi 19 mai 2014 08:08:55 UTC-7, Farid Mehrabi a =C3=
=A9crit :<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"rtl"=
><br><div><div dir=3D"ltr"><div class=3D"gmail_quote">2014-05-18 23:28 GMT+=
04:30 Richard Smith <span dir=3D"ltr"><<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"yPMAw_qvIrQJ" onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;">ric...@metafoo.co.uk</a>></span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-ri=
ght-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;=
padding-left:1ex;padding-right:1ex">
<div><div class=3D"gmail_quote"><div>On Sun, May 18, 2014 at 6:17 AM, Farid=
Mehrabi <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"yPMAw_qvIrQJ" onmousedown=3D"this.href=3D'javascript=
:';return true;" onclick=3D"this.href=3D'javascript:';return true;">farid..=
...@gmail.com</a>></span> wrote:<br>
<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"rtl"><br></div></blockquote></div><div>This is=
true on common platforms, but not in general, and the standard has no such=
requirement.</div><div><div> </div></div></div></div></blockquote><di=
v><br></div>
<div>I used to consider this as the de facto standard.</div></div></d=
iv></div></div></blockquote><div><br></div><div>But we are in a group discu=
ssing proposals for the formal standard.</div><div> </div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"rtl"><div dir=3D"ltr"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border=
-right-style:solid;padding-left:1ex;padding-right:1ex"><div><div class=3D"g=
mail_quote"><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-l=
eft-style:solid;padding-left:1ex"><div dir=3D"rtl"><div><div dir=3D"ltr">An=
d they are implicitly statically cast-able to void*; static_cast back from =
this result to the original type is also well-defined behavior. </div>=
</div></div></blockquote>
<div><br></div></div><div>Yes, void* must be able to represent any object p=
ointer, but some pointer types might be smaller than void*. For instance, o=
n a word-addressable machine, the ABI might say that all class types have a=
size that is a multiple of one word, and all class pointers are the "norma=
l" size for the machine, but char* and void* are represented as a pair of (=
word pointer, byte index).</div>
</div></div></blockquote><div><br></div><div> </div><div>I need a conc=
rete practical example please. PC mainframe micro?? </div><div>A machi=
ne + OS + tool chain + relative pointer-sizes .</div></div></div></div></bl=
ockquote><div><br></div><div>I know of none. I'm pretty sure it is al=
lowed because it was the case for some C implementations (mainframe or embe=
dded systems are the suspects, I know again none, the two unusual implement=
ations for C I know which target word-addressable machines -- KCC for PDP-1=
0 and unysis C compiler for OS 2200 -- are using the same pointer size for =
all data pointers). </div><div><br></div><div>You could propose to mak=
e what you think the de factor standard official, but this is an area where=
the C++ committee usually defers to the C one.</div><div><br></div><div>Yo=
urs,</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_175_19629993.1400514143631--
.
Author: Jean-Marc Bourguet <jm.bourguet@gmail.com>
Date: Mon, 19 May 2014 08:45:35 -0700 (PDT)
Raw View
------=_Part_485_8942102.1400514335426
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le lundi 19 mai 2014 08:26:40 UTC-7, Farid Mehrabi a =C3=A9crit :
>
>
>
>
>
>>
>> Even if any platform with such design exists, the forward declared type=
=20
> can use pointers/references with void* layout. This is sub-optimal but ye=
t=20
> easily implementable.
>
>
> I don't see how that would work when calling functions whose definition=
=20
don't see the forward declaration.
Yours,
--=20
Jean-Marc
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_485_8942102.1400514335426
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le lundi 19 mai 2014 08:26:40 UTC-7, Farid Mehrabi a =C3=
=A9crit :<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"rtl"=
><br><div><div dir=3D"rtl"><br><br><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 .8ex;border-left:1px #ccc solid;bord=
er-right:1px #ccc solid;padding-left:1ex;padding-right:1ex"><div dir=3D"ltr=
"><div class=3D"gmail_quote"><br><br></div></div></blockquote></div></div><=
div dir=3D"ltr">Even if any platform with such design exists, the forward d=
eclared type can use pointers/references with void* layout. This is sub-opt=
imal but yet easily implementable.</div>
<div dir=3D"ltr"><br></div><div dir=3D"ltr"><br></div></div></div></blockqu=
ote><div>I don't see how that would work when calling functions whose defin=
ition don't see the forward declaration.</div><div><br></div><div>Yours,</d=
iv><div><br></div><div>-- </div><div>Jean-Marc</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_485_8942102.1400514335426--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 19 May 2014 09:35:20 -0700
Raw View
Em seg 19 maio 2014, =E0s 19:38:55, Farid Mehrabi escreveu:
> > Yes, void* must be able to represent any object pointer, but some point=
er
> > types might be smaller than void*. For instance, on a word-addressable
> > machine, the ABI might say that all class types have a size that is a
> > multiple of one word, and all class pointers are the "normal" size for =
the
> > machine, but char* and void* are represented as a pair of (word pointer=
,
> > byte index).
>=20
> I need a concrete practical example please. PC mainframe micro??
> A machine + OS + tool chain + relative pointer-sizes .
Let me throw another wrench in this discussion:
even if you could determine the bitwise composition of the pointer or=20
reference of this forward declared typename, you can't call a function with=
it=20
and you can't use it in a template expansion. Some ABIs require encoding th=
e=20
aggregate type (class, struct, enum), and most ABIs will encode the origina=
l,=20
non-typedef'ed name.
--=20
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
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Tue, 20 May 2014 19:30:27 +0430
Raw View
--001a11c23ff618544704f9d62509
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2014-05-19 20:15 GMT+04:30 Jean-Marc Bourguet <jm.bourguet@gmail.com>:
> Le lundi 19 mai 2014 08:26:40 UTC-7, Farid Mehrabi a =C3=A9crit :
>
>>
>>
>>
>>
>>>
>>> Even if any platform with such design exists, the forward declared type
>> can use pointers/references with void* layout. This is sub-optimal but y=
et
>> easily implementable.
>>
>>
>> I don't see how that would work when calling functions whose definition
> don't see the forward declaration.
>
>
where should those functions be declared if they are intended for public
use? how can an undeclared function be used in c++ without generating any
sort of compile time diagnostics?
if a function is a part of public interface of the type, it should be
declared in the same header that declares the type and that header is
included in the defining module of the interface as well as client modules.
smart cautious use of include directives can help optimize away the
overhead of long pointer size - In case hypothetically such an overhead is
expected on a platform - in private modules whose functions are not to be
published for public use.
regards,
FM.
--=20
how am I supposed to end the twisted road of your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c23ff618544704f9d62509
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><br><div class=3D"gmail_extra"><div dir=3D"ltr"><br><br><d=
iv class=3D"gmail_quote">2014-05-19 20:15 GMT+04:30 Jean-Marc Bourguet <spa=
n dir=3D"ltr"><<a href=3D"mailto:jm.bourguet@gmail.com" target=3D"_blank=
">jm.bourguet@gmail.com</a>></span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 .8ex;border-left:1px #c=
cc solid;border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex">Le=
lundi 19 mai 2014 08:26:40 UTC-7, Farid Mehrabi a =C3=A9crit=C2=A0:<div cl=
ass=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"rtl"><br><div><div dir=3D"rtl"><br><br><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 .8ex;border-left:1px=
#ccc solid;border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex"=
><div dir=3D"ltr">
<div class=3D"gmail_quote"><br><br></div></div></blockquote></div></div><di=
v dir=3D"ltr">Even if any platform with such design exists, the forward dec=
lared type can use pointers/references with void* layout. This is sub-optim=
al but yet easily implementable.</div>
<div dir=3D"ltr"><br></div><div dir=3D"ltr"><br></div></div></div></blockqu=
ote></div><div>I don't see how that would work when calling functions w=
hose definition don't see the forward declaration.</div><div><br></div>
</blockquote></div></div><div style=3D"text-align:left"><br></div><div styl=
e=3D"text-align:left" dir=3D"ltr">where should those functions be declared =
if they are intended for public use? how can an undeclared function =C2=A0b=
e used in c++ without generating any sort of compile time diagnostics?</div=
>
<div style=3D"text-align:left" dir=3D"ltr"><br></div><div style=3D"text-ali=
gn:left" dir=3D"ltr">if a function is a part of public interface of the typ=
e, it should be declared in the same header that declares the type and that=
header is=C2=A0</div>
<div style=3D"text-align:left" dir=3D"ltr">included in the defining module =
of the interface as well as client modules. smart cautious use of include d=
irectives can help optimize away the overhead of long pointer size - In cas=
e hypothetically =C2=A0such an overhead is expected on a platform - in priv=
ate modules whose functions are not to be published for public use.</div>
<div style=3D"text-align:left" dir=3D"ltr"><br></div><div style=3D"text-ali=
gn:left" dir=3D"ltr">regards,</div><div style=3D"text-align:left" dir=3D"lt=
r">FM.</div><div><br></div>-- <br><div dir=3D"ltr">how am I supposed to end=
the twisted road of=C2=A0 your hair in the dark night??<br>
unless the candle of your face does turn a lamp up on my way!!!<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 />
--001a11c23ff618544704f9d62509--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Tue, 20 May 2014 19:37:48 +0430
Raw View
--f46d044402f46001ab04f9d63f36
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2014-05-19 21:05 GMT+04:30 Thiago Macieira <thiago@macieira.org>:
> Em seg 19 maio 2014, =C3=A0s 19:38:55, Farid Mehrabi escreveu:
> > > Yes, void* must be able to represent any object pointer, but some
> pointer
> > > types might be smaller than void*. For instance, on a word-addressabl=
e
> > > machine, the ABI might say that all class types have a size that is a
> > > multiple of one word, and all class pointers are the "normal" size fo=
r
> the
> > > machine, but char* and void* are represented as a pair of (word
> pointer,
> > > byte index).
> >
> > I need a concrete practical example please. PC mainframe micro??
> > A machine + OS + tool chain + relative pointer-sizes .
>
> Let me throw another wrench in this discussion:
>
> even if you could determine the bitwise composition of the pointer or
> reference of this forward declared typename, you can't call a function
> with it
> and you can't use it in a template expansion. Some ABIs require encoding
> the
> aggregate type (class, struct, enum), and most ABIs will encode the
> original,
> non-typedef'ed name.
>
>
>
will encode ? ?
no compiler is currently implementing this syntax, that`s the purpose of
this post: we want future std compilers to be able to do it and we are
discussing how to.
The general forward declaration syntax (the one with generic specifier
'typename') should instruct the compiler to choose the most conservative
approach. I don`t how that`s gonna make any troubles.Unless you don`t use
the value semantics compiler does not complain. the pointer/reference has
proper memory layout.
regards,
FM.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--f46d044402f46001ab04f9d63f36
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div style=3D"text-align:left"><br></div><div class=3D"gma=
il_extra"><div style=3D"text-align:left"><br></div><div style=3D"text-align=
:left"><br></div><div class=3D"gmail_quote"><div dir=3D"ltr">2014-05-19 21:=
05 GMT+04:30 Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailto:thiago=
@macieira.org" target=3D"_blank">thiago@macieira.org</a>></span>:</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 style=3D"text-align:left">Em seg 19 maio 2014, =C3=A0=
s 19:38:55, Farid Mehrabi escreveu:</div>
<div class=3D""><div style=3D"text-align:left">> > Yes, void* must be=
able to represent any object pointer, but some pointer</div><div style=3D"=
text-align:left">> > types might be smaller than void*. For instance,=
on a word-addressable</div>
<div style=3D"text-align:left">> > machine, the ABI might say that al=
l class types have a size that is a</div><div style=3D"text-align:left">>=
; > multiple of one word, and all class pointers are the "normal&qu=
ot; size for the</div>
<div style=3D"text-align:left">> > machine, but char* and void* are r=
epresented as a pair of (word pointer,</div><div style=3D"text-align:left">=
> > byte index).</div><div style=3D"text-align:left">></div><div s=
tyle=3D"text-align:left">
> I need a concrete practical example please. PC mainframe micro??</div>=
<div style=3D"text-align:left">> A machine + OS + tool chain + relative =
pointer-sizes .</div>
<div style=3D"text-align:left"><br></div>
</div><div style=3D"text-align:left">Let me throw another wrench in this di=
scussion:</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">eve=
n if you could determine the bitwise composition of the pointer or</div><di=
v style=3D"text-align:left">reference of this forward declared typename, yo=
u can't call a function with it</div>
<div style=3D"text-align:left">and you can't use it in a template expan=
sion. Some ABIs require encoding the</div><div style=3D"text-align:left">ag=
gregate type (class, struct, enum), and most ABIs will encode the original,=
</div>
<div style=3D"text-align:left">non-typedef'ed name.</div>
<div class=3D"im"><div style=3D"text-align:left"><br></div><div style=3D"te=
xt-align:left"><br></div></div></blockquote><div>=C2=A0</div><div style=3D"=
text-align:left" dir=3D"ltr">will encode ? ?<br></div><div style=3D"text-al=
ign:left" dir=3D"ltr">
no compiler is currently implementing this syntax, that`s the purpose of th=
is post: we want future std compilers to be able to do it and we are discus=
sing how to.</div><div style=3D"text-align:left" dir=3D"ltr">The general fo=
rward declaration syntax (the one with generic specifier 'typename'=
) should instruct the compiler to choose the most conservative approach. I =
don`t how that`s gonna make any troubles.Unless you don`t use the value sem=
antics compiler does not complain. the pointer/reference has proper memory =
layout.</div>
<div style=3D"text-align:left" dir=3D"ltr"><br></div><div style=3D"text-ali=
gn:left" dir=3D"ltr">regards,</div><div style=3D"text-align:left" dir=3D"lt=
r">FM.=C2=A0</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 />
--f46d044402f46001ab04f9d63f36--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 20 May 2014 08:58:11 -0700
Raw View
Em ter 20 maio 2014, =E0s 19:37:48, Farid Mehrabi escreveu:
> > even if you could determine the bitwise composition of the pointer or
> > reference of this forward declared typename, you can't call a function
> > with it
> > and you can't use it in a template expansion. Some ABIs require encodin=
g
> > the
> > aggregate type (class, struct, enum), and most ABIs will encode the
> > original,
> > non-typedef'ed name.
>=20
> will encode ? ?
They will encode because they do right now.
> no compiler is currently implementing this syntax, that`s the purpose of
> this post: we want future std compilers to be able to do it and we are
> discussing how to.
Indeed. But please understand you're asking every single compiler to break=
=20
their ABI. That is, to enable support for this feature, no program previous=
ly=20
compiled will link with new code.
> The general forward declaration syntax (the one with generic specifier
> 'typename') should instruct the compiler to choose the most conservative
> approach. I don`t how that`s gonna make any troubles.Unless you don`t use
> the value semantics compiler does not complain. the pointer/reference has
> proper memory layout.
Right now, if you do like this:
class Class;
struct Struct;
typedef Struct T;
void f(Class *, Struct *);
void g(T *);
The external name of f and g will include some information that this propos=
al=20
makes impossible to know.
IA-64 mangling for g():=20
_Z1g P6Struct (space mine, note the typedef was piereced)
MSVC mangling for both:
?f@@YAX PAVClass@@ PAUStruct@@ @Z
?g@@YAX PAUStruct@@ @Z
(space mine, note the U before Struct and V before Class)
If the code above were:
typename Class;
typename Struct;
typename T;
Then how would the compiler know that Class is a class and Struct is a stru=
ct,=20
and that T is the same as Struct?
--=20
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
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Tue, 20 May 2014 20:45:09 +0430
Raw View
--001a11c23ff638c68104f9d7302d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2014-05-20 20:28 GMT+04:30 Thiago Macieira <thiago@macieira.org>:
> Em ter 20 maio 2014, =C3=A0s 19:37:48, Farid Mehrabi escreveu:
> > > even if you could determine the bitwise composition of the pointer or
> > > reference of this forward declared typename, you can't call a functio=
n
> > > with it
> > > and you can't use it in a template expansion. Some ABIs require
> encoding
> > > the
> > > aggregate type (class, struct, enum), and most ABIs will encode the
> > > original,
> > > non-typedef'ed name.
> >
> > will encode ? ?
>
> They will encode because they do right now.
>
> > no compiler is currently implementing this syntax, that`s the purpose o=
f
> > this post: we want future std compilers to be able to do it and we are
> > discussing how to.
>
> Indeed. But please understand you're asking every single compiler to brea=
k
> their ABI. That is, to enable support for this feature, no program
> previously
> compiled will link with new code.
>
> > The general forward declaration syntax (the one with generic specifier
> > 'typename') should instruct the compiler to choose the most conservativ=
e
> > approach. I don`t how that`s gonna make any troubles.Unless you don`t u=
se
> > the value semantics compiler does not complain. the pointer/reference h=
as
> > proper memory layout.
>
> Right now, if you do like this:
>
> class Class;
> struct Struct;
> typedef Struct T;
>
> void f(Class *, Struct *);
> void g(T *);
>
> The external name of f and g will include some information that this
> proposal
> makes impossible to know.
>
> IA-64 mangling for g():
> _Z1g P6Struct (space mine, note the typedef was piereced)
>
> MSVC mangling for both:
> ?f@@YAX PAVClass@@ PAUStruct@@ @Z
> ?g@@YAX PAUStruct@@ @Z
> (space mine, note the U before Struct and V before Class)
>
> If the code above were:
>
> typename Class;
> typename Struct;
> typename T;
>
> Then how would the compiler know that Class is a class and Struct is a
> struct,
> and that T is the same as Struct?
>
First, let the mangling to the compiler producers.
the purpose is that the compiler does not care what 'T' or 'Class' ... is,
unless in a library private module. Anywhere else it only need know that T*
is a pointer to some unknown type.
take a look at classic 'FILE' type in standard C lib docs, and sqlite lib
for example. the client code does not care what 'FILE' or 'sqlite' is;
it only deals with FILE* or sqlite* . The definition is buried deeply
inside the private library modules which maybe not available in source form
to the application programmer. declaring such types with typename will not
change the semantics but rather relaxes the library programmer from early
decision about aspects that might change in future versions of the library.
The idea is to hide as much unnecessary details from application programmer
as possible.
regards,
FM.
> --
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c23ff638c68104f9d7302d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div style=3D"text-align:left"><br></div><div class=3D"gma=
il_extra"><div style=3D"text-align:left"><br></div><div style=3D"text-align=
:left"><br></div><div class=3D"gmail_quote"><div dir=3D"ltr">2014-05-20 20:=
28 GMT+04:30 Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailto:thiago=
@macieira.org" target=3D"_blank">thiago@macieira.org</a>></span>:</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 style=3D"text-align:left">Em ter 20 maio 2014, =C3=A0=
s 19:37:48, Farid Mehrabi escreveu:</div>
<div class=3D""><div style=3D"text-align:left">> > even if you could =
determine the bitwise composition of the pointer or</div><div style=3D"text=
-align:left">> > reference of this forward declared typename, you can=
't call a function</div>
<div style=3D"text-align:left">> > with it</div><div style=3D"text-al=
ign:left">> > and you can't use it in a template expansion. Some =
ABIs require encoding</div><div style=3D"text-align:left">> > the</di=
v>
<div style=3D"text-align:left">> > aggregate type (class, struct, enu=
m), and most ABIs will encode the</div><div style=3D"text-align:left">> =
> original,</div><div style=3D"text-align:left">> > non-typedef=
9;ed name.</div>
<div style=3D"text-align:left">></div><div style=3D"text-align:left">>=
; will encode ? ?</div>
<div style=3D"text-align:left"><br></div>
</div><div style=3D"text-align:left">They will encode because they do right=
now.</div>
<div class=3D""><div style=3D"text-align:left"><br></div><div style=3D"text=
-align:left">> no compiler is currently implementing this syntax, that`s=
the purpose of</div><div style=3D"text-align:left">> this post: we want=
future std compilers to be able to do it and we are</div>
<div style=3D"text-align:left">> discussing how to.</div>
<div style=3D"text-align:left"><br></div>
</div><div style=3D"text-align:left">Indeed. But please understand you'=
re asking every single compiler to break</div><div style=3D"text-align:left=
">their ABI. That is, to enable support for this feature, no program previo=
usly</div>
<div style=3D"text-align:left">compiled will link with new code.</div>
<div class=3D""><div style=3D"text-align:left"><br></div><div style=3D"text=
-align:left">> The general forward declaration syntax (the one with gene=
ric specifier</div><div style=3D"text-align:left">> 'typename') =
should instruct the compiler to choose the most conservative</div>
<div style=3D"text-align:left">> approach. I don`t how that`s gonna make=
any troubles.Unless you don`t use</div><div style=3D"text-align:left">>=
the value semantics compiler does not complain. the pointer/reference has<=
/div>
<div style=3D"text-align:left">> proper memory layout.</div>
<div style=3D"text-align:left"><br></div>
</div><div style=3D"text-align:left">Right now, if you do like this:</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">cla=
ss Class;</div><div style=3D"text-align:left">struct Struct;</div><div styl=
e=3D"text-align:left">typedef Struct T;</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">voi=
d f(Class *, Struct *);</div><div style=3D"text-align:left">void g(T *);</d=
iv>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">The=
external name of f and g will include some information that this proposal<=
/div><div style=3D"text-align:left">makes impossible to know.</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">IA-=
64 mangling for g():</div><div style=3D"text-align:left">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 _Z1g P6Struct =C2=A0 =C2=A0 (space mine, note the typedef was pi=
ereced)</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">MSV=
C mangling for both:</div><div style=3D"text-align:left">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 ?f@@YAX PAVClass@@ PAUStruct@@ @Z</div><div style=3D"text-align:=
left">=C2=A0 =C2=A0 =C2=A0 =C2=A0 ?g@@YAX PAUStruct@@ @Z</div>
<div style=3D"text-align:left">=C2=A0 =C2=A0 =C2=A0 =C2=A0 (space mine, not=
e the U before Struct and V before Class)</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">If =
the code above were:</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">typ=
ename Class;</div><div style=3D"text-align:left">typename Struct;</div><div=
style=3D"text-align:left">typename T;</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">The=
n how would the compiler know that Class is a class and Struct is a struct,=
</div><div style=3D"text-align:left">and that T is the same as Struct?</div=
>
<div class=3D""><div class=3D"h5"><div style=3D"text-align:left"></div></di=
v></div></blockquote><div><br></div><div style=3D"text-align:left" dir=3D"l=
tr">First, let the mangling to the compiler producers.</div><div style=3D"t=
ext-align:left" dir=3D"ltr">
<br></div><div style=3D"text-align:left" dir=3D"ltr">the purpose is that th=
e compiler does not care what 'T' or 'Class' ... is, unless=
in a library private module. Anywhere else it only need know that T* is a =
pointer to some unknown type.</div>
<div style=3D"text-align:left" dir=3D"ltr">take a look at classic 'FILE=
' type in standard C lib docs, and sqlite lib for example. the client c=
ode does not care what 'FILE' or 'sqlite' is;=C2=A0</div><d=
iv style=3D"text-align:left" dir=3D"ltr">
it only deals with FILE* or sqlite* . The definition is buried deeply insid=
e the private library modules which maybe not available in source form to t=
he application programmer. declaring such types with typename will not chan=
ge the semantics but rather relaxes the library programmer from early decis=
ion about aspects that might change in future versions of the library. The =
idea is to hide as much unnecessary details from application programmer as =
possible.</div>
<div style=3D"text-align:left" dir=3D"ltr"><br></div><div style=3D"text-ali=
gn:left" dir=3D"ltr">regards,</div><div style=3D"text-align:left" dir=3D"lt=
r">FM.</div><div style=3D"text-align:left" dir=3D"ltr"><br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">
<div class=3D""><div class=3D"h5"><div style=3D"text-align:left">--</div></=
div></div></blockquote></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 />
--001a11c23ff638c68104f9d7302d--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 20 May 2014 09:37:47 -0700
Raw View
Em ter 20 maio 2014, =E0s 20:45:09, Farid Mehrabi escreveu:
> First, let the mangling to the compiler producers.
And to standard writers who make changes that affect ABI. Standard develope=
rs=20
need at least to know that the feature they're proposing can be implemented=
..
> the purpose is that the compiler does not care what 'T' or 'Class' ... is=
,
> unless in a library private module. Anywhere else it only need know that =
T*
> is a pointer to some unknown type.
You do realise that you're asking that C++ drop backwards compatibility,=20
right?
That is, if I have an existing library already compiled and I want to use i=
t=20
in new code, I need to know what T is. Relaxing this requirement means the=
=20
compiler breaks compatibility.
Sure, the standard does know about libraries. But real life does. This feat=
ure=20
is major and invasive and it will unreasonably break existing code.
> take a look at classic 'FILE' type in standard C lib docs, and sqlite lib
> for example. the client code does not care what 'FILE' or 'sqlite' is;
> it only deals with FILE* or sqlite* . The definition is buried deeply
> inside the private library modules which maybe not available in source fo=
rm
> to the application programmer. declaring such types with typename will no=
t
> change the semantics but rather relaxes the library programmer from early
> decision about aspects that might change in future versions of the librar=
y.
> The idea is to hide as much unnecessary details from application programm=
er
> as possible.
Unfortunately, that's not the case. The compiler does care what FILE is=20
because it gets mangled in the C++ external name. (with glibc, FILE is a=20
typedef to struct _IO_FILE; on OS X, FILE is typedef to struct __sFILE)
--=20
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
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 20 May 2014 17:21:57 -0400
Raw View
On 2014-05-18 09:17, Farid Mehrabi wrote:
> Back to the OT: I think from a library creator sight this could be good
> idea for hiding the implementation of a type from the final programmer. The
> type is to be used in either ref or pointer form in user code and the
> client program does not need to know anything about its memory layout.
class Private;
void foo(Private*);
....still works AFAIK.
A better argument is that it's convenient to the API (and *ABI*) to be
able to declare "Private" without specifying if it is a class, struct,
or typedef. (This drives me nuts on occasion, where I have to include a
header that defines some typedef that is only ever referenced as a
pointer/reference/return, just because it *is* a typedef and so can't be
forward declared. Or worse, because it may or may not be a typedef,
depending on the platform.)
Of course the "gotcha" (as Thiago notes) is that the compiler won't know
how to mangle these if it never sees a definition (unless they're
"strong", but then the TU that emits the symbol using the typename would
also have to know that it's "strong", or the mangled names won't match
and will result in link errors). Though as implied by Farid, this may
rarely be a problem in practice.
I'm not convinced the alleged ABI breakage is as much of an issue as is
being stated, since the ABI only changes for users of the feature.
Presumably these are either brand new ABI's with nothing old to break,
or else the library authors that choose to switch to using the new
feature know what they are doing.
--
Matthew
--
---
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: Thiago Macieira <thiago@macieira.org>
Date: Tue, 20 May 2014 16:58:35 -0700
Raw View
Em ter 20 maio 2014, =E0s 17:21:57, Matthew Woehlke escreveu:
> I'm not convinced the alleged ABI breakage is as much of an issue as is
> being stated, since the ABI only changes for users of the feature.
> Presumably these are either brand new ABI's with nothing old to break,
> or else the library authors that choose to switch to using the new
> feature know what they are doing.
That only works if the new opaque definition exists for everyone and is use=
d=20
everywhere.
That is, if we have:
typename Foo;
typename Bar::type;
typename Baz;
typename FooBar;
Then *everyone* needs to see the typename, even those TUs that expand it=20
later:
// required even if "typename Bar" wasn't previously seen,=20
// due to typename Bar::type
typename struct Bar { typedef int type; };
typename class Foo : public Bar {};
typename class enum Baz { Frob =3D 0 };
typename typedef Foo FooBar;
Either the previous typename must be present or the extra keyword must.=20
Otherwise, the program is ill-formed. In this, it behaves like the noexcept=
=20
keyword.
Also note that typename typedef should only be allowed if opaque typedefs h=
ave=20
been standardised and their behaviour is well understood.=20
And finally, note the duplication of the typename keyword:
typename typedef typename ADL<T>::type type;
--=20
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
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Wed, 21 May 2014 19:09:13 +0430
Raw View
--001a113457dcfe425104f9e9f64d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2014-05-21 4:28 GMT+04:30 Thiago Macieira <thiago@macieira.org>:
> Em ter 20 maio 2014, =C3=A0s 17:21:57, Matthew Woehlke escreveu:
> > I'm not convinced the alleged ABI breakage is as much of an issue as is
> > being stated, since the ABI only changes for users of the feature.
> > Presumably these are either brand new ABI's with nothing old to break,
> > or else the library authors that choose to switch to using the new
> > feature know what they are doing.
>
> That only works if the new opaque definition exists for everyone and is
> used
> everywhere.
>
> That is, if we have:
>
> typename Foo;
> typename Bar::type;
> typename Baz;
> typename FooBar;
>
> Then *everyone* needs to see the typename, even those TUs that expand it
> later:
>
> // required even if "typename Bar" wasn't previously seen,
> // due to typename Bar::type
> typename struct Bar { typedef int type; };
>
> typename class Foo : public Bar {};
> typename class enum Baz { Frob =3D 0 };
>
>
typename typedef Foo FooBar;
>
>
Noooooooo:
///////////////////////////Public.h//////////////////////////
typename Private;
void PublicFoo(Private&);
//////////////////////////Private.h//////////////////////////
typedef XXXX Private;
//////////////////////////Private.c//////////////////////////
/* Output -> Private.a, Private.lib , Private.so, Private.dll*/
#include <Public.h>
#include <Private.h>
void PublicFoo(Private& ref)
{
//blah,blah....
};
///////////////////////////User.c/////////////////////////////
#include <Public.h>
void UserFoo(Private* ptr){PublicFoo(*ptr);};
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a113457dcfe425104f9e9f64d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div style=3D"text-align:left"><br></div><div class=3D"gma=
il_extra"><div style=3D"text-align:left"><br></div><div style=3D"text-align=
:left"><br></div><div class=3D"gmail_quote"><div dir=3D"ltr">2014-05-21 4:2=
8 GMT+04:30 Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailto:thiago@=
macieira.org" target=3D"_blank">thiago@macieira.org</a>></span>:</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 style=3D"text-align:left">Em ter 20 maio 2014, =C3=A0=
s 17:21:57, Matthew Woehlke escreveu:</div>
<div class=3D""><div style=3D"text-align:left">> I'm not convinced t=
he alleged ABI breakage is as much of an issue as is</div><div style=3D"tex=
t-align:left">> being stated, since the ABI only changes for users of th=
e feature.</div>
<div style=3D"text-align:left">> Presumably these are either brand new A=
BI's with nothing old to break,</div><div style=3D"text-align:left">>=
; or else the library authors that choose to switch to using the new</div>
<div style=3D"text-align:left">
> feature know what they are doing.</div>
<div style=3D"text-align:left"><br></div>
</div><div style=3D"text-align:left">That only works if the new opaque defi=
nition exists for everyone and is used</div><div style=3D"text-align:left">=
everywhere.</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">Tha=
t is, if we have:</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 typename Foo;</div><div style=3D"text-align:left">=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 typename Bar::type;</div><div style=3D"text-ali=
gn:left">=C2=A0 =C2=A0 =C2=A0 =C2=A0 typename Baz;</div><div style=3D"text-=
align:left">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 typename FooBar;</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">The=
n *everyone* needs to see the typename, even those TUs that expand it</div>=
<div style=3D"text-align:left">later:</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 // required even if "typename Bar" wasn&=
#39;t previously seen,</div><div style=3D"text-align:left">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // due to typename Bar::type</div>
<div style=3D"text-align:left">=C2=A0 =C2=A0 =C2=A0 =C2=A0 typename struct =
Bar { typedef int type; };</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 typename class Foo : public Bar {};</div><div styl=
e=3D"text-align:left">=C2=A0 =C2=A0 =C2=A0 =C2=A0 typename class enum Baz {=
Frob =3D 0 };</div><div style=3D"text-align:left">
=C2=A0=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex"><div style=3D"text-align:le=
ft"> =C2=A0 =C2=A0 =C2=A0 typename typedef Foo FooBar;</div>
<div style=3D"text-align:left"><br></div></blockquote><div style=3D"text-al=
ign:left" dir=3D"ltr"><br></div><div style=3D"text-align:left" dir=3D"ltr">=
Noooooooo:</div><div style=3D"text-align:left" dir=3D"ltr">////////////////=
///////////Public.h//////////////////////////</div>
<div style=3D"text-align:left" dir=3D"ltr">typename Private;</div><div styl=
e=3D"text-align:left" dir=3D"ltr">void PublicFoo(Private&);</div><div s=
tyle=3D"text-align:left" dir=3D"ltr"><br></div><div style=3D"text-align:lef=
t" dir=3D"ltr">
//////////////////////////Private.h//////////////////////////</div><div sty=
le=3D"text-align:left" dir=3D"ltr">typedef XXXX Private;<br></div><div styl=
e=3D"text-align:left" dir=3D"ltr"><br></div><div style=3D"text-align:left" =
dir=3D"ltr">
//////////////////////////Private.c//////////////////////////</div><div sty=
le=3D"text-align:left" dir=3D"ltr">/* Output -> Private.a, Private.lib ,=
Private.so, Private.dll*/</div><div style=3D"text-align:left" dir=3D"ltr">=
<div dir=3D"ltr">
#include <Public.h></div><div><div dir=3D"ltr">#include <Private.h=
></div></div><div>void PublicFoo(Private& ref)</div><div>{</div><div=
>=C2=A0 =C2=A0 =C2=A0 //blah,blah....</div><div>};</div><div><br></div><div=
>///////////////////////////User.c/////////////////////////////</div>
<div>#include <Public.h><br></div><div>void =C2=A0UserFoo(Private* pt=
r){PublicFoo(*ptr);};</div><div><br></div><div><br></div></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 />
--001a113457dcfe425104f9e9f64d--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 21 May 2014 08:15:54 -0700
Raw View
Em qua 21 maio 2014, =E0s 19:09:13, Farid Mehrabi escreveu:
> ///////////////////////////Public.h//////////////////////////
> typename Private;
> void PublicFoo(Private&);
>=20
> //////////////////////////Private.h//////////////////////////
> typedef XXXX Private;
>=20
> //////////////////////////Private.c//////////////////////////
> /* Output -> Private.a, Private.lib , Private.so, Private.dll*/
> #include <Public.h>
> #include <Private.h>
As long as that #include <Public.h> is present, you're still matching my=20
request.
> void PublicFoo(Private& ref)
> {
> //blah,blah....
> };
>=20
> ///////////////////////////User.c/////////////////////////////
> #include <Public.h>
> void UserFoo(Private* ptr){PublicFoo(*ptr);};
The above translates to:
=3D=3D=3D private.cpp =3D=3D=3D
typename Private;
typedef XXXX Private;
void PublicFoo(Private &ref) {}
=3D=3D=3D public.cpp =3D=3D=3D
typename Private;
void PublicFoo(Private &);
void UserFoo(Private *ptr) { PublicFoo(*ptr); }
=3D=3D=3D=3D
The above is could work.
However, if you remove the first line in the private source and make it lik=
e=20
so:
=3D=3D=3D private.cpp =3D=3D=3D
typedef XXXX Private;
void PublicFoo(Private &ref) {}
=3D=3D=3D=3D
Then the program is ill-formed.
--=20
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
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Wed, 21 May 2014 21:38:04 +0430
Raw View
--001a113457dc63796a04f9ec0b4b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2014-05-21 19:45 GMT+04:30 Thiago Macieira <thiago@macieira.org>:
> Em qua 21 maio 2014, =C3=A0s 19:09:13, Farid Mehrabi escreveu:
> > ///////////////////////////Public.h//////////////////////////
> > typename Private;
> > void PublicFoo(Private&);
> >
> > //////////////////////////Private.h//////////////////////////
> > typedef XXXX Private;
> >
> > //////////////////////////Private.c//////////////////////////
> > /* Output -> Private.a, Private.lib , Private.so, Private.dll*/
> > #include <Public.h>
> > #include <Private.h>
>
> As long as that #include <Public.h> is present, you're still matching my
> request.
>
> > void PublicFoo(Private& ref)
> > {
> > //blah,blah....
> > };
> >
> > ///////////////////////////User.c/////////////////////////////
> > #include <Public.h>
> > void UserFoo(Private* ptr){PublicFoo(*ptr);};
>
> The above translates to:
>
> =3D=3D=3D private.cpp =3D=3D=3D
> typename Private;
> typedef XXXX Private;
> void PublicFoo(Private &ref) {}
>
> =3D=3D=3D public.cpp =3D=3D=3D
> typename Private;
> void PublicFoo(Private &);
> void UserFoo(Private *ptr) { PublicFoo(*ptr); }
> =3D=3D=3D=3D
>
> The above is could work.
>
> However, if you remove the first line in the private source and make it
> like
> so:
>
> =3D=3D=3D private.cpp =3D=3D=3D
> typedef XXXX Private;
> void PublicFoo(Private &ref) {}
>
> =3D=3D=3D=3D
>
> Then the program is ill-formed.
>
>
That matters only If the layout of pointer is type-dependent. Name mangling
issues can be fixed by some sort of regexp magic in the linker design to be
able to match correct definitions. That sort of trick is already used in
embedded industry to enable optional definition of e.g interrupt handler
functions; if the user provides a definition for certain functions, the
default definition is rejected.
--=20
how am I supposed to end the twisted road of your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a113457dc63796a04f9ec0b4b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><br><div class=3D"gmail_extra"><div style=3D"text-align:le=
ft"><br></div><div style=3D"text-align:left"><br></div><div class=3D"gmail_=
quote"><div dir=3D"ltr">2014-05-21 19:45 GMT+04:30 Thiago Macieira <span di=
r=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thia=
go@macieira.org</a>></span>:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"text-align:left">Em qua 21 mai=
o 2014, =C3=A0s 19:09:13, Farid Mehrabi escreveu:</div>
<div class=3D""><div style=3D"text-align:left">> ///////////////////////=
////Public.h//////////////////////////</div><div style=3D"text-align:left">=
> typename Private;</div><div style=3D"text-align:left">> void Public=
Foo(Private&);</div>
<div style=3D"text-align:left">></div><div style=3D"text-align:left">>=
; //////////////////////////Private.h//////////////////////////</div><div s=
tyle=3D"text-align:left">> typedef XXXX Private;</div><div style=3D"text=
-align:left">
></div><div style=3D"text-align:left">> //////////////////////////Pri=
vate.c//////////////////////////</div><div style=3D"text-align:left">> /=
* Output -> Private.a, Private.lib , Private.so, Private.dll*/</div><div=
style=3D"text-align:left">
> #include <Public.h></div><div style=3D"text-align:left">> #in=
clude <Private.h></div>
<div style=3D"text-align:left"><br></div>
</div><div style=3D"text-align:left">As long as that #include <Public.h&=
gt; is present, you're still matching my</div><div style=3D"text-align:=
left">request.</div>
<div class=3D""><div style=3D"text-align:left"><br></div><div style=3D"text=
-align:left">> void PublicFoo(Private& ref)</div><div style=3D"text-=
align:left">> {</div><div style=3D"text-align:left">> =C2=A0 =C2=A0 =
=C2=A0 //blah,blah....</div>
<div style=3D"text-align:left">> };</div><div style=3D"text-align:left">=
></div><div style=3D"text-align:left">> ///////////////////////////Us=
er.c/////////////////////////////</div><div style=3D"text-align:left">> =
#include <Public.h></div>
<div style=3D"text-align:left">> void =C2=A0UserFoo(Private* ptr){Public=
Foo(*ptr);};</div>
<div style=3D"text-align:left"><br></div>
</div><div style=3D"text-align:left">The above translates to:</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">=3D=
=3D=3D private.cpp =3D=3D=3D</div><div style=3D"text-align:left">typename P=
rivate;</div><div style=3D"text-align:left">typedef XXXX Private;</div><div=
style=3D"text-align:left">
void PublicFoo(Private &ref) {}</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">=3D=
=3D=3D public.cpp =3D=3D=3D</div><div style=3D"text-align:left">typename Pr=
ivate;</div><div style=3D"text-align:left">void PublicFoo(Private &);</=
div><div style=3D"text-align:left">
void UserFoo(Private *ptr) { PublicFoo(*ptr); }</div><div style=3D"text-ali=
gn:left">=3D=3D=3D=3D</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">The=
above is could work.</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">How=
ever, if you remove the first line in the private source and make it like</=
div><div style=3D"text-align:left">so:</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">=3D=
=3D=3D private.cpp =3D=3D=3D</div><div style=3D"text-align:left">typedef XX=
XX Private;</div><div style=3D"text-align:left">void PublicFoo(Private &=
;ref) {}</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">=3D=
=3D=3D=3D</div>
<div style=3D"text-align:left"><br></div><div style=3D"text-align:left">The=
n the program is ill-formed.</div>
<div class=3D"HOEnZb"><div class=3D"h5"><div style=3D"text-align:left"><br>=
</div></div></div></blockquote><div><br></div><div style=3D"text-align:left=
" dir=3D"ltr">That matters only If the layout of pointer is type-dependent.=
Name mangling issues can be fixed by some sort of regexp magic in the link=
er design to be able to match correct definitions. That sort of trick is al=
ready used in embedded industry to enable optional definition of e.g interr=
upt handler functions; if the user provides a definition for certain functi=
ons, the default definition is rejected.</div>
<div>=C2=A0</div></div><div style=3D"text-align:left">--=C2=A0</div><div di=
r=3D"ltr">how am I supposed to end the twisted road of=C2=A0 your hair in t=
he dark night??<br>unless the candle of your face does turn a lamp up on my=
way!!!<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 />
--001a113457dc63796a04f9ec0b4b--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 21 May 2014 11:04:53 -0700
Raw View
Em qua 21 maio 2014, =E0s 21:38:04, Farid Mehrabi escreveu:
> > =3D=3D=3D public.cpp =3D=3D=3D
> > typename Private;
> > void PublicFoo(Private &);
> > void UserFoo(Private *ptr) { PublicFoo(*ptr); }
> > =3D=3D=3D=3D
[snip]
> > However, if you remove the first line in the private source and make it
> > like
> > so:
> >=20
> > =3D=3D=3D private.cpp =3D=3D=3D
> > typedef XXXX Private;
> > void PublicFoo(Private &ref) {}
> >=20
> > =3D=3D=3D=3D
> >=20
> > Then the program is ill-formed.
>=20
> That matters only If the layout of pointer is type-dependent. Name mangli=
ng
> issues can be fixed by some sort of regexp magic in the linker design to =
be
> able to match correct definitions. That sort of trick is already used in
> embedded industry to enable optional definition of e.g interrupt handler
> functions; if the user provides a definition for certain functions, the
> default definition is rejected.
I suggest you reconsider.
Symbols aren't matched just at the traditional link time. Run-time linking =
is=20
very important and performance-critical. Doing fuzzy matches at runtime is=
=20
going to incur non-trivial cost.
And besides, I don't think it's even possible. Suppose we have the source f=
ile=20
above compiled into a library. Since the source didn't list "typename Priva=
te"=20
anywhere, the typedef is a traditional one, from the depths of C++ history=
=20
(not an opaque one). As such, the source file has a symbol for:
"void PublicFoo(XXXX &)"
just to make matters a little more complex, let's say there's an overload:
"void PublicFoo(YYYY &)"
Now we have the public.cpp source compiled with the new feature, which is=
=20
requesting the symbol:
"void PublicFoo(Private &)"
Please explain which algorithm will allow the compiler, linker and/or dynam=
ic=20
linker to realise that Private =3D=3D XXXX.
--=20
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
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 21 May 2014 14:32:39 -0400
Raw View
On 2014-05-21 14:04, Thiago Macieira wrote:
> Please explain which algorithm will allow the compiler, linker and/or dynamic
> linker to realise that Private == XXXX.
Are symbol aliases allowed?
What if we just exported the symbol under all possible names?
IOW, given:
class foo;
using bar = foo;
typename bar;
void my(bar&);
....we would have symbol aliases for both my(typename bar) and my(class
foo), which would be the same entry point.
--
Matthew
--
---
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: Magnus Fromreide <magfr@lysator.liu.se>
Date: Thu, 22 May 2014 08:49:12 +0200
Raw View
On Wed, May 21, 2014 at 07:09:13PM +0430, Farid Mehrabi wrote:
> 2014-05-21 4:28 GMT+04:30 Thiago Macieira <thiago@macieira.org>:
>=20
> > Em ter 20 maio 2014, =E0s 17:21:57, Matthew Woehlke escreveu:
> > > I'm not convinced the alleged ABI breakage is as much of an issue as =
is
> > > being stated, since the ABI only changes for users of the feature.
> > > Presumably these are either brand new ABI's with nothing old to break=
,
> > > or else the library authors that choose to switch to using the new
> > > feature know what they are doing.
> >
> > That only works if the new opaque definition exists for everyone and is
> > used
> > everywhere.
> >
> > That is, if we have:
> >
> > typename Foo;
> > typename Bar::type;
> > typename Baz;
> > typename FooBar;
> >
> > Then *everyone* needs to see the typename, even those TUs that expand i=
t
> > later:
> >
> > // required even if "typename Bar" wasn't previously seen,
> > // due to typename Bar::type
> > typename struct Bar { typedef int type; };
> >
> > typename class Foo : public Bar {};
> > typename class enum Baz { Frob =3D 0 };
> >
> >
> typename typedef Foo FooBar;
> >
> >
> Noooooooo:
> ///////////////////////////Public.h//////////////////////////
> typename Private;
> void PublicFoo(Private&);
>=20
> //////////////////////////Private.h//////////////////////////
> typedef XXXX Private;
>=20
> //////////////////////////Private.c//////////////////////////
> /* Output -> Private.a, Private.lib , Private.so, Private.dll*/
> #include <Public.h>
> #include <Private.h>
> void PublicFoo(Private& ref)
> {
> //blah,blah....
> };
>=20
> ///////////////////////////User.c/////////////////////////////
> #include <Public.h>
> void UserFoo(Private* ptr){PublicFoo(*ptr);};
Would
/// Public.hpp
struct Private;
void PublicFoo(Private&);
/// Private.hpp
struct Private { XXXX value; };
/// Private.cpp
/* Output -> Private.a, Private.lib , Private.so, Private.dll*/
#include <Public.h>
#include <Private.h>
void PublicFoo(Private& ref)
{
//blah,blah...., but with ref.value rather than ref.
};
/// User.c
include <Public.h>
void UserFoo(Private* ptr){PublicFoo(*ptr);}
really be bad enough to warrant a change to the standard that have great
potential to affect the various ABIs.
The lesson from this is to never ever use typedefs in interfaces and allow
forward declaration of non-template structs from the std namespace.
Thus
namespace std { struct string : basic_string<char> { using basic_string; };=
}
instead of
namespace std { using string =3D std::basic_string<char>; }
would have saved immense amounts of preprocessing time as the former is
trivial to forward declare while the latter requires a declaration of
basic_string to forward declare.
Yes, I see why the standard isn't written like this, with the "good" form
using C++11 features or reeated constructors, but it would have been better=
..
/MF
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: walter1234 <walter2bz@gmail.com>
Date: Sun, 15 Jun 2014 05:15:21 -0700 (PDT)
Raw View
------=_Part_497_356091.1402834521600
Content-Type: text/plain; charset=UTF-8
I like this idea.
Would it be possible to use 'typename' for this?
typename foo;
void Bar(foo& .. );
// would that also be useful for disambiguating parse information in some
contexts,
// e.g. you now know "foo *a;" is a variable declaration not a call to
operator *, without having parsed the full definition of foo from a header
yet.
--
---
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_497_356091.1402834521600
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I like this idea.</div>Would it be possible to use 't=
ypename' for this?<div><br></div><div>typename foo;</div><div>void Bar(foo&=
amp; .. );</div><div><br></div><div>// would that also be useful for disamb=
iguating parse information in some contexts, </div><div>// e.g. you no=
w know "foo *a;" is a variable declaration not a call to operator *, =
without having parsed the full definition of foo from a header yet. </=
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_497_356091.1402834521600--
.