Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > const element type in standard library containers

Reply
Thread Tools

const element type in standard library containers

 
 
Ian Collins
Guest
Posts: n/a
 
      05-30-2008
James Kanze wrote:
> On May 30, 6:27 am, Ian Collins <(E-Mail Removed)> wrote:
>>>>>> No, you get away with it because the insert operation isn't
>>>>>> doing an assignment.

>
>>>>> You don't get away with anything. Violating the requirements is
>>>>> undefined behavior. An implementation is not required to
>>>>> diagnose it, but it isn't required to document what happens if
>>>>> there is no diagnostic. The code is wrong, and should be
>>>>> corrected, even if your tests today don't show any problems.

>
>>>> I think that's what I said.....

>
>>> You said that even if the tests show that the code works...

>
>> Ah but I would have added a test for insert of an immutable
>> object!

>
> Which might pass, even though the code is wrong. Undefined
> behavior means that tests are meaningless, and IMHO, the problem
> *isn't* with the concept of testing.
>

I meant a test in the standard library container test suite.

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

--
Ian Collins.
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      05-31-2008
On May 30, 12:29 pm, Ian Collins <(E-Mail Removed)> 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. Practically, of
course, regardless of what the standard says, the behavior is
always never totally undefined; the behavior of something like
i++ + i++ may be undefined, but once the compiler has generated
code for the statement, that code will always do the same thing.
It's still a situation which leaves much to be desired; ideally:
-- we'd like any test using such code to fail, or
-- failing that, we'd like to have the guarantee that if such
code passed our tests, it would pass then the next time we
compile as well (possibly with a different level of
optimization, or a more recent version of the compiler).
The first is, I think, practically unattainable, but reducing a
lot of the unnecessary undefined behavior in C++ would certainly
go a long way to reaching the second.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      05-31-2008
James Kanze wrote:
> On May 30, 12:29 pm, Ian Collins <(E-Mail Removed)> 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.

--
Ian Collins.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-31-2008
On May 31, 10:43 am, Ian Collins <(E-Mail Removed)> wrote:
> James Kanze wrote:
> > On May 30, 12:29 pm, Ian Collins <(E-Mail Removed)> 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:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      06-01-2008
James Kanze wrote:
> On May 31, 10:43 am, Ian Collins <(E-Mail Removed)> wrote:
>> James Kanze wrote:
>>> On May 30, 12:29 pm, Ian Collins <(E-Mail Removed)> 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.
>

That depends if the library has undefined behaviour. If the type of
objects stored in a container is required to be copy constructable and
assignable, that can be tested. The test might have to be done at the
build level, a verification that compilation fails if this requirement
is violated.

I was thinking along the lines of:

#include <utility>
#include <list>

template < typename T >
struct CheckTypeIsAssignable : std::list<T>
{
CheckTypeIsAssignable()
{
T t;
t = T();
}
};

int main()
{
CheckTypeIsAssignable<std:air<const int, const int> > c1;

return 0;
}

int main()
{
CheckTypeIsAssignable<std:air<const int, const int> > c1;

return 0;
}

> (But I think we largely agree here. Testing is important, and
> anything that makes testing more difficult and less reliable is
> a bad thing.)
>

Can't argue with that!

--
Ian Collins.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      06-01-2008
On Jun 1, 2:44 am, Ian Collins <(E-Mail Removed)> wrote:
> James Kanze wrote:
> > On May 31, 10:43 am, Ian Collins <(E-Mail Removed)> wrote:
> >> James Kanze wrote:
> >>> On May 30, 12:29 pm, Ian Collins <(E-Mail Removed)> 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.


> That depends if the library has undefined behaviour. If the
> type of objects stored in a container is required to be copy
> constructable and assignable, that can be tested.


I'm not sure we're on the same wave length. There are two
issues, and I'm not really sure which one we're talking about.

The first: in specific cases (library or not), C++ has undefined
behavior. You cannot reliably test whether your code falls into
one of those cases or not unless the implementation has defined
the behavior in some specific way you can test for. Two good
examples: instantiating an std::list over a type which doesn't
support assignment (which will never in fact fail with some
implementations of std::list), and something like i++ + ++i (in
which case I know of no implementation where it will "fail", but
it won't always give the same results). In my opinion, such
undefined behavior seriously reduces the confidence we can have
in our tests, and C++ really should try to close as many of
these holes as possible.

The second is the case of library implementors themselves. The
standard says that in certain cases (e.g. std::string(NULL)),
the library has undefined behavior. If, as an implementor, you
define this behavior (e.g. by guaranteeing an assertion
failure), you can and should test for it. But if you decide not
to do so, what does it even mean to test it? Does it have any
meaning to test to ensure that you haven't accidentally defined
any behavior, and if so, how do you test it? Again, in general,
my opinion is that you shouldn't define such cases; that as a
library implementor, you should define the behavior regardless
of what the client code does. But performance considerations
can intervene; checking for null in std::string(char const*)
isn't that expensive, but tracking iterators to verify their
validity can definitely have a measurable impact on performance.

> The test might have to be done at the build level, a
> verification that compilation fails if this requirement is
> violated.


Concept checking, in sum. Some standard library implementations
(g++, and maybe also Dinkumware) implement concept checking
already. The next version of the standard will introduce
language support for this, and require the library to use it (I
think). A lot less undefined behavior, and a major step
forward.

> I was thinking along the lines of:


> #include <utility>
> #include <list>
>
> template < typename T >
> struct CheckTypeIsAssignable : std::list<T>
> {
> CheckTypeIsAssignable()
> {
> T t;
> t = T();
> }
> };


> int main()
> {
> CheckTypeIsAssignable<std:air<const int, const int> > c1;
>
> return 0;
> }


> int main()
> {
> CheckTypeIsAssignable<std:air<const int, const int> > c1;
>
> return 0;
> }


I'm not quite sure what you're trying to show in this example.
It doesn't test the library in anyway (at least that I can see),
and it doesn't test your code (i.e. verifying that you haven't
instantiated std::list over a type which isn't assignable).
Such concept checks have to be part of the library to be useful.
(Thus, g++ does do something like this when you instantiate an
std::list, so just writing std::list< const int > myList; will
cause compilation to fail.)

> > (But I think we largely agree here. Testing is important,
> > and anything that makes testing more difficult and less
> > reliable is a bad thing.)


> Can't argue with that!


So you'd agree with me that C++ should eliminate undefined
behavior as far as possible.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      06-01-2008
James Kanze wrote:
> On Jun 1, 2:44 am, Ian Collins <(E-Mail Removed)> wrote:
>
> Concept checking, in sum. Some standard library implementations
> (g++, and maybe also Dinkumware) implement concept checking
> already. The next version of the standard will introduce
> language support for this, and require the library to use it (I
> think). A lot less undefined behavior, and a major step
> forward.
>

Yes and long overdue!

> I'm not quite sure what you're trying to show in this example.
> It doesn't test the library in anyway (at least that I can see),
> and it doesn't test your code (i.e. verifying that you haven't
> instantiated std::list over a type which isn't assignable).


The idea was for a test case that should fail to compile. As you say,
the over simplified example I posted doesn't do a great deal. I
originally had a private member,

void checkTypeIsAssignable()
{
T t;
t = T();
};

to be called from the container constructors thus:

if(0) checkTypeIsAssignable();

The call should be optimised away by an optimiser while still causing a
compilation error for immutable types.
>
>>> (But I think we largely agree here. Testing is important,
>>> and anything that makes testing more difficult and less
>>> reliable is a bad thing.)

>
>> Can't argue with that!

>
> So you'd agree with me that C++ should eliminate undefined
> behavior as far as possible.
>

Yes.

--
Ian Collins.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Necessity for const and non-const containers Matteo Settenvini C++ 1 02-02-2011 01:31 PM
Constant qualifier pros/cons, type const& versus const type&, etc. paulo C++ 9 03-06-2009 09:55 AM
CopyConstructible requirement for standard library containers subramanian100in@yahoo.com, India C++ 4 10-01-2008 07:35 AM
const vector<A> vs vector<const A> vs const vector<const A> Javier C++ 2 09-04-2007 08:46 PM
const type& and type const& p|OtrEk C++ 6 07-17-2005 06:36 PM



Advertisments