Полезные фичи и советы по программированию

[Dilan]

Василий, #35 >> Я, конечно, прошу прощения, но ты на чем пишешь под Linux? Де-факто в Linux - C  , можно писать, конечно, и на Java, Perl, Pascal и других, НО без глубокого знания С   в Linux'е делать нечего.  

[Dilan]

Dilan, #41 от 13-05-2004 11:27 >>
> Василий, #35 >> Я, конечно, прошу прощения, но ты на чем пишешь под Linux? Де-факто в Linux - C  , можно писать, конечно, и на Java, Perl, Pascal и других, НО без глубокого знания С   в Linux'е делать нечего.  

Это мое IMHO.  

[Василий]

> Де-факто в Linux - C  , можно писать, конечно, и на Java, Perl, Pascal и других, НО без глубокого знания С   в Linux'е делать нечего.
Вот именно - по мнению. Ядро на чём написано? На C  ? Нет! C   его даже не всегда и собирает (о такой возможности сейчас идут споры). На чистом С, а это уже легче. Более того, многие серьёзные проекты написаны именно на С, без плюсов. А если попытаться собрать чего-нибудь на С с плюсами, то даже при уменьшении оптимизации времени на это уйдёт...
А пишу я на FreePascal. Он имеет неплохие библиотеки, поддержку всего, чего надо, а теперь и прекрасную IDE типа Delphi под Linux и Windows (кстати, интерфейс на русском языке, не без меня).
Когда участвовал (немного) в общих С-шных проектах, то пользовался p2c - C-шный код я и без того понимал, а для нового лучше всё-таки паскалевский.

[Dilan]

Василий, #43 >> Не знаю, как с FreePascal, но под Linux проще писать на С и С  , т.к. есть возможность не изобретать велосипед заново, а использовать огромное количество уже готовых внешних библиотек, хотя бы библиотек GTK, Qt или SDL, а в паскале такой возможности, насколько я знаю нема (просто на паскале никогда не писал мощные вещи).

[Dilan]

Василий, #43 >> Я имею в виду софт, который в большинстве своем пошется на С  .

[Василий]

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

[Dilan]

Василий, #46 >> Уууух, Лор - бадяга, уж лучше на www.linuxshop.ru статьи и новости почитывать, хотя на мой взгляд самый рулезный сайт по новостям - www.linuxcenter.ru

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

[Dilan]

Dilan, #44 от 13-05-2004 16:28 >>
> Василий, #43 >> Не знаю, как с FreePascal, но под Linux проще писать на С и С  , т.к. есть возможность не изобретать велосипед заново, а использовать огромное количество уже готовых внешних библиотек, хотя бы библиотек GTK, Qt или SDL, а в паскале такой возможности, насколько я знаю нема (просто на паскале никогда не писал мощные вещи).

Забыл добавить, надо же еще стараться делать что-то с наименьшими затратами времени, ресурсов и т.д.

[Василий]

> уж лучше на www.linuxshop.ru статьи и новости почитывать, хотя на мой взгляд самый рулезный сайт по новостям - www.linuxcenter.ru
Всё бы хорошо, но больно уж он в Netscape на старых машинах тормозил. К счастью, новости оттуда почти всегда дублируются на ЛОРе.
> По поводу устойчивости - когда программист пишет прогу, даже если она будет без вопросов компилиться, он всегда не единожды сделает трассировочку, отладку, оптимизацию кода, вот только тогда всплывут все баги.

Тогда уж можно спокойно захлёбываться в воде - медики всегда сделают Вам искусственное дыхание.
К моменту отладки ошибок должно быть как можно меньше. Ведь отладка - вещь некорректная - программа может работать прекрасно, и только при определённой комбинации действий сработает опечатка.
К тому же отладка - вещь очень трудоёмкая, если при компиляции ошибку можно найти сразу и почти там, где она есть, то при отладке ошибка всплывёт где-нибудь ещё.
Более  того, программист может, будучи нетерпеливым, провести отладку основной ветки, не проверив обработку всех исключительных ситуаций.
А теперь попробуйте вообразить, во что превращается отладка, когда затрагивается важный файл более или менее серьёзного C  -проекта, пересборка которого займёт часов 5. Если учесть, что скорость компилятора Паскаля выше, да и первые ошибки, которые в С   можно поймать при выполнении, будут выявлены в момент компиляции этого файла (т.е. в первые секунды), то, думаю, преимущества явные.
Вот пример - знаменитая уязвимость, когда в условном операторе вместо проверки (сравнения)== поместили присваивание =. Конечно, мне, как паскалисту, вообще не понятно, зачем в условии вообще предусматривать возможность присваивания.
> Не знаю, как с FreePascal, но под Linux проще писать на С и С  , т.к. есть возможность не изобретать велосипед заново, а использовать огромное количество уже готовых внешних библиотек, хотя бы библиотек GTK, Qt или SDL, а в паскале такой возможности, насколько я знаю нема
Не всё так плохо, как Вам кажется. Во-первых, уже сделали более или менее юзабельную h2pas, что позволяет путём незначительного исправления переделать традиционные с-шные h-файлы для связывания с библиотеками. Во-вторых, посмотрите, что входит в комплект пакетов FreePascal - gtk, xlib, zlib, mysql (gtk2 - есть отдельно) и многие другие привязки уже есть в готовом виде.SDL - не помню, наверно, есть.
Qt в Паскале имеет очень мало смысла (хотя в kylixе его используют), т.к. в паскале и в С разная идеология ООП.
А если учесть, что возможности графических библиотек (включая gtk и qt) почти полностью перекрываются возможностями vcl, clx и lcl (последний - для FPC), то о лишних затратах времени можно не говорить.

[Dilan]

Василий, #49 от 14-05-2004 12:51 >>
> А теперь попробуйте вообразить, во что превращается отладка, когда затрагивается важный файл более или менее серьёзного C  -проекта, пересборка которого займёт часов 5.

Что же это за файл должен быть???   Каждый файл можно оттрасировать отдельно...  

[Василий]

> Что же это за файл должен быть???  Каждый файл можно оттрасировать отдельно..
Скажем, config.h

[Dilan]

Василий, #51 >> Гы, шутник.   Я этим не занимаюсь, это за меня другие люди делают.  

[Василий]

Вот то-то и оно! Сделает configure то, чего Вы плохо предусмотрели, и всё! Сколько раз бывает, что при "экзотической" конфигурации системы (а такой может оказаться любая конфигурация, отличная от программиста), компиляция просто не удаётся. configure проходит, а дальше - в лучшем случае, ошибка компиляции. В худшем - "nasty bug".
А, вообще, кроме config.h есть и масса других общих .h файлов, используемых почти всеми .c-файлами.

[Dilan]

Василий, #53 >> Еще НИ РАЗУ не было такого, чтобы у наших проектов возникали проблемы с чем-либо, ни configure, ни компиляция не подводили никогда, потому что есть четкое распределение обязанностей. В мои обязанности не входит следить, например, за проблемами конфигурирования => мне по барабану кто и как ее будет решать. А вот если написанный моню код не компилится - это уже моя проблема, и соответственно никтьо кроме меня не будет решать эту проблему. Вот такие пироги.

[Василий]

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

[Dilan]

Василий, #55 >> Приходится учитывать такие мелочи, но пока проблем не было.