two C "style" questions

[sandeep]

Hello friends

Two questions for you...

1| Is it considered best practise to use the full C names for Composite
Types (ie long int, short int, unsinged long long int), or to use the
short Java-style names (ie long, short, unsigned long long).

2| If a function has to receive multiple parameters, on what conditions
is it recommended to have a container struct for the parameters instead
of passing them individually.

Thanks...

 

[Hamiral]

Hello friends

Two questions for you...

1| Is it considered best practise to use the full C names for Composite
Types (ie long int, short int, unsinged long long int), or to use the
short Java-style names (ie long, short, unsigned long long).

It's more explicit to use full names for the types, but any C programmer
would (should) understand the "short" versions.

2| If a function has to receive multiple parameters, on what conditions
is it recommended to have a container struct for the parameters instead
of passing them individually.

Structs should be used to group data that relate to each other. Or you
will end up writing structs for each functions...

just my 0.02€

Ham

 

[Seebs]

1| Is it considered best practise to use the full C names for Composite
Types (ie long int, short int, unsinged long long int), or to use the
short Java-style names (ie long, short, unsigned long long).

I don't know, but I personally write "int" only when something is not
a short, long, or long long.

2| If a function has to receive multiple parameters, on what conditions
is it recommended to have a container struct for the parameters instead
of passing them individually.

When it makes sense.

Seriously, not kidding. If the parameters are logically a single thing,
they should be passed in as a single thing. If they're separate things,
they should be passed in separately.

-s

 

[Andrew Poelstra]

Hello friends

Two questions for you...

1| Is it considered best practise to use the full C names for Composite
Types (ie long int, short int, unsinged long long int), or to use the
short Java-style names (ie long, short, unsigned long long).

It makes no difference. Most people read them quickly enough
not to even notice whether 'int' appears. So it's up to you.
I prefer brevity.

2| If a function has to receive multiple parameters, on what conditions
is it recommended to have a container struct for the parameters instead
of passing them individually.

If your parameters relate to each other, you can group them into
structs. Like, if you had a function

double distance_4D(w1, x1, y1, z1, w2, x2, y2, z2);

probably you would benefit from some sort of 4D point structure.


I've never had a case where I needed a struct just for the sake of
making a function declaration short, though.

 

[John Bode]

Hello friends

Two questions for you...

1| Is it considered best practise to use the full C names for Composite
Types (ie long int, short int, unsinged long long int), or to use the
short Java-style names (ie long, short, unsigned long long).

I don't know if there's any agreed-upon convention; we don't have
anything that specific in our coding standards where I work. For
myself, I tend to use the short forms.

2| If a function has to receive multiple parameters, on what conditions
is it recommended to have a container struct for the parameters instead
of passing them individually.

The only reason to create a composite data type is if the elements of
the type are logically related to each other and describe a larger
entity. Under normal circumstances, you would *not* create a
composite data type *just* to bundle otherwise unrelated function
parameters together (there may be specific and unusual cases where
it's necessary to meet a performance requirement or address an
architectual quirk, but these should be very rare).

 

[Ersek, Laszlo]

I've never had a case where I needed a struct just for the sake of
making a function declaration short, though.

"generic callback functions" sometimes take a pointer-to-void, or a
union of two members, a pointer-to-void and some integer. The
pointer-to-void allows you to pass arbitrary parameters to the callback,
packed in an "artificial" struct. Example from N1425:

----v----
7.24.5.1 The thrd_create function

Synopsis

int thrd_create(thrd_t *thr, thrd_start_t func,
void *arg);

Description

The thrd_create function creates a new thread executing func(arg). [...]
----^----

Granted, this is not done for the brevity but the uniformity of the
interface.

lacos

 

[chrisbazley]

2| If a function has to receive multiple parameters, on what conditions
is it recommended to have a container struct for the parameters instead
of passing them individually.

In the ARM procedure call standard (and many others, I imagine) a
limited number of registers are available for passing function
arguments. The C compiler has to generate instructions to push any
additional arguments onto the stack before calling a function. This
can be costly, especially if the function is called within the body of
one or more loops.

In such cases it is usually more efficient to pass the function a
pointer to a struct instead of excess arguments. The values held in
the struct don't have to be related (except being required by the
callee). The saving is especially worthwhile if some arguments have
the same value over multiple invocations of the function (i.e. they
are more like context).

HTH,

 

[Nick Keighley]

1| Is it considered best practise to use the full C names for Composite
Types (ie long int, short int, unsinged long long int),

ITYM
unsung long long int

or to use the
short Java-style names (ie long, short, unsigned long long).

I use the shortest type I can get away with. I might even alias things
like unsigned char (and some will hate me for it)

2| If a function has to receive multiple parameters, on what conditions
is it recommended to have a container struct for the parameters instead
of passing them individually.

I'd apply what I call the "good module" principle. In unix they say a
program "should do one think well". In old structured programming
books (Constantine and Yourdon) they talk about "the cohesiveness" of
a function. In OO design books they talk about "crisply defined
boundaries". The same sort of concepts can be applied to other
"thingies". So you bundle things into a struct if they belong together
functionally. Occaisionally for efficiency you might bundle rather
unrelated things together. But you could think of this as an
optimisation of argument passing.

 

[Richard Bos]

1| Is it considered best practise to use the full C names for Composite
Types (ie long int, short int, unsinged long long int), or to use the
short Java-style names (ie long, short, unsigned long long).

The very idea that these are "Java-style", when Java came along a decade
or two after those short names were allowed in C, is daft.

Which is "considered best practice" (another daft phrase) depends for
99% on the project you're working on.

2| If a function has to receive multiple parameters, on what conditions
is it recommended to have a container struct for the parameters instead
of passing them individually.

Never. If some of your parameters have the property of fundamentally
belonging together, and always being used together, they should have
been a struct in the calling function. Never create a struct just for
calling another function. It smacks of braindead attempts at
optimisation.

Richard

 

[ImpalerCore]

Hello friends

Two questions for you...

1| Is it considered best practise to use the full C names for Composite
Types (ie long int, short int, unsinged long long int), or to use the
short Java-style names (ie long, short, unsigned long long).

I typically create variables that use the short names. The "int" part
doesn't add information about the type in of itself. However, in
casting, I will use the longer type if the original variable was
declared that way by someone else.

2| If a function has to receive multiple parameters, on what conditions
is it recommended to have a container struct for the parameters instead
of passing them individually.

It depends on how related they are. The rule of thumb I use is if
I've gone to the point of creating a struct for a set of variables,
then I typically use that struct in functions that use it.

 

[Nick]

"generic callback functions" sometimes take a pointer-to-void, or a
union of two members, a pointer-to-void and some integer. The
pointer-to-void allows you to pass arbitrary parameters to the callback,
packed in an "artificial" struct. Example from N1425:

----v----
7.24.5.1 The thrd_create function

Oh great, we're going to get a thrd_create function. What was wrong
with frst_create and secnd_create, eh?

 

[Andrew Poelstra]

Oh great, we're going to get a thrd_create function. What was wrong
with frst_create and secnd_create, eh?

We couldn't figure out how to unlock them.

 

[Paul N]

2| If a function has to receive multiple parameters, on what conditions
is it recommended to have a container struct for the parameters instead
of passing them individually.

Besides what others have said, it might be worth considering this if
one function is going to pass on all, or most, of the parameters to
one or more subfunctions. The code may look tidier if the various
parameters are just fed in at one end and are available everywhere you
need them; and it may be more efficient if you just pass a pointer to
them. That's "may", not "will", of course.