#include <vector>

I'm not sure I understand.

Forward declaration for STD types is undefined behavior so that wouldn't work + It doesn't work for members.
So why isn't the include needed ?

According to Wiktionary, interesting = interest +‎ -ing, from Latin interesse = present active infinitive of intersum = inter- +‎ sum, where

inter:

From Proto-Italic *enter, from Proto-Indo-European *h₁entér (“between”). Cognates include Sanskrit अन्तर् (antár, “between, within, into”), Oscan ????? (anter, “between”), Old Irish eter (“between”), Albanian ndër (“between, among, amid, throughout”), Old High German untar (“between”) and German unter (“among”).

sum:

The present stem is from Proto-Italic *ezom, from Proto-Indo-European *h₁ésmi (“I am, I exist”). Cognates include Ancient Greek εἰμί (eimí), Sanskrit अस्मि (ásmi), Old English eom (English am). The perfect stem is from Proto-Italic *(fe)fūai, from Proto-Indo-European *bʰúHt (“to become, be”) (whence also fīō (“to become, to be made”), and future and imperfect inflections -bō, -bam).

In other words he has a patch for it somewhere, see discussion in D1637.

No I do not have a patch anywhere related to this. If I am being more specific at what I am getting at, just see the differences of vector<notBoolT> vs vector<boolT>.
D1637 has nothing to do with this. (I did not need to go with cpp btw. Js was optimized to the point where it performed at the same speed). It’s more of low level details in this case.

Just to clarify, I am not being vague here. I am just trying to avoid making a direct statement since I don't consider myself an expert in C++.

I guess you mean that https://en.cppreference.com/w/cpp/container/vector_bool might or might not be worth reading

(Also to clarify, I didn't want to imply that you were intentionally vague in that statement, I actually wanted to derive the statement from the etymology but failed the last steps of the deduction and it's useless indirection anyhow)

Or tldr; It's not an STL container and therefore does not work like one (code which would compile for other T vector would not compile for this specific thing). And it's placement is widely regarded as a mistake in the standard. But despite the various attempts to remove or depreciate the thing, it still remains as part of the standard. For backwards compatibility I suppose.

I guess this is the part where I propose solutions. boost bitsets.

refs https://stackoverflow.com/questions/17794569/why-is-vectorbool-not-a-stl-container

So the problem with it is it pretends to be an STL container but isn't one, which is arguably contradictory and thus a mistake, and thus can be assumed to be deprecated in the future and thus not using it now would mean that our code doesn't have to be changed in the future, even if one only uses those functions that compile fine now.

The question is whether there is also a plan for a successor, since the use case for bit arrays won't go away.

I thought it would be preferable to avoid making the code depend on boost libraries.

Arguments for not using this and using boost.
https://www.boost.org/doc/libs/1_54_0/doc/html/container/Cpp11_conformance.html#container.Cpp11_conformance.Vector_bool

A bitset that is reasonably performant is not that difficult to implement. So that is an alternative too.

Or just keep this as is. As long as whoever will commit this is fine with it, this whole discussion can be safely ignored.

@Angen can you try the boost bitesets and do some profiling ? :) You can usually do so in the tests, so that you have an easy sandbox.

Would be something like

return (!(LosIsOffWorld(i, j) ||
    !(i >= 0 && j >= 0 && i < m_TerrainVerticesPerSide && j < m_TerrainVerticesPerSide)) &&
    m_LosState[j*m_TerrainVerticesPerSide + i] & (state << (2 * (player - 1)))

Could be make clearer with functions maybe :)