Segmentation fault on large array sizes

The following code gives me a segmentation fault when run on a 2Gb machine, but works on a 4GB machine.

int main()

{

   int c[1000000];

   cout << "donen";

   return 0;

}

The size of the array is just 4Mb. Is there a limit on the size of an array that can be used in c++?

edited Dec 4 '09 at 15:43

sth

167k42247334

asked Dec 4 '09 at 15:41

Mayank

566154

add a comment |

The following code gives me a segmentation fault when run on a 2Gb machine, but works on a 4GB machine.

int main()

{

   int c[1000000];

   cout << "donen";

   return 0;

}

The size of the array is just 4Mb. Is there a limit on the size of an array that can be used in c++?

edited Dec 4 '09 at 15:43

sth

167k42247334

asked Dec 4 '09 at 15:41

Mayank

566154

add a comment |

The following code gives me a segmentation fault when run on a 2Gb machine, but works on a 4GB machine.

int main()

{

   int c[1000000];

   cout << "donen";

   return 0;

}

The size of the array is just 4Mb. Is there a limit on the size of an array that can be used in c++?

edited Dec 4 '09 at 15:43

sth

167k42247334

asked Dec 4 '09 at 15:41

Mayank

566154

The following code gives me a segmentation fault when run on a 2Gb machine, but works on a 4GB machine.

int main()

{

   int c[1000000];

   cout << "donen";

   return 0;

}

The size of the array is just 4Mb. Is there a limit on the size of an array that can be used in c++?

c++ arrays segmentation-fault

edited Dec 4 '09 at 15:43

sth

167k42247334

asked Dec 4 '09 at 15:41

Mayank

566154

edited Dec 4 '09 at 15:43

sth

167k42247334

asked Dec 4 '09 at 15:41

Mayank

566154

edited Dec 4 '09 at 15:43

sth

167k42247334

edited Dec 4 '09 at 15:43

sth

167k42247334

edited Dec 4 '09 at 15:43

sth

167k42247334

asked Dec 4 '09 at 15:41

Mayank

566154

asked Dec 4 '09 at 15:41

Mayank

566154

asked Dec 4 '09 at 15:41

Mayank

566154

add a comment |

5 Answers
5

active

oldest

votes

103

You're probably just getting a stack overflow here. The array is too big to fit in your program's stack address space.

If you allocate the array on the heap you should be fine, assuming your machine has enough memory.

int* array = new int[1000000];

But remember that this will require you to delete the array. A better solution would be to use std::vector<int> and resize it to 1000000 elements.

edited Jun 2 '13 at 3:40

answered Dec 4 '09 at 15:42

Charles Salvia

42.3k10107135

1

Thanks for the answer, but could you explain me why arrays are allocated on the stack and why not in the main program memory.

– Mayank
Dec 4 '09 at 15:51

11

The given code allocates on the stack because it's specified as an array with a constant number of elements at compile time. Values are only put on the heap with malloc, new, etc.

– Seth Johnson
Dec 4 '09 at 16:05

3

All automatic varables are allocated on the stack. If you look at the disasseble you will see the size of your local variables subtracted from the stack pointer. When you call malloc or calloc or any of the memory fuctions the fuctions go and find blocks of memory large enough to sataisfy your reqest.

– rerun
Dec 4 '09 at 16:12

@Charles why we could allocate more memory from heap, not from stack? from my understanding, both stack and heap moves in opposite direction in allocated address space in the memory.

– saurabh agarwal
Feb 24 '15 at 6:58

2

@saurabhagarwal The heap doesn't move. It's not even a contiguous memory region. The allocator simply returns a free memory block that fits your size requirement What and where are the stack and heap?

– phuclv
Jun 23 '15 at 4:45

|
show 1 more comment

In C or C++ local objects are usually allocated on the stack. You are allocating a large array on the stack, more than the stack can handle, so you are getting a stackoverflow.

Don't allocate it local on stack, use some other place instead. This can be achieved by either making the object global or allocating it on the global heap. Global variables are fine, if you don't use the from any other compilation unit. To make sure this doesn't happen by accident, add a static storage specifier, otherwise just use the heap.

This will allocate in the BSS segment, which is a part of the heap:

static int c[1000000];

int main()

{

   cout << "donen";

   return 0;

}

This will allocate in the DATA segment, which is a part of the heap too:

int c[1000000] = {};

int main()

{

   cout << "donen";

   return 0;

}

This will allocate at some unspecified location in the heap:

int main()

{

   int* c = new int[1000000];

   cout << "donen";

   return 0;

}

edited May 23 '17 at 12:34

Community♦

answered Dec 4 '09 at 15:58

Gunther Piez

24.8k55596

If you use the third pattern, allocating on the heap, don't forget to delete the pointer at some stage or you'll leak memory. Or look into smart pointers.

– davidA
Sep 5 '12 at 1:20

6

@meowsqueak Of course it is good practice to delete everywhere you allocate with new. But if you are sure you allocate memory only once (like in main) it is strictly not needed - the memory is guaranteed to be freed at the exit of main even without explicit delete.

– Gunther Piez
Sep 5 '12 at 8:11

'at'drhirsch (how do you do an at-character anyway?) - yes, fair comment. As the OP appears new to the language I just wanted to make sure that they, and anyone else seeing your good answer, were aware of the implications of the third option if used generally.

– davidA
Sep 5 '12 at 12:19

@meowsqueak: Depends on your keyboard. For me it is RightALT-L (Mac) or RightALT-Q (Windows). You need to add the "@" symbol if you want to answer to a comment, so that the author of the original comment gets a notice. In this case I get noticed anyway, because it was my answer.

– Gunther Piez
Sep 5 '12 at 14:50

1

if I put @ + drhirsch at the start of my comment, the @ and your name disappear, even from the edit box. Very odd. Oh well, this isn't the place to sort this one out.

– davidA
Sep 5 '12 at 21:05

|
show 1 more comment

Also, if you are running in most UNIX & Linux systems you can temporarily increase the stack size by the following command:

ulimit -s unlimited

But be careful, memory is a limited resource and with great power come great responsibilities :)

edited Jul 25 '17 at 9:59

Usman.3D

1,46921426

answered Nov 8 '13 at 15:38

RSFalcon7

1,13822051

This is the solution but I advise all to be extremely cautious when removing this default limits on the program's stack size. You will experience not only severe performance drop but your system might crash. For example I tried to sort an array with 16 000 000 integer elements with quicksort on a machine with 4GB RAM and my system was almost killed. LOL

– rbaleksandar
Oct 16 '14 at 16:51

@rbaleksandar I think you ~16MB program almost kill your machine because you were working with several copies of the array (may be one per function call?) try a more memory aware implementation ;)

– RSFalcon7
Oct 16 '14 at 23:20

I'm pretty sure the array handling is okay since I'm passing by reference and not by value. The same thing happens with bubblesort. Hell, even if my implementation of quicksort sucks bubblesort is something that you cannot possibly implement incorrectly. LOL

– rbaleksandar
Oct 17 '14 at 10:07

LOL you could try radix sort, or simply use std::sort :)

– RSFalcon7
Oct 17 '14 at 16:54

1

No chance. It's a lab assignment. :D

– rbaleksandar
Oct 17 '14 at 17:00

add a comment |

You array is being allocated on the stack in this case attempt to allocate an array of the same size using alloc.

answered Dec 4 '09 at 15:43

rerun

21.1k53571

add a comment |

Because you store the array in the stack. You should store it in the heap. See this link to understand the concept of the heap and the stack.

edited Apr 14 '12 at 20:50

evotopid

4,12522139

answered Jan 7 '11 at 23:21

Narek

18.3k57174312

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f1847789%2fsegmentation-fault-on-large-array-sizes%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

5 Answers
5

active

oldest

votes

5 Answers
5

active

oldest

votes

103

You're probably just getting a stack overflow here. The array is too big to fit in your program's stack address space.

If you allocate the array on the heap you should be fine, assuming your machine has enough memory.

int* array = new int[1000000];

But remember that this will require you to delete the array. A better solution would be to use std::vector<int> and resize it to 1000000 elements.

edited Jun 2 '13 at 3:40

answered Dec 4 '09 at 15:42

Charles Salvia

42.3k10107135

1

Thanks for the answer, but could you explain me why arrays are allocated on the stack and why not in the main program memory.

– Mayank
Dec 4 '09 at 15:51

11

The given code allocates on the stack because it's specified as an array with a constant number of elements at compile time. Values are only put on the heap with malloc, new, etc.

– Seth Johnson
Dec 4 '09 at 16:05

3

All automatic varables are allocated on the stack. If you look at the disasseble you will see the size of your local variables subtracted from the stack pointer. When you call malloc or calloc or any of the memory fuctions the fuctions go and find blocks of memory large enough to sataisfy your reqest.

– rerun
Dec 4 '09 at 16:12

@Charles why we could allocate more memory from heap, not from stack? from my understanding, both stack and heap moves in opposite direction in allocated address space in the memory.

– saurabh agarwal
Feb 24 '15 at 6:58

2

@saurabhagarwal The heap doesn't move. It's not even a contiguous memory region. The allocator simply returns a free memory block that fits your size requirement What and where are the stack and heap?

– phuclv
Jun 23 '15 at 4:45

|
show 1 more comment

103

You're probably just getting a stack overflow here. The array is too big to fit in your program's stack address space.

If you allocate the array on the heap you should be fine, assuming your machine has enough memory.

int* array = new int[1000000];

But remember that this will require you to delete the array. A better solution would be to use std::vector<int> and resize it to 1000000 elements.

edited Jun 2 '13 at 3:40

answered Dec 4 '09 at 15:42

Charles Salvia

42.3k10107135

1

Thanks for the answer, but could you explain me why arrays are allocated on the stack and why not in the main program memory.

– Mayank
Dec 4 '09 at 15:51

11

The given code allocates on the stack because it's specified as an array with a constant number of elements at compile time. Values are only put on the heap with malloc, new, etc.

– Seth Johnson
Dec 4 '09 at 16:05

3

All automatic varables are allocated on the stack. If you look at the disasseble you will see the size of your local variables subtracted from the stack pointer. When you call malloc or calloc or any of the memory fuctions the fuctions go and find blocks of memory large enough to sataisfy your reqest.

– rerun
Dec 4 '09 at 16:12

@Charles why we could allocate more memory from heap, not from stack? from my understanding, both stack and heap moves in opposite direction in allocated address space in the memory.

– saurabh agarwal
Feb 24 '15 at 6:58

2

@saurabhagarwal The heap doesn't move. It's not even a contiguous memory region. The allocator simply returns a free memory block that fits your size requirement What and where are the stack and heap?

– phuclv
Jun 23 '15 at 4:45

|
show 1 more comment

103

You're probably just getting a stack overflow here. The array is too big to fit in your program's stack address space.

If you allocate the array on the heap you should be fine, assuming your machine has enough memory.

int* array = new int[1000000];

But remember that this will require you to delete the array. A better solution would be to use std::vector<int> and resize it to 1000000 elements.

edited Jun 2 '13 at 3:40

answered Dec 4 '09 at 15:42

Charles Salvia

42.3k10107135

You're probably just getting a stack overflow here. The array is too big to fit in your program's stack address space.

If you allocate the array on the heap you should be fine, assuming your machine has enough memory.

int* array = new int[1000000];

But remember that this will require you to delete the array. A better solution would be to use std::vector<int> and resize it to 1000000 elements.

edited Jun 2 '13 at 3:40

answered Dec 4 '09 at 15:42

Charles Salvia

42.3k10107135

edited Jun 2 '13 at 3:40

answered Dec 4 '09 at 15:42

Charles Salvia

42.3k10107135

answered Dec 4 '09 at 15:42

Charles Salvia

42.3k10107135

answered Dec 4 '09 at 15:42

Charles Salvia

42.3k10107135

1

Thanks for the answer, but could you explain me why arrays are allocated on the stack and why not in the main program memory.

– Mayank
Dec 4 '09 at 15:51

11

The given code allocates on the stack because it's specified as an array with a constant number of elements at compile time. Values are only put on the heap with malloc, new, etc.

– Seth Johnson
Dec 4 '09 at 16:05

3

All automatic varables are allocated on the stack. If you look at the disasseble you will see the size of your local variables subtracted from the stack pointer. When you call malloc or calloc or any of the memory fuctions the fuctions go and find blocks of memory large enough to sataisfy your reqest.

– rerun
Dec 4 '09 at 16:12

@Charles why we could allocate more memory from heap, not from stack? from my understanding, both stack and heap moves in opposite direction in allocated address space in the memory.

– saurabh agarwal
Feb 24 '15 at 6:58

2

@saurabhagarwal The heap doesn't move. It's not even a contiguous memory region. The allocator simply returns a free memory block that fits your size requirement What and where are the stack and heap?

– phuclv
Jun 23 '15 at 4:45

|
show 1 more comment

1

Thanks for the answer, but could you explain me why arrays are allocated on the stack and why not in the main program memory.

– Mayank
Dec 4 '09 at 15:51

11

The given code allocates on the stack because it's specified as an array with a constant number of elements at compile time. Values are only put on the heap with malloc, new, etc.

– Seth Johnson
Dec 4 '09 at 16:05

3

All automatic varables are allocated on the stack. If you look at the disasseble you will see the size of your local variables subtracted from the stack pointer. When you call malloc or calloc or any of the memory fuctions the fuctions go and find blocks of memory large enough to sataisfy your reqest.

– rerun
Dec 4 '09 at 16:12

@Charles why we could allocate more memory from heap, not from stack? from my understanding, both stack and heap moves in opposite direction in allocated address space in the memory.

– saurabh agarwal
Feb 24 '15 at 6:58

2

@saurabhagarwal The heap doesn't move. It's not even a contiguous memory region. The allocator simply returns a free memory block that fits your size requirement What and where are the stack and heap?

– phuclv
Jun 23 '15 at 4:45

Thanks for the answer, but could you explain me why arrays are allocated on the stack and why not in the main program memory.

– Mayank
Dec 4 '09 at 15:51

The given code allocates on the stack because it's specified as an array with a constant number of elements at compile time. Values are only put on the heap with malloc, new, etc.

– Seth Johnson
Dec 4 '09 at 16:05

All automatic varables are allocated on the stack. If you look at the disasseble you will see the size of your local variables subtracted from the stack pointer. When you call malloc or calloc or any of the memory fuctions the fuctions go and find blocks of memory large enough to sataisfy your reqest.

– rerun
Dec 4 '09 at 16:12

@Charles why we could allocate more memory from heap, not from stack? from my understanding, both stack and heap moves in opposite direction in allocated address space in the memory.

– saurabh agarwal
Feb 24 '15 at 6:58

@saurabhagarwal The heap doesn't move. It's not even a contiguous memory region. The allocator simply returns a free memory block that fits your size requirement What and where are the stack and heap?

– phuclv
Jun 23 '15 at 4:45

|
show 1 more comment

In C or C++ local objects are usually allocated on the stack. You are allocating a large array on the stack, more than the stack can handle, so you are getting a stackoverflow.

This will allocate in the BSS segment, which is a part of the heap:

static int c[1000000];

int main()

{

   cout << "donen";

   return 0;

}

This will allocate in the DATA segment, which is a part of the heap too:

int c[1000000] = {};

int main()

{

   cout << "donen";

   return 0;

}

This will allocate at some unspecified location in the heap:

int main()

{

   int* c = new int[1000000];

   cout << "donen";

   return 0;

}

edited May 23 '17 at 12:34

Community♦

answered Dec 4 '09 at 15:58

Gunther Piez

24.8k55596

If you use the third pattern, allocating on the heap, don't forget to delete the pointer at some stage or you'll leak memory. Or look into smart pointers.

– davidA
Sep 5 '12 at 1:20

6

@meowsqueak Of course it is good practice to delete everywhere you allocate with new. But if you are sure you allocate memory only once (like in main) it is strictly not needed - the memory is guaranteed to be freed at the exit of main even without explicit delete.

– Gunther Piez
Sep 5 '12 at 8:11

'at'drhirsch (how do you do an at-character anyway?) - yes, fair comment. As the OP appears new to the language I just wanted to make sure that they, and anyone else seeing your good answer, were aware of the implications of the third option if used generally.

– davidA
Sep 5 '12 at 12:19

@meowsqueak: Depends on your keyboard. For me it is RightALT-L (Mac) or RightALT-Q (Windows). You need to add the "@" symbol if you want to answer to a comment, so that the author of the original comment gets a notice. In this case I get noticed anyway, because it was my answer.

– Gunther Piez
Sep 5 '12 at 14:50

1

if I put @ + drhirsch at the start of my comment, the @ and your name disappear, even from the edit box. Very odd. Oh well, this isn't the place to sort this one out.

– davidA
Sep 5 '12 at 21:05

|
show 1 more comment

In C or C++ local objects are usually allocated on the stack. You are allocating a large array on the stack, more than the stack can handle, so you are getting a stackoverflow.

This will allocate in the BSS segment, which is a part of the heap:

static int c[1000000];

int main()

{

   cout << "donen";

   return 0;

}

This will allocate in the DATA segment, which is a part of the heap too:

int c[1000000] = {};

int main()

{

   cout << "donen";

   return 0;

}

This will allocate at some unspecified location in the heap:

int main()

{

   int* c = new int[1000000];

   cout << "donen";

   return 0;

}

edited May 23 '17 at 12:34

Community♦

answered Dec 4 '09 at 15:58

Gunther Piez

24.8k55596

If you use the third pattern, allocating on the heap, don't forget to delete the pointer at some stage or you'll leak memory. Or look into smart pointers.

– davidA
Sep 5 '12 at 1:20

6

@meowsqueak Of course it is good practice to delete everywhere you allocate with new. But if you are sure you allocate memory only once (like in main) it is strictly not needed - the memory is guaranteed to be freed at the exit of main even without explicit delete.

– Gunther Piez
Sep 5 '12 at 8:11

'at'drhirsch (how do you do an at-character anyway?) - yes, fair comment. As the OP appears new to the language I just wanted to make sure that they, and anyone else seeing your good answer, were aware of the implications of the third option if used generally.

– davidA
Sep 5 '12 at 12:19

@meowsqueak: Depends on your keyboard. For me it is RightALT-L (Mac) or RightALT-Q (Windows). You need to add the "@" symbol if you want to answer to a comment, so that the author of the original comment gets a notice. In this case I get noticed anyway, because it was my answer.

– Gunther Piez
Sep 5 '12 at 14:50

1

if I put @ + drhirsch at the start of my comment, the @ and your name disappear, even from the edit box. Very odd. Oh well, this isn't the place to sort this one out.

– davidA
Sep 5 '12 at 21:05

|
show 1 more comment

In C or C++ local objects are usually allocated on the stack. You are allocating a large array on the stack, more than the stack can handle, so you are getting a stackoverflow.

This will allocate in the BSS segment, which is a part of the heap:

static int c[1000000];

int main()

{

   cout << "donen";

   return 0;

}

This will allocate in the DATA segment, which is a part of the heap too:

int c[1000000] = {};

int main()

{

   cout << "donen";

   return 0;

}

This will allocate at some unspecified location in the heap:

int main()

{

   int* c = new int[1000000];

   cout << "donen";

   return 0;

}

edited May 23 '17 at 12:34

Community♦

answered Dec 4 '09 at 15:58

Gunther Piez

24.8k55596

In C or C++ local objects are usually allocated on the stack. You are allocating a large array on the stack, more than the stack can handle, so you are getting a stackoverflow.

This will allocate in the BSS segment, which is a part of the heap:

static int c[1000000];

int main()

{

   cout << "donen";

   return 0;

}

This will allocate in the DATA segment, which is a part of the heap too:

int c[1000000] = {};

int main()

{

   cout << "donen";

   return 0;

}

This will allocate at some unspecified location in the heap:

int main()

{

   int* c = new int[1000000];

   cout << "donen";

   return 0;

}

edited May 23 '17 at 12:34

Community♦

answered Dec 4 '09 at 15:58

Gunther Piez

24.8k55596

edited May 23 '17 at 12:34

Community♦

edited May 23 '17 at 12:34

Community♦

edited May 23 '17 at 12:34

Community♦

answered Dec 4 '09 at 15:58

Gunther Piez

24.8k55596

answered Dec 4 '09 at 15:58

Gunther Piez

24.8k55596

answered Dec 4 '09 at 15:58

Gunther Piez

24.8k55596

If you use the third pattern, allocating on the heap, don't forget to delete the pointer at some stage or you'll leak memory. Or look into smart pointers.

– davidA
Sep 5 '12 at 1:20

6

@meowsqueak Of course it is good practice to delete everywhere you allocate with new. But if you are sure you allocate memory only once (like in main) it is strictly not needed - the memory is guaranteed to be freed at the exit of main even without explicit delete.

– Gunther Piez
Sep 5 '12 at 8:11

'at'drhirsch (how do you do an at-character anyway?) - yes, fair comment. As the OP appears new to the language I just wanted to make sure that they, and anyone else seeing your good answer, were aware of the implications of the third option if used generally.

– davidA
Sep 5 '12 at 12:19

@meowsqueak: Depends on your keyboard. For me it is RightALT-L (Mac) or RightALT-Q (Windows). You need to add the "@" symbol if you want to answer to a comment, so that the author of the original comment gets a notice. In this case I get noticed anyway, because it was my answer.

– Gunther Piez
Sep 5 '12 at 14:50

1

if I put @ + drhirsch at the start of my comment, the @ and your name disappear, even from the edit box. Very odd. Oh well, this isn't the place to sort this one out.

– davidA
Sep 5 '12 at 21:05

|
show 1 more comment

If you use the third pattern, allocating on the heap, don't forget to delete the pointer at some stage or you'll leak memory. Or look into smart pointers.

– davidA
Sep 5 '12 at 1:20

6

@meowsqueak Of course it is good practice to delete everywhere you allocate with new. But if you are sure you allocate memory only once (like in main) it is strictly not needed - the memory is guaranteed to be freed at the exit of main even without explicit delete.

– Gunther Piez
Sep 5 '12 at 8:11

'at'drhirsch (how do you do an at-character anyway?) - yes, fair comment. As the OP appears new to the language I just wanted to make sure that they, and anyone else seeing your good answer, were aware of the implications of the third option if used generally.

– davidA
Sep 5 '12 at 12:19

@meowsqueak: Depends on your keyboard. For me it is RightALT-L (Mac) or RightALT-Q (Windows). You need to add the "@" symbol if you want to answer to a comment, so that the author of the original comment gets a notice. In this case I get noticed anyway, because it was my answer.

– Gunther Piez
Sep 5 '12 at 14:50

1

if I put @ + drhirsch at the start of my comment, the @ and your name disappear, even from the edit box. Very odd. Oh well, this isn't the place to sort this one out.

– davidA
Sep 5 '12 at 21:05

If you use the third pattern, allocating on the heap, don't forget to delete the pointer at some stage or you'll leak memory. Or look into smart pointers.

– davidA
Sep 5 '12 at 1:20

@meowsqueak Of course it is good practice to delete everywhere you allocate with new. But if you are sure you allocate memory only once (like in main) it is strictly not needed - the memory is guaranteed to be freed at the exit of main even without explicit delete.

– Gunther Piez
Sep 5 '12 at 8:11

'at'drhirsch (how do you do an at-character anyway?) - yes, fair comment. As the OP appears new to the language I just wanted to make sure that they, and anyone else seeing your good answer, were aware of the implications of the third option if used generally.

– davidA
Sep 5 '12 at 12:19

@meowsqueak: Depends on your keyboard. For me it is RightALT-L (Mac) or RightALT-Q (Windows). You need to add the "@" symbol if you want to answer to a comment, so that the author of the original comment gets a notice. In this case I get noticed anyway, because it was my answer.

– Gunther Piez
Sep 5 '12 at 14:50

if I put @ + drhirsch at the start of my comment, the @ and your name disappear, even from the edit box. Very odd. Oh well, this isn't the place to sort this one out.

– davidA
Sep 5 '12 at 21:05

|
show 1 more comment

Also, if you are running in most UNIX & Linux systems you can temporarily increase the stack size by the following command:

ulimit -s unlimited

But be careful, memory is a limited resource and with great power come great responsibilities :)

edited Jul 25 '17 at 9:59

Usman.3D

1,46921426

answered Nov 8 '13 at 15:38

RSFalcon7

1,13822051

This is the solution but I advise all to be extremely cautious when removing this default limits on the program's stack size. You will experience not only severe performance drop but your system might crash. For example I tried to sort an array with 16 000 000 integer elements with quicksort on a machine with 4GB RAM and my system was almost killed. LOL

– rbaleksandar
Oct 16 '14 at 16:51

@rbaleksandar I think you ~16MB program almost kill your machine because you were working with several copies of the array (may be one per function call?) try a more memory aware implementation ;)

– RSFalcon7
Oct 16 '14 at 23:20

I'm pretty sure the array handling is okay since I'm passing by reference and not by value. The same thing happens with bubblesort. Hell, even if my implementation of quicksort sucks bubblesort is something that you cannot possibly implement incorrectly. LOL

– rbaleksandar
Oct 17 '14 at 10:07

LOL you could try radix sort, or simply use std::sort :)

– RSFalcon7
Oct 17 '14 at 16:54

1

No chance. It's a lab assignment. :D

– rbaleksandar
Oct 17 '14 at 17:00

add a comment |

Also, if you are running in most UNIX & Linux systems you can temporarily increase the stack size by the following command:

ulimit -s unlimited

But be careful, memory is a limited resource and with great power come great responsibilities :)

edited Jul 25 '17 at 9:59

Usman.3D

1,46921426

answered Nov 8 '13 at 15:38

RSFalcon7

1,13822051

This is the solution but I advise all to be extremely cautious when removing this default limits on the program's stack size. You will experience not only severe performance drop but your system might crash. For example I tried to sort an array with 16 000 000 integer elements with quicksort on a machine with 4GB RAM and my system was almost killed. LOL

– rbaleksandar
Oct 16 '14 at 16:51

@rbaleksandar I think you ~16MB program almost kill your machine because you were working with several copies of the array (may be one per function call?) try a more memory aware implementation ;)

– RSFalcon7
Oct 16 '14 at 23:20

I'm pretty sure the array handling is okay since I'm passing by reference and not by value. The same thing happens with bubblesort. Hell, even if my implementation of quicksort sucks bubblesort is something that you cannot possibly implement incorrectly. LOL

– rbaleksandar
Oct 17 '14 at 10:07

LOL you could try radix sort, or simply use std::sort :)

– RSFalcon7
Oct 17 '14 at 16:54

1

No chance. It's a lab assignment. :D

– rbaleksandar
Oct 17 '14 at 17:00

add a comment |

Also, if you are running in most UNIX & Linux systems you can temporarily increase the stack size by the following command:

ulimit -s unlimited

But be careful, memory is a limited resource and with great power come great responsibilities :)

edited Jul 25 '17 at 9:59

Usman.3D

1,46921426

answered Nov 8 '13 at 15:38

RSFalcon7

1,13822051

Also, if you are running in most UNIX & Linux systems you can temporarily increase the stack size by the following command:

ulimit -s unlimited

But be careful, memory is a limited resource and with great power come great responsibilities :)

edited Jul 25 '17 at 9:59

Usman.3D

1,46921426

answered Nov 8 '13 at 15:38

RSFalcon7

1,13822051

edited Jul 25 '17 at 9:59

Usman.3D

1,46921426

edited Jul 25 '17 at 9:59

Usman.3D

1,46921426

edited Jul 25 '17 at 9:59

Usman.3D

1,46921426

answered Nov 8 '13 at 15:38

RSFalcon7

1,13822051

answered Nov 8 '13 at 15:38

RSFalcon7

1,13822051

answered Nov 8 '13 at 15:38

RSFalcon7

1,13822051

This is the solution but I advise all to be extremely cautious when removing this default limits on the program's stack size. You will experience not only severe performance drop but your system might crash. For example I tried to sort an array with 16 000 000 integer elements with quicksort on a machine with 4GB RAM and my system was almost killed. LOL

– rbaleksandar
Oct 16 '14 at 16:51

@rbaleksandar I think you ~16MB program almost kill your machine because you were working with several copies of the array (may be one per function call?) try a more memory aware implementation ;)

– RSFalcon7
Oct 16 '14 at 23:20

I'm pretty sure the array handling is okay since I'm passing by reference and not by value. The same thing happens with bubblesort. Hell, even if my implementation of quicksort sucks bubblesort is something that you cannot possibly implement incorrectly. LOL

– rbaleksandar
Oct 17 '14 at 10:07

LOL you could try radix sort, or simply use std::sort :)

– RSFalcon7
Oct 17 '14 at 16:54

1

No chance. It's a lab assignment. :D

– rbaleksandar
Oct 17 '14 at 17:00

add a comment |

