>> double * reserved(aligned_alloc(8192));
>>
>> // 3x3
>> Map<double> m(reserved, 3, 3);
>>
>> // 10x10 -- resize w/o reallocation -- equivalent to NeverRealloc w/o
>> much repatching(?)
>> m.remap(reserved, 10, 10);
>
[...]
> Matrix<float, Dynamic, Dynamic, NoRealloc> A, B, C;
>
> A.reserve(16); A.resize(4,4);
> B.reserve(25); B.resize(5,5);
> C.reserve(81); C.resize(9,9);
>
> B=A; //this should work and resize B to 4x4
> B=C; //this should raise an assertion failure
>
> To achieve this behaviour, we do need a dedicated class -- or an
> option, such as in the patch.
Sure... but not quite -- if we are talking about adding extra
"sanity-checking" in the debug builds of an app, and if current API
has no such assertions, then some form of changes would be needed.
But in such a case, still -- I don't think Benoit was arguing against
any changes -- only in favor of smaller/more-elegant ones...
Map<> obj. ctor could indeed have an additional arg denoting the max
size of the (re)mappable mem (on which it is mapping)... or indeed, as
others have alluded to, one could pass an 'array object' instead of
just 'float/double *' (given that what you are really trying to
'sanity-check' is the boundary -- and such is not meant to
auto-reallocate but to assert -- implying that this should not be
happening 'by design') -- so a logical conclusion would be for Map<>
to be able to map from a vector/array type (e.g. ::boost::array
semantics), then:
array a1(25);
array a2(81);
Map m1(a1, 5, 5);
Map m2(a2, 9, 9);
m1 = m2; // assertion due to boundary-checking of 'intelligent' arrays...
or if constructing/mapping explicitly from "double/float *"
double *a1(alloc(25));
Map m1(a1, 5, 5, 25); // i.e. additional arg denoting max mappable mem.
double *a2(alloc(81));
Map m2(a2, 9, 9, 81);
m1 = m2; // the same assertion... (ifndef NDEBUG of course)
In fact, given that you are only requiring an assertion (not exception
throwing), then the actual presence of the above fields (e.g. in the
Map class, the 'bounds-keeping' variable could, itself, exist only
#ifndef NDEBUG
size_t max_mappable_size;
#endif
Alternatively, as you mentioned -- another class may be used... but,
if such is to be the case, then what I was trying to say was that this
class feels like being more of a facade design-pattern, not a patch to
the existing class:
struct blah {
double * data;
Map m;
blah()
: data(allocate), m(data, x, y)
{
}
etc. etc. -- like op= with checking for memory-bounds violations...
};
.... but only if one wants it...
from your code-example it looks to me like it really should be subject
to an "array" object... or a Map object... as memory-bounds checking
is really a question of abstracting the c-style 'arrays' in the first
place... ideally...
kind regards
Leon.