Fact-checked by Grok 2 weeks ago

Object slicing

Object slicing is a concept in the C++ programming language where an object of a derived class is copied or assigned to an object of its base class, resulting in the loss of the derived class's additional data members and potentially its polymorphic behavior, as only the base class portion is retained. This occurs during value-based operations, such as passing a derived object by value to a function expecting a base class parameter or directly assigning a derived object to a base class variable, because C++ performs a shallow copy that truncates the object to the size of the base class. The behavior is defined in the C++ standard under copying and moving class objects, where the derived parts are effectively "sliced off" without invoking any special handling for polymorphism unless virtual functions are involved post-slicing. The consequences of object slicing include , unexpected program behavior, and corruption of polymorphic hierarchies, as calls on the sliced object may resolve to the base class implementation rather than the derived one, leading to subtle bugs that are difficult to debug. To avoid slicing, C++ best practices recommend using references or pointers to base classes for polymorphic operations, suppressing public copy constructors and assignment operators in base classes (often with a method), or preferring concrete types over deep hierarchies when possible.

Fundamentals of Object Slicing

Definition and Core Concept

Object slicing in C++ refers to the process where an object of a derived is implicitly or explicitly converted to a base type, resulting in the truncation of the derived 's specific data members and the associated table information. This conversion copies only the base subobject, effectively discarding the additional attributes and polymorphic capabilities unique to the derived . At its core, object slicing arises from C++'s value semantics, which perform a shallow copy during or initialization. When a derived object is treated as a object, the generates code that copies solely the memory layout of the class portion, leading to the loss of derived-specific members and potentially altering runtime behavior by substituting the base class's virtual dispatch mechanism. This mechanism highlights C++'s emphasis on explicit control over , without built-in deep cloning for hierarchies. The term "object slicing" emerged in the early development of C++ to describe this unintended data loss, stemming from the language's design choices favoring value-based copying over automatic polymorphic preservation, as explored in foundational texts on C++ programming. To illustrate, consider the following pseudocode demonstrating slicing upon assignment: 
class Base {
public:
    int base_member;
};

class Derived : public Base {
public:
    int derived_member;
};

Derived d;
d.base_member = 1;
d.derived_member = 2;

Base b = d;  // Slicing: only base_member (value 1) is copied to b; derived_member is lost
In this example, the assignment truncates the Derived object's layout to match Base, preserving only the shared subobject while eliminating the extended portion.

Relation to Object-Oriented Programming Principles

Object slicing emerges as a consequence of the "is-a" relationship in object-oriented inheritance, where a derived class object can be substituted for a base class object, but C++'s default static binding during value-based operations truncates the derived portions, retaining only the base subobject. In this context, C++ leverages inheritance to extend base class functionality while preserving substitutability, yet the language's compile-time type checking enforces static resolution for non-polymorphic copies, leading to the loss of derived-specific attributes. Within the polymorphism paradigm, object slicing undermines (dynamic) polymorphism by enforcing static binding when derived objects are copied by value, as opposed to C++'s support for dynamic binding through s. C++ distinguishes static binding, which resolves function calls at based on the static type (e.g., the base class declaration), from dynamic binding, which uses the virtual function table (vtable) to dispatch calls at according to the dynamic type of the object. However, slicing discards the derived class's vtable pointer, replacing it with the base class's, thereby preventing access to overridden s and reverting behavior to the base implementation. C++'s emphasis on value semantics further facilitates slicing, as objects are copied in their entirety by default during assignments or parameter passing, but polymorphic conversions implicitly copy only the base subobject, excluding derived data and vtable adjustments. This contrasts with semantics, where assignments copy only a reference or pointer, preserving the full derived object and enabling polymorphic dispatch without . Value semantics prioritize efficiency through direct copies but introduce slicing risks in inheritance hierarchies, as the compiler does not automatically extend the copy to include derived members. As a prerequisite, object slicing risks are inherent in both single and multiple inheritance, where the former involves a straightforward subobject and the latter complicates layout with multiple subobjects, amplifying potential and vtable misalignment upon slicing. In single inheritance, the derived object contains a single subobject followed by derived members, and slicing extracts only that base portion, discarding the rest including the vtable override. heightens these risks by requiring careful subobject ordering and potential vtable adjustments per , which are not preserved in value copies, leading to incomplete polymorphic hierarchies.

Mechanisms Causing Object Slicing in C++

Slicing During Object Assignment

In C++, object slicing during object assignment occurs when a derived class object is assigned to a base class object variable, resulting in an implicit conversion that copies only the base class subobject and discards the derived class's additional members. This behavior arises from the default assignment operator (or copy constructor in initialization contexts), which performs member-wise copying limited to the base class's data and virtual function table (vtable), while omitting the derived class's members, thereby creating an incomplete representation of the original object. The slicing is implicit in standard assignments, such as Base b = Derived(), where copy initialization invokes the copy constructor, or in direct assignments like b = derived_object, where the assignment operator handles the conversion; explicit , such as static_cast<Base>(derived_object), produces the same slicing effect by forcing the . The following compilable C++ example demonstrates slicing with a Shape and derived class Circle that includes a radius member; after , the derived-specific data is lost, and polymorphic behavior reverts to the . 
cpp
#include <iostream>

class Shape {
public:
    Shape() = default;
    virtual ~Shape() = default;
    virtual void draw() const {
        std::cout << "Drawing a generic shape." << std::endl;
    }
};

class Circle : public Shape {
public:
    Circle(double r) : radius(r) {}
    void draw() const override {
        std::cout << "Drawing a circle with radius " << radius << "." << std::endl;
    }
private:
    double radius{0.0};
};

int main() {
    Circle c(5.0);
    c.draw();  // Outputs: Drawing a circle with radius 5.

    Shape s;
    s = c;  // Assignment slices the Circle object, copying only Shape portion.
    s.draw();  // Outputs: Drawing a generic shape.
              // radius is not accessible or copied.

    Shape s2 = c;  // Initialization also slices.
    s2.draw();  // Outputs: Drawing a generic shape.

    return 0;
}
In this snippet, the assignment s = c invokes Shape's default assignment operator, which copies base members but excludes Circle::radius, rendering s a plain Shape instance unaware of the original circle's properties.

Slicing in Function Parameters and Return Values

In C++, object slicing frequently occurs when functions accept parameters of a base class type by value and a derived class object is passed as an argument. This process involves copying only the base class portion of the derived object into the function's parameter, effectively discarding the derived class's additional data members and virtual function table entries. The base class's copy constructor is invoked during this copy operation, as the parameter is treated as a base class instance, leading to the loss of polymorphic behavior within the function scope. Consider the following example, where a base class Animal has a derived class Dog with an extra member: 
cpp
class Animal {
public:
    virtual void makeSound() const { std::cout << "Some generic animal sound\n"; }
    std::string name;
};

class Dog : public Animal {
public:
    virtual void makeSound() const override { std::cout << "Woof!\n"; }
    int tailLength;
};

void processAnimal(Animal a) {  // Pass-by-value parameter
    a.makeSound();  // Calls Animal's version due to slicing
}
When invoking processAnimal(Dog{{"Buddy"}, 12}), the Dog object is sliced: the tailLength is lost, and the parameter a behaves as a plain Animal, outputting "Some generic animal sound". This demonstrates how the derived object's identity is truncated during the copy to the stack-allocated parameter. Object slicing also arises in function return statements when a derived class object is returned as a base class type by value. Here, the return value is constructed as a base class object, copying only the base portion and invoking the base copy constructor, which severs the derived components regardless of the caller's expectations for polymorphism. Even with return value optimization (RVO) or named return value optimization (NRVO), which elide unnecessary copies by constructing the return object directly in the caller's storage, slicing persists because the return type dictates the base class layout; optimizations merely avoid redundant copies of the already-sliced base object. For instance: 
cpp
Animal createAnimal() {
    Dog d{{"Buddy"}, 12};
    return d;  // Slices d to Animal type
}
The returned Animal from createAnimal() retains only the base data, losing tailLength and the overridden makeSound(), with RVO potentially constructing it in-place but still as a base instance. This can propagate incomplete objects to callers, complicating downstream polymorphic usage. When parameters or return values involve pass-by-value, temporary objects are often allocated on the stack, exacerbating slicing risks. For parameters, the derived argument binds to a temporary base object on the function's stack frame, whose lifetime ends when the function returns, potentially leaving callers with dangling references to sliced remnants if not handled carefully. Return temporaries similarly occupy stack space briefly before optimization or copy, but the sliced base form limits their utility and can lead to subtle lifetime mismatches in chained function calls. These stack-based mechanics underscore the efficiency trade-offs of value passing, where slicing not only loses data but also incurs unnecessary construction overhead on limited stack resources.

Consequences of Object Slicing

Loss of Derived Class Data and Members

Object slicing in results in the truncation of data specific to the derived class when a derived object is copied into a base class object, as only the base class subobject is replicated during the assignment or initialization process. This means that any data members—whether private, protected, or public—declared in the derived class are not copied over to the target base class object. Instead, these derived-specific members are effectively discarded, leaving the base class object without access to that information. Consequently, if the base class object attempts to utilize or rely on derived data indirectly, it may encounter default-initialized values (for uninitialized members) or undefined behavior if the code assumes the presence of derived state. The size of the resulting base class object underscores this data loss, as it matches only the layout and memory footprint of the base class (sizeof(Base)), rather than the larger size of the derived class (sizeof(Derived)), which includes additional members and potential virtual table pointers. This mismatch arises because the compiler invokes the base class's copy constructor or assignment operator, which operates solely on the base subobject, ignoring the extended derived portion. In practice, this can lead to subtle bugs where the sliced object appears functional for base class operations but fails to preserve the full state intended by the derived class design. In scenarios involving multiple inheritance, object slicing introduces further complications, particularly in diamond or complex hierarchies, where the derived class inherits from multiple base classes. When slicing occurs, data from secondary base classes is lost entirely, as only the primary base subobject being assigned to is copied, truncating contributions from other bases. For instance, in a class Manager inheriting from both Employee and Person, assigning a Manager object to an Employee object retains only the Employee portion, discarding Person-specific data and potentially leading to incomplete or inconsistent object states in hierarchical structures. To diagnose this issue, consider the following example, which illustrates the size discrepancy and member omission through object slicing: 
cpp
#include <iostream>

class [Base](/page/Base) {
protected:
    int baseData = 10;
public:
    [Base](/page/Base)() = [default](/page/Default);
    [Base](/page/Base)(const [Base](/page/Base)& other) : baseData(other.baseData) {}
    int getBaseData() const { [return](/page/Return) baseData; }
};

class [Derived](/page/Derived) : [public](/page/Public) [Base](/page/Base) {
private:
    int derivedData = [20](/page/2point0);  // Private member lost in slicing
protected:
    int protectedData = 30;
[public](/page/Public):
    [Derived](/page/Derived)() : [Base](/page/Base)(), protectedData(30), derivedData([20](/page/2point0)) {}
    [Derived](/page/Derived)(const [Derived](/page/Derived)& other) : [Base](/page/Base)(other), protectedData(other.protectedData), derivedData(other.derivedData) {}
    int getDerivedData() const { [return](/page/Return) derivedData; }  // Inaccessible after slicing
};

int main() {
    Derived d;
    std::cout << "sizeof(Derived): " << sizeof(d) << std::endl;  // e.g., 12 (3 ints)
    
    Base b = d;  // Slicing occurs here
    std::cout << "sizeof(Base): " << sizeof(b) << std::endl;     // e.g., 4 (1 int)
    std::cout << "b.getBaseData(): " << b.getBaseData() << std::endl;  // 10, correct
    // std::cout << b.getDerivedData();  // Error: not a member of Base; derivedData lost
    
    return 0;
}
This code demonstrates how the derived object's additional members contribute to its larger size, but post-slicing, the base object reverts to its smaller size, with derived data omitted and inaccessible.

Impact on Polymorphic Behavior

Object slicing fundamentally undermines runtime polymorphism in C++ by converting a derived class object into a base class object, which results in the loss of the derived class's virtual function table (vtable). Each class with virtual functions maintains a vtable containing pointers to its virtual member functions, and objects of that class include a hidden vptr pointing to the appropriate vtable for dynamic dispatch. Upon slicing, the resulting base class object retains only the base class's vptr, directing all virtual function calls to the base class's implementations rather than the overridden versions in the derived class. Non-virtual function calls remain unaffected by slicing in terms of resolution, as they are determined at compile time based on the static type of the object; however, since the sliced object lacks derived class members, only base class non-virtual functions are accessible. In contrast, virtual function calls post-slicing always resolve to the base class's vtable entries, preventing the polymorphic behavior intended for derived class overrides. This disruption occurs because slicing severs the connection to the derived class's runtime type information (RTTI) and vtable. A common pitfall arises during upcasting in containers or collections, such as storing derived objects in a std::vector<Base>. When a derived object is inserted, it is copied by value, triggering slicing that truncates it to the base class size and vtable; subsequent virtual calls on these elements invoke uniform base class behavior, eliminating polymorphism across the collection. This leads to unexpected uniformity in execution, where diverse derived behaviors collapse into a single base implementation. Consider the following example illustrating the loss of polymorphic dispatch: 
cpp
class Shape {
public:
    [virtual](/page/Virtual) void draw() { std::cout << "Drawing a shape" << std::endl; }
};

class Circle : public Shape {
public:
    void draw() override { std::cout << "Drawing a circle" << std::endl; }
};

void process(Shape s) {
    s.draw();  // Calls Shape::draw() due to slicing
}

int main() {
    Circle c;
    process(c);  // Outputs: "Drawing a shape"
    return 0;
}
Here, passing a Circle object by value to process slices it into a Shape, causing the draw() call to use the base class vtable and output the base implementation, despite the original object's derived type. Using a reference or pointer, such as void process(Shape& s), would preserve the vptr and invoke Circle::draw().

Prevention and Mitigation Strategies

Using References and Pointers

One effective strategy to prevent object slicing in C++ is to pass objects of derived classes to functions using references to the base class, such as const Base& or Base&, rather than by value. This approach avoids creating a copy of the object, thereby preserving the complete derived type and enabling polymorphic behavior through dynamic dispatch on virtual functions. By binding the reference to the original derived object, the function can access all members and invoke overridden methods specific to the derived class without truncation of data. For instance, consider a base class Base with a function display() and a derived class Derived that overrides it. When a Derived object is passed by value to a function expecting Base, slicing occurs, and only the base portion is copied, leading to the base version of display() being called. In contrast, passing by reference maintains the full object identity: 
cpp
#include <iostream>

class Base {
public:
    [virtual](/page/Virtual) void display() const {
        std::cout << "Base display" << std::endl;
    }
    [virtual](/page/Virtual) ~Base() = default;
};

class Derived : public Base {
public:
    void display() const override {
        std::cout << "Derived display" << std::endl;
    }
};

void funcByValue(Base b) {
    b.display();  // Calls Base::display due to slicing
}

void funcByRef(const Base& b) {
    b.display();  // Calls Derived::display if b refers to Derived
}

