Программирование[8]

переформулируй вопрос

асинхронщина нужна когда она нужна, а когда она не нужна лучше пистать синхронно

нужна когда есть требования либо по производительности (пераллельное выполнение, либо чтобы потоки не жрало), либо по асинхронности (когда отдаешь клиенту ОК, а по факту тяжелую операцию стартуешь асинхронно)

ручное создание потоков - это очень низкоуровневая херня, которую если использовать для высокоуровневых тасков - пишешь свои велосипеды с кучей багов и неоптимальностей, лучше юзать всякие экзекьюторы и высокоуровневые фьючи

когда мне нужно было сделать что-то асинхронно в java 8 я очень порадовался что есть статический метод, который просто ранит на дефолтном тредпуле 

Я тупой, почему это:
  

    MainWindow *main =new MainWindow();
    main->show();
    this->close(); 

дает утечку памяти?

это плюсы?

есть тут джава галерщики в тырпрайз разработке?

часто вы юзаете фьючи, комплитабл, ручное создание потоков, асинхронное выполнение кода?

гавноеды на месте

отвечаю:

нет

нет

нет

тут сложнее: на текущей работе у нас прожект реактор

так что косвенно ответ на твой вопрос - да

но это уж не голым кодом делается, а фреймворком

это плюсы?

да

https://stackoverflow.com/questions/22521946/qt-is-there-any-memory-leak-in-the-following-code

https://stackoverflow.com/questions/22521946/qt-is-there-any-memory-leak-in-the-following-code

Я правильно понимаю, что новое окно создается в куче и имеет родство со старым, и старое окно не удаляется?

Изменено 24 июля 2019 пользователем kmtw

Я тупой, почему это:

если это QT то потому что это QT

я больше года(почти 2) работал только с QT-кодом(UI в том числе), конечно мой уровень остался на уровне тупого ламера, но багов я повидал довольно много

 

совет испольовать электрон(и аналоги) может буть бесполезным, так как у тебя уже вся прога на QT

поэтому совет переписать все на "без QT" и UI сделать какойто минималистичной либой

 

Я правильно понимаю, что новое окно создается в куче и имеет родство со старым, и старое окно не удаляется?

может это https://stackoverflow.com/questions/32252841/does-qt-applications-have-automatic-garbage-collection ?

(там полный ппц с пониманием как память выделяется/очищается, чтоб  это понять надо все классы QT знать)

Изменено 24 июля 2019 пользователем hira88

Переписать не вариант, у меня типо работа. Проблему уже решил, просто интересно, как это работает. Ладно, пойду читать дальше, спасибо за ссылку.

есть тут джава галерщики в тырпрайз разработке?

часто вы юзаете фьючи, комплитабл, ручное создание потоков, асинхронное выполнение кода?

Все во флаксах.

Комплитаблы из другиг апи оборачиваем в Mono.fromFuture

Реактивщина делает код конкаренси агностик ну и дает механизм там бэкпрешур раскидывания по потокам.

https://www.jetbrains.com/idea/whatsnew/

 

HTTP client supports cURL requests

kaifstelish

Я тупой, почему это:

  

    MainWindow *main =new MainWindow();
    main->show();
    this->close(); 

дает утечку памяти?

Краткий ответ опытного чувака на кутях:

 

 

если ты где-то вызвал new, то кто-то должен где-то вызвать delete

new выделяет память в куче

пока delete не будет применен к выделенной памяти, менеджер памяти ее будет считать занятой

и никому не отдаст

а если ты проебешь адрес, который тебе new дал, то ты проебал память считай

еще чет начали затирать про смартпоинтеры. Но тут сам читай.

 

есть тут джава галерщики в тырпрайз разработке?

часто вы юзаете фьючи, комплитабл, ручное создание потоков, асинхронное выполнение кода?

Все во флаксах.

Комплитаблы из другиг апи оборачиваем в Mono.fromFuture

Реактивщина делает код конкаренси агностик ну и дает механизм там бэкпрешур раскидывания по потокам.

https://www.jetbrains.com/idea/whatsnew/

 

HTTP client supports cURL requests

kaifstelish

 

а что вы пилите на всем этом

 

 

а что вы пилите на всем этом

 

Вебсервисы. Микросервисы.

 

Банальные

   контролер                сервис                    дао

Flux<TypeDTO> -> Flux<TypeDTO> -> Flux<TypeEntity>

 

Скоро ещё в моду реактивные драйвера войдут. В принципе уже можно перекатываться.

У нас ещё micronaut, в теории ноль рефлекшона в приложении, даже джексон через Introspection можно настроить

 

На грани будущего стоим  kaifstelish

 

Хотя сборка конечно идет через легаси скрипты для rake  zemlyapuhom

 

Переписать бы все на gradle

а потом прокрутка в браузере лагает

 

 

пока delete не будет применен к выделенной памяти, менеджер памяти ее будет считать занятой

небольшая утечка памяти лучше чем краш программы

delete при многопотоке(который уже по дефолту был начиная с qt4 пять лет назад) крашит програму случайно(по очевидным причнам)

и писать правильную программу на qt следуя всем рекомендациям-сложнее чем писать свой фреймворк с нуля, когда я осилил qt4 вышел уже qt5 с двумя обновлениями(на который было все переписано и на многие непонятные баги я просто забил, и заказчикам пофик)

слишком много подводных камней в qt, если кратно

а что в кт много гуишных потоков?

создавать и удалять будет один и тот же поток

 

пока delete не будет применен к выделенной памяти, менеджер памяти ее будет считать занятой

небольшая утечка памяти лучше чем краш программы

delete при многопотоке(который уже по дефолту был начиная с qt4 пять лет назад) крашит програму случайно(по очевидным причнам)

и писать правильную программу на qt следуя всем рекомендациям-сложнее чем писать свой фреймворк с нуля, когда я осилил qt4 вышел уже qt5 с двумя обновлениями(на который было все переписано и на многие непонятные баги я просто забил, и заказчикам пофик)

слишком много подводных камней в qt, если кратно

 

Хз, у меня нет оснований не доверять челу, который это писал. Он в соло ебашит уже больше 5 лет коммерческое приложение, в котором и с памятью, и с крашами всё очень хорошо. 

переформулируй вопрос

асинхронщина нужна когда она нужна, а когда она не нужна лучше пистать синхронно

нужна когда есть требования либо по производительности (пераллельное выполнение, либо чтобы потоки не жрало), либо по асинхронности (когда отдаешь клиенту ОК, а по факту тяжелую операцию стартуешь асинхронно)

ручное создание потоков - это очень низкоуровневая херня, которую если использовать для высокоуровневых тасков - пишешь свои велосипеды с кучей багов и неоптимальностей, лучше юзать всякие экзекьюторы и высокоуровневые фьючи

когда мне нужно было сделать что-то асинхронно в java 8 я очень порадовался что есть статический метод, который просто ранит на дефолтном тредпуле 

что за метод?

 

переформулируй вопрос

асинхронщина нужна когда она нужна, а когда она не нужна лучше пистать синхронно

нужна когда есть требования либо по производительности (пераллельное выполнение, либо чтобы потоки не жрало), либо по асинхронности (когда отдаешь клиенту ОК, а по факту тяжелую операцию стартуешь асинхронно)

ручное создание потоков - это очень низкоуровневая херня, которую если использовать для высокоуровневых тасков - пишешь свои велосипеды с кучей багов и неоптимальностей, лучше юзать всякие экзекьюторы и высокоуровневые фьючи

когда мне нужно было сделать что-то асинхронно в java 8 я очень порадовался что есть статический метод, который просто ранит на дефолтном тредпуле

что за метод?

Думаю речь о методах интерфейсов Executor и ExecutorService. Они прям сильно упрощают работу с потоками благодаря тредпулу и не только. В доках к этим интерфейсам нормально написано)
Изменено 25 июля 2019 пользователем Pep_See

Вот только средствами джавы сложно сделать ленивые асинхронные вычисления.

То что на изи делается реактивщиной.

 

А по поводу Java8, там есть

CompletableFuture<Void> runAsync(Runnable runnable)

и тд, для быстрого и удобного выполнения асинхронного кода. И не надо заводить экзекьютор сервисы, без лишнего тюнинга оно само пропихнет ранабл в форкджоин пул.