|
|
Note another difference in the type definitions created by the two compilers: while g2comp gives the proj field a type of long[4], g2++comp(1C++) gives it a type of Vblock<long>. In general, g2++comp(1C++) replaces [] by Vblock .
As the manpage explains, a Vblock is just like a Block (see Block(3C++), except that (for technical reasons) some of its functions are virtual.
From the client programmer's viewpoint, proj can be accessed exactly as if it were a one-dimensional array with four cells. Unlike an array, however, the number of cells can be increased beyond this defined size if needed. When the size is increased, a new, larger storage area is allocated and the contents of the old storage area are copied into the new area. A Vblock is not resized automatically, however; it is the client's responsibility to check that an index is within bounds before using it to access a Vblock element:
#include "usr.h" main(){ USR u; ... for( unsigned i=0;i<100;i++ ){ u.proj.reserve(i); u.proj[i]=i; } cout << u; }
The function reserve(i) guarantees that the index i is valid; in other words, it guarantees that the number of elements is strictly greater than i. ``Extra'' elements, if any, will be zeros.
If we inspect the u.proj field before the loop, we will see that it has four cells, each containing zero. Immediately after the loop, we will find that it contains at least 100 cells containing consecutive integers 0,1,2,....99. The G2++ record definition, on the other hand, defined proj as having a maximum of four elements. Is this a problem? Once again, the answer is ``No:'' the typed inserter will not write out more than four elements, and the typed extractor will ignore any index greater than three. Again, this behavior is strictly compatible with G2. In the next section, we will see that G2++ also allows users to define records containing arbitrary size arrays.