fix code

[aarklon]

Hi all,

the following is a question which i found on a book,the reader is asked
to predict the output

#include<stdio.h>

#define SUM(F_NAME,DATA_TYPE,L)\
void F_NAME(DATA_TYPE x,DATA_TYPE y)\
{\
DATA_TYPE add;\
add = x + y;\
printf("The summation of "#DATA_TYPE""\
" values is %"#L"\n",add);\
}

void sum_int(int,int);
void sum_float(float,float);
int main(void)
{
sum_int(3,5);
sum_float(3.1,5.3);

return 0;
}

SUM(sum_int,int,d);
SUM(sum_float,float,f);

Output is given as

the summation of int values is 8
the summation of float values is 8.400000


But I am getting the error as # operator is not followed by a macro
argument name.
can anybody suggest ways to fix this code??

 

[Eric Sosman]

Hi all,

the following is a question which i found on a book,the reader is asked
to predict the output

#include<stdio.h>

#define SUM(F_NAME,DATA_TYPE,L)\
void F_NAME(DATA_TYPE x,DATA_TYPE y)\
{\
DATA_TYPE add;\
add = x + y;\
printf("The summation of "#DATA_TYPE""\
" values is %"#L"\n",add);\

Insert a space between the L and the following ".

The sequence L"\n" is a wide string literal that
will (eventually) produce a zero-terminated array of
wide characters. This sequence is recognized during
translation phase 3; macro processing doesn't happen
until phase 4. By that time, the L is long gone so
the macro processing encounters

string_literal # wide_string_literal

.... and the error results. Separating the L from what
follows means the combination is no longer recognized
as a wide string literal, so during macro expansion
you have

string_literal # L string_literal

.... as intended.

}

void sum_int(int,int);
void sum_float(float,float);
int main(void)
{
sum_int(3,5);
sum_float(3.1,5.3);

return 0;
}

SUM(sum_int,int,d);
SUM(sum_float,float,f);

Another improvement would be to get rid of the
semicolons in these two lines. After macro expansion
you'll have

void sum_int(...) {
...
}
;
void sum_float(...) {
...
}
;

 

[aarklon]

Can you explain what is meant by phase 4.
as far as i know the different phases of a compiler are

lexical analysis
syntax analysis
semantic analysis
intermediate code generation
code optimization
code generation

is it during intermediate code generation phase?

 

[Ben Pfaff]

Can you explain what is meant by phase 4.

The C standard divides translation into 8 phases. Phase 4 is
this:

4. Preprocessing directives are executed, macro invocations
are expanded, and _Pragma unary operator expressions are
executed. If a character sequence that matches the
syntax of a universal character name is produced by token
concatenation (6.10.3.3), the behavior is undefined. A
#include preprocessing directive causes the named header
or source file to be processed from phase 1 through phase
4, recursively. All preprocessing directives are then
deleted.

 

[Micah Cowan]

Hi all,

the following is a question which i found on a book,the reader is asked
to predict the output

#include<stdio.h>

#define SUM(F_NAME,DATA_TYPE,L)\
void F_NAME(DATA_TYPE x,DATA_TYPE y)\
{\
DATA_TYPE add;\
add = x + y;\
printf("The summation of "#DATA_TYPE""\
" values is %"#L"\n",add);\
}

void sum_int(int,int);
void sum_float(float,float);
int main(void)
{
sum_int(3,5);
sum_float(3.1,5.3);

return 0;
}

SUM(sum_int,int,d);
SUM(sum_float,float,f);

Output is given as

the summation of int values is 8
the summation of float values is 8.400000


But I am getting the error as # operator is not followed by a macro
argument name.
can anybody suggest ways to fix this code??

Yes.

1. Remove the final semicolons from your invocations of SUM(). Does
the original have these?
2. Use a space between the L and the " following it, or use a
different letter.

Your problem is that the sequence {L"} is the start of a /wide string
literal/. The L will never be tokenized into an identifier, and
therefore isn't recognized as the macro parameter.

HTH,
-Micah

 

[Keith Thompson]

Insert a space between the L and the following ".

The sequence L"\n" is a wide string literal that
will (eventually) produce a zero-terminated array of
wide characters. This sequence is recognized during
translation phase 3; macro processing doesn't happen
until phase 4. By that time, the L is long gone so
the macro processing encounters

string_literal # wide_string_literal

... and the error results. Separating the L from what
follows means the combination is no longer recognized
as a wide string literal, so during macro expansion
you have

string_literal # L string_literal

... as intended.

Or use an identifier other than L.