15

Object slicing happens when we assign or copy an object of derived class to an object of its base class, losing the derived part of it in the process.

It has been explained in more depth here: What is the slicing problem in C++?.

(Myself, I don't see it as a problem, rather a natural consequence of language's value semantics, but that's not the point of this question.)

What I wonder is: are there ever situations where you'd use it purposedly? A situtation where it is the "right tool for the job"?

Community
  • 1
  • 1
jrok
  • 54,456
  • 9
  • 109
  • 141
  • 1
    Possible duplicate: http://stackoverflow.com/questions/2389125/object-slicing-is-it-advantage – shivakumar May 07 '13 at 10:17
  • @shivakumar thanks, nice find. The example in the answer is made up, though. I hoped somebody would come up with real world example. – jrok May 07 '13 at 10:32

2 Answers2

7

Sure, it can be useful when wanting to drop the derived portion of class, perhaps to drop dependencies.

For example say we have an object system setup where each base belongs to a derived type, and each derived type has various dependencies, perhaps fulfilled through dependency injection. A clone of a base might want to be created, though a completely new set of dependencies for the actual derived type of that base may want to be assigned.

This can be likened to an game engine where there are many types of colliders. Each collider derives from a base interface-like object in various ways. We want to clone a collider to retrieve it's position and scale (from base), but want to place an entirely different derived implementation on-top of this base. "Object slicing" could be a simple way to achieve this.

In reality a component, or aggregate object organization would make a lot more sense than object slicing specifically, but it's mostly the same idea.

RandyGaul
  • 1,915
  • 14
  • 21
  • Conceptually, it seems like for any given type inheritance-related substitutability will generally be meaningful at exactly one particular depth of mutable indirection. Java and .NET assume that except for arrays substitutability applies to singly-indirect references (a reference to `derived` substitutes for a reference to a `base`, but e.g. ` List` does not substitute for `List`). I would posit that the main slicing "problem" stems from the fact that types which are substitutable directly should not allow single-indirect substitutions of mutable references. – supercat Aug 12 '13 at 16:58
1

Some STL implementations actually use object slicing to implement algorithms: E.g., using iterator_tags you can easily make std::advance use the most efficient algorithm:

namespace std {

template <class I>
void advance_impl(I& it, int n, input_iterator_tag) {
    for (; n > 0; --n)
        ++it;
}

// Forward Iterators use the same implementation as Input Iterators...

// TODO:
// Add bidirectional_iterator_tag implementation...

template <class I>
void advance_impl(I& it, int n, random_access_iterator_tag) {
    it += n;
}

template <class I>
void advance(I& it, int n) {
    advance_impl(it, n, typename iterator_traits<I>::iterator_category());
}

} // std

Using your own little class hierarchy you can disambiguate otherwise ambiguous function overloads. E.g. to convert an object to a std::string you might want to use the objects member function to_string() if it exists or otherwise use operator<<.

struct R2 {};       // rank 2
struct R1 : R2 {};  // rank 1

// C++11.
// Use some type traits and enable_if in C++03.
template <class T>
auto ToString(R1, T const& t) -> decltype(t.to_string()) {
    return t.to_string();
}

template <class T>
std::string ToString(R2, T const& t) {
    std::ostringstream s;
    s << t;
    return s.str();
}

template <class T>
std::string ToString(T const& t) {
    return ToString(R1(), t);
}
user3250917
  • 76
  • 3