More function names, same implementation

Hi folks,
I need - if exists - the correct syntax to do something like this:

int foo1(void *)
int foo2(void *)
{
return 0;
}

Is there a way besides #defining?

InuY4sha

InuY4sha <> writes:
> I need - if exists - the correct syntax to do something like this:
>
> int foo1(void *)
> int foo2(void *)
> {
> return 0;
> }
>
> Is there a way besides #defining?

Just to be clear, you want foo1 and foo2 to be two different names for
the same function, right?

In your example, ignoring the first line, you have a definition for
foo2 with no name for the parameter, which means the parameter can't
be used. I'll assume you left the name out for the sake of the
example.

int foo1(void *param)
{
return 0;
}

int (*const foo2)(void*) = foo1;

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson

Sorry.. (it was late night)

> int foo1(void *param)
> {
> * * return 0;
>
> }
>
> int (*const foo2)(void*) = foo1;
>

This is exactly what I needed (so in the end you use pointers, no
strange syntax like I did)

InuY4sha

Btw.. it looks like I can't do this:

struct cell {
char *data1;
char *data2;
int (* const fptr)(void *);
};

int foo1(void *param)
{
return 0;
}
int (*const foo2)(void *) = foo1;

static struct mystuff data[] = {
{ DATA1, DATA2, foo2},
{ DATA3, DATA4, foo2},
///...
};

If I do so, I get this

error: initializer element is not constant
error: (near initialization for ‘operation[0].fptr’)

Switching foo2 to foo1 in the static struct "mystuff" fixes but could
become very inconvenient (unclean solution) to me...

THanks

InuY4sha

On 2009-11-07, InuY4sha <> wrote:
> error: initializer element is not constant
> error: (near initialization for ?operation[0].fptr?)

That's right, it isn't.

> Switching foo2 to foo1 in the static struct "mystuff" fixes but could
> become very inconvenient (unclean solution) to me...

Might help if you were to start by explaining what it actually is that
you want to do that has you wanting to have two names for the same
function.

-s
--
Copyright 2009, 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!

Seebs

> Might help if you were to start by explaining what it actually is that
> you want to do that has you wanting to have two names for the same
> function.
>
Agreed.

I'm implementing a mathematical parser (don't ask me why I don't use
yacc!

What I'm trying to do is to code it in such a way that users can add
new functions and their handling within a simple header file.

I'm using a binary tree to handle parser structure. The nice thing is
that to me, "expanding" an expression such as "a*b*c" is exactly the
same thing as expanding "a+b+c" and not much different than "a-b-c" or
"a/b/c".

Basically I've come to a point where the main handling of operations
is based on the number of operands that the operation requires.


I'd like users to be able to add standard functions in such form:


{OPERATION_ID, OPERATION_EXPR, EXPAND_FUNC_PTR, CALCULATE_FUNC_PTR}

To make code readable I'd like EXPAND_FUNC_PTR name to match the
operation we are working with:

{ 0, "+", sum_expand, sum_calc}
{ 1, "*", mult_expand, mult_calc}

The current sum_expand and mult_expand implementation are identical
and accept as input argument the pointer to the structure referencing
the functions itselves, so by just changing the structure they change
the operators within the identical btree that they generate.

I'd like to give these functions different names to keep the code
clear to newcomers (mine is a positive attitude in the end

InuY4sha

On 2009-11-07, InuY4sha <> wrote:
> What I'm trying to do is to code it in such a way that users can add
> new functions and their handling within a simple header file.

Interesting.

> {OPERATION_ID, OPERATION_EXPR, EXPAND_FUNC_PTR, CALCULATE_FUNC_PTR}

> To make code readable I'd like EXPAND_FUNC_PTR name to match the
> operation we are working with:

> { 0, "+", sum_expand, sum_calc}
> { 1, "*", mult_expand, mult_calc}

Seems plausible.

> I'd like to give these functions different names to keep the code
> clear to newcomers (mine is a positive attitude in the end

I am not sure that this is actually clear. If you have the same
exact function, but it performs different operations in different
contexts, giving them different names strikes me as obfuscating rather
than clarifying. If it's really the same function, then calling it
by two names leads the user to assume that it's two functions, and if
you lead them to believe something untrue, that seems unhelpful.

I'd say maybe it's more readable if you have EXPAND_FUNC_PTR describe
the type of expansion, so if you have many things which use the same
EXPAND_FUNC_PTR, it's clear from looking at the table that they're all
the same thing.

Or you can do crazy stuff:

/* expand_func_default.c */
FUNC() {
/* do stuff */
}


/* various_expand.c */
#define FUNC sum_expand
#include expand_func_default.c

#undef FUNC
#define FUNC mul_expand
#include expand_func_default.c

(But this means that they really ARE two different functions, they
just share source.)

-s
--
Copyright 2009, 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!

Seebs

> > I'd like to give these functions different names to keep the code
> > clear to newcomers (mine is a positive attitude in the end
>
> I am not sure that this is actually clear. *If you have the same
> exact function, but it performs different operations in different
> contexts, giving them different names strikes me as obfuscating rather
> than clarifying. *If it's really the same function, then calling it
> by two names leads the user to assume that it's two functions, and if
> you lead them to believe something untrue, that seems unhelpful.


THanks Seebs.. after a couple of posts here and there, I'd like to
summarize the issue and proposed solutions (because clearly I myself
did not completely comprehend what I exactly needed)...
As a C programmer I was probably wishing for a more flexible language
(I know I should be punished for this! ^_^ ):
Basically I have an "object" (struct) with

- operator ID
- mathematical expression
- expanding function
- solver function (calculate)

1) From a logical point of view, expanding a tree of sums is different
from expanding a tree of multiplications.
2) Again if we logically consider the above set of data which is
obviously monolithic, the knowledge of the operator ID, automatically
determines the type of expansion we need to perform.
3) From a practical point of view expanding a bunch sums or
multiplications are the ~ same operation.


These 3 points would lead me to this "needs":

1) I'd like to have different expand function names to meet the
logical difference existing between each expanding function.
2) I'd like the expanding functions that implement the same logical
procedure, to converge within the same code function implementation.
3) I'd like such implementation to be *aware* of what operator
triggered the function, so that we can adjust processing the minimal
changes required (basically the operator used to set the inner nodes).


Regarding point 3) we could use the operator as an ARGUMENT of the
expanding function. This is a non-elegant working method.

Regarding points 1) and 2), apparently using #defines or the above
descibed method hereby pasted

int foo1(void *param)
{
return 0;
}
int (*const foo2)(void *) = foo1;

are the only two possible ways to answer these needs.

InuY4sha

On 2009-11-09, InuY4sha <> wrote:
> 1) From a logical point of view, expanding a tree of sums is different
> from expanding a tree of multiplications.

I don't agree with this. I think it's the same thing; it's expanding a
tree of binary operators.

> 1) I'd like to have different expand function names to meet the
> logical difference existing between each expanding function.

What difference? They're doing the same thing. They're doing it on different
data, is all. Just view the operator as part of the data, rather than part
of the function, and All Is Well.

Or, alternatively, bury it:

int
expand_mul(void *o1, void *o2) {
return expand_binop(o1, o2, '*');
}

But really, it seems to me that that's unnecessary. There is NOT a logical
difference between expanding different binary operators.

> Regarding point 3) we could use the operator as an ARGUMENT of the
> expanding function. This is a non-elegant working method.

I don't think it's non-elegant at all. You're describing a single consistent
operation (expand a tree with a binary operator at the top), and you're
telling it what it needs to do that.

Here's the thing: If the actual thing done is the same except for a piece
of data, then it really is the same function. And it seems like the thing
done is indeed the same.

-s
--
Copyright 2009, 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!

Seebs