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

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

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

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


COF>>Вариант с C++ уже все посчитал, а создатель F# сидит — затачивает моно
G>Мегакластер на плюсах? Плюсов там и не будет, голый C.

Откуда дровишки?

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

COF>>>Вариант с C++ уже все посчитал, а создатель F# сидит — затачивает моно
G>>Мегакластер на плюсах? Плюсов там и не будет, голый C.
B>Откуда дровишки?

ну, в общем-то, плюсы там будут. после С и Fortran'а
дровишки можно поискать среди открытых и не очень hpc приложений, доступных в инете... вообще сейчас туда всё тащат, даже boost но старого кода пока больше

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


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

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

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

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

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

ГВ>Отнюдь. Строка может представляться как:
Опять же — представления типа. Тип строка — один единственный.

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

ГВ>Ну и какую комбинацию мы примем за единственно правильную?
А она всего одна — строка как тип данных.

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

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

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

ГВ>Собственно, самое главное — строки в "общечеловеческом" смысле в принципе не могут совпадать со строками в "компьютерном" смысле.

Тип может совпадать (конечно же) и совпадает. Примером тому c#, java, python, ruby — и другие нормальные языки.

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

И снова Вы говорите не о типе, а о реализации. Тип строка — один единственный. Точка.

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

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

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

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

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


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

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

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

Ничего он не должен.

C>>Цитирую:

C>>

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

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

ГВ>GoF, как и многие идеологи современного программирования обожают приписывать хорошо знакомым терминам необычные значения.
Все понятно. Все вокруг Вас приписывают необычные значения хорошо знакомым (почему-то только Вам одному) терминам.

Вопросов больше не имею. Не утруждайте себя больше ответами по этой теме.

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

C>Очень интересная статейка, сколько я таких быдланов повидал и пообламывал,

C>Ха, вот имено столкнулся, лбами, и судя по всему скорлупа его мозга дала непоправимую трещину, сорри за лирику — не выдержал.

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

C>хотелось бы пройтись по вышеозначенному документу, сравнивать плюсы буду с жабой, те там где имею опыт (а не так как делают шарписты обсирая язык который знают по наслышке):
А я пройдусь по твоему проходу. Ибо я знаю оба мира очень хорошо. Ибо и на том и на другом пописал весьма не мало.

C>И вот такого там 90%, изречения ничем не обоснованные, замете, что автор говорит сугубо о своём опыте, о неудачном опыте, он не говорит о том что этими корявыми средствами он делал шедевры, а говорит что в его кучерявом дизайне и коде виноват имено С++, это называется трезумция виновности, когда отталкиваются от обвинения, а не от защиты.
Ну а я воял. И вполне успешно. Сейчас одно крутится 7х24 с фаиловером и прочими радостями на кластере и еще очень долго будет крутиться, другое на куче нефтяных заводов понатыкано,...
Правда всегда чувствовал что что-то тут не то.
Как-то все очень сложно.
А все почему?
А по тому что кривой язык заставляет делать кривой дизайн для того чтобы компенсировать кривизну языка.
Понял я это когда начал изучать другие и сильно другие языки.

C>А примеры? Как такой крутой перец и гуру не наваял нам с десяток красивых примеров.
Исходники буста почитай... Там вся "красота" С++ в полный рост.

C>И вот тут я хочу остановиться на книге "Exceptional C++" в двух томах, где описывается как молодой девелопер может сделать криво, а как после прочтения это можно сделать шедеврально.
Молодой "девелопер" может сделать только криво. Тем более на С++. Тем более после того как начитается.

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

C>Вот это да, 4 года работаю с жабой в "огромных" (компания лидер в индустрии, не буду называть) индустриальных масштабах, и всегда видел интерфейс как "заплатку" на дырень моно-наследования.
Как по мне наследование реализации нужно вообще отменить.
А вот так.
Не нужно оно.
Только лишнюю связанность на ровном месте создает.

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

