информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяВсе любят медСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
>Процесс разработки ПО и ЯП 04.05.04 12:44  Число просмотров: 3180
Автор: null666 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Процесс разработки ПО и ЯП
> Костин Г.В.

> Все в этой книге может оказаться ошибкой.
> Р. Бах. Иллюзии
"Каждый имеет право написать книгу и каждый имеет право её не читать!" (с)кто-то неглупый

Господи, очередной "критик" с претензиями к "плюсам". Вы случаем на http://www.delphikingdom.ru не ошиваетесь? Слишком уж пропахший стиль. Попытки тщательно замаскировать дифирамбы Виртовским языкам не удались - заметили, имхо, все.

Применю грязный приём (оттуда же): если он Вам так не нравится, то какого чёрта Вы про него пишите? Не можете бросить? Ну бывает... Процесс разработки ПО говорите? Ну что же, я согласен, написано у Вас немножко (судя по скроллу - 30% статьи - не больше). За исключением прямоугольника - давно известные факты. Может быть следовало как-то расширить этот раздел?

>Лёгкость понимания программы человеком. Компьютер программу компилирует, а читает и
>модифицирует её человек. Успешность этого процесса в значительной степени зависит от легкости
>понимания программы. В частности, синтаксиса языка. "
Полностью согласен. И вот тут-то как раз языки Вирта сливают. Они разработаны не для человека - они разработаны для компилятора. От и до. Я не знаю каким нужно быть извращенцем, чтобы заменить наиболее часто используемый оператор присваивания на крайне трудную в наборе последовательность. Зато с точки зрения компилятора - абсолютно всё равно и крайне удобно. Крайняя линейность и рубленность конструкций (чаще всего не более двух-трёх операций в строке), безусловно выравнивает ситуацию с чтением программ, но ощущение, что ты вынужден размеренно шагать по коридору выбранному компилятором - не покидает. Modula и Oberon (знаком только по спецификациям и публикациям на пресловутом http://www.delphikingdom.ru) вызывают абсолютно те же чувства.

>ЯП языки - явление прежде всего социальное, а научное. Умозрительные критерии и оценки
>достоинств и недостатков языков, по меньшей мере, неубедительны - основной критерий: практика
> массового использования.
Перед словом "научное" видимо пропущено "не".
Вы идёте по скользкой дорожке перманентной критики а-ля Windows из разряда "ёжики плакали, кололись, но продолжали есть кактус". Массовость использования отнюдь не показатель.

>Единственное требование к использованию языка - это адекватность применения.
А вот это уже на 5 баллов! ^_^ b

>Наиболее верный путь к успеху - использование чистого объектно - ориентированного языка
Использование чистых объектно-ориентированных языков также не приводит ни к чему хорошему. Автор (Ян Джойнер) либо апологет чистого объектно-ориентированного подхода, либо ни разу не программировал на чистых объектно-ориентированных языках. Использование бесконечных классов, интерфейсов и пр. перегружает программу как лексически, так и логически. Банальное описание точки входа в программу занимает половину экрана. Спор из разряда goto и рекурсии. Да, без этого вполне можно обойтись, но порой решение с применением данных парадигм является самым простым и понятным.

>На x86, к примеру, это ничего не дает. И A=B++ и A:=B; inc(b); приведут к командам ассемблера
>MOV a,b; inc b
Неправда Ваша. Во-первых в Виртовских языках идеологически верным является написание A:=B; B:=B+1; Во-вторых то что Вы привели в качестве примера ассемблерного аналога - не более, чем дань моде и необходимости. Причём хочется заметить, что Паскалевская конструкция inc(b); вовсе необязательно будет интерпретирована как ассемблерная инструкция inc b - дело в том, что inc является библиотечной функцией, а посему её поведение никоим образом не зависит от Ваших (да и Вирта тоже) желаний.

>Вирт писал что : "...язык должен определяться в терминах математических, абстрактных концепций
>И только, если язык удовлетворяет этому критерию, он может считаться высокоуровневым."
Встречалось. Только вот в математических абстрактных концепциях нет места такой банальщине, как inc, оптимизация челочисленного умножения путем замены сдвигом битового представления числа... Да что там говорить - в математике понятием класса и то не пооперируешь. Видимо поэтому-то Вирт в своём развитии и остановился на уровне процедур - они вполне вписываются в стройные математические модели.

>Изменяющиеся от платформы к платформе размеры типов данных.
А что Delphi уже научился обеспечивать Integer одинаковым на всех платформах? Не смешите!

>int i=0,ar[2]={10,11};
>i=ar[i++];// А кто сразу скажет чему равно значение i
10. Столь любимая Виртом строгая математическая концепция приоритета операторов срабатывает безукоризненно. В отличие от следующей конструкции: IF a>4 AND a<6 THEN ...;

>Если заменить short int на longt int, то придется менять и printf("%d\n",x) на printf("%D\n",x)
Чуть выше был cout, а тут вдруг printf. Либо Вы грязно передёргиваете, либо сам себе злобный буратино. Оба случая полностью на Вашей совести.

>Отсутствует логический тип данных.
RTFM. Уже давным-давно существует.

>А что может значить, по Вашему мнению, команда a=24[ar]; ?
>При условии, что int ar[50]; int a; она полностью эквивалентна a:=ar[24];
Опять же с точки зрения математической логики - абсолютно верная конструкция. Ибо сложение, как водится, коммутативно - если Вы этого не знали - нужно было меньше в школе уроки прогуливать.

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

>Что вполне логично, т.к. проверка у процессоров 80x86 реализуются на аппаратном уровне.
Вы багтрак-то читаете? Если всё так шоколадно с аппаратной проверкой выхода за границы массива, то откуда все эти buffer overflow?

>Да и вынести низкоуровневый код, в отдельный модуль написанный, допустим, на ассемблере не
>составляет проблем
Вы пробовали это отлаживать??? Уж не говоря о том, что в этом случае нужен программист со знанием двух языков, ну или два программиста...

>Но ведь и заметного проигрыша тоже нет ?
Для некоторых задач и разница в 5% является крайне значимой.

В общем как уже сказал кто-то до меня - можно привести кучу подобных аргументов против Вирта. И правда напоминаете студента почему-то обидевшегося на С++.
<site updates>
Процесс разработки ПО и ЯП 11.10.03 19:59  
Publisher: dl <Dmitry Leonov>
<"чистая" ссылка>
Процесс разработки ПО и ЯП
Костин Г.В.

Все в этой книге может оказаться ошибкой.
Р. Бах. Иллюзии
Здесь привожу некоторые фрагменты из проведенного мной анализа ЯП (несколько сот страниц; с охватом от Assembler до Zhell, от архитектуры процессоров до языков сценариев и от Fortran до C#). Обратная связь приветствуется. Будут интересны мнения, ссылки на литературу, конструктивная критика... Я с удовольствием рассмотрю предложения об обучении в вашем ВУЗе /участие в конференции/ работе связанной с анализом ЯП/Информации о заинтересованных лицах. E - mail автора: georgii"Nospam"@pisem.net. Естественно, перед отправкой писем строчку "Nospam" необходимо убрать.
С полным оглавлением данного исследования можно ознакомиться здесь. [ .keep/languages.content.html ] Что есть язык?
Для начала ответим на вопрос: Что есть язык ?
Язык - это интерфейс между двумя субъектами
Примеры: Человеческий язык - совокупность (слова, жесты, телодвижения, интонаций и мимики). Интерфейсы (мышка, пользователя, API) ...

Полный текст
По-моему, у автора просто немного не сложилось с С и С++... 06.05.04 20:19  
Автор: lzd Статус: Незарегистрированный пользователь
<"чистая" ссылка>
По-моему, у автора просто немного не сложилось с С и С++. ^_^
Во-первых, он их слабо различает. Во-вторых, явно нет серьезного опыта работы с этими языками.
А в-третьих, хотелось бы видеть больше запятых и меньше грамматических ошибок. Раз уж взялись серьезные статьи писать.
>Процесс разработки ПО и ЯП 04.05.04 12:44  
Автор: null666 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Процесс разработки ПО и ЯП
> Костин Г.В.

> Все в этой книге может оказаться ошибкой.
> Р. Бах. Иллюзии
"Каждый имеет право написать книгу и каждый имеет право её не читать!" (с)кто-то неглупый

Господи, очередной "критик" с претензиями к "плюсам". Вы случаем на http://www.delphikingdom.ru не ошиваетесь? Слишком уж пропахший стиль. Попытки тщательно замаскировать дифирамбы Виртовским языкам не удались - заметили, имхо, все.

Применю грязный приём (оттуда же): если он Вам так не нравится, то какого чёрта Вы про него пишите? Не можете бросить? Ну бывает... Процесс разработки ПО говорите? Ну что же, я согласен, написано у Вас немножко (судя по скроллу - 30% статьи - не больше). За исключением прямоугольника - давно известные факты. Может быть следовало как-то расширить этот раздел?

>Лёгкость понимания программы человеком. Компьютер программу компилирует, а читает и
>модифицирует её человек. Успешность этого процесса в значительной степени зависит от легкости
>понимания программы. В частности, синтаксиса языка. "
Полностью согласен. И вот тут-то как раз языки Вирта сливают. Они разработаны не для человека - они разработаны для компилятора. От и до. Я не знаю каким нужно быть извращенцем, чтобы заменить наиболее часто используемый оператор присваивания на крайне трудную в наборе последовательность. Зато с точки зрения компилятора - абсолютно всё равно и крайне удобно. Крайняя линейность и рубленность конструкций (чаще всего не более двух-трёх операций в строке), безусловно выравнивает ситуацию с чтением программ, но ощущение, что ты вынужден размеренно шагать по коридору выбранному компилятором - не покидает. Modula и Oberon (знаком только по спецификациям и публикациям на пресловутом http://www.delphikingdom.ru) вызывают абсолютно те же чувства.

>ЯП языки - явление прежде всего социальное, а научное. Умозрительные критерии и оценки
>достоинств и недостатков языков, по меньшей мере, неубедительны - основной критерий: практика
> массового использования.
Перед словом "научное" видимо пропущено "не".
Вы идёте по скользкой дорожке перманентной критики а-ля Windows из разряда "ёжики плакали, кололись, но продолжали есть кактус". Массовость использования отнюдь не показатель.

>Единственное требование к использованию языка - это адекватность применения.
А вот это уже на 5 баллов! ^_^ b

>Наиболее верный путь к успеху - использование чистого объектно - ориентированного языка
Использование чистых объектно-ориентированных языков также не приводит ни к чему хорошему. Автор (Ян Джойнер) либо апологет чистого объектно-ориентированного подхода, либо ни разу не программировал на чистых объектно-ориентированных языках. Использование бесконечных классов, интерфейсов и пр. перегружает программу как лексически, так и логически. Банальное описание точки входа в программу занимает половину экрана. Спор из разряда goto и рекурсии. Да, без этого вполне можно обойтись, но порой решение с применением данных парадигм является самым простым и понятным.

>На x86, к примеру, это ничего не дает. И A=B++ и A:=B; inc(b); приведут к командам ассемблера
>MOV a,b; inc b
Неправда Ваша. Во-первых в Виртовских языках идеологически верным является написание A:=B; B:=B+1; Во-вторых то что Вы привели в качестве примера ассемблерного аналога - не более, чем дань моде и необходимости. Причём хочется заметить, что Паскалевская конструкция inc(b); вовсе необязательно будет интерпретирована как ассемблерная инструкция inc b - дело в том, что inc является библиотечной функцией, а посему её поведение никоим образом не зависит от Ваших (да и Вирта тоже) желаний.

>Вирт писал что : "...язык должен определяться в терминах математических, абстрактных концепций
>И только, если язык удовлетворяет этому критерию, он может считаться высокоуровневым."
Встречалось. Только вот в математических абстрактных концепциях нет места такой банальщине, как inc, оптимизация челочисленного умножения путем замены сдвигом битового представления числа... Да что там говорить - в математике понятием класса и то не пооперируешь. Видимо поэтому-то Вирт в своём развитии и остановился на уровне процедур - они вполне вписываются в стройные математические модели.

>Изменяющиеся от платформы к платформе размеры типов данных.
А что Delphi уже научился обеспечивать Integer одинаковым на всех платформах? Не смешите!

>int i=0,ar[2]={10,11};
>i=ar[i++];// А кто сразу скажет чему равно значение i
10. Столь любимая Виртом строгая математическая концепция приоритета операторов срабатывает безукоризненно. В отличие от следующей конструкции: IF a>4 AND a<6 THEN ...;

>Если заменить short int на longt int, то придется менять и printf("%d\n",x) на printf("%D\n",x)
Чуть выше был cout, а тут вдруг printf. Либо Вы грязно передёргиваете, либо сам себе злобный буратино. Оба случая полностью на Вашей совести.

>Отсутствует логический тип данных.
RTFM. Уже давным-давно существует.

>А что может значить, по Вашему мнению, команда a=24[ar]; ?
>При условии, что int ar[50]; int a; она полностью эквивалентна a:=ar[24];
Опять же с точки зрения математической логики - абсолютно верная конструкция. Ибо сложение, как водится, коммутативно - если Вы этого не знали - нужно было меньше в школе уроки прогуливать.

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

>Что вполне логично, т.к. проверка у процессоров 80x86 реализуются на аппаратном уровне.
Вы багтрак-то читаете? Если всё так шоколадно с аппаратной проверкой выхода за границы массива, то откуда все эти buffer overflow?

>Да и вынести низкоуровневый код, в отдельный модуль написанный, допустим, на ассемблере не
>составляет проблем
Вы пробовали это отлаживать??? Уж не говоря о том, что в этом случае нужен программист со знанием двух языков, ну или два программиста...

>Но ведь и заметного проигрыша тоже нет ?
Для некоторых задач и разница в 5% является крайне значимой.

В общем как уже сказал кто-то до меня - можно привести кучу подобных аргументов против Вирта. И правда напоминаете студента почему-то обидевшегося на С++.
Процесс разработки ПО и ЯП 31.10.03 13:15  
Автор: читатель Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Абсолютно неясно, при чём здесь "Процесс разработки ПО и ЯП". Такое ощущение (извините за резкость), что автор - студент N-го курса, получивший "неуд" за знание С/С++, и теперь пытающийся убедить окружающих в том, что С/С++ сложный, малоупотребительный язык. А как,интересно , будет выглядеть статья по ассемблеру?
Процесс разработки ПО и ЯП 12.11.03 15:26  
Автор: Георгий Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Абсолютно неясно, при чём здесь "Процесс разработки ПО и
> ЯП".
А начало статьи ты не читал ?
Такое ощущение (извините за резкость), что автор -
> студент N-го курса, получивший "неуд" за знание С/С++, и
Вообще-то автомат у меня был по C++
> теперь пытающийся убедить окружающих в том, что С/С++
> сложный, малоупотребительный язык.
И приводящий при этом цитаты в его пользу.
А как,интересно , будет
> выглядеть статья по ассемблеру?
Ну вообщето есть такая глава. И критики в ней нет абсолютно.
Процесс разработки ПО и ЯП 16.10.03 12:04  
Автор: Serge Sereda Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Процесс разработки ПО и ЯП
> Костин Г.В.


Начало статьи не соответствует её завершению. "Начали за здравие, а кончили за упокой".
Название: "Процесс разработки ПО и ЯП", а статья сведена к анализу плюсов и минусов "плюсов" (пардон за каламбур ;-)
Не учтены требования Законов Развития Технических систем (напр. http://cie.ase.md/~sereda/os_devel.htm или http://consumer.nm.ru/os_devel.htm).

Кроме того, крайне спорны утверждения об умении отдельных представителей Homo Sapiens Sapiens ходить по воде и превращать воду в вино ;-)

>Интересен сравнительный анализ ЯП и компиляторов и вообще всё
>что с этим связанно.

Вот описание полностью отечественной системы компиляции, интерпретации и анализа программ на С/С++, там частично приведён сравнительный анализ С++ и Ада95.
http://www.interstron.ru/txt/PaperEAZ_Autoref_Ru.htm

>В частности связь с психологией. Очень
>интересно отличие "у нас" и " за бугром".

С психологией технические системы не должны быть связаны никак.
Так же как и процесс их развития (http://www.bugtraq.ru/library/misc/invent.html).

>Интересуют также координаты людей и организаций, в чьи
>профессиональные и научные интересы входят ЯП.

Пока могу указать только http://www.interstron.ru/


С уважением,

Сергей Середа
serge_sereda 'at' hotmail.com
Процесс разработки ПО и ЯП 13.10.03 12:45  
Автор: читатель Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Процесс разработки ПО и ЯП ?
Совершенно непонятно почему автор выбрал такое название статьи.
На мой взгляд статья должна была бы называться как-то вроде "N-цать неубедительных аргументов, доказывающих, что С и С++ суть отстой".
Очень многое "притянуто за уши" 12.10.03 16:54  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Все в этой книге может оказаться ошибкой.

Например, мне было очевидно, что анализ не слишком непредвзятый. Автору не нравятся C/C++, но аргументы выбраны не самые лучшие.

Сначала возникло желание поквотить чуть ли не весь текст и прокомментировать с другой позиции (мне C/C++ нравятся). Потом сдержался :-), потому как потом бы самого себя оштрафовал бы за оверквотинг :-)
интересно, сам автор пробовал скомпилировать программку-Basic? :))) 10.11.03 13:33  
Автор: serg2 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
нормальные компиляторы не пропускают switch (...) { break; ... }
и вполне справедливо сообщают что дальнейшие команды unreachable :)
это, увы, сильно подрывает доверие к уровню компетентности автора и его рассуждениям.
интересно ?-пробовал 12.11.03 15:23  
Автор: Георгий Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> нормальные компиляторы не пропускают switch (...) { break;
А я на ненормпльном GNU C по Linux ;)
И работает
увы 29.12.03 12:45  
Автор: serg2 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> А я на ненормпльном GNU C по Linux ;)
> И работает

ну дак и я на ненормальном:) конечно оно все поправимо и потом запускаемо, но в исходном виде (copy-paste из текста статьи) дает такой результат:
GNU C version 2.95.4 20011002 (Debian prerelease) (i386-linux) compiled by GNU C version 2.95.4 20011002 (Debian prerelease).
test.c: In function `main':
test.c:12: parse error before `;'
test.c:13: warning: unreachable code at beginning of switch statement
test.c:15: parse error before `;'

---
Не знаю, с некоторыми тезисами я вынужден согласиться. 12.10.03 17:01  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
Но анализ говорит о том, что автор занимался C/C++ весьма поверхностно. Фраза "Элементарные операции со строками требуют знакомства с STL и шаблонами." меня порядком развлекла :)
C *некотороми* и я согласен. 12.10.03 18:01  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Но анализ говорит о том, что автор занимался C/C++ весьма
> поверхностно. Фраза "Элементарные операции со строками
> требуют знакомства с STL и шаблонами." меня порядком
> развлекла :)
Но сейчас просто что вспомню:

1) Два простейших цикла до 4-х миллиардов и рандом внутри. Скорость зависит от реализации самого rand, а не от того как язык компилит циклы (уж
это умеет делать компилятор любого языка). Если бы там был "правильный" рандом на MD5 к примеру, разница в скорости была бы еще больше.

2) Мутная прога. Непонятную программу можно написать на любом языке (и на виртовской линейке тоже), а вот эффективную - не всегда. То что это МОЖНО сделать не значит, что это следует делать.

3) for, который на самом деле можно сделать while-ом: покажите такой язык программирования, где нельзя.

4) Избыточность. То бишь наличие в C++ сходных и по функциям и (самое интересное) по получаемым результатам механизмов. Спорно. Чаще всего те или иные механизмы позиционируются на разных участках шкалы скорость-используемая память. Практически любую задачу, реализованную с помощью виртуальных функций можно переписать на шаблонах и наоборот, но шаблоны совсем не то же самое, что виртуальные функции.

5) Множственное наследование. Как аргумент против него: возможна ситуация, которую придется обходить. Ага. А если жить на улице, то квартиру не ограбят. Кроме того, вилкой можно выколоть себе глаз, так что давайте есть руками. Множественное наследование не исключает одиночное, а дополняет его. Никто не заставляет пользоваться множестенным наследованием, если не умеешь.

6) Критика printf-а. Следует различать сам язык и его библиотеку (хотя она тоже входит в стандарт языка). printf является обычной функцией, реализованной на языке. Иначе реализовать было просто нельзя. В паскале же ввод/вывод вообще введен в сам язык (в этом месте можно перечитать аргументы против страуструповского желания ввести в C++, причем не в язык, а в библиотеку, инстременты для создания GUI и работы с DB - автор непоследователен, вирту можно, страуструпу нельзя)

7) Для меня END LOOP ничуть не более понятен, чем } (если циклов, скажем штуки 4), но при этом набирать его гораздо дольше. Для обеспечения понятности во первых принято за закрывающей скобкой писать комментарий, к чему она относилась, во вторых все современные IDE позволяют быстро перейти к парной скобке - посмотреть чего там такое и вернуться обратно. Причем делается это горячими клавишами за пару секунд.

И т.д.. Сейчас больше не вспомню. Кое какие аргументы действительно имеют резон, но БОЛЬШИНСТВО не выдерживают критики. Скажем так, я встречал и более качественную критику C++, к которой я подкопаться не мог. Точно так же как встречал критику паскаля и других виртовских языков.
C *некотороми* и я согласен. 12.10.03 21:32  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
> 3) for, который на самом деле можно сделать while-ом:
> покажите такой язык программирования, где нельзя.
Не. Речь о том, чтобы использовать for для обхода некоего набора величин. А там товарищ привел классическую для C бяку, когда начинающие в приращение цикла начинают пихать что ни попадя. Действительно не слишком хорошая вещь, хотя в ряде случаев как раз эта возможность может быть весьма полезной. В общем, как обычно - любым мощным инструментом надо уметь пользоваться...

> 4) Избыточность. То бишь наличие в C++ сходных и по
> функциям и (самое интересное) по получаемым результатам
> механизмов. Спорно. Чаще всего те или иные механизмы
> позиционируются на разных участках шкалы
> скорость-используемая память. Практически любую задачу,
> реализованную с помощью виртуальных функций можно
> переписать на шаблонах и наоборот, но шаблоны совсем не то
> же самое, что виртуальные функции.
Ну нет, про виртуальные функции и шаблоны я категорически не согласен, но об этом в аську либо в приват, потому что это долго :)

> 5) Множственное наследование. Как аргумент против него:
> возможна ситуация, которую придется обходить. Ага. А если
> жить на улице, то квартиру не ограбят. Кроме того, вилкой
> можно выколоть себе глаз, так что давайте есть руками.
> Множественное наследование не исключает одиночное, а
> дополняет его. Никто не заставляет пользоваться
> множестенным наследованием, если не умеешь.
Ну здесь я опять-таки не могу однозначно сказать что-то. В целом я вынужден согласиться с автором статьи, что множественное наследование - да, спорно. Причем и идея, и реализация в случае C++. По сравнению, например, с CLOS, в C++ множнаследование выглядит убого.

> 6) Критика printf-а. Следует различать сам язык и его
> библиотеку (хотя она тоже входит в стандарт языка). printf
> является обычной функцией, реализованной на языке. Иначе
> реализовать было просто нельзя. В паскале же ввод/вывод
> вообще введен в сам язык (в этом месте можно перечитать
> аргументы против страуструповского желания ввести в C++,
> причем не в язык, а в библиотеку, инстременты для создания
> GUI и работы с DB - автор непоследователен, вирту можно,
> страуструпу нельзя)
Ну там автор вообще плохо провел черту между языком и библиотекой :)

> 7) Для меня END LOOP ничуть не более понятен, чем } (если
> циклов, скажем штуки 4), но при этом набирать его гораздо
> дольше. Для обеспечения понятности во первых принято за
> закрывающей скобкой писать комментарий, к чему она
> относилась, во вторых все современные IDE позволяют быстро
> перейти к парной скобке - посмотреть чего там такое и
> вернуться обратно. Причем делается это горячими клавишами
> за пару секунд.
Правильно, точно так же как все современные IDE от END LOOP позволяют перескочить на начало цикла и обратно. Короче, дело вкуса.

> И т.д.. Сейчас больше не вспомню. Кое какие аргументы
> действительно имеют резон, но БОЛЬШИНСТВО не выдерживают
> критики. Скажем так, я встречал и более качественную
> критику C++, к которой я подкопаться не мог. Точно так же
> как встречал критику паскаля и других виртовских языков.
Это да.
Нет, почему же, мне, например, это тоже интересно. Давайте... 16.05.04 15:17  
Автор: feldgendler Статус: Незарегистрированный пользователь
<"чистая" ссылка>

> > Практически любую задачу,
> > реализованную с помощью виртуальных функций можно
> > переписать на шаблонах и наоборот, но шаблоны совсем
> > не то же самое, что виртуальные функции.

> Ну нет, про виртуальные функции и шаблоны я категорически
> не согласен, но об этом в аську либо в приват, потому что
> это долго :)

Нет, почему же, мне, например, это тоже интересно. Давайте обсудим виртуальные функции и шаблоны?

> > 7) Для меня END LOOP ничуть не более понятен, чем }
> > (если циклов, скажем штуки 4), но при этом набирать его
> > гораздо дольше. Для обеспечения понятности во первых
> > принято за закрывающей скобкой писать комментарий,
> > к чему она относилась, во вторых все современные IDE
> > позволяют быстро перейти к парной скобке - посмотреть
> > чего там такое и вернуться обратно. Причем делается это
> > горячими клавишами за пару секунд.

> Правильно, точно так же как все современные IDE от END LOOP
> позволяют перескочить на начало цикла и обратно. Короче,
> дело вкуса.

Господа, я всё понимаю, но какое отношение имеют эти, чисто косметические, различия к сравнительному анализу языков? Аргументы наподобие "а ещё в паскале оператор присваивания := дурацкий" или "а в C идиотские фигурные скобки вместо нормальных begin ... end" идут в ход на предпоследней стадии holy wars, непосредственно перед переходом на личности и собственно мордобоем.
Если кратко: виртуальные функции обеспечивают полиморфизм времени выполнения, а шаблоны - полиморфизм времени компиляции. 16.05.04 21:51  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
>
> > > Практически любую задачу,
> > > реализованную с помощью виртуальных функций можно
> > > переписать на шаблонах и наоборот, но шаблоны
> совсем
> > > не то же самое, что виртуальные функции.
>
> > Ну нет, про виртуальные функции и шаблоны я
> категорически
> > не согласен, но об этом в аську либо в приват, потому
> что
> > это долго :)
>
> Нет, почему же, мне, например, это тоже интересно. Давайте
> обсудим виртуальные функции и шаблоны?
Есть подозрение, что это уже интересно только вам :) Так что опять же можно воспользоваться приватом либо аськой либо почтой :) Краткое выражение моей позиции - в сабже.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach