Overhead for the PLO - page 6
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
but it doesn't work :-)
I'm telling you - try to do it, it's a fierce lot-of-code. Instantifiable class "CFoo: public InterfaceCFoo" must contain InterfaceCFoo *privateContext field (make 1:1 relation), create and delete it via factory, delegate all methods and translate CFoo* references this<->privateContext here and there. This is "sunsetting the sun by hand", i.e. replacing inheritance with delegation, and on the spot.
Create through the factory and delete in the usual way. Whether you need delegation is determined by how the contents of the library is supposed to be used: if it provides classes that do the work themselves, then you won't need to delegate anything - just call the interface methods.
By the way, in Android/Java there is a similar thing with kernel classes - due to lack of multiple inheritance one has to insert a delegate into object and make wrapper methods for its methods. C'est la vie.
I'm telling you - try it, it's a fierce lot-of-code. Instantifiable class "CFoo: public InterfaceCFoo" must contain InterfaceCFoo *privateContext field (make 1:1 relation), create and delete it via factory, delegate all methods and at the same time translate CFoo* references this<->privateContext here and there. This is "sunsetting the sun by hand", i.e. replacing inheritance with delegation, and on the spot.
And the language, a sober person can't understand what we're talking about without half a litre. :) And all this OOP stuff and all this chinese literacy is made for - to make a simple data exchange, which is trivially realized on the procedural level...
OOP itself is not to blame for the existence of vicious OOP coders. There is nothing wrong with OOP in general, you are completely wrong in your opinion of OOP.
OOP itself is not to blame for the existence of vicious OOP coders. There is nothing wrong with OOP in general, you are completely wrong in your opinion of OOP.
You don't know its history.
Repeated bans for direct sabotage. So don't react to his belligerent ignorance.
In general, there is nothing wrong with OOP; you are completely wrong in your opinion of OOP.
I will give you some famous critical quotes from the wiki about OOP from people, who for some reason are not called ignorant:
As a liberation, I will cite some famous critical quotes from the wiki about OOP from people, who for some reason are not called ignorant:
And all three of them: Stepanov born in 1950, Wirth in 1934 and the equally ancient Killea (his book was published in 1998) will be very ashamed to repeat it in 2017.
What they said was so long ago it's already embarrassing to remember. C++ compilers were at least 2 orders of magnitude dumber and more primitive in optimizations. In fact, there was not a trace of optimization there. Back then (very beginning of the nineties), I wrote a lot of assembler myself and was similar in thinking: "C/C++ is slow".
It's not for me to conduct links in the form of plucked quotations. Moreover, you have already managed to show your extreme dullness and aggressive ignorance in this thread.
Renat Fatkhullin:
All the more you have managed already in this thread to show your extreme dullness and aggressive ignorance.
Let's summarize. Here's my main hypothesis about OOP: "OOP only makes sense as a convenient text wrapper or when used minimally during runtime initialization..." in post #10.
And here is a reasoned opinion from an independent expert with a similar opinion and detailed code level proof.
http://rainman-rocks.livejournal.com/122876.html
"The final conclusion from all this is this:
The main reason for the effectiveness of object-oriented programming is that it contains the means to provide modularity and declarativity. It is modularity and declarativity that are the tools that increase the efficiency of development - i.e. "like-silver bullets". It is these that one should focus on when choosing a methodology. OOP alone should not be the goal."
To summarise. Here's my basic hypothesis about OOP: "OOP only makes sense as a convenient text wrapper or when used minimally in runtime initialization..." in post #10.
And here is a reasoned opinion from an independent expert with a similar opinion and detailed code level proof.
http://rainman-rocks.livejournal.com/122876.html
"The final conclusion from all this is this:
The main reason for the effectiveness of object-oriented programming is that it contains the means to provide modularity and declarativity. It is modularity and declarativity that are the tools that increase the efficiency of development - i.e. "like-silver bullets". It is these that one should focus on when choosing a methodology. OOP in itself should not be the goal."
Show your personally implemented projects so that your opinion is accepted at least minimally. You can't even understand the cited link - it's just ode to OOP, including the output.
All software is practically more than 90% written on OOP (don't mention nonsense about drivers). In fact it is impossible to write and then to maintain a large project without OOP. And no words about "just a wrapper" are accepted when it comes to business. Software development has long been a well-established and time-tested business.
Those who complain about OOP without understanding are not aware of what modern C++ compilers do. There is often nothing at all left of OOP in the final code. I'm talking about C++, of course.
Show your personally realised projects so that your opinion is accepted at least minimally. You can't even understand the cited link - it's just an ode to OOP, including the conclusion.
Let me give you one more quote about the main idea of this article so that there is no doubt what it says:
"Thus, OOP, while seeking to replace structured-procedural programming, eventually returned to almost the same thing, but only in fancy wrappings. Some question arises: was there any sense in the maneuver at all...".
Sorry, but I don't understand the logic and cause and effect relationship - why do you need any realised projects so that one's opinion is taken for minimal consideration. Usually in a civilised discussion, the reasoning and reasonable validity of the submitted opinion itself is sufficient.
Otherwise, we come to the absurd conclusion that if a person has implemented a project, then all of his subsequent statements must be accepted by everyone initially, although in fact it may not be all smooth with reasoning or even contradict the opinion of other professionals who also have implemented projects.
Again, it is not very modest to boast about something, for it is bad for karma.
That is, there are no projects, hence no experience.
At the same time, you do not forget about experience, trying to pull out the oldest sayings of once experienced(in terms of their time) people. Since you do not have your own experience, you do not understand that the taken out utterances did not work long ago. They did not work and were only delusions peculiar to that time. These delusions are already embarrassing to recall.
In addition, you do not really understand the essence of what is written in the cited links. You snatch words and misinterpret them, although it says "OOP is better than crutches (and crutches are an attempt to emulate OOP without OOP) and must be used".