README 19.3 KB
Newer Older
thomas.forbriger's avatar
thomas.forbriger committed
1
/*! \file libaff/README
thomas.forbriger's avatar
thomas.forbriger committed
2
 * \brief C++ containers for numbers (libaff)
3
4
5
 *
 * ----------------------------------------------------------------------------
 *
6
 * $Id: README,v 1.13 2002-12-23 14:32:04 forbrig Exp $
7
8
9
 * 
 * Copyright (c) 2002 by Thomas Forbriger (IMG Frankfurt) 
 * 
thomas.forbriger's avatar
thomas.forbriger committed
10
 * C++ containers for numbers (libaff)
11
12
 *
 * This file contains:
thomas.forbriger's avatar
thomas.forbriger committed
13
 *  - documentation of namespace aff
14
15
 *  - mainpage text
 *  - documentation for pages:
16
 *    - \ref page_design
17
18
 *    - \ref page_using
 *    - \ref page_notes
19
 *    - \ref page_naming
20
21
 * 
 * REVISIONS and CHANGES 
thomas.forbriger's avatar
thomas.forbriger committed
22
 *  - 06/12/2002   V1.0   Thomas Forbriger (copied from libcontxx)
thomas.forbriger's avatar
thomas.forbriger committed
23
24
25
26
27
 *  - 20/12/2002   V1.1   (thof)
 *                        - complete revision of this file
 *                        - there are major gaps in
 *                          -# \ref sec_design_multidimensional
 *                          -# \ref page_using
28
29
30
31
32
33
34
 * 
 * ============================================================================
 */

/*! \brief Root namespace of library
  
  This namespace contains all modules of the library
thomas.forbriger's avatar
thomas.forbriger committed
35
36
37
  (see \ref sec_main_modules). 
  Here you should find all components, the user needs to work with this
  library.
38
  When working with the binary version of the library, you have to use
thomas.forbriger's avatar
thomas.forbriger committed
39
  aff::prebuilt in place of aff (see \ref sec_design_binary).
40
 */
41
42
namespace aff {
} // namespace aff
43
44
45
46
47
48

/*======================================================================*/

/*! \mainpage

\author Thomas Forbriger
thomas.forbriger's avatar
thomas.forbriger committed
49
50
51
\author Wolfgang Friederich
\since December 2002
\date December 2002
52
\version V1.0
53
$Id: README,v 1.13 2002-12-23 14:32:04 forbrig Exp $
54
55

  Contents of this page:
56
  - \ref sec_main_aims
57
  - \ref sec_main_modules
thomas.forbriger's avatar
thomas.forbriger committed
58
59
    - \ref sec_main_modules_basic
    - \ref sec_main_modules_extended
thomas.forbriger's avatar
thomas.forbriger committed
60
  - \ref sec_main_peculiar
61
62

  Additional information:
63
64
65
66
  - \ref page_design
  - \ref page_using
  - \ref page_notes
  - \ref page_naming
67
  - \ref page_representation
thomas.forbriger's avatar
thomas.forbriger committed
68
  - \ref page_fortran
thomas.forbriger's avatar
thomas.forbriger committed
69
  - \ref page_changelog
thomas.forbriger's avatar
thomas.forbriger committed
70
  - \ref page_project_status
71
72
73
74
75
76
77

\section sec_main_aims Aims of the library
  
  The AFF (Array of Friederich and Forbriger) is a lightweight class library.
  It offers a simple and easy to use container for numbers as is necessary in
  numerical code. The offered array always has a rectangular strided layout,
  reference semantics (through counted references) and a Fortran layout in
thomas.forbriger's avatar
thomas.forbriger committed
78
  memory. The interface is intentionally kept sparse to keep compilation times
79
80
81
82
83
84
85
  small. The array itself is meant to be used to pass numbers from one program
  module to the other. If you want to exploit the power of expression
  templates, pass the array contents to something like Blitz++.

  \sa \ref sec_notes_need

/*----------------------------------------------------------------------*/
86
87
88

\section sec_main_modules Modules of the library

89
90
  The main module is the array class aff::Array. It provides basic
  functionality through its interface. See the explanation there.
thomas.forbriger's avatar
thomas.forbriger committed
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
  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.

\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::Strided is the shape of a strided Fortran array and defines the
                memory layout of aff::Array objects.
  -# 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).
  -# aff::SimpleRigidArray is a linear array with size fixed at compile-time.
                There are several inline functions defined for operations with
                this array class.
thomas.forbriger's avatar
thomas.forbriger committed
109
  -# aff::Exception is the exception base class used in the library .
thomas.forbriger's avatar
thomas.forbriger committed
110
  -# aff::AllocException is the exception that indicated a failed memory
thomas.forbriger's avatar
thomas.forbriger committed
111
                allocation(see also "\ref group_error").
