comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Performance of element access in Vector
Date: Tue, 20 Jan 2009 17:01:28 -0600
Date: 2009-01-20T17:01:28-06:00	[thread overview]
Message-ID: <gl5l54$qor$1@munin.nbi.dk> (raw)
In-Reply-To: gl3c7s$m6i$1@munin.nbi.dk

> "Maciej Sobczak" <see.my.homepage@gmail.com> wrote:

>> What happens in C++ when the element whose reference you are using is 
>> deleted?
>
>Formally speaking - undefined behavior.
>The difference is, however, that it is possible to use vectors in C++ 
>without going into undefined behavior, whereas it seems to be impossible to 
>use Vectors in Ada without being slow.

Maybe it is possible to avoid undefined behavior, but only if you (the 
programmer) never makes mistakes. I don't think such a programmer exists.

The containers in Ada are designed to be safe; that necessarily requires 
giving up a bit of performance. We didn't go all the way to perfectly safe 
in order to keep some modicum of performance.

But, honestly, if the performance of some data structure in your program is 
critical enough to make it worth timing, then it should not be written using 
a predefined container -- anybodies predefined containers. But for the vast 
majority of programs (probably over 90% of uses), the performance of a 
container (so long as it is reasonable) is not relevant.

>I think that given two correct programs a typical customer will pick
>the faster one.

In the absense of using SPARK or somthing like it, there are no correct 
programs. There are only more or less buggy ones, and ones that are more 
tolerant of bugs. (Testing proves nothing whatsoever about correctness; it 
can only prove that a program appears to work for a particular set of input. 
And I say "appears to work" because getting the right answer doesn't prove 
anything about the absense of bugs, either, it only proves that there aren't 
any bugs that change the answer. We Ada programmers do spend some time 
fixing bugs that don't actually affect the answer (such as unused 
initialization values that are out of range).)

So the real question is what amount of confidence that you have in the 
correctness of the program. Sadly, end users cannot tell the quality of the 
development process used on a program, so they end up thinking all programs 
are barely functioning garbage and then pick the one that is faster by 0.01 
sec (which is not noticable to a human) or, more likely, pick the one with 
the "cooler" graphics (despite the fact that the program itself is barely 
usable and not at all understandable).

                      Randy.





  parent reply	other threads:[~2009-01-20 23:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-18 21:42 Performance of element access in Vector Maciej Sobczak
2009-01-19  0:03 ` george.priv
2009-01-19  3:23 ` george.priv
2009-01-19 11:25   ` Georg Bauhaus
2009-01-19 16:32   ` (see below)
2009-01-20  2:17 ` Randy Brukardt
2009-01-20  8:03   ` Maciej Sobczak
2009-01-20  8:26     ` Dmitry A. Kazakov
2009-01-20 22:07       ` george.priv
2009-01-21  8:52         ` Maciej Sobczak
2009-01-21 19:25           ` george.priv
2009-01-22 10:01             ` Georg Bauhaus
2009-01-22 12:43               ` Maciej Sobczak
2009-01-22 13:52               ` george.priv
2009-01-21  8:59         ` Dmitry A. Kazakov
2009-01-21  9:19           ` Maciej Sobczak
2009-01-21 10:19             ` Dmitry A. Kazakov
2009-01-21 13:14               ` Maciej Sobczak
2009-01-21 19:00                 ` Dmitry A. Kazakov
2009-01-21 13:22             ` Georg Bauhaus
2009-01-23 14:56         ` Alex R. Mosteo
2009-01-20 23:01   ` Randy Brukardt [this message]
2009-01-21  9:15     ` Maciej Sobczak
2009-01-21 18:08       ` Georg Bauhaus
2009-01-23 14:55         ` Alex R. Mosteo
2009-01-23 17:30           ` Georg Bauhaus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox