Making a crowdsourced project on Canvas - page 24
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
If two programmers with the same experience and intelligence are competing, creating similarlarge projects. But the first uses only functions, and the second uses functions and classes. Definitely, the victory will be for the second one. But, I repeat, if it is a voluminous project, the latter will make it faster because there will be fewer bugs and more order. And the product of the second will be more readable, maintainable and more easily updated and supplemented. This isn't even my imho, it's just a statement of fact. It's easier to dig a hole with a shovel than with a trowel. If you implemented your mechanism not only on functions but also on classes, it would become more efficient. Now this is my imho.
Let's start with the question of the need for classes in the implementation of large mechanisms. A class is a shell for a set of some functions, and a "big mechanism" is a block of code that implements a set of tasks. In my implementation, a "big mechanism" is almost always one very large function and a set of small ones that serve it. The so-called "engine". If you stuff it with serving functions into one class, nothing will change, and if you stuff it into different classes, the access between them will become more complicated and mechanism efficiency will lower.
If the size of the mechanism enlarges, you must optimize its code or divide the functionality into files. Isn't it enough? Moreover, periodical optimization of the code in one block leads to miracles of efficiency. It is constantly compressed and takes more and more functions to be implemented. That is the number of functions decreases on the contrary. They are generalized in one block, the code of which is constantly improved. This is a direct road to efficiency .
Further, if we make important variables global, they will be visible everywhere in the mechanism, and it will be easy to work with them, and if we define scopes for them, it will create superfluous task from the point of view of efficiency of the mechanism. Again, complication of access. Creating class objects, and so on... The tendency to fragment the mechanism into a large number of functions ruins not only efficiency, but also universality of code blocks. It turns out that each concrete task needs a separate function, and the universality of code blocks simply isn't improved. The number of calls and parameters passed also grows. This doesn't make the mechanism more efficient, but this tendency is in fact promoted by OOP.
OOP is more efficient when a project is worked on by a group of programmers. In this case you cannot do without it. Although, if you think about it, you can find a way to do without it here too...
But of course, these are all words. In practice, I would quickly prove what I am talking about.
Nikolai Semko:
And, Peter, I've had a quick look at your code and realized that you're using canvas to its full extent (not CCanvas class, but who cares). Then why all these questions about canvas and why I'm trying to explain all these things here? :)).
)))), I'm a bit surprised by your explanations of kanvas' drawing principles. I've told you before and showed you that everything in my kanvas is drawn.)) (Well almost everything. :))
Started this topic because I can not understand why so far no one has not drawn the same button as mine. After all, and in your words it's easy.
))), I was also a bit surprised by your explanation of the principles of drawing on canvas, because I've told you and shown you before that everything is drawn.)) (Well almost everything. :))
Started this topic because I can not understand why so far no one has not drawn the same button as mine. After all, and in your words it's easy.
If you have not seen, it does not mean that no one but you can not do it. It's just so insignificant that you don't even need to post it - too insignificant an event - creating just a button - to post its code, not because you're the best ;)
You're all competing, and rightly so, Anatoly - with windmills.
If you haven't seen it, that's not to say that no one but you is able to do it. It's just so insignificant that there's no need to post it - too insignificant an event - just creating a button - to post its code, not because you're the best ;)
You're all competing, and rightly so, with windmills.
Calm down, Artem. I've already realized that you don't like me. Apparently, so do many others on this resource. Maybe it's justified, but it's too much to change your personality out of the blue when discussing technical issues.
I'm calm, what makes you think otherwise?
Like/dislike a person - it's not a technical forum to discuss. You are neutral to me - nothing more. Equally, as for the rest of us it seems to me.
But for you to be mentioned not in the style of "ah-ah-ah..., it's that Don Quixote..., I remember, I remember...", you need to do something useful at least.
You may or may not do what you want to do - your right, and no one is disputing it. Nobody needs your word here - you should give it to yourself in the first place ;)
The atmosphere is very friendly - people tell you how nice it is to use OOP in some situations, a man is crucifying before you, trying to help you in something, coding for you to show you, to make it more understandable. But it turns out - from your own words - that you don't even need it - you just don't know who else to compete with, and try to challenge people "weakly".
And what also seems to me - you're not because you decided not to write and not to study OOP, that you've weighed everything and understood that you, using procedural programming, write much better and optimized code (as you presented it to everybody here), but simply because you don't understand anything there, and invented an excuse, which you announced to everyone, supporting it with words and challenge "believe only he who beats me".
Remember the joke about "Elusive Joe"?
...
Remember the joke about "Elusive Joe"?
Absolutely agree.
The elusive lyricist/philosopher... :-) the same crap as "Joe", only in the "other hand"... :-)
Let's start with the issue of the need for classes in the implementation of large mechanisms. A class is a shell for a set of functions, and a "big mechanism" is a block of code that implements a set of tasks. In my implementation, a "Big Machine" is almost always one very large function and a set of small ones that serve it. The so-called "engine". If you stuff it with serving functions into one class, nothing will change, and if you stuff it into different classes, the access between them will become more complicated and mechanism efficiency will lower.
If the size of the mechanism enlarges, you must optimize its code or divide the functionality into files. Isn't it enough? Moreover, periodical optimization of the code in one block leads to miracles of efficiency. It is constantly compressed and takes more and more functions to be implemented. That is the number of functions decreases on the contrary. They are generalized in one block, the code of which is constantly improved. This is a direct road to efficiency .
Further, if we make important variables global, they will be visible everywhere in the mechanism, and it will be easy to work with them, and if we define scopes for them, it will create superfluous task from the point of view of efficiency of the mechanism. Again, complication of access. Creating class objects, and so on... The tendency to fragment the mechanism into a large number of functions ruins not only efficiency, but also universality of code blocks. It turns out that each concrete task needs a separate function, and the universality of code blocks simply isn't improved. The number of calls and parameters passed also grows. This doesn't contribute to the efficiency of the mechanism but this tendency is actually promoted by OOP.
OOP is more efficient when a project is handled by a team of programmers. In this case you cannot do without it. Although, if you think about it, you can find a way to avoid it here too...
But of course, these are all words. In practice, I would quickly prove what I am talking about.
Peter, it's just that I used to program only with functions and reasoned almost the same way as you do now, and then I almost through force (for the force of habit is incredible) started programming with classes. Now I can compare the two states, while you, who haven't tried applying classes, can't. No offence. It just reminds me of another situation. I've been a vegetarian for many years now. And with enviable regularity there are people who have never been vegetarian and try to rub it in to me about proteins, essential amino acids etc. I tell them: we are not in equal conditions, I was a meat eater and now I am a vegetarian so I can compare these two conditions in terms of practice. You are not and your knowledge is only theoretical which has nothing to do with practice.
Do not waste your time - master OOP.
You're completely banned on this forum, my friend. :)) Including me. :( Don't despair - what does not kill us makes us stronger. I believe in you!!! :))
Don't waste your time - master OOP.
You are completely banned on this forum, my friend. :)) Me too. :( Don't despair - what doesn't kill us makes us stronger. I believe in you!!! :))
Let's start with the issue of the need for classes in the implementation of large mechanisms. A class is a shell for a set of functions, and a "big mechanism" is a block of code that implements a set of tasks. In my implementation, a "Big Machine" is almost always one very large function and a set of small ones that serve it. The so-called "engine". If you stuff it with serving functions into one class, nothing will change, and if you stuff it into different classes, the access between them will become more complicated and mechanism efficiency will lower.
If the size of the mechanism grows, it is necessary to optimize its code or divide the functionality into files. Isn't it enough? Moreover, periodical optimization of the code in one block leads to miracles of efficiency. It is constantly compressed and takes more and more functions to be implemented. That is the number of functions decreases on the contrary. They are generalized in one block, the code of which is constantly improved. This is a direct road to efficiency .
Further, if we make important variables global, they will be visible everywhere in the mechanism, and it will be easy to work with them, and if we define scopes for them, it will create superfluous task from the point of view of efficiency of the mechanism. Again, complication of access. Creating class objects, and so on... The tendency to fragment the mechanism into a large number of functions ruins not only efficiency, but also universality of code blocks. It turns out that each concrete task needs a separate function, and the universality of code blocks simply isn't improved. The number of calls and parameters passed also grows. This doesn't contribute to the efficiency of the mechanism but this tendency is actually promoted by OOP.
OOP is more efficient when a project is worked on by a group of programmers. In this case you cannot do without it. Although, if you think about it, you can find a way to avoid it here too...
But of course, these are all words. In practice, I would quickly prove what I am talking about.
And there's something to that. Alan Kay, the creator of OOP, actually had a very different idea from what is meant by OOP today. It is even more similar to your vision. I've got an idea to create a project with one core and services calling to it for some functionality. And the communication between the elements will happen only through events-messages. As soon as you send an event-request with the data, you receive the event-reply with the result. There is no inheritance, polymorphism or inclusion.
By the way, with this approach multithreading is easier to organize because all the elements by definition work independently of each other.
There is something in it. Alan Kay, the creator of OOP, had a different idea from what is meant by OOP today. It is even more similar to your vision. I've got an idea to create a project with one core and services calling to it for some functionality. And the communication between the elements will happen only through events-messages. As soon as you send an event-request with the data, you receive the event-reply with the result. There is no inheritance, polymorphism or inclusion.
By the way, with this approach, multithreading is easier to organise, because all the elements are by definition working independently of each other.