Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Правда? Я вот надеюсь, что boost::bind станет частью языка, тогда это будет такой же стандартный механизм, как делегаты, а не заплатка.
VD>Не беспокойся — не станет. Я тут прочел твою ссылку на очередное откровение Страуструпа и понял, что основные вещи он уеж решил (ну, классы есть же?) а мелочи вроде делегатов или процедурных типов он делать не желает. Это мелкие частности. Ну, что поделать если человек настолко образован, что ему плевать на целую парадигму функционального программирования? В общем, орлам вроде Степанова и дальше прийдется извращаться, чтобы написать примитивную фичу вроде boost::bind. Причем компилироваться это будет часами. В общем, маразм крепчал...
Насколько я понимаю ситуацию, для boost::bind не нужна модификация языка -- нужен компилятор, который C++ достаточно полно поддерживает. Поэтому я не вижу необходимости модификации языка (чего не хочет Страуструп) для стандартизации boost::bind (хотя boost я сейчас не использую).
А что ты понимаешь под "процедурными типами", которые нужны в C++? Может ссылочку куда-нибудь дашь?
E>>Ключевое слово -- "я". Если бы я мог все сам отрефакторить, я бы отрефакторил. А если я говорю своим коллегам: "Друзья мои, я сделал маленькое дополнение к библиотечке, из-за которого вы должны отрефакторить свой код", то я расчитываю услышать массу слов в свой адрес.
VD>А ты рафактри сам. Нечего сваливать на молодежь.
Классное замечание
Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?
E>>Нет, вопрос в том, как formatter десериализует объект, класса которого вообще нет в сборке на принимающей стороне?
VD>Если объяснять на пальцах, то все просто... Описание классов в сборках. Если нужно его прочесть, то сборка просто динамически подгружается. Далее форматер читает информацию и можепт поднять или сериализовать любой объект. Сам объект ему по большому барабану. А технология называется рефлекшон.
Влад, ты не понимаешь: на принимающей стороне вообще нет кода сборки с нужным классом и подгрузить его неоткуда! Такое бывает, слово даю. Вот, например, в таких случаях: Реализация паттерна Async Completion Token
Здравствуйте, eao197, Вы писали:
E>Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?
Насколько мне известно первый версии Эклипса, до тех пор пока его архитектура окончательно не стабилизировалась, посылали такую совместимость далеко и надолго. В результате получилась нормальная система, а не набор затычек и заплаток. Так что тут надо ещё разобраться что лучше.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?
IT>Насколько мне известно первый версии Эклипса, до тех пор пока его архитектура окончательно не стабилизировалась, посылали такую совместимость далеко и надолго. В результате получилась нормальная система, а не набор затычек и заплаток. Так что тут надо ещё разобраться что лучше.
Про первые версии совершенно согласен. А если изменения вносятся в код, который уже несколько лет находится в stable-состоянии? Имхо, тогда совместимость становится чуть-ли не решающим фактором.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Про первые версии совершенно согласен. А если изменения вносятся в код, который уже несколько лет находится в stable-состоянии? Имхо, тогда совместимость становится чуть-ли не решающим фактором.
Мелкие изменения, баги, фички — для этого как правило не надо менять интерфей. Если же дархитектура меняется принципиально, то наверное лучше выпустить новый продукт, а старый только сопровождать.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>Про первые версии совершенно согласен. А если изменения вносятся в код, который уже несколько лет находится в stable-состоянии? Имхо, тогда совместимость становится чуть-ли не решающим фактором.
IT>Мелкие изменения, баги, фички — для этого как правило не надо менять интерфей. Если же дархитектура меняется принципиально, то наверное лучше выпустить новый продукт, а старый только сопровождать.
К-хе, К-хе (смущенное покашливание), я опять согласен. Но вот наткнулся на случай, когда и функциональность нужно было чуть-чуть расширить, и интерфейс для этого заменить, и совместимость сохранить. Поскольку даже выпуск новой версии, с измененным интерфейсом, означал бы, что рано или поздно на него пришлось бы переходить с соответствующим рефакторингом. А так, благодоря фишкам языка, и рефакторинг не потребовался.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>К-хе, К-хе (смущенное покашливание), я опять согласен. Но вот наткнулся на случай, когда и функциональность нужно было чуть-чуть расширить, и интерфейс для этого заменить, и совместимость сохранить.
Как бы это было на C#. Создаем новую версию интерфейса. Старую оставляем для совместимости, но по сути вызов старых методов теперь сводится к работе через новый интерфейс. При этом старый интерфейс помечается как Obsolete. При этом если использовать старый интефейс при компиляции будут выдаваться предупреждения, а в тексте сообщения содержатся указания на то чем заменен устаревший интерфейс. Т.е. будет все примерно так:
[Obsolete("Use NewMethod instead")]
public void OldMethod(...)
{
NewMethod(...);
}
public void NewMethod(...)
{
// ...
}
E>Поскольку даже выпуск новой версии, с измененным интерфейсом, означал бы, что рано или поздно на него пришлось бы переходить с соответствующим рефакторингом. А так, благодоря фишкам языка, и рефакторинг не потребовался.
Программисту получают новую версию либы. Все работает как раньше, но выдаются предупреждения об использовании устаревшего интерфейса. Необходимые замены с испольщованием рефакторинга и конкретных мест, где этот устаревший интерфейс используется занимают совсем немного времени.
ЗЫ: почитал свой текст... прям сказка какая-то получается, как у маркетологов MS... и что интересно, от жизни отличается не принципиально
Здравствуйте, eao197, Вы писали:
E>Насколько я понимаю ситуацию, для boost::bind не нужна модификация языка
Извини, а сам boost::bind не является модификацией языка?
E> -- нужен компилятор, который C++ достаточно полно поддерживает.
А может нужно немного утихомирить маразматический фанатизм? Ну, вместо 150 килобайт обмана компилятора встроить в язык примитивную конструкцию которая есть почти во всех серьезных языках?
E> Поэтому я не вижу необходимости модификации языка (чего не хочет Страус-труп) для стандартизации boost::bind (хотя boost я сейчас не использую).
И Страус-труп не видит. От того язычек и загнется. В общем, логично все хорошее загибается от крепчания маразма.
E>А что ты понимаешь под "процедурными типами", которые нужны в C++? Может ссылочку куда-нибудь дашь?
Сиии delegat & closure в какой-нить википедии.
E>Классное замечание E>Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?
Проект буедт открытым. Изменения можно будет вносить в SVN. Если изменения будут тупыми, то откамим. Иначе... все ОК.
E>Влад, ты не понимаешь: на принимающей стороне вообще нет кода сборки с нужным классом и подгрузить его неоткуда!
Да, не понимаю. Сборка это набор байт. Всегда можно скачать...
E> Такое бывает, слово даю.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Насколько я понимаю ситуацию, для boost::bind не нужна модификация языка
VD>Извини, а сам boost::bind не является модификацией языка?
Языка -- нет. Стандартной библиотеки -- да.
E>>А что ты понимаешь под "процедурными типами", которые нужны в C++? Может ссылочку куда-нибудь дашь?
VD>Сиии delegat & closure в какой-нить википедии.
Ok, посмотрим.
E>>Влад, ты не понимаешь: на принимающей стороне вообще нет кода сборки с нужным классом и подгрузить его неоткуда!
VD>Да, не понимаю. Сборка это набор байт. Всегда можно скачать...
Нет. Далеко не всегда.
E>> Такое бывает, слово даю.
VD>У гого?
VladD2,
> E>Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?
> Проект буедт открытым. Изменения можно будет вносить в SVN. Если изменения будут тупыми, то откамим. Иначе... все ОК.
Ты отвечаешь на другой вопрос. Речь шла об использовании твоих компонент в чужом коде.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
SiAVoL,
> E>К-хе, К-хе (смущенное покашливание), я опять согласен. Но вот наткнулся на случай, когда и функциональность нужно было чуть-чуть расширить, и интерфейс для этого заменить, и совместимость сохранить.
> Как бы это было на C#. Создаем новую версию интерфейса. Старую оставляем для совместимости, но по сути вызов старых методов теперь сводится к работе через новый интерфейс.
Так не выйдет, потому что есть некоторые промежуточные классы, возвращающие ссылки на "старые" интерфейсы, но теперь хочется, чтоб они возвращали ссылки на новые интерфейсы, т.к. эти классы используются в "новом" коде. Этих классов много. Т.е. проблема не в том, чтоб старые клиенты могли работать со старым интерфейсом, а в том, чтоб они по-старому могли работать с новым.
Сводится к тому, что, допустим, есть некоторый класс C, у которого есть функция f, возвращающая ссылку на интерфейс I. Теперь нужно, чтоб эта функция этого класса возвращала ссылку на интерфейс I2, но клиенты, работающие с этим I2 по-старому, как с I, продолжали работать корректно.
Если потребовать "почкования" не только интерфейсов, но и промежуточных классов, подобных C, введя вместо них C2, то в итоге это сведется к каскадной замене I на I2 по всему коду, чего как раз и хочется избежать.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
согласен со всем, если речь идет о развитии библиотеки.
если же речь об неком одиночном внешнем интерфейсе, да еще который обычно используют через обертку (даже в C#), то SiAVol описал вполне приемлимый сценарий.
vdimas,
> согласен со всем, если речь идет о развитии библиотеки. > если же речь об неком одиночном внешнем интерфейсе, да еще который обычно используют через обертку (даже в C#), то SiAVol описал вполне приемлимый сценарий.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, eao197, Вы писали:
E>>>Насколько я понимаю ситуацию, для boost::bind не нужна модификация языка
VD>>Извини, а сам boost::bind не является модификацией языка?
E>Языка -- нет. Стандартной библиотеки -- да.
Нет? И я могу вот так за просто получить в С++ указатель на произвольный метод?
Странно. А ведь boost::bind это море очень не быстро компилируемого кода который использует уж совсем не кчемную функциональность языка вроде указателей на методы. И все это вмесо примитивной модификации языка.
Для меня бредовость и маразматичность этой ситуации является просто приговором для этого языка. Его авторы просто костьми ложатся чтобы не признавать своих ошибок. А это гарантия ненормального развития.
Мне не хочется в очередной раз писать трактат о функциональных типах. Кажется о них было сказано уже довольно много. Ну, да если ты действительно не понимашь всю глубину маразма этой ситуации, то скажи... и я попытаюсь описать ее более детально.
VD>>Да, не понимаю. Сборка это набор байт. Всегда можно скачать...
E>Нет. Далеко не всегда.
И когда нельзя?
E>А ты хоть прочитал, о чем там речь Если да, и нет понимания, то я готов раскрыть тему более подробно.
Раскрывай.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
>> E>Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?
>> Проект буедт открытым. Изменения можно будет вносить в SVN. Если изменения будут тупыми, то откамим. Иначе... все ОК.
ПК>Ты отвечаешь на другой вопрос. Речь шла об использовании твоих компонент в чужом коде.
Боюсь, что ты не понимашь меня и не потому, что я отвечаю на другой вопрос, а потому, что ты живешь в другом мире где совместимость дикая проблема.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Так не выйдет, потому что есть некоторые промежуточные классы, возвращающие ссылки на "старые" интерфейсы, но теперь хочется, чтоб они возвращали ссылки на новые интерфейсы, т.к. эти классы используются в "новом" коде. Этих классов много. Т.е. проблема не в том, чтоб старые клиенты могли работать со старым интерфейсом, а в том, чтоб они по-старому могли работать с новым.
Посмотри списки абсолт-методов и интерфесов ко второму фрэймворку и попробуй обяснить почему это немого выйти.
ПК>Если потребовать "почкования" не только интерфейсов, но и промежуточных классов, подобных C, введя вместо них C2, то в итоге это сведется к каскадной замене I на I2 по всему коду, чего как раз и хочется избежать.
Кончай пугать людей страшилками. Погляди на реальную жизнь.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
>>> E>Вот представь, сделал ты вместо Scintill-ы свой редактор на C# (кстати, желаю удачи). Его начали использовать в разных проектах, даже в тех, в которых ты участия не принимаешь. И вот ты захотел пару-тройку сигнатур поменять, нарушив при этом совместимость на уровне исходников. Как ты себе представляешь проведение рефакторинга в чужих проектах?
>>> Проект буедт открытым. Изменения можно будет вносить в SVN. Если изменения будут тупыми, то откамим. Иначе... все ОК.
ПК>>Ты отвечаешь на другой вопрос. Речь шла об использовании твоих компонент в чужом коде.
VD>Боюсь, что ты не понимашь меня и не потому, что я отвечаю на другой вопрос, а потому, что ты живешь в другом мире где совместимость дикая проблема.
Совместимость здесь вообще ни при чем. Речь шла о невозможности рефакторинга кода чужих проектов, что ты предлагал в качестве выхода в ситуации автора начального сообщения данной подветки.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>>>Извини, а сам boost::bind не является модификацией языка?
E>>Языка -- нет. Стандартной библиотеки -- да.
VD>Нет? И я могу вот так за просто получить в С++ указатель на произвольный метод?
Дело в том, что
1) в C++ смысла от этого ноль -- ведь чтобы вызвать метод по указателю, нужно знать точную сигнатуру метода.
2) с помощь явных кастов в C++ можно привести указатель на один метод к указателю на другой метод. Только это нафиг не нужно.
VD>Странно. А ведь boost::bind это море очень не быстро компилируемого кода который использует уж совсем не кчемную функциональность языка вроде указателей на методы. И все это вмесо примитивной модификации языка.
Никчемность указателей на методы -- это собственное впечатление?
Лично мне они кажутся настолько же удобными, как и указатели на функии. И время от времени я ими пользуюсь.
VD>Мне не хочется в очередной раз писать трактат о функциональных типах. Кажется о них было сказано уже довольно много. Ну, да если ты действительно не понимашь всю глубину маразма этой ситуации, то скажи... и я попытаюсь описать ее более детально.
Опиши.
VD>>>Да, не понимаю. Сборка это набор байт. Всегда можно скачать...
E>>Нет. Далеко не всегда.
VD>И когда нельзя? VD>Раскрывай.
Use case 1: Async Completion Token (так же рассматривался здесь
Пусть у нас есть некий сервер S и несколько клиентов C1,...,Cn, которые к этому серверу подключаются. Каждый клиент отсылает запросы на сервер и каждый запрос должен уникальным образом однозначно идентифицироваться. Для этого клиент вставляет в запрос свой trx_id. Если клиенты подключаются к S по разным портам, то проблемы со смешением trx_id от разных клиентов, вроде бы нет. Но, сервер S на самом деле может представлять из себя более сложную структуру из маршрутизаторов R1,...,Rm и конкретных исполнителей P1,...,Po. Причем несколько клиентов могут быть подключены к одному маршрутизатору, а один маршрутизатор может быть подключен к нескольким исполнителям. При этом исполнитель хочет, чтобы все запросы, приходящие с конкретного маршрутизатора, имели уникальные идентификаторы. Получается, что маршрутизатор, к которому подключено несколько клиентов, не может использовать trx_id клиентов для обращения к исполнителю. Поскольку trx_id у клиентов могут пересекаться. И здесь возможны следующие варианты:
1. В качестве trx_id используется последовательно возрастающий unsigned int (обычное решение при использовании РСУБД для хранения информации о запросах). Тогда маршрутизатор принимает от клиентов их trx_id(Ci), сохраняет их в БД и получает новый trx_id(Rj). Далее делает запрос к Pk. Когда маршрутизатор получает от Pk ответ с trx_id(Rj), он по БД восстанавливает trx_id(Ci) и узнает, какому клиенту нужно передать ответ. Получается, что маршрутизатор должен работать с СУБД всегда, даже если он выполняет не очень сложные вещи. Например, если маршрутизатор выступает в роли load-balancer-а или просто выполняет рутинные преобразования данных в запросах (например, преобразует величины из одной системы счисления в другую, или конвертирует одну валюту в другую). Если же нужно объединить в цепочку несколько маршрутизаторов (каждый из которых выполняет собственные преобразования), то тогда будут лишние расходы не только по администрированию БД (и обеспечению отказоустойчивости), но и потери производительности (т.к. каждый маршрутизатор будет что-то записывать в БД).
2. В качестве trx_id применяется какой-то черный ящик. Только отправляющая сторона знает, что из себя представляет trx_id и как его распарсить. Тогда маршрутизатор принимает от клиентов их trx_id(Ci) и генерирует свой trx_id(Rj) в который включает идентификатор клиента и исходный trx_id(Ci). Далее trx_id(Rj) идет исполнителю Pk, но исполнитель совершенно не в курсе того, что находится в trx_id(Rj). И ему это совершенно не нужно знать. Когда маршрутизатор получает от исполнителя ответ с trx_id(Rj), то маршрутизатор извлекает из trx_id(Rj) идентификатор клиента и исходный trx_id(Ci). После чего не составляет труда переслать ответ нужному клиенту с нужным идентификатором. В таком подходе не нужно использовать СУБД для фиксации промежуточных данных (соответственно, не нужно обеспечивать отказоустойчивость). И нет лишних накладных расходов на обращения к БД.
Лично мне второй подход нравится гораздо больше. Но возникает вопрос, как все же представлять trx_id? Будет ли это просто неинтерпритируемая последовательность байт, которая на C++ представляется либо std::string, либо std::vector<char>? Или ее можно структурировать?
Так вот мой подход к сериализации позволяет выделить общий базовый класс trx_id_t, от которого каждая сторона может сделать себе производный класс. Например, клиенты могут делать rnd_trx_id_t (который хранит уникальный unsigned int из БД), а маршрутизаторы -- router_trx_id_t (который хранит идентификатор клиента и trx_id, полученный от клиента). При этом фишка в том, что маршрутизатору совершенно не нужно знать про тип rnd_trx_id_t и иметь его код на своей стороне. Когда Rj получает запрос от Ci, он десериализует только ту часть trx_id, которая известна обоим сторонам (т.е. базовый класс trx_id_t). Но когда десериализованный объект на стороне Rj сериализуется вновь, то получается точно такой же образ, какой был после сериализации на стороне Ci. Достигается это за счет того, что при десериализации при объекте сохраняется т.н. "неизвестное расширение". А при повторной сериализации это расширение используется для получения исходного двоичного образа.
Use case 2: Unknown Traits
Я описал этот случай вот здесь: Наследование расширением -- лучше вряд ли напишу (читать можно только до "Описание механизма subclassing_by_extension").
Хочу отметить, что все приведенные случаи не требуют того, чтобы взаимодействующие стороны точно знали типы используемых для коммуникации объектов. Более того, они и не нуждаются в наличии чужого кода на своей стороне. Более того, конкретный прикладной протокол может вообще не содержать возможности по передачи на удаленную сторону нужного для десериализации объектов кода. И более того, эта передача кода может быть в принципе запрещена по соображениям безопасности.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Сводится к тому, что, допустим, есть некоторый класс C, у которого есть функция f, возвращающая ссылку на интерфейс I. Теперь нужно, чтоб эта функция этого класса возвращала ссылку на интерфейс I2, но клиенты, работающие с этим I2 по-старому, как с I, продолжали работать корректно.
1. Унаследовать I2 от I1 можно?
2. Можно ли унаследовать С2 от С1 и в нем ввести new I2 f()?
Т.е. пользователям, доступающимся до объектов С2 как до С1 будет отдаваться старая версия интерфейса, а новым — новая. Где противоречие?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ПК>>Сводится к тому, что, допустим, есть некоторый класс C, у которого есть функция f, возвращающая ссылку на интерфейс I. Теперь нужно, чтоб эта функция этого класса возвращала ссылку на интерфейс I2, но клиенты, работающие с этим I2 по-старому, как с I, продолжали работать корректно.
S>1. Унаследовать I2 от I1 можно?
Да.
S>2. Можно ли унаследовать С2 от С1 и в нем ввести new I2 f()?
Да. Но чтоб это имело смысл, придется унаследовать и все классы D, через которые клиенты получают доступ к C, а также все классы E, через которые клиенты получают доступ к D и т.п. Именно этого хочется избежать.
S>Т.е. пользователям, доступающимся до объектов С2 как до С1 будет отдаваться старая версия интерфейса, а новым — новая. Где противоречие?
Противоречия нет; есть масса работы, которую не хочется делать.
Пример:
interface I { ... };
class C {
public:
I1& i();
};
class D {
public:
C& c();
};
class E {
public:
D& d();
};
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Если нам не помогут, то мы тоже никого не пощадим.
