«

Hi!
I have written some peace of code, but I wonder if it's legal for ansi-c
I have no problem to compiling it, but since I'm inexperience and the
output is not correct I have doubts. Thank you for help!

#include <stdio.h>
#include <stdlib.h>

#define __buff(s, c) s_c

int main(){

int i;
for(i=0;i<10;i++){
int __buff(*send,i);
}

for(i=0;i<10;i++){
__buff(send,i) = i;
}
for(i=0;i<10;i++){
printf("%d \n",__buff(send,i));
}

return 0;
}

The output is always 3...
My intentions is to deal with several int pointer with loops, since I'm
lazy to write all int's...
I want to make X number of int pointer

int *pointer_1
.....
int *pointer_X

allocate memory for all
pointer_1=malloc(sizeof( *pointer_1))
.....
pointer_X=malloc(sizeof( *pointer_X))
fill them with values
and do something

if this way not proper is there a "hack" for lazy programmer like me?

Thank you again!

L R

sorry... old code.. here is the "right version"

#include <stdio.h>
#include <stdlib.h>

#define __buff(s, c) s_c

int main(){

int i;
int __buff(*send, ZERO);
for(i=0;i<4;i++){
int __buff(*send,i);
}
for(i=0;i<4;i++){
__buff(send,i) = malloc(sizeof (__buff(*send,i)));
}

for(i=0;i<4;i++){
__buff(send,i) = i;
}
for(i=0;i<4;i++){
printf("%d \n",__buff(send,i));
}

return 0;
}

In article <464b4a8e$0$13493$>,
Carramba <> wrote:
>#include <stdio.h>
>#include <stdlib.h>
>
>#define __buff(s, c) s_c

That defines an object-like macro __buff() that takes two parameters,
but no matter what the parameters are, always emits the variable name
s_c . Literally, ess underscore cee, totally unrelated to the s
and c parameters given to the macro. The output behaviour you
observe can be deduced from this.

You cannot just join parameters together in the manner you were thinking;
it -is- possible to create new identifiers from macro parameters, but
it requires fancier preprocessor work, and the replacement is
always done at -compile- time, not at execution time.

I would suggest that what you want to do is use arrays, not
try to generate new variable names dynamically.

>int main(){
>
> int i;
> int __buff(*send, ZERO);
> for(i=0;i<4;i++){
> int __buff(*send,i);
> }
> for(i=0;i<4;i++){
> __buff(send,i) = malloc(sizeof (__buff(*send,i)));
> }
>
> for(i=0;i<4;i++){
> __buff(send,i) = i;
> }
> for(i=0;i<4;i++){
> printf("%d \n",__buff(send,i));
> }
>
> return 0;
>}
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

Walter Roberson skrev:
> In article <464b4a8e$0$13493$>,
> Carramba <> wrote:
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> #define __buff(s, c) s_c
>
> That defines an object-like macro __buff() that takes two parameters,
> but no matter what the parameters are, always emits the variable name
> s_c . Literally, ess underscore cee, totally unrelated to the s
> and c parameters given to the macro. The output behaviour you
> observe can be deduced from this.
>
> You cannot just join parameters together in the manner you were thinking;
I was afraid so
> it -is- possible to create new identifiers from macro parameters, but
> it requires fancier preprocessor work, and the replacement is
> always done at -compile- time, not at execution time.

could you by kind and suggest how to do it?
I would really like to learn some fancy c stuff is it ok that they
are created at compile time.

> I would suggest that what you want to do is use arrays, not
> try to generate new variable names dynamically.
>

Carramba <> writes:
> sorry... old code.. here is the "right version"
>
> #include <stdio.h>
> #include <stdlib.h>
>
> #define __buff(s, c) s_c

Identifiers starting with underscores are reserved to the
implementation. It's more complex than that, but you should avoid
using such identifiers them in your own code.

This macro ignores its arguments and expands to the identifier "s_c".
I doubt that that's what you intended. You might want to look into
the "##" operator.

You've managed to write code that compiles, but that doesn't do
anything resembling what you're trying to do.

