Re: Characterize parameters by type
On 1 Jul, 10:55, "Alf P. Steinbach" <al...@start.no> wrote:
* 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.
....
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.
Yep.
That defeats the goal of static type checking, so it's just ungood.
With the caveat that I don't have the grasp of C++' tech
lingo, *one* plymorphic result is what I want to return
from this argument check routine.
As for 'ungood', it's not a solution I would have chosen
anywhere else, but I'm constrained by how matlab is already
doing things.
Also keep in mind that I tend, as far as possible, to use
argument type matches, as opposed to switch-case constructs,
to discriminate between options whereever I can. This
'idee fixee' of mine pretty much dominates how I design
my programs.
Now, due to the constraints of the context of this particular
program, I can not avoid them completely (I do need to
perform such a test on the argument recieved from matlab),
but once it is done, I prefer to use polymorphism based
on types, everywhere else.
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?
Yes. Specifically, I have a number of routines for designing
digital filters. The C++ design routines take a filter
specification object as argument, and based on the type
of this argument the proper computations are done:
class GenericFilterSpec{};
class LowPassSpec : public GenericFilterSpec{};
class HighPassSpec : public GenericFilterSpec{};
class BandPassSpec : public GenericFilterSpec{};
class BandStopSpec : public GenericFilterSpec{};
So in the interface routine the user calls from matlab,
I need a way to transform the input arguments, that
describe the desired response, to the classes the
business routines require as arguments.
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. ;-)
Well, yes, maybe. Maybe the size of this particular problem
(just four options) is too small to warrant an involved
solution, but I want to get a grasp of the ideas.
And agian: I just don't want to use switches and enums
if I can in any way avoid it. At some time this C++ filter
design class might be expanded by more awkward stuff.
There are no reasons to expect that such expansions would
fit nicely into the enum frame.
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...
Ah. All of a sudden a lot of stuff made a lot more sense...
Actually, I'm a bit more hesitant today than I was yesterday.
Getting back to your code:
try
{
foo();
assert( "Should never get here" && 0 );
}
catch( Case1Class const& r )
{
// Deal with Case1Class
}
catch( Case2Class const& r )
{
// Deal with Case2Class
}
Now, you might have removed switch-case *syntax*, but you
haven't removed the undesireable switch-case *construct*:
- There is a test for the argument
- There is a list of individual steps
that match each possible outcome of the test.
As I said above, I just don't like this kind of stuff,
so I don't want to use it if I have half a choise.
Of course, one could set up a class hierarchy for the
exceptions, similar to the filter specs above, and use,
say, a visitor pattern to get the correct routines called.
But if you do, you are back to mzdude's solution, only
this time it is obfuscated by being wrapped inside the
exception mechanism, which makes for a highly unusual
control loop construct.
Nah, I think mzdude's polymorphic return is the one
I'll be investigating further.
Rune
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]