Re[6]: вектор и границы
От: jazzer Россия Skype: enerjazzer
Дата: 29.09.05 19:20
Оценка: 1 (1) +2 :)
Здравствуйте, GregZ, Вы писали:

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


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


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


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


Значит, говоришь, если у класса нет виртуального деструктора, от него нельзя наследоваться?
Сейчас я тебя напугаю.
Лучше сразу сядь, прежде чем читать то, что я сейчас напишу.

Если ты внимательно посмотришь в Стандарт в части STL — ты увидишь множество случаев наследования БЕЗ виртуального деструктора в базовом классе.

Например, классы std::unary_function и std::binary_function не содержат виртуальных деструкторов.
Тем не менее, всякие std::plus, std::equal_to и прочие функторы, биндеры и адаптеры от них успешно наследуются публичным образом.

Та же ситуация с тегами итераторов (24.3.3/1).
namespace std {
     struct input_iterator_tag {};
     struct output_iterator_tag {};
     struct forward_iterator_tag: public input_iterator_tag {};
     struct bidirectional_iterator_tag: public forward_iterator_tag {};
     struct random_access_iterator_tag: public bidirectional_iterator_tag {};
}


Более того, все то же самое происходит и с самими итераторами (24.4.1.1) и инсертерами (24.4.2.1):
class reverse_iterator : public iterator


Хуже того, они сами и рекомендуют наседоваться от этого ужасного класса без виртуального деструктора:
24.3.3/4 [Example: If a C++ program wants to define a bidirectional iterator for some data structure containing
double and such that it works on a large memory model of the implementation, it can do so with:

class MyIterator :
   public iterator<bidirectional_iterator_tag, double, long, T*, T&> {
                                // code implementing ++, etc.
};
Then there is no need to specialize the iterator_traits template. —end example]


Так что опасность открытого наследования без виртуального деструктора очень сильно преувеличена :)
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
вектор и границы
От: Tom Россия http://www.RSDN.ru
Дата: 29.09.05 10:00
Оценка: +1 :))
Вот сижу делаю ревью чужого кода:

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));
    }
};


Как вам такое? Я вот думаю как бы помягче обьяснить человеку, что он не прав.
Народная мудрось
всем все никому ничего(с).
Re[3]: вектор и границы
От: Elich  
Дата: 29.09.05 16:59
Оценка: 7 (1) -1
Tom>Ты имеешь ввиду отправить рассматривать std::vector? Или книжку отправить читать?

Книжки, конечно, нужно отправить читать. Но в книжках не написано, как лучше поступить конкретно в данной ситуцаии — для этого уже нужен опыт. Потому посадить за монитор рядом с собой, и дать этот опыт — показать, как бы реализация данной задачи выглядела лучше. И почему лучше.
Re[2]: вектор и границы
От: Глеб Алексеев  
Дата: 29.09.05 10:14
Оценка: 1 (1) +1
Здравствуйте, Нахлобуч, Вы писали:

Н>А с каких пор разрешено наследоваться от std::vector?

А с каких пор запрещено?
ИМХО, опасность удаления наследника стандартного контейнера через указатель на базовый класс несколько преувеличена, хоть Майерсы с Саттерами любят в нее носом тыкать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: вектор и границы
От: jazzer Россия Skype: enerjazzer
Дата: 29.09.05 18:39
Оценка: +1 :)
Здравствуйте, eao197, Вы писали:

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


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


Судя по названию класса SafeVector это не тот случай :)
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: вектор и границы
От: rus blood Россия  
Дата: 29.09.05 10:04
Оценка: +1
Здравствуйте, Tom, Вы писали:

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


Без контекста использования нельзя сказать, прав он или нет.
Может требуется такая логика работы, извращенная...
Имею скафандр — готов путешествовать!
Re[9]: вектор и границы
От: Centaur Россия  
Дата: 29.09.05 17:08
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>Я делал примерно такую штуку, когда меня совсем достало. Возвращал объект, который на все вопросы отвечал exception. Логика такого требовала, нужна была только ссылка.


А вот это уже pattern Null Object.
Re[8]: вектор и границы
От: leper Россия  
Дата: 30.09.05 06:38
Оценка: +1
GregZ wrote:

> Обобщу: *(если что понял неправильно, поправьте)*

> Отсутствие виртуального деструктора в стандартных контейнерах говорит о
> том, что их классы *не* предполагается использовать как полиморфные

Точнее, не предполагается *полиморфное удаление* данных классов.
Posted via RSDN NNTP Server 2.0 beta
Think for yourself. Question authory.
Re: вектор и границы
От: srggal Украина  
Дата: 29.09.05 10:05
Оценка:
Здравствуйте, Tom, Вы писали:

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


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


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

vector::at()


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

Впрочем как и все представители этого вида спорта
... << RSDN@Home 1.1.4 stable rev. 510>>
Re: вектор и границы
От: Нахлобуч Великобритания https://hglabhq.com
Дата: 29.09.05 10:07
Оценка:
Здравствуйте, Tom, Вы писали:

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


А с каких пор разрешено наследоваться от std::vector? Уж пусть пишет контейнерный адаптер тогда. Как std::stack, например.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
HgLab: Mercurial Server and Repository Management for Windows
Re: вектор и границы
От: Glоbus Украина  
Дата: 29.09.05 10:08
Оценка:
Здравствуйте, 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().
Удачи тебе, браток!
Re: вектор и границы
От: Глеб Алексеев  
Дата: 29.09.05 10:09
Оценка:
Здравствуйте, Tom, Вы писали:

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


Намекнуть на существование метода at?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: вектор и границы
От: ssm Россия  
Дата: 29.09.05 10:24
Оценка:
Здравствуйте, Tom, Вы писали:


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


ИМХО название "SafeVector" выбрано неудачно для данной концепции. А вообще стоило бы показать как сие используется. Если как повсеместная замена std::vector, то однозначно — зло. А если как вариант Элджеровской хромающей лошадки, то почему бы и нет?
Re[2]: вектор и границы
От: Tom Россия http://www.RSDN.ru
Дата: 29.09.05 10:27
Оценка:
Здравствуйте, rus blood, Вы писали:

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


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


RB>Без контекста использования нельзя сказать, прав он или нет.

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

Применяется он вместо вектора, например так:
return m_mCells[nChildID][nLookupID][nCell-1].m_nAchieved;
Народная мудрось
всем все никому ничего(с).
Re[3]: вектор и границы
От: GregZ СССР  
Дата: 29.09.05 10:59
Оценка:
Здравствуйте, Глеб Алексеев, Вы писали:

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


Н>>А с каких пор разрешено наследоваться от std::vector?

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

Т.е. для вас вполне приемлемо создать собственный контейнер, открыто наследуясь от какого-либо стандартного контейнера?
Re[4]: вектор и границы
От: Анатолий Широков СССР  
Дата: 29.09.05 11:02
Оценка:
GZ>Т.е. для вас вполне приемлемо создать собственный контейнер, открыто наследуясь от какого-либо стандартного контейнера?

Простите, а кто Вам внушил обратное — то есть, что это делать нельзя?
Re[4]: вектор и границы
От: _DAle_ Беларусь  
Дата: 29.09.05 11:08
Оценка:
Здравствуйте, GregZ, Вы писали:

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


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


Н>>>А с каких пор разрешено наследоваться от std::vector?

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

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


Вот, например, мнение двухлетней давности Андрея Тарасевича.
http://www.rsdn.ru/Forum/Message.aspx?mid=421616&amp;only=1
Автор: Андрей Тарасевич
Дата: 25.10.03
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[5]: вектор и границы
От: GregZ СССР  
Дата: 29.09.05 11:10
Оценка:
Здравствуйте, Анатолий Широков, Вы писали:

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


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


По-моему отсутствие виртуального деструктора у стандартных контейнеров говорит об этом достаточно красноречиво.
Re[6]: вектор и границы
От: Анатолий Широков СССР  
Дата: 29.09.05 11:12
Оценка:
GZ>По-моему отсутствие виртуального деструктора у стандартных контейнеров говорит об этом достаточно красноречиво.

А Вы что, будете удалять вектор полиморфно, то есть через базу? Хм.
Re[7]: вектор и границы
От: GregZ СССР  
Дата: 29.09.05 11:14
Оценка:
Здравствуйте, Анатолий Широков, Вы писали:

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

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

Я — скорее всего не буду.
Сторонний человек использующий мой контейнер — вполне вероятно.
Re[8]: вектор и границы
От: Анатолий Широков СССР  
Дата: 29.09.05 11:16
Оценка:
GZ>Я — скорее всего не буду.
GZ>Сторонний человек использующий мой контейнер — вполне вероятно.

Но это не повод отказываться от наследования.
Re[9]: вектор и границы
От: GregZ СССР  
Дата: 29.09.05 11:22
Оценка:
Здравствуйте, Анатолий Широков, Вы писали:

GZ>>Я — скорее всего не буду.

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

Интересное мнение. Я конечно не параноик, но предпочитаю перестраховываться.
Может тогда кто объяснит мне почему же нет таки виртуальных деструкторов у стандартных контейнеров?
Re[3]: вектор и границы
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.05 11:25
Оценка:
Здравствуйте, Tom, Вы писали:

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


RB>>Без контекста использования нельзя сказать, прав он или нет.

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

Tom>Применяется он вместо вектора, например так:

Tom>return m_mCells[nChildID][nLookupID][nCell-1].m_nAchieved;

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

Может быть и здесь "попадания в молоко" по алгоритму вполне допустимы?
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: вектор и границы
От: Анатолий Широков СССР  
Дата: 29.09.05 11:31
Оценка:
GZ>Интересное мнение. Я конечно не параноик, но предпочитаю перестраховываться.
GZ>Может тогда кто объяснит мне почему же нет таки виртуальных деструкторов у стандартных контейнеров?

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


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


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

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

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

Так зачем же вектору виртуальный деструктор?
Re[4]: вектор и границы
От: Tom Россия http://www.RSDN.ru
Дата: 29.09.05 11:42
Оценка:
E>Может быть и здесь "попадания в молоко" по алгоритму вполне допустимы?
Автор кода сказал, что это только для защиты сделано
Народная мудрось
всем все никому ничего(с).
Re[5]: вектор и границы
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.05 11:51
Оценка:
Здравствуйте, Tom, Вы писали:

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

Tom>Автор кода сказал, что это только для защиты сделано

Тогда можно у него поинтересоваться, как он гарантирует корректность приложения во для этого оператора:
std::vector<Item>::const_reference operator[](
        std::vector<Item>::size_type Index) const
{
        if (Index < 0 || Index >= size())
                return m_FakeItem;
        return (*(begin() + Index));
}


Фактически же он подсовывает мусор, который затем где-нибудь обязательно даст себя знать.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: вектор и границы
От: igna Россия  
Дата: 29.09.05 11:57
Оценка:
Здравствуйте, Нахлобуч, Вы писали:

Н>А с каких пор разрешено наследоваться от std::vector?


Если в наследующем классе не определять нестатических переменных и виртуальных функций, какие проблемы могут возникнуть?
Re[11]: вектор и границы
От: srggal Украина  
Дата: 29.09.05 12:01
Оценка:
Здравствуйте, Анатолий Широков, Вы писали:


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


Имеем холиварс, причем несколько параноидальный (стороны) и более прагматичный с другой

Позволю напомнить, что в С++ принято не платить за то, что не используешь.

Cоотвественно, нет виртуальных деструкторов в контейнерах STL, если нужен — делай в своем классе, хоть бы он и потомок контейнера ИМХО.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[3]: вектор и границы
От: Bell Россия  
Дата: 29.09.05 12:13
Оценка:
Здравствуйте, igna, Вы писали:

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


Н>>А с каких пор разрешено наследоваться от std::vector?


I>Если в наследующем классе не определять нестатических переменных и виртуальных функций, какие проблемы могут возникнуть?


Да так, мелочи всякие...

5.3.5/3
In the first alternative (delete object), if the static type of the operand is 
different from its dynamic type, the static type shall be a base class of the 
operand’s dynamic type and the static type shall have a virtual destructor or 
the behavior is undefined.
Любите книгу — источник знаний (с) М.Горький
Re[4]: вектор и границы
От: igna Россия  
Дата: 29.09.05 12:37
Оценка:
Здравствуйте, Bell, Вы писали:

B>
B>5.3.5/3
B>In the first alternative (delete object), if the static type of the operand is 
B>different from its dynamic type, the static type shall be a base class of the 
B>operand’s dynamic type and the static type shall have a virtual destructor or 
B>the behavior is undefined.
B>


