Problem with std::map management

[JonB]

@SamiV123

accessing the index at item count is already undefined.

Meaning what? It will give std::out_of_range: vector. Which is what the user sees.

I don't see why we disagreeing here. In general the way to see where such an error occurs is under a debugger.

Yes, if there is no other code it may well be that oAutoCADVersionNumberMap = { is evaluated/executed before oAutoCADVersionNumberVector = { and that is the cause of the error. What harm does it do to check this under debugger?

[BushyAxis793]

@SamiV123 Yes, global.

[SamiV123]

@JonB said in Problem with std::map management:

@SamiV123

accessing the index at item count is already undefined.

Meaning what? It will give std::out_of_range: vector. Which is what the user sees.

I don't see why we disagreeing here. In general the way to see where such an error occurs is under a debugger.

Yes, if there is no other code it may well be that oAutoCADVersionNumberMap = { is evaluated/executed before oAutoCADVersionNumberVector = { and that is the cause of the error. What harm does it do to check this under debugger?

actually the operator [] isn't required to be "safe".

so therefore if you have

std::vector<int> foo; foo[0];

It's undefined behavior.

I was just pointing out that you can't access an element at the index that equals the size of the vector since the last valid index is size - 1 so your comment was incorrect.

[BushyAxis793]

Gentlemen, I found a mistake. One of the vectors in another file had 204 instead of 205 elements. Sorry for the confusion. And thank you for your help!

[SamiV123]

@BushyAxis793 said in Problem with std::map management:

@SamiV123 Yes, global.

Yeah, don't do that.

either make a function like this

std::vector<int> MyVec() {
   static std::vector<int> foo {... };
  return foo;
}

or use global pointers and restructure your code not to rely on global object initialization.

[JonB]

@SamiV123 said in Problem with std::map management:

I was just pointing out that you can't access an element at the index that equals the size of the vector since the last valid index is size - 1 so your comment was incorrect.

I don't know what you are on about or why you just seem to want to argue. Of course everyone knows "the last valid index is size - 1". My comment was not incorrect, I said just that. Are you quibbling over the fact that I wrote "or greater than the item count." when I could have written "greater than or equal to the item count." but didn't because I was trying to give the idea typing quickly, is that it? It doesn't matter whether you try to access [10] or [1000000] in a vector which has 10 elements, either one is "out of range". Why don't you actually try it and see whether you get uncaught exception of type std::out_of_range: vector instead of arguing semantics?

OP writes

One of the vectors in another file had 204 instead of 205 elements.

Oh look, just what I said: trying to access an element one (or could have been more, but 1 here) beyond the number in a vector....

[SamiV123]

@JonB said in Problem with std::map management:

@SamiV123 said in Problem with std::map management:

I was just pointing out that you can't access an element at the index that equals the size of the vector since the last valid index is size - 1 so your comment was incorrect.

I don't know what you are on about or why you just seem to want to argue. Of course everyone knows "the last valid index is size - 1". My comment was not incorrect, I said just that. Are you quibbling over the fact that I wrote "or greater than the item count." when I could have written "greater than or equal to the item count." but didn't because I was trying to give the idea typing quickly, is that it? It doesn't matter whether you try to access [10] or [1000000] in a vector which has 10 elements, either one is "out of range". Why don't you actually try it and see whether you get uncaught exception of type std::out_of_range: vector instead of arguing semantics?

OP writes

One of the vectors in another file had 204 instead of 205 elements.

Oh look, just what I said: trying to access an element one (or could have been more, but 1 here) beyond the number in a vector....

I don't think everyone knows. It seems obvious that the OP is a newbie since if they weren't they would not have even posted this question.

So therefore they might have gone off the rails thinking that accessing the element at an off by one index is actually safe.

This is C++, you can't be "99%" correct you have to be 100% correct or your program is ill-defined. (which it always is anyway)

Thats all, peace out.

[JonB]

@SamiV123 said in Problem with std::map management:

This is C++, you can't be "99%" correct you have to be 100% correct or your program is ill-defined. (which it always is anyway)

I will hold you to this in all your future posts, then ;-) [ <-- That's a wink! ]

For the record, I have edited my original post to be "100%" clear :)

[Christian Ehrlicher]

@SamiV123 It's funny that you're arguing with 100% correct c++ here but advertising a proprietary way to link against libraries ('# pragma comment(lib, "ws2_32.lib")') in another thread.

[SamiV123]

@Christian-Ehrlicher said in Problem with std::map management:

@SamiV123 It's funny that you're arguing with 100% correct c++ here but advertising a proprietary way to link against libraries ('# pragma comment(lib, "ws2_32.lib")') in another thread.

Yeah and that's completely orthogonal to this here.
Using a compiler specific way to link your program doesn't make it ill-defined (just possibly non portable).

[Christian Ehrlicher]

@SamiV123 said in Problem with std::map management:

just possibly non portable

Which contradicts the c++ idea.

[SamiV123]

@Christian-Ehrlicher said in Problem with std::map management:

@SamiV123 said in Problem with std::map management:

just possibly non portable

Which contradicts the c++ idea.

Maybe so but that's not how real life works. In real life practically every C++ program is only as portable as the developers intended, i.e. it only compiles and runs on the platforms targeted by the developers.