Limited Types
Assignment and equality
So far, we discussed nonlimited types in most cases. Limited types, in contrast, have the following restrictions, which we discussed in the Introduction to Ada course:
copying objects of limited types via direct assignments is forbidden; and
there's no predefined equality operator for limited types.
(Of course, in the case of nonlimited types, assignments are possible and the equality operator is available.)
A good reason for having these restrictions for limited types is that the assignment and equality operations may have side-effects that lead to erroneous programs, even though they are perfectly OK in many cases. Programs can become erroneous when we use those operations on record types that have components of access types, for example:
In this code, we declare the Simple_Rec type in the
Nonlimited_Types package and use it in the
Show_Wrong_Assignment_Equality procedure. In principle, we're already
doing many things right here. For example, we're declaring the
Simple_Rec type private, so that the component V of access
type is encapsulated. Programmers that declare objects of this type cannot
simply mess up with the V component. Instead, they have to call the
Init function and the Set procedure to initialize and change,
respectively, objects of the Simple_Rec type. That being said, there are
two problems with this code, which we discuss next.
The first problem we can identify is that the first call to Show_Compare
shows that A and B are different, although both have the same
value in the V component (A.V.all = 0 and B.V.all = 0)
— this was set by the call to the Init function. What's happening
here is that the A = B expression is comparing the access values
(A.V = B.V), while we might have been expecting it to compare the actual
integer values after dereferencing (A.V.all = B.V.all). Therefore, the
predefined equality function of the Simple_Rec type is useless and
dangerous for us, as it misleads us to expect something that it doesn't do.
After the assignment of A to B (B := A), the information
that the application displays seems to be correct — both A.V.all
and B.V.all have the same value of two. However, when assigning the
value seven to B by calling Set (B, 7), we see that the value of
A.V.all has also changed. What's happening here is that the previous
assignment (B := A) has actually assigned access values
(B.V := A.V), while we might have been expecting it to assign the
dereferenced values (B.V.all := A.V.all). Therefore, we cannot simply
directly assign objects of Simple_Rec type, as this operation changes
the internal structure of the type due to the presence of components of access
type.
For these reasons, forbidding these operations for the Simple_Rec type
is the most appropriate software design decision. If we still need assignment
and equality operators, we can implement custom subprograms for the limited
type. We'll discuss this topic in the next sections.
In addition to the case when we have components of access types, limited types are useful for example when we want to avoid the situation in which the same information is copied to multiple objects of the same type.
In the Ada Reference Manual
Assignments
Assignments are forbidden when using objects of limited types. For example:
As expected, we get a compilation error for the B := A statement. If we
need to copy two objects of limited type, we have to provide a custom procedure
to do that. For example, we can implement a Copy procedure for the
Simple_Rec type:
The Copy procedure from this example copies the dereferenced values of
From to To, which matches our expectation for the
Simple_Rec. Note that we could have also implemented a
Shallow_Copy procedure to copy the actual access values (i.e.
To.V := From.V). However, having this kind of procedure can be dangerous
in many case, so this design decision must be made carefully. In any case,
using limited types ensures that only the assignment subprograms that are
explicitly declared in the package specification are available.
Equality
Limited types don't have a predefined equality operator. For example:
As expected, the comparison A = B triggers a compilation error because
no predefined = operator is available for the Simple_Rec type.
If we want to be able to compare objects of this type, we have to implement
the = operator ourselves. For example, we can do that for the
Simple_Rec type:
Here, the = operator compares the dereferenced values of Left.V
and Right.V, which matches our expectation for the Simple_Rec
type. Declaring types as limited ensures that we don't have unreasonable
equality comparisons, and allows us to create reasonable replacements when
required.
In other languages
In C++, you can overload the assignment operator. For example:
class Simple_Rec
{
public:
// Overloaded assignment
Simple_Rec& operator= (const Simple_Rec& obj);
private:
int *V;
};
In Ada, however, we can only define the equality operator (=).
Defining the assignment operator (:=) is not possible. The following
code triggers a compilation error as expected:
package Limited_Types is
type Integer_Access is access Integer;
type Simple_Rec is limited private;
procedure ":=" (To : in out Simple_Rec
From : Simple_Rec);
-- ...
end Limited_Types;
Limited types and aggregates
Note
This section was originally written by Robert A. Duff and published as Gem #1: Limited Types in Ada 2005 and Gem #2.
In this section, we focus on using aggregates to initialize limited types.
Historically
Prior to Ada 2005, aggregates were illegal for limited types. Therefore, we would be faced with a difficult choice: Make the type limited, and initialize it like this:
which has the maintenance problem the full coverage rules are supposed to prevent. Or, make the type non-limited, and gain the benefits of aggregates, but lose the ability to prevent copies.
Full coverage rules for limited types
Previously, we discussed full coverage rules for aggregates. We can also use them for limited types.
Historically
The full coverage rules have been aiding maintenance since Ada 83. However, prior to Ada 2005, we couldn't use them for limited types.
Suppose we have the following limited type:
This type has a self-reference; it doesn't make sense to copy objects,
because Self would end up pointing to the wrong place. Therefore,
we would like to make the type limited, to prevent developers from
accidentally making copies. After all, the type is probably private, so
developers using this package might not be aware of the problem. We could
also solve that problem with controlled types, but controlled types are
expensive, and add unnecessary complexity if not needed.
We can initialize objects of limited type with an aggregate. Here, we can say:
The Self => <> means use the default value of
Limited_Person'Unchecked_Access. Since Limited_Person
appears inside the type declaration, it refers to the "current instance"
of the type, which in this case is X. Thus, we are setting
X.Self to be X'Unchecked_Access.
One very important requirement should be noted: the implementation is
required to build the value of X in place; it cannot construct
the aggregate in a temporary variable and then copy it into X,
because that would violate the whole point of limited objects —
you can't copy them.
Historically
Since Ada 2005, an aggregate is allowed to be limited; we can say:
It seems uncomfortable to set the value of Self to the wrong value
(null) and then correct it. It also seems annoying that we have a
(correct) default value for Self, but prior to Ada 2005, we
couldn't use defaults with aggregates. Since Ada 2005, a new syntax in
aggregates is available: <> means "use the default value, if any".
Therefore, we can replace Self => null by Self => <>.
Important
Note that using <> in an aggregate can be dangerous, because it can
leave some components uninitialized. <> means "use the default
value". If the type of a component is scalar, and there is no
record-component default, then there is no default value.
For example, if we have an aggregate of type String, like this:
we end up with a 10-character string all of whose characters are invalid values. Note that this is no more nor less dangerous than this:
As always, one must be careful about uninitialized scalar objects.
Constructor functions for limited types
Note
This section was originally written by Robert A. Duff and published as Gem #3.
Given that we can use build-in-place aggregates for limited types, the obvious next step is to allow such aggregates to be wrapped in an abstraction — namely, to return them from functions. After all, interesting types are usually private, and we need some way for clients to create and initialize objects.
Historically
Prior to Ada 2005, constructor functions (that is, functions that create new objects and return them) were not allowed for limited types. Since Ada 2005, fully-general constructor functions are allowed.
Let's see an example:
Given the above, clients can say:
As for aggregates, the result of Make_T is built in place (that is,
in My_T), rather than being created and then copied into
My_T. Adding another level of function call, we can do:
It might help to understand the implementation model: In this case,
Rumplestiltskin_Is_My_Name is allocated in the usual way (on the
stack, presuming it is declared local to some subprogram). Its address is
passed as an extra implicit parameter to Make_Rumplestiltskin,
which then passes that same address on to Make_T, which then builds
the aggregate in place at that address. Limited objects must never be
copied! In this case, Make_T will initialize the Name
component, and create the My_Task and My_Prot components,
all directly in Rumplestiltskin_Is_My_Name.
Historically
Note that Rumplestiltskin_Is_My_Name is constant. Prior to
Ada 2005, it was impossible to create a constant limited object, because
there was no way to initialize it.
The (<>) on type T means that it has unknown
discriminants from the point of view of the client. This is a trick that
prevents clients from creating default-initialized objects (that is,
X : T; is illegal). Thus clients must call Make_T whenever
an object of type T is created, giving package P full
control over initialization of objects.
Ideally, limited and non-limited types should be just the same, except for the essential difference: you can't copy limited objects. By allowing functions and aggregates for limited types, we're very close to this goal. Some languages have a specific feature called constructor. In Ada, a constructor is just a function that creates a new object.
Historically
Prior to Ada 2005, constructors only worked for non-limited types. For limited types, the only way to construct on declaration was via default values, which limits you to one constructor. And the only way to pass parameters to that construction was via discriminants.
Consider the following package:
Since Ada 2005, we can say:
whether or not Set is limited. This_Set : Set := Empty_Set;
seems clearer than:
which might mean "default-initialize to the empty set" or might mean "leave it uninitialized, and we'll initialize it in later".
Return objects
Extended return statements for limited types
Note
This section was originally written by Robert A. Duff and published as Gem #10: Limited Types in Ada 2005.
Previously, we discussed extended return statements. For most types, extended return statements are no big deal — it's just syntactic sugar. But for limited types, this syntax is almost essential:
The return statement here is illegal, because Result is local to
Make_Task, and returning it would involve a copy, which makes no
sense (which is why task types are limited). Since Ada 2005, we can write
constructor functions for task types:
If we call it like this:
Result is created in place in My_Task. Result is
temporarily considered local to Make_Task during the
-- some statements part, but as soon as Make_Task returns,
the task becomes more global. Result and My_Task really are
one and the same object.
When returning a task from a function, it is activated after the function
returns. The -- some statements part had better not try to call one
of the task's entries, because that would deadlock. That is, the entry
call would wait until the task reaches an accept statement, which will
never happen, because the task will never be activated.
Initialization and function return
As mentioned in the previous section, the object of limited type returned by the initialization function is built in place. In other words, the return object is built in the object that is the target of the assignment statement.
For example, we can see this when looking at the address of the object
returned by the Init function, which we call to initialize the limited
type Simple_Rec:
When running this code example and comparing the address of the object E
in the Init function and the object that is being initialized in the
Show_Limited_Init procedure, we see that the return object E (of
the Init function) and the local object in the Show_Limited_Init
procedure are the same object.
Important
When we use non-limited types, we're actually copying the returned object — which was locally created in the function — to the object that we're assigning the function to.
For example, let's modify the previous code and make Simple_Rec
non-limited:
In this case, we see that the local object
Ein theInitfunction is not the same as the object it's being assigned to in theShow_Non_Limited_Init_By_Copyprocedure. In fact,Eis being copied toAandB.
Building objects from constructors
Note
This section was originally written by Robert A. Duff and published as Gem #11: Limited Types in Ada 2005.
We've earlier seen examples of constructor functions for limited types similar to this:
It is useful to consider the various contexts in which these functions may be called. We've already seen things like:
in which case the limited object is built directly in a standalone object. This object will be finalized whenever the surrounding scope is left.
We can also do:
Here, the result of the function is built directly in the formal parameter
X of Do_Something. X will be finalized as soon as we
return from Do_Something.
We can allocate initialized objects on the heap:
The result of the function is built directly in the heap-allocated object,
which will be finalized when the scope of T_Ref is left (long after
Heap_Alloc returns).
We can create another limited type with a component of type T, and
use an aggregate:
As usual, the function results are built in place, directly in
Outer_Obj.This and Outer_Obj.That, with no copying involved.
The one case where we cannot call such constructor functions is in an assignment statement:
which is illegal because assignment statements involve copying. Likewise, we can't copy a limited object into some other object:
Default initialization
Note
This section was originally written by Robert A. Duff and published as Gem #12: Limited Types in Ada 2005.
Consider the following type declaration:
If we want to say, "make Count equal 100, but initialize
Color and Is_Gnarly to their defaults", we can do this:
Historically
Prior to Ada 2005, the following style was common:
Here, we only wanted Object_100 to be a default-initialized
T, with Count equal to 100. It's a little bit annoying
that we had to write the default values Red and False twice.
What if we change our mind about Red, and forget to change it in all
the relevant places? Since Ada 2005, the <> notation comes to the
rescue, as we've just seen.
On the other hand, if we want to say, "make Count equal 100,
but initialize all other components, including the ones we might add next
week, to their defaults", we can do this:
Note that if we add a component Glorp : Integer; to type T,
then the others case leaves Glorp undefined just as this
code would do:
Therefore, you should be careful and think twice before using
others.
Limited types as parameter
Previously, we saw that parameters can be passed by copy or by reference. Also, we discussed the concept of by-copy and by-reference types. Explicitly limited types are by-reference types. Consequently, parameters of these types are always passed by reference.
Here, it's important to understand when a type is explicitly limited and when
it's not — using the limited keyword in a part of the declaration
doesn't necessary ensure this, as we'll see later. Let's start with an example
of an explicitly limited type:
In this example, Rec is a by-reference type because the type declaration
is an explicit limited record. Therefore, the parameter R of the
Proc procedure is passed by reference.
We can run the Test application below and compare the address of the
R object from Test to the address of the R parameter of
Proc to determine whether both R s refer to the same object or
not:
When running the Test application, we confirm that R was passed
by reference. Note, however, that the fact that R was passed by
reference doesn't automatically imply that Rec is a by-reference type:
the type could have been ambiguous, and the compiler could have just decided to
pass the parameter by reference in this case. (We'll discuss this ambiguity
later.)
The Rec type is also explicitly limited when it's declared limited in
the private type's completion (in the package's private part):
In this case, Rec is limited both in the partial and in the full view,
so it's considered explicitly limited.
If we make the full view of the Rec non-limited (by removing the
limited keyword in the private part), then the Rec type
isn't explicitly limited anymore:
Now, even though the Rec type was declared as limited private, the full
view indicates that it's actually a non-limited type, so it isn't explicitly
limited. In this case, Rec is neither a by-copy nor a by-reference
type. Therefore, the decision whether the parameter is passed by reference or
by copy is made by the compiler.
In the Ada Reference Manual
Limited record elements
Todo
Complete section!
Private implementation of limited types
Todo
Complete section!