Комментарии 95
Самое поганое, что даже недостаточно просто заменить string на ansistring, pchar на pAnsiChar. Старая строка была по сути byte string, и при операциях не учитывалась кодировка.
Кроме того, WinApi везде в новых дельфях по умолчанию используется в W варианте, тоже много переделок. RTL вся только под WideString. Отсюда — постоянные преобразования от однобайтного к двухбайтному представлению и обратно — потеря производительности. Просто тупо удвоенный расход памяти, учитывая, что все строки — ASCII и второй байт всегда будет равен нулю.
И нет бы сделать как в FPC, чтобы можно было выбрать Ansi-only вариант или Unicode, так нет, просто порвали совместимость.
Я тупо менял sting на AnsiString, pchar на PAnsiChar и т.д., ну и ручками доковыривал
Это-то не проблема, и утилиты для этого есть. Но этого мало.
Представьте, что у вас весь код — ASCII, и вам надо кинуть исключение, а оно в новой RTL только Unicode — нужны либо явные приведения, а это нечитаемо, либо неявные, а это лишние warning'и, подавлять которые некомильфо.
Вся работа с TStringList'ами, с WinAPI переписывается. В общем, веселье еще то.
Проблема с быстродействием не стояла, потому как компьютеры со времён Delphi 6-7 ушли далеко вперёд.
Сравнение-то не компьютера времен 6-7 и сегодняшнего дня. А сегодняшнего дня с 7кой и сегодняшнего дня с 10.
Там, где много приведений туда-обратно, это является проблемой. А уж двойная потеря памяти и вовсе атас, в некоторых местах может не хватить адресного пространства (код-то 32 битный).
Если проект действительно настолько большой, то переносите через промежуточные версии. Будет гораздо легче (но не обязательно быстрее).
Самому сейчас надо переносить проект в много миллионов строк с 7 на 10.2, и это ппц.В целом не всё так плохо. По собственному опыту переноса нескольких миллионнострочных приложений. Как раз таки, как правило, string и char/pchar трогать не нужно.
Самое поганое, что даже недостаточно просто заменить string на ansistring, pchar на pAnsiChar.
Не WideString
, а UnicodeString
.
Решение «кого-то умного» полностью поддерживаю, неюникодное приложение в XXI веке это дичь какая-то. Да и исправление тривиальное, заменить на RawByteString
. А если уместно, то перевести на использование TBytes
.
Решение «кого-то умного» полностью поддерживаю, неюникодное приложение в XXI веке это дичь какая-то.
Да ну? Вот проект, в котором я работаю: полностью американский рынок, только ASCII, только хардкор. Юникод — бесполезная свистелка.
Да и поймите, string — это не просто строка текста, где можно говорить о кодировке.
Если кто-то не в курсе (это я не вам, а так в сторону), почему в Delphi часто строки используют как буферы данных, поясняю: типа shared_ptr там нет (не было в тем времена), а строка в Дельфи с самых ранних версий — RefCounted, поэтому строка — это в первую очередь, динамический байтовый массив, с поддержкой совместного владения, copy-on-write и автоматического удаления.
Поэтому строками можно свободно передавать данные на любую глубину вложенности, между любыми объектами — она всегда thread safe и автоматически удаляется по завершению использования. При этом работать с этим массивом можно стандартными строковыми функциями из RTL, результат можно хранить в RTL же коллекциях без преобразований типа.
Да и исправление тривиальное, заменить на RawByteString
Не совсем. RawByteString это не настоящий тип данных, а обертка для cast'а.
Новый RTL работает только с юникодом — это — постоянные преобразования туда-обратно. Implicit, что кидает warning'и тысячами. Так что или обертки, или сторонние классы типа JCL AnsiStringList'а.
WinApi, который теперь по умолчанию использует W версии.
Индексирование по строке.
Заменить на TBytes не везде можно, много где для членения буферов используются функции типа Copy/Pos. Плюс ко всему замена типа FastCode, как будет работать с TBytes — а хез. Сколько вылезет косяков в приложении, которому 30 лет — можно только гадать.
Вон, правильно пишут про ассемблерный код.
Да там нюансов для legacy вагон.
В 1996 году начиная изучать только что появившийся Delphi, я не мог себе представить, какая будет судьба у этого языка, который сильно повлиял на Java и C#
Справедливо только про C# (разработчика переманили и дизайнер форм очень похож), который вышел позже. Про Java же сомнительно, и Delphi и Java вышли в 1995
Комментаторы не раз отмечали, что идеи Вирта зачастую опережали развитие компьютерной индустрии на годы, иногда — на десятилетия. Разработанная в начале 1970-х система Pascal-P, предполагающая компиляцию программ на Паскале в универсальный «пи-код» и реализацию на любой платформе интерпретатора пи-кода (одна из известных её реализаций — UCSD-Pascal Университета Сан-Диего), которая позволяла с минимальными затратами переносить Паскаль-системы на новые аппаратные платформы, более чем на два десятилетия опередила идеи интерпретатора промежуточного кода, реализованные в системах, поддерживающих исполнение программ на языке Java и в платформе .NET. Идея совмещения системы программирования со сборщиком мусора, освобождающим программиста от необходимости отслеживать время жизни объектов, динамически размещённых в памяти, была реализована в 1988 году в языке и операционной системе Оберон. Обе эти идеи были использованы разработчиками Java и .NET во второй половине 1990-х годов.
Delphi развился в самостоятельный язык. «Эффективные менеджеры» из Borland могли бы взять лучшее из Оберона и Модулы и других идей Вирта, но — не взяли. Ну и
Желающие поизучать наследие Вирта могут посмотреть на ЯП: Паскаль (Lazarus), Oberon, Modula, Zonnon, Go, Nim, Lua, Ada, Eiffel,…
Приличные IDE для Java, насколько помню, появились только в начале 2000х
При чем тут IDE? В статье речь про язык. Да и основная концепция (Write once, run anywhere) и виртуальная машина Java ничего общего с Delphi не имеет.
Одним FMX жив не будешь. REST, ORM, SSL, PostrgeSQL, MongoDB, нормальный парсер JSON, наконец! Где это всё? А нигде, как были кривые сторонние решения, так всё и осталось, как раньше молились на VirtualTreeView и Synapce, так до сих пор ничего не поменялось, хочешь получить что-то работающее — пиши ручками. И очень чувствуется недостаток разработчиков языка, новые мелкие фичи вводятся с невероятной помпой, вместо разработки компонентов покупают шареварщиков.
Я программирую на делфах с самого первого выпуска, и соскочил с него на котлин. Господи, какой же кайф, когда и в языке куча сахара, и сообщество имеется, и решений множество на любой вкус.
Поезд делфей ушёл, и основная вина в этом руководства, которое в эпоху бесплатных средств разработки задрало цену в заоблачные высоты, а теперь пытаются хоть кого-то привлечь выпуском community edition.
И очень жалко разработчиков, которые поставили весь свой бизнес не на ту лошадь. Например, Сергей Ткаченко, которые написал текстовый редактор уровня word, с таблицами, гиперссылками и прям вот дофига всего. Работы море, а кому продать результат, если на делфах только остаются, но никто не приходит? Что было бы, если бы он начал писать на Java…
так всё и осталось, как раньше молились на VirtualTreeView и Synapce,
Synopse.
Так а в чем проблема-то, если решение есть, и оно хорошее? Часть популярных пакетов потом становится стандартом, как те же Indy или FastMM.
Пакетов — море, инструментов для отладки — тоже. Чего нет, можно подключить хоть из C, хоть из net.
Насчёт подключения сторонних либ. Вы пробовали перевести хидеры из C++ в Делфи? Попробуйте перетащить и отладить (!) 100-200 классов, уверяю, вам не понравится.
Пакет для отладки более-менее удобный только один — EurecaLog, сторонний, платный. Впрочем, как и многое в Делфах
Нет на indy ssl-rest сервера, на синапсе можно прикрутить, но после знатных танцев с бубнами
Не пробовал рест в синапсе, не могу сказать; но документация у них очень обширная, модульность неплоха, должно быть выполнимо — судя по примерам, REST сервер делается легко. Форум у них опять же есть, живой, на вопросы отвечают очень быстро. Я использую синапс мормот сейчас просто как https/websockets библиотеку и здесь выбор есть — Indy (1 connection=1 thread, не подходит), ICL и тому подобное или morMot от синапса (async, worker thread pool все дела, причем используется httpd ядра NT).
В моей области деятельности — все есть, поэтому «так во всем» принять не могу.
Касательно синапса «Не у кого спросить, невозможно найти примеры» так и вовсе мимо — и примеры есть полные, и форум, как писал выше.
В общем, вопрос «где это все» — как-то странен.
Насчёт подключения сторонних либ. Вы пробовали перевести хидеры из C++ в Делфи? Попробуйте перетащить и отладить (!) 100-200 классов, уверяю, вам не понравится
Из плюсов — нет. Просто из Си — да, это не проблема. NETовские DLLки тоже использовал без проблем.
Пакет для отладки более-менее удобный только один — EurecaLog, сторонний, платный. Впрочем, как и многое в Делфах
Да, Eureka тоже пользуюсь. Инструмент отличный, не нарадуюсь. Приятно же при креше получать полный отчет с детализацией до номера строки.
Платный? Ну да, так что с того? 150-250$ за лицензию для одиночки и до 1250$ за полную enterprise с исходниками на всю команду — разве это расходы? 750$ на команду если без исходников. Это не деньги.
FastMM помогает отладить утечки памяти, например. Через map2dbg можно и WinDbg использовать и тому подобное.
Мне решительно не понятен ваш фетиш на тему «сторонний — не сторонний». Инструмент — есть, какая разница, кем он выпущен? Никого же не возмущает, что надо использовать, скажем, сторонний (изначально) Boost?
Это же замечательно, что есть возможность расширения сторонними производителями.
А так да, всё нормально…
Опять сторонее, создаваемое ОДНИМ человеком
Так и пусть стороннее. Про то, сколько там разработчиков — не знаю, мне казалось, что команда.
Таблиц не больше 64, left join в запросах работает криво, при ошибке на сервере запрос остаётся в отрытом состоянии, отжирая память на клиенте.
В какой версии? Не думаю, что ограничение на количество таблиц невозможно исправить. Но — повторю — я использовал только сетевую библиотеку mORMot, конкретно обсуждать ваш случай не могу.
И ОДНО обсуждение в русскоязычном интернете…
Даже не знаю, что ответить. А кому оно нужно? За последние 10-12 лет из русскоязычных ресурсов пользовался только Хабром. Мне не понять вашу боль — для меня «задать вопрос» железобетонно = «задать вопрос на английском ресурсе». Особенно если продукт не из б. СССР.
А по -поводу русскоязычного — это просто показывает распространение делфей у нас…
А по -поводу русскоязычного — это просто показывает распространение делфей у нас…
Уж если считать, что они у нас не распространены, то где тогда. РФ был последний оплот паскаля, можно сказать.
Максимум таблиц и полей в таблице 256, связано с ограничением на размер set в Delphi.
Команда там интернациональная, и русскоязычных там довольно много. Общаемся в основном на местном форуме на английском.
unit mORMot;
function TSQLRecord.RecordReference(Model: TSQLModel): TRecordReference;
begin
..if (self=nil) or (fID<=0) then
....result := 0 else begin
....result := Model.GetTableIndexExisting(PSQLRecordClass(Self)^);
....if result>63 then // TRecordReference handle up to 64=1 shl 6 tables
......result := 0 else
......inc(result,fID shl 6);
....end;
end;
И как в 6 бит запихнуть аж 256 таблиц? Не скажу, что документацию выучил наизусть, но такое фундаментальное ограничение должно быть написано красными буквами 14 размера в самом начале! А так я делал, делал, отлаживал, отлаживал, и все никак понять не мог — схренали ссылка показывает «в ту степь»
И действительно большое спасибо за предупреждение о максимальном количестве таблиц, в документации этого тоже нет
Нет на indy ssl-rest сервера, на синапсе можно прикрутить, но после знатных танцев с бубнами.
mORMot в помощь:
github.com/synopse/mORMot
Довольно навороченная бесплатная либа.
Понимаете, и это во всём! Чуть то нужно — ищи хоть что-нибудь, доделывай, переделывай, и это из-за ОЧЕНЬ маленького сообщества.
Я бы не сказал, что сообщество даже в рунете маленькое, не говоря о мировом. Отвечают почти всегда.
Не у кого спросить, невозможно найти примеры
Если уж не нашел один из десятка активных форумов, можешь на телеграм канал зайти:
t.me/Delphi_Lazarus
Ежедневные, почти ежечасные обсуждения всего подряд.
на гитхабе жуткое неразвивающееся старьё
Это не так, множество проектов довольно активно развивается, вот список:
github.com/Fr0sT-Brutal/awesome-pascal
Насчёт подключения сторонних либ. Вы пробовали перевести хидеры из C++ в Делфи?
Пробовали. Существует с десяток авто-переводчиков, большей частью справляются автоматом. Поправить хитрые места только.
Пакет для отладки более-менее удобный только один — EurecaLog, сторонний, платный. Впрочем, как и многое в Делфах
Это неверно. Есть FastMM, есть JCL Debug, есть Mad Excpept. Всё либо бесплатное, либо с ограничениями (последний пакет, по возможностям он местами лучше Эврики).
mORMot в помощь:Использую, у него свои косяки.
Существует с десяток авто-переводчиков, большей частью справляются автоматом.Можно примеры? А то у нас человек сильно матерится, переводя HikVision и Bosch SDK
Есть FastMM, есть JCL DebugОни научились автоматически создавать тикет в тикет-системе?
Можно примеры? А то у нас человек сильно матерится, переводя HikVision и Bosch SDKВот хотя б из свежих:
github.com/neslib/Chet
Они научились автоматически создавать тикет в тикет-системе?Mad Except умеет.
Вот хотя б из свежих:К сожалению, и этот не умеет С++, что прискорбно.
Mad Except умеет.По нашему опыту, он самостоятельно падает чаше Еврики
stackoverflow.com/questions/100596/best-resources-for-converting-c-c-dll-headers-to-delphi
По нашему опыту, он самостоятельно падает чаше ЕврикиСтранно, у меня сложилось мнение как раз наоборот. Эврика, бывает, иногда падает, правда очень редко. Mad не видел ни разу, что бы упал. Правда, мы его юзали меньше, Эврика удобнее.
Существует с десяток авто-переводчиков, большей частью справляются автоматом.
Можно примеры?
SWIG (Simplified Wrapper and Interface Generator).
Начиная с v1.3.22 — Modula-3, с UPDATE 2017:
Modified by FMXExpress ( see on GitHub ) version of
SWIG 3.0.11 for Delphi and Object Pascal
Кстати, нормальный парсер JSON в C# тоже сторонний пакет — Newtonsoft.Json
Но так-то да, боль ваша понятна. Сам на C# сейчас.
Написал виндовое приложение на с# после 5 лет явы и питона. С# это боль, боль которую я лечил 1 месяцем кодинга на питоне. А знаете почему боль? Язык то хороший, ну с оговорками, а-ля я не готов писать переменные с большой буквы, а фигурные скобки переносить на новую строку — глаза вытекают при прочтении, но это мелочи, самое плохое в этом 2 месячном приключении это Visual Studio, после IDE от IntelliJ она воспринимается как Блокнот после Sublime Text. Ну и конечно виндоус, это печаль, я не представляю как люди продуктивно работают на этой ОС
Глаза вырывают скобочки не там? Это отдельная тема где они должны стоять. И все что вы перечислели это необязательно.
Вот работаю на маке, в свободное время, благо работодатели дали такую возможность, сам бы не решился экспереметировать. И хочу вам сказать, это слабое подобие левой руки, хотя если подготовиться скриптами за пятерку лет, то можно и работать с той же эффективностью что у меня сейчас на на винде.
И так-же, у вас были деньги на Jetbrains продукты под линухами, почему вы рассчитывали без них обойтись на винде? Ставим ReSharper и имеем все те же плюшки. Или совсем рядом Rider — тот же экспириенс IDEA, и, учитывая сколько вы «помучались» с Visual Studio, думаю до недоделок вы бы и рядом не добрались.
Под статьёй о Delphi, в котором операторные скобки занимают от трёх до пяти символов каждая, рассуждать бы о многословности Java. :)
Под статьёй о Delphi, в котором операторные скобки занимают от трёх до пяти символов каждаяЭто весьма известная история ( и ей тут самое место):
В Modula-2, ADA и Oberon «пятибуквенных скобок» меньше.За выживший в «эволюционной борьбе» begin можете сказать спасибо вполне конкретному ( с какого-то момента) бизнесмену. Почти дословно: «И зачем нам Borland Modula-2, когда и то что есть продаётся?»
Кстати, в Clarion со «скобочками» ( и, заодно, с "=") ещё более лаконично:
If x = 5
y = z * 3
.
Тяжеловесная форма блочного оператора в (Object) Pascal воспринимается как синтаксический шум и быстро перестает быть чем-то значимым.
Многословность Java в другом — начиная от принятой тяжеловесности идентификаторов и заканчивая собственно строго объектной парадигмой, что требует написания дополнительного чисто формального кода.
Многословность Java в другом — начиная от принятой тяжеловесности идентификаторов и заканчивая собственно строго объектной парадигмой, что требует написания дополнительного чисто формального кода.В конце концов не зря же Котлин появился :)
Писать begin/end, к слову, в Delphi давно не нужно — экспертом ctrl+shift+b блок добавляется на любом выделенном фрагменте кода (или просто на пустом месте) и сразу форматируется как нужно.
Господи, какой же кайф, когда и в языке куча сахара, и сообщество имеется, и решений множество на любой вкус.
Странно, решения своих проблем я находил без проблем, даже в рунете. Благо когда язык был на пике популярности писалось на нем многое.
Если вам не сложно, приведите пару примеров синтаксического сахара которого вам так не хватало в Делфи.
....for (row in (s_tree.select { (s_tree.objectid eq parent.id) and (s_tree.objecttype eq parent.type) })) {
........parentPathStr = row[s_tree.objectpath]
........break
....}
}
Запустил транзакцию, выполнил запрос с параметрами, взял нужное поле, удалил запрос, закрыл транзакцию. В select передана DSL лямбда… Этот запрос всегда должен возвращать одну запись, а break- это перестраховка.
Дело не в том, чего не хватало, в делфах и дженерики есть, и хелперы, в последних делфах даже var разрешили в коде писать (не прошло и 10 лет..) Но вот лаконичность синтаксиса kotlin — это прям как крылья за спиной. Вот сравните просто лямбды на котлине и анонимные функции на делфах — вроде и предназначение одинаково, но насколько меньше писать, никаких тебе function(bla-bla) :bla
FireDac вроде как умеет работать с PostgreSql. К ресту запросы через TIdHttp спокойной делаются и ssl там есть. Для json есть superobject. VirualTreeView отличный в DevExpress
REST, ORM, SSL, PostrgeSQL, MongoDB, нормальный парсер JSON, наконец! Где это всё?
Рекомендую поискать тут (вроде бы всё, что хочется есть):
github.com/Fr0sT-Brutal/awesome-pascal
Переход массовым и был… Все знакомые организации и разработчики ушли с Delphi. Одни любители (для Windows-поделок) и legacy support остались.
Delphi, даже в свои лучшие времена, так и не стала industry standard; даже в 97-98 в Штатах практически никто (по масштабам индустрии) Delphi не использовалНу, как раз Microsoft делала всё, чтобы защитить штатовский рынок. А вот в Японии, Бразилии, СССР Delphi был очень популярен.
Знаю проект который наоборот окончательно отказался от Дельфи благодаря Крюкову, они купили у него лицензию на VG scene, а он прекратил поддержку, потому что ушёл в Борланд.
Вообще Борланд создали Голландцы, которые потом уехали в Лондон, а потом в США. В сущности чужаки и это объясняет, что их продукты американцам мало известны. Поначалу у них был бизнес гаражного типа, с паскалем им повезло, склепали на коленке, продавался неплохо, стали нанимать народ. Но это не самоокупалось и превратиться в большой америкаский бизнес они не сумели, хотя вокруг них и отличная команда собралась уже из местных. Но кто будет покупать компиляторы у независимого производителя? Паскаль /Дельфи просто не окупались. Люди сделали всё что могли и в конце приняли логичное решение — устроиться поодиночке в этой жизни пока есть предложения. На момент переименования в Инпрайз уже вроде почти все разбежались. Вся последущая история это жизнь после смерти и то как настоящие американцы могут в своей стране делать деньги даже из того, что вот собственно говоря имеется теперь.
Вообще оно может все и выжило бы, если бы они честно двигались в сторону opensource, в конечном счете, для всех популярных языков есть opensource реализации, даже MS с .net пошли в конце концов по этому пути.
Для меня Delphi это пример того как хорошие идеи губятся эффективными менеджерами.
Вирт — гений. Его идеи оказали огромное влияние на всю IT- отрасль. Любой программист или компания пытавшаяся игнорировать хотя бы некоторые его "истины" в итоге наступал на такие грабли, что в итоге не все оставались на плаву.
К сожалению, Вирт не менеджер, и он не оставил такого же короткого, ёмкого и всем понятного свода правил для управления. В итоге Borland хоть и следовала правилам Вирта в IT-части, не смогла вытянуть в менеджменте. Современные гиганты как раз таки основаны "правильными" менеджерами, которые интуитивно следуют правилам "IT-менеджмента". Попытка формализовать эти правила выливается в многотомные талмуды ITIL, TOGAF и хреново знает ещё что. Это область все ещё ждёт своего Вирта.
И добавлю про сам Delphi. Он "развивается" "эффективными менеджерами" по принципу "здесь купить — там продать". Они так и не выстроили нормальный диалог с сообществом. Информатика — наука о способах генерации, хранения, передачи, обработки и представления информации. И язык программирования должен развивать инструменты для покрытия всех этих способов с учётом их изменении. У нас же кое-как допилили Indy для работы с TCP/IP и UDP. Причём только с OpenSSL. А ведь кроме OpenSSL есть несколько способов безопасной передачи информации. Но нет, ни WinCryptoAPI, ни WinCNG. Не говоря о других. И API у OpenSSL поменялся. Но поддержку не завозят 2 год. Что насчёт MQ? MQ это IoT, это будущее. Есть три стандарта протоколов MQ. Delphi не поддерживает ни один из них. Заниматься для этого переводом заголовочных файлов C/C++ это мазохизм. Клепание для этого обертки над C# либами проводит к осознанию что лучше все на C# переписать.
Каждый раз когда говорят о Delphi мне становится грустно. Как вспоминания о студенчестве оставшееся в прошлом. Но в отличие от молодости востребованность языка можно вернуть. Наблюдаешь за каждым релизом, смотришь на roadmap, и каждый раз мысль "не то, они не желают нас слышат". Главное продать обернув купленную очередную шаровару в красивую обертку.
Делфийская история успеха программиста из Улан-Удэ