-1

Without giving an explicit size, it works up to index 79. It prints the value 200 at index 79, but when I increase the index by 1 that is 80, it prints nothing and program terminates.

#include <iostream>
using namespace std;

typedef int list[];
int main() {
   list myList{};
   myList[79]={200};
   cout<<myList[79]; // OUTPUT: 200
   return 0;
}

#include <iostream>
using namespace std;

typedef int list[];
int main() {
   list myList{};
   myList[80]={200};
   cout<<myList[80]; // No Output and Process finished with exit code -1073741819 (0xC0000005)
   return 0;
}
Hamza Khan
  • 21
  • 5
  • 4
    That's an example of undefined behavior. – rawrex Jun 05 '21 at 12:08
  • 2
    There's no such thing as a "dynamically growing array" in C++. C++ does not work this way. The resulting code results in random memory corruption, which gets bad enough to cause an immediate crash only when you try to use that particular index, but the whole thing is undefined behavior. – Sam Varshavchik Jun 05 '21 at 12:11
  • This shouldn't even compile. `list myList{};` is array of size 0. – Lukas-T Jun 05 '21 at 12:13
  • @SamVarshavchik I initialized the array with i using a loop, from 1 up to 79 and printed the whole array and it did print the values from 1 to 79 and beyond that it didn't. How could it be randomly initializing the indexes up to 79 and crash always at 80. Still confused. I mean how an array can be dynamically growing upto 79 without explicit size.... – Hamza Khan Jun 05 '21 at 12:32
  • @churill it is getting complied as well as running bro. – Hamza Khan Jun 05 '21 at 12:32
  • I repeat: there is no such thing as a dynamically growing array in C++. Which part of this is unclear to you? And just because the program compiles doesn't mean that it will run correctly. C++ does not work this way. – Sam Varshavchik Jun 05 '21 at 12:34
  • @HamzaKhan That means you are probably compiling with `g++`. Then you should add the flags `-Wall` and `-pedantic` to spot pontentially dangerous non-standard extensions. Zero-size arrays [are not allowed in C++](https://stackoverflow.com/a/9723093/5105949). – Lukas-T Jun 05 '21 at 13:00
  • Please consider spending some time in reading about the containers that the C++ Standard Library has to offer, like [`std::vector`](https://en.cppreference.com/w/cpp/container/vector) or [`std::map`](https://en.cppreference.com/w/cpp/container/map). – Bob__ Jun 05 '21 at 13:25
  • The array does not and can not grow. By the language standard it is a fixed size at compile time. You are just accessing an array out of bounds. This is undefined behavior. One of the worst behaviors of UB is when broken code appears to work under some conditions even though it is broken. – drescherjm Jun 05 '21 at 13:40
  • @SamVarshavchik The Unclear part is that how an array, without explicit size, is getting initialized upto 79th index when there is no dynamic array in c++? Array is storing values from 1 to 79 and are also retrieved. And if it is getting initialized upto 79, what is hindering to from getting initialized beyond 79? – Hamza Khan Jun 05 '21 at 15:28
  • It's very simple: [undefined behavior means anything can happen](https://stackoverflow.com/questions/32132574/does-undefined-behavior-really-permit-anything-to-happen). In your specific case, with your specific compiler, C++ library, and operating system, there just happens to be, by random, some unused or not-yet used memory that's big enough to store 79 values. But that's only true, right this instant. Tomorrow, when you run the same program, this may no longer be the case. For others, the same program might work only up to 50 values. For others, it will crash immediately. Welcome to C++! – Sam Varshavchik Jun 05 '21 at 15:46
  • 1
    @HamzaKhan The behaviour you're seeing is pure chance/coincidence. Please read about [undefined behaviour](https://en.cppreference.com/w/cpp/language/ub). – G.M. Jun 05 '21 at 15:47
  • hahaha Thankyou @SamVarshavchik Got your point. – Hamza Khan Jun 05 '21 at 16:52
  • I will definitely go through it...Thanks for writing @G.M. – Hamza Khan Jun 05 '21 at 16:53

2 Answers2

5

First, try to do the following:

list myList {};
cout << sizeof(myList) << endl;
// Prints 0, since no elements 
// Note, the number does not signifies the number of elements,
// it signifies the number of bytes.

The int foo[] is not a dynamically growing array, it is legacy of C and is as primitive as it can be. When you subscript an array, it does not add an element at the index (nor up to the index).

When you do the myList[79]={200}; it does not creates an element, and especially does not populates the array up to this index. Here, your program just tries to access an out of bound memory location (and does write to it, which may be the worst part of it all). It does not matter whether it is 79 or 80, either will lead to undefined behavior.

Note, the T foo[] arrays have no convince for their user or any internal intelligence in them, they represent raw memory. There's no bounds checking, no implicit or explicit growing of the allocated memory.

It is up to the programmer that uses this type to ensure that subscript value is in the allowed range (up to the predetermined size of the array).

That's why C++ programmers should use any appropriate Standard Library container for any real world applications.

rawrex
  • 4,044
  • 2
  • 8
  • 24
  • @rarwrex if myList[79]={200} is not creating an element then how come cout< – Hamza Khan Jun 05 '21 at 15:35
  • @HamzaKhan because it is undefined behavior first of all, in particular, because you **do command to assign a value** to this memory location. Read on a buffer overflow bug. Who knows what you've overwritten in memory with this assignment. – rawrex Jun 05 '21 at 15:56
2

For starters, the code is not legal C++. If your compiler accepts it, then your compiler settings are not strict enough.

If your compiler accepts it, then it treats it as a zero-size array, not as a "dynamically growing array", which isn't a thing.

You're accessing the array out of bounds, so the behavior is underfined (as much as it applies to invalid C++).

HolyBlackCat
  • 78,603
  • 9
  • 131
  • 207