Вот сижу делаю ревью чужого кода:

template <class Item>
class SafeVector : public std::vector<Item>
{
    static Item m_FakeItem;
public:
    std::vector<Item>::const_reference operator[](
        std::vector<Item>::size_type Index) const
    {
        if (Index < 0 || Index >= size())
            return m_FakeItem;
        return (*(begin() + Index));
    }
    std::vector<Item>::reference operator[](
        std::vector<Item>::size_type Index)
    {
        if (Index < 0 || Index >= size())
            return m_FakeItem;
        return (*(begin() + Index));
    }
};

Как вам такое? Я вот думаю как бы помягче обьяснить человеку, что он не прав.

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

Tom>Как вам такое? Я вот думаю как бы помягче обьяснить человеку, что он не прав.

Без контекста использования нельзя сказать, прав он или нет.
Может требуется такая логика работы, извращенная...

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

Tom>Вот сижу делаю ревью чужого кода:

Tom>Я вот думаю как бы помягче обьяснить человеку, что он не прав.

Обяснить, что есть

vector::at()

только и всего, невооруженным газом видно, что велосипедист хотел сделать как лучше

Впрочем как и все представители этого вида спорта

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

Tom>Как вам такое? Я вот думаю как бы помягче обьяснить человеку, что он не прав.

А с каких пор разрешено наследоваться от std::vector? Уж пусть пишет контейнерный адаптер тогда. Как std::stack, например.

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

Tom>Вот сижу делаю ревью чужого кода:

Tom>

Tom>template <class Item>
Tom>class SafeVector : public std::vector<Item>
Tom>{
Tom>    static Item m_FakeItem;
Tom>public:
Tom>    std::vector<Item>::const_reference operator[](
Tom>        std::vector<Item>::size_type Index) const
Tom>    {
Tom>        if (Index < 0 || Index >= size())
Tom>            return m_FakeItem;
Tom>        return (*(begin() + Index));
Tom>    }
Tom>    std::vector<Item>::reference operator[](
Tom>        std::vector<Item>::size_type Index)
Tom>    {
Tom>        if (Index < 0 || Index >= size())
Tom>            return m_FakeItem;
Tom>        return (*(begin() + Index));
Tom>    }
Tom>};
Tom>

Tom>Как вам такое? Я вот думаю как бы помягче обьяснить человеку, что он не прав.

Да очень просто — получается, что даже если пользователь класса указал недопустимый индекс, он все равно получит вполне валидное значение из вектора. И кому такое надо? Уж лучше бы эксепшин кидал. Далее — еще не хватает второго параметра шаблона — аллокатора для вектора — тоже хорошо бы ввести. Ну и так как operator[] не виртуальный, то при передаче по указателю на базовый класс объекта этого типа код будет неправильно работать.
А вообще — специально для этого есть метод at() — он кидает исключение std::out_of_range().

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

Tom>Как вам такое? Я вот думаю как бы помягче обьяснить человеку, что он не прав.

Намекнуть на существование метода at?

Здравствуйте, Нахлобуч, Вы писали:

Н>А с каких пор разрешено наследоваться от std::vector?
А с каких пор запрещено?
ИМХО, опасность удаления наследника стандартного контейнера через указатель на базовый класс несколько преувеличена, хоть Майерсы с Саттерами любят в нее носом тыкать.

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


Tom>Как вам такое? Я вот думаю как бы помягче обьяснить человеку, что он не прав.

ИМХО название "SafeVector" выбрано неудачно для данной концепции. А вообще стоило бы показать как сие используется. Если как повсеместная замена std::vector, то однозначно — зло. А если как вариант Элджеровской хромающей лошадки, то почему бы и нет?

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

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

Tom>>Как вам такое? Я вот думаю как бы помягче обьяснить человеку, что он не прав.

RB>Без контекста использования нельзя сказать, прав он или нет.
RB>Может требуется такая логика работы, извращенная...

Применяется он вместо вектора, например так:
return m_mCells[nChildID][nLookupID][nCell-1].m_nAchieved;

Здравствуйте, Глеб Алексеев, Вы писали:

ГА>Здравствуйте, Нахлобуч, Вы писали:

Н>>А с каких пор разрешено наследоваться от std::vector?
ГА>А с каких пор запрещено?
ГА>ИМХО, опасность удаления наследника стандартного контейнера через указатель на базовый класс несколько преувеличена, хоть Майерсы с Саттерами любят в нее носом тыкать.

