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

Д>из того самого паскаля, который использует на порядок большее количество людей, чем Оберон — из Object Pascal AKA Delphi.

А к Вирту тогда какие претензии? Вирт к Object Pascal-ю отношения не имеет.

Object Pascal-евский with

with TMyObj.Create() do begin 
  DoSmth;
  Free;
end;

Виртовский WITH:

WITH
  msg: SomeMsg    DO .... |
  msg: AnotherMsg DO ....
  ELSE ..
END;

Они разные не только по смыслу, но и по написанию всей конструкции.

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

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

Д>Я говорил именно об этом. Роль паскаля в современной индустрии близка к нулю, так что его отстутствие не повлияло бы практически ни на что. Может быть только, еще больше склонило бы чашу весов в сторону C/C++

Насчёт роли Паскаля мне кажется неоднозначно. Конечно, я не могу судить о больших, промышленных комплексах, но мне кажется, что если посмотреть по download-серверам, то там очень много продуктов, написанных на Дельфи. Возможно, что больше, чем на С++.

Повторюсь, я не знаю и не могу знать процент крупных "промышленных" проектов, выполняемый на Паскале (Дельфи).

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

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

K_O>>О, как вы неправы, создает и еще как! Для больших С++ проектов после появления IncrediBuilda это — самый больной вопрос. Линковка в течении 40 минут на современном компе — это далеко не фантастика. Более того, это один из главных тормозов в разработке сложных систем. Проверено на собственной шкуре.

K>Да, механизм компиляции в С++ устарел до безобразия. С этим никто не спорит.

Ну вот, приплыли. С чего бы это? И какие будут предложения по его замене?

K>Кстати а что мешает в таком крупном проекте заюзать dll?

Кстати, да. Тут соглашусь.

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Да вы что! Это же замечательная вещь. Можно работать с неименованной переменной без копирования в локальную переменную. Это и быстро (х.з. сможет компилятор ли соптимизировать лишее копирование), и красиво — не загромождаем код лишними переменными.

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

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

WH>И зачем ради этого вводить специальную конструкцию в язык?

А зачем вводить в язык оператор switch (или CASE) если его можно эмулировать с помощью цепочки if-else?

А зачем вводить в язык несколько циклов WHILE, REPEAT, FOR, LOOP если достаточно одного?

Это нужно для написания более оптимальных программ.

В обероне WITH — это тот же самый CASE но только CASE — работает с перечислимыми типами, а WITH работает со внутренним тегом в котором зашифрована RTTI информация о динамическом типе полиморфной переменной. Теоретически (я не проверял) WITH должен работать быстрее чем цепочка dynamic_cast-ов, равно как swith теоретически должен работать быстрее цепочки if-else. Плюс к этому — большая структуризация текста программы.

Здравствуйте, Сергей Губанов, Вы писали:

Д>>из того самого паскаля, который использует на порядок большее количество людей, чем Оберон — из Object Pascal AKA Delphi.

честно говоря — не помню уже, как оно в Дельфи с этим with
в паскале Вирта это ключевое слово позволяет писать обращения к полям записей — без явного указания в обращении, какой из записей они принадлежат
еще в том самом древнем учебнике, который я читал в школе, было предострежение о проблемах при совпадении имен
вот за этот самый with ему и должно было быть стыдно

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

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

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

K_O>>>О, как вы неправы, создает и еще как! Для больших С++ проектов после появления IncrediBuilda это — самый больной вопрос. Линковка в течении 40 минут на современном компе — это далеко не фантастика. Более того, это один из главных тормозов в разработке сложных систем. Проверено на собственной шкуре.

K>>Да, механизм компиляции в С++ устарел до безобразия. С этим никто не спорит.

D>Ну вот, приплыли. С чего бы это? И какие будут предложения по его замене?