> int main(){

Ok, but "int main(void)" is more explicit.

> int i;
> int __buff(*send, ZERO);

This simply expands to

int s_c;

> for(i=0;i<4;i++){
> int __buff(*send,i);

You declare another variable named "s_c" inside your loop, but you
don't use it.

> }
> for(i=0;i<4;i++){
> __buff(send,i) = malloc(sizeof (__buff(*send,i)));

This expands to
s_c = malloc(sizeof s_c);

Since s_c is an int, and malloc() returns a void* (and the compiler
knows it, since you have the correct "#include <stdlib.h>" directive),
this is illegal (actually a constraint violation; the compiler is
required to issue a diagnostic, but it's allowed to accept it).

More briefly, your compiler almost certainly warned you about a type
mismatch, but you ignored the warning. If your compiler *didn't* warn
you, crank up its warning levels until it does.

> }
>
> for(i=0;i<4;i++){
> __buff(send,i) = i;

s_c = i;

> }
> for(i=0;i<4;i++){
> printf("%d \n",__buff(send,i));

printf("%d \n",s_c);

> }
>
> return 0;
> }

I can really only guess what you're *trying* to do. Looking at a
snippet of your code:

#define __buff(s, c) s_c
/* ... */

for(i = 0; i < 4; i++) {
int __buff(*send,i);
}

I *think* you're trying to create the following declarations:

int *send_0;
int *send_1;
int *send_2;
int *send_3;

The preprocessor just doesn't work that way. If your __buff() macro
were defined correctly, using the ## operator, the line would expand
to

int *send_i;

Macro expansion does textual substitution. The *value* of i is not
available to the preprocessor; it doesn't exist until your program is
actually running.

And even if that worked, the scope of the variable declaration is just
the compound statement. A new variable is created on each iteration
of the loop, and destroyed on reaching the closing '}'.

Basically, you've badly mixed up compilation time and execution time.

You're trying to create a numbered sequence of variables.

That's called an array:

int *send[4];

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson skrev:
> Carramba <> writes:
>> sorry... old code.. here is the "right version"
> I can really only guess what you're *trying* to do. Looking at a
> snippet of your code:

I posted in my first help request.. but with wrong code. and then
reposting code I just forgot to repost question ... seem like a lot
mistakes today

My intentions is to deal with several int pointer with loops, since I'm
lazy to write all int's...
I want to make X number of int pointer

int *pointer_1
......
int *pointer_X

allocate memory for all
pointer_1=malloc(sizeof( *pointer_1))
......
pointer_X=malloc(sizeof( *pointer_X))
fill them with values
and do something

if this way not proper is there a "hack" for lazy programmer like me?

Thank you again!

>
> #define __buff(s, c) s_c
> /* ... */
>
> for(i = 0; i < 4; i++) {
> int __buff(*send,i);
> }
>
> I *think* you're trying to create the following declarations:
>
> int *send_0;
> int *send_1;
> int *send_2;
> int *send_3;

yes I was *hopping* to by able to achieve this

> The preprocessor just doesn't work that way. If your __buff() macro
> were defined correctly, using the ## operator, the line would expand
> to
>
> int *send_i;
>
> Macro expansion does textual substitution. The *value* of i is not
> available to the preprocessor; it doesn't exist until your program is
> actually running.
>
> And even if that worked, the scope of the variable declaration is just
> the compound statement. A new variable is created on each iteration
> of the loop, and destroyed on reaching the closing '}'.
>
> Basically, you've badly mixed up compilation time and execution time.

I understand that now...

> You're trying to create a numbered sequence of variables.
>
> That's called an array:
>
> int *send[4];

good idea! this is one possible solution!
I kind of enjoy using macros, and this is the result of *over using*
it... this is bit a shame that one can create preprocessor loop.. some
times would make life easier.

Thank you.

L R

(Walter Roberson) writes:
> In article <464b4a8e$0$13493$>,
> Carramba <> wrote:
>>#include <stdio.h>
>>#include <stdlib.h>
>>
>>#define __buff(s, c) s_c
>
> That defines an object-like macro __buff() that takes two parameters,
> but no matter what the parameters are, always emits the variable name
> s_c . Literally, ess underscore cee, totally unrelated to the s
> and c parameters given to the macro. The output behaviour you
> observe can be deduced from this.
[...]

Quibble: it's a function-like macro, not an object-like macro.
But yes, it ignores its arguments.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson skrev:
> (Walter Roberson) writes:
>> In article <464b4a8e$0$13493$>,
>> Carramba <> wrote:
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> #define __buff(s, c) s_c
>> That defines an object-like macro __buff() that takes two parameters,
>> but no matter what the parameters are, always emits the variable name
>> s_c . Literally, ess underscore cee, totally unrelated to the s
>> and c parameters given to the macro. The output behaviour you
>> observe can be deduced from this.
> [...]
>
> Quibble: it's a function-like macro, not an object-like macro.
> But yes, it ignores its arguments.
>
why is that
#define min(X, Y) ((X) < (Y) ? (X) : (Y))
calling min(1,2) will expend to ((1) < (2) ? (1) : (2))

but
#define __buff(s, c) s_c
calling __buff(1,2) will expand to s_c and not to 1_2 ?
is this because of '_' ?
would
#define __buff(s, c) sc
__buff(1,2) => make 12 ?

In article <464b5f4e$0$14219$>,
Carramba <> wrote:

>My intentions is to deal with several int pointer with loops, since I'm
>lazy to write all int's...
>I want to make X number of int pointer
>
>int *pointer_1
>.....
>int *pointer_X
>
>allocate memory for all
>pointer_1=malloc(sizeof( *pointer_1))
>.....
>pointer_X=malloc(sizeof( *pointer_X))
>fill them with values
>and do something

>if this way not proper is there a "hack" for lazy programmer like me?

No. The closest you could come would be a macro, perhaps called
Declare_and_malloc, that you would use like

Declare_and_malloc(pointer,1);
Declare_and_malloc(pointer,2);

and so on for each value, with the macro expanding to

int *pointer_1 = malloc(sizeof(*pointer_1));
int *pointer_2 = malloc(sizeof(*pointer_2));

and so on.

But there is no way to do something like:

#for J(1,10) Declare_and_malloc(pointer,J);

and have it generate the Declare_and_malloc(pointer,1);
and Declare_and_malloc(pointer,2); and so on up to 10.

Use arrays instead:

int *pointers[10];
for (j = 1; j < 10; j++)
pointers[j] = malloc(sizeof **pointers);

--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson

In article <464b6108$0$13493$>,
Carramba <> wrote:

>why is that
>#define min(X, Y) ((X) < (Y) ? (X) : (Y))
>calling min(1,2) will expend to ((1) < (2) ? (1) : (2))

>but
>#define __buff(s, c) s_c
>calling __buff(1,2) will expand to s_c and not to 1_2 ?
>is this because of '_' ?
>would
>#define __buff(s, c) sc
>__buff(1,2) => make 12 ?

No. Macros work on the basis of matching tokens, and _ is a valid
part of a token name. In

#define __buff(s,c) s_c

the preprocessor sees the single token s_c not the three tokens
s _ c .

It is possible to put tokens together, but the steps necessary are
obscure:


#define Join3b(a,b,c) a ## b ## c
#define Join3(a,b,c) Join3b(a,b,c)

then

Join3(s,_,c) would expand to s_c

It is -necessary- to use a two-step process to get this to work.
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell