что быстрее delphi или c

Незаконченная история перехода с Delphi на C#

Предисловие

2003 год) по 2007-ю, были не просто непопулярны. Их IDE были крайне нестабильны. Фатальные сбои среды разработки, требующие перезапуска, становились неотъемлемой частью процесса программирования. Сам язык менялся настолько незначительно, что большинство разработчиков на вопрос: “Что изменилось в новой версии?” могли только невнятно пробубнить: “Ну,… кажется, были добавлены новые компоненты…”. И только в 2009 году отделившаяся от Borland компания CodeGear смогла вывести на рынок относительно стабильную RAD Studio 2009, включающую новую версию Delphi. Подведя итоги, получаем 6 с лишним лет застоя, на фоне бурно развивающихся информационных технологий.
Поэтому и по сей день, значительный процент профессиональных разработчиков Delphi работает в 7-й версии. Могу только посочувствовать их упорству и посоветовать (если они и далее желают работать с Delphi) как можно скорее осваивать Delphi 2010. В сравнении с Delphi 7, 2010-я версия — это качественный скачек вперед. Я не стану подробно останавливаться на сравнении, поскольку это расходиться с темой статьи, но совсем промолчать не могу. Таких людей нужно чаще мотивировать, поскольку привыкание может быть существенной помехой на пути профессионального развития. Перейдя на версию 2010, вы получите стабильно работающую IDE, значительно превосходящую по комфорту работы среду Delphi 7. Из языковых возможностей вы приобретете поддержку юникода, возможность работы с обобщенными типами и анонимные методы, которые также могут плодотворно сказаться на качестве кода и скорости работы.

Начало

Изучение C#

Чего мне не хватает в C# и Visual Studio

Вплотную поработав с двумя языками и двумя средами программирования, и сделав для себя четкий выбор в пользу C# и Visual Studio, я естественно стал замечать некоторые особенности языка и IDE, которые в Delphi меня устраивали больше. Это примерно такое же чувство, как если четыре года подряд прокататься на одном велосипеде, который в принципе тебя почти всем устраивал, а потом купить и пересесть на новый, более современный, с дисковыми гидравлическими тормозами, облегченной рамой, 27-ю скоростями и прочими наворотами. Почти сразу станут видны нюансы, которые на старом велосипеде были реализованы лучше: сидение не так впивается в энное место, нога лучше сидит на педали, ручки руля не так натирают руки и т.д.
Итак. Перечень того, что мне не хватает в C# и Visual Studio в сравнении с Delphi и RAD Studio:

Проверка на попадание во множество

Вполне возможно, что кто-то сможет предложить более простой вариант на C#, но это то лучшее, что пока смог придумать я. На создание множества, которое задается в Delphi 12-символами “[37..75,100]”, в C# уходит 3 строки кода, включающие создание объекта и цикл.

Вложенные функции

Явное приведение типов

На мой взгляд, способ Delphi намного более элегантен. Только не нужно говорить, что в C# можно воспользоваться оператором as. Это ничего не меняет, поскольку в Delphi также есть такая возможность.

TStringList

Попробуйте реализовать то же самое на C#. Если у Вас получится сделать это также элегантно, то я буду только рад, поскольку давно уже ищу такой способ.

Чтение данных с электронной почты

Закладки в модулях кода

Конечно, я сейчас не скажу, что в Visual Studio нет возможности добавлять закладки. Все дело в том, что в RAD Studio их добавление и переход по ним реализован на порядок удобнее: Shift + Ctrl + цифра устанавливает нужную закладку в модуле, а комбинация Ctrl + цифра позволяет на нее перейти. Все настолько просто и интуитивно понятно, что нет необходимости в дополнительных окнах с кнопками и списками закладок. Если закладка с каким-то номером Вам стала не нужна, вы просто переопределяете ее той же самой комбинацией клавиш. Я был очень сильно удивлен, когда не нашел ничего подобного в Visual Studio. Если я плохо искал и такая возможность есть, буду только рад услышать критику в свой адрес, поскольку в итоге еще одним неудобством в работе для меня станет меньше.

Поиск в модуле кода

Ну, и напоследок еще одно замечание. Опять же не могу сказать, что поиск в модуле кода в Visual Studio не реализован. Я даже не могу сказать, что он реализован неудобно. Он просто реализован не так удобно, как в Delphi, начиная с версии 2009. В RAD Studio при нажатии Ctrl + f не появляется никакого дополнительного окна, а появляется небольшая панель в нижней части экрана с полем, в которое можно ввести строку поиска. После нажатия клавиши Enter редактор кода не просто переходит на искомый участок кода, все вхождения искомой строки также четко выделяются в коде. Благодаря стрелкам «Следующий» и «Предыдущий» можно в любой момент продолжить поиск в прямом или обратном направлении.

Может это просто моя привычка заставляет меня думать, что в Delphi поиск реализован удобнее? Но посмотрите, например, реализацию поиска в самом популярном на сегодня интернет браузере firefox и увидите почти аналогичную реализацию.

Еще раз поясню, что в этом разделе я вовсе не пытался доказать превосходство Delphi. Для меня лично, превосходство C# очевидно. Я хотел показать те нюансы, которых мне недостает во время работы с C#.

Источник

Python, Delphi и C++ глазами учёного

Статья про использование Python в научных вычислениях подтолкнула меня написать эту статью. Это история, случившаяся со мной и с коллегами 6 лет назад. На тот момент я уже достаточно подразобрался с Delphi и Python, но только теперь я ощущаю что достаточно поработал с C/C++, чтобы здраво оценить время на «ремонт» сломанного кода и вообще — общее время разработки. Да, это статья про код, который был написан разными людьми на Delphi, Python и C++ для одной и той же задачи, внутри одной команды.

Перед описанием ситуации, хочу оставить вторую преамбулу для тех программистов, которые не сталкивались с программированием в науке, и не имеют базовых представлений об этом. Осторожно, далее будет несколько мини-инфарктов:
— В коде просто обязано иметь много переменных. И многие из них должны иметь названия типа mu_e, mu_m, E, T_f, T и так далее — просто потому, что в формулы эти величины входят именно так, и учёным, которые в этой области занимаются исследованиями, могут потратить много времени вспоминая как расшифровывается название коэффициента в полном виде, зато безошибочно узнают букву, которой он обозначается во всех статьях, и скажет — «Ага! Это наша мю. »
— Код никто не защищает от неправильного ввода и нет никакого UX. Код пишется для того чтобы с ним работали учёные, аспиранты, и специально обученные студенты, и никогда — типичные_пользователи и хакеры.
— Технического задания у вас нет. Вы ведёте исследование, значит вы пишете один код, смотрите на результат, который он выдал, анализируете, и в зависимости от результатов формируется следующая задача, под которую будет дописываться существующий проект.
— Большая часть кода будет использоваться один, или два раза. Один — если аспирант, или научный сотрудник делает некий расчёт. Два — если студент делает некий расчёт, а затем демонстрирует работу кода своему научному руководителю. Соответственно, код почти никогда не абстрактен, и в нём может повстречаться костыль любого вида и размера.

На первое время хватит, начну свой рассказ. Я был слегка моложе, голова моя была чистой, сердце — горячим, а руки были холодными и чесались что-то делать. И так случилось, что одним из первых заданий в новой исследовательской группе (после смены руководителя), для меня стал разбор чужого кода, который по неясным его создателю причинам — не работал. Далее последуют три истории отладки и настройки программы. Одна из них слегка уходит в сторону размышлений, две другие про реально предпринятые действия, и столь же достоверно описывают среднестатистический опыт работы учёного с соответствующим языком программирования.

Задача была одна на всех — решение дифференциального уравнения (у которого не существует аналитического решения) с разными начальными условиями. Уравнение было большим и пёстрым — f(x) и x, описывающие состояние системы в некоем нестационарном процессе, входили в нём и в производные, и в производные их частного, и в экспоненты, и в логарифмы, и в разнообразные степенные функции. Некоторые коэффициенты при степенях неявно также зависели от них, и их необходимо было пересчитывать на каждом шаге. В дипломах и диссертациях такие уравнения встречаются довольно часто, и обычно в таких выражениях вводят замены, чтобы уместить в одну строку, но часто и замены не помогают — тогда уже расписывают на весь лист. Предсказать вид такой функции (он же — поведение системы) просто по виду задающего её уравнения — задача абсолютно неподъёмная для человека, пусть даже и человека с самыми развитыми способностями к анализу функций и самыми благими намерениями. Соответственно задача программы — тут же вывести этот самый вид, начертив график.
Решаются такие задачи просто: есть одна приблизительно известная точка, которая берётся за исходные данные. Затем от неё на каждой итерации цикла делается шаг в сторону, с расчётом новых значений из старых. В случае метода Эйлера величина шага пропорциональна производной в исходной точке. В случае метода Рунге-Кутты зависимость несколько сложнее, чтобы быть слегка точнее. Есть и другие методы, когда точка, строго говоря, вам неизвестна. Но вам известна y координата одной точки, и x координата другой. Тогда применяются слегка более извращённые методы, но сводятся они всегда к перебору всех возможных вариантов и множественному использованию Эйлера, или РК. Ну а найдя точки — надо тут же отправлять их на интерфейс в график. Звучит несложно, приступим.

Начнём с С++
После проверки всего кода, с множеством переменных с одно- и двухбуквенными названиями, вы приходите к выводу, что программа должна правильно рассчитать все коэффициенты, правильно найти значения для следующего шага, правильно перейти на следующий шаг, и правильно вывести данные на график. Следовательно, программа в целом должна отработать правильно, решаете вы, и запускаете.
Компьютер зависает и происходит какая-то очень нехорошая ошибка каким-то непонятным образом связанна с памятью.
Вы остаётесь с задачкой как это всё отладить. Очевидный путь — включить дебаггер и пройтись по потоку вычислений — в данном случае пока не подходит. Ведь вы не знаете сколько раз успел отработать цикл, вдруг миллион, два? Выходит, чтобы начать отладку, вам нужно найти точку вылета. То есть намечается целых четыре новых этапа: переписать код так, чтобы он выводил в лог номер цикла, чтобы заметить последний номер итерации, где происходит вылет, затем переписать код ещё раз, чтобы остановиться на этой итерации и выставить красную точечку в дебаггере, и пройтись по последней итерации дебаггером, надеясь на то что ошибка станет ясной. При этом
а) у вас нет гарантий что лог сохранится, в связи с падением ОС. Возможно придётся проводить работу визуально, разбив первый этап на на два: сначала выводить номер цикла в консоль и пытаться запомнить последнее число примерно, затем переписать код чтобы включить в цикл искусственный замедлитель после этой запомненной итерации — тогда на следующем тесте можно будет увидеть как числа перед падением начинают поступать медленнее, и успеть прочитать последнюю итерацию (скажем, 6524-ая), значит количество падений будет не 3, а 4.
б) у вас нет гарантий, что вы поймёте, или даже найдёте ошибку с первого раза. Скорее всего где-то перед самой ошибкой код начнёт уводить вас вглубь кроличьей норы — по извилистым лабиринтам стандартных библиотек, и хоть вы пройдётесь всего по одной ветке, вам потребуется изучить значительную часть дерева возможностей вокруг этой ветки, чтобы понять что вообще произошло, ведь функции в ней зачастую просто перебрасывают какие-то ошмётки данных от одних проверок к другим, для понимания многих из них вам понадобиться ещё и разбираться в физическом устройстве машинных операций, а понимание значения иных приходит к человеку только после попытки написать свою ОС. Более того, после того как вы решите что нашли в чём проблема, нет никаких гарантий, что вы правы. Начался длительный процесс отладки, и вам предстоит ещё много тестов… Вместо четырёх падений мы получаем n, где n>3.
в) необходимые для тестов падения, вообще говоря, вещь довольно стрёмная. Мало ли что произойдёт? А тем более, когда предстоит сделать это много раз.

Теперь вы сидите и думаете, а стоит ли вообще приступать к реализации такого плана? Он выглядит громоздко, и неизвестность вас слегка пугает — мало ли где зарылась ошибка.

Pascal/Delphi
Проверка кода. Вообще говоря она может занимать больше времени, но в данном конкретном случае вам нравится, что все 66 коэффициентов объявлены и заданы в начале, а не в любом месте кода, например перед использованием. Вы сверили коэффициентики, отбросили табличку и теперь просто сверили все формулы. Опять таки, всё хорошо. Запускаете программу, и — о чудо, график рисуется. График рисуется, доходит до конца оставленного для него участка числовой оси и останавливается. Программа не вылетела, ничего страшного с ОС не произошло. Но произошло с данными. Он плавно доходит до координаты 6524, а затем вдруг его кусает бешеная блоха. Он скачет вверх и вниз абсолютно случайно и заполняет всё оставшееся полупространство справа кромешной тьмой.
На этом этапе вы удручены неудачей. Но всё же находитесь в выигрышной позицией по сравнению с си, ведь:
а) система не упала
б) вы уже локализовали итерацию, где возникает ошибка
в) вы можете пробовать новые исправления, не боясь что система вдруг упадёт

и г) — вы видите одно выведенное значение. Оно неверно. И возможно, уже на этом этапе предполагаете что это может быть, скажем, переполнение, либо ошибка чисел с плавающей точкой. Осталось понять где именно, чтобы не создавать тысячи экстендедов. Вы дописываете строчку кода чтобы остановить на номере 6524. Проходитесь дебаггером и замечаете подозрительную операцию очень маленького числа на очень большое, начиная с которой тянется ошибка, которая приводит к расходимости. Есть оказывается, в вашей функции такая особая точка, крохотный участок, где состояние имеет локальный минимум, но за пределами небольшого ограждения в потенциале начинается крутой спуск, приводящий к расходимости всего решения, и уводящий значения за пределы и дальше — в переполнение их типов. И естественно, численный метод немного промахивается на этом шаге мимо нужного локального минимума, из-за банальной нехватки точности для всего двух коэффициентов. И заметно это становится только здесь — в том узком месте, где даже незначительно отклонение отправляет итерации по дурной дорожке расходимости. Значит надо ещё разок переписать код, ввернув пару экстендед вариэйблс… Но опять какой-то косяк происходит, хотя график выглядит уже немного по другому. Я имею ввиду, конечно же, чёрную его часть. Брыкающуюся. Сколько ещё надо колдовать над кодом? Ну, поработать над реализацией работы с длинными числами. И обнаружить (после исправления этих двух) ещё один «протекающий»* коэффициент.
*протекающий — это потому что выход за пределы типа должен приводить к изменению бита слева от места его физического хранения, т. е. Нам нужен ещё один, либо несколько бит, которые не содержаться по нашей ссылке на объект такого типа. Ок, это заняло не так уж много времени.

перепишем на Python
Проверяем код, запускаем. Проблема не наблюдается. График чертится полностью, на всей области. Никаких скачков и черноты, никаких вылетов.
Волшебство интерпретатора помогает доброму питону увидеть, сколько памяти требует моё число, и выделить ровно столько, сколько ему будет достаточно.

Так что я с тех самых пор пользуюсь именно Python’ом почти для всех научных работ (одну я всё-таки сделал в спец пакете, и только ради красивой визуализации под случай), и даже разобрался в некоторых его тонкостях. Чего и вам желаю.
Используйте Python. Двигайте науку. Лучей добра.

Источник

Что изучать: Delphi или C#? [закрыт]

Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы на него можно было дать ответ, основанный на фактах и цитатах.

Что понятнее и легче усваиваемое для мозга 14-ти летнего школьника: delphi или C#?

UPD Ну, а если судить по развитию, то что быстрее развивается и не превратиться лет через 10 раритетом

5 ответов 5

Все зависит от энтузиазма, сил и подобного. Теоретически, можно хоть сразу взяться за более востребованный C#. Но лично мне в 14 лет было трудновато и с Delphi (правда, тогда было плохо с поиском русской информации по нему в инете, как с точки зрения моего умения поиска, так и с точки зрения вообще наличия качественной информации по программированию), так что сейчас я немного жалею, что не знал о том, что можно было не спешить прыгать слишком высоко. Наверняка, если бы я начал с чего-то простого, потом чуть сложнее и тп, я бы быстрее достиг текущего уровня. Плюс я бы натренеровался в том, чтобы быть гибким и легко переучиваться между совсем разными языками (лучшие программисты мира часто говорят, что хороший программист должен учить по одному новому языку в год).

Дело вкуса. Наверняка тут найдутся любители и того и другого, которые будут поливать грязью противоположный язык. Лично я за Delphi для первого языка программирование, т.к. Pascal (а он в основе Delphi) создавался для знакомства с ЯВУ.

Источник

C++ или Delphi? [закрыт]

Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы на него можно было дать ответ, основанный на фактах и цитатах.

Хочу поинтересоваться, если делать приложение полностью создавая с нуля интерфейс, использую только стандартные Parent-ы то в какой среде это получится сделать более качественно?

5 ответов 5

С Delphi не знаком!

У использования плюсов есть некоторые плюсы 🙂

Во-первых, зная C++ есть возможность использовать бОльшее количество различных библиотек, будь то GUI, мультитридинг или сетевая разработка. К тому же (на мой взгляд) у C++ больше «комьюнити» и больший потенциал чем у дельфей.

Во-вторых. Касательно гуев и плюсов: здесь есть названия книг по Qt. Я уверен что разработанное на нем ПО будет более качественным, чем на Delphi, и даже чистом WinAPI. К тому же приложения созданные с использованием C++/Qt можно перекомпилировать и они без проблем будут работать как на MacOSX, так и на Linux.

Все зависит от количества серого вещества того кто делает.

и опять будет холивар что круче C++ или Delphi

Подытожив и выразив свое мнение:

Дельфисты и сиплюсисты вечно в противостоянии, этот вопрос терзал многих. Одни обливают грязью и скудностью обьектный паскаль и производные продукты (делфи, BDS Delphi), другие говорят напротив, что с++ (Visual) сложен для построения информационных систем, так как работа с БД Borland отточила на максимум. Баталии споров помню еще между pascalщиками и сиплюсплюсчиками. Если ум, есть, то можно в любом инструментарии создать продукт-конфетку, на которую будет любо, дорого смотреть. Вообще я знаю и делфи и с++, для меня они практически равноценны. Будущее за c#, если говорить о прикладном программирование. Если говорить о сетях и интернете, то пора ударяться в облачные технологии, через 4-6 лет они заполонят нас). Идеология ООП одинакова в общем случае у них, но за с++ больше практического кода, и как правильно сказали люди большая часть библиотек писалось на нем. Быстрее наверное на с++, хотя я бы эскпериментировал и там, и там).

делать приложение полностью создавая с нуля интерфейс

Имеете в виду на голом WinAPI? Тогда, пожалуй, лучше с++.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками delphi c++ или задайте свой вопрос.

Связанные

Похожие

дизайн сайта / логотип © 2021 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2021.12.6.40898

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Источник

Научный форум dxdy

Математика, Физика, Computer Science, Machine Learning, LaTeX, Механика и Техника, Химия,
Биология и Медицина, Экономика и Финансовая Математика, Гуманитарные науки

Delphi vs. C++

Заслуженный участник

Готов сослаться на личный опыт. У меня моя квалификация тоже сомнения не вызывает. Дальше что?

Я как-то нахожу и свои и Ваши аргументы легковесными, несерьезными.

Я уважаю Delphi, C, C++, и все остальное. И пользуюсь по мере подходящести к задаче. Для бизнес-приложений Delphi подходит, а для управления микроконтролером — слаб. Паскаль — прост, но умоляю: не называйте входной язык Delphi Паскалем. Вирт бы, ну не обиделся бы, но очень удивился. И покажите мне как в Паскале (а не в Delphi) вызвать функцию ядра системы (внешней библиотеки).

Каждая система программирования — это плод бессонных ночей и мучительных компромисов. У каждой — своя область применения. Поэтому делать тест вне этой области — смешно. Насколько легко написать обработчик прерывания или ядро ОС на Delphi Паскале? А для С++ есть десятки систем, оптимизированных именно под это. Не говорите, что можно поменять Паскаль. Можно. А С не нужно менять. Но это не делает его лучше. В ряде смыслов, С хуже. Ну и что?

Заслуженный участник

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

Во-вторых, когда пишут о языке, пишут о языке. Когда сравнивают системы программирования, говорят о системах программирования. Вы же смешали все в кучу, сравнивая систему программирования (Delphi) с языком С. На что Вам и было иронически указано в предыдущем посте (например, ссылками на ColdFire, обработчики прерываний).

Обработчик прерывний — понятие куда более общее, чем DOS, на который Вы ссылаетесь. Есть они даже(!) в Windows, с ними сталкиваются те, кто пишут драйверы. Ну, хотя бы драйвер контролера прерываний. Но во встроенных системах, особенно небольших — важная часть кода.

Управлять микроконтроллером, я, разумеется, имел в виде прошивку. То, что делается с ПК, я обычно называю коммуникацией. Поэтому, суммируя Вашу и мою точку зрения (включая OS, ядра): Delphi не подходит для встроенных приложений. Вспоминая язык Паскаль, можно призвать на помощь авторитетов. Никлаус Вирт считал, что Пасколь не подходит для написания ОС и сделал новый язык — Modula-2. Итого, какой из языков ближе к железу: С или Delphi Паскаль?

Ограничив же себя wintel’ом, трудно говорить о какой-либо близости к железу. Там все далеки (пока драйверы писать не начинают). Я, обычно, вообще игнорирую скорость, когда речь идет о GUI. В таких случаях мне важна только скорость разработки, и я брал VB. Что сейчас буду брать — не знаю.

Теперь я готов ответить на этот вопрос. На опыте программирования, заметно более широком, чем в Win32. Т.е. на том, что Вы исключили из рассмотрения.

P.S. Я готов привести пример, о котором мне было бы интересно услышать Ваше мнение. Я даже не хочу говорить заранее, что Delphi хуже или лучше. Как бы Вы реализовали на Delphi какое-нибудь управление памятью (memory manager), скажем, с таким интерфейсом:

При создании пула должна захватываться начальная область initialSize MB, если очередной alloc() не может быть удовлетворен — то добавлено increment MB. alloc() выделяет кусок области, free() возвращает выделенное. alloc() типизирован, free() — атипно. Дело понятное, чем быстрее работает, тем лучше.

Я (упаси Боже) не жду программу. Может быть, интерфейс в Delphi. В любом случае, Ваши мысли — что удобно делать, что неудобно. Например, как организовать данные внутри. Путь С понятен — адресная арифметика. Какой будет путь Delphi?

Пример практический. Мне приходилось писать подобые пулы несколько раз (для разных нужд). Иногда стандартный механизм был слишком медленным, иногда — конфликты между thread’ами, иногда не хотелось следить за освобождением памяти (освобождение пула прощает все).

Заслуженный участник

Я читаю внимательно. Но, если Вы не заметили, Ваше выражение «НЕ использовать ассемблерные вставки и/или подпрограммы» не однозначно: согласно грамматике русского языка его можно интепретировать как «не использовать ассемблерные вставки и/или ассемблерные подпрограммы» или «не использовать ассемблерные вставки и/или не использовать подпрограммы». Вы имели в виду первый вариант, но Ваш читатель вынужден гадать. Я прочитал второй, к Вашему неудовольствию.

Столь же безосновательны и Ваши претензии к ссылам на не win32. Напомню Ваш первоначальный вопрос:

Что касается ответа на мой вопрос об управлении памятью, то большая часть Вашего ответа втуне. Поскольку вопрос был отнюдь не «какие есть средства управления памятью в Delphi». А как бы Вы написали класс с вполне определенным интерфейсом. И с указанной семантикой. (Например, можете считать, что решение писать уже принято.) Между прочим, Ваша идея с использованием потоков для управления памятью весьма интересна. Может быть, расскажете подробнее? А с динамическими массивами я тоже не понял — мой alloc() возвращает указатели на объекты заказанного типа. Я просто пишу в вызове, что мне нужно:

Как тут Вы используете динамические массивы?

Против. Времени нет на то, что я считаю не важным. У меня когда-то была опубликована статья о сравнении компиляторов и языков, так что я делать это умею. Но на данный момент меня совершенно не интересует сравнение компиляторов на PC. Под wintel это моя самая последняя забота, так как выбор языка определяется совсем иными нуждами проекта. Если я буду считать, что какой-то кусок не Delphi можно ускорить, переписав на С, я так и поступлю. Если же меня не интересует производительность, то мне тем более все равно. А для очень многих проектов я выберу Python, хоть он и проиграет по скорости раз в десять. Зато усилия на разработку и сопровождение сократятся.

На мой взгляд, эпоха священных войн за языки программирования отошла в прошлое. Можно написать Delphi на флаге и ринуться в бой с шашкой наголо. Но те, кто в танке, на Вас посмотрят с некоторым изумлением. Причем независимо от того, с какой стороны линии фронта находятся. Дальше Ваш выбор…

Позвольте напомнить вопрос темы:

var
p1,p2:pointer;
begin
//создание экземпляра класса tmyclass
getmem(p1,sizeof(tmyclass));
tmyclass(p1^):=tmyclass.create;
//обращение к полям экземпляра класса:
tmyclass(p1^).my_class_int_field:=12;

//создание экземпляра класса tyourclass
getmem(p2,sizeof(tyourclass));
tyourclass(p2^):=tyourclass.create;
//обращение к полям экземпляра класса:
tyourclass(p2^).your_class_char_field:=’r’;

уничтожение экземпляров:
tmyclass(p1^).free;
tyourclass(p2^).free;
end;

Источник