Commit 08872ad7 authored by thomas.forbriger's avatar thomas.forbriger Committed by thomas.forbriger
Browse files

new base classes...

This is a legacy commit from before 2015-03-01.
It may be incomplete as well as inconsistent.
See COPYING.legacy and README.history for details.


SVN Path:     http://gpitrsvn.gpi.uni-karlsruhe.de/repos/TFSoftware/trunk
SVN Revision: 1242
SVN UUID:     67feda4a-a26e-11df-9d6e-31afc202ad0c
parent b9d43233
# this is <Makefile>
# ----------------------------------------------------------------------------
# $Id: Makefile,v 1.14 2002-12-27 17:03:02 forbrig Exp $
# $Id: Makefile,v 1.15 2002-12-29 00:09:05 forbrig Exp $
#
# Copyright (c) 2002 by Thomas Forbriger (IMG Frankfurt)
#
......@@ -83,6 +83,7 @@ REMCMMNT=remcmmnt
# compiler and preprocessor flags
FLAGS=
CXXFLAGS=-Wall -pedantic $(FLAGS) -O3
CXXFLAGS=-Wall $(FLAGS) -O3
LDFLAGS=-L$(LOCLIBDIR)
CPPFLAGS=-I$(LOCINCLUDEDIR) $(FLAGS)
......@@ -304,6 +305,9 @@ doxyview: doxydoc doxyfullview
# delegate test targets
# ---------------------
tests/%.P:
cd tests; echo "#############################"; $(MAKE) $(notdir $@)
tests/%: tests/%.cc install-include libaff.a
cd tests; echo "#############################"; $(MAKE) $(notdir $@)
......
......@@ -3,7 +3,7 @@
*
* ----------------------------------------------------------------------------
*
* $Id: README,v 1.13 2002-12-23 14:32:04 forbrig Exp $
* $Id: README,v 1.14 2002-12-29 00:09:05 forbrig Exp $
*
* Copyright (c) 2002 by Thomas Forbriger (IMG Frankfurt)
*
......@@ -25,6 +25,11 @@
* - there are major gaps in
* -# \ref sec_design_multidimensional
* -# \ref page_using
* - 28/12/2002 V1.2 (thof)
* - new term for containers of const elements
* - added documentation regarding the concept of
* const correctness
* - added documentation regarding member typedefs
*
* ============================================================================
*/
......@@ -50,7 +55,7 @@ namespace aff {
\since December 2002
\date December 2002
\version V1.0
$Id: README,v 1.13 2002-12-23 14:32:04 forbrig Exp $
$Id: README,v 1.14 2002-12-29 00:09:05 forbrig Exp $
Contents of this page:
- \ref sec_main_aims
......@@ -90,23 +95,24 @@ $Id: README,v 1.13 2002-12-23 14:32:04 forbrig Exp $
functionality through its interface. See the explanation there.
It is presented in aff/array.h and aff/binarray.h (see also
\ref sec_design_binary).
The object code is places in libaff.a.
The object code is placed in libaff.a.
\subsection sec_main_modules_basic Basic array modules
By including aff/array.h you will get access to the following modules:
-# aff::Array is the main array interface.
-# aff::Array is the main array interface (see example tests/arraytest.cc).
-# aff::Strided is the shape of a strided Fortran array and defines the
memory layout of aff::Array objects.
memory layout of aff::Array objects (see example
tests/shapetest.cc).
-# aff::SharedHeap is the representation used by aff::Array. It holds the
data in memory and provides an interface to it. This interface
may be passed separately from the array object (see also
\ref page_representation).
"\ref page_representation" and example tests/reprtest.cc).
-# aff::SimpleRigidArray is a linear array with size fixed at compile-time.
There are several inline functions defined for operations with
this array class.
-# aff::Exception is the exception base class used in the library .
this array class (see example tests/simplearraytest.cc).
-# aff::Exception is the exception base class used in the library.
-# aff::AllocException is the exception that indicated a failed memory
allocation(see also "\ref group_error").
......@@ -125,21 +131,25 @@ $Id: README,v 1.13 2002-12-23 14:32:04 forbrig Exp $
These additional modules are:
-# aff::Shaper presented in aff/shaper.h and used to pass Fortran layouts
to array constructors.
to array constructors (see example tests/shapetest.cc).
-# aff::Series presented in aff/series.h which is used to interface linear
sequences of data (like time series or Fourier spectra).
-# aff::Iterator presented in aff/iterator.h which is an iterator interface
to containers like aff::Array or aff::Series.
to containers like aff::Array or aff::Series (see example
tests/helpertest.cc).
-# aff::Range presented in aff/lib/range.h which is usefull where ever you
need to deal with numerical ranges (calculate with them, find
the smallest in a set, etc.).
-# aff::Subarray presented in aff/subarray.h to conveniently create
subarrays from aff::Array objects.
subarrays from aff::Array objects (see example
tests/helpertest.cc).
-# aff::Slice presented in aff/slice.h to conveniently create
slices from aff::Array objects.
slices from aff::Array objects (see example
tests/helpertest.cc).
-# aff::FortranArray and its associate aff::util::FortranShape are presented
in aff/fortranshape.h. They calculate a Fortran 77 array
layout (leading dimensions) from a given AFF array.
layout (leading dimensions) from a given AFF array (see
example tests/f77test.cc).
-# aff::dump and its associates, presented in aff/dump.h. They are used to
dump shape or contents of containers and are thus useful when
debugging your code. See also "\ref group_helpers".
......@@ -149,12 +159,18 @@ $Id: README,v 1.13 2002-12-23 14:32:04 forbrig Exp $
(aff::Array and aff::SharedHeap) are presented in namespace aff::prebuilt.
\sa \ref sec_design_namespaces
\sa \ref sec_nameing_files
\sa \ref sec_naming_files
/*----------------------------------------------------------------------*/
\section sec_main_peculiar Peculiarities
\par Containers use counted references
All containers (e.g. aff::Array, aff::Series) use counted references to access
global memory. Assigning one container object to another just assigns the
reference. Both will use the same data in memory afterwards.
See also "\ref page_representation".
\par Const-correctness for array elements
In this library we follow provide functionality to write const-correct code
with regard to the array container and with regard to its element values.
......@@ -174,12 +190,72 @@ See also "\ref sec_design_multidimensional".
/*! \page page_design Design decisions
Contents of this page:
- \ref sec_design_interface
- \ref sec_design_copy
- \ref sec_design_namespaces
- \ref sec_design_binary
- \ref sec_design_multidimensional
- \ref sec_design_const
\section sec_design_interface Common interface elements
\subsection sec_design_interface_typedef Member typedefs
Class templates like aff::Iterator may be used with any container class,
that provides an appropriate interface. This interface convention concerns
the access to the type of related objects. I will explain by example:
We use an iterator \c i which was declared
\code aff::Iterator<Cont> i \endcode
for a container of type \c Cont, it expects to find a corresponding
container class that promises constness of the elements through
\code Cont::Tcontainer_of_const \endcode
or short
\code Cont::Tcoc \endcode
For aff::ConstArray the type aff::ConstArray::Tcoc is just the class itself.
However aff::Array::Tcoc gives an aff::ConstArray.
\sa aff::SharedHeap::Tcontainer_of_const
\sa aff::ConstSharedHeap::Tcontainer_of_const
\sa aff::Array::Tcontainer_of_const
\sa aff::ConstArray::Tcontainer_of_const
\sa aff::Series::Tcontainer_of_const
\sa aff::ConstSeries::Tcontainer_of_const
In the same way we may access the appropriate element type through
\code Cont::Tvalue \endcode
which is \c T for aff::Array<T> and \c const \T for aff::ConstArray<T>.
However a
\code Cont::Tconst_value \endcode
will always provide a type with const qualifier.
\sa aff::Array::Tvalue
\sa aff::Array::Tconst_value
\sa aff::ConstArray::Tvalue
\sa aff::ConstArray::Tconst_value
\sa aff::Series::Tvalue
\sa aff::Series::Tconst_value
\sa aff::ConstSeries::Tvalue
\sa aff::ConstSeries::Tconst_value
In the same way we may access the type of the appropriate representation
(although the base class of any container is always an aff::SharedHeap) by
\code Cont::Trepresentation \endcode
\sa aff::Array::Trepresentation
\sa aff::ConstArray::Trepresentation
\sa aff::Series::Trepresentation
\sa aff::ConstSeries::Trepresentation
\b Notice: Using these typedefs (and also the typedefs for the shape class,
etc.) improves the maintainability of your code. Think of using the $HOME
variable in shell scripts. Once the name of your home directory changes, you
need not modify all your shell scripts. Now consider one day your shape
class might be renamed...
/*----------------------------------------------------------------------*/
\section sec_design_copy Copy constructor and copy operator
Usually we would expect the copy operator and the copy constructor to have
......@@ -284,7 +360,32 @@ in the structure of header files and may be activated in the future.
\section sec_design_const Notes on the const-correctness of arrays
\subsection sec_design_const_approach Approach used in this library
\subsection sec_design_const_problem Where is the problem?
When passing a container (i.e. an array) to a function, we would like to
promise that the values in the container are not modified, in case the
function uses only read-access. Consider a declaration
\code void func(const int& v) \endcode
of a function that takes an argumtn of type \c int an promises that this
will not be modified. Passing by reference is used, because this is more
efficient than passing by value (in particular for large objects - which is
not the case for \c int). And qualifying the type \c const promises that the
value passed by reference will not be changed.
A declaration
\code void func(const Array<int>& v) \endcode
does not what we want (see "\ref sec_design_const_general"). It just
promises the constness of the container, not of the data. Within the
function the passed reference may be assigned to a non-const \c Array<int>,
which allows modification of the data (see "\ref page_representation").
Thus we must use something like
\code void func(const ConstArray<int>& v) \endcode
where \c ConstArray<int> does not allow modification of the data (be no
means - copying and conversions included) and may be derived from an
\c Array<int> by a trivial conversion (like a conversion to a public base
class).
\subsection sec_design_const_approach The approach used in this library
We distinguish between the constness of the array and the constness of the
elements. A definition
......@@ -299,7 +400,7 @@ in the structure of header files and may be activated in the future.
If you want to define constness of the contained values (e.g. when passing
an array to a function), you have to use
\code
aff::Array<const int> C(A);
aff::ConstArray<int> C(A);
\endcode
which defines that the contents of \c C may not be changed (i.e. they are of
type \c const \c int.
......@@ -310,30 +411,83 @@ in the structure of header files and may be activated in the future.
type \c const \c T.
Functions that only need read access to arrays should be declared like
\code
void func(const aff::Array<const int>& array);
void func(const aff::ConstArray<int>& array);
\endcode
and may be called like
\code
aff::Array<int> A(12,12);
func(A);
\endcode
The type conversion from \c aff::Array<int> to
\c const \c aff::Array<const \c int>& is trivial and has no runtime
The type conversion from \code aff::Array<int> \endcode to
\code const aff::ConstArray<int>& \endcode is trivial and has no runtime
overhead.
A container (aff::Array, etc.) with \c const qualifier offers no access
operators, that allow modification of the data.
Each container class must deal with this issue on its own. Sorry...
\sa aff::ConstSharedHeap
\sa aff::ConstArray
\sa aff::ConstSeries
\par Restrictions for containers with const qualifier
Strictly distinguishing between constness of the container and constness of
the contained data would allow to modify data through an object \c c that
was declared
\code const Array<int> c; \endcode
The containers in this library (aff::Array, etc.), however, provide only a
reduced set of access operators, when declared with \c const qualifier.
They do not allow direct modification of the data (only through assignment
to a non-const container instance).
Although the constness of the container object generally does not imply
constness of the contained data, we think that every user will expect the
classes to behave like this.
To ensure true constness of the data, you have to assign to a container for
element type \c const \c T. Remember that a \c const \c aff::Array always
To ensure true constness of the data, you have to assign to the base class
of the container.
Any container class (e.g. \c Cont) provides the type of container for const
elements through a typedef Tcontainer_of_const
(i.e. \c Cont::Tcontainer_of_const) or short Tcoc.
Remember that a \c const \c aff::Array always
may be assigned to a mutable aff::Array, which in turn allows modification
of the data!
\sa aff::SharedHeap< const T >
\sa aff::Array< const T >
\sa aff::Series< const T >
\subsection sec_design_const_alternatives Alternatives
Three alternatives to this concept have been discussed (and discarded).
Both have the appealing property of needing only one class definition for
each container (in contrast to a class and a base class in our case).
Additionally both would offer name commonality for containers of non-const
elements and containers of const elements.
\par Using arrays with element type \c const \c T
A rather straight approach is to use the element type \c const \c T
where an array of elements of type \c T should be used, that we do not allow
to be changed. This design concept can be accomplished with a special traits
class that is specialized for \c const \c T and allows to derive a mutable
or const version of any type. Be further providing appropriate conversion
operators, an \code Array<T> \endcode could be converted to an
\code Array<const T>, \endcode both sharing the same elements in memory.
In this approach, however, both container classes are completely
independent (although having the same name) due to their different template
arguments. The conversion to the container for const elements is not a
trivial conversion (like for a reference to a reference of a public base
class) and must be done explicitely. That's inconvenient for the most common
use (i.e. passing a container to a function).
\par Deriving from a template specialization
The name commonality could still be achieved by deriving the Array<T> from
template specialization Array<const T>. In this case the specialization must
be used as a base class before it is actually defined. That's impropoer
design.
\par Ensuring constness of elements through const qualifier of functions
We could strictly follow the concept (as we do anyway to some extent) to
couple the constness of the container to the constness of the contained
data. This is done by const qualifiers to member functions that allow
modification of the data. Avoid pitfalls, we have to consider copy operators
and copy constructors then too. Both must not promise const-ness to their
arguments. While this works in principle, we would end up with a container
class which doesn't allow copies of const instances. Hence we could not
return a container from a function, that ensures that the accessed data
cannot be modified.
\subsection sec_design_const_general General considerations
......@@ -448,11 +602,11 @@ We need more text and examples.
/*! \page page_naming Naming conventions
Contents of this page:
- \ref sec_nameing_identifiers
- \ref sec_nameing_macros
- \ref sec_nameing_files
- \ref sec_naming_identifiers
- \ref sec_naming_macros
- \ref sec_naming_files
\section sec_nameing_identifiers Classes, Typedefs, etc.
\section sec_naming_identifiers Classes, Typedefs, etc.
During coding it is sometimes helpfull to recognize the meaning of an
identifier due to some signals in irs name. Therefor the following
......@@ -471,12 +625,12 @@ We need more text and examples.
Member data identifiers always start with a capital \c M.
\section sec_nameing_macros Preprocessor macros
\section sec_naming_macros Preprocessor macros
Preprocessor macros like include-guards should have the prefix "AFF_".
The macros in the \ref group_helpers are an exception to this rule.
\section sec_nameing_files Filenames
\section sec_naming_files Filenames
Files with the extension \c .cc contain only non-template definitions. Files
with the extension \c .h may contain prototypes, class declarations or
......
......@@ -3,7 +3,7 @@
*
* ----------------------------------------------------------------------------
*
* $Id: README.changelog,v 1.23 2002-12-27 16:18:05 forbrig Exp $
* $Id: README.changelog,v 1.24 2002-12-29 00:09:05 forbrig Exp $
*
* Copyright (c) 2002 by Thomas Forbriger (IMG Frankfurt)
*
......@@ -21,12 +21,27 @@
/*! \page page_changelog ChangeLog (AFF)
$Id: README.changelog,v 1.23 2002-12-27 16:18:05 forbrig Exp $
$Id: README.changelog,v 1.24 2002-12-29 00:09:05 forbrig Exp $
\sa \ref page_project_status
Major changes in the interface of the library are marked by \b !!.
- \b 28/12/2002 (thof)
- \b !! Wolfgang pointed out a fundamental design error: Classes
aff::Array, aff::Series and aff::SharedHeap used a specialization of
themselves as base class to implement a version for const element type
(see "\ref sec_design_const"). Since specialization may only be declared
after the general template itself, the base class definition is not
available at the point it is used in the declaration of the general
class template. We made the base class a completely independent class
template. Base classes aff::ConstArray, aff::ConstSeries, and
aff::ConstSharedHeap are introduced.
- reworked documentation in
-# lib/README
-# lib/sharedheap.h
-# array_dec.h
- \b 27/12/2002 (thof)
- completed Fortran interface documentation (\ref page_fortran)
......@@ -96,7 +111,7 @@
/*! \page page_project_status Project status (AFF)
$Id: README.changelog,v 1.23 2002-12-27 16:18:05 forbrig Exp $
$Id: README.changelog,v 1.24 2002-12-29 00:09:05 forbrig Exp $
\sa \ref page_changelog
......@@ -116,7 +131,7 @@
<TD>8/12/02</TD><TD>20/12/02</TD><TD>19/12/02</TD><TD> </TD>
</TR>
<TR><TD>libaff/array_dec.h</TD>
<TD>19/12/2002</TD><TD> </TD><TD>19/12/2002</TD>
<TD>19/12/2002</TD><TD>28/12/2002</TD><TD>19/12/2002</TD>
<TD> </TD>
</TR>
<TR><TD>libaff/array_def.h</TD>
......@@ -148,12 +163,14 @@
</TR>
<TR><TD>libaff/slice.h</TD>
<TD>23/12/02</TD><TD> </TD><TD>23/12/02</TD>
<TD>The syntax to use a Slice object stand-alone for assignment is not
<TD><B>Does not work with new ConstArray</B>.
The syntax to use a Slice object stand-alone for assignment is not
very intuitive</TD>
</TR>
<TR><TD>libaff/subarray.h</TD>
<TD>23/12/02</TD><TD> </TD><TD>23/12/02</TD>
<TD>The syntax to use a Subarray object stand-alone for assignment is
<TD><B>Does not work with new ConstArray</B>.
The syntax to use a Subarray object stand-alone for assignment is
not very intuitive</TD>
</TR>
......
This diff is collapsed.
......@@ -3,7 +3,7 @@
*
* ----------------------------------------------------------------------------
*
* $Id: array_def.h,v 1.12 2002-12-23 11:44:03 forbrig Exp $
* $Id: array_def.h,v 1.13 2002-12-29 00:09:06 forbrig Exp $
* \author Thomas Forbriger
* \since 08/12/2002
*
......@@ -33,6 +33,9 @@
* representation
* - 23/12/2002 V1.4 (thof)
* - copyin() and copyout() work
* - 28/12/2002 V1.5 (thof)
* - changed base class from specialization to
* independent class template
*
* ============================================================================
*/
......@@ -45,9 +48,9 @@
#ifndef AFF_ARRAY_DEF_H_VERSION
#define AFF_ARRAY_DEF_H_VERSION \
"AFF_ARRAY_DEF_H V1.4"
"AFF_ARRAY_DEF_H V1.5"
#define AFF_ARRAY_DEF_H_CVSID \
"$Id: array_def.h,v 1.12 2002-12-23 11:44:03 forbrig Exp $"
"$Id: array_def.h,v 1.13 2002-12-29 00:09:06 forbrig Exp $"
#include<aff/lib/error.h>
#include<aff/lib/stridedstepper.h>
......@@ -68,10 +71,10 @@ namespace prebuilt {
//! construct array from given dimension sizes
template<class T>
Array<const T>::Array(const Tsize& s0,
const Tsize& s1,
const Tsize& s2,
const Tsize& s3)
ConstArray<T>::ConstArray(const Tsize& s0,
const Tsize& s1,
const Tsize& s2,
const Tsize& s3)
{
Tshape::TSizeVec size;
size[0]=s0;
......@@ -87,8 +90,8 @@ namespace prebuilt {
//! construct array from shape and representation
template<class T>
Array<const T>::Array(const Tshape& shape,
const Tmutable_representation& representation)
ConstArray<T>::ConstArray(const Tshape& shape,
const Tmutable_representation& representation)
{
AFF_assert((shape.first_offset()>=0),
"ERROR (Array): invalid shape in constructor");
......@@ -102,7 +105,7 @@ namespace prebuilt {
//! construct array from shape
template<class T>
Array<const T>::Array(const Tshape& shape): Tshape(shape)
ConstArray<T>::ConstArray(const Tshape& shape): Tshape(shape)
{
this->Tmutable_representation::operator=(
Tmutable_representation(this->Tshape::memory_size()));
......@@ -112,7 +115,7 @@ namespace prebuilt {
//! set whole array to scalar value
template<class T>
Array<const T>& Array<const T>::operator=(const T& value)
ConstArray<T>& ConstArray<T>::operator=(const T& value)
{
aff::util::StridedStepper st(*this);
for(st.tofirst(); st.valid(); st.incr())
......@@ -125,10 +128,10 @@ namespace prebuilt {
//! read data from other array
template<class T>
template<class TT>
Array<const T>& Array<const T>::copyin(const Array<const TT>& a)
ConstArray<T>& ConstArray<T>::copyin(const ConstArray<TT>& a)
{
typedef typename Array<const TT>::Tstepper Tsta;
typedef typename Array<const T>::Tstepper Tstm;
typedef typename ConstArray<TT>::Tstepper Tsta;
typedef typename ConstArray<T>::Tstepper Tstm;
Tsta sta(a);
Tstm stm(*this);
sta.tofirst();
......
......@@ -3,7 +3,7 @@
*
* ----------------------------------------------------------------------------
*
* $Id: iterator.h,v 1.5 2002-12-23 11:44:03 forbrig Exp $
* $Id: iterator.h,v 1.6 2002-12-29 00:09:06 forbrig Exp $
* \author Thomas Forbriger
* \since 08/12/2002
*
......@@ -17,6 +17,9 @@
* - 08/12/2002 V1.0 copied from libcontxx
* - 23/12/2002 V1.1 (thof)
* - reorganized code: do not inherit from Stepper
* - 28/12/2002 ---- (thof)
* - revised: is not affected by new style of base
* classes for constant elements
*
* ============================================================================
*/
......@@ -27,7 +30,7 @@
#define AFF_ITERATOR_H_VERSION \
"AFF_ITERATOR_H V1.1"
#define AFF_ITERATOR_H_CVSID \
"$Id: iterator.h,v 1.5 2002-12-23 11:44:03 forbrig Exp $"
"$Id: iterator.h,v 1.6 2002-12-29 00:09:06 forbrig Exp $"
#include<aff/lib/types.h>
#include<aff/lib/stridedstepper.h>
......
......@@ -3,7 +3,7 @@
*
* ----------------------------------------------------------------------------
*
* $Id: README,v 1.12 2002-12-27 17:03:03 forbrig Exp $
* $Id: README,v 1.13 2002-12-29 00:09:06 forbrig Exp $
*
* Copyright (c) 2002 by Thomas Forbriger (IMG Frankfurt)
*
......@@ -21,6 +21,8 @@
* - 27/12/2002 V1.2 (thof)
* - completed Fortran considerations
* - doxygen now reads Fortran and f2c generated code
* - 28/12/2002 V1.3 (thof)
* - new term for containers of const elements
*
* ============================================================================
*/
......@@ -301,7 +303,7 @@ Aspects to consider:
const-correctness it takes arguments of type
\code const aff::Array<float>& \endcode
rather than
\code const aff::Array<const float>& \endcode
\code const aff::ConstArray<float>& \endcode
(see also "\ref sec_design_const").
- f77interface::sums has to create an AFF array of appropriate size before
passing a pointer to the underlying Fortran subroutine. Since the
......
......@@ -3,7 +3,7 @@
*
* ----------------------------------------------------------------------------
*
* $Id: dump_array.h,v 1.2 2002-12-23 11:44:04 forbrig Exp $
* $Id: dump_array.h,v 1.3 2002-12-29 00:09:06 forbrig Exp $
* \author Thomas Forbriger
* \date 19/12/2002
*
......@@ -15,6 +15,9 @@
*
* REVISIONS and CHANGES
* - 19/12/2002 V1.0 Thomas Forbriger
* - 28/12/2002 V1.1 (thof)
* - functions now take ConstArray class reference
* arguments
*
* ============================================================================
*/
......@@ -23,9 +26,9 @@
#ifndef AFF_DUMP_ARRAY_H_VERSION
#define AFF_DUMP_ARRAY_H_VERSION \
"AFF_DUMP_ARRAY_H V1.0 "
"AFF_DUMP_ARRAY_H V1.1"
#define AFF_DUMP_ARRAY_H_CVSID \
"$Id: dump_array.h,v 1.2 2002-12-23 11:44:04 forbrig Exp $"
"$Id: dump_array.h,v 1.3 2002-12-29 00:09:06 forbrig Exp $"
#include<iostream>
#include<aff/array.h>
......@@ -41,10 +44,10 @@ namespace {
* \ingroup group_helpers
*/
template<class T>
void dump_array_helper(const aff::Array<const T>& array,
const Tdim& i, const Tdim& j,
Strided::TIndexVec& index,
std::ostream& os)
void dump_array_helper(const aff::ConstArray<T>& array,
const Tdim& i, const Tdim& j,
Strided::TIndexVec& index,
std::ostream& os)
{
if (i>1)
{
......@@ -114,7 +117,7 @@ namespace {
* \ingroup group_helpers
*/
template<class T>
void dump_array(const Array<const T>& array,
void dump_array(const ConstArray<T>& array,
const Tdim& i=(Strided::Mmax_dimen-1),
std::ostream& os=std::cout)
{
......@@ -133,7 +136,7 @@ void dump_array(const Array<const T>& array,
* \ingroup group_helpers
*/
template<class T>
void dump(const Array<const T>& array, std::ostream& os=std::cout)