www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - More "switch/default" woes

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Can anyone figure out why the following doesn't cause two combo boxs to 
be displayed.

I am, as I suspect Kris will also be, sighing deeply


extern (Windows) LPARAM wndProc(HWND hWnd, UINT uMsg, WPARAM wParam, 
LPARAM
lParam) {
  switch (uMsg) {

    case WM_DESTROY:
      PostQuitMessage(0);
      break;

    case WM_CREATE:
      HWND comboBoxHandle = CreateWindowExA(0, "COMBOBOX", "", WS_CHILD 
|
WS_VISIBLE | CBS_DROPDOWN | CBS_HASSTRINGS, 10, 10, 150, 100, hWnd, 
null,
null, null);
      SendMessageA(comboBoxHandle, CB_ADDSTRING, 0,
cast(LPARAM)toStringz("Item one"));
      SendMessageA(comboBoxHandle, CB_ADDSTRING, 0,
cast(LPARAM)toStringz("Item two"));
      break;
      HWND comboBoxHandle2 = CreateWindowExA(0, "COMBOBOX", "", WS_CHILD 
|
WS_VISIBLE | CBS_DROPDOWN | CBS_HASSTRINGS, 200, 200, 150, 100, hWnd, 
null,
null, null);
    default:
      break;
  }
  return DefWindowProcA(hWnd, uMsg, wParam, lParam);
}
Feb 26 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
I don't think the code is reachable. There's a break after the first combo 
box is created.

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:cvppqg$6ge$1 digitaldaemon.com...

 Can anyone figure out why the following doesn't cause two combo boxs to be 
 displayed.

 I am, as I suspect Kris will also be, sighing deeply


 extern (Windows) LPARAM wndProc(HWND hWnd, UINT uMsg, WPARAM wParam, 
 LPARAM
 lParam) {
  switch (uMsg) {

    case WM_DESTROY:
      PostQuitMessage(0);
      break;

    case WM_CREATE:
      HWND comboBoxHandle = CreateWindowExA(0, "COMBOBOX", "", WS_CHILD |
 WS_VISIBLE | CBS_DROPDOWN | CBS_HASSTRINGS, 10, 10, 150, 100, hWnd, null,
 null, null);
      SendMessageA(comboBoxHandle, CB_ADDSTRING, 0,
 cast(LPARAM)toStringz("Item one"));
      SendMessageA(comboBoxHandle, CB_ADDSTRING, 0,
 cast(LPARAM)toStringz("Item two"));
      break;
      HWND comboBoxHandle2 = CreateWindowExA(0, "COMBOBOX", "", WS_CHILD |
 WS_VISIBLE | CBS_DROPDOWN | CBS_HASSTRINGS, 200, 200, 150, 100, hWnd, 
 null,
 null, null);
    default:
      break;
  }
  return DefWindowProcA(hWnd, uMsg, wParam, lParam);
 }
Feb 26 2005
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
Exactly. But did the compiler balk on it, with a helpful message? No, and no!

"John C" <johnch_atms hotmail.com> wrote in message
news:cvq1q3$h6o$1 digitaldaemon.com...

I don't think the code is reachable. There's a break after the first combo box
is created.

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvppqg$6ge$1 digitaldaemon.com...

 Can anyone figure out why the following doesn't cause two combo boxs to be
displayed.

 I am, as I suspect Kris will also be, sighing deeply


 extern (Windows) LPARAM wndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM
 lParam) {
  switch (uMsg) {

    case WM_DESTROY:
      PostQuitMessage(0);
      break;

    case WM_CREATE:
      HWND comboBoxHandle = CreateWindowExA(0, "COMBOBOX", "", WS_CHILD |
 WS_VISIBLE | CBS_DROPDOWN | CBS_HASSTRINGS, 10, 10, 150, 100, hWnd, null,
 null, null);
      SendMessageA(comboBoxHandle, CB_ADDSTRING, 0,
 cast(LPARAM)toStringz("Item one"));
      SendMessageA(comboBoxHandle, CB_ADDSTRING, 0,
 cast(LPARAM)toStringz("Item two"));
      break;
      HWND comboBoxHandle2 = CreateWindowExA(0, "COMBOBOX", "", WS_CHILD |
 WS_VISIBLE | CBS_DROPDOWN | CBS_HASSTRINGS, 200, 200, 150, 100, hWnd, null,
 null, null);
    default:
      break;
  }
  return DefWindowProcA(hWnd, uMsg, wParam, lParam);
 }
Feb 26 2005
next sibling parent Nick Sabalausky <a a.a> writes:
Yea, that looks like a good place for an "unreachable code" error.

Matthew wrote:

 Exactly. But did the compiler balk on it, with a helpful message? No, and no!
 
 "John C" <johnch_atms hotmail.com> wrote in message
news:cvq1q3$h6o$1 digitaldaemon.com...
 

I don't think the code is reachable. There's a break after the first combo box
is created.

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvppqg$6ge$1 digitaldaemon.com...


Can anyone figure out why the following doesn't cause two combo boxs to be
displayed.

I am, as I suspect Kris will also be, sighing deeply


extern (Windows) LPARAM wndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM
lParam) {
 switch (uMsg) {

   case WM_DESTROY:
     PostQuitMessage(0);
     break;

   case WM_CREATE:
     HWND comboBoxHandle = CreateWindowExA(0, "COMBOBOX", "", WS_CHILD |
WS_VISIBLE | CBS_DROPDOWN | CBS_HASSTRINGS, 10, 10, 150, 100, hWnd, null,
null, null);
     SendMessageA(comboBoxHandle, CB_ADDSTRING, 0,
cast(LPARAM)toStringz("Item one"));
     SendMessageA(comboBoxHandle, CB_ADDSTRING, 0,
cast(LPARAM)toStringz("Item two"));
     break;
     HWND comboBoxHandle2 = CreateWindowExA(0, "COMBOBOX", "", WS_CHILD |
WS_VISIBLE | CBS_DROPDOWN | CBS_HASSTRINGS, 200, 200, 150, 100, hWnd, null,
null, null);
   default:
     break;
 }
 return DefWindowProcA(hWnd, uMsg, wParam, lParam);
}
Feb 26 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cvr6lh$1ndv$1 digitaldaemon.com...

 Exactly. But did the compiler balk on it, with a helpful message? No, and


no!

 "John C" <johnch_atms hotmail.com> wrote in message


news:cvq1q3$h6o$1 digitaldaemon.com...

I don't think the code is reachable. There's a break after the first




combo box is created.

I tend to generate lots of unreachable code when trying to isolate a
problem. It's a nuisance having the compiler complain about it.
Feb 26 2005
next sibling parent John Reimer <brk_6502 yahoo.com> writes:
Walter wrote:

 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cvr6lh$1ndv$1 digitaldaemon.com...
 

Exactly. But did the compiler balk on it, with a helpful message? No, and


 
 no!
 

"John C" <johnch_atms hotmail.com> wrote in message


 
 news:cvq1q3$h6o$1 digitaldaemon.com...
 

I don't think the code is reachable. There's a break after the first




 
 combo box is created.
 
 I tend to generate lots of unreachable code when trying to isolate a
 problem. It's a nuisance having the compiler complain about it.
 
 


Time for another compiler switch? ;-)
Feb 26 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Yet again, my friend, you're prescribing behaviour with enormous 
ramifications on the entire (current and potential) D community as a 
result of your own personal experience and development style. I have to 
say, as I've said many times before, that I think this is a bad general 
strategy, and this is a specific acute example of it.

