Surprising behaviour of strings.fixed.overwrite

Surprising behaviour of strings.fixed.overwrite

[Markus Schöpflin]

Given the following Ada program:

---%<---
with TEXT_IO;
with ADA.STRINGS;
with ADA.STRINGS.FIXED;

procedure TEST
is
    S : STRING(1 .. 6);
begin
    S := "@@@@@@";
    ADA.STRINGS.FIXED.OVERWRITE (S, S'First + 5, "56", ADA.STRINGS.LEFT);
    TEXT_IO.PUT_LINE (S);

    S := "@@@@@@";
    ADA.STRINGS.FIXED.OVERWRITE (S, S'First + 5, "56", ADA.STRINGS.RIGHT);
    TEXT_IO.PUT_LINE (S);
end;
--->%---

What would you expect to be the output of the program?

Scroll down for the answer...

















































Well, I would have expected the output to be

@@@@@6
@@@@@5

But it is:

@@@@56
@@@@@5

Which is correct according to the definition of overwrite, but nevertheless I 
find this extremely surprising.

Am I alone in this?

Or can anyone please the rational on defining the behaviour of overwrite as it is?

Markus

Re: Surprising behaviour of strings.fixed.overwrite

[G.B.]

On 12.11.14 11:49, Markus Schöpflin wrote:
>
>
> Well, I would have expected the output to be
>
> @@@@@6
> @@@@@5
>
> But it is:
>
> @@@@56
> @@@@@5
>
> Which is correct according to the definition of overwrite, but
> nevertheless I find this extremely surprising.
>
> Am I alone in this?

No, I don't think so. To me it seems that perhaps the LRM is
trying to convey mathematical meaning using common sense words:
Overwrite involves creating a potentially longer string and
then dropping characters from that new string, either left
or right. In doing so, the procedure needs to abstractly
overwrite at positions before Position, which is odd.

Re: Surprising behaviour of strings.fixed.overwrite

[Adam Beneschan]

On Wednesday, November 12, 2014 2:49:33 AM UTC-8, Markus Schöpflin wrote:

> Well, I would have expected the output to be
> 
> @@@@@6
> @@@@@5
> 
> But it is:
> 
> @@@@56
> @@@@@5
> 
> Which is correct according to the definition of overwrite, but nevertheless I 
> find this extremely surprising.
> 
> Am I alone in this?
> 
> Or can anyone please the rational on defining the behaviour of overwrite as it is?

I agree that it's odd.  However, it does make some sense that the Overwrite *function* would return a 7-character String in the first case, although that also isn't the effect I would have expected at first (since the characters that get appended to the string aren't overwriting anything).  I can imagine how this kind of result from the function would be useful.  I'm guessing, though, that this possible behavior of the function was missed when it was decided to define the procedure's semantics in terms of the function.

                                -- Adam

Re: Surprising behaviour of strings.fixed.overwrite

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

"Markus Schöpflin" <no.spam@spam.spam> wrote in message 
news:m3vdvn$uu$1@speranza.aioe.org...
> Given the following Ada program:
...
> Which is correct according to the definition of overwrite, but 
> nevertheless I find this extremely surprising.

I suppose, but so what? It's not like we could change the meaning of this 
routine (or any routine in Ada.Strings), as doing so would potentially 
silently break existing code.

IMHO, the vast majority of Ada.Strings.Fixed routines are rather nonsense. I 
think they exist so that there are counterparts to the routines in 
Ada.Strings.Unbounded, but there's rarely much reason to use them rather 
than just using an appropriate slice. I personally use Ada.Strings.Fixed for 
Index and sometimes Translate or Move, and that's about it. Everything else 
I do with slices or loops (admittedly, I started doing that back in the Ada 
83 days before Ada.Strings.Fixed existed, and there doesn't seem to be much 
reason to change). I find that I have to look up the definition (both the 
name, the parameters, and the semantics) for any other routine, and by the 
time I've done that, I could have written a slice that would generally be 
faster and smaller anyway.

                                      Randy.


                                  Randy.

Re: Surprising behaviour of strings.fixed.overwrite

[Markus Schöpflin]

Am 13.11.2014 um 00:19 schrieb Randy Brukardt:
> "Markus Schöpflin" <no.spam@spam.spam> wrote in message
> news:m3vdvn$uu$1@speranza.aioe.org...
>> Given the following Ada program:
> ...
>> Which is correct according to the definition of overwrite, but
>> nevertheless I find this extremely surprising.
>
> I suppose, but so what? It's not like we could change the meaning of this
> routine (or any routine in Ada.Strings), as doing so would potentially
> silently break existing code.

True, but I suspect in this case chances are that it would actually silently
fix existing code. :-)

> IMHO, the vast majority of Ada.Strings.Fixed routines are rather nonsense.
> I think they exist so that there are counterparts to the routines in
> Ada.Strings.Unbounded, but there's rarely much reason to use them rather
> than just using an appropriate slice.

That's exactly what I'm trying to avoid. I tend to get the indices wrong when
doing manual slicing; and I have already seen too much code getting it wrong, too.

> I personally use Ada.Strings.Fixed for Index and sometimes Translate or
> Move, and that's about it. Everything else I do with slices or loops
> (admittedly, I started doing that back in the Ada 83 days before
> Ada.Strings.Fixed existed, and there doesn't seem to be much reason to
> change). I find that I have to look up the definition (both the name, the
> parameters, and the semantics) for any other routine, and by the time I've
> done that, I could have written a slice that would generally be faster and
> smaller anyway.

I was hoping to eventually remember all these things when I would finally 
start consistently using the standardized methods provided by Ada.

But by now I think I'm better off creating my own set of functions and 
procedures which just do what I need, as it turns out that the standard 
implementation is rather slow, anyway.

Markus

Re: Surprising behaviour of strings.fixed.overwrite

[Simon Wright]

Markus Schöpflin <no.spam@spam.spam> writes:

> But by now I think I'm better off creating my own set of functions and
> procedures which just do what I need, as it turns out that the
> standard implementation is rather slow, anyway.

No issue with creating your own subprograms, but GNAT's implementation
isn't the standard (the Standard contains no implementation, after all).

Re: Surprising behaviour of strings.fixed.overwrite

[Markus Schöpflin]

Am 13.11.2014 um 13:40 schrieb Simon Wright:
> Markus Schöpflin <no.spam@spam.spam> writes:
>
>> But by now I think I'm better off creating my own set of functions and
>> procedures which just do what I need, as it turns out that the
>> standard implementation is rather slow, anyway.
>
> No issue with creating your own subprograms, but GNAT's implementation
> isn't the standard (the Standard contains no implementation, after all).
>
Sorry, what I wanted to say is that GNAT's implementation of the standard is 
rather slow in this case.