4 ms·

IMHO Inheritance (especially the C++ flavored inheritance with its access specifiers and myriad rules) has always scared me. It makes a codebase confusing and h

IMHO Inheritance (especially the C++ flavored inheritance with its access specifiers and myriad rules) has always scared me. It makes a codebase confusing and hard to reason with. I feel the eschewing of inheritance by languages such as Go and Rust is a step in the right direction. As an aside, I have noticed that the robotics frameworks (ROS and ROS2) heavily rely on inheritance and some co-dependent C++ features like virtual destructors (to call the derived class's destructor through a base class pointer). I was once invited to an interview for a robotics company due to my "C++ experience"and grilled on this pattern of C++ that I was completely unfamiliar with. I seriously considered removing C++ from my resume that day.

masfoobar 1y ago
To me, inheritence makes sense if you view your codebase as actual "Objects" The reality is that a codebase is not that simple. Many things you create are not representable as realworld "objects" - to me, this is where is gets confusing to follow especially when the code gets bigger. I remember those OOP books (I cannot comment on modern OOP books) where the first few chaptors would use Shapes as an example. Where A Circle, Square, Triangle, etc.. would inherit the Shape object. Sure, in simple examples like this.. it makes sense. I remember covering inheritence and how to tell if its better or composition... which is the "Object IS X" or "Object HAS X" - so you base you're heirarchy around that mindset. - "A Chair is Furniture" (Chair inherits Furniture) - "A Chair has Legs" (Chair has array of Leg) I will always remember my first job - creating shop floor diagrams where you get to select a Shelf or Rack and see the visual representation of goods, etc. My early codebase was OOP... a Product, Merchandise, Shelf, Bay, Pegboard, etc. Each object inherits something in one way or another. Keeping on top of it eventually became a pain. I think there was, overall, about 5 levels of inheritence. I reviewed my codebase one day and decided to screw it -- I would experiment other approaches. I ended up created simple classes with no inheritence. Each class was isolated from one another with the exception of a special Id which represented "something" like a Pin, or Shelf, etc. Now my code was flexible... "A Shelf has this and this" In later years I realised what I did was following along the lines of what is commonly known as ECS or Entity-Component-System. Seems popular in games (and I viewed that project is a game-like fashion so it makes sense)
- tmountain 1y ago
  I’m not on the cutting edge of gamedev, but I still believe that ECS is a solid pattern with lots of use cases.
  - ogogmad 1y ago
    Sounds like relational databases: Entities are IDs. Components are tables with an ID column.
    - masfoobar 1y ago
      EXACTLY! It is very much like building a database. Each class I created is very much like creating a table. I had my "Objects" which was a simple class with an Id. In ECS land, this would be better known as an entity. I would then create classes (or tables) for each "feature" to support. A feature could be Is it Solid? Is it Visible Is is a Shape/Model Does it has Position Does it have Children etc. Each feature an object supports gives it extra data. So each feature is essentially a table with an Id, ObjectId, and additional fields. Basically, I am "creating my object hierarchy" at runtime, not at compile time with OOP methods. This made it sooo more flexible when more Companies wanted to use the software, especially with their unique approaches to shop management. All configurations were in XML files -- much better than trying to change an OOP hierarchy to suit ALL companies rulesets. This is going back a few years, now. Its amazing what comes back to memory.. how I wrote most of this entirely in Javascript to eventually moving to a backend language using AJAX.. to simplifying code with jQuery. Fond memories.
  - masfoobar 1y ago
    I do make games at home and dont follow ECS religiously, but it is there depsing on how I solve a problem. :-)
deleted 1y ago
[deleted]
quietbritishjim 1y ago
To be fair, deleting a derived object through a base class pointer is pretty basic C++. Slicing and virtual destructors are usually the first couple of things you learn about after virtual methods and copy constructors/assignment.
- rakejake 1y ago
  Quite a few sections of C++ can be classified as "pretty basic C++". None of the rules are complicated in isolation but that doesn't necessarily make it easy to reason about it.

masfoobar 1y ago

To me, inheritence makes sense if you view your codebase as actual "Objects" The reality is that a codebase is not that simple. Many things you create are not representable as realworld "objects" - to me, this is where is gets confusing to follow especially when the code gets bigger. I remember those OOP books (I cannot comment on modern OOP books) where the first few chaptors would use Shapes as an example. Where A Circle, Square, Triangle, etc.. would inherit the Shape object. Sure, in simple examples like this.. it makes sense. I remember covering inheritence and how to tell if its better or composition... which is the "Object IS X" or "Object HAS X" - so you base you're heirarchy around that mindset. - "A Chair is Furniture" (Chair inherits Furniture) - "A Chair has Legs" (Chair has array of Leg) I will always remember my first job - creating shop floor diagrams where you get to select a Shelf or Rack and see the visual representation of goods, etc. My early codebase was OOP... a Product, Merchandise, Shelf, Bay, Pegboard, etc. Each object inherits something in one way or another. Keeping on top of it eventually became a pain. I think there was, overall, about 5 levels of inheritence. I reviewed my codebase one day and decided to screw it -- I would experiment other approaches. I ended up created simple classes with no inheritence. Each class was isolated from one another with the exception of a special Id which represented "something" like a Pin, or Shelf, etc. Now my code was flexible... "A Shelf has this and this" In later years I realised what I did was following along the lines of what is commonly known as ECS or Entity-Component-System. Seems popular in games (and I viewed that project is a game-like fashion so it makes sense)

tmountain 1y ago
I’m not on the cutting edge of gamedev, but I still believe that ECS is a solid pattern with lots of use cases.
- ogogmad 1y ago
  Sounds like relational databases: Entities are IDs. Components are tables with an ID column.
  - masfoobar 1y ago
    EXACTLY! It is very much like building a database. Each class I created is very much like creating a table. I had my "Objects" which was a simple class with an Id. In ECS land, this would be better known as an entity. I would then create classes (or tables) for each "feature" to support. A feature could be Is it Solid? Is it Visible Is is a Shape/Model Does it has Position Does it have Children etc. Each feature an object supports gives it extra data. So each feature is essentially a table with an Id, ObjectId, and additional fields. Basically, I am "creating my object hierarchy" at runtime, not at compile time with OOP methods. This made it sooo more flexible when more Companies wanted to use the software, especially with their unique approaches to shop management. All configurations were in XML files -- much better than trying to change an OOP hierarchy to suit ALL companies rulesets. This is going back a few years, now. Its amazing what comes back to memory.. how I wrote most of this entirely in Javascript to eventually moving to a backend language using AJAX.. to simplifying code with jQuery. Fond memories.
- masfoobar 1y ago
  I do make games at home and dont follow ECS religiously, but it is there depsing on how I solve a problem. :-)

deleted 1y ago

[deleted]

quietbritishjim 1y ago

To be fair, deleting a derived object through a base class pointer is pretty basic C++. Slicing and virtual destructors are usually the first couple of things you learn about after virtual methods and copy constructors/assignment.

rakejake 1y ago
Quite a few sections of C++ can be classified as "pretty basic C++". None of the rules are complicated in isolation but that doesn't necessarily make it easy to reason about it.