int main() {
    Derived d;
    funcByValue(d);  // Output: Base display
    funcByRef(d);    // Output: Derived display
    return 0;
}
This example demonstrates how reference parameters retain polymorphic access, while value parameters trigger slicing. Pointers provide a similar mechanism for avoiding slicing by allowing a base class pointer, such as Base*, to point to a Derived object, which supports dynamic dispatch without object duplication. This indirection ensures that virtual function calls resolve to the derived implementation at runtime. To manage ownership safely and prevent memory leaks, smart pointers like std::unique_ptr<Base> or std::shared_ptr<Base> should be used, as they handle automatic deallocation while preserving polymorphic type information. In collections, storing pointers to base class objects in containers like std::vector<Base*> or std::vector<std::unique_ptr<Base>> prevents slicing that would occur with std::vector<Base>, where inserting derived objects copies only the base subobject. This pointer-based storage allows a heterogeneous collection of derived types to maintain their full identities and supports iteration with polymorphic operations. For example, pushing new Derived() into a std::vector<Base*> followed by calling display() on each via the base pointer will invoke the appropriate derived method for each element.

Leveraging Virtual Destructors and Constructors

In C++, base classes intended for polymorphic use must declare their destructors as virtual to ensure proper cleanup of derived class objects when deletion occurs through a base class pointer or reference. Without a virtual destructor, deleting a derived object via a base pointer invokes only the base class destructor, potentially leading to resource leaks from uninvoked derived class cleanup code, such as deallocating dynamically allocated memory or closing file handles. This is essential in polymorphic designs that use pointers or references to base classes to avoid object slicing, as it guarantees the complete destructor chain is executed during polymorphic deletion (C.35). To further prevent slicing, polymorphic base classes should suppress public copy constructors and move operations by explicitly deleting them (e.g., Base(const Base&) = delete; Base& operator=(const Base&) = delete;). This physically blocks attempts to copy derived objects into base objects, avoiding . If copying is needed, provide a protected copy constructor or, preferably, a clone() that derived classes override to return a pointer to a new copy of their own type, preserving the full derived state. This aligns with C++ Core Guidelines C.67, which recommends suppressing copy/move in polymorphic classes to eliminate slicing risks. Constructors in C++ cannot be virtual in the traditional sense, as the virtual function table (vtable) is not fully constructed until after the base class constructor completes, preventing polymorphic dispatch during object creation. However, to support polymorphic construction patterns that mitigate slicing—such as avoiding direct copies of derived objects into base containers—developers employ techniques like the or virtual clone methods, where a base class provides a pure virtual clone() function that derived classes override to return pointers to new instances of their own type. These patterns allow runtime determination of the concrete type during creation, preserving derived state and behavior without slicing. emphasizes that while constructors themselves lack virtual behavior, integrating virtual methods for post-construction initialization or cloning enables safe polymorphic object lifecycles in inheritance hierarchies. The Rule of Five extends to base classes with virtual destructors, requiring explicit definitions or deletions of the destructor, copy constructor, copy assignment operator, move constructor, and move assignment operator to manage resource ownership correctly in polymorphic designs. Deleting copy operations not only prevents slicing but also avoids shallow copies of resources that could lead to leaks or . By defaulting or implementing these members appropriately, developers ensure robust object lifecycles, especially when combined with pointers to avoid value-based slicing. The C++ standard reference highlights that violating the Rule of Five in polymorphic bases can suppress implicit moves, underscoring the need for explicit handling. Consider a simple inheritance hierarchy where a base Shape manages a color string, and a derived Circle adds a radius with dynamic allocation: 
cpp
#include <iostream>
#include <string>
#include <memory>

class Shape {
public:
    Shape(const std::string& color) : color_(color) {}
    virtual ~Shape() {  // Virtual destructor
        std::cout << "Shape destructor\n";
    }
    virtual double area() const = 0;
private:
    std::string color_;
};

class Circle : public Shape {
public:
    Circle(const std::string& color, double radius) : Shape(color), radius_(new double(radius)) {}
    ~Circle() override {
        std::cout << "Circle destructor, freeing radius\n";
        delete radius_;
    }
    double area() const override {
        return 3.14159 * (*radius_) * (*radius_);
    }
private:
    double* radius_;
};
Using pointers avoids slicing and leverages the virtual destructor: 
cpp
int main() {
    Shape* s = new Circle("red", 5.0);
    delete s;  // Calls Circle::~Circle() then Shape::~Shape(), freeing radius properly
    return 0;
}
Output:
Circle destructor, freeing radius
Shape destructor In contrast, without the virtual destructor in Shape, only Shape::~Shape() would execute, leaking the memory allocated for radius_. If slicing occurs—e.g., Shape base = *static_cast<Shape*>(new Circle("red", 5.0));—the temporary Circle is destroyed (calling its full destructor if managed correctly), but the base object lacks the radius allocation, illustrating ; subsequent deletion of base calls only the base destructor, with no derived resources to leak in this copy but highlighting the broader lifecycle risks in non-pointer designs. This example demonstrates how virtual destructors safeguard against incomplete cleanup in polymorphic scenarios, even as slicing itself must be avoided via .

Object Slicing in Other Programming Languages

Absence in Java and Garbage-Collected Languages

In , objects are allocated on the and manipulated exclusively through , which are pointers to these objects rather than copies of their contents. This ensures that assignments and upcasts do not involve value copying of the object itself; instead, only the reference is duplicated, preserving the full identity and state of the derived class object even when stored in a base class variable. As a result, object slicing—where derived class data is lost due to shallow copying—cannot occur, as there is no mechanism for direct object value semantics in non-primitive types. Java enforces polymorphism through dynamic method dispatch by default for all overriding methods, eliminating the risk of vtable loss associated with slicing. Non-static, non-final methods are implicitly , meaning that invocations on a base class resolve to the overridden in the actual derived object at , without any shallow copy altering the object's . This design inherently supports subtype polymorphism while avoiding the data truncation that slicing introduces in value-based languages. The role of Java's garbage collection further reinforces the absence of slicing by providing automatic memory management for heap-allocated objects, removing the need for manual allocation, copying, or deallocation that could expose programmers to slicing pitfalls in lower-level languages. Garbage collection identifies and reclaims unreachable objects, ensuring that references always point to complete, intact instances without the complications of stack-based value copies or handling. To illustrate, consider a C++-like scenario translated to : a base Animal with a makeSound() and a derived Dog that overrides it and adds a bark() field-specific . Assigning a Dog instance to an Animal reference preserves the full Dog object. 
java
class Animal {
    public void makeSound() {
        System.out.println("Animal sound");
    }
}

class Dog extends [Animal](/page/A.N.I.M.A.L.) {
    public void makeSound() {
        System.out.println("Woof!");
    }
    public void bark() {
        System.out.println("Barking...");
    }
}

[public](/page/Public) class Example {
    [public](/page/Public) static void main(String[] args) {
        Dog myDog = new Dog();
        [Animal](/page/A.N.I.M.A.L.) animalRef = myDog;  // Assignment copies reference, no slicing
        animalRef.makeSound();     // Outputs "Woof!" via dynamic dispatch
        ((Dog) animalRef).bark();  // Full derived object accessible via cast
    }
}
In this example, the derived data and remain intact, demonstrating how Java's semantics prevent any loss from assignment.

Similarities and Differences in C# and Python

In C#, types such as behave similarly to those in and garbage-collected languages, preventing object slicing through semantics where assignment to a base variable simply reassigns the to the complete derived instance on the , preserving all data and polymorphic . However, types like structs introduce a nuanced risk analogous to during and operations. Since structs do not support from other or structs—only —traditional slicing via derived-to-base assignment is impossible by , avoiding complications like slicing seen in potential extensions of C++ semantics. a struct to an object or copies its fields to the managed , creating an independent instance; if accessed solely through the boxed type, additional struct-specific members become inaccessible without explicit and , effectively the visible data and . must target the exact original type to avoid an InvalidCastException, ensuring no unintended but highlighting the copy-based nature that can lead to desynchronization between the original and boxed copies. Consider this C# example illustrating truncation-like behavior with a struct implementing an interface: 
csharp
using System;

