You love me ulong time?

[EmilyStrange]

I ninja-edited my post, he was correct. (No sleep is a bad thing)

Forgiven.

You've failed to provide a reason for using your struct at all from within C# code. Until you provide a concrete reason, other than 'code should be self documenting' (which is usually true, however, that's why comments are available in nearly every language), then I'll stop picking at your code.

In usual code however; there's no need for it when there's a perfectly viable language-specific replacement. (ulong, long, etc)

I still stand by my claim that a clearly defined and named "typedef" (unfortunately, C# struct in this case) is preferable to a more generic base type, such as ulong.

IntPtr (apart from providing other benefits) is clearly preferable to using uint to represent a memory address within a language that does not directly support pointers, even though uint is more efficient and quicker to type. Within the context of accessing the Warcraft game client, even though we only care about 32-bits of address space and don't do much with the addresses other than pass them in to a memory reading function or add offsets to them, IntPtr is still preferable. IntPtr is explicit in what the programmer means, even if the chosen variables names and function names are lousy and comments are non-existent.

I believe that GameGUID (or whatever else you want to name it to save typing) fulfills the same requirement.

@cyper: re: "Their/they're" edit. I can see that now. Oddly enough I read Apoc's post, but misread your post on the usage. I shall have to mentally adjust my opinion of Apoc's sneakiness when reading any of his posts.

[Cypher]

This thread amuses me.

[Apoc]

Forgiven.





I still stand by my claim that a clearly defined and named "typedef" (unfortunately, C# struct in this case) is preferable to a more generic base type, such as ulong.

IntPtr (apart from providing other benefits) is clearly preferable to using uint to represent a memory address within a language that does not directly support pointers, even though uint is more efficient and quicker to type. Within the context of accessing the Warcraft game client, even though we only care about 32-bits of address space and don't do much with the addresses other than pass them in to a memory reading function or add offsets to them, IntPtr is still preferable. IntPtr is explicit in what the programmer means, even if the chosen variables names and function names are lousy and comments are non-existent.

I believe that GameGUID (or whatever else you want to name it to save typing) fulfills the same requirement.

@cyper: re: "Their/they're" edit. I can see that now. Oddly enough I read Apoc's post, but misread your post on the usage. I shall have to mentally adjust my opinion of Apoc's sneakiness when reading any of his posts.

Actually; if MS didn't recommend using IntPtr/UIntPtr for memory addresses, I may agree with you. We use them because they are similar to DWORD_PTRs in C++. 4 bytes when in x86, and 8 bytes in x64. UInt32 is 4 bytes regardless of CPU arch. so it can't hold the entire address in some cases using 4 bytes when in x64 (thus IntPtr will work, with 0 code changes). Also, C# does directly support pointers, it's just suggested you not use them due to the managed nature of the CLR. If you know what you're doing, you can write your entire application using 'unsafe' code. Get your facts correct please. (I concede, it's not 'true' pointer usage, but it's roughly the same, similar enough to be considered equal due to the gigantic language differences. [We ARE ignoring VB.NET in this convo right?])

This is C#. NOT C/C++ where you need typedefs. Blizzard themselves use plain old unsigned __int64 (assumed they typedef'd it to something easier to type), which still makes my point valid. The only 'change' would be to change the name, not add overhead and make the name LONGER.

ulong
unsigned __int64
unsigned long long
GameGUID

Hmmm... which is easier to type and will give me the exact same result (with zero confusion) when used in the following context...

public <insert type here> Guid { get { return GetGuidOrSomeOtherImpl(); } }

As you so 'clearly' pointed out; code should be mostly self documenting. So, again, I still don't see the need for a new struct especially when you can y'know, name the params for your functions?

void Foo(ulong guid, params object[] otherCrap)

As a last note; IntPtr can be used for more than just a pointer. You could even use it to replace Int32 if you want. Sure; it'll add more overhead and typing, but it's not always 'clear'. Please use some better examples next time if you want to attempt to refute my point. You've still failed to do so.

[EmilyStrange]

Also, C# does directly support pointers, it's just suggested you not use them due to the managed nature of the CLR.

I am aware of the pointer support in .NET. Usage of pointers is a good benchmark of separating the wannabe programmers from the real programmers during the interview process.

We ARE ignoring VB.NET in this convo right?

Never mention that language again.

As you so 'clearly' pointed out; code should be mostly self documenting. So, again, I still don't see the need for a new struct especially when you can y'know, name the params for your functions?

I guess my philosophy of programming is different to yours. I assume that any values passed in to a function I write will be complete garbage. I assume that any return values I give back will not be checked. I assume that any functions I call will have parameter names and variables such as "foo", "bar" and "valueOfCoefficient" (value of which coefficient!?!?) and not actually do what the documentation (if any even exists) states.

I attempt to write defensive code, explicit in its declaration, and never rely on another programmer being, actually, y'know, "intelligent" who is just waiting to shoot themselves in the foot with all of the rope they have been given.

When I write code for myself, it reflects the same philosophy I use when writing code that will interact with other programmers' code. No matter how many functions I write that uses the parameter name "renderSurface" some programmer, somewhere, on some project, will ask "does that mean it takes a reference to a surface or does it want a bitmap?"

I guess your philosophy and mine are just different.

[Apoc]

I am aware of the pointer support in .NET. Usage of pointers is a good benchmark of separating the wannabe programmers from the real programmers during the interview process.



Never mention that language again.



I guess my philosophy of programming is different to yours. I assume that any values passed in to a function I write will be complete garbage. I assume that any return values I give back will not be checked. I assume that any functions I call will have parameter names and variables such as "foo", "bar" and "valueOfCoefficient" (value of which coefficient!?!?) and not actually do what the documentation (if any even exists) states.

I attempt to write defensive code, explicit in its declaration, and never rely on another programmer being, actually, y'know, "intelligent" who is just waiting to shoot themselves in the foot with all of the rope they have been given.

When I write code for myself, it reflects the same philosophy I use when writing code that will interact with other programmers' code. No matter how many functions I write that uses the parameter name "renderSurface" some programmer, somewhere, on some project, will ask "does that mean it takes a reference to a surface or does it want a bitmap?"

I guess your philosophy and mine are just different.

Fair enough.

Though; my philosophy is simple. If you can't understand what's going on, even with comments. You shouldn't be touching the code anyway.

C# is type safe, so you really can't screw it up too much. Plus; 99% of the code I write is for my own use so I know exactly what's being passed to it. (Hence; lack of error checking unless it's an 'unknown') All my public code releases are usually riddled with excessive error checking and whatnot to account for idiots, yet that seems to make no difference. (What ever happened to programmers that could read the exception messages?)

[EmilyStrange]

Fair enough.

Though; my philosophy is simple. If you can't understand what's going on, even with comments. You shouldn't be touching the code anyway.

True. But I have worked with people at companies that I wouldn't trust to correctly write a "Hello World!" application in BASIC without somehow passing the wrong parameters, yet still I must work with them.

[Apoc]

True. But I have worked with people at companies that I wouldn't trust to correctly write a "Hello World!" application in BASIC without somehow passing the wrong parameters, yet still I must work with them.

That's why God made boots, and *******s. They work well in tandem.

[satia]

Only reason WoW uses 2 different DWORDs in memory; is because x86 processes can't store 64 bit values in 1 register. So it's split into 2.

x86-32 mmx -> MOVQ
x86-64-> MOV

=P

[Cypher]

x86-32 mmx -> MOVQ
x86-64-> MOV

=P

The first is an extension which isn't enabled by default in WoW at the moment afaik.

The second is from the AMD64 architecture, WoW is only designed for IA32, so it's irrelevant.

[amadmonk]

Gotta join the peanut gallery here

I would go with the "pseudo-typedef" if the ulong had internal meaning and was not designed to be opaque. But FWIK, it's *supposed* to be opaque. Of course, that doesn't mean that it's truly a monolithic structure -- parts of the guid mean different things. But in theory, at least, a guid is, well, you know what it stands for -- just an opaque bit of data that is designed to be unique.

So, using an int to hold an enum is bad, since you're *obscuring* the intent. But the intent of the ulong guid's passed around in WoW is simply to be what they are -- a big-ass number that is most likely unique. So simply using the convenient ulong type obscures no intent.

As to being on the .Net team, say hi to the folks in Bldg 41 for me! It's been many a year since I worked on the VS2k3 team (when .Net was just a newborn baby!), but there were some sharp, sharp folks on that team. Not the PM's, of course, but still... :P