Related
I wrote a directory information utility and (because I, and the people I wrote this for collect & use vintage hardware,) made it compatible with DOS and Windows 9x as well as Windows XP/Vista/7/8 64-bit (because we also use those.) The problem I'm running into is that in Windows 9x it's reporting available drive space and total drive space as 2G (well 1.9997 G) even on larger drives. On Windows XP and beyond (32-bit or 64-bit,) it reports the drive sizes correctly. In DOS, of course, this isn't an issue as the maximum size in DOS is 2G already.
The code I'm using is (DInfo.Path is the directory being accessed, with [0] being the drive letter - A, B, C, etc...):
_dos_getdiskfree(DInfo.Path[0] - 'A' + 1, &Free);
BlockSize = Free.sectors_per_cluster * Free.bytes_per_sector;
for (i = 0; i < BlockSize; i++) {
DriveBytes += Free.total_clusters;
if (DriveBytes < Free.total_clusters) ++DBOverflow;
FreeBytes += Free.avail_clusters;
if (FreeBytes < Free.avail_clusters) ++FBOverflow;
}
The only difference between the code in the DOS stub and the Windows portion of the executable is the _dos_getdiskfree is replaced with _getdiskfree instead. I use unsigned __int32 variables in the above code (or unsigned long for the DOS code.) I used 32 bit for compatibility and to reduce re-writing the code as much as possible when converting the DOS code to Windows code. In Windows XP+ I could probably have simplified things by using __int64 variables, but again, I wasn't sure if Windows 9x would provide those or not. I wasn't even sure if the 32-bit versions of Windows XP+ would allow it or not, and really didn't want to research it just streamline it a bit. Even on older HW it works fast enough with the loop.
With the Overflow & Byte variables both 32 bit integers, the size should max out at 8 exabytes (kilobytes, megabytes, gigabytes, terabytes, petabytes, exabytes in case you were wondering,) and since the largest drives currently available are measured in single digit terabytes, that limit shouldn't cause a problem for a while. At least it's doubtful to do so during my lifetime.
The answer provided by Raymond Chen in a comment has fixed the problem. Using GetDiskFreeSpaceEx rather than GetDiskFreeSpace produced the correct results.
I'm running Windows 7 (64-bit).
This question looks at the same question found here:
long on a 64 bit machine
but is more in-depth as it deals with even more data types and applies
to C or C++, not C#. First of all, I am using Microsoft Visual Studio Ultimate 2012.
Unfortunately, while this IDE supports C# and Visual C++ it no longer supports plain
old Visual C it seems. Anyhow, I've tried the creating the following standard C++
program in the IDE:
#include <cstdio>
int main(int argc, char **argv) {
printf("sizeof(short): %d\n", (int) sizeof(short));
printf("sizeof(int): %d\n", (int) sizeof(int));
printf("sizeof(long): %d\n", (int) sizeof(long));
printf("sizeof(long long): %d\n", (int) sizeof(long long));
printf("sizeof(size_t): %d\n", (int) sizeof(size_t));
printf("sizeof(void *): %d\n", (int) sizeof(void *));
printf("Hit enter to exit.\n");
char *scannedText;
scanf("%s", &scannedText);
return 0;
}
and since I couldn't find the option to run a console application I simply
placed a breakpoint at the "return 0;" statement, so as to view the output
in the console. The result was:
sizeof(short): %d\n", 4
sizeof(int): %d\n", 4
sizeof(long): %d\n", 4
sizeof(long long): 8
sizeof(size_t): 4
sizeof(void *): 4
Hit enter to exit.
Old C textbooks state that int is set to the "word size", which is 16 on 16-bit
machines and 32 on 32-bit machines. However this rule seems to break on 64-bit
systems where one would expect the "word size" to be 64. Instead, from what
I've read these systems are like 32-bit systems but have better support for
64-bit computations than their 32-bit counterparts did. Hence, the results
obtained from the above C++ program are exactly the same as one would
obtain on a 32-bit system. The size of data types (size_t) (which can
be used to measure amount of memory taken up by objects in memory)
also stores its values in 4 bytes, and it is also interesting that
the size of pointers used to access memory locations (for instance sizeof(void *)
shows the number of bits used to store generic pointers to any location in memory)
is also 32 bits long.
Anyone know how come Visaul C was removed from Visual Studio 2012 and whether
it is still possible to run console applications from Visual Studio 2012 without
having to set a breakpoint or read text from standard input prior to exiting
as above in order for the console window to pause before closing?
Furthermore, is my interpretation correct, or do I have something misconfigured
in the IDE so that, for instance, it compiles for 32-bit rather than for 64-bit
systems? According to one of the poster, since my system is 64-bit, I should
see the results described here for size_t and pointers:
https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
but I am not seeing this. Is there a way to reconfigure Visual Studio
so that it may support a 64-bit memory model, as opposed to what
I am currently seeing in the program's output?
Thanks.
Looks right to me. In c/c++ int isn't specifically defined in terms of bit-size. When creating a project you can select a "console application". VS2012 still supports C, but they mostly lump projects into C/C++. There is a compiler option (/TC I think) which will force the compiler into C compliance. By default it will imply the language by the file extension. MS C support isn't ideal, it doesn't include stdbool.h for instance.
If you want to control the bit size of your data you can use stdint.h which contains exact width int datatypes.
On the 32-bit machine, why the size of a pointer is 32-bit? Why not 16-bit or 64-bit? What's the cons and pros?
Because it mimics the size of the actual "pointers" in assembler. On a machine with a 64 bit address bus, it will be 64 bits. In the old 6502, it was an 8 bit machine, but it had 16 bit address bus so that it could address 64K of memory. On most 32 bit machines, 32 bits were enough to address all the memory, so that's what the pointer size was in C++. I know that some of the early M68000 series chips only had a 24 bit memory address space, but it was addressed from a 32 bit register so even on those the pointer would be 32 bits.
In the bad old days of the 80286, it was worse - there was a 16 bit address register, and a 16 bit segment register. Some C++ compilers didn't hide that from you, and made you declare your pointers as near or far depending on whether you wanted to change the segment register. Mercifully, I've recycled most of those brain cells, so I forget if near pointers were 16 bits - but at the machine level, they would be.
The size of a pointer in C++ is implementation-defined. C++ might run on anything from your toaster's chip up to huge mainframes. Different architectures require different sizes of the data types.
If on your implementation a pointer is 32bit, then that's very likely an architecture which can address 2^32 bytes. (Note that even the size of bytes might be different depending on the implementation.) 64bit architectures generally can address 2^64 bytes, so implementations on these architectures will likely have a pointer size of 64bit.
16 bit would obviously be insufficient - you could only address 64K then.
Why not emulate 64 bit on 32 bit systems - I guess because the performance of pointer arithmetic would degrade.
As mentioned in many other answers, the size of a pointer need not be 32-bits - the implementation will set the size of a pointer to be whatever the architecture of the platform dictates. On a system with 64-bit addressing, the size of a pointer will generally be 64-bits.
However, you should also note that even on a single implementation, different types of pointers might have different sizes. In particular, pointer-to-member types (which I'll grant are odd-ball pointers) may have different sizes than plain-old pointers to objects.
The same is true about pointers to plain old functions - they might have a different size than pointers to objects (this applies to C as well as C++). However on modern desktop systems you'll usually find that pointers to functions are the same size as pointers to objects.
Here's a short example of fun with pointer-to-member-functions:
#include <stdio.h>
class A {};
class B {};
class VirtD: public virtual A, public virtual B {
public:
virtual int Dfunc() { return 5; };
};
typedef int (VirtD::* Derived_mfp)();
int main()
{
VirtD virtd;
Derived_mfp mfp = &VirtD::Dfunc;
printf( "sizeof( mfp) == %u\n", (unsigned int) sizeof( mfp));
}
Displays: sizeof( mfp) == 12 on MSVC.
The size of the pointer has little to do with the architecture(32bit, 64bit). 32bit usually refers to the fact that the register size is 32bit. As a result, the maximum possible number of address that you can address using one register is 2^32. So, it boils down to efficiency of addressing the memory slots using a register.
With a 32-bit pointer you can point to a wider range of memory than with 16-bit pointers. When 32-bit pointers were standardized, 64-bit CPUs were not very popular (or even existent?). Therefor a pointer would not be able to fit inside the CPU register, which is a very important factor for speed.
Why not 16-bit? Because, presuming a flat 32-bit address space, you cannot address every byte. Far from it: you can only address 216 unique locations with a 16-bit pointer. Even if your pointers only point to dwords and not bytes, this still leaves 1073676288 dwords unaddressable.
Assuming a flat 32-bit address space, you can already address every single byte with a 32-bit pointer. At this point, 64-bit pointers are just wasting space, unless you want to add additional information to each pointer. For example, on 32-bit PowerPC, a function descriptor is actually a 96-bit entity, with one third pointing to the executable code and the rest being data that helps make relocating modules easier.
In a segmented address space, having larger-than-32-bit pointers to data could be useful. Windows NT on the DEC Alpha was a 32-bit operating system, but the Alpha hardware was 64-bit capable. Your ordinary address space was still 32-bit, but there were special APIs to allow 32-bit programs to access 64-bit addresses, as if they were in otherwise-inaccessible segments.
To answer your question: C++ itself says very little about the size of a pointer, and certainly not that it has to be 32 bits or anything. The size of a pointer should be the natural one for the machine architecture.
The documentation for the InterlockedExchangePointer Function states:
On a 64-bit system, the parameters are 64 bits and the Target parameter must be aligned on 64-bit boundaries; otherwise, the function will behave unpredictably. On a 32-bit system, the parameters are 32 bits and the Target parameter must be aligned on 32-bit boundaries.
I'm compiling for 32bits and the program will run on 32bits and 64bits architectures; does the following structure provide pointers which are usable by InterlockedExchangePointer on any (32 or 64bits) running architecture without code adaptation?
template <class T>
struct Foo {
enum { count = 3 };
__declspec(align(64)) T objects[count];
};
(I suppose that if a single pointer is aligned on 64bits it's also aligned on 32bits -- even if there is a padding if running on 32bits)
Thanks.
On 64-bit system program that written for 32-bit platform will work through compatibility layer (WoW, Windows on Windows), and your pointers must be aligned on 32 bits.
But, if you compile your program in 64 bit mode - your pointers will be automaticaly aligned on 64 bits.
This question already has answers here:
Do all pointers have the same size in C++?
(10 answers)
Closed 8 months ago.
For example:
sizeof(char*) returns 4. As does int*, long long*, everything that I've tried. Are there any exceptions to this?
The guarantee you get is that sizeof(char) == 1. There are no other guarantees, including no guarantee that sizeof(int *) == sizeof(double *).
In practice, pointers will be size 2 on a 16-bit system (if you can find one), 4 on a 32-bit system, and 8 on a 64-bit system, but there's nothing to be gained in relying on a given size.
Even on a plain x86 32 bit platform, you can get a variety of pointer sizes, try this out for an example:
struct A {};
struct B : virtual public A {};
struct C {};
struct D : public A, public C {};
int main()
{
cout << "A:" << sizeof(void (A::*)()) << endl;
cout << "B:" << sizeof(void (B::*)()) << endl;
cout << "D:" << sizeof(void (D::*)()) << endl;
}
Under Visual C++ 2008, I get 4, 12 and 8 for the sizes of the pointers-to-member-function.
Raymond Chen talked about this here.
Just another exception to the already posted list. On 32-bit platforms, pointers can take 6, not 4, bytes:
#include <stdio.h>
#include <stdlib.h>
int main() {
char far* ptr; // note that this is a far pointer
printf( "%d\n", sizeof( ptr));
return EXIT_SUCCESS;
}
If you compile this program with Open Watcom and run it, you'll get 6, because far pointers that it supports consist of 32-bit offset and 16-bit segment values
if you are compiling for a 64-bit machine, then it may be 8.
Technically speaking, the C standard only guarantees that sizeof(char) == 1, and the rest is up to the implementation. But on modern x86 architectures (e.g. Intel/AMD chips) it's fairly predictable.
You've probably heard processors described as being 16-bit, 32-bit, 64-bit, etc. This usually means that the processor uses N-bits for integers. Since pointers store memory addresses, and memory addresses are integers, this effectively tells you how many bits are going to be used for pointers. sizeof is usually measured in bytes, so code compiled for 32-bit processors will report the size of pointers to be 4 (32 bits / 8 bits per byte), and code for 64-bit processors will report the size of pointers to be 8 (64 bits / 8 bits per byte). This is where the limitation of 4GB of RAM for 32-bit processors comes from -- if each memory address corresponds to a byte, to address more memory you need integers larger than 32-bits.
The size of the pointer basically depends on the architecture of the system in which it is implemented. For example the size of a pointer in 32 bit is 4 bytes (32 bit ) and 8 bytes(64 bit ) in a 64 bit machines. The bit types in a machine are nothing but memory address, that it can have. 32 bit machines can have 2^32 address space and 64 bit machines can have upto 2^64 address spaces. So a pointer (variable which points to a memory location) should be able to point to any of the memory address (2^32 for 32 bit and 2^64 for 64 bit) that a machines holds.
Because of this reason we see the size of a pointer to be 4 bytes in 32 bit machine and 8 bytes in a 64 bit machine.
In addition to the 16/32/64 bit differences even odder things can occur.
There have been machines where sizeof(int *) will be one value, probably 4 but where sizeof(char *) is larger. Machines that naturally address words instead of bytes have to "augment" character pointers to specify what portion of the word you really want in order to properly implement the C/C++ standard.
This is now very unusual as hardware designers have learned the value of byte addressability.
8 bit and 16 bit pointers are used in most low profile microcontrollers. That means every washing machine, micro, fridge, older TVs, and even cars.
You could say these have nothing to do with real world programming.
But here is one real world example:
Arduino with 1-2-4k ram (depending on chip) with 2 byte pointers.
It's recent, cheap, accessible for everyone and worths coding for.
In addition to what people have said about 64-bit (or whatever) systems, there are other kinds of pointer than pointer-to-object.
A pointer-to-member might be almost any size, depending how they're implemented by your compiler: they aren't necessarily even all the same size. Try a pointer-to-member of a POD class, and then a pointer-to-member inherited from one of the base classes of a class with multiple bases. What fun.
From what I recall, it's based on the size of a memory address. So on a system with a 32-bit address scheme, sizeof will return 4, since that's 4 bytes.
In general, sizeof(pretty much anything) will change when you compile on different platforms. On a 32 bit platform, pointers are always the same size. On other platforms (64 bit being the obvious example) this can change.
No, the size of a pointer may vary depending on the architecture. There are numerous exceptions.
Size of pointer and int is 2 bytes in Turbo C compiler on windows 32 bit machine.
So size of pointer is compiler specific. But generally most of the compilers are implemented to support 4 byte pointer variable in 32 bit and 8 byte pointer variable in 64 bit machine).
So size of pointer is not same in all machines.
In Win64 (Cygwin GCC 5.4), let's see the below example:
First, test the following struct:
struct list_node{
int a;
list_node* prev;
list_node* next;
};
struct test_struc{
char a, b;
};
The test code is below:
std::cout<<"sizeof(int): "<<sizeof(int)<<std::endl;
std::cout<<"sizeof(int*): "<<sizeof(int*)<<std::endl;
std::cout<<std::endl;
std::cout<<"sizeof(double): "<<sizeof(double)<<std::endl;
std::cout<<"sizeof(double*): "<<sizeof(double*)<<std::endl;
std::cout<<std::endl;
std::cout<<"sizeof(list_node): "<<sizeof(list_node)<<std::endl;
std::cout<<"sizeof(list_node*): "<<sizeof(list_node*)<<std::endl;
std::cout<<std::endl;
std::cout<<"sizeof(test_struc): "<<sizeof(test_struc)<<std::endl;
std::cout<<"sizeof(test_struc*): "<<sizeof(test_struc*)<<std::endl;
The output is below:
sizeof(int): 4
sizeof(int*): 8
sizeof(double): 8
sizeof(double*): 8
sizeof(list_node): 24
sizeof(list_node*): 8
sizeof(test_struc): 2
sizeof(test_struc*): 8
You can see that in 64-bit, sizeof(pointer) is 8.
The reason the size of your pointer is 4 bytes is because you are compiling for a 32-bit architecture. As FryGuy pointed out, on a 64-bit architecture you would see 8.
A pointer is just a container for an address. On a 32 bit machine, your address range is 32 bits, so a pointer will always be 4 bytes. On a 64 bit machine were you have an address range of 64 bits, a pointer will be 8 bytes.
Just for completeness and historic interest, in the 64bit world there were different platform conventions on the sizes of long and long long types, named LLP64 and LP64, mainly between Unix-type systems and Windows. An old standard named ILP64 also made int = 64-bit wide.
Microsoft maintained LLP64 where longlong = 64 bit wide, but long remained at 32, for easier porting.
Type ILP64 LP64 LLP64
char 8 8 8
short 16 16 16
int 64 32 32
long 64 64 32
long long 64 64 64
pointer 64 64 64
Source: https://stackoverflow.com/a/384672/48026