By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,323 Members | 1,855 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,323 IT Pros & Developers. It's quick & easy.

Take paramaters as one pointer?

P: n/a
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.

Nov 15 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
a_*****@yahoo.com wrote:
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

Nov 15 '06 #2

P: n/a
>
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!

Nov 16 '06 #3

P: n/a
a_*****@yahoo.com wrote:

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

Nov 16 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.