Ответ на »сообщение 915« (AVC)
___________________________
Спасибо за совет!
Про контейнеры я знал, однако в команде авто-птр с векторами используют, мотивируя тем, что во всех "нормальных" реализациях STL вектор не выполняет копирование своих элементов через их =, а выполняет низкоуровневое копирование памяти...

Ответ на »сообщение 914« (Илья Ермаков)
___________________________

Илья, сразу одна реплика, по горячим следам.


auto_ptr - крайне паршивая замена сборки мусора - в частности, с некоторыми контейнерами порождает проблемы.

В книжке Скотта Мейерса "Эффективное использование STL" восьмой совет гласит:
"Никогда не создавайте контейнеры, содержащие auto_ptr"
Такие контейнеры еще называются COAP (Containers Of Auto_Ptrs) и всегда ведут к проблемам.
Некоторые компиляторы их просто запрещают, но некоторые нет.
Если уж "занесла Вас нелегкая" :) использовать современный Си++ (уже не "старый добрый" Си с классами), то весьма рекомендую Вам эту книжку Мейерса.
Когда я ее читал, у меня было впечатление (возможно, слишком уж пессимистичное), что программирование с помощью STL - это какое-то хождение по минному полю.

Ответ на »сообщение 913« (AVC)
___________________________

Ответ на »сообщение 912« (AVC)
Это т.н. "принцип Калашникова": избыточная сложность = уязвимость.
А что думают остальные?

info21 правильно сказал: "Пропались они пропадом, эти...".
Сейчас приходится, параллельно с работами по ББ, включаться в один крупный, уже долгоидущий проект на С++ (компьютерная лингвистика). Честное слово, более через...сто реализовать самые базовые вещи, чем это сделано в С++, просто невозможно... В частности, namespacы претендуют на эмуляцию модульности, но даже их  примитивной "модульностью" сишники почему-то предпочитают редко пользоваться...
Сокрытие реализации сведено только к инкапсуляции в классах, о сокрытии конкретных потомков и открытии исключительно базовых, абстрактных интерфейсов слыхом не слыхивали, все валится пачкой в один .h - и прототипы, и реализация, "чтобы не плодить файлы"...
auto_ptr - крайне паршивая замена сборки мусора - в частности, с некоторыми контейнерами порождает проблемы.
Реализация строк std::string в версии Visual Studio 8 была заменена, а ребята "захацкали" очень многие вещи в опоре на особенности 6-й версии, теперь переписывают код... Хотя реализация объектно-ориентированная, интерфейсы между "модулями"-DLL-ями процедурные, на хендлах, смесь двухбайтовых и однобайтовых строк с постоянными перекодировками, тьфу...
Дремучесть, каменный век, и непрошибаемая уверенность в том, что "лучше С++ нет ничего, потому что все на нем работают, и Микрософт столько лет двигала именно его". Но при этом половина действительно высокоуровневых возможностей языка все равно не используется.

Ответ на »сообщение 912« (AVC)
___________________________


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

Эта мысль имеет некоторое основание.
Рассмотрим пример.
В Оберонах нет множественного наследования.
Если вдруг оно "позарез" понадобится, надо будет как-то выкручиваться.
Одним из решений является паттерн "Близнецы", предложенный Мессенбеком:
http://www.ssw.uni-linz.ac.at/Research/Papers/Moe99.html
Если бы в Обероне было множественное наследование, то этот паттерн не потребовался бы.
С другой стороны, какова цена включения в язык конструкций "не первой необходимости"?
Усложняется язык, его труднее освоить; усложняется компилятор, его труднее написать; и т.д.

Одна из возможных точек зрения неоднократно и совершенно ясно высказывалась здесь info21.
Это т.н. "принцип Калашникова": избыточная сложность = уязвимость.
А что думают остальные?

Ответ на »сообщение 911« (info21)
___________________________


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

Любопытно, что одно из последних обсуждений на RSDN было затеяно, похоже, с прямо противоположных позиций и называется "Паттерны суть слабости языков программирования".
Мысль в том, что паттерны приходится реализовывать повторно, а это плохо.
Мол, хороший язык программирования исключает необходимость во многих паттернах.
Обсуждение вызвано к жизни любопытной статьей
http://newbabe.pobox.com/~mjd/blog/prog/design-patterns.html

