is this legal declaration/not correct output

Discussion in 'C Programming' started by Carramba, May 16, 2007.

  1. Carramba

    Carramba Guest

    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
    Carramba, May 16, 2007
    #1
    1. Advertising

  2. Carramba

    Carramba Guest

    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;
    }
    Carramba, May 16, 2007
    #2
    1. Advertising

  3. 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, May 16, 2007
    #3
  4. Carramba

    Carramba Guest

    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, May 16, 2007
    #4
  5. 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) <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, May 16, 2007
    #5
  6. Carramba

    Carramba Guest

    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
    Carramba, May 16, 2007
    #6
  7. -cnrc.gc.ca (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) <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, May 16, 2007
    #7
  8. Carramba

    Carramba Guest

    Keith Thompson skrev:
    > -cnrc.gc.ca (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 ?
    Carramba, May 16, 2007
    #8
  9. 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
    Walter Roberson, May 16, 2007
    #9
  10. 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
    Walter Roberson, May 16, 2007
    #10
  11. Carramba <> writes:
    [...]
    > 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 ?


    Let's get rid of the leading underscores:

    #define buff(s, c) s_c

    buff(1, 2) /* expands to s_c; the arguments are ignored */

    "s_c" is simply a single identifier. In an identifier, the '_'
    character acts very much like a letter (except for the fact that
    leading underscores can cause problems). s_c is a token by itself;
    it's *not* composed of separate tokens s and c separated by an
    underscore.

    Similarly:

    #define buff(s, c) sxc
    buff(1, 2) /* expands to sxc; the arguments are ignored */

    It is possible to paste tokens together in macro expansions, using the
    "##" operator. Any decent C textbook should explain this (I recommend
    Kernighan & Ritchie's _The C Programming Language_, known to its
    friends as K&R2). I'm not going to go into detail here because (a)
    you're likely to learn more if you do the research yourself (and I
    might get something wrong), and (b) it's not a good solution to your
    problem.

    --
    Keith Thompson (The_Other_Keith) <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, May 16, 2007
    #11
  12. Carramba

    Carramba Guest

    Carramba skrev:

    >
    > L R


    thank you all!
    Carramba, May 17, 2007
    #12
  13. On Wed, 16 May 2007 22:46:47 -0400, CBFalconer <>
    wrote:
    <snip: several good points>
    > > int i;
    > > for(i=0;i<10;i++){

    >
    > Separate things with spaces.
    >
    > > int __buff(*send,i);

    >

    (Which actually expands to int s_c;)

    > In general (especially C90) you can't specify storage after code.


    In C90 (really C<99) you can't have declarations after statements
    _within a block_. Since the body of this for statement is a compound
    statement == block, a declaration at its beginning is perfectly legal.
    But it is effective only within that block, and does not declare a
    variable usable _after_ this for loop ends, much less a series of such
    variables, as the OP wanted.

    > Macros just do text replacement. This is meaningless, with s_c
    > undefined.
    >

    Just text replacement yes, but the result int s_c; is a perfectly
    valid though useless declaration that locally defines s_c.

    > > }

    <snip rest>
    - formerly david.thompson1 || achar(64) || worldnet.att.net
    David Thompson, Jul 1, 2007
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. SenderX
    Replies:
    7
    Views:
    370
    Greg Comeau
    Aug 29, 2003
  2. Joost Kraaijeveld

    Is this forward declaration legal C++?

    Joost Kraaijeveld, Jun 28, 2004, in forum: C++
    Replies:
    7
    Views:
    457
    Sharad Kala
    Jun 29, 2004
  3. Replies:
    3
    Views:
    446
  4. Replies:
    2
    Views:
    356
  5. Universe
    Replies:
    6
    Views:
    307
    Universe
    Mar 26, 2011
Loading...

Share This Page