[ros-svn] [gdalsnes] 18113:-reorderInsertXscendingOrder
macro argument order and update uses
psusi at cfl.rr.com
Wed Sep 28 17:18:46 CEST 2005
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
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.
More information about the Ros-dev