Little confusion Regarding general Initilizaion..!!!

[kunalnandi]

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

[caduel]

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.

[wysota]

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.

[caduel]

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

( 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. )

[Kumosan]

( 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.

[spirit]

STL vector, this is General programming.

[wysota]

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

[spirit]

I totally agree. STL is ugly like MFC

[wysota]

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.

[spirit]

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

[caduel]

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.)

[wysota]

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.