Gunnar Dalsnes wrote:
The new operator is just a word as anything else. Just because its a compiler feature doesnt make it "magic". It just means that every C++ compiler should reserve and support it just like we can say ReactOS reserve and support Xxx for usage Xxx. And you can overload new u know. Then you never know what it _really_ does;-P
I think you missed the point. The fact of the matter is that new is a part of standard C++. Every programmer who knows C++ can understand your code when you stick to standard C++. When you start obfuscating the code with macros, it becomes much harder to understand, and in effect, you aren't really speaking C++ anymore because anyone fluent in C++ can't read your code. It's like if you were to overload operator+ and have it do something completely unrelated to adding two things together. Sure, you can do it, and sure, if you understand the implementation of that operator+ you can figure out what the code is doing, but it is in no way obvious to someone who knows C++ and has the expectation that an operator+ adds. Hard to read code is bad code.
It this context it would be "Zimbabwean sound so weird I refuse to learn it. Zimbabwean is flawed and ppl should stop speaking it. They should learn English instead so I can understand them."
Again you miss the point entirely. I don't learn Zimbabwean because everyone I need to speak with understands English perfectly fine. *YOU* speak English perfectly fine. Just because you want to speak Zimbabwean does not mean that I should learn it. Sure, I could, but why should I waste the time learning it when there is no gain? You and I already can communicate in English, switching to Zimbabwean has no real benefit, so me learning it is only a waste of time. You trying to FORCE me to learn it is well, insulting.
So then Im free to apply that schema thruout ros? Or will I then get: "gotos sux", "please dont do this", "it looks so ugly", "i refuse to do it this way" etc?
Lots of code in ReactOS uses gotos in the way I described before. As all beginning programming students are taught, gotos are evil, but sometimes they are the lesser evil. This type of error handling in C is a time when CAREFUL use of gotos is less evil than the alternative. It avoids duplicating cleanup code while remaining clear and concise, which is why it is an industry standard practice. If you search you can find plenty of code out there that uses it, and plenty of best practices material that advises it.
They are just as deficient as the goto example you showed ei. equivalent.
No, they aren't. The goto is defficient because it breaks the control of flow. Exactly how it breaks it though, is obvious to anyone who speaks the language. The alternative to breaking flow control is to duplicate cleanup code, and that is a greater evil bacuse it produces even harder to maintain code than using the gotos. The macros not only break flow control, but they do so in a non obvious way, which makes them more evil than the gotos. That increase in evil is not balenced by an increase in good, so it is a bad decision.
Just because someone else says you should do so doesnt make it right. Thinking for urself (open mind) and not caring about what others says ("the standard") can be a relief.
You seem to be missing the entire point of this conversation. You are not a unique snowflake. Being different for the sake of being different is not a good thing. Ignoring others when you are trying to work with them is not a good thing. You are not the first person to have this idea. A great many before you have had this idea, and finally come to realize why it is bad. That is the reason that use of gotos and not flow control macros have become industry standard. While one should not blindly follow standards without question, there are very good reasons the standards exist, so unless you have a better reason not to follow it, you should.
In this case, following the generally accepted standards produces more readable code, and as a programmer, that should be one of your priorities. Sometimes breaking with convention can be a good thing, but such a decision needs to be weighed carefully and taken only if the benefits outweigh the losses. In this case, the only benefit to use of flow control macros is they save you a few keystrokes when writing the code, and you find it aesthetically pleasing. Of course you do, you wrote it.
With no real benefit the needs of the many outweigh your aesthetic desire to use the macros. The readability of the code to others and its maintainability in the future are far more important than your aesthetics.
Have a look at any medium to large function in ros and youll pretty fast find points of return (in case of error/fail) where it fails to do some cleanup. Having a common place for cleanup makes it easier to make this right.
Yes, having a common return point is a good programming practice, but again, when choosing HOW to have a common point of return, the method that is clearest and simplest and best understood produces the best code.
Thats exactly what macros _should_ be used for. Hiding mess. Im sure macros, gotos etc. can be abused but imo this is not the case here.
That IS the case here. Macros should _ONLY_ be used to hide a mess when doing do has some pretty strong benefits to outweigh the complexity it adds. In this case, the macro does not have any real benefit, therefore the added complexity with no benefit constitutes abuse.