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

← →
Игорь Шевченко © (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, то перекомпилировались и все другие модули, которые его использовали. Или я не прав?

2 VGA,
Проверил на версии dcc32.exe v15.0, подтверждаю поведение именно такое как вы описываете. Странно.

А вообще, это зависит от компилятора. FPC например хранит интерфейс скомпилированного модуля в отдельном файле, а сгенерированный машинный код - в обычном .o (т.к. он пользуется линкером, ассемблером и прочим из binutils)

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

offtop.
Это конечно придирка, но все-таки, я предпочитаю написание Vga, а не VGA. Хотя ник по сути действительно аббревиатура (И.Ф.О.).

>И компилятор вполне может обходиться перекомпиляцией только того,
> что действительно нужно - дельфи 7 это в общем-то и демонстрирует.

Ок, с раздельной компиляцией убедили. Но тут надо полагаться на "ум" компиляторов. В C оно все равно прозрачней - изменел header, автоматически все файлы включающие этот header изменятся и как следствие - перекомпилируются. Изменил .c файл - откомпилировался только он.

Зато чудесная прозрачность с тем, как заголовки включаются - типа #ifdef MY_H. У всего есть плюсы и минусы. У модулей в целом меньше видимо, раз Java & C# предпочли именно модули.

> Сабж все же был о пользе. Стоит изучать или не стоит. Если
> чел собрался зарабатывать на хлеб программированием, то,
> конечно же, стоит. Знать С/С++ с этой точки зрения гораздо
> полезнее чем знать Delphi

Это из другой опер... в смысле ветки ;)

> то мое субъективное мнение - на Delphi или С#

И Java не забудем ;)

Судя по некоторым - в плане "для удовольствия" не стоит забывать еще питон и руби. Кто их знает из моих знакомых - тащатся :)

А еще не стоит забывать и о lua. Писать на нем - одно удовольствие :) ИМХО.

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

> Как это не удивительно, но оперировать указателями я научился,
> когда познакомился с их реализацией на Си. Так что не всегда
> "Паскаль для обучения".

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

По ходу вспомнил что меня больше всего всегда раздражало в Си: зависимость регистра. Это уж точно надо быть машиной, чтобы воспринимать идентификаторы не по семантике, а по комбинации символов из ASCII :-) Ведь в любом естественном языке - регистр служит для удобства чтения, разделения предложений, но никак не для обозначения другого смысла. Почему бы хотя бы не сделать опциональным эту фичу? Я понимаю зависимость регистра в пароле, но какого черта нужно помнить регистр у своих идентификаторов? Причем сами Сишники похоже это неявно признают: верхний регистр стараются не использовать и повсеместно используют "_" для длинных идентификаторов :)

> ab

> Фигасе!

Точка - это конкатенация строк. На самом деле b :) Прикол в том, что не смотря на скобки, в условие попадает все что до вопроса. А "a1" - это истинное выражение.

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