This is the solution but I advise all to be extremely cautious when removing this default limits on the program's stack size. You will experience not only severe performance drop but your system might crash. For example I tried to sort an array with 16 000 000 integer elements with quicksort on a machine with 4GB RAM and my system was almost killed. LOL

– rbaleksandar
Oct 16 '14 at 16:51

@rbaleksandar I think you ~16MB program almost kill your machine because you were working with several copies of the array (may be one per function call?) try a more memory aware implementation ;)

– RSFalcon7
Oct 16 '14 at 23:20

I'm pretty sure the array handling is okay since I'm passing by reference and not by value. The same thing happens with bubblesort. Hell, even if my implementation of quicksort sucks bubblesort is something that you cannot possibly implement incorrectly. LOL

– rbaleksandar
Oct 17 '14 at 10:07

LOL you could try radix sort, or simply use std::sort :)

– RSFalcon7
Oct 17 '14 at 16:54

1

No chance. It's a lab assignment. :D

– rbaleksandar
Oct 17 '14 at 17:00

This is the solution but I advise all to be extremely cautious when removing this default limits on the program's stack size. You will experience not only severe performance drop but your system might crash. For example I tried to sort an array with 16 000 000 integer elements with quicksort on a machine with 4GB RAM and my system was almost killed. LOL

– rbaleksandar
Oct 16 '14 at 16:51

@rbaleksandar I think you ~16MB program almost kill your machine because you were working with several copies of the array (may be one per function call?) try a more memory aware implementation ;)

– RSFalcon7
Oct 16 '14 at 23:20

I'm pretty sure the array handling is okay since I'm passing by reference and not by value. The same thing happens with bubblesort. Hell, even if my implementation of quicksort sucks bubblesort is something that you cannot possibly implement incorrectly. LOL

– rbaleksandar
Oct 17 '14 at 10:07

LOL you could try radix sort, or simply use std::sort :)

– RSFalcon7
Oct 17 '14 at 16:54

No chance. It's a lab assignment. :D

– rbaleksandar
Oct 17 '14 at 17:00

add a comment |

You array is being allocated on the stack in this case attempt to allocate an array of the same size using alloc.

answered Dec 4 '09 at 15:43

rerun

21.1k53571

add a comment |

You array is being allocated on the stack in this case attempt to allocate an array of the same size using alloc.

answered Dec 4 '09 at 15:43

rerun

21.1k53571

add a comment |

You array is being allocated on the stack in this case attempt to allocate an array of the same size using alloc.

answered Dec 4 '09 at 15:43

rerun

21.1k53571

You array is being allocated on the stack in this case attempt to allocate an array of the same size using alloc.

answered Dec 4 '09 at 15:43

rerun

21.1k53571

answered Dec 4 '09 at 15:43

rerun

21.1k53571

answered Dec 4 '09 at 15:43

rerun

21.1k53571

answered Dec 4 '09 at 15:43

rerun

21.1k53571

add a comment |

Because you store the array in the stack. You should store it in the heap. See this link to understand the concept of the heap and the stack.

edited Apr 14 '12 at 20:50

evotopid

4,12522139

answered Jan 7 '11 at 23:21

Narek

18.3k57174312

add a comment |

Because you store the array in the stack. You should store it in the heap. See this link to understand the concept of the heap and the stack.

edited Apr 14 '12 at 20:50

evotopid

4,12522139

answered Jan 7 '11 at 23:21

Narek

18.3k57174312

add a comment |

Because you store the array in the stack. You should store it in the heap. See this link to understand the concept of the heap and the stack.

edited Apr 14 '12 at 20:50

evotopid

4,12522139

answered Jan 7 '11 at 23:21

Narek

18.3k57174312

Because you store the array in the stack. You should store it in the heap. See this link to understand the concept of the heap and the stack.

edited Apr 14 '12 at 20:50

evotopid

4,12522139

answered Jan 7 '11 at 23:21

Narek

18.3k57174312

edited Apr 14 '12 at 20:50

evotopid

4,12522139

edited Apr 14 '12 at 20:50

evotopid

4,12522139

edited Apr 14 '12 at 20:50

evotopid

4,12522139

answered Jan 7 '11 at 23:21

Narek

18.3k57174312

answered Jan 7 '11 at 23:21

Narek

18.3k57174312

answered Jan 7 '11 at 23:21

Narek

18.3k57174312

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu