0

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

5
  • 2
    Can anyone explain this to me? -- Where do you think that array is going to be stored? -- As is known to all,those contests have strict limits on execution time -- Those limits are overcome by using better algorithms, not by trying to tweak a compiler here or there. Overloading operator new was totally unnecessary. Commented Apr 25, 2017 at 8:43
  • 1
    Handling of static arrays during compile-time Commented Apr 25, 2017 at 8:49
  • Even if using the same algorithm,the execution time differs depending on the implementation.Not all the judging computers runs fast as Codeforces',and in China,most of the contests even don't add -O2 while compiling.Thanks for your answer.I really didn't know where the array is to be stored. Commented Apr 25, 2017 at 8:58
  • 1
    most of the contests even don't add -O2 while compiling -- Then these contests are a waste of time. Complain to the sites. Commented Apr 25, 2017 at 9:12
  • 1
    ... or stop with this "competitive [broken] programming" nonsense and instead practice getting good at writing real software. Commented Apr 25, 2017 at 9:13

1 Answer 1

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.

Sign up to request clarification or add additional context in comments.

3 Comments

I appreciate your suggestion.Thank you.But I am still confused.I didn't give an initial value,so why this increases my .exe file size?
I ran more tests,and the increase of the size of .exefile only happens when I overload a struct member operator new,and doesn't happen when I overload the global operator new.Why is this?
@Lucida: I don't know, and it doesn't matter!

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.