interface IShape {
    double Area { get; }
}

struct Circle : IShape {
    public double Radius;
    public double Area => Math.PI * Radius * Radius;
    // Additional member not in interface
    public string Color { get; set; }
}

class Program {
    static void Main() {
        Circle c = new Circle { Radius = 5, Color = "Red" };
        object boxed = c;  // Boxing: copies struct to heap
        IShape shape = (IShape)boxed;  // Treat as interface; Color inaccessible here
        Console.WriteLine(shape.Area);  // Outputs ~78.54; full struct state preserved but truncated view
        // To access Color: ((Circle)((IShape)boxed)).Color, but requires exact unboxing
    }
}
This demonstrates how boxing enforces a value copy while limiting access, differing from C++'s direct memory layout slicing but sharing the risk of lost derived-specific data visibility. In Python, the everything-is-an-object model with universal reference semantics eliminates C++-style object slicing entirely, as variable assignment binds a name to a rather than copying the object, ensuring the full instance—including derived class attributes and methods—remains intact and accessible regardless of the assigned name's type hint or context. supports polymorphic dispatch via dynamic method resolution following the method resolution order (MRO), without explicit virtual tables; instead, attribute lookup traverses the instance, class, and base classes at runtime. further mitigates slicing risks by prioritizing behavioral compatibility—if an object supports the required methods (e.g., via __len__ or __getitem__), it behaves polymorphically without type enforcement, though attempting to access unsupported attributes raises an AttributeError, which can mimic behavioral loss if the object's full capabilities are overlooked. Unlike C++, Python lacks value-type distinctions, treating all user-defined classes as mutable s, but sequence slicing (e.g., on tuples or lists) creates shallow copies of elements, preserving immutability for tuples without altering the original object's identity. For instance, assigning a derived instance to a variable in retains the complete object: 
python
class Shape:
    def area(self):
        raise NotImplementedError

class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius
        self.color = "Red"  # Derived-specific attribute

    def area(self):
        import math
        return math.pi * self.radius ** 2

c = Circle(5)
base: Shape = c  # Reference assignment; no copy or loss
print(base.area())  # Calls Circle's method: ~78.54
print(base.color)   # Accesses derived attribute: "Red"; full state preserved
This contrasts with C++ slicing, where such assignment would copy only base portions, losing color. Key differences between C# and underscore their approaches: C# distinguishes classes from structs, enabling efficient allocation for small, non-inheriting types but requiring careful handling of to avoid performance overhead and access truncation, whereas 's uniform and promote flexibility without copy-induced data loss, though at the cost of runtime type checks. In , slicing applies primarily to sequences like immutable tuples (creating new tuples) or mutable lists (shallow copies), unrelated to inheritance but highlighting the language's emphasis on preservation over copying.

