Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2007.08.26;
Скачать: [xml.tar.bz2];

Вниз

Кто что думает?   Найти похожие ветки 

 
Zagaevskiy ©   (2007-06-03 11:54) [0]


Создатели Cи и UNIX признают, что разыграли весь мир

    В заявлении, потрясшем весь компьютерный  мир,  Кен  Томпсон,  Деннис
Ричи и Брайан Керниган признали, что  операционная  система  UNIX  и  язык
программирования   Си,   созданные   ими   --   тщательно   спланированный
первоапрельский розыгрыш,  "продержавшийся"  более  20  лет.  Выступая  на
последнем Конгрессе разработчиков программного обеспечения  для  ОС  ДЕМОС
(UnixWorld Software Development Forum), Томпсон признал следующее:

    "В 1969 году AT&T завершила работу над проектом операционной  системы
Multics (известная операционная система  60-х,  см.  прим.2)  Брайан  и  я
только что начали работу с  ранней  реализаций  Паскаля,  разработанной  в
лаборатории  проф.  Вирта  в  Швейцарии,  и  находились  под  впечатлением
элегантности, простоты  и  мощи  этого  языка.  Деннис  как  раз  прочитал
"Уставший  от  колец",  веселую  сатиру  на  знаменитую  трилогию  Толкина
"Властелин колец" (*1*). Ради шутки мы решили написать  пародии  на  среду
Multics и Паскаль. Деннис и я отвечали за  операционную  среду.  Глядя  на
Multics, мы спроектировали новую систему настолько сложной  и  запутанной,
чтобы максимально "испортить жизнь" рядовым пользователям, назвали ее UNIX
как пародию  на  Multics,  добавив  много  других  достаточно  рискованных
аналогий.
    Затем Деннис и Брайан разработали по-настоящему  извращенный  диалект
Паскаля, назвав его "A". Когда мы  обнаружили,  что  другие  действительно
пытаются писать программы на A, мы  быстро  добавили  еще  парочку  хитрых
примочек, создав B, BCPL,  и,  наконец,  Си.  Мы  остановились,  добившись
успешной компиляции следующего:

   for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

    Мы не могли даже  представить,  что  современные  программисты  будут
пытаться  использовать  язык,  допускающий  подобный  оператор!  Мы   даже
собирались  продать  все  это  Советам,  чтобы   отбросить   развитие   их
компьютерного дела на 20 лет  назад  (*2*).  Представьте  наше  удивление,
когда  AT&T,  а  также  другие  американские  корпорации  начали  пытаться
использовать UNIX и  Си!  Более  20  лет  ушло  на  то,  чтобы  приобрести
достаточный  опыт  для  создания  хоть  немного  полезных   приложений   с
использованием  этой  технологической  пародии  60-х.  Мы  были   поражены
упорством  и  целеустремленностью  (если  не  чувством  здравого   смысла)
типичного программиста, использующего  UNIX  и/или  Си.  В  любом  случае,
Брайан, Деннис и я в  течение  последних  лет  работали  исключительно  на
Паскале в среде Apple Macintosh и чувствуем себя по-настоящему  виноватыми
в том хаосе, путанице и действительно скверном программировании,  причиной
которых явилась наша неудачная шутка столько лет тому назад."

    Большинство поставщиков версий UNIX и Си,  включая  AT&T,  Microsoft,
Hewlett-Packard, GTE, NCR, DEC, отказались комментировать это выступление.
Borland International, ведущий производитель инструментальных средств  для
Паскаля и Си, включая популярные Турбо Паскаль, Турбо  Си  и  Турбо  Си++,
заявил, что они давно подозревали это и  будут  продолжать  улучшать  свои
разработки для Паскаля и  прекратят  дальнейшие  усилия  по  развитию  Си.
Официальный  представитель  IBM  разразился  безудержным  хохотом  и   был
вынужден отменить спешно собранную конференцию о судьбе RS6000 заявив, что
"VM появится в ближайшее время". В непонятом аудиторией кратком  сообщении
проф. Вирт, отец Паскаля, Модулы-2 и Оберона, сказал лишь, что некто  P.T.
Barnum был прав.
    Кстати, из обычно совершенно надежных источников стало известно,  что
подобное признание возможно скоро последуют от Вильяма Гейтса относительно
MS-DOS и Windows. Не случайно, вышеупомянутый представитель IBM уже  начал
отрицать, что Виртуальная Машина (VM) является созданной  для  внутреннего
употребления аналогичной шуткой, вырвавшейся наружу.


 
homm ©   (2007-06-03 12:04) [1]

Думаю мир не рухнет от таких заявлений, даже ЕСЛИ это и правда.


 
Anatoly Podgoretsky ©   (2007-06-03 12:13) [2]

> Zagaevskiy  (03.06.2007 11:54:00)  [0]

И откуда ты только откопал этот древний  боян


 
Zagaevskiy ©   (2007-06-03 12:24) [3]

Да так, лазал в инете и вот результат...


 
Рамиль ©   (2007-06-03 12:51) [4]

Всем баянам боян:)


 
Юрий Зотов ©   (2007-06-03 12:55) [5]

> Кто что думает?

Думаю (и всегда так думал), что все эти извращения типа i++ взамен нормально читаемой записи не дают никаких реальных преимуществ (поскольку все определяется выходом компилятором, а не его входом) и только лишь запутывают исходный код.


 
homm ©   (2007-06-03 13:05) [6]

> что все эти извращения типа i++

На мой взгляд извращения типа somevar += othervar; наоборот упрощают чтение.


 
Zagaevskiy ©   (2007-06-03 13:22) [7]


> На мой взгляд извращения типа somevar += othervar; наоборот
> упрощают чтение

Да но :
  for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);
Ж8-[   ]


 
Юрий Зотов ©   (2007-06-03 13:30) [8]

> homm ©   (03.06.07 13:05) [6]

Не будем брать явное (и явно нарочитое) извращение типа

for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

Возьмем извращение простое: somevar += othervar;

И зададимся простым вопросом: а чем же оно конкретно упрощает (как Вы считаете) чтение кода?


 
homm ©   (2007-06-03 13:36) [9]

> : а чем же оно конкретно упрощает (как Вы считаете) чтение
> кода?

Найдите отличие.
this.somevar[x][y].R = this.somevar[x][y].R + othervar;
this.somevar[x][y].R = this.somevar[x][y].P + othervar;

Легко ошибиться как при написании, так и при чтении.
this.somevar[x][y].R += othervar;
А так в 2 раза короче.


 
Gero ©   (2007-06-03 13:38) [10]

> [8] Юрий Зотов ©   (03.06.07 13:30)И зададимся простым вопросом:
> а чем же оно конкретно упрощает (как Вы считаете) чтение кода?


Отсутствием избыточного повторения идентификатора в строчке.


 
Anatoly Podgoretsky ©   (2007-06-03 13:41) [11]

> homm  (03.06.2007 13:05:06)  [6]

Упрощает, это надо же такое извращение над мозгом делать.
Жрецом от программирования показаться хочется, что бы не посвященные не поняли.


 
имя   (2007-06-03 14:00) [12]

Удалено модератором


 
isasa ©   (2007-06-03 14:06) [13]

homm ©   (03.06.07 13:36) [9]
Найдите отличие.
this.somevar[x][y].R = this.somevar[x][y].R + othervar;


Проше надо быть. :)

ThisFu_kLongNameVariable tmpvar;

tmpvar=this.somevar[x][y].R;
...
tmpvar=tmpvar+othervar;


 
имя   (2007-06-03 14:07) [14]

Удалено модератором


 
имя   (2007-06-03 14:09) [15]

Удалено модератором


 
homm ©   (2007-06-03 14:14) [16]

> Проше надо быть. :)
> ThisFu_kLongNameVariable tmpvar;
> tmpvar=this.somevar[x][y].R;
> ...
> tmpvar=tmpvar+othervar;

Конечно так проще, чем предложено. У вас, что комплекс чтоли, у старшего поколения? Боитесь видеть очевидные вещи :(


 
Юрий Зотов ©   (2007-06-03 14:20) [17]

> homm ©   (03.06.07 13:36) [9]

1. Вообще-то, если человек дает полям (свойствам, методам...) имена R и P, то это его проблемы.

2. Пример некорректен. Сравнивать надо ОДИНАКОВО. Найдите  отличие:
this.somevar[x][y].R += othervar;
this.somevar[x][y].P += othervar;

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

3. Короче - не значит понятнее. Вот пример на Паскале:
W := PWord(Integer(@I) + 2)^;
I имеет тип integer, W имеет тип word. Возьмите любое значение I (кроме нуля) и скажите - чему будет равно W после выполнения этого кода на платформе x86? Сможете сказать без компьютера и не ошибиться?

А мы ведь говорим о простоте чтения кода.

> Gero ©   (03.06.07 13:38) [10]

См. п.3 выше.


 
isasa ©   (2007-06-03 14:24) [18]

homm ©   (03.06.07 14:14) [16]
Конечно так проще, чем предложено. У вас, что комплекс чтоли, у старшего поколения? Боитесь видеть очевидные вещи


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


 
Юрий Зотов ©   (2007-06-03 14:28) [19]

> homm ©   (03.06.07 14:14) [16]

Есть предложение дискутировать ДОКАЗАТЕЛЬНО и по СУТИ. Воздерживаясь от оценки поколений, длин, толщин и прочего.

Есть еще одно предложение - произнося слово "очевидно", НИКОГДА не забывать добавлять к нему слова "всего лишь для меня".


 
isasa ©   (2007-06-03 14:30) [20]

Юрий Зотов ©   (03.06.07 14:20) [17]
W := PWord(Integer(@I) + 2)^;


Тонкий намек, на то, что младший байт хранится первым? :)


 
Mike Kouzmine ©   (2007-06-03 14:30) [21]

А мне си++ больше нравится, чем паскаль для объектов. А перешел я на него (паскаль) в начале 90 из-за того, что дома была только 286, а си++ борланда текущей версии требовал 386.


 
Юрий Зотов ©   (2007-06-03 14:34) [22]

> isasa ©   (03.06.07 14:30) [20]

Да, но суть не в этом. Это пример того, как НЕ надо писать НИ НА КАКОМ языке. Этот код и короток в исходнике, и эффективен в машинном виде, но не приведи Боже когда-нибудь сопровождать такую программу.

Еще это пример того, что при желании (глупом, конечно) даже и на Паскале можно написать write-only код. А уж о Си и говорить нечего.


 
homm ©   (2007-06-03 14:43) [23]

> 2. Пример некорректен. Сравнивать надо ОДИНАКОВО. Найдите
> отличие:
> this.somevar[x][y].R += othervar;
> this.somevar[x][y].P += othervar;

Тогда что-же вы написали неодинаково?
this.somevar[x][y].R += othervar;
this.somevar[x][y].R = this.somevar[x][y].P + othervar;


Вот так одинокого, только во втором варианте ошибка, которую фиг увидишь.


 
Юрий Зотов ©   (2007-06-03 14:47) [24]

> homm ©   (03.06.07 14:43) [23]

В примере на Паскале человек хотел написать R, а написал P.
В примере на Cи человек хотел написать P, а написал R.

Или наоборот. Как угодно, суть будет все та же.

И что? Какая ошибка лучше? Какая хуже? И в чем разница?


 
homm ©   (2007-06-03 14:58) [25]

> И что? Какая ошибка лучше? Какая хуже? И в чем разница?

Разница в том, что если я пишу
this.somevar[x][y].P += othervar;
я сразу вижу, что не то написал, а если написано
this.somevar[x][y].R = this.somevar[x][y].P + othervar;
Я сижу и долго втыкаю, почему же оно не работает, потому что вторая запись не бросается в глаза, потоу-что человек уже подсознательно ЗНАЕТ что там написано то-же самое, и проверит это лишь в последнюю очередь.


 
Юрий Зотов ©   (2007-06-03 15:10) [26]

> homm ©   (03.06.07 14:58) [25]

> если я пишу
> this.somevar[x][y].P += othervar;
> я сразу вижу, что не то написал

А я - не вижу. Кто сказал, что здесь должно быть R, а не P? Кто сказал, что здесь должно быть P, а не R?

И когда эта строка не одна, как здесь, а среди сотен других, как в реальной программе, то заметить ошибку одинаково трудно на ЛЮБОМ языке.

Не надо давать переменным дурацких имен - тогда не будет и дурацких ошибок. И это правило справедливо тоже для ЛЮБОГО языка.


 
Anatoly Podgoretsky ©   (2007-06-03 15:44) [27]


> Вот так одинокого, только во втором варианте ошибка, которую
> фиг увидишь.

Строго наоборот, это в первом варианте не увидишь, а во втором она в глаза бросается.


 
IMHO ©   (2007-06-03 15:49) [28]


> homm ©   (03.06.07 14:14) [16]



У тебя что, комплекс что ли,  у младшего поколения?


 
имя   (2007-06-03 15:56) [29]

Удалено модератором


 
Zagaevskiy ©   (2007-06-03 16:02) [30]

Удалено модератором
Примечание: Тоже на бан нарываетесь? Так Вы скажите, сделаем.


 
имя   (2007-06-03 16:03) [31]

Удалено модератором


 
TUser ©   (2007-06-03 16:05) [32]


> 3. Короче - не значит понятнее. Вот пример на Паскале:
> W := PWord(Integer(@I) + 2)^;
> I имеет тип integer, W имеет тип word. Возьмите любое значение
> I (кроме нуля) и скажите - чему будет равно W после выполнения
> этого кода на платформе x86? Сможете сказать без компьютера
> и не ошибиться?
>
> А мы ведь говорим о простоте чтения кода.

Пиведенный пример на си - это очень распространенная конструкция. А вот пример с приведением кода на Паскале, это еще надо специально выдумывать алгоритм, где это действителньо требуется.


 
Юрий Зотов ©   (2007-06-03 16:07) [33]

> TUser ©   (03.06.07 16:05) [32]

Да. И что?


 
имя   (2007-06-03 16:17) [34]

Удалено модератором


 
Zagaevskiy ©   (2007-06-03 16:25) [35]

Удалено модератором
Примечание: Извинения приняты, все ОК. Но сколько же раз можно извиняться? Ветка о ДРУГОМ, не надо оффтопить.


 
Alx2 ©   (2007-06-03 16:29) [36]

Полтора года назад полностью перешел на С++. Очень приглянулась реализация ООП в нем. Реализации лаконичнее и понятнее получается, чем на ООП версии Pascal. Хотя, дело, наверное, в руках и в кривости их.  
Но ведь и на Pascal можно написать так, что не въедешь в код. И на С++. Только на последнем меньше предохранителей от этого.


 
Однокамушкин   (2007-06-03 16:37) [37]


> Юрий Зотов ©   (03.06.07 13:30) [8]
> > homm ©   (03.06.07 13:05) [6]
> И зададимся простым вопросом: а чем же оно конкретно упрощает
> (как Вы считаете) чтение кода?

Сравним две записи:
a = a + b;
a += b;


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

Только не думайте, что я так уж люблю си и его конструкции... на самом деле мне и этот язык, и его порождения активно не нравятся... но конкретно операции типа += относятся к тому немногому, что я в сях считаю хорошим...


 
Юрий Зотов ©   (2007-06-03 16:42) [38]

> Однокамушкин   (03.06.07 16:37) [37]

Сравним две записи:
a = a + b;
a += b;

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

:о)

Причем заметьте, что ТАКАЯ трактовка НИЧУТЬ не хуже Вашей...
:о)


 
Kostafey ©   (2007-06-03 16:48) [39]

> a = a + b;
> a += b;

По - моему это вопрос привычки.
Ни больше, ни меньше.


 
Zeqfreed ©   (2007-06-03 16:49) [40]

Недели софистики с Юрием Зотовым на Дельфимастере :)


 
TUser ©   (2007-06-03 16:50) [41]

> Да. И что?

Некто считает, что в распространенном случае Си понятнее. Вы привели в качестве контраргумента пример нечитаемого кода на Паскале. Но кода, который практически никому никогда не пригодится. Так что контрпример хромает, имхо. Мало ли странностей можнео создать на любом языке. Давайте сравнивать одинаковые по распространенности конструкции. Увеличение значения переменной - одна из них. На мой взгляд конструкция
a := a + b // присводить а сумму текущих значений а и b
менее понятна, чем
a += b // увеличить а на величину b
Она длинее и плохо переводится в человеческий язык (мой перевод приведен в комментариях). Поэтому я использую
inc (a, b)

:)


 
Alx2 ©   (2007-06-03 16:55) [42]

Судя по всему, встроенные inc и dec - тоже туманны и опасны.

>Kostafey ©   (03.06.07 16:48)

Скорее, способ мышления.
Мне составные
<op>=
нравятся.

Нисколько при разборе не вгоняет в ступор. Конечно, если остальное тоже сразу понятно :)


 
Юрий Зотов ©   (2007-06-03 17:03) [43]

> TUser ©   (03.06.07 16:50) [41]

Если плохочитаемая конструкция к тому же еще и распространена - то что же сильнее хромает?

Насчет a += b: вот как раз ЭТА запись на ЧЕЛОВЕЧЕСКИЙ язык переводится ПЛОХО. Потому что на ЧЕЛОВЕЧЕСКОМ языке должно быть ДВА слагаемых, а здесь одно из них - НЕЯВНОЕ. А в записи a := a + b все явно и привычно даже пятикласснику.

Еще - попробуйте ошибиться и случайно поменять знаки местами: a =+ b. Среди сотен строчек кода. Веселая жизнь гарантирована. И попробуйте сделать такую же ошибку на Паскале - не получится.


 
ferr ©   (2007-06-03 17:05) [44]

Я вам завидую..
Искренне спорить на тему что лучше a += b или a = a + b. Класс!


 
Kostafey ©   (2007-06-03 17:09) [45]

Одним словом, как ни крути, Pascal - forever ! ;)


 
homm ©   (2007-06-03 17:11) [46]

> Насчет a += b: вот как раз ЭТА запись на ЧЕЛОВЕЧЕСКИЙ язык
> переводится ПЛОХО. Потому что на ЧЕЛОВЕЧЕСКОМ языке должно
> быть ДВА слагаемых, а здесь одно из них - НЕЯВНОЕ.

Увеличь а на б. Где здесь непереводимость?


 
Юрий Зотов ©   (2007-06-03 17:16) [47]

> homm ©   (03.06.07 17:11) [46]

А где здесь "увеличь а на б"?

Читаем: "а плюс <неизвестно_что> равно b". Где здесь "увеличь а на б"?

Чисто искусственная запись, без всякого человеческого смысла.


 
Eraser ©   (2007-06-03 17:20) [48]

> [47] Юрий Зотов ©   (03.06.07 17:16)

для пятиклассника a = a + b тоже "Чисто искусственная запись, без всякого человеческого смысла" :o)

a += b дело привычки, раньше тоже плевался, а как на php поработать пришлось, так через месяцок привык, ко всему привыкаешь :))


 
Alx2 ©   (2007-06-03 17:21) [49]

>Юрий Зотов ©   (03.06.07 17:16)

>Читаем: "а плюс <неизвестно_что> равно b". Где здесь "увеличь а на б"?

Вот парсер как-то с этим справляется однозначно.

Юрий, вас не устраивает именно запись "+="  как синоним "увеличить на"?


 
Johnmen ©   (2007-06-03 17:26) [50]


> homm ©   (03.06.07 17:11) [46]
> Увеличь а на б. Где здесь непереводимость?

Да всё переводится. Вот только а=а+б и переводить не надо.
И сквозь мозг, воспаленный си, пропускать тоже не требуется...:)


 
Alx2 ©   (2007-06-03 17:29) [51]

Вообще, зыбкая тема. Сродни религиозным.
Есть же возможность писать и на С++ "человечьим" языком. Только при нужде предохранители ставить рублем или администрацией.
Строгие рамки дает Pascal. С окончанием пеленочного роста программеру можно дать и бритву со всей ответственностью за ее использование.

Вот сейчас имеются в Delphi эксперименты над расширением синтаксиса. Недавно helper-ы обсуждали. Или та же перегрузка операций - вот чем они вызваны?


 
Юрий Зотов ©   (2007-06-03 17:30) [52]

> Alx2 ©   (03.06.07 17:21) [49]

> Вот парсер как-то с этим справляется однозначно.

Спасибо, но я и не сомневался. Только мы говорим о понятности для ЧЕЛОВЕКА, а не для парсера.

> вас не устраивает именно запись "+="  как синоним "увеличить на"?

Если речь идет обо мне лично, то все эти синтаксисы мне давно пофигу. Не раз и не два уже были случаи, когда садился - и с ходу писал программу на незнакомом языке. И без особых проблем, и все работало. Так что лично меня устраивает все. Даже Форт.

А если речь идет о сравнении самих языков, то я считаю, что понятнее тот язык, который ближе к человеческому. И что Паскаль к нему ближе, чем Си.


 
TUser ©   (2007-06-03 17:35) [53]

Для пятикласника символ := тоже очень непонятен. А еще ему непонятно, почему надо писать собака.


 
Alx2 ©   (2007-06-03 17:39) [54]

>Юрий Зотов ©   (03.06.07 17:30)

Спасибо. Согласен, конечно, что паскаль понятнее и строже.

Да, есть гораздо большая возможность допустить кучу ляпов на С++ труднообнаружимой небрежностью.  Но можно просто не давать детям опасные "игрушки", а вместо этого использовать хорошие стороны языка.
И доверить это делать зрелому и классному специалисту. :)


 
Johnmen ©   (2007-06-03 17:40) [55]


> TUser ©   (03.06.07 17:35) [53]

Откуда знаешь?


 
Юрий Зотов ©   (2007-06-03 17:42) [56]

> TUser ©   (03.06.07 17:35) [53]

Символ := означает ПРИСВАИВАНИЕ. Этот оператор так и называется - оператор ПРИСВАИВАНИЯ. И читать этот символ так и нужно: ПРИСВОИТЬ.

Поэтому запись a := a + b на "человеческий" язык переводится "в лоб". Прямо так, как она и пишется: "Присвоить переменной a значение суммы переменных a и b". Все очень просто, очень естественно и очень понятно.

Попробуйте так же "в лоб", просто, естественно и понятно перевести на "человеческий" язык запись a += b. Не получится. Потому что запись искусственная, "нечеловеческая".


 
Юрий Зотов ©   (2007-06-03 17:46) [57]

> Alx2 ©   (03.06.07 17:39) [54]
> Но можно просто не давать детям опасные "игрушки"

Можно. Но есть и еще один способ. Причем и гораздо более простой, и гораздо более безопасный - не ДЕЛАТЬ опасных игрушек.
:о)


 
Alx2 ©   (2007-06-03 17:46) [58]

Но ведь можно написать
a = a + b

только присваиванием здесь работает "=", которое, правда, воспитывалось как "равенство".


 
Alx2 ©   (2007-06-03 17:48) [59]

>Юрий Зотов ©   (03.06.07 17:46)

Да, тут не могу возразить. Но так скучно будет... :)


 
TUser ©   (2007-06-03 17:52) [60]

> Юрий Зотов

В порядке бреда. Вот мы же не говорим: "Добейся того, чтобы в емкости А было столько же воды, сколько сейчас в емкостях А и Б вместе." Мы говорим: "Перелей воду из Б в А."

Ждем какого-нибудь события, а оно не наступает. Мы говорим всегда: "Подождем еще час." Никто не говорит: "Мы ждем уже 9 часов. Будем ждать столько, чтобы время ожиданияв целом получилось равным 10 часам."

Если я еще не напился, то говрю себе: "Дай ка я выпью еще две бутылки водки." Мне и в голову не прирдет что-нибудь вроде: "Скока тама я уже вылакал? Три, не, пять, надодогнать до того, чтобы это вот плюс два было семь."

и т.д.


 
Anatoly Podgoretsky ©   (2007-06-03 17:58) [61]

> Alx2  (03.06.2007 17:21:49)  [49]

Да где же здесь увеличение, число сложить и сравнить


 
Kostafey ©   (2007-06-03 17:59) [62]

> [60] TUser ©   (03.06.07 17:52)

;)

Я в какой-то книжке читал, что в результате
a += b
будет сгененирован более оптимальный код, чем в результате
a = a + b

Это наверное от компилятора зависит ?


 
Alx2 ©   (2007-06-03 17:59) [63]

И все-таки, по моему опыту, на С++ часто получается меньше рутины, чем для аналогичных вещей на Паскале. Вопрос только в уместности использования инструментов.


 
Alx2 ©   (2007-06-03 18:01) [64]

>Anatoly Podgoretsky ©   (03.06.07 17:58)

Ой, забыл отметить. Я для синтаксиса С. И точка с запятой забыта в конце. :(


 
Юрий Зотов ©   (2007-06-03 18:02) [65]

> Alx2 ©   (03.06.07 17:46) [58]

> Но ведь можно написать
> a = a + b

Можно. И это было бы правльно. Потому что точно так же легко и понятно переводится на язык "человеческий".

Неправильно другое - то, что "нечеловеческая" конструкция a+=b вообще в языке допустима.

Учитывая, что символ = читается "присвоить", переведите "в лоб" с английского на русский две конструкции:
1. if <условие_справедливо> then a = <выражение_1> else a = <выражение_2>
2. a = <условие_справедливо> ? <выражение_1> : <выражение_2>

Первое перводится естественно и просто, даже без знания. языка. Второе "в лоб" не переводится вообще никак, нужно знать условности языка.


 
Юрий Зотов ©   (2007-06-03 18:07) [66]

> Kostafey ©   (03.06.07 17:59) [62]

> Это наверное от компилятора зависит ?

Естественно. Только от него, и ни от чего другого. Входной язык здесь вообще ни при чем.


 
Anatoly Podgoretsky ©   (2007-06-03 18:07) [67]

> Alx2  (03.06.2007 17:46:58)  [58]

Ну в математике такое выражение не возможно, поэтому в более развитых языках и применены два оператор - сравнение и присваивание.
Человеческие языки позаботятся чтобы не было проблема, шаманские позволять применить вместо одного другое и не заметить этого.


 
Kostafey ©   (2007-06-03 18:08) [68]

> Учитывая, что символ = читается "присвоить", переведите
> "в лоб" с английского на русский две конструкции:
> 1. if <условие_справедливо> then a = <выражение_1> else
> a = <выражение_2>
> 2. a = <условие_справедливо> ? <выражение_1> : <выражение_2>
>
> Первое перводится естественно и просто, даже без знания.
> языка. Второе "в лоб" не переводится вообще никак, нужно
> знать условности языка.


Вот тут не соглашусь.
Вторая конструкция может быть очень удобна в ситуации, когда необходимо возвращиать результат.
Например, при формировании строки.

По читабельности - спору нет.


 
Anatoly Podgoretsky ©   (2007-06-03 18:09) [69]

> Kostafey  (03.06.2007 17:59:02)  [62]

Ты такие книжки более не читай


 
Gero ©   (2007-06-03 18:09) [70]

> [57] Юрий Зотов ©   (03.06.07 17:46)
> Можно. Но есть и еще один способ. Причем и гораздо более
> простой, и гораздо более безопасный &#151; не ДЕЛАТЬ опасных
> игрушек.

Тогда взрослые запаникуют — им с безопасными неинтересно.


 
Юрий Зотов ©   (2007-06-03 18:12) [71]

> Kostafey ©   (03.06.07 18:08) [68]

> По читабельности - спору нет.

А мы тут о чем, вообще, говорим-то? Начиная аж с [5].


 
Kostafey ©   (2007-06-03 18:13) [72]

> Ты такие книжки более не читай

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


 
Petr V.Abramov   (2007-06-03 18:13) [73]

> Попробуйте так же "в лоб", просто, естественно и понятно перевести на "человеческий" язык запись a += b
а увеличить  на значение b :)


 
homm ©   (2007-06-03 18:14) [74]

> Попробуйте так же "в лоб", просто, естественно и понятно
> перевести на "человеческий" язык запись a += b. Не получится.

Юра, вы что-то уже совсем в спор увлеклись. Как так не получиться????
«а увеличить на б»


 
homm ©   (2007-06-03 18:17) [75]

К а прибавить б куда естественнее и понтнее для человека. Он видит, лежит 2 яблока, и ложит еще 3 рядом, он прибавил. По вашему он должен взять те два, потом еще 3 и потом положить обратно, туда где взял 2.


 
Юрий Зотов ©   (2007-06-03 18:17) [76]

> Petr V.Abramov   (03.06.07 18:13) [73]

Перевод не "в лоб", он придуман. В исходной записи нет символа, переводящегося как "увеличить". Есть символ, переводящийся как "сложить".


 
Kostafey ©   (2007-06-03 18:17) [77]

> > По читабельности - спору нет.
>
> А мы тут о чем, вообще, говорим-то? Начиная аж с [5].

На нет, тут спора быть не может. Pascal понятнее.
Единственное, что мне в нем не нравилось, так это работа с динамическими объектами.
Но это давно было.
С появлением object pascal исчезла и проблема.


 
Alx2 ©   (2007-06-03 18:17) [78]

>Anatoly Podgoretsky ©   (03.06.07 18:07)

Да, про математику хотел заикнуться тоже. Часто возникала проблема формульно описать присваивание. Вследствие чего искусственно уезжал на реккурентные соотношения.

Но ведь здесь другая формальная система. Есть непротиворечивая аксиоматика. Есть правила работы с ней. Другое дело, что много труднее сориентироваться в построении оптимальных с точки зрения восприятия вещей. Это минус. Но она (я про С++ в жен. роде :) ) включает как подмножество всю классику. Ничего нет такого на Паскале, что с такой же лаконичностью не выразилось бы на С++. Кроме двух досадных исключений: мне жутко нехватает множеств и вложенных функций с процедурами. Правда, с последними я более-менее освоился вложенными классами. Но все-равно остается нехорошее чувство.


 
homm ©   (2007-06-03 18:18) [79]

> Перевод не "в лоб", он придуман. В исходной записи нет символа,
> переводящегося как "увеличить". Есть символ, переводящийся
> как "сложить".

Кто вам сказал??? += такое-же увеличить, как := присвоить.


 
Petr V.Abramov   (2007-06-03 18:19) [80]

> В исходной записи нет символа, переводящегося как "увеличить". Есть символ, переводящийся как "сложить".
есть символ "увеличить на". вот если б он записывался как "-:" - вот тогда действительно тяжко было б :)


 
Kostafey ©   (2007-06-03 18:20) [81]

> К а прибавить б куда естественнее и понтнее для человека.
> Он видит, лежит 2 яблока, и ложит еще 3 рядом, он прибавил.
> По вашему он должен взять те два, потом еще 3 и потом положить
> обратно, туда где взял 2.


OK !
a /= b
А так как по-русски сказать ??


 
homm ©   (2007-06-03 18:21) [82]

> OK !
> a /= b
> А так как по-русски сказать ??

а разделить на б?


 
Alx2 ©   (2007-06-03 18:22) [83]

Kostafey ©   (03.06.07 18:20)

сделать a поделенным на b :)


 
Kostafey ©   (2007-06-03 18:22) [84]

> а разделить на б?

И присвоить а? :)

Ладно, бред все это :))


 
Юрий Зотов ©   (2007-06-03 18:23) [85]

> Kostafey ©   (03.06.07 18:17) [77]
> что мне в нем не нравилось, так это работа с динамическими объектами.

А работа с динамическими объектами во всех языках одинакова: выделил память, использовал память, освободил память. Что в Паскале, что в Си.

И даже с автоматической сборкой мусора - схема та же, только за тебя сборщик работает (что, кстати, не всегда хорошо).


 
VirEx ©   (2007-06-03 18:23) [86]

о как зыбко на душе, вы тут спорите, а у меня играет классика а за окном снег, в зеленом лесу.. снег... :(


 
Kostafey ©   (2007-06-03 18:24) [87]

> сделать a поделенным на b :)

Только язык не сломайте:
a %= b
:)


 
homm ©   (2007-06-03 18:26) [88]

>
> Только язык не сломайте:
> a %= b
> :)

промодулировать? :))


 
Zagaevskiy ©   (2007-06-03 18:26) [89]


> о как зыбко на душе, вы тут спорите, а у меня играет классика
> а за окном снег, в зеленом лесу.. снег... :(

Ты вкаком городе? Где сейчас снег ?


 
Kostafey ©   (2007-06-03 18:27) [90]

> А работа с динамическими объектами во всех языках одинакова:
> выделил память, использовал память, освободил память. Что
> в Паскале, что в Си.

Это-то да, я про синтаксис.
Э-э-ээ как это было-то...по-моему:
(Object)^.field:=...

что-то в этом роде. Вот что мне не нравилось.


 
VirEx ©   (2007-06-03 18:27) [91]


>  [89] Zagaevskiy ©   (03.06.07 18:26)

урал, дом сказочника Бажова в 1,5 километрах от меня


 
Kostafey ©   (2007-06-03 18:29) [92]

> промодулировать? :))

;))
новый термин ввели ? :)


 
Юрий Зотов ©   (2007-06-03 18:29) [93]

> Kostafey ©   (03.06.07 18:24) [87]
> a %= b

Очень правильный смайлик. Вылезшие на лоб, перекошенные от изумления глаза и вытянувшийся от изумления нос. Вполне соответствует тому, что он обозначает.
:о)


 
Kostafey ©   (2007-06-03 18:31) [94]

> [91] VirEx ©   (03.06.07 18:27)

Нормально, был я там.

За 3 года пребывания на урале переболел всеми видами ОРЗ.
Кстати, это время так и называется "зеленая зима" ;)


 
Zagaevskiy ©   (2007-06-03 18:33) [95]


> VirEx ©   (03.06.07 18:27) [91]
>
> >  [89] Zagaevskiy ©   (03.06.07 18:26)
>
> урал, дом сказочника Бажова в 1,5 километрах от меня

Ты там живёш или гостишь?


 
VirEx ©   (2007-06-03 18:35) [96]


>  [95] Zagaevskiy ©   (03.06.07 18:33)

живу конечно.
вся Сысерть вокруг горы построена (медная гора), и завод у реки (тож в сказках есть), так и остались старые постройки с 20х годов наверное


 
Alx2 ©   (2007-06-03 18:41) [97]

>Юрий Зотов ©   (03.06.07 18:02)

>Неправильно другое - то, что "нечеловеческая" конструкция a+=b вообще
>в языке допустима.

Из Alx2 ©   (03.06.07 17:29)
"Вот сейчас имеются в Delphi эксперименты над расширением синтаксиса. Недавно helper-ы обсуждали. Или та же перегрузка операций - вот чем они вызваны?"


>Учитывая, что символ = читается "присвоить", переведите "в лоб" с
>английского на русский две конструкции:
...

Я думаю, жертва лаконичности. Незначительная. Начинающий напишет знакомой конструкцией. Профи сто раз подумает над тем, как его поймут в таком задоре.


 
Zagaevskiy ©   (2007-06-03 18:46) [98]


> VirEx ©   (03.06.07 18:35) [96]
>
> >  [95] Zagaevskiy ©   (03.06.07 18:33)
>
> живу конечно.
> вся Сысерть вокруг горы построена (медная гора), и завод
> у реки (тож в сказках есть), так и остались старые постройки
> с 20х годов наверное

Классно наверное... Я живу в столице, но не в Москве. И население поменьше и всё такое...


 
Юрий Зотов ©   (2007-06-03 18:48) [99]

> Alx2 ©   (03.06.07 18:41) [97]

Идея хелперов мне понравилась, и даже очень. Много раз были случаи, когда требовалось совместить в одном классе фунциональность двух уже имевшихся - а множественного наследования нет. Для этой задачи хелперы подходят просто замечательно.


 
homm ©   (2007-06-03 18:53) [100]

> > a %= b
>
> Очень правильный смайлик. Вылезшие на лоб, перекошенные
> от изумления глаза и вытянувшийся от изумления нос. Вполне
> соответствует тому, что он обозначает.

Какой у вас богатый внутренний мир. По мне, так там знак процента и равно ;)


 
Alx2 ©   (2007-06-03 18:56) [101]

>Юрий Зотов ©   (03.06.07 18:48) [99]

Вот. А я ярый противник множественного. Но я думаю, что все-это религия все-таки. Пока обсуждение на уровне философии. Просто мозги по-разному приспособлены работать.

Но то, в чем я уверен, и то, о чем вы говорили (ведь говорили?) согласен:
высокий шанс допустить очевидный, но малозаметный промах - большой минус языку.


 
Однокамушкин   (2007-06-03 20:12) [102]


> Юрий Зотов ©   (03.06.07 17:03) [43]
> Еще - попробуйте ошибиться и случайно поменять знаки местами:
>  a =+ b. Среди сотен строчек кода. Веселая жизнь гарантирована.
>  И попробуйте сделать такую же ошибку на Паскале - не получится.

Вам уже приводили пример другой ошибки, когда вместо a=a+b можно случайно написать a=c+b, и если идентификаторы не однобуквенные, а сложные, тоже тяжело будет заметить... имхо, одна ошибка стоит другой...

Ну а лично я вовсе не упёрт именно на += - если бы Inc работал не только с целыми, а с вещественными и строками, я был бы вполне удовлетворён... есть у вас возражения против такого Inc-а?

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


> Тем не менее, именно те свойства языка C, которые делают
> его использование источником дыр в больших программах, привели
> к его популярности среди незрелых киддисов от программирования,
>  рассматривающих его как игру, соревнование, арену демонстрации
> собственного «интеллекта». Важно понимать, что подобные
> явления не являются специфичными для программирования: в
> филологии и детской психологии хорошо известно аналогичное
> явление «детского фольклора» (страшилки и т.п.), демонстрирующее
> устойчивость на протяжении многих десятилетий. Таким образом,
>  можно говорить о стихийном распространении своеобразной
> мифологии вокруг языка C и его производных, коренящейся
> в естественном недостатке знаний и опыта, а также в особенностях
> психики юных программеров - желания самоутвердиться среди
> сверстников («настоящие программеры пишут на C») и т.д.
>
> <...>
>
> Стихийное распространение в среде юных партизан от программирования
> порочной мифологии, возникшей вокруг языков C/C++, имеет
> резоны в примитивных архетипах подростковой психологии.

источник - http://www.xakep.ru/post/38388/default.asp


 
Юрий Зотов ©   (2007-06-03 20:19) [103]

> Однокамушкин   (03.06.07 20:12) [102]

Как и Вы, с цитатой согласен на все 100. Но хочу заметить, что то, о чем в ней идет речь, стало возможным именно благодаря "дырам" в самом языке Си. На Паскале такое было бы невозможно.


 
Kostafey ©   (2007-06-03 20:23) [104]

> > психики юных программеров - желания самоутвердиться среди
> > сверстников («настоящие программеры пишут на C») и т.д.


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


 
Petr V.Abramov   (2007-06-03 20:27) [105]

> Стихийное распространение в среде юных партизан от программирования
да ладно, на сях юникс написан, вместе с популярностью юникса и популярность си росла.


 
isasa ©   (2007-06-03 20:36) [106]

Однокамушкин   (03.06.07 20:12) [102]
Ну а лично я вовсе не упёрт именно на += - если бы Inc работал не только с целыми, а с вещественными и строками, я был бы вполне удовлетворён... есть у вас возражения против такого Inc-а?


Тут эта, а что в С += работает со строками (вещественные, понятно) ?


 
Однокамушкин   (2007-06-03 20:51) [107]


> isasa ©   (03.06.07 20:36) [106]
> Тут эта, а что в С += работает со строками (вещественные,
>  понятно) ?

Для CString-а этот оператор переопределён, так что работает... когда я писал на плюсах, то в основном с CString-ом и приходилось работать... Ещё в C#, на котором мне сейчас приходится работать, можно += к строкам применять...

Кстати, в C++ есть ещё один большой маразм - операторы + и += никак между собой не связаны, поэтому можно переопределить их так, что a+=b и a=a+b будут означать совсем разные вещи... в шарпе от этого идиотизма отказались, там += переопределить нельзя, смысл этого оператора всегда выводится компилятором из того, как определён +...


 
Johnmen ©   (2007-06-03 20:51) [108]


> Ну а лично я вовсе не упёрт именно на += - если бы Inc работал
> не только с целыми, а с вещественными и строками, я был
> бы вполне удовлетворён... есть у вас возражения против такого
> Inc-а?

Никто никому не мешает написать свою, какую угодно, процедуру Inc.


 
alien1769 ©   (2007-06-03 22:06) [109]

http://delphimaster.net/view/15-1179845192/

Предлагаю всем решить задачку автора.
Приведите код на Паскале и С++. Посмотрим кто быстрее справится: молодежь или программисты со стажем ?


 
Johnmen ©   (2007-06-03 22:09) [110]

Ага, новый конкурс, у кого толще, длиннее и красивше...


 
Loginov Dmitry ©   (2007-06-03 22:13) [111]

> Всем баянам боян:)


Приблизительно 17-летний баянчик :)


 
Alien1769 ©   (2007-06-03 22:13) [112]

Просто интересно.


 
Defunct ©   (2007-06-03 22:23) [113]


> Думаю (и всегда так думал), что все эти извращения типа
> i++ взамен нормально читаемой записи не дают никаких реальных
> преимуществ (поскольку все определяется выходом компилятором,
>  а не его входом) и только лишь запутывают исходный код.
>


В некоторых процессорах имеется аппратный автоикремент индексного регистра, поэтому запись:

  A[ i++ ] = x;

выглядит куда более понятной, читаемой и компактной чем

A[ i ] := x;
i := i + 1;


 
YurikGL ©   (2007-06-03 22:29) [114]

http://www.linux.org.ru/view-message.jsp?msgid=284934

дата опубликования (26.02.2003 15:08:54)


 
Defunct ©   (2007-06-03 22:42) [115]


> На нет, тут спора быть не может. Pascal понятнее.


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

Пример:

If (b > 100) then
  a := a + b shr 2;
else
  a := a + b;

на C все это займет одну строку:

a += (b > 100) ?  (b >> 2) : b;


 
Loginov Dmitry ©   (2007-06-03 22:43) [116]

> http://www.linux.org.ru/view-message.jsp?msgid=284934
>
> дата опубликования (26.02.2003 15:08:54)


Причем тут дата опубликования?
Когда появился Си? Прибавь к этому 20 лет, получится дата рождения этого прикола :)


 
Sergey Masloff   (2007-06-03 22:45) [117]

YurikGL ©   (03.06.07 22:29) [114]
А на дельфимастер дата публикования сегодня. И что? Я эту шутку читал в фидо когда у меня и интернета не было никакого это год 96 максимум. И то она была не нова на тот момент ;-)


 
Юрий Зотов ©   (2007-06-03 23:10) [118]

> Defunct ©   (03.06.07 22:23) [113]

Зависит исключительно от компилятора. Хороший компилятор задействует эту фичу и при i := i +1, плохой - не задействует и при i++.

> Defunct ©   (03.06.07 22:42) [115]

Да, Паскаль читабельнее, а C - компактнее. Никто с этим не спорит. И что?

В понятности кода есть большой практический смысл (поддержка, преемственность, коллективная разработка и т.п.) .

А какой смысл в компактности кода? Кому и зачем она нужна, эта компактность? Чтобы по клавишам меньше стучать?

Очень сомнительное достоинство. Тем более, когда оно идет в ущерб читаемости.


 
Vga ©   (2007-06-03 23:16) [119]

VirEx ©   (03.06.07 18:23) [86]
Фигасе. Я живу в Каменске-Уральском, это недалеко, но у нас вроде уже весь снег потаял... Хотя холодно :(


 
P   (2007-06-03 23:20) [120]

Язык сам по себе не важен, как и библиотеки или технологии. Важен процесс производимый изделием и соответствие его требованиям заказчика.

Пишут же навороченный GUI на JavaScript+HTML = AJAX и никто не умер. Только тормозит это все жутко, зато есть возможность попонтоваться крутостью компа, на котором даже приложение на AJAX не тормозит.


 
antonn ©   (2007-06-03 23:31) [121]


> Пример:
>
> If (b > 100) then
>   a := a + b shr 2;
> else
>   a := a + b;
>
> на C все это займет одну строку:
>
> a += (b > 100) ?  (b >> 2) : b;

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


 
Defunct ©   (2007-06-03 23:36) [122]


> В понятности кода есть большой практический смысл (поддержка,
>  преемственность, коллективная разработка и т.п.) .


Никто не мешает на Си писать понятно для других.
Грамотно оформлять и добавлять коментарии.

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

Здесь я преувеличиваю конечно, но смысл именно таков. То что стучать по кнопкам меньше - дополнительный бонус.


 
sniknik ©   (2007-06-03 23:47) [123]

> А какой смысл в компактности кода? Кому и зачем она нужна, эта компактность? Чтобы по клавишам меньше стучать?
ну не скажи... по клавишам это тоже важно... начинающим. когда я только учился, и набивал текст одним пальцем, я очень завидовал С-ишникам (на одном потоке было как бы два отдела) потому как им просто скобки {} поставить, а мне надо было писать begin end;... и т.д.
;о))

вообще шутки шутками, а если бы тогда заранее знал, что там писать больше, еще неизвестно чтобы выбрал...


 
isasa ©   (2007-06-03 23:48) [124]

Defunct ©   (03.06.07 22:42) [115]
Второй раз не выдержу. :)
Я бы не отождествлял оператор "условного присваивания"(...?...:...) с "условным оператором" (if ... else ...), т.к. в некоторых языках он именно только присваивание по выполнению условия(вычияляется все, затем присваивается). Короче, из разных опер.
Не зная нюансов, можно сильно нарваться -> ( а = (null!=b) ? d.field : null; ) . Да и способ написания не прозрачен. :)


 
Юрий Зотов ©   (2007-06-04 00:01) [125]

> Defunct ©   (03.06.07 23:36) [122]

> Никто не мешает на Си писать понятно для других.

Никто. Беда в другом - в том, что никто не мешает писать на Си и так, что через полгода даже сам не разберешься. Это я и называю - дыры в языке. Писать так же непонятно на Паскале - непросто, для этого опыт и талант нужен.

> Компактую запись проще охватить взглядом..

И труднее понять. И что толку в этом "все вижу, но ничего не понимаю"?

> Функция на С, занимающая один экран, при реализации на Паскале может
> не уместиться на одном экране.. И вся читабильность кода будет "коту-
> под хвост", т.к. одним взглядом уже нелучится охватить алгоритм этой
> функции.

Вы сами себе и ответили: "Здесь я преувеличиваю конечно".

> То что стучать по кнопкам меньше - дополнительный бонус.

Вы называете переменные так: a1, b37, i5 и т.д.? Или называете их "по-человечески", чтобы из названия был ясен смысл?

Называйте их как можно короче - меньше же по кнопкам стучать. Дополнительный бонус. И фиг с ним, со смыслом.


 
Defunct ©   (2007-06-04 00:12) [126]

Писать так же непонятно на Паскале - непросто, для этого опыт и талант нужен.
ну отчего же, ведь и на паскале можно объявлять переменные
"a1, b37, i5 и т.д."  
пользовать goto и т.п.


> Называйте их как можно короче - меньше же по кнопкам стучать.
>  Дополнительный бонус. И фиг с ним, со смыслом.


Это уже преувеличение с Вашей стороны. Вернемся к операторам +=, -= и т.д. Какой бы длины ни были переменные, в паскалевском аналоге текста будет вдвое больше.


 
Defunct ©   (2007-06-04 00:22) [127]


> Не зная нюансов, можно сильно нарваться ->
> ( а = (null!=b)  ? d.field : null; ) .


А тут все ок как синтаксисом так и с поведением.
Что вы хотели сказать этим примером?


 
исследователь   (2007-06-04 00:29) [128]

Начался очередной холивар...


 
Юрий Зотов ©   (2007-06-04 00:30) [129]

> Defunct ©   (04.06.07 00:12) [126]

Итак.

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

2. Синтаксис Си позволяет писать и понятный код тоже - но тогда этот код, естественно, перестает быть компактным.

3. По п.2 Си - аналог Паскаля.

4. По п.1 Си отличается от Паскаля. На Паскале нельзя ЛЕГКО писать компактный, но непонятный код. Не получится.

5. Вывод: синтаксис Си ПЛОХ !!!


 
Defunct ©   (2007-06-04 00:52) [130]

> Юрий Зотов ©   (04.06.07 00:30) [129]

У Вас неточность в п.2.

>2. Синтаксис Си позволяет писать и понятный код тоже - но тогда этот код, естественно, перестает быть компактным.

Да код будет менее компактен чем это возможно, но тем не менее он будет более компактен чем на Паскале.

> 5. Вывод: синтаксис Си ПЛОХ !!!

то что синтаксис более ГИБОК - не значит, что он ПЛОХ...


 
Юрий Зотов ©   (2007-06-04 00:58) [131]

> Defunct ©   (04.06.07 00:52) [130]

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


 
Eraser ©   (2007-06-04 00:59) [132]

> [120] P   (03.06.07 23:20)


> Пишут же навороченный GUI на JavaScript+HTML = AJAX и никто
> не умер.

пишут, живы пока.

> Только тормозит это все жутко

с кого это перепугу оно тормозит? работает быстрее чем без AJAX.


 
Real ©   (2007-06-04 01:18) [133]

"Сд.пр.кв.с.вс.уд.д.од.ин." - прочитав это, Остап понял что речь идет о том, что "Сдается прекрасная квартира со всеми удобствами для одинокого интеллегента" (с) Золотой теленок, И.Ильф, Е.Петров

Оригинал объявления написан в духе Си :-) То есть соблюденна самая "важная" часть исходника: краткость записи. Никогда не понимал почему это сишный компилятор так любит эту самую краткость. Ну да ладно, когда скорость процессоров мерялась десятками МГц - еще прокатывало что "скорость компиляции важна", хотя хороший программист вряд ли компилит свой проект каждые 10 минут :)

Имхо, сишникам нравится что код краткий и мало понятный (даже им самим спустя время) зато чайники смотрят на них как на полубогов. По-моему, этим простым человеческим качеством можно объяснить тягу к чисто машинным и кратким записям у поклонников Си. Почему в разговорном языке они не используют методики Васисуалия Лоханкина :)


 
Kostafey ©   (2007-06-04 01:18) [134]

Все, кажется, я наконец-то понял, что пытается втолковать Ю.З.

Речь идет прежде всего о коллективной разработке.
Самому Ю.З. в любом случае все равно на чем писать и что
читать (по одному из постов).
Но если кто-то другой будет использовать код написанный кем-то,
то вероятность того, что он быстрее и легче его поймет для
pascal будет выше чем для cpp.

Только и всего.


 
Kostafey ©   (2007-06-04 01:21) [135]

> зато чайники смотрят на них как на полубогов.

Я, например уважительно отношусь к тому, кто хорошо знает STL,
а не потому что код непонятен.


 
Real ©   (2007-06-04 01:22) [136]


> Но если кто-то другой будет использовать код написанный
> кем-то,
> то вероятность того, что он быстрее и легче его поймет для
> pascal будет выше чем для cpp.

С таким же успехом, можно сказать что "если писать книги черными символами на белом фоне, то вероятность того что читатели быстрее прочтут и поймут книгу, чем если писать салатовым шрифтом на фиолетовом фоне. Только и всего" :)

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


 
Defunct ©   (2007-06-04 01:31) [137]

> Real ©   (04.06.07 01:18) [133]

Я конечно, понимаю что форум по Delphi, и доказывать, или говорить плохо о pascal здесь просто низя..
Но не доводите аргументацию до абсурда...
Cи код может быть написан абсолютно прозрачно для понимания, быть читабельным, и также иметь свою красоту. То что Си пригоден для коллективной разработки сомнений нет, иначе его бы просто нигде не применяли.


 
DrPass ©   (2007-06-04 01:31) [138]


> Kostafey ©   (04.06.07 01:18) [134]


> Но если кто-то другой будет использовать код написанный
> кем-то,
> то вероятность того, что он быстрее и легче его поймет для
> pascal будет выше чем для cpp.
>
> Только и всего.

Это "только и всего" на самом деле является одним из важнейших качеств программного кода. Ни один мало-мальски серьезный проект не пишется в одиночку. Это еще не говоря о том, что по твоему коду просто могут учиться другие {будущие} программисты, основывать свои программы на нем, брать его в качестве примера и т.д.


 
Kostafey ©   (2007-06-04 01:31) [139]

> С таким же успехом, можно сказать что "если писать книги
> черными символами на белом фоне, то вероятность того что
> читатели быстрее прочтут и поймут книгу, чем если писать
> салатовым шрифтом на фиолетовом фоне. Только и всего" :)

А что, тоже верно ! :)


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

Да, да, да. И большая точка.

Хотя, иногда, смастерив какой-нибудь эдакий велосипед на С
навроде изменения значений нескольких переменных в заголовке цикла,
да так, что чтобы тонять что же на само деле происходит, приходится
прочитывать код несколько раз, и при каждом перечтении изумляясь
на сколько оригинально получилось...отвлекся :)

Нельзя так писать. Такие веши неприемлемы для профессионального
программирования, а вот студентам для забавы, моском поиграть -
самое оно !


 
Kostafey ©   (2007-06-04 01:37) [140]

> Cи код может быть написан абсолютно прозрачно для понимания,
> быть читабельным, и также иметь свою красоту. То что Си
> пригоден для коллективной разработки сомнений нет, иначе
> его бы просто нигде не применяли.

Понял. Скажите, Вам с идиотами доводилось иметь дело?
Нет ? Вам повезло, ибо их довольно много.
Так вот о том речь, что на СPP реализовать свои замашки
неизмеримо проще чем на pascal.

P.S.
Вам повезло, ибо их довольно много.
Чуть не сказал: и один из них перед вами :))


 
Real ©   (2007-06-04 01:45) [141]


> Я конечно, понимаю что форум по Delphi, и доказывать, или
> говорить плохо о pascal здесь просто низя..

Что за бред, найдите мне в правилах что-то типа "запрещено негативные высказывания в адрес Паскаля (языка и Блеза :) а также Н.Вирта"? Имхо, идет обмен мнениями, если вам мое мнение неприемлимо, это не означает ваше самое правильное, а я пишу только ради политкорректности :)


> Но не доводите аргументацию до абсурда...
> Cи код может быть написан абсолютно прозрачно для понимания,
>  быть читабельным, и также иметь свою красоту. То что Си
> пригоден для коллективной разработки сомнений нет, иначе
> его бы просто нигде не применяли.

В том-то и грусть, писать прозрачно можно, но школа Си учит обратному: пишите кратко :) Язык конечно же ни в чем не виноват.  Особенно его последние версии.


 
Defunct ©   (2007-06-04 01:49) [142]


> Вам с идиотами доводилось иметь дело?
> Нет ? Вам повезло, ибо их довольно много.
> Так вот о том речь, что на СPP реализовать свои замашки
> неизмеримо проще чем на pascal.


Мысль ваша понятна, но надо принять во внимание, что Cpp все же достаточно сложен, и далеко не каждый идиот сможет на нем писать.. Все не так уж и плохо..


 
DrPass ©   (2007-06-04 01:52) [143]


>  надо принять во внимание, что Cpp все же достаточно сложен,
>  и далеко не каждый идиот сможет на нем писать

Он не настолько сложен, чтобы человек, имеющий базовые навыки программирования и достаточно амбиций, не смог сваять какого-нибудь программного уродца.


 
Defunct ©   (2007-06-04 02:33) [144]


> Он не настолько сложен, чтобы человек, имеющий базовые навыки
> программирования и достаточно амбиций, не смог сваять какого-
> нибудь программного уродца.


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


 
Defunct ©   (2007-06-04 02:34) [145]

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

Хотя сорри - как всегда есть исключения - AvtoShema Дмитрия О., но увы она не на C..


 
euru ©   (2007-06-04 02:40) [146]

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

А Паскаль - это чуть ли не естественный для обычных людей язык. Достаточно краткого знакомства, и любой внятно написанный на нём код будет таким же понятным, как и родной английский.

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


 
P   (2007-06-04 02:58) [147]


> Юрий Зотов ©   (04.06.07 00:58) [131]
>
> > Defunct ©   (04.06.07 00:52) [130]
>
> Он плох не потому, что гибок, а потому что опасен. Он позволяет
> то, чего позволять не должен.


Для написания программ на C/C++ нужны мозги, на Delphi - диплом ПТУ. Выпускник ПТУ - дешевле.


 
Слоник_   (2007-06-04 03:06) [148]

если не хватает естественности - на выручку приходёт 1С! :)
ну что поморщились? просили же понятного синтаксиса, хехе


 
Defunct ©   (2007-06-04 04:05) [149]

Юрий,
Я тут еще раз перечитал ваш спор..


> Перевод не "в лоб", он придуман. В исходной записи нет символа,
>  переводящегося как "увеличить". Есть символ, переводящийся
> как "сложить".


Вы в своем переводе выражения
a := a + b;
переводите конструкцию из двух символов ":=" как "присвоить".
В таком случае

Что нам мешает переводить конструкцию из двух символов "+=" как "увеличить на". И по аналогии
-= - уменьшить на
*= - умножить на
/= - резделить на
&= про "and"ить" с
^= проксорить с
>>= сдвинуть на
и т.д.


 
Думкин ©   (2007-06-04 08:46) [150]

Одно такое дорогого стоит:
if(a=5) {}
Надо всегда себя в тонусе держать при работе с рядом языков одновременно. Паскаль при подобном сматерится на уровне компилятора. Сишник, ПХПист же будет материться самостоятельно и по получении бага.


 
Игорь Шевченко ©   (2007-06-04 09:48) [151]

Наша сила - в наших пальцах.
Чем больше мы набираем слова begin, end,
выражения вида someidentifier := someidentifier + someanotheridentifier,
тем сильнее становятся мускулы пальцев и кистей рук, недалек тот день, когда программирующий на паскале легко прошибет пальцем двухдюймовую доску.


 
Однокамушкин   (2007-06-04 09:56) [152]


> Думкин ©   (04.06.07 08:46) [150]
> Одно такое дорогого стоит:
> if(a=5) {}

Ага... :) когда-то я долго не мог понять, зачем пишут так неестественно: if (5 == a)... потом узнал, что именно для того, чтобы не допустить этой ошибки... :)))))


 
Evgeny V ©   (2007-06-04 10:09) [153]


> Юрий Зотов ©   (03.06.07 12:55) [5]
> ...что все эти извращения типа i++ взамен ....

Си позиционировался как язык промежуточный между ассемблером и языками высокого уровня. И одним из распространных тогда языков , на котором функционировал UNIX и си на базе PDP 11 (В СССР примерные аналоги CM3, СМ4, СМ1420....) Так вот у команды I++. ++I, --I,I-- были скажем так прямые ассемблерные аналоги в акссембелере PDP11 типа (Rn)+ или +(Rn)... и т.д Где Rn - рассшифровывается как регистр номер..  Так, что для многих в те времена эта команда была знакома и не вызывала неудобств в чтении. В 80-е годы кстати на машинах этого класса си уступал только ассемблеру в размере кода и скорости выполнения. Меняется класс машин, класс компиляторов, процессоров, одним словом проходит время - меняется и то, как мы видим реализацию языков программирования. Но никто не мешает мне написать вместо I++ ->   I=I+1 ни сейчас, ни тогда не мешал. Более того макрос (хот можно такие насооздавать, что и сам черт ногу сломит) может это перевести в дельфийский Inc, если вам так удобнее.
Все дело в привычке, мне кажетcя это и сейчас удобным писать на C# I++, особенно в теле цикла например. То же в Java. А потом чем это хуже Inc в дельфи? Дело привычки, если уж идти к простоте языка, то надо писать на Обероне ИМХО:-))  

> Думкин ©   (04.06.07 08:46) [150]


Согласен, бывают у людей ... ошибки из-за этого, есть плюсы у компилятора паскаля, не спорю, хотя warning таки у меня си-компилятор дает, читать просто надо и warning-и, а если посмотреть C# , то тот уже дает ошибку. Бороться можно кстати и в си с таким, надо просто приучить себя писать так if(5==а) (  if(5=a) - ошибка компилятора) {} :-)


 
Юрий Зотов ©   (2007-06-04 10:26) [154]

> P   (04.06.07 02:58) [147]

> Для написания программ на C/C++ нужны мозги, на Delphi - диплом ПТУ.

Встречаются высказывания, реакция на которые может быть только одна - восторг их оригинальностью. Другой реакции они не заслуживают.

> Defunct ©   (04.06.07 04:05) [149]

Ничто не мешает. Как и ничто не мешает прочитать и понять вообще любую языковую конструкцию, даже самую навороченную.

Но возникает вопрос - а зачем вообще вводить какие-то усложнения, если:
а). спокойно можно обойтись и без них;
б). они не дают ничего реально полезного;
в). они могут затруднить читабельность кода.

Зачем?

Только не надо о краткости записи. Мы уже выясняли - если она хоть чуть-чуть мешает пониманию кода (особенно, чужого), то она более вредна, чем полезна.

Итак - зачем?


 
Юрий Зотов ©   (2007-06-04 10:33) [155]

> Evgeny V ©   (04.06.07 10:09) [153]

> Си позиционировался как язык промежуточный между ассемблером и
> языками высокого уровня.

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

> прямые ассемблерные аналоги

И даже этим нельзя оправдать те самые неестественные конструкции типа i++. Для повышения эффективности надо не язык корежить, а компилятор нормальный делать. Который и переведет естественную конструкцию в прямой машинный аналог (если таковая имеется).


 
db2admin ©   (2007-06-04 10:43) [156]

холиварчик давно такого не было ))


 
Игорь Шевченко ©   (2007-06-04 10:45) [157]

Юрий Зотов ©   (04.06.07 10:33) [155]

Вот не понимаю, честное слово. Ты на ассемблере программировал, ничего там для себя неестественного не видел ?


 
TUser ©   (2007-06-04 10:46) [158]

> холиварчик давно такого не было ))

Тебе какой символ больше понятен (интуитивно) := или +=.

Кстати, += еще удобен тем, что они на одной кнопке, - набирать быстрее.


 
clickmaker ©   (2007-06-04 10:48) [159]


> И даже этим нельзя оправдать те самые неестественные конструкции
> типа i++.

если б это был единственный вариант написания, то да. А так, почему бы не писать i = i + 1?


 
Плохиш ©   (2007-06-04 10:51) [160]


> TUser ©   (04.06.07 10:46) [158]
> > холиварчик давно такого не было ))
>
> Тебе какой символ больше понятен (интуитивно) := или +=

А мне вот этот "==" непонятен...


 
clickmaker ©   (2007-06-04 10:52) [161]


> [160] Плохиш ©   (04.06.07 10:51)

а в пхп есть даже ===


 
Плохиш ©   (2007-06-04 10:53) [162]


> clickmaker ©   (04.06.07 10:52) [161]
>
> > [160] Плохиш ©   (04.06.07 10:51)
>
> а в пхп есть даже ===

Вот он крутой язык, символов им не хватает :-D


 
Evgeny V ©   (2007-06-04 10:55) [163]


> Юрий Зотов ©   (04.06.07 10:26) [154]


> Зачем?



> Юрий Зотов ©   (04.06.07 10:33) [155]


И тем не менее мне кажется - краткость, и I++ не является непонятным...тем более если писал на ассемблере PDP 11, где просто просматривается прямая аналогия... Тогда это было очень естесвенно... И потом тогда в то время были нормальные компиляторы языка паскаль? Я не видел, а на СМ-ках так вообще был интерпретатор. Парк машин  для предприятия тогда был простите или EC или СM. Мелочь типа ДВК или Искра не в счет. Даже когда появились персоналки на базе x86, то и то не все сразу компиляторы стали похожи на компиляторы нынешнего уровня. Наработки на си остались, так почему бы их не использовать?  

Если постараться и написать длинный макрос или строку - ну это уже просто говорит о стиле написания. На любом языке можно написать непонятно.
Хотя о чем спорить, если есть возможность - каждый выбирает тот язык, на котором ему нравится писать, или пишет на том, на чем скажет начальство:-)) В конце концов Вирт создал Модулу 2, а потом Оберон. И хотя begin и end  там остались, но он не считал эти языки паскалем:-)


 
Zagaevskiy ©   (2007-06-04 10:56) [164]


>Kostafey ©   (04.06.07 01:21) [135]
> > зато чайники смотрят на них как на полубогов.
>
> Я, например уважительно отношусь к тому, кто хорошо знает
> STL,
> а не потому что код непонятен.

Отсюда вывод - ты чайник?


 
Юрий Зотов ©   (2007-06-04 10:56) [165]

> Игорь Шевченко ©   (04.06.07 10:45) [157]

> Ты на ассемблере программировал

И даже напрямую в машкодах. С них, кстати, и начинал.

> ничего там для себя неестественного не видел?

Игорь, для себя (то есть, для человека) - видел. Для человека там все неестественно.

А для машины там все очень даже естественно. И в машинном языке именно так и должно быть. Это же ЕЕ язык, язык машины. А не человека.

А ЯВУ - это НЕмашинные языки. Они - для ЧЕЛОВЕКА. Именно для ЧЕЛОВЕКА они и были придуманы. И поэтому они должны быть естественными для ЧЕЛОВЕКА. Иначе теряется сам смысл ЯВУ.


 
db2admin ©   (2007-06-04 11:00) [166]

