Topic: Obtaining a non-const iterators from a
Author: Xavi Gratal <gratal@gmail.com>
Date: Wed, 1 Jan 2014 21:12:26 -0800 (PST)
Raw View
------=_Part_7341_26809654.1388639546150
Content-Type: text/plain; charset=ISO-8859-1
As a concrete example of why this would be useful, consider the following
excerpt from a simple graph class:
template<typename vertex_data>
class graph {
typedef std::list<vertex_data> vertex_list;
typedef typename vertex_list::iterator vertex_iterator;
typedef typename vertex_list::const_iterator vertex_const_iterator;
struct edge {
edge(const vertex_iterator &s,const vertex_iterator &d)
:src(s),dst(d) {}
vertex_iterator src;
vertex_iterator dst;
};
typedef std::list<edge> edge_list;
typedef typename edge_list::iterator edge_iterator;
typedef typename edge_list::const_iterator edge_const_iterator;
public:
graph() {}
vertex_iterator add_vertex(const vertex_data v) {
vertices.emplace_back(v);
return vertices.end()-1;
}
edge_iterator add_edge(const vertex_iterator &src,const vertex_iterator
&dst) {
edges.emplace_back(src,dst);
return edges.end()-1;
}
private:
vertex_list vertices;
edge_list edges;
};
If edge contained const_iterators, it would later be impossible to return
non-const references to vertices given edges, while, as is currently
implemented, the add_edge function must take non-const iterators, while
there is really no reason for it.
C++11 went one step in the right direction by having functions such as
erase and insert take const_iterators. Having a way to obtain iterators
from const_iterators would allow a class like the above to do the same.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7341_26809654.1388639546150
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">As a concrete example of why this would be useful, conside=
r the following excerpt from a simple graph class:<div><br></div><div><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> vertex_data</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><font color=3D"#660066"><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">graph </span></font><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typedef</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>list</span><span style=3D"color: #080;" class=3D"styled-by-prettify"><v=
ertex_data></span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> vertex_list</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
> </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">typedef</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">typenam=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> vertex_l=
ist</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">iterator vertex=
_iterator</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ty=
pedef</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> vertex_list</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">const_iterator vertex_=
const_iterator</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
br> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> edge </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
edge</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> vertex_iterator </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> vertex_iterator </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">d</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">src</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">s</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">),</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">dst</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">d</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{}</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
<br> vertex_iterator src</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; vertex_iterator dst</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> <br> </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">typedef</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">list</span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify"><edge></span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> edge_list</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">typedef</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">type=
name</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> edge_=
list</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">iterator edge_=
iterator</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typ=
edef</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> edge_list</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">const_iterator edge_const=
_iterator</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=
">public</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
graph</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{}</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br> <br>&=
nbsp; vertex_iterator add_vertex</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">const</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> vertex_data v</span><span style=3D"color: #660;" class=3D"s=
tyled-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>&nbs=
p; vertices</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">emplace_back</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
; </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> vertices</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">.</span><span style=3D"color: #008;" class=3D"styled-by-prettify">e=
nd</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()-</spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">1</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><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br><br> edge_iterato=
r add_edge</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> vertex_iterat=
or </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">src</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> vertex_iterator </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">dst</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br> edges</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">emplace_back</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">src</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">dst</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> edges</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">.</span><span style=3D"color: #008;" class=3D"styled-by-prettify">end</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">()-</span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br> <br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">private</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br> vertex_list vertice=
s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
edge_list edges</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div><=
/code></div><div><br>If edge contained const_iterators, it would later be i=
mpossible to return non-const references to vertices given edges, while, as=
is currently implemented, the add_edge function must take non-const iterat=
ors, while there is really no reason for it.</div><div><br></div><div>C++11=
went one step in the right direction by having functions such as erase and=
insert take const_iterators. Having a way to obtain iterators from const_i=
terators would allow a class like the above to do the same.</div></div><div=
><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7341_26809654.1388639546150--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 02 Jan 2014 13:23:34 +0800
Raw View
On 1/2/14 12:19 PM, Xavi Gratal wrote:
> I would like to add some mechanism to the standard containers so that given a
> non-const reference to the container and a const_iterator, it is possible
> to obtain a non-const iterator in constant time.
It might even be reasonable to have const_iterator_cast, not requiring a
container reference. It seems pointless to legislate this kind of thing.
A programmer who doesn't "get it," whom the safer function is trying to
protect, may just pass a reference to the wrong container, and the
implementation will be none the wiser unless it does perhaps O(N) worth
of verification work.
> This would be useful in a scenario where an algorithm takes a const
> reference to a container and finds some interesting element inside,
> returning a const_iterator to it.
I the problem may become more relevant over time, as it can be
exacerbated by multithreading. A common fix is to grant write access to
more of the program, but that could have immediate consequences if the
compiler is trying to keep track of who might modify what.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Miroslav Knejp <miro@knejp.de>
Date: Thu, 02 Jan 2014 07:59:17 +0100
Raw View
Being able to get a const_iterator from a iterator would sometimes be
indeed useful. Just not the other way around or people start breaking
stuff as they tend to do now with const_cast.
An off-topic note about your code: if this is pasted from real-world use
you probably want to change the single-argument signature of add_vertex
to accept a non-const vetex_data by value and then std::move() it into
emplace_back. The current code as it is will always call vertex_data's
copy constructor because you cannot move from a const object and you end
up with two copy operations instead of one (or even zero if the argument
to add_vertex is a temporary).
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: xavi <gratal@gmail.com>
Date: Thu, 2 Jan 2014 08:06:13 +0100
Raw View
--047d7beb9dcad3ed2804eef76d53
Content-Type: text/plain; charset=ISO-8859-1
2014/1/2 Miroslav Knejp <miro@knejp.de>
> Being able to get a const_iterator from a iterator would sometimes be
> indeed useful. Just not the other way around or people start breaking stuff
> as they tend to do now with const_cast.
>
> Obtaining a const_iterator from an iterator is already possible. For most
(all?) containers in the standard library, iterator is implicitly
convertible to const_iterator.
What I'm proposing doesn't break the constness rules (as const_cast does).
It merely adds a mechanism to optimize what is already possible with
advance and distance. I think it should be implemented as a non-const
member function of the container, so that it can't be used to bypass
constness. It will actually increase constness-safety, since it will allow
const_iterators to be used where iterators are currently needed.
> An off-topic note about your code: if this is pasted from real-world use
> you probably want to change the single-argument signature of add_vertex to
> accept a non-const vetex_data by value and then std::move() it into
> emplace_back. The current code as it is will always call vertex_data's copy
> constructor because you cannot move from a const object and you end up with
> two copy operations instead of one (or even zero if the argument to
> add_vertex is a temporary).
>
> It was a toy example, but yes, I agree that sink parameters should be
passed by value.
>
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
> proposals/.
>
--
---
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/.
--047d7beb9dcad3ed2804eef76d53
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2014=
/1/2 Miroslav Knejp <span dir=3D"ltr"><<a href=3D"mailto:miro@knejp.de" =
target=3D"_blank">miro@knejp.de</a>></span><br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
Being able to get a const_iterator from a iterator would sometimes be indee=
d useful. Just not the other way around or people start breaking stuff as t=
hey tend to do now with const_cast.<br>
<br></blockquote><div>Obtaining a const_iterator from an iterator is alread=
y possible. For most (all?) containers in the standard library, iterator is=
implicitly convertible to const_iterator.</div><div>What I'm proposing=
doesn't break the constness rules (as const_cast does). It merely adds=
a mechanism to optimize what is already possible with advance and distance=
.. I think it should be implemented as a non-const member function of the co=
ntainer, so that it can't be used to bypass constness. It will actually=
increase constness-safety, since it will allow const_iterators to be used =
where iterators are currently needed.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
An off-topic note about your code: if this is pasted from real-world use yo=
u probably want to change the single-argument signature of add_vertex to ac=
cept a non-const vetex_data by value and then std::move() it into emplace_b=
ack. The current code as it is will always call vertex_data's copy cons=
tructor because you cannot move from a const object and you end up with two=
copy operations instead of one (or even zero if the argument to add_vertex=
is a temporary).<div class=3D"HOEnZb">
<div class=3D"h5"><br></div></div></blockquote><div>It was a toy example, b=
ut yes, I agree that sink parameters should be passed by value.=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7beb9dcad3ed2804eef76d53--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Wed, 1 Jan 2014 23:14:00 -0800
Raw View
--001a1134c94c06be0904eef78cc8
Content-Type: text/plain; charset=ISO-8859-1
>If edge contained const_iterators, it would later be impossible to return
non-const references to vertices given edges, while, as is currently
implemented, the add_edge function must take non-const iterators, while
there is really no reason for it.
That seems like the correct thing would be to have non-const iterators
there. You intend to modify the object to which the iterator refers; and as
such it shouldn't be a const iterator.
I'm not saying that this is a bad idea; I'm just saying that example isn't
motivating.
> C++11 went one step in the right direction by having functions such as
erase and insert take const_iterators. Having a way to obtain iterators
from const_iterators would allow a class like the above to do the same.
But this breaks const correctness. The reason you have the workaround for
the random-access containers is that you have a mutable reference to the
container itself which avoids breaking const-correctness.
You would need something like:
iterator const_iterator_cast(Container& c, Container::const_iterator i)
This of course makes the assumption that there is some cheap way to recover
an iterator given a const iterator; though I suspect 99.99% of the time
that is true.
> if the compiler is trying to keep track of who might modify what.
The compiler cannot use const as a means of determining if someone is
modifying something, because const_cast exists in the language. The
compiler must be able to prove that the operations done on something are in
fact constant operations in order to optimize based on this assumption.
> Being able to get a const_iterator from a iterator would sometimes be
indeed useful. Just not the other way around or people start breaking stuff
as they tend to do now with const_cast.
You can already do this -- const iterator has a constructor taking
iterator. (e.g. a wchar_t* can turn into a wchar_t const* without a cast;
and const_iterator must mimic this behavior)
Billy O'Neal
http://stackoverflow.com/users/82320/billy-oneal
--
---
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/.
--001a1134c94c06be0904eef78cc8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">><span style=3D"font-family:arial,sans-serif;font-size:=
13px">If edge contained const_iterators, it would later be impossible to re=
turn non-const references to vertices given edges, while, as is currently i=
mplemented, the add_edge function must take non-const iterators, while ther=
e is really no reason for it.</span><div>
<font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial,=
sans-serif">That seems like the correct thing would be to have non-const i=
terators there. You intend to modify the object to=A0which the iterator ref=
ers; and as such it shouldn't be a const iterator.</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">I'm not saying that this is a bad idea; I'm just =
saying that=A0example isn't motivating.</font></div><div><font face=3D"=
arial, sans-serif"><br>
</font></div><div><font face=3D"arial, sans-serif">>=A0</font><span styl=
e=3D"font-family:arial,sans-serif;font-size:13px">C++11 went one step in th=
e right direction by having functions such as erase and insert take const_i=
terators. Having a way to obtain iterators from const_iterators would allow=
a class like the above to do the same.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><font face=3D"arial, sans-serif">But this breaks const correctn=
ess. The reason you have the=A0workaround for the random-access containers =
is that you have a mutable reference to the container itself which avoids b=
reaking const-correctness.</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">You would need something like:</font></div><div><font fac=
e=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-ser=
if">iterator const_iterator_cast(Container& c, Container::const_iterato=
r i)</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">This of course makes the assumption that there is some ch=
eap way to recover an iterator given a const iterator; though I suspect 99.=
99% of the time that is true.</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">>=A0</font><span style=3D"font-family:arial,sans-serif=
;font-size:13px">if the compiler is trying to keep track of who might modif=
y what.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><font face=3D"arial, sans-serif">The compiler cannot use const =
as a means of determining if someone is modifying something, because const_=
cast exists in the language. The compiler must be able to prove that the op=
erations done on something are in fact=A0constant operations in order to op=
timize based on this assumption.</font></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">>=
;=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13px">Bein=
g able to get a const_iterator from a iterator would sometimes be indeed us=
eful. Just not the other way around or people start breaking stuff as they =
tend to do now with const_cast.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><font face=3D"arial, sans-serif">You can already do this -- con=
st iterator has a=A0constructor taking iterator. (e.g. a wchar_t* can turn =
into a wchar_t const* without a cast; and const_iterator must mimic this be=
havior)</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><div class=3D"g=
mail_extra"><div><div dir=3D"ltr"><div>Billy O'Neal</div><div>
<a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_bla=
nk">http://stackoverflow.com/users/82320/billy-oneal</a></div></div></div><=
/div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1134c94c06be0904eef78cc8--
.
Author: Miroslav Knejp <miro@knejp.de>
Date: Thu, 02 Jan 2014 08:29:48 +0100
Raw View
>
> Obtaining a const_iterator from an iterator is already possible. For
> most (all?) containers in the standard library, iterator is implicitly
> convertible to const_iterator.
> What I'm proposing doesn't break the constness rules (as const_cast
> does). It merely adds a mechanism to optimize what is already possible
> with advance and distance. I think it should be implemented as a
> non-const member function of the container, so that it can't be used
> to bypass constness. It will actually increase constness-safety, since
> it will allow const_iterators to be used where iterators are currently
> needed.
Ok, I forgot about of the conversion. But then I don't see the point in
the proposal. Any mechanics that allow me to change a const_iterator to
iterator is implicitly a mechanic to change const T& to T& without a
verbose and easy to search keyword. If it is a dedicated function like
const_iterator_cast at least it's easy to search. Having a (reference
to) a container doesn't really help. You could just make a temporary
container and use it for the cast. Unless the iterators track their
container (which is probably only the case in debug builds, if at all)
this works even better than the advance/distance trick (which is at
least quite inefficient for most iterator types).
I'd say if you need to modify elements in a container, or get non-const
references to those elements, don't design your classes with const_iterator.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: xavi <gratal@gmail.com>
Date: Thu, 2 Jan 2014 08:29:52 +0100
Raw View
--047d7b6d99b062a58904eef7c2d5
Content-Type: text/plain; charset=ISO-8859-1
2014/1/2 Billy O'Neal <billy.oneal@gmail.com>
> >If edge contained const_iterators, it would later be impossible to
> return non-const references to vertices given edges, while, as is currently
> implemented, the add_edge function must take non-const iterators, while
> there is really no reason for it.
>
> That seems like the correct thing would be to have non-const iterators
> there. You intend to modify the object to which the iterator refers; and as
> such it shouldn't be a const iterator.
>
> I'm not saying that this is a bad idea; I'm just saying that example isn't
> motivating.
>
I believe it is analogous to having erase take const_iterators in the STL.
It was changed in C++11, so someone must have thought it was a good idea.
In add_edge you are not modifying the vertex, so there is no reason why the
vertex iterators should be const. Also, to call add_edge you need to have a
non-const reference to the graph, so there is no logical constness
violation in any case.
Forcing the user to pass non-const iterators to add_edge means that, for
example, if we implement an algorithm that finds pairs of vertices that
should be added to the graph to make it connected, we must make the
algorithm take a non-const reference to the graph, so that the pairs of
vertices it returns can be used to make the graph connected. Forcing such
an algorithm to take a non-const reference greatly reduces the
const-safety, since the algorithm doesn't need to modify the graph. So I
think this example is quite motivating.
>
> > C++11 went one step in the right direction by having functions such as
> erase and insert take const_iterators. Having a way to obtain iterators
> from const_iterators would allow a class like the above to do the same.
>
> But this breaks const correctness. The reason you have the workaround for
> the random-access containers is that you have a mutable reference to the
> container itself which avoids breaking const-correctness.
>
Yes, my suggestion is to allow it only when you have the mutable reference,
which is the case in which it's already possible.
>
> You would need something like:
>
> iterator const_iterator_cast(Container& c, Container::const_iterator i)
>
> I was thinking more along the lines of a member function:
iterator iterator_to(const_iterator i);
added to containers. The containers should have the knowledge to make the
conversion, and since it's a non-const function const-correctness wouldn't
be violated.
> This of course makes the assumption that there is some cheap way to
> recover an iterator given a const iterator; though I suspect 99.99% of the
> time that is true.
>
> > if the compiler is trying to keep track of who might modify what.
>
> The compiler cannot use const as a means of determining if someone is
> modifying something, because const_cast exists in the language. The
> compiler must be able to prove that the operations done on something are in
> fact constant operations in order to optimize based on this assumption.
>
> > Being able to get a const_iterator from a iterator would sometimes be
> indeed useful. Just not the other way around or people start breaking stuff
> as they tend to do now with const_cast.
>
> You can already do this -- const iterator has a constructor taking
> iterator. (e.g. a wchar_t* can turn into a wchar_t const* without a cast;
> and const_iterator must mimic this behavior)
>
> Billy O'Neal
> http://stackoverflow.com/users/82320/billy-oneal
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b6d99b062a58904eef7c2d5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2014/1/2 Billy O'Neal <span dir=3D"ltr"><<a href=3D"mailto:b=
illy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.com</a>></span=
><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im">><span style=3D"font-family:arial,san=
s-serif;font-size:13px">If edge contained const_iterators, it would later b=
e impossible to return non-const references to vertices given edges, while,=
as is currently implemented, the add_edge function must take non-const ite=
rators, while there is really no reason for it.</span><div>
<font face=3D"arial, sans-serif"><br></font></div></div><div><font face=3D"=
arial, sans-serif">That seems like the correct thing would be to have non-c=
onst iterators there. You intend to modify the object to=A0which the iterat=
or refers; and as such it shouldn't be a const iterator.</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">I'm not saying that this is a bad idea; I'm just =
saying that=A0example isn't motivating.</font></div></div></blockquote>=
<div>
I believe it is analogous to having erase take const_iterators in the STL. =
It was changed in C++11, so someone must have thought it was a good idea. I=
n add_edge you are not modifying the vertex, so there is no reason why the =
vertex iterators should be const. Also, to call add_edge you need to have a=
non-const reference to the graph, so there is no logical constness violati=
on in any case.=A0</div>
<div><br></div><div>Forcing the user to pass non-const iterators to add_edg=
e means that, for example, if we implement an algorithm that finds pairs of=
vertices that should be added to the graph to make it connected, we must m=
ake the algorithm take a non-const reference to the graph, so that the pair=
s of vertices it returns can be used to make the graph connected. Forcing s=
uch an algorithm to take a non-const reference greatly reduces the const-sa=
fety, since the algorithm doesn't need to modify the graph. So I think =
this example is quite motivating.</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><div><fon=
t face=3D"arial, sans-serif"><br>
</font></div><div><font face=3D"arial, sans-serif">>=A0</font><span styl=
e=3D"font-family:arial,sans-serif;font-size:13px">C++11 went one step in th=
e right direction by having functions such as erase and insert take const_i=
terators. Having a way to obtain iterators from const_iterators would allow=
a class like the above to do the same.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div></div><div><font face=3D"arial, sans-serif">But this breaks const co=
rrectness. The reason you have the=A0workaround for the random-access conta=
iners is that you have a mutable reference to the container itself which av=
oids breaking const-correctness.</font></div>
</div></blockquote><div>Yes, my suggestion is to allow it only when you hav=
e the mutable reference, which is the case in which it's already possib=
le.=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">You would need something like:</font></div><div><font fac=
e=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-ser=
if">iterator const_iterator_cast(Container& c, Container::const_iterato=
r i)</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div></div></blockquote><=
div>I was thinking more along the lines of a member function:</div><div><br=
></div><div>iterator iterator_to(const_iterator i);</div><div><br></div>
<div>added to containers. The containers should have the knowledge to make =
the conversion, and since it's a non-const function const-correctness w=
ouldn't be violated.</div><div>=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><font face=3D"arial, sans-serif"></font></div><div><f=
ont face=3D"arial, sans-serif">This of course makes the assumption that the=
re is some cheap way to recover an iterator given a const iterator; though =
I suspect 99.99% of the time that is true.</font></div>
<div class=3D"im">
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">>=A0</font><span style=3D"font-family:arial,sans-serif=
;font-size:13px">if the compiler is trying to keep track of who might modif=
y what.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div></div><div><font face=3D"arial, sans-serif">The compiler cannot use =
const as a means of determining if someone is modifying something, because =
const_cast exists in the language. The compiler must be able to prove that =
the operations done on something are in fact=A0constant operations in order=
to optimize based on this assumption.</font></div>
<div class=3D"im">
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">>=
;=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13px">Bein=
g able to get a const_iterator from a iterator would sometimes be indeed us=
eful. Just not the other way around or people start breaking stuff as they =
tend to do now with const_cast.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div></div><div><font face=3D"arial, sans-serif">You can already do this =
-- const iterator has a=A0constructor taking iterator. (e.g. a wchar_t* can=
turn into a wchar_t const* without a cast; and const_iterator must mimic t=
his behavior)</font></div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div><font face=3D"arial, sans-serif"><br></font></div><div><div class=3D"g=
mail_extra"><div><div dir=3D"ltr"><div>Billy O'Neal</div><div>
<a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_bla=
nk">http://stackoverflow.com/users/82320/billy-oneal</a></div></div></div><=
/div></div></font></span></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b6d99b062a58904eef7c2d5--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 02 Jan 2014 11:40:23 -0200
Raw View
On quinta-feira, 2 de janeiro de 2014 08:29:48, Miroslav Knejp wrote:
> You could just make a temporary
> container and use it for the cast. Unless the iterators track their
> container (which is probably only the case in debug builds, if at all)
> this works even better than the advance/distance trick (which is at
> least quite inefficient for most iterator types).
The iterator doesn't need to track the container for the debug code to be able
to verify if the const_iterator being passed belongs to that container.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Thu, 2 Jan 2014 10:51:11 -0500
Raw View
On Jan 1, 2014, at 11:19 PM, Xavi Gratal <gratal@gmail.com> wrote:
> Given a const_iterator ci to an element of a container c, it is already p=
ossible to obtain a non-const iterator with:
>=20
> auto i=3Dstd::advance(c.begin(),std::distance(c.cbegin(),ci);
>=20
> However, this is extremely inefficient for non-random-access containers. =
I would like to add some mechanism to the standard containers so that given=
a non-const reference to the container and a const_iterator, it is possibl=
e to obtain a non-const iterator in constant time.
> This would be useful in a scenario where an algorithm takes a const refer=
ence to a container and finds some interesting element inside, returning a =
const_iterator to it. Then, as long as you have a non-const reference to th=
e container, you should be able to modify the element you found. It is alre=
ady possible to erase it using a const_iterator.
>=20
> Is there any reason why such a facility doesn't exist for the standard co=
ntainers?
It does exist, and it is efficient:
auto i =3D c.erase(ci, ci);
Howard
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: xavi <gratal@gmail.com>
Date: Thu, 2 Jan 2014 18:00:42 +0100
Raw View
--047d7bd76fd0dfa44304eeffbbfe
Content-Type: text/plain; charset=ISO-8859-1
Neat, hadn't thought of that. Thanks for the hint!
2014/1/2 Howard Hinnant <howard.hinnant@gmail.com>
> On Jan 1, 2014, at 11:19 PM, Xavi Gratal <gratal@gmail.com> wrote:
>
> > Given a const_iterator ci to an element of a container c, it is already
> possible to obtain a non-const iterator with:
> >
> > auto i=std::advance(c.begin(),std::distance(c.cbegin(),ci);
> >
> > However, this is extremely inefficient for non-random-access containers.
> I would like to add some mechanism to the standard containers so that given
> a non-const reference to the container and a const_iterator, it is possible
> to obtain a non-const iterator in constant time.
> > This would be useful in a scenario where an algorithm takes a const
> reference to a container and finds some interesting element inside,
> returning a const_iterator to it. Then, as long as you have a non-const
> reference to the container, you should be able to modify the element you
> found. It is already possible to erase it using a const_iterator.
> >
> > Is there any reason why such a facility doesn't exist for the standard
> containers?
>
> It does exist, and it is efficient:
>
> auto i = c.erase(ci, ci);
>
> Howard
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bd76fd0dfa44304eeffbbfe
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Neat, hadn't thought of that. Thanks for the hint!</di=
v><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014/1/2 Ho=
ward Hinnant <span dir=3D"ltr"><<a href=3D"mailto:howard.hinnant@gmail.c=
om" target=3D"_blank">howard.hinnant@gmail.com</a>></span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Jan 1, 2014, at 11:19 P=
M, Xavi Gratal <<a href=3D"mailto:gratal@gmail.com">gratal@gmail.com</a>=
> wrote:<br>
<br>
> Given a const_iterator ci to an element of a container c, it is alread=
y possible to obtain a non-const iterator with:<br>
><br>
> auto i=3Dstd::advance(c.begin(),std::distance(c.cbegin(),ci);<br>
><br>
> However, this is extremely inefficient for non-random-access container=
s. I would like to add some mechanism to the standard containers so that gi=
ven a non-const reference to the container and a const_iterator, it is poss=
ible to obtain a non-const iterator in constant time.<br>
> This would be useful in a scenario where an algorithm takes a const re=
ference to a container and finds some interesting element inside, returning=
a const_iterator to it. Then, as long as you have a non-const reference to=
the container, you should be able to modify the element you found. It is a=
lready possible to erase it using a const_iterator.<br>
><br>
> Is there any reason why such a facility doesn't exist for the stan=
dard containers?<br>
<br>
</div>It does exist, and it is efficient:<br>
<br>
=A0 =A0auto i =3D c.erase(ci, ci);<br>
<br>
Howard<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bd76fd0dfa44304eeffbbfe--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Thu, 2 Jan 2014 10:59:57 -0800
Raw View
--089e0158a92ec0a38204ef0168b7
Content-Type: text/plain; charset=ISO-8859-1
>I believe it is analogous to having erase take const_iterators in the STL
Not really. Erase takes const iterators because it does not modify the
iterators' target; it modifies the container itself, and the iterators
serve merely as position indicators. There's no conceptual const-ness
violation there.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
On Wed, Jan 1, 2014 at 11:29 PM, xavi <gratal@gmail.com> wrote:
>
>
>
> 2014/1/2 Billy O'Neal <billy.oneal@gmail.com>
>
>> >If edge contained const_iterators, it would later be impossible to
>> return non-const references to vertices given edges, while, as is currently
>> implemented, the add_edge function must take non-const iterators, while
>> there is really no reason for it.
>>
>> That seems like the correct thing would be to have non-const iterators
>> there. You intend to modify the object to which the iterator refers; and as
>> such it shouldn't be a const iterator.
>>
>> I'm not saying that this is a bad idea; I'm just saying that example
>> isn't motivating.
>>
> I believe it is analogous to having erase take const_iterators in the
> STL. It was changed in C++11, so someone must have thought it was a good
> idea. In add_edge you are not modifying the vertex, so there is no reason
> why the vertex iterators should be const. Also, to call add_edge you need
> to have a non-const reference to the graph, so there is no logical
> constness violation in any case.
>
> Forcing the user to pass non-const iterators to add_edge means that, for
> example, if we implement an algorithm that finds pairs of vertices that
> should be added to the graph to make it connected, we must make the
> algorithm take a non-const reference to the graph, so that the pairs of
> vertices it returns can be used to make the graph connected. Forcing such
> an algorithm to take a non-const reference greatly reduces the
> const-safety, since the algorithm doesn't need to modify the graph. So I
> think this example is quite motivating.
>
>>
>> > C++11 went one step in the right direction by having functions such as
>> erase and insert take const_iterators. Having a way to obtain iterators
>> from const_iterators would allow a class like the above to do the same.
>>
>> But this breaks const correctness. The reason you have the workaround for
>> the random-access containers is that you have a mutable reference to the
>> container itself which avoids breaking const-correctness.
>>
> Yes, my suggestion is to allow it only when you have the mutable
> reference, which is the case in which it's already possible.
>
>>
>> You would need something like:
>>
>> iterator const_iterator_cast(Container& c, Container::const_iterator i)
>>
>> I was thinking more along the lines of a member function:
>
> iterator iterator_to(const_iterator i);
>
> added to containers. The containers should have the knowledge to make
> the conversion, and since it's a non-const function const-correctness
> wouldn't be violated.
>
>
>> This of course makes the assumption that there is some cheap way to
>> recover an iterator given a const iterator; though I suspect 99.99% of the
>> time that is true.
>>
>> > if the compiler is trying to keep track of who might modify what.
>>
>> The compiler cannot use const as a means of determining if someone is
>> modifying something, because const_cast exists in the language. The
>> compiler must be able to prove that the operations done on something are in
>> fact constant operations in order to optimize based on this assumption.
>>
>> > Being able to get a const_iterator from a iterator would sometimes be
>> indeed useful. Just not the other way around or people start breaking stuff
>> as they tend to do now with const_cast.
>>
>> You can already do this -- const iterator has a constructor taking
>> iterator. (e.g. a wchar_t* can turn into a wchar_t const* without a cast;
>> and const_iterator must mimic this behavior)
>>
>> Billy O'Neal
>> http://stackoverflow.com/users/82320/billy-oneal
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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/.
--089e0158a92ec0a38204ef0168b7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">><span style=3D"font-family:arial,sans-serif;font-size:=
13px">I believe it is analogous to having erase take const_iterators in the=
STL</span><div><span style=3D"font-family:arial,sans-serif;font-size:13px"=
><br>
</span></div><div><font face=3D"arial, sans-serif">Not really. Erase takes =
const iterators because it does not modify the iterators' target; it=A0=
modifies=A0the container itself, and=A0the iterators serve merely as positi=
on indicators. There's no conceptual const-ness violation there.</font>=
</div>
<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http:/=
/stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>
</div></div>
<br><br><div class=3D"gmail_quote">On Wed, Jan 1, 2014 at 11:29 PM, xavi <s=
pan dir=3D"ltr"><<a href=3D"mailto:gratal@gmail.com" target=3D"_blank">g=
ratal@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div class=3D"im">2014/1/2 Billy O'Neal <span dir=3D"ltr"><<=
a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail=
..com</a>></span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>><span style=3D"font-family:arial,sans-serif;font-=
size:13px">If edge contained const_iterators, it would later be impossible =
to return non-const references to vertices given edges, while, as is curren=
tly implemented, the add_edge function must take non-const iterators, while=
there is really no reason for it.</span><div>
<font face=3D"arial, sans-serif"><br></font></div></div><div><font face=3D"=
arial, sans-serif">That seems like the correct thing would be to have non-c=
onst iterators there. You intend to modify the object to=A0which the iterat=
or refers; and as such it shouldn't be a const iterator.</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">I'm not saying that this is a bad idea; I'm just =
saying that=A0example isn't motivating.</font></div></div></blockquote>=
</div>
<div>
I believe it is analogous to having erase take const_iterators in the STL. =
It was changed in C++11, so someone must have thought it was a good idea. I=
n add_edge you are not modifying the vertex, so there is no reason why the =
vertex iterators should be const. Also, to call add_edge you need to have a=
non-const reference to the graph, so there is no logical constness violati=
on in any case.=A0</div>
<div><br></div><div>Forcing the user to pass non-const iterators to add_edg=
e means that, for example, if we implement an algorithm that finds pairs of=
vertices that should be added to the graph to make it connected, we must m=
ake the algorithm take a non-const reference to the graph, so that the pair=
s of vertices it returns can be used to make the graph connected. Forcing s=
uch an algorithm to take a non-const reference greatly reduces the const-sa=
fety, since the algorithm doesn't need to modify the graph. So I think =
this example is quite motivating.</div>
<div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><font face=3D"ari=
al, sans-serif"><br>
</font></div><div><font face=3D"arial, sans-serif">>=A0</font><span styl=
e=3D"font-family:arial,sans-serif;font-size:13px">C++11 went one step in th=
e right direction by having functions such as erase and insert take const_i=
terators. Having a way to obtain iterators from const_iterators would allow=
a class like the above to do the same.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div></div><div><font face=3D"arial, sans-serif">But this breaks const co=
rrectness. The reason you have the=A0workaround for the random-access conta=
iners is that you have a mutable reference to the container itself which av=
oids breaking const-correctness.</font></div>
</div></blockquote></div><div>Yes, my suggestion is to allow it only when y=
ou have the mutable reference, which is the case in which it's already =
possible.=A0</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">You would need something like:</font></div><div><font fac=
e=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-ser=
if">iterator const_iterator_cast(Container& c, Container::const_iterato=
r i)</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div></div></blockquote><=
/div><div>I was thinking more along the lines of a member function:</div><d=
iv><br></div><div>iterator iterator_to(const_iterator i);</div><div><br>
</div>
<div>added to containers. The containers should have the knowledge to make =
the conversion, and since it's a non-const function const-correctness w=
ouldn't be violated.</div><div>=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">
<div dir=3D"ltr"><div><font face=3D"arial, sans-serif"></font></div><div><f=
ont face=3D"arial, sans-serif">This of course makes the assumption that the=
re is some cheap way to recover an iterator given a const iterator; though =
I suspect 99.99% of the time that is true.</font></div>
<div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">>=A0</font><span style=3D"font-family:arial,sans-serif=
;font-size:13px">if the compiler is trying to keep track of who might modif=
y what.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div></div><div><font face=3D"arial, sans-serif">The compiler cannot use =
const as a means of determining if someone is modifying something, because =
const_cast exists in the language. The compiler must be able to prove that =
the operations done on something are in fact=A0constant operations in order=
to optimize based on this assumption.</font></div>
<div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">>=
;=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13px">Bein=
g able to get a const_iterator from a iterator would sometimes be indeed us=
eful. Just not the other way around or people start breaking stuff as they =
tend to do now with const_cast.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div></div><div><font face=3D"arial, sans-serif">You can already do this =
-- const iterator has a=A0constructor taking iterator. (e.g. a wchar_t* can=
turn into a wchar_t const* without a cast; and const_iterator must mimic t=
his behavior)</font></div>
<span><font color=3D"#888888">
<div><font face=3D"arial, sans-serif"><br></font></div><div><div class=3D"g=
mail_extra"><div><div dir=3D"ltr"><div>Billy O'Neal</div><div>
<a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_bla=
nk">http://stackoverflow.com/users/82320/billy-oneal</a></div></div></div><=
/div></div></font></span></div></div><div><div>
<p></p>
-- <br><div class=3D"im">
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></div></blockquote></div><br></div></div><div class=3D"HOEnZb">=
<div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0158a92ec0a38204ef0168b7--
.
Author: Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
Date: Thu, 2 Jan 2014 17:23:34 -0200
Raw View
On Thu, Jan 2, 2014 at 1:51 PM, Howard Hinnant <howard.hinnant@gmail.com> wrote:
>
[snip]
>> Is there any reason why such a facility doesn't exist for the standard containers?
>
> It does exist, and it is efficient:
>
> auto i = c.erase(ci, ci);
Wow, I'd never thought of that! And I agree, as the OP, that this
feature is really
useful. Maybe someone should propose Boost to create a free function that
does exactly this.
template <typename Container>
typename Container::iterator const_iterator_cast(Container& c,
typename Container::const_iterator i)
{
return c.erase(i, i);
}
> Howard
>
> --
Regards,
--
Felipe Magno de Almeida
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Thu, 2 Jan 2014 11:25:20 -0800
Raw View
--047d7b47202c75a2b504ef01c384
Content-Type: text/plain; charset=ISO-8859-1
I wouldn't even call that a cast -- "cast" implies "messing with the type
system" -- and this isn't. :)
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
On Thu, Jan 2, 2014 at 11:23 AM, Felipe Magno de Almeida <
felipe.m.almeida@gmail.com> wrote:
> On Thu, Jan 2, 2014 at 1:51 PM, Howard Hinnant <howard.hinnant@gmail.com>
> wrote:
> >
>
> [snip]
>
> >> Is there any reason why such a facility doesn't exist for the standard
> containers?
> >
> > It does exist, and it is efficient:
> >
> > auto i = c.erase(ci, ci);
>
> Wow, I'd never thought of that! And I agree, as the OP, that this
> feature is really
> useful. Maybe someone should propose Boost to create a free function that
> does exactly this.
>
> template <typename Container>
> typename Container::iterator const_iterator_cast(Container& c,
> typename Container::const_iterator i)
> {
> return c.erase(i, i);
> }
>
> > Howard
> >
> > --
>
> Regards,
> --
> Felipe Magno de Almeida
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b47202c75a2b504ef01c384
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I wouldn't even call that a cast -- "cast" i=
mplies "messing with the type system" -- and this isn't. :)</=
div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div=
>Billy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/=
users/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/8=
2320/billy-oneal</a></div>
</div></div>
<br><br><div class=3D"gmail_quote">On Thu, Jan 2, 2014 at 11:23 AM, Felipe =
Magno de Almeida <span dir=3D"ltr"><<a href=3D"mailto:felipe.m.almeida@g=
mail.com" target=3D"_blank">felipe.m.almeida@gmail.com</a>></span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Thu, Jan 2, 2014 at 1:51 PM, Howard Hinna=
nt <<a href=3D"mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com=
</a>> wrote:<br>
><br>
<br>
[snip]<br>
<div class=3D"im"><br>
>> Is there any reason why such a facility doesn't exist for the =
standard containers?<br>
><br>
> It does exist, and it is efficient:<br>
><br>
> =A0 =A0auto i =3D c.erase(ci, ci);<br>
<br>
</div>Wow, I'd never thought of that! And I agree, as the OP, that this=
<br>
feature is really<br>
useful. Maybe someone should propose Boost to create a free function that<b=
r>
does exactly this.<br>
<br>
template <typename Container><br>
typename Container::iterator const_iterator_cast(Container& c,<br>
typename Container::const_iterator i)<br>
{<br>
=A0 return c.erase(i, i);<br>
}<br>
<br>
> Howard<br>
><br>
> --<br>
<br>
Regards,<br>
--<br>
Felipe Magno de Almeida<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b47202c75a2b504ef01c384--
.
Author: Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
Date: Thu, 2 Jan 2014 17:28:01 -0200
Raw View
On Thu, Jan 2, 2014 at 5:25 PM, Billy O'Neal <billy.oneal@gmail.com> wrote:
> I wouldn't even call that a cast -- "cast" implies "messing with the type
> system" -- and this isn't. :)
I wouldn't too. But I didn't find a better name. I'm open to suggestions :).
> Billy O'Neal
> https://github.com/BillyONeal/
> http://stackoverflow.com/users/82320/billy-oneal
[snip]
Regards,
--
Felipe Magno de Almeida
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: xavi <gratal@gmail.com>
Date: Thu, 2 Jan 2014 20:57:44 +0100
Raw View
--047d7bf16006f50a0304ef02341a
Content-Type: text/plain; charset=ISO-8859-1
It kind of messes with the type system. You can use it to cheat, since the
container c doesn't need to be the one containing the iterator. Also, at
least in gcc 4.9 (it's not supported in 4.8 and earlier), it is implemented
with a const_cast, so yes, I believe there's some messing :).
The only way to implement it without a cast is that const_iterators
actually contain non-const pointers, which is possible, but not any safer.
2014/1/2 Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
> On Thu, Jan 2, 2014 at 5:25 PM, Billy O'Neal <billy.oneal@gmail.com>
> wrote:
> > I wouldn't even call that a cast -- "cast" implies "messing with the type
> > system" -- and this isn't. :)
>
> I wouldn't too. But I didn't find a better name. I'm open to suggestions
> :).
>
> > Billy O'Neal
> > https://github.com/BillyONeal/
> > http://stackoverflow.com/users/82320/billy-oneal
>
> [snip]
>
> Regards,
> --
> Felipe Magno de Almeida
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bf16006f50a0304ef02341a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It kind of messes with the type system. You can use it to =
cheat, since the container c doesn't need to be the one containing the =
iterator. Also, at least in gcc 4.9 (it's not supported in 4.8 and earl=
ier), it is implemented with a const_cast, so yes, I believe there's so=
me messing :).<div>
The only way to implement it without a cast is that const_iterators actuall=
y contain non-const pointers, which is possible, but not any safer.</div></=
div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014/1/2 =
Felipe Magno de Almeida <span dir=3D"ltr"><<a href=3D"mailto:felipe.m.al=
meida@gmail.com" target=3D"_blank">felipe.m.almeida@gmail.com</a>></span=
><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Thu, Jan 2, 2014 at 5:2=
5 PM, Billy O'Neal <<a href=3D"mailto:billy.oneal@gmail.com">billy.o=
neal@gmail.com</a>> wrote:<br>
> I wouldn't even call that a cast -- "cast" implies "=
;messing with the type<br>
> system" -- and this isn't. :)<br>
<br>
</div>I wouldn't too. But I didn't find a better name. I'm open=
to suggestions :).<br>
<div class=3D"im"><br>
> Billy O'Neal<br>
> <a href=3D"https://github.com/BillyONeal/" target=3D"_blank">https://g=
ithub.com/BillyONeal/</a><br>
> <a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a><br>
<br>
</div>[snip]<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Regards,<br>
--<br>
Felipe Magno de Almeida<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bf16006f50a0304ef02341a--
.
Author: Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
Date: Thu, 2 Jan 2014 19:47:36 -0200
Raw View
On Thu, Jan 2, 2014 at 5:57 PM, xavi <gratal@gmail.com> wrote:
> It kind of messes with the type system. You can use it to cheat, since the
> container c doesn't need to be the one containing the iterator. Also, at
> least in gcc 4.9 (it's not supported in 4.8 and earlier), it is implemented
> with a const_cast, so yes, I believe there's some messing :).
> The only way to implement it without a cast is that const_iterators actually
> contain non-const pointers, which is possible, but not any safer.
That is undefined behavior. The function's preconditions is obvious and if
you deviate from that then that's outside the function's goal. So,
if you use it for messing with the type system, then it is your fault and
not the function's objective.
Regards,
--
Felipe Magno de Almeida
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Thu, 2 Jan 2014 17:03:59 -0500
Raw View
--001a11369b0e82f5aa04ef03f812
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jan 2, 2014 at 4:47 PM, Felipe Magno de Almeida <
felipe.m.almeida@gmail.com> wrote:
> That is undefined behavior. The function's preconditions is obvious and if
> you deviate from that then that's outside the function's goal. So,
> if you use it for messing with the type system, then it is your fault and
> not the function's objective.
>
> How does that differ from say 'const_cast'? The preconditions are clear
and so on... Not saying it has to be one way or another, but this is
borderline on the semantics of 'const_cast'. If you consider that an
iterator models a pointer, a conversion from 'const_iterator' to 'iterator'
is equivalent in semantics as a conversion from 'T const *' to 'T *'. And
this is really a conversion from one type to another, which is commonly
used by means of "casts".
At any rate this is bikeshed discussion, so ignoring the name, the question
stands: should the standard provide a mechanism to transform a
'const_iterator' into an 'iterator'?
Adding to the bikeshed discussion: this could be part of the iterator
traits:
iterator_traits<std::vector<int>::const_iterator>::mutable_iterator(cit)
This is unprocessed thought, it might be a function, a functor or some
other mechanism, but if this is going to move forward users should be able
to provide a way of transforming their own iterators.
--
---
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/.
--001a11369b0e82f5aa04ef03f812
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 2, 2014 at 4:47 PM, Felipe Magno de Almeida <span dir=3D"ltr"><<=
a href=3D"mailto:felipe.m.almeida@gmail.com" target=3D"_blank">felipe.m.alm=
eida@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(3=
4,34,34)">That is undefined behavior. The function's preconditions is o=
bvious and if</span><br>
</div>
you deviate from that then that's outside the function's goal. So,<=
br>
if you use it for messing with the type system, then it is your fault and<b=
r>
not the function's objective.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div>H=
ow does that differ from say 'const_cast'? The preconditions are cl=
ear and so on... Not saying it has to be one way or another, but this is bo=
rderline on the semantics of 'const_cast'. If you consider that an =
iterator models a pointer, a conversion from 'const_iterator' to &#=
39;iterator' is equivalent in semantics as a conversion from 'T con=
st *' to 'T *'. And this is really a conversion from one type t=
o another, which is commonly used by means of "casts".<br>
<br>At any rate this is bikeshed discussion, so ignoring the name, the ques=
tion stands: should the standard provide a mechanism to transform a 'co=
nst_iterator' into an 'iterator'?<br><br>Adding to the bikeshed=
discussion: this could be part of the iterator traits:<br>
<br>iterator_traits<std::vector<int>::const_iterator>::mutable_=
iterator(cit)<br><br>This is unprocessed thought, it might be a function, a=
functor or some other mechanism, but if this is going to move forward user=
s should be able to provide a way of transforming their own iterators.<br>
<br><br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11369b0e82f5aa04ef03f812--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Thu, 2 Jan 2014 14:37:20 -0800
Raw View
--f46d04479f9328ee3204ef04720e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
The difference is that it requires a *mutable* reference to the container.
You aren't converting a const_iterator into an iterator -- you are asking
the mutable container for a mutable iterator at the same position as a
given const_iterator; which is safe.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
On Thu, Jan 2, 2014 at 2:03 PM, David Rodr=EDguez Ibeas <dibeas@ieee.org>wr=
ote:
> On Thu, Jan 2, 2014 at 4:47 PM, Felipe Magno de Almeida <
> felipe.m.almeida@gmail.com> wrote:
>
>> That is undefined behavior. The function's preconditions is obvious and =
if
>> you deviate from that then that's outside the function's goal. So,
>> if you use it for messing with the type system, then it is your fault an=
d
>> not the function's objective.
>>
>> How does that differ from say 'const_cast'? The preconditions are clear
> and so on... Not saying it has to be one way or another, but this is
> borderline on the semantics of 'const_cast'. If you consider that an
> iterator models a pointer, a conversion from 'const_iterator' to 'iterato=
r'
> is equivalent in semantics as a conversion from 'T const *' to 'T *'. And
> this is really a conversion from one type to another, which is commonly
> used by means of "casts".
>
> At any rate this is bikeshed discussion, so ignoring the name, the
> question stands: should the standard provide a mechanism to transform a
> 'const_iterator' into an 'iterator'?
>
> Adding to the bikeshed discussion: this could be part of the iterator
> traits:
>
> iterator_traits<std::vector<int>::const_iterator>::mutable_iterator(cit)
>
> This is unprocessed thought, it might be a function, a functor or some
> other mechanism, but if this is going to move forward users should be abl=
e
> to provide a way of transforming their own iterators.
>
>
> --
>
> ---
> 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/.
>
--=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/.
--f46d04479f9328ee3204ef04720e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The difference is that it requires a *mutable* refere=
nce to the container. You aren't converting a const_iterator into an it=
erator -- you are asking the mutable container for a mutable iterator at th=
e same position as a given const_iterator; which is safe.</div>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>
</div></div>
<br><br><div class=3D"gmail_quote">On Thu, Jan 2, 2014 at 2:03 PM, David Ro=
dr=EDguez Ibeas <span dir=3D"ltr"><<a href=3D"mailto:dibeas@ieee.org" ta=
rget=3D"_blank">dibeas@ieee.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
class=3D"im">On Thu, Jan 2, 2014 at 4:47 PM, Felipe Magno de Almeida <span=
dir=3D"ltr"><<a href=3D"mailto:felipe.m.almeida@gmail.com" target=3D"_b=
lank">felipe.m.almeida@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div><span style=3D"color:rgb(34,34,34)">That is undefined=
behavior. The function's preconditions is obvious and if</span><br>
</div>
you deviate from that then that's outside the function's goal. So,<=
br>
if you use it for messing with the type system, then it is your fault and<b=
r>
not the function's objective.<br>
<div><div><br></div></div></blockquote></div><div>How does that differ from=
say 'const_cast'? The preconditions are clear and so on... Not say=
ing it has to be one way or another, but this is borderline on the semantic=
s of 'const_cast'. If you consider that an iterator models a pointe=
r, a conversion from 'const_iterator' to 'iterator' is equi=
valent in semantics as a conversion from 'T const *' to 'T *=
9;. And this is really a conversion from one type to another, which is comm=
only used by means of "casts".<br>
<br>At any rate this is bikeshed discussion, so ignoring the name, the ques=
tion stands: should the standard provide a mechanism to transform a 'co=
nst_iterator' into an 'iterator'?<br><br>Adding to the bikeshed=
discussion: this could be part of the iterator traits:<br>
<br>iterator_traits<std::vector<int>::const_iterator>::mutable_=
iterator(cit)<br><br>This is unprocessed thought, it might be a function, a=
functor or some other mechanism, but if this is going to move forward user=
s should be able to provide a way of transforming their own iterators.<br>
<br><br></div></div></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--f46d04479f9328ee3204ef04720e--
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Fri, 3 Jan 2014 00:35:44 -0500
Raw View
--089e0115f9020bdc8104ef0a4879
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jan 2, 2014 at 5:37 PM, Billy O'Neal <billy.oneal@gmail.com> wrote:
> The difference is that it requires a *mutable* reference to the container.
> You aren't converting a const_iterator into an iterator -- you are asking
> the mutable container for a mutable iterator at the same position as a
> given const_iterator; which is safe.
>
>
This is a discussion that has been held before in this same thread. You are
asking *a* container to transform the const iterator into a non-const one.
The operation cannot be *checked* in constant time for any container in
which doing `advance(begin(), distance(begin(),it))` is not already
constant time. Without the operation being checked, it is *unsafe*.
Felipe's point was that if the operation need not be checked, it is
undefined behavior and that's that. I mentioned that this does not make a
huge difference from 'const_cast', similar risk of undefined behavior and
similar semantics.
Then you come back stating that having a valid mutable container makes it
safe, but that is not checked, and at this point you can continue the
unproductive discussion by rereading the previous paragraph. You can also
add that undefined behavior could be 'checked' in debug builds, with
checked iterators, using defensive programing techniques and you would have
a point. That is why I mentioned that arguing on the naming is pretty
useless at this point. Both sides have valid points
Summarizing and focusing on what I believe are more productive discussions:
The operation can take a mutable reference to a container together with
const_iterator, *but* the constraints on the operation (constant time) mean
that in the general case it cannot be verified.
Since it cannot be verified, a different approach could just take the
iterator and behave as a cast. It is unsafe, but not much more unsafe than
the previous alternative.
Other than that, we can discuss on the form of the operation (should this
be a trait in 'iterator_traits'? A member function of the `const_iterator`?
A function of the container? A separate operation? (How would users extend
this for their own iterators?)
--
---
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/.
--089e0115f9020bdc8104ef0a4879
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Jan 2, 2014 at 5:37 PM, Billy O'Neal <span dir=
=3D"ltr"><<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">bil=
ly.oneal@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div=
class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The difference is that=
it requires a *mutable* reference to the container. You aren't convert=
ing a const_iterator into an iterator -- you are asking the mutable contain=
er for a mutable iterator at the same position as a given const_iterator; w=
hich is safe.</div>
</div><div class=3D"gmail_extra"><div class=3D"im"><br></div></div></blockq=
uote><div><br></div><div>This is a discussion that has been held before in =
this same thread. You are asking *a* container to transform the const itera=
tor into a non-const one. The operation cannot be *checked* in constant tim=
e for any container in which doing `advance(begin(), distance(begin(),it))`=
is not already constant time. Without the operation being checked, it is *=
unsafe*. Felipe's point was that if the operation need not be checked, =
it is undefined behavior and that's that. I mentioned that this does no=
t make a huge difference from 'const_cast', similar risk of undefin=
ed behavior and similar semantics.</div>
<div><br></div><div>Then you come back stating that having a valid mutable =
container makes it safe, but that is not checked, and at this point you can=
continue the unproductive discussion by rereading the previous paragraph. =
You can also add that undefined behavior could be 'checked' in debu=
g builds, with checked iterators, using defensive programing techniques and=
you would have a point. That is why I mentioned that arguing on the naming=
is pretty useless at this point. Both sides have valid points</div>
<div><br></div><div>Summarizing and focusing on what I believe are more pro=
ductive discussions:</div><div><br></div><div>The operation can take a muta=
ble reference to a container together with const_iterator, *but* the constr=
aints on the operation (constant time) mean that in the general case it can=
not be verified.</div>
<div><br></div><div>Since it cannot be verified, a different approach could=
just take the iterator and behave as a cast. It is unsafe, but not much mo=
re unsafe than the previous alternative.</div><div><br></div><div>Other tha=
n that, we can discuss on the form of the operation (should this be a trait=
in 'iterator_traits'? A member function of the `const_iterator`? A=
function of the container? A separate operation? (How would users extend t=
his for their own iterators?)</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0115f9020bdc8104ef0a4879--
.
Author: Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
Date: Fri, 3 Jan 2014 10:50:45 -0200
Raw View
On Fri, Jan 3, 2014 at 3:35 AM, David Rodr=EDguez Ibeas <dibeas@ieee.org> w=
rote:
> On Thu, Jan 2, 2014 at 5:37 PM, Billy O'Neal <billy.oneal@gmail.com> wrot=
e:
>>
>> The difference is that it requires a *mutable* reference to the containe=
r.
>> You aren't converting a const_iterator into an iterator -- you are askin=
g
>> the mutable container for a mutable iterator at the same position as a g=
iven
>> const_iterator; which is safe.
>>
>
> This is a discussion that has been held before in this same thread. You a=
re
> asking *a* container to transform the const iterator into a non-const one=
..
> The operation cannot be *checked* in constant time for any container in
> which doing `advance(begin(), distance(begin(),it))` is not already const=
ant
> time. Without the operation being checked, it is *unsafe*. Felipe's point
> was that if the operation need not be checked, it is undefined behavior a=
nd
> that's that. I mentioned that this does not make a huge difference from
> 'const_cast', similar risk of undefined behavior and similar semantics.
const_cast is not UB to remove const from objects defined as mutable.
Actually, it exists exactly to allow that. The function I demonstrated
is to get an iterator from its mutable container that points to the same
position as a const_iterator. Being able to get a iterator from a
const_iterator without a reference to the correct container is UB.
So the semantics are *completely different*. That you can get away
with UB is just a coincidence and surely not true for all standard
implementations.
> --
Regards,
--=20
Felipe Magno de Almeida
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Maurice Bos <m-ou.se@m-ou.se>
Date: Sat, 25 Jan 2014 14:59:41 +0100
Raw View
--f46d043d66e10f155f04f0cbe47f
Content-Type: text/plain; charset=UTF-8
Hello,
A bit late reply, but you might still be interested: This exact issue was
discussed before:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/1Q_HgjQpirA/jKXXuqaJMHsJ
Kind regards,
Maurice Bos
2014/1/2 Xavi Gratal <gratal@gmail.com>
> Given a const_iterator ci to an element of a container c, it is already
> possible to obtain a non-const iterator with:
>
> auto i=std::advance(c.begin(),std::distance(c.cbegin(),ci);
>
> However, this is extremely inefficient for non-random-access containers. I
> would like to add some mechanism to the standard containers so that given a
> non-const reference to the container and a const_iterator, it is possible
> to obtain a non-const iterator in constant time.
> This would be useful in a scenario where an algorithm takes a const
> reference to a container and finds some interesting element inside,
> returning a const_iterator to it. Then, as long as you have a non-const
> reference to the container, you should be able to modify the element you
> found. It is already possible to erase it using a const_iterator.
>
> Is there any reason why such a facility doesn't exist for the standard
> containers?
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--f46d043d66e10f155f04f0cbe47f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello,<br><br>A bit late reply, but you might still be int=
erested: This exact issue was discussed before: <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msg/std-proposals/1Q_HgjQpirA/jKXXuqaJMHsJ">https:=
//groups.google.com/a/isocpp.org/d/msg/std-proposals/1Q_HgjQpirA/jKXXuqaJMH=
sJ</a><br>
<br>Kind regards,<br>Maurice Bos<br><br></div><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">2014/1/2 Xavi Gratal <span dir=3D"ltr"><=
;<a href=3D"mailto:gratal@gmail.com" target=3D"_blank">gratal@gmail.com</a>=
></span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Given a const_iterator ci t=
o an element of a container c, it is already possible to obtain a non-const=
iterator with:<div>
<br></div><div>auto i=3Dstd::advance(c.begin(),std::distance(c.cbegin(),ci)=
;</div><div><br></div><div>However, this is extremely inefficient for non-r=
andom-access containers. I would like to add some mechanism to the standard=
containers so that given a non-const reference to the container and a cons=
t_iterator, it is possible to obtain a non-const iterator in constant time.=
</div>
<div>This would be useful in a scenario where an algorithm takes a const re=
ference to a container and finds some interesting element inside, returning=
a const_iterator to it. Then, as long as you have a non-const reference to=
the container, you should be able to modify the element you found. It is a=
lready possible to erase it using a const_iterator.</div>
<div><br></div><div>Is there any reason why such a facility doesn't exi=
st for the standard containers?</div><span class=3D"HOEnZb"><font color=3D"=
#888888"><div><br></div></font></span></div><span class=3D"HOEnZb"><font co=
lor=3D"#888888">
<p></p>
-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--f46d043d66e10f155f04f0cbe47f--
.