Re: Characterize parameters by type
* Rune Allnor:
I have an application written in C++ that needs to be
interfaces with matlab. The interface routine needs to
take a number of untyped parameters from matlab
domain, and return a typed object to be passed to the
C++ business routine.
The parameters are:
par1 - vector of either 2 or 4 doubles
par2 - vector of 2 doubles
I would like to implement a test TestParameters that
returns an object which type depends on the combination
of the parameters:
if (par1.size() == 2)
{
if (par2(1) > par2(2))
// return object of class Case1Class
else
// return object of class Case2Class
}
else if (par1.size() == 4 )
{
if (par2(1) > par2(2))
// return object of class Case3Class
else
// return object of class Case4Class
}
else
{
return 0;
}
I can't see how to wrap this into a function that can
be called from the interface routine.
Any suggestions?
As I understand it you have a routine foo() picking up the 'par1' and 'par2'
from some MatLab routine that it calls, and depending on the data you want it
packaged in different C++ types for the purpose of static type checking.
That precludes using 'boost::any', because it implies dynamic checking.
Or, it doesn't completely preclude using 'boost::any', but if you do use
'boost::any' then the caller needs to do the discrimination sort of manually.
What you need is a branch to code that expects only the relevant of the C++
types, and you can't do that automagically by a normal 'return'. If you don't
care about nano-sec performance the simplest solution is to use an exception.
Yes, I know very well that that is *heretical*, since most compilers optimize
for exceptions denoting failure and since C and C++ programmers are obsessively
concerned with nano-sec performance, but this is one of the exceptional cases.
That is, translating from run-time type knowledge to static type knowledge is
almost exactly what an exception /does/, just that it also does a bit more.
The hypothetical client code (callers) syntax
accept_from( foo() )
when( Case1Class const& r )
{
// Deal with Case1Class
}
when( Case2Class const& r )
{
// Deal with Case2Class
}
is then expressed as actual C++ code
try
{
foo();
assert( "Should never get here" && 0 );
}
catch( Case1Class const& r )
{
// Deal with Case1Class
}
catch( Case2Class const& r )
{
// Deal with Case2Class
}
or e.g., if you like to obfuscate the code and make the reader's eyes hurt,
#define ACCEPT_FROM( e ) try{ e; assert( "Should never get here" && 0 ); }
#define WHEN( decl ) catch( decl )
#define PRODUCE( e ) throw e
...
ACCEPT_FROM( foo() )
WHEN( Case1Class const& r )
{
// Deal with Case1Class
}
WHEN( Case2Class const& r )
{
// Deal with Case2Class
}
He he... :-)
Alternatively you can pass callback interface to foo(), an object with with four
methods, one for each type, and let your routine call the approriate one.
I think that's what I'd do, but choose your own poison, even 'boost::any'.
[BTW - what happened to comp.lang.c++? Nothing but spam there. ]
All the [clc++] spam originates with Google Groups. Since the spam dropped off
markedly when Google added captcha, one may tentatively conclude that (a) the
spammers have now broken the captcha thing, and/or (b) the spammers have
realized that the cost of hiring a human to log in is negligible, and/or (c)
it's actually Google doing the spamming, e.g. to promote Google Groups ;-). Now,
I hope Google doesn't sue me but instead perhaps does the sensible thing.
Cheers & hth.,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]