Topic: Dot for pointer dereferencing


Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 9 Mar 2015 05:56:26 -0700 (PDT)
Raw View
------=_Part_67_2109393769.1425905786324
Content-Type: multipart/alternative;
 boundary="----=_Part_68_1921030907.1425905786324"

------=_Part_68_1921030907.1425905786324
Content-Type: text/plain; charset=UTF-8

References use . to access members, pointers use -> to access 'members'.
One frequently has pointer variables / parameters that are known to be not
non-NULL.
Being able to use . would (slightly) simplify the code and remove an
unnecessary difference between pointers and references.
You'd also no longer have to swap . and -> when the type changes for
whatever reason.
There's an issue with smart pointers but that might be solved when
operator. overloading is allowed.

--

---
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_68_1921030907.1425905786324
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">References use . to access members, pointers use -&gt; to =
access 'members'. One frequently has pointer variables / parameters that ar=
e known to be not non-NULL.&nbsp;<div>Being able to use . would (slightly) =
simplify the code and remove an unnecessary difference between pointers and=
 references.</div><div>You'd also no longer have to swap . and -&gt; when t=
he type changes for whatever reason.</div><div>There's an issue with smart =
pointers but that might be solved when operator. overloading is allowed.</d=
iv></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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_68_1921030907.1425905786324--
------=_Part_67_2109393769.1425905786324--

.


Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 09 Mar 2015 12:32:08 -0400
Raw View
On 2015-03-09 08:56, Olaf van der Spek wrote:
> References use . to access members, pointers use -> to access 'members'.
> One frequently has pointer variables / parameters that are known to be not
> non-NULL.
> Being able to use . would (slightly) simplify the code and remove an
> unnecessary difference between pointers and references.
> You'd also no longer have to swap . and -> when the type changes for
> whatever reason.
> There's an issue with smart pointers but that might be solved when
> operator. overloading is allowed.

Do you mean for *bare* pointers (e.g. "int*"), or for pointer-like
classes (e.g. std::unique_ptr)? If the latter, how would you
differentiate between members of the pointer class, and members of the
contained class?

(If you "know" that a pointer is non-null, why not just use a reference
instead in the first place?)

--
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: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Mon, 9 Mar 2015 12:33:26 -0400
Raw View
--001a1140e85ef49f6d0510dd97e4
Content-Type: text/plain; charset=UTF-8

