Re: const element type in standard library containers
On May 31, 10:43 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On May 30, 12:29 pm, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
[...]
The "meaningless" is obviously hyperbole. But the
presence of undefined behavior in C++ does make reliable
software significantly more difficult, since it reduces
the significence of tests: you can never be sure that the
test didn't pass just because some undefined behavior
happened to work this time.
One of the purposes of tests is to remove undefined
behaviour. But the whole thing goes pear shaped when you
rely on a library which has its own undefined behaviour.
The problem is that formally speaking, you can't test for
undefined behavior, since whatever happens is undefined---it
could work in all your tests and still fail.
That goes without saying, but don't forget where we started,
insertion of an immutable object into a standard container.
It would be possible to assert this in the library code.
It would be possible for a library implementation to define most
or all of the undefined behavior, and check for it. (The better
ones do, or at least attempt to.) It would also be possible
(and desirable) that the a library which did so test it. But if
for whatever reasons (usually performance), the library decides
to leave it as "undefined behavior", how can the library
implementors test that it really is undefined? Or for that
matter, does such a test make sense? Isn't specifying something
as "undefined behavior" just another way of saying "we don't
have to test it"?
(But I think we largely agree here. Testing is important, and
anything that makes testing more difficult and less reliable is
a bad thing.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34