Здравствуйте, 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) в этом плане был бы куда полезнее.
Здравствуйте, paradoks, Вы писали:
P>а мне например глубоко наплевать куда складывает, мне важно, что на андроид работает, в гугл плэй принимают
А мне нет, потому что работаю над кодом не один. Да даже если один — первый же бранч (и последующий мёрж при параллельных изменениях в бранче и мастере) покажет тупиковость этого подхода. Как это уже было для бинарного TLB, для которого с грехом пополам прикрутили ещё и поддержку текстовой IDL, и то костыльно; из той же серии компонент TImageList и прочая и прочая.
Здравствуйте, 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 и т.д.).
