March 16, 2005
Andrew Fedoniouk wrote:

> In my opinion following code:
> 
>       uint flags = ...some bit flag value...;
> 
>       uint f = DT_NOPREFIX | DT_SINGLELINE;
>       switch( flags & 0xF)
>       {
>         case Graphics.DRAW.LEFT: f |= DT_LEFT; break;
>         case Graphics.DRAW.RIGHT: f |= DT_RIGHT; break;
>         case Graphics.DRAW.CENTER: f |= DT_CENTER; break;
>       }
>       switch( flags & 0xF0)
>       {
>         case Graphics.DRAW.TOP: f |= DT_TOP; break;
>         case Graphics.DRAW.BOTTOM: f |= DT_BOTTOM; break;
>         case Graphics.DRAW.MIDDLE: f |= DT_VCENTER; break;
>       }
>       ..... use of translated 'f' ....
> 
> is perfectly valid and yet logicaly clear.
> 
> But DMD/Walter does not like it for some reasons.

The reason, as given below, is to "catch the common programming error"

It is similar to other constructs, like not allowing "for (...);" loops
or making "if (a = b)" an invalid statement ? All of these DO stop bugs.

> absence of default: break; branch being
> compiled with -debug flag generates an exception in runtime (only, sic!) and
> compiled with -release flag generates no exception in runtime.

The -debug flag has nothing to do with this, it's just -release or not.
(it's about if you want to check the contract for the switch statement?)

> This is, IMO, just unacceptable.
> Either it shall not compile at all either it shall not generate an exception
> (btw: in some very strange place in debugger).

It is rather clear in the D language specification,
http://www.digitalmars.com/d/statement.html#switch:

> # If none of the case expressions match, and there is not a default
> # statement, a SwitchError is thrown. The reason for this is to catch the
> # common programming error of adding a new value to an enum, but failing
> # to account for the extra value in switch statements.

Note that if all the cases match, there will never be a SwitchError...
And if you don't want to list eg. all DRAW states, you can use "default"

> # This behavior is unlike C or C++.

Yet, D still provides the "no asserts" option of -release which makes
the old C code still work and shut up - even if it is now invalid in D.

> And yet I don't understand intentions of forcing 'default' in 'switch'.
> I am pretty sure that this was already discussed many times in the past.
> Could somebody provide me a link for the discussion?
> I would like to know intentions.

It is to catch missing, or mispelt, cases in long and complex switches.

It's really not *that* much work to add default: or default: assert(0);
to the old C switches, to make them pass all D warnings and contracts ?

Note that the new D warnings do complain about missing defaults now.
I corrected a bunch of such cases, that were in the Phobos library.

http://www.digitalmars.com/d/warnings.html
"warning - switch statement has no default"

    ****

Examples:

>  switch (i & 3)
>  {
>    case 0: ... break;
>    case 1: ... break;
>    case 2: ... break;
>    case 3: ... break;
>  }

No changes needed, all cases accounted for...

>  switch (flags)
>  {
>    case FLAG_A: ... break;
>    case FLAG_B: ... break;
+    default: break;
>  }

Line added, to make it behave like C used to.

>  switch (enum)
>  {
>    case ENUM_1: ... break;
>    case ENUM_2: ... break;
>    case ENUM_3: ... break;
+    default: assert(0); break;
>  }

Line added, to make it catch any unplanned cases...
(note that this behaviour is covered by SwitchError
already, and thus does not really have to be added)

The extra "break;" added above is optional at the end.
(just added it here for extra clarity, and in case
someone decides to move it above the regular cases...)


I think D switches are OK ?
Different from C, but OK...

--anders


March 16, 2005
In article <d17l6d$28eq$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>In my opinion following code:

I praise you! and other new guys on the group.
You are raising all the problems we argued before
and it was basically all against Walter.
Hopefully Walter will see that every new guy that is really
interested in D will come up again and again with the
same problems.
Cary on please.
I'm counting on you and the next new guy next month.

Ant


March 16, 2005
In article <d19f7l$193g$1@digitaldaemon.com>, Ant says...

>I praise you! and other new guys on the group.
>You are raising all the problems we argued before
>and it was basically all against Walter.
>Hopefully Walter will see that every new guy that is really
>interested in D will come up again and again with the
>same problems.
>Cary on please.
>I'm counting on you and the next new guy next month.

Hmm... I'd not go so far as to say, just because "we new guys" don't understand something, it means there is a problem with D. IMO, it means that some concepts have changed, and many new ideas have been added, and that all this needs to be learned and understood first. D or any new language will never be self explainatory.

A trivial example, just think back to the early days of C programming and \0 terminated string. Coming from C64-Basic or Amiga Basic, string handling under C was lunacy... but we managed to learn it. In D, the strings no longer are \0 terminated. And there is probably a good reasons for this. Since I am still reading up on all of this, I could not say if this is an advantage, but I have the feeling it is.

Presently, D to me is a new code notation. Since the examples I test are basically C, using D's new features. My gut feeling is, that those things I have sofar understood, are indeed better and more elegant in D though.

Sofar I can only say awesome job Walter! So many things I had hoped to find in C++, e.g. better clearer string handling are finally available in a language close to C :)

[sorry about the rambling]

AEon
March 16, 2005
Ant schrieb:
> In article <d17l6d$28eq$1@digitaldaemon.com>, Andrew Fedoniouk says...
> 
>>In my opinion following code:
> 
> 
> I praise you! and other new guys on the group.
> You are raising all the problems we argued before
> and it was basically all against Walter.
> Hopefully Walter will see that every new guy that is really
> interested in D will come up again and again with the
> same problems.

While I agree that it is important to raise issues that seem illogical and unintuitive, I think that the solution that was found for switch is by far the most logical *and* intuitive one I've seen yet.

When I started writing programs in D, the program complained about a switch statement with a missing default case. I basically thought, "Oh, that's a cool feature" and added the default line.

Really, what's the big deal with that?

The only thing I'd improve is the error message. "Error: Switch default" isn't very specific.


On a different note, when learning a programming language, I think one should be prepared to *learn*. D's primary goal should *not* be to be "just like C++" to avoid confusing anybody. I think when a programmer learns D, their mind should be open to the ways of the language.

Just yelling, "This isn't like C++! It's wrong!!!" doesn't make any sense.

> Ant

-Sebastian
March 16, 2005
Sebastian Beschke wrote:

> The only thing I'd improve is the error message. "Error: Switch default"
> isn't very specific.

It's an Error class toString. They all look kinda terse like that...
Guess they were always meant to be thrown in the same situation ?


module std.asserterror;
/// thrown on false "assert" assertions
class AssertError : Error
	"AssertError Failure %.*s(%u)", filename, linnum

module std.switcherr;
/// thrown on missing "default" in "switch"
class SwitchError : Error
	"Switch Default %.*s(%u)", filename, linnum

module std.array;
/// thrown on array index out of bounds
class ArrayBoundsError : Error
	"ArrayBoundsError %.*s(%u)", filename, linnum


For some annoying reason, ArrayBoundsError is not in arraybounds.d ?

It's also kinda annoying that In/Out/InvariantException don't exist ?
(see http://www.digitalmars.com/d/dbc.html)

But OutOfMemory is the worst, as it is not even an Error but Object ?


But it's not that this hasn't been discussed a dozen times before...
http://www.digitalmars.com/d/archives/15869.html
http://www.digitalmars.com/d/archives/digitalmars/D/6049.html
http://www.digitalmars.com/d/archives/digitalmars/D/10415.html
(and so on, and so forth)

--anders
1 2
Next ›   Last »