471,078 Members | 807 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,078 software developers and data experts.

Preprocessor trick

Hi All,

I'm trying to define a macro that will allow me to write the following
code :

#include MY_MACRO( NAME, SPACE )

and end up with the following preprocessed code :

#include NAME.hpp

namespace SPACE {
typedef NAME ImportedNAME;
}

I have a macro that generates the correct text but since macros expand
on one unique line, what I actually end up with is the following :

#include NAME.hpp namespace SPACE { typedef NAME ImportedNAME; }

The problem with this is that the preprocessor will ignore any text
behind the filename in an #include directive, so the "namespace SPACE
...." gets skipped and meerly disappears.

I've tried to defined a macro representing the carrige return
character, but it doesn't work, and I can't seem to find any other
idea. Is there a way to get a macro to expand on several lines ?

Thanks for your help.

BR,

Olivier.

Nov 22 '06 #1
6 2923
ol***********@gmail.com wrote:
I'm trying to define a macro that will allow me to write the following
code :

#include MY_MACRO( NAME, SPACE )

and end up with the following preprocessed code :

#include NAME.hpp

namespace SPACE {
typedef NAME ImportedNAME;
}

I have a macro that generates the correct text but since macros expand
on one unique line, what I actually end up with is the following :

#include NAME.hpp namespace SPACE { typedef NAME ImportedNAME; }

The problem with this is that the preprocessor will ignore any text
behind the filename in an #include directive, so the "namespace SPACE
..." gets skipped and meerly disappears.

I've tried to defined a macro representing the carrige return
character, but it doesn't work, and I can't seem to find any other
idea. Is there a way to get a macro to expand on several lines ?
No. Lines do not really exist after the preprocessor is done with
the source code.

And I am not sure you're getting what you wanted. If a macro expands
into another preprocessor directive, that directive is not going to
be preprocessed. No recursive preprocessing except for macro expansion.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Nov 22 '06 #2
Victor Bazarov wrote:
No. Lines do not really exist after the preprocessor is done with
the source code.

And I am not sure you're getting what you wanted. If a macro expands
into another preprocessor directive, that directive is not going to
be preprocessed. No recursive preprocessing except for macro expansion.
Well that can't be true, or else, the following code would be valid :

#include <iostream>
#include "MyFile.hpp" namespace Testing { typedef int Type; }

int main( int argc, char **argv )
{
Testing::Type i(0);
std::cout << "i = " << i << "\n";
return 0;
}

This code won't compile, and the compiler will complain there is an
extra token after the #include directive. All preprocessor directives
need to be on their own line. Even a macro that is _defined_ on several
lines still expands on only one line. For example the following macro :

#define TEST( NAME ) \
class NAME \
{ \
public: \
NAME( ) { } \
}

Is defined on several lines by using the "\" character that means the
current line of code is extended on the next line of the file. If you
use this macro with a simple call like "TEST(Test);", you will actually
get the resulting formatting in your preprocessed source file :

class Test { public: Test( ) { } };

The full macro will be expanded on one single text line. Due to this, I
need to find a way where I can get multiline macro _expansion_. And I
can't figure out how to do this. If you have any ideas ...

BR,

Olivier.

Nov 22 '06 #3
casul wrote:
Victor Bazarov wrote:
>No. Lines do not really exist after the preprocessor is done with
the source code.

And I am not sure you're getting what you wanted. If a macro expands
into another preprocessor directive, that directive is not going to
be preprocessed. No recursive preprocessing except for macro
expansion.

Well that
What 'that'? That I am not sure? That if a macro expands into
a directive, it is not going to be recursively interpreted?
can't be true, or else, the following code would be valid :

#include <iostream>
#include "MyFile.hpp" namespace Testing { typedef int Type; }

int main( int argc, char **argv )
{
Testing::Type i(0);
std::cout << "i = " << i << "\n";
return 0;
}

This code won't compile, and the compiler will complain there is an
extra token after the #include directive.
Yes. How does that go against what I've said?
All preprocessor directives
need to be on their own line. Even a macro that is _defined_ on
several lines still expands on only one line. For example the
following macro :

#define TEST( NAME ) \
class NAME \
{ \
public: \
NAME( ) { } \
}

Is defined on several lines
No, it isn't. The lines you see in the source code are actually
concatenated into one before the directive is preprocessed. So, when
you think you're defining it on more than one line, you don't.
by using the "\" character that means the
current line of code is extended on the next line of the file. If you
use this macro with a simple call like "TEST(Test);", you will
actually get the resulting formatting in your preprocessed source
file :

class Test { public: Test( ) { } };

The full macro will be expanded on one single text line. Due to this,
I need to find a way where I can get multiline macro _expansion_. And
I can't figure out how to do this. If you have any ideas ...
No macro can expand into more than one line. Think about it. When you
define a macro, it's a single line. So, no matter what tricks you try
to play, a macro expansion will never have line breaks in it.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Nov 22 '06 #4
:
I have a macro that generates the correct text but since macros expand
on one unique line, what I actually end up with is the following :

#include NAME.hpp namespace SPACE { typedef NAME ImportedNAME; }

There's a few preprocessor guru's over on comp.lang.c, I'd say you might have
a bit of luck posting there.

(Not being sarcastic)

--

Frederick Gotham
Nov 22 '06 #5

Victor Bazarov wrote:
casul wrote:
Victor Bazarov wrote:
No. Lines do not really exist after the preprocessor is done with
the source code.
This is what can't be true since the compiler expects a line break
after a preprocessor directive.
>
And I am not sure you're getting what you wanted. If a macro expands
into another preprocessor directive, that directive is not going to
be preprocessed. No recursive preprocessing except for macro
expansion.
Well that

What 'that'? That I am not sure? That if a macro expands into
a directive, it is not going to be recursively interpreted?
See my comment above.
>
can't be true, or else, the following code would be valid :

#include <iostream>
#include "MyFile.hpp" namespace Testing { typedef int Type; }

int main( int argc, char **argv )
{
Testing::Type i(0);
std::cout << "i = " << i << "\n";
return 0;
}

This code won't compile, and the compiler will complain there is an
extra token after the #include directive.

Yes. How does that go against what I've said?
Well you seem to be saying (mentioned above) that "Lines do not really
exist after the preprocessor is done with the source code" in which
case the code I posted with the namespace declaration just after the
#include directive should be valid and compile, but it doesn't.
>
All preprocessor directives
need to be on their own line. Even a macro that is _defined_ on
several lines still expands on only one line. For example the
following macro :

#define TEST( NAME ) \
class NAME \
{ \
public: \
NAME( ) { } \
}

Is defined on several lines

No, it isn't. The lines you see in the source code are actually
concatenated into one before the directive is preprocessed. So, when
you think you're defining it on more than one line, you don't.
Well that's what I ment. That even though the macro is defined on
several lines in the file, it will actually be considered as a single
code line broken down into several text lines.
by using the "\" character that means the
current line of code is extended on the next line of the file. If you
use this macro with a simple call like "TEST(Test);", you will
actually get the resulting formatting in your preprocessed source
file :

class Test { public: Test( ) { } };

The full macro will be expanded on one single text line. Due to this,
I need to find a way where I can get multiline macro _expansion_. And
I can't figure out how to do this. If you have any ideas ...

No macro can expand into more than one line. Think about it. When you
define a macro, it's a single line. So, no matter what tricks you try
to play, a macro expansion will never have line breaks in it.
That's exactly what I was looking for as an answer. Is it possible to
generate a macro with line breaks in it or not. Apparently not then.

Thanks

O.

Nov 23 '06 #6
casul wrote:
Victor Bazarov wrote:
>casul wrote:
>>Victor Bazarov wrote:
No. Lines do not really exist after the preprocessor is done with
the source code.

This is what can't be true since the compiler expects a line break
after a preprocessor directive.
The preprocessor is line oriented. It requires a line break after a
preprocessor directive. Once the preprocessor is done, the compiler only
cares about whitespace, not specifically line breaks.

Think of the preprocessor as what its name suggests: something you run
your source code through before you compile it. In fact, that's how it
started out, and that's pretty much how it's specified.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Nov 23 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by Florian | last post: by
9 posts views Thread by SerGioGio | last post: by
16 posts views Thread by Trying_Harder | last post: by
7 posts views Thread by Arthur J. O'Dwyer | last post: by
9 posts views Thread by ccwork | last post: by
7 posts views Thread by Erik Leunissen | last post: by
3 posts views Thread by John Devereux | last post: by
4 posts views Thread by nobrow | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.