C>Тогда решили сделать множественное наследование, и разрешить наследовать от одного класса, и одного и более недо-класса, который не мог бы вызвать испражнения из кучерявых пальцев говнокодеров, те никаких имплементаций, которые могут вызвать двоиственность сущностей, только описание метода, или словами микрософта — Pure Virtual Function.
Интерфейс это чистый контракт.
Тем он собственно и хорош.
Ибо SRP никто не отменял. А нарушать такие вещи в дизайне языка это совсем не хорошо.

C>Во первых зачем? А во вторых эти сахарные названия Persistence, Hibernate, DataObject, Serializable... как это всё напоминает ныне покойный билдер с его ВСПЛ(только не надо о его реинкорнации в кодгеар), и замете билдер был и под плюсы, и всё там было, но оказалось ненужным в настоящем языке, а всё потому-что плохому танцору...
Ты его видел?
А во я на нем пытался писать.
Так вот билдер сдох по тому что во первых был жутко глючный. Просто не реальное количество багов везде.
А во вторых ничего там не было.

C>нужны контролы, компоненты, фичи, крутой язык, автоматика во всём, даже мозх автоматический, 500 крутых названий, зазубривши которые ты зовёшся гуру.
Нормальным людям нужно решать задачу, а не контролы в каждом новом проекте выпиливать.

C>А много ли явошарпы знают удобных, простых и "интуитивно" понятных способов расширить функционал языка?
Ну так свет на явашарпах не сошелся.

C>Вот у меня требование к либе, я хочу регить callbackи вот таким способом:
C>alarmNotifier = GUIHandler::onAlarm + CoreRoutine::onAlarm
C>и что? у вас есть "костыль"? или всё чего нету нам не надо? Ха, это мертвецки неправильно, и обычно такое отмирает как несовершенное.
Ты попал пальце в небо.

alarmNotifier += GUIHandler.onAlarm;
alarmNotifier += CoreRoutine.onAlarm;

C>А как просто вам при вызове логгера указать текущее имя файла, исходника я имею ввиду,ай как вы ругали макросы, это так, это сяк, а как вы напишете:
C>logger::log(__filename__, __line__, "log text")
Ну если вспомнить что языки не ограничены жабошарпами. Причем есть куда более умные языки на тех же платформах.
И тоже самое там можно написать куда проще.

C>Ой, а никак, и даже костыли такие не выпускают, фабрика ещё не открылась, ну ничё, когда дядя Билл захочет нам это надо будет
Когда там комитет научит С++ делать такое:

  macro @while (cond, body)
  syntax ("while", "(", cond, ")", body) 
  {
    def loop = Nemerle.Macros.Symbol (Util.tmpname ("while_"));

    <[ 
      ($("_N_break" : global) : {
        def $(loop : name) () : void {
          when ($cond) {
            ($("_N_continue" : global) : {
              $body
            }) : void;
            $(loop : name) ()
          }
        } 
        $(loop : name) (); 
      }) : void
    ]>
  }

Получается while не отличимый от встроеного в язык.
Вот это макросы.
А то что в С++ это полное угрЁбище.

C>Ага, а теперь скажите мне, у меня огромный обьект, но я хочу сериализовать только, замете слово ТОЛЬКО хидеры во всей иерархий, вот так я это использовал:
C>dataStream << Modifiers::HeadersOnly << hugeObject;
Кто такие хидеры?

C>Слабо?
Нет.

C>или вы можете кичиться только готовыми фичами, но поверте мне, до 50% времени у больших команий использующих управляемые языки уходит на обход невозможности что-то сделать самому. И давайте честно, с примерами — сделайте мне на Яве универсальный алгоритм, да, который берёт генерик класс и делает с ним что-то своё, что есть общее для генерика. И не говорите мне что этот обрубок шаблонного метода вообще можно считать генерик, напишите-ка
В C# так сделать можно.

C>Знаете что было придумано дабы обойти всё это? был сделан препроцессор для Явы, да, препроцессор, вернулись к яблони таки.
Ну ява это ява. Но не одной явой...

C>Вот скажите мне серьёзно, хоть один реальный пример в рамках одного приложения(про распределённые системы отдельный разговор), когда на этапе компиляции тип обьекта не известен, а если он известен, то зачем его узнавать? Потеряли — плохой дизайн и кучерявые руки!!! + обрезанность языка.
Да пожалуйста:
Простенький оптимизатор грамматики.

  partial internal class Optimizer
  {
    public static CanInline(name : string, grammar : Grammar) : bool
    {
      def canInline(rule, recRules)
      {
        match (rule : Rule)
        {
        | Call(name)               =>
          if (recRules.Contains(name))
            false;
          else
            canInline(grammar.GetRule(name), recRules.Add(name));
        | Choice(rules)            => rules.ForAll(rule => canInline(rule, recRules));
        | Sequence(rules)          => rules.ForAll(rule => canInline(rule, recRules));
        | Capture(_, rule)         => canInline(rule, recRules);
        | RepeatMin(_, rule)       => canInline(rule, recRules);
        | RepeatMinMax(_, _, rule) => canInline(rule, recRules);
        | Not(rule)                => canInline(rule, recRules);
        | And(rule)                => canInline(rule, recRules);
        | Chars                    => true;
        | ExtensionPoint           => true;
        }
      }
      canInline(grammar.GetRule(name), Set().Add(name));
    }

    public static OptimizeRule(rule : Rule, grammar : Grammar) : Rule
    {
      def optimize(_ : Rule)
      {
      | Choice(rules) =>
        def rules = rules.Map(optimize);
        def rules = rules.Map(fun(_)
        {
        | Rule.Choice(rules) => rules;
        | rule => [rule];
        });
        def rules = rules.Flatten();
        def catChars(_)
        {
        | Rule.Chars([chars1]) :: Rule.Chars([chars2]) :: rules =>
          catChars(Rule.Chars([chars1.Sum(chars2)]) :: rules);
        | rule :: rules =>
          rule :: catChars(rules);
        | [] => [];
        }
        def rules = catChars(rules);
        match (rules)
        {
        | [rule] => rule;
        | _      => Rule.Choice(rules);
        }

      | Sequence(rules) =>
        def rules = rules.Map(optimize);
        def rules = rules.Map(fun(_)
        {
        | Rule.Sequence(rules) => rules;
        | rule => [rule];
        });
        def rules = rules.Flatten();
        def catChars(_)
        {
        | Rule.Chars(chars1) :: Rule.Chars(chars2) :: rules =>
          catChars(Rule.Chars(chars1.Append(chars2)) :: rules);
        | rule :: rules =>
          rule :: catChars(rules);
        | [] => [];
        }
        def rules = catChars(rules);
        match (rules)
        {
        | [rule] => rule;
        | _      => Rule.Sequence(rules);
        }

      | RepeatMin(min, rule)         => Rule.RepeatMin(min, optimize(rule));
      | RepeatMinMax(min, max, rule) => Rule.RepeatMinMax(min, max, optimize(rule));

      | Not(Not(rule))         => optimize(Rule.And(rule));
      | And(Not(rule))         => optimize(Rule.Not(rule));
      | Not(And(rule))         => optimize(Rule.Not(rule));
      | And(And(rule))         => optimize(Rule.And(rule));
      | Not(rule)              => Rule.Not(optimize(rule));
      | And(rule)              => Rule.And(optimize(rule));

      | Capture(name, rule)    => Rule.Capture(name, optimize(rule));
      | Chars as rule          => rule;
      | ExtensionPoint as rule => rule;

      | Call(name)             =>
        if (CanInline(name, grammar))
          optimize(grammar.GetRule(name));
        else
          Rule.Call(name);
      }
      optimize(rule);
    }
  }

Я конечно понимаю что это далеко не жаба и даже C#'у до этого языка пилить и пилить но тем не мение.
Кстати обрати внимание ни одной переменной. Только константы.

