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/

Лол , С++ с борзочекером это полная хрень. В чем тогда смысл не учить Руст?

Здравствуйте, T4r4sB, Вы писали:

LK>>https://habr.com/ru/news/842994/
TB>Лол , С++ с борзочекером это полная хрень. В чем тогда смысл не учить Руст?

Так в Rust нет ООП полноценного.

Здравствуйте, Shmj, Вы писали:

S>Так в Rust нет ООП полноценного.

1. Офигеть проблема лол
2. При наличии борзочекера всё равно придётся забыть все старые привычки, и старый код компилироваться не будет

Здравствуйте, T4r4sB, Вы писали:

TB>1. Офигеть проблема лол

Это важно для многих задач и большинство людей это понимают.

Новичков удалось убедить что ООП уже как не круто, не модно. На самом деле нет.

Вот чел. недавно книгу рекомендовал — https://rsdn.org/forum/cpp/8799828.flat

Автор: LaptevVV
Дата: 14.08 16:31

— без полноценного ООП это не возможно. Ну не то чтобы не возможно, но не удобно, а так то и на Си можно забульбашить.

Скоро зреет новый ЯП — Carbon. Возможно он сможет заменить Rust.

TB>2. При наличии борзочекера всё равно придётся забыть все старые привычки, и старый код компилироваться не будет

С чего бы? ООП то никуда не денется.

Здравствуйте, Shmj, Вы писали:

S>Новичков удалось убедить что ООП уже как не круто, не модно.

Ну и слава богу, будет меньше "программистов", которые без абстрактных фабрик 2+2 сложить не могут.
ООП переоценено.

>На самом деле нет.

На самом деле да

S>С чего бы? ООП то никуда не денется.

Учись писать код без того, что ты называешь "ООП".

Здравствуйте, T4r4sB, Вы писали:

S>>Новичков удалось убедить что ООП уже как не круто, не модно.

TB>Ну и слава богу, будет меньше "программистов", которые без абстрактных фабрик 2+2 сложить не могут.

А что, Rust имеет какие-то средства противодействия чему-то вроде (код условный):

trait SomeUsefulInterface {
  ... // Набор методов.
}

trait SomeUsefulInterfaceFactory {
  fn create(&mut self) -> Box<dyn SomeUsefulInterface>;
}

fn getCurrentFactory() -> Box<dyn SomeUsefulInterfaceFactory>;

TB>ООП переоценено.

Скорее извращено применением ОО-языков, вроде Java, в ынтерпрайзе с тамошним поклонениям паттернам и бест-практицез.

Здравствуйте, пффф, Вы писали:

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>На самом деле да

Были времена, когда ООП стало модным и начали пихать во все щели, причем не по делу. Потом маятник качнулся в обратную сторону и начали убеждать что оно нафиг не нужно. Сейчас все более-менее устаканилось и стало ясно что ООП. весьма удобный и полезный инструмент, лишать себя которого нет смысла — т.е. язык без ООП даже рассматривать не стоит.

Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>В первую очередь — возможность указать компилятору "тут я замыслил делать вот так, и бей меня по рукам, если я где-то попробую сделать иначе".

С такими мыслями надо сразу на раст переходить

Здравствуйте, dsorokin, Вы писали:


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/ и есть удобная утилита для проверки своих проектов.