Excuse me. Here is it again (re: inline)

[jacob navia]

I had a typo in my first message, and I wasn't very explicit
about what is the problem.

I apologize for this, probably I am too tired.

-------------------------------------------------
What I need to do is the following:

This is an interface:

typedef struct interface {
double (const *Deg2Rad)(double foo);
double (*doubleFn)(double foo);
char *SomeData;
double MoreData;
} Interface;

Now, I want to say that the member "Deg2Fn" is the following
INLINE function:

inline double Interface.Deg2Rad(double foo) { return foo/57.295; }


You see?

I propose that when defining an inline function, we can specify
a structure member (with matching prototype of course) so that
the compiler knows that all calls to:

Interface.Deg2fn(180.0)

can be safely replaced with the inlined function.

Of course the compiler is still required to generate that function so
that any initializations of the structure receive the correct field.

Interface myInterface = {
Deg2Rad, // This MUST be Deg2Rad All other values are an error
Foo,
"Foo",
3.14159
};

The objective is to allow inline functions within structure members.

Rationale:
----------

C is widely used as back end language for other languages. Eiffel is one
of the oldest examples, but now you have many others. In OO programming
this construct is very important. It would be nice if we would extend
the language to support inling structure members.

Besides, this is also important for C programmers when they use
this kinds of constructs in their code.


jacob

[Martin Shobe]

From this description ‪ it sounds like you want something similar to
C++'s static member functions. Rather than abusing inline that way,
wouldn't it be better to allow something more like,

typedef struct Interface
{
double Deg2Rad(double deg) { return deg / 57.295; }
double (*doubleFn)(double);
char * data;
double moreData;
} Interface;

then have

Interface myInterface = { Foo, "foo", 3.14159 };

and the call would be

myInterface.Deg2Rad(180.0);

Martin Shobe

[jacob navia]

Le 14/05/12 17:19, Martin Shobe a écrit :

>
> From this description ‪ it sounds like you want something similar to
> C++'s static member functions. Rather than abusing inline that way,
> wouldn't it be better to allow something more like,
>
> typedef struct Interface
> {
> double Deg2Rad(double deg) { return deg / 57.295; }
> double (*doubleFn)(double);
> char * data;
> double moreData;
> } Interface;
>
> then have
>
> Interface myInterface = { Foo, "foo", 3.14159 };
>
> and the call would be
>
> myInterface.Deg2Rad(180.0);
>
> Martin Shobe
>

Of course. That would be even better, but I was afraid that it would be
too much asking for :-)

But now that YOU propose it I agree of course :-)

[Ian Collins]

On 05/15/12 02:19 AM, jacob navia wrote:
> I had a typo in my first message, and I wasn't very explicit
> about what is the problem.
>
> I apologize for this, probably I am too tired.
>
> -------------------------------------------------
> What I need to do is the following:
>
> This is an interface:
>
> typedef struct interface {
> double (const *Deg2Rad)(double foo);
> double (*doubleFn)(double foo);
> char *SomeData;
> double MoreData;
> } Interface;
>
> Now, I want to say that the member "Deg2Fn" is the following
> INLINE function:
>
> inline double Interface.Deg2Rad(double foo) { return foo/57.295; }
>
>
> You see?
>
> I propose that when defining an inline function, we can specify
> a structure member (with matching prototype of course) so that
> the compiler knows that all calls to:
>
> Interface.Deg2fn(180.0)
>
> can be safely replaced with the inlined function.

I still don't get how this improves things. If the compiler can see the
function definition if can already inline it. See my original reply to
your other thread.

--
Ian Collins

[jacob navia]

Le 14/05/12 21:42, Ian Collins a écrit :

>
> I still don't get how this improves things. If the compiler can see the
> function definition if can already inline it. See my original reply to
> your other thread.
>

No. The compiler sees a function definition.
OK. It can inline it. OK

But it doesn't see the ASSIGNMENT to the structure member (because it
is in another compilation unit).

[Jens Gustedt]

