[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: Considering adding a "dispatch" function for compile-time polym
From: |
John W. Eaton |
Subject: |
Re: Fwd: Considering adding a "dispatch" function for compile-time polymorphism |
Date: |
Sat, 09 Aug 2014 13:21:51 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 |
On 08/08/2014 03:40 PM, David Spies wrote:
How is the type of resvec unknown? It appears to me that the type
of resvec is R.
R is a template parameter. That's what I meant by unknown
That doesn't make it unknown. It has type R, which presumably must
provide some kind of interface to be used. And the way it is currently
used, it is actually constructed inside the function because you have
resvec = R (res_dims);
inside the function even though resvec is passed by reference.
But putting stuff in a namespace doesn't actually make it private,
so if you really want to have all these internal/private functions,
maybe some other mechanism is appropriate?
Not in C++. We already had this whole discussion and I thought the
final decision was that the best approach would be to use a namespace to
conceal the "private" functions.
Perhaps I agreed that introducing a namespace would OK even though we
are not doing that uniformly in Octave yet. (We probably should be, but
that's a much larger and separate issue.) However, I don't recall
agreeing that using a namespace should imply that anything inside the
namespace is somehow considered private. That certainly won't be true
of any other namespaces we introduce in Octave later, and I don't think
it is a good convention.
There has to be a better name than "find_to_R". Just "find" would
be better. Most functions do something and store the result in some
object, but they are not all named VERB_to_OBJECT and naming
something that way does not help with understanding.
There already is a "find".
With the same signature?
As it is, your two switch cases are nearly identical copy-pasted
code. Perhaps I'm wrong, but I think there has to be a better way of
writing this.
Three lines of copy-pasted boilerplate right next to each other is a
very different thing from copy-pasting the entire find function.
Perhaps, but if the find function works on iterators, why would copy and
pasting be needed at all? Wouldn't it be the same in both cases, with
the iterator handling the direction? Isn't the function essentially
something like
find (iterator it, accumulator acc)
{
while (it != it.end ())
{
if (it.value ())
acc.record_location (it);
it.next ();
}
}
In find.cc:
namespace find
{
[...]
template<int nargout, typename T>
struct ffind_result;
Something I forgot to mention earlier is that I'm not really sold on
this style of using constant template parameters. Something about this
feels clunky and wrong to me, so if you think this is a good way to
write this code, you're going to have to convince me of that.
jwe