После двух лет разработки анонсирован (http://lists.freepascal.org/lists/fpc-devel/2010-January/018...) выход открытого кроссплатформенного компилятора Free Pascal 2.4.0 (http://www.freepascal.org/), совместимого с Borland Pascal 7, Delphi и Metrowerks Pascal.
Из улучшений (http://wiki.freepascal.org/User_Changes_2.4.0) можно отметить:
- Реализована поддержка платформ: Mac OS X/PowerPC64, Mac OS X/x86_64, Mac OS X/ARM (iPhone) и Haiku/i386;- Компилятор:
- Поддержка Delphi-подобного стиля работы с ресурсами;
- Новая инфраструктура оптимизации программы в целом, поддерживающая девиртуализацию и удаление неиспользуемых виртуальных методов;
- Значительное увеличение скорости компиляции модулей, содержащих множественное определение типов;
- Возможность отключения вывода отдельных подсказок, заметок и предупреждений компилятора;
- Улучшение генерации отладочной информации в формате DWARF;
- Улучшение поддержки платформ ARM/EABI и оптимизация использован...URL: http://lists.freepascal.org/lists/fpc-devel/2010-January/018...
Новость: http://www.opennet.me/opennews/art.shtml?num=24883
Есть какие-нибудь фронт-енды для freepascal?
>Есть какие-нибудь фронт-енды для freepascal?Лазарус, но он, имхо, скорее мертв чем жив. Если программируете профессионально, все-таки посоветую забыть о Паскале, и использовать какой-нибудь более "популярный" язык
С каких пор это Lazarus мертв? Все живо и все активно развивается. http://lazarus.freepascal.org/
>С каких пор это Lazarus мертв? Все живо и все активно развивается.
>http://lazarus.freepascal.org/Не знаю, когда я его в последний раз видела, он был еще то ли на GTK1, то ли на чем-то еще таком же страшном до ужаса.
Новость, что теперь в проектах поддерживается тулкит gtk2 и готовится qt, я пропустила.
Но сама IDE выглядела, мягко говоря, не современно в сравнении с тем же эклипсом :(
Хи-хи-хи...
Без ГУЯ, GTK-1, GTK-2, QT-4, CARBON, COCOA(пока слабо), WIN32 (64 тоже :). Для ленивых, конечно, всегда чего-то не хватает, но для разработок - ОК!
По-моему Эклипс уступаеn Lazarus по удобству, но не по широте функционала.
>По-моему Эклипс уступаеn Lazarus по удобству, но не по широте функционала.В редхатах gtk1 сломан, и выглядит просто отвратно. Чинить его уже никто не будет, так как gtk1 слишком старый, и очень мало кому нужен (и это правильно)
Когда я поставила Lazarus около года тому назад, что бы решить одну задачку, перекрестилась от ужаса, и написала все это на bash без всяких IDE и FreePascal :(
Простите, но, по-моему это юзать нельзя. Может быть, сейчас что-то и изменилось, конечно...=====UPDATE==========
А вот Eclipse и очень удобен, и красив... Собираюсь его использовать на регулярной основе для написания модулей на ruby для Puppet'а.Может быть, стоит сделать FreePascal для Eclipse?
Очень сильно все изменилось.
>Очень сильно все изменилось.Хорошо, спасибо, нужно будет посмотреть, как предоставится случай
>А вот Eclipse и очень удобен, и красив...Я же честно написал "По-моему Эклипс уступает Lazarus". То что красив - да :)
> Может быть, стоит сделать FreePascal для Eclipse?А кто сказал, что его нет? Например, http://www.gavab.etsii.urjc.es/wiki/pascaline/
>А кто сказал, что его нет? Например, http://www.gavab.etsii.urjc.es/wiki/pascaline/А в чем его смысл? Если не поддерживается визуальное конструирование с использованием LCL, то слишком много полезного недоступно.
Дамы в программировании у меня всегда вызывали уважение. Слишком уж не привлекательная и занудная материя.
Фраза "А вот Eclipse и очень удобен, и красив... Собираюсь его использовать на регулярной основе для написания модулей на ruby для Puppet'а." присуща скорее некоей Ксении Собчак от программирования.
Всякий инструмент имеет свои сильные и слабые стороны. Это не бантик, который, типа, "я собираюсь пришпандорить на свою собачку". Каждому из нас какие-то инструменты нравятся, а какие-то не нравятся. Но мы это можем оценить только когда попробуем. Как правило, речь идет от том, осилили ли мы инструмент или нет. Если не осилили, то это никак не предмет гордости в среде программистов, скорее наоборот. Поэтому как правило, редко можно услышать, что кто-то из спецов критикует либу которую сам лично не освоил. Скорее наоборот, критика со стороны чела, который в реале не в одном проекте использовал эту либу, выглядит весьма конструктивной и адекватной...Сам я к сожалению не сумел осилить руби под Eclipse'ом. Такое очущение, что руби там ровно для галочки, дабы написать в аннотации. Предпочитаю Vi(m) и cli под Linux.
vim'n'cli +1000
Не сочтите за наезд. Скорее предостережение...
>Не сочтите за наезд. Скорее предостережение...Да я вообще не программистка, а администратор :) Так что, делать ляпы и говорить глупости (в меру, конечно), должно быть можно.
Это пока не уволят.
>Это пока не уволят.В ближайшем будущем разве что я сама себя уволю:)) http://blog.shaggy-cat.ru/2009/12/blog-post.html
Кстати, прежде чем говорить такое, Вы бы перечитали еще раз, что я писала в этой теме: ничего такого, что бы не разделял целый ряд людей из серьезно, и на fulltime занимающихся кодингом(и неплохо занимающихся) я не написала.
Извинилась же я за категоричность суждений, которую может себе позволить только человек, работающий с предметом обсуждения, не более но и не менее.А еще, Вы ничего про мой реальный (а не на словах) опыт, знания, и про меня как человека ничего не знаете. Я слегка поискала по Вашим постам на форуме. Вероятно, (в техническом плане) Вы не идиот. Может быть, Вам захотелось прецепиться к кому-нибудь первому попавшемуся? Если так, то чем Вы лучше меня в данной теме, делая выводы, не имея точных знаний о предмете суждения?
Если не программировать, то любая среда будет мертвой, а Lazarus очень интенсивно развивается.
>Если программируете профессионально, все-таки посоветую забыть о Паскале, и использовать какой-нибудь более "популярный" языкОбожаю такие фразы, они сразу говорят, что человек вообще нуль в программировании.
>>Если программируете профессионально, все-таки посоветую забыть о Паскале, и использовать какой-нибудь более "популярный" язык
>
>Обожаю такие фразы, они сразу говорят, что человек вообще нуль в программировании.Не буду отрицать, на жизнь зарабатываю совсем другим.
Хорошо, прошу прощения у всех за пару глупостей в этой теме :)Но вообще, что Pascal не язык для серьезных проектов, считают несколько знакомых профессиональных кодеров. Я не то, что бы разделяю их мнение, но прислушиваюсь.
>Но вообще, что Pascal не язык для серьезных проектов, считают несколько знакомых профессиональных кодеров. Я не то, что бы разделяю их мнение, но прислушиваюсь.Что значит "серьезный проект"? За который много платят, который большой по объему, еще никем не реализован и поэтому трудный? В чем серьезность то?
Ну не буду я модуль ядра писать на Lazarus(по крайней мере пока) и не буду для Wi-Fi роутера писать утилиты на Free Pascal(тоже пока), но и проект управления базами данных не буду писать на С/С++, да и, если нужно быстро слепить утилитку со всеми прелестями ГУИ, то тоже мало подходящего есть, а вот Lazarus для этого просто суперовски подходит, не смотря на свой бета статус.
> да и, если нужно быстро слепить утилитку со всеми прелестями
>ГУИ, то тоже мало подходящего есть, а вот Lazarus для этого
>просто суперовски подходит, не смотря на свой бета статус.PyGTK/PyQT разве не удобнее и не стабильнее? Хотя, конечно, оно скриптовое а не бинарное
Да и Netbeans + Java удобно и производительно в плане написания, но оно тоже не далеко от скриптового.Паскаль дает хороший по стабильности и производительности код. Сам Lazarus может выделываться, но код работает хорошо. Хотя есть указатели, выделения памяти и естественно, что могут быть глюки присущие С, но в меньшей степени, но можно и обойти ручное влияние на память. Сравнительно с PyGTK/PyQT, то это как бы разные весовые категории.
>Да и Netbeans + Java удобно и производительно в плане написания, но
>оно тоже не далеко от скриптового.
>
>Паскаль дает хороший по стабильности и производительности код. Сам Lazarus может выделываться,
>но код работает хорошо. Хотя есть указатели, выделения памяти и естественно,
>что могут быть глюки присущие С, но в меньшей степени, но
>можно и обойти ручное влияние на память. Сравнительно с PyGTK/PyQT, то
>это как бы разные весовые категории.Нужно будет показать эту ветку знакомым кодерам, интересно будет, что они скажут с высоты _своего_ реального опыта
>интересно будет, что они скажут с высоты _своего_ реального опытаВыскажут свое мнение, точно так, как и я свое :)
>>Если программируете профессионально, все-таки посоветую забыть о Паскале, и использовать какой-нибудь более "популярный" язык
>Обожаю такие фразы, они сразу говорят, что человек вообще нуль в программировании.Ну не знаю. Тяжело себе предсавить случай, в котором для real-life проекта будет выбран Pascal или, скажем, BASIC. Единственный известный мне случай написания востребрванного и достаточно качественного коммерческого продукта на Pascal - VentaFax.
Для бд-оболочек/rca рулит С#.
>Ну не знаю. Тяжело себе предсавить случай, в котором для real-life проекта
>будет выбран Pascal или, скажем, BASIC. Единственный известный мне случай написания
>востребрванного и достаточно качественного коммерческого продукта на Pascal - VentaFax.
>
>Для бд-оболочек/rca рулит С#.Незнание реальных возможностей Pascal ещё не означает что можно так говорить. Я точно так же не могу представить зачем вообще нужен С#, ведь я абсолютно всё тоже самое могу реализовать на Паскале.
>Незнание реальных возможностей Pascal ещё не означает что можно так говорить. Я
>точно так же не могу представить зачем вообще нужен С#, ведь
>я абсолютно всё тоже самое могу реализовать на Паскале.Реализовать то Вы можете, но речь шла о профессиональных проектах:
1) Кто Вам за это заплатит?
2) Будут ли этим пользоваться.
>>Незнание реальных возможностей Pascal ещё не означает что можно так говорить. Я
>>точно так же не могу представить зачем вообще нужен С#, ведь
>>я абсолютно всё тоже самое могу реализовать на Паскале.
>
>Реализовать то Вы можете, но речь шла о профессиональных проектах:
>1) Кто Вам за это заплатит?
>2) Будут ли этим пользоваться.Понятно. Тут уже вынужден согласиться, предложений о работе для Delphi сейчас не густо (но ещё есть - я ведь нашёл) хотя слово "профессиональных" заменил бы на "тех, чьи заказчики поддались на пиар Microsoft/Sun etc." +влияние обычного толпизма, "куда все туда и я". Было такое и с Delphi в своё время, но те времена прошли..
lazarus
Кто С++ не осилил?
Есть много кода на Delphi, на который завязаны бизнес-процессы во многих компаниях.
Портировать его под натив с легким использованием (при необходимости) wine-либ правильнее, чем мучится-глючится, целиком запуская под Wine.Пусть будет, от проекта большая польза :) Сама до сих пор не осилю на адекватном уровне C/C++, и, хотя занимаюсь совсем не программированием (а администратору тот же Python, имхо, нужнее), вспоминаю дельфяче-виндовое прошлое с какой-то ностальгией :)
В своё время так и не понял зачем нужно Delphi когда есть C++ Builder - то же самое, только для нормального человеческого языка C++ :-)
Типа, кто не осилил С++, таким в удел Pascal? Ошибаетесь, очень ошибаетесь.
паскаль создавался в первую очередь для обучения. имхо только для этого он и нужен
а те, кто ниасилил с++ пусть учат бэйсик или вообще ничего не учат
Уважаемый, кроме кодеров и "кодеров" есть другие профессии, например инженера, которым в дополнение приходится писать программы. Так вот, пока на С/С++ нашкрябаешь, а потом пока баги повылавливаешь, то на Lazarus`е весь проект закончить можно. Яву не предлагайте, слишком медленная, а ВАСИК сами асиливайте для инженерии он не подходит в силу своей ограниченности, громоздкости, моральной старости и забытости в массах.
> ВАСИК сами асиливайте для инженерии он не подходит в силу своей ограниченности, громоздкости, моральной старости и забытости в массах.Тут, вообще-то, если Вы не знаете, товарищи инженеры из Флориды написали всю математику и GUI цифрового DSP ARQ модема на Visual Basic. А т. к. в Visual Studio всё транслируется в MSIL, то по быстродействию оно аналогично программе на C++.
Ну так откуда же инженерам из Флориды о Free Pascal знать, если бы знали, то однозначно на Бейсике не писали бы :)В свое время, если не ошибаюсь, более 60% прикладного софта было написано на Visual Basic, но это вовсе не значит, что не нужно искать новые пути сейчас.
>Тут, вообще-то, если Вы не знаете, товарищи инженеры из Флориды написали всю математику и GUI цифрового DSP ARQ модема на Visual Basic.Можно ссылочку, а то гугл как-то не помог. А то возможны варианты, в ВБ ведь можно любые ДЛЛ подключать. А то вторая часть вашего коммента наводит на плохое знание матчасти.
>А т. к. в Visual Studio всё транслируется в MSIL, то по быстродействию оно аналогично программе на C++.
msil - это код виртуальной машины. Как байткод у java. Тормозит то есть. Ну и конечно используется только для дотнет приложений т.е. никакого с++.
http://ru.wikipedia.org/wiki/Microsoft_Intermediate_Language
>msil - это код виртуальной машины. Как байткод у java. Тормозит то есть.Про JIT-компиляцию не слышали? В дотнете она, кстати, применяется изначально, в отличие от java, где еще можно встретить интерпретацию байт-кода. Поэтому никаких тормозов, более того, в ряде случаев MSIL-код может работать даже быстрее нативного. Например, за счет того, что будет запущен на каком-нибудь новеньком дотнете и Intel Core i7. Разработчики нативного софта не могут себе позволить компилировать бинарник, завязанный на новейшее поколение машинных инструкций, потому что есть шанс, что у клиента такого процессора не окажется. А вот среда исполнения дотнета - вполне.
>Ну и конечно используется только для дотнет приложений т.е. никакого
>с++.Что Вы говорите? :-D Я вот буквально 3 месяца назад писал проект на С++ под дотнет :D На досуге спросите гугл про Managed C++
>Про JIT-компиляцию не слышали?Слышал, но не видел.
>Поэтому никаких тормозов,
Блажен кто верует.
>более того, в ряде случаев MSIL-код может работать даже быстрее нативного.
Эти теоретические соображения я слышу уже лет 10. Более того 10 лет назад я сам в них верил.
>:D На досуге спросите гугл про Managed C++
Это тот который объединил недостатки C++ и дотнета?
>Слышал, но не видел.Оно и заметно.
>Блажен кто верует.
Ну если для Вас это вопрос веры... :-D Лично для меня это вопрос сугубо технический, который элементарно поддается измерениям и анализу. Что и было многократно сделано, и не только мной.
>Эти теоретические соображения я слышу уже лет 10
Еще раз повторяю - это не какие-то там высоко-философские тонкие материи, это элементарно проверяется на практике. И это работает.
>Более того 10 лет назад я сам в них верил.
Снова какие-то верования :D
>Это тот который объединил недостатки C++ и дотнета?
Ахаха, ну смешно, ну Петросян. А по существу ровным счетом ничего и не сказано.
>Ну если для Вас это вопрос веры... :-D Лично для меня это
>вопрос сугубо технический, который элементарно поддается измерениям и анализу. Что и
>было многократно сделано, и не только мной.Понимаете, если я вижу что прога тормозит, а тесты показывают обратное, то это какие-то специальные тесты, не для меня сделанные.
>>Это тот который объединил недостатки C++ и дотнета?
>Ахаха, ну смешно, ну Петросян. А по существу ровным счетом ничего и
>не сказано.По существу подходы дотнета и с++ несовместимы. А managed с++ МС отменила.
http://msdn.microsoft.com/en-us/library/b23b94s7.aspx
For Visual C++ 2008, support for Managed Extensions for C++ is deprecated, and might be removed entirely in a future release.
>По существу подходы дотнета и с++ несовместимы. А managed с++ МС отменила.Вы для начала читать научитесь, хотя бы то, что написано по Вашей же ссылке. Никто и не думает отменять Managed C++, там лишь идет речь о смене синтаксиса некоторых расширений и предостережение не использовать его в будущих релизах.
>Никто и не думает отменять Managed C++, там лишь идет речь о смене синтаксиса некоторых расширений и предостережение не использовать его в будущих релизах.Сказано что ваш старый код больше не поддерживается (т.е. переписывайте во 2 раз), но пока поленились эту поддержку выкинуть. Вообще это же все маркетинг. Для привлечения С++ программистов, которым не вилы неоднократно переписывать свой код (поскольку Managed C++ != C++ и не может быть по определению), чтоб потом его все-равно выкинуть, когда МС решит что хватит маркетинга и пора всех дотнетовцев на C#. Что на самом деле и разумно.
Но дело то не в перспективах Managed C++, а в том что для дотнета на С++ писать нельзя, все равно код надо переделывать. С++ код в дотнете не работает.
>Но дело то не в перспективах Managed C++, а в том что для дотнета на С++ писать нельзя, все равно код надо переделывать. С++ код в дотнете не работает.Вы попробуйте для начала этот Managed C++, прежде чем писать эту чушь. Все там работает, естественно, что существуют небольшие различия по сравнению с традиционным С++. Именно о смене синтаксиса этих расширений и шла речь, но это менее 1% исходного кода. А в остальном - тот же самый С++.
>Вы попробуйте для начала этот Managed C++, прежде чем писать эту чушь.
>Все там работает, естественно, что существуют небольшие различия по сравнению
>с традиционным С++. Именно о смене синтаксиса этих расширений и шла
>речь, но это менее 1% исходного кода. А в остальном - тот же самый С++.Приятно, что мы не расходимся во мнениях.
1. Managed C++ != С++
2. синтаксис расширений сменился, а старый больше не поддерживаетсяНасчет пробовать - это уж вы сами, без меня. Что до дотнет вообще и часто упоминаемых удивительных тестов, дам совет. Берете старый МС Оффис дотнета не требующий и новый без него не работающий, ставите рядышком на 1 машину (желательно не восьмиядерную) и запускаете по очереди. Аналогично можно поступить например с Автокадом. После этого перечитываем результаты тестов о том, что дотнет приложения быстрее.
>Можно ссылочку, а то гугл как-то не помог.google://WINMOR
>в ВБ ведь можно любые ДЛЛ подключать.
Со слов разработчика, они сначала подключали некоторые либы (DLL-ки в каталоге программы), но потом переписали внешние ф-ии под VB.NET.
>А то вторая часть вашего коммента наводит на плохое знание матчасти.
А как же тогда по-вашему компилятся программы на VB.NET?
P.S. Моя реплика была по поводу того, что BASIC не совесм "умер". Кое где ещё живёт, как видим. Я не агитирую писать на BASIC-е.
>google://WINMORВсе равно не нашел ссылки именно на VB реализацию WINMOR протокола. Но сам протокол уж очень низкоскоростной, так что вполне возможно.
is expected to provide speeds ranging from 125 to at least 1875 bits per second
>А как же тогда по-вашему компилятся программы на VB.NET?
Как и все дотнет проги. Они же вообще не компилятся в обычном понимании этого слова.
>P.S. Моя реплика была по поводу того, что BASIC не совесм "умер".
Конечно не умер. Вот еще
http://www.idevgames.com/news/cross-platform-basic-purebasic...
>Яву не предлагайте, слишком медленнаяНе верю ©
>Не верю ©А я верю своим глазам и это правда.
>а те, кто ниасилил с++ пусть учат бэйсик или вообще ничего не
>учат15 лет назад я вполне серьезно считал, что плюсы - единственный язык профессионального программирования. Но времена сильно изменились, появились интересные языки, которые медленно, но верно занимают его нишу.
А C++ при всех его достоинствах, не настолько велик как сам C, чтобы остаться бессмертным.
>паскаль создавался в первую очередь для обучения.ещё один "программист" который не знает, что ЯЗЫК для ОБУЧЕНИЯ студентиков специально не создаются. ЖГИ ЕЩЁ!
Еще один аноним, который не знает, что он ничего не знает. "Initially, Pascal was largely, but not exclusively, intended to teach students structured programming. Generations of students have used Pascal as an introductory language in undergraduate courses." http://en.wikipedia.org/wiki/Pascal_(programming_language)
Копните глубже википедии. Что бы там кто не говорил, а Паскаль это почти Алгол. А про Алгол никто почему то не догадался такого сказать.
>Копните глубже википедии. Что бы там кто не говорил, а Паскаль это
>почти Алгол. А про Алгол никто почему то не догадался такого
>сказать.
>
>http://ru.wikipedia.org/wiki/АлголДа, а студент-санитар - почти психиатр.
>>паскаль создавался в первую очередь для обучения.
>
>ещё один "программист" который не знает, что ЯЗЫК для ОБУЧЕНИЯ студентиков специально
>не создаются. ЖГИ ЕЩЁ!Вообще-то это всем (ну, оказывается, не всем) известный факт, что Николай Вирт создавал Pascal именно для обучения студентов программированию (да, можно учиться именно программированию, конкретный язык может быть средством, а не целью обучения). А языки специально для чего только ни создаются.
>паскаль создавался в первую очередь для обучения. имхо только для этого он
>и нужен
>а те, кто ниасилил с++ пусть учат бэйсик или вообще ничего не
>учатВы чрезвычайно сильно заблуждаетесь... Как минимум в современном Delphi есть практически всё, что есть в "больших" ООП-Языках программирования: поддержка интерфейсов, неймспейсов, дженериков, развитая система типов, анонимные методы. Так что в технологическом и архитектурном отношении, различия Delphi и C++ сейчас минимальны.
>Так что в технологическом и архитектурном отношении,
>различия Delphi и C++ сейчас минимальны.В некотором плане delphi превосходит с++
Имеется в виду "многословность" и строгость синтаксиса, что облегчает компиляцию и статический анализ. А также расздельная компиляция, пространства имен и т.п. о чем вы сами в курсеВсё таки доля современных диалектов паскаля незаслуженно мала. Тому виной тяжкое историческое наследие каменного века информационных технологий и необходимость поддерживать имеющююся инфраструктуру. Новые компилируемые языки (D, C# и пр.) имеют очень много общего с delphi.
вам шашечки или ехать?
>вам шашечки или ехать?Если хочется ехать то Паскаль не по адресу. Python, Ruby и прочие с динамической типизацией и автоматическим управлением памятью.
Если ехать то C++ без вариантов.
>Если ехать то C++ без вариантов.Смотря куда и как. :) Я долгое время писал на Делфи и Билдере под виндой, и, хотя сам предпочитаю Си, сейчас с прискорбием прихожу к выводу, что наиболее удобная среда для разработки гуйовых приложений под виндой - Делфи. По сравнению с тем же Билдером она и работает быстрее, и компилит быстрее, и совместимость с предыдущими версиями терпимая, и всяких нюансов меньше. Ну, Паскаль - тупой язык, но в целом преимуществ все равно получается больше. :(
>Ну, Паскаль - тупой язык, но
>в целом преимуществ все равно получается больше. :(И в чем же эта тупость проявляется?
>И в чем же эта тупость проявляется?Ну, например, чтобы определить массив, нужно всегда точно знать количество элементов массива. Дали мне, например, таблицу кодов, которую мне надо "жестко" прописать в программе. Я пишу:
type
TLocoRec = record
Name: string;
Code: Integer;
end;const
LocoCodeTable: array [1..166] of TLocoRec = (
(Name: '2М62'; Code: 539;),
(Name: '2М62У'; Code: 579;),
(Name: '2ТЭ10'; Code: 526;),//...
);
Так вот, чтобы определить этот массив, мне нужно обязательно СОСЧИТАТЬ количество элементов и убедиться, что их ровно 166! Хорошо, что их "всего лишь" 166, а если бы их было полторы тысячи? О_о Теперь спецификация изменилась и несколько кодов выкинули, а несколько добавили. Опять надо все пересчитывать или производить сложения и вычитания. Бред... В Си и других языках можно просто написать LocoCodeTable[] и редактировать массив как угодно.
> Хорошо, что их "всего лишь" 166, а если бы их было полторы тысячи?Честно говоря, не вижу большой проблемы.
Делов-то:
type
TLocoRec = record
Name: string;
Code: Integer;
end;TLocoCodeTable = array of TLocoRec;
var
myarray: TLocoCodeTable;
function LoadTableFromCSV(filename: string): TLocoCodeTable;
И вообще, для связок name = value есть StringList. Там уже все реализовано тыщу лет назад.А csv можно править через Excel/ОО. Так, имхо лучше.
Но от возможности писать
const
LocoCodeTable: array of TLocoRec (...)
я бы тоже не отказался. ;)
>[оверквотинг удален]
> Code: Integer;
> end;
>
> TLocoCodeTable = array of TLocoRec;
>
>var
>
>myarray: TLocoCodeTable;
>
>function LoadTableFromCSV(filename: string): TLocoCodeTable;Зачем? Мне всего лишь нужно описать массив констант, а вы предлагаете мне вместо этого загружать CVS, который я должен буду таскать везде вместе с экзешником или прилинковывать к нему в виде ресурса. К тому же, мне не надо чтобы к этой таблице имел доступ любой чайник.
>И вообще, для связок name = value есть StringList. Там уже все реализовано тыщу лет назад.
А инициализировать его как? Опять загружать из внешнего файла? Или писать 166 раз LocoCodeTable.Values['...'] := '...'? А чтобы получить целое значение Code каждый раз вызывать StrToInt? Я уже не говорю о том, что это будет работать медленнее чем с обычным массивом...
>А csv можно править через Excel/ОО. Так, имхо лучше.
Ага, а еще это можно сделать как-нибудь через собственный COM-объект... :) Вот о чем я и говорю! Как только не приходится извращаться в Паскале вместо того, чтобы просто написать:
locorec_t mytable[] = {
"2М62", 539,
"2М62У", 579,
//...
};>Но от возможности писать
>const
> LocoCodeTable: array of TLocoRec (...)
>я бы тоже не отказался. ;)Да я и не против. Но зачем указывать размерность массива! Это же константы! У студентов, может быть, время есть их пересчитывать, а мне семью кормить надо! :)
>Да я и не против. Но зачем указывать размерность массива! Это же
>константы! У студентов, может быть, время есть их пересчитывать, а мне
>семью кормить надо! :)Вы не обессудьте, но проблема представляется несколько надуманной. Если бы мне это было постоянно нужно, то я бы написал утилитку для автоподсчета элементов и формирования кода для описания массива который бы потом закопипастил в исходник. А один раз можно и посчитать.
А другие претензии есть?
В Си кстати у массива размерности по существу просто и нет. Там массив по существу указатель, и это создает свои проблемы, про которые тоже можно поговорить.
>Если бы мне это было постоянно нужно, то я бы написал утилитку для автоподсчета элементов и формирования кода для описания массива который бы потом закопипастил в исходник.То есть, купив за несколько десятков тысяч рублей Делфи, я, вместо того чтобы работать, должен изготавливать самодельный костыль, который будет подсчитывать элементы массива вместо компилятора. Какая прелесть! Причем виноваты в этом не Делфи и не компилятор, а сам синтаксис Паскаля. Вот поэтому-то я его и назвал его тупым языком.
>А другие претензии есть?
Есть, но высказывать их я больше не собираюсь - Паскаль от этого все равно не изменится. А вообще на эту тему есть классическая (правда, кое в чем уже устаревшая) статья Кернигана "Why Pascal is Not My Favorite Programming Language" http://www.lysator.liu.se/c/bwk-on-pascal.html
>В Си кстати у массива размерности по существу просто и нет. Там массив по существу указатель, и это создает свои проблемы, про которые тоже можно поговорить.
Вообще-то это не совсем так. Арифметика указателей и массивов в Си действительно одинаковая, но они суть разные вещи: http://c-faq.com/aryptr/aryptrequiv.html
Насчет проблем - согласен.
>То есть, купив за несколько десятков тысяч рублей Делфи, я, вместо того чтобы работать, должен изготавливать самодельный костыль, который будет подсчитывать элементы массива вместо компилятора.Зачем. Скачайте Лазаря бесплатно.
>(правда, кое в чем уже устаревшая) статья Кернигана "Why Pascal is
>Not My Favorite Programming Language" http://www.lysator.liu.se/c/bwk-on-pascal.htmlКерниган создатель Си, ну как ему может нравиться Паскаль. А я писал на обоих языках и с ним не согласен. А это
Comparing C and Pascal is rather like comparing a Learjet to a Piper Cub - one is meant for getting something done while the other is meant for learning
мне просто смешно читать. Я как раз наоборот считаю - сделать это Паскаль, мозг посношать - Си.>Вообще-то это не совсем так. Арифметика указателей и массивов в Си действительно
>одинаковая, но они суть разные вещи: http://c-faq.com/aryptr/aryptrequiv.htmlЭто только с точки зрения сишников есть, а с точки зрения паскалистов нет. Сравните аналогично указатели и массивы в Паскале, разница будет заметна. Один sizeof чего стоит. В общем то с точки зрения Паскаля в Си и строк нет. И это тоже создает массу проблем.
>Зачем. Скачайте Лазаря бесплатно.То есть, я буду точно так же подсчитывать элементы массива, но теперь уже бесплатно? :)
>Я как раз наоборот считаю - сделать это Паскаль, мозг посношать - Си.
Вам показывают черное, а вы говорите: "белое". Вот как раз сделать на Паскале и не получается - приходится массив констант из отдельного файла загружать или дополнительные утилиты к компилятору писать :) Прав Керниган.
>Это только с точки зрения сишников есть, а с точки зрения паскалистов нет.
Если, как вы утверждаете, вы писали на обоих языках, то должны понимать, что нет "сишников" и "паскалистов". Есть студенты, которые знают один из этих языков, а второй не осилили. Такие понятия, как "массив", "указатель" и "строка", являются универсальными и в разных языках различается только их реализация. Например, в Паскале традиционно длина строки хранилась в нулевом символе, а в Си строка ограничивалась терминальным нулем. И это вовсе не означает, что "с точки зрения Паскаля" (или с какой-либо другой точки зрения) в Си нет строк. Что-то надоело мне сегодня объяснять прописные истины... :(
>>Я как раз наоборот считаю - сделать это Паскаль, мозг посношать - Си.
>
>Вам показывают черное, а вы говорите: "белое". Вот как раз сделать на
>Паскале и не получается - приходится массив констант из отдельного файла
>загружать или дополнительные утилиты к компилятору писать :) Прав Керниган.Вы привели 1 частный пример. Мне например это неудобств не доставляло. А примеров сишных проблем я могу вагон написать. Керниган не прав ни по одному из пунктов сейчас, и по многим неправ в 1981.
>Если, как вы утверждаете, вы писали на обоих языках, то должны понимать,
>что нет "сишников" и "паскалистов".Я писал заметно больше чем на 2. А такое деление наблюдаю в жизни. Сишники это те кто игнорирует громадное количество сишных проблем.
>Есть студенты, которые знают один из
>этих языков, а второй не осилили.Такие понятия, как "массив", "указатель"
>и "строка", являются универсальными и в разных языках различается только их
>реализация.Только указатель универсальное, с остальным далеко не все так просто.
>Например, в Паскале традиционно длина строки хранилась в нулевом символе,
>а в Си строка ограничивалась терминальным нулем. И это вовсе не
>означает, что "с точки зрения Паскаля" (или с какой-либо другой точки
>зрения) в Си нет строк.Разница громадна. В 1 случае чтобы определить длину строки надо 1 чтение из памяти. Во 2 надо сканировать всю строку. Но сишники этого не понимают.
>Что-то надоело мне сегодня объяснять прописные истины... :(
Вы их не можете объяснить, сишники их не знают.
Что до Кернигана, то посмотрим повнимательнее
-------
To close, let me summarize the main points in the case against Pascal.
Since the size of an array is part of its type, it is not possible to write general-purpose routines, that is, to deal with arrays of different sizes.Неактуально. Open array parameters
In particular, string handling is very difficult.
Как бы не наоборот.
The lack of static variables, initialization and a way to communicate non-hierarchically combine to destroy the ``locality'' of a program - variables require much more scope than they ought to.Инициализация есть, полезность Си-подобных static в процедурах сомнительна, и как бы не вредна.
The one-pass nature of the language forces procedures and functions to be presented in an unnatural order; the enforced separation of various declarations scatters program components that logically belong together.Несерьезно.
The lack of separate compilation impedes the development of large programs and makes the use of libraries impossible.
Неактуально.
The order of logical expression evaluation cannot be controlled, which leads to convoluted code and extraneous variables.
Несерьезно. Скобки. Если кто не любит скобки, так, как люблю их я, тот сам себе злобный буратино.
The 'case' statement is emasculated because there is no default clause.Неактуально. case...else...end;
The standard I/O is defective. There is no sensible provision for dealing with files or program arguments as part of the standard language, and no extension mechanism.Неактуально.
The language lacks most of the tools needed for assembling large programs, most notably file inclusion.
Неактуально.
There is no escape.Неактуально.
Ну и его не main points, типаIn particular, there are no bit-manipulation operators (AND, OR, XOR, etc.)
тоже давно неактуальны.
И вообще он выдумал какой-то сферический pure pascal в вакууме (In its pure form, Pascal...) и его критикует.Да и его способность пронзать мыслью время не впечатляет
It has certainly influenced the design of recent languages, of which Ada is likely to be the most important.
ну и где теперь Ада и где Паскаль?
А уж это заявление, это вообще абзац.
This last point is perhaps the most important. The language is inadequate but circumscribed, because there is no way to escape its limitations. There are no casts to disable the type-checking when necessary. There is no way to replace the defective run-time environment with a sensible one, unless one controls the compiler that defines the ``standard procedures.'' The language is closed.
>Вы привели 1 частный пример. Мне например это неудобств не доставляло.Кому-то и на потолке спать неудобств не доставляет. Не аргумент.
>А примеров сишных проблем я могу вагон написать.
Проблем у Паскаля от этого не убавится.
>Керниган не прав ни по одному из пунктов сейчас, и по многим неправ в 1981.
Необоснованное утверждение.
>Я писал заметно больше чем на 2. А такое деление наблюдаю в
>жизни. Сишники это те кто игнорирует громадное количество сишных проблем.Я такого деления не наблюдаю. Возможно, вам следует больше общаться с опытными программистами.
>Только указатель универсальное, с остальным далеко не все так просто.
Звучит внушительно :)
>Разница громадна. В 1 случае чтобы определить длину строки надо 1 чтение
>из памяти. Во 2 надо сканировать всю строку. Но сишники этого
>не понимают.Во-первых, "сишники" понимают, что длина каждой строки программе не нужна. Длины строк не нужны даже для многих операций со строками - достаточно знать длину результирующего буфера. Зачем плодить сущности? Во-вторых, строка может быть длиннее 255 символов. Сколько байтов тогда отводить под длину? Два? А может быть сразу четыре? И таскать эти байты с каждой строкой, независимо от того нужна программе длина строки или нет? А может быть еще добавить динамические строки и наплодить зоопарк строковых типов как в Делфи? Решение в духе Паскаля! Ну, и наконец, вы экономите микросекунды на подсчете длины строки, но для подсчета числа элементов массива у вас есть время даже для написания отдельной утилиты! Да уж, "сишникам" этого не понять! :)
>
>>Что-то надоело мне сегодня объяснять прописные истины... :(
>
>Вы их не можете объяснить, сишники их не знают.
>Эти "сишники" вас, похоже, чем-то обидели... :)
>Что до Кернигана, то посмотрим повнимательнее
>...
>Неактуально. Open array parameters
>...
>Неактуально.
>...
>Неактуально.Для того, чтобы это все стало неактуально, пришлось создать современный Делфи-подобный Паскаль, который отличается от тогдашнего как небо от земли. А вот для Си это не было актуальным _никогда_, потому что он изначально был более последовательным языком и изменений претерпел гораздо меньше. Я помню еще как синтаксис Паскаля запрещал игнорировать возвращаемые функцией значения. То есть если ты вызываешь функцию и возвращаемое ей значение тебе не нужно, ты все равно должен объявить переменную и сделать присваивание! Вот идиотизм-то! Не удивительно, что пришлось потом придумать "расширенный синтаксис", чтобы избавиться от этой и других таких же замечательных фич... :)
>А уж это заявление, это вообще абзац.
>
>This last point is perhaps the most important. The language is
>inadequate but circumscribed, because there is no way to escape its
>limitations. There are no casts to disable the type-checking when
>necessary. There is no way to replace the defective run-time
>environment with a sensible one, unless one controls the compiler that
>defines the ``standard procedures.'' The language is closed.Абсолютно правильно! От ограничений Паскаля до сих пор никуда не денешься. Он даже препроцессором вменяемым до сих пор не обзавелся. И намертво привязан к своей run-time среде, что значительно сужает область его применения по сравнению с Си. Про проверку типов - даже у нынешнего Паскаля - и вспоминать не хочу! Парсить нетипизированные двоичные данные без геморроя просто не возможно.
>[оверквотинг удален]
>не нужны даже для многих операций со строками - достаточно знать
>длину результирующего буфера. Зачем плодить сущности? Во-вторых, строка может быть длиннее
>255 символов. Сколько байтов тогда отводить под длину? Два? А может
>быть сразу четыре? И таскать эти байты с каждой строкой, независимо
>от того нужна программе длина строки или нет? А может быть
>еще добавить динамические строки и наплодить зоопарк строковых типов как в
>Делфи? Решение в духе Паскаля! Ну, и наконец, вы экономите микросекунды
>на подсчете длины строки, но для подсчета числа элементов массива у
>вас есть время даже для написания отдельной утилиты! Да уж, "сишникам"
>этого не понять! :)AnsiString = 4 байта под длину. Ну и что? Надо без длины строку типа C - используй PAnsiChar.
> Про проверку типов - даже у нынешнего Паскаля
>- и вспоминать не хочу! Парсить нетипизированные двоичные данные без геморроя
>просто не возможно.Не замечал проблем.
>Я такого деления не наблюдаю.Игнорирование очевидных фактов не проиводит к их исчезновению.
>>Только указатель универсальное, с остальным далеко не все так просто.
>Звучит внушительно :)Дело в том, что вы не видите разницы между структурой данных и именованой областью памяти неизвестной длины и содержания. Первая содержит служебную информацию, вторая нет. В случае Паскаль строки служебка это длина и счетчик ссылок, а стоило бы и еще кое-что добавить. В целом вы не видите особой разницы между языком высокого уровня и макроассемблером.
Просто же указатель на адрес памяти неизвестно с чем, это вещь однозначная, хотя есть успешные языки без таких указателей.
>Во-первых, "сишники" понимают, что длина каждой строки программе не нужна. Длины строк
>не нужны даже для многих операций со строками - достаточно знать
>длину результирующего буфера. Зачем плодить сущности? Во-вторых, строка может быть длиннее 255 символов.Легко проверяемая длина строки нужна всегда. Иначе - переполнение буфера. Последствия этой ошибки каждый день в новостях. Как раз там где знают длину буфера не зная длины строк.
>Сколько байтов тогда отводить под длину? Два? А может быть сразу четыре? И таскать эти байты с каждой строкой, независимо от того нужна программе длина строки или нет?
Вот эта то дополнительная информация и отличает структуру данных - строку, от именованной области памяти неизвестной длины и содержания, которая гордо названа строкой в макроассемблере под названием Си.
>может быть еще добавить динамические строки и наплодить зоопарк строковых типов как в Делфи?
1. старая строка для совместимости, и обычно уже не нужна
2. новая строка, которой для всех дел обычно и хватает (и длины там 4 байта, и динамическая она, и счетчик ссылок есть, и \0 для фанатов добавили)
3. строки совместимости с другими языками
>Решение в духе Паскаля! Ну, и наконец, вы экономите микросекунды на подсчете длины строки,
речь не только об экономии (может быть довольно значительной), а и о возможном buffer overflow
>но для подсчета числа элементов массива у вас есть время даже для написания отдельной утилиты!
Я же сказал, у меня этой проблемы нет. И я не работаю со статическими массивами неизвестной мне длины, как хотите делать вы. Как можно не знать длину своих статических данных? В вашем же случае я бы скорее всего не стал применять статический массив, а использовал ассоциативный из sdl. Там и число элементов заранее знать не надо.
А писать утилиты обычное дело для любого программиста, а на Паскале на цикл написание-отладка уходит меньше времени, чем на Си.
>Эти "сишники" вас, похоже, чем-то обидели... :)
Не столько обидили, сколько работать мешают. Пропихивание всюду этого проблемного языка (или его частей - например в жабе или верилоге), людьми, не понимающими всей его проблемности, привело к тому, что мне приходится им иногда пользоваться. Что мне реально создает лишние проблемы.
>Для того, чтобы это все стало неактуально, пришлось создать современный Делфи-подобный Паскаль, который отличается от тогдашнего как небо от земли.
Вы путаете введение объектности (Си и ++ тоже рядом не лежали) с косметическими изменениями введенными давным-давно (кстати Си тоже менялся). А кроме того, лично я считаю введение многих из этих новых возможностей лишним, усложняется синтакс, без особого выигрыша по сути. Вот я например категорически против планируемого Си-подобного изменения в определении массивов.
Да и Керниган, после длинных завываний, сообщил, что все что сделано на Си он успешно сделал и на Паскале (на самом старом заметьте), и даже длина библиотеки не возросла.
The finished programs are in general about the same number of source lines as their Ratfor equivalents. At first this surprised me, since my preconception was that Pascal is a wordier and less expressive language.
И наконец Керниган то проблемы Си понимает, поэтому сам не предрекает ему большого будущего, а выступает за Аду. В реале же улучшили Паскаль.
>Я помню еще как синтаксис Паскаля запрещал игнорировать возвращаемые функцией значения. >То есть если ты вызываешь функцию и возвращаемое ей значение тебе не нужно, ты
>все равно должен объявить переменную и сделать присваивание! Вот идиотизм-то!В этом случае в Паскале пользуют вместо function procedure. И ничего объявлять не надо. А если функция что-то возвращает, то это обычно код ошибки или другая нужная инфа, которую игнорировать нежелательно. Как кстати и в Си.
>Не удивительно, что пришлось потом придумать "расширенный синтаксис",
Вот это то я и считаю лишним. Зачем было потакать сишникам которые не видят разницы между function и procedure, поскольку второй у них нет, или склонны игнорировать коды ошибок.
>Абсолютно правильно! От ограничений Паскаля до сих пор никуда не денешься. Он
>даже препроцессором вменяемым до сих пор не обзавелся.Препроцессор на самом деле не часть языка. Это просто программа, заменяющая одни наборы символов на другие. Используйте любой, например cpp.
The cpp(1) program is the C language preprocessor. The Pascal compiler driver pc normally calls cpp(1) during the first pass of a Pascal compilation. If you use the -xl switch, pc calls the alternate preprocessor cppas. Then cpp(1) and cppas will operate on files having the extension .p or .pas.
>Про проверку типов - даже у нынешнего Паскаля - и вспоминать не хочу!
Ну да, у макроассемблера типов действительно нету. От этого и проблемы. А проверка типов то нужна для отлова ошибок во время компиляции компилятором. Вот это реально экономит время программиста, а не возможность определять статические массивы неизвестной длины.
>Парсить нетипизированные двоичные данные без геморроя просто не возможно.
Не замечал особых проблем.
> В этом случае в Паскале пользуют вместо function procedure. И ничего объявлять не надо.Думаю, здесь товарищ имел в виду не вами писаную функцию, а якобы обязательность использования в вашем коде переменной для сохраниения результата вызова внешней функции.
Я не знаю, как во ФриПаскале, а в Делфи функцию можно вызывать как процедуру и не надо плодить переменных чтоб сохранять возвращаемый ф-цией результат.
Другое дело (тоже опыт Делфи), что для необъектных var(или out)-параметров функции или процедуры нужно заводить переменные для возвращения туда вызываемой ф-цией/процедурой значений (для объектных можно передавать в параметр nil на свой страх и риск)
> В этом случае в Паскале пользуют вместо function procedure. И ничего объявлять не надо.Думаю, здесь товарищ имел в виду не вами писаную функцию, а якобы обязательность использования в вашем коде переменной для сохраниения результата вызова внешней функции.
Я не знаю, как во ФриПаскале, а в Делфи функцию можно вызывать как процедуру и не надо плодить переменных чтоб сохранять возвращаемый ф-цией результат.
Другое дело (тоже опыт Делфи), что для необъектных var(или out)-параметров функции или процедуры нужно заводить переменные для возвращения туда вызываемой ф-цией/процедурой значений (для объектных можно передавать в параметр nil на свой страх и риск)
>Я не знаю, как во ФриПаскале, а в Делфи функцию можно вызывать
>как процедуру и не надо плодить переменных чтоб сохранять возвращаемый ф-цией
>результат.Это все понятно. Но вы все таки дочитайте что там еще написано.
>А если функция что-то возвращает, то это обычно код ошибки или другая нужная инфа, которую игнорировать нежелательно.
>Вам показывают черное, а вы говорите: "белое". Вот как раз сделать на Паскале и не >получается - приходится массив констант из отдельного файла загружать или дополнительные >утилиты к компилятору писать :) Прав Керниган.Вы же сами сказали - справочник может меняться. А если он может меняться, то он будет меняться. А если он будет меняться, вы будете перекомпилировать заново. В С/С++, кстати, тоже. Так что это баг вашей архитектуры, а не паскаля.
>Так что это баг >вашей архитектуры, а не паскаля.Да у него пары ключ-значение. Может вообще стоило бы в эту сторону поглядеть.
Ассоциативные структуры данных. SDL - первая библиотека структур данных для Delphi, которая предоставляет естественное, атомарное хранение ассоциаций. Например, добавление к ассоциативному массиву выполняется просто как map.putPair([10,'hello']). Операция размещает значение 'hello' c ключом 10 в ассоциативном массиве. Обратите внимание, что значения определяются без каких-либо объектных оберток. Мы можем также легко добавить объекты к ассоциации: map.putPair(['RossJudson',objTest]).
>Вы же сами сказали - справочник может меняться.Он может меняться только в процессе разработки. Спецификация может уточняться.
>>Вы же сами сказали - справочник может меняться.
>
>Он может меняться только в процессе разработки. Спецификация может уточняться.а почему прицепились именно к статическому массиву, раз возможны варианты? почему бы в таком случае не набивать динамический массив в initialization модуля, например?
Как раз в fpc-pascal обсуждается возможность реализации синтаксиса избавляющего от явного декларирования диапазона массива. Так что, глядишь в следующей версии компилятора это может и появиться.
>Как раз в fpc-pascal обсуждается возможность реализации синтаксиса избавляющего от явного декларирования
>диапазона массива. Так что, глядишь в следующей версии компилятора это может
>и появиться.А к тому времени, глядишь, и Лазаря допилят до уровня Делфи, и Делфи со спокойной душой можно будет выкинуть на помойку... :)
>Как раз в fpc-pascal обсуждается возможность реализации синтаксиса избавляющего от явного декларирования
>диапазона массива. Так что, глядишь в следующей версии компилятора это может
>и появиться.А совместимоcть побоку? Или у Дельфина такие же планы?
>А совместимоcть побоку? Или у Дельфина такие же планы?Ну так совместимость для FPC = компилировать код Delphi. О наоборот должны в embarcadero заботиться.
>Ну так совместимость для FPC = компилировать код Delphi.А для меня - возможность иметь один код для обоих сред. А так кто нибудь использует новое определение и с использованием его кода в Дельфине будут проблемы.
>>И в чем же эта тупость проявляется?
>
>Ну, например, чтобы определить массив, нужно всегда точно знать количество элементов массива.
>Дали мне, например, таблицу кодов, которую мне надо "жестко" прописать в
>программе. Я пишу:
>.........
>пересчитывать или производить сложения и вычитания. Бред... В Си и других
>языках можно просто написать LocoCodeTable[] и редактировать массив как угодно.Нммм да...
Ну это тупость не Пакаля ;)
В том то и преимущество Паскаля, что все заранее нужно продумать и описать, а это приводит к более быстрому выходу работоспособного кода. Я думаю Вы не против поиздеваться над "быдлокодерством"? Так, вот, паскаль и воспитывает не "давить клаву", а думать :)
>В том то и преимущество Паскаля, что все заранее нужно продумать и описать, а это приводит к более быстрому выходу работоспособного кода.Чтобы написать работоспособный код, нужно все заранее продумать и описать _независимо_ от того, на каком языке вы пишете. И Паскаль тут особых преимуществ не предоставляет.
>Так, вот, паскаль и воспитывает не "давить клаву", а думать :)
Думать и тупо пересчитывать элементы массива - по-моему, не одно и то же :)
ещё в прошлый раз отвечали, что очень тупо и неправильно жестко забивать в код программы варьирующиеся данные
Каждый день захожу на opennet.ru, читаю новости, комментировать воздерживался, но сейчас уже не смог «промолчать»… Для начала всем, кто свято верить в то, что паскаль нужен только для обучения или он «тупой», советую ознакомиться хотя бы с этим http://pascal.sources.ru/articles/058.htm, там немного, осилите. Опять же, это касается самого языка и его развития в виде других языков: Модула-2, Модула-3, Оберон и так далее.
dq0s4y71 в своём посту ,не подозревая сам об этом очень точно дал определение процесса разработки ПО на территории бывшего СССР. Во-первых, это туча «компьютерщиков», в лучшем случае «программистов». Почему второе в кавычках читайте далее. Большинство из этой тучи работает в маленьких коллективах IT инфраструктуры , чаше даже являясь единственным представителем этой самой инфраструктуры. Если же человек несколько, то процесс чаще выглядит так: начальник(есть несколько человек в отделе, значит и начальник будет, дрюкать надо по цыпочке) дает задание, подчиненный выполняет. Всё вроде бы правильно, но только одно но! Во-первых, как дается задание: «Сделай так, что бы бухгалтерия мне больше не капала на мозги!», нет ни тех задания, а главное объективных критерий КАЧЕСТВА ПО. Этот программист просто «клепает» «аппендикс», «геморройчик» и т.д.(список этих слов продолжите сами). А теперь сакраментальный вопрос: что будет делать в таком случае этот «программист»? Клепать! А на чем? На том что, во-первых, он знает и, самое главное, на чем быстрее. Я опущу рассуждения о знаниях этого «программиста», что же касается языка программирования(точнее среды), то это будет скорее всего Access(да, он родимый), возможно Delphi, и наконец если он «гуру» то Builder C++. Не могу удержаться от цитирования таких «гуру»: «Я пишу на Си, в билдере можно сделать все! Там есть STL.» и так далее. Во-первых, 99.9% процента кода в билдере вместе с любимыми компонентами написаны на Delphi(да, для тек кто не в курсе объектный паскаль используемый в Delphi, также назвали языком Delphi)! А эти «гуру» вставляю этот 0.1% кода на С++(но не Си)! Теперь о STL, в основном это map, реже vector и то, только чтобы временно создать список простых типов. При этом строки из STL не используются, т.к в Delphi/Builder C++ есть свой тип строк AnsiString. На заметку «гуру», такую программу хр…н перенесёшь… ни то чтобы под другую платформу, компилятор не поменяешь даже под Win32. Так как работает этот «гуру»? А просто: метает как икру компоненты на форму, выставляет свойства в дизайне, в общем, творит очередной «шедевр». Да, я ведь так подробно остановился на «гуру», а еще есть просто перцы, которым достаточно Access! Из всего это может сложиться впечатление, что я такой умный ,а больше половины дураков, вовсе нет! Я хочу сказать ,что уровень результата очень низок! И в первую очередь из-за того ,что НЕ ПРЕДЯВЛЯЮТСЯ НИ КАКИХ ВМЕНЯЕМЫХ ТРЕБОВАНИЙ К ПО. А это в первую очередь из-за того, что начальники служб IT, даже не подозревают что эти требования есть…
Подытожу: расширяйте кругозор, для программиста программирование – это ремесло, и чем больше вы будете знать, тем меньше будет таких суждении «экспертов», про Паскаль, в частности.
Если программа выполняет возложенные на нее функции, то какая разница кем и как она сделана.
>Если программа выполняет возложенные на нее функции, то какая разница кем и
>как она сделана.В принципе да. Однако ее бывает нужно править и сопровождать. А иногда и переносить. И не всегда автору.
>http://pascal.sources.ru/articles/058.htmТам однако прямо не сказано, что Паскаль это в общем то Алгол и есть. А это избавляет от многих неясностей.
>касается самого языка и его развития в виде других языков: Модула-2, Модула-3, Оберон и так далее.
Ну несерьезно поминать эту экзотику. Имеет смысл обсуждать только Object Pascal.
>все! Там есть STL.»
http://gurin.tomsknet.ru/delphidecal.html
>Во-первых, 99.9% процента кода в билдере вместе с любимыми компонентами написаны на Delphi
Точнее использованы из Дельфина. Но при чем тут это, ясно что при желании объектные модули полученные из разных языков собрать не трудно.
>тек кто не в курсе объектный паскаль используемый в Delphi, также назвали языком Delphi
Нет не назвали. Это Object Pascal и есть.
>Нет не назвали. Это Object Pascal и есть.Using Delphi
Delphi is a high-level, compiled, strongly typed language that supports structured and object-oriented design. Based on Object Pascal, its benefits include easy-to-read code, quick compilation, and the use of multiple unit files for modular programming.
Это из справки DELPHI. Перевести, я надеюсь, не составит труда.
Так вот, Delphi - это язык, ОСНОВАННЫЙ на объектном Паскале, и он имеет имя собственное - DELPHI.
>Так вот, Delphi - это язык, ОСНОВАННЫЙ на объектном Паскале, и он имеет имя собственное - DELPHI.Каюсь виноват не успел за b[ маркетологами. А то все привык читать object pascal reference quide.
>Там однако прямо не сказано, что Паскаль это в общем то Алгол
>и есть. А это избавляет от многих неясностей.Расширяйте кругозор. Почитайте вики, ресурсов хватает....
>Ну несерьезно поминать эту экзотику. Имеет смысл обсуждать только Object Pascal.
На счет Object Pascal смотрите пост выше.
>http://gurin.tomsknet.ru/delphidecal.html
Вы по диагонали сообщение читали? Если так, то у Вас плохо получается. Там была прямая речь, причем не моя.
И то, что есть SDL на свете, многие знают, в том числе и я.>Точнее использованы из Дельфина. Но при чем тут это, ясно что при
>желании объектные модули полученные из разных языков собрать не трудно.
>Нет не назвали. Это Object Pascal и есть.И опять, про ЯЗЫК DELPHI, смотрите пост выше...
>Расширяйте кругозор. Почитайте вики, ресурсов хватает....Я учил и тот и другой, могу сравнить и так. А вы думаете Вирт не был детально знаком с Алголом? Ах да, тогда вики не было...
Но речь то не об этом, а о том что Модулы и Оберон не стали популярными, поэтому их нельзя считать успешным развитием языка (я кстати сам посмотрев Модулу пользовать ее не стал, ну не глянулась как-то). А oblect pascal можно (кстати, я что в Лазаре пишу на языке Дельфина получается?) .
>Вы по диагонали сообщение читали?
Естественно по диагонали. Понимаете, у вас много букв и эмоций, а разбивки на абзацы нет.
>И то, что есть SDL на свете, многие знают, в том числе и я.
Вот и сказали бы просто о том, что данный сишник заблуждается и аналог stl есть. А то цитируете необоснованную критику, и на нее не отвечаете. Хотя реально полезность stl/sdl на мой взгляд несколько завышена.
Кстати, кто нибудь знает работает ли sdl в Лазаре?
>Кстати, кто нибудь знает работает ли sdl в Лазаре?Нашел вот это (decal delphi container and algorythm library = sdl), но еще не попробовал
http://svn.freepascal.org/cgi-bin/viewvc.cgi/contrib/decal/?...
> Кто С++ не осилил?Программировал когда-то на Delphi 1, потом ушёл на C++. Не жалею, так как этот язык более лаконичный и гибкий. Из замеченных плюсов в сторону Delphi/Pascal хочу отметить читабельность кода. Имеется ввиду не написание слов begin/end (это не читабельность, а тупость), а наличие ключевых слов обозначающих процедуры и переменные. Согласен что это не лаконично, но если в тексте C++ программы перед каждым объявлением переменной вписать var, то просмотр старого или чужого кода ускорится в разы.
Из-за читабельности, я думаю, и Ада создавалась многословной до тупости. И чистый Си многие любят больше C++ из-за большей понятности кода ввиду меньшего количества сущностей и типов фиксированного размера. Хотелось бы конечно увидеть возможности C++ и Си в немного более читабельном варианте, то есть не доходя до многословности Паскаля - так сказать золотую середину.
>сторону Delphi/Pascal хочу отметить читабельность кода. Имеется ввиду не написание слов
>begin/end (это не читабельность, а тупость),Для читаемости лучше всего EndDo, EndIf... Впрочем это можно частично исправить (увы только для человека, а не для компилятора)
end; //do
end; //ifКстати кто считает что begin/end = {} советую глянуть сюда
int array[2][3]={{1,2,3},{4,5,6}};
>процедуры и переменные. Согласен что это не лаконично, но если в
>тексте C++ программы перед каждым объявлением переменной вписать var, то просмотр
>старого или чужого кода ускорится в разы.Cи создавался во времена когда у мейнфреймов было 64к памяти. Экономили каждый байт. Это одна из причин нечитаемости. Вторая причина это то что Си на 50% не язык высокого уровня. Ну а C++ и Жаба хотя и делались совсем в других условиях, но мозг их творцов уже был изувечен навсегда.
>И чистый Си многие любят больше C++ из-за большей понятности кода ввиду меньшего
>количества сущностей и типов фиксированного размера.Довольно странное сравнение вообще. Ну а типы у современного Си есть типа таких
Furthermore, an implementation may also define extended integer types such as int24_t or uint_least128_t.
>Хотелось бы конечно увидеть
>возможности C++ и Си в немного более читабельном варианте, то есть не
>доходя до многословности Паскаля - так сказать золотую середину.Спорю что вы не первый это говорите. Вот только примеров якобы ненужной многословности Паскаля кроме знаменитого begin-end за 50 лет никто привести толком не может. Вы кстати любопытства ради как нибудь замените begin-end на {} и почитайте стало ли понятнее.
Обратные примеры тоже есть, скажем switch многословнее чем case.
И на С можно писать более читаемо. Но ни один сишник никогда не согласится что
например if(i!=0) более читаемо чем if(i)...
>>И чистый Си многие любят больше C++ из-за большей понятности кода ввиду меньшего
>>количества сущностей и типов фиксированного размера.
>Довольно странное сравнение вообще.Фиксированный размер типов упомянут в связи с тем что часто в С++ приходится изобретать свой тип размером с байт, 2 байта и т.п. - средства языка дают только относительные типы и только они подсвечиваются... соответственно самодельный тип именуется кому как вздумается и чтобы понять написанный кем-то алгоритм или искать ошибки придётся выяснять что же за типы были использованы, какой размерности... Тогда как в коде Си такие типы узнаются с одного взгляда.
Увеличенное количество сущностей в С++ думаю пояснять особо не надо, но добавлю что имелось ввиду ещё и переопределение операций. В итоге небольшой кусок программы на С++ получается шифровкой и чтобы понять написанное придётся просмотреть не один дополнительный файл, а в Си вы чаще видите сразу известные типы и операции.
>Фиксированный размер типов упомянут в связи с тем что часто в С++
>приходится изобретать свой тип размером с байт, 2 байта и т.п.С и С++ не имеют встроенных типов размером с байт, 2 байта и т.п. Стандарт определяет только минимальную длину простых типов, а не реальную
The size of the arithmetic types varies across machines. By size, we mean the number of bits used to represent the type. The standard guarantees a minimum size for each of the arithmetic types, but it does not prevent compilers from using larger sizes. Indeed, almost all compilers use a larger size for int than is strictly required.
Поэтому в С99 сделали попытку определить тип фиксированной длины
intN_t An integer type whose width is exactly N bits
но он не обязателен к реализации, поэтому полагаться на его наличие нельзя.
>Увеличенное количество сущностей в С++ думаю пояснять особо не надо, но добавлю
>что имелось ввиду ещё и переопределение операций. В итоге небольшой кусок
>программы на С++ получается шифровкой и чтобы понять написанное придётся просмотреть
>не один дополнительный файл, а в Си вы чаще видите сразу
>известные типы и операции.Именно переопределение операций в принципе позволяет повысит читаемость программы. Например +/-/* для 3D векторов.
Но как можно сравнивать объектный и необъектный языки?
Большинство языков имеют право на жизнь. "Если звезды зажигают, значит это кому-нибудь нужно?"
Будьте терпимее друг к другу, а уж к инструментам разработки и подавно)
Geany -- хорошая среда разработки, может работать с компилятором free pascal.
Спасибо за подсказку, не плохой редактор, но до среды разработки на паскале, Lazarus, ему очень далеко.
А если по делу - вот хочу я скомилить приложение под айфон. имею в наличии машину под винду. в качестве таргета я айфон выбрать не могу. косячок-с, сводящий на нет всю возможную дискуссию про качество айдеЕ...
Не занимался вопросами кросс-компиляции, но если чего-то лично для вас не хватает в IDE, то пишите в баг-трекер http://bugs.freepascal.org и это появится (особенно если это все-лишь цель для компилятора).
всё просто делается!
нужно собрать Apple-овский as и ld под винду (т.е. .exe файлы, которые будут собирать macho arm бинарики). исходники и as и ld здесь: opensource.apple.comпосле этого, с XCode необходимо взять библиотеки (iPhoneSDKs)
вот и всё ;) FPC легко подцепляет и as и ld. делов-то!
то что нужно для Jailbreak разработки! хотя Jailbreak отлично из под мака работают. хакинтош... хакинтош...
>> Есть какие-нибудь фронт-енды для freepascal?
Screenshots: http://wiki.lazarus.freepascal.org/Screenshots
А вот нахрена полностью повторять интефрейс делфи? ИМХО там таки убогий и неудобный редактор кода.
>А вот нахрена полностью повторять интефрейс делфи? ИМХО там таки убогий и
>неудобный редактор кода.Интерфейс делфи это Lazarus :) Но он совсем даже не убогий и многие его любят гораздо больше чем всякие визуал студии и монодевелоперы.
>>А вот нахрена полностью повторять интефрейс делфи? ИМХО там таки убогий и
>>неудобный редактор кода.
>
>Интерфейс делфи это Lazarus :) Но он совсем даже не убогий и
>многие его любят гораздо больше чем всякие визуал студии и монодевелоперы.
>А мне QT Creator нравится :)
>А мне QT Creator нравится :)Пробовал недавно - не сравнить с редактором Lazarus. Последний в разы удобнее. Сейчас работаю в Delphi 2009 и чувствую, что по крайней мере редактором кода, Лазарус уже догнал, а может и перегнал Delphi.
>>> Есть какие-нибудь фронт-енды для freepascal?Чего то здесь про MSE IDE забыли.
http://wiki.freepascal.org/MSEide_&_MSEgui
А между прочим уже довольна-таки зрелая штука, и многие уже ею пользуються.. Жаль только что под Mac пока нету.