TUser ©   (04.06.07 10:46) [158]
>>Тебе какой символ больше понятен (интуитивно) := или +=.

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


 
tesseract ©   (2007-06-04 11:01) [167]


> А мне вот этот "==" непонятен...


:=, ==, != - это из курса высшей математики вообще-то, для различения присваивания и сравнения. Там ещё какие-то были, но лекция была 4 года назад :-)


 
Думкин ©   (2007-06-04 11:02) [168]

> Evgeny V ©   (04.06.07 10:09) [153]

Это понятно, но это помнить надо, и если не константа?
Да и мой X++ никаких варнингов не дает - для него это ошибка, а вот от PHP варнинга ждать....


 
Думкин ©   (2007-06-04 11:03) [169]


> tesseract ©   (04.06.07 11:01) [167]

Это где извращения такие?


 
tesseract ©   (2007-06-04 11:05) [170]


> Это где извращения такие?


Нам это писал препод по вышке. На 2 или 3-м курсе.


 
tesseract ©   (2007-06-04 11:05) [171]


> Это где извращения такие?


Нам это писал препод по вышке. На 2 или 3-м курсе.


 
Думкин ©   (2007-06-04 11:06) [172]

> tesseract ©   (04.06.07 11:05) [171]

Вышка - это не предмет. В каком разделе? У нас такого ниразу не было ни по одному разделу.


 
data ©   (2007-06-04 11:08) [173]

интересно, а почему все кинулись сравнивать синтаксисы С++ и паскаля
а вот никто не упоминает о таких широких возможностях С++, как множественное наследование, макросы, использование заголовочных файлов и пр. Мне кажется, что для написания серьезного кода (уровня операционной системы) Си нет равных.


 
db2admin ©   (2007-06-04 11:08) [174]

#ifdef OFF_TOP
Господа а что же с шифрованием в ветке
http://delphimaster.net/view/15-1180611153/
мне просто интересно как быстро найдут зашифрованное одно слово
#endif


 
tesseract ©   (2007-06-04 11:08) [175]


> Вышка - это не предмет. В каком разделе? У нас такого ниразу
> не было ни по одному разделу.


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


 
Dmitry S.   (2007-06-04 11:10) [176]


>интересно, а почему все кинулись сравнивать синтаксисы С++ и паскаля
>а вот никто не упоминает о таких широких возможностях С++, как >множественное наследование, макросы, использование заголовочных файлов и >пр. Мне кажется, что для написания серьезного кода (уровня операционной >системы) Си нет равных.


а они просто не в курсе. :)

паскаль - это просто детский грубый язык для начинающих, гибкости и удобства
в нем 0.0


 
tesseract ©   (2007-06-04 11:10) [177]


>  как множественное наследование, макросы, использование
> заголовочных файлов и пр.


Множественное наследование  - багоматерь.
Максросы - тормоза при компиляции и матоматерь при разборе чужого кода.
Заголовочные файлы  - их в паскале нет что-ли? И причём с видимостью переменных гемора в паскале меньше.


 
Думкин ©   (2007-06-04 11:11) [178]

> data ©   (04.06.07 11:08) [173]

А речь изначально крутилась вокруг другого - а именно вокруг баяна сообщенного в сабже и вокруг
 for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);


 
TohaNik ©   (2007-06-04 11:12) [179]

В своей деревне знаю только двоих (по моему мнению, тех кто может считать своей специальностью программирование).

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

Причем даже тот кто начинал с си, в начальном варианте всеравно был более понятен, что удивительно...


 
db2admin ©   (2007-06-04 11:12) [180]

data ©   (04.06.07 11:08) [173]
Да у языков есть своя стезя в которой что то делается проще.
Есть два языка: язык А1
                      и язык А2
У них разный синтаксис они были расчитаны на разные вещи

Вопрос а что лучше трактор или болид формулы 1?


 
tesseract ©   (2007-06-04 11:13) [181]


> паскаль - это просто детский грубый язык для начинающих,
>  гибкости и удобства


Зато в нём высокая читабельность кода. Гибкость - это типа указатель через указатель через указатель? Да гуру в паскале не прослывешь, звериных троп малопонятных нетути.

Единственное, что иногда  раздражает, булевые к целым не приводяться :-(


 
data ©   (2007-06-04 11:13) [182]


> Множественное наследование  - багоматерь.
> Максросы - тормоза при компиляции и матоматерь при разборе
> чужого кода.


это все смотря как их использовать


 
db2admin ©   (2007-06-04 11:14) [183]

#define TRUE FALSE
c http://bash.org.ru/


 
data ©   (2007-06-04 11:15) [184]


>
> А речь изначально крутилась вокруг другого - а именно вокруг
> баяна сообщенного в сабже и вокруг
>  for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("|
> "+(*u/4)%2);


ну это же просто извращение. Ни один професионал писать так не будет


 
Evgeny V ©   (2007-06-04 11:15) [185]


> Думкин ©   (04.06.07 11:02) [168]

Да надо помнить,  возможно один из камней, для получения ошибки, не спорю. Тем не менее Cи мне нравится, Дельфи мне тоже нравится. Ругать паскаль не хочу. но и знание си мне не раз пригодилось. А потому спорить, что лучше, что хуже.... не буду.


 
tesseract ©   (2007-06-04 11:16) [186]


> db2admin ©   (04.06.07 11:14) [183]


tesseract (10:09:16 1/06/2007)
<******> к вопросу о вчерашних скриптостраданиях. Только что кодер знакомый прислал, нашёл в коде программы, написанной уволенным коллегой незадолго до ухода:
<******> #define TRUE FALSE //счастливой отладки суки
* ****** такого извращённого юмора ещё не встречал
Rouse_ (10:09:56 1/06/2007)
#define true ((rand() % 2) ? true : false) //с первым апреля суки!
tesseract (10:10:20 1/06/2007)
аццкий сотона !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!:-D


 
Думкин ©   (2007-06-04 11:16) [187]

> data ©   (04.06.07 11:15) [184]

Так сабж и про это. :)


 
data ©   (2007-06-04 11:17) [188]


> Вопрос а что лучше трактор или болид формулы 1?


так и я о том же)
смысл ругать один и хвалить другой, когда они в разных весовых категориях


 
Думкин ©   (2007-06-04 11:18) [189]

> Evgeny V ©   (04.06.07 11:15) [185]

Я и не призываю, сам не ругаю - но речь пошла с баяна в сабже, а подключающиеся нападают уже на последствия. :)


 
sniknik ©   (2007-06-04 11:34) [190]

> Единственное, что иногда  раздражает, булевые к целым не приводяться :-(
?
ShowMessage(IntToStr(integer(true))+":"+IntToStr(integer(false)));


 
Игорь Шевченко ©   (2007-06-04 11:36) [191]

Юрий Зотов ©   (04.06.07 10:56) [165]

Язык - это язык. Со своими правилами и заморочками. На VAX/VMS был такой язык BLISS - тоже, кстати, высокого уровня, однако синтаксических конструкций разного рода там было как звезд на небе.
Я к тому, что наличие ярлыка "Высокий уровень" еще не означает, что язык должен быть паскалеподобным.

И еще - кто скажет, что LIST, APL и Prolog не языки высокого уровня, тот барбос.


 
Evgeny V ©   (2007-06-04 11:36) [192]


> Думкин ©   (04.06.07 11:18) [189]

Это да:-))
Просто когда человек пишет (извиняюсь, выбрал то, что с чем не согласен, особенно по пункту 4) так и тянет дать ответ LOL

> Юрий Зотов ©   (04.06.07 00:30) [129]
>
> 2. Синтаксис Си позволяет писать и понятный код тоже - но
> тогда этот код, естественно, перестает быть компактным.
>
>
> 3. По п.2 Си - аналог Паскаля.
>
> 4. По п.1 Си отличается от Паскаля. На Паскале нельзя ЛЕГКО
> писать компактный, но непонятный код. Не получится
.


На паскале можно писать непонятный код, как впрочем и на другом языке. Потому, что код, это не только операторы или проыедуры и функции, а и логика работы программы.  Примеров тому у меня на работе много, так как  тут у меня 70% работы в доводке и сопровождении чужого, ранее написанного чежого кода...кстати на дельфи на 90 % А это такие головные боли зачастую, что часто проще написать заново ... Чем вот и занялся в последнее время.

И как шутка в тему, но которую вполне можно примерить и к холивару на тему языков программирования:-)

Конечно я понимаю, что человеку русскому, с английским знакомым по наслышке, типа меня -  MSDN читать на русском куда как удобнее, ругаясь при этом на необходимость читать его на английском(какого-такого его вообще написали на английском, у них что нет в MS русских программистов), поминая на каждом шагу всякие артикли, времена - ну которых просто нет в русском языке. Но тем не менее, Шекспира или Байрона почему-то все рекомендуют читать на языке авторов:-) Качественный перевод тем не менее приветствуется LOL


 
Думкин ©   (2007-06-04 11:38) [193]


>  LIST, APL и Prolog не языки высокого уровня, тот барбос.

LISP?


 
ocean ©   (2007-06-04 11:40) [194]

Спор идет мне кажется не в том направлении. Тема старая, и надо говорить в терминах того времени. В чем преимущество C? Удобство, минимальность машинного кода, переносимость. Преимущество Паскаля - лучшая читаемость засчет определенной избыточности. Вы еще PL вспомните, там вообще, кажется, массивы можно присваивать. Ну сделай на С еще одну функцию, и присваивай. Так что, как уже говорилось, читаемость программы зависит от автора. А вот указанные преимущества С на чистом Паскале достичь сложно, поэтому при написании например драйвера никому не приходило в голову брать Паскаль. Помнится, более 70 процентов Юникса середины 80-Х было написано на С. Добавлю, что лично мне больше по душе синтаксис С. До сих пор, хотя уже привык, ломает от конструкций типа "a := b" и "a <> b".
Зато потом вдруг появился Дельфи... И я отбросил ужасный MS C++ 4.0, хотя и делал на нем что-то, и узнал что такое настоящая жизнь. Сейчас ситуация изменилась совершенно. Возьмите хотя бы Васик.
По сабжу, не исключаю, что язык С появился как шутка, но считаю что он вырос до полноценного языка, за что и был многократно изуродован.


 
Dmitry S.   (2007-06-04 11:43) [195]


> Зато в нём высокая читабельность кода.

а у племени мумба-юмба всего 30 слов, читабельность там самая высокая в мире

возьмите код Дмитрия О. :) Там супер читаемость. Ведь в си вы берете крайности как аргумент. А мне вот нравится его код. :)

>>  гибкости и удобства
>Зато в нём высокая читабельность кода. Гибкость - это типа указатель через >указатель через указатель? Да гуру в паскале не прослывешь, звериных троп >малопонятных нетути.

- сучка ты крашеная!
- почему крашеная? Это мой натуральный цвет!


 
clickmaker ©   (2007-06-04 11:46) [196]


> Да гуру в паскале не прослывешь, звериных троп малопонятных
> нетути.

получается, что "мастера дельфи" - это миф? :)


 
keymaster ©   (2007-06-04 11:47) [197]


Real ©   (04.06.07 01:22) [136]
>С таким же успехом, можно сказать что "если писать книги черными >символами на белом фоне, то вероятность того что читатели быстрее >прочтут и поймут книгу,

Был у девушек в школе предмет - стенография. Нормальные слова там писались всякими закорючками. Получалось очень компактно, но ни разу не понятно для нормального человека.
Паскаль - нормальный, легкочитаемый язык.
Си - стенография.


>Dmitry S.   (04.06.07 11:10) [176]
>паскаль - это просто детский грубый язык для начинающих, гибкости и >удобствав нем 0.0

Очень спорное заявление. Скорее всего, автор ничего не знает о паскале.


>data ©   (04.06.07 11:15) [184]
>>  for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("|"+(*u/4)%2);
>ну это же просто извращение. Ни один професионал писать так не будет

Не... Это очень компактно и понятно.


 
ocean ©   (2007-06-04 11:48) [198]

Еще насчет инкремента, I++. Это вещь просто удобная и весьма читаемая, не надо му-му. Достаточно вспомнить, что допустим автоинкремент есть во многих ассемблерах. Мне ее очень не хватает в Паскале.


 
Однокамушкин   (2007-06-04 11:50) [199]


> Evgeny V ©   (04.06.07 10:55) [163]
> И тем не менее мне кажется - краткость, и I++ не является
> непонятным...

Отдельно взятый I++, может быть, и понятен... но скажите мне, как будет вычислено выражение
a=b+++c;


 
db2admin ©   (2007-06-04 11:50) [200]

clickmaker ©   (04.06.07 11:46) [196]
конечно миф ))
это просто друзья друг другу раздают значки по результатам распития пива ))

Dmitry S.   (04.06.07 11:43) [195]
ты наверное брат Дмитрия


 
Dmitry S.   (2007-06-04 11:53) [201]

>Очень спорное заявление. Скорее всего, автор ничего не знает о паскале.
вообще-то я с него начинал. не сказал бы что стал в нем профи, но представление получил самое полное. потом перешел на си и забыл о (delphi)
как о старте. собственно паскаль выполнил свою функцию - обучил азам программирования.

>ты наверное брат Дмитрия
точно не по отцу :)


 
Dmitry S.   (2007-06-04 11:56) [202]

Отдельно взятый I++, может быть, и понятен... но скажите мне, как будет вычислено выражение
a=b+++c;

очень просто
a = b++ + c;

a = b + c;
b = b + 1;


 
db2admin ©   (2007-06-04 12:00) [203]

ocean ©   (04.06.07 11:48) [198]
inc(x); <-- оно что делает?


 
Галинка ©   (2007-06-04 12:01) [204]

товарищи, программисты. Борцами за чистоту русского языка не стали, так хотя бы померятся чем-нибудь при сравнении паскаля и Си???

Если уж рассуждать на тему читабельности, то это все равно что сравнивать разные человеческие языки. Почему-то тут неикто не удивляется, что в русском вообще нет структуры предложения, потому как все связывается родовыми и падежными окончаниями. В английском только оди падеж, если притяжательный падеж вообще можно так назвать, но строгой структуры там тоже как бы нет. Но все тоже как-то связано. И совсем другой дело немецкий, например. Тут у каждого слова - члена предложения, конструкции свое строго определенное место. И причем не русские, изучая немецкий или английский, не соответственно люди двух остальных наций, изучая другой язык не пытаются найти смысл или логику в других языках. Просто учат.

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

Я долго писала на паскале, теперь пишу на си шарп. И тот у другой языки оригинальны. Хотя и считается, что идеология у них одинаковая. Но си шарп, это как бы гибрид. Точнее билингва урожденная - ребенок, впитавший стили от языков родителей - си и паскаля. И это хорошо.

И конструкция a += b, очень хорошо понятна, читается как "увеличиваю а на значение б", и мною очень любимый теперь цикл foreach - освобождает от заведения дополнительной индексной переменной. Т.е. переменной уикла является сам объект последовательности. Очень удобно. Потому как, после третьего-четвертого вложенного цикла уже парится начинаешь, за что какой индекс отвечает.

Все во имя человека, все для блага человека.


 
Evgeny V ©   (2007-06-04 12:01) [205]


> Однокамушкин   (04.06.07 11:50) [199]


Так же как и в другом языке, тут надо знать порядок выполнения (приоритет) операторов.  И конечно может сбить с толку такое написание, можно было бы написать так a=(b++)+c; Или если бы я хотел сделать прединкремент с, то a=b+(++c); В учебниках по си кстати рекомендуют расставлять скобки для более хорошей читаемости скобок.

a=b++ +c; разбивается на следующее
a:=b+c;
b:=b+1;


 
Однокамушкин   (2007-06-04 12:01) [206]


> Dmitry S.   (04.06.07 11:56) [202]
> очень просто
> a = b++ + c;

А почему не a=b+(++c)? или не s=b+(+(+c))? синтаксис, допускающий такую неоднозначность, однозначное зло, извините за каламбур...


 
ocean ©   (2007-06-04 12:03) [207]

> Си - стенография.
Да еще дальше наехал на кого-то, мол, ничего не знает о Паскале.
Очевидно, цитата отражает мнение молодежи, видящей, что журналы отмечают краткость С. Это и означает не понимать смысла спора.
Пошучу, однако. Есть языки, например моделирования, где операторы читаются как фразы на естественном языке. Не хочешь стенографировать - туда!


 
sniknik ©   (2007-06-04 12:07) [208]

> очень просто
> a = b++ + c;
вот и ошибка т.к. программист хотел (возможно) и написал бы так (если бы не опечетка)

a = b + ++c;


 
Галинка ©   (2007-06-04 12:12) [209]

sniknik ©   (04.06.07 12:07) [208]

а может не надо думать за других? кто что хотел и как писал?

Это уже в плоскости аккуратности и правил написания кода. Тпа что вложенности отделяются табом, назыания переменных как-то должны отражать их физический смысл, присваивание выделяется пробелами, точнее каждое новое действие выделяется пробелом и т.п. Просто хороший тон в программировании.


 
Anatoly Podgoretsky ©   (2007-06-04 12:25) [210]

> Игорь Шевченко  (04.06.2007 10:45:37)  [157]

Программировал, не видел, пока не появились ООП ассемблеры и макроассемблеры, которые слишком много на себя берут.
Ассемблер (не макро) честный язык


 
Anatoly Podgoretsky ©   (2007-06-04 12:26) [211]

> TUser  (04.06.2007 10:46:38)  [158]

А -= на разных


 
Anatoly Podgoretsky ©   (2007-06-04 12:27) [212]

> Плохиш  (04.06.2007 10:51:40)  [160]

А мне все двойные & &&, | || и так далее


 
Anatoly Podgoretsky ©   (2007-06-04 12:28) [213]

> clickmaker  (04.06.2007 10:52:41)  [161]

Так СИ (2) а ПХП (3) - так что все закономерно. ЛИСП посмотри


 
ocean ©   (2007-06-04 12:30) [214]

> inc(x); <-- оно что делает?
Набери-ка A := inc(I);
Во-первых, это процедура. Во-вторых, ее смысл гораздо шире, чем инкремент С. В-третьих, она не входит в стандарт Паскаля. Конечно, я могу написать
function PlusPlus(I : Integer) : Integer;


 
Anatoly Podgoretsky ©   (2007-06-04 12:30) [215]

> Evgeny V  (04.06.2007 10:55:43)  [163]

Правильно, что не считал, а то так бы и был автором одного языка


 
clickmaker ©   (2007-06-04 12:30) [216]


> ЛИСП посмотри

там есть ==== ?! o)


 
Anatoly Podgoretsky ©   (2007-06-04 12:34) [217]

> data  (04.06.2007 11:15:04)  [184]

Пишут и хуже


 
Anatoly Podgoretsky ©   (2007-06-04 12:35) [218]

> Думкин  (04.06.2007 11:18:09)  [189]

Не знаю как насчет нападения, надо просто расслабиться, получать удовольствие от процесса.


 
Zagaevskiy ©   (2007-06-04 12:36) [219]

Мастера! А что получится в результате копиляции этой стоки?
for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);


 
Anatoly Podgoretsky ©   (2007-06-04 12:36) [220]

> Игорь Шевченко  (04.06.2007 11:36:11)  [191]

Средний это верх изуверства


 
Anatoly Podgoretsky ©   (2007-06-04 12:38) [221]

> Evgeny V  (04.06.2007 11:36:12)  [192]

> ругаясь при этом на необходимость читать его на английском(какого-такого его вообще написали на английском, у них что нет в MS русских программистов),

Уже появились


 
Dmitry S.   (2007-06-04 12:49) [222]

b+++c
такие конструкции употребляются крайне редко
вобще за такой код отрывают уши. что касается
>А почему не a=b+(++c)? или не s=b+(+(+c))?
потому что код парсится слева направо

а почему a + b + c == (a + b) + c?

ограниченность не может быть преимуществом. это  просто сдерживающий фактор для плохого программиста, начинающего, студента, помойки типа кода
DmitryO. представляете что было бы если бы он писал на C?

>Набери-ка A := inc(I);
круто! чтобы увеличить переменную на И нужно вызвать процедуру!

> что получится в результате копиляции этой стоки?
>for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

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


 
Johnmen ©   (2007-06-04 12:59) [223]

>keymaster ©   (04.06.07 11:47) [197]
>Очень спорное заявление. Скорее всего, автор ничего не знает о паскале.

Совершенно точно. Ничего не знает.
"Я книгу не читал, но она плохая" (с)

>Юрий Зотов ©

По-моему, тут никто из спорящих и возражающих не понимает сути твоих высказываний. Все попытки с твоей стороны что-либо объяснить идут прахом...
Я бы забил....


 
db2admin ©   (2007-06-04 12:59) [224]

Dmitry S.   (04.06.07 12:49) [222]
не ты не брат Дмитрия О., ты злейший врах


 
sniknik ©   (2007-06-04 13:01) [225]

Галинка ©   (04.06.07 12:12) [209]
> sniknik ©   (04.06.07 12:07) [208]
> а может не надо думать за других? кто что хотел и как писал?
работа такая, думать за других когда они не справляются.... т.е. когда с проблемой с софтом (не обязательно моим) в конторе не могут разобраться ни в одной инстанции идут ко мне.
обычно получается. могу и за тебя попробовать...

разговор шел о том как легко сделать ошибку, при таком синтаксисе неоднозначном. так? привели пример неоднозначности, и ему после почемуто дали совершенно однозначное толкование... а вот если подумать? встречая подобную конструкцию, в чужом коде, о котором достоверно известно одно что он работает неправильно. как вы эту конструкцию истолкуете? при том, что - логика автора неизвестна, что он подразумевал под выражением неясно, но код в общем работает не так как ожидается и непонятно почему.
т.е. встретив в чужом коде a = b+++c; где уверенность что имелось ввиду именно a = b++ + c; ?
нет ее. про что вам Ю.З. уже устал вдалбливать...

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


 
Юрий Зотов ©   (2007-06-04 13:01) [226]

> Dmitry S.   (04.06.07 12:49) [222]

>> что получится в результате копиляции этой стоки?
>> for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

> данный код демострирует в первую очередь убогость программиста,
> помойку в его голове

Согласен. Но маленький вопрос - а что же тогда демонстрирует язык, в котором подобная конструкция вообще допустима?


 
db2admin ©   (2007-06-04 13:05) [227]

Юрий Зотов ©   (04.06.07 13:01) [226]
возможность писать так что аж плохо становиться

Тоже самое(тяжело-читаемый бред) можно написать практически на всех языках программирования


 
Юрий Зотов ©   (2007-06-04 13:05) [228]

> Johnmen ©   (04.06.07 12:59) [223]

Увы, очень похоже.


 
default ©   (2007-06-04 13:08) [229]


> Неправильно другое - то, что "нечеловеческая" конструкция
> a+=b вообще в языке допустима.

блин, ребята, даже в Visual Basic включили сокращённые операторы +=,-= и тд
чего уж там говорить об их запутанности а?:)


 
db2admin ©   (2007-06-04 13:17) [230]

if(mdam>=walldam)and(map[ix,iy]>=5)and(map[ix,iy]<=17)then begin map[ix,iy]:=69;broken:=1;end;
if(mdam>=round(walldam*1.5))and(map[ix,iy]>=18)and(map[ix,iy]<=22)then begin map[ix,iy]:=69;broken:=1;end;
if(mdam>=walldam*2)and(map[ix,iy]=23)then begin map[ix,iy]:=69;broken:=1;end;
if(mdam>=round(walldam*1.5))and(map[ix,iy]>=24)and(map[ix,iy]<=27)then begin map[ix,iy]:=69;broken:=1;end;
if(mdam>=walldam)and(map[ix,iy]>=28)and(map[ix,iy]<=33)then begin map[ix,iy]:=69;broken:=1;end;

источник
http://www.google.com/codesearch?hl=ru&q=+lang:pascal+%3Bfor+show:dTkUOSuSu38:nvUZ6XldoJk:iPczB9Gob8A&sa=N&cd=3&ct=rc&cs_p=http://users.tkk.fi/~kluojus/pback21.zip&cs_f=GAMEMISC.PAS#a0


 
Галинка ©   (2007-06-04 13:19) [231]

sniknik ©   (04.06.07 13:01) [225]

для этого есть дебуггер с кнопкой степ... (чего-то там) ну и минимальное разтраьтельство в предметной области задачи. Синтаксис тут не при чем.

Синтаксис призван повысить либо скорость понимания - программером или компилятором - либо степень упразднения рутинных процедур. Именно поэтому появились инкремент/декремнты и операции типа +=/-=. Это просто удобное сокращение, как в скнигах пишут "см." вместо "смотри". Есть принятые операторы и "сокращения" языка. Умеешь их использовать - работать становится приятнее. не умеешь/не любишь - твое право.


 
Anatoly Podgoretsky ©   (2007-06-04 13:19) [232]

> clickmaker  (04.06.2007 12:30:36)  [216]

Там есть }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}


 
Игорь Шевченко ©   (2007-06-04 13:20) [233]

Думкин ©   (04.06.07 11:38) [193]

Да, конечно LISP, обшибся :)


 
Anatoly Podgoretsky ©   (2007-06-04 13:21) [234]

> Johnmen  (04.06.2007 12:59:43)  [223]

Да кто же в серьез относится к данной ветке :-)


 
clickmaker ©   (2007-06-04 13:21) [235]


> [232] Anatoly Podgoretsky ©   (04.06.07 13:19)

ну так это и в Си можно. Не забыв такое же количество {


 
Anatoly Podgoretsky ©   (2007-06-04 13:22) [236]

> db2admin  (04.06.2007 12:59:44)  [224]

Да, да, тот круглый, а этот какой то змееподобный


 
Anatoly Podgoretsky ©   (2007-06-04 13:24) [237]

> default  (04.06.2007 13:08:49)  [229]

Ну и что? В Дельфи под напором ламеров много чего мусорного включили.


 
default ©   (2007-06-04 13:31) [238]

Anatoly Podgoretsky ©   (04.06.07 13:24) [237]
ой это уже религия какая-то:)
увеличение переменной очень частая операция
отсюда возникло хорошо читаемое сокращение этой операции
типа Inc() читается хуже, по-крайней мере для меня это гораздо менее эстетично


 
db2admin ©   (2007-06-04 13:53) [239]

procedure AddExtension(var n:String);
{ Adds extension .QFC to filename, if no extension were specified}

var s:String;
begin
s:=n;while Pos("\",s)<>0 do Delete(s,1,Pos("\",s));
if Pos(".",s)=0 then n:=n+".QFC";
end;


 
db2admin ©   (2007-06-04 13:53) [240]

http://www.google.com/codesearch?hl=ru&q=+lang:pascal+%3Bwhile+show:v2QXQ2QyRiA:81agreY22cg:rDspo9iWheM&sa=N&cd=1&ct=rc&cs_p=ftp://ftp.elf.stuba.sk/pub/pc/pack/qfc202c.zip&cs_f=QFC.PAS#a0


 
Zagaevskiy ©   (2007-06-04 13:55) [241]

Inc() читается нормально, а += труднее заметить в коде среди сотен строк типа -= == и *=


 
Anatoly Podgoretsky ©   (2007-06-04 14:04) [242]

> clickmaker  (04.06.2007 13:21:55)  [235]

Конечно можно, но в ЛИСПе нельзя меньше, вот в этом и разница. Я в какой то программке видел свыше сотни подряд и не одну убрать нельзя.


 
Anatoly Podgoretsky ©   (2007-06-04 14:05) [243]

> default  (04.06.2007 13:31:58)  [238]

Я не использую, я за читабельность, поэтому у меня нет никаких Inc в программах. Я пишу так, чтобы и не программисту было понятно


 
Однокамушкин   (2007-06-04 14:06) [244]


> Anatoly Podgoretsky ©   (04.06.07 14:04) [242]
> Конечно можно, но в ЛИСПе нельзя меньше, вот в этом и разница.
>  Я в какой то программке видел свыше сотни подряд и не одну
> убрать нельзя.

Правильно, одна из расшифровок LISP - Lost In Stupid Parenthesis...


 
euru ©   (2007-06-04 14:28) [245]


> Юрий Зотов ©   (04.06.07 10:56) [165]

> А ЯВУ - это НЕмашинные языки. Они - для ЧЕЛОВЕКА. Именно
> для ЧЕЛОВЕКА они и были придуманы. И поэтому они должны
> быть естественными для ЧЕЛОВЕКА. Иначе теряется сам смысл
> ЯВУ.
Это Паскаль-то естественен для человека? Ещё раз повторю: Паскаль от Си недалеко ушёл. И до естественных языков ему также далеко, как и Си.

Это хорошо видно, если сравнить Паскаль, например, с языком АВАР (Кобол-подобный язык).

1. Естественный язык состоит из предложений. На письме каждое предложение завершается точкой (ну, так принято в нормальных, естественных для человека языках). АВАР строго придерживается этого правила. В Паскале же оно в принципе не соблюдается. Неужели программисты на Паскале не видят этого неестественного для образованного человека способа записи своего труда? Или они настолько безграмотны, что просто этого не замечают?

2. Встречаются какие-то непонятные сокращения const, var, shl, shr.
Как обычный человек может понять, что const - это constant, а не, например, constrict или construction?
То же самое и с var. Более того, как только выяснится, что var - это variable, тут же возникает вопрос: а что именно является переменным у следующего за этим словом объекта данных? Быть может, имя его со временем меняется или тип его зависит от присваиваемых ему значений?
shl и shr вообще какой-то набор согласных, для которых очень сложно сходу подобрать нормальные человеческие слова. При чём как на письме, так и при устном произношении буквы R и L могут легко путаться.
И какой смысл в этих сокращениях? "Смысла никакого. Слово придумано ради самого слова - а это уже выпендреж." (с) Юрий Зотов. "Походу" [34]

АВАР в этом плане более близок нормальному человеку. В нём явно пишется CONSTANTS, вместо непонятного var используется более точное DATA, слэнговое выражение s shr 3 выражено на понятном человеческом языке SHIFT s BY 3 PLACES RIGHT.

3. Даже если слово пишется польностью, могут допускаются элементарные грамматические ошибки. Слово type может несогласовываться с последующими определениями по числу (при определении нескольких типов грамотнее, а значит, понятнее для человека, писать types). слово downto должно писаться раздельно.

4. Непонятно зачем введены различные специальные символы, как будто недостаточно способов выразить так же точно, но более понятно обычному человеку. Например, символ := обозначает "присвоить". Во-первых, нужно запоминать написание самого символа, а во-вторых правильно понимать его смысл. Т.е. непосвящённый человек сразу и не сообразит, что s := 5 означает "присвоить переменной s значение 5", что аналогично более близкому и понятному для человека "поместить значение 5 в переменную s". Именно такой вариант и используется в АВАР: MOVE 5 TO s.
Чтобы хоть как-то оправдать введения этого символа, для него придумали специальные выражения вида a := a + b, a := a /b и т.д. АВАР опять же более человечен в таких случаях:
ADD b TO a.
SUBTRACT b FROM a.
MULTIPLY a BY b.
DIVIDE a BY b.


В принципе, можно и продолжить сравнение, но, я так думаю, и из перечисленного видно, что Паскаль в сравнении с языком АВАР не намного ближе к человеческим языкам нежели Си.


 
default ©   (2007-06-04 14:28) [246]

Anatoly Podgoretsky ©   (04.06.07 14:05) [243]
это религия, Анатолий:)
мне вот нудобно сравнивать более-менее длинные и похожие имена на эквивалентость до и после присваивания, это тормозит чтения, есть риск ошибок как уже говорили
код становится более раздутым
вообщем я за "+=" и тд


 
Игорь Шевченко ©   (2007-06-04 14:30) [247]

euru ©   (04.06.07 14:28) [245]


> слэнговое выражение s shr 3 выражено на понятном человеческом
> языке SHIFT s BY 3 PLACES RIGHT.


Писать соскучишься на таком языке. Это уже проза получится. И компилятору скучно будет такое написанное переваривать.
Кроме того, чем длиннее слово, тем больше вероятность сделать в нем ошибку.

Ку ?


 
default ©   (2007-06-04 14:34) [248]

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


 
P   (2007-06-04 14:38) [249]

Настоящему программисту нет разницы на каком языке писать, например, как мне.


 
default ©   (2007-06-04 14:40) [250]

P   (04.06.07 14:38) [249]
речь совсем не о том, настоящий ты наш программист....
речь о том, сколько потребуется вспоминать всяких деталей и подводных камней при переключении с одного языка на другой, на каком языке труднее допустить трудноуловимые ошибки и тд и тп


 
Игорь Шевченко ©   (2007-06-04 15:09) [251]


> Настоящему программисту нет разницы на каком языке писать,
>  например, как мне.


Например на APL


 
Юрий Зотов ©   (2007-06-04 15:11) [252]

> db2admin ©   (04.06.07 13:53) [239]