void f(T *notNull) {
   T & theArg = *notNull;
// use . as desired within the function

On Mon, Mar 9, 2015 at 12:32 PM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:

> On 2015-03-09 08:56, Olaf van der Spek wrote:
> > References use . to access members, pointers use -> to access 'members'.
> > One frequently has pointer variables / parameters that are known to be
> not
> > non-NULL.
> > Being able to use . would (slightly) simplify the code and remove an
> > unnecessary difference between pointers and references.
> > You'd also no longer have to swap . and -> when the type changes for
> > whatever reason.
> > There's an issue with smart pointers but that might be solved when
> > operator. overloading is allowed.
>
> Do you mean for *bare* pointers (e.g. "int*"), or for pointer-like
> classes (e.g. std::unique_ptr)? If the latter, how would you
> differentiate between members of the pointer class, and members of the
> contained class?
>
> (If you "know" that a pointer is non-null, why not just use a reference
> instead in the first place?)
>
> --
> 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/.
>

--

---
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/.

--001a1140e85ef49f6d0510dd97e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">void f(T *notNull) {<br>=C2=A0 =C2=A0T &amp; theArg =3D *n=
otNull;<br>// use . as desired within the function</div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Mon, Mar 9, 2015 at 12:32 PM, Mat=
thew Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mw_triad@users.sourcef=
orge.net" target=3D"_blank">mw_triad@users.sourceforge.net</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2015-03-09 08:5=
6, Olaf van der Spek wrote:<br>
&gt; References use . to access members, pointers use -&gt; to access &#39;=
members&#39;.<br>
&gt; One frequently has pointer variables / parameters that are known to be=
 not<br>
&gt; non-NULL.<br>
&gt; Being able to use . would (slightly) simplify the code and remove an<b=
r>
&gt; unnecessary difference between pointers and references.<br>
&gt; You&#39;d also no longer have to swap . and -&gt; when the type change=
s for<br>
&gt; whatever reason.<br>
&gt; There&#39;s an issue with smart pointers but that might be solved when=
<br>
&gt; operator. overloading is allowed.<br>
<br>
</span>Do you mean for *bare* pointers (e.g. &quot;int*&quot;), or for poin=
ter-like<br>
classes (e.g. std::unique_ptr)? If the latter, how would you<br>
differentiate between members of the pointer class, and members of the<br>
contained class?<br>
<br>
(If you &quot;know&quot; that a pointer is non-null, why not just use a ref=
erence<br>
instead in the first place?)<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--001a1140e85ef49f6d0510dd97e4--

.


Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 9 Mar 2015 17:48:04 +0100
Raw View
2015-03-09 17:32 GMT+01:00 Matthew Woehlke <mw_triad@users.sourceforge.net>:
> On 2015-03-09 08:56, Olaf van der Spek wrote:
>> References use . to access members, pointers use -> to access 'members'.
>> One frequently has pointer variables / parameters that are known to be not
>> non-NULL.
>> Being able to use . would (slightly) simplify the code and remove an
>> unnecessary difference between pointers and references.
>> You'd also no longer have to swap . and -> when the type changes for
>> whatever reason.
>> There's an issue with smart pointers but that might be solved when
>> operator. overloading is allowed.
>
> Do you mean for *bare* pointers (e.g. "int*"), or for pointer-like
> classes (e.g. std::unique_ptr)? If the latter, how would you
> differentiate between members of the pointer class, and members of the
> contained class?

I mean raw pointers (at first). Having it for smart pointers too would
be a bonus but that has the obvious problem you and I already
mentioned.

> (If you "know" that a pointer is non-null, why not just use a reference
> instead in the first place?)

Code might look like:
if (p)
  cout << p->name << endl;

Or I might have a container of raw/shared/unique pointers.




--
Olaf

--

---
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: mayorga.geek@gmail.com
Date: Sun, 5 Apr 2015 23:39:23 -0700 (PDT)
Raw View
------=_Part_2368_873406111.1428302363929
Content-Type: multipart/alternative;
 boundary="----=_Part_2369_1285780332.1428302363930"

------=_Part_2369_1285780332.1428302363930
Content-Type: text/plain; charset=UTF-8

I regret I started the same topic in another thread before knowing the
existence of this one.
this other:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/-davlkCsBZo

glad to know there are more syntax unification supporters.. ; >


On Monday, March 9, 2015 at 1:56:26 PM UTC+1, Olaf van der Spek wrote:
>
> References use . to access members, pointers use -> to access 'members'.
> One frequently has pointer variables / parameters that are known to be not
> non-NULL.
> Being able to use . would (slightly) simplify the code and remove an
> unnecessary difference between pointers and references.
> You'd also no longer have to swap . and -> when the type changes for
> whatever reason.
> There's an issue with smart pointers but that might be solved when
> operator. overloading is allowed.
>

--

---
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_2369_1285780332.1428302363930
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I regret I started the same topic in another thread before=
 knowing the existence of this one. <br>this other: <br>https://groups.goog=
le.com/a/isocpp.org/forum/#!topic/std-discussion/-davlkCsBZo<br><br>glad to=
 know there are more syntax unification supporters.. ; &gt;<br><br><br>On M=
onday, March 9, 2015 at 1:56:26 PM UTC+1, Olaf van der Spek wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">References use . to ac=
cess members, pointers use -&gt; to access 'members'. One frequently has po=
inter variables / parameters that are known to be not non-NULL.&nbsp;<div>B=
eing able to use . would (slightly) simplify the code and remove an unneces=
sary difference between pointers and references.</div><div>You'd also no lo=
nger have to swap . and -&gt; when the type changes for whatever reason.</d=
iv><div>There's an issue with smart pointers but that might be solved when =
operator. overloading is allowed.</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&quot; 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_2369_1285780332.1428302363930--
------=_Part_2368_873406111.1428302363929--

.