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

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

C>>>>А ЕСЛИ это не исключение?
C>>>Что "это"? сatch(Exception e) ловит все исключения (т.к. он является базовым классом для классов исключений в дотнет). Не знали об этом?
CC>>Он о том, что запись в лог вызвана не в результате исключения или какой либо ошибки.
C>Какая разница?
Однако.

CC>>Почему то больше всего граблей в С++ видят те, кто на нем либо никогда не писал либо писал очень давно.
C>Наверно потому, что мы кроме С++ видели много более современных и качественных языков, чтоб иметь возможность судить здраво.
Неа.

C>>>Одна из реализаций. Как-там у нее с юникодом, кстати?
CC>>y wstring USC2 100% поддерживается
C>Разницу между std::string и std::wstring улавливаете?

typedef basic_string<char, char_traits<char>, allocator<char> > string;
typedef basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t> > wstring;

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

C>>Во первых переход на личности не показывает вас с лучшей стороны,
C>Где Вы увидели личности?

Сиречь, хамишь ты даже сам не замечая этого. Почему я не удивлён?

C>>во вторых я говорил о вашей цитате Майерса, а не о самой его цитате. То что вы впихнули сюда это, вот что не по существу, не поленитесь написать одинм-двумя предложениями в чём проблема С++ поддержки множественного наследования, а не множественного наследования такогого.
C>Проблема в самой концепции множественного наследования. Множественное наследование, хотя и бывает полезно в некоторых редких случаях, в исключительном большинстве других лишь значительно усложняет дизайн графа классов и создаем тем самым большой потенциал для ошибок дизайна — куда более страшных ошибок, чем большинства других, т.к. рефакторинг и особенно в С++ за неимением нормальных модульных тестов — задача крайне сложная и зачастую просто невыполнимая без тотального переписывания здоровенных участков кода.

Ты забыл добавить, что МН — это такой страшный монстр, который выскакивает из ниоткуда и живёт своей собственной жизнью. Всё смешалось в датском королевстве.

C>>Поймите, что и С++ и Ява поддверживают множественное наследовние как таковое, только вот используют разные методы обхода ловушек, таких как двоиственность, С++ добавляет виртуальное наследование, Ява разрешает наследовать только от одного не абстрактного класса, а все остальные классы должны быть чисто абстрактными (ака интерфейс).
C>Вы не путайте наследование (inheritance) с реализацией (implementation). Так вот интерфейсы не наследуются, а реализуются. А наследование и в С# и в Java есть только одинарное.

Об том, в частности, и речь, что вместо одного полного механизма Java и C# дают кучу обрезков со своими названиями. А потом появляется, то строка — базовый тип, то цикл — базовая конструкция, то linq — foundation всея программирования.

C>>И какой-же геморой вас ждёт, когда интерфейс должен иметь один маленький метод.
C>Что должен делать интерфейс?
C>Сморозили очередную глупость. Интерфейс — это просто контракт.

Интерфейс — это интерфейс. Контракт — гораздо более общая штука.

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

C>>>>>А ЕСЛИ это не исключение?
C>>>>Что "это"? сatch(Exception e) ловит все исключения (т.к. он является базовым классом для классов исключений в дотнет). Не знали об этом?
CC>>>Он о том, что запись в лог вызвана не в результате исключения или какой либо ошибки.
C>>Какая разница?
CC>Однако.
По существу какая разница?

CC>>>Почему то больше всего граблей в С++ видят те, кто на нем либо никогда не писал либо писал очень давно.
C>>Наверно потому, что мы кроме С++ видели много более современных и качественных языков, чтоб иметь возможность судить здраво.
CC>Неа.
Да.

C>>>>Одна из реализаций. Как-там у нее с юникодом, кстати?
CC>>>y wstring USC2 100% поддерживается
C>>Разницу между std::string и std::wstring улавливаете?

CC>typedef basic_string<char, char_traits<char>, allocator<char> > string;
CC>typedef basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t> > wstring;

Вот-вот. Никак у нее с юникодом. Потому что для юникода создан совсем другой класс — wstring.

ЧТД.

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

(троллинг и ламерствования ГВ вырезаны цензурой)

C>>>И какой-же геморой вас ждёт, когда интерфейс должен иметь один маленький метод.
C>>Что должен делать интерфейс?
C>>Сморозили очередную глупость. Интерфейс — это просто контракт.

ГВ>Интерфейс — это интерфейс. Контракт — гораздо более общая штука.
Демагогия.
Интерфейс в С# — это и есть контракт.

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

