Prev: Child vs nested package : efficiency matter
Next: Two miscellaneous questions about GPS : Ada indentation and thenSPARK integration
From: Dmitry A. Kazakov on 3 Jun 2010 03:48
On Thu, 03 Jun 2010 04:37:42 +0200, Yannick Duch�ne (Hibou57) wrote:
> Le Sat, 29 May 2010 20:23:36 +0200, Dmitry A. Kazakov
> <mailbox(a)dmitry-kazakov.de> a �crit:
>>> Conn : Class_Type := New_Class_Instance;
>> Should Conn be mutable? Otherwise you could use a function instead.
> Good note (formally talking).
> May be the reason was a matter of efficiency ?
A renaming could also go, but it would not because of the "unseen body"
Dmitry A. Kazakov
From: Dmitry A. Kazakov on 3 Jun 2010 03:57
On Thu, 03 Jun 2010 04:36:12 +0200, Yannick Duch�ne (Hibou57) wrote:
> Not necessarily, as he can move the body of the function returning
> Class_Type before the declaration of the variable initialized from this
You cannot have bodies in the package specifications. This is a difficult
problem, since present construction model does not support deferred
initialization. In short, you cannot have this in a single package.
Dmitry A. Kazakov
From: Yannick Duchêne (Hibou57) on 3 Jun 2010 04:21
Le Thu, 03 Jun 2010 09:57:33 +0200, Dmitry A. Kazakov
<mailbox(a)dmitry-kazakov.de> a écrit:
> You cannot have bodies in the package specifications. This is a difficult
> problem, since present construction model does not support deferred
> initialization. In short, you cannot have this in a single package.
OK. I had though the example was an exact extract from the real thing.
So indeed, if the variable is to be in a spec, it needs two packages, one
containing the function, and one containing the variable, so that one
package -- the one containing the function -- can be elaborated before the
other -- containing the variable. A child package would be a good choice
to hold that variable.
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
-- i.e. forget about previous premises which leads to conclusion
-- and start with new conclusion as premise.
From: Adam Beneschan on 3 Jun 2010 12:03
On Jun 2, 7:36 pm, Yannick Duchêne (Hibou57)
> Le Wed, 02 Jun 2010 01:36:17 +0200, Randy Brukardt <ra...(a)rrsoftware.com>
> a écrit:> You have to explicitly use a
> > type conversion here:
> > Conn : Class_Type := Class_Type (New_Class_Instance);
> This one is not legal, as Class_Type is limited and conversion are not
> allowed on limited type due to their copy based semantic.
> [ARM 2005 4.6] says about type conversions
> Neither the target type nor the operand type shall be limited
Umm, no, that sentence (4.6(24.7)) applies only to array types. (And,
I think, only in cases where there is no common ancestor of the
operand and target type.) However, 7.5(2.1-2.2) makes it illegal.
Type conversions on limited types are allowed in some cases; e.g. if
T1 is a limited tagged type, and T2 is a type extension, and X2 is an
object of type T2, you can use T1(X2) as an actual parameter to a
procedure that takes an IN OUT parameter of type T1. This is a view
conversion and doesn't involve a copy.
From: Marc A. Criley on 5 Jun 2010 14:47
On 06/01/2010 06:36 PM, Randy Brukardt wrote:
> "Marc A. Criley"<mcNOSPAM(a)mckae.com> wrote in message
>> Stripping out a test case, I see that it has nothing to with the C++
>> binding per se, but it's an Ada issue that's flummoxing me. Here's the
>> test code:
>> procedure Dyty_Test is
>> type Class_Type is tagged limited record
>> end record;
>> function New_Class_Instance return Class_Type'Class;
>> Conn : Class_Type := New_Class_Instance;
> This is illegal because the function returns a class-wide object and you are
> assigning it into an object of a specific type. You have to explicitly use a
> type conversion here:
> Conn : Class_Type := Class_Type (New_Class_Instance);
> to specify that you want to truncate the returned object, or make the object
> Conn : Class_Type'Class := New_Class_Instance;
> But notice that while both of these are legal, they'll both raise
> Program_Error because an access-before-elaboration error (the body of
> New_Class_Instance hasn't been elaborated at the point of this call).
Actually, stripping out the C++ interface pragmas was probably a bad
idea on my part. (Though the thread *was* educational :-)
I thought that to create an instance of the C++ class I had to invoke
the New_Class_Instance function myself, from which arose this issue.
Turns out I don't. GNAT's handling of the C++ pragmas does it all for me
The documentation on creation an Ada binding to C++ is somewhat...terse
when it comes to describing the mechanics of what is going on "under the
hood", from whence came my misunderstanding.
So this part is all better now, I can step in and verify that my
constructors are being executed. I'm having other problems, but that's
just the usual banging the head against the wall stuff.
Marc A. Criley