Re: Weird error with Dynamic_Predicate

[mockturtle <framefritti@gmail.com>]

Thank you everyone for your comments. 




@Randy, @Adam

> Ergo, this is a GNAT bug that's been fixed sometime in the past two years. 
> The OP needs a compiler upgrade (whether its available at this time is an 
> unknown question).

Yes, I was afraid of that, especially after seeing the "reduced example" by Adam.  BTW, this morning, thinking about that example, I found a workaround that works even with my version:

  function Extract_Namespace (Nome : Full_Identifier)
                               return Namespace_Identifier
   is
      Idx : Natural;
   begin
      Idx := Ada.Strings.Fixed.Index (String (Nome), ".");
      return Namespace_Identifier (Nome (Nome'First .. Idx - 1));
   end Extract_Namespace;

In other words, instead of initializing Index to the result of Index, I assign Idx in the function body.  This buys me some time before the upgrade... :-) 



@G.B.

> From a different angle, a rule of contract-based design--- 
> assuming the lessons learned from DbC---is not a substitute 
> for input checking. While I guess you have your reasons for 
> attaching the Dynamic_Predicate to a string type, 

One of the reason for using Dynamic_Predicate is... to make experience (it sounds better than "to play" :-) with it.  This is a piece of SW that I am writing for myself and I am using the occasion to get familiar with these new features.  

> By the above rule (about DbC not being input checking), 
> some I/O routine would check the syntax; 
> then, if the characters form a well formed string, the object 
> can be converted to a different string type; this string 
> type does not have the dynamic check attached, since after 
> the checking routine is done, the type's objects are known 
> to have only good values. 

This is actually my case: most of the strings are read via a scanner that implements an automaton that recognizes the identifiers (the other identifiers are just constant strings in the code).  If was sure that the automaton is correct (nice 'if'), I would be granted that the identifiers have the correct syntax; but since an error could slip, (or I could write a constant with the wrong syntax) I am using the predicate as a "bug trap" kept on at debug time.

Oh, BTW, sorry for the question, but what does DbC mean? (I guess it has nothing to do with dB...)



@Martin

> it should be the 'constructor' that ensures the class invariant - the 
> validity of the 'raw string' or raises an exception otherwise. 
>
> So you always want to force the user to use a proved 'constructor' 
> function and no other, e.g. 
> 
> package Valid_Strings is 
>    type Valid_String (<>) is tagged private; 
>    Invalid_String : exception; 
>    function Create (S : String) return Valid_String; 

Yes, and often I used this type of solution.  In this case I felt that it
was maybe a bit an overkill, since my object is a String, not only as a representation but also "conceptually", only with an additional 
constraint. (As I said above, the identifiers in my code are 
constants or are read via a scanner and this should grant the correct syntax) Also this solution would make the code a bit heavier since I would loose the fact that a String is an array and I should provide functions for slicing, concatenation, searching and so on; at the very minimum I would need a function to convert a Valid_String back into a String.     Not big deal?  I agree... nevertheless the code is a bit more "natural" in this way.

--

Best regards,

Riccardo