I just run accross the following code at my work:

#  NoWallCheck?value=_T("0"):value=_T("1");

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)

Lionello Lunesu wrote:
> I just run accross the following code at my work:
> 
> #  NoWallCheck?value=_T("0"):value=_T("1");
> 
> 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.

Lionello Lunesu schrieb:
> I just run accross the following code at my work:
> 
> #  NoWallCheck?value=_T("0"):value=_T("1");
> 
> 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 
???

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

Stewart Gordon wrote:
> Lionello Lunesu wrote:
>> I just run accross the following code at my work:
>>
>> #  NoWallCheck?value=_T("0"):value=_T("1");
>>
>> 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

dennis luehring wrote:
> Lionello Lunesu schrieb:
>> I just run accross the following code at my work:
>>
>> #  NoWallCheck?value=_T("0"):value=_T("1");
>>
>> 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.

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

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

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:
>
> #  NoWallCheck?value=_T("0"):value=_T("1");
>
> 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

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