Help on " ne10_result_t(* ne10_add_float)(ne10_float32_t *dst,ne10_float32_t *src1, ne10_float32_t *

[fl]

Hi,

I am learning ARM NEON library libNE10.a. It has the following variable definition. It is difficult for me to understand it. Could you explain it to me?

ne10_result_t is the return type.

What is "ne10_add_float"?

Thanks,


....................
ne10_result_t(* ne10_add_float)(ne10_float32_t *dst, ne10_float32_t *src1, ne10_float32_t *src2, ne10_uint32_t count)

Adds the elements of src1 to the elements of src2 and stores the results in the dst.

This function point could be pointed to one of ne10_add_float_c, ne10_add_float_neon and ne10_add_float_asm.

Parameters:
[out] dst Pointer to the destination array
[in] src1 The first array to use as the input array
[in] src2 The second array to use as the input array
[in] count The number of items in the two input arrays

Definition at line 248 of file NE10_init_math.c.

 

[Ike Naar]

I am learning ARM NEON library libNE10.a.
It has the following variable definition.
It is difficult for me to understand it. Could you explain it to me?

ne10_result_t is the return type.

What is "ne10_add_float"?

ne10_result_t(*ne10_add_float)(ne10_float32_t *dst,
ne10_float32_t *src1,
ne10_float32_t *src2,
ne10_uint32_t count)

Adds the elements of src1 to the elements of src2
and stores the results in the dst.

This function point[er] could be pointed to one of
ne10_add_float_c, ne10_add_float_neon and ne10_add_float_asm.

ne10_add_float is a pointer to a function that takes parameters of type
(ne10_float32_t*,ne10_float32_t*,ne10_float32_t*,ne10_uint32_t) and that
returns an ne10_result_t.

The idea is that, at the beginning of your program, you can choose which
variant (ne10_add_float_c, ne10_add_float_neon, ne10_add_float_asm) you
want to use in the rest of the program, by means of a simple assignment.

After, say,

ne10_add_float = ne10_add_float_c;

all calls to ne10_add_float will use ne10_add_float_c.

If you want to use ne10_add_float_asm instead of ne10_add_float_c,
you'll only have to change the assignment to

ne10_add_float = ne10_add_float_asm;

and after that, all calls to ne10_add_float will use ne10_add_float_asm.

 

[BartC]

ne10_result_t is the return type.

What is "ne10_add_float"?

ne10_result_t(* ne10_add_float)(ne10_float32_t *dst, ne10_float32_t *src1,
ne10_float32_t *src2, ne10_uint32_t count)

For complex type declarations I sometimes use a CDECL program to untangle
them and explain what they mean in English (eg. there's an online version
here: http://www.lemoda.net/c/cdecl/index.cgi).

Unfortunately that doesn't understand the typedefs used, so it's necessary
to replace them by standard types such as float and int, although by the
time you've done that, it may already be much clearer!

The naming scheme above is also poor and it makes it harder to figure out
what is the name of a type, and what is the name of the function (or
variable as it turns out), as most names contain 'float'.

Anyway, in your example, ne10_add_float is apparently a variable containing
a pointer to a function. The variable doesn't have a return type, but the
function will do when it's called.

 

[Keith Thompson]

ne10_result_t is the return type.

What is "ne10_add_float"?

ne10_result_t(* ne10_add_float)(ne10_float32_t *dst, ne10_float32_t *src1,
ne10_float32_t *src2, ne10_uint32_t count)

[snip]
The naming scheme above is also poor and it makes it harder to figure out
what is the name of a type, and what is the name of the function (or
variable as it turns out), as most names contain 'float'.

All the type names end with "_t".

 

[BartC]

ne10_result_t is the return type.

What is "ne10_add_float"?

ne10_result_t(* ne10_add_float)(ne10_float32_t *dst, ne10_float32_t
*src1,
ne10_float32_t *src2, ne10_uint32_t count)

[snip]
The naming scheme above is also poor and it makes it harder to figure out
what is the name of a type, and what is the name of the function (or
variable as it turns out), as most names contain 'float'.

All the type names end with "_t".

Are names ending in "_t" reserved to be names of types? If not then you
can't make any assumptions. Even if they are, nothing stops someone using,
for example, "ne10_add_float" as a type name.

 

[James Kuyper]

ne10_result_t is the return type.

What is "ne10_add_float"?

ne10_result_t(* ne10_add_float)(ne10_float32_t *dst, ne10_float32_t
*src1,
ne10_float32_t *src2, ne10_uint32_t count) [snip]
The naming scheme above is also poor and it makes it harder to figure out
what is the name of a type, and what is the name of the function (or
variable as it turns out), as most names contain 'float'.

All the type names end with "_t".

Are names ending in "_t" reserved to be names of types?

If you #include one of it's headers, POSIX does indeed reserve such
names to the implementation, for use as data types. Paradoxically, this
has led many people to follow the same convention in their own type
names, even though doing so violates that reservation.

 

[Kaz Kylheku]

Are names ending in "_t" reserved to be names of types?

No; this is some fantasy of the pitiful morons who look after POSIX.

 

[Keith Thompson]

ne10_result_t is the return type.

What is "ne10_add_float"?

ne10_result_t(* ne10_add_float)(ne10_float32_t *dst,
ne10_float32_t *src1,
ne10_float32_t *src2, ne10_uint32_t count) [snip]
The naming scheme above is also poor and it makes it harder to figure out
what is the name of a type, and what is the name of the function (or
variable as it turns out), as most names contain 'float'.

All the type names end with "_t".

Are names ending in "_t" reserved to be names of types? If not then
you can't make any assumptions. Even if they are, nothing stops
someone using, for example, "ne10_add_float" as a type name.

My point was merely that *in the example*, all the type names end with
"_t", so it's not at all hard to figure out which names refer to types
vs. variables. Functions vs. variables may be another matter, but
choosing descriptive names for both should address that.

(POSIX does, as I recall, reserve identifiers with the a "_t" suffix for
its own use; C does not.)

 

[BartC]

My point was merely that *in the example*, all the type names end with
"_t", so it's not at all hard to figure out which names refer to types
vs. variables.

But which are the type names? The OP's context as I understood it was that
he didn't understand the syntax (neither did I). You might perhaps see that
some names end with "_t", and some don't, and might guess that those are
types, and might further guess that *all* types in the example (see subject
line) follow that rule.

However at first glance all *I* saw was a mess of "ne10"s and "float"s! Even
written out like this:

T(*a)(T b, T c, T d, T e)

Where T is a definite type, and a...e are other identitifiers, it's not
immediately obvious to some us (ie. those of us for whom CDECL was invented)
what we're looking at.

 

[James Kuyper]

On 01/14/2014 04:39 AM, BartC wrote:
....

But which are the type names? The OP's context as I understood it was that
he didn't understand the syntax (neither did I). You might perhaps see that
some names end with "_t", and some don't, and might guess that those are
types, and might further guess that *all* types in the example (see subject
line) follow that rule.

However at first glance all *I* saw was a mess of "ne10"s and "float"s! Even
written out like this:

T(*a)(T b, T c, T d, T e)

Where T is a definite type, and a...e are other identitifiers, it's not
immediately obvious to some us (ie. those of us for whom CDECL was invented)
what we're looking at.

A general rule that covers most of the C type declaration syntax is that
it mirrors the syntax used when making use of the thing declared. In
this, case, the above declaration means that the expression (*a)(b, d,
d, e) has the type T, so long as b, c, d, and e are all expressions that
are implicitly convertible to type T.

 

[Keith Thompson]

But which are the type names?

In this particular example, the type names are all the identifiers
ending with "_t". That's a common convention (though it does conflict
with POSIX).

The OP's context as I understood it was that
he didn't understand the syntax (neither did I). You might perhaps see that
some names end with "_t", and some don't, and might guess that those are
types, and might further guess that *all* types in the example (see subject
line) follow that rule.

Yes, and that guess would be correct.

And yes, you *also* have to understand the syntax (and cdecl is a useful
tool for that; I use it myself).

You complained that "The naming scheme above is also poor and it makes
it harder to figure out what is the name of a type". In fact, the
naming scheme appears to be perfectly consistent. (Any naming scheme
requires understanding what the scheme is.)

I'm not sure what scheme would be clearer. Do you have a suggestion?

[...]

 

[Kaz Kylheku]

In this particular example, the type names are all the identifiers
ending with "_t". That's a common convention (though it does conflict
with POSIX).

It does not conflict with POSIX. POSIX may introduce new type names with _t in
the future which you don't know about today.

However, POSIX also has feature selection macros. The _t names you don't know
about today will only be revealed when you define some feature selection macro
whose name (or at least whose exact value) you also don't know about today. Or,
perhaps, if you include some new header which does not exist today.

So, you can cheerfully use _t identifiers in programs that target POSIX.

Note that not all POSIX extension work is in a lexically delimited namespace
like *_t. For instance, before the nanosleep function was introduced, where
was that name documented as being reserved? The name contains no suffix or
prefix. POSIX programs that were written before nanosleep was introduced can
continue to use it as their own identifier. Even as an external name. Even if
they include <time.h>, provided they don't define a feature selection macro
which reveals the declaration.