You really need an rvalue that contains these function pointers,
that's all, and that is possible with C as it stands now. As I have
given in the other thread one way is to have a cast of a compound
literal

(struct Interface)(struct Interface){ ... your initialization ... }

that you can pack in a macro "iList" if you like and you may const
qualify if you want.

Another possibility would be to create an inline function

inline struct Interface iList(void) {
return (struct Interface){ ... your initialization ... };
}

(perl does such things for constants) but this would force the user to
write something like iList(), not exactly the syntax that you
wanted. For the happiness of C purists you could do

#define iList iList()

Jens

[jacob navia]

Le 14/05/12 23:12, Jens Gustedt a écrit :

> You really need an rvalue that contains these function pointers,
> that's all, and that is possible with C as it stands now. As I have
> given in the other thread one way is to have a cast of a compound
> literal
>
> (struct Interface)(struct Interface){ ... your initialization ... }
>

That could be done with a small interface of a few functions (all
inlined). Yes, in those cases that would work, but imagine a simple
container like the list container having 56 functions...

The initialization would be very big. Will all compilers be so clever
that they willnotice that those immediate constants are the same and
create a single structure?

Or will they repeat all the initilizations with different immediate
literals at each call? In any case that wikll repeat the code at
each compilation unit. Maybe not a big deal if those initilaizations
are short, what is not always the case.

> that you can pack in a macro "iList" if you like and you may const
> qualify if you want.
>
> Another possibility would be to create an inline function
>
> inline struct Interface iList(void) {
> return (struct Interface){ ... your initialization ... };
> }
>

That solution has the same problems as above.

> (perl does such things for constants)

Yes, for *constants* but not for a whole interface.

> but this would force the user to
> write something like iList(), not exactly the syntax that you
> wanted. For the happiness of C purists you could do
>
> #define iList iList()
>
> Jens

Jens: your proposal *could* be a solution for special, small
cases where the interface is small. Now, for longuish interfaces
with quite a lot of functions, I see that much more difficult.

jacob

[Ian Collins]

Ah-ha, I didn't appreciate the in another compilation unit part. That
dose make it tricky. So what you are proposing is a means to specialise
a generic interface?

Have you considered implementing your changes in a cfront like
preprocessor? That would decouple them form any one compiler and allow
more users to try them and understand their value. Given the
committee's policy of standardising existing practice, surely that's the
best route to follow.

--
Ian Collins

[Jens Gustedt]

Am 14.05.2012 23:37, schrieb jacob navia:
> That could be done with a small interface of a few functions (all
> inlined). Yes, in those cases that would work, but imagine a simple
> container like the list container having 56 functions...
>
> The initialization would be very big. Will all compilers be so clever
> that they willnotice that those immediate constants are the same and
> create a single structure?

If it were just to create a const qualified compound literal, you are
right, not all compilers would notice the possibility to fold all of
these into one.

If it is an rvalue, there is no object to be allocated. All contents
of the rvalue can be constant propagated (I hope that's the correct
term and you see what I mean.) This is like doing

"A very very long string"[7]

*any* compiler should optimize that to the constant character 'v'.

> Or will they repeat all the initilizations with different immediate
> literals at each call? In any case that wikll repeat the code at
> each compilation unit. Maybe not a big deal if those initilaizations
> are short, what is not always the case.

if you have it as rvalues, there should never be an object allocated
for any of these, in particular if you then only select one of the
fields of that rvalue

>> (perl does such things for constants)
>
> Yes, for *constants* but not for a whole interface.

(I think in perl you can do that for "constants" in a very broad sense)

> Jens: your proposal *could* be a solution for special, small
> cases where the interface is small. Now, for longuish interfaces
> with quite a lot of functions, I see that much more difficult.

That's why I mentioned a possible extension of C that would be

"const qualified register variables in file scope".

That would be more appropriate as an extension to C than thinking of
introducing OO-like syntax. It would

- be simple to add, no existing code would break
- have a clear semantic
- add the missing feature of global, named constants for other types
than "int" (e.g double!)
- solve your problem much more elegantly that my crude macros with
their casting of compound literals.

Jens