# #define and ##name##

This topic is 4529 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

A friend of mine uses the syntax below to cut down on the number of code lines he has to write to add access functions for all his private variables.
#define GETFLOAT(NAME) float Get##NAME##(void) { return m_f##NAME##; } }

Now this seems to work quite well, and as long as it is kept simple, a real time saver. I wondered if anyone else had used this style of #define'ing before, and what their thoughts were on it? Also (and most important) is this a .net or MS specific peice of code, and will it work on Linux and Mac based systems? Thanks Spree

##### Share on other sites
Quote:
 Original post by SpreeTree...add access functions for all his private variables.

Eh.. Nice design..

##### Share on other sites
Not for getters and setters. If I even need more than a few then I've generally done something wrong and need to redesign it anyway.
However I do use macros and name concatenation freely to cut down on repetitive code, especially for data initialization.

Unless you happen to encounter a pre-ANSI C preprocessor I wouldn't worry about compability.

##### Share on other sites
Quote:
 Original post by SpreeTreeNow this seems to work quite well, and as long as it is kept simple, a real time saver.

Writing a macro for something that simple really isn't a good idea.

Quote:
 I wondered if anyone else had used this style of #define'ing before, and what their thoughts were on it?

I have used macros to produce definitions, but they were rather more intricate than that one. Honestly, I don't think much good of code like your friend's.

Quote:
 Also (and most important) is this a .net or MS specific peice of code, and will it work on Linux and Mac based systems?

It's pure C preprocessor stuff. It will work ony any system that provides one such. Which in fact is generally more likely on Linux and MacOS X than it is on Windows, since those two platform typically ship with a compiler (GCC) while Windows ... does not.

##### Share on other sites
Do you need getters for *all* your private variables? And if you do, how often is it always a trivial getter like that?

If the answer is yes to both of these questions, your class design probably isn't much good.

##### Share on other sites
Looking at his code (void return type, f prefix) it seems that he still thinks he's in C. Point him in the direction of a good C++ article!

##### Share on other sites
I used the above example as it was short and sweet, and showed the feature that I wanted to discuss.

I personally am not using it for getters and setters, instead using it for a chunk of code that I have to write time and time again, for different class types and variables (and no templates will not solve that problem:)

I just wanted peoples general opinion on the style of coding using that, and if (other than the usual macro problems) their are any particular dangers with the code.

Spree

##### Share on other sites
Quote:
 Original post by Daniel MillerLooking at his code (void return type, f prefix) it seems that he still thinks he's in C. Point him in the direction of a good C++ article!

If you look closer at the #define, it is actually a float return type, and the f prefix is a coding notation used for this particular piece of code. It has nothing to do with C or C++

Spree

##### Share on other sites
Quote:
 Original post by FrunyWriting a macro for something that simple really isn't a good idea.
I disagree. I regularly use macros to cut down on large chunks of very simple but highly repetitive code.

Quote:
 Original post by Daniel MillerLooking at his code (void return type, f prefix) it seems that he still thinks he's in C. Point him in the direction of a good C++ article!
I assume you're refering to the explicitly void parameter list.
Personally I'm in the habit of always writing out (void). Since it doesn't hurt in C++ while using a truly empty declaration in C is equivalent to a function with a variable argument list.
It's just way to easy to forget to switch back to the old style when using C since most compilers don't give you any warnings and gladly accept arguments to void functions. In fact I used a library where the author had forgotten about this just a few days ago.

Quote:
 Original post by SpreeTreeI personally am not using it for getters and setters, instead using it for a chunk of code that I have to write time and time again, for different class types and variables (and no templates will not solve that problem:)I just wanted peoples general opinion on the style of coding using that, and if (other than the usual macro problems) their are any particular dangers with the code.
Sure, as long as it saves time in the long run and doesn't obfuscate things too much.

##### Share on other sites
Quote:
 Original post by SpreeTreeI just wanted peoples general opinion on the style of coding using that, and if (other than the usual macro problems) their are any particular dangers with the code.

Debugging code generated by your preprocessor macros is going to be a pain in the arse.

##### Share on other sites
Quote:
 Original post by SandmanDebugging code generated by your preprocessor macros is going to be a pain in the arse.
This is true.
A good tip if things get out of hand is to use a selective preprocessor to expand the macros for you (to check the results or use temporarily for debugging).

##### Share on other sites
Quote:
 Original post by SandmanDebugging code generated by your preprocessor macros is going to be a pain in the arse.

Well the code I am using the macro for works, and has worked for over a year now. I just discovered this method, and realised I could replace a lot of my exisiting code with this macro.

The main benifit of doing this is when I need to extend the code, I will no longer have to do it countless times.

But yeah, if it doesn't work, I know how much of a pain it will be!

Spree

##### Share on other sites
Quote:
 I wondered if anyone else had used this style of #define'ing before, and what their thoughts were on it?

I've used that style of defining in my game engine, where I wanted to register a class (which is a child) with ease. This is what I did (which is kind of cheap):
#define OBJECT_REGISTER(var,class,parent) instance* __NEW_##var() { return new class; }  OBJ_ID var=object_register(&__NEW_##var,#var,parent)

And for an example:
class CBiscuit : public instance { ...}; OBJECT_REGISTER(idBiscuit,CBiscuit,-1);

What it did was take the function created by the macro, the name of the variable which was created to have the ID assigned to it, and took the parent's ID (OBJ_ID), stuck it in a list, and returned the ID to "var". This in turn allows me to create types of that instance with only ID's, which will aid me in the line of level creation and designing. Plus, it makes me feel special. *Get's slapped*

##### Share on other sites
Quote:
 Original post by SpreeTreeI could replace a lot of my exisiting code with this macro

You'd replace your EXISTING code in order to save typing time? That seems...... ill-advised.

##### Share on other sites
We use something very similar at work. I don't much care for it.

##### Share on other sites
Quote:
 Original post by SneftelYou'd replace your EXISTING code in order to save typing time? That seems...... ill-advised.

Not at all. The code I am replacing is very obtuse, and due to its similarity and size, is hard to maintain. Also, I will be adding similiar code in the future. Having two methods would be ill advised.

There is nothing wrong with replacing exisiting code if the new code or methods makes the code faster, easier to maintain or update.

Spree

##### Share on other sites
Quote:
 Original post by SpreeTreeThere is nothing wrong with replacing exisiting code if the new code or methods makes the code faster, easier to maintain or update.

But it wouldn't be any of those. Seriously, how horrible and obfuscated can a getter function be? You'd really have to work at it.

##### Share on other sites
Quote:
 Original post by SneftelBut it wouldn't be any of those. Seriously, how horrible and obfuscated can a getter function be? You'd really have to work at it.

As I said earlier, I used the getter code as an example of the feature I wanted to discuss.

The code I am using this for is for the creation, deletion and cycling through resources created using factories. As I have a large number of reasourcs, that already used templated factories, I wanted to cut down on the number of functions and lines of code I needed to write to make it all work :)

Spree

##### Share on other sites
I can see why some people have problems with it, but if you're lazy like me, you usually cbf copying and pasting code and renaming things. I've used simple things like this plenty of times before, but I've also used them for more complex things (like reading similar chunks from files and getting the necessary data from them, while discarding the rest, and quitting if something bad happened).

There is only a few places you can use them though, and unless you plan on naming everything in a similar mannor, it's generally more annoying to deal with. As for the debugging issues and so forth, if you think the code's going to cause you problems, write it out in full, rather than using macros, but if it's not going to slow you down, why waste time copying large chunks of text time and time again?

##### Share on other sites
Ah. I see.

Yes, for much more complex things like factory registration, macros can be useful. Be careful, though. The limitations of the preprocessor are often rather arbitrary and limiting; you may find yourself in a situation where your macro solution no longer fits the problem. Spend a significant amount of time deciding what functionality your solution will need, before you put it into use.

##### Share on other sites

This topic is 4529 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628647
• Total Posts
2984035

• 10
• 9
• 9
• 10
• 21