To MACRO or not to MACRO
-
In the C++ community there is certain unhappy feeling towards the use of MACROs. In a post someone was given the advice to use a inline function instead of a MACRO. This is certainly good advice. Now my question is the following: Are there any reasons/issues or other situations where a MACRO can be preferred over another solution. Or should one 'try' to find a better C++ approach. One thing could be to decrease the amount of code, so it becomes more readable and less complex. Any thoughts on this?
codito ergo sum
-
In the C++ community there is certain unhappy feeling towards the use of MACROs. In a post someone was given the advice to use a inline function instead of a MACRO. This is certainly good advice. Now my question is the following: Are there any reasons/issues or other situations where a MACRO can be preferred over another solution. Or should one 'try' to find a better C++ approach. One thing could be to decrease the amount of code, so it becomes more readable and less complex. Any thoughts on this?
codito ergo sum
BadKarma wrote:
One thing could be to decrease the amount of code, so it becomes more readable and less complex.
No, that is hiding complexity, not decreasing it. MACROS are a bad substitute for redesigning bad, unnecessarily complex code. They also make debugging more difficult. I can't think of any situation where a MACRO would be the preferred solution.
-
BadKarma wrote:
One thing could be to decrease the amount of code, so it becomes more readable and less complex.
No, that is hiding complexity, not decreasing it. MACROS are a bad substitute for redesigning bad, unnecessarily complex code. They also make debugging more difficult. I can't think of any situation where a MACRO would be the preferred solution.
The only time that it's acceptable is if you are deliberately attempting to create bad code where you are the only person who can maintain it. Hmmm - oh wait - that's the sign of a really bad app.
Deja View - the feeling that you've seen this post before.
-
BadKarma wrote:
One thing could be to decrease the amount of code, so it becomes more readable and less complex.
No, that is hiding complexity, not decreasing it. MACROS are a bad substitute for redesigning bad, unnecessarily complex code. They also make debugging more difficult. I can't think of any situation where a MACRO would be the preferred solution.
Actually MACROs are widely used in the ATL library, that is no such bad design example. MACROs are also used in MFC, and, for instance, to make more readable operations on ListView, ecc..., DirectX often hides COM complexity using macros. MACROs are hazardous of course and there are arguments against their use. But by no means MACROs are the origin or the signature of a bad design. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
-
In the C++ community there is certain unhappy feeling towards the use of MACROs. In a post someone was given the advice to use a inline function instead of a MACRO. This is certainly good advice. Now my question is the following: Are there any reasons/issues or other situations where a MACRO can be preferred over another solution. Or should one 'try' to find a better C++ approach. One thing could be to decrease the amount of code, so it becomes more readable and less complex. Any thoughts on this?
codito ergo sum
The only time I would see as an advantage of using macros is when programming in C (I haven't used C++), an instance of this was some code I wrote for a company who shall remain anonymous where the biggest emphasis was on speed because it was performing rainflow analysis of vast quantities of data, all on a micro. God forbid but most functions were eliminated in favour of copy and paste and gotos were used because the original idea was then to use an FPGA to do the analysis, i.e. perform it in hardware so because they don't have a concept of functions etc these were copied in and gotos were used because they're nice and fast, especially in hardware. In the end the other company decided to use a micro and refactored back my optimisations, then hit a problem, it was taking 4 times too long. I was called in and noticed they were doing stupid things like calling these tiny little functions, if it the micro had been able to manage it it would have had to call this routine 1,000 / second (note this was only a tiny part of the entire, complex algorithm) so I changed the function into a macro so it "looked" like a function to them but actually wasn't. Of course I guess this is exactly what inline functions are for in C++ but most if not all C compilers don't support them. So no I can't think of any good reason :rolleyes:
-
In the C++ community there is certain unhappy feeling towards the use of MACROs. In a post someone was given the advice to use a inline function instead of a MACRO. This is certainly good advice. Now my question is the following: Are there any reasons/issues or other situations where a MACRO can be preferred over another solution. Or should one 'try' to find a better C++ approach. One thing could be to decrease the amount of code, so it becomes more readable and less complex. Any thoughts on this?
codito ergo sum
In general macros are bad and should be avoided. I don’t believe this “macros are bad full stop” line however; macros have their uses. And I'm not alone: The Boost libraries are highly acclaimed C++ libraries and they use macros when needed; Andrei Alexandrescu says he’s not afraid to use macros here[^].
Steve
-
In the C++ community there is certain unhappy feeling towards the use of MACROs. In a post someone was given the advice to use a inline function instead of a MACRO. This is certainly good advice. Now my question is the following: Are there any reasons/issues or other situations where a MACRO can be preferred over another solution. Or should one 'try' to find a better C++ approach. One thing could be to decrease the amount of code, so it becomes more readable and less complex. Any thoughts on this?
codito ergo sum
Macros are processed at pre-compile time, so they serve a purpose of course. Think the ASSERT in MFC. Can't do that with inlined functions. Well you could, but what a waste. MACROS some might argue, are bad practice. Personally, there have been many times while programming in JS or PHP where I have considered running my code through a pre-processor to gain the benefits of macro expansion. Ask any interpreted language developer with experience in C/C++ and they'd likely agree. When you program OOP, everything is an object, at least in a purists eyes. Using inline functions would seem messy and pointless. Are you going to throw all generic functions inside a class named CGeneric and call them statically? That would be hack, IMHO. In those cases where you need some simple code, that is common in more places than a single class, Macros are a good thing. Most Macros that I have used, such as LOWORD, etc...make sense as a macro, not an inlined function... So to answer your question, no Macros are not evil, the developers who use them inappropriately are. :) There are times when I write code, that is clean and effective but could be slightly more elegant or efficient if I could use a GOTO (no longer the case in most languages). I think macros, globals, goto's and even multiple inheritence can still be useful, but their use has to be completely understood and justified, otherwise they promote bad coding practice and you end up with crap. Then again, I've seen purist OO code with-out macros, globals, goto, or MI and it was crap too. Cheers :)
I'm finding the only constant in software development is change it self.
-
BadKarma wrote:
One thing could be to decrease the amount of code, so it becomes more readable and less complex.
No, that is hiding complexity, not decreasing it. MACROS are a bad substitute for redesigning bad, unnecessarily complex code. They also make debugging more difficult. I can't think of any situation where a MACRO would be the preferred solution.
ASSERT & HIWORD/LOWORD are just two examples that came to mind. I certainly wouldn't use a inline function for either of those. :)
I'm finding the only constant in software development is change it self.
-
In the C++ community there is certain unhappy feeling towards the use of MACROs. In a post someone was given the advice to use a inline function instead of a MACRO. This is certainly good advice. Now my question is the following: Are there any reasons/issues or other situations where a MACRO can be preferred over another solution. Or should one 'try' to find a better C++ approach. One thing could be to decrease the amount of code, so it becomes more readable and less complex. Any thoughts on this?
codito ergo sum
When the intention is to abstract away repeating blocks of code which include things like "return", the only option is to use a macro. #define RETURN_IF_NULL(ptr) if(ptr==NULL) return FAILURE_NULL now, instead of the repetitively doing that null pointer check using three lines of code space, we can do it in one line, enabling us to focus on the "real" code. RETURN_IF_NULL(param1) RETURN_IF_NULL(param2) RETURN_IF_NULL(param3) This cannot be done using inline functions.
-
In the C++ community there is certain unhappy feeling towards the use of MACROs. In a post someone was given the advice to use a inline function instead of a MACRO. This is certainly good advice. Now my question is the following: Are there any reasons/issues or other situations where a MACRO can be preferred over another solution. Or should one 'try' to find a better C++ approach. One thing could be to decrease the amount of code, so it becomes more readable and less complex. Any thoughts on this?
codito ergo sum
Actually just saying that MACROs are bad, is half knowledge. Many many platforms like MFC and ATL use MACROs extensively. The platform(Architecture) I work on is OS independent. In that case MACRO work as saviour. We can't use standard template because that would make code platform dependent so we have to USE MACRO to simulate templates. MACROs are an effective way to use the strength of preprocessor, if you use them correctly then they can really be useful. When some one says that avoid MACROs then the main intention is to avoid using it at the place of function. But the usage of MACROs are beyond that also where they would be indispensable.