Я уже молчу про компонентный подход.
Там и на С++ dynamic_cast дергать приходиться.

C>А про шаблонные классы и алгоритмы автор видимо не читал, где вызов подставляется на этапе компиляции.
Только без лямбды которая только в C++0x планируется толку от этого как от козла молока.

C>

C>В С++ это практически невозможно сделать. Именно поэтому сперва в Delphi и C++ Builder, а затем и в остром С появилось возможность делегирования как расширение языка.

C>Именно поэтому два первых на сегодняшний день скончались а третий живёт только за счёт огромных вложений
Первые два скончались совсем по другим причинам.
Дельфя по тому что это просто недоязык которым невозможно пользоваться.
А дебилдер глючил так что работать было не реально.

C>переданный параметр не поменяется? и Вообще ни один параметр не поменяется? ах сколько говна было сьедено на этом миллионами программистами и тестерами. И вы говорите о том что управляемые языки там просты?
Правильные языки просты.
Ява просто не правильный язык.
C# объективно лучше. Но тоже не фонтан.

C>А так же примеры где производительность увеличивалась в 1000 раз, и тоже благодаря аллокаторам из СТЛя,
В 1000 раз от смены аллокатора?
Не верю.

C>а сделайте ка мне аллокатор на шарпе дорогой
Зачем тебе дорогой аллокатор? Чтобы на его фоне сделать в 1000 раз быстрее?

C>(только не надо что менеджер памяти мега умный и всё знает, он ничего не знает кроме вашего говнокода)
Он уже очень умный.
Можно сделать еще умнее.
А если сделать ВМ без тех косяков что во все щели насовали авторы жабы и нета то можно сделать такой что руками не догнать.

C>

C>Т.е. на С++ МОЖНО писать очень эффективно. И НЕКОТОРЫЕ даже пишут. Вопрос только — относитесь ли Вы к их числу ?

C>Да, а вы?
Я относился.
Еще раз за С++ возьмусь только за очень большие деньги.
А может и не возьмусь, а напишу язык который компилируется в С или в LLVM.
Ну это если натив будет реально нужен.

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

ГВ>>>Строки тоже бывают разными: в книге, в тетради, ровные, корявые, стихотворные, прозаические, написанные слева направо и справа налево, даже сверху вниз. Это всё — суть конечные наборы символов.
ГВ>>Собственно, самое главное — строки в "общечеловеческом" смысле в принципе не могут совпадать со строками в "компьютерном" смысле.
C>Тип может совпадать (конечно же) и совпадает. Примером тому c#, java, python, ruby — и другие нормальные языки.

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

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

Ну, попробуй тогда ответить на вопрос, что такое тип.

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

ГВ>>Отнюдь. Строка может представляться как:
C>Опять же — представления типа. Тип строка — один единственный.

Определение типа, которым ты руководствуешься — в студию!

ГВ>>Ну и какую комбинацию мы примем за единственно правильную?
C>А она всего одна — строка как тип данных.

Я сказал — определение.

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

ГВ>>>>Строки тоже бывают разными: в книге, в тетради, ровные, корявые, стихотворные, прозаические, написанные слева направо и справа налево, даже сверху вниз. Это всё — суть конечные наборы символов.
ГВ>>>Собственно, самое главное — строки в "общечеловеческом" смысле в принципе не могут совпадать со строками в "компьютерном" смысле.
C>>Тип может совпадать (конечно же) и совпадает. Примером тому c#, java, python, ruby — и другие нормальные языки.

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

Какое еще "заковычивание"? Вам самому еще не смешно от той билеберды, что Вы тут выдумываете?

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

ГВ>Ну, попробуй тогда ответить на вопрос, что такое тип.

http://en.wikipedia.org/wiki/Data_type читайте до полного просвящения.

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

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

Эх, кажется мне, что вы о разных сущностях говоррите. Где-то об интерфейсе, как конструкции того или иного языка, а где-то об интерфейсе, как о контракте класса...

