Должна ли согласно стандарту компилироваться следующая программа?:
#include <vector>
using namespace std;
int main()
{
int const a[] = { 0, 1, 2, 3 };
vector<int const> v(a, a + 4);
}
Здравствуйте, igna, Вы писали:
I>Должна ли согласно стандарту компилироваться следующая программа?:
I>I>#include <vector>
I>using namespace std;
I>int main()
I>{
I> int const a[] = { 0, 1, 2, 3 };
I> vector<int const> v(a, a + 4);
I>}
I>
По текущему стандарту, тип должен поддерживать присваивание (быть Assignable), int const, очевидно, этому требованию не удовлетворяет.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, jazzer, Вы писали:
J>>По текущему стандарту, тип должен поддерживать присваивание (быть Assignable), int const, очевидно, этому требованию не удовлетворяет.
I>А должен ли компилятор отказываться компилировать такую программу?
В стандарте написано так:
The type of objects stored in these components must meet the requirements of CopyConstructible types (20.1.3), and the additional requirements of Assignable types.
что программа ill-formed, не написано...
Здравствуйте, igna, Вы писали:
I>Здравствуйте, jazzer, Вы писали:
J>>По текущему стандарту, тип должен поддерживать присваивание (быть Assignable), int const, очевидно, этому требованию не удовлетворяет.
I>А должен ли компилятор отказываться компилировать такую программу?
Основываясь _только_ на определении Assignable/CopyConstructible должен компилировать если в месте использования выполняются требования, которые можно проверить на этапе компиляции (т.е. конструктор вектора с диапазоном итераторов приводит к вызову copy конструкторов элементов и т.п.). Но, учитывая тот факт, что типом элемента контейнера параметризируется также и аллокатор:
namespace std {
template <class T, class Allocator = allocator<T> >
class vector {
//...
то 'T' должен удовлетворять требованиям, предъявляемым к его параметру. А здесь ситуация такая:
library defect report #274 a missing/impossible allocator requirement:
I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be of any type. But the synopsis in 20.4.1 calls for allocator<>::address() to be overloaded on reference and const_reference, which is ill-formed for all T = const U. In other words, this won't work:
template class std::allocator<const int>;
...
Rationale:
Two resolutions were originally proposed: one that partially specialized std::allocator for const types, and one that said an allocator's value type may not be const. The LWG chose the second. The first wouldn't be appropriate, because allocators are intended for use by containers, and const value types don't work in containers. Encouraging the use of allocators with const value types would only lead to unsafe code.
The original text for proposed resolution 2 was modified so that it also forbids volatile types and reference types.
