Началось формирование и тестирование сборок движка Servo

очень круто когда есть 33 разных видов способов работы с памятью

Ты это серьёзно? В плюсах ничуть не меньше способов имеется. В С - из коробки поменьше, но велосипедов с головой.

но реализация и, судя по всему, ЦА тянут этот инструментик в разряд хипстоты.

Можно про реализацию подробнее?

Ты это серьёзно? В плюсах ничуть не меньше способов имеется.

ну и где я говорю что плюсы это хорошо ?

какие кстати в С способы то ? на стеке, да в heap понятным способом, никаких смартпоинтеров и прочих счетчиков ссылок.

Можно про реализацию подробнее?

дак почитай про Rust, мне лень разжовывать.

никаких смартпоинтеров и прочих счетчиков ссылок.

«Смартпоинтеры и прочие счетчики» - и в плюсах и в расте это библиотечная фишка. Пусть и стандартная, но не обязательная, и никак не недоступная в С. Например, может сослаться на GObject.

Например, может сослаться на GObject

Хотя, конечно, нельзя не отметить, что ожидать удобства работы, аналогичному С++ и Rust, тут не приходится.

Безопасность языка заключается в том что оно должно упасть с конкретной ошибкой, например неожиданый результат вызова API функции, а не с SIGSEGV

И где же эта конкретная ошибка в данном случае?
А вообще - нет. Заявлялась именно безопасность работы с памяью (и возможно, и другими ресурсами).

ну и где я говорю что плюсы это хорошо ?

А где говоришь, что плохо? Да, я обратил внимание, что ты говорил о С, потому и продолжил о нём. Но раст, в том числе в этой теме, активно сравнивают и с С++.

И моя мысль была о том, что если язык берётся предоставлять какие-то абстракции на эту тему, то будут как раз аналоги unique_ptr, shared_ptr и т.д. А если не берётся, то будут свои в каждом проекте, где понадобятся.

дак почитай про Rust, мне лень разжовывать.

У меня есть подозрение, что про раст знаю побольше тебя. Потому и интересно где ты видишь проблемы именно реализации, а не документации/«идеи».

Но раст, в том числе в этой теме, активно сравнивают и с С++.

дак велкам, но идея Rust (звини, смотрел только доки, в основном то что было интерестно, но не писал на нем еще) лучше чем C++, но мой посыл то в том что Rust С не заменит, а позиционирует себя так. Впрочем, читай выше что я писал.

У меня есть подозрение, что про раст знаю побольше тебя

вероятно

Потому и интересно где ты видишь проблемы именно реализации, а не документации/«идеи».

позиционирование и все вот это вот загибы с raw pointers и тд.

но мой посыл то в том что Rust С не заменит, а позиционирует себя так

Язык позиционируют как системный, без конкретных указаний, что собрались «заменять». Впрочем, я не вижу принципиальных сложностей с заменой С, кроме инертности/консервативности, ну и наличия легаси. Последнее является вполне объективной причиной, но преодолимой при большом желании.

То, что нет смысла бросаться переписывать ВСЁ - это другой вопрос.

позиционирование и все вот это вот загибы с raw pointers и тд.

То есть, тебя смущает конкретно, что «слишком много видов указателей, чтобы заменить С»?

И ещё один момент с «позиционированием». Не стоит валить в кучу цели выдвигаемые разработчиками и желания отдельных людей. К примеру, если я пишу на С++ и при любом удобном и не очень случае буду кричать, что язык отстой и надо срочно брать раст - это не будет значить, что язык так позиционируется.

но преодолимой при большом желании.

зачем ???

То есть, тебя смущает конкретно, что «слишком много видов указателей, чтобы заменить С»?

дак именно, я ж не как сторонник хипсторских проэктов предлагаю все делать на C, но там где оно надо, оно надо. А то выйдет как с systemd, который нафик не нужен, но сделали тк старое не нравилось...

Это немного разные вещи.

Не знаю, что у тебя там за разные вещи, а кто-то из крестовых корифеев практически прямым текстом писал: «юзайте средства языка Си, которым есть аналоги в С++, только в случае крайней необходимости». В числе этих средств упоминались сишные массивы.

Это немного разные вещи. По моему, Страуструп говорит, что не надо мучительно выбирать между vector, deque, list и т.д.

«И т.д.» включает также множества (как сортированные, так и нет) и даже с некоторой степенью неудобства, ассоциативные массивы. Не уверен, что конкретно Страуструп про конкретно мапы такое говорил, но в виду кривизны реализации имеет смысл.

А так чтобы повсеместно брали вектор вместо статических массивов? Вот в этом есть сомнения.

