Mehrdad wrote:
> 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.
There are no good compilers if that is your definition of a good compiler (such
a
good compiler would have to know exactly what kind of tradeoffs the programmer
had
in mind when writing the code), and DMD is not the best inliner.
Even a good compiler would not be allowed to optimize away the 2 words of
overhead
the delegate adds to the struct.
> 2. Problems like this can be difficult to solve, as was mentioned.
The code is probably broken if it is possible to change the behavior of the
comparison function for BinaryHeap during runtime. The solution to that is to
make
the 'signed'
variable a template parameter:
class Foo(bool signed) {
private bool cmp(uint a,uint b){return signed?a>b:b>a;}
BinaryHeap!(uint[],cmp) heap;
void bar () {/* uses heap */}
void frop () {/* uses heap */}
}
void main() {
Foo!false foo;
}
Sure, this does not solve the original problem, if it was really an issue.
@d coder: do you have an example where runtime changing of the comparison
function
behavior would be required?
> 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.
This renders them useless as (implementation and interface), but not as
(implementation xor interface).
It is not an issue for Phobos. The code is open source and has to be available
for
CTFE anyways.
Code bloat is only an issue if you instantiate the same template over and over
with different parameters, in which case you might indeed be looking for a
dynamic
solution.
Is there evidence that code bloat is a problem for Phobos?
>
> 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?
It should not be a problem for BinaryHeap, as there are typically few meaningful
variants to compare the same data. (and if you want to stop templating on the
datatype, you really want a generic C container library).
When you are talking about other programming languages, how many of them have
templates?
The C++ STL data structures take the comparator as a template parameter.
Cheers,
-Timon
