Jump to page: 1 2
Thread overview
More "switch/default" woes
Feb 26, 2005
Matthew
Feb 26, 2005
John C
Feb 27, 2005
Matthew
Feb 27, 2005
Nick Sabalausky
Feb 27, 2005
Walter
Feb 27, 2005
John Reimer
Feb 27, 2005
Matthew
Feb 27, 2005
Manfred Nowak
Feb 27, 2005
Regan Heath
Feb 28, 2005
Matthew
Feb 27, 2005
Ben Hinkle
Feb 27, 2005
Manfred Nowak
Feb 27, 2005
Walter
Feb 28, 2005
Matthew
February 26, 2005
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);
}


February 26, 2005
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);
> }
>
> 


February 27, 2005
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);
>> }
>>
>>
>
> 


February 27, 2005
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);
>>>}
>>>
>>>
>>
>>
> 
> 
February 27, 2005
"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.


February 27, 2005
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? ;-)
February 27, 2005
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.
>
> 


February 27, 2005
"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
February 27, 2005
"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.


February 27, 2005
"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
« First   ‹ Prev
1 2