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.
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.
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.
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.
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.
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.
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.
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)
Comments
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.
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).
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.
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
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.
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.
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.
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.
You never used types such as std:: function?
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.
Your experience is pretty uncommon. Grepping for it in my home's .h/.hpp yields roughly seven thousand matches
Our experience differs, yes. Do you have any basis for saying that yours is more common than mine?
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)