C>И Ком и Корба имплементируют "КОМПОНЕНТНУЮ" модель, и даже idl у них на 99% одинаковый, и всё сводится к общению между компонентами, но КОРБА имеет дополнительные аспекты.
Одинаковый? А разработчики корбы и DCOM об этом уже знают?

C>В общем начали с одного, закончили терминами, как обычно и делает crioSray.

C>Кстати, криоСрэй, какой стаж работы на С++?
7 лет подряд с 95го по 2002ой. А Ваш?
C>На примере когда ты сказал что в С++ шаблоне нельзя вызвать неделарированный метод из T,
Где я это сказал? Опять фантазируете?

C>я могу сказать что С++ для тебя это Си с классами(если помнишь), и обсуждать темы такого порядка ты может только на уровне "Мне это не нравится и ВСЁ".
По сути что можете сказать?
Хотите услышать чем вариант дотнет лучше шаблона из Вашего примера?
Тем, что ошибка будет указана прямо в редакторе во время набора на строке f<B>(), где B — класс, не реализующий интерфейс, а в С++ только во время компилляции будет выдана ошибка при чем совсем в другом месте — на вызове
t.f() — будет указано, что класс B НЕ имеет метода f().

C>Что за цитаты, примеры кода? Приведи реальный пример когда из-за кривизны языка, а не программера получаются неявные ошибки не описанные и заранее не продуманные в языке.
Ошибки заранее не продуманные в языке? Это Вы сильно сказали. К сожалению, мне слишком далеко до Вашего интеллектуального уровня, чтоб был смысл продолжать этот неконструктивный спор.

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

ГВ>>Интерфейс — это интерфейс. Контракт — гораздо более общая штука.
C>Демагогия.
C>Интерфейс в С# — это и есть контракт.

"Контракт" подразумевает соглашения о побочных эффектах, которые интерфейсом прямо не выражаются ни на C++, ни на C#. "Интерфейс в С# — это и есть контракт." — не более, чем сужение семантики термина "контракт". Зачем тебе это надо — я не знаю.

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

ГВ>"Контракт" подразумевает в частности соглашения о побочных эффектах [...]

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

ГВ>"Контракт" подразумевает соглашения о побочных эффектах

Занавес. Апплодисменты.

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

ГВ>>"Контракт" подразумевает соглашения о побочных эффектах
C>Занавес. Апплодисменты.

А что не так?

