Prev: Combine list view with a tab ctrl
Next: CWnd derived parent, owner draw reflection does not work
From: Joseph M. Newcomer on 20 Feb 2010 00:34
Actually, the speculation is much simpler:

<speculation>
The people who programmed Windows 1.0 in 1984 had NO IDEA about signed vs. unsigned.
Totally clueless.
</speculation>

It wasn't helped by the fact that the C compilers of that era would actually ALLOW you to
write
UINT n = -1;
and
if(n < 0)
and
if(n == -1)
without any complaint at all. And even generate the correct code for the if(n<0) test! It
was, pure and simple, sloppy design and slopping thinking.

Unfortunately, as compilers got smarter, it was proven conclusively that these people were
totally clueless. To this day, Microsoft does not really understand the concept of
"signed integer" and "unsigned integer". Consider that string lengths are integers,
although the concept of "negative string length" makes no sense at all. (Yes, I know this
is because they felt they should be compatible with the C library, that also things string
lengths are ints, but that was because the concept of "unsigned" did not exist when the
original string library was written!)
joe

On 19 Feb 2010 01:19:09 GMT, David Scambler <aa(a)aa> wrote:

>"RB" <NoMail(a)NoSpam> wrote in
>news:OdTxapPsKHA.1352(a)TK2MSFTNGP06.phx.gbl:
>
>>
>> ugh well yes I gather the bit thing as I'm aware the sign bit, and the
>> msdn link he gave me was the same as my VC helps files which I was
>> quoting from to start with. My question was "why is the struct written
>> that way?" I.e. if it was designed to sometimes hold a negative
>> value....Why didn't they just make it an int ?
>>
>
>It is probably futile to speculate what they were thinking. But here goes
>anyway...
>
><speculation>
>
>Valid itemIDs are indeed unsigned but they wanted to overload the field
>with a reserved "undefined" flag. I guess it is just sloppy documentation
>and/or imprecise specification. They could have defined a specific macro
>for ((UINT)-1) then "-1" would not have been mentioned. Defining the field
>as int would be inappropriate for the primary purpose of the field, namely
>to use it as a control index.
>
></speculation>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 20 Feb 2010 00:35
In the case of CListBox, sending -1 means "deselect the selection" for a single-select
listbox.
joe

On Fri, 19 Feb 2010 11:04:20 +0100, Oliver Regenfelder <oliver.regenfelder(a)gmx.at> wrote:

>Hello,
>
>David Scambler wrote:
>> Valid itemIDs are indeed unsigned but they wanted to overload the field
>> with a reserved "undefined" flag. I guess it is just sloppy documentation
>> and/or imprecise specification. They could have defined a specific macro
>> for ((UINT)-1) then "-1" would not have been mentioned. Defining the field
>> as int would be inappropriate for the primary purpose of the field, namely
>> to use it as a control index.
>
>Then why do all CListBox methods take the item index as int variable?
>
>Best regards,
>
>Oliver
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Scambler on 21 Feb 2010 20:50


> Actually, the speculation is much simpler:
>

Indeed.
Welcome back Joe.
From: Hans-J. Ude on 22 Feb 2010 03:43
Joseph M. Newcomer wrote:

>Actually, the speculation is much simpler:
>
><speculation>
>The people who programmed Windows 1.0 in 1984 had NO IDEA about signed vs. unsigned.
>Totally clueless.
></speculation>

That's what I thought too, it's legacy. If they change it in the next
SDK then probably thousands of programs wouldn't compile anymore. Or,
if they compile, possibly end up in malfunction, depending on how they
are written.

Hans

From: Joseph M. Newcomer on 22 Feb 2010 08:28
On of the reasons for doing careful design on day one is that you are stuck with bad
decisions forever. Witness the horrid number of bad examples of Hungarian Notation
failing completely because the data types HAD to change and they stupidly included the
datatype in the name (LPVOID lpstrAlgorithm is one of the more memorable ones, but the
number of UINT wWhatevers is pretty high, too. Just think: if HN hadn't been used, there
would be no discontinuity!)
joe

On Mon, 22 Feb 2010 09:43:35 +0100, Hans-J. Ude <news(a)s237965939.online.de> wrote:

>Joseph M. Newcomer wrote:
>
>>Actually, the speculation is much simpler:
>>
>><speculation>
>>The people who programmed Windows 1.0 in 1984 had NO IDEA about signed vs. unsigned.
>>Totally clueless.
>></speculation>
>
>That's what I thought too, it's legacy. If they change it in the next
>SDK then probably thousands of programs wouldn't compile anymore. Or,
>if they compile, possibly end up in malfunction, depending on how they
>are written.
>
>Hans
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Combine list view with a tab ctrl
Next: CWnd derived parent, owner draw reflection does not work