Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15691 > unrolled thread

Macro for pthread_create()

Back to article view | Back to comp.lang.c

Contents

  Macro for pthread_create() daniele@father.nostromo.wy (daniele.g) - 2012-01-10 19:21 +0100
    Re: Macro for pthread_create() jt@toerring.de (Jens Thoms Toerring) - 2012-01-10 19:02 +0000
      Re: Macro for pthread_create() jt@toerring.de (Jens Thoms Toerring) - 2012-01-10 20:18 +0000
        Re: Macro for pthread_create() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-10 20:29 +0000
          Re: Macro for pthread_create() jt@toerring.de (Jens Thoms Toerring) - 2012-01-10 21:03 +0000
    Re: Macro for pthread_create() James Kuyper <jameskuyper@verizon.net> - 2012-01-10 14:14 -0500
      Re: Macro for pthread_create() Seebs <usenet-nospam@seebs.net> - 2012-01-10 20:44 +0000
      Re: Macro for pthread_create() Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2012-01-13 07:18 -0800
    Re: Macro for pthread_create() Seebs <usenet-nospam@seebs.net> - 2012-01-10 19:15 +0000
      Re: Macro for pthread_create() daniele@mother.nostromo.wy (daniele.g) - 2012-01-10 23:01 +0100
        Re: Macro for pthread_create() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-10 22:23 +0000
          Re: Macro for pthread_create() Keith Thompson <kst-u@mib.org> - 2012-01-10 15:23 -0800
        Re: Macro for pthread_create() jt@toerring.de (Jens Thoms Toerring) - 2012-01-10 22:27 +0000
          Re: Macro for pthread_create() Keith Thompson <kst-u@mib.org> - 2012-01-10 15:25 -0800
        Re: Macro for pthread_create() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-10 17:31 -0500
          Re: Macro for pthread_create() daniele@mother.nostromo.wy (daniele.g) - 2012-01-11 00:04 +0100
            Re: Macro for pthread_create() James Kuyper <jameskuyper@verizon.net> - 2012-01-10 18:17 -0500
            Re: Macro for pthread_create() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-10 18:29 -0500
        Re: Macro for pthread_create() Ian Collins <ian-news@hotmail.com> - 2012-01-11 11:54 +1300
          Re: Macro for pthread_create() daniele@father.nostromo.wy (daniele.g) - 2012-01-11 10:09 +0100
            Re: Macro for pthread_create() Ian Collins <ian-news@hotmail.com> - 2012-01-11 22:20 +1300
            Re: Macro for pthread_create() James Kuyper <jameskuyper@verizon.net> - 2012-01-11 11:26 -0500
              Re: Macro for pthread_create() daniele@father.nostromo.wy (daniele.g) - 2012-01-12 12:07 +0100
                Re: Macro for pthread_create() James Kuyper <jameskuyper@verizon.net> - 2012-01-12 09:19 -0500
                  Re: Macro for pthread_create() Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-12 20:34 -0500
              Re: Macro for pthread_create() daniele@father.nostromo.wy (daniele.g) - 2012-01-12 11:52 +0100
            Re: Macro for pthread_create() Seebs <usenet-nospam@seebs.net> - 2012-01-11 18:46 +0000
              Re: Macro for pthread_create() blp@cs.stanford.edu (Ben Pfaff) - 2012-01-11 11:12 -0800

Page 1 of 2  [1] 2  Next page →

#15691 — Macro for pthread_create()

For code portability I need to write a macro THREAD(func, param) which
must be resolved into pthread_create(&func_id, NULL, func, (void *)
param)

I wrote this:

#define THREAD(func,parm) (pthread_create(&func, NULL, func, (void *)
 parm))

But it doesn't work. Any clue?

Thanks in advance.
-- 
               Volare e' utile, atterrare e' necessario.
               		-- Eros Drusiani

[toc] | [next] | [standalone]

#15692

daniele.g <daniele@father.nostromo.wy> wrote:
> For code portability I need to write a macro THREAD(func, param) which
> must be resolved into pthread_create(&func_id, NULL, func, (void *)
> param)

