-4
#include <iostream>

int mainarr[500000050];
int P[500000050];
int main()
{
  cout << p[100000];
}

Above code works fine on MAC but crashes in windows. Why Does mac happen to have more memory space for global variables than windows(Not tested on linux till now). How can I increase the size on windows.

VIVEK Yadav
  • 51
  • 8
  • question i am trying to ask is something wrong with my command that is trying to increase stack size. how can i run it on windows. – VIVEK Yadav Aug 16 '20 at 11:17
  • How exactly do you expect us to guess what is happening without sharing the code? – spectras Aug 16 '20 at 11:20
  • Why do you think changing stack size can help, if the arrays are not on the stack? – HolyBlackCat Aug 16 '20 at 11:23
  • 2
    According to [this article](https://www.viva64.com/en/k/0036/), 32-bit programs on Windows can't allocate more than 2 gb, and your arrays require around 3.7 gb. It also says that global variables can't occupy more than 2 gb, even for 64-bit programs. So the solution is probably to allocate arrays on the heap, and to use a 64-bit compiler (CB ships with a 32-bit one by default). – HolyBlackCat Aug 16 '20 at 11:25
  • aren't these array on stack ? Memory allocated through new operator is on heap that's what i used to think – VIVEK Yadav Aug 16 '20 at 11:26
  • Note that except for , it's pure C code. Why don't you use `std::vector`? Besides, your `L` and `H` arrays are on the stack. BTW, variable length arrays are supported in C, but not in C++. – Igor R. Aug 16 '20 at 11:26
  • i just wanted to know why did this code run on mac but not on windows – VIVEK Yadav Aug 16 '20 at 11:34
  • 1
    @VIVEKYadav No, global (and also static) variables are not on the stack. It's the third way of allocating memory, in addition to stack and heap. If it runs on Mac, that's probably because Mac allows more than 2gb of global variables. – HolyBlackCat Aug 16 '20 at 11:38
  • Here we go again. `int L[n];` is **not legal C++ code**. It may run on your Mac and not run on Windows, or it may run on your toaster and explode your Mac, or it may run but secretly launch a nuclear attack against San Marino. [Enable the warnings and treat them as errors](https://stackoverflow.com/questions/57842756/why-should-i-always-enable-compiler-warnings). – n. m. could be an AI Aug 23 '20 at 08:25

2 Answers2

1

You should'nt use that much global memory . Maybe mac has more memory for global than windows.

0

Global and static variables are defined in the Data Segment of the program's memory. I suggest reading about it on wiki. Allocating such big buffers, either on the stack or in the data segment is a really bad practice. (sorry for not being more polite, but it should be avoided at all costs!) Probably Mac-OS allows bigger Data Segments than other OS, but you should not rely on that!

I need to address a few more issues here:

  1. Using #define fi(i, n) for example, is another way to make your code completely unreadable, prone to errors, not scalable and so on. Just use for loop as intended!
  2. This #define lli long long int is obscuring the type, understanding that lli is long long int isn't that simple!. Since C++11 you can use #include <cstdint> look at the reference and use int64_t, knowing the exact size of the integer. (also, when it comes to not-negative numbers, you should use either std::size_t or uintXX_t, I personally use the uint64_t on 64-bit machines).
  3. In C++ you should use using lli = long long int; instead of #define ...
  4. Using 'using namespace std' is considered bad practice
  5. Divide your code into functions, it will make your code more readable.
  6. const lli _MOD = 1e9 + 7; should be constexpr uint64_t _MOD = 1e9 + 7;
Kerek
  • 1,106
  • 1
  • 8
  • 18