Но если вернуться именно к языковым конструкциям, так сказать, то вот есть у меня интерфейс, например такой:

struct IOrder {
    virtual bool IsInCorrectOrder( const TEltm* elem1, const TElem* elem2 ) = 0;
    virtual bool IsEquivalent( const TEltm* elem1, const TElem* elem2 ) = 0;
};

При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...

Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...

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

ГВ>>GoF, как и многие идеологи современного программирования обожают приписывать хорошо знакомым терминам необычные значения.
C>Все понятно. Все вокруг Вас приписывают необычные значения хорошо знакомым (почему-то только Вам одному) терминам.

Да, разумеется. Правда, то самое, хорошо знакомое значение терминов хорошо знакомо не только мне, о чём я сужу по реакции собеседников. И кстати, не только значение, но и взаимосвязь этого термина с другими терминами, явлениями и т.п.

C>Вопросов больше не имею. Не утруждайте себя больше ответами по этой теме.

Да это не у тебя ко мне вопросы, а у меня к тебе, если ты не заметил.

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


C>Вот-вот. Никак у нее с юникодом. Потому что для юникода создан совсем другой класс — wstring.
А как у System.String с Shift-JIT, например?

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

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

А почему ты думаешь, что одно место лучше другого?
Кста, дефолтный компилятор ещё посоветует посмотреть определение класса B, так что скорее всего попадёт в нужное место...

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

ГВ>>Мда? Надо думать, что общечеловеческое начертание строк символов тоже предполагает их закавычивание? Остроумно.
C>Какое еще "заковычивание"? Вам самому еще не смешно от той билеберды, что Вы тут выдумываете?

Ну что, моя очередь ставить двойки?

ГВ>>Ну, попробуй тогда ответить на вопрос, что такое тип.

C>http://en.wikipedia.org/wiki/Data_type читайте до полного просвящения.

Хорошо. Допустим. Что считать определением? Вот это:

Тип (сорт) – относительно устойчивая и независимая совокупность элементов, которую можно выделить во всем рассматриваемом множестве (предметной области).

?

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

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

Я — о разных. А criosray, похоже, склеивает их в одну.

E>Но если вернуться именно к языковым конструкциям, так сказать, то вот есть у меня интерфейс, например такой:

struct IOrder {
E>    virtual bool IsInCorrectOrder( const TEltm* elem1, const TElem* elem2 ) = 0;
E>    virtual bool IsEquivalent( const TEltm* elem1, const TElem* elem2 ) = 0;
E>};

При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...

E>Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...

Да, согласен. Скажем так — это составляющая контракта.

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

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

E>Эх, кажется мне, что вы о разных сущностях говоррите. Где-то об интерфейсе, как конструкции того или иного языка, а где-то об интерфейсе, как о контракте класса...

E>Но если вернуться именно к языковым конструкциям, так сказать, то вот есть у меня интерфейс, например такой:

struct IOrder {
E>    virtual bool IsInCorrectOrder( const TEltm* elem1, const TElem* elem2 ) = 0;
E>    virtual bool IsEquivalent( const TEltm* elem1, const TElem* elem2 ) = 0;
E>};

Да, это вполне корректный интерфейс, хотя и костыль, т.к. придет Вася Пупкин в проект и порушит всю чистоту конструкции, добавив неабстрактный метод.


E>При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...

Замечательно, что оно у Вас там где-то подразумевается, но при чем тут интерфейс?

E>Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...

Это контракт не интерфейса, а объекта, который реализует данный интерфейс.

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


ГВ>>>Мда? Надо думать, что общечеловеческое начертание строк символов тоже предполагает их закавычивание? Остроумно.
C>>Какое еще "заковычивание"? Вам самому еще не смешно от той билеберды, что Вы тут выдумываете?

ГВ>Ну что, моя очередь ставить двойки?

Попробуйте — снова посажу Вас в лужу.