Интерфейс (в терминах C#) — это только перечисление методов, pure virtual на C++ — то же самое. Конечно, это выражение некоторой части контракта класса, но только некоторой. И возвращаясь к твоему риторическому вопросу, "что должен делать интерфейс" — интерфейс может верифицировать часть более общего контракта класса. Как раз на C++ это реализовать особого труда не составляет, например, разделив интерфейс на public и protected секции:

class ISomeAction {
  public:
    // Вот это - "публичный контракт"
    // Здесь даже не нужно virtual
    void actOn(ISomeOther *pOther) {

      ASSERT(pOther->getSome() > 10); // Предусловие
      ASSERT(getMyData() > 5 && getMyData() < 8); // Ещё одно предусловие

      actOnImpl(pOther); // Собственно действие

      ASSERT(pOther->getSome() < 100); // Постусловие
      ASSERT(getMyData() > 5 && getMyData() < 8); // Обратно постусловие
    }
  protected:
    // А вот это - то, что должно быть реализовано классом, реализующим интерфейс
    virtual void actOnImpl(ISomeOther *pOther) = 0;
    virtual int getMyData() const = 0;
};

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

C>Вот-вот. Никак у нее с юникодом. Потому что для юникода создан совсем другой класс — wstring.

C>ЧТД.

int != double. Потому int — маздай, а double — рулит. Сила слова, да.

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

C>>Вот-вот. Никак у нее с юникодом. Потому что для юникода создан совсем другой класс — wstring.

C>>ЧТД.

ГВ>int != double. Потому int — маздай, а double — рулит. Сила слова, да.

Садитесь — два.

Целые числа и числа с плавающей запятой это разные понятия. Строка это одно понятие, а уж ANSI она или Unicode — детали реализации, которые у С++ в виду примитивизма языка торчат наружу.

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

ГВ>>>"Контракт" подразумевает соглашения о побочных эффектах
C>>Занавес. Апплодисменты.

ГВ>А что не так?

ГВ>Интерфейс (в терминах C#) — это только перечисление методов,

Не только. Садитесь — два.

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

C>Целые числа и числа с плавающей запятой это разные понятия.

Почему? И то, и другое суть "число". int, double, short int, BCD — это всё детали реализации.

C>Строка это одно понятие, а уж ANSI она или Unicode — детали реализации, которые у С++ в виду примитивизма языка торчат наружу.

"В общем" — одно. А вот с точки зрения компьютера (то есть — реализаций) этих самых "строк" может быть великое множество. А для человека все они будут выражать одну и ту же абстракцию — строку.

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

ГВ>>Интерфейс (в терминах C#) — это только перечисление методов,

C>Не только. Садитесь — два.

Ладно, пусть перечисление не только методов, но ещё и их параметров. Много поменялось в сути сказанного мной о контрактах?

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

ГВ>"что должен делать интерфейс" — интерфейс может верифицировать часть более общего контракта класса.

Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

Цитирую:

Интерфейс — набор всех сигнатур, определенных операциями объекта. Интерфейс описывает множество запросов, на которые может отвечать объект.

"Приемы объектно-ориентированного проектирования. Патерны проектирования" Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес

Если для Вас это облегчит понимание, то уточню, что книга эта была написана ДО дотнет и все примеры в книге приведены на С++.

Садитесь — еще одна двойка. Третья на сегодня.

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


ГВ>>>Интерфейс (в терминах C#) — это только перечисление методов,

C>>Не только. Садитесь — два.

ГВ>Ладно, пусть перечисление не только методов, но ещё и их параметров. Много поменялось в сути сказанного мной о контрактах?

Четвертая двойка. Не только методов и параметров.

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


C>>Целые числа и числа с плавающей запятой это разные понятия.

ГВ>Почему? И то, и другое суть "число".
Число это слишком обобщенное понятие. Даже школьники знают, что числы бывают целыми, дробными, с плавающей запятой, комплексными.
А строки "они и в африке" строки.

ГВ>"В общем" — одно. А вот с точки зрения компьютера (то есть — реализаций) этих самых "строк" может быть великое множество. А для человека все они будут выражать одну и ту же абстракцию — строку.
Нет, не может их быть великое множество. Заканчивайте фантазировать.

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

ГВ>>"что должен делать интерфейс" — интерфейс может верифицировать часть более общего контракта класса.

C>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

Зависит от того, как мы определяем сам термин "интерфейс". Если это только конструкция языка программирования вроде C# или Java — да, не может. Если это часть "контракта" — то не только может, но ещё и, не побоюсь этого слова, должен.

C>Цитирую:

C>

C>Интерфейс — набор всех сигнатур, определенных операциями объекта. Интерфейс описывает множество запросов, на которые может отвечать объект.

C>"Приемы объектно-ориентированного проектирования. Патерны проектирования" Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес

GoF, как и многие идеологи современного программирования обожают приписывать хорошо знакомым терминам необычные значения. Сейчас мне лень возиться, погугли по словам Liskov Substitution Principle, в статьях, обсжудающих LSP, в частности, встречается корректное определение "контракта". В том числе и строгое — через предикаты. Ещё, в качестве опорной точки поисков — языки CLU и Eiffel.

C>Если для Вас это облегчит понимание, то уточню, что книга эта была написана ДО дотнет и все примеры в книге приведены на С++.

Спасибо, я знаю. Больше того, это была первая книга по программированию, которую я сознательно отказался покупать в 2001 г. ибо абсолютно ничего нового для меня в ней не было.

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

ГВ>>Ладно, пусть перечисление не только методов, но ещё и их параметров. Много поменялось в сути сказанного мной о контрактах?
C>Четвертая двойка. Не только методов и параметров.

Ах, ещё пропертей и статических методов.

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

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


C>>>Целые числа и числа с плавающей запятой это разные понятия.

ГВ>>Почему? И то, и другое суть "число".
C>Число это слишком обобщенное понятие. Даже школьники знают, что числы бывают целыми, дробными, с плавающей запятой, комплексными.

C>А строки "они и в африке" строки.

Строки тоже бывают разными: в книге, в тетради, ровные, корявые, стихотворные, прозаические, написанные слева направо и справа налево, даже сверху вниз. Это всё — суть конечные наборы символов.

ГВ>>"В общем" — одно. А вот с точки зрения компьютера (то есть — реализаций) этих самых "строк" может быть великое множество. А для человека все они будут выражать одну и ту же абстракцию — строку.
C>Нет, не может их быть великое множество. Заканчивайте фантазировать.

Отнюдь. Строка может представляться как:

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

Естественно, может быть всё разнообразие кодировок: с фиксированным или плавающим количеством байт на символ. Так же естественно, что строка (как "объект") может содержать или не содержать операции поиска, конкатенации, выделения подстроки и т.п. И само собой, строки могут быть изменяемыми и не изменяемыми.

Ну и какую комбинацию мы примем за единственно правильную?