> I wrote this:

> #define THREAD(func,parm) (pthread_create(&func, NULL, func, (void *)
>  parm))

> But it doesn't work. Any clue?

pthread_create() takes (at least in the POSIX version) a
pointer to a pthred_t variable (that can't be NULL and must
be an address the function can write to) as its first ar-
gument, not a function (and also not a pointer to the
pointer to the function to be called). So this macro
can't "work". And what has using such a macro to do with
"portability"?
                             Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#15699

Jens Thoms Toerring <jt@toerring.de> wrote:
> daniele.g <daniele@father.nostromo.wy> wrote:
> > For code portability I need to write a macro THREAD(func, param) which
> > must be resolved into pthread_create(&func_id, NULL, func, (void *)
> > param)

> > I wrote this:

> > #define THREAD(func,parm) (pthread_create(&func, NULL, func, (void *)
> >  parm))

> > But it doesn't work. Any clue?

> pthread_create() takes (at least in the POSIX version) a
> pointer to a pthred_t variable (that can't be NULL and must
> be an address the function can write to) as its first ar-
> gument, not a function (and also not a pointer to the
> pointer to the function to be called). So this macro
> can't "work". And what has using such a macro to do with
> "portability"?

Sorry, I overlooked that it's 'func_id' in what you want the
macro to expand to. With that I can only guess at your inten-
tions: do you always have a variable for the thread ID (i.e.
the first argument) that has the same name as the function,
but with '_id' appended to it? In that case you could try

#define THREAD(func,parm) pthread_create(&#func_id, NULL, func, (void *) parm)

(assuming that your compiler understands the concatenation
bit '##', which is, as far as I remember from C99).

With this

THREAD( a, b )

should expand to

pthread_create(&a_id, NULL, a, (void *) b)

                              Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#15701

jt@toerring.de (Jens Thoms Toerring) writes:
<snip>
>> daniele.g <daniele@father.nostromo.wy> wrote:
>> > For code portability I need to write a macro THREAD(func, param) which
>> > must be resolved into pthread_create(&func_id, NULL, func, (void *)
>> > param)
>
>> > I wrote this:
>
>> > #define THREAD(func,parm) (pthread_create(&func, NULL, func, (void *)
>> >  parm))
>
>> > But it doesn't work. Any clue?
<snip>
> Sorry, I overlooked that it's 'func_id' in what you want the
> macro to expand to. With that I can only guess at your inten-
> tions: do you always have a variable for the thread ID (i.e.
> the first argument) that has the same name as the function,
> but with '_id' appended to it? In that case you could try
>
> #define THREAD(func,parm) pthread_create(&#func_id, NULL, func, (void *) parm)
>
> (assuming that your compiler understands the concatenation
> bit '##', which is, as far as I remember from C99).

It's as old as C89 ("ANSI C") and you've got a typo in the macro.  You
presumable wanted to write:

  #define THREAD(func,parm) \
          pthread_create(&func ## _id, NULL, func, (void *)parm)

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#15704

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> jt@toerring.de (Jens Thoms Toerring) writes:
> <snip>
> >> daniele.g <daniele@father.nostromo.wy> wrote:
> >> > For code portability I need to write a macro THREAD(func, param) which
> >> > must be resolved into pthread_create(&func_id, NULL, func, (void *)
> >> > param)
> >
> >> > I wrote this:
> >
> >> > #define THREAD(func,parm) (pthread_create(&func, NULL, func, (void *)
> >> >  parm))
> >
> >> > But it doesn't work. Any clue?
> <snip>
> > Sorry, I overlooked that it's 'func_id' in what you want the
> > macro to expand to. With that I can only guess at your inten-
> > tions: do you always have a variable for the thread ID (i.e.
> > the first argument) that has the same name as the function,
> > but with '_id' appended to it? In that case you could try
> >
> > #define THREAD(func,parm) pthread_create(&#func_id, NULL, func, (void *) parm)
> >
> > (assuming that your compiler understands the concatenation
> > bit '##', which is, as far as I remember from C99).

> It's as old as C89 ("ANSI C")

Thanks, had somehow associated it with C99.

> and you've got a typo in the macro.  You presumable wanted
> to write:
>   #define THREAD(func,parm) \
>           pthread_create(&func ## _id, NULL, func, (void *)parm)

Uups, yes, of course! I thought I had copy-and-paste'd it from
my test program but I seem to have screwed that up:-(

                         Best regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#15693

On 01/10/2012 01:21 PM, daniele.g wrote:
> For code portability I need to write a macro THREAD(func, param) which
> must be resolved into pthread_create(&func_id, NULL, func, (void *)
> param)

Where does func_id come from?

> I wrote this:
> 
> #define THREAD(func,parm) (pthread_create(&func, NULL, func, (void *)
>  parm))

There's no func_id in the expansion of that macro.

pthread_create() isn't part of the C standard library. As far as this
newsgroup is concerned, it could be anything, and the correct answer to
your question depends upon precisely how pthead_create is declared.
comp.programming.unix would be a more appropriate forum for such a question.

> But it doesn't work. Any clue?

What exactly does "doesn't work" mean? Before you post to
comp.programming.unix, create a simplified version of your program, as
small as possible, which demonstrates the problem. Do a test build and
run to make sure it actually demonstrates the problem. Give them the
exact text of the program that failed. Tell them precisely which
compiler you're using, the command line options you used, and precisely
what error messages, if any, you got when you compiled and linked it. If
"doesn't work" refers to something that happens when you run the
program, after successfully compiling and linking it, then tell them
precisely what input you gave the program, and what precisely the output
was that convinced you that "it doesn't work".

[toc] | [prev] | [next] | [standalone]

#15703

On 2012-01-10, James Kuyper <jameskuyper@verizon.net> wrote:
> On 01/10/2012 01:21 PM, daniele.g wrote:
>> For code portability I need to write a macro THREAD(func, param) which
>> must be resolved into pthread_create(&func_id, NULL, func, (void *)
>> param)

> Where does func_id come from?

My guess is that the intent is that if you call THREAD(foo, bar), the OP
wants
	pthread_create(&foo_id, NULL, foo, (void *) bar);

> pthread_create() isn't part of the C standard library. As far as this
> newsgroup is concerned, it could be anything, and the correct answer to
> your question depends upon precisely how pthead_create is declared.

I am not sure of that -- so far as I can tell, this one's purely a textual
representation question about the preprocessing phases.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#15799

On Jan 10, 1:14 pm, James Kuyper <jameskuy...@verizon.net> wrote:
(...)
> pthread_create() isn't part of the C standard library. As far as this
> newsgroup is concerned, it could be anything, and the correct answer to
> your question depends upon precisely how pthead_create is declared.
> comp.programming.unix would be a more appropriate forum for such a question.
>

The newsgroup you meant is most likely comp.unix.programmer

- Anand

[toc] | [prev] | [next] | [standalone]

#15694

On 2012-01-10, daniele.g <daniele@father.nostromo.wy> wrote:
> For code portability I need to write a macro THREAD(func, param) which
> must be resolved into pthread_create(&func_id, NULL, func, (void *)
> param)

> I wrote this:

> #define THREAD(func,parm) (pthread_create(&func, NULL, func, (void *)
>  parm))

> But it doesn't work. Any clue?

Nope.

Suggestion:  Maybe you should expand a little on "doesn't work".  You
might have meant:
	I get a compiler error.
	My program crashes.
	I looked at preprocessed output and it wasn't what I expected.

The obvious thing that leaps out at me is that you say you want
	pthread_create(&func_id, NULL, func, (void *) param)
but you wrote
	pthread_create(&func, NULL, func, (void *) param)

which makes me wonder whether you actually wanted the _id, and if so,
why you omitted it.  You may be looking for the "token pasting" operator,
##.  See the comp.lang.c FAQ for more info on that.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#15708

Seebs <usenet-nospam@seebs.net> writes:

