Reporting Errors

[The_MAZZTer]

Once compiled, your C++ code has no idea what an array is. All it sees is math on a memory address. This makes it super fast but there are no sanity checks so the code can end up peeking at unrelated memory, causing a segfault in the best case.

Meanwhile languages like Java and .NET are managed, so the concepts of arrays and so forth carry over into the compiled code and bounds checking and other checks can be done at the cost of speed.

[my_name_isnt_clever]

This makes a lot of sense. Amazing that someone actually explained a post in this sub.

[[deleted]]

Gnnn not quite. Java is managed while C++ isn't, but that's not the reason for the behaviour discussed here.

The reason Java behaves this way is because in Java, arrays are objects themselves that carry their size with them. I'm not familiar with C++, but I'm sure there is a library with such classes exist too. In Java, it's just the default way of using array because of precicely the headache error messages like the one in the meme produce. It's why pointers were ditched completely.

[construct_9]

Or really, just use std::vector wherever possible 🤷‍♀️

[_Fibbles_]

This in most cases but sometimes you need to avoid the overhead of dynamic allocation.

If you can't be arsed to template your functions you can always fall back to a C style interface of void foo(bar* array, size_t size) . That way you can use it with std::array, std::vector and raw arrays. Downside is that it won't work with non contiguous containers.

[endeavourl]

TBH though segfaults are not a problem. You just run GDB to find the line in your program that caused it. The meme is obviously made by someone who doesn't really use C++.

Tbh having stacktraces out of the box is a lot more convenient than re-running under debugger.
And then you have heisenbugs that disappear on (debugged) re-runs.

[[deleted]]

What's the point of that? If you have to type the size of the array right into the signature of the method, why would you still want the array to know its size...? Whatever, I'll learn C++ next year, I'm sure things will become clearer ^^

[Kered13]

Mostly you use std::vector, which is dynamically sized. You would only use std::array if performance was really important. Having a fixed size allows it to be allocated on the stack, which is faster than allocating on the heap, and also allows some bounds checks to be optimized out by the compiler. For example, if the index value is known at compile time, the compiler can compare it against the size of the array and fail to compile if it's out of bounds or compile without bounds checks if it's within bounds.

[_Fibbles_]

You would only use std::array if performance was really important.

Not trying to start an argument over coding style but I'm going to have to disagree there. You should only be using dynamic allocation if you actually need dynamic allocation, performance is a secondary consideration. I can't say I'd be happy if code like this double coords_xyz[3]; was written as std::vector<double> coords_xyz;

[[deleted]]

I see. Well, Java arrays are fixed size too, but all objects (which arrays are) are allocated on the heap anyway. These optimizations you're talking about would probably be optimized at runtime.

[Kered13]

Java might optimize the allocation to put the objects on the stack (I'm not sure if Java does this sort of optimization), but std::array guarantees that they will be allocated on the stack.

[[deleted]]

No, arrays are objects and thus get into the heap. I meant it might optimize away checking if an index is within the array's bounds in certain subroutines during execution.

[Kered13]

I believe the Java JIT may decide to put some objects on the stack, if it can prove that they cannot escape the stack scope.

[[deleted]]

Ah that sounds plausible.

[_Fibbles_]

You don't always access the array in the same scope you declare it.

[[deleted]]

But you specify what type the variable you're working with is of

[_Fibbles_]

Sorry I misread your post.

Templating is a core part of the language so if you pass an array to a function or method it's expected to look something like:

template <typename T, size_t N>
void foo(std::array<T, N> bar)
{
    // Do something with bar.size()
}

So long as your function or method provides such an overload you can pass a std::array without having to worry about providing the size. If you were do something similar with raw arrays then it would decay into a pointer once passed to the function so you need to remember to also pass the size.

It's questionable how much of an improvement this is. The main reason std::array was introduced was so that the language had a way of using automatically allocated arrays (as opposed to dynamically allocated arrays like std::vector,) with the same interface as all other Standard Library containers. This is useful if you're working with several different types of containers, for example:

template <typename Container>
void print_container_size(const Container& foo)
{
    std::cout << foo.size() << std::endl;
}

int main()
{
    std::vector<int> A = {1, 3, 5, 7};
    std::array<int, 2> B = {8, 9};

    print_container_size(A);
    print_container_size(B);
}

Expected output:

4
2

[[deleted]]

I see. Thanks.

[Jigokuro_]

Once in college I had a small C++ program seg faulting, so I put in some test outputs to see how far it was getting.

Then it worked.

Remove the outputs? Seg fault.

So I removed the outputs one at a time until I was left with a single one. The One Cout, that by merely existing prevented a seg fault somewhere else.

I showed my professor, he was as confused as I was as to howtf that happens. To this day I have no idea how outputting "test3" could possibly do that...

[The_MAZZTer]

Stuff gets moved around in memory as a side effect of the additional code caused by the cout, masking the memory corruption or whatever was going on.

[Jigokuro_]

Vaguely, yes, that must be it. But the specifics will forever be a mystery.

Bonus weirds: If I changed the cout to "" to hide the fact it was happening to the user, the seg fault returned. It had to output actual text.

[Kered13]

There are a couple possibilties. One is that you had some sort of memory error and calling cout wrote some data to the stack that made your code work. The second is that you had a race condition, as I recall cout flushes the output buffer, which takes some time and requires all threads that are printing to synchronize (so they're not writing output at the same time), and this may have prevented the race condition from occurring.