Welcome to E-Goat :: The Totally Unofficial Royal Air Force Rumour Network
Join our free community to unlock a range of benefits like:
  • Post and participate in discussions.
  • Send and receive private messages with other members.
  • Respond to polls and surveys.
  • Upload and share content.
  • Gain access to exclusive features and tools.
Join 7.5K others today

Macro vs Sub?

  • Following weeks of work, the E-GOAT team are delighted to present to you a new look to the forums with plenty of new features. Take a look around and see what you think!
Trending This Week
View More Trending
S

Shugster

Warrant Officer
3,702
0
0
Can anyone tell me the difference between a Macro and a Subroutine?

As far as I can see they're one and the same. Or are we talking the difference between assembler / C and the actual code that gets written to the eeprom / processor memory locations?
 
Shugster said:
Can anyone tell me the difference between a Macro and a Subroutine?

As far as I can see they're one and the same. Or are we talking the difference between assembler / C and the actual code that gets written to the eeprom / processor memory locations?
Click to expand...
This might help!

It's really simple to use when you get the hang of it.
 
Thanks for that. I could have gone to a number of better forums but wanted to get the grey matter stirring in other geeks... er I mean others interested in programming...

So, I'll stick with my subs, macros make life easier but take more space, (and therefore more time to execute), and as that's the lazy / easy approach I'll leave it.

A microsecond wasted is time I could have spent doing something else!
:PDT_Xtremez_15:
 
Shugster said:
Can anyone tell me the difference between a Macro and a Subroutine?

As far as I can see they're one and the same. Or are we talking the difference between assembler / C and the actual code that gets written to the eeprom / processor memory locations?
Click to expand...

You cant avoid using macros in C and C++. #include. #define, conditional compilation guards etc but their use should be limited as much as is possible. Macros ignore scope, types. Compilers have great difficulty in trapping compile-time errors that would otherwise be found in a subroutine. When they do go wrong they are a pig to debug. They can use memory in unexpected ways (and silently!) and wont be optimised by the compiler.

The syntax of macros is peculiar and not intuitive for more complex tasks...I know this because of a rather large part of my last project had a big smelly macro in it, designed by yours truly. This was accepted since we were suffering more problems with the original method.

If you remember one thing, remember, macros are bad.

As an aside, the original implementation of Microsoft MFC is full of macros. This means applications on your desktop depend on macros to execute, even though they are the work of the devil.

If youre talking about micro-controllers and assembly, thats another subject entirely. If youre working with a high-level language, especially if you are doing it professionally, avoid like the plague.
 
As you know I play with Microcontrollers.

I had to recompile somone elses code yesterday and Macros were included in the assembler code... Not only that, the old code was over ten years old and the new Microchip assembler flagged up case sensitive errors etc... over 300 in all! :PDT_Xtremez_35:

I got there in the end. :PDT_Xtremez_19:

Strange to have a job that you love / hate equally! :PDT_Xtremez_15:
 
You must log in or register to reply here.
Back
Top