[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