Действительно так написано.

И все же, если наследующий класс не добавляет нестатических переменных, а также не определяет виртуальных функций и деструктора, есть реальные причины не требовать определенного поведения? Может быть стандарт подправить, а компиляторы даже переделывать не придется?
Re[5]: вектор и границы
От: Bell Россия  
Дата: 29.09.05 13:13
Оценка:
Здравствуйте, igna, Вы писали:

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


B>>
B>>5.3.5/3
B>>In the first alternative (delete object), if the static type of the operand is 
B>>different from its dynamic type, the static type shall be a base class of the 
B>>operand’s dynamic type and the static type shall have a virtual destructor or 
B>>the behavior is undefined.
B>>


I>Действительно так написано.


I>И все же, если наследующий класс не добавляет нестатических переменных, а также не определяет виртуальных функций и деструктора, есть реальные причины не требовать определенного поведения?

К примеру:

#include <iostream>

using namespace std;

struct base
{
   //virtual ~base() {}
};


class d : public base
{
public:
   static void* operator new(size_t sz);
   static void  operator delete(void* ptr, size_t sz);
};

void* d::operator new(size_t sz)
{
   cout << "d::new" << endl;
   //Возможно, своя хитрая реализация
   return ::operator new(sz);
}

void d::operator delete(void* ptr, size_t sz)
{
   cout << "d::delete" << endl;
   //Возможно, своя хитрая реализация
   ::operator delete(ptr);
}


int main () 
{
   base* pb = new d();
   delete pb;

   return 0;
}


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

Может быть стандарт подправить, а компиляторы даже переделывать не придется?
Напиши formal proposal
Любите книгу — источник знаний (с) М.Горький
Re[6]: вектор и границы
От: Tom Россия http://www.RSDN.ru
Дата: 29.09.05 13:15
Оценка:
E>Фактически же он подсовывает мусор, который затем где-нибудь обязательно даст себя знать.
Ничего он не гарантирует, ди оно и падает
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Народная мудрось
всем все никому ничего(с).
Re[7]: вектор и границы
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.09.05 13:48
Оценка:
Здравствуйте, Tom, Вы писали:

E>>Фактически же он подсовывает мусор, который затем где-нибудь обязательно даст себя знать.

Tom>Ничего он не гарантирует, ди оно и падает

Ну так и скажи: "Господин хороший, ваши гарантии безопасности, как оказалось, ничего не гарантируют. Так позвольте вас спросить -- какого <здесь подставляется любое слово, хорошо отражающее степень твоего недоумения> вся эта ерунда (слово ерунда вполне возможно заменить на соответствующий нецензурный аналог) здесь делает?"
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: вектор и границы
От: Аноним  
Дата: 29.09.05 14:12
Оценка:
Здравствуйте, GregZ, Вы писали:

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


GZ>>>Я — скорее всего не буду.

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

GZ>Интересное мнение. Я конечно не параноик, но предпочитаю перестраховываться.

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

Насколько я понимаю, это сделано по той же причине, по которой у контейнеров нет общего базового класса. Т.е: иерархии контейнерных классов — зло, программист всегда должен четко понимать с каким контейнером он работатет и тогда он вегда будет знать сколько стоит та или иная операция с ним.
Re: вектор и границы
От: _Winnie Россия C++.freerun
Дата: 29.09.05 14:46
Оценка:
Здравствуйте, Tom, Вы писали:

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


У нас похожее чудо используется


namespace   std
{
template <class T, class A>
class OurVector
{
};

}

#define vector OurVector


Сделан был для того, что бы унифицированно использовать старый рукопсиный унаследованный вектор с std::vector, +понаставлены ассерты, +немного оптимизирован под наш менеджер памяти, +переносит объекты по памяти memcpy вместо , new(NewPlace) T(Old), Old->~T(), выкинута вся excepetion safity.
Правильно работающая программа — просто частный случай Undefined Behavior
Re[11]: вектор и границы
От: Tom Россия http://www.RSDN.ru
Дата: 29.09.05 15:42
Оценка:
АШ>Я далек от мысли, что все стандартные контейнеры вы используете по следующей схеме:
Мне намного сложнее читать код, находящийся внутри отнасдедованного от контейнера класса, так как народ у нас
наследуется от контейнера и пишет свои бизнес классы — не контейнеры, правда слава богу такой один (человек), а не все
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Народная мудрось
всем все никому ничего(с).
Re[12]: вектор и границы
От: srggal Украина  
Дата: 29.09.05 15:59
Оценка:
Здравствуйте, Tom, Вы писали:

