12 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 vector

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. 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). So any overridden methods which expect extra data in a subclass will not behave as expected. So what you usually do here is have a pointer and a VTable and all that jazz. But there's been a resurgence in interest in putting data into contiguous blocks of memory. Check up on data driven design. I don't think it's fair to compare GC'd languages to Rust's complexity. At least, compare C to Rust. But still, to be truly fair, weigh the usability differences against the safety differences. There are a lot of trade-offs here and perhaps this isn't the right way for you to go forward, but keep a broad view of the other aspects at play.

jcelerier 9y ago
> So what you usually do here is have a pointer and a VTable and all that jazz. But there's been a resurgence in interest in putting data into contiguous blocks of memory. Check up on data driven design. in particular, boost.polycollection is a nice implementation of heterogeneous vectors: http://www.boost.org/doc/libs/develop/doc/html/poly_collection.html http://www.boost.org/doc/libs/develop/doc/html/poly_collecti...
alexeiz 9y ago
> 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. Baloney. In C++ vector<any> or vector<variant> accomplish this task without any problems whatsoever.
- pcwalton 9y ago
  And you can do the same in Rust with Box<Any>. What Rust doesn't have is the object slicing gotcha, which is probably a language design mistake in C++.
  - pjmlp 9y ago
    That gotcha is yet another flaw inherited from copy-paste compatibility with C. structs being classes with public access by default, with default assignment operator behaving the same way as C code would expect.
geezerjay 9y ago
> 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.
katastic 9y ago
This is absolutely, 100%, certifiably wrong. > odd bugs which come about because your objects get clipped to the size of the smallest possible (the base class). This only EVER happens if you do something you're never supposed to do. If you have a base pointer, it only knows about... base pointer fields! >So what you usually do here is have a pointer and a VTable and all that jazz. "Making a VTable" in C++ sounds like you have zero understanding of the language.

jcelerier 9y ago

> So what you usually do here is have a pointer and a VTable and all that jazz. But there's been a resurgence in interest in putting data into contiguous blocks of memory. Check up on data driven design. in particular, boost.polycollection is a nice implementation of heterogeneous vectors: http://www.boost.org/doc/libs/develop/doc/html/poly_collection.html http://www.boost.org/doc/libs/develop/doc/html/poly_collecti...

alexeiz 9y ago

> 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. Baloney. In C++ vector<any> or vector<variant> accomplish this task without any problems whatsoever.

pcwalton 9y ago
And you can do the same in Rust with Box<Any>. What Rust doesn't have is the object slicing gotcha, which is probably a language design mistake in C++.
- pjmlp 9y ago
  That gotcha is yet another flaw inherited from copy-paste compatibility with C. structs being classes with public access by default, with default assignment operator behaving the same way as C code would expect.

geezerjay 9y ago

> 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.

katastic 9y ago

This is absolutely, 100%, certifiably wrong. > odd bugs which come about because your objects get clipped to the size of the smallest possible (the base class). This only EVER happens if you do something you're never supposed to do. If you have a base pointer, it only knows about... base pointer fields! >So what you usually do here is have a pointer and a VTable and all that jazz. "Making a VTable" in C++ sounds like you have zero understanding of the language.