You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since #1086, there are two cellular grid space models:
an unbounded space model KhalimskyPreSpaceND that allow unrestricted access to cell coordinates,
and a bounded space model KhalimskySpaceND that is shipped with many sanity checks and safeguards in order to guarantee cell's coordinates validity (ie that they lie inside the domain).
The second model implies that a (Signed)KhalimskyCellis meant to be given with the associated KhalimskySpaceND in order to allow safe manipulation. Conversely, if a function/method/class needs a cell without the associated bounded cellular grid space, this function/method/class might as well use a pre-cell from KhalimskyPreSpaceND.
Therefore, we should ideally respect the following guidelines:
if a function/method/class needs a (Signed)KhalimskyCell, always pass the associated KhalimskySpaceND,
otherwise, if a function/method/class doesn't need the associated KhalimskySpaceND (eg, the display related functions), then it should only accept a (Signed)KhalimskyPreCell.
If a function/method/class doesn't depend on the cellular grid bounds, it should use a KhalismkyPreSpaceND and the associated pre-cells.
To ease the code update, there is two facilities:
(Signed)KhalimskyCell are implicitly convertible to (Signed)KhalimskyPreCell, or an explicit conversion is available through the preCell() method.
KhalimskySpaceND features an alias to the associated KhalimskyPreSpaceND (named PreCellularGridSpace).
However, there is a little snag: C++ sees the implicit conversion only if it doesn't depend on template deduction. For example, in the following code:
Since #1086, there are two cellular grid space models:
KhalimskyPreSpaceND
that allow unrestricted access to cell coordinates,KhalimskySpaceND
that is shipped with many sanity checks and safeguards in order to guarantee cell's coordinates validity (ie that they lie inside the domain).The second model implies that a
(Signed)KhalimskyCell
is meant to be given with the associatedKhalimskySpaceND
in order to allow safe manipulation. Conversely, if a function/method/class needs a cell without the associated bounded cellular grid space, this function/method/class might as well use a pre-cell fromKhalimskyPreSpaceND
.Therefore, we should ideally respect the following guidelines:
(Signed)KhalimskyCell
, always pass the associatedKhalimskySpaceND
,KhalimskySpaceND
(eg, the display related functions), then it should only accept a(Signed)Khalimsky
Pre
Cell
.KhalismkyPreSpaceND
and the associated pre-cells.To ease the code update, there is two facilities:
(Signed)KhalimskyCell
are implicitly convertible to(Signed)KhalimskyPreCell
, or an explicit conversion is available through thepreCell()
method.KhalimskySpaceND
features an alias to the associatedKhalimskyPreSpaceND
(namedPreCellularGridSpace
).However, there is a little snag:
C++
sees the implicit conversion only if it doesn't depend on template deduction. For example, in the following code:the method
doSomething
can also accept aKhalimskyCell<dim,TInteger>
and the implicit conversion will be used. But in:C++
must be firstly able to deduce the template parameters and it is not allowed if aKhalimskyCell
is given.So, sometimes, two versions must be available (for cell and pre-cell) or the user must think to convert it before.
That's it, just a short reminder for what remains to be done after #1086.
The text was updated successfully, but these errors were encountered: