Little confusion Regarding general Initilizaion..!!!

Hello,

I have some confusion with Initilization of int.

Code:

---

#include <iostream>
 
using namespace std;
int main()
{
	int *p = new int[4];
	for( int i = 0; i < 6568; i++ )
	{
		p[i] = i;
		cout << i << " ->> " << p[i] << endl;
	}	
	return 0;
}

---

Above, i have initilize int *p = new int[4];
when i run this program on windows it get crashed after printing

Quote:

---

Output :
0 ->> 0
.
.
.
.
6567 ->> 6567

---

why is it so ???? :confused:


And instead of Initilizing like this
int *p = new int[4];

if i initilize
int *p = new int[100];

then on running this example it get crahsed on 182 ?
why is it so ??? :confused:

Quote:

---

Output :
0 ->> 0
.
.
.
.
182 ->> 182

---

can any body explain me why this happens ?
normally we expect that int[100] will take more values int[4], but its completely different here..!!

can any body tell me what does these below initilization says..!!

int *p = new int();
int *p = new int(10);
int *p = new int[10];

Thanks & Best Regards
Kunal Nandi

Quote:

---

Originally Posted by kunalnandi

int *p = new int();

---

creates a pointer to int with default value 0.

Quote:

---

Originally Posted by kunalnandi

int *p = new int(10);

---

creates a pointer to int with default 10.

Quote:

---

Originally Posted by kunalnandi

int *p = new int[10];

---

creates a pointer to a first element of array with size == 11

so, if you need to pass of all an array elements you need to use next code

Code:

---

const int arraySize = 10;
	int *p = new int[arraySize];
	for (int i = 0; i < arraySize + 1; ++i) {
		*(p3 + sizeof(p) + i) = i;
		qDebug() << (*(p + sizeof(p) + i));
	}

---

Thanks spirit,

one more question..!!

int *p = new int[4];
if i use this in my example then application get crashed after printing 6567

int *p = new int[100];
if i use this in my example then application get crashed after printing 182


Why is it so ??

Thanks & Best Regards
Kunal Nandi

6567 it is a number of iteration, but your array has only 4 or 100 elements and then index out of range in first case after i == 4 and in second case i == 100.

you mean to say tht p[0].. to p[4] will accept values and after tht index out of range..

is it like this
p[0] = 0
p[1] = 1
p[2] = 2
p[3] = 3
p[4] = 4
p[5] will give index out of range ??? is it so ??

i am not getting this..!! i get crash after i = 6567. why i don't know :confused:

This is call undefined behaviour. You are accessing (overwriting actually) memory which is not yours. Anything could happen. (You are destroying your stack amongst other things...)

That is why one can't explain (ok you could if you examine your cpu architecture, compiler etc most carefully you could explain it) at which iteration it will crash. That is part of being undefined.

Quote:

---

Originally Posted by spirit

creates a pointer to a first element of array with size == 11

---

Ouch, this statement is online for days and nobody disagrees loudly?

int *p = new int[10];

This reserves memory for exactly 10 integers. 0 ... 9, i.e. size == 10.

Quote:

---

Originally Posted by caduel

That is why one can't explain (ok you could if you examine your cpu architecture, compiler etc most carefully you could explain it) at which iteration it will crash. That is part of being undefined.

---

Actually it's possible to determine when the application will crash. Memory protection is mostly based on memory pages, so the likely place for the system to notice a violation is when you try to write beyond a page you have access to. As pages are most often 4kB big, the likely spot to have a crash is at most 4096B after the last valid index (unless you are "lucky" and the next page is reserved for you as well). Of course this is all academic talk - accessing memory that is not yours is forbidden, even one byte after the last valid index. This might get your frame stack corrupted which leads directly to many dangerous situations.

Yes, tracking down issues (crashes, if you're lucky) due to out of bounds violations (stack corruptions, overwritten local variables etc) is part of the "fun" when working with C/C++. Especially when the code was written by a dear colleague that has ideally left the company since :p

( In C++ you have more ways to step around this kind of problem as you have std::vector etc and do not have to work with what C calls arrays so often. )

Quote:

---

Originally Posted by caduel

( In C++ you have more ways to step around this kind of problem as you have std::vector etc and do not have to work with what C calls arrays so often. )

---

What do you mean with 'std::vector'? You certainly mean QVector. ;)

STL vector, this is General programming.

STL vector sucks :cool: It's much better than STL string (compared to QString), but sucks anyway...

I totally agree. STL is ugly like MFC :D

It's not that it's "ugly". According to me it has two problems - it lacks functionality and it has many different implementations with different quality, complexity, etc. And it tends to be heavy sometimes... Qt classes are much more lightweight.

if compare Qt and STL, then using Qt classes more convenient and as you say, more light.

When compared with a C style "array", even the worst STL is a blessing.
But I agree that Qt classes often offer better usability and more useful methods.
(But, as there are times when one can use C++ and STL but not introduce the dependency to Qt, I use STL, too.)

Quote:

---

Originally Posted by caduel

When compared with a C style "array", even the worst STL is a blessing.

---

C style arrays don't cause crashes when used correctly. Bad STL implementations (like the one present in VC6) do.

What does, when used correctly?
Obviously, anything you use as a layer between you and the cpu has a chance of introducing a bug and thus a crash: By 'worst' I did not mean buggy. :-)
But abstractions like (std:: or Q)vector, map etc just like classes you build upon them help because they allow you to work and think are nearer to the real world than the datastructures C has to offer.
(I realize that C++ has basically the same and this is rather an issue of good libraries. Only it's more easy and thus likely too use string, array etc 'classes' in C++ than C.)

Obviously naked C arrays have there place, too.
(Also in most applications I work with the trouble of checking "does the input fit here", "is this stack based array big enough" etc just is a pain. I see too many places where crashes would occur if the input was only too long. Sure, one can program to prevent that (you can in assembler, too...). But if people don't do it, not much of a help that they could have done it.
Therefore, in my opinion it is good if a language - or library - allows one not to have to deal with the dangerous world of memory management. (I say allow because now and then you need/want to have to deal with it. But not always and imho definitely not for string operations.)

And yes, one can write pretty code in C (one can in any language). But having to work with a large C (and partly C++) code base on a daily basis: believe me when I tell you: you can write very ugly code in it, too.
(The lack of a proper string entity leads to numerous hard to read (often incorrect) for-loops, working on char*, incrementing pointers etc that is way harder to read, debug etc than a e.g. nice simplifyWhitespace(), boost::strip() or whatever. Once again, I agree that one could use (or create) a string-struct in C, and write nice reusable and well named functions for it. But could is theory, and ugly code is my reality ;-) )

To sum up: it is not a problem with C, or C++, or naked C style arrays. It is a problem of the people using it...

Quote:

---

Originally Posted by caduel

What does, when used correctly?

---

As mentioned, VC6 implementation of STL does.

Quote:

---

But abstractions like (std:: or Q)vector, map etc just like classes you build upon them help because they allow you to work and think are nearer to the real world than the datastructures C has to offer.
(I realize that C++ has basically the same and this is rather an issue of good libraries. Only it's more easy and thus likely too use string, array etc 'classes' in C++ than C.)

---

That's completely another case but then we come back to a question "why use STL if you have Qt?". The latter provides an even more abstract and complete interface with better speed, memory footprint and capabilities.

Quote:

---

(The lack of a proper string entity (...)

---

Unfortunately for some time std::string is not a "proper string entity" as it is based on char* as well and in times of globalization this is unacceptable.