Re: Characterize parameters by type
* Rune Allnor:
On 30 Jun, 20:37, "Alf P. Steinbach" <al...@start.no> wrote:
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.
Eh... right. No, performance is not an issue - at least
not for now - but it's been hot for a few days now and
I need to think about this one.
Interesting. I've posted a couple of newbie questions
in the past, about how to use exceptions in control loops.
Now at last, when I thought I understood why that's not
a good idea, you come up with this.
He he... :-)
I must admit I thought about the base-class / derived-class
hierarchy just after I posted the first post yesterday,
before the first reply appeared.
Hm, I think you're referring to mzdude's reply, about using a polymorphic
function result.
That defeats the goal of static type checking, so it's just ungood.
However mzdude's alternative suggestion of using boost::any can work, with the
caveat I noted, that it involves some "manual" discrimination.
The exception thing is better technically, but since it's very unconventional it
may not be the best choice with respect to maintainance (or, it may be).
However, given your new more clear description of the problem (else-thread),
that foo() is called with MatLab args, that is, that those args do not stem from
a call *to* MatLab, packaging the type discrimination as a general routine only
makes sense if you have several different routines that are called by MatLab,
all with the same convention for dynamic type specification.
Is that the case?
If not, then just do the discrimination directly in the single routine called by
MatLab. Or perhaps factor the logic out as a routine returning an enum, then do
a switch. The *simplest* is often the best. ;-)
Your suggestion is just insane enough to be appealing.
Yeah. In the land of the blind, the one-eyed man has a very troubled life. ;-)
We may laugh at Monty Python's flotation test for whiches (floats => which, so
burn her/him, drowns => uh oh, not a which), but since we're both Norwegians: as
far as I know that test was invented in and only practiced in Norway...
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! ]