Основная проблемма в препроцессоре и инклюдах. от этого пора отказыватся, другое дело что так просто это не сделать. ИМХО пора делать новый язык на базе С++. Избавится от препроцессора, некоторых откровено устаревших фич. Небольшой косметический ремонт типа this — не указатель а ссылка. И сам механизм компиляции тоже требует радикальных изменений. Дабы избежать появления разных диалектов языка, хорошо бы иметь стандартный фронт-энд, который парзит файлы и создает AST(abstract syntax tree) в како-мнить стандартизированном формате. Это бы убило сразу всех зайцев. Фактически отдельным компилер-девелоперам не пришлось бы каждый раз писать парзер, а только кодогенератор, а во вторых какой был бы простор для разных визардов и тулзов? Надо выташить что-нить из кода, пжста — есть готовое AST. Можно узнать о коде все до мельчайших подробностей.

K>>Кстати а что мешает в таком крупном проекте заюзать dll?

D>Кстати, да. Тут соглашусь.

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

K_O>>О, как вы неправы, создает и еще как! Для больших С++ проектов после появления IncrediBuilda это — самый больной вопрос. Линковка в течении 40 минут на современном компе — это далеко не фантастика. Более того, это один из главных тормозов в разработке сложных систем. Проверено на собственной шкуре.

K>Да, механизм компиляции в С++ устарел до безобразия. С этим никто не спорит.
K>Кстати а что мешает в таком крупном проекте заюзать dll?

Две вещи — требование, чтобы продукт работал одновременно на Windows и на Unix платформе и, как ни странно, сам С++.

Из DLL можно экспортировать только функции, но не объекты (расширения Microsoft здесь не годятся), а стало быть, для того, чтобы выделить некоторую общую часть, реализованную на С++ с использованием ООП в отдельную DLL, надо либо оборачивать все в С-шные функции wrapper'ы, либо реализовывать свой COM, потому как нету его на Иксах.

На самом деле это о-очень давняя проблема и не мы первые с ней столкнулись. COM — как раз и явилось попыткой Microsoft разбить свои С++ проекты на DLL'ки. Получилось не слишком красиво и не очень удобно, следующим шагом стал .NET, что уже гораздо лучше. Только для этого потребовалось изменить язык. С++ оказался непригодным для создания сложных, расширяемых, кроссплатформенных систем.

И, кстати, пару слов о Стандарте, который здесь очень часто упоминают. Чтобы решить данную проблему потребовалось внести изменения в язык. Но в С++ нельзя самовольно (даже для Microsoft ) внести изменения, потому как такой компилятор до принятия нового стандарта не может называться С++'ом. Получается, что этот самый Стандарт и тормозит развитие языка. Уже в .NET сделано по-другому: MSIL стардартизирован, чтобы можно было всем, кому не лень свои языки создавать, а вот C# — нет, заявка на стандартизацию была, но ее отозвали.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, WolfHound, Вы писали:

WH>>И зачем ради этого вводить специальную конструкцию в язык?

СГ>А зачем вводить в язык оператор switch (или CASE) если его можно эмулировать с помощью цепочки if-else?

СГ>А зачем вводить в язык несколько циклов WHILE, REPEAT, FOR, LOOP если достаточно одного?

СГ>Это нужно для написания более оптимальных программ.

Оптимальных с какой т.зр.?
По скорости? По объёму бинарника? По объёму кода?

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

К>Тут есть полиморфизм повыше обычного ООПшного

Шаблоны — это статический полиморфизм — его нет во время работы программы.
А в ООП динамический полиморфизм — он есть во время работы программы.

К>вот реализуй полиморфную для любых типов ф-цию swap?

Если шаблонов нет, как я ее реализую? Никак. Чего тогда спрашиваешь?

Здравствуйте, Сергей Губанов, Вы писали:

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

К>>Тут есть полиморфизм повыше обычного ООПшного

СГ>Шаблоны — это статический полиморфизм — его нет во время работы программы.
СГ>А в ООП динамический полиморфизм — он есть во время работы программы.

т.е. ООП — священная корова, так?
И другие идеи суть ересь?

К>>вот реализуй полиморфную для любых типов ф-цию swap?

СГ>Если шаблонов нет, как я ее реализую? Никак. Чего тогда спрашиваешь?

И это ты называешь оптимальным языком без грабель?

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

