Hi everyone.

I'm maintaning some legacy code.

It used some crazy big plain arrays. So of course (with unit testing backing me off) i decided to use some std::vectors and std::arrays where they applied. Instead of big arrays, some small but well controlled arrays.

Everything was working fine but when i decided to actually delete one of the big plain array, some random crashes started to occur with very random error messages from the compiler. By experience, this smells like accesing vector/array bad locations. The code is far from clean now, but i need to find this outlimit acceses, so the tests keep succeding.

So, is there an alternative version of array/vector which actually throws and exception(or gives some message) when the index is outlimits?

Would it be a better idea to actually inherit from vector/array and override the index operator?

What do you say?

PD: The debugger won't help either in this case. The crashes are very random.

I love std::vectors. Quick question, is any of the data your handling in your vectors pointers?

some random crashes started to occur with very random error messages from the compiler.

Is your compiler actually crashing and giving you error messages? Or are you trying to say that your compiled program is crashing when you run it?

So, is there an alternative version of array/vector which actually throws and exception(or gives some message) when the index is outlimits?

In general you do not want throwing exceptions here since you never should access an invalid index in the first place. What you want is an assert (usually only enabled during debug builds but up to you). Of course with a decent compiler and a bit of debug info you should not even need that since you just run into a crash and then walk up the call stack until you see where your program tried to access an invalid index.

Would it be a better idea to actually inherit from vector/array and override the index operator?

Standard library containers are not intended to be inherited from. I have never seen a legitimate use for it either.

PD: The debugger won't help either in this case. The crashes are very random.

Of course the debugger helps even in those cases.

I hate std::vectors.

I love std::vector. There are legitimate reasons not to use it in specific circumstances but anyone 'hating' it probably does not understand it well enough and would run into the same or worse problems with something hand-rolled.

Edit: For example for gcc's typical standard library you can add define _GLIBCXX_DEBUG and get nice error messages like this:

C:/Qt/Qt5.5.0/Tools/mingw492_32/i686-w64-mingw32/include/c++/debug/vector:357:
    error: attempt to subscript container with out-of-bounds index 10, but 
    container only holds 10 elements.

Objects involved in the operation:
sequence "this" @ 0x0028fe44 {
  type = NSt7__debug6vectorIiSaIiEEE;
}

I believe MSVC automatically does a bounds check when you build the standard Debug configuration but I don't have it here to test at the moment and it's been a while since I was worried about that particular kind of error.

Quote


I hate std::vectors.
I love std::vector. There are legitimate reasons not to use it in specific circumstances but anyone 'hating' it probably does not understand it well enough and would run into the same or worse problems with something hand-rolled.

"I hate std::vectors" was not a defining statement that they are terrible. I just don't like to use them. I am not discrediting their existence or ability to perform the job, I myself just have a personal dislike of them. Assuming someone's level of understanding is somewhat of an underhanded insult btw.

"I hate std::vectors" was not a defining statement that they are terrible. I just don't like to use them. I am not discrediting their existence or ability to perform the job, I myself just have a personal dislike of them. Assuming someone's level of understanding is somewhat of an underhanded insult btw.

Then I suggest you either get into the habit of choosing more neutral language or explaining your point of view in more detail. With what you wrote there is really only the reader's choice between "tries to troll" or "does not know what he/she is doing".

Are this assertions compile-time or runtime?

The array acceses are not trivial.

Is your compiler actually crashing and giving you error messages? Or are you trying to say that your compiled program is crashing when you run it?

Yeah, sorry. When i run the program it crashes, not the compiler. By the way, i have isolated this kind of crash:

[xcb] Extra reply data still left in queue
[xcb] This is most likely caused by a broken X extension library
[xcb] Aborting, sorry about that.
program: /var/tmp/portage/x11-libs/libX11-1.6.3/work/libX11-1.6.3/src/xcb_io.c:576: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed.
Abortado

It bugs me, because before the array refactorization, ir worked fine. So i guess it has to be something there.

Edit: For example for gcc's typical standard library you can add define _GLIBCXX_DEBUG and get nice error messages like this:

With this flag define nothing changes.

Of course the debugger helps even in those cases.

I'm using gcc4.9/gdb7.9 and gdb stops at an external library routine. It's like if some memory got corrupted, that's all the information i have gotten from gdb.

Ok.

Using this flags in the compiler: -fsanitize=address -fstack-protector-all

together with the flag _GLIBCXX_DEBUG solved it. I was right, there were some out of bounds acceses.

No it works like a charm.