Topic: std::optional models (was: std::optional --
Author: Chris Jefferson <chris@bubblescope.net>
Date: Thu, 31 Jan 2013 15:34:41 +0000
Raw View
This is a multi-part message in MIME format.
--------------060509060300000705070706
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 31/01/13 15:16, Olaf van der Spek wrote:
> Op donderdag 31 januari 2013 10:27:36 UTC+1 schreef Nevin ":-)" Liber
> het volgende:
>
> For the record, I am strongly for a disengaged optional to be less
> than an engaged optional, and ==, !=, <, >, <=, >= to all be well
> defined (when they are well defined for T) for direct comparison.
> I'm also for defining all comparisons between optional<T> and T.
>
>
> Then maybe you should address the concerns others have.
>
> optional<int> is quite like int* if we consider the const interface.
> Both are empty/null or have a value. Yet you can't compare int* with
> int directly. You also either compare the pointers or the pointees,
> not both at the same time.
I realise this is a very long thread at this point, but I wish to
re-raise a point which has been made earlier.
Personally, I feel the important issue is the T -> optional<T> implicit
conversion.
Simply "poisioning" some subset of operators is covering a very small
part of all the places where the T -> optional<T> conversion could take
place.
Personally I am in favour of an implicit T -> optional<T> conversion,
but I can understand why some people would not be. What I am against is
choosing one very small place where this conversion takes effect
(ordering operators) and stopping just that one place.
Chris
--
---
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/?hl=en.
--------------060509060300000705070706
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 31/01/13 15:16, Olaf van der Spek
wrote:<br>
</div>
<blockquote
cite="mid:48d1c130-c263-4c01-861b-107ee1188cdc@isocpp.org"
type="cite">Op donderdag 31 januari 2013 10:27:36 UTC+1 schreef
Nevin ":-)" Liber het volgende:<br>
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div class="gmail_quote">
<div>For the record, I am strongly for a disengaged optional
to be less than an engaged optional, and ==, !=, <, >,
<=, >= to all be well defined (when they are well
defined for T) for direct comparison. I'm also for defining
all comparisons between optional<T> and T.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Then maybe you should address the concerns others have.</div>
<div><br>
</div>
<div>optional<int> is quite like int* if we consider the
const interface. Both are empty/null or have a value. Yet you
can't compare int* with int directly. You also either compare
the pointers or the pointees, not both at the same time.</div>
</blockquote>
<br>
I realise this is a very long thread at this point, but I wish to
re-raise a point which has been made earlier.<br>
<br>
Personally, I feel the important issue is the T ->
optional<T> implicit conversion.<br>
<br>
Simply "poisioning" some subset of operators is covering a very
small part of all the places where the T -> optional<T>
conversion could take place.<br>
<br>
Personally I am in favour of an implicit T -> optional<T>
conversion, but I can understand why some people would not be. What
I am against is choosing one very small place where this conversion
takes effect (ordering operators) and stopping just that one place.<br>
<br>
Chris<br>
</body>
</html>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------060509060300000705070706--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 31 Jan 2013 16:48:15 -0600
Raw View
--047d7b5da2a580e86b04d49d6e41
Content-Type: text/plain; charset=ISO-8859-1
On 31 January 2013 09:16, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Then maybe you should address the concerns others have.
*optional<T> relop optional<T>
*
A cursory look at n3485 shows the following types as supporting all the
relops:
pair
tuple
unique_ptr
shared_ptr
duration
time_point
type_index
basic_string
array
deque
forward_list
list
vector
map
multimap
set
multiset
queue
stack
reverse_iterator
move_iterator
val_array
sub_match
thread::id
Other than raw pointers on some implementations (again, where they have to
be because C doesn't guarantee a total ordering for pointers), what
standard types just specialize std::less and not allow the expression x < y?
I am unconvinced that the problematic cases are that problematic in
practice.
Not providing optional<T> relop optional<T> is *a deal breaker for me*. It
breaks user expectations. It does not fit in with the rest of the standard
library. It means that optional does not play well with the rest of the
standard library. I don't know how to rationally explain:
vector<optional<T>> v;
sort(v.beginI(), v.end()); // works
sort(v.begin(), v.end(), std::greater<optional<T>>()); // doesn't work
sort(v.begin(), v.end(), [](optional<T> const& l, optional<T> const& r){
return l > r; }); // doesn't work
*optional<T> relop T:
*
While this one isn't a deal breaker for me, I'm still strongly for it.
Standard templated types that allow mixed comparison with their underlying
types:
atomic
valarray
And as I mentioned before, people are looking to add this functionality to
other things in the standard (such as map lookup), so clearly there is a
desire for it. People don't want to pay the construction cost just to do a
comparison. Heck, that is why std::string allows a comparison against
const char* (and there are many other examples in the standard library like
this).
I am also unconvinced here that the problematic cases are that problematic
in practice.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--047d7b5da2a580e86b04d49d6e41
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 31 January 2013 09:16, Olaf van der Spek <<a href=3D"mailto:olafvdspe=
k@gmail.com">olafvdspek@gmail.com</a>> wrote:<br>> Then maybe you sho=
uld address the concerns others have.<br><br><b>optional<T> relop opt=
ional<T><br>
</b><br>A cursory look at n3485 shows the following types as supporting all=
the relops:<br><br>pair<div>tuple</div><div>unique_ptr</div><div>shared_pt=
r</div><div>duration</div><div>time_point</div><div>type_index</div><div>
basic_string</div><div>array</div><div>deque</div><div>forward_list</div><d=
iv>list</div><div>vector</div><div>map</div><div>multimap</div><div>set</di=
v><div>multiset</div><div>queue</div><div>stack</div><div>reverse_iterator<=
/div>
<div>move_iterator</div><div>val_array</div><div>sub_match</div><div>thread=
::id<br><br>Other than raw pointers on some implementations (again, where t=
hey have to be because C doesn't guarantee a total ordering for pointer=
s), what standard types just specialize std::less and not allow the express=
ion x < y?<br>
<br>I am unconvinced that the problematic cases are that problematic in pra=
ctice.<br><br>Not providing optional<T> relop optional<T> is <i=
>a deal breaker for me</i>. =A0It breaks user expectations. =A0It does not =
fit in with the rest of the standard library. =A0It means that optional doe=
s not play well with the rest of the standard library. =A0I don't know =
how to rationally explain:<br>
<br>vector<optional<T>> v;<br>sort(v.beginI(), v.end()); // wor=
ks<br>sort(v.begin(), v.end(), std::greater<optional<T>>()); =
=A0// doesn't work</div><div>sort(v.begin(), v.end(),=A0=A0[](optional&=
lt;T> const& l, optional<T> const& r){ return l > r; })=
; // doesn't work</div>
<div><br><br><b>optional<T> relop T:<br></b><br>While this one isn=
9;t a deal breaker for me, I'm still strongly for it.</div><div><br></d=
iv><div>Standard templated types that allow mixed comparison with their und=
erlying types:</div>
<div><br></div><div>atomic</div><div>valarray<br><br>And as I mentioned bef=
ore, people are looking to add this functionality to other things in the st=
andard (such as map lookup), so clearly there is a desire for it. =A0People=
don't want to pay the construction cost just to do a comparison. =A0He=
ck, that is why std::string allows a comparison against const char* (and th=
ere are many other examples in the standard library like this).</div>
<div><br></div><div>I am also unconvinced here that the problematic cases a=
re that problematic in practice.<br>--=A0<br>=A0Nevin ":-)" Liber=
=A0<mailto:<a href=3D"mailto:nevin@eviloverlord.com">nevin@eviloverlord=
..com</a>> =A0(847) 691-1404<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b5da2a580e86b04d49d6e41--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 1 Feb 2013 00:37:24 -0500
Raw View
On Thu, Jan 31, 2013 at 5:48 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 31 January 2013 09:16, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> Then maybe you should address the concerns others have.
>
> optional<T> relop optional<T>
>
> A cursory look at n3485 shows the following types as supporting all the
> relops:
>
> pair
> tuple
> unique_ptr
> shared_ptr
> duration
> time_point
> type_index
> basic_string
> array
> deque
> forward_list
> list
> vector
> map
> multimap
> set
> multiset
> queue
> stack
> reverse_iterator
> move_iterator
> val_array
> sub_match
> thread::id
>
I think that's a worthwhile list, thanks!
> Other than raw pointers on some implementations (again, where they have to
> be because C doesn't guarantee a total ordering for pointers), what standard
> types just specialize std::less and not allow the expression x < y?
>
> I am unconvinced that the problematic cases are that problematic in
> practice.
>
> Not providing optional<T> relop optional<T> is a deal breaker for me. It
> breaks user expectations. It does not fit in with the rest of the standard
> library. It means that optional does not play well with the rest of the
> standard library. I don't know how to rationally explain:
>
> vector<optional<T>> v;
> sort(v.beginI(), v.end()); // works
> sort(v.begin(), v.end(), std::greater<optional<T>>()); // doesn't work
If std::less<> was overloaded, I'd expect std::greater would be as
well. ie // works
> sort(v.begin(), v.end(), [](optional<T> const& l, optional<T> const& r){
> return l > r; }); // doesn't work
>
opt > opt doesn't actually bother me, but if it wasn't there I think I
could rationally explain it - "was deemed dangerous; see this giant
discussion. :-) std::less is there because it is useful, and less
dangerous"
I have yet to find anything in the proposal a deal breaker. We could
decide any way on any of these secondary issues and I'd still vote for
it.
>
> optional<T> relop T:
>
> While this one isn't a deal breaker for me, I'm still strongly for it.
>
> Standard templated types that allow mixed comparison with their underlying
> types:
>
> atomic
atomic<T> < T makes some sense as they share the same range of values.
That is not the same as optional<T> and T. ie there is no arbitrary
decision involved on how to order T with atomic<T>.
Also, atomic<T> relop atomic<T> is not an atomic operation. I thought
atomics didn't even have relops, for this very reason.
> valarray
>
valarray<T> relop T returns a valarray<bool>. I don't see how this
compares to optional, or if it does how it helps your argument. But
maybe you listed it just "for completeness".
> And as I mentioned before, people are looking to add this functionality to
> other things in the standard (such as map lookup), so clearly there is a
> desire for it.
"we'll allow mixed relops when you have defined those mixed relops"
!=
"we'll define mixed relops for you"
> People don't want to pay the construction cost just to do a
> comparison.
construction cost not necessary. More likely will be opt ? *opt < val
: false, etc. Which has clarity.
Whenever I view code and see opt < val, or even opt != val, I will
wonder whether the developer really meant that, or just got lucky that
it works in the nullopt case (or unlucky, and we are just realizing
that it doesn't work). One tells me the developer was aware, the
other doesn't. Maybe I should trust my fellow developers (including
myself, looking at my own code)? I don't think I can (or should) do
that. Because I suspect opt < T will be rarely used, I don't think I
should expect them to know it, ie knowing the behaviour of every
corner of the standard.
> Heck, that is why std::string allows a comparison against const
> char* (and there are many other examples in the standard library like this).
>
string and char *, again have the same range of values. Actually that
is not true, as std::string can hold internal nulls. But I don't
think that is as essential as nullopt is for optional.
> I am also unconvinced here that the problematic cases are that problematic
> in practice.
>
To me it hasn't been as much about problems. Or that is only
secondary. To me it is about principles. I just don't think
optional<T> relop T is optional's decision to make. But since I can
override it for particular Ts as needed, I'd say I'm only mildly
against. I do think it might be problematic, but more that it is
unprincipled. But I could live with it. I can even convince myself
that it is somewhat principled, as T converts to optional<T> so the
mixed relops just show up for free. But my gut says it shouldn't.
Tony
--
---
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/?hl=en.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 01 Feb 2013 08:22:02 +0100
Raw View
This is a multi-part message in MIME format.
--------------070403000105090007080704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 31/01/13 23:48, Nevin Liber a =E9crit :
> On 31 January 2013 09:16, Olaf van der Spek <olafvdspek@gmail.com=20
> <mailto:olafvdspek@gmail.com>> wrote:
> > Then maybe you should address the concerns others have.
>
> *optional<T> relop optional<T>
> *
> A cursory look at n3485 shows the following types as supporting all=20
> the relops:
>
> pair
> tuple
> unique_ptr
> shared_ptr
> duration
> time_point
> type_index
> basic_string
> array
> deque
> forward_list
> list
> vector
> map
> multimap
> set
> multiset
> queue
> stack
> reverse_iterator
> move_iterator
> val_array
> sub_match
> thread::id
>
> Other than raw pointers on some implementations (again, where they=20
> have to be because C doesn't guarantee a total ordering for pointers),=20
> what standard types just specialize std::less and not allow the=20
> expression x < y?
>
Which types on the list above have an underlying type that is implicitly=20
convertible to the type? The closer I can see is initialization from a=20
list initializer.
> I am unconvinced that the problematic cases are that problematic in=20
> practice.
>
> Not providing optional<T> relop optional<T> is /a deal breaker for=20
> me/. It breaks user expectations. It does not fit in with the rest=20
> of the standard library. It means that optional does not play well=20
> with the rest of the standard library. I don't know how to rationally=20
> explain:
>
> vector<optional<T>> v;
> sort(v.beginI(), v.end()); // works
> sort(v.begin(), v.end(), std::greater<optional<T>>()); // doesn't work
> sort(v.begin(), v.end(), [](optional<T> const& l, optional<T> const&=20
> r){ return l > r; }); // doesn't work
>
>
I agree, optional<T> relop optional<T> must be in. There is no question=20
about this.
> *optional<T> relop T:
> *
> While this one isn't a deal breaker for me, I'm still strongly for it.
>
> Standard templated types that allow mixed comparison with their=20
> underlying types:
>
> atomic
> valarray
>
Maybe it is worth noting the curious semantic of the relop on valarray
"26.6.3.2 valarray logical operators
template<class T> valarray<bool> operator=3D=3D(const valarray<T>&, const T=
&);
template<class T> valarray<bool> operator=3D=3D(const T&, const valarray<T>=
&);
template<class T> valarray<bool> operator!=3D(const valarray<T>&, const T&)=
;
template<class T> valarray<bool> operator!=3D(const T&, const valarray<T>&)=
;
template<class T> valarray<bool> operator< (const valarray<T>&, const T&);
template<class T> valarray<bool> operator< (const T&, const valarray<T>&);
....
4 Each of these operators may only be instantiated for a type T to which=20
the indicated operator can be
applied and for which the indicated operator returns a value which is of=20
type bool or which can be
unambiguously implicitly converted to type bool.
5 Each of these operators returns a bool array whose length is equal to=20
the length of the array argument.
Each element of the returned array is initialized with the result of=20
applying the indicated operator to
the corresponding element of the array and the non-array argument."
> And as I mentioned before, people are looking to add this=20
> functionality to other things in the standard (such as map lookup), so=20
> clearly there is a desire for it. People don't want to pay the=20
> construction cost just to do a comparison. Heck, that is why=20
> std::string allows a comparison against const char* (and there are=20
> many other examples in the standard library like this).
>
> I am also unconvinced here that the problematic cases are that=20
> problematic in practice.
IMHO, as far as optional<T> is implicitly convertible from T, defining=20
mixed relop is a matter of optimization. I we admit implicit conversion,=20
poisoning them could be surprising. Would this poisoning on the standard=20
a suggestion for the user to poison his functions taking an optional?
I'm against the implicit conversion, and I would prefer implicit=20
conversion from a initializer list (restricted to one element) but once=20
we admit implicit conversion we should make the whole design coherent=20
and poisoning doesn't helps in this sens.
Best,
Vicente
--=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/?hl=3Den.
--------------070403000105090007080704
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 31/01/13 23:48, Nevin Liber a
écrit :<br>
</div>
<blockquote
cite="mid:CAGg_6+Pn21JP1TiqQeAOf+z8+Qzz-LnL226ufxfT+62nR7kcMg@mail.gmail.com"
type="cite">On 31 January 2013 09:16, Olaf van der Spek <<a
moz-do-not-send="true" href="mailto:olafvdspek@gmail.com">olafvdspek@gmail.com</a>>
wrote:<br>
> Then maybe you should address the concerns others have.<br>
<br>
<b>optional<T> relop optional<T><br>
</b><br>
A cursory look at n3485 shows the following types as supporting
all the relops:<br>
<br>
pair
<div>tuple</div>
<div>unique_ptr</div>
<div>shared_ptr</div>
<div>duration</div>
<div>time_point</div>
<div>type_index</div>
<div>
basic_string</div>
<div>array</div>
<div>deque</div>
<div>forward_list</div>
<div>list</div>
<div>vector</div>
<div>map</div>
<div>multimap</div>
<div>set</div>
<div>multiset</div>
<div>queue</div>
<div>stack</div>
<div>reverse_iterator</div>
<div>move_iterator</div>
<div>val_array</div>
<div>sub_match</div>
<div>thread::id<br>
<br>
Other than raw pointers on some implementations (again, where
they have to be because C doesn't guarantee a total ordering for
pointers), what standard types just specialize std::less and not
allow the expression x < y?<br>
<br>
</div>
</blockquote>
Which types on the list above have an underlying type that is
implicitly convertible to the type? The closer I can see is
initialization from a list initializer.<br>
<blockquote
cite="mid:CAGg_6+Pn21JP1TiqQeAOf+z8+Qzz-LnL226ufxfT+62nR7kcMg@mail.gmail.com"
type="cite">
<div>I am unconvinced that the problematic cases are that
problematic in practice.<br>
<br>
Not providing optional<T> relop optional<T> is <i>a
deal breaker for me</i>. It breaks user expectations. It
does not fit in with the rest of the standard library. It means
that optional does not play well with the rest of the standard
library. I don't know how to rationally explain:<br>
<br>
vector<optional<T>> v;<br>
sort(v.beginI(), v.end()); // works<br>
sort(v.begin(), v.end(),
std::greater<optional<T>>()); // doesn't work</div>
<div>sort(v.begin(), v.end(), [](optional<T> const& l,
optional<T> const& r){ return l > r; }); // doesn't
work</div>
<div><br>
<br>
</div>
</blockquote>
I agree, optional<T> relop optional<T> must be in.
There is no question about this.<br>
<blockquote
cite="mid:CAGg_6+Pn21JP1TiqQeAOf+z8+Qzz-LnL226ufxfT+62nR7kcMg@mail.gmail.com"
type="cite">
<div><b>optional<T> relop T:<br>
</b><br>
While this one isn't a deal breaker for me, I'm still strongly
for it.</div>
<div><br>
</div>
<div>Standard templated types that allow mixed comparison with
their underlying types:</div>
<div><br>
</div>
<div>atomic</div>
<div>valarray<br>
<br>
</div>
</blockquote>
Maybe it is worth noting the curious semantic of the relop on
valarray <br>
<br>
"26.6.3.2 valarray logical operators<br>
<br>
template<class T> valarray<bool> operator==(const
valarray<T>&, const T&);<br>
template<class T> valarray<bool> operator==(const
T&, const valarray<T>&);<br>
template<class T> valarray<bool> operator!=(const
valarray<T>&, const T&);<br>
template<class T> valarray<bool> operator!=(const
T&, const valarray<T>&);<br>
template<class T> valarray<bool> operator< (const
valarray<T>&, const T&);<br>
template<class T> valarray<bool> operator< (const
T&, const valarray<T>&);<br>
...<br>
<br>
4 Each of these operators may only be instantiated for a type T to
which the indicated operator can be<br>
applied and for which the indicated operator returns a value which
is of type bool or which can be<br>
unambiguously implicitly converted to type bool.<br>
5 Each of these operators returns a bool array whose length is equal
to the length of the array argument.<br>
Each element of the returned array is initialized with the result of
applying the indicated operator to<br>
the corresponding element of the array and the non-array argument."<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAGg_6+Pn21JP1TiqQeAOf+z8+Qzz-LnL226ufxfT+62nR7kcMg@mail.gmail.com"
type="cite">
<div>And as I mentioned before, people are looking to add this
functionality to other things in the standard (such as map
lookup), so clearly there is a desire for it. People don't want
to pay the construction cost just to do a comparison. Heck,
that is why std::string allows a comparison against const char*
(and there are many other examples in the standard library like
this).</div>
<div><br>
</div>
<div>I am also unconvinced here that the problematic cases are
that problematic in practice.<br>
</div>
</blockquote>
<br>
IMHO, as far as optional<T> is implicitly convertible from T,
defining mixed relop is a matter of optimization. I we admit
implicit conversion, poisoning them could be surprising. Would this
poisoning on the standard a suggestion for the user to poison his
functions taking an optional?<br>
<br>
I'm against the implicit conversion, and I would prefer implicit
conversion from a initializer list (restricted to one element) but
once we admit implicit conversion we should make the whole design
coherent and poisoning doesn't helps in this sens.<br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------070403000105090007080704--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 1 Feb 2013 10:28:36 +0100
Raw View
On Thu, Jan 31, 2013 at 11:48 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 31 January 2013 09:16, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> Then maybe you should address the concerns others have.
> Other than raw pointers on some implementations (again, where they have to
> be because C doesn't guarantee a total ordering for pointers), what standard
> types just specialize std::less and not allow the expression x < y?
I think no standard types do that, but I do agree that ideally
optional should just work in containers and sorting.
And I'm sorry, you're not really addressing the concerns, you're
repeating your own arguments.
> optional<int> is quite like int* if we consider the const interface. Both are empty/null or have a value. Yet you can't compare int* with int directly. You also either compare the pointers or the pointees, not both at the same time.
So are you proposing that int* < int should be defined too? Why (not)?
--
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/?hl=en.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 1 Feb 2013 02:08:09 -0800 (PST)
Raw View
------=_Part_926_27550851.1359713289256
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 1 lutego 2013 10:28:36 UTC+1 u=BFytkownik Olaf van der Spe=
k=20
napisa=B3:
>
> On Thu, Jan 31, 2013 at 11:48 PM, Nevin Liber <ne...@eviloverlord.com<jav=
ascript:>>=20
> wrote:=20
> > On 31 January 2013 09:16, Olaf van der Spek <olafv...@gmail.com<javascr=
ipt:>>=20
> wrote:=20
> >> Then maybe you should address the concerns others have.=20
>
> > Other than raw pointers on some implementations (again, where they have=
=20
> to=20
> > be because C doesn't guarantee a total ordering for pointers), what=20
> standard=20
> > types just specialize std::less and not allow the expression x < y?=20
>
> I think no standard types do that, but I do agree that ideally=20
> optional should just work in containers and sorting.=20
> And I'm sorry, you're not really addressing the concerns, you're=20
> repeating your own arguments.=20
>
> > optional<int> is quite like int* if we consider the const interface.=20
> Both are empty/null or have a value. Yet you can't compare int* with int=
=20
> directly. You also either compare the pointers or the pointees, not both =
at=20
> the same time.=20
>
> So are you proposing that int* < int should be defined too? Why (not)?=20
>
Your argument -- If I read it correctly -- is "because pointers don't allow=
=20
it, optional shall not allow it". I do not find it valid an expectation.=20
Optional is similar to pointers in some (small) extent, but there are=20
places where it obviously needs to be different. A pointer is an address=20
under this address some value is stored. You should not in general compare=
=20
an address with a value of the type you may not even know. In contrast=20
optional::operator* just narrows the set of values from {nullopt, 0, 1,=20
...., N} to {0, 1, ..., N}. The semantics of operator* carries some=20
resemblance to the pointer indirection operator, but some aspects of its=20
semantics are different.
Note that I am not arguing in favor of mixed ordering here. I am only=20
arguing with the argument.
Regards,
&rzej =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/?hl=3Den.
------=_Part_926_27550851.1359713289256
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 1 lutego 2013 10:28:36 UTC+1 u=BFytkownik Olaf van=
der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Ja=
n 31, 2013 at 11:48 PM, Nevin Liber <<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"H_HvBLE0B9AJ">ne...@eviloverlord.com</a>>=
; wrote:
<br>> On 31 January 2013 09:16, Olaf van der Spek <<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"H_HvBLE0B9AJ">olafv...@gma=
il.com</a>> wrote:
<br>>> Then maybe you should address the concerns others have.
<br>
<br>> Other than raw pointers on some implementations (again, where they=
have to
<br>> be because C doesn't guarantee a total ordering for pointers), wha=
t standard
<br>> types just specialize std::less and not allow the expression x <=
; y?
<br>
<br>I think no standard types do that, but I do agree that ideally
<br>optional should just work in containers and sorting.
<br>And I'm sorry, you're not really addressing the concerns, you're
<br>repeating your own arguments.
<br>
<br>> optional<int> is quite like int* if we consider the const in=
terface. Both are empty/null or have a value. Yet you can't compare int* wi=
th int directly. You also either compare the pointers or the pointees, not =
both at the same time.
<br>
<br>So are you proposing that int* < int should be defined too? Why (not=
)?
<br></blockquote><div><br>Your argument -- If I read it correctly -- is "be=
cause pointers don't allow it, optional shall not allow it". I do not find =
it valid an expectation. Optional is similar to pointers in some (small) ex=
tent, but there are places where it obviously needs to be different. A poin=
ter is an address under this address some value is stored. You should not i=
n general compare an address with a value of the type you may not even know=
.. In contrast optional::operator* just narrows the set of values from {null=
opt, 0, 1, ..., N} to {0, 1, ..., N}. The semantics of operator* carries so=
me resemblance to the pointer indirection operator, but some aspects of its=
semantics are different.<br><br>Note that I am not arguing in favor of mix=
ed ordering here. I am only arguing with the argument.<br><br>Regards,<br>&=
amp;rzej <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_926_27550851.1359713289256--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 1 Feb 2013 11:19:59 +0100
Raw View
On Fri, Feb 1, 2013 at 11:08 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>> > optional<int> is quite like int* if we consider the const interface.
>> > Both are empty/null or have a value. Yet you can't compare int* with i=
nt
>> > directly. You also either compare the pointers or the pointees, not bo=
th at
>> > the same time.
>>
>> So are you proposing that int* < int should be defined too? Why (not)?
>
>
> Your argument -- If I read it correctly -- is "because pointers don't all=
ow
> it, optional shall not allow it". I do not find it valid an expectation.
Kinda. IMO ptr < val and opt < val are kinda equivalent constructs.
> Optional is similar to pointers in some (small) extent, but there are pla=
ces
> where it obviously needs to be different. A pointer is an address under t=
his
> address some value is stored. You should not in general compare an addres=
s
> with a value of the type you may not even know. In contrast
What do you mean by not knowing the type? The type is quite well-known.
You'd not be comparing the address, you'd be comparing the value at
that address.
> optional::operator* just narrows the set of values from {nullopt, 0, 1, .=
...,
> N} to {0, 1, ..., N}. The semantics of operator* carries some resemblance=
to
> the pointer indirection operator, but some aspects of its semantics are
> different.
I'm not sure how that's relevant. In both cases the return type of the
operator is the same, isn't it? Preconditions are the same as well.
--=20
Olaf
--=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/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 1 Feb 2013 02:37:29 -0800 (PST)
Raw View
------=_Part_788_3224724.1359715049457
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 1 lutego 2013 11:19:59 UTC+1 u=BFytkownik Olaf van der Spe=
k=20
napisa=B3:
>
> On Fri, Feb 1, 2013 at 11:08 AM, Andrzej Krzemie=F1ski <akrz...@gmail.com=
<javascript:>>=20
> wrote:=20
> >> > optional<int> is quite like int* if we consider the const interface.=
=20
> >> > Both are empty/null or have a value. Yet you can't compare int* with=
=20
> int=20
> >> > directly. You also either compare the pointers or the pointees, not=
=20
> both at=20
> >> > the same time.=20
> >>=20
> >> So are you proposing that int* < int should be defined too? Why (not)?=
=20
> >=20
> >=20
> > Your argument -- If I read it correctly -- is "because pointers don't=
=20
> allow=20
> > it, optional shall not allow it". I do not find it valid an expectation=
..=20
>
> Kinda. IMO ptr < val and opt < val are kinda equivalent constructs.=20
>
> > Optional is similar to pointers in some (small) extent, but there are=
=20
> places=20
> > where it obviously needs to be different. A pointer is an address under=
=20
> this=20
> > address some value is stored. You should not in general compare an=20
> address=20
> > with a value of the type you may not even know. In contrast=20
>
> What do you mean by not knowing the type? The type is quite well-known.=
=20
>
You're right. I used wrong words. I mean that on the left-hand side of 'ptr=
=20
< val' you have an address, which is almost an int. And on the right-hand=
=20
side you have value of some type unrelated to "almost" int, like=20
vector<string>.
=20
> You'd not be comparing the address, you'd be comparing the value at=20
> that address.=20
>
Well, such operator< does not exist. If you were to add it, you could=20
provide any semantics you like, but the first impression would be, this guy=
=20
is comparing an "almost int" (an address) to vector<string>. This is=20
because a raw pointer is a value-semantic type: its value is the address of=
=20
a certain memory location (or no-address) It is preserved in copy=20
constructor, copy assignment and equality comparison.=20
=20
>
> > optional::operator* just narrows the set of values from {nullopt, 0, 1,=
=20
> ...,=20
> > N} to {0, 1, ..., N}. The semantics of operator* carries some=20
> resemblance to=20
> > the pointer indirection operator, but some aspects of its semantics are=
=20
> > different.=20
>
> I'm not sure how that's relevant. In both cases the return type of the=20
> operator is the same, isn't it? Preconditions are the same as well.=20
>
Along with optional we propose a certain conceptual model for it.=20
If type unsigned int can assume one of the values {0, 1, ..., 2^32}, type=
=20
optional<unsigned> can assume values {nullopt, 0, 1, ..., 2^32}. Because we=
=20
provide implicit conversion from T, it follows that unsigned int is also=20
like the extended {nullopt, 0, 1, ..., 2^32}, except that there is no way=
=20
to assign nullopt to it. If you write comparison:
opt < val
You can think of it as comparing two values that range over the same set of=
=20
possible values, except that we are sure that 'val' will not assume value=
=20
nullopt.=20
One could argue that I could apply the same reasoning to pointers, but=20
pointers do not _contain_ the value they indirect to. They are only=20
addresses, and this is embedded by their semantics. For instance, their=20
copy assignment only copies the address, and you cannot implicitly convert=
=20
a T to T*.
--=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/?hl=3Den.
------=_Part_788_3224724.1359715049457
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 1 lutego 2013 11:19:59 UTC+1 u=BFytkownik Olaf van=
der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Fe=
b 1, 2013 at 11:08 AM, Andrzej Krzemie=F1ski <<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"UNR3NIXvBlwJ">akrz...@gmail.com</a=
>> wrote:
<br>>> > optional<int> is quite like int* if we consider the=
const interface.
<br>>> > Both are empty/null or have a value. Yet you can't compar=
e int* with int
<br>>> > directly. You also either compare the pointers or the poi=
ntees, not both at
<br>>> > the same time.
<br>>>
<br>>> So are you proposing that int* < int should be defined too?=
Why (not)?
<br>>
<br>>
<br>> Your argument -- If I read it correctly -- is "because pointers do=
n't allow
<br>> it, optional shall not allow it". I do not find it valid an expect=
ation.
<br>
<br>Kinda. IMO ptr < val and opt < val are kinda equivalent construct=
s.
<br>
<br>> Optional is similar to pointers in some (small) extent, but there =
are places
<br>> where it obviously needs to be different. A pointer is an address =
under this
<br>> address some value is stored. You should not in general compare an=
address
<br>> with a value of the type you may not even know. In contrast
<br>
<br>What do you mean by not knowing the type? The type is quite well-known.
<br></blockquote><div><br>You're right. I used wrong words. I mean that on =
the left-hand side of 'ptr < val' you have an address, which is almost a=
n int. And on the right-hand side you have value of some type unrelated to =
"almost" int, like vector<string>.<br> <br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">You'd not be comparing the address, you'd be =
comparing the value at
<br>that address.
<br></blockquote><div><br>Well, such operator< does not exist. If you we=
re to add it, you could provide any semantics you like, but the first impre=
ssion would be, this guy is comparing an "almost int" (an address) to vecto=
r<string>. This is because a raw pointer is a value-semantic type: it=
s value is the address of a certain memory location (or no-address) It is p=
reserved in copy constructor, copy assignment and equality comparison. <br>=
<br> <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>> optional::operator* just narrows the set of values from {nullopt, =
0, 1, ...,
<br>> N} to {0, 1, ..., N}. The semantics of operator* carries some rese=
mblance to
<br>> the pointer indirection operator, but some aspects of its semantic=
s are
<br>> different.
<br>
<br>I'm not sure how that's relevant. In both cases the return type of the
<br>operator is the same, isn't it? Preconditions are the same as well.
<br></blockquote><div><br>Along with optional we propose a certain conceptu=
al model for it. <br>If type unsigned int can assume one of the values {0, =
1, ..., 2^32}, type optional<unsigned> can assume values {nullopt, 0,=
1, ..., 2^32}. Because we provide implicit conversion from T, it follows t=
hat unsigned int is also like the extended {nullopt, 0, 1, ..., 2^32}, exc=
ept that there is no way to assign nullopt to it. If you write comparison:<=
br><br>opt < val<br><br>You can think of it as comparing two values that=
range over the same set of possible values, except that we are sure that '=
val' will not assume value nullopt. <br><br>One could argue that I could ap=
ply the same reasoning to pointers, but pointers do not _contain_ the value=
they indirect to. They are only addresses, and this is embedded by their s=
emantics. For instance, their copy assignment only copies the address, and =
you cannot implicitly convert a T to T*.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_788_3224724.1359715049457--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 1 Feb 2013 11:59:53 +0100
Raw View
On Fri, Feb 1, 2013 at 11:37 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
>> What do you mean by not knowing the type? The type is quite well-known.
>
>
> You're right. I used wrong words. I mean that on the left-hand side of 'p=
tr
> < val' you have an address, which is almost an int.
The interesting part isn't the pointer (address), it's the pointee.
> And on the right-hand
> side you have value of some type unrelated to "almost" int, like
> vector<string>.
Let's stick to int*. I wouldn't say int* and int are unrelated types.
>>
>> You'd not be comparing the address, you'd be comparing the value at
>> that address.
>
>
> Well, such operator< does not exist. If you were to add it, you could
> provide any semantics you like, but the first impression would be, this g=
uy
> is comparing an "almost int" (an address) to vector<string>. This is beca=
use
> a raw pointer is a value-semantic type: its value is the address of a
> certain memory location (or no-address) It is preserved in copy construct=
or,
> copy assignment and equality comparison.
I guess that's the same impression some have of opt < val.
Note that we're not talking about void*, which is basically just an address=
..
>> I'm not sure how that's relevant. In both cases the return type of the
>> operator is the same, isn't it? Preconditions are the same as well.
>
>
> Along with optional we propose a certain conceptual model for it.
> If type unsigned int can assume one of the values {0, 1, ..., 2^32}, type
> optional<unsigned> can assume values {nullopt, 0, 1, ..., 2^32}. Because =
we
> provide implicit conversion from T, it follows that unsigned int is also
> like the extended {nullopt, 0, 1, ..., 2^32}, except that there is no way=
to
> assign nullopt to it. If you write comparison:
>
> opt < val
>
> You can think of it as comparing two values that range over the same set =
of
> possible values, except that we are sure that 'val' will not assume value
> nullopt.
Again, that's basically the same for int*. It's either null or it
points to an int.
> One could argue that I could apply the same reasoning to pointers, but
> pointers do not _contain_ the value they indirect to. They are only
The storage location isn't relevant for the const interface, is it?
> addresses, and this is embedded by their semantics. For instance, their c=
opy
> assignment only copies the address, and you cannot implicitly convert a T=
to
> T*.
Sure, pointers and optionals aren't the same type, but I'm not sure
how that's relevant to this discussion.
--=20
Olaf
--=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/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 1 Feb 2013 04:34:58 -0800 (PST)
Raw View
------=_Part_825_15186291.1359722099017
Content-Type: text/plain; charset=ISO-8859-1
>
> > addresses, and this is embedded by their semantics. For instance, their
> copy
> > assignment only copies the address, and you cannot implicitly convert a
> T to
> > T*.
>
> Sure, pointers and optionals aren't the same type, but I'm not sure
> how that's relevant to this discussion.
>
Good question. Let me summarize. As I understand, the subject of this
sub-sub-thread is whether or not the same logic that applies to mixed
ordering for optionals should also apply to mixed ordering for pointers
(raw pointers in particular). My position is that it shouldn't and in a
very arrogantly short summary, it is because optional is different than
pointers, has different semantics than pointers, and the existence of mixed
ordering is one of such *natural* differences. My goal is to show the
"natural". I will try to respond to your response from bottom to top.
> One could argue that I could apply the same reasoning to pointers, but
> > pointers do not _contain_ the value they indirect to. They are only
>
> The storage location isn't relevant for the const interface, is it?
>
Word "contain" here isn't really about storage but about the _value_ (or
salient attributes, as per N2479). What is the value of a pointer? it is
only an integer that refers to some address in memory. What is the value of
an optional object? It is its engagement/disengagement state + the value of
the contained value if optional is engaged. This is not just a point of
view, or the way of looking at pointers and optionals. As per N2479 the
definition of the value for any given type is specified by its (homogenous)
operator==. Pointer's op== compares only addresses. Optional's op==
compares engagement and the value.
> You can think of it as comparing two values that range over the same set
> of
> > possible values, except that we are sure that 'val' will not assume
> value
> > nullopt.
>
> Again, that's basically the same for int*. It's either null or it
> points to an int.
>
It is not the same, given the definition of a value of an optional object
and of a value of a pointer as indicated above. Whatever a pointer points
to is not part of the pointer's value (even though you are capable of
reading this value).
If there were no indirection operators (or special syntax for pointer
declarations), the difference would probably be more apparent. The syntax
of indirecting a pointer would probably be:
pointer<string> p; // a raw pointer
string s = memory.get_object_at(p);
In other words, the fact that you can obtain the value located at the given
address is not the value of this address.
>>
> >> You'd not be comparing the address, you'd be comparing the value at
> >> that address.
> >
> > Well, such operator< does not exist. If you were to add it, you could
> > provide any semantics you like, but the first impression would be, this
> guy
> > is comparing an "almost int" (an address) to vector<string>. This is
> because
> > a raw pointer is a value-semantic type: its value is the address of a
> > certain memory location (or no-address) It is preserved in copy
> constructor,
> > copy assignment and equality comparison.
>
> I guess that's the same impression some have of opt < val.
> Note that we're not talking about void*, which is basically just an
> address.
>
You will not have the same impression for opt < val if you accept that what
opt indirects to is part of its value. This is not the case for pointers.
> And on the right-hand
> > side you have value of some type unrelated to "almost" int, like
> > vector<string>.
>
> Let's stick to int*. I wouldn't say int* and int are unrelated types.
>
they are related "somehow" (also int and vector<int> are related), but the
significant difference her is that what a pointer indirects to is not the
pointers value.
> You're right. I used wrong words. I mean that on the left-hand side of
> 'ptr
> > < val' you have an address, which is almost an int.
>
> The interesting part isn't the pointer (address), it's the pointee.
>
What is of the most interest is very subjective. It can be the pointee in
your case. However being part of the value or not is objective, and can be
used as foundations of the semantics of relational operations including the
mixed ones.
Regards,
&rzej
--
---
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/?hl=en.
------=_Part_825_15186291.1359722099017
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>> addresses, and this is embedded by their semantics. For instance, =
their copy
<br>> assignment only copies the address, and you cannot implicitly conv=
ert a T to
<br>> T*.
<br>
<br>Sure, pointers and optionals aren't the same type, but I'm not sure
<br>how that's relevant to this discussion.
<br></blockquote><div><br>Good question. Let me summarize. As I understand,=
the subject of this sub-sub-thread is whether or not the same logic that a=
pplies to mixed ordering for optionals should also apply to mixed ordering =
for pointers (raw pointers in particular). My position is that it shouldn't=
and in a very arrogantly short summary, it is because optional is differen=
t than pointers, has different semantics than pointers, and the existence o=
f mixed ordering is one of such *natural* differences. My goal is to show t=
he "natural". I will try to respond to your response from bottom to top.<br=
><br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px s=
olid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">> One=
could argue that I could apply the same reasoning to pointers, but
<br>> pointers do not _contain_ the value they indirect to. They are onl=
y
<br>
<br>The storage location isn't relevant for the const interface, is it?
<br></blockquote><div><br>Word "contain" here isn't really about storage bu=
t about the _value_ (or salient attributes, as per N2479). What is the valu=
e of a pointer? it is only an integer that refers to some address in memory=
.. What is the value of an optional object? It is its engagement/disengageme=
nt state + the value of the contained value if optional is engaged. This is=
not just a point of view, or the way of looking at pointers and optionals.=
As per N2479 the definition of the value for any given type is specified b=
y its (homogenous) operator=3D=3D. Pointer's op=3D=3D compares only address=
es. Optional's op=3D=3D compares engagement and the value.<br><br><blockquo=
te style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204,=
204); padding-left: 1ex;" class=3D"gmail_quote">> You can think of it a=
s comparing two values that range over the same set of
<br>> possible values, except that we are sure that 'val' will not assum=
e value
<br>> nullopt.
<br>
<br>Again, that's basically the same for int*. It's either null or it
<br>points to an int.
<br></blockquote><div><br>It is not the same, given the definition of a val=
ue of an optional object and of a value of a pointer as indicated above. Wh=
atever a pointer points to is not part of the pointer's value (even though =
you are capable of reading this value). <br></div>
<br>If there were no indirection operators (or special syntax for pointer d=
eclarations), the difference would probably be more apparent. The syntax of=
indirecting a pointer would probably be:<br><br><div class=3D"prettyprint"=
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
#000;" class=3D"styled-by-prettify">pointer</span><span style=3D"color: #0=
80;" class=3D"styled-by-prettify"><string></span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> p</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// a raw pointer</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">string</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> s </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> memor=
y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">get_object_at</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">p</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> <br></span></div></code></div><br>In oth=
er words, the fact that you can obtain the value located at the given addre=
ss is not the value of this address.<br><br><br><blockquote style=3D"margin=
: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-lef=
t: 1ex;" class=3D"gmail_quote">>>
<br>>> You'd not be comparing the address, you'd be comparing the val=
ue at
<br>>> that address.
<br>>
<br>> Well, such operator< does not exist. If you were to add it, you=
could
<br>> provide any semantics you like, but the first impression would be,=
this guy
<br>> is comparing an "almost int" (an address) to vector<string>.=
This is because
<br>> a raw pointer is a value-semantic type: its value is the address o=
f a
<br>> certain memory location (or no-address) It is preserved in copy co=
nstructor,
<br>> copy assignment and equality comparison.
<br>
<br>I guess that's the same impression some have of opt < val.
<br>Note that we're not talking about void*, which is basically just an add=
ress.
<br></blockquote><br>You will not have the same impression for opt < val=
if you accept that what opt indirects to is part of its value. This is not=
the case for pointers.<br><br><br><blockquote><blockquote style=3D"margin:=
0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left=
: 1ex;" class=3D"gmail_quote">> And on the right-hand
<br>> side you have value of some type unrelated to "almost" int, like
<br>> vector<string>.
<br>
<br>Let's stick to int*. I wouldn't say int* and int are unrelated types.
<br></blockquote></blockquote><br>they are related "somehow" (also int and =
vector<int> are related), but the significant difference her is that =
what a pointer indirects to is not the pointers value.<br><br><blockquote s=
tyle=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204=
); padding-left: 1ex;" class=3D"gmail_quote">> You're right. I used wron=
g words. I mean that on the left-hand side of 'ptr
<br>> < val' you have an address, which is almost an int.
<br>
<br>The interesting part isn't the pointer (address), it's the pointee.
<br></blockquote>
<br><div>What is of the most interest is very subjective. It can be the poi=
ntee in your case. However being part of the value or not is objective, and=
can be used as foundations of the semantics of relational operations inclu=
ding the mixed ones.<br><br>Regards,<br>&rzej<br></div><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_825_15186291.1359722099017--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 1 Feb 2013 14:35:25 +0100
Raw View
On Fri, Feb 1, 2013 at 1:34 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.co=
m> wrote:
>> > One could argue that I could apply the same reasoning to pointers, but
>> > pointers do not _contain_ the value they indirect to. They are only
>>
>> The storage location isn't relevant for the const interface, is it?
>
>
> Word "contain" here isn't really about storage but about the _value_ (or
> salient attributes, as per N2479). What is the value of a pointer? it is
> only an integer that refers to some address in memory. What is the value =
of
> an optional object? It is its engagement/disengagement state + the value =
of
> the contained value if optional is engaged. This is not just a point of
> view, or the way of looking at pointers and optionals. As per N2479 the
> definition of the value for any given type is specified by its (homogenou=
s)
> operator=3D=3D. Pointer's op=3D=3D compares only addresses. Optional's op=
=3D=3D compares
> engagement and the value.
I can't remember the last time I cared about the address of a pointer.
If I look at my own code it's rarely if ever about the address of the
pointer, it's all about what it points to.
I'm not familiar with N2479, but based on those definitions you're
probably right. So maybe those definitions are wrong or don't match
real-world expectations.
My point is that if I have a pointer, it almost always is about the
pointee (or no pointee) and not about the address.
With T*, I think it depends on the type T too. If T is iostream then
different pointers imply different iostreams. But if it's int, then
different pointers don't really imply different ints.
So it depends on use case.
>
>> > You can think of it as comparing two values that range over the same s=
et
>> > of
>> > possible values, except that we are sure that 'val' will not assume
>> > value
>> > nullopt.
>>
>> Again, that's basically the same for int*. It's either null or it
>> points to an int.
>
>
> It is not the same, given the definition of a value of an optional object
> and of a value of a pointer as indicated above. Whatever a pointer points=
to
> is not part of the pointer's value (even though you are capable of readin=
g
> this value).
>
> If there were no indirection operators (or special syntax for pointer
> declarations), the difference would probably be more apparent. The syntax=
of
> indirecting a pointer would probably be:
>
> pointer<string> p; // a raw pointer
> string s =3D memory.get_object_at(p);
>
> In other words, the fact that you can obtain the value located at the giv=
en
> address is not the value of this address.
What is memory here? I'd expect it to be just p.get(). Just like
shared_ptr, unique_ptr and ...
optional.
But that's just syntax, it still doesn't change the fact that you
still either have a value or not.
>> > You're right. I used wrong words. I mean that on the left-hand side of
>> > 'ptr
>> > < val' you have an address, which is almost an int.
>>
>> The interesting part isn't the pointer (address), it's the pointee.
>
>
> What is of the most interest is very subjective.
Is it?
I'd love to see some real-world code base where the interesting part
is the address, most of the time.
--=20
Olaf
--=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/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 1 Feb 2013 06:23:47 -0800 (PST)
Raw View
------=_Part_1934_1947988.1359728627676
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 1 lutego 2013 14:35:25 UTC+1 u=BFytkownik Olaf van der Spe=
k=20
napisa=B3:
>
> On Fri, Feb 1, 2013 at 1:34 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com<=
javascript:>>=20
> wrote:=20
> >> > One could argue that I could apply the same reasoning to pointers,=
=20
> but=20
> >> > pointers do not _contain_ the value they indirect to. They are only=
=20
> >>=20
> >> The storage location isn't relevant for the const interface, is it?=20
> >=20
> >=20
> > Word "contain" here isn't really about storage but about the _value_ (o=
r=20
> > salient attributes, as per N2479). What is the value of a pointer? it i=
s=20
> > only an integer that refers to some address in memory. What is the valu=
e=20
> of=20
> > an optional object? It is its engagement/disengagement state + the valu=
e=20
> of=20
> > the contained value if optional is engaged. This is not just a point of=
=20
> > view, or the way of looking at pointers and optionals. As per N2479 the=
=20
> > definition of the value for any given type is specified by its=20
> (homogenous)=20
> > operator=3D=3D. Pointer's op=3D=3D compares only addresses. Optional's =
op=3D=3D=20
> compares=20
> > engagement and the value.=20
>
> I can't remember the last time I cared about the address of a pointer.=20
> If I look at my own code it's rarely if ever about the address of the=20
> pointer, it's all about what it points to.=20
> I'm not familiar with N2479, but based on those definitions you're=20
> probably right. So maybe those definitions are wrong or don't match=20
> real-world expectations.=20
>
> My point is that if I have a pointer, it almost always is about the=20
> pointee (or no pointee) and not about the address.=20
>
> With T*, I think it depends on the type T too. If T is iostream then=20
> different pointers imply different iostreams. But if it's int, then=20
> different pointers don't really imply different ints.=20
> So it depends on use case.=20
>
> >=20
> >> > You can think of it as comparing two values that range over the same=
=20
> set=20
> >> > of=20
> >> > possible values, except that we are sure that 'val' will not assume=
=20
> >> > value=20
> >> > nullopt.=20
> >>=20
> >> Again, that's basically the same for int*. It's either null or it=20
> >> points to an int.=20
> >=20
> >=20
> > It is not the same, given the definition of a value of an optional=20
> object=20
> > and of a value of a pointer as indicated above. Whatever a pointer=20
> points to=20
> > is not part of the pointer's value (even though you are capable of=20
> reading=20
> > this value).=20
> >=20
> > If there were no indirection operators (or special syntax for pointer=
=20
> > declarations), the difference would probably be more apparent. The=20
> syntax of=20
> > indirecting a pointer would probably be:=20
> >=20
> > pointer<string> p; // a raw pointer=20
> > string s =3D memory.get_object_at(p);=20
> >=20
> > In other words, the fact that you can obtain the value located at the=
=20
> given=20
> > address is not the value of this address.=20
>
> What is memory here? I'd expect it to be just p.get(). Just like=20
> shared_ptr, unique_ptr and ...=20
> optional.=20
> But that's just syntax, it still doesn't change the fact that you=20
> still either have a value or not.=20
>
> >> > You're right. I used wrong words. I mean that on the left-hand side=
=20
> of=20
> >> > 'ptr=20
> >> > < val' you have an address, which is almost an int.=20
> >>=20
> >> The interesting part isn't the pointer (address), it's the pointee.=20
> >=20
> >=20
> > What is of the most interest is very subjective.=20
>
> Is it?=20
> I'd love to see some real-world code base where the interesting part=20
> is the address, most of the time.=20
>
The one I often see, although perhaps not the smartest one, is :
DataStruct& DataStruct::operator=3D( DataStruct const& rhs )
{
if (this =3D=3D addressof(rhs))
return *this;
// copy guts
}
In the check you are definitely interested in addresses. Basically, you use=
=20
addresses, when you are interested in comparing objects rather than values.
I use pointers to "flag" my objects. I have a collection of objects, I want=
=20
to process them (in random order) and flag, which of them I already=20
processed. I then use another container of pointers that represent objects=
=20
already processed:
std::deque<T> objects;
std::vector<T*> flags;
for (...) {
T& o =3D pick_one(objects);
process(o);
flag.push_back(addressof(o));
}
But why focus only on pointers? Consider iterators: they also provide=20
indirection operator and occasionally a comparison. For iterators using the=
=20
following is very common.
it !=3D end(); // compares addresses (or similar)
++it; // change address
If you are really never interested in addresses when using pointers, then=
=20
perhaps what you always needed was optional<T> but the language couldn't=20
offer it to you.
=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/?hl=3Den.
------=_Part_1934_1947988.1359728627676
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 1 lutego 2013 14:35:25 UTC+1 u=BFytkownik Olaf van=
der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Fe=
b 1, 2013 at 1:34 PM, Andrzej Krzemie=F1ski <<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"Py11oDMr0EUJ">akrz...@gmail.com</a>=
> wrote:
<br>>> > One could argue that I could apply the same reasoning to =
pointers, but
<br>>> > pointers do not _contain_ the value they indirect to. The=
y are only
<br>>>
<br>>> The storage location isn't relevant for the const interface, i=
s it?
<br>>
<br>>
<br>> Word "contain" here isn't really about storage but about the _valu=
e_ (or
<br>> salient attributes, as per N2479). What is the value of a pointer?=
it is
<br>> only an integer that refers to some address in memory. What is the=
value of
<br>> an optional object? It is its engagement/disengagement state + the=
value of
<br>> the contained value if optional is engaged. This is not just a poi=
nt of
<br>> view, or the way of looking at pointers and optionals. As per N247=
9 the
<br>> definition of the value for any given type is specified by its (ho=
mogenous)
<br>> operator=3D=3D. Pointer's op=3D=3D compares only addresses. Option=
al's op=3D=3D compares
<br>> engagement and the value.
<br>
<br>I can't remember the last time I cared about the address of a pointer.
<br>If I look at my own code it's rarely if ever about the address of the
<br>pointer, it's all about what it points to.
<br>I'm not familiar with N2479, but based on those definitions you're
<br>probably right. So maybe those definitions are wrong or don't match
<br>real-world expectations.
<br>
<br>My point is that if I have a pointer, it almost always is about the
<br>pointee (or no pointee) and not about the address.
<br>
<br>With T*, I think it depends on the type T too. If T is iostream then
<br>different pointers imply different iostreams. But if it's int, then
<br>different pointers don't really imply different ints.
<br>So it depends on use case.
<br>
<br>>
<br>>> > You can think of it as comparing two values that range ov=
er the same set
<br>>> > of
<br>>> > possible values, except that we are sure that 'val' will =
not assume
<br>>> > value
<br>>> > nullopt.
<br>>>
<br>>> Again, that's basically the same for int*. It's either null or=
it
<br>>> points to an int.
<br>>
<br>>
<br>> It is not the same, given the definition of a value of an optional=
object
<br>> and of a value of a pointer as indicated above. Whatever a pointer=
points to
<br>> is not part of the pointer's value (even though you are capable of=
reading
<br>> this value).
<br>>
<br>> If there were no indirection operators (or special syntax for poin=
ter
<br>> declarations), the difference would probably be more apparent. The=
syntax of
<br>> indirecting a pointer would probably be:
<br>>
<br>> pointer<string> p; // a raw pointer
<br>> string s =3D memory.get_object_at(p);
<br>>
<br>> In other words, the fact that you can obtain the value located at =
the given
<br>> address is not the value of this address.
<br>
<br>What is memory here? I'd expect it to be just p.get(). Just like
<br>shared_ptr, unique_ptr and ...
<br>optional.
<br>But that's just syntax, it still doesn't change the fact that you
<br>still either have a value or not.
<br>
<br>>> > You're right. I used wrong words. I mean that on the left=
-hand side of
<br>>> > 'ptr
<br>>> > < val' you have an address, which is almost an int.
<br>>>
<br>>> The interesting part isn't the pointer (address), it's the poi=
ntee.
<br>>
<br>>
<br>> What is of the most interest is very subjective.
<br>
<br>Is it?
<br>I'd love to see some real-world code base where the interesting part
<br>is the address, most of the time.
<br></blockquote><div><br>The one I often see, although perhaps not the sma=
rtest one, is :<br><div class=3D"prettyprint" style=3D"background-color: rg=
b(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bo=
rder-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">DataStruct</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">DataStr=
uct</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">DataStruct</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">const</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> rhs </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">this</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> addressof</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">rhs</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">))</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">this</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br><br> </span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">// copy guts</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br=
>In the check you are definitely interested in addresses. Basically, you us=
e addresses, when you are interested in comparing objects rather than value=
s.<br><br>I use pointers to "flag" my objects. I have a collection of objec=
ts, I want to process them (in random order) and flag, which of them I alre=
ady processed. I then use another container of pointers that represent obje=
cts already processed:<br><br><div class=3D"prettyprint" style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">deque</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">></span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> objects</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>std</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">vector</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">*></span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> flags</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">for</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(...)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br> T</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> o </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> pick_one</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">objects</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
; process</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">o</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> flag</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">push_back</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">addressof</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">o</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">));</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan></div></code></div><br>But why focus only on pointers? Consider iterato=
rs: they also provide indirection operator and occasionally a comparison. F=
or iterators using the following is very common.<br><br><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #000;" class=3D"styled-by-prettify">it </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">!=3D</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">end</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>// compares addresses (or similar)</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">++</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">it</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">// change addre=
ss</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an></div></code></div><br>If you are really never interested in addresses w=
hen using pointers, then perhaps what you always needed was optional<T&g=
t; but the language couldn't offer it to you.<br><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1934_1947988.1359728627676--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 1 Feb 2013 15:39:14 +0100
Raw View
On Fri, Feb 1, 2013 at 3:23 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.co=
m> wrote:
>> >> The interesting part isn't the pointer (address), it's the pointee.
>> >
>> >
>> > What is of the most interest is very subjective.
>>
>> Is it?
>> I'd love to see some real-world code base where the interesting part
>> is the address, most of the time.
>
>
> The one I often see, although perhaps not the smartest one, is :
> DataStruct& DataStruct::operator=3D( DataStruct const& rhs )
> {
> if (this =3D=3D addressof(rhs))
> return *this;
>
> // copy guts
> }
>
> In the check you are definitely interested in addresses. Basically, you u=
se
> addresses, when you are interested in comparing objects rather than value=
s.
That's a reference, not a pointer. In N2479 terms, it's checking
whether this and rhs are the same object.
> I use pointers to "flag" my objects. I have a collection of objects, I wa=
nt
> to process them (in random order) and flag, which of them I already
> processed. I then use another container of pointers that represent object=
s
> already processed:
>
> std::deque<T> objects;
> std::vector<T*> flags;
>
> for (...) {
> T& o =3D pick_one(objects);
> process(o);
> flag.push_back(addressof(o));
> }
I've done this too, but it doesn't use operator<, does it?
And the address itself isn't that interesting, you're just using it as
a way to identify what objects you've processed already.
> But why focus only on pointers? Consider iterators: they also provide
> indirection operator and occasionally a comparison. For iterators using t=
he
> following is very common.
>
> it !=3D end(); // compares addresses (or similar)
> ++it; // change address
>
> If you are really never interested in addresses when using pointers, then
> perhaps what you always needed was optional<T> but the language couldn't
> offer it to you.
Let's take this code:
void f(const int* v)
{
if (v)
cout << "value: " << *v;
else
cout << "no value";
}
The address really doesn't matter, it's all about the value. And you
can replace int* by optional<int>, it doesn't matter to the function
body.
Same with mixed operator<, the address doesn't matter (if it's not
null), it's all about the value.
--=20
Olaf
--=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/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 1 Feb 2013 06:54:11 -0800 (PST)
Raw View
------=_Part_91_30908517.1359730451756
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 1 lutego 2013 15:39:14 UTC+1 u=BFytkownik Olaf van der Spe=
k=20
napisa=B3:
>
> On Fri, Feb 1, 2013 at 3:23 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com<=
javascript:>>=20
> wrote:=20
> >> >> The interesting part isn't the pointer (address), it's the pointee.=
=20
> >> >=20
> >> >=20
> >> > What is of the most interest is very subjective.=20
> >>=20
> >> Is it?=20
> >> I'd love to see some real-world code base where the interesting part=
=20
> >> is the address, most of the time.=20
> >=20
> >=20
> > The one I often see, although perhaps not the smartest one, is :=20
> > DataStruct& DataStruct::operator=3D( DataStruct const& rhs )=20
> > {=20
> > if (this =3D=3D addressof(rhs))=20
> > return *this;=20
> >=20
> > // copy guts=20
> > }=20
> >=20
> > In the check you are definitely interested in addresses. Basically, you=
=20
> use=20
> > addresses, when you are interested in comparing objects rather than=20
> values.=20
>
> That's a reference, not a pointer. In N2479 terms, it's checking=20
> whether this and rhs are the same object.=20
>
> > I use pointers to "flag" my objects. I have a collection of objects, I=
=20
> want=20
> > to process them (in random order) and flag, which of them I already=20
> > processed. I then use another container of pointers that represent=20
> objects=20
> > already processed:=20
> >=20
> > std::deque<T> objects;=20
> > std::vector<T*> flags;=20
> >=20
> > for (...) {=20
> > T& o =3D pick_one(objects);=20
> > process(o);=20
> > flag.push_back(addressof(o));=20
> > }=20
>
> I've done this too, but it doesn't use operator<, does it?=20
> And the address itself isn't that interesting, you're just using it as=20
> a way to identify what objects you've processed already.=20
>
> > But why focus only on pointers? Consider iterators: they also provide=
=20
> > indirection operator and occasionally a comparison. For iterators using=
=20
> the=20
> > following is very common.=20
> >=20
> > it !=3D end(); // compares addresses (or similar)=20
> > ++it; // change address=20
> >=20
> > If you are really never interested in addresses when using pointers,=20
> then=20
> > perhaps what you always needed was optional<T> but the language couldn'=
t=20
> > offer it to you.=20
>
> Let's take this code:=20
>
> void f(const int* v)=20
> {=20
> if (v)=20
> cout << "value: " << *v;=20
> else=20
> cout << "no value";=20
> }=20
>
> The address really doesn't matter, it's all about the value. And you=20
> can replace int* by optional<int>, it doesn't matter to the function=20
> body.=20
> Same with mixed operator<, the address doesn't matter (if it's not=20
> null), it's all about the value.=20
>
You _can_ use an address (like a pointer) to speak about a potentially=20
missing value. And in fact, if you do not have something like optional, you=
=20
have to. However, this looks more like a hack or workaround than a proper=
=20
solution. Your function f() takes an optional argument and a pointer will=
=20
do. If you want your function to return an optional value the problems=20
start: precisely because you are returning an address but not the value. At=
=20
best you use another workaround: uniquue_ptr, but you still have to pay the=
=20
penalty of unnecessary heap allocation.
--=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/?hl=3Den.
------=_Part_91_30908517.1359730451756
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 1 lutego 2013 15:39:14 UTC+1 u=BFytkownik Olaf van=
der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Fe=
b 1, 2013 at 3:23 PM, Andrzej Krzemie=F1ski <<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"nzkijg-7aTMJ">akrz...@gmail.com</a>=
> wrote:
<br>>> >> The interesting part isn't the pointer (address), it'=
s the pointee.
<br>>> >
<br>>> >
<br>>> > What is of the most interest is very subjective.
<br>>>
<br>>> Is it?
<br>>> I'd love to see some real-world code base where the interestin=
g part
<br>>> is the address, most of the time.
<br>>
<br>>
<br>> The one I often see, although perhaps not the smartest one, is :
<br>> DataStruct& DataStruct::operator=3D( DataStruct const& rhs=
)
<br>> {
<br>> if (this =3D=3D addressof(rhs))
<br>> return *this;
<br>>
<br>> // copy guts
<br>> }
<br>>
<br>> In the check you are definitely interested in addresses. Basically=
, you use
<br>> addresses, when you are interested in comparing objects rather tha=
n values.
<br>
<br>That's a reference, not a pointer. In N2479 terms, it's checking
<br>whether this and rhs are the same object.
<br>
<br>> I use pointers to "flag" my objects. I have a collection of object=
s, I want
<br>> to process them (in random order) and flag, which of them I alread=
y
<br>> processed. I then use another container of pointers that represent=
objects
<br>> already processed:
<br>>
<br>> std::deque<T> objects;
<br>> std::vector<T*> flags;
<br>>
<br>> for (...) {
<br>> T& o =3D pick_one(objects);
<br>> process(o);
<br>> flag.push_back(addressof(o));
<br>> }
<br>
<br>I've done this too, but it doesn't use operator<, does it?
<br>And the address itself isn't that interesting, you're just using it as
<br>a way to identify what objects you've processed already.
<br>
<br>> But why focus only on pointers? Consider iterators: they also prov=
ide
<br>> indirection operator and occasionally a comparison. For iterators =
using the
<br>> following is very common.
<br>>
<br>> it !=3D end(); // compares addresses (or similar)
<br>> ++it; // change address
<br>>
<br>> If you are really never interested in addresses when using pointer=
s, then
<br>> perhaps what you always needed was optional<T> but the langu=
age couldn't
<br>> offer it to you.
<br>
<br>Let's take this code:
<br>
<br>void f(const int* v)
<br>{
<br> if (v)
<br> cout << "value: " << *v;
<br> else
<br> cout << "no value";
<br>}
<br>
<br>The address really doesn't matter, it's all about the value. And you
<br>can replace int* by optional<int>, it doesn't matter to the funct=
ion
<br>body.
<br>Same with mixed operator<, the address doesn't matter (if it's not
<br>null), it's all about the value.
<br></blockquote><div><br>You _can_ use an address (like a pointer) to spea=
k about a potentially missing value. And in fact, if you do not have someth=
ing like optional, you have to. However, this looks more like a hack or wor=
karound than a proper solution. Your function f() takes an optional argumen=
t and a pointer will do. If you want your function to return an optional va=
lue the problems start: precisely because you are returning an address but =
not the value. At best you use another workaround: uniquue_ptr, but you sti=
ll have to pay the penalty of unnecessary heap allocation.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_91_30908517.1359730451756--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 1 Feb 2013 16:04:10 +0100
Raw View
On Fri, Feb 1, 2013 at 3:54 PM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.co=
m> wrote:
>> Let's take this code:
>>
>> void f(const int* v)
>> {
>> if (v)
>> cout << "value: " << *v;
>> else
>> cout << "no value";
>> }
>>
>> The address really doesn't matter, it's all about the value. And you
>> can replace int* by optional<int>, it doesn't matter to the function
>> body.
>> Same with mixed operator<, the address doesn't matter (if it's not
>> null), it's all about the value.
>
>
> You _can_ use an address (like a pointer) to speak about a potentially
> missing value. And in fact, if you do not have something like optional, y=
ou
> have to. However, this looks more like a hack or workaround than a proper
> solution.
Depends on whether you want to pass it by value or by pointer/reference.
> Your function f() takes an optional argument and a pointer will
> do.
The point is that for this function and for optional operator<, the
address isn't really a concern.
> If you want your function to return an optional value the problems
> start: precisely because you are returning an address but not the value. =
At
> best you use another workaround: uniquue_ptr, but you still have to pay t=
he
> penalty of unnecessary heap allocation.
Right, I'm not saying optional isn't good for returning an optional value.
Though sometimes you want to return by reference/pointer.
--=20
Olaf
--=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/?hl=3Den.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Fri, 1 Feb 2013 07:59:49 -0800 (PST)
Raw View
------=_Part_196_3062105.1359734390032
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu pi=B1tek, 1 lutego 2013 16:04:10 UTC+1 u=BFytkownik Olaf van der Spe=
k=20
napisa=B3:
>
> On Fri, Feb 1, 2013 at 3:54 PM, Andrzej Krzemie=F1ski <akrz...@gmail.com<=
javascript:>>=20
> wrote:=20
> >> Let's take this code:=20
> >>=20
> >> void f(const int* v)=20
> >> {=20
> >> if (v)=20
> >> cout << "value: " << *v;=20
> >> else=20
> >> cout << "no value";=20
> >> }=20
> >>=20
> >> The address really doesn't matter, it's all about the value. And you=
=20
> >> can replace int* by optional<int>, it doesn't matter to the function=
=20
> >> body.=20
> >> Same with mixed operator<, the address doesn't matter (if it's not=20
> >> null), it's all about the value.=20
> >=20
> >=20
> > You _can_ use an address (like a pointer) to speak about a potentially=
=20
> > missing value. And in fact, if you do not have something like optional,=
=20
> you=20
> > have to. However, this looks more like a hack or workaround than a=20
> proper=20
> > solution.=20
>
> Depends on whether you want to pass it by value or by pointer/reference.=
=20
>
> > Your function f() takes an optional argument and a pointer will=20
> > do.=20
>
> The point is that for this function and for optional operator<, the=20
> address isn't really a concern.=20
>
> > If you want your function to return an optional value the problems=20
> > start: precisely because you are returning an address but not the value=
..=20
> At=20
> > best you use another workaround: uniquue_ptr, but you still have to pay=
=20
> the=20
> > penalty of unnecessary heap allocation.=20
>
> Right, I'm not saying optional isn't good for returning an optional value=
..=20
> Though sometimes you want to return by reference/pointer.=20
>
Yes sometimes, you just want to pass by pointer. But then you most likely=
=20
do not want to compare the pointees?
One another example:
int array[100];
int * it =3D array;
int * end =3D array + 100;
for( ; it < end : ++it ) {
f(*i);
}
--=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/?hl=3Den.
------=_Part_196_3062105.1359734390032
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu pi=B1tek, 1 lutego 2013 16:04:10 UTC+1 u=BFytkownik Olaf van=
der Spek napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Fe=
b 1, 2013 at 3:54 PM, Andrzej Krzemie=F1ski <<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"va_FY_and30J">akrz...@gmail.com</a>=
> wrote:
<br>>> Let's take this code:
<br>>>
<br>>> void f(const int* v)
<br>>> {
<br>>> if (v)
<br>>> cout << "value: " << *v;
<br>>> else
<br>>> cout << "no value";
<br>>> }
<br>>>
<br>>> The address really doesn't matter, it's all about the value. A=
nd you
<br>>> can replace int* by optional<int>, it doesn't matter to =
the function
<br>>> body.
<br>>> Same with mixed operator<, the address doesn't matter (if i=
t's not
<br>>> null), it's all about the value.
<br>>
<br>>
<br>> You _can_ use an address (like a pointer) to speak about a potenti=
ally
<br>> missing value. And in fact, if you do not have something like opti=
onal, you
<br>> have to. However, this looks more like a hack or workaround than a=
proper
<br>> solution.
<br>
<br>Depends on whether you want to pass it by value or by pointer/reference=
..
<br>
<br>> Your function f() takes an optional argument and a pointer will
<br>> do.
<br>
<br>The point is that for this function and for optional operator<, the
<br>address isn't really a concern.
<br>
<br>> If you want your function to return an optional value the problems
<br>> start: precisely because you are returning an address but not the =
value. At
<br>> best you use another workaround: uniquue_ptr, but you still have t=
o pay the
<br>> penalty of unnecessary heap allocation.
<br>
<br>Right, I'm not saying optional isn't good for returning an optional val=
ue.
<br>Though sometimes you want to return by reference/pointer.
<br></blockquote><div><br>Yes sometimes, you just want to pass by pointer. =
But then you most likely do not want to compare the pointees?<br><br>One an=
other example:<br><br>int array[100];<br>int * it =3D array;<br>int * end =
=3D array + 100;<br><br>for( ; it < end : ++it ) {<br> f(*i);<br>}=
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_196_3062105.1359734390032--
.