Direct comparing of two QVariant variables
-
It is beyond me why anybody would add such a malicious piece of code on purpose, especially if I could add code with the same or even less effort that works in 95 out of 100 cases and is absolutely type-safe instead of code that breaks on 95 out of 100 cases and has a load of potential pitfalls and limitations attached. But I think this has been stressed enough. In the end it is your decision and your accountability, not mine.
-
[quote author="Lukas Geyer" date="1326781097"]It is beyond me why anybody would add such a malicious piece of code on purpose, especially if I could add code with the same or even less effort that works in 95 out of 100 cases and is absolutely type-safe instead of code that breaks on 95 out of 100 cases and has a load of potential pitfalls and limitations attached[/quote]
Do you actually think that type safety imposed by other means is always less strict?
-
Something that I don't get is why you insist on doing it this way? What do you think is your benefit? Having one line of code less? Do you think this has better performance?
-
[quote]
Do you actually think that type safety imposed by other means is always less strict?
[/quote]Of course not, because the sole purpose of type safety is to be restrictive. It prevents developers from using code that has been written to work with a specific set of datatypes with any other datatype. There is nothing that hinders me to pass any object through the void* pointer in your implementation, not just int, double and const char*. This can be fatal and this is what I meant by saying your code doesn't get flexible, it just gets error-prone.
-
[quote author="KA51O" date="1326785780"]Something that I don't get is why you insist on doing it this way? What do you think is your benefit? Having one line of code less? Do you think this has better performance? [/quote]
In short, because chaining ifs (in whatever form) is a wrong way of doing things (let alone those deadborn template structures). The found solution may be dangerous but to me it is by far a more genuine and elegant way of doing this. Surely, it is not qt's fault that you have to hard-code your types, in c/c++ you cannot just write something like reinterpret_cast<type> where <type> is purely a run-time variable. So the idea of a void* pointer is brought forth as a revolt against this drawback. Yes, it is a wild beast that can kill you in a glimpse but if you know how to handle it all its power is at your disposal
Look, I have QDateTimes which are stored on disk as plain seconds and it takes ages to convert them back and forth. I could bear time when bulding index, but it would be hell to use them to retrieve data. Why not make comparison between those ints leaving these QDateTimes alone, you would ask me. Well, but why then stop half-way and not make direct comparisons between byte arrays, I would ask you? In fact, such comparisons make things even simpler since I already have to deal with raw data, so it won't actually get much worse than that
-
[quote author="Lukas Geyer" date="1326787337"]Of course not, because the sole purpose of type safety is to be restrictive. It prevents developers from using code that has been written to work with a specific set of datatypes with any other datatype. There is nothing that hinders me to pass any object through the void* pointer in your implementation, not just int, double and const char*. This can be fatal and this is what I meant by saying your code doesn't get flexible, it just gets error-prone.[/quote]
Yes, because such is the nature of a void* pointer. The pistol shoots and somebody will surely shoot himself - you cannot make everything bullet or fool proof
-
[quote author="deisik" date="1326790752"][quote author="KA51O" date="1326785780"]Something that I don't get is why you insist on doing it this way? What do you think is your benefit? Having one line of code less? Do you think this has better performance? [/quote]
In short, because chaining ifs (in whatever form) is a wrong way of doing things (let alone those deadborn template structures). The found solution may be dangerous but to me it is by far a more genuine and elegant way of doing this. Surely, it is not qt's fault that you have to hard-code your types, in c/c++ you cannot just write something like reinterpret_cast<type> where <type> is purely a run-time variable. So the idea of a void* pointer is brought forth as a revolt against this drawback. Yes, it is a wild beast that can kill you in a glimpse but if you know how to handle it all its power is at your disposal
Look, I have QDateTimes which are stored on disk as plain seconds and it takes ages to convert them back and forth. I could bear time when bulding index, but it would be hell to use them to retrieve data. Why not make comparison between those ints leaving these QDateTimes alone, you would ask me. Well, but why then stop half-way and not make direct comparisons between byte arrays, I would ask you? In fact, such comparisons make things even simpler since I already have to deal with raw data, so it won't actually get much worse than that[/quote]
I understand your approach and there may be uses cases were this solution is valid, but unless it is absolutely neccessary I would not use this solution.
-
[quote author="deisik" date="1326790823"]Yes, because such is the nature of a void* pointer. The pistol shoots and somebody will surely shoot himself - you cannot make everything bullet or fool proof[/quote]
[quote]The found solution may be dangerous but to me it is by far a more genuine and elegant way of doing this.[/quote]
Well, let's just agree that we have different development principles.
I wish you the best with your solution, but I'm officialy out now as this discussion obviously leads nowhere and is rather pointless at this moment.
-
[quote author="Lukas Geyer" date="1326794366"][quote author="deisik" date="1326790823"]Yes, because such is the nature of a void* pointer. The pistol shoots and somebody will surely shoot himself - you cannot make everything bullet or fool proof[/quote]
[quote]The found solution may be dangerous but to me it is by far a more genuine and elegant way of doing this.[/quote]
Well, let's just agree that we have different development principles.
I wish you the best with your solution, but I'm officialy out now as this discussion obviously leads nowhere and is rather pointless at this moment.[/quote]
Hi,
same for me. Just one last word from myself:
I would not try to optimize (and it looks like that to me) before you really know, where the bottleneck is. In one or two (or many) years, some other people might have to maintain the code and will they know what was done there? Will they understand? What will they do if new types will be introduced and they do not fit into this schema?
Just some thoughts.
-
If you just want total ordering, then there is no problem with comparing different types (actually you don't have to compare different types in order to have deterministic operator "less"):
bool operator<(QVariant const& lhs, QVariant const& rhs) { if (lhs.type() == rhs.type()) { return ... // types are same, can compare } else { return lhs.type() < rhs.type(); } }
Having this one can use QVariant as map key.