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 wrote:Any decent compiler (MSVC's, and GCC, in the least) will throw a warning about the conversion from unsigned to signed.
I guess that shows how long it's been since I've compiled without a large number of warning flags (plus -Werror) on...By default, GCC doesn't. Not even with -Wall. You need -Wextra.
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.earlz wrote: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...spere wrote: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
Then again, i use C# because duty calls. I prefer Masm/Nasm and communicating directly with the chip or processorSolar wrote: "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".
In other words, System.Uint32 is the "Microsoft way".Solar wrote: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.
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.pcmattman wrote:I guess that shows how long it's been since I've compiled without a large number of warning flags (plus -Werror) on...
Oh god I think I'm going to *BLARRRGGHHH*Solar wrote:And do you know how many programmers are still calling "gcc ... > /dev/null", as to "get rid of all those useless warnings"?
Solar wrote: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 wrote:Any decent compiler (MSVC's, and GCC, in the least) will throw a warning about the conversion from unsigned to signed.
Code: Select all
if(true);
Lol, does it go someting like this?earlz wrote: Also,gives a warning.. though it's not unsafe or anything. It just *does nothing*.Code: Select all
if(true);
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.gcc wrote: some.c: In function 'foo':
some.c:##: warning: stupid programmer detected
so i gatherSolar wrote: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.
another dll format to rip apartNail on the head scenarioTroy Martin wrote:In other words, System.Uint32 is the "Microsoft way".
(and uint)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.It has most of the warning flags in existance for GCC. This way TBOS is a stable little beast
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.pcmattman wrote: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.It has most of the warning flags in existance for GCC. This way TBOS is a stable little beast
so what your great at coding? Someones a bit stuck on themselves lol.Troy Martin wrote: saw how horrible I am at coding (haha, just kidding)
Code: Select all
//this is microsofts next language namespace usage
Builtins.Compiler.System.Core.Type.Integers.Uint32
Who better then Microsoft to make this changeearlz wrote: 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?
for better or for 
fronty wrote: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.
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...earlz wrote: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 OSsfronty wrote: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.