Safer casts

[Yigal Chripun]

Dee Girl wrote:
> Yigal Chripun Wrote:
> 
> 
> This should be good for the standard library. It is the most flexible
> approach. You can always do what you want in one line:
> 
> void mysort(int array[], bool delegate comp(int, int)) { 
> sort!(comp)(array); }
> 
> Now you can call mysort many times and there is only one version of
> std.sort (if I understand it correctly).

not exactly. there's always a balance between memory and time, if you
improve the first second worsens.
for each different comp function there will be a different sort instance
created by the compiler.
a simple example:
struct num(N) { int number = N; }
num!(1) is different from num!(2);
so with this method you'll get a bigger executable that contains the
sort code twice.
with my way on the other hand you'll always have only one sort function.
the cost in my case is that sort will always call the comp function to
compare while the template can avoid that function call. simply time vs.
memory. memory is cheap nowadays and the linker could be made better to
try to minimize the memory footprint. on the other hand cpu chips today
come with multi-cores and the compiler could optimize many calls to
small functions. so in the obj file, the compiler can inline the
function body instead of calling it.
the main question would be: what are you optimizing for?
if you develop on a cellphone memory could be more important then time,
but on a missile a nano second could mean the missile missed its target.
so it all depends on what you want to achieve.

> 
> But think what if your mysort is the only implementation given in the
> standard library. Maybe sometimes it is too slow for your program.
> What do you do?
> 
> void fastsort!(alias comp)(int[] array) { bool dg(int a, int b) {
> return comp(a, b); } mysort(array, dg); }
> 
> This will not be faster at all ^_^. As a friend said: You can build a
> dynamic library from a static one but not inverse. Things only stack
> one direction. I think it is good the way sort is now in the standard
> library, it offers the maximum possible and opens all options. It is
> very impressive for someone coming from many other language.
> 
>> Now, when you use a string with the template, the sort will contain
>> the code itself inline to the sort instance so it "saves" you a
>> function call. IMO, the string solution is not clean ( C MACROs?
>> )and while for simple cases it could save you a function call it's
>> premature optimization IMO.
> 
> To me it looks very convinent!
> 
>> Also, if I use delegates, I can't see how a template can save that
>> function call. so it just bloats my executable with unneeded copies
>> of sort.
> 
> You can use mysort above. It is my first contribution to D. ^_^
> 
>> I hate when library code forces me to this. I think the programmer
>> knows his code better than the library writer and should be able to
>> choose himself whether he needs to use a compile time solution to
>> save function calls or a run-time solution to prevent unnecessary
>> executable bloat. this optimization should be made by the
>> programmer and _not_ the library writer. This solution does not
>> give me that freedom.
> 
> It looks like you understand the exact oposite. std.sort gives you
> all freedom, anything else would give less. I have studied many
> languages but none offers the same flexibility. Functional languages
> force you to copy. Java, Smalltalk and C# force virtual calls on
> comparisons. C++ force you to go outside your function and write the
> comparison even simple as a.member < b.member! D is the best and
> std.algorithm very elegant.
> 
>> this solution is a classic STL piece of code, BUT, the main
>> difference is that for C++ this is probably the only reasonable
>> solution as C++ doesn't have delegates. this is why when coding for
>> D I urge people to rethink their solution instead of just doing
>> what is best in C++ (or any other preferred language of the library
>> writer). This is a prime example why the C++ solution is wrong for
>> D.
> 
> The other rant you wrote and the interesting discussion with Janice
> are good to read. But there is little objective points you bring. I
> see you do not like anything like C++ and then you go back and try to
> make arguments.
> 
> One objective point is you like a container hierarchy. I have worked
> with them and they can be useful. But like with mysort the same
> argument works. You can build a hierarchy of containers on top of
> fast containers. But not the inverse. Dee Girl

My rant emphasizes specific things, since that's the point of a rant. I
could talk about all the things I like in C++ and Janice would agree and
we won't have anything interesting to talk about. I do use c++ and it is
a powerful language. My point is not that I'm against templates, or that
I hate C++. What i'm trying to say is that using any one tool for
everything is wrong. I'm not arguing that delegates should replace all
template code in D! I'm arguing that both solutions need to be evaluated
and the better one chosen, also note that these two options overlap
sometimes and (when it's suitable) both solutions should be provided so
the user could choose his preferred trade-off (time vs. memory).

--Yigal