4 ms·

I am not sure this is an improvement. What is the added value? What is the cost? Virtual methods are not free. Indirections are not free (when you read the co

I am not sure this is an improvement. What is the added value? What is the cost? Virtual methods are not free. Indirections are not free (when you read the code)

aptxkid 6y ago
Well if this is an improvement or not depends on the use case. E.g. std::function does exactly this. What it achieves is exactly erasing the type (conforming to an affordance). The cost is definitely there. You pay vtable lookup when using std::function.
- nly 6y ago
  You're not wrong in any way, but interestingly, last I looked, common implementations of std::function didn't use virtual under the covers. Instead they re-implement something like the vtable to avoid unwanted extras, like RTTI, bloating your app size
AnimalMuppet 6y ago
It lets you treat things that aren't from the same class hierarchy as if they are from the same hierarchy. You probably wouldn't do this unless you had that problem. (And, in my entire career, I have never had this problem.) If you do have that problem, the alternative is to write an adapter or wrapper by hand. You may regard this as an improvement, or not, depending on your specific circumstances.
- LaLaLand122 6y ago
  It's a strictly better solution. You don't do it because the standard library doesn't give you tools to do it easily, but if it were the same effort everybody would do it. After all, Inheritance Is The Base Class of Evil (https://www.youtube.com/watch?v=2bLkxj6EVoM https://www.youtube.com/watch?v=2bLkxj6EVoM).
  - AnimalMuppet 6y ago
    Cute title, I guess, but a YouTube video proves nothing. You can (I presume) find YouTube videos "proving" that the Earth is flat. So, if you want me to believe this position, you're going to have to give me something better than the title of a video. Inheritance is just fine, used well. You've got a counterargument? Give it. Not a video; give me the actual argument.
    - LaLaLand122 6y ago
      I didn't give you only "the title of a video" (which sure, tries to be "cute"), I gave you the link to the video, in which no other than Sean Parent gives you the arguments. The summary is in https://www.youtube.com/watch?v=2bLkxj6EVoM&t=1275s https://www.youtube.com/watch?v=2bLkxj6EVoM&t=1275s Sure, inheritance is fine, I use it all the time. If it were that bad we would already have Virtual Concepts in the standard. But duck-typing is better, if only because the argument you already gave: "lets you treat things that aren't from the same class hierarchy as if they are from the same hierarchy". It's a lie that I want something that inherits from my class, I simply want something I can draw() with, but we keep telling that lie all the time... which sure, is not the end of the world.
      - AnimalMuppet 6y ago
        Yes, you gave me a link to the video. No, I'm not going to watch a video to find out what your point is, so what you actually gave me is just the title. Why am I not going to watch it? Well, how long is the video? 5 minutes? 30 minutes? An hour? Two hours? But it took me 30 seconds to read your post here. (I'm hoping that the last paragraph was a summary of the video's argument.) Even if it took you five minutes to write, your five minutes plus my 30 seconds is still a big win compared to a half-hour video. But we're on a public forum. If 10 people, or 100, have to go watch the video to figure out what your point is, that gets really inefficient. Which is why I yell at people - not just you - about making the readers do the work to figure out what the poster is talking about. > But duck-typing is better, if only because the argument you already gave: "lets you treat things that aren't from the same class hierarchy as if they are from the same hierarchy". Right; duck typing is better when you have that problem. But in 25 years of using C++, I have never had that problem. So I'm pushing back on you stating "duck typing is better" like it's a universal. It's not. > It's a lie that I want something that inherits from my class, I simply want something I can draw() with, but we keep telling that lie all the time... Sometimes I want more than that. I want something I can draw() that also satisfies the constraints of my class, at which point I do want something that inherits from my class, which makes it not a lie. Look, this approach has its place. That place is not everywhere, but a more limited set of places. I don't have a problem with people using this approach. I don't have a problem with people teaching others how to use this approach. I have a problem with people talking like this is the one right way. It's not.
- jcelerier 6y ago
  > And, in my entire career, I have never had this problem. You never used types such as std:: function?
  - AnimalMuppet 6y ago
    Um... I think I used it once, in a bit of throwaway code for my own entertainment (binding a parameter to a two-parameter function so that I could use it in Newton-Raphson). I have never used it professionally, and never had the kind of situation where I needed it.
    - jcelerier 6y ago
      Your experience is pretty uncommon. Grepping for it in my home's .h/.hpp yields roughly seven thousand matches
      - AnimalMuppet 6y ago
        Our experience differs, yes. Do you have any basis for saying that yours is more common than mine?
        jcelerier 6y ago
        never seen it not being used (or its ancestor boost::function) when doing consulting, a large amount of large projects used by other projects use it (boost, qt, llvm, eigen, opencv, the VST API, KDE ...). In particular most GUI toolkits have at least an equivalent as it's the only way to store callbacks of different types with an associated arbitrary state (e.g. lambdas)

I am not sure this is an improvement. What is the added value? What is the cost? Virtual methods are not free. Indirections are not free (when you read the code)

aptxkid 6y ago

Well if this is an improvement or not depends on the use case. E.g. std::function does exactly this. What it achieves is exactly erasing the type (conforming to an affordance). The cost is definitely there. You pay vtable lookup when using std::function.

nly 6y ago
You're not wrong in any way, but interestingly, last I looked, common implementations of std::function didn't use virtual under the covers. Instead they re-implement something like the vtable to avoid unwanted extras, like RTTI, bloating your app size

AnimalMuppet 6y ago

It lets you treat things that aren't from the same class hierarchy as if they are from the same hierarchy. You probably wouldn't do this unless you had that problem. (And, in my entire career, I have never had this problem.) If you do have that problem, the alternative is to write an adapter or wrapper by hand. You may regard this as an improvement, or not, depending on your specific circumstances.

LaLaLand122 6y ago
It's a strictly better solution. You don't do it because the standard library doesn't give you tools to do it easily, but if it were the same effort everybody would do it. After all, Inheritance Is The Base Class of Evil (https://www.youtube.com/watch?v=2bLkxj6EVoM https://www.youtube.com/watch?v=2bLkxj6EVoM).
- AnimalMuppet 6y ago
  Cute title, I guess, but a YouTube video proves nothing. You can (I presume) find YouTube videos "proving" that the Earth is flat. So, if you want me to believe this position, you're going to have to give me something better than the title of a video. Inheritance is just fine, used well. You've got a counterargument? Give it. Not a video; give me the actual argument.
  - LaLaLand122 6y ago
    I didn't give you only "the title of a video" (which sure, tries to be "cute"), I gave you the link to the video, in which no other than Sean Parent gives you the arguments. The summary is in https://www.youtube.com/watch?v=2bLkxj6EVoM&t=1275s https://www.youtube.com/watch?v=2bLkxj6EVoM&t=1275s Sure, inheritance is fine, I use it all the time. If it were that bad we would already have Virtual Concepts in the standard. But duck-typing is better, if only because the argument you already gave: "lets you treat things that aren't from the same class hierarchy as if they are from the same hierarchy". It's a lie that I want something that inherits from my class, I simply want something I can draw() with, but we keep telling that lie all the time... which sure, is not the end of the world.
    - AnimalMuppet 6y ago
      Yes, you gave me a link to the video. No, I'm not going to watch a video to find out what your point is, so what you actually gave me is just the title. Why am I not going to watch it? Well, how long is the video? 5 minutes? 30 minutes? An hour? Two hours? But it took me 30 seconds to read your post here. (I'm hoping that the last paragraph was a summary of the video's argument.) Even if it took you five minutes to write, your five minutes plus my 30 seconds is still a big win compared to a half-hour video. But we're on a public forum. If 10 people, or 100, have to go watch the video to figure out what your point is, that gets really inefficient. Which is why I yell at people - not just you - about making the readers do the work to figure out what the poster is talking about. > But duck-typing is better, if only because the argument you already gave: "lets you treat things that aren't from the same class hierarchy as if they are from the same hierarchy". Right; duck typing is better when you have that problem. But in 25 years of using C++, I have never had that problem. So I'm pushing back on you stating "duck typing is better" like it's a universal. It's not. > It's a lie that I want something that inherits from my class, I simply want something I can draw() with, but we keep telling that lie all the time... Sometimes I want more than that. I want something I can draw() that also satisfies the constraints of my class, at which point I do want something that inherits from my class, which makes it not a lie. Look, this approach has its place. That place is not everywhere, but a more limited set of places. I don't have a problem with people using this approach. I don't have a problem with people teaching others how to use this approach. I have a problem with people talking like this is the one right way. It's not.
jcelerier 6y ago
> And, in my entire career, I have never had this problem. You never used types such as std:: function?
- AnimalMuppet 6y ago
  Um... I think I used it once, in a bit of throwaway code for my own entertainment (binding a parameter to a two-parameter function so that I could use it in Newton-Raphson). I have never used it professionally, and never had the kind of situation where I needed it.
  - jcelerier 6y ago
    Your experience is pretty uncommon. Grepping for it in my home's .h/.hpp yields roughly seven thousand matches
    - AnimalMuppet 6y ago
      Our experience differs, yes. Do you have any basis for saying that yours is more common than mine?
      - jcelerier 6y ago
        never seen it not being used (or its ancestor boost::function) when doing consulting, a large amount of large projects used by other projects use it (boost, qt, llvm, eigen, opencv, the VST API, KDE ...). In particular most GUI toolkits have at least an equivalent as it's the only way to store callbacks of different types with an associated arbitrary state (e.g. lambdas)