关于运算符new中的静态数组

Question

I am taking part in programming contests using C++.As is known to all,those contests have strict limits on execution time,and allocating from heap using malloc or new is slow,so I tried overloading operator new in my program.

It worked fine,until today I was trying to solve a problem which requires about 700MB memory,I submitted on the online judge and got an complie error : Compiled file is too large

Then I checked my local .exe file,and shocked to find that it's about 30MB!!

After debugging for a long time,I found the cause:I declared a static array inside operator new ,and it seems that the size of the .exe file varies to the size of that array!!!! Here is my testing code:

#include <cstdlib>
const int MAXN=1e6;
struct A {
    int x;
    void *operator new(size_t) {
        static char Pool[MAXN*sizeof(A)];
        //static A Pool[MAXN];
        //static A *Pool=(A*)calloc(MAXN,sizeof(A));
        static A *Me=(A*)Pool;
        return Me++;
    }
};
int main() {
    A *null=new A;
    return 0;
}

the .exe size increases as the MAXN increases. Can anyone explain this to me? Thanks in advance ^_^

Environment:

Windows 7 x32

TDM-GCC 5.1.0

Answer 1

What's to explain? You said you wanted to avoid taking memory from the target machine's free store, and that's exactly what you've done — the memory is now found in the static data area of your program instead. The only other place to go would be "the stack", which is typically far too small for this amount of data. Basically, this is what happens when you try to go against conventional wisdom.

It was completely pointless anyway; sure, there's a small amount of overhead in dynamic allocation, but a small amount that will not tax a modern system. If you need to allocate 700MB in one go, that will not take more time than allocating 1MB. So just do it.

If you need to allocate 700MB in lots of little pieces then you may have a reason to use a pre-allocated memory pool, but that can still come from new .

The real way to beat "strict execution time limits" in competitive programming is not through "tricks", but through writing an efficient algorithm that scales at the proper rate and does not perform needless data copies everywhere. Or, better yet, stop with this "competitive [broken] programming" and instead practice getting good at writing real software... with the optimisation switches turned on .