K>Основная проблемма в препроцессоре и инклюдах. от этого пора отказыватся, другое дело что так просто это не сделать. ИМХО пора делать новый язык на базе С++. Избавится от препроцессора, некоторых откровено устаревших фич. Небольшой косметический ремонт типа this — не указатель а ссылка. И сам механизм компиляции тоже требует радикальных изменений. Дабы избежать появления разных диалектов языка, хорошо бы иметь стандартный фронт-энд, который парзит файлы и создает AST(abstract syntax tree) в како-мнить стандартизированном формате. Это бы убило сразу всех зайцев. Фактически отдельным компилер-девелоперам не пришлось бы каждый раз писать парзер, а только кодогенератор, а во вторых какой был бы простор для разных визардов и тулзов? Надо выташить что-нить из кода, пжста — есть готовое AST. Можно узнать о коде все до мельчайших подробностей.

Более того такое разделение компилера на отдельные куски, позволит писать компилер целой толпой, по кусочкам. Одна группа занимается стандартизацией — делает парзер в стандартный AST, другая например из AST в стандартный IL-код, третья, пятая, десятая уже кодогенераторы для конкретных платформ. Все это может со временем не подецки вырасти в целую индустрию, например вокруг AST — всякие тулзы визарды IDE и т.п. Вокруг IL — кода профайлеры, чекеры и т.п.

P.S. Гы, эк я размечтался-то? Целые воздушные замки соорудил

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

К>Оптимальных с какой т.зр.?
К>По скорости? По объёму бинарника? По объёму кода?

А это уже вопросы которые надо адресовать к конкретным компиляторам, а не к самому языку как таковому. Язык предполагает, а компилятор располагает.

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

K_O>>О, как вы неправы, создает и еще как! Для больших С++ проектов после появления IncrediBuilda это — самый больной вопрос. Линковка в течении 40 минут на современном компе — это далеко не фантастика. Более того, это один из главных тормозов в разработке сложных систем. Проверено на собственной шкуре.

D>Ну хорошо, давайте уточним, а что такое "большой проект"? Это сколько строк кода? И на какой машине делается сборка?
P4-1800, 1Gb RAM — как видите, не самый хилый комп. Кода — около 100 Mb.

D>>>Что же происходит в "модульных" языках? Да то же самое, совершенно то же самое. С той лишь разницей, что все имена (сигнатуры) в них разбиты на группы, которые относятся к разным модулям.

K_O>>Нет, в модульных языках есть одно существенное отличие — информация о типах данного модуля содержится в скомпилированных объектных файлах. Эта информация доступна компилятору при компиляции другого модуля, который содержит секцию импорта из другого модуля. В результате — каждая строка в исходном тексте программы обрабатывается компилятором ровно один раз.
K_O>>А теперь вопрос: сколько раз при компиляции большого С++ проекта компилятор обрабатывает, скажем, файл stdio.h?

D>Не пробовали использовать precompiled headers? Один раз. Всего один раз.
Пробовали — нету их на Unix'ax! Вот такой облом... К тому же к линковке они отношения не имеют.

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

K>Основная проблемма в препроцессоре и инклюдах. от этого пора отказыватся, другое дело что так просто это не сделать. ИМХО пора делать новый язык на базе С++. Избавится от препроцессора, некоторых откровено устаревших фич. Небольшой косметический ремонт типа this — не указатель а ссылка. И сам механизм компиляции тоже требует радикальных изменений. Дабы избежать появления разных диалектов языка, хорошо бы иметь стандартный фронт-энд, который парзит файлы и создает AST(abstract syntax tree) в како-мнить стандартизированном формате. Это бы убило сразу всех зайцев. Фактически отдельным компилер-девелоперам не пришлось бы каждый раз писать парзер, а только кодогенератор, а во вторых какой был бы простор для разных визардов и тулзов? Надо выташить что-нить из кода, пжста — есть готовое AST. Можно узнать о коде все до мельчайших подробностей.