Т.е. для вас вполне приемлемо создать собственный контейнер, открыто наследуясь от какого-либо стандартного контейнера?

GZ>Т.е. для вас вполне приемлемо создать собственный контейнер, открыто наследуясь от какого-либо стандартного контейнера?

Простите, а кто Вам внушил обратное — то есть, что это делать нельзя?

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

GZ>Здравствуйте, Глеб Алексеев, Вы писали:

ГА>>Здравствуйте, Нахлобуч, Вы писали:

Н>>>А с каких пор разрешено наследоваться от std::vector?
ГА>>А с каких пор запрещено?
ГА>>ИМХО, опасность удаления наследника стандартного контейнера через указатель на базовый класс несколько преувеличена, хоть Майерсы с Саттерами любят в нее носом тыкать.

GZ>Т.е. для вас вполне приемлемо создать собственный контейнер, открыто наследуясь от какого-либо стандартного контейнера?

Вот, например, мнение двухлетней давности Андрея Тарасевича.
http://www.rsdn.ru/Forum/Message.aspx?mid=421616&only=1

Автор: Андрей Тарасевич
Дата: 25.10.03

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

GZ>>Т.е. для вас вполне приемлемо создать собственный контейнер, открыто наследуясь от какого-либо стандартного контейнера?

АШ>Простите, а кто Вам внушил обратное — то есть, что это делать нельзя?

По-моему отсутствие виртуального деструктора у стандартных контейнеров говорит об этом достаточно красноречиво.

GZ>По-моему отсутствие виртуального деструктора у стандартных контейнеров говорит об этом достаточно красноречиво.

А Вы что, будете удалять вектор полиморфно, то есть через базу? Хм.

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

GZ>>По-моему отсутствие виртуального деструктора у стандартных контейнеров говорит об этом достаточно красноречиво.
АШ>А Вы что, будете удалять вектор полиморфно, то есть через базу? Хм.

Я — скорее всего не буду.
Сторонний человек использующий мой контейнер — вполне вероятно.

GZ>Я — скорее всего не буду.
GZ>Сторонний человек использующий мой контейнер — вполне вероятно.

Но это не повод отказываться от наследования.

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

GZ>>Я — скорее всего не буду.
GZ>>Сторонний человек использующий мой контейнер — вполне вероятно.
АШ>Но это не повод отказываться от наследования.

Интересное мнение. Я конечно не параноик, но предпочитаю перестраховываться.
Может тогда кто объяснит мне почему же нет таки виртуальных деструкторов у стандартных контейнеров?

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

Tom>>>Как вам такое? Я вот думаю как бы помягче обьяснить человеку, что он не прав.

RB>>Без контекста использования нельзя сказать, прав он или нет.
RB>>Может требуется такая логика работы, извращенная...

Tom>Применяется он вместо вектора, например так:
Tom>return m_mCells[nChildID][nLookupID][nCell-1].m_nAchieved;

Вот здесь

Автор: eao197
Дата: 09.06.05

я описывал задачку по решению СЛАУ большой размерности. Так для ее решения я как раз использовал подобный фокус. И он был оправдан тем, что в определенные ячейки матрицы всегда помещались нули. Эти нули получались в результате каких-то хитрых расчетов и никогда затем не использовались. В таких условиях проще было позволить писать в "молоко", чем преобразовывать сложный алгоритм первоначального заполнения матрицы.

Может быть и здесь "попадания в молоко" по алгоритму вполне допустимы?

GZ>Интересное мнение. Я конечно не параноик, но предпочитаю перестраховываться.
GZ>Может тогда кто объяснит мне почему же нет таки виртуальных деструкторов у стандартных контейнеров?

Я далек от мысли, что все стандартные контейнеры вы используете по следующей схеме:

std::vector<int> *ptr = new std::vector<int>(10, 1);
...
(*ptr)[1] = 10;
...
delete ptr;

А все таки предпочитаете более привычную:

std::vector<int> arr(10, 1);
...

и ни о каком удалении не задумываетесь.

Так зачем же вектору виртуальный деструктор?

E>Может быть и здесь "попадания в молоко" по алгоритму вполне допустимы?
Автор кода сказал, что это только для защиты сделано