thomas.forbriger's avatar
thomas.forbriger committed
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126

  It additionally offers the following type definitions:

  -# aff::Tsubscript is the type of subscripts to arrays (positive and
                     negative).
  -# aff::Tsize      is the type of size values (non-negative).
  -# aff::Tdim       is the type of the dimension index (small, non-negative).

\subsection sec_main_modules_extended Extensions
  
  The library provides some additional modules. You need only include the
  header file of those modules that you really want to use in addition to the
  basic aff::Array functionality.
  These additional modules are:

thomas.forbriger's avatar
thomas.forbriger committed
127
  -# aff::Shaper presented in aff/shaper.h and used to pass Fortran layouts
thomas.forbriger's avatar
thomas.forbriger committed
128
129
130
131
132
133
134
135
136
137
                 to array constructors.
  -# 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.
  -# 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.
thomas.forbriger's avatar
thomas.forbriger committed
138
  -# aff::Slice presented in aff/slice.h to conveniently create
thomas.forbriger's avatar
thomas.forbriger committed
139
                 slices from aff::Array objects.
140
141
142
  -# 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.
thomas.forbriger's avatar
thomas.forbriger committed
143
144
  -# 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
thomas.forbriger's avatar
thomas.forbriger committed
145
                 debugging your code. See also "\ref group_helpers".
thomas.forbriger's avatar
thomas.forbriger committed
146

147

thomas.forbriger's avatar
thomas.forbriger committed
148
149
  In the \ref sec_design_binary "binary version" some of the modules
  (aff::Array and aff::SharedHeap) are presented in namespace aff::prebuilt.
150

151
152
  \sa \ref sec_design_namespaces
  \sa \ref sec_nameing_files
153
154
155

/*----------------------------------------------------------------------*/

thomas.forbriger's avatar
thomas.forbriger committed
156
\section sec_main_peculiar Peculiarities
157

thomas.forbriger's avatar
thomas.forbriger committed
158
159
160
161
\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.
See also "\ref sec_design_const".
162

thomas.forbriger's avatar
thomas.forbriger committed
163
164
165
166
167
168
\par Multidimensional arrays
Every aff::Array of this class has aff::Strided::Mmax_dimen dimensions.
Construction and access for lower dimensionality is provided. In the case of
using less dimensions, the size of the unused dimensions is 1 by default and
its index is inherently set to the first index.
See also "\ref sec_design_multidimensional".
169

170
*/
171

172
/*======================================================================*/
173

174
/*! \page page_design Design decisions
175

176
177
178
179
180
181
  Contents of this page:
  - \ref sec_design_copy
  - \ref sec_design_namespaces
  - \ref sec_design_binary
  - \ref sec_design_multidimensional
  - \ref sec_design_const
182

183
184
185
186
187
188
189
190
191
\section sec_design_copy Copy constructor and copy operator
  
  Usually we would expect the copy operator and the copy constructor to have
  the same semantics. Here the copy constructor of aff::Array must have
  reference semantics (it does a shallow copy). This is necessary to allow
  arrays as return values from functions. In this case the copy constructor is
  automatically invoked. Reference semantics ensure a minimal overhead. in
  terms of memory usage and execution time.

thomas.forbriger's avatar
thomas.forbriger committed
192
193
  In the case of the copy (assignment) operator things are less clear: 
  If we define the
194
  copy operator to have reference semantics, it has the same behaviour as the
thomas.forbriger's avatar
thomas.forbriger committed
195
  copy constructor. That is what we usually would expect. An expression like
196
  \code
197
  A=B;
198
  \endcode
199
200
201
202
  means that array \c A drops its reference to the memory location it was
  pointing to and forgets its previous shape. Following this statement array
  \c A will refer to the same memory location as array \c B and will have the
  same shape. Both are indistinguishable.
203

thomas.forbriger's avatar
thomas.forbriger committed
204
205
206
  However, in many cases (most cases?) we will use the copy (assignment)
  operator in the
  sense of a mathematical equation. This may read like
207
  \code
208
  A=B+C;
209
  \endcode
210
  although expressions like this are not yet supported by the library
thomas.forbriger's avatar
thomas.forbriger committed
211
  features. In this case we do not mean that \c A should drop it reference. 
212
213
214
  \c A may refer to an array in memory which is also referred by other array
  instances. And we want these values to be set to the result of the operation
  \c B + \c C. In that case the copy operator should have deep copy semantics.
215

thomas.forbriger's avatar
thomas.forbriger committed
216
217
218
219
220
221
222
  \par Design decision
  The classes aff::Array and aff::Series provide copy (assignment) operators
  with shallow copy semantics. 
  This is sensible, because we are not offering mathematical array operations.
  This operations may be delegated to a wrapper class in the future, which
  then also may provide expression templates and an appropriate assignment
  operator.
223
224
225

/*----------------------------------------------------------------------*/