I had actually forgotten the 'deliberate' nature of this, and was 
feeling a little Kris-guilt at having made too much of a big deal about 
what was obviously a (temporary) compiler error. Now I realise the full 
horror of it, I realise I was far too easy on it. This is bad stuff. :-(

Matthew




"Walter" <newshound digitalmars.com> wrote in message 
news:cvrhvs$2222$1 digitaldaemon.com...

 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cvr6lh$1ndv$1 digitaldaemon.com...

 Exactly. But did the compiler balk on it, with a helpful message? No, 
 and


 no!

 "John C" <johnch_atms hotmail.com> wrote in message


 news:cvq1q3$h6o$1 digitaldaemon.com...

I don't think the code is reachable. There's a break after the first




 combo box is created.

 I tend to generate lots of unreachable code when trying to isolate a
 problem. It's a nuisance having the compiler complain about it.
Feb 26 2005
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote:

[...]

 This is bad stuff. :-( 


No. I assist Walter with another argument: You wrote `break'---so 
you meant `break'.

It is not the job of the compiler to declare some code as erroneous 
when you expressively wanted it.

Otherwise what would D end in?

Adding the `default' case to a `switch' statement is an error 
because the other cases cover all possible values and therefore the 
code of the `default' case is unreachable?

`if(e())return; <code>' is an error because the function `e' can be 
proved to compute `true' and therefore <code> is unreachable? 

`version(null)' without an `else' is an error because this version 
may not be set at the command line and therefore the code may be 
unreachable?

Unused variable? Unused member of a class? Unused class when 
importing a module? Linking to a library only possible if you use 
all and every construct in the library?

-manfred
Feb 27 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 27 Feb 2005 08:43:41 +0000 (UTC), Manfred Nowak  
<svv1999 hotmail.com> wrote:

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote:

 [...]

 This is bad stuff. :-(


 No. I assist Walter with another argument: You wrote `break'---so
 you meant `break'.

 It is not the job of the compiler to declare some code as erroneous
 when you expressively wanted it.


True.

IMO Matthews point was that the compiler should detect 'accidental'  
unreachable code. i.e.

switch() {
case x:
if (a);    <-accidental semi-colon
   break;
..unreachable..
..etc..

Note: The above is actually illegal D, as ; is not a valid empty statement  
{} must be used instead, so, the good news is that D does detect the  
accidental break, in this case.

Are there other examples of accidental unreachable code where the root  
cause is actually something else, like the ; {} thing above?


 Otherwise what would D end in?

 Adding the `default' case to a `switch' statement is an error
 because the other cases cover all possible values and therefore the
 code of the `default' case is unreachable?

 `if(e())return; <code>' is an error because the function `e' can be
 proved to compute `true' and therefore <code> is unreachable?

 `version(null)' without an `else' is an error because this version
 may not be set at the command line and therefore the code may be
 unreachable?

 Unused variable? Unused member of a class? Unused class when
 importing a module? Linking to a library only possible if you use
 all and every construct in the library?


I agree with you "In the general case it is undecidable, whether code is  
reachable."

However, it's possible (as in my example above) to detect the error that  
causes the unreachable code, meaning the programmer can still  
intentionally do it, but is less likely to accidentally do it.

Regan
Feb 27 2005
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Manfred Nowak" <svv1999 hotmail.com> wrote in message
news:cvs17s$2hoh$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote:

 [...]

 This is bad stuff. :-(


 No. I assist Walter with another argument: You wrote `break'---so
 you meant `break'.


Yeah, but there was no case!


 It is not the job of the compiler to declare some code as erroneous
 when you expressively wanted it.


No-one's saying it is.
Feb 28 2005
prev sibling next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:cvrknn$250a$1 digitaldaemon.com...

 Yet again, my friend, you're prescribing behaviour with enormous 
 ramifications on the entire (current and potential) D community as a 
 result of your own personal experience and development style. I have to 
 say, as I've said many times before, that I think this is a bad general 
 strategy, and this is a specific acute example of it.

 I had actually forgotten the 'deliberate' nature of this, and was feeling 
 a little Kris-guilt at having made too much of a big deal about what was 
 obviously a (temporary) compiler error. Now I realise the full horror of 
 it, I realise I was far too easy on it. This is bad stuff. :-(

 Matthew


What exactly are you requesting? Is it a warning about unreachable code?

Imagine an editor that would color unreachable code in a special color 
before you ever compile it. It shouldn't be too hard to do with with a dlint 
and an editor that lets you run a program and color text as a result. I tell 
you, an integrated lint is better than warnings. Complex control flow might 
be hard for a dlint to detect but a simple thing like two breaks in a case 
would be easy.
Feb 27 2005
parent Manfred Nowak <svv1999 hotmail.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote:

[...]

 Complex control flow might be hard for a dlint to detect


[...]

In the general case it is undecidable, whether code is reachable.

-manfred
Feb 27 2005
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cvrknn$250a$1 digitaldaemon.com...

 Yet again, my friend, you're prescribing behaviour with enormous
 ramifications on the entire (current and potential) D community as a
 result of your own personal experience and development style. I have to
 say, as I've said many times before, that I think this is a bad general
 strategy, and this is a specific acute example of it.


D can't help but be a reflection of my personal experience and development
style, just as C, C++, Ruby, Python, Perl, etc., are each a reflection of
their principal designers.


 I had actually forgotten the 'deliberate' nature of this, and was
 feeling a little Kris-guilt at having made too much of a big deal about
 what was obviously a (temporary) compiler error.


You argue for the compiler to complain about dead code in some
circumstances, but require the programmer to insert dead code in other
circumstances (the switch default, and the fallthrough return). Trying to
simultaneously codify both into the language rules would be tricky.


 Now I realise the full
 horror of it, I realise I was far too easy on it. This is bad stuff. :-(


The following code is perfectly legal C++, too:

    int foo()
    {
        return 1;
        return 2;
    }

There are many horrors in C++, but that one isn't. While it's "obviously"
wrong, there are many more subtle cases where things aren't so clear (many
popular compilers generate spurious and erroneous warnings about supposedly
dead code), and as I posted before, sometimes it is convenient to allow such
when trying to rapidly develop/test/debug code.
Feb 27 2005
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cvrhvs$2222$1 digitaldaemon.com...

 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cvr6lh$1ndv$1 digitaldaemon.com...

 Exactly. But did the compiler balk on it, with a helpful message? No, and


 no!

 "John C" <johnch_atms hotmail.com> wrote in message


 news:cvq1q3$h6o$1 digitaldaemon.com...

I don't think the code is reachable. There's a break after the first




 combo box is created.

 I tend to generate lots of unreachable code when trying to isolate a
 problem. It's a nuisance having the compiler complain about it.


Why so? Isn't it actually a good thing for the compiler to nag you to fix up
something which you admit is temporary?
Feb 28 2005