вопрос по шаблонам С++

Slavaga

есть у меня некая структура TMyStruct:
typedef struct TMyStruct
{
int a;
int b;
} tagMyStruct;
в программе используется вектор из этих структур:
vector<TMyStruct> MyStructs;
TMyStruct MyStruct;
MyStruct.a = 120;
MyStruct.b = 150;
MyStructs.push_back(MyStruct);
мне нужно, чтобы в вызове push_back делалась проверка на уникальность добавляемой структуры.
Для этого я переопределил push_back вот так:
namespace std
{
void vector<TMyStruct>::push_back(const TMyStruct & Val)
{
//выполнить проверку на уникальность
//добавить элемент в массив
};
}
вопрос: как избавить себя от написания кода добавления элемента в массив, а запользовать стандартный вариант?

evgen5555

Либо наследовацца, либо insert

stat7984215

Может так:

class TMyStructVector : public vector<TMyStruct>

{

public:

  void push_back(const TMyStruct & Val);

};



void TMyStructVector::push_back(const TMyStruct & Val);

{

  //тут проверка



  vector<TMyStruct>::push_back(Val);

}

?

Realist

1. Не пиши в std. Это черная магия.
2. Наследование — плохой путь. То, что ты делаешь, не есть наследование. Есть принцип, что потомок может всегда использоваться вместо предка (принцип подстановки Лисков). У тебя он нарушен. Например, нарушается инвариант предка, что число элементов после добавления становится на единицу больше.
В качестве же быстрого решения наследование — самое то.
Концептуально правильнее реализовать агрегирование или, на худой конец, закрытое наследование. Получится, что твой массив _реализован_ средствами стандартного (но _не является_ массивом в смысле std::vector). Итак, тебе надо создать свой класс (шаблон? закрытым членом которого является std::vector и перенаправлять все операции, которые ты посчитаешь нужным реализовать, в std::vector.
3. Не стоит использовать магические typedef — это наследие C. Пиши просто
struct TMyStruct
{
int a;
int b;
};
Структура есть класс, у которого по умолчанию все поля (и методы) открыты.

Slavaga

Ок, всем спасибо.

Sebasten

Может тебе всё таки лучше std::set использовать?

tamusyav

+1
Получится более красиво и понятно (естественно, для TMyStruct надо будет определить операцию сравнения).

Ivan8209

> Есть принцип, что потомок может всегда использоваться вместо предка (принцип подстановки Лисков).
> У тебя он нарушен. Например, нарушается инвариант предка, что число элементов после добавления становится на единицу больше.
И что мешает использовать вместо списка (массива, записи) длины N списка (массива, записи) длины N+1?
Про то, что поглючен сам "принцип", можно пока не говорить.
---
"Аллах не ведёт людей неверных."

Realist

И что мешает использовать вместо списка (массива, записи) длины N списка (массива, записи) длины N+1?

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

Про то, что поглючен сам "принцип", можно пока не говорить.

Вот и не говори.

Ivan8209

>> И что мешает использовать вместо списка (массива, записи) длины N списка (массива, записи) длины N+1?
> Я не говорю про неудобства использования списка длины N.
> Я утверждаю, что нарушен принцип и иллюстрирую этот факт.
Если даже и нарушен, ты этого не показал.
При _любом_ нетривиальном наследовании изменяется какой-нибудь инвариант.
>> Про то, что поглючен сам "принцип", можно пока не говорить.
> Вот и не говори.
Пока не буду, про запас отложу.
---
"Аллах не ведёт людей неверных."

Realist

Если даже и нарушен, ты этого не показал.
При _любом_ нетривиальном наследовании изменяется какой-нибудь инвариант.

Ты определись уж, я не показал что нарушен инвариант для операции добавления "при добавлении число элементов увеличивается на единицу"? Или я показал, что инвариант нарушен, но при любом наследовании будет какой-то инвариант нарушен? Или и то и другое?
Да, раз уж ты говоришь про нетривиальное наследование, то позволю себе ремарку: разумный инвариант. Пример неразумного инварианта: sizeof.
Далее, что-то мне подсказывает, что утверждение

При _любом_ нетривиальном наследовании изменяется какой-нибудь инвариант.

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