Tom>наследуется от контейнера и пишет свои бизнес классы — не контейнеры, правда слава богу такой один (человек), а не все


А вот это уже профанация, это не правильно ИМХО.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re: вектор и границы
От: Elich  
Дата: 29.09.05 16:25
Оценка:
Tom> Я вот думаю как бы помягче обьяснить человеку, что он не прав.

Наиболее гуманным кажется предложение альтернативной реализации и демонстрация ее преимуществ. Но не укор.
Re[8]: вектор и границы
От: GlebZ Россия  
Дата: 29.09.05 16:48
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ну так и скажи: "Господин хороший, ваши гарантии безопасности, как оказалось, ничего не гарантируют. Так позвольте вас спросить -- какого <здесь подставляется любое слово, хорошо отражающее степень твоего недоумения> вся эта ерунда (слово ерунда вполне возможно заменить на соответствующий нецензурный аналог) здесь делает?"


Я делал примерно такую штуку, когда меня совсем достало. Возвращал объект, который на все вопросы отвечал exception. Логика такого требовала, нужна была только ссылка.

С уважением, Gleb.
Re[2]: вектор и границы
От: Tom Россия http://www.RSDN.ru
Дата: 29.09.05 16:51
Оценка:
E>Наиболее гуманным кажется предложение альтернативной реализации и демонстрация ее преимуществ. Но не укор.
Ты имеешь ввиду отправить рассматривать std::vector? Или книжку отправить читать?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Народная мудрось
всем все никому ничего(с).
Re[2]: вектор и границы
От: Аноним  
Дата: 29.09.05 17:35
Оценка:
Здравствуйте, _Winnie, Вы писали:

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


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


_W>У нас похожее чудо используется


_W>

_W>namespace   std
_W>{
_W>template <class T, class A>
_W>class OurVector
_W>{
_W>};

_W>}

_W>#define vector OurVector
_W>


_W>Сделан был для того, что бы унифицированно использовать старый рукопсиный унаследованный вектор с std::vector, +понаставлены ассерты, +немного оптимизирован под наш менеджер памяти, +переносит объекты по памяти memcpy вместо , new(NewPlace) T(Old), Old->~T(), выкинута вся excepetion safity.


блин, это же труба. у нас тоже свой вектор, т.к. проект начинался в 93ем, но до такого слава Богу не доходит.
Re[6]: вектор и границы
От: Аноним  
Дата: 29.09.05 19:19
Оценка:
Сдаюсь.

Проблема следующая:
Две специализации basic_string отличающиеся только типом аллокатора, то есть basic_string<Ch, Tr, A1> и basic_string<Ch, Tr, A2> нельзя присваивать друг другу, конструировать друг из друга и так далее. Определил свой производный от basic_string шаблон класса (назовем его к примеру my_basic_string), который можно использовать везде, где можно использовать basic_string, и который к тому же разрешает присваивание my_basic_string<Ch, Tr, A1> и my_basic_string<Ch, Tr, A2> друг другу и прочее. Но у basic_string деструктор невиртуален ...

В my_basic_string переопределены все конструкторы basic_string и (невиртуальные) функции basic_string принимающие аргумент типа basic_string, больше там нет ничего.
Re[7]: вектор и границы
От: igna Россия  
Дата: 29.09.05 19:23
Оценка:
Это был я, igna.
Re[7]: вектор и границы
От: GregZ СССР  
Дата: 30.09.05 05:34
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Если ты внимательно посмотришь в Стандарт в части STL — ты увидишь множество случаев наследования БЕЗ виртуального деструктора в базовом классе.

...<выцарапано>...
J>Так что опасность открытого наследования без виртуального деструктора очень сильно преувеличена

Хорошо, будем считать убедили, хотя я и большой сторонник всяческих догм и правил.
Введу корректировку.

Обобщу: (если что понял неправильно, поправьте)
Отсутствие виртуального деструктора в стандартных контейнерах говорит о том, что их классы не предполагается использовать как полиморфные, но при этом не запрещается открыто от них наследоваться (с учетом того, что и дальше будет использоваться эта парадигма). Одним из плюсов является отсутствие таблицы vptr, за которую не приходится переплачивать дополнительно расходуемой памятью. При этом предполагается что пользователь производного контейнера знает об этой специфике.
Re[10]: вектор и границы
От: srggal Украина  
Дата: 30.09.05 07:16
Оценка:
Здравствуйте, Centaur, Вы писали:

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


GZ>>Я делал примерно такую штуку, когда меня совсем достало. Возвращал объект, который на все вопросы отвечал exception. Логика такого требовала, нужна была только ссылка.


C>А вот это уже pattern Null Object.


ИМХО: знание паттернов, не освобождает от ответственности за их применение, какой-бы это ни был паттерн

pattern Null Object


или pattern Moc-reference (название собственное, шутливое, искаьт доку по этому паттерну не стоит )
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[9]: вектор и границы
От: srggal Украина  
Дата: 30.09.05 07:42
Оценка:
Здравствуйте, leper, Вы писали:

L>GregZ wrote:


L>Точнее, не предполагается *полиморфное удаление* данных классов.


А если уточнить, под термином

*полиморфное удаление*


Понимается

    int    *pFoo    = new int(0);
        ...
    delete pFoo;


что зачастую означает то, что потомки таких классов — не должны производить каких-либо динамических распределений памяти, освобождение которой потребуется в деструкторе; либо, в свою очередь, сами потомки никогда не создаются динамически (поэтому и не требуется их "полиморфное удаление".

тема избитая, пример:

#include "stdafx.h"

struct foo
{
    foo()
    {
        std::cout << __FUNCTION__ << std::endl;
    }

    ~foo()
    {
        std::cout << __FUNCTION__ << std::endl;
    }
};

struct bar
    :    public    foo
{
    bar()
    {
        std::cout << __FUNCTION__ << std::endl;
    }

    virtual ~bar()
    {
        std::cout << __FUNCTION__ << std::endl;
    }
};

struct poly_foo
{
    poly_foo()
    {
        std::cout << __FUNCTION__ << std::endl;
    }

    virtual ~poly_foo()
    {
        std::cout << __FUNCTION__ << std::endl;
    }
};

struct poly_bar
    :    public    poly_foo
{
    poly_bar()
    {
        std::cout << __FUNCTION__ << std::endl;
    }

    virtual ~poly_bar()
    {
        std::cout << __FUNCTION__ << std::endl;
    }
};


int _tmain(int argc, _TCHAR* argv[])
{
    {
        std::cout << " ------- Test bar ------- " << std::endl;
        foo    *pFoo_ = new bar;
        delete pFoo_;
    }

    {
        std::cout << " ------- Test poy_bar  ------- " << std::endl;

        poly_foo    *pFoo_ = new poly_bar;
        delete pFoo_;
    }

    return 0;
}


ИМХО: необдуманное следование догмам — есть фанатизм, который зло, по своей сути, и этого следует избегать, путем обдумывания догм, и принития оных через осмысление.

ЗЫ: Во я загнул
... << RSDN@Home 1.1.4 stable rev. 510>>
Re: вектор и границы
От: Serpent_T.B.  
Дата: 30.09.05 12:24
Оценка:
Здравствуйте, Tom, Вы писали:

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

...

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



Такой контейнер, конечно, неплохо использовать с целью скорее не для проверки диапазона, а для экономии ресурсов — в случае, если выполняется много обращений на чтение елементов
const_reference []()
за пределами массива. ssm и eao197 об этом уже сказали, но есть один ньюанс (чуть ниже). И опять же — тогда не "SafeVector". Иначе — действительно at().


IMHO, если чтобы не обидеть, нужно ему обьяснить, что надо переписать реализацию НЕконстантного оператора [] (Пока в m_FakeItem ничего не пишем — конечно, всё и так работает неплохо )

Т.е., сделать что-то вроде copy-on-write — при вызове НЕконстантного оператора [] расширять и заполнять вектор до указанного индекса m_FakeItem'ами.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.