5 ms·

> It's important to note that in C++ you can easily run into problems with what you're describing: structs (objects) with different sizes being put into a vecto

> It's important to note that in C++ you can easily run into problems with what you're describing: structs (objects) with different sizes being put into a vector. This is simply wrong. > You may very well get the program to compile, but then run into odd bugs which come about because your objects get clipped to the size of the smallest possible (the base class). That has nothing to do with object sizes. You're describing the object slicing problem https://en.wikipedia.org/wiki/Object_slicing https://en.wikipedia.org/wiki/Object_slicing The cause of this problem is ignorance and incompetence regarding fundamental aspects of the language.

pcwalton 9y ago
> The cause of this problem is ignorance and incompetence regarding fundamental aspects of the language. No! You can rationalize any language problem away with this argument. That's why it's a fallacy with a name: "no true Scotsman" (as in: "no true C++ programmer would let object slicing introduce a bug"). Object slicing is a problem with C++, period.
- geezerjay 9y ago
  > No! You can rationalize any language problem away with this argument. Sorry, the sole problem is incompetence. Coupling incompetencr with the inability to learn is a problem that no programming language solves. If you insist in shooting yourself in the foot, it makes absolutely no sense to complain that the gun is broken because it doesn't guide bullets away from your foot when you intentionally aim at it. The object slicing problem is C++ 101. It isn't the language's fault that people who don't know the very basics end up doing mistakes.
  - pcwalton 9y ago
    "Don't use heap memory after it's been freed" is C++ (and C) 101 as well. Yet if the bar for C++ competence is "never wrote a use-after-free", then your bar for "competence" excludes essentially everyone in the industry. Whether a theoretically "competent" C++ developer makes mistakes related to object slicing is a completely uninteresting debate. Whether experienced C++ programmers make that mistake in practice is the interesting question. And they do.
    - geezerjay 9y ago
      > Yet if the bar for C++ competence is "never wrote a use-after-free" The bar for C++ competence in that regard is RAII. Furthermore, your strawman doesn't hold up. The object slicing problem is actually like someone being foolish enough to cast a 64-bit int to a 32-bit int and then complaining that the programming language is broken because the 32-bit variable doesn't hold 64 bits. Of course it doesn't. Why should it? And why make excuses an play the pin-the-blame game when the problem is caused by ignorance? Heck, you're assigning heterogenous objects of variable-length to a data structure that by definition was designed to hold homogeneous sequences of fixed-size objects, and even still you want to pin the blame on the language? How, if you clearly don't know what you're doing?
      - narag 9y ago
        If you think about this as a correct/incorrect thing, you're going nowhere. There's this usability concept that so many people resist to apply to dev tools as if programmers were not regular humans.
      - pcwalton 9y ago
        RAII is nowhere near enough to prevent heap use-after-free.
      - vvanders 9y ago
        Oh man, the number of libraries I've used over the years where I got nailed by their use after free/mem overwrite. Just because you're a perfect developer doesn't mean some downstream dependency isn't going to come along and wreck your day.
      - hsivonen 9y ago
        > The bar for C++ competence in that regard is RAII. If it was that simple we'd never need kungFuDeathGrip in Gecko. Yet, we need it a lot: https://searchfox.org/mozilla-central/search?q=kungfu&path= https://searchfox.org/mozilla-central/search?q=kungfu&path= (KungFuDeathGrip is the pattern of introducing an extra RAII refcount incrementer/decrementer on the stack to avoid subsequent method calls doing something that would free an object from underneath the current stack frame.)
