void pointers

[steve]

unnecessary (the functions are declared in <stdlib.h> and
non-portable (some systems might not provide <malloc.h>, others
might provide it with different contents).

Do you not consider that positive?

I failed to see how it had any bearing on the question at hand.
It had no effect on "void pointers" and their usage.

Steve

 

[Kenny McCormack]

See my prior reply, re: windows portion.



Did you have something positive to contribute to this discussion ?

Steve

We're talking about Kiki here. He never has anything helpful or useful
to say. Better get used to it, though - he's the voice of CLC.

Ref: http://redwing.hutman.net/~mreed/warriorshtm/android.htm

--
"The anti-regulation business ethos is based on the charmingly naive notion
that people will not do unspeakable things for money." - Dana Carpender

Quoted by Paul Ciszek (pciszek at panix dot com). But what I want to know
is why is this diet/low-carb food author doing making pithy political/economic
statements?

Nevertheless, the above quote is dead-on, because, the thing is - business
in one breath tells us they don't need to be regulated (which is to say:
that they can morally self-regulate), then in the next breath tells us that
corporations are amoral entities which have no obligations to anyone except
their officers and shareholders, then in the next breath they tell us they
don't need to be regulated (that they can morally self-regulate) ...

 

[steve]

Hey Ben,

......but once you have located the function to
call (exp in this case) you have to know that exp takes a double and
you'll have to turn the void * into a double to make the call.

Hmmm..., I see.

Often, the best solution to this problem is not to try to permit calls
to arbitrary dynamic function but to provide instead a mechanism that
automates the boiler-plate code needed to interface to a given library.

Yeh..., but, that is the whole purpose.
So that a script writer can 'call' function that are not built-in.
I just need to minimize the overhead.
Program 'bloat' is the issue.

.... but this
can be done statically (a tool to make a dynamic "glue" library for your
engine from some description of the external DLL) or dynamically (some
implementation specific mechanism that can build a valid call from some
kind of prototype string or structure).

That's what I set out to do, until I came upon void pointers.
They seemed like a good option, if I could get it to work.

The functions will still need to be passed arguments of the type that
they expect and, what is more, these arguments have to passed using the
correct calling conventions (e.g. you can't "pretend" that exp declared
double exp(...)).

Right, understood.
The engine has error trapping, in the event of this.

I.e. you'd automate the production of lots of
functions like this:

  void *engine_call_exp(void *arg1)
  {
      double *result = engine_allocate_object(sizeof *result);
      *result = exp(*(double *)arg1);
      return result;
  }

Yes.
I think you fully get what I'm after and I truely appreciate your time
and effort to explain this.

... and will rely on fair bit of trickery.

I like 'trickery'.

Steve

 

[Seebs]

Did you have something positive to contribute to this discussion ?

That struck me as pretty helpful. If I'm including a header that, on
many systems, either doesn't exist or does something undesireable, I'd
like to know.

-s

 

[Seebs]

I failed to see how it had any bearing on the question at hand.

It may or may not have. It's not unheard of for including a system-specific
header to have very surprising effects.

But even if it didn't, so what? General tips about how to improve my
programming are usually at least as useful to me as specific answers about
a particular question.

It had no effect on "void pointers" and their usage.

And how are people who don't happen to have that header to determine this?

-s

 

[Keith Thompson]

I failed to see how it had any bearing on the question at hand.
It had no effect on "void pointers" and their usage.

No, I didn't answer the question you asked. I commented on your
code. Why is that a problem? Would you prefer not to know that
you don't need <malloc.h>?

This is a discussion group, not just an "answer my question and
don't bother me with extra information" group.

If you didn't find my advice useful, I'll gladly give you a full
refund.

 

[Kenny McCormack]

No, I didn't answer the question you asked. I commented on your
code. Why is that a problem? Would you prefer not to know that
you don't need <malloc.h>?

This is a discussion group, not just an "answer my question and
don't bother me with extra information" group.

If you didn't find my advice useful, I'll gladly give you a full
refund.

Ha hahahahah haha!

http://redwing.hutman.net/~mreed/warriorshtm/android.htm

 

[Ben Bacarisse]

That's what I set out to do, until I came upon void pointers.
They seemed like a good option, if I could get it to work.

The main point is the void pointers don't help much on their own.

Right, understood.
The engine has error trapping, in the event of this.

I am not sure you do understand. If you get this wrong there will often
not be anything to "trap" on. I am not commenting about the user of
your script engine having to get the data right -- I take that for
granted -- I am talking about how you engineer the function call. If
you get that wrong, exp will quite likely simply return exp of the wrong
value.

Yes.
I think you fully get what I'm after and I truely appreciate your time
and effort to explain this.

[This next refers to doing it entirely dynamically]

I like 'trickery'.

I see elsewhere that you want a solution for one system family
(Windows). I think you will have ask in a Windows group as the
"trickery" is highly system specific.

 

[Morris Keesan]

If you mean the assumption that, on a given system, all addresses
(pointers) are the same size then this is not true. It is particularly
not true for function pointers and object pointers, but it can (at least
in theory) also not be true for other types of pointer.

And I have, in fact, worked on more than one system where pointers to
char were larger than all other pointers (except, of course, (void *)).

 

[steve]

I am talking about how you engineer the function call.  If

you get that wrong, exp will quite likely simply return exp of the wrong
value.

Yes, actually I do understand.

I see elsewhere that you want a solution for one system family (Windows).

No...,
that was simply an example for illustration.
One that showed calling any named DLL and passing multiple parameters.
And, could be easily understood even if not compiled.
It could be easily commented out.
Had I used a Linux or Unix specific illustration, the same thing would
have been said.

Steve

 

[steve]

Ha hahahahah haha!

http://redwing.hutman.net/~mreed/warriorshtm/android.htm

I concur.

 

[Ben Bacarisse]

No...,
that was simply an example for illustration.
One that showed calling any named DLL and passing multiple parameters.
And, could be easily understood even if not compiled.
It could be easily commented out.
Had I used a Linux or Unix specific illustration, the same thing would
have been said.

What I said was that you need to ask in system-specific group. If the
Windows code was just an example and you need a portable solution, then
you'll need to ask in a Windows group and in a Linux group and possibly
in others as well.

The advantage of the static solution (automating the making of an
interface module) is that it can be made portable. The dynamic solution
will require some run-time information about each library function you
might call and enough system-specific trickery that you'll probably need
to re-implement it afresh for each sufficiently different system.

 

[steve]

The advantage of the static solution (automating the making of an

interface module) is that it can be made portable.  

As distasteful as the idea is, (doing all that extra coding), this may
end up being my solution.

Steve

 

[Kenny McCormack]

(Kiki)

(You)
hahaha!

I dont think I ever saw a more perfect match!

Bwian is in this one :
http://redwing.hutman.net/~mreed/warriorshtm/bigdogmetoo.htm

I assume you mean that Bwian is the "MeToo" part of that, not the Big Dog.

--
One of the best lines I've heard lately:

Obama could cure cancer tomorrow, and the Republicans would be
complaining that he had ruined the pharmaceutical business.

(Heard on Stephanie Miller = but the sad thing is that there is an awful lot
of direct truth in it. We've constructed an economy in which eliminating
cancer would be a horrible disaster. There are many other such examples.)

 

[Kenny McCormack]

You got it.

"As Keith says ..." etc.
"We dont do ...." etc

Indeed. Quite so.

I see now that you did say "Bwian is _in_ this one" (emphasis mine).

--

No, I haven't, that's why I'm asking questions. If you won't help me,
why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.

 

[Barry Schwarz]

However, this statement will not compile:

params[indx] = (void*)dbl_param_values[ndx];

and generates this compiler error:

"...cast from 'double' to 'pointer to void' is illegal"



When it's all said and done, the idea is to pass the data referred to
in the array as function parameters,
like so:

MyFunction(params[0], params[1], etc.);

Does sombody understand void pointers enough to explain why the above
doesn't work and possibly offer a solution to the problem.

You want the address of the double of interest, so the statement should be:

params[indx] = (void*)(& (dbl_param_values[ndx]));

or perhaps

params[indx] = (void*)(dbl_param_values + ndx);

In neither case is the cast necessary.

 

[Ian Collins]

but if i call one function with the parameter "double" it is here
64 bits put *in the stack*, instead "void*" is 32bits always

Says who?

if every function were impemented with prototip compatible with pointers like
void* (__stdcall *stdcall_func4)();
void* (__stdcall *stdcall_func4)(void *);
void* (__stdcall *stdcall_func4)(void *, void *);
void* (__stdcall *stdcall_func4)(void *, void *, void *);
void* (__stdcall *stdcall_func4)(void *, void *, void *, void *);
etc
for example
for the C function "double cos(double );"
this
"double* __stdcall cos(double* );"
where each function has their parameters in that way
eg double v=3.0;
v=*cos(&v); // ok
but v=*cos(3.0) will be one error
and seems to me v=cos(&3.0) could be one error too
even if 3.0 is in some place in the memory
and so has to have one address (in runtime?)
is it possible printf function
can be enanced if their parameter
are all pointers to void

Eh?