References

  1. [1]
    OOP51-CPP. Do not slice derived objects - SEI CERT C++ Coding Standard - Confluence
    ### Definition and Explanation of Object Slicing in C++
  2. [2]
    C++ Core Guidelines - GitHub Pages
    Jul 8, 2025 · The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++.
  3. [3]
    25.9 — Object slicing - Learn C++
    Nov 19, 2016 · The assigning of a Derived class object to a Base class object is called object slicing (or slicing for short).
  4. [4]
    Inheritance — <code>virtual</code> functions, C++ FAQ
    A virtual function allows derived classes to replace the implementation provided by the base class. The compiler makes sure the replacement is always called ...
  5. [5]
    Reference and Value Semantics, C++ FAQ - Standard C++
    With reference semantics, assignment is a pointer-copy (ie, a reference). Value (or “copy”) semantics mean assignment copies the value, not just the pointer.Missing: slicing | Show results with:slicing
  6. [6]
    https://en.cppreference.com/w/cpp/language/copy_elision
  7. [7]
    Is the C++ NVRO applicable with object slicing or with a local object ...
    Dec 8, 2022 · The question is: will the C++ NVRO kick in in one or both of those 2 setups and if not, what is the best way to minimize copying around the Update return value?
  8. [8]
    C++ Tutorial: Object Slicing and Virtual Table - 2020 - BogoToBogo
    Open Source ... C++ Tutorial: Object Slicing and Virtual Table. ... The first call is passing an argument by value, the second one is passing an argument by ...
  9. [9]
    What is object slicing? - c++ - Stack Overflow
    Nov 8, 2008 · "Slicing" is where you assign an object of a derived class to an instance of a base class, thereby losing part of the information - some of it is "sliced" away.Avoiding object slicing - c++ - Stack OverflowIs object slicing by assigning through a base reference well-defined?More results from stackoverflow.com
  10. [10]
    [PDF] Dynamic casting, Slicing, Private Inheritance, Multiple Inheritance
    Mar 5, 2012 · What if the derived class contains some special function that is useful only for that class? Suppose that we need to compute the diagonal of a ...
  11. [11]
    https://en.cppreference.com/w/cpp/language/rule_of_three
  12. [12]
    Exceptions - cppreference.com - C++ Reference
    Dec 20, 2024 · To avoid unnecessary copying of the exception object and object slicing, the best practice for handlers is to catch by reference.<|separator|>
  13. [13]
    https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-copy-virtual
  14. [14]
    https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ri-11
  15. [15]
    https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-smartptr
  16. [16]
    https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ri-25
  17. [17]
    https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-dtor-virtual
  18. [18]
    https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c67-a-polymorphic-class-should-suppress-public-copymove
  19. [19]
    Bjarne Stroustrup's C++ Style and Technique FAQ
    Feb 26, 2022 · This is an ambitious project to guide people to an effective style of modern C++ and to provide tool to support its rules.
  20. [20]
    Virtual Destructor - GeeksforGeeks
    Jul 23, 2025 · Making base class destructor virtual guarantees that the object of derived class is destructed properly, ie, both base class and derived class destructors are ...
  21. [21]
    https://docs.oracle.com/javase/specs/jls/se17/html/jls-4.html#jls-4.3.1
  22. [22]
    Polymorphism - Java™ Tutorials
    This behavior is referred to as virtual method invocation and demonstrates an aspect of the important polymorphism features in the Java language. « Previous • ...
  23. [23]
    Structure types - C# reference - Microsoft Learn
    Dec 4, 2024 · A structure type (or struct type) is a value type that can encapsulate data and related functionality. You use the struct keyword to define a structure type.
  24. [24]
    Boxing and Unboxing (C# Programming Guide) - Microsoft Learn
    Boxing is the process of converting a value type to the type object or to any interface type implemented by this value type.
  25. [25]
    Boxing and Unboxing in C# - PVS-Studio
    Aug 21, 2023 · Boxing converts value types to reference types, while unboxing converts reference types back to value types. These operations can reduce ...
  26. [26]
    Does "C++ style" object slicing exist in C#? - Stack Overflow
    Feb 14, 2022 · You can achieve a similar effect by applying the new keyword instead of override on the method, but it's not slicing the object as in C++:
  27. [27]
    https://docs.python.org/3/reference/datamodel.html#objects-values-and-types
  28. [28]
    https://docs.python.org/3/reference/datamodel.html#class-inheritance
  29. [29]
    https://docs.python.org/3/reference/datamodel.html#special-method-names
  30. [30]
    https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy
  31. [31]
    https://docs.python.org/3/reference/datamodel.html#class-instances
  32. [32]
    https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/value-types
  33. [33]
    https://docs.python.org/3/reference/datamodel.html#immutable-sequences