Connecting Tech Pros Worldwide Forums | Help | Site Map

Take paramaters as one pointer?

a_agaga@yahoo.com
Guest
 
Posts: n/a
#1: Nov 15 '06
I will start a new discussion about this issue here.

The question popped up after investigating an other issue:
http://groups.google.fi/group/comp.l...07f29eaecd75c3
Maybe a separate discussion would be good for this.


Do you know how several arguments can be passed to an other method
through an intermediate method?
The intemediate method should not need to know how many arguments are
used. The intermediate method should not need to know the types of the
arguments either.

Is it possible to pass the arguments that way?

method1 -passes several arguments with different types to ->
intermediateMethod(use some kind of a pointer to args?)

Then intermediateMethod passes the arguments to -finalMethod1.
(And finalMethod read the arguments and passes the values one more time
to a library.)

The task above happen inside a wrapper class
(, which should e.g. convert the exception to a different type of
exception in the intermediateMethod).

Is it possible to pass the arguments behind a pointer?
finalMethod would read the arguments from the pointer, which it gets?
Or some other way.

I do not know is this possible.
I have seen this kind of a functionality e.g. when using threads,
arguments can be given to threads, and threads can read the arguments,
or there is also similar functionality in main: in "int
main(...argv...)".

I do not know would this kind of a functionality be easy to implement.


mlimber
Guest
 
Posts: n/a
#2: Nov 15 '06

re: Take paramaters as one pointer?


a_agaga@yahoo.com wrote:
Quote:
I will start a new discussion about this issue here.
>
The question popped up after investigating an other issue:
http://groups.google.fi/group/comp.l...07f29eaecd75c3
Maybe a separate discussion would be good for this.
>
>
Do you know how several arguments can be passed to an other method
through an intermediate method?
The intemediate method should not need to know how many arguments are
used. The intermediate method should not need to know the types of the
arguments either.
>
Is it possible to pass the arguments that way?
>
method1 -passes several arguments with different types to ->
intermediateMethod(use some kind of a pointer to args?)
>
Then intermediateMethod passes the arguments to -finalMethod1.
(And finalMethod read the arguments and passes the values one more time
to a library.)
>
The task above happen inside a wrapper class
(, which should e.g. convert the exception to a different type of
exception in the intermediateMethod).
>
Is it possible to pass the arguments behind a pointer?
finalMethod would read the arguments from the pointer, which it gets?
Or some other way.
>
I do not know is this possible.
I have seen this kind of a functionality e.g. when using threads,
arguments can be given to threads, and threads can read the arguments,
or there is also similar functionality in main: in "int
main(...argv...)".
>
I do not know would this kind of a functionality be easy to implement.
You could use a std::vector<boost::any>. See
http://boost.org/doc/html/any.html.

Cheers! --M

a_agaga@yahoo.com
Guest
 
Posts: n/a
#3: Nov 16 '06

re: Take paramaters as one pointer?


Quote:
>
You could use a std::vector<boost::any>. See
http://boost.org/doc/html/any.html.
>
Cheers! --M

Thank you!

Actually I would/will probably use void pointers in the vector
(vector<void*>),
but the main idea is the same as with boost::any.
Thanks for the idea!

mlimber
Guest
 
Posts: n/a
#4: Nov 16 '06

re: Take paramaters as one pointer?


a_agaga@yahoo.com wrote:
Quote:
Quote:

You could use a std::vector<boost::any>. See
http://boost.org/doc/html/any.html.

Cheers! --M
>
>
Thank you!
>
Actually I would/will probably use void pointers in the vector
(vector<void*>),
but the main idea is the same as with boost::any.
Thanks for the idea!
I'd recommend against that approach. The Boost.Any documentation offers
this warning:

"[A third kind of generic types are] [i]ndiscriminate types that can
refer to anything but are oblivious to the actual underlying type,
entrusting all forms of access and interpretation to the programmer.
This niche is dominated by void *, which offers plenty of scope for
surprising, undefined behavior."

Cheers! --M

Closed Thread