Re[5]: vector<int> = int - C/C++

Возможно ли такое?

typedef vector<int> mytype;

mytype& operator=(mytype& a; int b)
{
  a.clear();
  a.push_back(b);
  return a;
}

int main()
{
  mytype a = 2;
  assert(a.size() == 1);
  assert(a[0] == 2);
  return 0;
}

Код конечно не компилируется.

Здравствуйте, Tan4ik, Вы писали:

T>Возможно ли такое?

T>

T>typedef vector<int> mytype;

T>mytype& operator=(mytype& a; int b)//Может запятая?
T>{
T>  a.clear();
T>  a.push_back(b);
T>  return a;
T>}

T>int main()
T>{
T>  mytype a = 2;//Конструктор копии, но никак не operator =()
T>  assert(a.size() == 1);
T>  assert(a[0] == 2);
T>  return 0;
T>}
T>

T>Код конечно не компилируется.
Ничего удивительного.

Здравствуйте, Tan4ik, Вы писали:

T>Возможно ли такое?

T>

T>typedef vector<int> mytype;

T>mytype& operator=(mytype& a; int b)
T>{
T>  a.clear();
T>  a.push_back(b);
T>  return a;
T>}

T>int main()
T>{
T>  mytype a = 2;
T>  assert(a.size() == 1);
T>  assert(a[0] == 2);
T>  return 0;
T>}
T>

T>Код конечно не компилируется.

угу. operator= обязан быть мембером

Здравствуйте, Bell, Вы писали:

Да и operator = () должен быть членом класса.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Здравствуйте, Tan4ik, Вы писали:

T>>Возможно ли такое?

T>>

T>>typedef vector<int> mytype;

T>>mytype& operator=(mytype& a; int b)
T>>{
T>>  a.clear();
T>>  a.push_back(b);
T>>  return a;
T>>}

T>>int main()
T>>{
T>>  mytype a = 2;
T>>  assert(a.size() == 1);
T>>  assert(a[0] == 2);
T>>  return 0;
T>>}
T>>

T>>Код конечно не компилируется.

ЗХ>угу. operator= обязан быть мембером

Или friend-ом. И объявлять надо оператор для каждого типа справа

Здравствуйте, Tan4ik, Вы писали:

T>int main()
T>{
T> mytype a = 2;
T> assert(a.size() == 1);
T> assert(a[0] == 2);
T> return 0;
T>}
T>[/ccode]

T>Код конечно не компилируется.

Вдобавок ко всем прозвучавшим пинкам добавлю свои 5 копеек:

в инструкции

T>  mytype a = 2;

происходит не вызова operator=, а вызов конструктора.
Если хочешь, чтобы вызывался operator=, пиши так

mytype a;
a = 2;

А вообще, если тебе нужна подобная функциональность, то используй не std::vector, а std::valarray (мне показалось, что он больше подойдет к твоим неозвученным нуждам)

Здравствуйте, Tan4ik, Вы писали:

T>Возможно ли такое?

Да.

T>typedef vector<int> mytype;

T>int main()
T>{
T>  mytype a(1, 2);
T>  assert(a.size() == 1);
T>  assert(a[0] == 2);
T>  return 0;
T>}

Здравствуйте, jazzer, Вы писали:

J>Вдобавок ко всем прозвучавшим пинкам добавлю свои 5 копеек:

J>в инструкции
J>

T>>  mytype a = 2;
J>

J>происходит не вызова operator=, а вызов конструктора.

Я об этом говорил

J>А вообще, если тебе нужна подобная функциональность, то используй не std::vector, а std::valarray (мне показалось, что он больше подойдет к твоим неозвученным нуждам)

Да, наверное.

Здравствуйте, sercher, Вы писали:

ЗХ>>угу. operator= обязан быть мембером

S> Или friend-ом.

Нет, он не может быть friend.

J>А вообще, если тебе нужна подобная функциональность, то используй не std::vector, а std::valarray (мне показалось, что он больше подойдет к твоим неозвученным нуждам)

valarray<T>& operator=(const T& x);
member operator replaces each element of the controlled sequence with a copy of x

resize(1) ему бы сделать предварительно...
Просто фунционатьность vector меня бы вполне устроила. Сейчас написал вот так:

class myclass : public vector<int>
{
public:
    myclass& operator=(int a)
    {
        (*this).assign(1,a);
        return *this;
    }
};

Раскритикуйте если что.

Здравствуйте, Tan4ik, Вы писали:

Контейнеры STL не предназначены для наследования. Лучше используй включение.

Здравствуйте, Bell, Вы писали:

B>Здравствуйте, Tan4ik, Вы писали:

B>Контейнеры STL не предназначены для наследования. Лучше используй включение.

ну, это, ИМХО, для данного случая по-барабану

фраза "Контейнеры STL не предназначены для наследования" означает. что у них нет виртуальных методов, которые можно было бы переопределить в наследнике. а для расширения функциональности паблик-наследование самое оно. а при включении пришлось бы либо делать включенный контейнер паблик-членом. что не есть гут, либо делать обертки ко всем его операциям.

