Questions from a "dummy" - page 128
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
We won't forget ;)
Instead of overloading operators, you'd rather have multiple inheritance. It would be much more useful.
You'd better implement multiple inheritance instead of operator overloading. It would be much more useful.
Well written - make it happen :) That's exactly what multiple inheritance does.
A week ago I took part in a discussion "multiple inheritance vs. aggregation" and aggregation won a convincing victory.
Took part in the "multiple inheritance vs. aggregation" discussion a week ago, and aggregation won a convincing victory
Well yes, writing a kilometre of wrapper code for each implementation class is much better and more efficient. And much faster too.
Especially if the interfaces are a dozen or so.
But throw me the link, I'll study it at my leisure.
Unfortunately, this is not planned. At the moment we are only considering the possibility of inheriting classes from structures.
And pointers to structures would be very useful, and you don't have to make them (structures) dynamic - the main thing is that you can sort the index array instead of the structures themselves.
// In many cases, it is undesirable to replace structures with classes. They are economical (no virtual method table) and contain "solid" data.
Yes, it's much better and more efficient to write a kilometre of wrapper code for each implementation class.
But throw the link, I'll study it at my leisure.
About the wrapper - I agree, but most often it also acts as a frontend or adapter, i.e. it modifies the interface of the aggregated class.
I can't give you the link, it was an internal Skype discussion with about thirty interested people.
About the wrapper - I agree, but more often than not it also acts as a frontend or adapter, i.e. it modifies the interface of the class being aggregated.
It depends on how you look at it. One could say that aggregation in this case is a crutch, because multiple inheritance is much more transparent and convenient from logical and coding point of view.
Can I give you an example of how your firm handles lozenge hierarchies?
It depends on how you look at it. You could say that aggregation is a crutch in this case, because multiple inheritance is much more transparent and convenient both logically and coding-wise.
Can you give an example of how your firm handles lozenge hierarchies?
Hierarchies are, if I'm not mistaken, just a product of using multiple inheritance.
Can you give any real-life example where you've encountered the need to build and implement lozenge hierarchies?
Rhomboidal hierarchies are, if I'm not mistaken, just a product of using multiple inheritance.
Can you give any example in your life when you encountered the need to build and implement rhomboidal hierarchies?
A person has an arm, a leg and all sorts of organs, they are built from cells which are built from atoms, the set of atoms is finite but their sets are enormous.
all the organs have different purposes, but all together they are human beings. People are different and may have different professions, etc.
Those we started with a set from which a cell is inherited, those converged into one class, then diverged again into organs and converged again into a class of humans, and diverged again into professions.
Rhomboidal hierarchies are, if I'm not mistaken, just a product of using multiple inheritance.
No, it's a product of design. It doesn't depend on the use of language tools.
Can you give any real-life examples of when you needed to build and implement lozenge hierarchies?
Not at first, but I have used it more than once. And practically without any choice.
If you ask me, writing crutch wrappers is in itself a weighty argument.