Очень прискорбно видеть, как ПРОГРАММИСТ не понимает разницы между ЯЗЫКОМ и ТЕКСТОМ на этом языке.

Приводя пример плохого ТЕКСТА в ветке, где речь идет о ЯЗЫКАХ.

Увы.


 
db2admin ©   (2007-06-04 15:17) [253]

Юрий Зотов ©   (04.06.07 15:11) [252]
я просто приводил примеры плохо написанных кусков кода на паскале


 
db2admin ©   (2007-06-04 15:33) [254]

lemezza: Лекс, уползи, откуда взялся. Это цитата всего лишь по Далю.
put: а кто это такой? на каком языке програмил?
lemezza: на русь++


 
euru ©   (2007-06-04 16:21) [255]


> Игорь Шевченко ©   (04.06.07 14:30) [247]

> Писать соскучишься на таком языке.
Наоборот, очень весело писать на таком языке.


> Кроме того, чем длиннее слово, тем больше вероятность сделать
> в нем ошибку.
Двойные стандарты, однако. Если придерживаться этого правила, то в языке, включающем такие слова и выражения, как begin и a := a + b, вероятность допустить ошибку больше, чем в языке, содержащем { и a += .

А вообще приведённый мной текст - это была просто ирония. Хотя, как мне кажется, АВАР наиболее полно соответствует требованиям к языку программирования с точки зрения Юрия.


 
Defunct ©   (2007-06-04 16:31) [256]

ocean ©   (04.06.07 12:30) [214]
> Набери-ка A := inc(I);
> Во-первых, это процедура. Во-вторых, ее смысл гораздо шире, чем
> инкремент С. В-третьих, она не входит в стандарт Паскаля. Конечно,
> я могу написать
> function PlusPlus(I : Integer) : Integer;

Ой, а я всегда думал наоборот. Т.к. смысл инкремента в C гораздо шире, чем Inc в паскале. Вот наглядный пример:

1.
char *pU8 = (char *)smth;
pU8++ = 10;
pU8++ = 12;
pU8++ = 34

2.
short *pU16 = (short *)smth;
pU16++ = 10;
pU16++ = 12;
pU16++ = 34;

Обратите внимание, что во втором случае указатель автоматически будет увеличиваться на 2.


 
Defunct ©   (2007-06-04 16:34) [257]

в обоих примерах перед pU8/pU16 подразумевался оператор разименования:

*pU8++ = 10;
..


 
Однокамушкин   (2007-06-04 16:51) [258]

Многие ли люди смогут сразу сказать, что делает следующий код, при условии что d и s это указатели на char?

while (*d++ = *s++);

если подумать, то можно понять, что это копирование строки s в d... но очевидным это не назовёшь...


 
Юрий Зотов ©   (2007-06-04 16:52) [259]

> db2admin ©   (04.06.07 15:17) [253]

В том-то и дело. Как уже не раз говорилось, написать плохой или тормозной алгоритм, плохо структурировать и плохо отформатировать код (и т.д., и т.п.) можно на любом языке. Программа будет и плохой, и нечитаемой.

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

> All
Господа, а чего вы к Inc прицепились? Это, во-первых, не процедура, а псевдопроцедура (компилируется в inline-код); во-вторых она является принадлежностью библиотеки конкретного компилятора и к самому языку абсолютно никакого отношения не имеет.


 
Однокамушкин   (2007-06-04 16:52) [260]

Кстати, анекдот вспоминается... программист на си подобен астрологу: по расположению звёздочек пытается понять, что произойдёт... :)


 
Галинка ©   (2007-06-04 16:52) [261]

"указатели, завязанные узлом" (с) - это и есть С/С++... А то как написать инкремент, это уже дело десятое.


 
Игорь Шевченко ©   (2007-06-04 17:02) [262]


> Это, во-первых, не процедура, а псевдопроцедура (компилируется
> в inline-код);


i++ тоже компилируется :)


> А о том, способствует ли сам язык лучшей читабельности программ,
>  или он ей мешает.


А что является критерием читабельности на твой взгляд ?
Согласись, что человек, знающий некий язык программирования, с большей вероятностью без труда прочитает сложный код на этом языке, чем менее сложный, но на другом языке.

Кто судьи ?


 
Игорь Шевченко ©   (2007-06-04 17:04) [263]

Однокамушкин   (04.06.07 16:51) [258]


> если подумать, то можно понять, что это копирование строки
> s в d... но очевидным это не назовёшь...


Найди разницу в выразительности между

S1 := S2

и

S1 := Copy(S2,1,Length(S2));


 
euru ©   (2007-06-04 17:05) [264]


> Юрий Зотов ©   (04.06.07 16:52) [259]

И всё же, Юрий, шутки шутками, а как вы относитесь к использованию вместо Паскаля языка АВАР?


 
Юрий Зотов ©   (2007-06-04 17:11) [265]

> euru ©   (04.06.07 17:05) [264]

Я с этим языком незнаком, что могу о нем сказать?

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

Это я к тому, что писать SUBTRACT A FROM B вместо всем привычной и не менее понятной математической формулы - это уже абсурд.


 
Однокамушкин   (2007-06-04 17:13) [266]


> Игорь Шевченко ©   (04.06.07 17:04) [263]
> Найди разницу в выразительности между
>
> S1 := S2
>
> и
>
> S1 := Copy(S2,1,Length(S2));

Неэквивалентные конструкции однако... в первом случае будет увеличен счётчик ссылок уже имеющейся строки без копирования, а во втором реально создана новая строка, а в неё скопировано содержание исходной...

Только всё равно непонятно, как это связано с моим примером...


 
Игорь Шевченко ©   (2007-06-04 17:16) [267]

Однокамушкин   (04.06.07 17:13) [266]


> Неэквивалентные конструкции однако...


Эта...а в Delphi 1 или в BP7.0 ? А кто сказал, что это Delphi ваще ?

Речь идет о выразительности и только о выразительности.


 
Однокамушкин   (2007-06-04 17:30) [268]


> Игорь Шевченко ©   (04.06.07 17:16) [267]
>> Эта...а в Delphi 1 или в BP7.0 ? А кто сказал, что это Delphi
> ваще ?

Ну... подловил... :))))

> Речь идет о выразительности и только о выразительности.

Имхо, выразительнее S1:=S2, потому что здесь используется одна синтаксическая конструкция, специально предназначенная для того, что является целью этой операции...

Но я по-прежнему не понимаю, какое это отношение имеет к while (*d++=*s++); это совсем другой случай, здесь в одну строку запихано аж 6 конструкций, да ещё и использована та возможность одной из них, о которой обычно забывают... я имею ввиду, что оператор присваивания возвращает результат... одна простая констркуция против шести запутанных - в чём аналогия?


 
clickmaker ©   (2007-06-04 17:36) [269]


> while (*d++=*s++);

REP MOVSB форева :)


 
Игорь Шевченко ©   (2007-06-04 17:48) [270]

Однокамушкин   (04.06.07 17:30) [268]


> Имхо, выразительнее S1:=S2, потому что здесь используется
> одна синтаксическая конструкция, специально предназначенная
> для того, что является целью этой операции...


Это потому что в языке есть элементарный тип "строка". В языке С такого типа нет. Поэтому приходится использовать конструкции с указателями. Опять же - всего лишь ограничения языка. Цикл обхода связанного списка в языке С выглядит выразительнее, чем в языке Паскаль. Кстати.


> одна простая констркуция против шести запутанных


Для того, кто хорошо знает язык, запутанностью это не выглядит. Точно также, как для привыкших к паскалю не выглядят запутанными конструкции с множествами (+, *)


 
euru ©   (2007-06-04 17:52) [271]


> Юрий Зотов ©   (04.06.07 17:11) [265]

> всякую здравую идею можно, как известно, испохабить, доведя
> ее до абсурда.
Сдаётся мне, что вы необъективно языки оцениваете.

Пусть у нас есть выражение
  А := А + В;
где А, В - это некие длинные имена идентификаторов.
В этом выражении содержатся две потенциальные возможности совершить ошибку:
1. ошибиться при вводе идентификатора А, когда имя идентификатора А в левой части не будет совпадать с именем идентификатора А в правой части.
2. ошибиться в операторе, т.е. вместо знака "+" указать "*" (кстати, не соответствующий знаку умножения в математике).

АВАР полностью лишён этого недостатка.

Кроме того, фраза SUBTRACT b FROM a естествена для английского языка. Она будет понятна любому человеку, владеющему английским языком. Математическая же формула будет понятна только тем, кто предварительно изучал искусственно созданную систему математических обозначений. Да и смысл выражения А := А + В в элементарной математике (если закрыть глаза на символ ":=" и предположить, что это опечатка) обозначает, что при любых значения А значение В всегда равно нулю.


 
Virgo_Style ©   (2007-06-04 17:58) [272]

euru ©   (04.06.07 17:52) [271]

Я хотел бы поглядеть на программу вычисления, ну хотя бы корней квадратного уравнения. Впрочем, я и так уверен в ее нечитаемости.


 
Zagaevskiy ©   (2007-06-04 18:20) [273]


> Математическая же формула будет понятна только тем, кто
> предварительно изучал искусственно созданную систему математических
> обозначений

А разве ТУТ много таких людей?!
Я так понимаю, что НЕ поймёт тот, кто впервые сел программировать? типа Насти, Катюхи и тп?
А в языке АВАР я могу писать как захочу, главное на английском? (в смысле не надо знать определённых операторов???)


 
default ©   (2007-06-04 18:25) [274]

покажи программку на АВАР?!


 
Kolan ©   (2007-06-04 18:26) [275]

> Найдите отличие.
> this.somevar[x][y].R = this.somevar[x][y].R + othervar;

Оч. хорошо что на Dlephi длиннее получается. Пока пишешь может дойдет что это надо поместь в класс &laquo;R&raquo;.


 
Style ©   (2007-06-04 18:27) [276]


> Кто что думает?


Интересно над кем прикалывались создатели Perl и что они курили? :)


 
McSimm_ ©   (2007-06-04 18:43) [277]


> ADD b TO a.
> SUBTRACT b FROM a.
> MULTIPLY a BY b.
> DIVIDE a BY b.


Я тут прикинул...
MOVE (SUBTRACT (MULTIPLY (MULTIPLY x BY x) BY 5) BY C) TO y.
Правильная запись ?

На менее читабельных языках это выглядит как
y := 5 * x * x - c;

Мне стало интересно, можно ли в таком выражении некоторые скобки убирать, пользуясь приоритетами операций ?


 
default ©   (2007-06-04 18:57) [278]

McSimm_ ©   (04.06.07 18:43) [277]
может там есть что-то типа  MULTIPLY x1,x2,...,xn и тогда
MOVE (SUBTRACT (MULTIPLY (x, x, 5) BY C) TO y.
но тоже лишь чуть лучше

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


 
Kostafey ©   (2007-06-04 22:56) [279]

А как мирно все начиналось...
Такой холивар развернули.

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

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

Религия, однако ;)


 
Real ©   (2007-06-04 23:24) [280]

Мне кажется что сторонники Паскаля это те, кто привык к хорошей документации во всем. Рискну предположить что исходники Паскаля содержат больше комментариев :) Лично мне приятно видеть "begin" вместо "{", потому что для второго нужно помнить что это означает, а для первого - достаточно прочитать обычное английское слово. Мне как и многим приходится работать на нескольких языках, иногда за один день. Из-за этого неизбежны ошибки синтаксиса (типа написание "=" вместо ":="). Я вот уже несколько раз попался на один и тот же прикол: в ПХП, после нескольких часов Делфи пишу - if (a=1) ... И конечно же получаю логическую ошибку, потому как ПХП как и Си допускает присвоение в условном операторе... В дельфи по-моему нереально попасть в такую ситуацию, потому как язык достаточно строг к своему синтаксису. Си мне иногда напоминает "бои без правил", тогда как паскаль - хорошо организованный боксерский поединок :) Конечно, иногда раздражает что для объявления переменной нужно поднятся в секцию VAR - но при этом я всегда вспоминаю что сам виноват, больше надо было уделить времени проектированию. Строгая типизация - тоже часто дает негативные последствия, но сколько благодаря этому было выявленно ошибок за все время!


 
Kostafey ©   (2007-06-04 23:26) [281]

> [280] Real ©   (04.06.07 23:24)

+1
Ни дать - ни взять


 
Loginov Dmitry ©   (2007-06-04 23:26) [282]

А мне вот нравится в Паскале представление операторных скобок в виде begin...end. В случае их использования по правилу "begin и end всегда должны располагаться на одном уровне", скорость анализа кода ощутимо увеличивается Многие begin располагают сразу за предыдущим оператором, например,

if (Условие) then begin
  что-то там...
end


но это хуже вариант, усваиваемость кода ухудшается.

Во многих современных языках (Си, PHP, C# и т.п.) используются невзрачные фигурные скобки. Ну как их не располагай, усваимость все-равно ниже, чем при использовании правильно расположенных begin...end. Опять получается, что краткость в ущерб усваимости.

Не нравятся "извращенные" конструкции типа a = (b>c)?(b):(c). Такая конструкция неестественна :) Однако ее замена оператором IF естественности ничуть не прибавляет, а объем кода увеличивает. В Паскале IF более "естественен" благодаря наличию "лишнего" слова THEN.

Отдельного разговора заслуживает навороченный оператор цикла for(;;). (какая форма цикла FOR более естественна, та, что здесь, или та, что в Паскале?)


 
Kostafey ©   (2007-06-04 23:40) [283]

> А мне вот нравится в Паскале представление операторных скобок
> в виде begin...end

Так а > [280] Real ©   (04.06.07 23:24) о чем говорил ?


> Не нравятся "извращенные" конструкции типа a = (b>c)?(b)
> :(c).

Ну да, вместо них я пишу что-то вроде:

function cppq(strq: string; str1: string; str2: string):string;
begin
 if strq=str1 then
   Result:=str1
 else
   Result:=str2;
end;

Полезня в СPP эта конструкция !


> Отдельного разговора заслуживает навороченный оператор цикла
> for(;;). (какая форма цикла FOR более естественна, та, что
> здесь, или та, что в Паскале?)

Обе хороши.


 
Real ©   (2007-06-04 23:49) [284]


> +1
> Ни дать - ни взять

Благодарю :)


> Многие begin располагают сразу за предыдущим оператором,
>  например,
>
> if (Условие) then begin
>   что-то там...
> end


Заметил что большая часть исходников на си-подобных языках страдает этим форматированием. Поэтому первым делом заменяю все

if (условие) {
...
}


на

if (условие)
{
...
}


 
Eraser ©   (2007-06-04 23:51) [285]

> [280] Real ©   (04.06.07 23:24)

> Строгая типизация - тоже часто дает негативные последствия,
> но сколько благодаря этому было выявленно ошибок за все
> время!

эт точно, а php по-хорошему нужно все входные параметры функции приводить в нужному типу, иначе проблемы могут быть, так что отсутствие типизации, как это не пародоксально, приводит только к увеличению кода.
> [282] Loginov Dmitry ©   (04.06.07 23:26)

насчет скобок - не согласен, нормальная усваиваемость, особенно если писать в виде
if (a == b)
{
 c = a;
}

т.е. не далеть строку для скобки, а не
if (a == b) {
 c = a;
}

или
if (a == b) {c = a;}

> Не нравятся "извращенные" конструкции типа a = (b>c)?(b)
> :(c). Такая конструкция неестественна :)

не естесственна, согласен, но часто не хватает её в паскале.. ) есть конечно IfThen, но это немного не то.

но это все конечно дело вкуса.


 
Vendict ©   (2007-06-05 00:14) [286]

Defunct ©   (03.06.07 22:23) [113]
В некоторых процессорах имеется аппратный автоикремент индексного регистра, поэтому запись:

 A[ i++ ] = x;

выглядит куда более понятной, читаемой и компактной чем

A[ i ] := x;
i := i + 1;


ничего себе понятной ! не зная языка, не скажешь, что первым делается, увеличивается i или меняется значение элемента массива.


 
Kostafey ©   (2007-06-05 00:18) [287]

> ничего себе понятной ! не зная языка, не скажешь, что первым
> делается, увеличивается i или меняется значение элемента
> массива.

Ну для CPP/Pascal знание - незниние языка не столь актуально...

Вот однажды мне подсунули пронраммульку на Fortran...;)
Куда деваться-разобрался, перенес в Delphi.


 
euru ©   (2007-06-05 00:47) [288]


> default ©   (04.06.07 18:57) [278]
> мне вот интересно, этот язык был экспериментальный или как?
> ...для диссера может лишь...видна же сразу утопичность практического
> применения таких языков из-за чрезвычайной их перегруженности



> Kostafey ©   (04.06.07 22:56) [279]
> А этот АВАР - вообще имхо сумасшедший.Структура кода на
> нем, наверно будет, не читаема, короче не язык - бредполный
> (уж простите за грубость), ну не воспринимается он визуально,
> просто никак вообще не воспринимается.

Вы хотя бы для прикола в Яндексе слово "ABAP" набрали и оценили его экспериментальность.


> McSimm_ ©   (04.06.07 18:43) [277]
> Я тут прикинул...
> MOVE (SUBTRACT (MULTIPLY (MULTIPLY x BY x) BY 5) BY C) TO y.
> Правильная запись ?
Разве такая запись похожа на человеческую? На АВАР это записывается так:
MOVE 5 TO y.
MULTIPLY y BY x.
MULTIPLY y BY x.
SUBTRACT c FROM y.


Но можно использовать и упрощённый синтаксис:
y = 5 * x * x - c.
:)


> default ©   (04.06.07 18:25) [274]
> покажи программку на АВАР?!
Да пожалуйста.
* Вариация на тему "Hello, world"
report z_hello_world.

start-of-selection.
  write / "Hello, world!".


 
Real ©   (2007-06-05 00:53) [289]


> > default ©   (04.06.07 18:25) [274]
> > покажи программку на АВАР?!
> Да пожалуйста.
> * Вариация на тему "Hello, world"
> report z_hello_world.
>
> start-of-selection.
>   write / "Hello, world!".

Ужас какой-то... :)


 
Kostafey ©   (2007-06-05 01:06) [290]

> Вы хотя бы для прикола в Яндексе слово "ABAP" набрали и
> оценили его экспериментальность.

А он оказывается даже на практике применяется.

Ничего не понимаю (С)


 
Defunct ©   (2007-06-05 01:41) [291]

Мне в паскале нравится только одно - базовый тип String. Против этого не попрешь. В С string"а нет, в C++ string реализован через прогнившую абстракцию. Которая рушится при первой же попытке сделать
S = "hello " + "world";
Как ни странно почему-то никто этого не отметил.

Все остальные так называемые преимущетсва Паскаля - якобы более лучшая читаемость кода, строгая типизация позволяющая выявлять ошибки - надуманы. Читаемость кода зависит от опыта и от привычки, а это дело наживное. Годик другой поработать с C - и будет все понятно и естесственно.


 
Однокамушкин   (2007-06-05 08:38) [292]


> Kostafey ©   (04.06.07 23:40) [283]
> > Не нравятся "извращенные" конструкции типа a = (b>c)?(b)
> > :(c).
>
> Ну да, вместо них я пишу что-то вроде:
>
> function cppq(strq: string; str1: string; str2: string):
> string;
> begin
>  if strq=str1 then
>    Result:=str1
>  else
>    Result:=str2;
> end;
>
> Полезня в СPP эта конструкция !

Неэквивалентная замена... сравните:
a = b == 0 ? 0 : c/b;
и
function cppq(Cond: Boolean; const x, y: Real): Real;
begin
 if Cond then
   Result := x
 else
   Result := y;
end;

a := cppq(b = 0, 0, c/b);


так что эту конструкцию не всегда можно заменить функцией, иногда надо if прямо по месту вставлять...


> Defunct ©   (05.06.07 01:41) [291]
> Все остальные так называемые преимущетсва Паскаля - якобы
> более лучшая читаемость кода, строгая типизация позволяющая
> выявлять ошибки - надуманы.

Вы забыли ещё несколько вполне реальных преимуществ Паскаля... например, отсутствие мерзости под названием препроцессор... или нормальная раздельная компиляция модулей, а не объединение исходников на уровне текста... да и строгая типизация лично мне не раз помогала, так что надуманным это преимущество я назвать никак не могу...


 
Однокамушкин   (2007-06-05 08:56) [293]


> Игорь Шевченко ©   (04.06.07 17:48) [270]
> Для того, кто хорошо знает язык, запутанностью это не выглядит.
>  Точно также, как для привыкших к паскалю не выглядят запутанными
> конструкции с множествами (+, *)

Не согласен... психологи говорят, что человек может одновременно оперировать не более чем семью сущностями, да и то не у всех это получается... шесть конструкций в одной строке - это близко к пределу... А операции с множествами - это оперирование одной сущностью, и тут просто надо знать, что это за сущность...

Правда, для тех, кто много раз использовал while (*d++ = *s++); эта конструкция уже воспринимается как единое целое, а не комбинация шести конструкций, и вы этом смысле читается легко... но множество комбинаций, которые человек может запомнить как единое целое, очень мало по сравнению со всем множеством комбинаций...

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


 
db2admin ©   (2007-06-05 09:06) [294]

Loginov Dmitry ©   (04.06.07 23:26) [282]
#define begin {
#define end }

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


 
Alkid ©   (2007-06-05 09:09) [295]

Господа, внесу свежую мысль:
Синтаксис - это вопрос вкуса.
Он ортогонател семантике.
Нету по определению более лучшего синтаксиса или более худшего. Это вопрос првычки. Я привык к С-подобному синтаксису и дельфёвый мне кажется очень неуклюжим. Кто-то привык в паскалевсокму, и сишный синтаксис кажется ему убогим и нечитаемым.
Истины тут нет.


 
Однокамушкин   (2007-06-05 09:46) [296]


> Alkid ©   (05.06.07 09:09) [295]

Неправильная мысль... существуют формальные правила описания синтаксиса (например, форма Бэкуса-Наура) и связанные с ними правила синтаксического разбора... соответственно, грамматики языка могут иметь разные классы - LR(1), LL(1) и т.д... и при таком формальном описании количество и сложность синтаксических конструкций становится измеряемой объективной величиной...

Чтобы было понятнее, поясню... например, писать "{" или "begin" или там "%" или "mod" - это дело вкуса, потому что структура формальных правил при этом не меняются, просто одна лексема заменяется другой... а вот появление оператора ++ грамматику меняет сильно, потому что синтаксис выражения a+++b не описывается контекстно-свободной грамматикой, только контекстно-зависимой, а это объективно сложнее... кстати, если бы вместо ++ и -- использовались бы, например, @+ и @-, проблем бы не было, выражения a@++b и a+@+b не перепутаешь... проблема синтаксиса си в данном случае в том, что плохо проработан алфавит языка, т.е. "++" является одновременно и отдельным символом языка, и допустимой комбинацией двух символов...


 
palva ©   (2007-06-05 09:52) [297]

> Alkid ©   (05.06.07 09:09) [295]
Это точно. А то я все в недоумении читаю наезды на if (a=1) {;} или *a++=*b++;
Что здесь может быть заумного?  Для меня, как для сишника гораздо заумнее выглядит a := b


 
Alkid ©   (2007-06-05 09:53) [298]


> Однокамушкин   (05.06.07 09:46) [296]

Я это всё прекрасно понимаю, да. Но это всё теория. На практике синтаксис является именно делом вкуса. Случаи, где возникает неоднозначность с теми же операторами "++" и "--" редки. Скажу прямо - я на С/С++ программирую уже  лет 7-8 и у меня НИ РАЗУ подобные неоднозначности не возникали. Я что-то делаю не так?


 
Anatoly Podgoretsky ©   (2007-06-05 09:54) [299]

> Однокамушкин  (05.06.2007 09:46:56)  [296]

> проблема синтаксиса си в данном случае в том, что плохо проработан алфавит языка

Да кто же его прорабатывал


 
db2admin ©   (2007-06-05 09:56) [300]

Alkid ©   (05.06.07 09:53) [298]
ну не знаю попробуй книжки почитать Фленова например ))


 
SPeller_work   (2007-06-05 09:56) [301]

А я вот уже 2 года пишу на пхп, Дельфи не трогаю. Сишный синтаксис поначалу непривычен после паскалевского, но привыкаешь. Но читаемость сишных кодов всеравно хуже паскалевских из-за большого количества мелких, но значимых синтаксических деталей вроде {/(:? . Гибкость языка приятна, очень удобно писать $array[] = "new value"; когда хочешь добавить новый элемент к массиву, но поначалу попадался на конструкциях вроде $f = "a" . (true) ? "b" : "c"; (скажите без проверки, чему будет равна переменная f), когда гонялся за "вкусностями" языка.

Пришлось мне пописать и на визуал бейсике, 2005-м. Смесь си и бейсика оставила впечатление хуже паскаля, си и даже старого (визуал)бейсика.

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


 
palva ©   (2007-06-05 10:01) [302]

> чему будет равна переменная f
b это без проверки. Угадал?


 
Loginov Dmitry ©   (2007-06-05 10:05) [303]

ab


 
Reindeer Moss Eater ©   (2007-06-05 10:07) [304]

Лучше всего синтаксис у C#. Лучше даже, чем у Object Pascal.


 
palva ©   (2007-06-05 10:07) [305]

Фигасе! А я привык на c ставить операцию ? чуть ли не на последнее место. Я бы конечно скобками проложился, если бы сам писал.


 
Однокамушкин   (2007-06-05 10:28) [306]


> Reindeer Moss Eater ©   (05.06.07 10:07) [304]
> Лучше всего синтаксис у C#. Лучше даже, чем у Object Pascal.

Это что ж за синтаксис такой замечательный, что он не даёт мне объявить нормальную процедуру там, где требуется именно процедура? Я должен объявлять новый класс, в нём - статический метод, и при вызове этого метода указывать имя класса... класс - это нечто такое, экземпляры чего должны создаваться (или он должен служить предком для других классов), а тут получается, что язык вынуждает меня создавать класс, от которого ни наследования нет, ни экземпляры его не создаются... класс играет роль пространства имён... Какая от этого польза в народном хозяйстве?!!!

А уж что там они со сборками и пространствами имён накрутили, на этом вообще диссертацию по психиатрии писать можно... есть хорошо известная ещё со времён модулы-2 концепция модулей, которые являются и единицам компиляции, и единицами инкапсуляции, и единицами компоновки, и пространствами имён... все дельфисты должны знать эту концепцию, в Delphi её реализовали практически без изменений... А в C#? Простанство имён может быть размазано на несколько сборок, сборка - содержать несколько пространств имён, что является единицей компиляции, вообще понять невозможно... Очень надеюсь, что пессимистичные прогнозы насчёт висты исполнятся, мелкомягкие рухнут, и мы будем избавлены от этого кошмара...

Кстати, эта перепутанность сборок и пространств имён может приводить к совершенно неожиданным ошибкам - пример есть в книге http://www.piter-press.ru/book.phtml?978546900378


 
Reindeer Moss Eater ©   (2007-06-05 10:33) [307]

Это что ж за синтаксис такой замечательный, что он не даёт мне объявить нормальную процедуру

Это не синтаксис, это объектная модель такая.
Кстати я у нее плюсы нашел (после того, как поматерился минут 10)
Если любая "запятая" - это непременно член класса, то до нее лекго добраться через хинты  и подсказки иде.
В частности это касается разных констант - параметров процедур.
Ну удобно же.


 
Однокамушкин   (2007-06-05 10:55) [308]


> Reindeer Moss Eater ©   (05.06.07 10:33) [307]
> Это не синтаксис, это объектная модель такая.

Это имхо не объектная модель, а имитация объектной модели для рекламных целей... ООП сейчас в моде, вот они, вслед за джавой, и сделали такой синтаксис, чтобы можно было заявлять, что язык получился чисто объектно-ориентированным... Только ерунда всё это... есть три основных конструкции, каждая из которых однозначно выдаёт принадлежность языка к классу императивных: while, if и goto - в шарпе есть все три... так что это не ОО-язык, это императивный язык с элементами ООП, поэтому насильственное запихивание любой функции в класс смотрится в нём, как седло на корове... настоящий ОО-язык - это, например, Smalltalk... ради интереса попробуйте найти его описание и посмотреть, как в нём организуются циклы и ветвления... вот в таком языке действительно функция вне объекта - нонсенс...

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


 
Игорь Шевченко ©   (2007-06-05 11:00) [309]

Real ©   (04.06.07 23:24) [280]


> Лично мне приятно видеть "begin" вместо "{", потому что
> для второго нужно помнить что это означает, а для первого
> - достаточно прочитать обычное английское слово.


Для китайца или для русского что begin, что { - ни то, не другое не является родным. Скобку быстрее набить. Так что не надо говорить про "простое английское слово". Особенно про слово implementation - уж роднее некуда.


> Конечно, иногда раздражает что для объявления переменной
> нужно поднятся в секцию VAR - но при этом я всегда вспоминаю
> что сам виноват, больше надо было уделить времени проектированию


Лично меня раздражает, что все переменные надо объявлять в этой секции, даже те, которые нужны сугубо локально, внутри блоков begin..end. Код запутывается донельзя.

Defunct ©   (05.06.07 01:41) [291]


> Читаемость кода зависит от опыта и от привычки, а это дело
> наживное


Целиком и полностью поддерживаю.


 
Reindeer Moss Eater ©   (2007-06-05 11:03) [310]

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

А я вообще не обращаю внимания на то, как его пробуют преподнести.
Мне нравится он сам по себе и все.
:)


 
Юрий Зотов ©   (2007-06-05 11:42) [311]

Возвращаясь к синтаксису Си, предлагаю улыбнуться свежеживому примеру:

palva ©   (05.06.07 09:52) [297]
"...я все в недоумении читаю наезды на if (a=1) {;} или *a++=*b++;
Что здесь может быть заумного?  Для меня, как для сишника гораздо заумнее выглядит a := b"

SPeller_work   (05.06.07 09:56) [301]
"скажите без проверки, чему будет равна переменная f"

palva ©   (05.06.07 10:01) [302]
"b это без проверки. Угадал?"

Loginov Dmitry ©   (05.06.07 10:05) [303]
"ab"

palva ©   (05.06.07 10:07) [305]
"Фигасе!"

=====================================

Что видим? То, что даже сишник с опытом, человек, хорошо знающий язык - и то  "с лету" не понял написанного. Даже ему - и то потребовалось время на осмысливание.

Что тут скажешь? Простой, понятный, прозрачный синтаксис. Однозначно.
:о)


 
etc   (2007-06-05 11:47) [312]


> Юрий Зотов ©   (05.06.07 11:42) [311]

не путайте PHP и С, PHP хоть и С подобный, но всеже не С, так что это нормально.


 
palva ©   (2007-06-05 11:53) [313]

> хорошо знающий язык - и то  "с лету" не понял написанного
Xорошо знающий язык C и то  "с лету" не понял написанного на PHP. Бывает и такое. Но обычно сишник "понимает" также кучу других языков именно потому, что сишные конструкции для него прозрачны. А операция . в C просто отсутствует.


 
Игорь Шевченко ©   (2007-06-05 11:53) [314]


> Что видим? То, что даже сишник с опытом, человек, хорошо
> знающий язык - и то  "с лету" не понял написанного.


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


 
ocean ©   (2007-06-05 12:15) [315]

Глупо защищать С в Дельфовой конференции, но невозможно же слушать эти наезды. "Неоднозначный синтаксис, а вдруг я совершу ошибку"? Понятно, что при работе в команде "молодых дарований" и в условиях вечной нехватки времени это становится существенным. Но, извините, это все же слова ремесленника. "У простых людей и болезни должны быть прямые: переломы конечностей, грыжа..." "Дайте мне begin...end"
С и Паскаль - разные вещи. С прекрасен своей буйной адресной арифметикой, и оператор ++ - его изюминка.


 
DesWind ©   (2007-06-05 12:30) [316]

Разбирался тут в заголовочных файлах от MS для написания плагина, думал поседею.Макросов понапихали до нельзя. Конечно в итоге код в примере получился из трех строчек, но разобраться что на самом деле происходит очень тяжко. И в тоже время вполне понятны и прозрачны заголовочные файлы для Миранды.


 
Плохиш ©   (2007-06-05 12:34) [317]


> ocean ©   (05.06.07 12:15) [315]
> Глупо защищать С в Дельфовой конференции, но невозможно
> же слушать эти наезды.

ИМХО, вдвойне глупо приходить в делфийную конференцию и вопить какой делфи - плохой, а си - крютой и после плякать, что тебя послали...


 
Alkid ©   (2007-06-05 13:10) [318]

Ну здесь особо никто, вроде, и не вопил, что дельфи плохой :-)
Или я что-то пропустил?


 
IMHO ©   (2007-06-05 13:15) [319]


> Игорь Шевченко ©   (05.06.07 11:53) [314]
>
>
> > Что видим? То, что даже сишник с опытом, человек, хорошо
> > знающий язык - и то  "с лету" не понял написанного.
>
>
> Ты забыл добавить, что написанного на другом языке.


Чукча не читатель, чукча исключительно писатель?


 
Игорь Шевченко ©   (2007-06-05 13:17) [320]

IMHO ©   (05.06.07 13:15) [319]

В зеркало, дружок


 
Kostafey ©   (2007-06-05 13:19) [321]

> Неэквивалентная замена... сравните:
> a = b == 0 ? 0 : c/b;
> и
> function cppq(Cond: Boolean; const x, y: Real): Real;
> begin
> if Cond then
>   Result := x
> else
>   Result := y;
> end;
>
> a := cppq(b = 0, 0, c/b);
>
> так что эту конструкцию не всегда можно заменить функцией,
> иногда надо if прямо по месту вставлять...

Я и не говорил, что они эквивалентны.


 
Defunct ©   (2007-06-05 19:08) [322]

Однокамушкин   (05.06.07 08:38) [292]

>> Defunct ©   (05.06.07 01:41) [291]
>> Все остальные так называемые преимущетсва Паскаля - якобы
>> более лучшая читаемость кода, строгая типизация позволяющая
>> выявлять ошибки - надуманы.

> Вы забыли ещё несколько вполне реальных преимуществ Паскаля...
> например, отсутствие мерзости под названием препроцессор... или
> нормальная раздельная компиляция модулей, а не объединение
> исходников на уровне текста... да и строгая типизация лично мне не раз
> помогала, так что надуманным это преимущество я назвать никак не
> могу...

1. Препроцессор есть не только в C, но и в Delphi. В Delphi правда он немного кастрирован, но это больше минус чем плюс. Если вы им не пользуетесь это исключительно ваше дело. Возможно вы просто еще не доросли до использования препроцессора.

2. Раздельная компиляция в C сделана более естественно чем в паскале. Header можно оставлять без изменения, в то время как тело модуля можно править. При этом компилироваться будет лишь только один измененный C файл, а не весь проект. Не будут даже перекомпилироваться файлы которые используют ресурс перекомпилированного C файла. Прочуствовать преимущества полноценной раздельной компиляции (с линковкой) можно только на больших проектах, которые требуют десятки минут сборку.

3. Лично мне отсутствие строгой типизации в C - помогло тоже не раз. Так что для меня жесткая типизация - это именно надуманное преимущество. (если вообще ее можно отнести к преимуществам).


 
Real ©   (2007-06-05 22:08) [323]


> Игорь Шевченко ©
> Для китайца или для русского что begin, что { - ни то, не
> другое не является родным. Скобку быстрее набить. Так что
> не надо говорить про "простое английское слово". Особенно
> про слово implementation - уж роднее некуда.

1. Как ни крути, а английский - это самый популярный язык в мире и в китае кстати, его знает побольше людей чем в России.

2. Все ЯВУ - используют в своем синтаксисе английские слова для операндов

3. Трудно представить программиста не столкнувшегося с английским ни разу. Большая часть трудов по программированию написана именно на этом языке

Даже если человек не знает английского, предположу что "begin" хоть и дольше для набития с клавы, все же будет понятнее, потому что в его родном языке понятия обозначаются сочетанием букв алфавита, а не типографским символом :) Тут как раз только восточные народы привыкшие к иероглифам могут счесть что скобка понятнее :)

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


 
Real ©   (2007-06-05 22:19) [324]


> Xорошо знающий язык C и то  "с лету" не понял написанного
> на PHP. Бывает и такое. Но обычно сишник "понимает" также
> кучу других языков именно потому, что сишные конструкции
> для него прозрачны. А операция . в C просто отсутствует.

Тогда приведите конструкцию на Паскале, которую бы не понял программист пищущий на Бэйсике? ;) Разумеется в рамках того кол-ва символов что в примере с ПХП.

P.S. Даже при условии что бэйсик и паскаль достаточно отличаются, а ПХП и Си практически близнецы


 
Anatoly Podgoretsky ©   (2007-06-05 23:11) [325]

> Real  (05.06.2007 22:08:23)  [323]

Точно, СИ изобрели китайцы


 
palva ©   (2007-06-05 23:11) [326]

Ну такой оборот программист на бейсике вряд ли поймет
a := a SHL 1;
или такой
R := SQR(2);
Только зачем я должен вам приводить такие примеры - не понимаю.
Я должен вас в чем-то убеждать? То что в C много несуразностей я не спорю. В существующем Delphi, который далеко ушел от Вирта тоже много несуразностей. Сабж все же был о пользе. Стоит изучать или не стоит. Если чел собрался зарабатывать на хлеб программированием, то, конечно же, стоит. Знать С/С++ с этой точки зрения гораздо полезнее чем знать Delphi. Еще полезнее знать Basic или 1С. Если же ставить вопрос так: на чем приятней программировать, то мое субъективное мнение - на Delphi или С#


 
Real ©   (2007-06-05 23:16) [327]


> Я должен вас в чем-то убеждать? То что в C много несуразностей
> я не спорю. В существующем Delphi, который далеко ушел от
> Вирта тоже много несуразностей. Сабж все же был о пользе.
>  Стоит изучать или не стоит.

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

P.S. АП прав, китайцев же больше всего, потому он (Си) и более восстребован :)))))


 
Vga ©   (2007-06-05 23:18) [328]


> 2. Раздельная компиляция в C сделана более естественно чем
> в паскале. Header можно оставлять без изменения, в то время
> как тело модуля можно править. При этом компилироваться
> будет лишь только один измененный C файл, а не весь проект.
>  Не будут даже перекомпилироваться файлы которые используют
> ресурс перекомпилированного C файла. Прочуствовать преимущества
> полноценной раздельной компиляции (с линковкой) можно только
> на больших проектах, которые требуют десятки минут сборку.
>

Гм. Вообще-то, дельфи перекомпилирует только те модули, которые изменились. В результате типичная перекомпиляция в дельфи - перекомпиляция пары измененных модулей и линковка их с уже скомпилированными .dcu неизмененных файлов. Так что подобные изменения иногда вызывают даже меньше перекомпиляций (например, если модуль А использует B.Func1, и в B добавили Func2 - A перекомпилировать не требуется. С перекомпилирует, т.к. изменился включаемый файл).


 
Defunct ©   (2007-06-05 23:52) [329]

> Вообще-то, дельфи перекомпилирует только те модули, которые
> изменились.

Я так не думаю.
Как тогда определяется затронута ли интерфейсная секция?

Unit A;

interface

type

  TRec = Record
       i : integer;
  end;

....

Unit B;

uses A;

begin
  writeln( sizeof( TRec) );
end.

Как себя поведет компилятор если в модуле A изменить тип TRec? напр. ввести еще одну переменную:

TRec = Record
  i : integer;
  b : byte;
end;


 
Vga ©   (2007-06-06 00:08) [330]

При изменении использованного типа - да, перекомпилировал. Но и С тоже бы перекомпилировал. А при добавлении в А мового типа TRec2 в интерфейс - B не перекомпилировался. Т.е. перекомпилируется только если изменения интерфейса другого модуля затрагивают этот модуль.


 
Defunct ©   (2007-06-06 00:16) [331]

> Но и С тоже бы перекомпилировал.

Да но в C интерфейсная секция вынесена в отдельный файл. А в Delphi - нет.
Я этот пример привел к тому, чтобы поднять вопрос а как Delphi компилятор узнает изменился тип или не изменился в модуле A? И как он узнает надо ли перекомпилировать модуль B?

Он просто ребилдит все модули в которых используется модифицированный модуль. т.е. раздельная компиляция там несколько урезанная.


 
Vga ©   (2007-06-06 00:45) [332]

Нет. Если используемый тип не изменился, а изменилось что-то другое - то не пересобирает.


 
Vga ©   (2007-06-06 00:47) [333]

Если же изменить реализацию (секция implementation) - то пересоберется только измененный модуль. Остальные не перекомпилируются, т.к. интерфейс тот же, а внутренняя реализация - ненужные при линковке детали.


 
Vga ©   (2007-06-06 00:47) [334]

Тьфу, при компиляции


 
Vga ©   (2007-06-06 00:49) [335]

При компиляции на изменения проверяется не файл. а только интерфейс. И то не весь, а только используемые элементы интерфейса.


 
Defunct ©   (2007-06-06 00:53) [336]

> Если используемый тип не изменился, а изменилось что-то другое -
> то не пересобирает.

Если не затруднит, можете закрепить высказывание какой-нибудь авторитетной ссылкой или цитатой из Help"a?

Т.к. я все же полагаю, что ребилд основан на дате dcu модуля. Дата-время изменилось - вся цепочка использующая этот dcu файл должна быть перекомпилирована.


 
Defunct ©   (2007-06-06 00:54) [337]

> основан на дате dcu модуля

Читайте "основан на модификации" (размер, дата-время, аттрибут файла)


 
euru ©   (2007-06-06 00:57) [338]


> Real ©   (05.06.07 22:08) [323]
Как это не удивительно, но оперировать указателями я научился, когда познакомился с их реализацией на Си. Так что не всегда "Паскаль для обучения".


 
Anatoly Podgoretsky ©   (2007-06-06 00:58) [339]

> Defunct  (06.06.2007 00:54:37)  [337]

Исключительно только на дате pas/dcu файлов, как в среде, так и через make


 
celades ©   (2007-06-06 00:58) [340]


> Читайте "основан на модификации" (размер, дата-время, аттрибут
> файла)

а почему не на хеше? или на хеше каждого definition"а? Нет, модульность Delphi это плюс. К счстью эту самую модульность в далекой перспективе и в С++ сделают.


 
Vga ©   (2007-06-06 00:59) [341]

Закрепить не могу - это результаты наблюдений и экспериментов. Думаю, более старшие мастера на форуме скажут по этой теме больше.


 
Германн ©   (2007-06-06 01:03) [342]


> Anatoly Podgoretsky ©   (06.06.07 00:58) [339]
>
> > Defunct  (06.06.2007 00:54:37)  [337]
>
> Исключительно только на дате pas/dcu файлов, как в среде,
>  так и через make
>

А как же ранее существовавшая разница между изменениями в секциях interface и implementation?


 
Anatoly Podgoretsky ©   (2007-06-06 01:05) [343]

> Германн  (06.06.2007 01:03:42)  [342]

Не знаю о чем, но явно не об изменениях модулей.


 
Vga ©   (2007-06-06 01:08) [344]

Но по эксперименту:

unit A;

interface

uses AvL, B;

function RecSize: string;

implementation

function RecSize: string;
begin
 Result:=IntToStr(SizeOf(TMyRec));
end;

end.


unit B;

interface

type
 TMyRec=record
   A, B: Integer;
   C: Word;
 end;

implementation

function Test: Integer;
begin
 Result:=10;
end;

end.


program UnitTest;

uses AvL, A;

begin
 ShowMessage(RecSize);
end.


AvL обеспечивает функции IntToStr & ShowNessage.

После добавления в модуль B функции Test: Integer (в interface) и нового типа TMyRec2 (тоже в интерфейс) модуль А IDE не перекомпилировала. При этом работает он правильно. Функция Test однако же в модуле B скомпилирована, т.к. я добавил ее использование из головного модуля программы.


 
Vga ©   (2007-06-06 01:10) [345]

Эээ... Зря я разделители в код не поставил. Там три файла, найти где каждый начинается можно по заголовку unit/program


 
Vga ©   (2007-06-06 01:11) [346]

И еще ошибка - в начальном варианте модуля B в implementation отсутствует function Test: Integer - забыл удалить.


 
Vga ©   (2007-06-06 01:13) [347]

Сейчас время у файлов:
UnitTest.exe 3:02
A.dcu: 2:06
B.dcu: 3:02


 
Германн ©   (2007-06-06 01:13) [348]


> Anatoly Podgoretsky ©   (06.06.07 01:05) [343]
>
> > Германн  (06.06.2007 01:03:42)  [342]
>
> Не знаю о чем, но явно не об изменениях модулей.
>

Если мне не изменяет мой склероз, то существовало правило. Если есть изменения только в implementation, то перекомпилировался только сам модуль. А если были изменения в interface, то перекомпилировались и все другие модули, которые его использовали. Или я не прав?


 
Defunct ©   (2007-06-06 01:18) [349]

2 VGA,
Проверил на версии dcc32.exe v15.0, подтверждаю поведение именно такое как вы описываете. Странно.


 
Vga ©   (2007-06-06 01:19) [350]

А вообще, это зависит от компилятора. FPC например хранит интерфейс скомпилированного модуля в отдельном файле, а сгенерированный машинный код - в обычном .o (т.к. он пользуется линкером, ассемблером и прочим из binutils)


 
Vga ©   (2007-06-06 01:21) [351]

Еще бы странно, у меня такая же версия :) Возможно другие версии работают иначе. Вообще, по теории - достаточно при компиляции модуля использовать только интерфейсы других модулей и соответственно только их и проверять на совместимость/изменения. И компилятор вполне может обходиться перекомпиляцией только того, что действительно нужно - дельфи 7 это в общем-то и демонстрирует.


 
Vga ©   (2007-06-06 01:22) [352]

offtop.
Это конечно придирка, но все-таки, я предпочитаю написание Vga, а не VGA.  Хотя ник по сути действительно аббревиатура (И.Ф.О.).


 
Defunct ©   (2007-06-06 01:28) [353]

>И компилятор вполне может обходиться перекомпиляцией только того,
> что действительно нужно - дельфи 7 это в общем-то и демонстрирует.

Ок, с раздельной компиляцией убедили. Но тут надо полагаться на "ум" компиляторов. В C оно все равно прозрачней - изменел header, автоматически все файлы включающие этот header изменятся и как следствие - перекомпилируются. Изменил .c файл - откомпилировался только он.


 
Vga ©   (2007-06-06 01:36) [354]

Зато чудесная прозрачность с тем, как заголовки включаются - типа #ifdef MY_H. У всего есть плюсы и минусы. У модулей в целом меньше видимо, раз Java & C# предпочли именно модули.


 
Kostafey ©   (2007-06-06 01:37) [355]

> Сабж все же был о пользе. Стоит изучать или не стоит. Если
> чел собрался зарабатывать на хлеб программированием, то,
> конечно же, стоит. Знать С/С++ с этой точки зрения гораздо
> полезнее чем знать Delphi

Это из другой опер... в смысле ветки ;)


> то мое субъективное мнение - на Delphi или С#

И Java не забудем ;)


 
Vga ©   (2007-06-06 01:41) [356]

Судя по некоторым - в плане "для удовольствия" не стоит забывать еще питон и руби. Кто их знает из моих знакомых - тащатся :)


 
Vga ©   (2007-06-06 01:42) [357]

А еще не стоит забывать и о lua. Писать на нем - одно удовольствие :) ИМХО.


 
Vga ©   (2007-06-06 01:48) [358]

А о раздельной компиляции и больших проектах - то, что С++ компилирует 10мин, дельфи компилирует 10сек. А то, что С++ компилит всю ночь и выдает на выходе 20МБ ехе - дельфи не переварит (я где-то читал, что при размере выходного ехе больше примерно 20МБ дельфи начинает тормозить и глючить...)


 
Real ©   (2007-06-06 02:00) [359]


> Как это не удивительно, но оперировать указателями я научился,
>  когда познакомился с их реализацией на Си. Так что не всегда
> "Паскаль для обучения".

Просто потому, что в Си идеологически приучают что все данные - это просто свалка байт по определенному адресу и ты, программист - решай сам что с ней делать, как интерпретировать :) Тогда как в Паскале - строгая типизация данных и указатели хоть поддерживаются, но не рекомендуют использовать (кроме случаев, когда необходимо динамичекое выделение памяти, но и в этом случае - рекомендуется использовать типизированный указатель :) А Pointer - в паскале вообще дурной тон :)

По ходу вспомнил что меня больше всего всегда раздражало в Си: зависимость регистра. Это уж точно надо быть машиной, чтобы воспринимать идентификаторы не по семантике, а по комбинации символов из ASCII :-) Ведь в любом естественном языке - регистр служит для удобства чтения, разделения предложений, но никак не для обозначения другого смысла. Почему бы хотя бы не сделать опциональным эту фичу? Я понимаю зависимость регистра в пароле, но какого черта нужно помнить регистр у своих идентификаторов? Причем сами Сишники похоже это неявно признают: верхний регистр стараются не использовать и повсеместно используют "_" для длинных идентификаторов :)


 
SPeller ©   (2007-06-06 02:07) [360]


> ab


> Фигасе!

Точка - это конкатенация строк. На самом деле b :) Прикол в том, что не смотря на скобки, в условие попадает все что до вопроса. А "a1" - это истинное выражение.


 
Vga ©   (2007-06-06 02:08) [361]

[359]
Кстати да... Зато нету разнобоя регистра, как у некоторых неаккуратных товарисчей... :)


 
Defunct ©   (2007-06-06 02:16) [362]

Real ©   (06.06.07 02:00) [359]
> По ходу вспомнил что меня больше всего всегда раздражало в Си:
> зависимость регистра. Это уж точно надо быть машиной

Это вы просто не прониклись идеей.
Ведь как удобно порой объявлять и тип и переменную одним и тем же именем, но в разном регистрe:

struct tagMY_STRUC
{
 ...
} TMY_STRUCT, *PMY_STRUCT;

PMY_STRUCT pMyStruct;
...

> Зато нету разнобоя регистра, как у некоторых неаккуратных
> товарисчей... :)

И это кстати тоже плюс! Код выглядит аккуратнее.


 
Vga ©   (2007-06-06 02:19) [363]


> > Зато нету разнобоя регистра, как у некоторых неаккуратных
>
> > товарисчей... :)
>
> И это кстати тоже плюс! Код выглядит аккуратнее.

Аккуратнее-то аккуратнее, это да. плюс. Вот тока лично у меня код на С\С++ все равно вызывает аллергию :) Да и необходимость соблюдать регистр (особенно когда он задан чужой библиотекой и совсем не нравится) - тоже вызывает дискомфорт :)


 
Defunct ©   (2007-06-06 02:19) [364]

сорри, ночью очепятываюсь:

typedef struct tagMY_STRUC
{
...
} TMY_STRUCT, *PMY_STRUCT;

PMY_STRUCT pMyStruct;


 
Defunct ©   (2007-06-06 02:21) [365]

> Vga ©   (06.06.07 02:19) [363]

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


 
Vga ©   (2007-06-06 02:22) [366]


> Ведь как удобно порой объявлять и тип и переменную одним
> и тем же именем, но в разном регистрe:

Тоже верно. Удобно. Когда пишешь. А когда читаешь чужой код и кроме имени надо запомнить его регистр...


> #define m(x)(x<0?-1:!!x)
> #define g tj()-J
> #define a(x)(x<0?-x:x)
> #define h(x)((x)<=K?x:N-(x))
> #define f 9999
> #define A return
> #define H printf(
> #define R double
> #define U int
> #define V for
> #define b else
> #define u while
> #define B if

Это из реального кода... Дальнейшее разобрать невозможно - больше похоже на base64, чем на язык программирования. Аккуратный квадратик символов. При этом - компилируется и работает.


 
Vga ©   (2007-06-06 02:25) [367]

Нетрудно заметить, что H и h в данном коде выполняют слегка разные операции...


 
Defunct ©   (2007-06-06 02:35) [368]

> Это из реального кода...

Это возможно
1. из реального плохого кода, который читать не нужно.
2. из специально запутанного (некое подобие защиты от модификации) программой автоматом.

В реальных проектах никто бы не стал подменять ключевые слова макросами, да еще и с односимвольными именами.

С другой стороны имеются очень мощные редакторы, способные парсить код и при наведении на идентификатор мышкой - будут показывать вам в отдельном окне - место где была объявлена переменная ее тип и т.п./макрос/функция на которую вы навелись. Пример такого редактора - Source Insight.


 
Vga ©   (2007-06-06 02:47) [369]

Ну да, немного сжульничал и привел код с какого-то конкурса :) Но тем не менее, придется запоминать, что foo - переменная, а Foo - ее тип. Не слишком способствует разбору...
Source Insight - штука конечно крайне полезная :) Хотя даже с помощью подобных инструментов разбирать макросы сложее #define MAX_PATH 260 очень непросто.


 
Defunct ©   (2007-06-06 03:16) [370]

> Хотя даже с помощью подобных инструментов разбирать макросы сложее
> #define MAX_PATH 260 очень непросто.

В основном, в реальном коде макросы читать не приходится, т.к. они просто должны иметь интуитивно понятные имена. Аналогично имен функций.

Но если возникает необходимость их прочитать, то все не так уж и сложно

можно начать с того, что просто подставить параметры макроса и в уме или на листочке просчитать, что получится в результате. Пару-десятков таких успешных подстановок и считайте вы стали мастером макросов. ;>


 
Vga ©   (2007-06-06 03:28) [371]

эээ... Мне с реальным кодом в основном приходится иметь дело, чтобы понять что там к чему и пренести это в дельфи... Или перевести хедер. Как с макросами обращаться - представляю. Но нормальные конструкции разбираются на порядок быстрее.


 
db2admin ©   (2007-06-06 08:27) [372]

Vga ©   (06.06.07 03:28) [371]
> #define m(x)(x<0?-1:!!x)
> #define g tj()-J
> #define a(x)(x<0?-x:x)
> #define h(x)((x)<=K?x:N-(x))
> #define f 9999
> #define A return
> #define H printf(
> #define R double
> #define U int
> #define V for
> #define b else
> #define u while
> #define B if


 
Однокамушкин   (2007-06-06 09:48) [373]


> Defunct ©   (05.06.07 19:08) [322]
> 1. Препроцессор есть не только в C, но и в Delphi. В Delphi
> правда он немного кастрирован, но это больше минус чем плюс.
>  Если вы им не пользуетесь это исключительно ваше дело.
> Возможно вы просто еще не доросли до использования препроцессора.

Вот когда вы напишете в Delphi что-нибудь типа #define if while, тогда я поверю, что в Delphi есть препроцессор... препроцессор - это такое средство, которое позволяет тупо менять один набор символов на другой без учёта контекста и синтаксиса языка... Приведите пример чего-то подобного в Delphi...

А препроцессор я давно перерос... после того, как мой коллега в своём заголовочном файле зачем-то написал #define String STRING, а в моём коде, который использовал этот файл, у меня была структура с полем String... вот тогда я и понял, куда именно нужно засунуть препроцессор...

> 2. Раздельная компиляция в C сделана более естественно чем
> в паскале. Header можно оставлять без изменения, в то время
> как тело модуля можно править. При этом компилироваться
> будет лишь только один измененный C файл, а не весь проект.
>  Не будут даже перекомпилироваться файлы которые используют
> ресурс перекомпилированного C файла. Прочуствовать преимущества
> полноценной раздельной компиляции (с линковкой) можно только
> на больших проектах, которые требуют десятки минут сборку.

Поздравляю - понятие "раздельная компиляция" вам незнакомо... простой пример:
#define _UNICODE
#include <tchar.h>

в tchar.h объявлен тип TCHAR, определение которого зависит от того, определён или нет макрос _UNICODE... получается, что текст импортирующего модуля оказывает влияние на содержание импортируемого... если это раздельная компиляция, то я испанский лётчик... при раздельной компиляции все объявления, сделанные в импортируемом модуле, не зависят от содержания импортирующего...

И ещё... импорт заголовков на уровне препроцессора не позволяет однозначно определить, что нужно перекомпилировать, а что - нет... есть алгоритмы, которые в большинстве случаев дают правильный результат, но иногда всё же ошибаются... именно поэтому, когда я работал на VC++, мне приходилось время от времени делать полный ребилд проекта, потому что мои изменения не учитывались - умный компилятор не догадывался, что некоторые файлы надо перекомпилировать... в дельфях же ребилд мне приходится делать только в однной ситуации - когда я меняю в настройках компилятора какие-то опции, и хочу, чтобы эти изменения затронули весь проект...

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


 
Игорь Шевченко ©   (2007-06-06 10:00) [374]

Real ©   (05.06.07 22:08) [323]


> 1. Как ни крути, а английский - это самый популярный язык
> в мире и в китае кстати, его знает побольше людей чем в
> России.


И почему, спрашивается, математические формулы записываются на специальном языке, а вот программистам без английского хоть в петлю лезь и если begin в тексте программы нет, то она уже нечитаема.

Слабоватый какой-то аргумент, не находишь ?


> В обсуждении давно предлагается непредвзято сравнить синтаксисы.
>  Например с точки зрения начинающего программиста. Сколько
> я помню литературы по программированию для начинающих, во
> всех было написано что-то типа такого: "Паскаль идеален
> для обучения" и "Си - никак не назовешь языком для начинающих".
>  Если язык труден для начинающих, значит неявно подразумевается
> что писать на нем можно только привыкнув, не объясняет ли
> это все о чем спорят?


Для обучения не менее идеален, допустим, Алгол. И что ? Не учат, заразы, на нем.
Для обучения (и специально разработан, кстати) Basic, в котором ни слова от паскаля нет и в помине. И что ?

Не надо учить языку программирования. Ни в коем разе. Учить надо думать, желательно алгоритмически. А какой язык выбрать - а какая, по большому счету разница ?
В свое время народ учили Фортрану - и ничего, выучили. Неплохие программы люди пишут.

Думать, думать и еще раз думать!


 
Игорь Шевченко ©   (2007-06-06 10:01) [375]


> Просто потому, что в Си идеологически приучают что все данные
> - это просто свалка байт по определенному адресу и ты, программист
> - решай сам что с ней делать, как интерпретировать


Ерунда полная, уж извини.


 
euru ©   (2007-06-06 10:02) [376]


> Real ©   (06.06.07 02:00) [359]


> По ходу вспомнил что меня больше всего всегда раздражало
> в Си: зависимость регистра.
Здесь я противоположного мнения. Например, при прочих равных условиях в исходниках Си в отличие от Паскаля не встретишь ключевые слова вида FOR, For. Там возможен только один вариант for, что повышает читабельность текста, т.к. воспринимается уже на уровне подсознания и не требует дополнительной интерпретации.


> Причем сами Сишники похоже это неявно признают: верхний
> регистр стараются не использовать и повсеместно используют
> "_" для длинных идентификаторов :)
Просто так исторически сложилось. SQL, например, тоже регистронезависимый, однако в большинстве случаев названия таблиц пишутся также через "_".


 
Loginov Dmitry ©   (2007-06-06 13:34) [377]

> Здесь я противоположного мнения. Например, при прочих равных
> условиях в исходниках Си в отличие от Паскаля не встретишь
> ключевые слова вида FOR, For. Там возможен только один вариант
> for, что повышает читабельность текста, т.к. воспринимается
> уже на уровне подсознания и не требует дополнительной интерпретации.


Поэтому многие проггеры (если не большинство) на Паскале придерживаются правила - все зарезирвированные слова набирать в нижнем регистре. И тогда уже никаких затруднений с интерпретацией.


 
Alkid ©   (2007-06-06 13:47) [378]


> Ну да, немного сжульничал и привел код с какого-то конкурса
> :) Но тем не менее, придется запоминать, что foo - переменная,
>  а Foo - ее тип. Не слишком способствует разбору...

Ну, не знаю как у вас, а в нормальных конторах, где кодят много на С/С++ есть соглашения о наименовании, которые так же указывают и какой регистр когда использовать.
Правда, всегда есть и шалопаи, которые на них болт кладут :)


 
Defunct ©   (2007-06-06 14:07) [379]

> Однокамушкин   (06.06.07 09:48) [373]
> Вот когда вы напишете в Delphi что-нибудь типа #define if while, тогда я
> поверю, что в Delphi есть препроцессор...

Откомпилируйте и запустите ниже приведенный пример.
Потом разкоментируйте строчку //{$define NEED_UNIT_INIT} и откомпилируйте и запустите еще раз.

unit Unit1;

interface

//{$define NEED_UNIT_INIT}

uses
 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
 Dialogs;

type
 TForm1 = class(TForm)
 private
   { Private declarations }
 public
   { Public declarations }
 end;

var
 Form1: TForm1;

implementation

{$R *.dfm}

{$ifdef NEED_UNIT_INIT}
begin
  ShowMessage("this message depended on preprocessor settings");
{$endif}
end.


> Поздравляю - понятие "раздельная компиляция" вам незнакомо...
> простой пример:
> #define _UNICODE
> #include <tchar.h>
> в tchar.h объявлен тип TCHAR, определение которого зависит от того,
> определён или нет макрос _UNICODE...

Не смешите людей своими примерами. Похоже это вам действительно неизвестно, что такое и для чего нужна "раздельная компиляция". Перечитайте еще раз [322] или [353].

Учить матчасть.


 
Eraser ©   (2007-06-06 14:09) [380]

раздельная компиляция или нет, а "инклудовая" система явно уступает по функциональности и читабельности модульной. в MS это кстати тоже поняли.


 
Defunct ©   (2007-06-06 14:21) [381]

> Однокамушкин   (06.06.07 09:48) [373]
> именно поэтому, когда я работал на VC++, мне приходилось время от
> времени делать полный ребилд проекта, потому что мои изменения не
> учитывались - умный компилятор не догадывался, что некоторые файлы
> надо перекомпилировать...

Значит вы просто не разобрались с makefile...

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

Нет не удобная. Т.к. в большем проекте для целей отладки C позволяет разместить функцию в любом C файле и затем подключить к любому C файлу директивой extern, не изменяя ни одного header файла.

Я вас умоляю. Своим постом вы только показали ваш уровень знаний и по Delphi и по C.


 
Real ©   (2007-06-06 14:22) [382]


> И почему, спрашивается, математические формулы записываются
> на специальном языке, а вот программистам без английского
> хоть в петлю лезь и если begin в тексте программы нет, то
> она уже нечитаема.
> Слабоватый какой-то аргумент, не находишь ?

Не нахожу :) Я не говорил что хоть в петлю лезь без бегина, но считаю что слово на любом языке - нагляднее чем безликий символ, в разных контектсах обозначающий что угодно. И доказывать это не собираюсь, просто высказываюсь как думаю (то бишь имхо :)


> Для обучения не менее идеален, допустим, Алгол. И что ?
> Не учат, заразы, на нем.
> Для обучения (и специально разработан, кстати) Basic, в
> котором ни слова от паскаля нет и в помине. И что ?

Имхо, бэйсик хуже Паскаля для обучения. Алгол - когда будет Делфи для Алгол, тогда и ему будут учить :) Знаю об Алголе не слишком хорошо, но вроде это язык по мотивом которого делался и Паскаль, значит он в целом Паскале-подобный :)


> Не надо учить языку программирования. Ни в коем разе. Учить
> надо думать, желательно алгоритмически. А какой язык выбрать
> - а какая, по большому счету разница ?
> В свое время народ учили Фортрану - и ничего, выучили. Неплохие
> программы люди пишут.

Блин, ну вот опять. Речь о синтаксисе с точки зрения понимания и наглядности! Естественно что главное уметь программировать, а не знать какой-либо язык в совершенстве. Кодинг - для любого языка требует опыта и знаний о языке (правда имхо, в паскале опыт кодинга приходит быстрее :)


> > Просто потому, что в Си идеологически приучают что все
> данные
> > - это просто свалка байт по определенному адресу и ты,
>  программист
> > - решай сам что с ней делать, как интерпретировать
> Ерунда полная, уж извини.

Ну может немного нагнал на Си :) Просто в сравнении с Паскалем, отношение к типу данных менее ответственное (как последствие, в ПХП и появилась конструкция === т.к. иногда требуется знать булевый ли тип был вернут или числовой) и иногда фанатическая тяга к указателям, там где можно без них обойтись вообще.


> > По ходу вспомнил что меня больше всего всегда раздражало
> > в Си: зависимость регистра.
> Здесь я противоположного мнения. Например, при прочих равных
> условиях в исходниках Си в отличие от Паскаля не встретишь
> ключевые слова вида FOR, For

Не знаю, лично для меня что написание: FOR, fOR, For, FoR - означает только одно - оператор цикла FOR :^) Просто наверное потому, что я привык что регистр (шрифт, цвет) символов не меняют смысла слова, то есть так, как в любом естественном человеческом языке. А вот как писали выше - давать типу и экземпляру одинаковые идентификаторы, но в разных регистрах - имхо полный бред: попробуй через неделю вспомнить как именно ты использовал и там и там разный регистр. Отсюда и появляются привычки типа: Типы пишем заглавными, остальное прописными... Но это хорошо до тех пор, пока не придется работать с исходником программиста, у которого все наоборот :) Паскаль тоже дает рекомендации по использованию регистра, но это только рекомендации.


> Просто так исторически сложилось. SQL, например, тоже регистронезависимый,
>  однако в большинстве случаев названия таблиц пишутся также
> через "_".

Хе, это смотря где. В Линухе, где регистрозависимыми являются имена файлов - для MySQL будут и имена таблиц регистрозависимыми. Стоит ли напоминать на каком языке писали *никсы, что везде распространилась регистрозависимость? :)


 
Однокамушкин   (2007-06-06 14:57) [383]


> Defunct ©   (06.06.07 14:07) [379]
> Откомпилируйте и запустите ниже приведенный пример.

Очень интересно... я, кажется, русским языком написал, что мне нужен пример, аналогичный #define if while в Delphi... в ответ я получил пример директивы {$IFDEF}... Не находите, что замена неравноценная? Ещё раз спрашиваю: можно ли написать в Delphi аналог #define if while? Заменить одно ключевое слово другим?

А тот {$DEFINE}, который есть в Delphi, никак не может изменить сам код, поэтому не в пример безопаснее #define... возможность использования того, что так объявлено, локализована в специальных директивах, а не размазана по всему коду...

> Не смешите людей своими примерами. Похоже это вам действительно
> неизвестно, что такое и для чего нужна "раздельная компиляция".
>  Перечитайте еще раз [322] или [353].
>
> Учить матчасть.

Учить матчасть придётся вам, потому что это вы не знаете, что такое раздельная компиляция и чем она отливается от независимой: http://forum.pascal.net.ru/lofiversion/index.php/t12785.html

Под термином "раздельной компиляции" мы понимаем, что полная проверка типов производится компилятором не только внутри модуля, но и по его интерфейсам

А теперь - простой пример того, как C++ "умеет" выполнять такую проверку... создаём новый проект в VC++ - консольное приложение и добавляем к нему ещё два файла - Test.h и Test.cpp...

Файл InclTest.cpp
// InclTest.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "Test.h"

int _tmain(int argc, _TCHAR* argv[])
{
TestOut(1);
return 0;
}


Файл Test.h
extern "C" void __stdcall TestOut(int a);

Файл Test.cpp
#include "stdafx.h"
#include <stdio.h>

extern "C" void __stdcall TestOut(char* a)
{
printf("%s\n", a);
}


Файл stdafx.h не привожу, он стандартный, я там ничего не менял...

Обратите внимание, что прототипы функций TestOut в Test.h и Test.cpp различаются... тем не менее, проект компилируется, а вот при запуске даёт ошибку... потому что вместо TestOut с целым параметром тупой линкер подставил TestOut с параметром char*... так что никакой полной проверки он не выполняет, а без этого компиляция не является раздельной...

Вы можете и дальше рассказывать сказки о том, что в C++ компиляция раздельная, но, боюсь, в неё поверят только те, кто думает, что если при изменении файла перекомпилируется не весь проект, этого уже достаточно, чтобы называть компиляцию раздельной... ещё раз повторяю: в C++ компиляция независимая, но не раздельная...


 
Однокамушкин   (2007-06-06 15:08) [384]


> Defunct ©   (06.06.07 14:21) [381]
> Значит вы просто не разобрались с makefile...

Читайте внимательнее, что я написал... я работал с Visual C++, там по умолчанию никакие makefile не используются... среда решает эти вопросы самостоятельно... и вот почему-то получается, что Delphi такие вопросы решает легко, а VC++ спотыкается...

> Нет не удобная. Т.к. в большем проекте для целей отладки
> C позволяет разместить функцию в любом C файле и затем подключить
> к любому C файлу директивой extern, не изменяя ни одного
> header файла.

А вернувшись к проекту через год, можно запутаться, где что определено и где что используется... а если кому-то потом придётся разбирать ваш код, то я ему заранее сочувствую...

> Я вас умоляю. Своим постом вы только показали ваш уровень
> знаний и по Delphi и по C.

Не беспокойтесь, знания вполне приличные, особенно по Delphi... это вы показываете свой уровень... понимаете, главная задача программиста - писать понятный легко сопровождаемый и модифицируемый код, а судя по тому, что вы считаете возможным где попало объявлять функции и потом как попало их импортировать, этого вы до сих пор не поняли...


 
defunct ©   (2007-06-06 15:13) [385]

> А препроцессор я давно перерос... после того, как мой коллега в своём
> заголовочном файле зачем-то написал #define String STRING, а в моём
> коде, который использовал этот файл, у меня была структура с полем
> String... вот тогда я и понял, куда именно нужно засунуть препроцессор...

А может это не препроцессор виноват, а вы вместе с другом?
И это вас вместе с вашим другом надо засунуть именно туда куда вы предлагаете засунуть препроцессор.
Вы б еще структуре дали имя "struct" и а потом бы жаловались на язык.


 
palva ©   (2007-06-06 15:24) [386]

Что-то непонятно. Вы пишете пример, в котором просите сделать компилятор то-то и то-то. Он делает именно то, что вы пишете. Вы же сами написали для функции разные прототипы. Вполне возможно, что в этом заложен глубокий смысл. Вы хотите чтобы компилятор на этапе компиляции увидел, что прототипы разные? Так напишите тогда код по-другому. Но если программисту взбредет в голову использовать разные прототипы, то у него есть такая возможность.


 
defunct ©   (2007-06-06 15:29) [387]

Однокамушкин   (06.06.07 14:57) [383]

> Очень интересно... я, кажется, русским языком написал, что мне нужен
> пример, аналогичный #define if while в Delphi...

Уж извини, но у меня нет времени на вежлое втолковывание прописных истин. Ты почитай для общего образования, что такое препроцессор и для чего он используется, потом перечитай и попытайся понять смысл фразы из [322]

1. Препроцессор есть не только в C, но и в Delphi. В Delphi правда он немного кастрирован, но это больше минус чем плюс.

А потом наконец въедь, что #define if while это не препроцессор, это макро-определение. То что препроцессор Cи позволяет делать довольно гибкие макроопределения и даже подменять ключевые слова это не баг, это фича. На практике же imho только для экстремалу-экспериментатору может прийти в голову подменять или выбрасывать ключевые слова.

> Не беспокойтесь, знания вполне приличные, особенно по Delphi...

Каждый пост ими блещет.

> понимаете, главная задача программиста - писать понятный легко
> сопровождаемый и модифицируемый код,

Да я это понимаю. Поэтому в отличие от вас я в структурах не объявляю полей с именем "String", и не объявляю #define STRING String,
и никогда даже не пробовал использовать такую чушь как #define if while
потому что это опасно, непонятно и ведет к плачевным последствиям при сопровождении сопровождении.


 
db2admin ©   (2007-06-06 15:32) [388]

Удалено модератором


 
Vendict ©   (2007-06-06 15:57) [389]

Real ©   (05.06.07 22:19) [324]
For j:=0 to 3 do          
sm[j]:=(sm1 and ($ff shl (j*8)))  shr (j*8);
хотя это ещё цветочки ...


 
db2admin ©   (2007-06-06 16:02) [390]

Удалено модератором


 
Alkid ©   (2007-06-06 16:07) [391]


> Вы можете и дальше рассказывать сказки о том, что в C++
> компиляция раздельная, но, боюсь, в неё поверят только те,
>  кто думает, что если при изменении файла перекомпилируется
> не весь проект, этого уже достаточно, чтобы называть компиляцию
> раздельной... ещё раз повторяю: в C++ компиляция независимая,
>  но не раздельная...

Прошу не путать язык С++ и среду разработки Visual C++.
Это в Delphi язык и среда разрабтки тесно увязаны.


 
Alkid ©   (2007-06-06 16:09) [392]


> А вернувшись к проекту через год, можно запутаться, где
> что определено и где что используется... а если кому-то
> потом придётся разбирать ваш код, то я ему заранее сочувствую.
> ..

Ну-ну. Вообще-то бывают и более трудные случаи. Я, вон, не так давно на новую работу устроился, а тут проекты с мегабайтами исходного кода на С++.
И ничего, вник быстро.

Кстати, на предыдуще работы приходилось вникать в код на Дельфи. Скорость вникания от этого не выросла и не уменьшилась. Т.е. от языка она мало зависит.


 
b z   (2007-06-06 16:14) [393]

а вас не напрягает:
procedure
function
property
constructor
destructor

или в противовес:
постоянно указывать public ....
? :)


 
Defunct ©   (2007-06-06 16:29) [394]

> Вы можете и дальше рассказывать сказки о том, что в C++ компиляция
> раздельная, но, боюсь, в неё поверят только те, кто думает, что если при
> изменении файла перекомпилируется не весь проект, этого уже
> достаточно, чтобы называть компиляцию раздельной...

http://home.perm.ru/~strannik/st_txt_prog_02.html

Смотрите пункт
F. РАЗДЕЛЬНАЯ КОМПИЛЯЦИЯ В ЯЗЫКАХ ПРОГРАММИРОВАНИЯ.


 
Loginov Dmitry ©   (2007-06-06 16:49) [395]

> а вас не напрягает:
> procedure
> function
> property
> constructor
> destructor
> или в противовес:
> постоянно указывать public ....


А вот это как раз еще один большой плюс в сторону Паскаля.


 
Однокамушкин   (2007-06-06 17:54) [396]


> defunct ©   (06.06.07 15:29) [387]
> А потом наконец въедь, что #define if while это не препроцессор,
>  это макро-определение. То что препроцессор Cи позволяет
> делать довольно гибкие макроопределения и даже подменять
> ключевые слова это не баг, это фича. На практике же imho
> только для экстремалу-экспериментатору может прийти в голову
> подменять или выбрасывать ключевые слова.

Я знаю, что это фича... просто наличие такой фичи я считаю недостатком, о чём с самого начала и сказал... потому что в больших проектах трудно отследить, кто что переопределил...

> А может это не препроцессор виноват, а вы вместе с другом?
> И это вас вместе с вашим другом надо засунуть именно туда
> куда вы предлагаете засунуть препроцессор.
> Вы б еще структуре дали имя "struct" и а потом бы жаловались
> на язык.

Хамство ваше оставляю без внимания, оно характеризует вас, а не меня, а по поводу всего остального объясняю: в C++ нет зарезервированных слов String и STRING, поэтому использовать такие идентификаторы вполне допустимо... есть тип string в STL, но в том проекте STL не использовался...

А вообще, снова сталкиваюсь с подменой понятий с вашей стороны... я писал про переопределение ключевых слов - вы мне в ответ не относящийся к делу пример про {$IFDEF}... я пишу про идентификатор String - вы переводите стрелки на ключевое слово struct (компилятор, кстати, не дал бы объявить поле с таким именем, и вы не можете этого не знать)... подобную подмену понятий обычно используют тогда, когда возразить по сути нечего...

> Да я это понимаю. Поэтому в отличие от вас я в структурах
> не объявляю полей с именем "String", и не объявляю #define
> STRING String,
> и никогда даже не пробовал использовать такую чушь как #define
> if while
> потому что это опасно, непонятно и ведет к плачевным последствиям
> при сопровождении сопровождении.

Так это должен понимать компилятор, а не программист...

> > Не беспокойтесь, знания вполне приличные, особенно по
> Delphi...
>
> Каждый пост ими блещет.

У вас в контактных данных адрес живой? Мне есть чем доказать своё знание Delphi, но по некоторым причинам не хочу светить это на форуме... так что если вы не против, могу прислать письмо... А то надоело эти обвинения на пустом месте слушать... даже интересно, где это тут я проявил незнание Delphi? В чём конкретно?

> http://home.perm.ru/~strannik/st_txt_prog_02.html
>
> Смотрите пункт
> F. РАЗДЕЛЬНАЯ КОМПИЛЯЦИЯ В ЯЗЫКАХ ПРОГРАММИРОВАНИЯ.

Пока без комментариев, на работе доступ к этому ресурсу почему-то закрыт...


 
Однокамушкин   (2007-06-06 17:57) [397]


> palva ©   (06.06.07 15:24) [386]
> Что-то непонятно. Вы пишете пример, в котором просите сделать
> компилятор то-то и то-то. Он делает именно то, что вы пишете.
>  Вы же сами написали для функции разные прототипы. Вполне
> возможно, что в этом заложен глубокий смысл. Вы хотите чтобы
> компилятор на этапе компиляции увидел, что прототипы разные?
>  Так напишите тогда код по-другому. Но если программисту
> взбредет в голову использовать разные прототипы, то у него
> есть такая возможность.

"Разуму надо придать не крылья, а скорее свинец и тяжесть, чтобы они сдерживали всякий прыжок и полет" - Френсис Бэкон. Мне очень нравится этот философ...


 
defunct ©   (2007-06-06 18:18) [398]

> Однокамушкин   (06.06.07 17:54) [396]
> ...
> А вообще, снова сталкиваюсь с подменой понятий с вашей стороны...

Я протестовал против двух твоих высказываний.

1. Ты сказал что в Delphi нет препроцессора:
... "например, отсутствие мерзости под названием препроцессор..."

в коменте [379] - доказано, что препроцессор в Delphi есть.

2. Ты сказал что в C "ненормальная" раздельная компиляция -

"или нормальная раздельная компиляция модулей, а не объединение
исходников на уровне текста..."

я привел ссылку где сравнивается раздельная компиляция в различных языках. Паскаль набрал там 6 очков, C++ - 8 очков, C - 5.


Других вопросов к тебе ни имею, и не намерен по ним спорить.

Со своими понятиями надо разбираться самому.

> У вас в контактных данных адрес живой?

Живой, но прочитать смогу только вечером.


 
Vga ©   (2007-06-06 21:23) [399]


> db2admin ©   (06.06.07 08:27) [372]

Хех, не, такие приколы я смотрю, но расковырять не пытаюсь :) Хотя думаю, если прогнать через препроцессор и реформаттер - то можно будет и разобрать.


> Ну, не знаю как у вас, а в нормальных конторах, где кодят
> много на С/С++ есть соглашения о наименовании, которые так
> же указывают и какой регистр когда использовать.
> Правда, всегда есть и шалопаи, которые на них болт кладут
> :)

Ну Open Source сообщество контора не совсем нормальная, а из других контор ко мне сорцы обычно не попадают - закрыты :)


 
Vga ©   (2007-06-06 21:43) [400]


> defunct ©   (06.06.07 18:18) [398]

Знание автором статьи по ссылке языка Delphi (в вступлении сказано. что в качестве Pascal рассматривается Delphi) вызывает сомнения.


 
defunct ©   (2007-06-06 21:50) [401]

Vga ©   (06.06.07 21:43) [400]

Ну так в интернете есть другие ресурсы со статьями где можно взять более достоверные данные. Эта статья - первое что мне попалось при поиске в гугле по фразе "Раздельная компиляция". Привел ее просто чтобы показать уважаемому Однокамушкину, как обстоят дела с раздельной компиляцией в C/C++. А то его просто понесло..

Я бегло прочитал эту статью, вроде бы в ней все ок, может быть - немного устаревшие данные, но серьезных сомнений она не вызывает. (по крайней мере у меня)


 
Vga ©   (2007-06-06 22:04) [402]

Явно неверны (AFAIK естественно) таблицы G, H, I для Delphi (в статье под именем Pascal). Вызывает сомнения таблица F. Более ранние таблицы тоже вызывали сомнения, но я их не запоминал.


 
Однокамушкин   (2007-06-06 22:10) [403]


> defunct ©   (06.06.07 18:18) [398]
> в коменте [379] - доказано, что препроцессор в Delphi есть.

Не доказано, там используются {$DEFINE} и {$IFDEF}, которые во всех источниках называются директивами компилятора...

> я привел ссылку где сравнивается раздельная компиляция в
> различных языках. Паскаль набрал там 6 очков, C++ - 8 очков,
>  C - 5.

Посмотрел, с оценками не согласен:

1. По пункту "Раздел интерфейса модуля" паскаль получил одно очко, C и C++ два... видимо, имеется ввиду то, что в паскале interface и implementation находятся в одном файле, а в С всё строго: интерфейс в h-файле, реализация - в c- или cpp-файле... только это существует на уровне устных договорённостей, а так - ничего не мешает в h-файл вставить реализацию, а в #include написать cpp-файл... так что разделение модуля на интерфейсную и содержательную часть в C/С++ существует только до тех пор, пока программист согласен её соблюдать, а Паскаль программиста к этому обязывает, так что имхо у Паскаля по этому пункту оценка правильная, а С и С++ не заслуживают ни одного очка...

2. По пункту "Импорт модулей" не понял, почему С не получил ни одного очка, а С++ - одно... в чём между ними разница? сколько видел кода на С++, нигде ничего, кроме include, не встречал...

3. По пункту "Ограничения видимости" С++ получил одно очко, Паскаль - 0... видимо, имеется ввиду, что в интерфейсной части в C++ можно объявить, скажем, тип, который будет использоваться только приватными полями какого-то класса и не будет виден импортирующему модулю, а в паскале такого сделать нельзя... да, согласен, но есть и обратная сторона медали: в Паскале можно распространять один только dcu-файл, и тогда, например, о приватных членах класса извне узнать будет обычными методами невозможно, а в С++ достаточно просто открыть h-файл... так что по этому пункту очков должно быть поровну...

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

А вообще, профессионализм авторов этого сравнения вызывает большие вопросы... в пункте G Паскаль получил 0 очков за полиморфизм - это что, правда, что в Паскале нет полиморфизма? И это при наличии виртуальных конструкторов, обеспечивающих полиморфизм даже при создании объекта...

В пункте H Паскаль получил ноль за наличие исключений... а как же тогда try/except? да ещё и try/finally, которого мне всегда в C++ не хватало? Я уж думал, что речь идёт о каком-то другом диалекте Паскаля, но нет - для PASCAL использовалась реализация языка в компиляторах фирмы Borland (Objective Pascal системы Delphi)...

В пункте B С и С++ получили больше очков, чем остальные языки, за цикл for... ну да, он гибче, хотя из-за этого хуже оптимизируется... там же Паскаль, С и С++ получили по два очка за оператор break, а Ада - только одно, хотя в Аде break гибче - он позволяет выходить сразу из нескольких вложенных циклов... за блок опреаторов Паскаль не получил ни одного очка, хотя чем begin-end не блок - непонятно... к тому же отсутствие блоков, например, в Обероне относится к достоинствам языка, что авторы теста косвенно признали, подняв баллы за наличие elseif и endif в оценке оператора if... printf и WriteLn являются не операторами вывода, а стандартными процедурами (функциями) вывода... оператора new в Паскале нет, есть функция New, менее гибкая, кстати, чем в C, потому что нет аналога new[]...

В пункте C Паскаль не получил очков за неограниченный массив в параметрах функций, хотя открытые массивы есть со времён TP7... необязательные параметры тоже есть, хотя появились, если не ошибаюсь, только в пятёрке, возможно, этот рейтинг просто старый... хотя нет, очки за перегрузку процедур там у Паскаля есть, а она точно появилась не раньше, чем необязательные параметры... а вот откуда у Паскаля очко за inline-функции, тоже надо спросить у авторов...

В пункте D Паскаль получил только одно очко за скалярный тип и отрезок, а С и С++ по два... в то время как аналога паскалевского типа-диапазона в этих языках я что-то не припомню, а вот возможность назначать свои значения константам скалярного типа тоже уже есть, правда, я это достоинством не считаю... массив с переменной границей в Паскале тоже давно есть, и тоже появился не позже, чем перегрузка процедур, причём динамические массивы имхо удобнее массивов с переменной границей в С и С++... почему Оберон и Паскаль получили поровну за множество, я тоже не понимаю, в Обероне Вирт решил существенно упростить этот тип, так что обероновский SET - это аналог паскалевского set of 0..31, а других множеств в Обероне нет...

В пункте E Паскаль наравне с C и C++ не получил ни одного очка за контроль границ индекса массива, хотя в Паскале этот контроль можно включить, а в С и это невозможно...

В общем, это не тот рейтинг, которому можно доверять... думаю, что если бы я знал лучше Джаву, Модулу и Аду, нашёл бы ещё ошибки...


 
Vga ©   (2007-06-06 22:17) [404]


> Однокамушкин   (06.06.07 22:10) [403]

+1. Но по Модуле-2 - врядли, этот язык автор похоже знает лучше всех. В том числе и упоминаемый "Странник" представляет собой компилятор Модулы-2, Модулы-2 с синтаксисом С и Модулы-2 с синтаксисом Паскаля, написан ессно на Модуле-2 и компилится сам собой.


 
Anatoly Podgoretsky ©   (2007-06-06 22:23) [405]

> Однокамушкин  (06.06.2007 22:10:43)  [403]

> в Обероне Вирт решил существенно упростить этот тип, так что обероновский SET - это аналог паскалевского set of 0..31, а других множеств в Обероне нет...

Как он посмел, а еще математик


 
Vga ©   (2007-06-06 22:24) [406]

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


 
Vga ©   (2007-06-06 22:26) [407]

Вообще "Страник" напоминает ситуацию с языками на .NET на данный момент - языки, не являющиеся С# не реализуют полную функциональность ни .NET, ни самих себя.


 
Однокамушкин   (2007-06-06 22:28) [408]


> Anatoly Podgoretsky ©   (06.06.07 22:23) [405]
> Как он посмел, а еще математик

А разве Вирт математик? Насколько я помню, он закончил факультет электротехники...
http://www.inr.ac.ru/~info21/wirth/wirth_avia.htm


 
Vga ©   (2007-06-06 22:43) [409]


> Однокамушкин   (06.06.07 22:28) [408]
> > Anatoly Podgoretsky ©   (06.06.07 22:23) [405] > Как он
> посмел, а еще математикА разве Вирт математик? Насколько
> я помню, он закончил факультет электротехники...http://www.
> inr.ac.ru/~info21/wirth/wirth_avia.htm

Круто. Жаль, о выступлении Вирта в нашем универе я узнал постфактум :(


 
Defunct ©   (2007-06-06 23:54) [410]

> Не доказано, там используются {$DEFINE} и {$IFDEF}, которые во всех
> источниках называются директивами компилятора...

http://en.wikipedia.org/wiki/Preprocessor

остальное в ответе на письмо


 
Однокамушкин   (2007-06-07 07:09) [411]

Чтобы окончательно лично для себя решить вопрос с препроцессором в Delphi, провёл эксперимент - написал такой вот код:

procedure TForm1.Button1Click(Sender: TObject);
var
 a: Integer;
begin
 a := 10;
 if a{$IF Less}<{$ELSE}>{$IFEND}=20 then
   ShowMessage("Yes")
 else
   ShowMessage("No");
end;


Суть в том, что спорная директива разбивает на части лексему... код не компилируется, компилятор останавливается на символе "=" и пишет "Expression expected but "=" found"... если выкинуть символ "=", всё компилируется... отсюда вывод: директивы компилятора можно вставлять в любом месте между лексемами, но нельзя разбивать ими лексему на части...

Если бы в Delphi был настоящий препроцессор, который, соласно определению, обрабатывает текст перед компилятором, ему было бы всё равно, разбиваются лексемы на части или нет... компилятору тоже было бы всё равно, потому что на входе он получал бы код, в котором лексема была бы слита... возникновение в данной ситуации ошибки означает одно: директивы компилятора обрабатываются лексическим анализатором, а лексический анализатор - это часть компилятора, а не то, что выполняется до компилятора, так что препроцессора в дельфях всё же нет...

И ещё одна аналогия в голову пришла... тут в соседней ветке недавно выкладывались ссылки на статьи о том, насколько плохо наши интуитивные представления подходят для понимания основ классической механики... из людей приходится буквально выбивать интуитивные представления, чтобы они всё-таки смогли понять, как же будет двигаться тело... Имхо, то же самое и с программированием: наши интуитивные представления очень плохо походят для написания надёжных программ, из людей надо выбивать сконность к трюкачеству и заставлять писать нормальный код... и Паскаль лучше С в этом отношении, потому что на С можно писать и так и этак, а Паскаль всё-таки подталкивает от инстинктов к стргости, и в этом его достоинство...

И ещё одна мысль, которая пришла в голову... много раз от разных людей я слышал примерно такие слова: "Я ...дцать лет занимаюсь программировнием, за это время мне ни разу не понадобилось использовать goto, но если вдруг понадобится, я сделаю это не задумываясь, и никакая теория меня не переубедит"... причём во всех случаях это говорили программисты, чья квалификация не вызывала у меня сомнений - например, однажды я услышал такое от заслуженно уважаемого здесь Юрия Зотова... И меня это всегда удивляло, на мой взгляд, цепочка рассуждений должна быть совсем другая: я знаю, что есть теоретическое обоснование ненужности goto и ...дцать лет на практике я получал подтверждение того, что оно действительно не нужно, и если я столкнусь с ситуацией, когда мне захочется применить goto, то я остановлюсь и крепко подумаю, не сделал ли я где-то серьёзной ошибки... вот и в С очень много таких конструкций, что если возникает желание их применить, то нужно искать ошибку, а такие конструкции в языке имхо не нужны...


 
C+-   (2007-06-07 09:45) [412]

А можно вопрос?

int some(int a){return a+5;}

int b=3;
int c=some(b++);

Чему будет равно с?


 
Bless ©   (2007-06-07 10:14) [413]


> Чему будет равно с?


Восьми. А в чем подвох?


 
C+-   (2007-06-07 10:25) [414]

>>>Bless ©   (07.06.07 10:14) [413]

А подвоха нет. Только правильный ответ - "8 или 9, смотря чем компилировать"


 
tesseract ©   (2007-06-07 10:39) [415]


> Если бы в Delphi был настоящий препроцессор, который, соласно
> определению, обрабатывает текст перед компилятором,


Borland  всегда гордился однопроходным компилятором pascal.


 
Bless ©   (2007-06-07 10:42) [416]


> C+-   (07.06.07 10:25) [414]
> Только правильный ответ - "8 или 9, смотря чем компилировать"


А чем компилировать, чтоб получить 9?


 
tesseract ©   (2007-06-07 10:45) [417]


> А чем компилировать, чтоб получить 9?


Watcomm попробуй.


 
Bless ©   (2007-06-07 10:45) [418]

Это я так деликатно выражаю сомнение в том, что "c" может равняться 9 вообще :) На мой взгляд, как раз в этом примере нет неоднозначностей.


 
palva ©   (2007-06-07 10:52) [419]

> Watcomm попробуй.
А разве есть такой компилятор? Это я так деликатно выражаю сомнение в том, что название компилятора написано правильно.


 
Bless ©   (2007-06-07 11:08) [420]


> tesseract ©   (07.06.07 10:45) [417]
>
> Watcomm попробуй.


Мне напряжно качать десятки мегабайт (Open Watcom), чтоб просто попробовать. Готов поверить на слово. Проверял? Дает 9?
А еще лучше объясни словами, с какой стати пример в принципе может давать 9? Операция постинкремента подразумевает увеличение аргумента ПОСЛЕ подстановки его в выражение. В данном случае выражение примитивно и не допускает разночтений. Разве нет?


 
Bless ©   (2007-06-07 11:08) [421]


> tesseract ©   (07.06.07 10:45) [417]
>
> Watcomm попробуй.


Мне напряжно качать десятки мегабайт (Open Watcom), чтоб просто попробовать. Готов поверить на слово. Проверял? Дает 9?
А еще лучше объясни, с какой стати пример в принципе может давать 9? Операция постинкремента подразумевает увеличение аргумента ПОСЛЕ подстановки его в выражение. В данном случае выражение примитивно и, имхо, не допускает разночтений. Разве нет?


 
Bless ©   (2007-06-07 11:10) [422]

Прошу прощения за дубль


 
C+-   (2007-06-07 12:03) [423]

А так скока будет?

int some(int a,b){return a/b;}
int a=1;
int c=some(a++,a++);


 
Vendict ©   (2007-06-07 12:17) [424]

здесь по-моему в любом случае 1ца


 
C+-   (2007-06-07 12:26) [425]

>здесь по-моему в любом случае 1ца

Ага, тока наоборот. Все кроме 1.


 
clickmaker ©   (2007-06-07 12:28) [426]


> [423] C+-   (07.06.07 12:03)

calling convention?


 
Bless ©   (2007-06-07 12:29) [427]


> C+-   (07.06.07 12:03) [423]
>
> А так скока будет?


Вот так по-разному :)


 
Evgeny V ©   (2007-06-07 13:02) [428]

C+-   (07.06.07 12:26) [425] Пример интересный:-)
А  скомплировать под VS 2005 c поддержкой CLR??:-)))


 
_Слоник   (2007-06-07 13:43) [429]


> C+-   (07.06.07 12:03) [423]
> А так скока будет?
> int some(int a,b){return a/b;}
> int a=1;
> int c=some(a++,a++);

не помню как в с++ проходит пребразование к флоату, скорее всего будет 0 (результат точно 0.5). т.е. если бы в функции было b/a, то ответ 2.


 
defunct ©   (2007-06-07 16:35) [430]

> Однокамушкин   (07.06.07 07:09) [411]
Если бы в Delphi был настоящий препроцессор, который, соласно определению, обрабатывает текст перед компилятором, ему было бы всё равно, разбиваются лексемы на части или нет... компилятору тоже было бы всё равно, потому что на входе он получал бы код, в котором лексема была бы слита... возникновение в данной ситуации ошибки означает одно: директивы компилятора обрабатываются лексическим анализатором, а лексический анализатор - это часть компилятора, а не то, что выполняется до компилятора, так что препроцессора в дельфях всё же нет...

Я же ж сразу сказал что он немного кастрированный.
Но теперь то вы согласны, что он есть?


 
defunct ©   (2007-06-07 16:47) [431]

> C+-   (07.06.07 10:25) [414]
>> int some(int a){return a+5;}

>> int b=3;
>> int c=some(b++);

>> Чему будет равно с?
> А подвоха нет. Только правильный ответ - "8 или 9,
> смотря чем компилировать"

Неправда ваша. Здесь однозначный ответ 8.

А пример с неоднозначностью может быть например таким:

int i;
int x;

i = 5;
x = ++i + ++i;


 
Однокамушкин   (2007-06-08 09:33) [432]


> tesseract ©   (07.06.07 10:39) [415]
> Borland  всегда гордился однопроходным компилятором pascal.

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


 
Однокамушкин   (2007-06-08 10:28) [433]


> defunct ©   (07.06.07 16:35) [430]
> Я же ж сразу сказал что он немного кастрированный.
> Но теперь то вы согласны, что он есть?

Нет, не согласен... просто в Delphi часть той функциональности, которая в С реализуется препроцессором, берёт на себя лексический анализатор, а это не совсем одно и то же, и в тонких сулчаях разницу можно заметить... а сам факт наличия такой функциональности я никогда не отрицал, я эти директивы ещё в Турбо Паскале использовал...

Также я по-прежнему не согласен, что в С есть раздельная компиляция... Поймите меня правильно, я не отрицаю, что С и С++ умеют перекомпилировать только часть исходников, а не весь проект, и даже согласен с тем, что в большинстве случаев умеет правильно определять, какая именно часть исходников должна быть перекомпилирована... не согласен я с тем, что этого достаточно, чтобы называть компиляцию раздельной, она не раздельная, она независимая, хотя и более совершенная, чем незавивимая компиляция в Фортране... К сожалению, эти понятия действительно часто путают...

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

Но стоит ли строго следовать теории, если мы можем писать код проще, быстрее, а иногда и эффективнее, отсутпая от него? Думаю, понятно, что вопрос этот вызывает споры... Я лично вот что думаю по этому поводу... вот, например, существует умножение  в столбик - хорошо обоснованный формализм, который позволяет человеку умножить любое число на любое другое... но кто пользуется этим формализмом при умножении на 10? Никто - легче просто приписать нолик... а в школе у нас, помниться, была даже тема такая, "Формулы сокращённого умножения"... учили, что при умножении некоторого двузначного числа на 11 получается трёхзначное число, первая и последняя цифра которого совпадают с первой и последней в исходном числе, а средняя является суммой этих чисел... а если надо умножить на 25, то проще умножить на 100, а потом разделить на 4... Оправдано ли применение этих правил человеком? Да, оправдано, т.к. сокращает время вычислений, а проверка условий применимости и ветвление человеческому мозгу в смысле времени почти ничего не стоят... но представьте, например, что вы пишете библиотеку вычислений больших чисел - будете вы их использовать или ограничитесь универсальным формальным методом? Думаю, что ограничитесь формальизмом, потому что он даёт гарантированный результат при любых исходных данных и не требует многчисленных проверок условий применимости и ветвлений - код получается намного понятнее, его проще удержать в голове при написании и легче потом сопровождать...

К чему я всё это? К достоинствам С и С++ традиционно относят именно то, что они легче других языков позволяют программисту отказаться от формализма и реализовать более эффективные в конкретном случае частные правила... Но если писать действительно надёжный код, то во многих случаях окажется, что надо проверять довольном много условий применимости частного правила, чего обычно не делают, так как это сводит на нет преимущества в производительнсти... Условия применимости частных правил обычно только подразумеваются программистом - например, подразумевается, но не проверяется, что индекс массива не превысит его верхней границы... Но, с другой стороны, есть ситуации, когда применение частных правил позволяет получить более высокую производительность без снижения надёжности кода - за это С и С++ и любят...

Следолвательно, вопрос о том, хорош или нет принятый в этих языках подход, сводится к тому, оправдано или нет использование этих частных правил вместо универсальных, диктуемых строгой теорией... оправдано, но только тогда, когда действительно нужно выжать максимум производительности, а таких ситуаций благодаря совершенствованию железа и оптимизаторов становится всё меньше... следовательно, и область такого подхода должна сокращаться, потому что глупо, например, гордиться тем, что программа реагирует на нажатие конпки не за 3, а за одну миллисекунду, пользователь всё равно не заметит разницы... поэтому я и считаю, что мейнстримом должны стать строгие языки с не слишком гибкими конструкцияим, даже строже и менее гибче, чем нынешняя дельфя, а удел С с С++ это специальные относительно редкие применения в тех случаях, когда действительно требуется что-то выжать...

ЗЫ ой как букф многа, сам нипанимаю как асилил :))))))))


 
Vendict ©   (2007-06-09 16:30) [434]

C+-   (07.06.07 12:03) [423]
так кто-нибудь объяснит, почему ?


 
Однокамушкин   (2007-06-10 07:21) [435]


> palva ©   (06.06.07 15:24) [386]
> Что-то непонятно. Вы пишете пример, в котором просите сделать
> компилятор то-то и то-то. Он делает именно то, что вы пишете.
>  Вы же сами написали для функции разные прототипы. Вполне
> возможно, что в этом заложен глубокий смысл. Вы хотите чтобы
> компилятор на этапе компиляции увидел, что прототипы разные?
>  Так напишите тогда код по-другому. Но если программисту
> взбредет в голову использовать разные прототипы, то у него
> есть такая возможность.

Прототип функции это такой же важный признак, как имя... с вашей логикой можно дойти до того, что если объявлена функция с одним именем, а реализована с другим, компилятор всё равно должен вызвать функцию с другим именем, потому что так написан код - а вдруг в этом заложен глубокий смысл?


 
Algol   (2007-06-10 09:28) [436]


> оправдано, но только тогда, когда действительно нужно выжать
> максимум производительности, а таких ситуаций благодаря
> совершенствованию железа и оптимизаторов становится всё
> меньше

Отнюдь. Да, железо совершенствуется, но и задачи усложняются. Причем если производительность имеет тенденцию расти линейно, то сложность задач как правило растет совсем нелинейно. Поэтому какое бы железо не было, всегда найдутся задачи, которые требуют еще большей производительности. А времена, когда компьютеры считали только корни квадратного уравнения - давно прошли.


 
Algol   (2007-06-10 09:32) [437]


> C+-   (07.06.07 12:03) [423]
> так кто-нибудь объяснит, почему ?

После передачи первого параметра в функцию some(a++,a++) , значение a увеличивается на единицу, и в качестве второго параметра передается уже 2. Внутри функции происходит деление 1/2, но поскольку оба аргумента - целые, то происходит целочисленное деление, которое дает 0.


 
@!!ex_   (2007-06-10 09:34) [438]

Ничто так не раздувает ветку, как очередной холивар...


 
Bless ©   (2007-06-10 10:18) [439]


> Algol   (10.06.07 09:32) [437]
> Внутри функции происходит деление 1/2, но поскольку оба
> аргумента - целые, то происходит целочисленное деление,
> которое дает 0
>


Это не так. Стандарт не определяет порядок вычисления аргументов.
Цитата из "ISO/IEC 14882:1998 - C++ Final Draft" касаемо аргументов функций:
The order of evaluation of arguments is unspecified. All side effects of argument expression evaluations take effect before the function is entered. The order of evaluation of the postfix expression and the argument expression list is unspecified.

То есть допустим ряд вариантов, дающих разный результат, каждый из которых будет соответствовать стандарту. Например, первым будет вычислен второй аргумент (1), затем сработает его ++ и посчитается первый аргумент (2). В результате работы функции получим 2. Также допустима такая ситуация (если я правильно трактую второе из процитированных предложений, в чем я не совсем уверен): посчитается первый аргумент (1), второй аргумент (1), и лишь после этого выполнятся два ++. В результате функция вернет 1. :)


 
Bless ©   (2007-06-10 10:22) [440]

Не то процитировал у Algol-а. Мое возражение конечно же относится к предложению

> После передачи первого параметра в функцию some(a++,a++)
> , значение a увеличивается на единицу, и в качестве второго
> параметра передается уже 2.
>


 
Однокамушкин   (2007-06-11 09:30) [441]


> Algol   (10.06.07 09:28) [436]
> Отнюдь. Да, железо совершенствуется, но и задачи усложняются.
>  Причем если производительность имеет тенденцию расти линейно,
>  то сложность задач как правило растет совсем нелинейно.
>  Поэтому какое бы железо не было, всегда найдутся задачи,
>  которые требуют еще большей производительности. А времена,
>  когда компьютеры считали только корни квадратного уравнения
> - давно прошли.
> <Цитата>

Ну я же специально сказал, что совершенствуется не только железо, но и оптимизаторы... и современным оптимизаторам часто бывает легче оптимизировать код строгих языков, чем излишне гибких, потому что при оптимизации кода того же С++ надо всегда помнить, что у этого кода может быть какой-то особый смысл, который нельзя потерять, а вот, скажем, в Обероне таких проблем почти не возникает... Чем выше уровень абстракции, тем легче работать оптимизатору, да и с точки зрения экономики сейчас во многих случаях выгоднее загрузить лишней задачей процессор, чем программиста, т.к. машинное время намного дешевле... Вон, в Дельфи большинство людей почему-то пишут программы с помощью VCL, и их это устраивает, хотя всем известно, что без VCL можно написать такую же программу, но более быструю и меньую по объёму, только за гораздо больший срок, и код будет содержать ещё больше невыловленных багов, чем VCL... Так что давайте оставим низкоуровневую оптимизацию оптимизатору, а сами будем заниматься тем, что компьютер делать не умеет, тем более что, как написал один умный человек в каком-то форуме, "современный компилятор знает ассемблер гораздо лучше среднего программиста"...

А то, что задачи, в которых всё-таки потребуется ручная оптимизация, найдутся, я тоже писал... и писал о том, что не нужно использовать языки, заточенные на такую оптимизацию, в тех задачах, где она не нужна, потому что там, где мы можем себе это позволить, лучше сосредоточиться на том, что должно быть сделано, а не на том, как оно должно быть сделано...


 
Algol   (2007-06-11 12:15) [442]


> Это не так. Стандарт не определяет порядок вычисления аргументов.
>
> Цитата из "ISO/IEC 14882:1998 - C++ Final Draft" касаемо
> аргументов функций:
> The order of evaluation of arguments is unspecified. All
> side effects of argument expression evaluations take effect
> before the function is entered. The order of evaluation
> of the postfix expression and the argument expression list
> is unspecified.


А я спорю?) Я привожу пример как вычисляет конкретно мой компилятор (MSVS), а он вычисляет именно в такой последовательности.


 
celades ©   (2007-06-11 12:18) [443]


> Я привожу пример как вычисляет конкретно мой компилятор
> (MSVS),

ты уверен? просто порядок может меняться от вызова к вызову...


 
Vga ©   (2007-06-11 12:57) [444]

Гм. AFAIK, поведение компилятора на выражении, в котором одна переменная инкрементируется более одного раза непредсказуем и зависит как минимум от компилятора (а С++ не дельфи, где компилятор ровно 1), а возможно и от придури одного и того же компилятора (например изменение уровня оптимизации или взаимодействие при оптимизации с кодом на строчку выше/ниже... но это уже только мое предположение).


 
hahol_64_rus   (2007-06-11 20:35) [445]

а по моему чем проще тем лучше
ну этот С++ в ..опу


 
Юрий Зотов ©   (2007-06-11 23:17) [446]

> Vga ©   (11.06.07 12:57) [444]

> поведение компилятора на выражении, в котором одна переменная
> инкрементируется более одного раза непредсказуем и зависит как
> минимум от компилятора

Совершенно точно. Несовместимость и непредсказуемость уже на уровне исходников. Самые натуральные подводные грабли, да еще какие!!!

Но заметьте - стоит только убрать из языка этот самый инкремент, как тут же все становится на свои места. Однозначно.

Об чем и речь.


 
ferr ©   (2007-06-11 23:20) [447]

> Совершенно точно. Несовместимость и непредсказуемость уже
> на уровне исходников. Самые натуральные подводные грабли,
> да еще какие!!!
>
> Но заметьте - стоит только убрать из языка этот самый инкремент,
> как тут же все становится на свои места. Однозначно.
>
> Об чем и речь.

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


 
Юрий Зотов ©   (2007-06-11 23:23) [448]

> ferr ©   (11.06.07 23:20) [447]

Иногда встречаются люди, у которых воображение развито значительно сильнее логики, Вы не находите?

:о)


 
ferr ©   (2007-06-11 23:28) [449]

> Иногда встречаются люди, у которых воображение развито значительно
> сильнее логики, Вы не находите?

Я чтот не понимаю, это я себя так должен найти? Ну да бог с ним..

Просто для программирования на c++ должны допускаться люди имеющие справку из психдиспансера и других смежных служб, а то они там такого наворотят.. А на дельфи и джаву можно посадить хоть мартышку.. Плохо это или хорошо, наверное хорошо, но это ничуть не умоляет с++, он такой какой он есть.


 
Юрий Зотов ©   (2007-06-11 23:37) [450]

> ferr ©   (11.06.07 23:28) [449]

Поскольку второй абзац еще раз подтверждает первый, с Вами трудно не согласиться.


 
celades ©   (2007-06-11 23:38) [451]

Пробема не в языке, а в людях. С++ не все могут "асилить".


 
Юрий Зотов ©   (2007-06-11 23:55) [452]

> celades ©   (11.06.07 23:38) [451]

Ничего уж такого особенного для осиливания там нет. Как, впрочем, и в других ЯВУ. А насчет того, где проблема - перечитайте [444] и несколько постов выше.

Продолжая логику [447]: что Вы скажете о пистолете, который неизвестно куда выстрелит - то ли вперед, то ли назад?


 
Anatoly Podgoretsky ©   (2007-06-11 23:57) [453]

> celades  (11.06.2007 23:38:31)  [451]

Просто не все могут получить справку из психдиспансера


 
ferr ©   (2007-06-12 00:09) [454]

> Продолжая логику [447]: что Вы скажете о пистолете, который
> неизвестно куда выстрелит - то ли вперед, то ли назад?

Ну есть книжка в которой написано в какую погоду куда он стреляет ;-)


 
Юрий Зотов ©   (2007-06-12 00:12) [455]

> ferr ©   (12.06.07 00:09) [454]

> Ну есть книжка

Угу, есть. Причем далеко не одна. И в каждой написано по-разному.

[444] читали? Поняли?


 
ferr ©   (2007-06-12 00:20) [456]

> [444] читали? Поняли?

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


 
Юрий Зотов ©   (2007-06-12 00:26) [457]

> ferr ©   (12.06.07 00:20) [456]

Люди имеют полное право использовать абсолютно все возможности, которые предоставляет им синтаксис языка. А этот самый синтаксис ОБЯЗАН быть таким, чтобы НИКАКИХ неоднозначных трактовок не могло возникнуть в ПРИНЦИПЕ. В том числе, и у разработчиков компиляторов.

Иначе это язык для общения на одесском привозе, а не с компьютером.


 
ferr ©   (2007-06-12 00:35) [458]

> Люди имеют полное право использовать абсолютно все возможности,
> которые предоставляет им синтаксис языка. А этот самый
> синтаксис ОБЯЗАН быть таким, чтобы НИКАКИХ неоднозначных
> трактовок не могло возникнуть в ПРИНЦИПЕ. В том числе, и
> у разработчиков компиляторов.
>
> Иначе это язык для общения на одесском привозе, а не с компьютером.

Всё б вам использовать.. Вот вы на джаве писали я знаю.. И вы без задний мысли использовали derpecated методы? Думаю нет, тогда объясните неучу разницу.


 
ferr ©   (2007-06-12 00:36) [459]

Всё б Вам.. ;-)


 
Юрий Зотов ©   (2007-06-12 00:43) [460]

> ferr ©   (12.06.07 00:35) [458]

Странно, что ПРОГРАММИСТ ссылается на deprecated-методы в ветке, где речь идет о ЯЗЫКАХ...

Derpecated-методы бывают у КЛАССОВ и к ЯЗЫКУ абсолютно никакого отношения не имеют.


 
ferr ©   (2007-06-12 00:48) [461]

Вещи-то разные но смыслом похожи, ни те не рекомендуется использовать, ни эти.

Хорошо, приведу другой пример, создатели java отказались от оператора безусловного перехода, в то время как например в delphi он есть. Но де-факто он derprecated, не так ли?


 
Anatoly Podgoretsky ©   (2007-06-12 00:50) [462]

> ferr  (12.06.2007 00:48:41)  [461]

Ничего подобного, просто не рекомендуемый, но derprecated его не объявляли.


 
ferr ©   (2007-06-12 00:54) [463]

> Ничего подобного, просто не рекомендуемый, но derprecated
> его не объявляли.

Ну я его так назвал, возможно, чересчвур вольно, на самом деле его просто не рекомендуют, как и многие "крайние" возможности с++.


 
Юрий Зотов ©   (2007-06-12 01:00) [464]

> ferr ©   (12.06.07 00:48) [461]

Скажите честно - Вы ПОНИМАЕТЕ, о чем идет речь в ЭТОЙ ветке?

При чем тут ВООБЩЕ всякие там deprecated?

В Паскале Вы можете писать goto. Можете не писать. Как угодно. На однозначность это абсолютно НИКАК не влияет. Она сохраняется ВСЕГДА, какую бы синтаксическую конструкцию Вы ни использовали. Хоть рекомендуемую, хоть нет. Результат всегда ПРЕДСКАЗУЕМ.

Но когда результат вызова MyFunction(i++, i++) НЕПРЕДСКАЗУЕМ... и эта программа управляет ядерным реактором...


 
ferr ©   (2007-06-12 01:18) [465]

> Скажите честно - Вы ПОНИМАЕТЕ, о чем идет речь в ЭТОЙ ветке?

Мне казалось что да, жаль вот только я не понимаю смысла ЭТОЙ ветки.

Пожалуй, я удалюсь из этой ветки, чтобы лишний раз никого не нервировать.

Я лишь пытался высказать СВОЮ точку зрения. Она состояла в том, что на с++ может программировать лишь "воспитанный" человек, который не говорит компилятору всякие "гадости".


 
Юрий Зотов ©   (2007-06-12 01:37) [466]

> ferr ©   (12.06.07 01:18) [465]

ЛЮБАЯ синтаксически ВЕРНАЯ языковая конструкция "гадостью" не является по определению.

Гадостью является язык, позволяющий написать программу, результат исполнения которой зависит от стиля кодинга программиста.


 
Германн ©   (2007-06-12 01:40) [467]


> ferr ©   (12.06.07 01:18) [465]
>
> > Скажите честно - Вы ПОНИМАЕТЕ, о чем идет речь в ЭТОЙ
> ветке?
>
> Мне казалось что да, жаль вот только я не понимаю смысла
> ЭТОЙ ветки.
>
> Пожалуй, я удалюсь из этой ветки, чтобы лишний раз никого
> не нервировать.
>
> Я лишь пытался высказать СВОЮ точку зрения. Она состояла
> в том, что на с++ может программировать лишь "воспитанный"
> человек, который не говорит компилятору всякие "гадости".
>
>

Имхо, эта твоя "точка зрения" совпадает с мнением большинства в этой ветке. Только акценты расставлены не так. Ты налегаешь на "квалификацию программиста", а многие прочие на "строгость языка и его компилятора". Но поскольку, изначально сабж был именно о втором, то и твои посты "несколько, как-то" идут лесом. Увы :)


 
TohaNik ©   (2007-06-12 09:24) [468]


> Vga ©   (11.06.07 12:57) [444]
> Гм. AFAIK, поведение компилятора на выражении, в котором
> одна переменная инкрементируется более одного раза непредсказуем
> и зависит как минимум от компилятора (а С++ не дельфи, где
> компилятор ровно 1), а возможно и от придури одного и того
> же компилятора


Какие то бои без правил…
Да еще необходимость помнить о возможном визите к психиатру:)
Зона риска однако:)


 
Однокамушкин   (2007-06-12 09:42) [469]


> ferr ©   (12.06.07 01:18) [465]
> Я лишь пытался высказать СВОЮ точку зрения. Она состояла
> в том, что на с++ может программировать лишь "воспитанный"
> человек, который не говорит компилятору всякие "гадости".

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

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


 
palva ©   (2007-06-12 10:34) [470]


> Юрий Зотов ©   (12.06.07 01:00) [464]
> Скажите честно - Вы ПОНИМАЕТЕ, о чем идет речь в ЭТОЙ ветке?

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

Язык си был не альтернативой паскалю, а альтернативой ассемблеру. Его конструкции строились так, чтобы было легко написать хороший оптимизатор, чтобы программисты, пишущие на ассемблере компилятор или операционную систему могли большую часть кода написать на си. Даже стандарты языка менялись вместе с эволюцией процессора 8086 - я имею ввиду команды сдвига на величину больше чем 32 бита.

Как показала практика, язык оказался успешным. Программы, управляющие ядерным реактором, действительно пишут на си. Неопределенность никому не помешала.

Да и почему язык должен быть определенным? Если бы авторы си хотели бы сделать как лучше, они могли бы записать в стандарт определенный порядок вычисления параметров. Но они ведь оставили много таких неопределенностей. Здесь предполагается тандем программиста и оптимизатора. Программист знает, что такая неопределенность не скажется на его алгоритме, а оптимизатор может использовать эту неопределенность. Как бы то ни было, я несколько раз лично убеждался, что одна и та же программа написанная на паскале и на си, на си работает немного быстрее. И это естественно, паскаль дальше от железа, чем си, с другой стороны его синтаксис больше приспособлен для восприятия людьми не знающими ничего о командах процессора, а задачу сделать синтаксис удобным для оптимизатора авторы языка ИМХО вообще не ставили.

Разговоры же, что си является языком плохим или ненастоящим (первоапрельским розыгрышем) я нахожу несерьезными. Это подобно тому как православные христиане, уверяют что православие является истинным христианством, а остальное христианство ложное. В то время как православные составляют едва ли десятую часть христианского мира.


 
YurikGL ©   (2007-06-12 11:33) [471]

ИМХО, писать на Си - все равно что ездить с ручной коробкой передач... А паскале - с автоматической.
Кому-то нравится ручная т.к. они могут более оптимально расходовать топливо, более быстро разгоняться... кому-то автоматическая т.к. можно не напрягаться переключая передачи и нельзя случайно воткнуть не ту передачу.


 
Юрий Зотов ©   (2007-06-12 11:36) [472]

> palva ©   (12.06.07 10:34) [470]

1. Статью, конечно же, никто всерьез не принимает.
2. История Си ни для кого не новость.
3. Язык программирования обязан быть определенным.


 
Юрий Зотов ©   (2007-06-12 11:40) [473]

> YurikGL ©   (12.06.07 11:33) [471]


> ИМХО, писать на Си - все равно что ездить с ручной коробкой
> передач... А паскале - с автоматической.


Не совсем так. И там, и там коробка передач ручная. Но схема переключения передач Сишной коробки может вдруг сама по себе взять - и измениться. А у Дельфишной она гарантированно всегда одна и та же.


 
palva ©   (2007-06-12 11:50) [474]

> 1. Статью, конечно же, никто всерьез не принимает.
Ваше
> Скажите честно - Вы ПОНИМАЕТЕ, о чем идет речь в ЭТОЙ ветке?
я понял как призыв вернуться к обсуждению сабжа.

2. История Си ни для кого не новость.
Опять слишком категоричное утверждение. Может быть, для кого-то и новость. Во всяком случае разоблачения сабжа в ветке я еще не видел.

3. Язык программирования обязан быть определенным.
А интересно, делфи этому условию удовлетворяет? Я подозреваю, что там тоже есть правильные синтаксические конструкции, которые не ведут к определенным действиям.


 
etc   (2007-06-12 12:16) [475]

а можно воочию убедиться в [444], т.е. "поведение компилятора на выражении, в котором одна переменная инкрементируется более одного раза непредсказуем"?
действительно интересно ...


 
Юрий Зотов ©   (2007-06-12 12:37) [476]

> palva ©   (12.06.07 11:50) [474]

> А интересно, делфи этому условию удовлетворяет?

IMHO, полностью. Даже знаменитая конструкция
if ... then  if ... then... else ...
тоже совершенно однозначна: else однозначно относится ко второму if. Причем согласно синтаксису самого языка, а не соглашениям, принятым разработчиками компилятора.

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

Пример?


 
Однокамушкин   (2007-06-12 12:38) [477]


> Юрий Зотов ©   (12.06.07 11:40) [473]
> Не совсем так. И там, и там коробка передач ручная. Но схема
> переключения передач Сишной коробки может вдруг сама по
> себе взять - и измениться. А у Дельфишной она гарантированно
> всегда одна и та же.

Имхо не совсем правильная аналогия, я бы сказал по-другому: схема переключения сишной коробки сильно зависит от того, в каких положениях находятся прочие элементы управления, а паскалевская коробка имеет фиксированную схему...

А вообще, как человек, поездивший и с ручной коробкой, и с автоматической, могу сказать, что хороший автомат с овердрайвом и спортивным режимом позволяет делать всё то же, что и механика, но не обязывает водителя вмешиваться во все детали управления... Так что водитель сосредотачивает своё внимание на дороге, а не на том, как правильно передвинуть рычаг, да и сцепление сжечь на автомате практически невозможно, так что автомат рулит однозначно... Недостаток автомата один - он не всегда заставляет человека выбирать оптимальный режим, типа едет машина - ну и ладно... Но если припрёт, то такой режим можно выбрать, а если не припёрло, то, значит, не так уж страшна эта неоптимальность

Ещё раз призываю оставить низкоуровневую оптимизацию компьютеру... не делайте за компьютер его работу, он ответной любезности не проявит и вашу за вас не сделает :))


 
Alx2 ©   (2007-06-12 13:09) [478]

>Юрий Зотов ©   (12.06.07 12:37)

>Пример?


Var
i : Integer;
b : boolean;
v : Variant;
begin
 b := true;
 i := 1;
 v:=true;
 v := i and v and b;
 ShowMessage(v);
end;


Показывает "1" в D6. Но не знаю почему бы не показать "true".


 
Юрий Зотов ©   (2007-06-12 13:54) [479]

> Alx2 ©   (12.06.07 13:09) [478]

Здесь нет никакой неоднозначности - должна показываться именно 1, а не true.

При вычислении выражений со смешанными типами младшие типы приводятся к старшим, а результат получает самый старший тип. В данном случае булевские b и v приводятся к типу i, результат выражения получает тип Integer, а вариант получает тип varInteger - и мы видим единицу. Все строго, все однозначно и все полностью соответствует спецификации.

Изменим код - заставим компилятор приводить Integer к Boolean:

var
 i: Integer;
 b: boolean;
 v: Variant;
begin
 b := true;
 i := 1;
 v:=true;
 v := Boolean(i) and v and b;
 ShowMessage(v);
end;

И мы видим уже не 1, а True. Снова никаких чудес - все три операнда в выражении имеют тип Boolean, этот же тип получает результат, а вариант получает тип varBoolean. Снова все строго, все однозначно и все полностью соответствует спецификации.

То есть, Ваш пример можно считать обратным - он четко подтвердил полную однозначность и полную предсказуемость результата. Все работает именно так, как и должно.


 
sniknik ©   (2007-06-12 13:55) [480]

Alx2 ©   (12.06.07 13:09) [478]
пример неудачный, автоприведение типа в операциях вполне логично, и без двусмысленностей. (если не понимаешь почему и как, но надо определенное делай явное преобразование и все. никаких false вместо true не будет)
тебя кстати почемуто не смутило, что ShowMessage показал строку... сконвертировал из варианта (неважно "1" или "true").


 
Sergey Masloff   (2007-06-12 13:58) [481]

Да можно считать неоднозначностью - побитовый и логический операторы не различаются (ср. в том же це: | и ||, & и &&)


 
Sergey Masloff   (2007-06-12 14:03) [482]

Юрий Зотов ©   (12.06.07 13:54) [479]
Юр, у меня дельфы под рукой нет проверить, но все же мне кажется дело тут не в старшинстве.
Можно заменить boolean на LongBool который равен integer но ничего не поменяется (я предполагаю).
 Тут наверное механизм такой - у логического and оба операнды булевы. Если хотя бы один нет то он смотрит а не побитовый ли это оператор. И сразу видит integer как один из операндов - отлично то что нужно и быстро приводит второй операнд к интежеру.
 Но может я и не прав.


 
Юрий Зотов ©   (2007-06-12 14:04) [483]

> Sergey Masloff   (12.06.07 13:58) [481]

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


 
db2admin ©   (2007-06-12 14:05) [484]

Удалено модератором


 
Alx2 ©   (2007-06-12 14:09) [485]

>Юрий Зотов ©   (12.06.07 13:54)
>sniknik ©   (12.06.07 13:55)

Ребята, я это понимаю. Но подошел к этому вопросу с точки зрения "как понять человеку", которая, кажется, у Юрия в этой ветке верховодит.

>Юрий Зотов ©   (12.06.07 13:54)

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

Заменим integer на longint
а  i := 1;
заменим, например, на i := 1 shl 35;
Результатом будет 8.

То же самое и с типом i : double;
Он приводится к integer. Хотя по-классике уже криво смотрится double в связке с and.

И, судя по трассе отладчика, приводится только к integer.


 
Alx2 ©   (2007-06-12 14:13) [486]

С другой стороны, ведь и с теми "неоднозначностями" на С++ достаточно помнить о спецификации.


 
sniknik ©   (2007-06-12 14:18) [487]

> Заменим integer на longint
заменим все!
Var
 i : Integer;
 b : byte;
 k : word;
 v : Variant;
begin
 b := 1;
 i := 1;
 k := 1;
 v := boolean(k and b and i);
ShowMessage(v);
end;

и получим правильный результат (вернее то чего хотелось).
тип boolean это же тоже фактически число...

"ты думаешь ты тут воздухом дышишь?" @Морфиус

> То же самое и с типом i : double;
??? да ну? а ты туда точно с плавающей запятой значение задал? или такое какое позволило оптимизатору привести к целому?


 
Alx2 ©   (2007-06-12 14:22) [488]

>sniknik ©   (12.06.07 14:18)

>??? да ну? а ты туда точно с плавающей запятой значение задал? или такое
>какое позволило оптимизатору привести к целому?


var
 d: double;
 b: boolean;
 v: Variant;
begin
 b := true;
 d := 1.55;
 v := true;
 v := b and v and d;
 ShowMessage(v);
end;


Ответ round(d).
В данном случае 2.

PS
Мне кажется, не понимаете о чем я писал.
Давайте договоримся о том, что все мы знаем этот аспект Delphi.


 
Anatoly Podgoretsky ©   (2007-06-12 15:49) [489]

Это не аспект Дельфи, эти типы из АПИ - варианты
А с волками жить, по волчьи выть.


 
palva ©   (2007-06-12 17:37) [490]


Юрий Зотов ©   (12.06.07 12:37) [476]
Пример?

Берем Pointer присваиваиваем ему какое-нибудь целое число, а потом читаем байт по этому указателю. Синтаксически верная программа при разных запусках на разных машинах будет давать разные результаты. А если число подберем удачно, то и исключение получится.


 
Однокамушкин   (2007-06-12 17:44) [491]


> palva ©   (12.06.07 17:37) [490]

Ну так это ведь не потому, что клмпилятор генерирует разный код, а потому, что окружение меняется... а то так можно договориться до того, что программа, скаладывающая два введённых пользователем числа, тоже работает по-разному на разных компьютерах - пользователи ведь разные значения вводят... А Юрий говорил о совсем другом случае - когда компилятор одну и ту же строчку может по-разному откомпиляировать в зависимости от фазы луны и расположения звёзд...


 
palva ©   (2007-06-12 17:49) [492]

Однокамушкин   (12.06.07 17:44) [491]
Мы явно не понимаем друг друга. Компиляция строчки f(a++,b++) не зависит от фазы луны и расположения звезд. Она зависит от компилятора, ключей компиляции и окружающего кода. Точно то же самое можно сказать про паскалевские компиляторы.
Давайте пусть Юрий уточнит, какой пример он хочет.


 
palva ©   (2007-06-12 17:52) [493]

Кстати я как раз и привел пример того, что просил Юрий. Я же написал

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

Юрий в ответ на это попросил пример.


 
Однокамушкин   (2007-06-12 18:27) [494]


> palva ©   (12.06.07 17:49) [492]
> Однокамушкин   (12.06.07 17:44) [491]
> Мы явно не понимаем друг друга. Компиляция строчки f(a++,
> b++) не зависит от фазы луны и расположения звезд. Она зависит
> от компилятора, ключей компиляции и окружающего кода. Точно
> то же самое можно сказать про паскалевские компиляторы.

Абсолютно не понимаем... в одном случае от компилятора зависит получающийся код, в другом код одинаковый, но из-за разных входных данных выполняется по-разному - вы не находите, что ситуации не совсем эквивалентны?

Я могу привести пример, который просил Юрий... вот он:

var
 X, A, B: Integer; // глобальные переменные

function GetFive: Integer;
begin
 Result := 5;
 X := 10;
end;

begin
 X := 5;
 A := X + GetFive;
 X := 5;
 B := GetFive + X;
 WriteLn(A);
 WriteLn(B);
end.


Какие значения получат переменные A и B? 10 или 15? Стандарт языка Паскаль не определяет, в каком порядке вычисляются аргументы бинарных опреаций, компилятор имеет право выбирать этот порядок сам... во всех известных мне версиях Delphi компилятор в обоих случаях сначала вычислит GetFive, изменяя таким образом X, а потом к результату добавится значение X, т.е. и A, и B будут равны 15... но другой компилятор может решить по-другому, и тогда одна или обе переменные получат значение 10... вот о каких примерах говорил Юрий, а ему в ответ какие-то невнятные примеры с вариантами и указателями - всё запутано, но либо детерминировано, либо зависит от внешних условий...

Delphi такой пример, конечно, не украшает, но ведь, с другой стороны, Delphi - далкео не самый продвинутый в смысле выверенности конструкций язык, самый продвинутый на сегодня, это, видимо, Оберон... а Delphi всё же ближе к Оберону, чем С++ :))


 
Zeqfreed ©   (2007-06-12 18:46) [495]

> Однокамушкин   (12.06.07 18:27) [494]

Отличный пример. FPC выдает 10 15, в режиме совместимости с Delphi — 15 15. Только боюсь, что сейчас начнется, что это совсем разные языки и прочее.


 
palva ©   (2007-06-12 19:19) [496]

> Абсолютно не понимаем... в одном случае от компилятора зависит получающийся код, в другом код одинаковый, но из-за разных входных данных выполняется по-разному - вы не находите, что ситуации не совсем эквивалентны?

Нахожу, что не совсем эквивалентны.

> вот о каких примерах говорил Юрий, а ему в ответ какие-то невнятные примеры
Ну что тут сказать... На внятные вопросы будут внятные ответы. Это вам удалось его понять и интерпретировать. А я, например, не понимаю почему
> 3. Язык программирования обязан быть определенным.
да еще с точки зрения синтаксиса. Я не понимаю, где в f(a++,a++) неопределенность в синтаксисе. Это вполне определенное задание компилятору скомпилировать код, причем программисту неважно, в каком порядке выполняются параметры, раз он такое пишет. В конце-концов, возможно, что функция f симметрическая. С другой стороны непонятно почему язык, который должен быть "определенным", но таковым не является, используется гораздо шире чем "определенные" языки.


 
Однокамушкин   (2007-06-12 20:18) [497]


> palva ©   (12.06.07 19:19) [496]


> Я не понимаю, где в f(a++,a++) неопределенность в синтаксисе.
> Это вполне определенное задание компилятору скомпилировать
> код, причем программисту неважно, в каком порядке выполняются
> параметры, раз он такое пишет.

Неважно или нет, это вопрос... для кого-то неважно, а кто-то просто сделал неверное предположение...

> С другой стороны непонятно почему язык, который должен быть
> "определенным", но таковым не является, используется гораздо
> шире чем "определенные" языки.