Вот это правильно. Я даже думаю, что давно пора отказаться от хранения исходников в виде плоского текста, вместо этого — структурированное хранилище с AST внутри. Это очень упростило бы создание множества замечательных вещей
(сейчас тут наверно появится VladD2 и R# )
И это — не говоря уже о повышении скорости компиляции на несколько порядков.

А про this в виде ссылки — это наверно зря. Тогда нельзя будет сделать delete this, а это нужно при освобождении объектов по счетчику ссылок, например.

Здравствуйте, Сергей Губанов, Вы писали:

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

К>>Оптимальных с какой т.зр.?
К>>По скорости? По объёму бинарника? По объёму кода?

СГ>А это уже вопросы которые надо адресовать к конкретным компиляторам, а не к самому языку как таковому. Язык предполагает, а компилятор располагает.

Ну о какой оптимальности такой ты говоришь тогда, я не пойму?
Это как отпимальность сферического коня в вакууме чтоли?

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

WH>ЗЫ Прочитай "Эффективное программирование на С++" Кёниг и Му... Оказывается и С++ можно преподовать не сложнее паскаля. Ну и кому после этого нужен Вирт со своими выкидонами?
Ну, я лично к нему отношусь с большим уважением — все-таки не всякому удается такой след в истории ИТ оставить. Большинство из тех, кто относится к нему с пренебрежением, не удасться и тысячной доли того, что сделал он. А потом, может именно в борьбе противоположностей С и С++ стали такими, какие они есть сейчас. Ведь не было бы с чем сравнивать — неизвестно, как все повернултось бы.
А Кенига и МУ, я конечно, читал. Минус там один, как я уже писал в рецензии — нет привязки к конкретной среде. Это для русских студентов трудности создает с русским языком в программах.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Ну а теперь развеем Ваше невежество.
Ну а теперь поговорим о Вашей невнимательности. Я уже заметил, что вам хоть Джава говори — слышите вы только слово "Оберон". Я говорил именно о языке Паскаль. Поэтому вся аргументация по поводу Оберона здесь, мягко говоря, не к месту.

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

S>Ну а теперь поговорим о Вашей невнимательности. Я уже заметил, что вам хоть Джава говори — слышите вы только слово "Оберон". Я говорил именно о языке Паскаль. Поэтому вся аргументация по поводу Оберона здесь, мягко говоря, не к месту.

Эта ветка посвящена обсуждению статьи Вирта о том как хорошо было бы преподавать студентам Оберон, так, спрашивается, а зачем тогда Вы стали в этой ветке говорить о допотопном Паскале?

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

WH>>ЗЫ Прочитай "Эффективное программирование на С++" Кёниг и Му... Оказывается и С++ можно преподовать не сложнее паскаля. Ну и кому после этого нужен Вирт со своими выкидонами?
LVV>Ну, я лично к нему отношусь с большим уважением — все-таки не всякому удается такой след в истории ИТ оставить.
Ну Герострата до сих прор помнят. Не аргумент.
LVV>Большинство из тех, кто относится к нему с пренебрежением, не удасться и тысячной доли того, что сделал он.
А что он сделал? Несколько ни кому не нужных языков которые по сути не далеко ушли от ассемблера? Развел кучу тупых наездов на С/С++ из серии := vs = ? Создал культ поклонения Оберону? Ты посмотри на Губанова... он же просто фанатеет от оберонов.
LVV>А потом, может именно в борьбе противоположностей С и С++ стали такими, какие они есть сейчас.
Не понял кто с кем борится? Вес всех Виртовских поделок и близко не стоял с весом одного С++.
LVV>Ведь не было бы с чем сравнивать — неизвестно, как все повернултось бы.
Что с чем сравнивать? С++ с Паскалем? Да С++ от функциональных языков взял больше чем от паскаля. Если от паскаля вобще что-то взял.

LVV>А Кенига и МУ, я конечно, читал. Минус там один, как я уже писал в рецензии — нет привязки к конкретной среде.
Ну знаетели... ИМХО не аргумент. И тем болие не аргумент в пользу Виртовских поделок.
LVV>Это для русских студентов трудности создает с русским языком в программах.
Ну за это надо бить ичключительно переводчиков.