> The obvious thing that leaps out at me is that you say you want
> 	pthread_create(&func_id, NULL, func, (void *) param)
> but you wrote
> 	pthread_create(&func, NULL, func, (void *) param)
>
> Which makes me wonder whether you actually wanted the _id, and if so,
> why you omitted it.  You may be looking for the "token pasting" operator,
> ##.  See the comp.lang.c FAQ for more info on that.

Yur're right, I wrote wrong the macro expansion.
What I want is that when I compile this source under linux the macro is
translated into the pthread_create(...) function, knowing that the macro
has only two parameters. My problem is that I don't know how to create
dinamically a func_id to be inserted into the macro definition.

[toc] | [prev] | [next] | [standalone]

#15709

daniele@mother.nostromo.wy (daniele.g) writes:

> Seebs <usenet-nospam@seebs.net> writes:
>
>> The obvious thing that leaps out at me is that you say you want
>> 	pthread_create(&func_id, NULL, func, (void *) param)
>> but you wrote
>> 	pthread_create(&func, NULL, func, (void *) param)
>>
>> Which makes me wonder whether you actually wanted the _id, and if so,
>> why you omitted it.  You may be looking for the "token pasting" operator,
>> ##.  See the comp.lang.c FAQ for more info on that.
>
> Yur're right, I wrote wrong the macro expansion.
> What I want is that when I compile this source under linux the macro is
> translated into the pthread_create(...) function, knowing that the macro
> has only two parameters. My problem is that I don't know how to create
> dinamically a func_id to be inserted into the macro definition.

If there is a fixed, textual, relationship between "func" and "func_id"
(i.e. the first parameter is always the third but with _id added to the
name) then the token pasting macro already posted (it uses "func ## _id"
in the body) will do the trick.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#15717

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> daniele@mother.nostromo.wy (daniele.g) writes:
>> Seebs <usenet-nospam@seebs.net> writes:
>>> The obvious thing that leaps out at me is that you say you want
>>> 	pthread_create(&func_id, NULL, func, (void *) param)
>>> but you wrote
>>> 	pthread_create(&func, NULL, func, (void *) param)
>>>
>>> Which makes me wonder whether you actually wanted the _id, and if so,
>>> why you omitted it.  You may be looking for the "token pasting" operator,
>>> ##.  See the comp.lang.c FAQ for more info on that.
>>
>> Yur're right, I wrote wrong the macro expansion.
>> What I want is that when I compile this source under linux the macro is
>> translated into the pthread_create(...) function, knowing that the macro
>> has only two parameters. My problem is that I don't know how to create
>> dinamically a func_id to be inserted into the macro definition.
>
> If there is a fixed, textual, relationship between "func" and "func_id"
> (i.e. the first parameter is always the third but with _id added to the
> name) then the token pasting macro already posted (it uses "func ## _id"
> in the body) will do the trick.

Of course you have to declare "func" and "func_id", or "foo" and
"foo_id", or ....

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15710

daniele.g <daniele@mother.nostromo.wy> wrote:
> Seebs <usenet-nospam@seebs.net> writes:

> > The obvious thing that leaps out at me is that you say you want
> >       pthread_create(&func_id, NULL, func, (void *) param)
> > but you wrote
> >       pthread_create(&func, NULL, func, (void *) param)
> >
> > Which makes me wonder whether you actually wanted the _id, and if so,
> > why you omitted it.  You may be looking for the "token pasting" operator,
> > ##.  See the comp.lang.c FAQ for more info on that.

> Yur're right, I wrote wrong the macro expansion.
> What I want is that when I compile this source under linux the macro is
> translated into the pthread_create(...) function, knowing that the macro
> has only two parameters. My problem is that I don't know how to create
> dinamically a func_id to be inserted into the macro definition.

If you never need to use the thread ID (i.e. what's returned via
the first argument) perhaps this is what you're looking for:

#define THREAD( func, parm ) \
    { pthread_t thread_id; \
      pthread_create( &thread_id, NULL, func, ( void * ) ( parm ) ); }

The curly braces are just there for restricting the life-time
of the 'thread_id' variable (it "goes out of scope" at the
closing '}').

But if you need the thread ID later on then I guess you will
have to explain in more detail what this is all about (or what
you exactly mean with "dynamically create a func_id").

                              Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#15718

jt@toerring.de (Jens Thoms Toerring) writes:
[...]
> If you never need to use the thread ID (i.e. what's returned via
> the first argument) perhaps this is what you're looking for:
>
> #define THREAD( func, parm ) \
>     { pthread_t thread_id; \
>       pthread_create( &thread_id, NULL, func, ( void * ) ( parm ) ); }
>
> The curly braces are just there for restricting the life-time
> of the 'thread_id' variable (it "goes out of scope" at the
> closing '}').
[...]

A macro that expands to a statement should use the "do { ... } while
(0)" idiom:

#define THREAD( func, parm ) \
    do { \
        pthread_t thread_id; \
        pthread_create( &thread_id, NULL, (func), ( void * ) ( parm ) ); \
    while (0)


-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15711

On 1/10/2012 5:01 PM, daniele.g wrote:
>[...]
> Yur're right, I wrote wrong the macro expansion.
> What I want is that when I compile this source under linux the macro is
> translated into the pthread_create(...) function, knowing that the macro
> has only two parameters. My problem is that I don't know how to create
> dinamically a func_id to be inserted into the macro definition.

     You'd need to generate both the declaration and the use:

	#define THREAD(func,parm) { \
	    pthread_t func ## _id; \
	    pthread_create(&func ## _id, NULL, func, (void*)(parm)); \
	}

     Under C99 or later, which allow variable declarations to be
intermixed with executable statements, you can get rid of the
curly braces.

<off-topic>

     ... but it's a dumb idea.  The pthread_t variable is your only
"handle" for the new thread, something you'll need if you later
want to await the thread's completion or send it a signal or anything
of that kind.  It's a vital part of the machinery, not something that
should be swept under the rug.

     Also, the presence of the declaration means that the macro
expansion is no longer an expression (it's a declaration plus an
expression-statement, possibly wrapped in a compound statement).
Since it's not an expression it has no value, meaning that the value
returned by pthread_create() is simply lost: You have no way of
knowing whether thread creation succeeded or failed, and no clue
as to the cause of a failure.

     Why do you think such a macro would be desirable?

</off-topic>

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15714

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> <Off-topic>
>
>     ... But it's a dumb idea.  The pthread_t variable is your only
> "handle" for the new thread, something you'll need if you later
> want to await the thread's completion or send it a signal or anything
> of that kind.  It's a vital part of the machinery, not something that
> should be swept under the rug.

I do agree.

>     Also, the presence of the declaration means that the macro
> expansion is no longer an expression (it's a declaration plus an
> expression-statement, possibly wrapped in a compound statement).
> Since it's not an expression it has no value, meaning that the value
> returned by pthread_create() is simply lost: You have no way of
> knowing whether thread creation succeeded or failed, and no clue
> as to the cause of a failure.
>
>     Why do you think such a macro would be desirable?

That macro would be desiderable because I need to make it run under
Linux and another OS for embedded systems which doesn't support
pthreads. For now I want it run under Linux for testing. Maybe the macro
is badly defined, and need to be modified.

[toc] | [prev] | [next] | [standalone]

#15716

On 01/10/2012 06:04 PM, daniele.g wrote:
> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> 
>> <Off-topic>
>>
>>     ... But it's a dumb idea.  The pthread_t variable is your only
>> "handle" for the new thread, something you'll need if you later
>> want to await the thread's completion or send it a signal or anything
>> of that kind.  It's a vital part of the machinery, not something that
>> should be swept under the rug.
> 
> I do agree.
> 
>>     Also, the presence of the declaration means that the macro
>> expansion is no longer an expression (it's a declaration plus an
>> expression-statement, possibly wrapped in a compound statement).
>> Since it's not an expression it has no value, meaning that the value
>> returned by pthread_create() is simply lost: You have no way of
>> knowing whether thread creation succeeded or failed, and no clue
>> as to the cause of a failure.
>>
>>     Why do you think such a macro would be desirable?
> 
> That macro would be desiderable because I need to make it run under
> Linux and another OS for embedded systems which doesn't support
> pthreads. For now I want it run under Linux for testing. Maybe the macro
> is badly defined, and need to be modified.

To understand why a macro is needed, it would help to know how you were
thinking of defining the macro for the other OS. It's possible that
providing two different function definitions, depending upon the OS
(possibly with two different declarations) might be clearer and safer
than providing two different macro definitions.

The macro as you've presented it has one clear advantage: it enforces a
naming convention connecting the function and and the thread id.
However, it might be better to maintain that connection by other means,
such as a structure containing both the thread id and a pointer to the
relevant function.

[toc] | [prev] | [next] | [standalone]

#15719

On 1/10/2012 6:04 PM, daniele.g wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
>> [...]
>>      Why do you think such a macro would be desirable?
>
> That macro would be desiderable because I need to make it run under
> Linux and another OS for embedded systems which doesn't support
> pthreads. For now I want it run under Linux for testing. Maybe the macro
> is badly defined, and need to be modified.

     It seems likely that simulating threads on an unthreaded
system (or even just doing without them) will involve more changes
to your program than you can easily encapsulate in a macro.  The
purely-C question of how to write the macro has been answered, but
the beyond-C issues of managing the threading aren't really this
forum's business[*].  Try comp.programming.threads.

     [*] The latest "C11" edition of the C Standard defines threading
support for C, so at least some threading questions will eventually
become topical here.  But C11 is so fresh from the womb that its eyes
aren't yet open, so it'll be a while before you can find C11-conforming
implementations or get reliable advice on using them.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15713

On 01/11/12 11:01 AM, daniele.g wrote:
> Seebs<usenet-nospam@seebs.net>  writes:
>
>> The obvious thing that leaps out at me is that you say you want
>> 	pthread_create(&func_id, NULL, func, (void *) param)
>> but you wrote
>> 	pthread_create(&func, NULL, func, (void *) param)
>>
>> Which makes me wonder whether you actually wanted the _id, and if so,
>> why you omitted it.  You may be looking for the "token pasting" operator,
>> ##.  See the comp.lang.c FAQ for more info on that.
>
> Yur're right, I wrote wrong the macro expansion.
> What I want is that when I compile this source under linux the macro is
> translated into the pthread_create(...) function, knowing that the macro
> has only two parameters. My problem is that I don't know how to create
> dinamically a func_id to be inserted into the macro definition.

Why use a macro?  It would be easier and clearer to use a function.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#15734

Ian Collins <ian-news@hotmail.com> writes:

> On 01/11/12 11:01 AM, daniele.g wrote:
>> Seebs<usenet-nospam@seebs.net>  writes:
>>
>>> The obvious thing that leaps out at me is that you say you want
>>> 	pthread_create(&func_id, NULL, func, (void *) param)
>>> but you wrote
>>> 	pthread_create(&func, NULL, func, (void *) param)
>>>
>>> Which makes me wonder whether you actually wanted the _id, and if so,
>>> why you omitted it.  You may be looking for the "token pasting" operator,
>>> ##.  See the comp.lang.c FAQ for more info on that.
>>
>> Yur're right, I wrote wrong the macro expansion.
>> What I want is that when I compile this source under linux the macro is
>> translated into the pthread_create(...) function, knowing that the macro
>> has only two parameters. My problem is that I don't know how to create
>> dinamically a func_id to be inserted into the macro definition.
>
> Why use a macro?  It would be easier and clearer to use a function.

How? I mean: in Linux I can simply write:

#include <pthread.h>
...
pthread_create( ... );

in OS20 I can't since it doesn't have them, so my idea is to make a
conditional compiling using a macro. Am I right?
-- 
                  Vado pazzo per i piani ben riusciti!
                  		-- John `Hunnibal' Smith, "A-Team"

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web