www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Please remove ?:

reply Lionello Lunesu <lio lunesu.remove.com> writes:
I just run accross the following code at my work:



Took at least a minute to figure out what was going on.

Please remove ?:... It's useless, slow (just like if/else, but looks 
faster since it's so "convenient") and unreadable!

L.

(and removing it will free up the "?" for writefln!! :D)
Jun 02 2006
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Lionello Lunesu wrote:
 I just run accross the following code at my work:
 

 
 Took at least a minute to figure out what was going on.
 
 Please remove ?:... It's useless, slow (just like if/else, but looks 
 faster since it's so "convenient") and unreadable!
Useless? I've put it to plenty of use. So have many C programmers, some of which have moved on to D. Slow? I'm surprised. Do you have a benchmark? Unreadable? To me, it's certainly more readable than some code.
 L.
 
 (and removing it will free up the "?" for writefln!! :D)
What do you want it to do in writefln? Stewart.
Jun 02 2006
next sibling parent mclysenk <mclysenk_member pathlink.com> writes:
In article <e5pf9l$1363$1 digitaldaemon.com>, Stewart Gordon says...
Lionello Lunesu wrote:
 (and removing it will free up the "?" for writefln!! :D)
What do you want it to do in writefln?
Maybe QBasic style printing? Mik
Jun 02 2006
prev sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Stewart Gordon wrote:
 Lionello Lunesu wrote:
 I just run accross the following code at my work:



 Took at least a minute to figure out what was going on.

 Please remove ?:... It's useless, slow (just like if/else, but looks 
 faster since it's so "convenient") and unreadable!
Useless? I've put it to plenty of use. So have many C programmers, some of which have moved on to D.
??? I've multiple inheritance to use, "so have many C++ programmers, some of which have moved to D." By useless I meant that it can be replaced by if/else, so it does not fill in a void.
 Slow?  I'm surprised.  Do you have a benchmark?
Just as slow as if/else: asm { cmp x,y jne l1 nop ;case one jmp l2 l1: nop ;case two l2: } It'll always jump.
 Unreadable?  To me, it's certainly more readable than some code.
The if would be more readable. I find it "unreadable", mostly because there's not really a limit to what you put between ? and :.. I agree it's handy now and then, but I really would like it to be limited to constants or something.
 
 L.

 (and removing it will free up the "?" for writefln!! :D)
What do you want it to do in writefln?
Remember ? from basic? It's a joke.. nevermind :S
Jun 02 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Lionello Lunesu wrote:
 Useless?  I've put it to plenty of use.  So have many C programmers, 
 some of which have moved on to D.
By useless I meant that it can be replaced by if/else, so it does not fill in a void.
And all looping can be done with recursion, yet we also have for, while, do..while, and foreach. Sean
Jun 02 2006
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Lionello Lunesu wrote:
 Stewart Gordon wrote:
<snip>
 Useless?  I've put it to plenty of use.  So have many C programmers, 
 some of which have moved on to D.
??? I've multiple inheritance to use, "so have many C++ programmers, some of which have moved to D."
?: is a much simpler feature to implement than MI.
 By useless I meant that it can be replaced by if/else, so it does not 
 fill in a void.
Consider a case where a more complicated expression may have a ?: expression within it. Then can you think of a way of writing it instead that's nearly as concise?
 Slow?  I'm surprised.  Do you have a benchmark?
Just as slow as if/else:
<snip> Then why not remove if/else because it's slow? Moreover, language features are not "slow". What may be slow, however, is the code generated by a particular compiler to implement a particular language feature. Stewart.
Jun 06 2006
prev sibling next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Lionello Lunesu schrieb:
 I just run accross the following code at my work:
 

 
 Took at least a minute to figure out what was going on.
same like value = NoWallCheck ? _T("0") : _T("1"); think of printf("%s",bBool ? "true" : "false");
 It's useless
it is handy
 slow 
???
Jun 02 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
dennis luehring wrote:
 Lionello Lunesu schrieb:
 I just run accross the following code at my work:



 Took at least a minute to figure out what was going on.
same like value = NoWallCheck ? _T("0") : _T("1"); think of printf("%s",bBool ? "true" : "false");
I admit it's handy, but it should be limited to constants or something. In that case the compiler could also use a small look-up table for the two values, to get rid of the jmp instruction.
 
  > It's useless
 it is handy
It's sugar, nothing more. D should be RISC :)
 
 slow 
???
?: always results in a jump instruction. My knowledge of performance penalties dates back to the 486 era, so it _might_ not be that big a deal now with branch prediction and what not. L.
Jun 02 2006
parent reply pragma <pragma_member pathlink.com> writes:
In article <e5pjto$1bdj$1 digitaldaemon.com>, Lionello Lunesu says...
It's sugar, nothing more. 
This is not entirely true. The result of an if/else cannot be used as an rvalue, whereas '?' can. As it suits a very particular use scenario, it's no more sugar than it is an alternate way to express if/else with this added *advantage*. uint foobar = gorf() ? foo : bar; -vs- uint foobar; if(gorf()){ foobar = foo; } else{ foobar = bar; } Being more direct and to the point leads to more readable and thus maintainable code. Its really a good thing to have, provided its used responsibly (as with all of D's language constructs).
 D should be RISC :)
In principle, this is a grand idea. It means easy compiler construction, and an easy to understand language format. Everybody wins, and there's no more debate on what gets added to the language since simple is king - if anything, there's debate on what should be taken out in favor of a more rudimentary syntax. In practice it fails miserably*, since coders are *always* in the game of creating shortcuts. This is why we write libraries, adopt design principles like encapsulation and OOP, and press for more concise ways to express common idioms in the D language itself. So we choose classes over structs w/func-pointers and switch() over elaborate if/else statements where appropriate, even though they're functionally equivalent. We're also in the game of being very elaborate and "poetic" in a sense, in order to achive some cosmetic or practical effect. This is where templates, mixins and interfaces help make library users' lives a little easier. So ultimately you have all kinds of functional overlap in D *everywhere*, because every bit of overlap is done with some additional features that cover yet more use-cases and idioms. Please understand that I'm not advocating that D become this bloated monster mismash of features, but I hold onto the certainty that there is a balance point that allows for some healthy redundancy. *- Lisp is probably the only good example of a high-level language that has a RISC philosophy to its design. It also has some rather impressive achievements under its belt but its anything but "widely used" when compared to C or Java. I still file it under the 'failed' category only for this reason: it hasn't displaced other languages despite having been around for so long. - EricAnderton at yahoo
Jun 02 2006
parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"pragma" <pragma_member pathlink.com> wrote in message 
news:e5pr7d$1jmt$1 digitaldaemon.com...
 Being more direct and to the point leads to more readable and thus 
 maintainable
 code.  Its really a good thing to have, provided its used responsibly (as 
 with
 all of D's language constructs).
It's true that if you want to write unreadable code, you can do so no matter what, and there's little the grammar can do to prevent that.
 D should be RISC :)
In principle, this is a grand idea. It means easy compiler construction, and an easy to understand language format. Everybody wins, and there's no more debate on what gets added to the language since simple is king - if anything, there's debate on what should be taken out in favor of a more rudimentary syntax. In practice it fails miserably*, since coders are *always* in the game of creating shortcuts. This is why we write libraries, adopt design principles like encapsulation and OOP, and press for more concise ways to express common idioms in the D language itself. So we choose classes over structs w/func-pointers and switch() over elaborate if/else statements where appropriate, even though they're functionally equivalent.
(switch() does a table look-up or a binary search, so it really stands on its own.)
 So ultimately you have all kinds of functional overlap in D *everywhere*,
 because every bit of overlap is done with some additional features that 
 cover
 yet more use-cases and idioms.  Please understand that I'm not advocating 
 that D
 become this bloated monster mismash of features, but I hold onto the 
 certainty
 that there is a balance point that allows for some healthy redundancy.
