C++ Builder XE Starter — это хороший способ начать быструю визуальную разработку Windows-приложений с готовыми компонентами.
C++ Builder XE Starter — это урезанная версия Professional и предназначена для частных лиц.
Итак, воспользовавшись акцией и получив на свой e-mail письмо с моим бесплатным ключом на “C++ Builder 10.1 Berlin Starter”, я запустил “голую” Windows 7 x32 в VirtualBox и приступил к установке.
Образ установочного диска RAD Studio 10.1 Berlin одинаковый для всех редакций, поэтому его и будем использовать, предварительно загрузив из официального сайта.
Процесс установки практически не отличается от установки других редакций. В самом начале инсталлятор запрашивает ключ и по нему он определяет, что доступно к установке.
Также инсталлятор предлагает сразу установить “Microsoft Windows 10 SDK”, устанавливаем и его.
Полный процесс установки у меня занял всего несколько минут.
На моём жёстком диске “C++ Builder 10.1 Berlin Starter” занял 3,5 Гб.
Далее запускаем “C++ Builder 10.1 Berlin Starter” и он стартует мгновенно. Первым делом иду в меню Help > License Manager и вижу, что лицензия бессрочная только для платформы Windows и разрешено коммерческое использование в соответствии с лицензионным соглашением.
А теперь посмотрим непосредственно на “C++ Builder 10.1 Berlin Starter”.
Starter Edition не имеет многих возможностей более старших редакций.
Основные ограничительные моменты:
— компилятор только для Windows x32;
— нет исходного кода RTL и VCL;
— нет рефакторинга;
— нет Symbol Insight;
— нет Code и Class Completion;
— нет Code Formatter;
— нет Class Explorer;
— нет Resource Manager;
— нет утилит командной строки;
— заблокирован вызов компилятора командной строки;
— обрезанный отладчик;
— GetIt в урезанном варианте (многие компоненты отсутствуют);
— нет возможности установить CodeSite Express через GetIt;
— нет FireDAC;
— нет DataSnap;
— нет IoT;
— нет Beacon;
— нет LiveBinding.
Что нам доступно:
— VCL и FMX, но только для Windows x32;
— компоненты AppTethering;
— отладка приложения;
— стандартные компоненты;
— и другое.
Более подробно о том, что доступно в Starter-редакции, можно ознакомиться на официальном сайте по этим ссылкам:
» https://www.embarcadero.com/docs/Delphi-Feature-Matrix.pdf
» https://www.embarcadero.com/ru/products/delphi/starter
Официальный FAQ по вопросам Starter-редакции:
https://www.embarcadero.com/ru/products/delphi/starter-faq
Хочу отметить, что Starter-редакция существенно ограничена и предназначена для выполнения узкого круга задач, для разработки только windows-приложений с урезанным набором компонентов, но она хорошо подойдёт для некоторых программистов и её вполне хватит для выполнения определённых работ.
Я думаю, что стоит воспользоваться акцией и получить бессрочный ключ бесплатно.
Желаю всем отличного настроения и удачи!
UPDATE:
Друзья, я высказал свое мнение о возможностях Starter-редакции как факт. Каждый сам принимает для себя решение, подходит ему этот инструмент в этой редакции или не очень, не затрачивая на его изучение много времени. Ведь Starter в обычное время можно только купить, а триала Starter-редакции — нет. И программистам приходилось ориентироваться только на Feature Matrix, не попробовав продукт руками.
Комментарии (119)
TargetSan
11.08.2016 12:13+11Стоп-стоп-стоп. Т.е. это starter edition который обычно платный, и только сейчас бесплатный по акции. Т.е. это продукт, уступающий по всем параметрам Visual C++ Express (который бесплатный), ещё и за деньги? Кто это купит?
Diaskhan
11.08.2016 13:29Блин как же они достали уже, Теперь каждый год будут штамповать, Лучше бы веб сервер запили бы, ORM и нормальный шаблонизатор !!
Не пойму на что они надеется !!
yarosroman
11.08.2016 13:30+1В Express(в нескольких последних точно) версиях нет возможности работать с С++. Сравнивать стоит с Community версией. В Express версиях тоже много чего нельзя делать, нет расширений, рефакторинга, но возможности разработки не обрезаны.
Kobalt_x
11.08.2016 20:28В Community есть C++, дополнения и рефакторинг. Community это кажется Professional, но для opensource разработчиков.
withkittens
12.08.2016 23:48Community для:
— индивидуальных разработчиков;
— обучения, научных исследований, open-source проектов;
— использования в non-enterprise (< 250 компов и < миллиона долларов годового дохода) макс. пятью разработчиками.
grossws
15.08.2016 13:17Что-то вы смешали всё в кучу.
IDEA Ultimate бесплатна для open source с устоявшимся community, для студентов/преподавателей и применения в учебных заведениях для обучения. В каждом из этих случаев своя лицензия, везде требования non-commercial.
IDEA Community — под Apache License v2.0 и не содержит ограничений на область применения, количество разработчиков и т. п.
withkittens
16.08.2016 03:23Там выше в ветке речь шла о Visual Studio :)
А может и про Embarcadero, и я действительно перепутал.grossws
16.08.2016 03:25Извините, перепутал с другим тредом про IDEA. Возражения снимаю, политикой лицензирования VS не интересовался.
DrPass
11.08.2016 12:26+13— нет рефакторинга;
— нет Symbol Insight;
— нет Code и Class Completion;
— нет Code Formatter;
— нет Class Explorer;
— нет Resource Manager;
Я только одного не могу понять, зачем они ещё и редактор кода не отключили.
maydjin
11.08.2016 13:11+8Полезных ископаемых нет. Воды нет. Растительности нет. Населена роботами.
Стоит как студия-про, если не по акции, даже вроде подороже. Был уверен что сии платформы уже давно загнулись (delphi и builder) до прочтения этой рекламки.
nitrocaster
11.08.2016 14:22+4Хорошая попытка, Borland, но нет.
bentall
11.08.2016 15:22+3Да. Если бы они раздавали это на постоянной основе, какой-то шанс привлечь молодых разработчиков у них, возможно, и был бы.
А так — попытки продовать (после окончания акции, послезавтра, он ведь станет платным, да) откровенный «пробник» мало пригодный для настоящеей разработки, похоже на классический пример патологической жадности.
К примеру, вспоминая свой опыт с Delphi — в исходники VCL смотрел куда чаще, чем в доку по этому фреймворку. Это уж не говоря, что win32 — почти мёртвая платформа, повсеместно (кроме нетбуков с атомами, годе действительно 32-bit) теснимая 64-разрядными системами.SeeR
11.08.2016 21:20+2Однако, должен заметить, что количество 32-битных приложений все еще больше чем 64-битных.
Indemsys
11.08.2016 16:34-3Отличная новость.
Только не понял что такое IoT.
Имеется в виду то что из GetIt качается или компоненты стандартной палитры включая TBluetoothLE?
Когда делал в свое время выбор между Visual Studio и RAD Studio, то выбрал RAD Studio.
Delphi и открывается быстрее и компилирует считай мгновенно по сравнению с Visual.
Пока в Visual сделаешь одну итерацию в Delphi можно сделать две-три.
yarosroman
11.08.2016 17:59+3А вы RAD Studio купили?
bgBrother
11.08.2016 18:16+1Если я не ошибаюсь, Embarcadero бесплатно раздает 30-ти дневные версии своих продуктов. Вполне возможно, что человек это использовал.
quverty
11.08.2016 17:01Тоже поставил в VirtualBox, в частности, чтобы поэкспериментировать с их 3D приложениями. Надеюсь они там не обрезаны где-нибудь в существенной части у этой версии?
AGrynCo
11.08.2016 23:15-1Самая нормальная версия Delphi — это Delphi 7, дальше пошел порожняк… Хорошие были времена…
Error1024
12.08.2016 00:06+1Вам ведь не нужен юникод, дженерики, хелперы, новые модули в rtl, отложенная загрузка dll, улучшения VCL…
alexkran
12.08.2016 00:20Ага, так наулучшали VCL, что он переодически начал сам себя ломать. Спасибо, не надо.
Из ваших перечисленных плюсов вижу только: юникод(хотя тоже спорно довольно), отложенна загрузка dll, новыем модули rtl.
Ибо как минимум дженерики это такое себе для Delphi удовольствие.
Я конечно не могу судить по всем фронтам, но после 7 версии Delphi, самой стабильной и крутой версии(имхо), все остальные релизы дельфей не особо кажутся продуктивными. Можно еще отметить Delphi 10, просто как какое-то новое дыхание, но не более. И я лично предпочел бы юзать Delphi 7 и не видеть ломающую саму себя VCL, непонятные баги компиляции, несовместимость с сторонними библиотеками.Error1024
12.08.2016 00:27Delphi XE8, 10 Seattle — работает отлично, намного стабильнее ранних XE.
Да, дженерики в Delphi не супер, далеко не супер, но лучше чем их полное отсутсвие.
Что не очень хорошо это .net куски IDE для рефакторинга, но их наконец-то хотят убрать.
В целом для меня Delphi 10 Seattle отличный релиз и лучше Delphi 7, хотя безусловно Delphi 7 отличная IDE.alexkran
12.08.2016 01:27Seattle поломал мне 5 проектов. Просто так, по фану. Даже в тех вещах где он в принципе не должен ломаться, а ломается то внутри. Плюс, как я уже говорил ранее — писали с командой проект, написали — компайл, ошибка. Просто с плохого настроения начал просто так злясь тыкать постоянно скомпилировать — через 7-8 раз компиляция успешна и больше не летела, это легально вообще в продукции за кучу
баб...денег столько глупых вещей. Переодически Сиэтл отказывался открывать только что созданные им проекты, порой просто непонятно от чего не работал редактор форм, при этом работали все его тулзы и наоборот. И да, самое шикарное,- я так и не нашел как адекватно заставить работать автокомплит методов из ComObj и как его же адекватно дебажить. Если ранним версиям такое было простительно, то сейчас это уже немного непозволительно, не находите? Может я конечно чего-то не знаю, поправьте, если что-то не так.
Про XE8 не могу ничего сказать, не работал, но слышал, что там все довольно хорошо.
Единственное, что меня и правдо порадовало в XE — андроид разработка. Неплохо иметь из коробки
Честно? В Delphi по мне так они вообще не нужны. Язык не про это, в его задачах почти нет нигде вещей, чтобы юзать дженерики, это максимум для галочки. Delphi выбирают люди, для быстрой наклепки GUI приложений, логики с привязкой БД, ибо слишком легко уж с ними в дельфях.
Давно не видел людей, которым этот язык просто нравится, с точки зрения самого языка и его возможностей, и они предпочтут даже сложный софт писать на Дельфях, чем на более удобном инструменте.
Про .net куски я согласен полностью, пора бы давно уже.Error1024
12.08.2016 01:40-1Seattle поломал мне 5 проектов. Просто так, по фану.
Возможно проблемы в ваших проектах, а не в IDE? Кончено, если переезжать с Delphi 7, то поломки практически гарантированы, лет то много прошло уже.
А по поводу того что работает нестабильно, не открывает свои же проекты — вполне возможно что с вашей установленной Delphi что-то не так, я подобного поведения не замечал, и не видел жалоб.
Честно? В Delphi по мне так они вообще не нужны. Язык не про это, в его задачах почти нет нигде вещей, чтобы юзать дженерики, это максимум для галочки. Delphi выбирают люди, для быстрой наклепки GUI приложений, логики с привязкой БД, ибо слишком легко уж с ними в дельфях.
Нет, новые возможности нужны, один только расширенный RTTI чего стоит, для справки — в плюсах никакого RTTI все ещё не завезли.
Давно не видел людей, которым этот язык просто нравится, с точки зрения самого языка и его возможностей, и они предпочтут даже сложный софт писать на Дельфях, чем на более удобном инструменте.
Например яalexkran
12.08.2016 12:09+1Я говорю именно о проектах, которые при это только созданы были, недели не прошло он сам по себе отказывался открывать.
>> в плюсах никакого RTTI все ещё не завезли.
В С++ RTTI не завезли? Вы похоже с C++ не знакомы, либо знакомы минимально, там RTTI заведено еще со стандарта 98.
>>Например я
Ну, и удобно вам работать с языком в котором ООП кривое(имхо, из-за всего одной вещи при реализации полиморфизма как минимум), очень большие куски кода не читабельны, где сложная логика реализуется через костыли? Спасибо, тогда я уж лучше создам себе кучу других проблем, но буду писать на C++/D/Java.
Дельфи не подходит для задач, для которых он не создавался.Error1024
12.08.2016 13:30-2Я говорю именно о проектах, которые при это только созданы были, недели не прошло он сам по себе отказывался открывать.
Впервые вижу такую жалобу — скорее всего действительно проблемы в конкретно вашей установке.
В С++ RTTI не завезли? Вы похоже с C++ не знакомы, либо знакомы минимально, там RTTI заведено еще со стандарта 98.
Ага, именно поэтому много людей упрашивали наконец добавить его в новый стандарт, но сново были проигнорированны. Покажите мне этот RTTI.
Ну, и удобно вам работать с языком в котором ООП кривое(имхо, из-за всего одной вещи при реализации полиморфизма как минимум), очень большие куски кода не читабельны, где сложная логика реализуется через костыли? Спасибо, тогда я уж лучше создам себе кучу других проблем, но буду писать на C++/D/Java.
Дельфи не подходит для задач, для которых он не создавался.
И что же с ооп в Delphi не так?
Из реальных проблем разве что некоторые багофичи интерфейсов.
А вообще пишите на C++/D/Java, кто вам мешает то?alexkran
12.08.2016 14:00+2>>Покажите мне этот RTTI.
Заходим в гугл: RTTI C++ — Вам выдаст любой источник про typeid вместе с typeinfo.h и dynamic_cast<>. Вопросы?
>>И что же с ооп в Delphi не так?
Всего одна деталька — inherited. Покажите мне хоть один адекватный язык, где это необходимо делать так же.
>>А вообще пишите на C++/D/Java, кто вам мешает то?
Мне то как раз никто не мешает, и структура кода получается чище.Error1024
12.08.2016 14:14-1Заходим в гугл: RTTI C++ — Вам выдаст любой источник про typeid вместе с typeinfo.h и dynamic_cast<>. Вопросы?
Это не полноценное RTTI это ущербное подмножество, которое называть RTTI нельзя. Ах да, его ещё в опциях компилятора включить надо.
Если это полноценное RTTI, то зачем Qt своя реализация?:)
на деталька — inherited. Покажите мне хоть один адекватный язык, где это необходимо делать так же.
А что с Inherited не так?alexkran
12.08.2016 14:18+2>>Это не полноценное RTTI это ущербное подмножество, которое называть RTTI нельзя.
Да? И чем же оно ущербное интересно Вас послушать.
>>Ах да, его ещё в опциях компилятора включить надо.
Не знаю в каких вы дербрях лазите, у меня все из коробки работает и работало всегда.
В Qt много чего реализаций своего. Те же самые QString, QArray и подобное. Зачем? спросите у разработчиков.
>>А что с Inherited не так?
А вы счиатете при наследовании вручную вызывать конструктор/деструктор базового класса это нормально?Error1024
12.08.2016 14:25-2А вы счиатете при наследовании вручную вызывать конструктор/деструктор базового класса это нормально?
У меня это не вызывает неудобств. А вы каждый день по 100500 раз пишете новые классы и Inherited в конструкторах?
Неужели это и есть главная кривость ооп в Delphi?
Да? И чем же оно ущербное интересно Вас послушать.
Сериализацию формочек как в Delphi, попробуйте сделать на этом «RTTI»))
В Qt много чего реализаций своего. Те же самые QString, QArray и подобное. Зачем? спросите у разработчиков.
Затем, что в C++ нет нормальных, стандартных строк из коробкиalexkran
12.08.2016 14:35>>У меня это не вызывает неудобств. А вы каждый день по 100500 раз пишете новые классы и Inherited в конструкторах?
>>Неужели это и есть главная кривость ооп в Delphi?
Для меня — это косяк. Да, я люблю писать много классов и разделять функционал, если я вижу ему отдельное место в классе. Чем это плохо?
И да, в других языках это делается по умолчанию, но в Delphi решили сделать иначе.
Да, в C++ в этом плане необходим виртуальный деструктор вместо обычного, однако если вы юзаете умные указатели можно про это забыть.
>>Сериализацию формочек как в Delphi, попробуйте сделать на этом «RTTI»))
Кстати, неплохая идея. Надо пописать как-то на недельке. Вы слишком неодооцениваете возможности С++, его, как вы называете убогое RTTI и возможности метопрограммирования.
>>Затем, что в C++ нет нормальных, стандартных строк из коробки
std::string чем Вам не нравится? Для меня это вполне такие же адекватные строки. Да, это не string в дельфях и даже не в D/C#/Java, где они удобнее гораздо. Но это строки. Вполне себе.Error1024
12.08.2016 14:46-2Для меня — это косяк. Да, я люблю писать много классов и разделять функционал, если я вижу ему отдельное место в классе. Чем это плохо?
И да, в других языках это делается по умолчанию, но в Delphi решили сделать иначе.
Да, в C++ в этом плане необходим виртуальный деструктор вместо обычного, однако если вы юзаете умные указатели можно про это забыть.
Я не могу сказать что это даже проблема реализации, не то что фатальный недостаток ооп.
Итог: не доказали кривость ооп в Delphi.
Кстати, неплохая идея. Надо пописать как-то на недельке. Вы слишком неодооцениваете возможности С++, его, как вы называете убогое RTTI и возможности метопрограммирования.
Дерзайте, вы это лет через 10 реализуете если RTTI наконец станет частью стандарта C++. А возможно и не станет — тогда никогда.
И это если вам кларификации хватит на реализацию(Сомневаюсь).
std::string чем Вам не нравится? Для меня это вполне такие же адекватные строки. Да, это не string в дельфях и даже не в D/C#/Java, где они удобнее гораздо. Но это строки. Вполне себе.
Пока юникод не начнёшь использовать эти строки ещё куда не шло, хотя и «пахнут». Не зря же всякие wxWigets/Qt свои строки имеют.
А строки в Delphi — самые крутые из тех что видел.alexkran
12.08.2016 14:55>>Я не могу сказать что это даже проблема реализации, не то что фатальный недостаток ооп.
>>Итог: не доказали кривость ооп в Delphi.
Для меня — то, что я перечислил есть кривость. Это очень не удобно, если вы имеете большой косяк классов.
>>Дерзайте, вы это лет через 10 реализуете если RTTI наконец станет частью стандарта C++. А возможно и не станет — тогда никогда.
Считайте, как хотите. В C++ RTTI есть, пусть даже и малое в реализации. Мне его возможностей хватает.
>>Пока юникод не начнёшь использовать эти строки ещё куда не шло, хотя и «пахнут».
std::wstring — пожалуйста. проблем то.
Строки в Delphi удобные, не отрицаю, хотя что удобнее именно в плане строк из тех языков, что я пробовал, так и не выяснил.Error1024
12.08.2016 15:02-2Для меня — то, что я перечислил есть кривость. Это очень не удобно, если вы имеете большой косяк классов.
«Не удобно» <> кривость ооп.
Считайте, как хотите. В C++ RTTI есть, пусть даже и малое в реализации. Мне его возможностей хватает.
Вы признаете что в C++ нельзя реализовать сериализатор формочек как в Delphi?
qw1
14.08.2016 12:30+1«Не удобно» <> кривость ооп.
Формально, это нарушение инкапсуляции (класс-наследник решает, освободить ли ресурсы предка, вызывая inherited в деструкторе. Фактически — мелкая ошибка проектирования, с которой можно жить, научившись до автоматизма её обходить.
Вы признаете что в C++ нельзя реализовать сериализатор формочек как в Delphi?
Вы и сами понимаете, что поддержка dfm форм встроена в язык, IDE и runtime-классы. Поэтому довольно глупо требовать от другого языка, что он будет лучше конкурента в тех костылях, которыми конкурент напичкан по самое нехочу. Если дельфи так хорош в сериализации форм, то, может он легко прочитает формы BAML (бинарный XAML от платформы WPF, сериализованный в ресурсы)?
Если убрать привязку к формату, сишные фреймовки с поддержкой годонераторов (как Qt Creator) вполне себе могут всё, что может VCL, реализуя всякие published своими условностями в своей иерархии классов, и без RTTI.
Если говорить о хорошем RTTI, всё равно delphi далеко до reflection уровня C#. Например как любой дельфи класс перегнать в json (возьмём delphi 7, т.к. позднее в студиях XE для этой конкретной задачи встроили какие-то костыли).Error1024
14.08.2016 14:14-2Формально, это нарушение инкапсуляции (класс-наследник решает, освободить ли ресурсы предка, вызывая inherited в деструкторе. Фактически — мелкая ошибка проектирования, с которой можно жить, научившись до автоматизма её обходить.
Мелкая ошибка — это явно не фатальная кривость ооп, из-за которой стоит менять язык, как считат комментатор сверху, в C++ нарушений чистоты ооп тоже предостаточно.
Кроме того Inherited в конструкторах/деструкторах бывает полезен, а именно возможность вызывать конструктор/деструктор в предка в любой момент, а не в начале/конце.
Вы и сами понимаете, что поддержка dfm форм встроена в язык, IDE и runtime-классы. Поэтому довольно глупо требовать от другого языка, что он будет лучше конкурента в тех костылях, которыми конкурент напичкан по самое нехочу. Если дельфи так хорош в сериализации форм, то, может он легко прочитает формы BAML (бинарный XAML от платформы WPF, сериализованный в ресурсы)?
Нет сериализация классов — встроена в язык, рантайм. Dfm формат это заслуга одного из классов RTL. Вы можете хоть в JSON сериализлвать формы, написав немного кода.
Если убрать привязку к формату, сишные фреймовки с поддержкой годонераторов (как Qt Creator) вполне себе могут всё, что может VCL, реализуя всякие published своими условностями в своей иерархии классов, и без RTTI.
C++ не может сериализлвать классы, костыли типа кодогенераторов Qt это читерство, которое впрочем действительно годиться только для формочек. В то время как RTTI в Delphi встроен в язык и использовать можно в любых целях.
Если говорить о хорошем RTTI, всё равно delphi далеко до reflection уровня C#. Например как любой дельфи класс перегнать в json (возьмём delphi 7, т.к. позднее в студиях XE для этой конкретной задачи встроили какие-то костыли).
Во первых речь была о C++, а не C#, в котором есть полноценный RTTI.
Во вторых в Delphi 7 можно написать класс сериализующий любой класс с published полями в JSON. А зачем брать древнюю Delphi 7, когда есть XE с ещё более крутым RTTI?
А что за костыли встроили то?
Итог: все осталось как было в C++ нет RTTI, хвали, не хвали, защищай, не защищай, нет и все тут.qw1
14.08.2016 14:44+2И ещё
Ах да, его ещё в опциях компилятора включить надо.
$M+, разве не также?
А что за костыли встроили то?
Несколько классов для json в RTL, TJSONMarshal/TJSONUnMarshal, хотя может их можно было самому написать, без поддержки компилятора.
C++ не может сериализлвать классы, костыли типа кодогенераторов Qt это читерство, которое впрочем действительно годиться только для формочек. В то время как RTTI в Delphi встроен в язык и использовать можно в любых целях.
А я считаю, published это читерство ))
Впрочем, это можно накостылить в C++ макросом, добавил в класс строчки
PUBLISHED( myFieldName );
для каждого поля, видимого извне. И через шаблонную магию сделать всё это строго типизированным, в отличии от, где данные гоняются через тип Variant.Error1024
14.08.2016 22:11-1Несколько классов для json в RTL, TJSONMarshal/TJSONUnMarshal, хотя может их можно было самому написать, без поддержки компилятора.
Почему костыли? Обычные классы стандартной библиотеки, использующие стандартные возможности RTTI, никто не мешает самому написать подобные.
А я считаю, published это читерство ))
Это стандартная возможность языка, уж точно не является читерством.
Впрочем, это можно накостылить в C++ макросом, добавил в класс строчки
PUBLISHED( myFieldName );
для каждого поля, видимого извне. И через шаблонную магию сделать всё это строго типизированным, в отличии от, где данные гоняются через тип Variant.
Все верно это будет костылем имитирующем RTTI. Работать будет не для всех классов, а только для классов обёрнутых данным костылем, в работе такого сериализатора будет довольно много «но», ограничений и возможных багов. RTTI полезен не только для сериализаторов, и возможность в Delphi узнать почти все про любой класс позволяет делать много крутых штук, описанный же вами костыль не добавит RTTI во все классы.
Кроме того, в коде с данным костылем разобраться сможет нормально и сразу только автор.
Нет в C++ RTTI, хоть убейся, смотрел с надеждой подробности нового стандарта, добавили в стандарт кучу библиотечной всячины, но не добавили RTTI, которое уже давно просят сделать.qw1
14.08.2016 22:25+2Ну так в дельфи RTTI работает только для published свойств. В чужие классы, не меняя их исходников, через RTTI не влезть. В поля, которые не замаплены на свойства, не влезть. Метод по имени не вызвать. Поэтому мало разницы с накостыленным макросом в C++.
Error1024
14.08.2016 22:48-1С версии Delphi 2010 RTTI позволяет все это делать.
А костыль — он и есть костыль, даже при возможности получить информацию о published полях произвольного класса можно было бы сделать полноценную сериализацию.
Zapped
17.08.2016 13:44+1Всего одна деталька — inherited. Покажите мне хоть один адекватный язык, где это необходимо делать так же.
>>А что с Inherited не так?
А вы считаете при наследовании вручную вызывать конструктор/деструктор базового класса это нормально?
Ruby достаточно адекватный для Вас язык?
$ cat test.rb
class A def initialize puts 'Class A init' end end class B < A def initialize puts 'Class B init' end end class C < A def initialize puts 'Class C init' super end end [A, B, C].each do |klass| klass.new end
$ ruby test.rb Class A init Class B init Class C init Class A init
Или дело всё-таки в вызове inherited только в деструкторе (да, в Ruby нет деструкторов)?
DrPass
12.08.2016 09:45> Seattle поломал мне 5 проектов. Просто так, по фану
Это уже как повезет. Уже лет 15 прошло, а я до сих пор помню свою боль и страдания, когда Delphi 6 унесла с собой в могилу полпроекта с диска, включая несколько дней работы. Правда, с тех пор я приобрел полезную привычку коммититься после каждой мелкой доработки.
MrShoor
12.08.2016 02:46+1Из ваших перечисленных плюсов вижу только: юникод(хотя тоже спорно довольно), отложенна загрузка dll, новыем модули rtl.
Юникод — не спорно, потому что при интенсивной работе с текстом через WideString в делфи 7 вся производительность улетала в трубу на постоянных копированиях этих самых WideString и реаллокациях.
Отложенная загрузка dll — вот без неё как раз можно было жить. Хедер пишется один раз и все.
Ибо как минимум дженерики это такое себе для Delphi удовольствие.
А вот дженерики — реально крутая штука, потому что во многом развязывают руки. Вспомните лучше как например те же хеш таблицы раньше реализовывались. Ключ поинтер -> значение поинтер. Мало того, что это тянуло лишние аллокации, имело оверхед по памяти, так еще было не безопасно и не удобно. Рефакторить такой код — вообще грустно, один тайпкаст пропустил, и упало в рантайме у пользователя.
но после 7 версии Delphi, самой стабильной и крутой
Ох, вот не надо про стабильность. На больших проектах оно все разваливалось так же, как и с современными делфями.
И я лично предпочел бы юзать Delphi 7 и не видеть ломающую саму себя VCL
Как насчет такой баги например в VCL: https://habrahabr.ru/post/217189/
Вы предпочли бы оставаться с ней? Или использовать пофикшеную версию? Баги в VCL были и в 7 версии. Часть из них была закрыта в новых версиях, но так же появились новые. Мне например сложно сказать лучше или хуже стал VCL по багам.
непонятные баги компиляции
В принципе такие баги связаны только с новыми языковыми возможностями. Ровно так же, как было, когда в делфи появились динамические массивы (по моему в 5 версии...), сыро, но потом многое поправили.
За себя могу сказать точно, я бы не предпочел использовать Delphi 7 точно. Тем более когда помимо D10 есть еще Lazarus+FPC (который кстати уже достаточно крут, и на пятки наступает современным делфи, а в чем то даже обгоняет).Error1024
12.08.2016 13:49-3Зачем? alexkran ноющему о кривом ооп в дельфи не нужна такая мелочь как юникод :)
alexkran
12.08.2016 14:04+1>>Зачем? alexkran ноющему о кривом ооп в дельфи не нужна такая мелочь как юникод :)
Начнем с того, что никто не ноет. Высказывать свое мнение наверное уже запрещено законом.
Продолжим тем, что никто не говорил, что юникод не нужен, сказать, что это такое себе, не есть сказать то, что это не нужно вовсе.
alexkran
12.08.2016 13:51>>За себя могу сказать точно, я бы не предпочел использовать Delphi 7 точно
За себя могу сказать, что вообще бы не предпочел использование Delphi вовсе.
Вместо Lazarus я бы предпочел CodeTyphon, хорошая штука.
>>В принципе такие баги связаны только с новыми языковыми возможностями.
Знаете, тут это конечно аргументированно, но когда мне он ругался на обыкновенное «не возможно присвоить integer в integer» напрашивается вопрос, это как вообще возможно? При этом потом ничего не меняя это запускается, через какое-то кол-во итераций компиляции с запуском.
>>Как насчет такой баги например в VCL:
>>Вы предпочли бы оставаться с ней? Или использовать пофикшеную версию?
Я бы предпочел не использовать VCL вовсе. Но если бы потребовалось, я бы смотрел отталкиваясь от того, что мне нужно реализовать. В новой версии VCL я переодически не мог очистить ранее динамический созданный контрол, что очень подбешивало и приходилось выкручиваться костылями.
Про то, что лучше или хуже по багам, я соглашусь, сказать сложно.
>>А вот дженерики — реально крутая штука, потому что во многом развязывают руки.
Понимаете, они и правда во многом в языке не нужны. Я еще никогда не встречал задачу в которой захотел бы юзануть что-то по типу дженериков в Delphi. Почти в любом другом языке с которым сталкивался было подобное, но не в Delphi, ну не вижу я им применения в этом языке, потому что он не про это совсем, и делался без расчета на подобные возможности.Error1024
12.08.2016 14:03Вместо Lazarus я бы предпочел CodeTyphon, хорошая штука.
CodeTyphon это сборка Lazarus.
Знаете, тут это конечно аргументированно, но когда мне он ругался на обыкновенное «не возможно присвоить integer в integer» напрашивается вопрос, это как вообще возможно? При этом потом ничего не меняя это запускается, через какое-то кол-во итераций компиляции с запуском.
Окей, возможно вы наткнулись на баг компилятора, это случается редко и обходиться. Приведите конкретный пример пожалуйста.
Кроме того это происходит с разными компиляторами, разных языков, а не только с Delphi.
Я бы предпочел не использовать VCL вовсе. Но если бы потребовалось, я бы смотрел отталкиваясь от того, что мне нужно реализовать. В новой версии VCL я переодически не мог очистить ранее динамический созданный контрол, что очень подбешивало и приходилось выкручиваться костылями.
Про то, что лучше или хуже по багам, я соглашусь, сказать сложно.
Приведите пример того, что вы не могли очистить в одной из версий?
Понимаете, они и правда во многом в языке не нужны. Я еще никогда не встречал задачу в которой захотел бы юзануть что-то по типу дженериков в Delphi. Почти в любом другом языке с которым сталкивался было подобное, но не в Delphi, ну не вижу я им применения в этом языке, потому что он не про это совсем, и делался без расчета на подобные возможности.
Они не нужны конкретно вам, возможно вы не умеете ими пользоваться.
В Java/C#/Delphi дженерики не были заложены при проектировании, но были добавлены, и как не странно они очень похожи в этих языках.alexkran
12.08.2016 14:14-2>>Окей, возможно вы наткнулись на баг компилятора, это случается редко и обходиться. Приведите конкретный пример пожалуйста.
Воспроизвести чтобы, не приведу, ибо я сам от этого как-то отделался и потом лишь периодично решал. Если хотите тупо взглянуть на код, одна лишь строчка в новом методе: iColumn := 0; и здесь компилятор грохался на такое. Не отрицаю, что так бывает со многими компиляторами и языками, но я с С++ сижу долгое довольно время и за это время такого получил меньше в 2 раза чем с Delphi за 1.5-2 года.
>>Приведите пример того, что вы не могли очистить в одной из версий?
Это была холодная весна. Учебная практика помню. Дали просто задание на отвалите напиши тестовик, с неограниченным кол-вом вариантов вопросов/ответов, гистограммами результатов, распределением информации в Word/Excel. С последним проблем не было, изи залетело. Реализация первого тоже была легка, оставалась кнопка не помню уже чего, но она созадавалась самой последней, и при ее очистке я получал ошибку, точно не помню чего, может даже бы сейчас воспроизвел, но не под виндой нахожусь.
>>Они не нужны конкретно вам, возможно вы не умеете ими пользоваться.
>>В Java/C#/Delphi дженерики не были заложены при проектировании, но были добавлены, и как не странно они очень похожи в этих языках.
Но-но, не мешайте понятия. Что в Java, что в C# дженерики чаще всего используют для задания каких-то определенных архитектурных решений, и задачи у этих языков чуть-чуть отличаются.Error1024
12.08.2016 14:33Воспроизвести чтобы, не приведу, ибо я сам от этого как-то отделался и потом лишь периодично решал. Если хотите тупо взглянуть на код, одна лишь строчка в новом методе: iColumn := 0; и здесь компилятор грохался на такое. Не отрицаю, что так бывает со многими компиляторами и языками, но я с С++ сижу долгое довольно время и за это время такого получил меньше в 2 раза чем с Delphi за 1.5-2 года.
По вашим словам количество багов компилятора не отличается даже на порядок — это очень несущественное различие.
Если хотите тупо взглянуть на код, одна лишь строчка в новом методе: iColumn := 0; и здесь компилятор грохался на такое.
И какого же типа iColumn, что компилятор грохался от присваивания?
Это была холодная весна. Учебная практика помню. Дали просто задание на отвалите напиши тестовик, с неограниченным кол-вом вариантов вопросов/ответов, гистограммами результатов, распределением информации в Word/Excel. С последним проблем не было, изи залетело. Реализация первого тоже была легка, оставалась кнопка не помню уже чего, но она созадавалась самой последней, и при ее очистке я получал ошибку, точно не помню чего, может даже бы сейчас воспроизвел, но не под виндой нахожусь.
Вы не смогли разобраться в собственном говнокоде и обвинили во всем «глючную» Delphi/VCL.
Но-но, не мешайте понятия. Что в Java, что в C# дженерики чаще всего используют для задания каких-то определенных архитектурных решений, и задачи у этих языков чуть-чуть отличаются.
Возможности у дженериков в языках примерно одинаковые, и во всех трёх языках могут использоваться в том числе для определённых архитектурных решений.alexkran
12.08.2016 14:46-1>>По вашим словам количество багов компилятора не отличается даже на порядок — это очень несущественное различие.
Может. Но когда горят сроки и такая херь вылазит не очень есть круто.
>>И какого же типа iColumn, что компилятор грохался от присваивания?
Это был обычный integer, как следует из префикса i.
>>Вы не смогли разобраться в собственном говнокоде.
Обоснуйте. Вы не видели кода, во-первых. Во-вторых, где в строчке подобной SomeButton.Free говнокод? я просто решил почистить ресурсы, это происходит, и после выхода из процедуры очистки что-то внутри самого VCL дает сбой. Это мой говнокод называется? Вы уже начинаете не объективно мыслить.
>>Возможности у дженериков в языках примерно одинаковые, и во всех трёх языках могут использоваться в том числе для определённых архитектурных решений.
Устал спорить на эту тему с Вами. Вы мне говорите, что примерно одинаковые, область применения похожа, но тогда почему эту фишку используют малое кол-во людей? Я вижу Вас одного, кто правда это активно, наверное, юзает, за большое кол-во людей, кодящих на Delphi.Error1024
12.08.2016 14:55Это был обычный integer, как следует из префикса i.
Вы явно что-то не так делали, или вам крупно «повезло».
Обоснуйте. Вы не видели кода, во-первых. Во-вторых, где в строчке подобной SomeButton.Free говнокод? я просто решил почистить ресурсы, это происходит, и после выхода из процедуры очистки что-то внутри самого VCL дает сбой. Это мой говнокод называется? Вы уже начинаете не объективно мыслить.
Я сделал выводы на основе ваших суждений, вы студент который не смог разобраться с Delphi/VCL, психанул и стал изучать что-то другое, модное, молодежное.
Устал спорить на эту тему с Вами. Вы мне говорите, что примерно одинаковые, область применения похожа, но тогда почему эту фишку используют малое кол-во людей? Я вижу Вас одного, кто правда это активно, наверное, юзает, за большое кол-во людей, кодящих на Delphi.
Дженерики активно юзает множество программистов на Delphi, если есть возможность использовать современные версии. Кроме того они активно используются в RTL, FMX.alexkran
12.08.2016 15:01>>Вы явно что-то не так делали, или вам крупно «повезло».
Это не отрицаю, порой бывают слишком глупые ошибки в программе, которые уже не на уровне кода.
>>Я сделал выводы на основе ваших суждений, вы студент который не смог разобраться с Delphi/VCL, психанул и стал изучать что-то другое, модное, молодежное.
Не сочтите за понты или что-то подобное, но с VCL и Delphi я смог разобраться еще в 14 лет, это самое легкое для освоения, что я тогда попробовал. Вернувшись намного позже к этому всему и поимев опыт в написании уже не в учебных, а реальных рабочих процессов, разочаровался в технологии. Слишком много доставило проблем это все.
>>Дженерики активно юзает множество программистов на Delphi, если есть возможность использовать современные версии.
Ну, пока я кроме Вас не видел никого.Error1024
12.08.2016 15:12-2Не сочтите за понты или что-то подобное, но с VCL и Delphi я смог разобраться еще в 14 лет, это самое легкое для освоения, что я тогда попробовал. Вернувшись намного позже к этому всему и поимев опыт в написании уже не в учебных, а реальных рабочих процессов, разочаровался в технологии. Слишком много доставило проблем
Вы написали про практику в вузе, сомневаюсь что это можно назвать рабочим процессом. Кроме того вам вероятно мог достаться в наследство лютый говнокод, в котором Delphi\Vcl нет вины.
Ну, пока я кроме Вас не видел никого.
Из этого можно сделать что вы совершенно не в теме современной Delphi разработки, как и ваше окружение.
MrShoor
12.08.2016 22:03+2В новой версии VCL я переодически не мог очистить ранее динамический созданный контрол, что очень подбешивало и приходилось выкручиваться костылями.
Ох, сдается мне вы просто имеете мало опыта с делфи.
Я еще никогда не встречал задачу в которой захотел бы юзануть что-то по типу дженериков в Delphi.
Повезло вам. А вот у меня задачи постоянно такие. Любой контейнер лучше сделать с дженериком. А он в свою очередь тянет дженерик итераторы, дженерик компараторы. А почему вы считаете, что в C++ шаблоны нужны, а в Delphi дженерики не нужны? В чем принципиальная разница?alexkran
13.08.2016 13:50>>Ох, сдается мне вы просто имеете мало опыта с делфи.
По сравнению с C++ да, довольно мало. Но тут же были постоянные баги, когда в одном месте код работает, перенесли идентичный кусок кода моему товарищу — не работает.
>>А почему вы считаете, что в C++ шаблоны нужны, а в Delphi дженерики не нужны?
>>В чем принципиальная разница?
На template`ах C++ можно написать все что угодно, неограниченность в возможностях, на них можно реализовать все, что угодно, и это будет типонезависимо, это самое мощное метапрограммирование, которое вообще где либо присутствует. Я сильно не сидел над дженериками в Delphi, но как понял, что на них по сути только и удобно как вы заметили:
>>Любой контейнер лучше сделать с дженериком.
Ну сделали раз контейнер и на этом всё? В целом, может конечно я не вижу именно в Delphi этому применения, но по моему это на раз юзануть, либо сделать один раз что-то по типу большого модуля с нужными возможностями и забыть, что такое дженерики в принципе. Плюс, как я понял, они имеют такие же ограничения как и в C#, добавляет накладное время на компиляцию.
В целом: рассматривать этот вопрос с позиции template'ы C++ = generics Delphi неверно. У них может было одинаковое значение при создании, но при этом в C++ из-за низкоуровневости некоторых языковых конструкций они получились очень и очень мощным средством языка.Error1024
13.08.2016 16:23+1По сравнению с C++ да, довольно мало. Но тут же были постоянные баги, когда в одном месте код работает, перенесли идентичный кусок кода моему товарищу — не работает.
Это следствие отсутствия опыта\говнокода\криворукости.
И в целом это C++ напротив имеет дурную славу плохой переносимости изза всяких нестандартных расширений компиляторов. Откройте любой крупный C++ проект и найдите тонны
и подобного.#ifdef WIN32 #define Int32 int #endif
В Delphi\Object Pascal такого практически нет.
Плюс, как я понял, они имеют такие же ограничения как и в C#, добавляет накладное время на компиляцию.
Ну и бред вы пишите! Во первых это шаблонны C++ известны своей долгой компиляцией, во вторых дженерики в C# «компилируются» уже в рантайме, в отличие от Delphi где как и в C++ во время компиляции.
Ну сделали раз контейнер и на этом всё? В целом, может конечно я не вижу именно в Delphi этому применения, но по моему это на раз юзануть, либо сделать один раз что-то по типу большого модуля с нужными возможностями и забыть, что такое дженерики в принципе. Плюс, как я понял, они имеют такие же ограничения как и в C#, добавляет накладное время на компиляцию.
Вы уверяли что дженерики в Delphi не нужны в отличие от C# и Java, сейчас вы признали что у них возможности подобны => они точно также нужны. Уж определитесь.
Дженерики активно используются в RTL и FMX, разработчики их тоже используют, и не только для контейнеров. Если вам не позволяет узость мышления увидеть в дженериках смысл, не только для контейнеров, то не распространяйте пожалуйста это на всех.
Кроме того раз вы не смогли с однокурсниками разобраться в Delphi нормально, то не имеете никакого права судить о чем либо касаемо «кривого ооп», «ненужных дженериков» и прочего.
Итог: вы очередной обиженный школьник/студент/говнокодер, который не смог нормально разобраться в языке, а смог лишь обвинить во всем «кривой» Delphi :)alexkran
13.08.2016 22:57+3>>И в целом это C++ напротив имеет дурную славу плохой переносимости изза всяких нестандартных расширений компиляторов. Откройте любой крупный C++ проект и найдите тонны
>>В Delphi\Object Pascal такого практически нет.
Если присмотреться в серьезной разработке это в Delphi не нужно вовсе, просто потому, что большинство приложений банально НЕ ПИШУТСЯ под другие платформы и/или используют другие компиляторы. Если кроссплатформа — fpc, стандартно. Windows — тут думаю все ясно.
>>Ну и бред вы пишите! Во первых это шаблонны C++ известны своей долгой компиляцией, во вторых дженерики в C# «компилируются» уже в рантайме, в отличие от Delphi где как и в C++ во время компиляции.
Шаблоны С++ не компилируются до их использования.
>> вы очередной обиженный школьник/студент/говнокодер, который не смог нормально разобраться в языке, а смог лишь обвинить во всем «кривой» Delphi :)
Это уже оскорбление, я считаю, попридержите язык.
Начнем с того, что я Дельфи НЕ ТРОГАЛ ВООБЩЕ изначально. Речь шла о кривости Embarcadero и ненужности фич, либо вы что-то не понимаете, либо гнете свою линию укланаясь от темы разговоров.Error1024
13.08.2016 23:52-2Если присмотреться в серьезной разработке это в Delphi не нужно вовсе, просто потому, что большинство приложений банально НЕ ПИШУТСЯ под другие платформы и/или используют другие компиляторы. Если кроссплатформа — fpc, стандартно. Windows — тут думаю все ясно.
Под Delphi\Object Pascal я как-раз имел связку Delphi-FreePascal
Шаблоны С++ не компилируются до их использования.
Я имею ввиду то, что в C# в отличии от Delphi и C++ дженерики/шаблоны «компилируются» под конкретный тип в рантайме. А то что в C++ шаблонны очень тормозят компиляцию вы и сами знаете.
Это уже оскорбление, я считаю, попридержите язык.
Это вполне адекватная реакция за обвинения на язык\IDE от человека который не разобрался в возможностях языка\IDE.
Начнем с того, что я Дельфи НЕ ТРОГАЛ ВООБЩЕ изначально. Речь шла о кривости Embarcadero и ненужности фич, либо вы что-то не понимаете, либо гнете свою линию укланаясь от темы разговоров.
А это что тогда:
Ну, и удобно вам работать с языком в котором ООП кривое(имхо, из-за всего одной вещи при реализации полиморфизма как минимум), очень большие куски кода не читабельны, где сложная логика реализуется через костыли? Спасибо, тогда я уж лучше создам себе кучу других проблем, но буду писать на C++/D/Java.
Дельфи не подходит для задач, для которых он не создавался.
Кроме того, от вас прозвучали неоднократные утверждения в ненужности новых возможностей языка, таких как дженерики.
А от темы уклоняетесь вы, игнорируя вопросы адресованные вам.alexkran
14.08.2016 00:40>>Я имею ввиду то, что в C# в отличии от Delphi и C++ дженерики/шаблоны «компилируются» под конкретный тип в рантайме. А то что в C++ шаблонны очень тормозят компиляцию вы и сами знаете.
Тогда конкретно в этой ситуации я Вас не понял.
>>Это вполне адекватная реакция за обвинения на язык\IDE от человека который не разобрался в возможностях языка\IDE.
Не совсем. Если Вы считаете, что в довольно культурном споре нужно отдаляться от деталей и судить человека по его личностным качествам и его опыте, то как минимум Вы поступаете не как человек большого ума.
Вы не можете утверждать, в чем я разобрался, в чем нет, банально не зная человека нельзя судить о нем.
>> А это что тогда:
Ну, и удобно вам работать с языком в котором ООП кривое(имхо, из-за всего одной вещи при реализации полиморфизма как минимум), очень большие куски кода не читабельны, где сложная логика реализуется через костыли? Спасибо, тогда я уж лучше создам себе кучу других проблем, но буду писать на C++/D/Java.
Дельфи не подходит для задач, для которых он не создавался.
Кроме того, от вас прозвучали неоднократные утверждения в ненужности новых возможностей языка, таких как дженерики. <<
Это началось после Вашего же комментария:
>>Например я.
Я не говорил о том или сём в языке, я высказал мнение, что именно мне не нравится. Я язык не трогал изначально вообще. Речь шла о Embarcadero, их продукции.
Да, я тронул возможность языка, без которой, имхо, язык прекрасно обходился. Высказал мнение, что это не надо, аргументировав почему. Я пошел с Вами спорить и доказывать свою ТЗ только из-за Вашего же упрямства и желания отстоять это.
>>Кроме того, от вас прозвучали неоднократные утверждения в ненужности новых возможностей языка, таких как дженерики.
>>А от темы уклоняетесь вы, игнорируя вопросы адресованные вам.
Я ни от чего не уклоняюсь, я говорю как это вижу. Игнорирую я лишь то, в чем считаю спорить бесполезно. Мы имеем разный уровень знаний в разных языках и технологиях, и глупо отвечать на то, в чем Вы сами можете быть не уверены. Проще промолчать и закрыть вопрос, чем спорить и оба будем выглядеть как полные идиоты.
P.S. Видится продолжения этого спора бессмысленным.Error1024
14.08.2016 01:12-2Я не говорил о том или сём в языке, я высказал мнение, что именно мне не нравится. Я язык не трогал изначально вообще. Речь шла о Embarcadero, их продукции.
Тем не менее вы скатились к этому.
Я ни от чего не уклоняюсь, я говорю как это вижу. Игнорирую я лишь то, в чем считаю спорить бесполезно. Мы имеем разный уровень знаний в разных языках и технологиях, и глупо отвечать на то, в чем Вы сами можете быть не уверены. Проще промолчать и закрыть вопрос, чем спорить и оба будем выглядеть как полные идиоты.
Я с самого начала просил привести реальные примеры глюков Delphi\Rad Studio, вы же говорили лишь о не удаляемых кнопках, и прочих багах, но не одного конкретного примера не привели, это сложно назвать объективностью с вашей стороны. Потом вы признали что не разбираетесь в Delphi достаточно, чтобы спорить о глюках\недостатках.
А на неудобных вопросах, таких как RTTI в C++, вы просто слились.
Не совсем. Если Вы считаете, что в довольно культурном споре нужно отдаляться от деталей и судить человека по его личностным качествам и его опыте, то как минимум Вы поступаете не как человек большого ума.
Вы не можете утверждать, в чем я разобрался, в чем нет, банально не зная человека нельзя судить о нем.
По вашим суждениям видно какой у вас «богатый» опыт в Delphi, и как много вы знаете чтобы спорить на эти темы:
Это была холодная весна. Учебная практика помню. Дали просто задание на отвалите напиши тестовик, с неограниченным кол-вом вариантов вопросов/ответов, гистограммами результатов, распределением информации в Word/Excel. С последним проблем не было, изи залетело. Реализация первого тоже была легка, оставалась кнопка не помню уже чего, но она созадавалась самой последней, и при ее очистке я получал ошибку, точно не помню чего, может даже бы сейчас воспроизвел, но не под виндой нахожусь.
В новой версии VCL я переодически не мог очистить ранее динамический созданный контрол, что очень подбешивало и приходилось выкручиваться костылями.
По сравнению с C++ да, довольно мало. Но тут же были постоянные баги, когда в одном месте код работает, перенесли идентичный кусок кода моему товарищу — не работает.
Ну сделали раз контейнер и на этом всё? В целом, может конечно я не вижу именно в Delphi этому применения, но по моему это на раз юзануть, либо сделать один раз что-то по типу большого модуля с нужными возможностями и забыть, что такое дженерики в принципе. Плюс, как я понял, они имеют такие же ограничения как и в C#, добавляет накладное время на компиляцию.
alexkran
14.08.2016 01:31>>Я с самого начала просил привести реальные примеры глюков Delphi\Rad Studio, вы же говорили лишь о не удаляемых кнопках, и прочих багах, но не одного конкретного примера не привели, это сложно назвать объективностью с вашей стороны. Потом вы признали что не разбираетесь в Delphi достаточно, чтобы спорить о глюках\недостатках.
Несёте чушь. Кто Вам говорил, что эти глюки/баги, которые я привел в пример связаны с языком? Я говорил про баги связанные с может VCL, может самим компилятором, может линкером, леший его знает в такие дебри я не лез. При чем тут сам язык?
Недостатки я вижу, я писал много кода и на разных языках, я Вам сказал, что мне именно в Дельфи не нравится. Опыта как минимум для того, чтобы сравнивать удобство — хватает вполне. Если Вам не нравится что-то расскажите же.
>>А на неудобных вопросах, таких как RTTI в C++, вы просто слились.
Может так. Предпочту не отвечать на вопрос, где какая-то хз какая сериализация форм в Дельфи, которую нельзя реализовать на C++. Вы же судите не объективно, не зная возможностей C++ и утверждая, что реализация на этом языке невозможна. На С++ возможно все.Error1024
14.08.2016 02:08-3Несёте чушь. Кто Вам говорил, что эти глюки/баги, которые я привел в пример связаны с языком? Я говорил про баги связанные с может VCL, может самим компилятором, может линкером, леший его знает в такие дебри я не лез. При чем тут сам язык?
Недостатки я вижу, я писал много кода и на разных языках, я Вам сказал, что мне именно в Дельфи не нравится. Опыта как минимум для того, чтобы сравнивать удобство — хватает вполне. Если Вам не нравится что-то расскажите же.
Я же не просто так написал «Delphi\Rad Studio» — вы писали и про IDE, и про Delphi, и про VCL. Сейчас же вы отказываетесь от своих слов.
В Delphi вы не имеете достаточно опыта, раз считаете что плюсы дженериков ограничиваются контейнерами.
Да и ваши знания ооп весьма посредственны если для вас фатальная кривость ооп это необходимость писать Inherited в конструкторах\деструкторах.
Может так. Предпочту не отвечать на вопрос, где какая-то хз какая сериализация форм в Дельфи, которую нельзя реализовать на C++.
Ну правильно, сказали что реализуете на неделе (как же это по школьному звучит), а затем слились, делая вид что не говорили этого:
Я:
Сериализацию формочек как в Delphi, попробуйте сделать на этом «RTTI»))
Вы:
Кстати, неплохая идея. Надо пописать как-то на недельке. Вы слишком неодооцениваете возможности С++, его, как вы называете убогое RTTI и возможности метопрограммирования.
Вы же судите не объективно, не зная возможностей C++ и утверждая, что реализация на этом языке невозможна. На С++ возможно все.
Я как-раз в курсе возможностей C++ и невозможности реализовать полноценную сериализацию формочек\классов\…
Ну так что насчет сериализации формочек?)))
MrShoor
14.08.2016 00:19+1На template`ах C++ можно написать все что угодно
Можно, но не нужно. Иначе это темплейты головного мозга, которые приводят к тому, что код неоправданно долго компилируется, и его слишком сложно поддерживать.
Я сильно не сидел над дженериками в Delphi, но как понял, что на них по сути только и удобно как вы заметили:
В делфи роль дженериков ровно такая же, как в C#. Писать класс, который умеет работать с любым типом. В С++ же на темплейтах начинается магия. Откройте реализацию Dictionary на C#, и реализацию std::unordered_map на C++. Да на С++ рехнуться можно от такой реализации, в C# же все понятно.
Вот скажите, какой метод разрешения коллизий используется в std::unordered_map? В Dictionary в C# например это open addressing через linear probing. А в std::unordered_map на С++? И покажите мне код, где это видно. Сможете?
Плюс, как я понял, они имеют такие же ограничения как и в C#, добавляет накладное время на компиляцию.
Время компиляции вообще не аргумент, потому что даже с дженериками делфи компилирует в десятки раз быстрее С++. Но это только благодаря синтаксической простоте языка.lemelisk
14.08.2016 14:19+2Вот скажите, какой метод разрешения коллизий используется в std::unordered_map?
В C++ все элементы с одинаковым хешом хранятся в односвязном списке. Подобная реализация фактически задается самим стандартом, т.к. он определяет интерфейс для работы с bucket'ами (наборы элементов с одинаковым хешом), а также требует, чтоб при вставке/удалении ссылки на элементы не инвалидировались (т.е. не менялся адрес местоположения элементов в памяти).MrShoor
14.08.2016 19:32Эх, не вам я вопрос задавал. Тем не менее по исходному коду реализации std::unordered_map понять это горааааздо сложнее, чем по исходному коду Dictionary в C#.
zedxxx
11.08.2016 23:16А что это, собственно, за АКЦИЯ? Можно ссылку на неё?
DenisVasilyev
11.08.2016 23:31Бесплатный ключ на C++ Builder 10.1 Berlin Starter (акция до 12.08.2016)
https://allsoft.ru/offers/c-builder-berlin-so-skidkoy/
alexkran
11.08.2016 23:16+1Почитав, ужаснулся.
Их продукт и так порой не позволяет продуктивно работать, обладая при этом явными минусами, так еще и это выпустили. Embarcadero делая такую грязь разорятся. Проще, чем использовать их продукты, либо юзать Lazarus/CodeTyphon для Delphi, а для C++ что-то из множества других продуктов, как Qt, WX, Gtk, etc. и то продуктивней получается.Error1024
12.08.2016 00:19-1Акция скорее всего ориентирована на студентов и школьников.
Студенту, только входящему в мир C++, Starter edition вполне подходит, кроме того еб*и(простите не удержался) для начинающего будет намного меньше чем в Visual Studio, в студии с одними только типами проектов и визардами новички путаются, а чего стоят для новичка precompiled headers.
Пересадка на C++Builder решала проблему — люди начинали изучать C++, а не проблемы Visual Studio. Сейчас же студент/школьник может скачать билдер полностью легально.alexkran
12.08.2016 00:38+2Честно? Мне жалко новичков начинающих с C++ Builder, потому что любой новичок имеет мало опыта в плане разработки. Когда человек садится на VCL и формы после изучения самого языка начинается быдлокод, чаще всего. Новички не разделяют логику, лепя по +100500 вещей на одну кнопку, логику, которая бы удостоилась бы 2 отдельных модулей.
Проблема C++ Builder, что как раз-таки с ним учиться становится легче только на первых порах, потом он упирается в куски реализаций и свой же не поддерживаемый код. У меня есть даже живой пример таких людей.
Плюс, порой продукция Embarcadero делает невозможное: не компилится 10 раз и после абсолютно никаких изменений — раз и закомпилилось. Магия?
А вообще, по моему мнению, студенту изучаещему C++ надо садиться хорошего редактора вместе с GCC/MinGW(в зависимости от системы) и Make, так познается больше, имхо, а дальше уже выбирать осознано, зная как работать со структурой кода и etc.Error1024
12.08.2016 00:50Ну вот сложно новичку понять Make файлы, компиляторы командной строки и прочее, тут же — сел, написал и запустил одной кнопкой, при ошибке получил более-менее внятную ошибку, а курсор подсветил её место, а не портянку текста в консоли.
По поводу интерфейса — а для плюсов ничего так и нет подходящего новичкам:
Qt это не совсем C++, WinApi сложен, wxWigets тоже.
Я лично видел когда студенты не начинали писать говнокод, нет, они просто входили в депрессию, ничего не писали из-за сложности настройки IDE, проекта и прочего. Посадка на C++Builder давала людям хоть какую-то возможность писать, и некоторые выкарабкивались после.
Сомневаюсь что начал бы программировать в очень раннем возрасте, если бы у меня, вместо понятного, хоть и с кучей недостатков ZX-Spectrum Basic, была бы Visual Studio на PC с тонной визардов и подобного.alexkran
12.08.2016 01:10+1Это понятно, ошибки это наверное одно из ключевых моментов в освоении, однако к примеру многие используют тот же Python и никто на это не жалуется. Но консоль + make — дает наиболее полное понимание того, что ты делаешь, и что тебе потребуется в дальнейшем. Я вот в обратном направлении шел и жалею, что много упустил сначала. Сейчас cmake мой друг(каким раньше был обычный Make, пока боялся брать что-то новое), и это позволяет делать мои проекты продуктивнее.
Qt это С++, хоть и со своими плюшками, но очень удобно в использовании.
WinAPI это тоже не С++, на секундочку. Писался он на С и в стиле С.
В wxWidgets я видел сложность только в начальной настройке, хотя тут вы правы, это оттолкнуло.
Можно сказать, что тонна визардов и тд, но в наше время с этим разобраться на раз-два, ибо в наше время есть видео туториалы и для новичка, если он не хочет заморачиваться с остальным — ему показали как делать — делай. Даже уже в книгах лет пять точно такое практикуют. С этим уже проблем у новичков быть не будет.
А если брать совсем без наворочек для обучения — Code::Blocks. Для новичка там самое оно, размеры, скорость, ошибки. При желании расширяем и учим ее финтоплюшки — уже полноценная IDE для повседневной работы с обширными возможностями. Сам с неё начинал, бросил в определенный момент и ушел на Visual Studio.
P.S. оффтоп — новичкам не всегда в нашем мире надо бы учить C++. Хоть и самый любимый язык, но есть уже вещи для новичков в разработке и обучении поудобнее.Error1024
12.08.2016 01:27-1Я лишь написал то что сам видел :)
Тоже считаю C++ плохим выбором для новичка, но многие преподаватели/программы обучения думают иначе.
И при данных условиях ничего проще для вхождения чем C++Builder просто нет.
Ах да, после Qt люди тоже иногда скатываются, пихая кишки Qt где стоит и где нет, отрисовывая прямоугольник на соответствующей процедурой, а создавая виджет «прямоугольник», где это только к тормозам приводит.
Оффтоп:
Make файлы, компилятор командной строки при возможности использовать полноценную IDE, с нормальным отладчиком, а не огрызоком в виде GDB — это личные предпочтения и нравится далеко не всем.alexkran
12.08.2016 01:33Это да. Программу образования не сломаешь, как и убеждения некоторых преподавателей.
Если делать графические приложения да, не буду спорить. Однако для обучения просто языку все равно весь C++ Builder тащить, который совсем не лёгкий, что по размерам, что по потребляемым ресурсам, тащить по мне так не очень.
А про консоль и GDB.
Порой проще писать код, который не требует отладки, это конечно мечты, но если правильно сделать базовую логику проекта и сделать ее правильно, имхо, даже на C++ отладчик не всегда понадобится, а то и не понадобиться вовсе. Я лично после того как пересел на связку VS Code как редактор + cmake + gcc пока еще вообще отладчик не нужен был вовсе.
И да, GDB обидно назвать огрызком, даже из под консоли он очень даже ничего, если под рукой нет IDE или охота познать детальки:)Error1024
12.08.2016 01:45-1Я не говорю что консоль плоха — нет — но она на любителя :)
Да GDB хорош как консольный инструмент, но при сравнении даже с довольно топорными отладчиками в IDE — проигрывает :/
А про тяжесть C++Builder — Starter как-раз очень лёгок, в разы легче Visual Studio и меньше засирает систему.yarosroman
12.08.2016 02:59Ну теперь MS все поменяли, в новой VS 15, будет ставиться только то, что вы сами захотели. Как пример, preview, где пока есть только плюсы, занимает всего 700 метров.
HabrDev
12.08.2016 06:37-1Есть ещё С++/CLI. Это тоже не совсем C++, но он позволяет использовать WinForms, которая является довольно таки простой платформой для создания приложений с GUI.
alexkran
12.08.2016 12:12Ну, C++/CLI то есть, но это такое себе удовольствие. Это уже более не C++, чем тот же Qt, и теряет в скорости + не кроссплатформенно. А так, чтобы что-то склепать и не заморачиваться как вариант.
Error1024
12.08.2016 13:36Ну уж нет, тянуть за собой .net для формочек?, да и в целом C++/CLI какой-то обрезок без сообщества своего.
yarosroman
12.08.2016 18:01зачем его тянуть? я больше чем уверен, что он уже установлен у большинства, учитывая что он через автообновление доставляется
Error1024
12.08.2016 20:32Нужной версии? В принципе ничего хорошего от смеси native и managed кода в одном приложении не может получиться.
IvanhoeLab
12.08.2016 12:23До сих пору веду древний проект на Builder 5. Гигантская программа по обработке данных с прибора.
Причина применения BCB5 — за короткий срок надо было вывести на рынок большую мнгогоязычную программу с кучей фич. VCL значительно ускоряет разработку, когда одному программисту ставят «немыслимые» задачи.
Не горю желанием переползать на Embarcadero. Они выпускают новую версию, не заделав дыры в старой.
К слову, пользуюсь также VC2013, Qt.
Но новичкам все же советую присмотреться к VCL. Потом попробовать MFC. Ощутить его горький вкус после VCL. )
И уже решить где ваш личный путь.
DarkEld3r
12.08.2016 12:48Но новичкам все же советую присмотреться к VCL. Потом попробовать MFC.
А зачем пробовать устаревший MFC? Почему не Qt, где многое сделано удобно и "современно".
IvanhoeLab
12.08.2016 13:13-1Соглашусь. Qt меня восхищает. Насколько грамотно продумана иерархия классов. И на каждый случай есть свой класс.
Но вот либы в дистрибе таскать накладно. Жду не дождусь когда Qt-libs будут входить в поставку с Windows.alexkran
12.08.2016 13:22-1>> Жду не дождусь когда Qt-libs будут входить в поставку с Windows.
Эх, было бы идеально:)
Можно либы и не таскать, но заморачиваться со статической линковкой не всегда хочется, к сожалению.
OYTIS
12.08.2016 13:25Что-то на хабре в последнее время: Delphi, Lazarus, C++ Builder. Какая-то новая мода на девяностые?
Error1024
12.08.2016 13:46Открываем TIOBE Index, видим что Delphi более популярна чем новомодные Rust/Swift/Go/R/D… Думаем.
OYTIS
12.08.2016 14:08Насколько я понимаю, TIOBE считают долю сток кода в общем корпусе. То есть, на Паскаль играет большое количество legacy-кода и многословность (ну и большое количество автоматически генерируемого кода). Если посмотреть на рейтинг IEEE, составленный, очевидно, по другим признакам, то Delphi там как раз над Фортраном (и после Раста).
Error1024
12.08.2016 14:19TIOBE не считает строки кода вовсе. И считаться одним из самых объективных рейтингов.Кроме того, стрелочки показывают падение/взлёт языка, как видите популярность растёт, что было бы странно для only-legacy языка.
OYTIS
12.08.2016 15:06А да, меня смутила аннотация к индексу. В описании они пишут, что ориентируются на поисковые запросы, что очень странно, потому что особого хайпа вокруг Дельфи на других сайтах я не замечаю.
Интересно было бы выяснить, где же Делфи реально используется. То есть, в России я представяю себе, где, а вообще.
alan008
12.08.2016 15:20В России, Бразилии и Китае Delphi довольно активно используется. В десктопных Windows-приложениях в основном.
OYTIS
12.08.2016 16:46+1Вот последняя информация, что я нашел. Как ни странно, в первой пятерке вполне себе первый мир. Интересно, где все эти люди прячутся.
UPD:
ссылка, вставить по-человечески интерфейс не дает: http://community.embarcadero.com/blogs/entry/where-in-the-world-are-programmers-using-delphi
MrShoor
12.08.2016 22:13+3что особого хайпа вокруг Дельфи на других сайтах я не замечаю.
Пишем на хабре про делфи -> рейтинг растет -> постим картинку с выросшим рейтингом в комменты -> profit.
Diaskhan
12.08.2016 18:02Господа прежде чем хаять Delphi и же с ним, Напишите сначала банковскую систему на нем!!!
Абс Colvir Используется во всем СНГ, причем не первый год. Колвир написан на Дельфи!
И кстати Skype уже переписали на C# ???
DarkEld3r
12.08.2016 18:12-1И кстати Skype уже переписали на C# ???
Скайп изначально не был написан только на Delphi. Под каждую платформу свой язык и фреймворк. Как сейчас — понятия не имею.
Колвир написан на Дельфи!
И что это доказывает?
Diaskhan
12.08.2016 18:16Доказывает хотя бы то что, где в банках используется Колвир, программисты пишут на дельфи.
А в народном банке казахстана как раз таки используется колвир (самый древний банк 2 уровня)
Интересно какая система используется в СБЕРЕDarkEld3r
12.08.2016 18:39+2Это всё хорошо, но никак не говорит о качестве языка или этой системы. Просто переход может быть слишком дорогим и не приносить очевидной выгодно. Не так ли?
В целом я не агитирую за или против Delphi, просто хочу сказать, что такие аргументы никак не характеризуют язык.
Diaskhan
12.08.2016 18:42Да я тоже не аггитирую, но считаю что язык или платформа создаются чтобы закрыть дыру. Как например Гоу который был создан по канонам С++, И конкурентности чтобы по максимуму использовать аппаратные средства, и экономить на серверах в ГУГЛЕ. Хотя просто писать на с++ гугловцы задолбались.
stoune
12.08.2016 19:00+3А в Штатах Cobol в банкинге продолжают исспользовать вовсю.Возможно тогда нам стоит начать писать на кобол.
Ваш колвир написан на Делфи наверное потому что были недорогие разработчики которые ничего другого не знали. Делфи очень плохой язык для описания предметной области банкинга и почти никакой как язык универсального предназначения по сравнению с современными альтернативами.
Основной причиной расспространения продуктов Борланд на територии екс-Совка было пиратство и обучение Паскалю/Делфи на первых курсах в ВУЗах(опять же из-за пиратства). Сейчас экономического смысла в продуктах embarcadero ноль, если только вы не застряли в поддержке уже написаного кода вроде вашего колвира.Diaskhan
12.08.2016 19:03Поймите в то время был VB, Mfc,fox pro, и это было не очень… То время а не наше....
stoune
12.08.2016 19:03+1Ксати ваш колвир судя по описанию от Delphi избавляется http://www.colvir.com/ru/solutions/
бэк офис разработан с использованием смарт клиента (кросс-платформенная QT-технология / Python / Delphi).
yarosroman
Вот только зачем оно нужно? Нет тех фич, которые рекламирует производитель. Без community edition, скоро это никому не нужно будет, и не надо говорить о том, что у производителя это основной хлеб.