Hello.
I am reading the book written by Bjarne Stroustrup called " The
C++ Programming Language - Special Edition" and
had a doubt which a think is really important to distinguish between
the main features of modules, namespaces, and
User-Defined types. The text above was copied from page 31.
--------------------------------------------------------
namespace Stack{ // representation
const int max_ size = 200;
struct Rep {
char v[max_ size] ;
int top;
};
const int max = 16; // maximum number of stacks
Rep stacks[max] ; // preallocated stack representations
bool used[max] ; // used[i] is true if stacks[i] is in use
typedef Rep& stack;
void push(stack s, char c) { /* check s for overflow and push c */
}
char pop(stack s) { /* check s for underflow and pop
*/ }
stack create() { /* pick an unused Rep, mark
it used, initialize it, and return a reference to it */ }
void destroy(stack s) { /* mark s unused */ }
}
void f()
{
Stack::stack s1 = Stack: :create() ; / / make a new stack
Stack::stack s2 = Stack: :create() ; / / make another new stack
Stack::push(s1,´c´) ;
Stack::push(s2,´k´) ;
if (Stack::pop(s1) != ´c´) throw Bad_ pop() ;
if (Stack::pop(s2) != ´k´) throw Bad_ pop() ;
Stack::destroy(s1) ;
Stack::destroy(s2) ;
}
" What we have done is to wrap a set of interface functions around
the representation type. How the
resulting ‘‘stack type'' behaves depends partly on how we defined
these interface functions, partly
on how we presented the representation type to the users of Stacks,
and partly on the design of the
representation type itself.
This is often less than ideal. A significant problem is that the
presentation of such ‘‘fake types''
to the users can vary greatly depending on the details of the
representation type – and users ought to
be insulated from knowledge of the representation type. For example,
had we chosen to use a more
elaborate data structure to identify a stack, the rules for assignment
and initialization of
Stack: :stacks would have changed dramatically. This may indeed be
desirable at times. However,
it shows that we have simply moved the problem of providing convenient
stacks from the
Stack module to the Stack: :stack representation type.
More fundamentally, user-defined types implemented through a
module providing access to an
implementation type don't behave like built-in types and receive less
and different support than do
built-in types. For example, the time that a Stack: :Rep can be used
is controlled through
Stack: :create() and Stack: :destroy() rather than by the usual
language rules."
Bjarne Stroustrup
--------------------------------------------------------
The disadvantage of using the module in this way , in my opinion,
is because of creation and
destruction are not directly suported by the language.
My doubt is that I can't visualize a way in which changes will be
necessary in the inicialization and assignment due to modifications in
the representation. Since when creation is performed a reference
is returned, we have exactly the representation previously created, so
I don't understand why "the rules for assignment and initialization of
Stack: :stacks would have changed dramatically".
Thanks,
Guilherme Pinto