226
\section sec_design_namespaces Namespaces
227

228
  We group all code in two namespaces. Major modules which will be accessed by
thomas.forbriger's avatar
thomas.forbriger committed
229
230
231
232
233
234
235
236
237
238
239
  the user are placed in namepsace aff. Modules meant to be used internally are
  placed in aff::util.
  Use directives like
  \code
  using namespace aff;
  \endcode
  or
  \code
  using aff::Array;
  \endcode
  for convenient access.
240
241
242

/*----------------------------------------------------------------------*/

243
\section sec_design_binary Binary library
244
245
246

  We provide a binary version of the library. It contains a set of prebuilt
  class objects. Using this version and linking against the binary library
247
  libaff.a should reduce compilation times in comparison to complete
248
249
250
251
252
253
254
  template evaluation.
  This will become more significant the more code is factored out to separate
  definition headers.
  This approach offers no improvement with inlined code (which we use
  extensively in array access functions).

  To use the binary version you should include binarry.h in place of array.h
thomas.forbriger's avatar
thomas.forbriger committed
255
256
  You will find modules aff::Array and aff::SharedHeap
  in aff::prebuilt that are in aff in the full-template version.
257
258
259
260

  \sa tests/binarraytest.cc
  \sa binarray.h

261
262
  The inclusion of header files is controlled by a set of preprocessor macros.
  \sa AFF_PREBUILT
263
  \sa AFF_INDEXCHECK
264
265
266
  \sa AFF_NO_DEFINITIONS
  \sa AFF_COMPILING_LIBRARY
  \sa DOXYGEN_MUST_SKIP_THIS
267

thomas.forbriger's avatar
thomas.forbriger committed
268
269
270
271
272
273
274
\note
Since we reduced to number of template parameters significantly in this
approach, many parts of code have already been factored out to separate files
that are compiled into the binary libaff.a. The approach of explicitly
instantiated class templates is not supported so far. It is, however, prepared
in the structure of header files and may be activated in the future.
\date 20/12/2002
275

276
/*----------------------------------------------------------------------*/
277

278
\section sec_design_multidimensional Multidimensional arrays
279

280
281
  \todo
  Explain Wolfgangs idea of multidimensional arrays.
282

283
/*----------------------------------------------------------------------*/
284

285
286
\section sec_design_const Notes on the const-correctness of arrays

thomas.forbriger's avatar
thomas.forbriger committed
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
\subsection sec_design_const_approach Approach used in this library

  We distinguish between the constness of the array and the constness of the
  elements. A definition
  \code
  aff::Array<int> A(12,12);
  const aff::Array<int> B(A);
  \endcode
  means that array \c B is a constant array initialized to array \c A. This
  means, that the container is constant. Its shape and reference may not be
  changed.

  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);
  \endcode
  which defines that the contents of \c C may not be changed (i.e. they are of
  type \c const \c int. 
  They are still refering to the same data in memory. 
  If you modify data elements through \c A, this will be visible through \c C.

  An array for elements of type \c T is derived from an array for elements of
  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);
  \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
  overhead.

  A container (aff::Array, etc.) with \c const qualifier offers no access
  operators, that allow modification of the data. 
  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
  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_general General considerations

340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
  Arrays using the shared heap representation have reference semantics.
  Different instances will access the same data in memory. Copying an array
  instance just copies a reference to the data. This mechanism is not obvious
  to the compiler. The array instances are values in the sense of C++ types
  and not references. Passing an \c const \c aff::Array to a function does
  not prohibit the function from assigning this instance to a non-const
  \c aff::Array, which then references the same memory area and allows the
  modification of the values contained in the array.

  Generally it has to be defined, what is meant by declaring an array instance
  to be \c const. In the first place this means constness of the container to
  the compiler. The compiler will ensure, that the container (array class) is
  not changed, thus no data member of the array is changed. This means that
  the array will keep the reference to the same data and that the
  index-mapping defined by the array shape may not be changed. However, the
  compiler will not prevent to change any data, the array refers to. 

  We may define access operators that have a non-const version that returns a
  reference to the data, allowing to change the data values together with a
  const version that returns a value of const reference, thus preventing the
  data from being changed through an instance that is declared const. However,
  the compiler will always allow to create a non-const copy of a const array
  instance. In the sense of const-ness of C++ data, this does not violate the
thomas.forbriger's avatar
thomas.forbriger committed
363
  const-ness of the source of the copy. The shape of the original array may
