[AssKoala]

Cool idea, but that's far too complicated to be of good use like that.

Take this as constructive criticism.

Your implementation makes error checking more complicated than this function really needs. Basically, you would have to implement a more proper algorithm to do this in reverse to ensure that if your array of formats (KB, MB, etc) stops early, your algorithm will still work.

In other words, this is a better, in terms of stability, way to do it (the code is crude, I threw this together and tested it in about 10 minutes):

char *mem_types[] = { "B", "KB", "MB", "GB" };
int numTypes = sizeof(mem_types)/sizeof(char*);

double getHRSize(double fileSize_Bytes, int base, int *type) {
    double HRSize = fileSize_Bytes;
    int baseLevel = 0;
    
    for (;baseLevel < numTypes-1 && fileSize_Bytes >= base;baseLevel++) {
        fileSize_Bytes /= base;   
        HRSize = fileSize_Bytes;
    }
    
    *type = baseLevel;     
    
    return HRSize;
    
}

With example usage:

const int bibiBytebase = 1024;
const int byteBase = 1000;

void outputHR(double fileSize) {
    
    double HRSize;
    int type;
    
    HRSize = getHRSize(fileSize, bibiBytebase, &type);
    
    std::cout << "FileSize: " << HRSize << " " << mem_types[type] << std::endl;
    
    
}

So, with that code, it will not crash regardless of how big the input filesize is. If you used the above memory types (mem_types[]) in your code, you would read outside of your array for anything larger than 1023 GB.

Your algorithm is actually very elegant, you can quickly find out just how many divisions by the base are necessary which will directly correlate to the human readable format. The problem is, you would then have to do the algorithm I just posted in reverse to get it into a format that your types array supports. In other words, the above algorithm supports human readable types indefinitely (or as long as the data types will hold out).

There is also the problem of efficiency. Your algorithm requires two logs and raising to a power. One of the two logs (log(1024)) can theoretically be optimized out by the compiler, but chances are it won't be.

The direct approach (what I posted) will, in general, require only a few iterations (less than 4). It will scale linearly, so at a higher number of iterations, yours would be superior assuming an indefinitely long memory types list. However, it could be modified to use your algorithm to "jump" to the solution, then reverse solve into a solution that fits into the memory types array.

This is overkill, but somewhat important considering program security nowadays. Plus, on many systems, you might not have access to math.h, be dissallowed/discouraged from using math.h, lack a fast implementation of math.h, etc etc.