IID>Ни одна ОС не имеет механизмов для безопасного убивания ПОТОКОВ. Убивать можно только ПРОЦЕССЫ (да, я в курсе, что в буханке с этим некоторая путаница).
Почему это никого не удивляет. Столько лет прошло и до сих пор нет механизма?
IID>Поэтому непонятна претензия к языку, не дающему тебе возможности убить подпрограмму.
Вот как раз язык вполне может реализовать любой функционал, даже которого нет в операционке. Даже если для этого придётся использовать виртуальную машину.
_>>Как останавливать блокирующие операции, как преобразовать сигнал в исключение, почему деление на 0 асинхронное событие.... IID>Сигналы ? А что это ? В моей ОС их нет. IID>(намёк на то, что не надо прибивать язык гвоздями к архитектуре и операционке).
QueueUserAPC у вас тоже нет?
Здравствуйте, kov_serg, Вы писали:
_>С++ вообще чудной язык и развивается как-то странно. В с++ добавили потоки, но проблему владения потоками и ресурсами смели под коврик как обычно. Например если я запустил две конкурирующие задачи по вычислениею чего-то. И первая завершилась раньше, я немедленно хочу прибить вторую причем так что бы она освободила все свои ресурсы и остановила свои потоки, которые она запустила для решения поставленной задачи. Или запустить подпрограмму, ограничив время исполнения 30мс и т.п. Как останавливать блокирующие операции, как преобразовать сигнал в исключение, почему деление на 0 асинхронное событие....
А это вообще простые вопросы на традиционных архитектурах? Как ты можешь остановить поток? Можно его прибить, но это плохое решение, т.к. все незакрытые ресурсы останутся незакрытыми, это не чистый выход. В посиксе сигналы, в сочетании с потоками это очень мутная тема, особенно если учесть, что юниксов много. То же самое с делением на ноль. Процессор дёргает обработчик прерываний операционной системы, операционная система шлёт сигнал в приложение, а какой там поток, насколько я понимаю, это уже не сообщается, что тут С++ сделает. Может что-то и может сделать, конечно, но это уже усилия, проще абстрагироваться и сказать — хз, а там может конкретные компиляторы или библиотеки реализуют более определённое поведение. Остановить блокирующие операции? Так на С++ все пишут с использованием платформенных API, там и останавливай как положено, в стандарте С++ наверняка до сих пор TCP-сервер не создать, не говоря уже об HTTP, а если юзаешь там POSIX или WinAPI, там уже и есть какие-то определенные методы для прерывания.
Здравствуйте, ononim, Вы писали:
O>>>Нет. Достаточно того что без умных указателей невозможен полноценный RAII. А без RAII С++ ничем не лучше Java (:trollface S>>Вы ошибаетесь, мсье. RAII ортогонален умным указателям и зависит исключительно от реализации класса объекта. O>RAII: O>_НЕ_ RAII:
Здравствуйте, kov_serg, Вы писали:
IID>>Поэтому непонятна претензия к языку, не дающему тебе возможности убить подпрограмму. _>Вот как раз язык вполне может реализовать любой функционал, даже которого нет в операционке. Даже если для этого придётся использовать виртуальную машину.
Люди используют С++ не для того, чтобы их код выполнялся под виртуальной машиной, а, скорее, наоборот, чтобы их код был как можно ближе к железу с абсолютным минимумом абстракций.
Кстати, в Java с её виртуальной машиной потоки всё равно убивать нельзя и обработки сигналов там нет Деление на 0, правда, работает нормально — кидает исключением в нужном месте и нужном потоке.
S>А, вы наверное про необходимость обработки исключений? Почему в первом случае их не обрабатываете?
Потому что всю необходимую обработку выполнит ЯП. Для этого RAII и нужен.
Фактически в грамотном С++ коде try catch нужен крайне редко, а throw в catch не нужен никогда
Как много веселых ребят, и все делают велосипед...
На мой взгляд, это замечание справедливо только для shared_ptr. Их я стараюсь не использовать. Их обилие, по-моему мнению, сигнал непродуманной архитектуры. А вот использование unique_ptr, по-мимо прочего, экономит время разработки. А время невознобновимый ресурс.
P.S. Есть ещё грустный момент, это исключения в конструкторе. Тогда деструктор класса, в котором произошло исключение, не вызывается. То есть если была выделена память до исключения, она освобождена не будет, ели это обычный указатель. Однако для полей, которые содержат умные указатели, деструктор вызовется.
Здравствуйте, Sheridan, Вы писали:
SVZ>>В итоге от С++ приходим к "Си с классами". Тоже имеет право на существование.
S>А зачем концепцию "воркера" переделывать в функцию? По всей видимости вам нужен некий функтор, который можно по месту, на стеке объявить и вызвать. В функторе в конструкторе выделили память, в деструкторе освободили, по мере вычислений расставляем нужные try/catch/throw. в итоге при выходе из функции объект удалится с с освобождением памяти без лишних телодвижений.
До тех пор, пока не добавляется полиморфизм. Когда тип твоего воркера выбирается снаружи, в зависимости от каких-то условий. Уже не получится создать на стеке.
Вот и пришли к Фабрике. А дальше, либо хранить голый указатель и дюжина повторяющихся delete'ов, либо смартпоинтер, который сам приберется при выходе из скоупа.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, ononim, Вы писали:
S>>Остаётся выяснить зачем вы инициализацию объекта вынесли за конструктор объекта, даже вообще из объекта. Вы знаете что такое инкапсуляция? O>шта?
Нераспарсил тот вопрос с первого раза )
Здравствуйте, ononim, Вы писали:
S>>А, вы наверное про необходимость обработки исключений? Почему в первом случае их не обрабатываете? O>Потому что всю необходимую обработку выполнит ЯП. Для этого RAII и нужен. O>Фактически в грамотном С++ коде try catch нужен крайне редко, а throw в catch не нужен никогда https://rsdn.org/forum/flame.comp/7328391.1
по делу — ядро линукса написано без смарт поинтеров
и даже без С++
и ничего, работает
соответственно можно писать код по разному и он будет работать
НО
необходимость смарт поинтеров приходит с опытом которого у вас нет
вы рассчитываете что кто то в этой теме вам в нескольких сообщениях разовьет его и вам откроется истинна ?
абсурд
переведите какой нибудь проект использующих смарт поинтеры на сырые указатели, который чуть больше чем ваш хелоу ворлд
к примеру переведите Куте на сырые указатели
и вам откроется истинна смарт поинтеров
O>>0x1000000 байт влезет не в каждый лишь стек. S>Тогда гарантируйте невозможность аварийного выхода из функтора и создавайте без стека
Во-первых, это просто частный пример.
Во-вторых, ты сейчас хрень какуюто сказал. Оно сейчас и создается без стека. Проблема в том что "ляляля" может кинуть исключение.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Stanislav V. Zudin, Вы писали:
S>>А зачем концепцию "воркера" переделывать в функцию? По всей видимости вам нужен некий функтор, который можно по месту, на стеке объявить и вызвать. В функторе в конструкторе выделили память, в деструкторе освободили, по мере вычислений расставляем нужные try/catch/throw. в итоге при выходе из функции объект удалится с с освобождением памяти без лишних телодвижений.
SVZ>До тех пор, пока не добавляется полиморфизм. Когда тип твоего воркера выбирается снаружи, в зависимости от каких-то условий. Уже не получится создать на стеке. SVZ>Вот и пришли к Фабрике. А дальше, либо хранить голый указатель и дюжина повторяющихся delete'ов, либо смартпоинтер, который сам приберется при выходе из скоупа.
Какойто бардак я вижу.
Почему обязательно тип выбирать снаружи и почему обязательно фабрика? Почему функтор сам не может "в зависимости от каких-то условий" пойти тем или иным путём вычислений?
Или из крайности в крайность? Теперь обязательно должен быть полиморфизм? А почему полиморфизм только у функтора, а не у вызывающего объекта, причём с за templateченым типом функтора нопример?
Здравствуйте, vsb, Вы писали:
vsb>А это вообще простые вопросы на традиционных архитектурах? Как ты можешь остановить поток? Можно его прибить, но это плохое решение, т.к. все незакрытые ресурсы останутся незакрытыми, это не чистый выход.
Что мешает получать все от того кто создал поток? И когда он решит его остановить он точно будет знать чем тот владел. Более того он может потребовать ограничить или запретить использовать часть ресурсов. Просто надо сделать соответствующий ABI и runtime. vsb>В посиксе сигналы, в сочетании с потоками это очень мутная тема, особенно если учесть, что юниксов много. То же самое с делением на ноль. Процессор дёргает обработчик прерываний операционной системы, операционная система шлёт сигнал в приложение, а какой там поток, насколько я понимаю, это уже не сообщается, что тут С++ сделает.
И что мешает явно декларировать поведение? vsb>Может что-то и может сделать, конечно, но это уже усилия, проще абстрагироваться и сказать — хз, а там может конкретные компиляторы или библиотеки реализуют более определённое поведение. Остановить блокирующие операции? Так на С++ все пишут с использованием платформенных API, там и останавливай как положено, в стандарте С++ наверняка до сих пор TCP-сервер не создать, не говоря уже об HTTP, а если юзаешь там POSIX или WinAPI, там уже и есть какие-то определенные методы для прерывания.
Вообще то там есть select, epoll др. не блокирующие варианты. Но уйти в нирвану можно и при обычном открытии файла с сетевого диска. Жаль сейчас нет дискет где частенько были bad block-и с их "вжж-вжж-вжж-дрр-вжж-вжж-вжж-шхшхшх" abort,repeat,ignore?
Здравствуйте, ononim, Вы писали:
O>>>0x1000000 байт влезет не в каждый лишь стек. S>>Тогда гарантируйте невозможность аварийного выхода из функтора и создавайте без стека O>Во-первых, это просто частный пример. O>Во-вторых, ты сейчас хрень какуюто сказал. Оно сейчас и создается без стека. Проблема в том что "ляляля" может кинуть исключение.
Да пусть хоть обкидается. Функтор уже отработал, вернул результат и удалён. Или по вашему условию строго обязательно и никогда не может быть изменено удаление именно в конце функции?
