Sign in to follow this  
SpreeTree

#define and ##name##

Recommended Posts

SpreeTree    396
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 this post


Link to post
Share on other sites
doynax    850
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 this post


Link to post
Share on other sites
Fruny    1658
Quote:
Original post by SpreeTree
Now 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 this post


Link to post
Share on other sites
Sandman    2210
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 this post


Link to post
Share on other sites
SpreeTree    396
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 this post


Link to post
Share on other sites
SpreeTree    396
Quote:
Original post by Daniel Miller
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!


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 this post


Link to post
Share on other sites
doynax    850
Quote:
Original post by Fruny
Writing 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 Miller
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!
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 SpreeTree
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.
Sure, as long as it saves time in the long run and doesn't obfuscate things too much.

Share this post


Link to post
Share on other sites
Sandman    2210
Quote:
Original post by SpreeTree
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.


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

Share this post


Link to post
Share on other sites
doynax    850
Quote:
Original post by Sandman
Debugging 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 this post


Link to post
Share on other sites
SpreeTree    396
Quote:
Original post by Sandman
Debugging 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 this post


Link to post
Share on other sites
deadimp    310
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 this post


Link to post
Share on other sites
Sneftel    1788
Quote:
Original post by SpreeTree
I 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 this post


Link to post
Share on other sites
SpreeTree    396
Quote:
Original post by Sneftel
You'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 this post


Link to post
Share on other sites
Sneftel    1788
Quote:
Original post by SpreeTree
There 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 this post


Link to post
Share on other sites
SpreeTree    396
Quote:
Original post by Sneftel
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.


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 this post


Link to post
Share on other sites
Gorax    202
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 this post


Link to post
Share on other sites
Sneftel    1788
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 this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this