(1) Huh? unsigned char c; while(cin>>c) cout<<c<<'\n'; gives exactly what I expect
(2) The value of (unsigned char)0 *is* 0; not the value of the character '0'
What exactly do you expect? Moreover, your thought experiment is incomplete, as you have provided no assumptions for the behavior of (cin >> c). I am sure that our expectations coincide on assumption that cin is empty
But the text form of (unsigned char) 0 is the string "0", not the character '\0'.
This constructs a temporary GameEntity (that's the GameEntity() expression). Then, a vector element GameEntity is copy-constructed from the temporary. Then the temporary is destroyed (temporaries are destroyed "at the semicolon").
If GameEntity‘s copy constructor has trivial path, there is a workaround, although contrived and against the bitzkrieg convention that objects in C++ should not have an error state: push back a temporary constructed to follow that trivial path and do serious things to v.back() afterwards.
Am I correct you are using enumerated types to store values outside the declared range of the type? I admit that C++ already allows this where it allows (Enum()) as a valid expression; however, I would never mix entities like that. I would rather use the underlying type or, if it is needed for resolution, a wrapper class.
BTW, I would really appreciate if enumerated types were true compile-type sets of values in C++, with expressions like (wrapping) increments (++e), (--e), (limits<e>) (this one would require compiler magic because builtin types only have min and max as library definitions) and (e = dynamic_cast <Enum> (07)) throwing bad_cast. Of course, these features can be simulated with TMP, but it takes a lot to write such code (and, even worse, to read it).
[giecrilj71pl] > And, even if you insist, the interface class should be called Matrix (or, in fact, Grid proper) and use a vector of vectors as an implementation detail.
My Nurikabe Grid class uses a vector of vectors as an implementation detail. It is strongly encapsulated and nobody outside of the Grid is aware of its presence. I saw, and continue to see, no reason to further encapsulate the Grid's storage. (On the other
hand, Region is a nontrivial data structure, which benefits greatly from the partial encapsulation that I gave to it.)
On the other hand, a Matrix is a fairly general data structure, and if you promoted your implementation to a separate component, you could use it elsewhere. But then my criticism at your implementation choice would be much more valid, so it was actually
clever to hide it
> but then, please explain the options for low RAM environments because STL is not an option for various reasons.
Actually, the STL is extremely good at conserving space.
Your correctly observed in Installment 1 how the triple A-I-C saves us from having A*C implementations. However, this only applies to
source code, because the object code will contain (up to) A*C implementations (actually A*C*T). Of course, most code sets do not use all pairs; however, depending on the domain, the object size can skyrocket. This is not a big problem for algorithms
like find, and any algorithms you would type inline off your head, but complex and long template algorithms do exist, e.g. sort. That was a significant problem for Adobe when they created their image manipulation library.
Mr_Crash! Have you ever used Windows Media Encoder? Do try, and in the meantime go visit your family in another state
Vector of vectors is appropriate for a text editor, less appropriate for relational data where you want to do things to rows, and totally inappropriate for a matrix, unless the matrix is so huge that you cannot keep it all in RAM --- but then, please explain
the options for low RAM environments because STL is not an option for various reasons. And, even if you insist, the interface class should be called Matrix (or, in fact, Grid proper) and use a vector of vectors as an implementation detail.
And I do not think that explaining the viewers that the numbers count the fields in contiguous white areas would be such a waste of time. I am watching your videos in circumstances where I cannot type.
The problem with a shared pointer to a vector is that you have to dereference twice to get at the data, so what is really needed is a form of a vector featuring shared storage and reference counting; I would say not having this is an oversight.
My question at Installment 1 got drowned together with my comment it was in, and I would really like to know: STL is optimised for time, do you know a library optimised for space? I mean, get along with virtual functions but do not create the M*N*X implementations
As a related thought about safe destruction, observe that there is no object in the STL to safely hold a standard message catalogue.