> > Patrick Burrows wrote: > > > No, it was converted for display according to local settings. > > Locale doesn't tell me whether I want to show two or four > places after the > decimal place. Locale is only helpful for dates & times, and > when you are > looking for very specific types of formatting (currencies, etc.). >
No, it is formatted ultimately according to what I pass in. > > LOL. I think of variables in terms of the information stored in them > > (integer = 32 bytes, for instance). Choosing to store my 32 > bytes as an > > integer or in an array of 32 bytes doesn't make a > difference in my mind. > > Ignoring that it's 32 bits (not bytes), that's a consequence > of your VB > heritage, I think. > heh. true. my bad. > > The only reason I would choose one over the other is the > functionality > > that data type may give me. But in C++ I can't pass my int > to a function > > that expects an HWND. It gives me a type mismatch. Even > though it is the > > same amount of data. > > Well, there are those of use who think in types, not buckets > of bits (which, > I'll be honest, is even rather unusual for a VB programmer). > Just because an > HWND is (opaquely) a 32-bit integer, doesn't mean that any > 32-bit integer > can be an HWND. You can't twiddle the bits, you can't add > them together or > subtract them, and have any meaningful answer. That's why it's opaque. > That's why C++ people don't store HWNDs in ints, because an > HWND is-not-a > integer. > In most cases. An HWND of 0 (for instance), has a special meaning to some functions. > > One that the compiler, IMO, does *not* need to be doing. > > After spending years in C debugging things that should've > been (and can now > be) caught by the compiler, I don't think it's even possible for me to > disagree with you more on this point. > Heh. Fair enough. But on the same token, type dangerousness (the opposite of type safety, I guess) in VB does not cause as many problems as you seem to think it does. You get caught once, and then never again. If I see some of the common type problems (rs!Bob = MyTextBox) I can spot and fix them immediately. Nothing really difficult to find. Sort of like this format thing for me in VB.NET, I won't have that same problem again. And you gain a *lot* more from this than you lose in debugging time. Functions are far more flexible. > > We (VB developers) develop this mentality through use of the API and > > translating between C++ and VB. > > Right. Calling the API is what causes you to think that HWNDs > are ints, when > clearly they are not ints. They share the same amount of data space in > memory, and that is where the commonality begins and ends. > IMO, to treat an > HWND as though it were truly an integer is terrible > discipline, even though > your language forced you to declare it as one. > But to the computer, they are. Why should one block of bits somewhere mean one thing and some other mean something else unless it adds some needed functionality. int and HWND may not be a good example, since an HWND has a very specific meaning. How about int and a char[] though? If I choose to use them the same way... But anyway, I'm sure you are right. Your way is better in C++. Mine is better in VB. In VB.NET everything is done the C++ way. So it goes. Patrick Burrows The hangman fumbles with the noose -------------------- Now Playing: depeche mode - just canīt get enough - [ -------------------- You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
