[ros-dev] Re: [ros-svn] [gdalsnes] 18113:-reorderInsertXscendingOrder macro argument order and update uses

[Phillip Susi]

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.