«

On 01/11/2012 04:09 AM, daniele.g wrote:
> Ian Collins <ian-> writes:
....
>> 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?

Not necessarily. In the places where your code would call
pthread_create() on linux, what do you want your code to do on OS20?

On 2012-01-11, daniele.g <> wrote:
> 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?

No.

A macro is a good choice if you can write a single thing which expands to
something suitable on each of your target systems. If you can't, you should
write a function for each system to provide the functionality.

The problem is that the conditional compilation doesn't do anything to solve
your actual *problem*, which is that if you don't spawn threads, the code
won't work. You need to rethink that part of the design...

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-
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.

Seebs <usenet-> writes:

> On 2012-01-11, daniele.g <> wrote:
>> 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?
>
> A macro is a good choice if you can write a single thing which expands to
> something suitable on each of your target systems. If you can't, you should
> write a function for each system to provide the functionality.

I would say, instead, that a function (possibly marked "inline")
is a good choice in any case, and that a macro is a second choice
if a function cannot work.
--
"Large amounts of money tend to quench any scruples I might be having."
-- Stephan Wilms

James Kuyper <> writes:

> On 01/11/2012 04:09 AM, daniele.g wrote:
>> Ian Collins <ian-> writes:
> ...
>>> 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?
>
> Not necessarily. In the places where your code would call
> pthread_create() on linux, what do you want your code to do on OS20?

It has a os20_task_create() function, which I really don't yet know how
it works, I will have to manage it in a second time.
--
I ragazzi dell'85 sono strani. Ne ho visto uno rubare la droga per
comprarsi un'autoradio.
-- Gino & Michele

James Kuyper <> writes:

> On 01/11/2012 04:09 AM, daniele.g wrote:
>> Ian Collins <ian-> writes:
> ...
>>> 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?
>
> Not necessarily. In the places where your code would call
> pthread_create() on linux, what do you want your code to do on OS20?

task_create(), this is its syntax:

extern task_t *task_create(
task_function_t proc_func, // pointer to the task's entry point.
task_param_t proc_param, // the parameter which will be passed into proc_func.
const size_t stack_size, // required stack size for the task, in bytes.
const int priority, // task's scheduling priority.
const char *name, // the name of the task.
task_flags_t flags // start status of the task.
);


--
Ci sono poche donne oneste che non siano stanche del loro mestiere.
-- La Rochefoucauld, "Massime"

On 01/12/2012 06:07 AM, daniele.g wrote:
> James Kuyper <> writes:
>
>> On 01/11/2012 04:09 AM, daniele.g wrote:
>>> Ian Collins <ian-> writes:
>> ...
>>>> 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?
>>
>> Not necessarily. In the places where your code would call
>> pthread_create() on linux, what do you want your code to do on OS20?
>
> task_create(), this is its syntax:
>
> extern task_t *task_create(
> task_function_t proc_func, // pointer to the task's entry point.
> task_param_t proc_param, // the parameter which will be passed into proc_func.
> const size_t stack_size, // required stack size for the task, in bytes.
> const int priority, // task's scheduling priority.
> const char *name, // the name of the task.
> task_flags_t flags // start status of the task.
> );

That's a fairly complicated interface; I can't imagine what your macro
would look like, but I think it would be a nightmare, as a macro.

You're basically suggesting that a macro be defined as follows:

#if SOMETHING

#include <pthread.h>
#define THREAD(func,parm) \
pthread_create(&func ## _id, NULL, func, (void *)parm)
#else

#include "something.h"
#define THREAD(func, parm) \
thread_create(????)

#endif

Note that the macro has to take the same number of parameters in both
definitions. You might need to give it more parameters, so it can pass
more on to thread_create() - but then you need to decide what
pthread_create() should do, if anything, with those additional parameters.

An easier approach would be to design your own function that wraps
whichever of the two functions is appropriate, with an interface that
allows it to make proper use of either one:

In my_thread.h:
#if SOMETHING
#include <pthread.h>
struct my_thread_info
{
// information you'll need to keep track of while using pthreads
};
#else
#include "something.h"
struct my_thread_info
{
// information you'll need while using other library
};
#endif
your_return_type my_thread_create(
struct thread_info* /* other parameters */);

in my_thread.c:

#include "my_thread.h"

my_return_type my_thread_create(
struct my_thread_info* info /*, other parameters */
)
{
#if SOMETHING
// Setup for call
pthread_create(/* arguments for call */);
// After call cleanup
#else
// Setup for call
thread_create(/* Arguments for call */);
// After call cleanup
#endif
}

You'll need a lot of flexibility to make two different threading systems
look the same, and using a function gives you a lot more flexibility
than a macro - part of the reason is the "Setup" and "After" sections
shown above.
--
James Kuyper

On 1/12/2012 9:19 AM, James Kuyper wrote:
> On 01/12/2012 06:07 AM, daniele.g wrote:
>> James Kuyper<> writes:
>>
>>> On 01/11/2012 04:09 AM, daniele.g wrote:
>>>> Ian Collins<ian-> writes:
>>> ...
>>>>> 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?
>>>
>>> Not necessarily. In the places where your code would call
>>> pthread_create() on linux, what do you want your code to do on OS20?
>>
>> task_create(), this is its syntax:
>>
>> extern task_t *task_create(
>> task_function_t proc_func, // pointer to the task's entry point.
>> task_param_t proc_param, // the parameter which will be passed into proc_func.
>> const size_t stack_size, // required stack size for the task, in bytes.
>> const int priority, // task's scheduling priority.
>> const char *name, // the name of the task.
>> task_flags_t flags // start status of the task.
>> );
>
> That's a fairly complicated interface; I can't imagine what your macro
> would look like, but I think it would be a nightmare, as a macro.
>
> You're basically suggesting that a macro be defined as follows:
>
> #if SOMETHING
>
> #include<pthread.h>
> #define THREAD(func,parm) \
> pthread_create(&func ## _id, NULL, func, (void *)parm)
> #else
>
> #include "something.h"
> #define THREAD(func, parm) \
> thread_create(????)
>
> #endif
>
> Note that the macro has to take the same number of parameters in both
> definitions. You might need to give it more parameters, so it can pass
> more on to thread_create() - but then you need to decide what
> pthread_create() should do, if anything, with those additional parameters.
>
> An easier approach would be to design your own function that wraps
> whichever of the two functions is appropriate, with an interface that
> allows it to make proper use of either one:
>
> In my_thread.h:
> #if SOMETHING
> #include<pthread.h>
> struct my_thread_info
> {
> // information you'll need to keep track of while using pthreads
> };
> #else
> #include "something.h"
> struct my_thread_info
> {
> // information you'll need while using other library
> };
> #endif
> your_return_type my_thread_create(
> struct thread_info* /* other parameters */);
>
> in my_thread.c:
>
> #include "my_thread.h"
>
> my_return_type my_thread_create(
> struct my_thread_info* info /*, other parameters */
> )
> {
> #if SOMETHING
> // Setup for call
> pthread_create(/* arguments for call */);
> // After call cleanup
> #else
> // Setup for call
> thread_create(/* Arguments for call */);
> // After call cleanup
> #endif
> }
>
> You'll need a lot of flexibility to make two different threading systems
> look the same, and using a function gives you a lot more flexibility
> than a macro - part of the reason is the "Setup" and "After" sections
> shown above.

I'll second James' recommendation: Differences in threading
schemes are almost certainly too drastic to hide inside a macro,
or even a set of macros. You'll need the full power of the C
language, not just a macro's power of textual substitution.

--
Eric Sosman
d

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