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.
next prev 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