Here if I remove the two comments(one each on vector insert and deque
insert), I get compilation error. But for list, there is no
compilation error for a similar insert. Why does compilation error
occur, only for vector and deque and not for list and map ?

, India wrote:
> On May 28, 1:51 pm, "Bo Persson" <> wrote:
>> Standard containers require that the value type is assignable. When
>> the pair members are const, it is not.
>>
>> With list and map, you just get away with this violation when the
>> assignment operator isn't used by the implementation.
>>
>> Bo Persson
>
> Does this mean that the CopyConstructible and Assignable requirements
> are not mandatory for list, map ? Rather, are they implementation-
> dependent ?
>
No, you get away with it because the insert operation isn't doing an
assignment.

On May 29, 8:42 am, Ian Collins <> wrote:
> , India wrote:
> > On May 28, 1:51 pm, "Bo Persson" <> wrote:
> >> Standard containers require that the value type is
> >> assignable. When the pair members are const, it is not.
> >> With list and map, you just get away with this violation
> >> when the assignment operator isn't used by the
> >> implementation.
> > Does this mean that the CopyConstructible and Assignable
> > requirements are not mandatory for list, map ? Rather, are
> > they implementation- dependent ?
> 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.

James Kanze wrote:
> On May 29, 8:42 am, Ian Collins <> wrote:
>> , India wrote:
>>> On May 28, 1:51 pm, "Bo Persson" <> wrote:
>>>> Standard containers require that the value type is
>>>> assignable. When the pair members are const, it is not.
>
>>>> With list and map, you just get away with this violation
>>>> when the assignment operator isn't used by the
>>>> implementation.
>
>>> Does this mean that the CopyConstructible and Assignable
>>> requirements are not mandatory for list, map ? Rather, are
>>> they implementation- dependent ?
>
>> 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.....

On May 29, 12:55 pm, Ian Collins <> wrote:
> James Kanze wrote:
> > On May 29, 8:42 am, Ian Collins <> wrote:
> >> , India wrote:
> >>> On May 28, 1:51 pm, "Bo Persson" <> wrote:
> >>>> Standard containers require that the value type is
> >>>> assignable. When the pair members are const, it is not.
> >>>> With list and map, you just get away with this violation
> >>>> when the assignment operator isn't used by the
> >>>> implementation.
> >>> Does this mean that the CopyConstructible and Assignable
> >>> requirements are not mandatory for list, map ? Rather, are
> >>> they implementation- dependent ?
> >> 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...

Seriously, I think that's what you meant. But the way you
expressed it could easily be misunderstood by someone whose
native language wasn't English; it depended on a certain reading
between the lines. And I've had enough experience with
non-native English speakers to know that it helps to put the
dots on the i's (which I'm not sure that non-native speakers
will understand either).

James Kanze wrote:
> On May 29, 12:55 pm, Ian Collins <> wrote:
>> James Kanze wrote:
>>> On May 29, 8:42 am, Ian Collins <> wrote:
>>>> , India wrote:
>>>>> On May 28, 1:51 pm, "Bo Persson" <> wrote:
>>>>>> Standard containers require that the value type is
>>>>>> assignable. When the pair members are const, it is not.
>
>>>>>> With list and map, you just get away with this violation
>>>>>> when the assignment operator isn't used by the
>>>>>> implementation.
>
>>>>> Does this mean that the CopyConstructible and Assignable
>>>>> requirements are not mandatory for list, map ? Rather, are
>>>>> they implementation- dependent ?
>
>>>> 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!

On May 30, 6:27 am, Ian Collins <> 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.

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.

James Kanze wrote:
> On May 30, 6:27 am, Ian Collins <> 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.

[...]
> > 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 wrote:
> On May 30, 12:29 pm, Ian Collins <> 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.

On May 31, 10:43 am, Ian Collins <> wrote:
> James Kanze wrote:
> > On May 30, 12:29 pm, Ian Collins <> 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 wrote:
> On May 31, 10:43 am, Ian Collins <> wrote:
>> James Kanze wrote:
>>> On May 30, 12:29 pm, Ian Collins <> 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.

On Jun 1, 2:44 am, Ian Collins <> wrote:
> James Kanze wrote:
> > On May 31, 10:43 am, Ian Collins <> wrote:
> >> James Kanze wrote:
> >>> On May 30, 12:29 pm, Ian Collins <> 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.

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 wrote:
> On Jun 1, 2:44 am, Ian Collins <> 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.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!