digitalmars.D - Please remove ?:
- Lionello Lunesu (7/7) Jun 02 2006 I just run accross the following code at my work:
- Stewart Gordon (7/18) Jun 02 2006 Useless? I've put it to plenty of use. So have many C programmers,
- mclysenk (3/6) Jun 02 2006 Maybe QBasic style printing?
- Lionello Lunesu (21/41) Jun 02 2006 ??? I've multiple inheritance to use, "so have many C++ programmers,
- Sean Kelly (4/10) Jun 02 2006 And all looping can be done with recursion, yet we also have for, while,...
- Stewart Gordon (12/23) Jun 06 2006 ?: is a much simpler feature to implement than MI.
- dennis luehring (6/13) Jun 02 2006 same like
- Lionello Lunesu (9/27) Jun 02 2006 I admit it's handy, but it should be limited to constants or something.
- pragma (41/43) Jun 02 2006 This is not entirely true. The result of an if/else cannot be used as a...
- Lionello Lunesu (13/42) Jun 03 2006 It's true that if you want to write unreadable code, you can do so no ma...
- Derek Parnell (23/30) Jun 02 2006 This is hard to read because the author wrote that way. An alternative
- Ivan Kazmenko (9/11) Jun 02 2006 Well it's slightly less readable than if..else because of operator prece...
- Lionello Lunesu (12/18) Jun 03 2006 When I'm writing libraries, I tend to give longer, complicated names to
- Ivan Kazmenko (4/11) Jun 03 2006 Hmm, you have the point here. However, I doubt many people use the same ...
- Jarrett Billingsley (15/16) Jun 02 2006 I'll agree with you to an extent, though keep in mind that I am of the
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
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
In article <e5pf9l$1363$1 digitaldaemon.com>, Stewart Gordon says...Lionello Lunesu wrote:Maybe QBasic style printing? Mik(and removing it will free up the "?" for writefln!! :D)What do you want it to do in writefln?
Jun 02 2006
Stewart Gordon wrote:Lionello Lunesu wrote:??? 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.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?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.Remember ? from basic? It's a joke.. nevermind :SL. (and removing it will free up the "?" for writefln!! :D)What do you want it to do in writefln?
Jun 02 2006
Lionello Lunesu wrote:And all looping can be done with recursion, yet we also have for, while, do..while, and foreach. SeanUseless? 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.
Jun 02 2006
Lionello Lunesu wrote:Stewart Gordon wrote:<snip>?: is a much simpler feature to implement than MI.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.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?<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.Slow? I'm surprised. Do you have a benchmark?Just as slow as if/else:
Jun 06 2006
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 uselessit is handyslow???
Jun 02 2006
dennis luehring wrote:Lionello Lunesu schrieb: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.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 handyIt's sugar, nothing more. D should be RISC :)?: 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.slow???
Jun 02 2006
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
"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.(switch() does a table look-up or a binary search, so it really stands on its own.)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.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
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
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
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
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 :SHmm, 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
"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