Здравствуйте, Зверёк Харьковский, Вы писали:

B>>Контейнеры STL не предназначены для наследования. Лучше используй включение.

ЗХ>ну, это, ИМХО, для данного случая по-барабану

ЗХ>фраза "Контейнеры STL не предназначены для наследования" означает. что у них нет виртуальных методов,

На практике она означает, что Вы получили еще одну возможность достичь неопределенного поведения без диагностики со стороны компилятора.

Здравствуйте, Зверёк Харьковский, Вы писали:

B>>Контейнеры STL не предназначены для наследования. Лучше используй включение.

ЗХ>ну, это, ИМХО, для данного случая по-барабану
В данном да. Но ИМХО всегда следует придеживаться определенных правил. При программировании на С++ самодисциплина играет далеко не самую последнюю роль.

ЗХ>фраза "Контейнеры STL не предназначены для наследования" означает. что у них нет виртуальных методов, которые можно было бы переопределить в наследнике.
В том числе у них нет виртуального деструктора.

ЗХ>...а для расширения функциональности паблик-наследование самое оно.
Спорное утверждение, ну да ладно...

ЗХ>...а при включении пришлось бы либо делать включенный контейнер паблик-членом. что не есть гут,
А это еще зачем?!

ЗХ>...либо делать обертки ко всем его операциям.
Да, интерфейс придется повторить. Это так ужасно?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Зверёк Харьковский, Вы писали:

B>>>Контейнеры STL не предназначены для наследования. Лучше используй включение.

ЗХ>>ну, это, ИМХО, для данного случая по-барабану

ЗХ>>фраза "Контейнеры STL не предназначены для наследования" означает. что у них нет виртуальных методов,

А>На практике она означает, что Вы получили еще одну возможность достичь неопределенного поведения без диагностики со стороны компилятора.

это почему же?

Здравствуйте, Bell, Вы писали:

B>Здравствуйте, Зверёк Харьковский, Вы писали:

B>>>Контейнеры STL не предназначены для наследования. Лучше используй включение.

ЗХ>>ну, это, ИМХО, для данного случая по-барабану
B>В данном да. Но ИМХО всегда следует придеживаться определенных правил. При программировании на С++ самодисциплина играет далеко не самую последнюю роль.

правила — правилами. но для соответствующих задач нужно использовать соответствующие решения.

ЗХ>>фраза "Контейнеры STL не предназначены для наследования" означает. что у них нет виртуальных методов, которые можно было бы переопределить в наследнике.
B>В том числе у них нет виртуального деструктора.

ой. это да. тут ничего не попишешь. тормозю...

ЗХ>>...а для расширения функциональности паблик-наследование самое оно.
B>Спорное утверждение, ну да ладно...

спорное — давай спорить

ЗХ>>...а при включении пришлось бы либо делать включенный контейнер паблик-членом. что не есть гут,
B>А это еще зачем?!

а чтоб обертки не делать

ЗХ>>...либо делать обертки ко всем его операциям.
B>Да, интерфейс придется повторить. Это так ужасно?

когда нужно добавить всего 1 операцию, и ту для прикола, а больше ничего менять не надо, это — не лучшее решение. просто противно, в конце концов. сложность решения должна быть пропорциональна сложности задачи. хотя бы иногда.

Здравствуйте, Зверёк Харьковский, Вы писали:

А>>На практике она означает, что Вы получили еще одну возможность достичь неопределенного поведения без диагностики со стороны компилятора.

ЗХ>это почему же?

Потому, что при открытом наследовании Вы получаете возможность удалять производный объект через указатель на базовый.

ЗХ>>>фраза "Контейнеры STL не предназначены для наследования" означает. что у них нет виртуальных методов, которые можно было бы переопределить в наследнике.
B>>В том числе у них нет виртуального деструктора.
ЗХ>ой. это да. тут ничего не попишешь. тормозю...

И чем это грозит?
Извините за глупые вопросы, я на cpp недавно.

Здравствуйте, Tan4ik, Вы писали:

B>>>В том числе у них нет виртуального деструктора.
ЗХ>>ой. это да. тут ничего не попишешь. тормозю...

T>И чем это грозит?

Неопределенным поведением при удалении через указатель на базовый класс.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Зверёк Харьковский, Вы писали:

А>>>На практике она означает, что Вы получили еще одну возможность достичь неопределенного поведения без диагностики со стороны компилятора.

ЗХ>>это почему же?

А>Потому, что при открытом наследовании Вы получаете возможность удалять производный объект через указатель на базовый.

ну и что?

	От:	Tan4ik
	Дата:	24.10.03 08:01
	Оценка:

	От:	Bell
	Дата:	24.10.03 08:10
	Оценка:

	От:	Зверёк Харьковский
	Дата:	24.10.03 08:13
	Оценка:

	От:	Bell
	Дата:	24.10.03 08:14
	Оценка:

	От:	sercher
	Дата:	24.10.03 08:27
	Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	24.10.03 08:41
Оценка: