which *int* ?

[Solar]

Any decent compiler (MSVC's, and GCC, in the least) will throw a warning about the conversion from unsigned to signed.

By default, GCC doesn't. Not even with -Wall. You need -Wextra. And do you know how many programmers are still calling "gcc ... > /dev/null", as to "get rid of all those useless warnings"?

[pcmattman]

By default, GCC doesn't. Not even with -Wall. You need -Wextra.

I guess that shows how long it's been since I've compiled without a large number of warning flags (plus -Werror) on...

[spere]

Being a C# developer, it would be
uint
or
System.UInt32
didn't expect that one, did you?

Then again in masm i would use
VarName dw

ugh.. I hate C# in that respect.. Uint32. Just look at it. What an ugly name. It's inconsistent with every other language, and itself(where core types are lower case, such as int, float, object, string) Microsoft should've thought a little harder about that...

Well i think it (System.UInt32) is quiet clear on first read. This is, the number of bits being used, whether it is signed or unsigned and what the developer plans to store in the variable. Then again this is the CLR implementation and in C# we could bypass it by using uint. In which case the C# compiler would convert it into the the CLR implementation, so that the compiled code (DLL) could be used with other CLR compliant languages.

Using uint in C# is pretty much like

"int" might be 32 bit, but it does neither guarantee nor say so. "int" says "a whatever-sized integer value, I don't really care". Whereas int32_t says "a 32bit integer, and make it exactly 32 bits because it's important".

Then again, i use C# because duty calls. I prefer Masm/Nasm and communicating directly with the chip or processor

[Solar]

I think earlz was referring to the name System.Uint32 as opposed to uint32, uint_32, uint32_t, UINT32 or any other "sane" way to name the type.

[Troy Martin]

I think earlz was referring to the name System.Uint32 as opposed to uint32, uint_32, uint32_t, UINT32 or any other "sane" way to name the type.

In other words, System.Uint32 is the "Microsoft way".

I guess that shows how long it's been since I've compiled without a large number of warning flags (plus -Werror) on...

My CFLAGS is like 4 lines long. It has most of the warning flags in existance for GCC. This way TBOS is a stable little beast, and I can't find a way to break the current development version. I should probably also find out if NASM has any nice warning flags.

And do you know how many programmers are still calling "gcc ... > /dev/null", as to "get rid of all those useless warnings"?

Oh god I think I'm going to *BLARRRGGHHH*

[earlz]

Any decent compiler (MSVC's, and GCC, in the least) will throw a warning about the conversion from unsigned to signed.

By default, GCC doesn't. Not even with -Wall. You need -Wextra. And do you know how many programmers are still calling "gcc ... > /dev/null", as to "get rid of all those useless warnings"?

I'm not pessimistic with any warnings brought forth by anything not included by -Wall. As such, I strive to avoid warnings, but I also don't specify -Wextra and -Werror and all those... cause when I'm making something really quick "just work" I don't want to worry about (signed) (unsigned) casting crap. I want it to work with maybe a few warnings, and then I go back and fix the warnings once my prototype is complete and I want to make the code more "safe"

Also,

Code: Select all

if(true);

gives a warning.. though it's not unsafe or anything. It just *does nothing*.

[Firestryke31]

Also,

Code: Select all

if(true);

gives a warning.. though it's not unsafe or anything. It just *does nothing*.

Lol, does it go someting like this?

some.c: In function 'foo':
some.c:##: warning: stupid programmer detected

Anyway, I just use int and unsigned int, and others when needed, but for loops I usually use size_t. I should probably go and start using the size-specific ones, but I want to get what I have working on my computer first, then I can focus on portability.

[spere]

I think earlz was referring to the name System.Uint32 as opposed to uint32, uint_32, uint32_t, UINT32 or any other "sane" way to name the type.

so i gather

Microsoft sees .Net as the future of all Windows based development and being an OS enthusiast, that another one in my "sane" list.
another dll format to rip apart

In other words, System.Uint32 is the "Microsoft way".

Nail on the head scenario (and uint)

[pcmattman]

It has most of the warning flags in existance for GCC. This way TBOS is a stable little beast

Sorry to jump OT, but I have to point out that you can have all the warnings in the world fixed, but still have an operating system that doesn't actually work (say, #PF's or triple faults all the time). Not having any warnings != having stable code. If you want to get closer to stable code you can run static code analysis. Truly stable code comes from hours of testing, debugging, and modifications, not from fixing warning messages.

[Troy Martin]

It has most of the warning flags in existance for GCC. This way TBOS is a stable little beast

Sorry to jump OT, but I have to point out that you can have all the warnings in the world fixed, but still have an operating system that doesn't actually work (say, #PF's or triple faults all the time). Not having any warnings != having stable code. If you want to get closer to stable code you can run static code analysis. Truly stable code comes from hours of testing, debugging, and modifications, not from fixing warning messages.

Sorry for bringing the OT further, but I think I should rephrase it. Before I added all sorts of warning flags, it was really unstable and even, in some parts, completely broken. After I added the warning flags, saw how horrible I am at coding (haha, just kidding), and fixed the multiple hundred warnings that GCC spat out at me, it ran with a perfect smoothness, completely working. So yeah, actually, adding the warning flags and fixing the warnings did make my OS stable. Even solved a couple #UDs and a GPF or two.

[earlz]

saw how horrible I am at coding (haha, just kidding)

so what your great at coding? Someones a bit stuck on themselves lol.

And my problem with System.Uint32 is even when you include the System namespace, you still have an ugly inconsistent piece of crap. Uint32. Could they not have at least followed there own unspoken standard and called it just `uint32` as all the other core types are? And wtf is a core type even doing in a namespace anyway?

Code: Select all

//this is microsofts next language namespace usage
Builtins.Compiler.System.Core.Type.Integers.Uint32

[spere]

And my problem with System.Uint32 is even when you include the System namespace, you still have an ugly inconsistent piece of crap. Uint32. Could they not have at least followed there own unspoken standard and called it just `uint32` as all the other core types are?

Who better then Microsoft to make this change for better or for

[fronty]

When programming with C# you don't have to use System.Uint32 or Uint32 if you prefer uint. Int32 ^ int, Uint32 ^ uint, Int64 ^ long, and so on. And don't say that it's bad that those shorter names don't tell the actual width of variable, because when you program C#, you always know that your int is 32 bits wide. C# standard says that int represents 32-bit integral value. There are no other possibilities.

[earlz]

When programming with C# you don't have to use System.Uint32 or Uint32 if you prefer uint. Int32 ^ int, Uint32 ^ uint, Int64 ^ long, and so on. And don't say that it's bad that those shorter names don't tell the actual width of variable, because when you program C#, you always know that your int is 32 bits wide. C# standard says that int represents 32-bit integral value. There are no other possibilities.

I've always hated microsofts decision to make 64bit programming *look* like 32bit programming.. it just ends up in 3 or 4 years, when 64bit arithmetic is slightly faster than 32bit arithmetic, Windows will be *even* slower than other OSs

[NickJohnson]

When programming with C# you don't have to use System.Uint32 or Uint32 if you prefer uint. Int32 ^ int, Uint32 ^ uint, Int64 ^ long, and so on. And don't say that it's bad that those shorter names don't tell the actual width of variable, because when you program C#, you always know that your int is 32 bits wide. C# standard says that int represents 32-bit integral value. There are no other possibilities.

I've always hated microsofts decision to make 64bit programming *look* like 32bit programming.. it just ends up in 3 or 4 years, when 64bit arithmetic is slightly faster than 32bit arithmetic, Windows will be *even* slower than other OSs

Except that then they could just have the types actually be 64 bit, and things would act exactly the same, except for the memory usage. Of course, the entire system would have to be recompiled to update the library interfaces...