Printable View
I've been trying to integrate C & C++, and I got that working using
but I can't get ASM (assembler) integrated into C++.. is it possible? Do I have to include something else?Code:extern "C"
{
...
}
Next problem: I tried making a simple file encryptor, but it couldn't properly load large files using fopen. Is there something else that would work better, or can I split it into an array so it's not just one variable loading the file?
What are you trying to do? C calling a C++ function?Quote:
Originally Posted by RobotGymnast
__asm or asm { something }Quote:
but I can't get ASM (assembler) integrated into C++.. is it possible? Do I have to include something else?
fopen works with all files, there's probably some other problem here.Quote:
Next problem: I tried making a simple file encryptor, but it couldn't properly load large files using fopen. Is there something else that would work better, or can I split it into an array so it's not just one variable loading the file?
C++ calling a C function o_O
I couldn't getworking.. kept giving me compiler errors.Code:__asm
{
...
}
well I fopened the file, then fread(ed) it into a buffer, but something went wrong when I tried it with large files.
Again ... specifics. (And the details of asm vary from compiler to compiler, so you should look it up anyway.)Quote:
Originally Posted by RobotGymnast
There are probably 157 things that could have gone wrong here. (I can't think of them all right now, but it sounds right.) Check return value of fopen? Dynamic memory allocation fails? The value you read in not a valid type when interpreted in whatever type you made your buffer? Trying to read in too many bytes at one time? Trying to allocate more and more space to your buffer as you keep reading? And doesn't C++ have a whole new set of file stream operators that we could be using instead?Quote:
Originally Posted by RobotGymnast
well there was too many bytes I'm pretty sure.. I was trying to open like 5GB files.. which is why I think it worked with smaller files just fine..
Well, yes, you wouldn't be able to read the whole thing into memory at one time. So? (You're not supposed to be reading in whole files at a time.)
okay.. does anybody know the max number of bytes you can read at once?
Typically limited by the biggest number of memory you can allocate, but that doesn't mean you should do it. Typical buffers is around 1 - 10 MB or so, I think. But I don't know what a good size is.
since on a 32-bit system the length of pointers is 32-bits, you can allocate a theoratical maximum of 2^32-1 bytes (~4GB) assuming both the OS and hardware supports it. (I think there is a smaller limit set by Windows though, 2GB or something like that, not sure about linux)
but anyways, as Elysia said, it is by no means good practice even if it is possible.
having too small a buffer will hinder performance, and too big of a buffer is wasting memory. I would suggest trying 4KB (4096 bytes) as that is what people typically use to copy things in Linux using the dd command. I am not too sure on that though. It is always an option to experiment a bit. Just keep increasing the size of the buffer and keep track of performance. When the performance stops increasing noticeably, that should be a good buffer size.
How does pointer length effect how big the maximum (supposedly) should be?
If you plan to use that byte, you need to be able to access it. Even if you had a massive char array that somehow started at address 0x0, you would only be able to get to memory address 0xFFFFFFFF, four gigs down the road, before your addresses would wrap back around to 0x0.
Because 4 bytes can only hold 0 to 2 ^ 32 - 1 (which is 4 GB - 1024 * 1024 * 1024 * 1024).Quote:
Originally Posted by RobotGymnast