boost::function map with different return types
Hi,
I have the following code:
---------------
#include
Julia,
The only way I can think of accomplishing this is to have all the methods
have the same return type. function<void> and function<int> are two
distinct types. Assigning them both to a function<void> just doesn't seem
right.
Jeff
-----Original Message-----
From: news [mailto:news@main.gmane.org]On Behalf Of Julia Donawald
Sent: Tuesday, September 03, 2002 8:22 AM
To: boost-users@yahoogroups.com
Subject: [Boost-Users] boost::function map with different return types
Hi,
I have the following code:
---------------
#include
Hi,
in compl.lang.c++ I got the following answer to my problem:
--------------------------------------------------------------------
On Tue, 3 Sep 2002 17:21:00 +0200, "Julia Donawald"
Hi, I have the following code:
Calling the correct function with the entries in the map is no problem, but how can I get the return value. I tried something like that: "unsigned int i = functions["Function5"]();" but sadly it doesnt work, maybe cause in the map I declared for the return value "void"? How can I have such a map where to have functions with different return types in it and to get the return value after a call of the function
[snipped code] through
the map?
Boost has another lovely library called "any". An "any" can hold any
time, with the unfortunate exception of void. Below is a partial
solution to your problem that will work with any function that returns
something other than void. (tested with gcc 3.2)
#include
Hi, I found the mistake why it throws me an exception... so now it works quite well.... what do you think about that solution in general? Thanks in advance Julia
I don't understand the reason for mapping boost::functions with different
return type signatures ? What does it get you since to pick up the correct
return value you must know exactly what each return type is for each map
entry and there is nothing in the map entry itself to tell you this except
the name. So you end up hard-coding knowledge of each entry in the map based
on the name into your code. Doesn't sound like it gets you anything as far
as design goes. Perhaps there is something wrong in your design that
necessitates something like like this ?
"Julia Donawald"
Hi, I found the mistake why it throws me an exception... so now it works quite well.... what do you think about that solution in general?
participants (3)
-
Edward Diener
-
Jeff Faust
-
Julia Donawald