Т.е. людей фактически принуждают сменить течение на более правильное. Причем принуждают со всех сторон. А люди упираются. Называют староверами, обвиняют что им просто лень учить.
Пишут что кто принял новую веру — становятся более продуктивными и менее ошибаются.
Тут еще стоит разделить — одно дело голый C, совсем другое дело современный C++ с умными указателями.
Голый C возможно и имеет смысл заменить Rust-ом, и то не уверен. А вот C++ имеет намного более удобную ООП-реализацию, а косяки с отсутствием проверок (выход за границы массива, проверка что значение перемещено и т.д.) — не так уж критичны.
Здравствуйте, Shmj, Вы писали:
S>Т.е. людей фактически принуждают сменить течение на более правильное. Причем принуждают со всех сторон. А люди упираются. Называют староверами, обвиняют что им просто лень учить.
Понятно. Хомячки услышали новое звонкое слово и побежали на шум.
В чем вопрос-то? Взрослый специалист сам способен сознательно выбрать себе инструменты. Хомячков переведут на то, на что босс скажет. Не вижу особой темы для дискуссии-то.
Здравствуйте, Pzz, Вы писали:
S>>Т.е. людей фактически принуждают сменить течение на более правильное. Причем принуждают со всех сторон. А люди упираются. Называют староверами, обвиняют что им просто лень учить.
Здравствуйте, Dair, Вы писали:
S>>>Т.е. людей фактически принуждают сменить течение на более правильное. Причем принуждают со всех сторон. А люди упираются. Называют староверами, обвиняют что им просто лень учить.
D>Компилятор rust есть под iOS/Android?
Не знаю. Скорее всего, да. В принципе, компилятор rust есть для всего, для чего есть LLVM-ский бакенд.
Но это будет, с точки зрения системы, как на Си писать. Т.е., для iOS OK, а для Андроида — нативное приложение, не явское.
Здравствуйте, Pzz, Вы писали:
Pzz>В чем вопрос-то? Взрослый специалист сам способен сознательно выбрать себе инструменты. Хомячков переведут на то, на что босс скажет. Не вижу особой темы для дискуссии-то.
Ну видимо там не один человек решение принимает а учитывают мнение команды.
АНБ даже рекомендует отказаться от C++ в пользу Rust.
Так же в Rust более удобная централизованная система пакетов Cargo — https://crates.io/ — которая позволяет вставлять палки в колеса неугодным странам и блокировать им доступ. Мелочь — а (не) приятно.
В ответ на намерение Алмейда создать обвязку над написанными на языке Си интерфейсами файловых систем для их использования в коде на языке Rust, Тед Цо указал на то, что подобная обвязка неминуемо приведёт к проблемам, так как любое изменение Си-интерфейсов и проведение рефакторинга потребует изменения обвязки для Rust и он не хочет брать на себя лишней ответственности за исправление возникающих проблем в коде на Rust и отслеживании состояния Rust-обвязки. Код на Си постоянно развивается и если его изменение нарушит работу обвязки для Rust, это приведёт к нарушению работы и всех завязанных на эту обвязку файловых систем.
Тед также считает, что в обозримом будущем обвязка для Rust останется второстепенной и возникновение проблем в биндингах будет головной болью только для разработчиков Rust-for-Linux, а не для сообщества разработчиков файловых систем в ядре. Указано, что не все разработчики собираются изучать Rust и поэтому после внесения влияющих на другой код изменений, они смогут обновить только зависящий код на Си, но не смогут исправить Rust-обвязки, так как не знают Rust. К дискуссии также присоединился Джеймс Боттомли (James Bottomley), сопровождающий подсистему SCSI, который сказал, что чем больше семантики кодируется в обвязках, тем они становятся более ломкими с точки зрения обеспечения синхронизации.
Здравствуйте, Shmj, Вы писали:
S>Так же в Rust более удобная централизованная система пакетов Cargo — https://crates.io/ — которая позволяет вставлять палки в колеса неугодным странам и блокировать им доступ. Мелочь — а (не) приятно.
Ну, тогда неугодные страны у себя зеркало заведут...
P.S. Между прочим, официальная сборка в большинстве организаций делается на сборочных (обычно виртуальных) машинках, изолированных от интернета. В т.ч. и от crates.io. Так что дорожка в эту сторону уже протоптана...
N>В ядре Линукса с этим другая история (читать с середины новости): N>В ответ на намерение Алмейда создать обвязку над написанными на языке Си интерфейсами файловых систем для их использования в коде на языке Rust, Тед Цо указал на то, что Вот
Правильно, пускай эти растаманы сами свой линукс пишут, с блэкджеком и боксом
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Pzz, Вы писали:
Pzz>Взрослый специалист сам способен сознательно выбрать себе инструменты.
сколько ни встречал "взрослых" специалистов, все выбирают инструмент, который лучше знают. То есть если человеку религия не позволяет смотреть в сторону изыков типа Rust, то он ни при каких обстоятельствах его не выберет. Доказательную базу подведут под нужный результат — дескать "умные указатели в С++ делают то же, что и Rust", скорость нам не так важна, безопасностью можно пренебречь.
Поэтому немного смешно читать про "взрослых" специалистов. У "хомячков" как раз более подвижная психика. Они одинаково плохо знают все инструменты и могут выбрать подходящий исходя не из личных предпочтений, а более-менее обоснованно.
Здравствуйте, ononim, Вы писали:
O>Правильно, пускай эти растаманы сами свой линукс пишут, с блэкджеком и боксом
Уже — Redox.
Насколько я понимаю, проблема тут обоюдная. С одной стороны, нужная безопасная ОС типа Линукса, которую с нуля на Расте написать не могут. С другой, разработчики ядра Линукса стареют, нужна свежая кровь. Поэтому Раст в ядро идёт по согласию обеих сторон. Но потом оказывается, что не всё так просто.
Здравствуйте, sergii.p, Вы писали:
SP>сколько ни встречал "взрослых" специалистов, все выбирают инструмент, который лучше знают.
И это неплохой критерий, кстати. Не единственный, но неплохой.
SP>То есть если человеку религия не позволяет смотреть в сторону изыков типа Rust, то он ни при каких обстоятельствах его не выберет.
С религией — это не взрослые специалисты, а престарелые хомячки.
Взрослый специалист оценивает, даст ли использование нового инструмента преимущества в текущем проекте, с учетом времени на обучение и рисков. Если не проходит, то смотрит, можно ли выделить время на изучение нового инструмента из ресурсов, отведенных на саморазвитие или в качестве хобби. Если везде "нет", то увы.
SP>Поэтому немного смешно читать про "взрослых" специалистов. У "хомячков" как раз более подвижная психика. Они одинаково плохо знают все инструменты и могут выбрать подходящий исходя не из личных предпочтений, а более-менее обоснованно.
Хомячки и рады бы выбрать хайповую тулзовину, но за них менеджеры решают.
Там же, где это решение отдано на откуп хомячкам, редко какой проект успевает выпуститься раньше, чем появится новая хайповая тулзовина
Здравствуйте, Shmj, Вы писали:
S>Вы поддерживаете староверов?
Как можно не хотеть изучить и попробовать что-то новое если тем более это оплачивает работодатель.
Странно. Всегда хочется чего-то нового узнать, но не всегда на это есть время
Здравствуйте, Нomunculus, Вы писали:
Н>Как можно не хотеть изучить и попробовать что-то новое если тем более это оплачивает работодатель. Н>Странно. Всегда хочется чего-то нового узнать, но не всегда на это есть время
Возможно люди того уровня — уже посмотрели и разобрались — после чего пришли к выводу что новое — не значит лучшее. Это же не школьники.
Вот, кстати, постепенно зреет Carbon — очередной убивца C++. Может это будет настоящий убийца — так чего его два раза вставать?
Ох уж эти вечные поиски какого-то убивца. Вера в наличие убивца бредовее чем старо-верие.
Если убивец и появится, то это будет не акт убийства а постепенное и оооочееь долгое вытеснение.
Здравствуйте, sergii.p, Вы писали:
SP>сколько ни встречал "взрослых" специалистов, все выбирают инструмент, который лучше знают. То есть если человеку религия не позволяет смотреть в сторону изыков типа Rust, то он ни при каких обстоятельствах его не выберет. Доказательную базу подведут под нужный результат — дескать "умные указатели в С++ делают то же, что и Rust", скорость нам не так важна, безопасностью можно пренебречь.
Ну я посмотрел, там нихрена нет привычного, и еще с боромиром каким-то постоянно бороться предлагается. Ну его нафик, сказал я себе.
SP>Поэтому немного смешно читать про "взрослых" специалистов. У "хомячков" как раз более подвижная психика. Они одинаково плохо знают все инструменты и могут выбрать подходящий исходя не из личных предпочтений, а более-менее обоснованно.
Или безосновательно, потому что рюшечки у одного розовые, а у другого в крапинку. Какие могут быть обоснования, если ничего из ассортимента не знаешь?
Здравствуйте, Shmj, Вы писали:
S>Так же в Rust более удобная централизованная система пакетов Cargo — https://crates.io/ — которая позволяет вставлять палки в колеса неугодным странам и блокировать им доступ. Мелочь — а (не) приятно.
Лично я больше пострадал не от того, что кому-то заблокировали репозиторий, а от того, что любая хрень тащит 100500 зависимостей, раздувающих даже простейшее приложение до мегабайта. И это уже в релизе, с лто, после стрипа.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Shmj, Вы писали:
S>Т.е. людей фактически принуждают сменить течение на более правильное. Причем принуждают со всех сторон. А люди упираются. Называют староверами, обвиняют что им просто лень учить.
4 куска баксов чистыми и я тебе пишу на расте. А да на 24 месяца. Если на 3 месяца, то 8 кусков в месяц.
"Деньги вперед" (С) Сам знаешь кто.
Здравствуйте, Vzhyk2, Вы писали:
V>4 куска баксов чистыми и я тебе пишу на расте. А да на 24 месяца. Если на 3 месяца, то 8 кусков в месяц. V>"Деньги вперед" (С) Сам знаешь кто.
Так поищите — вполне возможно что найдете в развитых странах и удаленно. Если за плечами опыт 20 лет харкорного C++-а — то наверняка сейчас больше получаете, раз готовы опуститься по зарплате ради нового — то в чем проблема.
Здравствуйте, Shmj, Вы писали:
S>Вы поддерживаете староверов?
Я не вижу преимуществ Rust в тех задачах, с которыми я сталкиваюсь. Я в последнее время много пишу на C и просто не допускаю багов. Для меня это не сложно, хотя я в C особо и не специалист, так, мимо проходил по большому счёту. Писать на C легко и приятно. Это проторённый путь. Для него существует весь нужный инструментарий и в первую очередь библиотеки и SDK. Rust привносит кучу сложностей и чего ради? Убрать какие-то баги и уязвимости? А зачем мне это? Ну будут в моём коде баги, допускаю. И что? Мне за это штраф не выпишут. Найдут баг — я исправляю и всё. Я не софт для марсоходов пишу. Хорошо протестировать перед релизом и оставить вариант для апдейта, вот и всё, что надо.
Т.е. я в теории очень уважаю Rust, в каком-то своём персональном проекте я бы его обязательно использовал, просто чтобы мозги поразмять. Если у кого-то очень много денег и он хочет их мне заплатить за то, чтобы я учился писать на Rust, пожалуйста, готов эти деньги принять. Но на практике в моих задачах C это просто оптимальный вариант.
C++ я особо не рассматриваю. В целом ничего против C++, как C с некоторыми фичами из С++ не имею (хотя пока и не использую, но мысли были). Иногда они к месту. Но тот C++, который предлагают его адепты, мне точно не нужен, так же, как и Rust. Но тут мотивация немного другая. Я себя считаю фуллстак программистом. Знаю всё понемногу. С C++ так не получится, я так думаю. C++ надо или знать очень хорошо, ну или даже не пытаться применять полноценно. А знать C++ очень хорошо — смысла не вижу, для моих задач C хватает. Причём тут не только мои личные умения я рассматриваю, но и умения тех, кого могут нанять после меня на сопровождение моего кода. Людей, которые знают C, найти куда проще, чем людей, которые отлично знают С++.
Поэтому в какой-то мере я тот самый старовер, который не хочет переходить на Rust. Но всё же считаю свои аргументы обоснованными. На Rust учебный код я писал, его немного знаю, но в коммерческом коде, который я пишу, я ему места пока не вижу. Конечно это всё субъективный опыт работы в небольших компаниях в небольшой стране, где сложно подбирать квалифицированный персонал. В каком-нибудь Google ситуация будет совсем иная.
Здравствуйте, vsb, Вы писали:
vsb>Я в последнее время много пишу на C и просто не допускаю багов.
А у меня, вот, недавно случился детский баг — выход за границы памяти. Вроде чел. с 20 летним опытом постоянным практически ежедневным написанием ПО — не должен такого себе позволять — ан случилось.
Причина — ранее не сталкивался с новым C++ std::ranges — и применил не правильно. В итоге писал в память мусор.
Причем в десктопной версии оно работало нормально и баг себя не проявлял, а вот в WASM-версии просто падало без всяких опознавательных знаков.
vsb>Писать на C легко и приятно. Это проторённый путь.
Ну не знаю — чем скуднее язык — тем сложнее на нем писать. Вроде логично.
На голом C писать в ООП стиле намного сложнее чем на том же C++. И ведь все-равно пишут и вирт. функции через указатель void* и все делают. И это те же самые парадигмы по сути, т.е. ничего проще не стало — но намного больше бойлерплейт-кода и намного меньше наглядности.
Я уже не говорю про макросы, когда их много — это жуть. А язык этому способствует.
vsb>Найдут баг — я исправляю и всё.
Тут еще вопрос — как быстро вы сможете найти. Допустим, если где-то вышли за границы массива и записали мусор в память — это не сразу может себя проявить — вот в чем беда.
vsb>C++ я особо не рассматриваю. В целом ничего против C++, как C с некоторыми фичами из С++ не имею (хотя пока и не использую, но мысли были). Иногда они к месту. Но тот C++, который предлагают его адепты, мне точно не нужен, так же, как и Rust. Но тут мотивация немного другая. Я себя считаю фуллстак программистом. Знаю всё понемногу. С C++ так не получится, я так думаю. C++ надо или знать очень хорошо, ну или даже не пытаться применять полноценно.
C++ есть разных поколений — и вам не обязательно знать досконально прошлые поколения языка. Тот же auto_ptr возможно где и встретите и не будете знать что это — но это уже архаизм.
Более того — не обязательно тащить и использовать все конструкции языка. Активный язык может быть не таким уж большим для решения задач, а пассивный (т.е. читаете, но так не пишите) — со временем нарабатывается.
vsb>Людей, которые знают C, найти куда проще, чем людей, которые отлично знают С++.
Тут точно не соглашусь. Голые С-шники вообще не от мира сего, где их искать — не ясно. Возможно какой-то школьник и знает конструкции С, но сможет ли он писать код для продакшена? Конечно нет. Тут же не только тупо знание языка нужно.
Здравствуйте, Shmj, Вы писали: S>Так поищите — вполне возможно что найдете в развитых странах и удаленно. Если за плечами опыт 20 лет харкорного C++-а — то наверняка сейчас больше получаете, раз готовы опуститься по зарплате ради нового — то в чем проблема.
Сейчас для интереса поглядел в развитых странах и удаленно, считай вообще нет работ зарплата серьезно меньше чем на C/C++, при этом похоже ожидается опыт по этому делу -..дцать лет. Типа ищут экперта за зарплату мида. Еще и не возьмут опускаться по зарплате ради нового.
Здравствуйте, Shmj, Вы писали:
S>Голый C возможно и имеет смысл заменить Rust-ом, и то не уверен. А вот C++ имеет намного более удобную ООП-реализацию, а косяки с отсутствием проверок (выход за границы массива, проверка что значение перемещено и т.д.) — не так уж критичны. S>Вы поддерживаете староверов?
У Страуструпа, для тех кто не знает создателя C++, есть несколько книг, причём некоторые в нескольких изданиях.
На мой взгляд наиболее полными из них выглядят.
1. Язык программирования C++.
2. Дизайн и эволюция языка C++.
3. Программирование. Принципы и практика с использованием C++.
Книга "Дизайн и эволюция языка C++" как раз на эту тему.
Несколько рецензентов просили меня сравнить C++ с другими языками. Но я решил этого не делать. Ещё раз выскажу свою неизменную точку зрения: сравнение языков редко бывает осмысленным, а ещё реже честным. Для хорошего сравнительного анализа основных языков программирования требуется больше времени, чем можно себе позволить, нужно иметь опыт работы во многих прикладных областях, быть беспристрастным и объективным. Времени у меня нет, и вряд ли я, как создатель C++, могу рассчитывать, что многие поверят в мою беспристрастность по этому поводу.
Ещё меня беспокоит некий феномен, который я неоднократно наблюдал, когда другие пытались заняться честным сравнением языков. Авторы изо всех сил стараются быть объективными, но обязательно делают упор на каком-то одном виде приложений, одном стиле или определённой культуре программирования. А уж если один язык более известен, чем другой, то в оценке чуть ли изначально возникает некая предубежденность: дефекты хорошо известного языка признаются несущественными, для них предлагаются простые способы обхода, тогда как аналогичные изъяны в других языках объявляются фундаментальными проблемами. Но ведь часто бывает, что в менее популярном языке давно известны методы решения подобных задач, только автор сравнительного обзора о них не знает или считает неудовлетворительными, поскольку в знакомом ему языке они работать не будут.
Смысл в том, что сравнивать языки с C++ пытаются вовсе не эксперты по C++. Очередной человек пытается изучить нечто модное и начинает себя и главное других убеждать, что все вокруг дураки и не лечатся.
S>Т.е. людей фактически принуждают сменить течение на более правильное. Причем принуждают со всех сторон. А люди упираются. Называют староверами, обвиняют что им просто лень учить.
А между прочим это аргумент про лень учить новый язык.
Я не боюсь того, кто изучает 10'000 различных языков программирования.
Я боюсь того, кто изучает один язык программирования 10'000 раз.
Здравствуйте, Shmj, Вы писали:
S>Так же в Rust более удобная централизованная система пакетов Cargo — https://crates.io/ — которая позволяет вставлять палки в колеса неугодным странам и блокировать им доступ. Мелочь — а (не) приятно.
Здравствуйте, Doom100500, Вы писали:
S>>Ну не знаю — чем скуднее язык — тем сложнее на нем писать. Вроде логично.
D>Гошники в недоумении...
действительно просто, даже кнопка есть
PS: Если серьёзно — знакомые что на нём пишут говорят, что уровень копипастинга превосходит все мыслимые пределы, а язык этому очень активно способствует.
Здравствуйте, Shmj, Вы писали:
vsb>>Писать на C легко и приятно. Это проторённый путь.
S>Ну не знаю — чем скуднее язык — тем сложнее на нем писать. Вроде логично.
S>На голом C писать в ООП стиле намного сложнее чем на том же C++. И ведь все-равно пишут и вирт. функции через указатель void* и все делают. И это те же самые парадигмы по сути, т.е. ничего проще не стало — но намного больше бойлерплейт-кода и намного меньше наглядности.
S>Я уже не говорю про макросы, когда их много — это жуть. А язык этому способствует.
У меня почти никогда не бывает потребности в ООП и в макросах (кроме примитивных #define для констант). Я пишу просто — есть функции, есть структуры. Всё моё "ООП" это передача структуры первым параметром и именование функций по имени структуры для группировки. А чтобы виртуальные функции нужны были — ну теоретически такое могу представить, на практике это скорей исключение.
S>C++ есть разных поколений — и вам не обязательно знать досконально прошлые поколения языка. Тот же auto_ptr возможно где и встретите и не будете знать что это — но это уже архаизм.
S>Более того — не обязательно тащить и использовать все конструкции языка. Активный язык может быть не таким уж большим для решения задач, а пассивный (т.е. читаете, но так не пишите) — со временем нарабатывается.
Я не представляю себе такого использования языка. Это надо быть кем-то вроде джуниора в команде с опытным товарищем, чтобы тебе выделяли конкретные задачи, где хватит этого подмножества. Я в такой ситуации никогда не оказывался, мне всегда приходилось делать всё самому, от начала до конца. Поэтому я не представляю себе использования любого языка не зная его досконально, "от и до". И для большинства языков мне не составляет сложности его изучить. Тот же Kotlin я в своё время за несколько часов изучил. Просто прочитал доку от начала до конца, там несколько десятков страниц и из них 80% можно проглядеть по диагонали. После чего я его успешно применял. С С++ так не получится.
vsb>>Людей, которые знают C, найти куда проще, чем людей, которые отлично знают С++.
S>Тут точно не соглашусь. Голые С-шники вообще не от мира сего, где их искать — не ясно. Возможно какой-то школьник и знает конструкции С, но сможет ли он писать код для продакшена? Конечно нет. Тут же не только тупо знание языка нужно.
С знает почти любой, кто учился в университете по IT направлению. И даже те, кто его потом не применял — легко вспомнят и освоят недостающее, т.к. язык крайне простой и небольшой.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Shmj, Вы писали:
S>>Так же в Rust более удобная централизованная система пакетов Cargo — https://crates.io/ — которая позволяет вставлять палки в колеса неугодным странам и блокировать им доступ. Мелочь — а (не) приятно.
FR>Не позволяет, можно поднять локальное зеркало всего одной командой с помощью https://github.com/panamax-rs/panamax
Этого мало. А на вшивость кто будет проверять эти пакеты? В случае дистрибутивов линукса худо-бедно пакеты проверяют мейнтейнеры дистрибутивов, за что и отвечают. Создатель дистрибутива российского, в целом, отвечает по закону. А здесь кто гарантирует, что от репозитория не прилетит какая зараза? У любителей node.js опыт уже имеется
S>>Более того — не обязательно тащить и использовать все конструкции языка. Активный язык может быть не таким уж большим для решения задач, а пассивный (т.е. читаете, но так не пишите) — со временем нарабатывается.
vsb>Я не представляю себе такого использования языка.
Тем не менее такой вариант использования очень распространен.
vsb>Это надо быть кем-то вроде джуниора в команде с опытным товарищем, чтобы тебе выделяли конкретные задачи, где хватит этого подмножества.
Обычно такого небольшого подмнождества хватит на подавляющее большинство задач. Закон Парето работает и здесь.
И совсем не обязательно нужен опытный товарищ. Во-первых, вместо опытного товарища бывает достаточно легаси-кода, к которому надо что-то свое добавить и на который можно смотреть как на образец. Во-вторых, если надо — можно и с нуля разобраться по документации, не углубляясь в дебри.
vsb>Я в такой ситуации никогда не оказывался, мне всегда приходилось делать всё самому, от начала до конца. Поэтому я не представляю себе использования любого языка не зная его досконально, "от и до". И для большинства языков мне не составляет сложности его изучить. Тот же Kotlin я в своё время за несколько часов изучил. Просто прочитал доку от начала до конца, там несколько десятков страниц и из них 80% можно проглядеть по диагонали. После чего я его успешно применял. С С++ так не получится.
Я в подобных ситуациях оказывался не раз. Но далеко не всегда при этом изучал новый язык или технологию досконально, иногда ограничивался достаточным уровнем поверхностного изучения. Не то чтобы изучать было сложно, но просто не было такой цели и были более приоритетные задачи.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Shmj, Вы писали:
S>>Вы поддерживаете староверов?
vsb>Я не вижу преимуществ Rust в тех задачах, с которыми я сталкиваюсь. Я в последнее время много пишу на C и просто не допускаю багов.
Ах вот оно как всё просто. Пойду коллегам расскажу, чтоб тоже не допускали багов.
Здравствуйте, netch80, Вы писали:
N>PS: Если серьёзно — знакомые что на нём пишут говорят, что уровень копипастинга превосходит все мыслимые пределы, а язык этому очень активно способствует.
Здравствуйте, Bigger, Вы писали:
O>>Правильно, пускай эти растаманы сами свой линукс пишут, с блэкджеком и боксом B>Так уже написали
А можешь вот этот момент пояснить?
Вместо адресации через URL (например, для записи в лог мог использоваться URL "log://", а для сетевого взаимодействия "tcp://") задействован традиционный для Unix-систем формат файловых путей, что положительно повлияло на совместимость с программами и библиотеками POSIX/Linux.
Здравствуйте, vsb, Вы писали:
vsb>У меня почти никогда не бывает потребности в ООП и в макросах (кроме примитивных #define для констант). Я пишу просто — есть функции, есть структуры. Всё моё "ООП" это передача структуры первым параметром и именование функций по имени структуры для группировки.
O>Правильно, пускай эти растаманы сами свой линукс пишут, с блэкджеком и боксом
Вот вот. Ведут себя как долбанные черви-паразиты, присасывающиеся к чужой славе. У самих ни одного проекта калибра Linux, Unreal Engine, WebKit за плечами. У самих даже примитивная хрень типа эмуляторов терминалов настолько онкологически раздута, что бинари в десятки мегов весом. Боюсь представить, сколько терабайт занимали бы ОС или веб-движки в их исполнении.
vsb>>Людей, которые знают C, найти куда проще, чем людей, которые отлично знают С++. S>Тут точно не соглашусь. Голые С-шники вообще не от мира сего, где их искать — не ясно. Возможно какой-то школьник и знает конструкции С, но сможет ли он писать код для продакшена? Конечно нет. Тут же не только тупо знание языка нужно.
Они таки существуют, и в количестве, но есть пара нюансов:
1. Они заняты. Пилят ядро, гном, постгрес, ffmeg и т.д.
2. У них самомнение выше крыши. До написания очередного опердня и сервиса доставки еды они точно не снизойдут. Поэтому-то бизнюкам и приходится искать и людей попроще, и использовать языки, ведущие за ручку.
D>Компилятор rust есть под iOS/Android?
Да. Однако, как и всё в мире раста, оно производит глубокое впечатление сделанного для галочки, а не для реального мира. Был у нас в компании один такой проект. Через год новая версия Раста с новыми тулингами-обвязками, разумеется, его не собирала, и валилась с мегатоннами ошибок. То есть никакой стандартизации, никакой обратной совместимости, никаких комитетов, спецификаций и конкурирующих реализаций. Детский сад, короче.
Здравствуйте, zx zpectrum, Вы писали:
D>>Компилятор rust есть под iOS/Android? ZZ>Да. Однако, как и всё в мире раста, оно производит глубокое впечатление сделанного для галочки, а не для реального мира. Был у нас в компании один такой проект. Через год новая версия Раста с новыми тулингами-обвязками, разумеется, его не собирала, и валилась с мегатоннами ошибок. То есть никакой стандартизации, никакой обратной совместимости, никаких комитетов, спецификаций и конкурирующих реализаций. Детский сад, короче.
панятна, спасибо.
Я-то просто имею опыт кроссплатформенной разработки iOS/Android, когда бизнес-логика (в терминах архитектур MV* – слой Model и, возможно что угодно кроме слоя View), пилится кроссплатформенно на С++, а View пишется на родном для платформы фреймворке.
Если ВНЕЗАПНО Rust мог бы заменить C++ для этого — это было бы интересно.
Пока что удивительным образом может подходить Kotlin Native.
Здравствуйте, vsb, Вы писали:
vsb>У меня почти никогда не бывает потребности в ООП и в макросах (кроме примитивных #define для констант). Я пишу просто — есть функции, есть структуры. Всё моё "ООП" это передача структуры первым параметром и именование функций по имени структуры для группировки. А чтобы виртуальные функции нужны были — ну теоретически такое могу представить, на практике это скорей исключение.
ООП нужно для определенного класса задач — общая суть которых — язык. DSL (Domain-Specific Languages), язык описания элементов пользовательского интерфейса (GUI), или язык описания DOM, AST (abstract syntax tree).
Вообще вся наша цивилизация держится на языках — язык математики, разработки ПО и пр. И для всех задач, так или иначе связанных с более-менее сложным языком — нужно ООП.
Вот в том же Gnome Builder вроде пишут GUI на голом C, но по сути используют ООП. При этом весьма неудобно — куча бойлерплейт кода с макросами.
S>>Более того — не обязательно тащить и использовать все конструкции языка. Активный язык может быть не таким уж большим для решения задач, а пассивный (т.е. читаете, но так не пишите) — со временем нарабатывается.
vsb>Я не представляю себе такого использования языка.
Да ну как! Это ваше большое заблуждение.
По сути для разработки вам нужно знать около 100 вещей:
1. Как объявить ячейки для хранения данных, какие у них типы.
2. Циклы, условия и пр.
3. Структуры данных и удобная работа с ними — классы это или ваш вариант с void*
4. Работа с контейнерами — список, словарь и т.д.
5. Работа с памятью, динамическое выделение памяти. В C++ это автоматизировали уже частично.
6. Потоки, блокировки и пр.
7. И т.д.
И это все нужно знать, не зависимо от языка. В Си вам тоже нужно каждый из этих 100+ пунктов знать.
S>>Тут точно не соглашусь. Голые С-шники вообще не от мира сего, где их искать — не ясно. Возможно какой-то школьник и знает конструкции С, но сможет ли он писать код для продакшена? Конечно нет. Тут же не только тупо знание языка нужно. vsb>С знает почти любой, кто учился в университете по IT направлению. И даже те, кто его потом не применял — легко вспомнят и освоят недостающее, т.к. язык крайне простой и небольшой.
Просто знание языка не позволит сделать что-либо полезное.
Здравствуйте, Shmj, Вы писали:
S>Т.е. людей фактически принуждают сменить течение на более правильное. Причем принуждают со всех сторон. А люди упираются. Называют староверами, обвиняют что им просто лень учить.
Свободный мир — он такой.
Я посмотрю на Rust не раньше, чем его стандартизуют. Нет стандарта — не язык.
D>Я-то просто имею опыт кроссплатформенной разработки iOS/Android, когда бизнес-логика (в терминах архитектур MV* – слой Model и, возможно что угодно кроме слоя View), пилится кроссплатформенно на С++, а View пишется на родном для платформы фреймворке.
D>Если ВНЕЗАПНО Rust мог бы заменить C++ для этого — это было бы интересно.
В роли бизнес-логики на iOS/Android может работать, внезапно, даже гошечка.
Сам такой изврат не практиковал, однако официальный клиент Wireguard на айфинчиках уже много лет работает. Что удивительно, даже батарею при этом не высаживает, как многие другие постоянно включенные VPN
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, netch80, Вы писали:
N>>PS: Если серьёзно — знакомые что на нём пишут говорят, что уровень копипастинга превосходит все мыслимые пределы, а язык этому очень активно способствует.
T>Вопросы к знакомым, а не к го
Учитывая, что они из совсем разных фирм и кругов — таки к го.
Здравствуйте, AntoxaM, Вы писали:
AM> vsb>Я не вижу преимуществ Rust в тех задачах, с которыми я сталкиваюсь. Я в последнее время много пишу на C и просто не допускаю багов. AM> Ах вот оно как всё просто. Пойду коллегам расскажу, чтоб тоже не допускали багов.
Да-да, расскажи, а то х#й кладут на культуру разработки, а потом бегают в коричневых штанах, серебрянную пулю ищут
Здравствуйте, Dair, Вы писали:
D> Если ВНЕЗАПНО Rust мог бы заменить C++ для этого — это было бы интересно.
D> Пока что удивительным образом может подходить Kotlin Native.
Когда я смотрел котлин натив, он был тормознее котлин жэвээм
Здравствуйте, Shmj, Вы писали:
S>Голый C возможно и имеет смысл заменить Rust-ом, и то не уверен. А вот C++ имеет намного более удобную ООП-реализацию, а косяки с отсутствием проверок (выход за границы массива, проверка что значение перемещено и т.д.) — не так уж критичны.
симпатичный видосик от letsgetrusty https://www.youtube.com/watch?v=sjsnuirLyKM
Правда на английском, но он там довольно понятный. Одна из интересных идей, что новые фичи (типа умных указателей) языку безопасности не прибавляют, так как всё равно остаются способы отстрелить себе ногу. Так что С++ только могила исправит.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, AntoxaM, Вы писали:
AM>> vsb>Я не вижу преимуществ Rust в тех задачах, с которыми я сталкиваюсь. Я в последнее время много пишу на C и просто не допускаю багов. AM>> Ах вот оно как всё просто. Пойду коллегам расскажу, чтоб тоже не допускали багов.
R>Да-да, расскажи, а то х#й кладут на культуру разработки, а потом бегают в коричневых штанах, серебрянную пулю ищут
тоже весь в белом и без багов? ну-ну, верим.
Здравствуйте, netch80, Вы писали:
N>Учитывая, что они из совсем разных фирм и кругов — таки к го.
Хз, у меня другой опыт. Копипаста на го (и не только на го) — это добровольный выбор программиста. Кривая абстракция может сэкономить пару строк копипасты за счет существенного усложнения кода и в го комьюнити так делать просто не принято. Но при этом сам язык тебя ни в чем не ограничивает, хочешь делать кривые абстракции для экономии 2-х строк кода — флаг в руки и вперед. А если смог придумать не кривую, а хорошую абстракцию, то и тем более проблем нет.
Здравствуйте, L.K., Вы писали:
LK>Староверы победили, переход на Rust отменяется, теперь можно просто освоить безошибочную писанину на С++: LK>https://habr.com/ru/news/842994/
Ну не факт что это будет одобрено староверами. Возможно признают как ересь.
Здравствуйте, FR, Вы писали:
FR>Главпингвин точно не одобрит C++.
Ну там же разные тусовки. В C свои староверы, в C++ — свои. Это как сравнить язычников и христианских староверов. А им хотят навязать модное православие. Какова будет реакция?
Здравствуйте, sergii.p, Вы писали:
SP>симпатичный видосик от letsgetrusty https://www.youtube.com/watch?v=sjsnuirLyKM SP>Правда на английском, но он там довольно понятный. Одна из интересных идей, что новые фичи (типа умных указателей) языку безопасности не прибавляют, так как всё равно остаются способы отстрелить себе ногу. Так что С++ только могила исправит.
Ролик пересмотрел, очень четкая дикция у ведущего, прямо приятно слушать, редко встретишь в техно-роликах.
Но дело в том что мы тут не пальцем деланы. Я прошел вступительные уроки по Rust и понимаю все эти фишки, не отрицаю полезности. Однако же есть и очевидные минусы, как-то отсутствие полноценного ООП как в C++/Java а так же слишком большое обилие макросов. Ну и отсутствие кодовой базы в таком же количестве, как у C++. По этому даже когда была возможность выбрать технологию для проекта, решил писать на ++ и не экспериментировать.
ZZ>Что удивительно, даже батарею при этом не высаживает, как многие другие постоянно включенные VPN
PS. И что еще более прикольно, гошечка со сборщиком мусора, работая внутри Wireguard/iOS в режиме туннельного провайдера, даже за квоты RAM не выходит. А в iOS у сетевых App Extensions довольные жесткие лимиты. Во времена шестого айфончика потолок по RSS был 15 Mb, на середнячковых девайсах что-то в районе 40-ка мегов, на самых жирных распоследних устройствах, ЕМНИП, 120. Так даже на шестом айфоне, пока Wireguard/iOS его поддерживал, он летал и не падал.
Нововеры хотят захватить Линукс своим недоделанным растом. Хотя казалось бы начни с Линукса перепиши все то, что там плохое по их мнению потому что на C. Назови новую ось Супернуксом и наслаждайся как на него все переходят а Линукс остается в забвении.
Здравствуйте, zx zpectrum, Вы писали:
D>>Компилятор rust есть под iOS/Android? ZZ>Да. Однако, как и всё в мире раста, оно производит глубокое впечатление сделанного для галочки, а не для реального мира. Был у нас в компании один такой проект. Через год новая версия Раста с новыми тулингами-обвязками, разумеется, его не собирала, и валилась с мегатоннами ошибок. То есть никакой стандартизации, никакой обратной совместимости, никаких комитетов, спецификаций и конкурирующих реализаций. Детский сад, короче.
Самое главное не рассказали. Выходы за пределы массива были? Обращения к освобожденной памяти?
Здравствуйте, Pzz, Вы писали:
Pzz>В чем вопрос-то? Взрослый специалист сам способен сознательно выбрать себе инструменты. Хомячков переведут на то, на что босс скажет. Не вижу особой темы для дискуссии-то.
Ну вот же пример привели взрослых специалистов не способных выбрать себе инструменты.
Здравствуйте, L.K., Вы писали:
S>>Вы поддерживаете староверов?
LK>Староверы победили, переход на Rust отменяется, теперь можно просто освоить безошибочную писанину на С++:
LK>https://habr.com/ru/news/842994/
Лол , С++ с борзочекером это полная хрень. В чем тогда смысл не учить Руст?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
— без полноценного ООП это не возможно. Ну не то чтобы не возможно, но не удобно, а так то и на Си можно забульбашить.
Скоро зреет новый ЯП — Carbon. Возможно он сможет заменить Rust.
TB>2. При наличии борзочекера всё равно придётся забыть все старые привычки, и старый код компилироваться не будет
Здравствуйте, T4r4sB, Вы писали:
S>>Новичков удалось убедить что ООП уже как не круто, не модно.
TB>Ну и слава богу, будет меньше "программистов", которые без абстрактных фабрик 2+2 сложить не могут.
А что, Rust имеет какие-то средства противодействия чему-то вроде (код условный):
Здравствуйте, пффф, Вы писали:
vsb>>У меня почти никогда не бывает потребности в ООП и в макросах (кроме примитивных #define для констант). Я пишу просто — есть функции, есть структуры. Всё моё "ООП" это передача структуры первым параметром и именование функций по имени структуры для группировки.
П>Поздравляю. Ты изобрёл классы, их методы и this
В догонку. Сишники такие смешные. Пишут на C++, но на C. Нет чтобы писать на C++ сразу на C++, всё какие-то костыли изобретают
Здравствуйте, vsb, Вы писали:
vsb>В целом ничего против C++, как C с некоторыми фичами из С++ не имею (хотя пока и не использую, но мысли были).
Если таки заставите себя перейти с C на разумное подмножество C++, то не потеряете ничего полезного — возможно, лишь часть вредных привычек, да сомнительную практику предельно краткой записи. А выиграете немало. В первую очередь — возможность указать компилятору "тут я замыслил делать вот так, и бей меня по рукам, если я где-то попробую сделать иначе".
Но да, придется сопротивляться адептам "канонического C++". Пока Вы используете чистый C, мало кому придет в голову упрекать Вас в неиспользовании тех или иныых свойств языка — там это весьма либерально. Даже собственные реализации каких-нибудь memcpy/strcat не вызывают такого баттхёрта, как реализации new/delete или тех же векторов/списков вместо готовых из STL.
vsb>тот C++, который предлагают его адепты, мне точно не нужен
Он много кому не нужен. Но мало кто находит в себе силы не прогнуться под давлением сообщества.
vsb>C++ надо или знать очень хорошо, ну или даже не пытаться применять полноценно. А знать C++ очень хорошо — смысла не вижу
Знать его "очень хорошо", чтоб не лазить периодически в стандарты/справочники, требуется только тем, кто участвует в собеседованиях (с обеих сторон). А знать то самое разумное подмножество, чтоб не лазить в документацию слишком часто, вовсе не сложно — в нем все почти так же, как и в C, новых принципов/правил немного, и большинство понятно интуитивно.
vsb>для моих задач C хватает.
Ну, чисто функционально для любой задачи хватает и машинного кода. Такой аргумент имеет смысл, когда для изучения и/или применения нового инструмента требуются значительные затраты ресурсов. Для "канонического" C++ они действительно значительны — как на изучение, так и на выполнение, обеспечение совместимости, поиск ошибок и т.п. А для C++ уровня где-то самого начала 90-х, когда правила наследования, использования конструкторов/деструкторов и прочих основных вещей, уже устаканились, а шаблонная магия еще не вошла в моду, и шаблоны использовались только для простого и наглядного обобщения, затраты на изучение невелики, а на все остальное — равны нулю, ибо те возможности C++, что функционально не отличаются от сишных, не порождают оверхэда вообще.
vsb>не только мои личные умения я рассматриваю, но и умения тех, кого могут нанять после меня на сопровождение моего кода. Людей, которые знают C, найти куда проще, чем людей, которые отлично знают С++.
Это да — типичный "современный плюсовик", особенно малоопытный, увидев код, не использующий STL, впадает минимум в когнитивный диссонанс, а максимум — в панику.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Но да, придется сопротивляться адептам "канонического C++". Пока Вы используете чистый C, мало кому придет в голову упрекать Вас в неиспользовании тех или иныых свойств языка — там это весьма либерально. Даже собственные реализации каких-нибудь memcpy/strcat не вызывают такого баттхёрта, как реализации new/delete или тех же векторов/списков вместо готовых из STL.
Батхерт от собственных реализаций "тех же векторов/списков" происходит от того, что ничего нового, кроме кучи багов, эти реализации не добавляют обычно.
ЕМ>Это да — типичный "современный плюсовик", особенно малоопытный, увидев код, не использующий STL, впадает минимум в когнитивный диссонанс, а максимум — в панику.
Много ты видел типичных современных плюсовиков?
И да, при прочих равных всегда лучше использовать STL. Потому что кроме гарантий качества, классы STL дают и гарантии по интерфейсу (ты уже знаешь, что и как использовать), и гарантии по времени выполнения, гарантии по инвалидации итераторов, и тд и тп.
А наколеночные поделки изобилуют багами и умолчаниями, о которых ты не знаешь; постоянно надо лезть в сорцы и искать, как сделать то-то и то-то (документации же конечно нет); и сидишь в итоге на нервяке — вопрос не в том упадёт или нет, вопрос в том, насколько быстро это произойдёт, и размер проблем от этого
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это да — типичный "современный плюсовик", особенно малоопытный, увидев код, не использующий STL, впадает минимум в когнитивный диссонанс, а максимум — в панику.
Ну от QT то точно никто в панику не впадет — QT продуман со всех сторон, на нем пишешь и ощущение как будто это почти .Net.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>как реализации new/delete или тех же векторов/списков вместо готовых из STL.
ЕМ>А знать то самое разумное подмножество, чтоб не лазить в документацию слишком часто, вовсе не сложно — в нем все почти так же, как и в C, новых принципов/правил немного, и большинство понятно интуитивно.
Очередная демонстрация незнания предмета. Без хорошего знания особенностей C++ сделать свой аналог std::vector будет не просто.
Здравствуйте, Nuzhny, Вы писали:
N>нужная безопасная ОС типа Линукса, которую с нуля на Расте написать не могут.
Software Rendering
We don't have GPU drivers yet but LLVMpipe (OpenGL CPU emulation) is working.
Если не могут написать с нуля на расте, тогда зачем мучают 5 точку? Вон в MS когда-то хотели всю OS на пончике запилить, но что-то пошло не так. На жаве попытки были "чистой безопасной OS".
Здравствуйте, so5team, Вы писали:
S>Очередная демонстрация незнания предмета. Без хорошего знания особенностей C++ сделать свой аналог std::vector будет не просто.
А свой аналог List на C# — легко сделать? Для частного случае, для себя, чтобы иметь ограниченное количество вариантов использования — не проблема. А вот чтобы это работало для других людей и миллионы людей с сотнями тысяч вариантов использования остались довольны — уже задача не такая уж простая
Здравствуйте, T4r4sB, Вы писали:
TB>ООП переоценено. TB>На самом деле да
Были времена, когда ООП стало модным и начали пихать во все щели, причем не по делу. Потом маятник качнулся в обратную сторону и начали убеждать что оно нафиг не нужно. Сейчас все более-менее устаканилось и стало ясно что ООП. весьма удобный и полезный инструмент, лишать себя которого нет смысла — т.е. язык без ООП даже рассматривать не стоит.
FR>>Не позволяет, можно поднять локальное зеркало всего одной командой с помощью https://github.com/panamax-rs/panamax
D>Этого мало. А на вшивость кто будет проверять эти пакеты?
Это уже другая проблема.
D>В случае дистрибутивов линукса худо-бедно пакеты проверяют мейнтейнеры дистрибутивов, за что и отвечают. Создатель дистрибутива российского, в целом, отвечает по закону. А здесь кто гарантирует, что от репозитория не прилетит какая зараза? У любителей node.js опыт уже имеется
Реально никто нигде ничего не гарантирует, в том числе и популярные дистрибутивы линукса. Как пример троян в базовых iso linux mint https://www.opennet.ru/opennews/art.shtml?num=43915 . Другой пример недавний бекдор в библиотеке zx которая распространяется без всяких менеджеров пакетов, и вполне успела заразить и несколько роллинг дистрибутивов линукс и неизвестное число разработчиков тупо скачавших релизы с гитхаба.
И если вернутся к расту то там за безопасностью пакетов тоже в меру возможностей следят https://rustsec.org/ и есть удобная утилита для проверки своих проектов.
Здравствуйте, Shmj, Вы писали:
S>Были времена, когда ООП стало модным и начали пихать во все щели, причем не по делу. Потом маятник качнулся в обратную сторону и начали убеждать что оно нафиг не нужно. Сейчас все более-менее устаканилось и стало ясно что ООП. весьма удобный и полезный инструмент, лишать себя которого нет смысла — т.е. язык без ООП даже рассматривать не стоит.
Если язык без ООП даже рассматривать не стоит, значит, снова пихать его во все щели?
Интересно, как мне удалось обходиться без ООП, когда я JNI делал?
Здравствуйте, Shmj, Вы писали:
S>Во все щели пихать что угодно — это плохая практика, хотя и популярная. Пихать шаблоны во всех щели или лямбды — так же плохо, как и пихать ООП.
Здравствуйте, Privalov, Вы писали:
P>В предыдущем сообщении было: P>
P>язык без ООП даже рассматривать не стоит
P>Это разве не означает "пихать во все щели"?
Нет. Если в языке есть ООП но ваша текущая задача его не требует — то не используйте. Вторая задача потребует ООП и вы будете писать на привычном вам языке.
S>Нет. Если в языке есть ООП но ваша текущая задача его не требует — то не используйте. Вторая задача потребует ООП и вы будете писать на привычном вам языке.
А если в языке нет ООП и текущая задача его не требует, рассматривать?
Здравствуйте, Privalov, Вы писали:
S>>Нет. Если в языке есть ООП но ваша текущая задача его не требует — то не используйте. Вторая задача потребует ООП и вы будете писать на привычном вам языке.
P>А если в языке нет ООП и текущая задача его не требует, рассматривать?
Здравствуйте, пффф, Вы писали:
П>Батхерт от собственных реализаций "тех же векторов/списков" происходит от того, что ничего нового, кроме кучи багов, эти реализации не добавляют обычно.
До сих пор контейнеры STL не имеют метода contains().
Здравствуйте, FR, Вы писали:
ЕМ>>В первую очередь — возможность указать компилятору "тут я замыслил делать вот так, и бей меня по рукам, если я где-то попробую сделать иначе".
FR>С такими мыслями надо сразу на раст переходить
В Rust, насколько я знаю, эта концепция используется весьма последовательно. А в C++ до сих пор борются (и еще долго будут бороться) два подхода: "этого нужно избегать любой ценой" и "если кажется, что программист решил отстрелить себе яйца, то недопустимо мешать ему сделать это с комфортом и без напряга".
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, so5team, Вы писали:
S>>Очередная демонстрация незнания предмета. Без хорошего знания особенностей C++ сделать свой аналог std::vector будет не просто.
S>А свой аналог List на C# — легко сделать? Для частного случае, для себя, чтобы иметь ограниченное количество вариантов использования — не проблема. А вот чтобы это работало для других людей и миллионы людей с сотнями тысяч вариантов использования остались довольны — уже задача не такая уж простая
На C# несравнимо легче, на порядки легче. Хотя я с товарищем so5team предпочитаю не пересекаться, но вот здесь с ним соглашусь.
А так получается, что ты не читал ни талмуд Страуструпа (пример с simple vector), ни книгу Александреску и Саттера "Стандарты программирования" (про уровни безопасности). А исключения — это такая сложная штука. И мне, кстати, интересно, как в Аде с этим борются. Там исключения появились раньше, и преподносились они как супер-фича.
Вообще, так как я — неисправимый фанат ФП, то мне, конечно, нравится Rust. И один из моментов, почему нравится, это то, что из исключений там есть только паника. Сложность представляет собой код unsafe, где по-хорошему нужно думать о том, как будет вести себя блок unsafe во время паники, о чем многие забывают... В коде safe вроде как все должно отработать четко — так и задумывалось. А так, это такое облегчение, что в Rust почти нет исключений. Сразу гора с плеч. Но Rust все равно далек от идеала. У него и своих проблем хватает, которые я затронул выше. Увы, идеала никакого нет. Н-да, и не будет!
Здравствуйте, dsorokin, Вы писали:
D>На C# несравнимо легче, на порядки легче. Хотя я с товарищем so5team предпочитаю не пересекаться, но вот здесь с ним соглашусь.
Так а вы смотрели исходники стандартного List<T> в C#? Не так то все и просто
D>А так получается, что ты не читал ни талмуд Страуструпа (пример с simple vector), ни книгу Александреску и Саттера "Стандарты программирования" (про уровни безопасности). А исключения — это такая сложная штука. И мне, кстати, интересно, как в Аде с этим борются. Там исключения появились раньше, и преподносились они как супер-фича.
И так ясно что реализация vector из стандартной библиотеки — для большинства людей не посильна. Вот, для примера, что выдал GPT в качестве примера по моим наводкам:
Здравствуйте, Shmj, Вы писали:
S>Сможете ли вы сходу найти ошибки?
Сходу, не вчитываясь, у вас конструктор копирования+операторы копирования и методы resize/pushBack не exception safe, в resize запросто произойдет переполнение _capacity, а еще ваш SimpleVector не будет работать с T у которого нет дефолтного конструктора.
Здравствуйте, Артём, Вы писали:
Аё>Если не могут написать с нуля на расте, тогда зачем мучают 5 точку? Вон в MS когда-то хотели всю OS на пончике запилить, но что-то пошло не так. На жаве попытки были "чистой безопасной OS".
в каждой sim карте сотового оператора и в каждой банковской карте с чипом (контактной или nfc) внутри работает jvm со своей безопасной ос.
это, примерно, от 30 до 50 миллиардов устройств в промышленной эксплуатации.
Здравствуйте, sergii.p, Вы писали:
SP>что новые фичи (типа умных указателей) языку безопасности не прибавляют, так как всё равно остаются способы отстрелить себе ногу.
Еще из очевидного: ваш resize не обрабатывает ситуацию, когда вектор оказался пустым в результате перемещения. У вас _capacity будет 0, вы ноль умножите на два и получите ноль. Вот пример такого сценария:
Здравствуйте, so5team, Вы писали:
S>Еще из очевидного: ваш resize не обрабатывает ситуацию, когда вектор оказался пустым в результате перемещения. У вас _capacity будет 0, вы ноль умножите на два и получите ноль. Вот пример такого сценария: S>
Здравствуйте, Shmj, Вы писали:
S>>Еще из очевидного: ваш resize не обрабатывает ситуацию, когда вектор оказался пустым в результате перемещения. У вас _capacity будет 0, вы ноль умножите на два и получите ноль. Вот пример такого сценария: S>>
Здравствуйте, пффф, Вы писали:
П>Наверное, всё можно было бы сделать в несколько раз проще. И скорее всего, ООП там тоже был, только свой, костыльный, как у vsb
Основной проект был на Java. В принципе, ООП, только наследования реализации было слишком до хрена и часто не по делу.
Коллега делал какую-то утилиту или дополнение, уже не помню. И что-то ему понадобилось от Винды. А Java сама не могла. Коллега спросил меня, я был немного в курсе, ну и сделал JNI. Десятки строк на голых Сях, ничего особенного. Лепить классы, заворачивать их в функции было бы слишком.
В принципе я на Сях ничего такого больше нескольких сотен строк не делал. И, как правило, это были дополнения к чему-то. К Фортрану или Жаве. Плюс пара-тройка небольших утилит.
Здравствуйте, so5team, Вы писали:
S>Тупизма и непонимания с вашей стороны. Что и получилось. S>ЗЫ. Уж точно не тихой порчи хипа здесь нужно ожидать.
Ну перейти на личности легче всего. А конкретно — после std::move(first) вы опять пытаетесь использовать first. В Rust вам бы на уровне компиляции выдало ошибку, в C++ ошибку на уровне компиляции не выдаст, но все знают что так делать нельзя.
Здравствуйте, Shmj, Вы писали:
S>Ну перейти на личности легче всего.
В вашем случае -- это единственный возможный вариант. Вы засрали RSDN своей тупостью и поэтому заслуживаете того, чтобы вас в вашу же тупость макали снова и снова.
S>А конкретно — после std::move(first) вы опять пытаетесь использовать first.
И?
S>В Rust вам бы на уровне компиляции выдало ошибку
Мы сейчас C++ обсуждаем. В C++ объект после перемещения содержимого должен оставаться в некотором валидном состоянии.
Те, кто имеют мозги, могут подумать о том, что такое "валидное" состояние для контейнера после перемещения его содержимого.
Даже если вы сочли, что два этих фрагмента ну вот вообще ни капли не эквивалентны, то зачем делать так, что попытка pushBack-а в опустошенный контейнер ведет к порче памяти, а не к выбросу исключения или, хотя бы, игнору переданного значения? Потому что ChatGPT этого вам не подсказал?
Ну или взгляд с другой стороны: у вас pushBack написан так, что если в контейнере места для нового элемента нет, то вызывается resize. И если resize завершился нормально, значит выполнено условие что в хранилище достаточно места для нового элемента. Т.е. успешный resize реализует инвариант (_capacity > _size). Но после перемещения содержимого этот инвариант перестает выполняться. Схерали?
S>в C++ ошибку на уровне компиляции не выдаст, но все знают что так делать нельзя.
Здравствуйте, so5team, Вы писали:
S>Мы сейчас C++ обсуждаем. В C++ объект после перемещения содержимого должен оставаться в некотором валидном состоянии.
Ну не знаю, пишут "валидном но неопределенном" — что весьма обтекаемо. Я всегда относился к перемещенным объектам по принципу Rust — переместили и забыли, нечего труп ворошить.
Но ладно, правда ваша — вынужден со скрипом признать — ноль там все-таки не валидное состояние.
Здравствуйте, Privalov, Вы писали:
П>>Наверное, всё можно было бы сделать в несколько раз проще. И скорее всего, ООП там тоже был, только свой, костыльный, как у vsb
P>Основной проект был на Java. В принципе, ООП, только наследования реализации было слишком до хрена и часто не по делу. P>Коллега делал какую-то утилиту или дополнение, уже не помню. И что-то ему понадобилось от Винды. А Java сама не могла. Коллега спросил меня, я был немного в курсе, ну и сделал JNI. Десятки строк на голых Сях, ничего особенного. Лепить классы, заворачивать их в функции было бы слишком.
Ну на таких масштабах да, можно и сишечкой перетоптаться
КБ>Самое главное не рассказали. Выходы за пределы массива были? Обращения к освобожденной памяти?
Не той важности был проектик, чтобы этими вопросами заморачиваться.