Здравствуйте, AVC, Вы писали:
AVC>А сколько, интересно, стоит такой переход?
сравнимо со стоимостью полной разработки заново
AVC>Кроме того, существует множество конверторов с языка на язык.
это наверно тоже была шутка
AVC>Количество проектов отражает популярность языка, его поддержку заинтересованными организациями. Но отражает ли качество языка?
Бизнес — это по большей части совершенно рациональный процесс. Если используют именно этот язык — значит, для этого были основания.
AVC>А скрыто — тот факт, что еще за два года до его статьи появился компилятор Модулы-2, языка, в котором все существенные недостатки Паскаля были Виртом уже устранены.
Который, конечно же, был абсолютно несовместим с Паскалем и не имел никакого распространения по сравнению с ним же. Иными словами — очередной "Неуловимый Джо" в мире программирования. Ну и зачем тогда его рассматривать?
Если бы Вирт потратил хоть небольшую часть времени не на размножение бесконечных несовместимых вариаций и диалектов, а на заботу о совместимости и/или интеропе — глядишь, его творениями и пользовались бы сейчас. Когда говорят про его "непрактичность" и "оторванность от жизни" — говорят именно про это.
Какими будут контр-аргументы?
Здравствуйте, Дарней, Вы писали:
AVC>>А сколько, интересно, стоит такой переход? Д>сравнимо со стоимостью полной разработки заново
Может быть, в таком случае стоило остановиться на Фортране?
AVC>>Кроме того, существует множество конверторов с языка на язык. Д>это наверно тоже была шутка
Отнюдь. (Как ловко я ввернул это слово. )
Например, та же фирма XDS часто предоставляет конверторы с языка на язык.
В конце концов, это ведь всего лишь разновидность компиляции.
AVC>>Количество проектов отражает популярность языка, его поддержку заинтересованными организациями. Но отражает ли качество языка? Д>Бизнес — это по большей части совершенно рациональный процесс. Если используют именно этот язык — значит, для этого были основания.
Угу. Например, у крупных фармацевтических фирм свои представления о том, какое здоровье у людей им (этим фирмам) желательно. И ведь не подкопаешься — все рационально.
AVC>>А скрыто — тот факт, что еще за два года до его статьи появился компилятор Модулы-2, языка, в котором все существенные недостатки Паскаля были Виртом уже устранены. Д>Который, конечно же, был абсолютно несовместим с Паскалем и не имел никакого распространения по сравнению с ним же. Иными словами — очередной "Неуловимый Джо" в мире программирования. Ну и зачем тогда его рассматривать? Д>Если бы Вирт потратил хоть небольшую часть времени не на размножение бесконечных несовместимых вариаций и диалектов, а на заботу о совместимости и/или интеропе — глядишь, его творениями и пользовались бы сейчас. Когда говорят про его "непрактичность" и "оторванность от жизни" — говорят именно про это. Д>Какими будут контр-аргументы?
Если бы Вирт работал на крупную фирму, то "практичность" его творений была бы гарантирована.
Но его языки были бы хуже.
Например, были бы такими же как Си++.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Может быть, в таком случае стоило остановиться на Фортране?
Многие так и делают, если переход себя не оправдывает. Но если оправдывает — старый язык бросают без сожалений.
Переход на Модулу себя не оправдывал.
AVC>В конце концов, это ведь всего лишь разновидность компиляции.
С таким же успехом можно сказать, что процесс обычной компиляции — это и есть процесс производства программных продуктов. И за ненадобностью отменить программистов
AVC>Угу. Например, у крупных фармацевтических фирм свои представления о том, какое здоровье у людей им (этим фирмам) желательно. И ведь не подкопаешься — все рационально.
Ты хочешь сказать, что они (эти самые фирмы) намеренно портят людям здоровье?
AVC>Если бы Вирт работал на крупную фирму, то "практичность" его творений была бы гарантирована. AVC>Но его языки были бы хуже. AVC>Например, были бы такими же как Си++.
Это ты тоже очень ловко ввернул.
Оберонам до старичка С++ — как до Пекина раком, даже при всех его недостатках.
AVC пишет:
> AVC>>А *сколько*, интересно, стоит такой переход? > Д>сравнимо со стоимостью полной разработки заново > Может быть, в таком случае стоило остановиться на Фортране?
Интересно, почему же большую часть научного софта до сих пор на нем
пишут?
> Д>Если бы Вирт потратил хоть небольшую часть времени не на размножение > бесконечных несовместимых вариаций и диалектов, а на заботу о > совместимости и/или интеропе — глядишь, его творениями и пользовались > бы сейчас. Когда говорят про его "непрактичность" и "оторванность от > жизни" — говорят именно про это. > Д>Какими будут контр-аргументы? > Если бы Вирт работал на крупную фирму, то "практичность" его творений > была бы гарантирована. > Но его языки были бы хуже.
Понимаете, даже у того же Оберона есть _практические_ недостатки:
1. Нет единой спецефикации для модулей расширения. (для _практического_
использования — абсолютно критично).
2. GC консервативный, а сам язык не особо подходит для точного GC.
Аналог такого кода:
SomeObject *obj=new SomeObject();
static int ref=(int)obj;
вызовет _утечку_ _памяти_.
3. Нет интероперабельности GC и кода расширений (следует из 2).
и т.д.
Здравствуйте, AVC, Вы писали:
AVC>Самое простой вопрос: как должен реагировать компилятор на следующие конструкции?
AVC>void foo(int *p)
AVC>{
AVC> p[4] = 21; /* как узнать - массив p или нет? */
AVC> p++;
AVC>}
или
void foo(int *p)
AVC>{
AVC> free(p); /* указывет p на объект кучи, или это адрес переменной в стеке или сегменте данных? */
AVC>}
Пожалуй, тут просто необходимо ввести такое понятие, как домен (область определения) указателя.
Уточнение происходит следующим образом (извините за корявость изложения идеи)
модель "Указатель" / "Ссылка" (можно разыменовывать)
<- модель "Указатель на тип T" (результат разыменования - объект T)
<- тип T*, some_container::iterator и т.п.
<- домен "объект в динамической памяти", "объект-агрегат", (статический, стековый, член, элемент массива)
<- домен "элемент конкретного массива" (или одиночный элемент), "голова массива", "хвост массива", ноль
В скриптовых языках ограничиваются моделью "указатель".
В С/С++ — типом указателя.
В Обероне — доменом "динамический/статический", получая разные типы.
Наверное, при желании можно детализировать, хотя бы различая голову, середину и хвост массива.
тип допустимые приведения пример инициализации функциональность
new_array >-+ <-- p1 = new T[10]; можно применять delete[] p1;
|
new_object | >-+ <-- p2 = new T; можно применять delete p2;
| |
| |
array_ptr <-+ | >-+ <-- T arr[10]; p3 = arr; можно применять адресную арифметику и разыменовывать
| | | p3=p1; p3=p3+4;
| | |
object_ptr <-+ <-+ <-+ >-+ <-- T var; p4 = &var; можно разыменовывать
| | | |
range_ptr <-+ | <-+ | >-+ <-- ptr=arr+n; ptr=&var+1; можно применять арифметику, но не разыменовывать
| | | | |
match_ptr <-+ <-+ <-+ <-+ <-+ <-- ptr = NULL; можно проверять на равенство
Трактовка одиночных объектов как одноэлементных массивов — от неё можно безболезненно избавиться.
В С++, чтобы к такой схеме придти, нужно налепить разных умных указателей и придерживаться конвенции — оборачивать все источники (new, new[], &) в соответствующие умные типы.
В новых языках — можно вынести на уровень языка (или, если это клон С++, заставить соответствующие выражения возвращать правильный тип).
Причём, обратите внимание: абстрагируясь от голого указателя, мы получаем возможность вводить любую рантайм-проверку и разные бонусы:
— проверять совпадение доменов при сравнении и адресной арифметике
— проверять выход за пределы домена при адресной арифметике и разыменовании
— находить границы домена
— реализовать сборку мусора (поскольку для каждого указателя можно найти голову блока, на середину которого он указывает; даже если этот блок — не массив, а структура)
Здравствуйте, Cyberax, Вы писали:
C>Понимаете, даже у того же Оберона есть _практические_ недостатки:
Ну, так "нет в мире совершенства".
C>2. GC консервативный, а сам язык не особо подходит для точного GC.
GC не консервативный (точнее, почти не консервативный). C>Аналог такого кода:
SomeObject *obj=new SomeObject();
static int ref=(int)obj;
C>вызовет _утечку_ _памяти_.
Именно _такого_ — не вызовет.
Трурль пишет:
> C>2. GC консервативный, а сам язык не особо подходит для точного GC. > GC не консервативный (точнее, почти не консервативный).
Да, ошибся. Объекты в куче он считает точными (это не сложно), а вот
стек — консервативен.
> C>Аналог такого кода: > >SomeObject *obj=new SomeObject(); >static int ref=(int)obj; > > C>вызовет _утечку_ _памяти_. > Именно _такого_ — не вызовет.
А если убрать static, то вызовет (до выхода из стекового фрейма)
Здравствуйте, Дарней, Вы писали:
AVC>>Может быть, в таком случае стоило остановиться на Фортране? Д>Многие так и делают, если переход себя не оправдывает. Но если оправдывает — старый язык бросают без сожалений. Д>Переход на Модулу себя не оправдывал.
Возможно. Важны факторы, принимаемые во внимание.
Вы, часом, — не консервативный гегельянец, не полагаете, что "все разумное — действительно, все действительное — разумно"?
AVC>>В конце концов, это ведь всего лишь разновидность компиляции. Д>С таким же успехом можно сказать, что процесс обычной компиляции — это и есть процесс производства программных продуктов. И за ненадобностью отменить программистов
И какая, пардон, связь?
Вас же не удивляет компиляция в машинный код?
А теперь представьте себе, что какой-нибудь компьютер "понимает" Си++, Си или даже (вот ужас! ) Оберон.
AVC>>Угу. Например, у крупных фармацевтических фирм свои представления о том, какое здоровье у людей им (этим фирмам) желательно. И ведь не подкопаешься — все рационально. Д>Ты хочешь сказать, что они (эти самые фирмы) намеренно портят людям здоровье?
Да.
Т.к. я многодетный отец , то этот вопрос для меня не праздный.
Плюс — у моей жены есть медицинское образование.
AVC>>Если бы Вирт работал на крупную фирму, то "практичность" его творений была бы гарантирована. AVC>>Но его языки были бы хуже. AVC>>Например, были бы такими же как Си++. Д>Это ты тоже очень ловко ввернул. Д>Оберонам до старичка С++ — как до Пекина раком, даже при всех его недостатках.
"Тешь себя, тешь себя" (поглаживает) (с) "Ирония судьбы"
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Cyberax, Вы писали:
>> AVC>>А *сколько*, интересно, стоит такой переход? >> Д>сравнимо со стоимостью полной разработки заново >> Может быть, в таком случае стоило остановиться на Фортране? C>Интересно, почему же большую часть научного софта до сих пор на нем C>пишут?
Ну, так именно это я и имел в виду.
Зачем Си++?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC пишет:
>>> AVC>>А *сколько*, интересно, стоит такой переход? >>> Д>сравнимо со стоимостью полной разработки заново >>> Может быть, в таком случае стоило остановиться на Фортране? > C>Интересно, почему же большую часть научного софта до сих пор на нем > C>пишут? > Ну, так именно это я и имел в виду. > Зачем Си++?
Здравствуйте, Дарней, Вы писали:
AVC>>В конце концов, это ведь всего лишь разновидность компиляции.
Д>С таким же успехом можно сказать, что процесс обычной компиляции — это и есть процесс производства программных продуктов. И за ненадобностью отменить программистов
Нетовский рефлектор достаточно хорошо декомпилирует MSIL код во многие нетовские языки. Так, то выбор только за промежуточным языком, AST итд
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Cyberax, Вы писали:
>>>> AVC>>А *сколько*, интересно, стоит такой переход? >>>> Д>сравнимо со стоимостью полной разработки заново >>>> Может быть, в таком случае стоило остановиться на Фортране? >> C>Интересно, почему же большую часть научного софта до сих пор на нем >> C>пишут? >> Ну, так именно это я и имел в виду. >> Зачем Си++? C>Для тех, кому надоело писать софт на Фортране.
Понимаю.
А как же совместимость?
(Вот, говорят, Модула-2 — это плохо, т.к. несовместимо с Паскалем.)
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC пишет:
>>> Ну, так именно это я и имел в виду. >>> Зачем Си++? > C>Для тех, кому надоело писать софт на Фортране. > Понимаю. > А как же совместимость? > (Вот, говорят, Модула-2 — это плохо, т.к. несовместимо с Паскалем.)
Так вот поэтому ВСЕ и не переписывают
Вообще, С++ создавался как ОО-расширение для С, с сохранением максимума
совместимости. И в этом он вполне преуспел.
Здравствуйте, Cyberax, Вы писали:
>>>> Зачем Си++? >> C>Для тех, кому надоело писать софт на Фортране. >> Понимаю. >> А как же совместимость? >> (Вот, говорят, Модула-2 — это плохо, т.к. несовместимо с Паскалем.) C>Так вот поэтому ВСЕ и не переписывают
Тут не вполне ясно.
Специально не переписывают что-то с Фортрана на Си++, чтобы сохранить совместимость?
В общем, не понял.
C>Вообще, С++ создавался как ОО-расширение для С, с сохранением максимума C>совместимости. И в этом он вполне преуспел.
Да ужъ... (Хотя, кажется, комитет по стандартизации Си не так озабочен совместимостью с Си++. Страуструп жалуется. Хотя еще надеется.)
Как бы-то ни было, если на вопрос "Зачем Си++" отвечают "Потому что Си", то возникает следующий вопрос: "Зачем Си?"
Зачем вообще что-то кроме Фортрана, если уж так важна совместимость?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC пишет:
>>> А как же совместимость? >>> (Вот, говорят, Модула-2 — это плохо, т.к. несовместимо с Паскалем.) > C>Так вот поэтому ВСЕ и не переписывают > Тут не вполне ясно. > Специально не переписывают что-то с Фортрана на Си++, чтобы сохранить > совместимость?
Да, много фортрановского софта не переписывают на другие языки из-за
библиотек.
> C>Вообще, С++ создавался как ОО-расширение для С, с сохранением максимума > C>совместимости. И в этом он вполне преуспел. > Да ужъ... (Хотя, кажется, комитет по стандартизации Си не так озабочен > совместимостью с Си++. Страуструп жалуется. Хотя еще надеется.)
Это уже из "современной истории"
> Как бы-то ни было, если на вопрос "Зачем Си++" отвечают "Потому что > Си", то возникает следующий вопрос: "Зачем Си?"
Потому что на нем к середине 80-х годов было уже написана и работала
большая часть софта.
> Зачем вообще что-то кроме Фортрана, *если уж так важна совместимость*?
Serginio1,
> Нетовский рефлектор достаточно хорошо декомпилирует MSIL код во многие нетовские языки. Так, то выбор только за промежуточным языком, AST итд
Я недавно экспериментировал с этим делом. Например, на C++/CLI сделал индексированное свойство, возвращающее managed pointer. Reflector это дело честно в C# отобразил, дописав в возвращаемом значении ref. Но это же не значит, что на C#, действительно, можно так писать (в частности, это индексированное свойство C# "потреблять" отказался)
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Кодт, Вы писали:
AVC>>Самое простой вопрос: как должен реагировать компилятор на следующие конструкции?
AVC>>void foo(int *p)
AVC>>{
AVC>> p[4] = 21; /* как узнать - массив p или нет? */
AVC>> p++;
AVC>>}
или
void foo(int *p)
AVC>>{
AVC>> free(p); /* указывет p на объект кучи, или это адрес переменной в стеке или сегменте данных? */
AVC>>}
К>Пожалуй, тут просто необходимо ввести такое понятие, как домен (область определения) указателя. К>Уточнение происходит следующим образом (извините за корявость изложения идеи) К>
К>модель "Указатель" / "Ссылка" (можно разыменовывать)
К> <- модель "Указатель на тип T" (результат разыменования - объект T)
К> <- тип T*, some_container::iterator и т.п.
К> <- домен "объект в динамической памяти", "объект-агрегат", (статический, стековый, член, элемент массива)
К> <- домен "элемент конкретного массива" (или одиночный элемент), "голова массива", "хвост массива", ноль
К>
К>В скриптовых языках ограничиваются моделью "указатель". К>В С/С++ — типом указателя. К>В Обероне — доменом "динамический/статический", получая разные типы.
К>Наверное, при желании можно детализировать, хотя бы различая голову, середину и хвост массива. К>
К>тип допустимые приведения пример инициализации функциональность
К>new_array >-+ <-- p1 = new T[10]; можно применять delete[] p1;
К> |
К>new_object | >-+ <-- p2 = new T; можно применять delete p2;
К> | |
К> | |
К>array_ptr <-+ | >-+ <-- T arr[10]; p3 = arr; можно применять адресную арифметику и разыменовывать
К> | | | p3=p1; p3=p3+4;
К> | | |
К>object_ptr <-+ <-+ <-+ >-+ <-- T var; p4 = &var; можно разыменовывать
К> | | | |
К>range_ptr <-+ | <-+ | >-+ <-- ptr=arr+n; ptr=&var+1; можно применять арифметику, но не разыменовывать
К> | | | | |
К>match_ptr <-+ <-+ <-+ <-+ <-+ <-- ptr = NULL; можно проверять на равенство
К>
К>Трактовка одиночных объектов как одноэлементных массивов — от неё можно безболезненно избавиться.
К>В С++, чтобы к такой схеме придти, нужно налепить разных умных указателей и придерживаться конвенции — оборачивать все источники (new, new[], &) в соответствующие умные типы. К>В новых языках — можно вынести на уровень языка (или, если это клон С++, заставить соответствующие выражения возвращать правильный тип).
К>Причём, обратите внимание: абстрагируясь от голого указателя, мы получаем возможность вводить любую рантайм-проверку и разные бонусы: К>- проверять совпадение доменов при сравнении и адресной арифметике К>- проверять выход за пределы домена при адресной арифметике и разыменовании К>- находить границы домена К>- реализовать сборку мусора (поскольку для каждого указателя можно найти голову блока, на середину которого он указывает; даже если этот блок — не массив, а структура)
В принципе, идея мне кажется разумной.
Но что особенно радует в предлагаемом подходе — его простота.
Правда, в Обероне таких проблем вообще нет. (Он просто грамотно сделан.)
Но ведь это такой скучный язык.
А вот Си++ — это романтика.
Ну где еще можно "зацепить" один поток за стековую переменную другого потока? Такая прелесть!
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Честно говоря, я все еще не понял проблемы?
AVC>Самое простой вопрос: как должен реагировать компилятор на следующие конструкции?
AVC>void foo(int *p)
AVC>{
AVC> p[4] = 21; /* как узнать - массив p или нет? */
AVC> p++;
AVC>}
Он должен реагировать на эти конструкции, как это описано в стандарте (ну это в общем и без меня понятно).
Массив или нет? Я всегда полагал, что подобные вопросы решаются в описании функции, которое в любом случае должно присутствовать и описывать, что делает эта функция. Программист, который пишет эту функцию должен знать, что он подразумавет под р.
Адресная арифметика — низкоуровневая возможностью. Вы считаете, что она вредна?
P.S. Возможно, что я что-то упускаю, но проблемы не вижу.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Serginio1,
>> Нетовский рефлектор достаточно хорошо декомпилирует MSIL код во многие нетовские языки. Так, то выбор только за промежуточным языком, AST итд
ПК>Я недавно экспериментировал с этим делом. Например, на C++/CLI сделал индексированное свойство, возвращающее managed pointer. Reflector это дело честно в C# отобразил, дописав в возвращаемом значении ref. Но это же не значит, что на C#, действительно, можно так писать (в частности, это индексированное свойство C# "потреблять" отказался)
Ну что то похожее же выдал.
Ну он много чего не умеет.
Например
public static unsafe object Box(void* ptr, Type type)
{
if (type == null)
{
throw new ArgumentNullException("type");
}
if (!type.IsPointer)
{
throw new ArgumentException(Environment.GetResourceString("Arg_MustBePointer"), "ptr");
}
Pointer pointer1 = new Pointer();
pointer1._ptr = ptr;
pointer1._ptrType = type;
return pointer1;
}
function Pointer.Box(ptr: *; type: Type): TObject;
var
pointer1: Pointer;
begin
if (&type = nil) then
raise ArgumentNullException.Create('type');
if (not &type.IsPointer) then
raise ArgumentException.Create(Environment.GetResourceString('Arg_MustBePointer'), 'ptr');
pointer1 := Pointer.Create;
pointer1._ptr := ptr;
pointer1._ptrType := &type;
begin
result := pointer1;
exit
end
end;
А вообще то из С# можно сделать конфетку не уступающей по возможностям C++/CLI.
Например поводу боксинга. Например в яве есть аналоги отбоксенных валуе типов начинающиеся с большой буквы, правда там нет структур.
Мне например был бы приятен смнтаксис Delphi
type
PMyStruct = box MyStructSt
PInt = box int;
итд. Вообщето впечатление такое, что C# явно придерживается, о чем кстати возмущался Рихтер.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня