Safer casts

[Dee Girl]

Yigal Chripun Wrote:

> 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.

I do not think so. In fact I am sure you are entirely wrong this time.

mysort has a signature that is not parameterized. The language definitions (I just read again) implies the model of compiling is that not-parameterized functions have only one implementation.

If mysort has only one implementation, it is not possible for mysort to use different instantiations of sort. It is called the pigeonhole principle. It uses only one instantiations for all calls. Unless D generates code at runtime. ^_^

> 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.

I understand that very well (better than English...) I did just implemented a compiler for a mini-pl0 language with generics in class. These problems of code duplication are very clear when I wrote the compiler my self! ^_^ But maybe you did not understand how mysort works without duplicating code.

> 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.

If you believe this then you should be happy with std.sort. Which gives the option to optimize for what you want. All other sort implementation I read only go one way and it's hard to make them go an other way.

> > 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.

But you want to use one tool for all job. You want indirect calls and they force your design only one way.

> 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).

Maybe once it is clear the inclusion relationship: that with the template you can have dynamic. Then you will be happy. Dee Girl