Здравствуйте, Nuzhny, Вы писали:
N>Самое главное, что теперь переменные можно объявлять где хочешь, а не в начале блока! Как же это бесило в универе (после с Паскалем дела не имел).
Госсподи!!! И 30 лет не прошло. Это в каком году такое счастье появилось ?
Здравствуйте, Khimik, Вы писали:
K>type K>TVect=record K>x,y,z:double; K>function VectRad:double;//Длина вектора K>function VectRad2:double;//Квадрат длины K>function IsNil:boolean;//Равен ли нулю K>function MinVect:tvect;//Поменять все знаки K>end;
С некоторых пор меня стали сильно удивлять такие имена переменных, функций и классов, для которых нужно тут же писать объясняющий комментарий.
Кто такой VectRad? При чем тут радианы, если речь о длине? Или речь о какой-то радости? MinVect, судя по названию, должен возвращать какой-то минимизированный вектор
Почему бы не сделать так, например:
TVector = record
x, y, z: Double;
function GetLength: Double;
function GetSquareLength: Double;
function IsZeroLength: Boolean;
function InvertAllSigns: TVector;
end;
И выглядит каноничненько и комментарии тут сто лет не нужны
Лучше дать хорошее имя и не экономить на его длине (никакого смысла в такой экономии давно нет), чем через пару месяцев расшифровывать свои же собственные сокращения.
Я как программист скорее непрофессионал, поскольку у меня только один проект — графическая программа для химиков, и последние 15 лет почти не требовалось изучать что-то новое. Кроме того, я привык не пользоваться сторонними библиотеками, а всё пишу сам (например графика в моей программе рисуется без аппаратного ускорения, просто по пикселям программа всё прорисовывает) .
У меня большая часть суждений идет не от конкретных знаний, а скорее от интуиции, и я считаю что конкретно для меня такой принцип работает хорошо (но это отдельная тема).
Я знаю действительно мало конкретики про C++, C#, и это наверно действительно моя проблема, надо наверстать. Мне вот не очень понятно, почему сейчас гораздо чаще пишут на C++ чем на Delphi. По-моему это принципиально достаточно похожие языки, но в C++ многое сложилось исторически как напластование рудиментов, а Delphi всё гораздо красивее. Сейчас мне кажется, что основная причина упадка Delphi – мало библиотек и нет нормальной поддержки Linux и Android/Ios.
Вот три темы на gamedev.ru. Мне кажется тут видно, что среди них довольно многие пишут на Delphi:
В последней теме есть ссылки на бенчмарки Delphi vs C++, и написали что сейчас вроде по скорости Delphi не должен ему уступать.
AG>* Поддержка .Net
А тут можно поконкретнее? Это есть в Delphi XE8?
.net это байт-код, я правильно понимаю? А можно написать этот код и перекомпилировать на Linux?
P>ну а какие игры из более-менее популярных написаны на Дельфи?
Это надо спросить на gamedev.ru, а я там не особо читаю, скорее я писатель)
P>вот ты, например, что и для кого (без имен) на Дельфи пишешь?
p.s. химиков много, а я один)
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Khimik, Вы писали:
K> Я знаю действительно мало конкретики про C++, C#, и это наверно действительно моя проблема, надо наверстать. Мне вот не очень понятно, почему сейчас гораздо чаще пишут на C++ чем на Delphi. По-моему это принципиально достаточно похожие языки, но в C++ многое сложилось исторически как напластование рудиментов, а Delphi всё гораздо красивее.
Это у тебя совсем не верное представление о языках и их похожести. На самом деле схема такая:
— Язык Pascal (который древний, без всяких префиксов) с точностью до синтаксических мелочей равен по возможностям языку C. Оба языка почти не развиваются в данное время (хотя C всё же чуть лучше чувствует в этом смысле). При этом C используется очень много где, а про чистый Паскаль я давно не слышал.
— В середине 90-ых язык Borland Pascal (ранее Turbo Pascal) был приблизительно равен по возможностям языку C++ . Но ветка развития Turbo Pascal остановилась в этих самых 90-ых, а C++ активно развивался все эти годы, так что сейчас никакого сравнения естественно быть не может. Однако если бы тогда Borland не слил это направление и его продолжили активно развивать, то возможно это был бы равный C++ конкурент. Потенциал во всяком случае был, но этого не случилось — полностью умерло.
— а вот язык Delphi (в девичестве Object Pascal) относится совсем к другой категории языков (рефлексия, динамика, подсчёт ссылок, свойства и т.п.) и из семейства C-подобных напоминает большего всего убогий Objective-C с небольшой примесью VisualBasic (в смысле RAD возможностей).
Ну а C# это уже третья категория языков (виртуальная машина, байт-код, сборщик мусора и т.д и т.п.), который является копией Java, а в семействе языков Pascal никого похожего нет (портирование Паскаля под JVM/.Net естественно не считаем — это вообще другие языки выходят).
Так вот эти три категории языков принципиально разные (причём я совсем не про синтаксис говорю!) и применяются для совсем разных целей.
K>Сейчас мне кажется, что основная причина упадка Delphi – мало библиотек и нет нормальной поддержки Linux и Android/Ios.
Основная причина упадка Delphi в том, что эта платформа была хороша только для очень узкой категории ПО: только десктоп, только винда, желательно что-нибудь с кучей формочек и без требования производительности. Сейчас же сами десктопные приложения в упадке на массовом рынке и используется преимущественно профессионалами (всяческие CAD'ы и т.п., требующее производительность и 3D графику, причём ещё желательно кроссплатформенно, т.е. опять же не для Delphi). А основной рынок переехал в веб и на мобилки.
K> В последней теме есть ссылки на бенчмарки Delphi vs C++, и написали что сейчас вроде по скорости Delphi не должен ему уступать.
Здравствуйте, Alexander G, Вы писали:
AG>Завязал тоже с семёрки, краем глаза слежу. AG>* Поддержка .Net AG>* Поддержка Unicode и x64, сильно позже чем нужно было, ну хоть когда то AG>* Дополнения языка Object Pascal/Delphi: шаблоны (generics), структуры (record) с методами, и прочие фичи языка
Самое главное, что теперь переменные можно объявлять где хочешь, а не в начале блока! Как же это бесило в универе (после с Паскалем дела не имел).
Здравствуйте, Alexander G, Вы писали:
AG>Здравствуйте, 129912, Вы писали:
1>>Расскажи, а? А то я последнее с чем работал — это D7, давно дело было. А что сейчас?
AG>Завязал тоже с семёрки, краем глаза слежу. AG>* Поддержка .Net
Нет там поддержки .Net. Это были попытки сделать в 2005/2006 делфе, но потом все загнулось.
Расскажи, а? А то я последнее с чем работал — это D7, давно дело было. А что сейчас? Веб сайт на Дельфе можно сделать?
Кстати, вот придумал идею: визуальный html-js-php редактор с компонентами по типу дельфового. Т.е. помещаешь на формочке компоненты, тыкаешь мышкой, вбиваешь свойства и события, пишешь немножко кода — и прототип сайта готов. Времени тратится не два-три дня, а два-три часа. Для всяких стартапов — самое оно.
Здравствуйте, 129912, Вы писали:
1>Кстати, вот придумал идею: визуальный html-js-php редактор с компонентами по типу дельфового. Т.е. помещаешь на формочке компоненты, тыкаешь мышкой, вбиваешь свойства и события, пишешь немножко кода — и прототип сайта готов.
Это было даже в упомянутом Delphi 7 — см IntraWeb. Ну и были другие реализации.
Здравствуйте, 129912, Вы писали:
1>Расскажи, а? А то я последнее с чем работал — это D7, давно дело было. А что сейчас?
Завязал тоже с семёрки, краем глаза слежу.
* Поддержка .Net
* Поддержка Unicode и x64, сильно позже чем нужно было, ну хоть когда то
* Дополнения языка Object Pascal/Delphi: шаблоны (generics), структуры (record) с методами, и прочие фичи языка
Всё равно не вернусь, даже не только потому, что проектов нет, С++ теперь более родной.
(Хотя билдер можно было бы, но тут уже упираемся в "проектов нет")
Здравствуйте, Khimik, Вы писали:
K>Я тут не понимаю. Почему код на C++ более компактен и лучше читаем?
Потому что вся логика реализуется в более понятных абстракциях. Перегрузка арифметических операций позволяет писать единообразный код для перемножения и сложения матриц, векторов, скаляров. Не надо помнить, какие там функции для этого (типа MatMulToVect(M, V)), а писать просто: M * V.
Самое крутое, что можно в таком стиле писать большие выражения, а они уже будут вычисляться не по частям, а как единое целое. Так умеет Eigen, OpenCV и множество других библиотек.
Здравствуйте, Khimik, Вы писали:
K>Найдите мне на rsdn пост мыщъх-а, где он писал, что в США серьёзные компании переходят с C++ на C. Был же вроде такой пост...
Он чего только не писал, нет смысла доверять всему. Про С/С++ было например здесь
Здравствуйте, Lazy Bear, Вы писали:
LB>>> function GetSquareLength: Double; Ops>>Все равно непонятно. LB>Ваши предложения?
Так ведь не "длина квадрата" же, а "квадрат длины" — LengthSquared, конечно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, paradoks, Вы писали:
P>а мне например глубоко наплевать куда складывает, мне важно, что на андроид работает, в гугл плэй принимают
А мне нет, потому что работаю над кодом не один. Да даже если один — первый же бранч (и последующий мёрж при параллельных изменениях в бранче и мастере) покажет тупиковость этого подхода. Как это уже было для бинарного TLB, для которого с грехом пополам прикрутили ещё и поддержку текстовой IDL, и то костыльно; из той же серии компонент TImageList и прочая и прочая.
Здравствуйте, 129912, Вы писали:
1>Расскажи, а? А то я последнее с чем работал — это D7, давно дело было. А что сейчас? Веб сайт на Дельфе можно сделать?
1>Кстати, вот придумал идею: визуальный html-js-php редактор с компонентами по типу дельфового. Т.е. помещаешь на формочке компоненты, тыкаешь мышкой, вбиваешь свойства и события, пишешь немножко кода — и прототип сайта готов. Времени тратится не два-три дня, а два-три часа. Для всяких стартапов — самое оно.
Здравствуйте, 129912, Вы писали:
1>Расскажи, а? А то я последнее с чем работал — это D7, давно дело было. А что сейчас? Веб сайт на Дельфе можно сделать?
1>Кстати, вот придумал идею: визуальный html-js-php редактор с компонентами по типу дельфового. Т.е. помещаешь на формочке компоненты, тыкаешь мышкой, вбиваешь свойства и события, пишешь немножко кода — и прототип сайта готов. Времени тратится не два-три дня, а два-три часа. Для всяких стартапов — самое оно.
Это уже было еще до Embarcadero, так и называлось Delphi for PHP
Здравствуйте, Khimik, Вы писали:
K>Мне вот не очень понятно, почему сейчас гораздо чаще пишут на C++ чем на Delphi. По-моему это принципиально достаточно похожие языки, но в C++ многое сложилось исторически как напластование рудиментов, а Delphi всё гораздо красивее. Сейчас мне кажется, что основная причина упадка Delphi – мало библиотек и нет нормальной поддержки Linux и Android/Ios.
Всё не так, Делфи исторически предназначался для написания десктопных программ под Windows, в том числе интерфейсов. Из этой области Делфи и С++ выпер .Net + C#. С++ и Делфи мало конкурировали.
Мне как-то давно (год 2005 или около того) надо было написать диплом для девочки по машинной графике на Делфи. Как раз твоя область: всякое 3D без применения аппаратного ускорения, а пиксели ручками. Это было настоящее мучение, потому что не было шаблонов и аналогов STL. Поначалу я просто не понимал, как на этом языке что-то писать. Грубо говоря, на С++ быстренькой реализовывались классы матриц и векторов, перегрузить арфметические операторы, для коллекций использовать STL. А на Делфи это был ужасный кустарный код, полный велосипедов. Допускаю, что я за неделю не успел нормально изучить язык, но всё равно уверен, что такого компактного и при этом хорошо читаемого кода, как на С++, получить бы мне не удалось принципиально.
Здравствуйте, Nuzhny, Вы писали:
N>Грубо говоря, на С++ быстренькой реализовывались классы матриц и векторов, перегрузить арфметические операторы, для коллекций использовать STL. А на Делфи это был ужасный кустарный код, полный велосипедов. Допускаю, что я за неделю не успел нормально изучить язык, но всё равно уверен, что такого компактного и при этом хорошо читаемого кода, как на С++, получить бы мне не удалось принципиально.
Это так, на Delphi сложно писать программу, которая что-либо считает
Вот, кстати, темы Химика вполне иллюстрируют проблему
N>>Грубо говоря, на С++ быстренькой реализовывались классы матриц и векторов, перегрузить арфметические операторы, для коллекций использовать STL. А на Делфи это был ужасный кустарный код, полный велосипедов. Допускаю, что я за неделю не успел нормально изучить язык, но всё равно уверен, что такого компактного и при этом хорошо читаемого кода, как на С++, получить бы мне не удалось принципиально.
AG>Это так, на Delphi сложно писать программу, которая что-либо считает
Че-то у вас не те претензии к Delphi
Операторы там перегружаются, коллекции какие-никакие есть. С читаемостью же, имхо, все очень не плохо.
Очень мгогословно и многих штук нет (есть ли Linq уже?), но это с некоторых сторон даже плюс к читаемости.
Вот что бы я очень хотел попробовать в C# (перед тем как сказать, что это нужно ) это отдельно объявление и реализацию классов. С секциями private, public, как в Паскале.
Может это у меня деформация, потому что первый язык был Pascal и потом много писал на/в Delphi (не формы, как раз расчеты и инженерную грфику), но до сих пор, когда приходится подглядывать в старые делфийские исходники, восхищаюсь, как же прикольно их читать (но не писать! )
Здравствуйте, elmal, Вы писали:
N>>Самое главное, что теперь переменные можно объявлять где хочешь, а не в начале блока! Как же это бесило в универе (после с Паскалем дела не имел). E>Госсподи!!! И 30 лет не прошло. Это в каком году такое счастье появилось ?
Здравствуйте, Nuzhny, Вы писали:
N>Кажется, в 2018
Однако. Может там еще и стандартная библиотека нормальная появилась? Коллекции там нормальные, всякие мапы, поддержка многопоточности?
Здравствуйте, ylem, Вы писали:
Y>Че-то у вас не те претензии к Delphi Y>Операторы там перегружаются, коллекции какие-никакие есть. С читаемостью же, имхо, все очень не плохо.
Это ещё старые претензии. С другой стороны, все эти плюшки стали появляться только недавно.
Перегрузка операторов в каком году? Судя по логу, в 2013-м году это работало только для Андроида. А на десктопе?
Объявление переменных в месте использования в 2018.
А коллекции с произвольными типами когда появились?
Y>Может это у меня деформация, потому что первый язык был Pascal и потом много писал на/в Delphi (не формы, как раз расчеты и инженерную грфику), но до сих пор, когда приходится подглядывать в старые делфийские исходники, восхищаюсь, как же прикольно их читать (но не писать! )
У меня тоже Паскаль (школьный Бейсик не считается). Потом с огромным удовольствием перелез на С++ и так и не слез.
Здравствуйте, elmal, Вы писали:
e> N>Кажется, в 2018
e> Однако. Может там еще и стандартная библиотека нормальная появилась? Коллекции там нормальные, всякие мапы, поддержка многопоточности?
Здравствуйте, elmal, Вы писали:
E>Однако. Может там еще и стандартная библиотека нормальная появилась? Коллекции там нормальные, всякие мапы, поддержка многопоточности?
Класс TThread появился ещё в Delphi2, если память не изменяет. Так что, многопоточность завезена давно и достаточно удобно (если не считать этого мега-костыляки Synchronize, который все радостно начинают пихать сразу после прочтения мануала).
Здравствуйте, elmal, Вы писали:
E> поддержка многопоточности?
Я что-то многопоточное да дельфе делал году в 1999-м, все там было. До этого в основном под ДОС писал, поэтому настоящая многопоточность была мне тогда в диковинку.
Здравствуйте, D. Mon, Вы писали:
DM>Я что-то многопоточное да дельфе делал году в 1999-м, все там было. До этого в основном под ДОС писал, поэтому настоящая многопоточность была мне тогда в диковинку.
А что там удивительного? Учитывая, что это было лишь обёрткой над winapi'шным CreateThread.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, ylem, Вы писали:
Y>>Че-то у вас не те претензии к Delphi Y>>Операторы там перегружаются, коллекции какие-никакие есть. С читаемостью же, имхо, все очень не плохо.
N>Это ещё старые претензии. С другой стороны, все эти плюшки стали появляться только недавно.
N>Перегрузка операторов в каком году? Судя по логу, в 2013-м году это работало только для Андроида. А на десктопе?
Перегрузка операторов для винды где-то 2005-2007
В Delphi.Net раньше
N>Объявление переменных в месте использования в 2018.
Малонужная вещь, иногда полезная
N>А коллекции с произвольными типами когда появились?
>Допускаю, что я за неделю не успел нормально изучить язык, но всё равно уверен, что такого компактного и при этом хорошо читаемого кода, как на С++, получить бы мне не удалось принципиально.
Я тут не понимаю. Почему код на C++ более компактен и лучше читаем?
>А на Делфи это был ужасный кустарный код, полный велосипедов.
А здесь мне всё понятно. Действительно, я профессиональный велосипедист), и мне всегда было проще придумать алгоритм самому, чем искать сторонние библиотеки.
Я вот думаю, если на Delphi главная проблема — нехватка библиотек, может дельфисты из России захотят объединиться и обмениваться библиотеками? Я планирую написать об этом на геймдеве.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Alexander G, Вы писали:
AG>Здравствуйте, Nuzhny, Вы писали:
N>>Грубо говоря, на С++ быстренькой реализовывались классы матриц и векторов, перегрузить арфметические операторы, для коллекций использовать STL. А на Делфи это был ужасный кустарный код, полный велосипедов. Допускаю, что я за неделю не успел нормально изучить язык, но всё равно уверен, что такого компактного и при этом хорошо читаемого кода, как на С++, получить бы мне не удалось принципиально.
AG>Это так, на Delphi сложно писать программу, которая что-либо считает
AG>Вот, кстати, темы Химика вполне иллюстрируют проблему
AG>https://rsdn.org/forum/philosophy/7306082.1
K>Я вот думаю, если на Delphi главная проблема — нехватка библиотек, может дельфисты из России захотят объединиться и обмениваться библиотеками? Я планирую написать об этом на геймдеве.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, Khimik, Вы писали:
K>>Мне вот не очень понятно, почему сейчас гораздо чаще пишут на C++ чем на Delphi. По-моему это принципиально достаточно похожие языки, но в C++ многое сложилось исторически как напластование рудиментов, а Delphi всё гораздо красивее. Сейчас мне кажется, что основная причина упадка Delphi – мало библиотек и нет нормальной поддержки Linux и Android/Ios.
N>Всё не так, Делфи исторически предназначался для написания десктопных программ под Windows, в том числе интерфейсов. Из этой области Делфи и С++ выпер .Net + C#. С++ и Делфи мало конкурировали. N>Мне как-то давно (год 2005 или около того) надо было написать диплом для девочки по машинной графике на Делфи. Как раз твоя область: всякое 3D без применения аппаратного ускорения, а пиксели ручками. Это было настоящее мучение, потому что не было шаблонов и аналогов STL. Поначалу я просто не понимал, как на этом языке что-то писать. Грубо говоря, на С++ быстренькой реализовывались классы матриц и векторов, перегрузить арфметические операторы, для коллекций использовать STL. А на Делфи это был ужасный кустарный код, полный велосипедов. Допускаю, что я за неделю не успел нормально изучить язык, но всё равно уверен, что такого компактного и при этом хорошо читаемого кода, как на С++, получить бы мне не удалось принципиально.
Мдя, я тут неделю назад начал осваивать сноуборд, и при прыжках с трамплина почему-то падаю, хотя на горных лыжах умею это уже 20 лет.
Здравствуйте, swame, Вы писали:
S>Мдя, я тут неделю назад начал осваивать сноуборд, и при прыжках с трамплина почему-то падаю, хотя на горных лыжах умею это уже 20 лет.
Ещё хуже: сноуборд пришлось предварительно самому выстругать из доски.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, swame, Вы писали:
S>>Мдя, я тут неделю назад начал осваивать сноуборд, и при прыжках с трамплина почему-то падаю, хотя на горных лыжах умею это уже 20 лет.
N>Ещё хуже: сноуборд пришлось предварительно самому выстругать из доски.
Ну поскольку за неделю блужданий в горах не удалось найти магазин со сноубордами пришлось выстругать из елки.
А может так и надо было по замыслу диплома
Здравствуйте, Nuzhny, Вы писали:
DM>>Я что-то многопоточное да дельфе делал году в 1999-м, все там было. До этого в основном под ДОС писал, поэтому настоящая многопоточность была мне тогда в диковинку.
N>А что там удивительного? Учитывая, что это было лишь обёрткой над winapi'шным CreateThread.
Да просто очень непривычно после ДОСа-то однозадачного.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, Khimik, Вы писали:
K>>Я тут не понимаю. Почему код на C++ более компактен и лучше читаем?
N>Потому что вся логика реализуется в более понятных абстракциях. Перегрузка арифметических операций позволяет писать единообразный код для перемножения и сложения матриц, векторов, скаляров. Не надо помнить, какие там функции для этого (типа MatMulToVect(M, V)), а писать просто: M * V. N>Самое крутое, что можно в таком стиле писать большие выражения, а они уже будут вычисляться не по частям, а как единое целое. Так умеет Eigen, OpenCV и множество других библиотек.
Ну вот в Delphi XE8 есть рекорды с процедурами и функциями. По-моему, их можно назвать статическими классами.
Скажем, есть у меня рекорд — вектор (три координаты):
type
TVect=record
x,y,z:double;
function VectRad:double;//Длина вектора
function VectRad2:double;//Квадрат длины
function IsNil:boolean;//Равен ли нулю
function MinVect:tvect;//Поменять все знаки
end;
Так что в коде можно писать, например:
CurRadius:=myvector1.VectRad;
На самом деле, я только начал понемногу переписывать старый дерьмокод, который писал без этих возможностей. Для суммы векторов у меня пока есть функция:
function SumVects(vect1,vect2:tvect):tvect;
begin
result.x:=vect1.x+vect2.x;
result.y:=vect1.y+vect2.y;
result.z:=vect1.z+vect2.z;
end;
Когда дойдут руки, заменю её на это:
TVect=record
...
class operator Add(self, othervect:tvect):tvect;
end;
И можно будет в коде писать так:
MyVector3:=MyVector1+MyVector2;
Хотя уже на этом примере видно, что такой подход далеко не всегда применим: скажем, умножать два вектора можно по-разному (скалярное или векторное умножение).
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Khimik, Вы писали:
K> Я как программист скорее непрофессионал, поскольку у меня только один проект — графическая программа для химиков
Кстати а что за программа, если не секрет? Химическое моделирование? Насколько глубоко нужно знать химию чтобы такую написать? Много ли конкурентов?
Я вот думаю (в связи со спорами с Shmj о происхождении жизни, и также с некоторыми высказываниями в соцсетях), может ознакомиться с областью софтостроения в органической химии и биологии...
Нет такого преступления, на которое не пошло бы суверенное родоплеменное быдло ради продления своего бессмысленного рода и распространения своего бессмысленного генома.
K>Хотя уже на этом примере видно, что такой подход далеко не всегда применим: скажем, умножать два вектора можно по-разному (скалярное или векторное умножение).
Согласен, выражение реальной математики в виде перегруженных операторов ограничивается малым числом операторов в программировании, в которые можно отобразить математические символы, которых намного больше. Получается только +, -, частично *, /.
Я писал с использованием перегрузок большую библиотеку для 2D графики, там например нужно четко проводить границу между вычислениями с плавающей точкой и целочисленными вычислениями, это далеко от математических формул.
Все равно получаются цепочки вызовов функций типа такого
Оператор сложения для массивов векторов просто побоялся написать — что он будет означать — объединить эти массивы в один один за другим или попарно сложить в них точки?
Здравствуйте, D. Mon, Вы писали:
DM>Я что-то многопоточное да дельфе делал году в 1999-м, все там было. До этого в основном под ДОС писал, поэтому настоящая многопоточность была мне тогда в диковинку.
Дело не просто в многопоточности. А примитивы синхронизации, какие то гарантии при конкуррентном обращении к области памяти, всякие атомарные операции, барьеры и тому подобное. Плюс легкое распараллеливание, всякие пулы потоков и тому подобное. Или это все ручками нужно лисапедить по прежнему?
Здравствуйте, anonymouse2, Вы писали:
A>Кстати а что за программа, если не секрет? Химическое моделирование? Насколько глубоко нужно знать химию чтобы такую написать? Много ли конкурентов? A>Я вот думаю (в связи со спорами с Shmj о происхождении жизни, и также с некоторыми высказываниями в соцсетях), может ознакомиться с областью софтостроения в органической химии и биологии...
anonymouse2, а давайте обмен — услуга за услугу? Найдите мне на rsdn пост мыщъх-а, где он писал, что в США серьёзные компании переходят с C++ на C. Был же вроде такой пост...
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, D. Mon, Вы писали:
DM>>Я что-то многопоточное да дельфе делал году в 1999-м, все там было. До этого в основном под ДОС писал, поэтому настоящая многопоточность была мне тогда в диковинку. E>Дело не просто в многопоточности. А примитивы синхронизации, какие то гарантии при конкуррентном обращении к области памяти, всякие атомарные операции, барьеры и тому подобное. Плюс легкое распараллеливание, всякие пулы потоков и тому подобное. Или это все ручками нужно лисапедить по прежнему?
async/await там нет и близко. Есть threadvar. Пула потоков еще пару лет назад не было. Есть сторонние реализации, но на то они и сторонние, что качество и вероятность развития не известны.
Реально Делфи пригоден только для разработки десктопного софта под виндовс. Но эта ниша полностью перекрывается C#+WiunForms/WPF.
Здравствуйте, Khimik, Вы писали:
K>На самом деле, я только начал понемногу переписывать старый дерьмокод, который писал без этих возможностей. Для суммы векторов у меня пока есть функция:
K>function SumVects(vect1,vect2:tvect):tvect; K>begin K>result.x:=vect1.x+vect2.x; K>result.y:=vect1.y+vect2.y; K>result.z:=vect1.z+vect2.z; K>end;
K>Когда дойдут руки, заменю её на это:
K>TVect=record K>... K>class operator Add(self, othervect:tvect):tvect; K>end;
K>И можно будет в коде писать так:
K>MyVector3:=MyVector1+MyVector2;
Да! Как раз так и надо писать.
Но С++ всё таки умеет больше, например, expression templates в том же Eigen может оптимизировать матричные операции на этапе компиляции, объединяя их в одно выражение. Это позволяет писать математическую логику очень оптимально и при этом очень читабельно.
K>Хотя уже на этом примере видно, что такой подход далеко не всегда применим: скажем, умножать два вектора можно по-разному (скалярное или векторное умножение).
Умножать можно только одним способом, рассматривая вектора, как одномерные матрицы. Векторное и скалярное произведения уже не должны кодироваться арифметическими операциями.
_>Основная причина упадка Delphi в том, что эта платформа была хороша только для очень узкой категории ПО: только десктоп, только винда, желательно что-нибудь с кучей формочек и без требования производительности.
L>2) Дельфи прекрасно делает все что надо для Андроид, отличные очень быстрые приложения L>потому что в этой RAD C++ и Паскаль компилятся в машинные коды
Это вы про Firemonkey? Так он вроде совершенно глючный.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
K>Ну вот в Delphi XE8 есть рекорды с процедурами и функциями. По-моему, их можно назвать статическими классами. K>Скажем, есть у меня рекорд — вектор (три координаты):
А теперь сравни вот с этим https://glm.g-truc.net/0.9.9/index.html
сразу все что можно и нельзя из коробки с вариациями 2,3,4 координаты double/float и поддержкой полного набора векторной алгебры включая кватернионы и SSE.
Все header only. делаешь git clone себе в подкаталог и инклудишь. Оттестированный кучей народу набор классов готов к работе.
Или потратить неделю другую чтобы получить велосипед с кривыми колесами.
По поводу Embarcadero с++ 10 Seattle/Berlin — остался один раритетный проект на нем, страшная дрянь. Чтобы было понятно- штатный линкер содержит ошибку которая рандомно вышибает его в x64 системах при сборке. И решаеться это сторонней кривой утилитой которую приспособил посторонний человек, официального фикса нет много лет.Для поддержки x64 и С++11 вкорячили clang доработанный напильником, но компоненты на версии Seattle, оно собирать не умеет, багфикс есть в рамках платной поддержки которая стоит в год как половина лицензии, а лицензия как 10 Visual Studio. В общем в этом году переписали один проект, еще через пару добьем последний, и тожественно и с плясками сожжем лицензию на этот кусок субстанции.
Здравствуйте, Khimik, Вы писали:
L>>2) Дельфи прекрасно делает все что надо для Андроид, отличные очень быстрые приложения L>>потому что в этой RAD C++ и Паскаль компилятся в машинные коды
K>Это вы про Firemonkey? Так он вроде совершенно глючный.
это что за бред из 19 века?!
уже много лет ничего нигде не глючит и прекрасно работает, года 3 как использую для андроид не вижу никаких глюков
да и вы просто скачайте Дельфи и убедитесь что сделать средней сложности андроид апликуху займет 5 минут и ничего нигде не глючит
ну ладно не буду рекламировать, мне не платят да и в принципе меньше народу больше кислороду
K>>type K>>TVect=record K>>x,y,z:double; K>>function VectRad:double;//Длина вектора K>>function VectRad2:double;//Квадрат длины K>>function IsNil:boolean;//Равен ли нулю K>>function MinVect:tvect;//Поменять все знаки K>>end;
LB>С некоторых пор меня стали сильно удивлять такие имена переменных, функций и классов, для которых нужно тут же писать объясняющий комментарий. LB>Кто такой VectRad? При чем тут радианы, если речь о длине? Или речь о какой-то радости? MinVect, судя по названию, должен возвращать какой-то минимизированный вектор
LB>Почему бы не сделать так, например:
LB>
LB>TVector = record
LB> x, y, z: Double;
LB> function GetLength: Double;
LB> function GetSquareLength: Double;
LB> function IsZeroLength: Boolean;
LB> function InvertAllSigns: TVector;
LB>end;
LB>
LB>И выглядит каноничненько и комментарии тут сто лет не нужны
LB>Лучше дать хорошее имя и не экономить на его длине (никакого смысла в такой экономии давно нет), чем через пару месяцев расшифровывать свои же собственные сокращения.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Lazy Bear, Вы писали:
LB>>Здравствуйте, Ops, Вы писали:
LB>>>>
LB>>>> function GetSquareLength: Double;
LB>>>>
Ops>>>Все равно непонятно.
LB>>Ваши предложения?
Ops>Если это квадрат длины (единственный на мой взгляд осмысленный вариант), то он внутри класса не нужен.
Предлагаю подумать самостоятельно, для чего нужна эта функция.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Lazy Bear, Вы писали:
LB>Здравствуйте, Khimik, Вы писали:
LB>С некоторых пор меня стали сильно удивлять такие имена переменных, функций и классов, для которых нужно тут же писать объясняющий комментарий. LB>Кто такой VectRad? При чем тут радианы, если речь о длине? Или речь о какой-то радости? MinVect, судя по названию, должен возвращать какой-то минимизированный вектор
LB>Почему бы не сделать так, например:
LB>
LB>TVector = record
LB> x, y, z: Double;
LB> function GetLength: Double;
LB> function GetSquareLength: Double;
LB> function IsZeroLength: Boolean;
LB> function InvertAllSigns: TVector;
LB>end;
LB>
LB>И выглядит каноничненько и комментарии тут сто лет не нужны
LB>Лучше дать хорошее имя и не экономить на его длине (никакого смысла в такой экономии давно нет), чем через пару месяцев расшифровывать свои же собственные сокращения.
То они требуют перегрузку операторов, то сразу убивают достигнутую с их помощью читаемость длиннющими названиями, заставляющими тратить мозг при чтении и так сложных формул на всякие мусорные GetXXXXXXXXXXXXXXXXXXX. Выучить несколько деcятсков коротких операторов на 3-4 когда копаещься в большой библиотеки матана несложно, зато разбирать потом код потом легче. Ну конечно эти короткие выражения должны нести какой то смысл.
Вот пример из моей библиотеки. Сейчас бы я сократил кое -какие операторы
THPointF = record helper for TFloatPoint
private
function GetLen: Double;
procedure SetLen(const Value: Double);
function GetStr: string;
procedure SetStr(const Value: string);
function GetStrC: string;
public
constructor Create (const SX, SY: string); overload;
function Px2Sx (K: single=1.0): TSxPoint; overload;
function Sx2Px (K: single=1.0): TPxPoint; overload;
function Px2Sp (K: single=1.0): TPoint; overload;
function Sx2Pp (K: single=1.0): TPoint; overload;
function Presise (const P2 : TPointF; Epsilon: Single=FLOATPOINT_ACCURACY): boolean;
function IsHor (Epsilon: Single=FLOATPOINT_ACCURACY) : boolean; overload;
function IsVert (Epsilon: Single=FLOATPOINT_ACCURACY) : boolean; overload;
function IsOrtho (Epsilon: Single=FLOATPOINT_ACCURACY) : boolean; overload;
function IsHor (const P2 : TPointF; Epsilon: Single=FLOATPOINT_ACCURACY) : boolean; overload;
function IsVert (const P2 : TPointF; Epsilon: Single=FLOATPOINT_ACCURACY) : boolean; overload;
function IsOrtho (const P2 : TPointF; Epsilon: Single=FLOATPOINT_ACCURACY) : boolean; overload;
function Neg: TPointF;
function DistFast(const P2 : TPointF) : Double;
function Mul(K: single): TPointF;
function RoundF: TPointF;
function GP: TGPPointF;
function AlignDif: TFloatPoint;
function IsAligned: boolean;
function Scalar(const P2 : TPointF): Double;
function PseudoScalar(const P2 : TPointF): Double;
function ColLinear(const P2 : TPointF; Epsilon: Single=FLOATPOINT_ACCURACY): boolean;
function RotateD (Angle: single; const CP: TFloatPoint): TFloatPoint; overload;
function RotateD (Angle: single): TFloatPoint; overload;
function RotateR (Angle: single; const CP: TFloatPoint): TFloatPoint; overload;
function RotateOrient(Orient: integer): TFloatPoint; overload;
function RotateOrient(Orient: integer; const CP: TFloatPoint): TFloatPoint; overload;
function RotateR (Angle: single): TFloatPoint; overload;
procedure Mirror;
function MirrorTo (bMirror: boolean=true): TFloatPoint;
function OffsetTo(const DX, DY: Single): TFloatPoint; overload;
function OffsetTo(const Point: TPointF): TFloatPoint; overload;
function OffsetTo(const Size: TSize): TFloatPoint; overload;
function AngleD (const Center: TPointF): single;
function AngleR (const Center: TPointF): single;
function SetLenRes(const Value: Double): boolean;
function Interpolation(const P2 : TPointF; K: single): TPointF;
{точка на расстоянии ALength от начала}function VectorByLength (const P2 : TPointF; ALength: single): TPointF;
function Middle(const P2: TFloatPoint): TFloatPoint;
function Arctan2D (K: single = 1): single;
function Arctan2R (K: single = 1): single;
procedure StrXY (out SX, SY: string);
property Len: Double read GetLen write SetLen;
property Str: string read GetStr write SetStr;
property StrС: string read GetStrC write SetStr;
end;
TFloatEllipseArc = record
const
YNOT_X : double = 1;
private
function PA (A: single): TFloatPoint;
function GoldenDistanceP(const P: TFloatPoint; AR1, AR2: single; var NearestP: TFloatPoint): single;
function ApproximateAngle (A1, A2: single): TPolygon;
public
R: TFloatRect; //границы
P3, P4: TFloatPoint; //концы
bClockWise: boolean; //по часововй стрелкеconstructor Create (const AR: TFloatRect; const AP3, AP4: TFloatPoint; AClockWise: boolean = false);
constructor CreateEllipse (const AR: TFloatRect); overload;
constructor CreateEllipse (const AR: TRect); overload;
function Perimeter: double; //вычисление полного периметраfunction ah: double;
function bh: double;
function IsCircle: boolean;
function IsZero: boolean;
function Len: double;
function CantrellQuater: double;
function Salter (a, b, alpha: double): double;
function Salter1 (a, b, alpha: double): double;
function Len_Integral (a, b, alpha: double): double;
function LengthP (const P: TFloatPoint): double; //длина от начала до заданной точкиfunction CrossRay (const P: TFloatPoint): TFloatPoint;
function CrossArc (const Arc: TFloatEllipseArc; var CP: TPolygon): integer;
function CrossEllipse (const Ellipse: TRectF; var CP: TPolygon): integer;
function CrossEllipseEllipse (const Ellipse: TRectF; var CP: TPolygon): integer;
function CrossEllipseEllipse1 (const Ellipse: TRectF; var CP: TPolygon): integer;
function CrossPolygonEllipse (const Polygon: TPolygon; const Ellipse: TRectF; var CP: TPolygon): integer;
function CrossPolygonArc (const Polygon: TPolygon; Arc: TFloatEllipseArc; var CP: TPolygon): integer;
function Tangential(const P: TFloatPoint): TFloatPoint;
function Approximate: TPolygon;
function ApproximateEllipse: TPolygon;
function LengthPCircle (const P: TFloatPoint): double; //длина от начала до заданной точки в любом направленииfunction PointDistantly (D: single): TFloatPoint; //точка на расстоянии D от начала (P3) вдоль дугиfunction Contains (const P: TFloatPoint; Epsilon: Single=FLOATPOINT_ACCURACY): boolean;
function ContainsCircle (const P: TFloatPoint; Epsilon: Single=FLOATPOINT_ACCURACY): boolean;
function DistanceP(const P: TFloatPoint; var NearestP: TFloatPoint): single;
function DistanceCircleP(const P: TFloatPoint; var NearestP: TFloatPoint): single;
function Bounds: TFloatRect;
end;
Здравствуйте, swame, Вы писали:
LB>>Лучше дать хорошее имя и не экономить на его длине (никакого смысла в такой экономии давно нет), чем через пару месяцев расшифровывать свои же собственные сокращения.
S>То они требуют перегрузку операторов, то сразу убивают достигнутую с их помощью читаемость длиннющими названиями, заставляющими тратить мозг при чтении и так сложных формул на всякие мусорные GetXXXXXXXXXXXXXXXXXXX. Выучить несколько деcятсков коротких операторов на 3-4 когда копаещься в большой библиотеки матана несложно, зато разбирать потом код потом легче. Ну конечно эти короткие выражения должны нести какой то смысл.
Речь не о длинных или коротких именах, а о понятных. Подбирать удачные имена — не важно, длинные или короткие — не такая уж простая задача.
Постоянно вижу у коллег неоднозначные названия на code review. Спрашиваю — что оно у тебя делает? — Вот это. — Так назови же соответствующим образом, например ХХХХХХХ. Так лучше? — Да, гораздо лучше!
Но в следующий раз будет опять то же самое
Меж прочим, Orient (англ) — Восток. А где тогда у тебя Occident?
А если имеется в виду Orientation, то какие допустимые возвращаемые значения? 0|1, или градусы, или радианы, или что-то свое?
S>Вот пример из моей библиотеки. Сейчас бы я сократил кое -какие операторы
Вот, сократи VectorByLength до VecByLen. Мощная экономия получится в эпоху code completion
LB>>И выглядит каноничненько и комментарии тут сто лет не нужны
LB>>Лучше дать хорошее имя и не экономить на его длине (никакого смысла в такой экономии давно нет), чем через пару месяцев расшифровывать свои же собственные сокращения.
S>То они требуют перегрузку операторов, то сразу убивают достигнутую с их помощью читаемость длиннющими названиями, заставляющими тратить мозг при чтении и так сложных формул на всякие мусорные GetXXXXXXXXXXXXXXXXXXX. Выучить несколько деcятсков коротких операторов на 3-4 когда копаещься в большой библиотеки матана несложно, зато разбирать потом код потом легче. Ну конечно эти короткие выражения должны нести какой то смысл. S>Вот пример из моей библиотеки. Сейчас бы я сократил кое -какие операторы S>
S> THPointF = record helper for TFloatPoint
S> private
S> function GetLen: Double;
S> procedure SetLen(const Value: Double);
S> function GetStr: string;
S> procedure SetStr(const Value: string);
S> function GetStrC: string;
S> public
S> constructor Create (const SX, SY: string); overload;
S> function Px2Sx (K: single=1.0): TSxPoint; overload;
S> function Sx2Px (K: single=1.0): TPxPoint; overload;
S> function Px2Sp (K: single=1.0): TPoint; overload;
S> function Sx2Pp (K: single=1.0): TPoint; overload;
S> function Presise (const P2 : TPointF; Epsilon: Single=FLOATPOINT_ACCURACY): boolean;
S> function IsHor (Epsilon: Single=FLOATPOINT_ACCURACY) : boolean; overload;
S> function IsVert (Epsilon: Single=FLOATPOINT_ACCURACY) : boolean; overload;
S> function IsOrtho (Epsilon: Single=FLOATPOINT_ACCURACY) : boolean; overload;
S> function IsHor (const P2 : TPointF; Epsilon: Single=FLOATPOINT_ACCURACY) : boolean; overload;
S> function IsVert (const P2 : TPointF; Epsilon: Single=FLOATPOINT_ACCURACY) : boolean; overload;
S> function IsOrtho (const P2 : TPointF; Epsilon: Single=FLOATPOINT_ACCURACY) : boolean; overload;
S> function Neg: TPointF;
S> function DistFast(const P2 : TPointF) : Double;
S> function Mul(K: single): TPointF;
S> function RoundF: TPointF;
S> function GP: TGPPointF;
S> function AlignDif: TFloatPoint;
S> function IsAligned: boolean;
S> function Scalar(const P2 : TPointF): Double;
S> function PseudoScalar(const P2 : TPointF): Double;
S> function ColLinear(const P2 : TPointF; Epsilon: Single=FLOATPOINT_ACCURACY): boolean;
S> function RotateD (Angle: single; const CP: TFloatPoint): TFloatPoint; overload;
S> function RotateD (Angle: single): TFloatPoint; overload;
S> function RotateR (Angle: single; const CP: TFloatPoint): TFloatPoint; overload;
S> function RotateOrient(Orient: integer): TFloatPoint; overload;
S> function RotateOrient(Orient: integer; const CP: TFloatPoint): TFloatPoint; overload;
S> function RotateR (Angle: single): TFloatPoint; overload;
S> procedure Mirror;
S> function MirrorTo (bMirror: boolean=true): TFloatPoint;
S> function OffsetTo(const DX, DY: Single): TFloatPoint; overload;
S> function OffsetTo(const Point: TPointF): TFloatPoint; overload;
S> function OffsetTo(const Size: TSize): TFloatPoint; overload;
S> function AngleD (const Center: TPointF): single;
S> function AngleR (const Center: TPointF): single;
S> function SetLenRes(const Value: Double): boolean;
S> function Interpolation(const P2 : TPointF; K: single): TPointF;
S> {точка на расстоянии ALength от начала}
S> function VectorByLength (const P2 : TPointF; ALength: single): TPointF;
S> function Middle(const P2: TFloatPoint): TFloatPoint;
S> function Arctan2D (K: single = 1): single;
S> function Arctan2R (K: single = 1): single;
S> procedure StrXY (out SX, SY: string);
S> property Len: Double read GetLen write SetLen;
S> property Str: string read GetStr write SetStr;
S> property StrС: string read GetStrC write SetStr;
S> end;
S>
Поясните пожалуйста, что значит helper for TFloatPoint?
А TFloatPoint — это общее обозначение для single, double, extended? Это обозначение прошито в кишках среды или где-то в конкретном коде?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
K>Поясните пожалуйста, что значит helper for TFloatPoint? K>А TFloatPoint — это общее обозначение для single, double, extended? Это обозначение прошито в кишках среды или где-то в конкретном коде?
TFloatPoint это наш внутренний синоним для TPointF из System.Types,
сложился исторически из времен, когда таких типов в Delphi не было.
Здравствуйте, Mr.Delphist, Вы писали:
MD>если не считать этого мега-костыляки Synchronize, который все радостно начинают пихать сразу после прочтения мануала
А как еще? Врукопашную сообщения слать, или переделывать цикл их обработки в GUI-потоке, дополнительно проверяя кучу разных примитивов?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Lazy Bear, Вы писали:
LB>Речь не о длинных или коротких именах, а о понятных. Подбирать удачные имена — не важно, длинные или короткие — не такая уж простая задача. LB>Постоянно вижу у коллег неоднозначные названия на code review. Спрашиваю — что оно у тебя делает? — Вот это. — Так назови же соответствующим образом, например ХХХХХХХ. Так лучше? — Да, гораздо лучше! LB>Но в следующий раз будет опять то же самое
Так именование сущностей да инвалидация кеша — основные проблемы, остальное все решается куда проще.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Mr.Delphist, Вы писали:
E>>Однако. Может там еще и стандартная библиотека нормальная появилась? Коллекции там нормальные, всякие мапы, поддержка многопоточности?
MD>Класс TThread появился ещё в Delphi2, если память не изменяет. Так что, многопоточность завезена давно и достаточно удобно (если не считать этого мега-костыляки Synchronize, который все радостно начинают пихать сразу после прочтения мануала).
Здравствуйте, loginx, Вы писали:
_>>Основная причина упадка Delphi в том, что эта платформа была хороша только для очень узкой категории ПО: только десктоп, только винда, желательно что-нибудь с кучей формочек и без требования производительности. L>1) В Дельфи есть C++ https://www.embarcadero.com/ru/products/cbuilder
А ты что называешь словом Дельфи то? ) Автор изначально писал про сравнение языков (про C++, C# и т.п.). А ты похоже имел в виду некую IDE или что? )
L>2) Дельфи прекрасно делает все что надо для Андроид, отличные очень быстрые приложения
Т.е. я могу написать одно приложение (с GUI естественно) и оно будет без проблем работать на Android/Windows/iOS/OSX? Скажем на C++ это сейчас без проблем делается...
L>потому что в этой RAD C++ и Паскаль компилятся в машинные коды
Эм, а где это сейчас C++ и Паскаль компилируются не в машинные коды? Не, ну есть конечно WebAssembly, но это отдельная тема, требующая специальных тулчейнов.
L>3) про мало библиотек это откровенный бред, на самом деле их конечно огромное гигантское необозримое кол-во.
Я про мало библиотек ничего не писал, так что не знаю зачем ты мне это пишешь. Однако т.к. Дельфи уже давно не мейнстрим, то подозреваю что и с библиотеками там уже всё печально. Однако я сам не проверял, так что огульно утверждать не буду.
Здравствуйте, Ops, Вы писали:
Ops>А как еще? Врукопашную сообщения слать, или переделывать цикл их обработки в GUI-потоке, дополнительно проверяя кучу разных примитивов?
PostMessage, конечно, ничего в этом не вижу дурного. Тем более что синтаксис Delphi позволяет бесшовно интегрировать класс в цикл обработки сообщений:
Здравствуйте, Mr.Delphist, Вы писали:
MD>PostMessage, конечно, ничего в этом не вижу дурного. Тем более что синтаксис Delphi позволяет бесшовно интегрировать класс в цикл обработки сообщений:
MD>
Здравствуйте, Ops, Вы писали:
Ops>Не пойму, а Synchronize чем плох, почему это "костыль"? Это ж просто абстракция повыше уровнем.
Надо понимать цену этой абстракции:
1) Вызывающий поток ставится на паузу
2) Дожидаемся, пока освободится UI-поток (по сути, делаем SendMessage)
3) Делаем тот код что передан параметром Synchronize(...)
4) Освобождаем UI-поток
5) Возобновляем исполнение вызывавшего потока
Вот такая вот "эффективная" однопоточная многопоточность. А если сюда ещё примешать иные примитивы синхронизации, то и до дедлока недалеко (например, поток залочил примитив, далее UI встал на ожидание разлочки, далее поток пытается сделать Synchronize и ждёт его окончания, но UI всё ещё висит на ожидании разлочки).
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, D. Mon, Вы писали:
DM>>Я что-то многопоточное да дельфе делал году в 1999-м, все там было. До этого в основном под ДОС писал, поэтому настоящая многопоточность была мне тогда в диковинку. E>Дело не просто в многопоточности. А примитивы синхронизации, какие то гарантии при конкуррентном обращении к области памяти, всякие атомарные операции, барьеры и тому подобное. Плюс легкое распараллеливание, всякие пулы потоков и тому подобное. Или это все ручками нужно лисапедить по прежнему?
Классы TThread, TMutex, TCriticalSection... Всё основное там есть.
Здравствуйте, Teolog, Вы писали:
T>По поводу Embarcadero с++ 10 Seattle/Berlin — остался один раритетный проект на нем, страшная дрянь. Чтобы было понятно- штатный линкер содержит ошибку которая рандомно вышибает его в x64 системах при сборке. И решаеться это сторонней кривой утилитой которую приспособил посторонний человек, официального фикса нет много лет.
Оу, как знакомо — на некоторых версиях Delphi тоже были рандомные вылеты линкера при сборке большого проекта.
L>это что за бред из 19 века?! L>уже много лет ничего нигде не глючит и прекрасно работает, года 3 как использую для андроид не вижу никаких глюков L>да и вы просто скачайте Дельфи и убедитесь что сделать средней сложности андроид апликуху займет 5 минут и ничего нигде не глючит
А оно по-прежнему складывает все визуальные стили в хекс-дамп а-ля TDataModule?
Здравствуйте, Mr.Delphist, Вы писали:
MD>Надо понимать цену этой абстракции:
Угу, надо. Если кто-то не понимает, то что, абстракция виновата?
Да, не без недостатков, зато просто. Скажем, изредка обновить прогресс фоновой операции, без лишней писанины, вполне годится.
MD>Вот такая вот "эффективная" однопоточная многопоточность. А если сюда ещё примешать иные примитивы синхронизации, то и до дедлока недалеко (например, поток залочил примитив, далее UI встал на ожидание разлочки, далее поток пытается сделать Synchronize и ждёт его окончания, но UI всё ещё висит на ожидании разлочки).
Как будто без Synchronize нельзя дедлоков наделать, на одних примитивах. Многопоточность вообще сложная штука, надо понимать, что делаешь. Но это не повод отказываться от каких-то удобств там, где они применимы.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
_>Эм, а где это сейчас C++ и Паскаль компилируются не в машинные коды? Не, ну есть конечно WebAssembly,
android традиционно пишут на java C#, т.е. сразу все типа БПФ без выкрутасов недоступно.
А Дельфи и его С++ — да! БПФ пашет как надо.
из своего опыта могу подтвердить — работает без проблем android с 2.3 , OS-X с 10.75 на более ранних не было нужды, 7-8-10 на более ранних не было нужды.
Здравствуйте, Ops, Вы писали:
Ops>Да, не без недостатков, зато просто. Скажем, изредка обновить прогресс фоновой операции, без лишней писанины, вполне годится.
Да, но очень часто приходилось встречать код Synchronize(GodFunction) с вопросом "а почему у меня всё тормозит". Примитив-сахар на PostMessage (вместо SendMessage) в этом плане был бы куда полезнее.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Да, но очень часто приходилось встречать код Synchronize(GodFunction) с вопросом "а почему у меня всё тормозит".
Это когда не понимают, что делают.
MD>Примитив-сахар на PostMessage (вместо SendMessage) в этом плане был бы куда полезнее.
Скорее не "вместо", а как дополнение. Все же Synchronize обеспечивает синхронизацию в обе стороны, ждет окончания выполнения в главном потоке, а PostMessage — в одну. Если уж погромисты настолько некомпетентны, то с PostMessage у них может еще больше проблем возникнуть.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, paradoks, Вы писали:
_>>Эм, а где это сейчас C++ и Паскаль компилируются не в машинные коды? Не, ну есть конечно WebAssembly, P>android традиционно пишут на java C#, т.е. сразу все типа БПФ без выкрутасов недоступно.
Нуу допустим, только непонятно причём тут C++ и Паскаль. )))
P>А Дельфи и его С++ — да! БПФ пашет как надо.
Это понятно, просто оно так у любых компиляторов C/C++/Pascal и т.п. )))
P>из своего опыта могу подтвердить — работает без проблем android с 2.3 , OS-X с 10.75 на более ранних не было нужды, 7-8-10 на более ранних не было нужды.
Один и тот же код, без модификаций (перекомпиляцию допускаем естественно)? Если так, то молодцы. А можно где глянуть скрины или видео получаемых интерфейсов?
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, paradoks, Вы писали:
P>>а мне например глубоко наплевать куда складывает, мне важно, что на андроид работает, в гугл плэй принимают
MD>А мне нет, потому что работаю над кодом не один. Да даже если один — первый же бранч (и последующий мёрж при параллельных изменениях в бранче и мастере) покажет тупиковость этого подхода. Как это уже было для бинарного TLB, для которого с грехом пополам прикрутили ещё и поддержку текстовой IDL, и то костыльно; из той же серии компонент TImageList и прочая и прочая.
значит оно для одиночек, мне плевать на бранчи, главное чтобы работало и допускалось в гугл плэй .
Здравствуйте, alex_public, Вы писали:
_>Один и тот же код, без модификаций (перекомпиляцию допускаем естественно)? Если так, то молодцы. А можно где глянуть скрины или видео получаемых интерфейсов?
Здравствуйте, paradoks, Вы писали:
_>>Это понятно, просто оно так у любых компиляторов C/C++/Pascal и т.п. ))) P>назовите несколько компиляторов Паскаль для Android-Windows-iOS-OS-X одновременно с однотипным GUI на всех платформах?
Какая вообще связь между компилятором и GUI? И причём тут вообще GUI к обсуждаемому вопросу? )))
P>Ну можете и С++ кроме Qt попробовать назвать?
Qt — это всего лишь GUI библиотека (одна из многих — конкурентов полно, хотя и менее вылизанных), которая собирается любым популярным C++ компилятором (gcc/icc/clang/msvc и т.д.).
?
