You're not a C++ programmer at all if you think you don't use pointers in C++. HL1 is a combination of C and C++, although it uses a lot of C++, it's really a mixture of the two (it tends to use more C design patterns - unlike HL2 which is far more object oriented).
To reply to the other two guys about porting: I worked on porting the Small compiler, VM, and a bunch of assembly stuff from x86 to AMD64. In the former two, the only difficult thing was remembering that certain sizes change and others don't (for example, "long" is different depending whether the architecture is LP64 or LLP64). As ScratchMonkey said, this seriously matters when you're taking apart data from binary streams, but you should be using architecture inspecific typing there anyway. I.e., you should write portable code, and contain the nonportable stuff appropriately. The comment about optimized code not being portable is nonsense, unless the optimizations are so extreme they're down at the assembly level. In this case, AMD64 ports of assembly code are usually very straightforward - you only need to account for the new addressing and calling conventions, both of which mattered to me because AMX Mod X uses self-editing code in some areas. In fact it makes some things easier, with the new registers and media instructions. Sorry if that was too technical, I just felt I had to reply to some misleading comments. The end result here is that if you've written code with portability in mind, portability won't be a big problem, and I know this from experience of the AMX Mod X and Metamod AMD64 ports (note: Metamod needed no changes, which is how it should be!). ~dvander http://www.amxmodx.org/ > -- > [ Picked text/plain from multipart/alternative ] > Yes but it is uncommon to use pointers in C++. C has pointers and its > common > but not C++. I'm guessing HL was made in C++ because the Quake engine was > made in C++. > C++ is such a high level lanuage, they a lot of developers dont practice > any specific hardware code. > But as i said, you do have to change some code. Then recompile it. You > wouldn't spend months changing code. > > On 9/16/05, ScratchMonkey <[EMAIL PROTECTED]> wrote: >> >> --On Friday, September 16, 2005 8:41 AM -0400 Alan Clegg >> <[EMAIL PROTECTED]> >> wrote: >> >> > And, if you've written optimized code, you've written unportable code. >> >> Such code need not be splattered about. You contain the non-portable >> stuff >> and mark it accordingly. >> >> I've been porting some 32-bit stuff to 64-bit and the biggest issues >> have >> been dealing with casts from pointers to 32-bit ints, because the >> pointers >> are too big, and in some assembly code to do CPU detection (which is of >> course expected). The pointer issue comes from some streaming code that >> tries to stream structures across the network. The pointers get >> converted >> to integer tags for transit and back again when received. That'll >> probably >> be an issue in any streaming library. >> >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >> > -- > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