tkzzbneig 9y ago
Okay, sure, if you want to get into the nitty gritty, that's fine. But I just wanted to provide a high level overview of how putting differently-sized structs into a vector can be problematic. Sure, ignorance, whatever. Indeed. That's why I brought it up. But my greater point still stands: do you want the compiler to catch these things? If so, you have trade-offs.
- geezerjay 9y ago
  > Okay, sure, if you want to get into the nitty gritty, that's fine. But I just wanted to provide a high level overview of how putting differently-sized structs into a vector can be problematic. A vector is a container for homogeneous sequences of fixed-size objects that are stored contiguously. Even if we ignore the slicing problem, don't you see a problem in trying to shove sets of square and rectangular pegs into a container that was specifically designed to support only round pegs of one specific size?
  - tkzzbneig 9y ago
    Yes. I'm not sure why you seem to think I don't. There are times when you need to do something conceptually like having a list of things of similar, but different kind. There are different ways to go about this. Briefly mentioned in my original post: object pointers; or breaking up the data according to DDD (just because something is conceptually one item, does not mean it cannot be spread into different data structures. after all, if you have an array full of things, there's likely one property in common between those things of different kind that is similar and germane to their being in the collection).

pcwalton 9y ago

> The cause of this problem is ignorance and incompetence regarding fundamental aspects of the language. No! You can rationalize any language problem away with this argument. That's why it's a fallacy with a name: "no true Scotsman" (as in: "no true C++ programmer would let object slicing introduce a bug"). Object slicing is a problem with C++, period.

geezerjay 9y ago
> No! You can rationalize any language problem away with this argument. Sorry, the sole problem is incompetence. Coupling incompetencr with the inability to learn is a problem that no programming language solves. If you insist in shooting yourself in the foot, it makes absolutely no sense to complain that the gun is broken because it doesn't guide bullets away from your foot when you intentionally aim at it. The object slicing problem is C++ 101. It isn't the language's fault that people who don't know the very basics end up doing mistakes.
- pcwalton 9y ago
  "Don't use heap memory after it's been freed" is C++ (and C) 101 as well. Yet if the bar for C++ competence is "never wrote a use-after-free", then your bar for "competence" excludes essentially everyone in the industry. Whether a theoretically "competent" C++ developer makes mistakes related to object slicing is a completely uninteresting debate. Whether experienced C++ programmers make that mistake in practice is the interesting question. And they do.
  - geezerjay 9y ago
    > Yet if the bar for C++ competence is "never wrote a use-after-free" The bar for C++ competence in that regard is RAII. Furthermore, your strawman doesn't hold up. The object slicing problem is actually like someone being foolish enough to cast a 64-bit int to a 32-bit int and then complaining that the programming language is broken because the 32-bit variable doesn't hold 64 bits. Of course it doesn't. Why should it? And why make excuses an play the pin-the-blame game when the problem is caused by ignorance? Heck, you're assigning heterogenous objects of variable-length to a data structure that by definition was designed to hold homogeneous sequences of fixed-size objects, and even still you want to pin the blame on the language? How, if you clearly don't know what you're doing?
    - narag 9y ago
      If you think about this as a correct/incorrect thing, you're going nowhere. There's this usability concept that so many people resist to apply to dev tools as if programmers were not regular humans.
    - pcwalton 9y ago
      RAII is nowhere near enough to prevent heap use-after-free.
    - vvanders 9y ago
      Oh man, the number of libraries I've used over the years where I got nailed by their use after free/mem overwrite. Just because you're a perfect developer doesn't mean some downstream dependency isn't going to come along and wreck your day.
    - hsivonen 9y ago
      > The bar for C++ competence in that regard is RAII. If it was that simple we'd never need kungFuDeathGrip in Gecko. Yet, we need it a lot: https://searchfox.org/mozilla-central/search?q=kungfu&path= https://searchfox.org/mozilla-central/search?q=kungfu&path= (KungFuDeathGrip is the pattern of introducing an extra RAII refcount incrementer/decrementer on the stack to avoid subsequent method calls doing something that would free an object from underneath the current stack frame.)

tkzzbneig 9y ago

Okay, sure, if you want to get into the nitty gritty, that's fine. But I just wanted to provide a high level overview of how putting differently-sized structs into a vector can be problematic. Sure, ignorance, whatever. Indeed. That's why I brought it up. But my greater point still stands: do you want the compiler to catch these things? If so, you have trade-offs.

geezerjay 9y ago
> Okay, sure, if you want to get into the nitty gritty, that's fine. But I just wanted to provide a high level overview of how putting differently-sized structs into a vector can be problematic. A vector is a container for homogeneous sequences of fixed-size objects that are stored contiguously. Even if we ignore the slicing problem, don't you see a problem in trying to shove sets of square and rectangular pegs into a container that was specifically designed to support only round pegs of one specific size?
- tkzzbneig 9y ago
  Yes. I'm not sure why you seem to think I don't. There are times when you need to do something conceptually like having a list of things of similar, but different kind. There are different ways to go about this. Briefly mentioned in my original post: object pointers; or breaking up the data according to DDD (just because something is conceptually one item, does not mean it cannot be spread into different data structures. after all, if you have an array full of things, there's likely one property in common between those things of different kind that is similar and germane to their being in the collection).