[PATCH] D31153: Add the ability to use the children() range API in a const-correct manner
David Blaikie via cfe-commits
cfe-commits at lists.llvm.org
Mon Mar 27 14:28:06 PDT 2017
On Mon, Mar 27, 2017 at 10:20 AM Aaron Ballman via Phabricator <
reviews at reviews.llvm.org> wrote:
> aaron.ballman added a comment.
>
> In https://reviews.llvm.org/D31153#711287, @dblaikie wrote:
>
> > As I mentioned to Craig Topper recently on another review, generally
> when implementing const and non-const overloads the non-const is
> implemented in terms of the const overload (& const_casts away const on the
> result). This ensures no UB if the const overload is called on a truly
> const object. Even if there aren't any truly const Stmts today, I'd still
> prefer the code be written so as not to assume they couldn't exist.
>
>
> In practice, this is really hard to do because there's no such thing as a
> const_iterator_cast operation to convert a const_iterator into an iterator,
> unless you have the underlying container handy.
Seems like it might be feasible to implement. Something along the lines of:
struct StmtIterator : ... {
private:
StmtIterator(const ConstStmtIterator& RHS) : StmtIteratorImpl(RHS) { }
friend StmtIterator const_cast(const ConstStmtIterator& RHS) {
return RHS;
}
Something along those lines, I think?
(StmtIteratorImpl has a protected ctor that takes a StmtIteratorBase -
const or non-const, it doesn't seem to care - so StmtIterator can call that
with a ConstStmtIterator and do the conversion?)
> Since many of these uses do not have an underlying container (they're
> often trailing objects), I'm not certain this is practical (though I agree
> with the reasoning). Suggestions welcome, however.
>
>
> https://reviews.llvm.org/D31153
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170327/de360cb0/attachment.html>
More information about the cfe-commits
mailing list