Safer casts
Dee Girl
deegirl at noreply.com
Mon May 12 12:55:57 PDT 2008
Yigal Chripun Wrote:
> my issues with the use of this syntax:
> a) what if I had a typo?
algorithm.d(2528): Error: binaryFun(ElementType1,ElementType2) is not an lvalue
algorithm.d(2528): static assert "void*"
Maybe the static assert message should be better. What if it says: Your comparison function is invalid?
> what if i typed n instead of b (they are next
> to each other on my keyboard)?
Same message is written.
> your solution or any other string
> solution cannot check this, since it is syntactically valid D code
> inside the string.
> b) if I want to compare q{a.member > b.member} there is no check that
> member exists, or any other type checking. the error would occur in the
> template code itself not in the string in both of the above examples.
Same message is written again.
> c) what if I forgot to type the "q"?
./test.d(9): found '}' when expecting ';' following 'statement'
At least now it is in your file ^_^
> d) most IDEs mark strings with a different color or something like that
> so I treat them automatically as data and not code. ( this is a minor
> issue, since IDEs could be made to work differently. but, my
> sub-conscience response to strings as "not code" is harder to fix)
The strings are short otherwise they anyway are better as functions. I do not think this could be a problem.
> the only benefit to this is a slight performance benefit (though a good
> compiler could provide the same performance by inlining a function call)
> and a slightly shorter syntax which is a personal preference since you
> type less but IMHO it becomes less readable and less obvious.
I think it is very readable and obvious for reasons below.
> I prefer:
> sort!((int a, int b) {return a.member > b.member;})(array);
> this is more typing but provides all the checks and is more readable.
It is nice you can do both. You can put a string when it is small. You double the size of the code to write. When you have long comparison, you make it separate function. What I think is best of D when coming from other languages is that it gives so much options in such small core.
> Think of the poor guy that will need to do maintenance on your code
> years from now. now the string is a cool quick'n'dirty solution to the
> problem at hand but in the future that other programmer will have no
> idea what those "a" and "b" are. especially since you didn't write the
> types of them.
Here you may be wrong two times. First I tell from experience. I worked internship for a biotech company in Boston. I thought it will be research but it was so much work! ^_^ They used Perl and I did not know Perl when I began. But then I learned it and it has many nice things. One is sort which looks like this
sort { $a <=> $b } array;
I remember: first time I saw sort I understood how it works. The only odd thing was <=> but that means -1, 0 or 1 if a is less, equal or greater than b. I thought Perl has the most elegant definition of sort but now I think D has it.
Second you may be wrong because you think types help. They do not help in fact they may un-help. Write this
long array[] = ...;
sort!((int a, int b) {return a > b;})(array);
Sadly D lets long -> int conversion go through. Code will compile and run! But it gives wrong results for big numbers.
For sort type deduction is best. You should write
sort!((auto a, auto b) {return a > b;})(array);
And that works with int, long, float, string and all types that have >. It is the best writing of the intent of the sort. But I do not know how much type inference the D compiler can do.
> also the performance could be the same if I used a function instead of a
> delegate allowing the compiler to inline it (hopefully).
Good abstraction is the best. Performance is a good bonus ^_^
> since this is identical to:
> sort(array, (int a, int b) {return a.member > b.member;});
> there is no benefit in making it a template, IMO.
I hoped I convinced you otherwise. After all effort still no understanding? Templates are best. They give you static and dynamic. Dynamic only gives dynamic.
> side note: using a feature of arrays in D this could be also rewritten as:
> array.sort((int a, int b) {return a.member > b.member;});
Would be nice to allow array.sort!(cmp).
> Again, this is only my opinion (and I do prefer higher level solutions
> and think the compler/linker can do a better job optimizing than I can).
> you do not have to agree with this view, and there are already people
> that disagree.
Different views of same issues is good. But I see there are some things about which you are simply wrong because you do not understand how they work. Then I waste time explaining ^_^ Thank you, Dee Girl
More information about the Digitalmars-d
mailing list