мне кажется rust хорошо для программистов среднего уровня, не владеющих C++.
Все же работа с памятью создает большую когнитивную нагрузку.
Возможно после этого можно переехать проще на ziglang. Он в чем то похож.
и к тому же позволяет интегрироваться с си(++).
но раст реально просто. не так ли?
Здравствуйте, Разраб, Вы писали:
Р>мне кажется rust хорошо для программистов среднего уровня, не владеющих C++.
В первую очередь для программистов высокого уровня, с большим опытом C++.
Потому что они реально понимают все те проблемы, которые решает "borrow checker",
только явное преобразование типов (привет integer promotion), трейты Send/Sync,
нормальный менеджер пакетов, явная обработка ошибок и т.п. и т.д.
И имея большой опыт C++ такой человек может рассказать почему на примерах все эти фишки
хороши, иначе будет возникать куча вопросов, а зачем так усложнять, а почему компилятор
не дает писать так и тому подобное.
Р>Все же работа с памятью создает большую когнитивную нагрузку. Р>Возможно после этого можно переехать проще на ziglang. Он в чем то похож.
Zig вообще ничем не похож и ничего нового особо не приносит.
В нем никаких новых идей по сравнению с С нет, только синтаксис другой.
Р>но раст реально просто. не так ли?
Ну некоторые считают что у него очень крутая кривая обучения,
и в общем-то согласен. Дописать и поправить кусочек новичку будет легко,
и компилятор много проконтролирует. Так что это будет приятное путешествие,
без присущих новичку ошибок, типа передачи указателя на переменную класса "auto"
в другой поток. Но когда нужно будет сделать что-нибудь сложнее,
тогда начнутся проблемы.
Здравствуйте, Zhendos, Вы писали:
Z>В первую очередь для программистов высокого уровня, с большим опытом C++. Z>Потому что они реально понимают все те проблемы, которые решает "borrow checker",
Не, как раз С++ники с большим опытом понимают что тот геморрой, что создаёт ржавый подход, совершенно неоправдан ради решения проблемы, которая перед опытными С++никами и не стоИт вовсе.
Z>И имея большой опыт C++ такой человек может рассказать почему на примерах все эти фишки хороши
Скорее почему для этого нафиг не надо городить отдельный язык.
CC>Не, как раз С++ники с большим опытом понимают что тот геморрой, что создаёт ржавый подход, совершенно неоправдан ради решения проблемы, которая перед опытными С++никами и не стоИт вовсе.
Не знпю, я регулярно напарываюсь на измененип итерируемого контейнера, более завуалированно и неявно, конечно. И ловится оно через раз. Приходится с санитайзерами пересобирать, они сразу показывают.
А так тут вопрос скорее о том, что быстрее — написать без этих строгих правил и починить все баги, или по часу ублажать компилятор на каждый чих. Мне ответ не очевиден. Но Раст это пока что самая удачная попытка плвысить безопасность, сохранив скорость и не слишком усложнить написание логики
Здравствуйте, Shmj, Вы писали:
S> Нужно с этим языком поработать хотя бы месяца два-три, чтобы познакомиться с его внутренним дьяволом. А пока такой возможности нет.
Здравствуйте, rudzuk, Вы писали:
S>> Нужно с этим языком поработать хотя бы месяца два-три, чтобы познакомиться с его внутренним дьяволом. А пока такой возможности нет. R>Работай, кто тебе мешает
но это и без этого понятно
достаточно понять синтаксис/семантику раста
что бы понять что они избыточны для плюсов
даже не смотря на некоторые конструкции/семантику раста которые сокращают объем логики, паттерн матчинг или "?" возврат ошибок
Здравствуйте, T4r4sB, Вы писали:
TB>Не знпю, я регулярно напарываюсь на измененип итерируемого контейнера, более завуалированно и неявно, конечно. TB> И ловится оно через раз. Приходится с санитайзерами пересобирать, они сразу показывают.
Что именно ты тут называешь "измененип итерируемого контейнера"?
Я считаю, что не нужно связывать язык программирования и уровень профессионализма отдельных программистов. Когда начинаются рассуждения, что некий язык программирования хорош тем, что на нём могут программировать не профессиональные программисты, то для меня это сразу маркер, что пошла рекламная компания маркетологов впаривающая свои продукты.
Посмотрел видео и выделил некоторые моменты о которых говорит докладчик.
1. После Python, PHP, JavaScript мозги атрофируются. У тебя теряется ясность ума. (2:00)
2. Почитайте хорошие книги по математике, они написаны простым человеческим языком. И вспомните чему нас учили в институте. Конспекты, конспекты, толстые конспекты, бред. (2:50)
3. В программировании мы видим слишком много подходов, очень много философии. Процедурные, объектные, функциональные языки, скриптинг. (4:15)
4. Машина Тьюринга универсальный вычислитель. Это бензопила, которой можно отпилить себе части тела. Можно писать программы и всё будет работать, но проблема в том, что мы забываем, то что мы написали. (5:35)
5. Мы думаем, что мы гомо сапиенс (человек разумный), а на самом деле у нас проблемы с памятью. (6:53)
6. Вычитывайте свой код. Я вычитываю свой код три раза. А бывают люди вычитывают два раза. А бывают ни разу не вычитывают. (7:15)
...
Если программисту сложно систематизировать знания, потому что есть проблема преждевременной систематизации. Или знания всё время забываются, а если записываются, то теряются. Вот пожалуйста универсальное решение для любого языка программирования, для любой парадигмы программирования, для любого фреймворка.
Вся лекция крутится вокруг идеи, что у программиста проблемы с головой. Но это не проблема какого-то языка программирования или его философии, как утверждает докладчик.
Вообще я описал каждую проблему мешающую "хорошему" программисту "танцевать". Личная база знаний это лишь поверхностный подход, который позволяет начать решать проблему методом грубой силы.
1. Например, всё программирование на английском, но не просто на английском, на английском, на котором думал программист, когда он это писал. Нет однозначных терминов, вы можете каждое понятие описать по-разному. Может быть это будет не скоро, может быть никогда, а может и скоро, но я собираюсь решить эту проблему с помощью LayerEditor. Это сотрёт грань между разговорными языками, только порядок будет иметь значения, а не то, что там написано в лексемах.
2. Или вот хотелось бы функционал как Расширенная Форма Бэкуса—Наура. Ведь докладчик он не инопланетянин, я столкнулся с такими же проблемами. Я хочу, чтобы можно написать какую-то форму в графическом виде для архитектуры, и потом просто её заполнять. В идеале ещё распознавать архитектуры в произвольном коде, чтобы из разного кода с помощью автоматического сравнения получать шаблоны РБНФ. Но именно в графическом виде, типа древовидных списков как для дурачка.
3. Я сейчас исходный код Qt заливаю в личную базу знаний. Дело это не быстрое, причём я использую метод конвейера. И опять я возвращаюсь к идее виртуального каталога. А виртуальный каталог, это такой псевдокаталог, который содержит относительные пути и хеш-суммы. Если у вас есть на диске нужные файлы, то при автоматическом сканировании хеш-сумм можно восстановить этот виртуальный каталог сверив размер и хеш-суммы. А пока я должен работать с файлами физически, а не по ссылкам виртуального каталога, что не совсем удобно, в свете того, что многие автоматические операции недоступны.
Я считаю, что в программировании огромное количество специализаций. Один программист знает одно, другой другое. Каждый человек заморочен на своём. Я пошёл по пути универсальности. Да, я считаю, что для моих целей лучше всего подходит C++, но проблема у меня в поглощении разнородных знаний с любого языка программирования, или любого разговорного текста, даже если это китайский или японский, который без компьютерного словаря даже прочитать не смогу.
Жизнь программиста на каждом языке программирования важна. Не надо унижать фреймворки или мелкие библиотеки алгоритмов. Из любого мусора можно извлечь полезные знания или хотя бы мусор. Просто у программиста не будет такого волшебства, что он взял тот же Rust и такой раз, и стал из нубо джуна каким-нибудь сеньором помидором, причём в любой области программирования. Это всё сказки от маркетологов.
Маркетологи меня более двух десятилетий назад так и подловили. Я же не сразу пришёл к тем выводам которых я придерживаюсь сейчас. Были проблемы, были размышления. Причём проблемы до сих пор остались, смена языка программирования очевидно их не решает.
Здравствуйте, rudzuk, Вы писали:
R>Я думаю, это прекрасный язык, с замечательным синтаксисом.
R>
fn longest<'a>(a: &'a str, b: &'a str) -> &'a str {
R> if a.len() < b.len() { a } else { b }
R>}
В реальности времена жизни применяются в основном в библиотечном коде и только в том случае, если компилятор их не может вывести. Вот сейчас свой проект посмотрел — почти нигде <'a> не встречается.
Здравствуйте, CreatorCray, Вы писали:
CC>Не, как раз С++ники с большим опытом понимают что тот геморрой, что создаёт ржавый подход, совершенно неоправдан ради решения проблемы, которая перед опытными С++никами и не стоИт вовсе.
Вот я перешёл на раст и вздохнул с облегчением. При написании дикой многопоточки не надо постоянно напрягаться и держать себя в ежовых рукавицах при написании кода, боясь словить data race или порчу памяти в общих для потоков объектах. Не надо никаких стат анализаторов, асанов, тредсанов и прочих средств, без которых на плюсах не напишешь более-менее сложный проект
Здравствуйте, CreatorCray, Вы писали:
CC>Что именно ты тут называешь "измененип итерируемого контейнера"?
Видимо речь о случаях, когда в процессе итерации по контейнеру в него добавляются или убираются элементы, что приводит к инвалидации итераторов, пропуску элементов или бесконечному росту. У меня такая проблема встречается при "быстром кодировании", когда, например, каждому элементу контейнера вызывается виртуальная функция, внутри которой может быть что угодно, например, удаление себя или добавление собратьев. При аккуратном подходе к архитектуре таких проблем почти не бывает.
Здравствуйте, Разраб, Вы писали:
Р>мне кажется rust хорошо для программистов среднего уровня, не владеющих C++.
Ты делишь языки по уровням программистов.
Я делю инструменты по областям применимости.
Мне и на Basic писать не стыдно, если он оптимален для каких-то задач. Для каких задач оптимален Rust, я пока не понимаю. Серверную бизнес-логику писать без виртуальной машины (JVM, CLR) — идея не очень хорошая. Мобильные приложения делают всё больше на webview, либо на том, на чём предлагают разработчики Android и iOS. Десктопные приложения удобнее писать на том, на чём основной API написан (C++), либо, опять же, на webview или CLR.
Здравствуйте, CreatorCray, Вы писали:
CC>Что именно ты тут называешь "измененип итерируемого контейнера"?
Ну итерируешься по некой хеш-мапе, в процессе вызываешь функцию, которая где-то внутри добавляет в эту же мапу элементы.
Только полный нубас такой может наговнокодить, да?
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, reversecode, Вы писали:
R>>сказал же — в два раза
NB>что "в два раза"? NB>я спросил, какой объем кода перевел с одного языка на другой?
чищу раст от всевозможных комментов
пока
на ~230 кил почищенного от коммента раста
вышло ~70кил плюсов без комментов(я их вообще не использую)
но это я еще не рефакторил, так, в черную набрасываю
и там еще раста на 2 мега без комментов
R>>занимаюсь переводом токио в свободное время, не спеша
NB>зачем? что мешает написать свою библиотеку?
рядовой булочкин,
нука смотреть на свет!
каково ваше звание и к каким войскам пренадлежите?
чет мне скучно от ваших вопросов
давайте я?
кто или что мешает плюсовикам написать окуенную сетевую либу ? стандрат с++ тоже кстати дерьмо продвигает, если примут это будет финишь
да я в этом овер 20 лет и знаю все эти libuv libev libfev libevent asio folly libunifex итд
у меня всего это зоопарка где то 148 папок
и все они мне не подходят от слова совсем
Здравствуйте, Разраб, Вы писали:
Р>https://youtu.be/AH4V4M7R88k?si=LKVfBKaqx9NXXiPo
Р>мне кажется rust хорошо для программистов среднего уровня, не владеющих C++. Р>Все же работа с памятью создает большую когнитивную нагрузку.
Как связаны современный C++ и работа с памятью? Там такой же RAII как в расте.
Р>Возможно после этого можно переехать проще на ziglang. Он в чем то похож.
Даже хз в чем похож
Р>и к тому же позволяет интегрироваться с си(++).
Раст или zig?
Р>но раст реально просто. не так ли?
Раст проще C++, так как гораздо меньше способов отстрелить себе ноги. Оставаясь в safe контексте это сделать крайне сложно.
С другой стороны, оставаясь в том же safe контексте можно писать очень быстрый код, на порядки быстрее python и в разы быстрее java и .net.
НО само написание программ на Rust требует гораздо больше когнитивных усилий. Иногда сложно объяснить компилятору, что твои действия на самом деле safe, при этом нельзя просто сказать "мамой клянусь, это safe". Приходится делать через unsafe, указатели и тяжелый синтаксис.
Сам язык слаб, очень многие вещи делаются через макросы, которые сложно писать и отлаживать. Макросы ломают тулинг, замедляют компиляцию, делают сложнее отладку и диагностику ошибок.
Изучать раст, как образец новых концепций и паттернов — очень полезно. Писать на нем большие программы — сомнительно. Для локальной замены микросервисов на медленных языках раст вполне подходит.
Здравствуйте, Alekzander, Вы писали:
A>Здравствуйте, flаt, Вы писали:
F>>наследования тоже нет.
A>Серьёзно? А если надо реализовать классическую иерархию векторных объектов, например?
Не знаю, что такое классическая иерархия, но можно имплементировать интерфейсы.
И можно делать вектор юников на эти самые интерфейсы. И каждый элемент может иметь разный тип, но все они должны имплементировать один интерфейс.
Объект может имплементировать много интерфейсов, и самое крутое, в самом объекте никакие указатели на твм не нужны. Вместо этого понятие "указатель на интерфейс" означает пару "указатель на твм, указатель на объект".
но написать свою либу — я расшифровал как, вложите 100% своего времени в вашу 10% потребность такой либы
к тому же в далеком будущем, если таки реализую(а разбираюсь я с ней последние 3 года, по несколько недель в год)
то если захочеся какого то хайпа
то хайпа к условному tokio-c++ будет больше внимания
чем к my_super_network_library которых уже +10500 в гугле можно найти
Здравствуйте, reversecode, Вы писали:
R>чищу раст от всевозможных комментов R>пока R>на ~230 кил почищенного от коммента раста R>вышло ~70кил плюсов без комментов(я их вообще не использую)
70к это ничем
R>но это я еще не рефакторил, так, в черную набрасываю R>и там еще раста на 2 мега без комментов
откуда столько?
там чистого кода без комментов, утилсов и прочего всего меньше полутора
R>>>занимаюсь переводом токио в свободное время, не спеша
NB>>зачем? что мешает написать свою библиотеку?
R>да я в этом овер 20 лет и знаю все эти libuv libev libfev libevent asio folly libunifex итд R>у меня всего это зоопарка где то 148 папок R>и все они мне не подходят от слова совсем
а, решил пополнить коллекцию
понятно
R>ответ почему свою не написать — очевиден
Здравствуйте, flаt, Вы писали:
F>Даже переписывая проект на том же языке, можно сократить код в разы. F>Аналогично, можно также и раздуть.
Однажды мне написали ТЗ на >100 страниц. Я почитал и сказал что это много и надо сократить. В итоге получил тот же самый текст, в котором куча слов заменили на их сокращения, уменьшили и размер шрифта и межстрочное расстояние
PS: не совсем в тему, но почему-то навеяло )
Здравствуйте, T4r4sB, Вы писали:
TB>Не знаю, что такое классическая иерархия, но можно имплементировать интерфейсы. TB>И можно делать вектор юников на эти самые интерфейсы. И каждый элемент может иметь разный тип, но все они должны имплементировать один интерфейс. TB>Объект может имплементировать много интерфейсов, и самое крутое, в самом объекте никакие указатели на твм не нужны. Вместо этого понятие "указатель на интерфейс" означает пару "указатель на твм, указатель на объект".
там вроде были ограничения по применению dyn интерфейсов в генериках
Здравствуйте, 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>Сделать универсальную долго, муторно, дорого, и нафиг нужно если тебе за это не платят. Ну и получится плохо в итоге, ибо придётся пойти на компромиссы и похерить то, ради чего эта либа писалась изначально.
Э... Зачем был написан этот комментарий и что из него я должен был узнать?
Здравствуйте, reversecode, Вы писали:
R>>>не знаю что вы подразумеваете под этим
S>>Прежде всего то, что сделать либу, которая удовлетворяет собственные потребности -- это даже не половина дела, а может быть даже и не четверть. Вся весялуха начнется когда этой либой начнут пользоваться другие люди, особенно те, кто с вами никак не связан.
R>для всех я не делаю, хз где вы опять этого прочитали в моих словах
Тут бы спросить "где вы взяли "опять"?" Но, т.к. вы слились, то ответа не будет, увы.
Нет, речи о том, что вы сделаете либу "для всех" не было. Ибо сделать такую либу -- это явно не языком на форуме звиздеть.
R>но вы увы этого не поняли и остапа понесло....
Но увы, вы не поняли того, что вам сказали.
R>я к счастью не шмга и прочиее, не люблю болото из лесенок для скрола вверх и вниз
Шмыга хотя бы дает себе труд пользоваться нормальным русским языком и оформляет тексты так, что их можно читать, в отличии от.
S>>А зачем вам хайп?
R>программист который не увидел слова "если"
Это мне пытается пенять "программист", который не понял, что если не "если", то вопрос про хайп просто не нужен? Ну ОК, можно переформулировать специально для вас:
> то если захочеся какого то хайпа
Если вам захочется какого-то хайпа, то зачем он вам?
Здравствуйте, T4r4sB, Вы писали:
TB>А неудобочитаемые рахитектурные иерархии классов на десятки этажей — да нафиг оно нужно.
В КУ недавно была картинка про два десятка шлицев. Если представить, что каждый шлиц — это какой-то приём, тогда наследование реализаций будет что-то типа Torx. Нужно раз в год, при описании архитектуры, да ещё и не в каждом проекте. Но когда оно понадобится, чтобы описать предметную область более понятным языком, что тогда? Умники решили, что если оно нужно редко, то и биту такую из набора можно исключить? Или решили, что раз его часто используют не по делу (это чистая правда), то они будут так народ перевоспитывать? Как с форматтером и скобками на той же строке?
Если эта отвёрточная метафора не устраивает, можем поговорить о конкретике, например, обёртке над API типа WinAPI. О векторных объектах в редакторе. О любом другом сценарии, для которого использование наследования реализаций считается подходящим инструментом.
Здравствуйте, Alekzander, Вы писали:
A>В КУ недавно была картинка про два десятка шлицев. Если представить, что каждый шлиц — это какой-то приём, тогда наследование реализаций будет что-то типа Torx.
Здравствуйте, CreatorCray, Вы писали:
CC>Ошибки делают все и на всех языках. Но ошибки надо исправлять а не давать памперсам прятать их. Иначе это лишь закрепляет хреновые подходы к дизайну. CC>В итоге хреново спроектированное как то работает и не падает, после чего на это наматывают ещё слоёв и упираются в то, что всё это работает криво, медленно, и жрёт ресурсы. После чего это только взорвать и построить заново.
В этом контексте непонятно, причём тут Раст.
Разговор следует вести вообще не о том, кто крут и какие ошибки не делает, а с позиции что дешевле —
1. собрать все баги на С++ и пофиксить их,
или
2. часами ублажать компилятор.
До Раста все попытки сделать безопасный эффективный язык сводились к тому, что 1 было очевидно намного дешевле. А с Растом уже не очевидно. И это огромный прорыв.
Здравствуйте, T4r4sB, Вы писали:
TB>А тут Раст проиграет, скорее всего. У Раста MVP выйдет дольше, но будет менее глючным. Просто когда надо проверить рабочий ли подход — это не очень.
По опыту могу сказать, что программист тупит только первые пару-тройку месяцев, глядя на ошибки, которые выдаёт компилятор. Через какое-то время, благодаря дрессировке от компилятора, он привыкает к хорошим практикам и сразу пишет правильно. В итоге получается писать быстро как с правильной архитектурой, так и в стиле "заговнокодить по-быстрому, чтобы понять, нужно оно нам или нет, и прикинуть куда это потом можно развивать"
Здравствуйте, T4r4sB, Вы писали:
A>>В КУ недавно была картинка про два десятка шлицев. Если представить, что каждый шлиц — это какой-то приём, тогда наследование реализаций будет что-то типа Torx.
TB>Непонятная аналогия — словно ёж, севший на забор.
А с чем сравнить человека, который проигнорировал предложение вместо непонятной метафоры обсудить вопрос на конкретных примерах, которые ему привели?
CC>В итоге хреново спроектированное как то работает и не падает, после чего на это наматывают ещё слоёв и упираются в то, что всё это работает криво, медленно, и жрёт ресурсы. После чего это только взорвать и построить заново.
Здравствуйте, Разраб, Вы писали:
Р>https://youtu.be/AH4V4M7R88k?si=LKVfBKaqx9NXXiPo
Р>мне кажется rust хорошо для программистов среднего уровня, не владеющих C++. Р>Все же работа с памятью создает большую когнитивную нагрузку.
Работа с памятью это хорошо, но не надо ограничивать себя плинтусовым уровнем плюсов.
В расте есть модульность, есть нормальная стандартная библиотека, стандартные строки и потоки есть наконец. Это позволяет иметь нормальную экосистему библиотек, а не то фрагментированое безобразие что есть на плюсах.
Жалобы про "ублажать компилятор" вообще смешны. Научились же на автомате расставлять const ублажать компилятор С++ и ничего.
Но это лишь в общих чертах, чтобы понять язык — нужно минимум 3 месяца на нем пописать и периодически включать мозги. А для этого нужна фин. мотивация.
Здравствуйте, velkin, Вы писали:
V> Причём проблемы до сих пор остались, смена языка программирования очевидно их не решает.
ЯП это инструмент, в детстве в деревне ходил к зубному, сверло работало как отбойный молоток — по пол зуба отлетало,
взрослый в городе пошел, вжжжжыы — мелкая пыль.
От инструмента зависит можно ли решить задачу и насколько качественно.
Овладеть да, требуется любым инструментом, так как и период обучения будет разным.
Одно дело научиться дрова колоть да гвозди заколачивать, другое — смастерить лодку и т.п.
V>Обезьяна vs человека
да, видел этот фильм. интересно.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Константин Б., Вы писали:
CC>>>В итоге хреново спроектированное как то работает и не падает КБ>>Хорошо C++ описал
CC>Это подходит к куче языков но точно не к плюсам.
Здравствуйте, Разраб, Вы писали:
Р>От инструмента зависит можно ли решить задачу и насколько качественно.
Если человек сидел на C++ у которого есть ещё и ассемблерные вставки, то вот прямо что-то радикально новое или без чего он не может обходиться в других популярных языках программирования он не найдёт. Популярные языки программирования не сильно отличаются в плане инструкций, а о непопулярных действительно отличающихся мало кто говорит.
Основа языков программирования код, а код это текст. Потому я считаю двигаться нужно в сторону улучшения работы с текстом, в частности к гиперссылкам. Именно текстовый редактор это тот инструмент, который может улучшить качество и скорость написания кода. Причём улучшение произойдёт на любом текстовом языке на котором пишут программисты.
Если тебе нравятся аналогии, то представь, что тебе чем-то не понравился русский язык. Вместо того, чтобы научиться лучше с ним работать, ты переходишь на английский язык. Но он тебе тоже не совсем нравится, и тогда ты переходишь на китайский язык. Но с китайский языком тоже не очень всё понятно, и тогда ты переходишь на арабский язык.
А потом ты такой, вот там хорошо и плохо, и здесь хорошо и плохо, давай изобретём эсперанто. Но эсперанто тоже какой-то не такой, какое-то непонятное соединение европейских парадигм и что-то упущено, что есть в других языках. А мог бы просто писать на русском языке только в улучшенном текстовом редакторе.
Потому лично я за общее улучшение для всех, а не за местечковый переход на ещё один язык программирования. С моей точки зрения гораздо серьёзнее проблема размазывания алгоритма выполняющего одну задачу по коду. Из-за этого простые алгоритмы превращаются в сложные, покрываются огромным количеством абстракций. А идеи лежащие в основе сложно извлекать, даже если это свободное программное обеспечение.
Здравствуйте, Shmj, Вы писали:
S> Тут мозги включать не нужно — можно и за бесплатно языком почесать.
S> Я посмотрел Rust в общих чертах, прошел курс на https://metanit.com/
S> Но это лишь в общих чертах, чтобы понять язык — нужно минимум 3 месяца на нем пописать и периодически включать мозги. А для этого нужна фин. мотивация.
То есть, когда ты несешь пургу о квалиа и прочем, ты это с отключенным мозгом делаешь?
Здравствуйте, T4r4sB, Вы писали:
TB>Шо, всё-таки падает?
К счастью, такой говнокод, который выживает за счёт памперсов в других языках, на плюсах нежизнеспособен
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, T4r4sB, Вы писали:
TB>>Шо, всё-таки падает? CC>К счастью, такой говнокод, который выживает за счёт памперсов в других языках, на плюсах нежизнеспособен
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, T4r4sB, Вы писали:
TB>>Шо, всё-таки падает? CC>К счастью, такой говнокод, который выживает за счёт памперсов в других языках, на плюсах нежизнеспособен
В Расте он не скомпилится, только и всего.
В плюсах он как раз будет жить, но иногда загадочно падать
Здравствуйте, Разраб, Вы писали:
Р>Здравствуйте, gandjustas, Вы писали:
Р>>>и к тому же позволяет интегрироваться с си(++). G>>Раст или zig?
Р>На ziglang заявлено. т.е. как я понял можно смиксовать исходники из трех языков в одном проекте.
Здравствуйте, CreatorCray, Вы писали:
CC>Что именно ты тут называешь "измененип итерируемого контейнера"?
Классика. В одном потоке читаешь из контейнера обычным foreach, а во втором добавляешь/удаляешь элемент. Ловить проблему можно долго. Мьютексы ставить на каждый чих жаба давит. В 99,9% случаев всё работает.
Но это только с нубами случается конечно, не стоит переживать.
Здравствуйте, so5team, Вы писали:
S>Э... Зачем был написан этот комментарий и что из него я должен был узнать?
Очевидно же: мы должны были в очередной раз узнать как Креатор не любит опенсорс
Здравствуйте, T4r4sB, Вы писали:
TB>Ну я бы уже на первой строчке бы задал вопросы — типа если чар знаковый, то автор уверен, что он имеет в виду 255, а не -1?
для автора может вообще этот char не число (знаковое или беззнаковое), а некий код, имеющий шестнадцатеричное представление 0xff и, соответственно, двоичное 11111111.
Но это не важно. Он не понимает почему байт, даже знаковый, беззнаково расширенный до unsigned int (так он воспринимает преобразование char к unsigned int) вдруг становится 0xffffffff. Оказывается потому что сначала он приводится к знаковому int, а потом уже к этому int применяется преобразование (unsigned int).
То есть пишем (unsigned int)с, а на самом деле имеем (unsigned int)(int)c
Здравствуйте, sergii.p, Вы писали:
SP>Классика. В одном потоке читаешь из контейнера обычным foreach, а во втором добавляешь/удаляешь элемент. Ловить проблему можно долго. Мьютексы ставить на каждый чих жаба давит. В 99,9% случаев всё работает. SP>Но это только с нубами случается конечно, не стоит переживать.
Почему только с нубами? Некоторые "профессионалы" с двадцатью годами опыта тоже так делают
Здравствуйте, sergii.p, Вы писали:
SP> Ловить проблему можно долго. SP> Мьютексы ставить на каждый чих жаба давит. SP> В 99,9% случаев всё работает.
SP> Но это только с нубами случается конечно, не стоит переживать.
Гнать нахрен из профессии...
Здравствуйте, CRT, Вы писали:
CRT>Он не понимает почему байт, даже знаковый, беззнаково расширенный до unsigned int
Ещё раз: ЗНАКОВОЕ, расширенное до бОльшего колва бит.
CRT> так он воспринимает преобразование char к unsigned int
А ребёнок воспринимает стулья с покрывалом сверху как каменный форт, и чо теперь?
Если человек не понимает инструмента, которым пользуется, то результаты будут немного предсказуемымы.
CRT>Оказывается потому что сначала он приводится к знаковому int, а потом уже к этому int применяется преобразование (unsigned int).
Может для начала надо бы почитать про язык и его правила?
Здравствуйте, T4r4sB, Вы писали:
TB>Хорошо, что я никогда не интересовался этой дрочью, банда четырёх, гоф, паттерны... поэтому мне оно максимально безболезненно.
Если человек падает на гололёде — то это просто потому, что он не знает, что на гололёде вредно падать. Вот если бы ему заранее это сказали, то он бы не упал.
(Почему-то именно в С/С++ запредельная концентрация мамкиных кулхацкеров с такой логикой.)
Здравствуйте, пффф, Вы писали:
TB>>Хорошо, что я никогда не интересовался этой дрочью, банда четырёх, гоф, паттерны... поэтому мне оно максимально безболезненно. П>Так вот ты что такой невежда
Справедливости ради, у гофы много такого, что надо знать с одной целью: чтобы не применять. И сама гофа подчёркивала, что пишет энциклопедию, а не учебник. А то такие анекдоты бывают. Студака собеседуют: какие паттерны применял? Тот: синглтон. Не подходишь: мало применял! Я там в уголке сидел, от стыда лицо Рихтером прикрывал. Ему ещё сказали: как научишься больше применять, приходи. Если бы я был пятым лишним, я бы назвал это "фабрика невежества".
Здравствуйте, CreatorCray, Вы писали:
CRT>>Он не понимает почему байт, даже знаковый, беззнаково расширенный до unsigned int CC>Ещё раз: ЗНАКОВОЕ, расширенное до бОльшего колва бит.
а мы говорим об интуитивности. А так-то понятно что всё описано в 1000+ страниц спецификации С++.
Вот ты так понимаешь: "ЗНАКОВОЕ, расширенное до бОльшего колва бит."
а кто-то понимает так "если я преобразую в беззнаковый тип, какого хрена он знаковый бит размножает??"
в java похожие приколы
byte b=(byte)0xff;
b>>>=1;
получаем тот же 0xff в b
Что за хрень? (был когда-то вопрос у меня). Я же применяю БЕЗЗНАКОВЫЙ сдвиг >>>, то есть не должен знаковый бит копироваться в освобождаемые биты! Оказывается оператор >>> нифига не байт сдвигает — он не умеет байты сдвигать. Сначала байт расширяется до int, потом int сдвигается беззнаково — получаем 0x7fffffff, а потом результат впихивается в байт обрубая старшие биты. Потому что integer promotion
а вот такой код
byte b=(byte)0xff;
b>>>=25;
дает 0x7f
очень интуитивно.
Что им мешало сделать оператор >>> для short и byte тоже? Непонятно.
CRT>>Оказывается потому что сначала он приводится к знаковому int, а потом уже к этому int применяется преобразование (unsigned int). CC>Может для начала надо бы почитать про язык и его правила?
понятно что это правила, но эта подветка пошла от вопроса "Что не так с integer promotion?".
то есть "а не лучше ли если бы были другие правила или лучше так оставить?"
Здравствуйте, sergii.p, Вы писали:
SP>Здравствуйте, CRT, Вы писали:
SP>надо сказать, что на расте поведение аналогично
SP>
SP>let i: i8 = -1;
SP>println!("{}", i as u64);
SP>
SP>
SP>18446744073709551615
Пример не идентичный )
let i: i8 = 0xff;
println!("{}", i as u64);
error: literal out of range for `i8`
--> src\main.rs:2:17
|
2 | let i: i8 = 0xff;
| ^^^^
|
= note: the literal `0xff` (decimal `255`) does not fit into the type `i8` and will become `-1i8`
= help: consider using the type `u8` instead
= note: `#[deny(overflowing_literals)]` on by default
help: to use as a negative number (decimal `-1`), consider using the type `u8` for the literal and cast it to `i8`
|
2 | let i: i8 = 0xffu8 as i8;
| ~~~~~~~~~~~~
Здравствуйте, CRT, Вы писали:
CRT>а мы говорим об интуитивности.
Интуиция зависит от опыта, потому легко может быть разной у разных людей.
CRT>Вот ты так понимаешь: "ЗНАКОВОЕ, расширенное до бОльшего колва бит."
Мне интуитивно понятно что сначала происходит расширение битности, банально потому что я начинал с ассемблера и знаю как оно работает в проце.
CRT>а кто-то понимает так "если я преобразую в беззнаковый тип, какого хрена он знаковый бит размножает??"
Этому человеку банально не хватает знаний архитектуры железа.
CRT>Что за хрень? (был когда-то вопрос у меня). Я же применяю БЕЗЗНАКОВЫЙ сдвиг >>>, то есть не должен знаковый бит копироваться в освобождаемые биты! Оказывается оператор >>> нифига не байт сдвигает — он не умеет байты сдвигать. Сначала байт расширяется до int, потом int сдвигается беззнаково — получаем 0x7fffffff, а потом результат впихивается в байт обрубая старшие биты. Потому что integer promotion
"Учите матчасть!" (С)
CRT>понятно что это правила, но эта подветка пошла от вопроса "Что не так с integer promotion?".
С ним всё так, не так с теми, кто не знает и не хочет узнавать.
CRT>то есть "а не лучше ли если бы были другие правила или лучше так оставить?"
ЛОЛ! С++ низкоуровневый язык который растёт от железа.
Если человек не имеет базовых знаний и не желает читать документацию — будут вот такие вопросы.
Р>> ЯП это же инструмент, следовательно его нужно освоить,помимо новых идей в расте компилятор умный.
R>Освоить ради освоения, или ради чего?
Не попробуешь не узнаешь. так ведь.
Здравствуйте, Zhendos, Вы писали:
Z>Zig вообще ничем не похож и ничего нового особо не приносит. Z>В нем никаких новых идей по сравнению с С нет, только синтаксис другой.
строгая типизация, да и defer один только уже круто.
вот взять яп с исключениями. try finally
где-то ниже по коду закрыли файл(или нет).
а тут открыли и следующей строкой defer f.close();
наглядно и надежно.
Здравствуйте, Разраб, Вы писали:
Р>Не попробуешь не узнаешь. так ведь.
Хехе, ты правда не догадываешься какого объёма банка с червями открывается этой невинной фразой?
CRT>>Вот ты так понимаешь: "ЗНАКОВОЕ, расширенное до бОльшего колва бит." CC>Мне интуитивно понятно что сначала происходит расширение битности, банально потому что я начинал с ассемблера и знаю как оно работает в проце.
Понятно что расширение битности. А вот будет размножаться или нет знаковый бит при преобразовании знакового типа к более широкому беззнаковому типу — это из какой конструкции ассемблера тебе интуитивно понятно?
В ассемблере вообще у переменных нет знаковости или беззнаковости. Ты объявляешь размерность переменной: 1, 2, 4 или 8 байтов. А знаковоые они или беззнаковые ты никак не объявляешь.
Ты когда работаешь с ними, сам явно выбираешь какие команды использовать — те которые трактуют переменную как знаковую, или те которые трактуют ее как беззнаковую.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Разраб, Вы писали:
Р>>строгая типизация, да и defer один только уже круто.
S>Круто тем, что его можно забыть написать?
S>Вот взять C++, ЯП с исключениями. Никаких finally. Деструкторы рулят и бибикают.
По той же логике можно и обертку с деструктором забыть написать. Или забыть raii применить.
Вообще такую закономерность наблюдаю — чем сложнее какая-то штука делается, тем чаще про нее "забывают". А в языках где-то же самое делается просто — почему-то не забывают.
Программисты на с/с++ самые забывчивые получаются. И проецируют свой нерелевантный опыт на другие языки программирования.
Здравствуйте, Константин Б., Вы писали:
S>>Вот взять C++, ЯП с исключениями. Никаких finally. Деструкторы рулят и бибикают.
КБ>По той же логике можно и обертку с деструктором забыть написать. Или забыть raii применить.
Что характерно, что Си-программисты, которые думают, что программируют на C++, как раз и забывают.
Тогда как одно из отличий C++программистов от Си-программистов в том, что C++программисты про RAII не забывают, а используют во все поля.
КБ>Программисты на с/с++ самые забывчивые получаются.
Вообще-то само по себе "программисты на c/c++" -- это сферический конь в вакууме. Т.к. нет такого языка, как c/c++.
Но даже если забить на это (хотя зачем забивать, одно это уже отправляет ваше мнений по вполне заслуженному адресу), то пруффы какие-то будут? Или это все из личного опыта?
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Константин Б., Вы писали:
S>>>Вот взять C++, ЯП с исключениями. Никаких finally. Деструкторы рулят и бибикают.
КБ>>По той же логике можно и обертку с деструктором забыть написать. Или забыть raii применить.
S>Что характерно, что Си-программисты, которые думают, что программируют на C++, как раз и забывают. S>Тогда как одно из отличий C++программистов от Си-программистов в том, что C++программисты про RAII не забывают, а используют во все поля.
Ну вот и программисты на zig не забывают defer.
КБ>>Программисты на с/с++ самые забывчивые получаются.
S>Вообще-то само по себе "программисты на c/c++" -- это сферический конь в вакууме. Т.к. нет такого языка, как c/c++.
Да. Это два отдельных языка. Утверждение справедливо и для тех и для других.
S>Но даже если забить на это, то пруффы какие-то будут? Или это все из личного опыта?
S>>Вот взять C++, ЯП с исключениями. Никаких finally. Деструкторы рулят и бибикают.
КБ>По той же логике можно и обертку с деструктором забыть написать.
Можно. Только деструктор ты пишешь один раз при определении класса, а потом много раз пользуешься классом .
а defer тебе надо каждый раз писать при использовании.
соответственно вероятность забыть написать defer — выше. Или такая же, если ты пользуешься классом только один раз.
хотя я бы от defer или finally в С++ не отказался. Шлепать свой класс для каждого типа объекта из какого-нибудь API на С не очень удобно.
Здравствуйте, Константин Б., Вы писали:
КБ>>>Программисты на с/с++ самые забывчивые получаются.
S>>Вообще-то само по себе "программисты на c/c++" -- это сферический конь в вакууме. Т.к. нет такого языка, как c/c++.
КБ>Да. Это два отдельных языка. Утверждение справедливо и для тех и для других.
В C++ деструкторы вызываются автоматически, так что для C++программистов "справедливо" сильное переувеличение.
S>>Но даже если забить на это, то пруффы какие-то будут? Или это все из личного опыта?
КБ>Сразу после пруфов про забытые defer.
Да легко. Было сказано:
Круто тем, что его можно забыть написать?
Итак, нужно доказать что "можно забыть".
Есть ли в zig какие-то средства, которые заставляют разработчика использовать defer для освобождения ресурсов (закрытия файла, например)?
Вроде нет. А раз так, раз по рукам никто не бьет, значит забыть написать defer можно.
Заметьте, я говорил только про возможность забыть написать дефер. Я ничего не утверждал про то, что это забывают делать. И ничего про то, насколько часто они это забывают делать по сравнению с другими.
Тогда как вы высказались вот так:
Программисты на с/с++ самые забывчивые получаются.
т.е. вы говорите, что в C++ забывают чаще, чем на других языках. И вот этот вот нуждается в пруффах, которые вы, конечно же, сейчас предоставите, ведь ваша просьба была удовлетворена.
Здравствуйте, CRT, Вы писали:
CRT>хотя я бы от defer или finally в С++ не отказался. Шлепать свой класс для каждого типа объекта из какого-нибудь API на С не очень удобно.
Оно уже есть. Да и собственный вариант наговнокодить на коленке можно если не за 5мин, то за 15-20 наверняка.
Для многих C-шных библиотек, в которых функции возвращают указатели на что-то при создании (типа того же fopen), отлично работает стандартный unique_ptr с кастомным deleter-ом. Но вот почему-то об этом знают далеко не все
Здравствуйте, so5team, Вы писали:
S>Да легко. Было сказано: S>
Круто тем, что его можно забыть написать?
S>Итак, нужно доказать что "можно забыть". S>Есть ли в zig какие-то средства, которые заставляют разработчика использовать defer для освобождения ресурсов (закрытия файла, например)? S>Вроде нет. А раз так, раз по рукам никто не бьет, значит забыть написать defer можно.
Замечательно. Есть ли в С++ средства которые заставляют разработчика использовать raii для освобождения ресурсов (закрытия файла, например)?
Вроде нет. А раз так, раз по рукам никто не бьет, значит забыть использовать raii можно.
Здравствуйте, Константин Б., Вы писали:
S>>Да легко. Было сказано: S>>
Круто тем, что его можно забыть написать?
S>>Итак, нужно доказать что "можно забыть". S>>Есть ли в zig какие-то средства, которые заставляют разработчика использовать defer для освобождения ресурсов (закрытия файла, например)? S>>Вроде нет. А раз так, раз по рукам никто не бьет, значит забыть написать defer можно.
КБ>Замечательно. Есть ли в С++ средства которые заставляют разработчика использовать raii для освобождения ресурсов (закрытия файла, например)? КБ>Вроде нет. А раз так, раз по рукам никто не бьет, значит забыть использовать raii можно.
Да, можно. Разве я утверждал, что нельзя? Перечитайте, плз, еще раз то, что вам пишут.
А теперь пруфф утверждения про:
Программисты на с/с++ самые забывчивые получаются.
Здравствуйте, Константин Б., Вы писали:
КБ>Замечательно. Есть ли в С++ средства которые заставляют разработчика использовать raii для освобождения ресурсов (закрытия файла, например)?
Ну и как бы нельзя не поделиться ссылкой: ifstream (равно как и ofstream, равно как и fstream). Если вы открыли файл, то не закрыть его вы просто так уже не сможете.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Константин Б., Вы писали:
КБ>>Замечательно. Есть ли в С++ средства которые заставляют разработчика использовать raii для освобождения ресурсов (закрытия файла, например)?
S>Ну и как бы нельзя не поделиться ссылкой: ifstream (равно как и ofstream, равно как и fstream). Если вы открыли файл, то не закрыть его вы просто так уже не сможете.
Здравствуйте, Константин Б., Вы писали:
S>>Ну и как бы нельзя не поделиться ссылкой: ifstream (равно как и ofstream, равно как и fstream). Если вы открыли файл, то не закрыть его вы просто так уже не сможете.
КБ>Конечно смогу КБ>
КБ>new std::ifstream("file.txt");
КБ>
Может вам C++ подучить. Ну чтобы хоть знать предмет, о котором вы пытаетесь рассуждать?
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Константин Б., Вы писали:
S>>>Ну и как бы нельзя не поделиться ссылкой: ifstream (равно как и ofstream, равно как и fstream). Если вы открыли файл, то не закрыть его вы просто так уже не сможете.
КБ>>Конечно смогу КБ>>
КБ>>new std::ifstream("file.txt");
КБ>>
S>Может вам C++ подучить. Ну чтобы хоть знать предмет, о котором вы пытаетесь рассуждать?
Здравствуйте, Константин Б., Вы писали:
S>>>>Ну и как бы нельзя не поделиться ссылкой: ifstream (равно как и ofstream, равно как и fstream). Если вы открыли файл, то не закрыть его вы просто так уже не сможете.
КБ>>>Конечно смогу КБ>>>
КБ>>>new std::ifstream("file.txt");
КБ>>>
S>>Может вам C++ подучить. Ну чтобы хоть знать предмет, о котором вы пытаетесь рассуждать?
КБ>А может вам?
Я-то вынужден делать это регулярно. Что и позволяет увидеть, что здесь нет проблемы с закрытием файла. Здесь другая проблема, которой вы пытаетесь замаскировать тот факт, что в C++ деструкторы автоматически делают то, что в zig и Go приходится делать вручную с помощью defer.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Константин Б., Вы писали:
S>>>>>Ну и как бы нельзя не поделиться ссылкой: ifstream (равно как и ofstream, равно как и fstream). Если вы открыли файл, то не закрыть его вы просто так уже не сможете.
КБ>>>>Конечно смогу КБ>>>>
КБ>>>>new std::ifstream("file.txt");
КБ>>>>
S>>>Может вам C++ подучить. Ну чтобы хоть знать предмет, о котором вы пытаетесь рассуждать?
КБ>>А может вам?
S>Я-то вынужден делать это регулярно. Что и позволяет увидеть, что здесь нет проблемы с закрытием файла.
Т.е. файл будет закрыт? Точно C++ подучить не надо?
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Константин Б., Вы писали:
КБ>>Т.е. файл будет закрыт?
S>Ага, как только внесенную ошибку исправите.
А как дысал, как дысал. "Вон ваш zig не принуждает писать правильынй код, а С++ принуждает. Возьмите iostream и файл обязательно будет закрыт."
А оказывается надо всего лишь писать без ошибок. Собственно этим всегда разговоры о C++ и заканчиваются. Надо просто писать без ошибок и все будет хорошо.
Здравствуйте, Константин Б., Вы писали:
КБ>А как дысал, как дысал. "Вон ваш zig не принуждает писать правильынй код, а С++ принуждает. Возьмите iostream и файл обязательно будет закрыт."
Да, возьмите и будет закрыт. Если не можете, то вы ССЗБ.
Что взять в zig, чтобы не нужно было вручную его закрывать?
КБ>А оказывается надо всего лишь писать без ошибок.
Покажите мне хоть один язык, который бы это не требовал.
Здравствуйте, CreatorCray, Вы писали:
CC>Мне интуитивно понятно что сначала происходит расширение битности, банально потому что я начинал с ассемблера и знаю как оно работает в проце.
Ого, ничесе, ты знаешь как представляются числа в памяти компа!
А про какое расширение битности ты говоришь — знаковое или беззнаковое!
CC>ЛОЛ! С++ низкоуровневый язык который растёт от железа.
От какого железа? От PDP-11? Или от 8080? С++ как раз пытается быть абстрактным и кроссплатформенным, по минимуму заточенным на особенности конкретных реализаций.
Здравствуйте, Константин Б., Вы писали:
КБ>Конечно смогу КБ>
КБ>new std::ifstream("file.txt");
КБ>
И как ты сможешь это сделать случайно?
Ни один крестовик с хоть каким-то опытом не будет делать new для временного стекового объекта, это не требует внимательности.
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, Константин Б., Вы писали:
КБ>>Конечно смогу КБ>>
КБ>>new std::ifstream("file.txt");
КБ>>
TB>И как ты сможешь это сделать случайно? TB>Ни один крестовик с хоть каким-то опытом не будет делать new для временного стекового объекта, это не требует внимательности.
Ну вот прям щас сделал поиск в гитхабе, получил >7 тысяч new std::ifstream. Ткнул на случайный проект и вижу:
...
auto src_file = new std::ifstream(path);
if (!src_file->is_open())
throw std::runtime_error("Unable to open source file " + path);
...
PS: ХЗ что за проект, но у него 1800 звёзд )
PPS: справедливости ради надо сказать, что в некоторых найденных проектах народ делает сначала new std::ifstream, а затем присваивает результат во владеющий умный указатель
Здравствуйте, CRT, Вы писали:
CRT> это из какой конструкции ассемблера тебе интуитивно понятно?
В асме ты всегда явно задаёшь что хочешь получить. Если просто начнёшь работать с регистром как с более широким до того как он был использован исключительно как "узкий" то в старших битах и вовсе мусор может быть.
CRT>В ассемблере вообще у переменных нет знаковости или беззнаковости.
Там и переменных то нету
Но есть некоторые отдельные команды для знаковых операций, того же перемножения например.
CRT>Ты когда работаешь с ними, сам явно выбираешь какие команды использовать — те которые трактуют переменную как знаковую, или те которые трактуют ее как беззнаковую.
Ты выбираешь команды в зависимости от того, какой результат ты хочешь получить.
Здравствуйте, T4r4sB, Вы писали:
TB>А про какое расширение битности ты говоришь — знаковое или беззнаковое!
ДА!
CC>>ЛОЛ! С++ низкоуровневый язык который растёт от железа. TB>От какого железа? От PDP-11? Или от 8080?
TB>С++ как раз пытается быть абстрактным и кроссплатформенным, по минимуму заточенным на особенности конкретных реализаций.
С вырос как более высокоуровневый ассемблер
С++ вырос из С
Всё остальное — нашлёпки сбоку для переносимости
TB>ПС Я надеюсь, тебе не больше 20 лет?
Оставь пустые надежды
CC>В асме ты всегда явно задаёшь что хочешь получить.
еще раз, какая конструкция в ассемблере тебе дает интуитивно понять что в С++ конструкция (unsigned)char(0xff) даст 0xffffffff ?
вот именно, что в асме ты ЯВНО задаешь с помощью команд что происходит с числом. Хочешь у тебя из 0xff будет 0xffffffff, а хочешь — будет 0x000000ff. Никто и ничто не заставляет в асме тебе сделать так что у тебя получиться 0xffffffff
Здравствуйте, reversecode, Вы писали:
R>movzx movsx ?
И? Вот ты знаешь ассемблер. Ты знаешь команды movzx movsx.
Как тебе помогают эти знания понять что для реализации (unsigned int)char(0xff) будет обязательно выбрано movsx?
В этом вопрос же
CreatorCray утверждает что знание ассемблера ему позволяет интуитивно понимать что (unsigned int)char(0xff) будет равно 0xffffffff
Здравствуйте, reversecode, Вы писали:
R>когда я пишу на С/C++ я очевидно не думаю об ассемблере — я правльно ответил?
нет, неправильно. Потому что в этой подветке CreatorCray утвержает что знание ассемблере ему позволяет интуитивно понять что (unsigned int)char(0xff) будет равно 0xffffffff
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, T4r4sB, Вы писали:
TB>>А про какое расширение битности ты говоришь — знаковое или беззнаковое! CC>ДА!
Что да?
У меня ощущение, что я сейчас разговариваю с кулхацкером из 9 "Б"
Здравствуйте, ArtDenis, Вы писали:
AD>Ну вот прям щас сделал поиск в гитхабе, получил >7 тысяч new std::ifstream. Ткнул на случайный проект и вижу: AD>
AD>...
AD> auto src_file = new std::ifstream(path);
AD> if (!src_file->is_open())
AD> throw std::runtime_error("Unable to open source file " + path);
AD>...
AD>
AD>
Что любопытно, там вообще элементарно избежать подобных проблем. Вместо того, чтобы:
std::istream* source = &std::cin;
std::istream* target = nullptr;
std::ostream* output = &std::cout;
if (args.count("src")) {
auto path = args["src"].as<std::string>();
auto src_file = new std::ifstream(path);
if (!src_file->is_open())
throw std::runtime_error("Unable to open source file " + path);
source = src_file;
}
...
if (source != &std::cin)
delete source;
if (target)
delete target;
if (output != &std::cout)
delete output;
можно было бы, например, сделать так:
std::istream source_file; // Не открываем сразу.
std::istream* source = &std::cin;
std::istream target_file; // Не открываем сразу.
std::istream* target = nullptr;
std::ostream output_file; // Не открываем сразу.
std::ostream* output = &std::cout;
if (args.count("src")) {
auto path = args["src"].as<std::string>();
source_file.open(path);
if (source_file->is_open())
throw std::runtime_error("Unable to open source file " + path);
source = &source_file;
}
...
// Блок с ручным delete не нужен вообще.
AD>PS: ХЗ что за проект, но у него 1800 звёзд )
Такое ощущение, что C++ный код там писали Python-исты. Они, например, прямо в main бросают исключения не озадачившись заключить код в try..catch, как будто вылетевшее из main исключение кто-то обещал обязательно поймать и показать пользователю.
Да и вообще, наглядное свидетельство того, что как только появляется один характерный признак говнокода (слишком длинные функции), так следом обнаружатся и другие.
AD>PPS: справедливости ради надо сказать, что в некоторых найденных проектах народ делает сначала new std::ifstream, а затем присваивает результат во владеющий умный указатель
Справедливости ради нужно сказать, что я не утверждал "возьмите std::ifstream и файл будет обязательно закрыт". Дословно было сказано вот что: "Если вы открыли файл, то не закрыть его вы просто так уже не сможете." Т.е. не просто так не закрыть сможете, что Константин Б и продемонстрировал подсадив в код явный баг.
Но у него баг простой и очевидный. Можно было бы поизощреннее пример привести:
Его изобрели для одной задачи — пилить web browser, и для этой задачи оно как раз уникально подходит.
Браузерами пользуются много миллионов людей каждый день, они компилируют и запускают мегабайты чужого кода на каждый клик, а цена security bugs для них прям катастрофическая.
Например, если зловредный javascript или там css, прилетевший из какой-нибудь рекламы, сможет получить контроль над целым браузером и своровать данные из соседней закладки, в которой интернет банк — такой браузер мгновенно превратится в тыкву.
Для браузеров, безопасность кода — цель номер один.
Поэтому Rust такой. Плевать на usability, время компиляции, синтаксис из фильмов про пришельцев, время разработки, и сложности найма программистов.
Если все эти минусы чинят пару классов security bugs, именно для браузеров это всё равно хороший tradeoff.
Браузеры не уникальны, кроме них есть ещё kernel-mode куски операционных систем, гипервизоры, и возможно сервера баз данных.
Вот для такого, раст вполне норм.
Однако сторонники раста похоже верят, что это лучший в мире язык, и настойчиво предлагают переписывать на нём весь имеющейся в мире софт.
Это очень плохая идея, потому что подавляющее большинство кода, который пилят программисты, не имеет таких же требований к безопасности.
Например, почти весь user mode код уже неплохо изолирован от окружающего мира, потому что отдельный процесс, и в современных ОС ещё сверху песочницы, контейнеры, привилегии процессов, и подобное.
Скорость разработки часто имеет огромное значение для проектов.
Для кучи софта, языки вроде Java и C#, которые компилируются в байт код и автоматически управляют памятью, это очень хороший tradeoff. Они примерно такие же безопасные как тот раст, не сильно медленнее, жгут несколько больше памяти из-за GC, но память всё ещё экспоненциально дешевеет со временем.
Здравствуйте, T4r4sB, Вы писали:
AD>>Ну вот прям щас сделал поиск в гитхабе, получил >7 тысяч new std::ifstream. Ткнул на случайный проект и вижу:
TB>Мне кажется, это не очень вменяемые люди. Ну или просто не крестовики. Писали на жабошарпах всю жизнь.
А это не важно. Важно то, что пишут, не понимая всех тонкостей и даже азов. Язык позволяет, а компилятор не бъёт по рукам. Это данность и с этим ничего не поделаешь )
Здравствуйте, m2user, Вы писали:
M>Небрежные питонисты, т.к. аналогичный код является потенциально проблемным даже в языке с GC. M>Если будет исключение тут M>
M>то delete source не будет вызван. И пока GC не доберется до объекта, будет висеть открытый файловый дескриптор, препятствуя удалению файла например.
Их оправдывает то обстоятельство, что все это в main происходит: если исключение вылетит, то программа завершит свою работу и уже ОС подчистит за ней.
Подобный подход временами используют для "разовых утилит", т.к. для программ, которые запускаются, быстро что-то делают и завершают свою работу. В таких случаях даже память не освобождают в программе. Если не ошибаюсь, разработчики PVS-Studio про свой анализатор рассказывали, что они такой подход эксплуатируют: мол, на анализ файла стартует новый процесс, в этом процессе память не освобождается, т.к. при работе это не нужно (да и сложно анализ реализовывать, т.к. при освобождении памяти висячие ссылки и протухшие указатели могут появится), а после работы вся память будет освобождена после завершения процесса.
Правда, разработчики упомянутого CTranslate2/cli/translator.cc и здесь где-то на полпути остановились, зачем-то блок с delete написали. Явно не от большого опыта и хорошего понимания происходящего.
Здравствуйте, ArtDenis, Вы писали: AD>А это не важно. Важно то, что пишут, не понимая всех тонкостей и даже азов. Язык позволяет, а компилятор не бъёт по рукам. Это данность и с этим ничего не поделаешь )
Но всё же это — ненастоящие шотландцы!
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
AD>>А это не важно. Важно то, что пишут, не понимая всех тонкостей и даже азов. Язык позволяет, а компилятор не бъёт по рукам. Это данность и с этим ничего не поделаешь ) S>Но всё же это — ненастоящие шотландцы!
Может и настоящие, но необученные еще
Вообще, если посмотреть на человека, который в первый раз в жизни взялся за гвозди и молоток, то зрелище будет жалкое, да и без отбитых пальцев вряд ли обойдется. Виноват ли в этом молоток и настоящий ли шотландец за него взялся?
Ну а так-то шуруп, забитый молотком, держит лучше, чем гвоздь, закрученный отверткой. Что в обсуждаемом фрагменты мы и наблюдаем.
Здравствуйте, Sinclair, Вы писали:
S>Но всё же это — ненастоящие шотландцы!
Блин, я понимаю что эта аналогия тут сама напрашивается, но ведь и правда если крестовик без повода лепит new, то это невменько какоето а не крестовик.
Здравствуйте, so5team, Вы писали:
S>Ну а так-то шуруп, забитый молотком, держит лучше, чем гвоздь, закрученный отверткой. Что в обсуждаемом фрагменты мы и наблюдаем.
Мы наблюдаем спор двух субъективностей.
Типа программисты на С++ инстинктивно знают, где надо писать с new, а где — без new.
А программисты на zig — инстинктов лишены, потому не знают, где ставить defer, а где — не ставить.
С таким подходом я предлагаю сразу вычеркнуть из "программистов zig" всех, кто не умеет правильно defer-ить. Ведь всех не понимающих тонкости времени жизни плюсовых объектов мы из С++-программистов вычеркнули, так что пуркуа бы и не па?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Ну а так-то шуруп, забитый молотком, держит лучше, чем гвоздь, закрученный отверткой. Что в обсуждаемом фрагменты мы и наблюдаем. S>Мы наблюдаем спор двух субъективностей. S>Типа программисты на С++ инстинктивно знают, где надо писать с new, а где — без new. S>А программисты на zig — инстинктов лишены, потому не знают, где ставить defer, а где — не ставить.
Нет, спор не об этом.
Вы серьезно считаете, что пример Константин Б с "new std::ifstream" в этом споре корректен?
Здравствуйте, Sinclair, Вы писали:
S>Типа программисты на С++ инстинктивно знают, где надо писать с new, а где — без new.
Дык все очень просто: не нужно писать new
Здравствуйте, so5team, Вы писали: S>Нет, спор не об этом. S>Вы серьезно считаете, что пример Константин Б с "new std::ifstream" в этом споре корректен?
Он станет некорректен сразу после того, как компилятор надаёт ему за такое по рукам.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Вы серьезно считаете, что пример Константин Б с "new std::ifstream" в этом споре корректен? S>Он станет некорректен сразу после того, как компилятор надаёт ему за такое по рукам.
Лучше ли одно действие чем два?
Если нам нужно выполнить два действия вместо одного, то можно ли забыть второе?
Можно ли между первым и вторым действиями со временем вставить что-то, что приведет к преждевременному return-у?
Вот это все и подразумевалось, когда задавался вопрос "Круто тем, что его можно забыть написать?"
И это мы не затрагиваем такой момент как включение объекта файл в какой-то агрегат (структуру, массив, хэш-таблицу) с последующим копированием-перемещением экземпляра этого агрегата.
В качестве контраргумента приводится код, который заведомо некорректен:
auto * file = new std::ifstream{path};
... // Подразумевается, что delete не будет.
Можно ли написать такой некорректный код в C++? Да. С этим никто и не спорил.
Имеет ли смысл рассматривать то, что делает (или чего не делает) заведомо некорректный код?
Как по мне, так ни в коем случае.
Можно ли рассуждать о том, насколько сложно написать корректный код на C++?
Вполне. И, что характерно, написать корректный код не сложно. Самый простой вариант уже был показан.
Но даже если хочется именно C++ (ну у человека Java в ДНК, мозга нет в принципе), ну бывает, достаточно на вас посмотреть и почитать что вы здесь пишете. Ну OK, специально для вас:
auto file = std::make_unique<std::ifstream>(path);
Все. Остальное за нас сделает компилятор.
И опять же, нет надобности ни в каких defer.
Ну и еще одно: пример с new std::ifstream{path} -- это вообще не про отсутствие автоматического закрытия файла (которое типа было обещано). Это вообще про другой тип ошибки. Устраните эту ошибку и вы получите те самые гарантии, которые якобы не выполняются. При этом, устранив ошибку, вам не придется делать ничего дополнительного чтобы закрыть файл.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Sinclair, Вы писали:
S>>>Вы сейчас тупите или стебетесь? S>>Я абсолютно серьёзен.
S>Ну тогда давайте серьезно. Для того, чтобы написать корректный код на zig программисту нужно сделать два действия: S>
Здравствуйте, Разраб, Вы писали:
Р>В зиге вы делаете все явно(это описано в манифесте), в плюсах получается некоторая магия которую вы не контролируете.
Недавно узнал, что для некоторых программистов неявное появление this в нестатических методах класса -- это уже магия. Так что, да, неконтролируемая магия
Здравствуйте, so5team, Вы писали:
S>Недавно узнал, что для некоторых программистов неявное появление this в нестатических методах класса -- это уже магия. Так что, да, неконтролируемая магия
Здравствуйте, sergii.p, Вы писали:
SP>Классика. В одном потоке читаешь из контейнера обычным foreach, а во втором добавляешь/удаляешь элемент. Ловить проблему можно долго. Мьютексы ставить на каждый чих жаба давит. В 99,9% случаев всё работает. SP>Но это только с нубами случается конечно, не стоит переживать.
Здравствуйте, T4r4sB, Вы писали:
TB>Это та же мантра, что и у школьных кулхацкеров — они считают себя настолько скиловыми, что никогда не делают идиотских ошибок.
боясь словить data race или порчу памяти в общих для потоков объектах.
Это не идиотская ошибка.
Это показатель того, что автор не понимает, что вообще делает.
Здравствуйте, ArtDenis, Вы писали:
AD>Это не всегда получается когда нужен быстрый MVP. Уже потом в процессе написания продукта, архитектура будет постепенно улучшаться, а "дикая" многопоточка превратиться в обычную. Но на старте мне важно чтобы была возможность писать так, чтобы 1) писалось быстро без продумывания архитектуры, 2) работало как ожидается и 3) не падало на любой чих.
Любая "дикая" многопоточка в итоге приводит к одному из двух:
1. Провал проекта
2. Замене на многопоточку "нормальную"
Поскольку нормальная многопоточка — это почти всегда один из двух-трех стандартных паттернов разработки, нет никакой причины изобретать велосипед. Быстрее и дешевле сразу писать нормально.
S>Лучше ли одно действие чем два? S>Если нам нужно выполнить два действия вместо одного, то можно ли забыть второе? S>Можно ли между первым и вторым действиями со временем вставить что-то, что приведет к преждевременному return-у?
+100500
Самое главное, про что забывают, это то, что на скольно-нибудь живом проекте этот defer рано или поздно будет похерен при ручном мерже или просто в результате экспериментов. Не "может быть похерен", а именно будет, с вероятностью в 100%. С прохождением всех тестов и ревью.
И приведет к трудноотлваливаемому багу, который выстрелит через 20 релизов и который будут искать всем отделом несколько недель подряд, с перерывами только на туалет.
Здравствуйте, landerhigh, Вы писали:
L>И приведет к трудноотлваливаемому багу, который выстрелит через 20 релизов и который будут искать всем отделом несколько недель подряд, с перерывами только на туалет.
Здравствуйте, rameel, Вы писали:
L>>И приведет к трудноотлваливаемому багу, который выстрелит через 20 релизов и который будут искать всем отделом несколько недель подряд, с перерывами только на туалет. R>Это больше про C++
Вы ниасилили в плюсы?
Сочуствую. Там уже 30 лет как RAII есть.
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, Константин Б., Вы писали:
КБ>>Конечно смогу КБ>>
КБ>>new std::ifstream("file.txt");
КБ>>
TB>И как ты сможешь это сделать случайно? TB>Ни один крестовик с хоть каким-то опытом не будет делать new для временного стекового объекта, это не требует внимательности.
Не один зиговик с хоть каким-то опытом не будет создавать временный стековый объект без defer на следующей строчке. 🤷🏿
Здравствуйте, Константин Б., Вы писали:
КБ>Не один зиговик с хоть каким-то опытом не будет создавать временный стековый объект без defer на следующей строчке. 🤷🏿
Я правильно понимаю, что необходимость явно деинициализировать временный стековый объект в 2023 году — это вот прямо офигеть какая инновация?
Здравствуйте, landerhigh, Вы писали:
L>Вы ниасилили в плюсы? L>Сочуствую. Там уже 30 лет как RAII есть.
Забавно, но с колупанием с неделю я почему-то все время наблюдаю обратную ситуацию, что бы там не говорили про RAII (фича классная не спорю), но в C++ до сих пор расстрелы и лики вещь не редкая, и наведенные ошибки с этим связанные, которые как ты выразился ищут неделями при чем без перерыва на туалет, в отличие от.
И не надо рассказывать про неосиляторов, когда под боком решают даже не заморачиваться с памятью и связанными с ними ошибками, ибо дорого, долго и нудно и не всегда успешно https://rsdn.org/forum/flame.comp/8596614.1
Если не ошибаюсь, разработчики PVS-Studio про свой анализатор рассказывали, что они такой подход эксплуатируют: мол, на анализ файла стартует новый процесс, в этом процессе память не освобождается, т.к. при работе это не нужно (да и сложно анализ реализовывать, т.к. при освобождении памяти висячие ссылки и протухшие указатели могут появится), а после работы вся память будет освобождена после завершения процесса.
Но конечно, это мы просто плюсы не осилили, у тебя таких проблем нет, ну а как иначе, профессионал ведь
Здравствуйте, rameel, Вы писали:
R>И не надо рассказывать про неосиляторов, когда под боком решают даже не заморачиваться с памятью и связанными с ними ошибками, ибо дорого, долго и нудно и не всегда успешно https://rsdn.org/forum/flame.comp/8596614.1
Вообще-то говоря, такая отсылка -- это аргумент из категории Рабинович напел.
Если ссылаться именно на опыт PVS-Studio, то тогда уже на первоисточник: https://pvs-studio.ru/ru/blog/posts/cpp/0916/
При этом Андрей Карпов несколько лет назад выкладывал в публичный доступ свои соображения о том, как следует программировать на С++. И, помнится, согласиться там можно было далеко не со всем (деталей, к сожалению, уже не помню).
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, Константин Б., Вы писали:
КБ>>Не один зиговик с хоть каким-то опытом не будет создавать временный стековый объект без defer на следующей строчке. 🤷🏿
L>Я правильно понимаю, что необходимость явно деинициализировать временный стековый объект в 2023 году — это вот прямо офигеть какая инновация?
Здравствуйте, Константин Б., Вы писали:
L>>Я правильно понимаю, что необходимость явно деинициализировать временный стековый объект в 2023 году — это вот прямо офигеть какая инновация? КБ>Нет, не правильно.
Тогда выходит, что имеем язык с принудительным закатом солнца вручную.
Здравствуйте, Разраб, Вы писали:
Р>https://youtu.be/AH4V4M7R88k?si=LKVfBKaqx9NXXiPo
Р>мне кажется rust хорошо для программистов среднего уровня, не владеющих C++. Р>Все же работа с памятью создает большую когнитивную нагрузку. Р>Возможно после этого можно переехать проще на ziglang. Он в чем то похож. Р>и к тому же позволяет интегрироваться с си(++). Р>но раст реально просто. не так ли?
Нету исключений.
Я не понимаю как писать на языках без исключений. Приходится на каждом уровне забоититься о пробросе ошибок наверх.
По моему это какой то бред.
Исключения же дают возможность писать в стиле "happy path" не заморачиваясь об ошибках — обработчики ставятся на верхних уровнях.
Rust же предлагает вручную тащить это наверх самому. соответсвенно надо мержить эти ошибки вручную если на уровне отдаются разнотипные ошибки от разных API и вот это вот все.
Соответвенно разработчику предоставляется выбор — либо заниматься этим гемором с ошибками, либо вообще забивать иногда типа "я знаю здесь никогда не стрельнет"
Здравствуйте, iHateBrightVictories, Вы писали:
HBV>Здравствуйте, Разраб, Вы писали:
Р>>https://youtu.be/AH4V4M7R88k?si=LKVfBKaqx9NXXiPo
Р>>мне кажется rust хорошо для программистов среднего уровня, не владеющих C++. Р>>Все же работа с памятью создает большую когнитивную нагрузку. Р>>Возможно после этого можно переехать проще на ziglang. Он в чем то похож. Р>>и к тому же позволяет интегрироваться с си(++). Р>>но раст реально просто. не так ли?
HBV>Нету исключений.
Есть panic, как исключения, только без раскрутки стека.
HBV>Я не понимаю как писать на языках без исключений. Приходится на каждом уровне забоититься о пробросе ошибок наверх. HBV>По моему это какой то бред.
В расте это делается одним символом в конце выражения.
HBV>Исключения же дают возможность писать в стиле "happy path" не заморачиваясь об ошибках — обработчики ставятся на верхних уровнях.
Именно так и работает panic handler
HBV>Rust же предлагает вручную тащить это наверх самому.
"Тащить" это громко сказано. Синтаксический оверхэед от "тащить" меньше чем от асинхронных вызовов. А вот мерж ошибок конечно доставляет.
HBV>соответсвенно надо мержить эти ошибки вручную если на уровне отдаются разнотипные ошибки от разных API и вот это вот все.
Для этого уже давно есть готовые либы, вроде anyhow
HBV>Соответвенно разработчику предоставляется выбор — либо заниматься этим гемором с ошибками, либо вообще забивать иногда типа "я знаю здесь никогда не стрельнет"
ИМХО проблема преувеличена. Это в Go с ошибками прям совсем все плохо, а в rust геморроя очень мало. В zig его изначально нет, так как есть anyerror изначально.
Современные языки способны делать нормальную обработку ошибок без исключений.
Здравствуйте, gandjustas, Вы писали:
G>А вот мерж ошибок конечно доставляет.
В большинстве случаев удаётся агрегировать низкоуровневые ошибки в высокоуровневые через крейт thiserror. Там всё это делается автоматом. А если не удаётся, я просто использую .map_err(...)
Здравствуйте, Константин, Вы писали:
К>Его изобрели для одной задачи — пилить web browser, и для этой задачи оно как раз уникально подходит.
Не уверен, что это соответствует действительности. Изначально язык появился как хобби-проект одного чувака и даже после того как Мозилла подключилась, язык претерпевал значительные изменения. Не похоже, что разработчики изначально чётко знали, что делали.
К>Для браузеров, безопасность кода — цель номер один.
Если бы это было так, то браузеры писали бы чём-то вроде Coq или Agda.
К> Плевать на usability, время компиляции, синтаксис из фильмов про пришельцев, время разработки
Это смотря с чем мы сравниваем. Языки с GC действительно много прячут под капот и это упрощает написание бизнес-логики, но заменять растом джаву как-то странновато. А если сравнить с С++, то по этим параметрам можно поспорить.
Здравствуйте, iHateBrightVictories, Вы писали:
HBV>Здравствуйте, Разраб, Вы писали:
Р>>https://youtu.be/AH4V4M7R88k?si=LKVfBKaqx9NXXiPo
Р>>мне кажется rust хорошо для программистов среднего уровня, не владеющих C++. Р>>Все же работа с памятью создает большую когнитивную нагрузку. Р>>Возможно после этого можно переехать проще на ziglang. Он в чем то похож. Р>>и к тому же позволяет интегрироваться с си(++). Р>>но раст реально просто. не так ли?
HBV>Нету исключений. HBV>Я не понимаю как писать на языках без исключений. Приходится на каждом уровне забоититься о пробросе ошибок наверх. HBV>По моему это какой то бред. HBV>Исключения же дают возможность писать в стиле "happy path" не заморачиваясь об ошибках — обработчики ставятся на верхних уровнях.
HBV>Rust же предлагает вручную тащить это наверх самому. соответсвенно надо мержить эти ошибки вручную если на уровне отдаются разнотипные ошибки от разных API и вот это вот все. HBV>Соответвенно разработчику предоставляется выбор — либо заниматься этим гемором с ошибками, либо вообще забивать иногда типа "я знаю здесь никогда не стрельнет"
В зиге вроде и ошибки и перехват в одном флаконе. https://ziglang.org/documentation/0.8.0/#Errors
Но конечно самое крутое это в коммон лисп. там не только исключения но и сигналы и перезапуски. полнейший хаос.
Здравствуйте, DarkEld3r, Вы писали:
DE>язык появился как хобби-проект одного чувака
Этот чувак в тот момент работал в Mozilla Research, и рисёрчил там, как лучше пилить веб браузеры.
DE>Если бы это было так, то браузеры писали бы чём-то вроде Coq или Agda.
Обе этих штуки какой-то bullshit для математиков.
Браузеры не имеют отношения к математике или доказательству теорем.
Зато им необходимы практически все API операционных систем, которые в них вообще есть: многопоточность, стек TCP/IP, 3D GPU, Bluetooth, потоковое видео и аудио и кодеки для них, захват экрана, криптография, и много остального.
Интересно, что-то из перечисленного легко использовать из Coq или Agda?
BTW, одно лишь обилие ввода/вывода в браузерах делает FP языки плохо подходящими для такого.
DE>Языки с GC действительно много прячут под капот и это упрощает написание бизнес-логики, но заменять растом джаву как-то странновато. А если сравнить с С++, то по этим параметрам можно поспорить.
Следует учесть, что каких-то 25 лет назад на C++ делали вообще всё: веб приложения, мобильные приложения, десктопные приложения, бизнес-логику, и всё остальное тоже.
Поскольку разработка сложного ПО очень дорогое удовольствие, довольно много людей до сих пор используют С++ по инерции, несмотря на то что в современном мире более высокоуровневые языки подходят для такого лучше.
Здравствуйте, CreatorCray, Вы писали:
CC>Не, как раз С++ники с большим опытом понимают что тот геморрой, что создаёт ржавый подход, совершенно неоправдан ради решения проблемы, которая перед опытными С++никами и не стоИт вовсе.
А можешь назвать хотя бы один популярный продукт, который написали опытные C++-ники? А то как ни популярный продукт, так сразу куча CRE уязвимостей (значит неопытные писали)
Здравствуйте, T4r4sB, Вы писали:
TB>А так тут вопрос скорее о том, что быстрее — написать без этих строгих правил и починить все баги, или по часу ублажать компилятор на каждый чих. Мне ответ не очевиден. Но Раст это пока что самая удачная попытка плвысить безопасность, сохранив скорость и не слишком усложнить написание логики
Тут вот какое дело. Даже если быстрее починить все очевидные баги в коде на C++, всё равно множество неочевидных багов связанных с memory corruption/buffer overrun и пр. просочатся в продакшен, через которые код будут иметь злоумышленники, если он кому-то интересен.
EP>По моим наблюдениям, ошибки от которых страхует Rust (замечательно что он это делает, ничего против не имею, только за) — это меньше 1% от всех задач в большом проекте, над которым работают смесь из продвинутых и неопытных C++ программистов.
Зато эти проблемы являются причиной 70% всех серьезных уязвимостей.
Здравствуйте, mrTwister, Вы писали:
T>Тут вот какое дело. Даже если быстрее починить все очевидные баги в коде на C++, всё равно множество неочевидных багов связанных с memory corruption/buffer overrun и пр. просочатся в продакшен, через которые код будут иметь злоумышленники, если он кому-то интересен.
Все это зависит от того, для чего программа. Для геймдева важно побыстрее тяпляп и чтоб критические баги не особо лезли в глаза. Для гражданской авиации другие требования
Здравствуйте, T4r4sB, Вы писали:
TB>Все это зависит от того, для чего программа. Для геймдева важно побыстрее тяпляп и чтоб критические баги не особо лезли в глаза. Для гражданской авиации другие требования
Взять, например iMessage — подумаешь, мессежер для домохозяек просто, никак не гражданская авиация. И, там не менее, стал источником нескольких резонансных скандалов из-за RCE уязвимостей с неприятными последствиями. Но его видимо тоже неопытные программисты писали
Здравствуйте, mrTwister, Вы писали:
S>>А на каком языке он реализован? Objective-C, Swift? Чистый Си? Или таки на C++?
T>Не знаю, но принцип "нормально делай, нормально будет" ко всем одинаково подходит.
Может быть, может быть.
Но как-то странно, когда речь про C++ников и о том, чтобы на C++ писать нормально, а в качестве примера приводится софтина, написанная, скорее всего, не на C++. Можно же было бы примеры из Chrome, Firefox, MongoDB, MariaDB, KDE и прочего C++ного софта привести.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, Разраб, Вы писали:
R>Я думаю, это прекрасный язык, с замечательным синтаксисом.
R>
fn longest<'a>(a: &'a str, b: &'a str) -> &'a str {
R> if a.len() < b.len() { a } else { b }
R>}
А чё тут такого, вроде всё понятно?
В конце концов никто не говорил что Раст это новый Джава-Скрипт фреймворк с ещё более крутыми фишками. Это фундаментально отличающийся язык, настолько, что на его фоне C++ и Javascript можно скинуть в одну корзину. Rust так же не функциональный язык. Это новый подход.
https://rsdn.org/forum/flame.comp/8596614.1
