Здравствуйте, Shmj, Вы писали:
S> S>> Нужно с этим языком поработать хотя бы месяца два-три, чтобы познакомиться с его внутренним дьяволом. А пока такой возможности нет.
S> R>Работай, кто тебе мешает
S> А деньги кто за это платить будет?
Здравствуйте, T4r4sB, Вы писали:
NB>>там вроде были ограничения по применению dyn интерфейсов в генериках TB>А в плюсах шаблонный абстрактный метод можно что ли?
можно абстрактный метод у шаблонного класса
сорри, сейчас всех проблем с применением dyn не помню, поэтому не готов предметно спорить
помню что когда изучал этот момент не понравился
Здравствуйте, reversecode, Вы писали:
R>не знаю что вы подразумеваете под этим
Прежде всего то, что сделать либу, которая удовлетворяет собственные потребности -- это даже не половина дела, а может быть даже и не четверть. Вся весялуха начнется когда этой либой начнут пользоваться другие люди, особенно те, кто с вами никак не связан.
Ну и, конечно же, как только вы явите свою либу миру, найдется не менее профессиональный, все знающий, все умеющий, все пробовавший reversecode-v.2.0, который запишет ваше творение в ряд к libevent, libev, libuv, asio, libunifex и т.д., и т.п.
R>то если захочеся какого то хайпа R>то хайпа к условному tokio-c++ будет больше внимания
Здравствуйте, Alekzander, Вы писали:
A>Опять кому-то о-о-пэ помешало. Ладно, лично мне этого достаточно, чтобы больше им не интересоваться.
Да есть тут ооп, но наследоваться можно только от абстрактных интерфейсов.
И деструкторы можно писать.
И приватные поля есть.
А неудобочитаемые рахитектурные иерархии классов на десятки этажей — да нафиг оно нужно.
Хорошо, что я никогда не интересовался этой дрочью, банда четырёх, гоф, паттерны... поэтому мне оно максимально безболезненно.
Здравствуйте, so5team, Вы писали:
S>Вся весялуха начнется когда этой либой начнут пользоваться другие люди, особенно те, кто с вами никак не связан.
Вот потому их и куча, ибо либа делается в первую очередь для решения своей задачи.
Потом запуливается в опенсорс и долбитесь с этим как хотите.
Сделать универсальную долго, муторно, дорого, и нафиг нужно если тебе за это не платят. Ну и получится плохо в итоге, ибо придётся пойти на компромиссы и похерить то, ради чего эта либа писалась изначально.
Здравствуйте, Went, Вы писали:
W>Видимо речь о случаях, когда в процессе итерации по контейнеру в него добавляются или убираются элементы, что приводит к инвалидации итераторов, пропуску элементов или бесконечному росту.
И при чём тут язык когда руки растут из нестандартного места?
W>При аккуратном подходе к архитектуре таких проблем почти не бывает.
Бинго!
Здравствуйте, ArtDenis, Вы писали:
AD>При написании дикой многопоточки не надо постоянно напрягаться и держать себя в ежовых рукавицах при написании кода
Ну т.е. не надо думать.
Это та же мантра что и у адептов GC: можно срать не снимая штаны — потом няня памперс поменяет.
Но тут всё отличие в рамках, в которые тебя загоняет язык. Пиши так же на плюсах — будет получаться так же.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, reversecode, Вы писали:
R>>не знаю что вы подразумеваете под этим
S>Прежде всего то, что сделать либу, которая удовлетворяет собственные потребности -- это даже не половина дела, а может быть даже и не четверть. Вся весялуха начнется когда этой либой начнут пользоваться другие люди, особенно те, кто с вами никак не связан.
для всех я не делаю, хз где вы опять этого прочитали в моих словах
S>Ну и, конечно же, как только вы явите свою либу миру, найдется не менее профессиональный, все знающий, все умеющий, все пробовавший reversecode-v.2.0, который запишет ваше творение в ряд к libevent, libev, libuv, asio, libunifex и т.д., и т.п.
поэтому я сказал что я нехочу тратить свое время на это
и возьму то на чем другие набили все возможные шишки и сделали максимально удобно для многих
и это совпадает с моими вкусами и потребностями
и портирую на плюсы
но вы увы этого не поняли и остапа понесло....
я к счастью не шмга и прочиее, не люблю болото из лесенок для скрола вверх и вниз
и стараюсь не уходить глубже пары ответов, это все найт бест виноват проказник
и особенно если для себя я не вижу никакой выгоды от осбуждения
так что всех благ
R>>то если захочеся какого то хайпа R>>то хайпа к условному tokio-c++ будет больше внимания
S>А зачем вам хайп?
Здравствуйте, T4r4sB, Вы писали:
TB>Это та же мантра, что и у школьных кулхацкеров — они считают себя настолько скиловыми, что никогда не делают идиотских ошибок.
Ошибки делают все и на всех языках. Но ошибки надо исправлять а не давать памперсам прятать их. Иначе это лишь закрепляет хреновые подходы к дизайну.
В итоге хреново спроектированное как то работает и не падает, после чего на это наматывают ещё слоёв и упираются в то, что всё это работает криво, медленно, и жрёт ресурсы. После чего это только взорвать и построить заново.
Здравствуйте, ArtDenis, Вы писали:
AD>При написании дикой многопоточки не надо постоянно напрягаться
Ошибка уже в выделенном. В 99.99999% случаев "дикая" многопоточка не нужна.
AD>и держать себя в ежовых рукавицах при написании кода, боясь словить data race или порчу памяти в общих для потоков объектах.
Я когда последний раз спрашивал про дедлоки в Rust — мне ответили весёлой фразой, мол что Rust "deadlock safe", что означает что deadlock можно словить в safe коде
А как ты убеждаешься отсутствии дедлоков в "дикой" многопоточке?
AD>Не надо никаких стат анализаторов, асанов, тредсанов и прочих средств, без которых на плюсах не напишешь более-менее сложный проект
По моим наблюдениям, ошибки от которых страхует Rust (замечательно что он это делает, ничего против не имею, только за) — это меньше 1% от всех задач в большом проекте, над которым работают смесь из продвинутых и неопытных C++ программистов.
Такие проблемы реально вылезают только когда неопытные остаются предоставленны сами себе без надзора и review, что безотносительно языка такая себе идея.
Здравствуйте, CreatorCray, Вы писали:
CC>Ну т.е. не надо думать. CC>Это та же мантра что и у адептов GC: можно срать не снимая штаны — потом няня памперс поменяет.
Я бы сказал по-другому: ты больше тратишь усилий на бизнес-задачу, чем на контроль за памятью, защиту общих ресурсов и т.п. Это основная причина, почему я использую раст, несмотря на его недостатки.
CC>Пиши так же на плюсах — будет получаться так же.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Ошибка уже в выделенном. В 99.99999% случаев "дикая" многопоточка не нужна.
Отучаемся говорить за всех. Вот мне нужна, например.
EP>Я когда последний раз спрашивал про дедлоки в Rust — мне ответили весёлой фразой, мол что Rust "deadlock safe", что означает что deadlock можно словить в safe коде EP>А как ты убеждаешься отсутствии дедлоков в "дикой" многопоточке?
Да, не смогли они в делдоки. Раст тут не панацея. PS: никак не убеждаюсь в отсутствии, но убеждаюсь в присутствии по жалобам пользователей
EP>По моим наблюдениям, ошибки от которых страхует Rust (замечательно что он это делает, ничего против не имею, только за) — это меньше 1% от всех задач в большом проекте, над которым работают смесь из продвинутых и неопытных C++ программистов.
Всё верно. Только даже одна подобная ошибка может похерить плоды непосильного труда пользователя, чем он не слишком будет рад )
EP>Такие проблемы реально вылезают только когда неопытные остаются предоставленны сами себе без надзора и review, что безотносительно языка такая себе идея.
Тоже согласен. Ревью нужно. Но лучше и продуктивнее ревьюить то, как программист выстроил функционал решения проблемы, чем постоянно тыкать ему, что он явно допустил UB, обратившись по освобождённому указателю или забыл защитить данные от многопоточного обращения.
Здравствуйте, ArtDenis, Вы писали:
EP>>Ошибка уже в выделенном. В 99.99999% случаев "дикая" многопоточка не нужна. AD>Отучаемся говорить за всех. Вот мне нужна, например.
Нужна только многопоточка? Или именно "дикая"?
EP>>А как ты убеждаешься отсутствии дедлоков в "дикой" многопоточке? AD>Да, не смогли они в делдоки. Раст тут не панацея. PS: никак не убеждаюсь в отсутствии, но убеждаюсь в присутствии по жалобам пользователей
Может вместо "дикой" попробовать нормальную?
EP>>Такие проблемы реально вылезают только когда неопытные остаются предоставленны сами себе без надзора и review, что безотносительно языка такая себе идея. AD>Тоже согласен. Ревью нужно. Но лучше и продуктивнее ревьюить то, как программист выстроил функционал решения проблемы, чем постоянно тыкать ему, что он явно допустил UB, обратившись по освобождённому указателю или забыл защитить данные от многопоточного обращения.
"забыл защитить данные от многопоточного обращения" — это явно говорит о том что в консерватории что-то не так — такаядикая многопоточка, где нужно постоянно держать в голове что нужно защищать, а что нет, с локами разбросанными по всему коду и хрен знает какими дедлоками — не нужна, за крайне редкими исключениями.
Поэтому и нужен кто-то знающий и опытный на проекте — большинство подобных вопросов должны разруливаться грамотным дизайном, и вообще не возникать как класс.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Нужна только многопоточка? Или именно "дикая"?
И та и другая нужна.
EP>Может вместо "дикой" попробовать нормальную?
Это не всегда получается когда нужен быстрый MVP. Уже потом в процессе написания продукта, архитектура будет постепенно улучшаться, а "дикая" многопоточка превратиться в обычную. Но на старте мне важно чтобы была возможность писать так, чтобы 1) писалось быстро без продумывания архитектуры, 2) работало как ожидается и 3) не падало на любой чих.
EP>"забыл защитить данные от многопоточного обращения" — это явно говорит о том что в консерватории что-то не так — такаядикая многопоточка, где нужно постоянно держать в голове что нужно защищать, а что нет, с локами разбросанными по всему коду и хрен знает какими дедлоками — не нужна, за крайне редкими исключениями. EP>Поэтому и нужен кто-то знающий и опытный на проекте — большинство подобных вопросов должны разруливаться грамотным дизайном, и вообще не возникать как класс.
В итоге к этому всё и приходит. Но незамеченные ошибки остаются, даже если архитектура организована правильно и соблюдаются все рекомендации при написании многопоточных приложений. В расте же код с подбной ошибкой просто не скомпилируется.
Здравствуйте, CreatorCray, Вы писали:
S>>Вся весялуха начнется когда этой либой начнут пользоваться другие люди, особенно те, кто с вами никак не связан. CC>Вот потому их и куча, ибо либа делается в первую очередь для решения своей задачи. CC>Потом запуливается в опенсорс и долбитесь с этим как хотите. CC>Сделать универсальную долго, муторно, дорого, и нафиг нужно если тебе за это не платят. Ну и получится плохо в итоге, ибо придётся пойти на компромиссы и похерить то, ради чего эта либа писалась изначально.
Э... Зачем был написан этот комментарий и что из него я должен был узнать?