Ответ на »сообщение 908« (AVC)
___________________________

Да нет, система обработки данных как раз ничего. Просто я представил себе "функции высших порядков" в том конктексте...

Да, верно.
Оберон по построению содержит минимальный практичный набор конструкционных средств. Все, что уровнем выше -- "идиоматика" -- паттерны и проч.  для сложных вещей.
Сложные вещи (как раз на последней лекции философствовал) имеют тенденцию к уникальности (типа электроны тождественны, а человеки все разные). Одни простые списки сколько вариаций имеют.

Ответ на »сообщение 909« (AVC)

аналогичного правилу Си++ о порядке вызова конструкторов статических объектов в порядке их объявления?

Если нет модулей, то о каком порядке вообще можно говорить? Допустим, классы описаны в разных файлах Packets.cs и Tables.cs. Который из этих файлов первый? А ключевое слово partial вообще позволяет описывать разные части одного и того же класса в разных файлах...

Ответ на »сообщение 901« (Сергей Губанов)
___________________________

Сергей, спасибо за ответ.
Действительно, кажется, что-то они не вполне продумали.
Особенно с пространствами имен и использованием неквалифицированных идентификаторов.
Наверное, перед создателями дотнета лежал бо-о-ольшой список требований, а также было очень много источников для заимствования идей.
Прямо как при создании Ады. :)
Как тут сохранить "консистентность" проекта? :)
К тому же автор C#, Хейлсберг, никогда ее особенно и не ценил, если судить еще по ТурбоПаскалю.

По поводу первого пункта.
Интересно, а разве в C# нет соглашения, аналогичного правилу Си++ о порядке вызова конструкторов статических объектов в порядке их объявления?
Как бы то ни было, это дает некоторую пищу для размышлений о конструкторах...

Ответ на »сообщение 900« (info21)
___________________________


Сейчас вот только вернулся с очередной сессии обсуждения системы обработки данных со своими экспериментаторами.
Чтоб я сдох: провались пропадом все эти, блин, функции высших порядков...

Ни хрена они не дают, только головная боль.
В Обероне есть все конструктивные средства, чтобы все, что надо, смоделировать.
Сложности встречаются редко, их всегда можно сделать, зато все остальное с минимумом затрат.

С Трурлем трудно не согласиться насчет параметрического...
Но и тут keep it simple, stupid: редко это встречается, можно скопировать код и поменять там INTEGER на CHAR...

..... все эти замыкания -- говорю как математический физик.

Похоже, система обработки данных не вдохновила Вас... :)
Попытаюсь выжать главную мысль:

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

Верно?
Кстати, о параметрическом полиморфизме: раз уж Copy&Paste пока наша судьба, то это действо вполне можно автоматизировать и иными способами, помимо шаблонов/дженериков.
Завести набор часто используемых (полиморфных по характеру) структур и организовывать их в ставку в исходник через меню или по нажатию коммандера.
При этом может открываться диалоговое окошко, где программиста попросят указать требуемый тип-параметр, и вставленный код уже не надо будет править ручками.
В ББ, например, "за полиморфизм" вполне могла бы отвечать какая-нибудь отдельная подсистема.

Ответ на »сообщение 906« (AVC)
___________________________


Чтобы не быть голословным, сошлюсь хотя бы на один источник:
http://www.rsdn.ru/article/philosophy/SyntacticSugar.xml

Как я уже говорил, понять ребят с RSDN иногда трудно.
Например, приведенный в статье код (для иллюстрации мысли {Quote]Оператор continue заменяется рекурсией)

    for (int i = 0; i < 100; i++)
    {
      if (Predicate(i))
        continue;

      result++;
    }

проще было бы просто изменить на

    for (int i = 0; i < 100; i++)
    {
      if (!Predicate(i))
        result++;
    }

чем прибегать к рекурсии для избаления от continue.
И т.д.
Короче, чего-то я не "догоняю".
А как вы думаете?