Не сомевайтесь. Нужно понимать, что C++ - язык сложный и читатель книжки «изучить C++ за 21 день» во всех этих хитросплетениях разбираться ещё долго не будет, поэтому совет «везде вектор вместо C-стайл массива» правилен. Если я добавлю в свой класс обычный массив, то работать нормально будет только если этот массив интегрирован в объект, а не выделяется на куче и тип объектов имеет нормальный конструктор по умолчанию. Ни одно из этих условий не гарантировано. В то время как использование вектора стоит недорого, по производительности разницы между вектором и массивом в куче нет. И при этом класс с вектором получает автоматически сгенерированные рабочие конструкторы копирования и перемещения, что и безопасно и хорошо для производительности.

Если у виндузятников нет мозгов — выходит, зомбиапокалипсис давно наступил?

Философ, однако.

зачем ???

Откуда я знаю? Я же не предлагаю бросаться переписывать всё с С на раст.

дак именно, я ж не как сторонник хипсторских проэктов предлагаю все делать на C, но там где оно надо, оно надо

Как по мне, так от всех этих «видов указателей» есть польза. В том числе, в низкоуровневом программировании.

А то выйдет как с systemd, который нафик не нужен, но сделали тк старое не нравилось...

Значит кому-то оказалось нужным. Это нормально. (:

«юзайте средства языка Си, которым есть аналоги в С++, только в случае крайней необходимости»

Ну и? В С++ есть std::array. А до его появления std::vector был не (прямым) аналогом сишным массивам.

читатель книжки «изучить C++ за 21 день»

Так может и о расте будем судить по тому что читатели лора себе выдумали? Я не считаю, что по хеловорлдам написанных после беглого изучения языка стоит делать выводы в плане принятых практик.

Ну да, я не совсем верно выразился. Скажем так: новичок в C++ должен использовать вектор вместо C-массива потому что он не знает всех особенностей копирования/перемещения объектов и с большой долей вероятности напортачит. Разбирающийся в C++ программист знает большинство этих хитросплетений и поэтому в 99% использует вектор, просто чтоб не изобретать велосипед.

Ну и?

Ну и «там считается идиоматическим пихать std::vector даже туда, где он не нужен». ЧТД.

ЧТД.

Не увидел доказательства.

Не увидел доказательства.

«Корифеи C++ считают сишные массивы говном и предлагают юзать вместо них std::vector» -> «В C++ считают идиоматичным юзать вектор даже там, где хватило бы массивов статического размера на стеке». Какие-то проблемы?

Какие-то проблемы?

Да, ведь ты подменил понятия. Всего пару сообщений назад было вот это:

кто-то из крестовых корифеев практически прямым текстом писал: «юзайте средства языка Си, которым есть аналоги в С++, только в случае крайней необходимости»

И ещё раз повторюсь: в С++ в качестве аналога сишных массивов есть std::array.

Да, ведь ты подменил понятия.

Что конкретно я подменил?

И ещё раз повторюсь: в С++ в качестве аналога сишных массивов есть std::array.

Это экзотика. Кроме меньшего потребления памяти, преимуществ веред вектором у него нет, а вот гибкость теряется значительно.

а вот гибкость теряется значительно.

Это проблема только если эта гибкость нужна.

Ладно, это бессмысленный спор. Тем более, что он начался с моего утверждения, что не вижу повального применения вектора вместо статических массивов. Доказательством тут могла бы быть статистика по реальным проектам, но её и мне собирать лень.

Это проблема только если эта гибкость нужна.

Учитывая нынешние объёмы оперативы, гибкость практически всегда нужнее, чем незначительное уменьшение потребления памяти.

Доказательством тут могла бы быть статистика по реальным проектам

ИМО - едва ли. Я понимаю под «идиоматическим кодом» код, в котором используются best practices, пропагандируемые авторами и признанными гуру языка. Сколько бы говнокодеров не набижало в реальные проекты, идиоматическим их код не станет.

Учитывая нынешние объёмы оперативы, гибкость практически всегда нужнее, чем незначительное уменьшение потребления памяти.

Во первых, это напоминает аргумент за какую-нибудь джаву. Такими темпами можно дойти до ненужности плюсов и раста. (:

Во вторых, есть случаи когда гибкость не нужна даже теоретически. В конце концов, зачем платить за то, что не используешь?

это напоминает аргумент за какую-нибудь джаву

Как раз проблема Java в том, что она добавляет ощутимый оверхэд по скорости и не умеет в хард риалтайм. А по поводу памяти в наш просвещённый век парятся, разве что, эмбедщики.

есть случаи когда гибкость не нужна даже теоретически

Я же говорю, экзотика.

И ещё раз повторюсь: в С++ в качестве аналога сишных массивов есть std::array

В С++ массивы никуда не делись, они часть языка. И мало чем отличаются от таковых в Си. Почему тогда аналогом массивов в Си должен являться array, а не такие же массивы?

А по поводу памяти в наш просвещённый век парятся, разве что, эмбедщики.

Как скажешь.

Почему тогда аналогом массивов в Си должен являться array, а не такие же массивы?

Контекст сообщения: «кто-то из крестовых корифеев практически прямым текстом писал: «юзайте средства языка Си, которым есть аналоги в С++, только в случае крайней необходимости»».

Это правильно, но этот принцип в С++ относится к таким вещам как например использование new и delete вместо аналогичных инструментов из Си (которые теоретически никто не запрещает но лучше не надо). Или использвание << вместо всяких printf, то есть там где есть аналогичные инструменты С++. При чём тут вообще массивы?

При чём тут вообще массивы?

При том, что у std::array тоже есть преимущества относительно «сишных массивов».

Возможно, но мне кажется что вполне разумный принцип «юзайте средства языка Си, которым есть аналоги в С++, только в случае крайней необходимости» все же не относится к таким базовым вещам как указатели, массивы или функции. Это про всякие Сишные fopen которым в С++ появилась замена.

И каким же образом платформа определяет задачи? Нужны или не нужны статические массивы, определяется задачей.

Зачем следить? Старая работать перестанет, что ли? Когда перестанет — тогда и пересобирай.

Я согласен, что это не так уж принципиально, но ведь какого-то оверхеда из-за std::array нет, а определённые преимущества имеются (да хотя бы то, что он автоматически к указателю не приводится). Так что почему нет.

И каким же образом платформа определяет задачи?

Задачи определяют платформу.

Нужны или не нужны статические массивы, определяется задачей.

Покажи мне задачу, где не обойтись без статических массивов.

какого-то оверхеда из-за std::array нет

Чо, правда? А аллокация?

А аллокация?

Аллокация чего?

Единственное неудобство, которое я знаю, у std::array заключается в том, что самому количество считать приходится. Это вполне повод использовать сишный массив, но к оверхеду (в привычном понимании) отношения не имеет.

Единственное неудобство, которое я знаю, у std::array заключается в том, что самому количество считать приходится

Количество чего? :(

Наркоманский спор. std::array - обертка над сишным массивом, по всем свойствам ему идентичная.

Количество чего? :(

Элементов.

int a1[]              = {1, 2, 3};
std::array<int, 3> a2 = {1, 2, 3};

std::array - обертка над сишным массивом, по всем свойствам ему идентичная.

Можно попридераться и сказать, что копирование у обёртки будет более ожидаемым.

Думаю, можно че-нибудь нагородить, но согласен, есть неудобство. Трудно было догадаться, о чем ты.

копирование у обёртки будет более ожидаемым

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

Пацаны, я по такому не угораю

Задачи определяют платформу.

Ты из какого века? Что мешает вести учёт кроликов в браузере, поднять на смарт-часах координатор для майнинг-пула или сидеть во фтентаклике из CLI?

Покажи мне задачу, где не обойтись без статических массивов

Покажи мне задачу, в которой нельзя числа одноячеечными массивами заменить. Или запихнуть в вектор дерево из пар индекс-значение. Да давай сразу на брейнфаке писать, чего уж там, кому надо городить эффективные структуры, если можно просто хуякнуть вектор.

По чему не угораешь? По «работает — не трожь»?

Ты из какого века?

О, эти манямирки йуных дарований.

поднять на смарт-часах координатор для майнинг-пула

может мешать отсутствие таковых у заказчика.

сидеть во фтентаклике из CLI

может мешать ЦА из домохозяек.

вести учёт кроликов в браузере

Ничего не мешает. Но это не значит, что задача «учёт кроликов» не зависит от платформы - это значит, что она предполагает выбор платформ из списка. То есть, ты можешь наформошлёпить, нафронтэндить, но едва ли будешь делать кластер или заказывать печатную плату с контроллером и пилить прошивку.

«Покажи мне задачу, в которой нельзя» и дальнейшие плоды йуношеского максимализма

Мне лень разбирать. Скажу только, что задачи, предполагающие уэб в качестве платформы, либо не предъявляют требований к производительности, либо упираются производительность I/O. Более того, в языках , на которых обычно пишут уэб, статических массивов на стеке нет в принципе.

Аллокация чего?

А, мой фейл. Я из-за некогда читанного кривого перевода C++11 FAQ считал, что array юзает динамическую память.

может мешать отсутствие таковых у заказчика

Если у заказчика УЖЕ есть определённое железо, то вопрос тем более актуален.

ЦА из домохозяек

Но не все же ЦА.

это значит, что она предполагает выбор платформ из списка

На остальные платформы можно водрузить эльфпак и нашлепать самому, например.

задачи, предполагающие уэб в качестве платформы

Речь о плюсах шла, ващет.

Если у заказчика УЖЕ есть определённое железо, то вопрос тем более актуален.

Какой вопрос?

Но не все же ЦА.

Не распарсил. Переведи на человеческий.

На остальные платформы можно водрузить эльфпак и нашлепать самому, например.

Тогда у тебя будет платформа «Эльфпак поверх $PLATFORM_NAME».

Речь о плюсах шла, ващет.

Не юли, речь шла о зависимости использования/неиспользования статических массивов от платформы.

O_O Зачем тогда они вообще его делают?

Ради всего остального. Параллельного и безопасного.

Это же настоящий прорыв!