9

I'm considering this question on const and non-const class methods. The preferred answer is taken from Effective C++ by Scott Meyers, where the non-const method is implemented in terms of the const method.

Extending this further, how can code duplication be reduced if the methods return iterators instead of references? Modifying the example in the linked question:

class X
{
    std::vector<Z> vecZ;    
public:
    std::vector<Z>::iterator Z(size_t index)
    {
        // ...
    }
    std::vector<Z>::const_iterator Z(size_t index) const
    {
        // ...
    }
};

I can't implement the non-const method in terms of the const method because it's not possible to convert directly from a const_iterator to an iterator without using the distance()/advance() technique.

In the example, because we're using a std::vector as the container, it might actually be possible to cast from a const_iterator to an iterator because they may well be implemented as pointers. I don't want to rely on this. Is there a more general solution?

2
  • This function is either trivial or it should be implemented as an algorithm function template that makes the member function trivial again.
    – ipc
    Commented Jan 21, 2013 at 19:49
  • In this case, both functions could be return vecZ.begin() + index. Or, if you absolutely must make them different, the const version could be return vecZ.cbegin() + index. Look ma, no duplication!
    – Bo Persson
    Commented Jan 21, 2013 at 20:32

3 Answers 3

5

There are a couple tricks you can use. You can turn a const_iterator into an iterator if you have non-const access to the container. (which you do):

std::vector<Z>::iterator Z(size_t index)
{
    std::vector<Z>::const_iterator i = static_cast<const X&>(*this).Z(index);
    return vecZ.erase(i, i);
}

You could also do this:

std::vector<Z>::iterator Z(size_t index)
{
    return std::next(vecZ.begin(), std::distance(vecZ.cbegin(), static_cast<const X&>(*this).Z(index)));
}

Neither are particularly elegant. Why don't we have a const_iterator_cast like const_pointer_cast? Maybe we should.

EDIT, I missed the most obvious and elegant solution because I was trying to use the const method from the non-const method. Here I do the opposite:

std::vector<Z>::const_iterator Z(size_t index) const
{
    return const_cast<X&>(*this).Z(index);
}

You are dereferencing the result of const_cast however this is not undefined behavior as long as the non-const Z does not modify any data in X. Unlike the other 2 solutions I gave, this is one I might use in practice.

3
  • 1
    You should always implement the const version and const cast away from that. This prevents the implementation from accidently mutating this. Commented Jan 22, 2013 at 13:52
  • @CharlesBeattie Prevents the implementation from accidentally mutating this? It prevents you from accidentally mutating this in your non-const method. But, I already wrote that disclaimer. It's UB if you do modify X in the non-const Z and call the non-const Z from the const Z. I agree that this is bad practice, especially if people are messing with Z and someone might add some modifying code to it.
    – David
    Commented Jan 22, 2013 at 13:56
  • 1
    Yes I think your thinking mirrors mine on this. I wanted to add extra emphasis the last solution is bad practice (although it is a practical solution.) Commented Jan 22, 2013 at 14:06
2

I believe, it is only possible with the helper

typedef int Z;

class X
{
    std::vector<Z> vecZ;    
public:
    std::vector<Z>::iterator foo(size_t index)
    {
        return helper(*this);
    }
    std::vector<Z>::const_iterator foo(size_t index) const
    {
        return helper(*this);
    }

    template <typename T>
    static auto helper(T& t) -> decltype(t.vecZ.begin())
    {
        return t.vecZ.begin();
    }
};

EDIT Same can be implemented without c++11

template <typename T>
struct select
{
    typedef std::vector<Z>::iterator type;
};
template <typename T>
struct select<const T&>
{
    typedef std::vector<Z>::const_iterator type;
};

template <typename T>
static
typename select<T>::type
helper(T t) 
{
    return t.vecZ.begin();
}

But, well, I think you should think twice before using this approcach

9
  • That looks like a useful approach, though I won't have a C++11 compiler for my target platform for the foreseeable future. Commented Jan 21, 2013 at 20:04
  • This has the same problem as in the attempt three days ago to reduce code duplication - it actually results in more code. Where is the advantage?
    – Bo Persson
    Commented Jan 21, 2013 at 20:20
  • 2
    @BoPersson, The idea is that helper could take more than one line. And it could be more than one function, that uses select
    – Lol4t0
    Commented Jan 21, 2013 at 20:22
  • I actually like @Dave first solution
    – Lol4t0
    Commented Jan 21, 2013 at 20:23
  • 2
    @BoPersson, if we continue going in this direction we could come up with #define Z this.vecZ.begin() :) The idea is that in my and @Dave example it exists single point, where code should be modified, so modifications will be reflected in both const and not const version. Ithink, that is main idea, not technically reducing number of lines of code.
    – Lol4t0
    Commented Jan 21, 2013 at 20:38
1

If you're using C++11, there is a more elegant (IMHO) way that uses only two typedefs in a template iterator class to distinguish between a const and regular iterator: http://www.sjvs.nl/c-implementing-const_iterator-and-non-const-iterator-without-code-duplication/

Not the answer you're looking for? Browse other questions tagged or ask your own question.