364
365
366
367
368
369
370
371
372
  not be changed. Only the shape of the copy may be changed. But the data of
  the original array may now be changed through the copied instance, since our
  array classes implicitly have reference semantic. Thus we have to
  distinguish between const-ness of the container (array class instance) and
  the contained data (values in memory the arrays refers to).

  In this library we will not provide a const and a non-const version of the
  array classes. With templated code it is more convenient to use an array
  with element type \c const \c T as the const version of an array with
thomas.forbriger's avatar
thomas.forbriger committed
373
374
375
  element type \c T. To allow conversion of an instance with element type \c T
  to an instance of type \c const \c T, we use the version for elements of
  type \c const \c T as a base classe.
376
377
378
379
380
381
382
383
384
385
386
387

   -  The need of const-correctness is discussed in "Chapter 1 Introduction,
      C++ Conventions, Implementation of Vector and Matrix Classes" of
      "Numerical Recipes in C++". A link to a PDF file of this chapter is
      provided at "http://www.nr.com/cpp-blurb.html".
   - The "C++ FAQ Lite" discusses many aspects of const-correctness in Chapter
     18, which you find at
     "http://www.inf.uni-konstanz.de/~kuehl/cpp/cppfaq.htm/const-correctness.html".
   -  You may find my thoughts about const-correctness with containers that
      have reference semantics at
      "http://www.geophysik.uni-frankfurt.de/~forbrig/txt/cxx/tutorial/consthandle.doc/doc/html/index.html".

388
389
390
391
*/

/*======================================================================*/

392
/*! \page page_using HOWTO use this library
393

394
395
  Contents of this page:
  - \ref sec_using_constructor
thomas.forbriger's avatar
thomas.forbriger committed
396
  - \ref sec_using_examples
397
398

\section sec_using_constructor Constructing arrays
thomas.forbriger's avatar
thomas.forbriger committed
399
400
401
402
  Arrays are most easy constructed by means of the aff::Shaper.
  If you want e.g. define an array \c A of element type int with Fortran
  layout, three dimensions and the index ranges [-2:2], [1:4], and [6:10] you
  have to code
403
  \code
thomas.forbriger's avatar
thomas.forbriger committed
404
405
  using namespace aff;
  Array<int> A(Shaper(-2,2)(4)(6,10));
406
  \endcode
thomas.forbriger's avatar
thomas.forbriger committed
407
  The shaper is presented in aff/shaper.h.
408

thomas.forbriger's avatar
thomas.forbriger committed
409
410
411
412
413
414
\section sec_using_examples Example code
  The test programs may serve as examples for using this library:
  - tests/arraytest.cc
  - tests/shapetest.cc
  - tests/reprtest.cc
  - tests/simplearraytest.cc
415
416

\todo
thomas.forbriger's avatar
thomas.forbriger committed
417
418
We need more text and examples.

419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
*/


/*======================================================================*/

/*! \page page_notes General notes

  Contents of this page:
  - \ref sec_notes_need

\section sec_notes_need The need of an array library
  
  One major reason for replacing Fortran77 by C++ in numerical code is the
  convenience in expressing logistics. Data of different type and size may be
  packed into classes and encapsulated from the outside world. Most numerical
  results are to be stored in arrays, multi-dimensional arrays in particular.
  This library provides the basic functionality for storing many data of the
  same type in memory, passing them around between subroutines in an efficient
  way and accessing them through convenient interfaces. The main purpose of
  this library is not calculation but managing (passing between program
  modules, selection of subsets of the data) large amounts of numbers. In the
  future it might provide interfaces to libraries like blitz++ for finite
  difference calculations, MTL for linear algebra calculations, and POOMA for
  parallel computations.

444
445
446
447
*/

/*======================================================================*/

448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
/*! \page page_naming Naming conventions

  Contents of this page:
  - \ref sec_nameing_identifiers
  - \ref sec_nameing_macros
  - \ref sec_nameing_files

\section sec_nameing_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
  guidelines are used. The nameing of template parameters is left free for
  convenience.

  \par Classes
   
  Class names always start with a capital letter.

  \par Typedefs

  Typedefs always start with a capital \c T.

  \par Member data

  Member data identifiers always start with a capital \c M.

\section sec_nameing_macros Preprocessor macros

  Preprocessor macros like include-guards should have the prefix "AFF_".
thomas.forbriger's avatar
thomas.forbriger committed
477
  The macros in the \ref group_helpers are an exception to this rule.
478
479
480
481
482
483
484
485
486

\section sec_nameing_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
  template code. Files ending on \c def.h contain template code definitions
  that is factored out to be compilable into a binary library for explicit
  instantiation.

thomas.forbriger's avatar
thomas.forbriger committed
487
488
  The main directory %aff contains headers that are usually included by the
  user. A subdirectory %aff/lib contains additional headers that are mostly
489
490
  used internally.

491
492
493
*/

// ----- END OF README -----