On 7/16/2011 2:01 PM, Andrei Alexandrescu wrote:
On 7/16/11 10:50 AM, d coder wrote:
Sorry for bumping. Want to know if there is a solution to the situation
I face often.
I think this is a reasonable thing to want, but it's difficult to
implement technically. You want a comparitor with state (which is
fine), but at the same time the state must be cleverly wired during
construction of the enclosing class object.
I'll think of a reasonable workaround or library fix, if I come with
anything I'll post here.
Andrei
I think this is a _really_ good reason why we shouldn't use the template
hammer for every nail we see. D templates are nice, but I think they're
being used a bit more than they should be.
I'm actually still confused at why _functions_ should be passed as
template parameters -- that just doesn't make much sense to me, because:
1. If it's an optimization issue, it's overkill, since the benefits
don't really justify it. A good compiler would just examine the
parameter itself in the same exact way.
2. Problems like this can be difficult to solve, as was mentioned.
3. Templates are *useless* in shared libraries. Sure, they work as long
as you want to give others the source to your code and don't care about
code bloat, but as soon as you want a bit more structure, templates are
just the exact opposite of what you're looking for.
I think this problem could simply be solved if BinaryHeap instead took a
parameter in its structure as a comparator, like in most other
programming languages. Is there a good reason why this (and pretty much
everything else) is becoming templated?