Ну, если считать широту использования главным критерием, то и опреационных систем лучше Windows нет...

А почему многие любят С и С++, это понятно... для многих главным достоинством любого ЯВУ кажется возможность писать конструкции типа while (*d++=*s++); примитивные рассуждения из серии "на С я могу записать одной строчкой то, для чего в Delphi понадобится десять строк, значит, С++ круче"... а понимание того, что за эту крутость приходится расплачиваться неуправляемостью большого проекта, приходит не ко всем... Или, точнее, приходит в итоге ко всем, но к некоторым - только после собственного горького опыта, когда проект уже с нуля не перепишешь... Вот и возникают всякие корпоративные стандарты кодирования, которые прямо запрещают использования некоторых конструкций языка или комбинаций этих конструкций по причине того, что разгребать такой код, если что, будет очень трудно... А теперь вопрос на засыпку: зачем в языке нужны конструкции, которые потом запрещаются правилами написания ясного кода? Не лучше ли будет, если язык не будет вообще содержать таких конструкций?


 
Zeqfreed ©   (2007-06-12 20:48) [498]

> Однокамушкин   (12.06.07 20:18) [497]


> while (*d++=*s++);

Вместо этого уже давно есть strcpy. А если бы не было, то ее бы сделали и, вполне возможно, что тем же злосчастным циклом. Наглядность не портится. Лаконичность остается. Все просто, очевидно и понятно. Не нужно искать проблемы там, где их нет :)


 
Однокамушкин   (2007-06-12 20:55) [499]


> Zeqfreed ©   (12.06.07 20:48) [498]
> Вместо этого уже давно есть strcpy.

Вместо этого есть, а вместо чего-нибудь ещё подобного нет, на все такие извращения стандартных функций не напасёшься...


 
Zeqfreed ©   (2007-06-12 20:56) [500]

> Однокамушкин   (12.06.07 20:55) [499]

Зато можно единожды написать ее для всего проекта, оттестировать и продолжить жить напеваючи.


 
Однокамушкин   (2007-06-12 21:01) [501]


> Zeqfreed ©   (12.06.07 20:56) [500]

Можно написать... а можно - не написать... в этом-то и заключается главная проблема С++, что можно писать простой и понятный код, а можно - запутанный и небезопасный, и конструкции языка не побуждают программиста к первому варианту...


 
Zeqfreed ©   (2007-06-12 21:10) [502]

Начинается :) Ладно, философствуйте далее. Я наблюдаю :)


 
palva ©   (2007-06-12 21:59) [503]

> А почему многие любят С и С++, это понятно...
Любят? Если это про меня, то это не то слово. Хорошо знают. Если говорить о любви, то мне больше нравится паскаль. Но в тех конторах, где я работал раньше мне либо было предписано писать на си, либо, в случае, когда я сам мог выбирать средство разработки, я выбирал си. И не потому что он круче, а потому что я его лучше знал, а мой проект могли сопровождать другие. Один раз я выбрал паскаль. Еще под DOS. Писал на Turbo Vision. Но следующий проект на Turbo Vision писал уже на си.

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

А то ведь таким образом много рацпредложений можно предложить. Например, зачем в корпоративных стандартах требуют тело цикла выделять отступом? Зачем требуют соблюдать правила при наименовании переменных? Не лучше ли будет, если отступы будут носить семантический смысл, а сам компилятор по первым буквам имени переменной будет понимать, какой ее тип? Может быть и лучше. Только это будет уже не си, а питон или бейсик. В некоторых организациях и выбирают, кстати, бейсик.


 
palva ©   (2007-06-12 22:15) [504]

> в этом-то и заключается главная проблема С++, что можно писать простой и понятный код, а можно - запутанный и небезопасный, и конструкции языка не побуждают программиста к первому варианту...

Что-то я не наблюдаю среди делфи программистов склонности к ясному и безопасному коду. Почитайте вопросы в начинающих - раз в неделю спрашивают, как работать со строкой или с динамическим массивом функцией Move. Или еще какие-нибудь подобные сомнительные фокусы. Если пишущий на языке ощущает его ограничения, то он стремится из них вырваться. Это психология человека. А сишники гораздо больше ценят ясность и безопасность когда. Они просто лучше понимают что это такое. Ощутив свободу и поэкспериментировав с ней они сразу же устанавливают самоограничения без всяких корпоративных стандартов. Иначе через месяц не разберешься со своим собственным кодом.

Здесь наверно есть какая-то аналогия со спорами демократов и коммунистов. Что лучше безудержная свобода или скромненький лагерь.


 
ProgRAMmer Dimonych ©   (2007-06-12 22:29) [505]

> Не лучше ли будет, если отступы будут носить семантический
> смысл, а сам компилятор по первым буквам имени переменной
> будет понимать, какой ее тип? Может быть и лучше. Только
> это будет уже не си, а питон или бейсик. В некоторых организациях
> и выбирают, кстати, бейсик.

Насколько я знаю классический Basic (времён MS-DOS), там никогда не было ничего из вышеперечисленного...


 
Sergey Masloff   (2007-06-12 22:35) [506]

Так, долго маскировавшийся под добросовестного дельфина palva(c) оказался засланцем и адептом це. Куда катится мир ;-)
 На самом деле нужно не париться а есть возможность изучать что попало потому что на самом деле интересно. Правда бывает сначала трудно научиться писать на це как на це а не как на дельфе (на ьбейсике как на бейсике а не как на це, и так далее). А так нормально. И позволяет адекватные инструменты выбирать.
 Замерюсь тут как я троих сишников в джавистов переделал. Был проджект который писали и развивали три человека. Но трудно было так как платформ много и приходилось подстраиваться - то там то сям что вылезет. Хотя ребята серьезные я с большим удовольствием код их читал потом и многому научвился.
 Но когда я посмотрел на задачу я (некрасиво хвалиться, на самом деле это могли сделать многие) написал библиотеку на PL/SQL. Которая ясно дело кросплатформенная, а объем клиента после этого уменьшился в 10 раз (кроме шуток, 10% от исходного) и настолько простой как бубен что я его сам написал. И сейчас его поддерживает один человек который вообще не программист а по совместительству.
 А сишников отправили на курсы яву учить потому что ребята правда квалифицированные а проектов новых сишных не осталось.


 
palva ©   (2007-06-12 23:04) [507]

> Насколько я знаю классический Basic (времён MS-DOS), там никогда не было ничего из вышеперечисленного...

Ну это я не стал объяснять. В сишных корпоративных стандартах определяют тип по первым символам, а в бейсике - по последним.
И в Turbo Basic и в Quick Basic было правило определения типа переменной по последнему символу: a$ - это строка, X& - Long, W% - Integer и т. д. Это правило работало вплоть до VB6. Даже тип возвращаемого значения у функции можно было не писать явно а шифровать в имени функции.

Так что формально вы правы. Но там было нечто похожее.
Похожая штука есть в Perl там применяются символы $ @ %. За последний символ не ручаюсь, давно не писал на Perl, совсем его забыл.


 
Юрий Зотов ©   (2007-06-12 23:43) [508]

> palva ©   (12.06.07 17:37) [490]
> на разных машинах
Саш, ну самому-то не смешно?

> Однокамушкин   (12.06.07 18:27) [494]
+1


 
Zeqfreed ©   (2007-06-12 23:58) [509]

Слишком лаконично. Общественность ждала публичного раскаянья :)


 
Плохиш ©   (2007-06-13 00:05) [510]


> palva ©   (12.06.07 22:15) [504]


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

Умора :-)) где ты видел в "Начинающим" делфи-программистов? Там 80% крютых перцев даже справку читать считающих ниже своего достоинства...

> Если пишущий на языке ощущает его ограничения, то он стремится
> из них вырваться.

Речь идёт о тех же, что и в предыдущих предложениях? Тогда это не ограничения языка, а ошибки в днк этого так называемого "пишущего"...


 
sniknik ©   (2007-06-13 00:10) [511]

> Общественность ждала публичного раскаянья :)
от вас, вообщето... хотя бы за то, что свое мнение пытаетесь за общественное выдать.


 
Zeqfreed ©   (2007-06-13 00:22) [512]

> sniknik ©   (13.06.07 00:10) [511]

Не стоит воспринимать так серьезно. Ничего я никуда не пытаюсь.


 
Юрий Зотов ©   (2007-06-13 01:32) [513]

> palva ©   (12.06.07 22:15) [504]
> Почитайте вопросы в начинающих

Э-э-э... а более серьезных аргументов нет, случаем?


 
Германн ©   (2007-06-13 02:48) [514]


> palva ©   (12.06.07 22:15) [504]
>
> > в этом-то и заключается главная проблема С++, что можно
> писать простой и понятный код, а можно - запутанный и небезопасный,
>  и конструкции языка не побуждают программиста к первому
> варианту...
>
> Что-то я не наблюдаю среди делфи программистов склонности
> к ясному и безопасному коду. Почитайте вопросы в начинающих
> - раз в неделю спрашивают, как работать со строкой или с
> динамическим массивом функцией Move. Или еще какие-нибудь
> подобные сомнительные фокусы.

Ты бы ещё упомянул спам в конференциях сего форума!
Саш, ну ты же уже не "дитё неразумное"! Причём тут "язык программирования"? В "начинающие" "сваливают" всё, что не является явным спамом, оффтопиком, etc.
Но может ты знаешь форум по С, где есть конференция "начинающие"?


 
Однокамушкин   (2007-06-13 09:36) [515]


> palva ©   (12.06.07 21:59) [503]
> Но программисту широкие  возможности не мешают. Он просто
> не использует то, что не нужно. Возможно даже не имеет об
> этих возможностях понятия - пишет на сабсете языка.

Неправда, иногда мешают, он может неосознанно применить их... например, программист, не знающий, что С++ умеет неявно превращать вещественные числа в целые, может случайно подставить вещественное значение там, где требуется целое, потерять и-за этого часть данных и долго мучаться, пытаясь найти ошибку, потому что ему просто не придёт в голову искать её именно в этом месте - он же не знает, что такое в принципе возможно...


 
Игорь Шевченко ©   (2007-06-13 09:53) [516]

Однокамушкин   (12.06.07 20:18) [497]


> А почему многие любят С и С++, это понятно... для многих
> главным достоинством любого ЯВУ кажется возможность писать
> конструкции типа while (*d++=*s++); примитивные рассуждения
> из серии "на С я могу записать одной строчкой то, для чего
> в Delphi понадобится десять строк, значит, С++ круче"...
>  а понимание того, что за эту крутость приходится расплачиваться
> неуправляемостью большого проекта, приходит не ко всем..
> .


Дорогой друг, объясни мне, бестолковому, почему на грязном неуправляемом С написано так много больших проектов, начиная от Unix, Windows, Oracle и Firebird, заканчивая кучей бизнес-приложений.

В то же время обилия подобных же проектов на Паскале, Обероне или Delphi не наблюдается :)

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


 
Юрий Зотов ©   (2007-06-13 09:58) [517]

> Ощутив свободу и поэкспериментировав с ней они сразу же
> устанавливают самоограничения без всяких корпоративных стандартов.
> Иначе через месяц не разберешься со своим собственным кодом.

Что, собственно, и требовалось доказать. Комментарии уже излишни. Разве что один: разве можно назвать хорошим и безопасным язык, программируя на котором приходится вводить самоограничения? Разве не лучше было бы ввести ровно те же ограничения в сам язык?


 
Alkid ©   (2007-06-13 10:00) [518]

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


 
clickmaker ©   (2007-06-13 10:06) [519]


> какие цели преследуют люди, старающиеся убедить остальных
> в том, что С/С++ это такие монструозные языки, что на них
> ничего сложнее "Hello ,World" не напишешь (проект потеряет
> управляемость) или что Дельфи - это такой "игрушечный" язык,
> на котором опять же ничего сложнее "Hello, World" не напишешь?

никаких. У них просто нет целей


 
Игорь Шевченко ©   (2007-06-13 10:07) [520]


> разве можно назвать хорошим и безопасным язык, программируя
> на котором приходится вводить самоограничения?


Конечно можно.


> Разве не лучше было бы ввести ровно те же ограничения в
> сам язык?


Юра, а скажи мне, опять же, бестолковому, нафига в Паскале оператор GOTO оставили, который considered harmful много-много раз ?
Разве не лучше внести ограничения в сам язык и убрать оттуда этот оператор ?


 
palva ©   (2007-06-13 10:09) [521]

Однокамушкин   (13.06.07 09:36) [515]
Пожалуй вы правы. У меня был такой случай: после программирования на си я попробовал писать на делфи. Пишу:

var
 i, j: Integer;
 d: Double;
begin
 { TODO -oUser -cConsole Main : Insert code here }
 i := 15;
 j := 8;
 d := i / j;
 WriteLn(d);
end.

Господи, почему же дробное число печатает? Почему операция над целыми числами дает дробный результат? Потом понял, что в Делфи есть возможность делить целые при помощи операции div. Что за проклятый язык? Зачем туда напихали всяких конструкций, которые никомуникогданинахреннивкраснуюармию не нужны.

Ну конечно, я бы так сказал, если бы воспитывался как программист на языке Basic, ну а поскольку я все таки начинал с восмиричного кода машины M-20, то я подумал: "Молодец этот Вирт. Интересная фича" Правда слова фича тогда не было.


 
boriskb ©   (2007-06-13 10:09) [522]

Юрий Зотов ©   (13.06.07 9:58) [517]
разве можно назвать хорошим и безопасным язык, программируя на котором приходится вводить самоограничения?


Хорошим можно.
Безопасным для большинства нельзя


 
Alkid ©   (2007-06-13 10:18) [523]


> никаких. У них просто нет целей

Видимо да.
Однако народ всё равно каждый раз радостно бросается толочь воду в ступе...


 
Юрий Зотов ©   (2007-06-13 10:35) [524]

> Alkid

Два человека обсуждают фильм. Книгу. Спектакль. Соседскую красотку. Качество вареников в столовой на ул. M в гор. N. Еще что-угодно.

Вам приходилось участвовать в таких разговорах?

Ну и какие цели Вы при этом преследовали?


 
Alkid ©   (2007-06-13 10:46) [525]


> Два человека обсуждают фильм. Книгу. Спектакль. Соседскую
> красотку. Качество вареников в столовой на ул. M в гор.
> N. Еще что-угодно.

Понимаете, я никогда не  обсуждал по 25 раз одну и ту же книгу, соседку или спекаткль :) А тема про убожество(крутизну) [синтаксиса] С++ (Дельфи, Паскаля, вписать нужное) поднималась и обсасывалась тут уже неоднократно с одинкаовыми аргументами и одинаково нулевым резульатом. :) В связи с этим выражаю некоторое удивление, что эта тема опять, подобно фениксу, восстала из пепла :)


 
clickmaker ©   (2007-06-13 10:47) [526]


> Соседскую красотку. Качество вареников в столовой на ул.
> M в гор. N

да-да, давайте лучше это пообсуждаем


 
Думкин ©   (2007-06-13 10:50) [527]

> Игорь Шевченко ©   (13.06.07 10:07) [520]
> Юра, а скажи мне, опять же, бестолковому, нафига в Паскале
> оператор GOTO оставили, который considered harmful много-
> много раз ?
> Разве не лучше внести ограничения в сам язык и убрать оттуда
> этот оператор ?

По бестолковости и оставили. По серьезному - нет ему там места. И все.


 
Однокамушкин   (2007-06-13 10:54) [528]


> Игорь Шевченко ©   (13.06.07 09:53) [516]
> Дорогой друг, объясни мне, бестолковому, почему на грязном
> неуправляемом С написано так много больших проектов, начиная
> от Unix, Windows, Oracle и Firebird, заканчивая кучей бизнес-
> приложений.

Я уже писал здесь, что если судить по массовости использования, то лучшая операционная систама - это Windows...

И почему С так любят, я тоже уже писал: когда человек только начинает осваивать программирование, возможность написать что-то в одну строчку вместо десяти кажется главным достоинством языка, а тут С практически вне конкуренции, вот и остаётся первое впечатление, что С и С++ - лучшие языки... получается что-то вроде импринтинга, который, как учат психологи, сложно преодолеть... А то, что человек способен написать работающий большой проект даже на таком языке, как С, говорит хорошо не столько о языке, сколько о человеке :)))


 
Однокамушкин   (2007-06-13 10:56) [529]


> Игорь Шевченко ©   (13.06.07 10:07) [520]
> Юра, а скажи мне, опять же, бестолковому, нафига в Паскале
> оператор GOTO оставили, который considered harmful много-
> много раз ?
> Разве не лучше внести ограничения в сам язык и убрать оттуда
> этот оператор ?

В Обероне Вирт так и сделал - выкинул goto, и, имхо, он абсолютно прав... А Паскаль создавался тогда, когда этот шаг казался слишком смелым и Вирту, и, навероное, даже Дейкстре...


 
Думкин ©   (2007-06-13 10:56) [530]


> А то, что человек способен написать работающий большой проект
> даже на таком языке, как С, говорит хорошо не столько о
> языке, сколько о человеке

если плюсы, то мои 200 тут, ен меньше. :о)


 
reonid ©   (2007-06-13 11:00) [531]

>Игорь Шевченко ©   (13.06.07 09:53) [516]

>Дорогой друг, объясни мне, бестолковому, почему на грязном >неуправляемом С написано так много больших проектов, начиная от Unix, >Windows, Oracle и Firebird, заканчивая кучей бизнес-приложений.

Почему так много людей в этом мире говорит на
таком сложном в написании и произношении китайском ?...
:-)


 
Думкин ©   (2007-06-13 11:03) [532]


> reonid ©   (13.06.07 11:00) [531]

Достойному вопросу достойный ответ. :о)


 
Alkid ©   (2007-06-13 11:04) [533]


> Почему так много людей в этом мире говорит на
> таком сложном в написании и произношении китайском ?...
> :-)

Я бы пошёл ещё дальше - почему на свете жалких слабых людишек так много, а красивых сильных и гордых тигров так мало?


 
Игорь Шевченко ©   (2007-06-13 11:11) [534]

reonid ©   (13.06.07 11:00) [531]

Я еще не видел нацию, с рождения говорящую и пишущую на С или на Паскале. Теплое с мягким не надо путать.

Однокамушкин   (13.06.07 10:54) [528]


> Я уже писал здесь, что если судить по массовости использования,
>  то лучшая операционная систама - это Windows...


Видишь ли, миллионы мух не могут ошибаться...И если Windows используют, значит он является лучшим за ту цену и для тех задач.


> И почему С так любят, я тоже уже писал: когда человек только
> начинает осваивать программирование, возможность написать
> что-то в одну строчку вместо десяти кажется главным достоинством
> языка, а тут С практически вне конкуренции


Ерунда полная. По части написать в одну строчку у APL до сих пор нет ни одного конкурента. Ты много видел программирующих на APL в трезвом уме и твердой памяти ?

Кроме того, вопрос был несколько не о том - почему народ пишет большие проекты на С ?
Может, не так все плохо, как здесь малюют ?


 
Игорь Шевченко ©   (2007-06-13 11:13) [535]

Однокамушкин   (13.06.07 10:56) [529]


> В Обероне Вирт так и сделал - выкинул goto, и, имхо, он
> абсолютно прав...


а где сайт "Мастера Оберона" ? :)


 
Думкин ©   (2007-06-13 11:16) [536]

> Игорь Шевченко ©   (13.06.07 11:13) [535]

Так и сайта "отличиникки Матеь ее матики" нет, а вот дай списать- только отбиваться успевай. Я еще не видл сайта уровня выше кванта, а вот от специалистов для построения ВД первого и второго рода отбоя нет.


 
euru ©   (2007-06-13 11:22) [537]


> Юрий Зотов ©   (13.06.07 09:58) [517]
> разве можно назвать хорошим и безопасным язык, программируя
> на котором приходится вводить самоограничения? Разве не
> лучше было бы ввести ровно те же ограничения в сам язык?

Не понимаю, почему виноватым во всех бедах должен считаться язык, а не тот, кто им пользуется?

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


 
Игорь Шевченко ©   (2007-06-13 11:22) [538]

Думкин ©   (13.06.07 11:16) [536]

Дима, при всей моей эрудированности, я честно не слышал о распространении Оберона. Может, не тем ухом слушаю ? :)
А сферических коней в вакууме достаточно...


 
Игорь Шевченко ©   (2007-06-13 11:24) [539]

"Полезно взглянуть на два языка программирования - PL/1 и C. Язык PL/1 был
разработан корпорацией IBM в 60-ые годы, так как поддерживать одновременно FORTRAN и COBOL и слушать при этом ворчание ученых о том, что Algol лучше, чем FORTRAN и COBOL, вместе взятые, было невыносимо. Поэтому был создан комитет для создания нового языка, удовлетворяющего запросам всех программистов: PL/1.
Этот язык обладал некоторыми чертами языка FORTRAN, некоторыми особенностями языка COBOL и некоторыми свойствами языка Algol. Проект потерпел неудачу, потому что ему недоставало единой концепции. Проект представлял собой лишь набор свойств, конфликтующих друг с другом, к тому же язык PL/1 был слишком громоздким и неуклюжим, чтобы программы на нем можно было эффективно компилировать.
Теперь взглянем на язык С. Он был спроектирован всего одним человеком
(Деннисом Ритчи) для единственной цели (системного программирования). Успех его был колоссален, и это не в последнюю очередь объяснялось тем, что Ритчи знал, чего хотел и чего не хотел. В результате спустя десятилетия после своего появления этот язык все еще широко распространен. Наличе четкого представления о своих целях является решающим."

(с) Эндрю Таненбаум


 
Думкин ©   (2007-06-13 11:26) [540]

> Игорь Шевченко ©   (13.06.07 11:22) [538]

Что есть распространенность?

Игорь, ты при всей своей эрудированности не сможешь и два слова выдавить из себя по поводу теоремы Геделя, кроме азбуки. И что? А уж про Пеано и далее...
А про Оберон с Виртом тут сцылка была, и насколько понял - весьма впечатляющая. Никто при этом Си и иже в грязь не давит, но то что это путь в никуда - довольно очевидно.


 
Игорь Шевченко ©   (2007-06-13 11:31) [541]


> Игорь, ты при всей своей эрудированности не сможешь и два
> слова выдавить из себя по поводу теоремы Геделя


Даже одного не смогу.


> А про Оберон с Виртом тут сцылка была, и насколько понял
> - весьма впечатляющая


Дима, а что толку во впечатляющих ссылках, сам посуди ? Вот если бы прилавки книжных магазинов были уставлены книжками "Оберон для чайников" или "Как научиться пргораммировать на Обероне за 21 день", тогда бы я сказал, что да, язык пользуется любовью и уважением в массах.


 
Думкин ©   (2007-06-13 11:32) [542]

> Игорь Шевченко ©   (13.06.07 11:31) [541]

Могу вернуть только твое.
Весь экранный телеприлавок завален поделками уровня Дом-2 и иже.
Извини что ниже пояса.


 
Думкин ©   (2007-06-13 11:38) [543]

> Игорь Шевченко ©   (13.06.07 11:31) [541]

Нельзя поощрять невежество. Это и твой кстати тезис. Си тут не при чем, но он при чем когда пишутся книги про него от того же Фленова. Си позволяет плодородится невеждам. Это чернозем для них.
Хотя спорное конечно в реалии утверждение. Согласен.


 
boriskb ©   (2007-06-13 11:43) [544]

Все  зависит  от  каждого  индивидуума  в отдельности.
Например, вон тот блондинчик в третьем ряду. Положим, он играет
хорошо...
    Блондин в третьем ряду зарделся.
    -- А вон тот брюнет, допустим,  хуже.  Все  повернулись  и
осмотрели также брюнета.
    -- Что же мы видим, товарищи? Мы видим, что блондин играет
хорошо,  а  брюнет  играет  плохо.  И никакие лекции не изменят
этого соотношения сил, если каждый индивидуум в отдельности  не
будет постоянно тренироваться в шашк... то есть я хотел сказать
- в  шахматах...

(с)


 
Игорь Шевченко ©   (2007-06-13 11:44) [545]

Думкин ©   (13.06.07 11:38) [543]

Нельзя поощрять. С этим никто не спорит. Фленов и иже с ними пишут книги про то, что пользуется той самой популярностью, так как на популярном легче денег поиметь, компрене ву ?
То есть, на факт популярности Фленов не влияет, он и брат его во Христе Архангельский - это уже следствие того, что нечто пользуется успехом.
Но я, опять же, о другом - на любом языке можно одинаково легко писать как грамотные и понятные программы так и абсолютно запутанные и несопровождаемые. И искать соринки на предмет того, что дескать указатели и ++ неудобны - занятие, скажем так, бесперспективное.
И неумное.


 
db2admin ©   (2007-06-13 11:47) [546]

500 постов ни плохо, а до 1000 сможете?

Игорь Шевченко ©   (13.06.07 11:31) [541]
описание языка оберона 10 страниц по заявлению Вирта, просто Вирт не умеет продовать/рекламировать/втюхивать продукт

Думкин ©   (13.06.07 11:38) [543]
а если Невежда начинает писать на языке А1, постоянно что то изучает, что то пишет, он остается невеждой навсегда?
а как в род доме определить кто невежда?


 
db2admin ©   (2007-06-13 11:49) [547]

Игорь Шевченко ©   (13.06.07 11:44) [545]
я еще не видел нормальных вменяемых списков книг для начинающих...
Так что Фленовы, Фигурновы(*был такой деятель*), Архнагельские будут только плодиться


 
Думкин ©   (2007-06-13 11:50) [548]

> Игорь Шевченко ©   (13.06.07 11:44) [545]

С этим я и не спорил. Донос или гимн пингвинов можно написать и на Дао и на чукотском.
Но пример я привел про организауцию условия. Это на уровне языка. Я сейчас переключаюсь между написанием по языкам - и спотыкаюсь, на Сишных диалектах и на уровне далее компилятора - меня это нервирует. Чесслово.
Если я спотыкаюсь далее компилятора я злюсь. Паскаль мне такое удовольствие доставляет мало. При этом я знаю, что и ногти надо постригать и голову мыть...но неплохо когда это автоматом идет.


 
Игорь Шевченко ©   (2007-06-13 11:50) [549]

db2admin ©   (13.06.07 11:47) [546]

У меня к вам просьба - прежде чем вступать в дискуссию, выучите орфографический словарь русского языка.


 
Думкин ©   (2007-06-13 11:51) [550]

> db2admin ©   (13.06.07 11:47) [546]

я вас не понял.


 
Игорь Шевченко ©   (2007-06-13 11:53) [551]

Думкин ©   (13.06.07 11:50) [548]


> Я сейчас переключаюсь между написанием по языкам - и спотыкаюсь,
>  на Сишных диалектах и на уровне далее компилятора - меня
> это нервирует. Чесслово.


Могу посочувствовать :) Я, когда перекючаюсь между C# и Delphi тоже не сразу нужный контекст загружаю. Но поверь, гораздо труднее было переключаться с ассемблера ЕС ЭВМ на PL/1 той же ЕС ЭВМ :)


 
Думкин ©   (2007-06-13 11:57) [552]

> Игорь Шевченко ©   (13.06.07 11:53) [551]

Спасибо. %)

Но очень все-таки приятно, когда ты предупрежден на уровне компилятора.
У Паскаля такая возможность есть. И это плюс. Хоть и один.


 
pasha_golub ©   (2007-06-13 18:01) [553]

Ребяты... Сволочи... Вы сожрали мой моск. Я всю ветку с первого поста прочитал. Шоб Вам на ABAP"e программировать, теоритики, растудытьвашу кобылу сферическую! :)


 
euru ©   (2007-06-13 18:18) [554]


> pasha_golub ©   (13.06.07 18:01) [553]
> Шоб Вам на ABAP"e программировать...
АВАР, кстати, не самых плохой язык программирования. Особенно если нужно с СУБД работать, то с учётом критериев Юрия Зотова понадёжнее Дельфи будет.


 
Anatoly Podgoretsky ©   (2007-06-13 19:39) [555]

> Игорь Шевченко  (13.06.2007 10:07:40)  [520]

> Юра, а скажи мне, опять же, бестолковому, нафига в Паскале оператор GOTO оставили

Так и было, не хотел Вирт этого, но не смог выдержать борьбы с апологетами и сказал нате вам GOTO, подавитесь, но проклянут меня и вас будущие поколения.


 
Anatoly Podgoretsky ©   (2007-06-13 19:42) [556]

> Alkid  (13.06.2007 10:18:43)  [523]

> Однако народ всё равно каждый раз радостно бросается толочь воду в ступе...

Ты что никогда не развлекаешься?


 
Anatoly Podgoretsky ©   (2007-06-13 19:43) [557]

> Alkid  (13.06.2007 10:46:45)  [525]

> я никогда не  обсуждал по 25 раз одну и ту же соседку

А другим нравится


 
Anatoly Podgoretsky ©   (2007-06-13 19:47) [558]

> Игорь Шевченко  (13.06.2007 11:11:54)  [534]

> Кроме того, вопрос был несколько не о том - почему народ пишет большие проекты на С ?

Этому есть обоснование в исторической ретроспективе. А с учетом напора Микрософта тем более понятно.

Побеждает не всегда самый сильный.


 
Anatoly Podgoretsky ©   (2007-06-13 19:51) [559]

> Игорь Шевченко  (13.06.2007 11:22:58)  [538]

Если бы не сговор Микрософта с Борландом в старые, старые времена, то неизвестно что сейчас бы было. В итоге Микрософт не трогает Паскаль, а Борланд прекратил разработки Бейсика, а его Турбо Бейсик в свое время был на голову выше, также как и Паскаль от Микрософта.
Но в то время они не подходили для системного программирования, сильно уступали тому же Си


 
Anatoly Podgoretsky ©   (2007-06-13 19:53) [560]

> Игорь Шевченко  (13.06.2007 11:44:05)  [545]

Все равно все останутся при своих


 
Anatoly Podgoretsky ©   (2007-06-13 19:56) [561]

> pasha_golub  (13.06.2007 18:01:13)  [553]

> Я всю ветку с первого поста прочитал.

Ты что мазохист?


 
Германн ©   (2007-06-14 00:54) [562]


> pasha_golub ©   (13.06.07 18:01) [553]
>
> Ребяты... Сволочи... Вы сожрали мой моск. Я всю ветку с
> первого поста прочитал.

Действительно мазохист.
Чтобы быть в курсе событий достаточно читать "Регулярный Вечерний Дайджест от АП" (С комментариями составителя.)
:)


 
Defunct ©   (2007-06-14 03:27) [563]

> Кто что думает?

Уже подумываю, что вся эта ветка - это ГОНИВО


 
Игорь Шевченко ©   (2007-06-14 09:44) [564]

Anatoly Podgoretsky ©   (13.06.07 19:39) [555]


> сказал нате вам GOTO, подавитесь, но проклянут меня и вас
> будущие поколения


И прокляли Вирта будущие поколения... :)


> Этому есть обоснование в исторической ретроспективе. А с
> учетом напора Микрософта тем более понятно.


Дык эта...обоснование ж не с потолка взялось...


 
имя   (2007-06-18 00:01) [565]

Удалено модератором


 
Однокамушкин   (2007-06-25 09:29) [566]

Только что на башорге:

serg> Читаю код доставшийся от коллеги
serg> ...
if ($flag == false) {
# на вский случай
if (false == true)
exit;
include "execute.php";
}
serg> чувак убил мой моск...
serg> какой <вырезано цензурой> ВСЯКИЙ СЛУЧАЙ???


Видимо, коллега когда-то нарвался на чём-то типа #define FALSE TRUE... :)))))))


 
db2admin ©   (2007-06-25 09:53) [567]

Однокамушкин   (25.06.07 09:29) [566]
это не Си и не Паскаль, оффтоп


 
имя   (2007-07-02 14:13) [568]

Удалено модератором


 
имя   (2007-07-25 00:01) [569]

Удалено модератором



Страницы: 1 2 3 4 5 6 7 8 9 
10 11 12 13 14 15 вся ветка

Форум: "Прочее";
Текущий архив: 2007.08.26;
Скачать: [xml.tar.bz2];

Наверх





Память: 2.43 MB
Время: 0.064 c
15-1185260598
boriskb
2007-07-24 11:03
2007.08.26
"Кысь"


1-1182165752
Makhanev Alexander
2007-06-18 15:22
2007.08.26
Как убить поток...


15-1185480586
Knight
2007-07-27 00:09
2007.08.26
Кто-нить может дать советы по настройке...


3-1178435782
~MaGic~
2007-05-06 11:16
2007.08.26
Добавление записей в таблицу


4-1172688389
Eraser
2007-02-28 21:46
2007.08.26
CreateProcessAsUserW и ошибка ERROR_PIPE_NOT_CONNECTED





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский