Delphi vs C#

@turboq · Регистрация: 14.01.2010

Студворк — интернет-сервис помощи студентам

Всем привет.
Я уже давно люблю покодить на делфи(7) и вот решил попробовать на с#.
Тема глупая и затасканная, но все же какие преимущества я получу(и недостатки) с точки зрения любителя.

@Curry · 16.05.2019, 09:43

Сообщение от WH

Почему Вы так считаете? (про Аду)

Потому что под оси не реального времени и других языков полно. А для Ады либы для таких осей весьма примитивные. adagtk работает, но очень бедная. К тому же, как и просто GTK, она не типобезопасная. Ну и так далее. Попробуете на аде что то под винду писать - узнаете что ничего и нет. К тому же проблема с кодировками при выводе в консоль.
Встроенная система распараллеливания и взаимодействия межу потоками древняя, тогда ещё не знали как это делать.
То же про динамическое распределение памяти (Unchecked_Deallocation).
Но для embedded годится.

@Fulcrum_013 · 04.06.2019, 01:13

Сообщение от Curry

Если бы как в Delphi.

А именно такой целью и задавались. Но шарп не нэтив. У него с автоматикой совсем плохо. Хуже чем у Дельфы у которой только вручную создаваемый полуавтомат.

Добавлено через 16 минут

Сообщение от Curry

То же про динамическое распределение памяти (Unchecked_Deallocation).
Но для embedded годится.

для embedded все что использует динамическое перераспределение памяти не годится в принципе. Гарантировать одновременное наличие нужных буферов можно только имея их распределенными со старта. А без такой гарантии и обработку в реальном масштабе времени гарантировать никак низя.

@Curry · 04.06.2019, 07:02

Сообщение от Fulcrum_013

для embedded все что использует динамическое перераспределение памяти не годится в принципе. Гарантировать одновременное наличие нужных буферов можно только имея их распределенными со старта. А без такой гарантии и обработку в реальном масштабе времени гарантировать никак низя.

Это вы обобщаете. Существуют ситуации когда нужно много временных буферов заранее неизвестного размера, если памяти достаточно для худшего случая, то требования рилтайма сохраняются. Могут быть в одной программе (на одном контроллере) требования жёсткого реального времени для одной группы входных и выходных сигналов, а другие низкоприоритетные, выполняются когда времени, памяти и прочих ресурсов хватает. Обычное дело. Или, например, контроллер чем то рулит. Пока изменения редки, он точнее рулит. Когда изменения пошли быстрее, он начинает прогнозировать на меньшую величину, требование релтайма сохраняется. В таких программах сложно заранее оптимально выделить буфера. Поучится что при небольшом потоке данных программа будет работать не оптимально.

@Fulcrum_013 · 04.06.2019, 19:05

Сообщение от Curry

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

Как гарнантировать что ее достаточно? Кроме того если ее достаточно зачем ее туда сюда дергать? Выделили большой буфер и нарезаем из него мелкие. Всяко быстрее чем дергать глобальный new. Опять же откуда взялся неизвестный размер? Всегда есть предел размера который можно обработать в реалтайме. Превышен - все уже поломалось потому что уже не успевает обрабатывать в заданный лимит времени. Поэтому разер всегда ограничен.

@Curry · 04.06.2019, 23:07

Сообщение от Fulcrum_013

Как гарнантировать что ее достаточно?

Существуют случаи когда максимально возможный размер можно рассчитать.
И чем отличаются

Сообщение от Fulcrum_013

ее туда сюда дергать

от

Сообщение от Fulcrum_013

Выделили большой буфер и нарезаем из него мелкие.

? То есть, вас заранее не устраивает имеющийся в языке или стандартной библиотеке механизм выделения памяти и вы хотите написать тоже сами? Ну, пишите.

@Fulcrum_013 · 04.06.2019, 23:55

Сообщение от Curry

То есть, вас заранее не устраивает имеющийся в языке или стандартной библиотеке механизм выделения памяти и вы хотите написать тоже сами? Ну, пишите.

Механизм в языке предназначен для выделения суб-куч распределение/удаление из которых осуществляются более оптимальными для обслуживаемой суб кучей конкртеной структуры данных. К примеру такой суб-кучей может служить вектор для стека или кольцевой буфер для очереди.

Сообщение от Curry

Существуют случаи когда максимально возможный размер можно рассчитать.

На самом деле других случаев не существует. Потому что существует максимальный объем который можно обработать в заданный лимит времени. А когда максимальный объем известен он на старте и распределяется. Чтобы избежать ситуаций когда двум подсистемам эти максимальные объемы понадобились одновременно а одновременно их нету.

@Curry · 05.06.2019, 15:56

Сообщение от Fulcrum_013

Механизм в языке предназначен для выделения суб-куч распределение/удаление из которых осуществляются более оптимальными для обслуживаемой суб кучей конкртеной структуры данных.

Вы иногда как будто промтом на русский переводите.

Суть в том, что программы реального времени бывают с динамическим выделением памяти. Мы можем подстраивать алгоритм что бы укладываться во время отклика и размер памяти, например, строить в памяти дерево вариантов на большую или меньшую глубину. Может для ускорения что то кешировать, а в случае приоритетного требования памяти обрубить кеши.
По этому, в частности, в аде, есть динамическое выделение памяти. Нет таких требований что бы системах даже жёсткого релтайма нельзя было динамически память распределять. Релтайм, конечно, усложняет задачу распределения памяти, но не делает её невозможной.

Сообщение от Fulcrum_013

А когда максимальный объем известен он на старте и распределяется. Чтобы избежать ситуаций когда двум подсистемам эти максимальные объемы понадобились одновременно а одновременно их нету.

Это тривиальный простой случай. Так можно говорить только про минимально требуемые объёмы. См. выше про алгоритмы с прогнозом (деревом вариантов).

@Fulcrum_013 · 05.06.2019, 22:10

Сообщение от Curry

Так можно говорить только про минимально требуемые объёмы.

Сообщение от Curry

Это тривиальный простой случай.

Это любой случай. Иначе реалтаймовую обработку гарантировать нельзя.

Добавлено через 6 минут

Сообщение от Curry

См. выше про алгоритмы с прогнозом (деревом вариантов).

Высвобожденную память все равно никому нельзя отдавать в использование другим подсистемам. Она должна оставаться зарезервированной за подсистемой. Потому что предсказать когда она понадобится этой подсистеме снова тем более нереально. Именно поэтому и нет никакого смысла в динамическом перераспределении.

@WH · 09.06.2019, 06:46

Сообщение от Curry

Потому что под оси не реального времени и других языков полно. А для Ады либы для таких осей весьма примитивные. adagtk работает, но очень бедная. К тому же, как и просто GTK, она не типобезопасная. Ну и так далее. Попробуете на аде что то под винду писать - узнаете что ничего и нет. К тому же проблема с кодировками при выводе в консоль.

Кодировки для консоли это по моему для любых языков проблема. Про отдельные библиотеки спорить не буду, не знаю как тут с Адой. Но вместе с тем каждый день на форуме вопросы о TurboPascal, заброшенном еще в 1994 году. Это несколько удивляет, чем в данном отношении Ада хуже? Для встраиваемых систем, как Вы сами писали, это отличный язык.

@Fulcrum_013 · 09.06.2019, 10:09

Сообщение от Curry

adagtk работает, но очень бедная. К тому же, как и просто GTK, она не типобезопасная.

Только вот гуи и прочие свистопирделки для реалтаймовых систем нужны чуть менее чем никак, особенно по нынешним временам. Управляющая часть на одном вычислителе, напрочь лишенном хюман интерфейса, хюман интерфейс на другом. Что резко все упрощает.

@WH · 09.06.2019, 10:22

Ну и потом язык то не заброшенный (про Аду), вполне современный, а компилятор GNAT включен в коллекцию компиляторов gcc.

@Curry · 09.06.2019, 11:10

Сообщение от WH

Кодировки для консоли это по моему для любых языков проблема.

Для большинства не проблема.

Сообщение от WH

каждый день на форуме вопросы о TurboPascal

... и по другим языкам, давно заброшенным или никогда и не взлетавшим. Откуда мне знать почему так? Некоторые любят извращения.

Сообщение от WH

чем в данном отношении Ада хуже?

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

Сообщение от Fulcrum_013

Только вот гуи и прочие свистопирделки для реалтаймовых систем нужны чуть менее чем никак

Да, кэп. Только на аде не обязательно писать рилтаймовые приложения.

@WH · 09.06.2019, 12:28

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

@Curry · 09.06.2019, 13:33

Сообщение от WH

Прекрасный язык для расчетов

Покажите преимущества перед, например, адой. Кроме встроенных операций с матрицами (которые на любом языке библиотечно реализуются).
В фортране (коболе) идеология "всё встроено". Это плохо потому что не гибко. В современных языках хотим такую библиотеку (работы с матрицами, со строками, форматирования вывода, работы с файлами ...) используем, хотим другую. Выбор не за авторами языка.
Ну и много других причин. Фортран используют не программисты - профессионалы. Используют профессионалы, но других профессий. А потом случается так что физик обращается к программисту. Тот выберет что угодно, но не фортран, и зачем эти сложности межязыковые?

В общем, жду примеров преимуществ по сравнению хоть с адой, хоть с Delphi (из заголовка темы), хоть с С++, хоть с C# (в последнем случае кроме скорости выполнения, которая теоретически на фортране может быть выше).
Желательно преимущества для построения сложной программы, а не учебной задачки про схему Горнера.

@WH · 09.06.2019, 19:19

Curry, холивары как в теме про cobol разводить не буду, нет не времени не желания к этой никому не нужной "виртуальной борьбе". На Ваши аргумены скажу лишь, что в современном фортране все так же гибко как и в любом другом современном ЯП, а наличие встроенных функций никак не портит язык, а скорее напротив делает его удобным, к тому же реализации этих функций уделяется много внимания в отношении их производительности. Сравнение с шарпом и delphi вообще некорректно по целому ряду весьма увесистых причин. Нравится вам шарп или Delphi, пожалуйста, используйте, каждый язык хорош в своей области применения.

@Curry · 09.06.2019, 20:45

Сообщение от WH

скажу лишь

То есть аргументов нет. Что же, это лучше чем пытаться доказать абсурд.

@Fulcrum_013 · 09.06.2019, 21:33

Сообщение от Curry

Тот выберет что угодно, но не фортран, и зачем эти сложности межязыковые?

Вы когда нибудь видели код написанный физиками на плюсах? Ей богу пусть лучше на фортране пишут. А то настоящий физик на любом языке может писать на фортране IV.

@Curry · 09.06.2019, 21:40

Сообщение от Fulcrum_013

А то настоящий физик на любом языке может писать на фортране.

Вы прямо мои мысли читаете. Я видел в своё время код написанный специалистами по аэродинамике на фортране.
Тут ещё плохо то, что он стиль программирования, если так можно выразится, такой прививает. Спорно, но, может быть, если бы им с самого начала не преподавали фортран, может быть они писали бы лучше.

@Fulcrum_013 · 09.06.2019, 22:06

Сообщение от Curry

Спорно, но, может быть, если бы им с самого начала не преподавали фортран, может быть они писали бы лучше.

Основные библиотеки STL, которые были в ней изначально - еще один пример работы физика. P.J.Plaguer дохтор физики а не разу не CS . У них просто моск не в ту сторону повернут.
К примеру в одной либе по обработке сигналов написанной физиками наткнулся на такую штуку как перегенерация километрового вектора фильтра заново каждую итерацию хотя измениться он не то что между итерациями не может, а даже в течение жизненного цикла хозяина в привате у которого живет. При этом для прикручивания возможности замены фильтра кастомным пришлось препарировать с ног до головы, и в общем то разобрать что они там на преобразовании фурье и дискретно-косинусном считают и написать с нуля было бы быстрее.
В общем там где программист возьмет из массива ренджи и произведет с ним операции, физик домножит несколько километровых массивов на оконную функцию и произведет операции с полными массивами а не с интересными окнами (частями)

@Curry · 09.06.2019, 23:36

Fulcrum_013, да это ладно. Я видел в их программе большие куски кода которые попали туда неизвестно как и выполнялись впустую, "благо" в фортране не нужно объявлять все переменные, просто все вычисленные в этом коде значения потом затирались или далее не использовались. А на вопрос "зачем это?" был ответ "не знаем, но так работает".

Результаты опроса: Что лучше?
Delphi	64	24.43%
C#	123	46.95%
Они дополняют друг друга	20	7.63%
Ни один из них	55	20.99%
Голосовавшие: 262. Вы ещё не голосовали в этом опросе

Новые блоги и статьи Все статьи Все блоги /
Был там один разговор по поводу свободы в материальном мире. kumehtar 19.08.2026 Суть: рассматривается живое существо, оказавшееся внутри довольно странной системы (этого мира) и пытающееся обустроить в ней свой кусок пространства. Жизнь действительно предъявляет каждому. . .	Когда логика программы не спасает от человеческих ошибок Maks 18.08.2026 В последнее время всё чаще и чаще сталкиваюсь с таким явлением, как абсолютная невнимательность (или глупость) пользователей. Проявляется это чаще всего на работе в коллективе. Допустим, человек с. . .	Лето уходит kumehtar 17.08.2026	Мысли в слух kumehtar 17.08.2026 Забавно, насколько сейчас стала доступна информация. Например о магии, духовном развитии, медитациях, и других подобных направлениях, ранее зачастую тайных, передаваемых от учителя к ученику. Хотя. . .
Перемещение строк из ТЧ в другой документ с учетом текущего пробега Maks 17.08.2026 Реализация из решения ниже выполнена на примере нетипового документа "Автозапчасти", с ТЧ "Шины". За основу взят алгоритм отсюда: https:/ / www. cyberforum. ru/ blogs/ 359708/ 10838. html Задача: . . .	Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .	Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .	Часы с будильником на основе класса QLCDNumber Uhbif79 12.08.2026 Всем добрый день, выкладываю программу часов с будильником на основе класса QLCDNumber. Здесь я пробовал самостоятельно создавал классы, впервые столкнулся с видимостью переменной одного класса из. . .

@turboq 160 / 159 / 13 Регистрация: 14.01.2010 Сообщений: 1,497

	Delphi vs C# 24.01.2010, 11:31. Показов 82278. Ответов 861 Метки нет (Все метки) Всем привет. Я уже давно люблю покодить на делфи(7) и вот решил попробовать на с#. Тема глупая и затасканная, но все же какие преимущества я получу(и недостатки) с точки зрения любителя. 0

@WH 1589 / 817 / 192 Регистрация: 10.09.2013 Сообщений: 3,293 Записей в блоге: 3
	09.06.2019, 10:22
	Ну и потом язык то не заброшенный (про Аду), вполне современный, а компилятор GNAT включен в коллекцию компиляторов gcc. 0

@WH 1589 / 817 / 192 Регистрация: 10.09.2013 Сообщений: 3,293 Записей в блоге: 3
	09.06.2019, 12:28
	Насчет cobol не знаю, но фортран Вы зря устаревшим считаете. Прекрасный язык для расчетов, последний стандарт языка 2018 года, и это уже совсем другой мир, нежели тот код который все видели в прошлом веке. Напротив загадка, почему нередко что то используют вместо него, хотя не загадка, привычки и стереотипы все объясняют. 0

@WH 1589 / 817 / 192 Регистрация: 10.09.2013 Сообщений: 3,293 Записей в блоге: 3
	09.06.2019, 19:19
	Curry, холивары как в теме про cobol разводить не буду, нет не времени не желания к этой никому не нужной "виртуальной борьбе". На Ваши аргумены скажу лишь, что в современном фортране все так же гибко как и в любом другом современном ЯП, а наличие встроенных функций никак не портит язык, а скорее напротив делает его удобным, к тому же реализации этих функций уделяется много внимания в отношении их производительности. Сравнение с шарпом и delphi вообще некорректно по целому ряду весьма увесистых причин. Нравится вам шарп или Delphi, пожалуйста, используйте, каждый язык хорош в своей области применения. 0

@Curry Модератор 5165 / 3527 / 536 Регистрация: 01.06.2013 Сообщений: 7,676 Записей в блоге: 9
	09.06.2019, 23:36
	Fulcrum_013, да это ладно. Я видел в их программе большие куски кода которые попали туда неизвестно как и выполнялись впустую, "благо" в фортране не нужно объявлять все переменные, просто все вычисленные в этом коде значения потом затирались или далее не использовались. А на вопрос "зачем это?" был ответ "не знаем, но так работает". 0