Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Issues with porting C++ code to a 64-bit platform

viva64.com

Post reply on HN
Print view View original

41–45 of 45 posts

Re: Issues with porting C++ code to a 64-bit platform

#41

Post by mpyne »

CamperBob2 wrote: post #39
vinkelhake wrote: post #38

Earlier quoted context omitted.

C++ doesn't have an automatic conversion from void* to T* so having NULL as ((void*)0) wouldn't have worked.

True, but again, the whole problem is all of these weird, random changes and exceptions that only a small subset of programmers can keep in their heads. If you're going to go down that path, you should pick safe weird, random changes and exceptions. In this case, they should have turned NULL into a first-class keyword that would parse as an invalid pointer of any given type, and called it "done." In the original C sp…

Turning a macro defined in probably hundreds of header files into a keyword would be a very bad idea for backward compatibility. It would have been nice if C had reserved it for use as a pointer and C++ had been coded from the beginning to allow NULL to be defined to any pointer type, but that wasn't how it ended up.

But what library vendors can do now is to simply

    #ifdef __cplusplus
    #if /* version check for C++11 */
    #undef NULL
    #define NULL nullptr
    #endif
    #endif
And that way there's less stuff to memorize, but still requires that the code itself has to opt-in, instead of the language having to figure out what insanity NULL may have been defined to.

Re: Issues with porting C++ code to a 64-bit platform

#42

Post by derleth »

cube13 wrote: post #24
georgemcbay wrote: post #5

This is great information for anyone making the 32-bit to 64-bit transition, and at this point you really should be viewing 64-bit as your primary platform if you're writing code for x86(amd64) platforms. Just falling back to 32-bit mode with WoW or similar for your target platform is just inexcusable at this point unless you have very specific legacy support issues. As someone who has been stepping away from C/C++ c…

> This is great information for anyone making the 32-bit to 64-bit transition, and at this point you really should be viewing 64-bit as your primary platform if you're writing code for x86(amd64) platforms. Just falling back to 32-bit mode with WoW or similar for your target platform is just inexcusable at this point unless you have very specific legacy support issues. Eh, unless you absolutely need the addressable m…

> Eh, unless you absolutely need the addressable memory, there's no real reason to move a legacy codebase to native 64-bit unless the software absolutely needs the RAM.

Unless it can take advantage of the extra opcodes that are only available on x86-64 hardware. I think AVX is the best example here.

http://en.wikipedia.org/wiki/Advanced_Vector_Extensions

> Using things like longs(especially if you're targeting both Linux and Windows), and assumed pointer lengths can bite you in the ass if you're not careful(and there is a special circle of hell reserved for people who think bitshifting on a pointer type is fine). A few minutes doing some preventative #defines can save you a world of hurt, especially when porting to the next largest system.

Or investigate the types in stddef.h, such as ptrdiff_t:

> It is a type able to represent the result of any valid pointer subtraction operation.

> A pointer subtraction is only guaranteed to have a valid defined value for pointers to elements of the same array (or for the element just past the last in the array).

http://www.cplusplus.com/reference/cstddef/ptrdiff_t/

Trying to mess with #define stuff is only a good idea if you're targeting older or somewhat nonconformant compilers. The includes were written by the compiler authors; trust them to know more about their compiler than you do.

Re: Issues with porting C++ code to a 64-bit platform

#43

Post by Arelius »

MichaelSalib wrote: post #17
Arelius wrote: post #15

Earlier quoted context omitted.

> 64 bits is 64 bits he said, right... well yes That's the problem right there. 64 bits is not always 64 bits. While a 64 bit int gives you a 64 bit number (Actually a 63 bit number and a 1 bit sign flag). An IEEE double precision float only gives you a 52 bit number, and a separate 11 bit number as an exponent. So the problem is that declaring that 64 bits is 64 bits is actually precisely the issue here.

Actually a 63 bit number and a 1 bit sign flag Not true. Modern architectures use 2s-complement rather than an explicit sign bit to represent integers. If you use a sign bit, there are two different zeros (positive and negative) but the range of positive numbers is exactly as large as the range of negative numbers. With 2s-complement, there's only one zero and the range of negative numbers is larger (by one) than the…

Are you arguing that given such, I have more than 63 bits for the number, or do you just have a problem with the usage of the words "sign flag"?

Re: Issues with porting C++ code to a 64-bit platform

#44

Post by AndreyKarpov »

asynchronous13 wrote: post #35

I happen to be working on some 32/64 bit code right now, and this article has some very useful tips. Pretty sure they mixed up arguments on their memset() call in section 3 though: memset(values, ARRAY_SIZE * sizeof(size_t), 0); should be: memset(values, 0, ARRAY_SIZE * sizeof(size_t)); That would not be a fun bug to track down.

Thank you. I will correct it.

Re: Issues with porting C++ code to a 64-bit platform

#45

Post by dschatz »

MichaelSalib wrote: post #31
dschatz wrote: post #20

Earlier quoted context omitted.

In 2s complement, the most significant bit is the sign bit. In fact all valid C integer representations have a sign bit.

This is wrong. Take an integer value x. Flip the sign bit. Do you now have the value -x? On a 2s complement architecture, you do not. In 2s complement, you have to flip all the bits and add one to get -x.

Sign bit means one bit represents the sign of the integer which is the case with the most significant bit in 2s complement.

If you flip the sign bit, the sign changes. It does not mean that if you flip the sign, the value is negated.

Post reply on HN