I totally agree. I must admit that my original post was highly emotional. Just thought the code that I've encountered should have been illegal to begin with. I also agree that ?: has its uses, but I wonder if it can be limited to select 1 of 2 constants / literals. I mean, could the grammar be changed to only allow constants / literals after the ?. L.
Jun 03 2006
prev sibling next sibling parent "Derek Parnell" <derek psych.ward> writes:
On Fri, 02 Jun 2006 22:57:14 +1000, Lionello Lunesu  
<lio lunesu.remove.com> wrote:

 I just run accross the following code at my work:



 Took at least a minute to figure out what was going on.

 Please remove ?:... It's useless, slow (just like if/else, but looks  
 faster since it's so "convenient") and unreadable!

 L.

 (and removing it will free up the "?" for writefln!! :D)
This is hard to read because the author wrote that way. An alternative could have been .. value = _T( NoWallCheck ? "0" : "1" ); Or maybe you prefer the long hand format ... { char[] temp; if (NoWallCheck) temp = "0"; else temp = "1"; value = _T(temp); } Or maybe ... if (NoWallCheck) value = _T("0"); else value = _T("1"); The ?: operator does not have to be obscure or inefficient. -- Derek Parnell Melbourne, Australia
Jun 02 2006
prev sibling next sibling parent reply Ivan Kazmenko <gassa mail.ru> writes:
Please remove ?:... It's useless, slow (just like if/else, but looks 
faster since it's so "convenient") and unreadable!
Well it's slightly less readable than if..else because of operator precedence issues. However, it's the responsibility of the program author to make it clear, and there are situations when it's convenient to use branched result as an rvalue. These are what ?: is for. What makes me wonder is why ?: looks faster. Does * look faster than /, then? Yet, it is on modern PCs. In my humble opinion, a programmer should not, generally speaking, judge expressions' performance by how many words or keywords are used. Ivan Kazmenko.
Jun 02 2006
parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
 What makes me wonder is why ?: looks faster. Does * look faster than /, 
 then?
 Yet, it is on modern PCs. In my humble opinion, a programmer should not,
 generally speaking, judge expressions' performance by how many words or 
 keywords
 are used.
When I'm writing libraries, I tend to give longer, complicated names to functions that are slow. People using libraries don't know the performance of a function, and with all that intellisense stuff, they don't read the docs. If you have an array and want to check whether it contains item X, they select "Contains(X)" from the intellisense popup and that's that. I had to rename the function to get it through to them that you don't want to be calling Contains(X) (doing a linear search) in an inner loop :S Similarly, I think ?: looks faster than if...else but it's exactly the same construct (ok, ?: can also be an rvalue), resulting in the same code. * and / both result in 1 cpu instruction; 1 token -> 1 instruction seems perfect : ) L.
Jun 03 2006
parent Ivan Kazmenko <gassa mail.ru> writes:
When I'm writing libraries, I tend to give longer, complicated names to 
functions that are slow. People using libraries don't know the performance 
of a function, and with all that intellisense stuff, they don't read the 
docs. If you have an array and want to check whether it contains item X, 
they select "Contains(X)" from the intellisense popup and that's that. I had 
to rename the function to get it through to them that you don't want to be 
calling Contains(X) (doing a linear search) in an inner loop :S
Hmm, you have the point here. However, I doubt many people use the same method, AFAIK, most folks use names to make clear what the function does and docs or comments or source code to explain how it is done. Ivan Kazmenko.
Jun 03 2006
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Lionello Lunesu" <lio lunesu.remove.com> wrote in message 
news:e5pcja$td0$1 digitaldaemon.com...

 Please remove ?:...
I'll agree with you to an extent, though keep in mind that I am of the opinion that the tradeoff of a bit more space for a lot more readability is a Good Thing (TM). ?: can be abused, certainly, but so can most of the other language constructs. That code that you show is certainly abuse; any code where the effect isn't immediately obvious is, in my opinion, badly-written. I've seen conditional statements nested three deep before. It's not a pretty thing. I rarely use ?:, and when I do, it's always something very short and obvious, such as char[] name = (numApples > 1) ? "apples" : "apple"; However, there will always be programmers who _like_ to nest conditional statements three deep, and because D is a practical language and not an ideological language, ?: won't be going away.
Jun 02 2006