C++20 и 2D Graphics

Хабалка - самая точная характеристика RazrFalcon xD

У вас в примере Trait Object.

Какие нафиг багрепорты, если код работает?

А если не работает - форк + фикс + пользуешь дальше. Даже переносить фиксы не нужно будет если автор забросил поделку.

А если какие-то гарантии ждёшь от serious business то ты наивный чукотский юноша.

У вас в примере Trait Object.

Ну да, надо же даункаст, а без него и в С++ все просто и удобно.

Какие нафиг багрепорты, если код работает?

«В любой программе есть ошибки» :-) Чти классику, юноша :-)

А если не работает - форк + фикс + пользуешь дальше.

Нет, спасибо :-) Форкать + фиксить чужой заброшенный код мне не интересно :-) У меня аллергия на это :-)

А если какие-то гарантии ждёшь от serious business то ты наивный чукотский юноша.

Это ещё почему? :-) Вот я, например, жду гарантий того, что стандартная библиотека в реализации GCC будет работать чётко и стабильно :-) А если выйдет какой-то конфуз, то его оперативно исправят :-) И я уж точно знаю, что мне не придётся форкать GCC :-) Лол :-) Поэтому чем больше будет в стандартной библиотеке, тем мне будет спокойнее и легче :-) Так кто из нас наивный? :-) Лол :-)

жди

Из подобных языков приходит в голову только tcl/tk

Ну так-то это неплохой пример.

Ну вот элементарный пример: не используют unique_ptr.

Вот тебе еще более элементарный пример: используют динамическую память на каждый чих. А потом удивляются: а чего это приложение жрет гигабайты RSS?

Ну а затем всякие приятные мелочи типа итерирования по буквам

Из чистого любопытства: «и» + «◌̆» что должны выдавать? Будет ли итерация по буквам возвращать string или одиночный char?

to_lower/to_upper

Юникодные toupper/tolower очень быстро разочаруют тебя своей «локалезависимостью».

split, join, trim, pad, etc

Все озвученное помещается в небольшой файлик объемом в сотню строчек. Кому надо, тот напишет.

Для начала не хватает string_view, которые наконец-то добавили.

Полное г-но, потому что не имеет абсолютно никакой поддержки в крестовой экосистеме вообще, в том числе и в стандартной библиотеке. На каждый чих будешь делать string из string_view. Удачи!

Вот тебе еще более элементарный пример: используют динамическую память на каждый чих.

Это решения разного уровня: применять или не применять динамическую память — это решение уровня проектирования. А вот когда разработчик уже решил, что без динамической памяти ему не обойтись (уже не важно, прав он или нет), то упростить себе жизнь с new/delete он должен уже на уровне реализации (кодирования). И тут выясняется любопытное: нередки случаи, когда люди не представляют, какие готовые средства уже есть в языке, как их можно использовать, чтобы упростить себе жизнь.

Вот пример из кода Firefox-а, взятый наугад. Буквально первый тык в случайный файл и сразу прекрасное: https://github.com/mozilla/gecko-dev/blob/master/parser/html/nsHtml5AtomTable...

class nsHtml5AtomEntry : public nsStringHashKey
{
  public:
    explicit nsHtml5AtomEntry(KeyTypePointer aStr);
    nsHtml5AtomEntry(const nsHtml5AtomEntry& aOther);
    ~nsHtml5AtomEntry();
    inline nsAtom* GetAtom() { return mAtom; }
  private:
    nsAtom* mAtom;
};

nsHtml5AtomEntry::nsHtml5AtomEntry(KeyTypePointer aStr)
  : nsStringHashKey(aStr)
  , mAtom(new nsAtom(nsAtom::AtomKind::HTML5Atom, *aStr, 0))
{
}

nsHtml5AtomEntry::nsHtml5AtomEntry(const nsHtml5AtomEntry& aOther)
  : nsStringHashKey(aOther)
  , mAtom(nullptr)
{
  NS_NOTREACHED("nsHtml5AtomTable is broken and tried to copy an entry");
}

nsHtml5AtomEntry::~nsHtml5AtomEntry()
{
  delete mAtom;
}

Казалось бы, фишки современного C++ в Mozilla-вских guidelines можно использовать. Ну так и напиши тогда всего пару методов:

class nsHtml5AtomEntry : public nsStringHashKey
{
  public:
    explicit nsHtml5AtomEntry(KeyTypePointer aStr);
    inline nsAtom* GetAtom() { return mAtom.get(); }
  private:
    std::unique_ptr<nsAtom> mAtom;
};

Но нет. Сперва напишут говнокода. Потом заморозят развитие своей кодовой базы на много лет, потеряют изрядное количество пользователей, а затем будут еще несколько лет избавляться от старого говнокода, плодя новый, но уже на Rust-е. При этом громко рассказывая всем, как хорош Rust для написания параллельного кода и как у них это не получалось на C++: https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum...

Ну слава богу, в этом треде Rust опять победили.

Из чистого любопытства: «и» + «◌̆» что должны выдавать?

Строку?

Будет ли итерация по буквам возвращать string или одиночный char?

Зависит от char. В rust он 4-е байта, поэтому возвращают его.

Юникодные toupper/tolower очень быстро разочаруют тебя своей «локалезависимостью».

УМВР

Кому надо, тот напишет.

Я не сишник, чтобы std переизобретать.

На каждый чих будешь делать string из string_view.

Так и задумано. А некто тут рассказывал, что все либы уже поголовно string используют. Осталось ещё 10 лет подождать и на string_view перейдут. Вот тогда заживём!

как хорош Rust для написания параллельного кода и как у них это не получалось на C++

Вы так говорите, как будто на C++ проще писать параллельный код, чем на rust?

И в этой статье лучший момент - это:

It replaces approximately 160,000 lines of C++ with 85,000 lines of Rust.

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

Та вроде не. В очередной раз было убедительно показано, что Rust — вот выбор настоящих неасиляторов!

Вы так говорите, как будто на C++ проще писать параллельный код, чем на rust?

Если бы на Rust параллельный код было бы писать не проще, чем на C++, то нахер вообще он нужен? Речь о том, что у Mozilla не получилось запилить параллельную обработку страничек не из-за сложности написания параллельного кода на C++, а потому, что они производят на С++ говнокод.

Почти в два раза меньше кода.

Выше уже был пример, как на C++ получить в два раза меньше кода, причем с большим контролем со стороны компилятора. Для этого даже не нужно на другой язык переписывать.

Ну и зачем мозиле поддерживать убогую сишку

«Убогую сишку», дейсвительно, незачем. Но вот какая религия им запретила перейти на современный C++... Видимо, среди разрабов Mozilla много персонажей вроде вас. Которым C++ срет в штаны, а они даже не могу внятно рассказать как именно.

Вот вы уже созрели до того, чтобы внятно объяснить свои проблемы с unique_ptr и полиморфизмом?

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

Ну вот что это за нах?

Лол :-) Скорее всего они так пытаются экономить память на машинах, где Фаерфокс компилируется :-) Шаблончики то - это не бесплатная финтифлюшка :-) От них, как известно, объектники пухнут так не хило :-) А с учётом размаха кодовой базы Фаерфокса, даже трудно сказать, какой выхлоп объектников будет получаться при сборке и сколько потребуется памяти на линковку и LTO, если всё усеять шаблонами :-) Лол :-)

Такое чувство, что на планете Земля только вы знаете C++, а все остальные «производят на С++ говнокод».

В общем ЧТД, в который раз.

Вот ты точно производишь говнокод и на расте и на цепепе xD

Есть такой эпичный проект: svgpp.

Его автор, судя по всему, - вторая личность eao197. Вся либа - хедеры. Ибо всё на шаблонах.

Идёя конечно хорошая, ибо шаблоны же «позволяют генерировать оптимальный код». Правда для сборки этой либы в один поток! еле хватает 8GB RAM! И занимает это пол часа (когда я последний раз тыкал). Вот вам сила шаблонов в действии.

Ну хоть что-то произвожу, в отличии от.

Внушает, чо.

В контексте того, что я пытался шутить, более уместным было бы сравнение меня с Петросяном, а не с Шерлоком Холмсом.

Т.е. внятного объяснения _ваших_ проблем с unique_ptr и полиморфизмом не будет? «ЧТД, в который раз» (с)

Идёя конечно хорошая, ибо шаблоны же «позволяют генерировать оптимальный код». Правда для сборки этой либы в один поток! еле хватает 8GB RAM! И занимает это пол часа (когда я последний раз тыкал). Вот вам сила шаблонов в действии.

Вы оцениваете эффективность кода по времени компиляции, а не по времени работы? Ба, да вы горазды дно пробивать!

В контексте того, как я вижу со стороны вашу позицию, я выбрал верную аналогию. Полноте вам, вы на одной из предыдущих страниц огульно занесли всех программистов на Rust в разряд умственно неполноценных неосиляторов C++. Какова доля юмора в подобном утверждении(?)

Казалось бы, фишки современного C++ в Mozilla-вских guidelines можно использовать. Ну так и напиши тогда всего пару методов:

Ну и чем твой вариант лучше? Тот же get, возвращающий сырой указатель.

при этом громко рассказывая всем, как хорош Rust для написания параллельного кода и как у них это не получалось на C++: https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum...

unique_ptr не предотвращает специфических ошибок при написании конкурентного кода. И да, Rust предотвращает как минимум некоторые ошибки при работе с таким кодом.

Ну так и напиши тогда всего пару методов:

Думаю, что этот код будет постарше «современного C++», отсюда и отсутствие unique_ptr. Так и есть: https://github.com/mozilla/gecko-dev/commit/3ad04b51a727e03edffdf92ae616a15b0...

https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum...

Бывают такие танцоры, которым всегда что-то мешает. Однако C++ — это трындец, и чем «современней» он становится, тем трындецовей.

как я вижу со стороны вашу позицию

Значит вы неправильно видите.

Полноте вам, вы на одной из предыдущих страниц огульно занесли всех программистов на Rust в разряд умственно неполноценных неосиляторов C++

Вам показалось. Если человек не осилил C++, то ему прямая дорога в Rust. Ну не на C++ же ему программировать.

Но далеко не все, кто пришли в Rust a) являются неосиляторами Rust-а и b) многие из них с C++ вообще никогда дела не имели.

А вот RazrFalcon — типичный неосилятор, Rust для него самый верный выбор.

Зависит от char. В rust он 4-е байта, поэтому возвращают его.

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

Я не сишник, чтобы std переизобретать.

Вот как раз в C стандартную библиотеку не переизобретают. А вот в крестах всем постоянно то строки не нравятся, то AVL вместо rbtree хочется. Улавливаешь?

Осталось ещё 10 лет подождать и на string_view перейдут

Свистни, когда syscall-ы на string_view перейдут. А пока извини, но даже std::fstream не принимает string_view в качестве имени файла.

Ну и чем твой вариант лучше? Тот же get, возвращающий сырой указатель.

Если ты за время копания на чистом C в embedded-мире совсем забыл C++, то перечитай еще раз. Речь шла не про get, а про хранение голого указателя внутри объекта. С надобностью определять деструктор. И с конструктором копирования который явно напоминает говнокод.

Что до get-а, то тут уже нужно разбираться с областью применения. Возможно, там можно обойтись ссылкой. Ну и, плюс к тому, в голых невладеющих указателях нет ничего плохого.

unique_ptr не предотвращает специфических ошибок при написании конкурентного кода.

А unique_ptr и не приводился как инструмент для предотвращения таких ошибок. Это был пример того, что в коде Mozilla есть явные проблемы с качеством.

Если единственный путь для преодоления этих проблем у Mozilla — это переход на Rust, ну Ok. Возможно, они могут себе это позволить.

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

Иногда ощущение, что кто-то привык с 90-x, что в std ничего нет (или есть, но функционала не хватает/неудобное). Вообще сам иногда на это попадаюсь.

Думаю, что этот код будет постарше «современного C++», отсюда и отсутствие unique_ptr. Так и есть:

Уже в 1998-ом в С++ был auto_ptr, у которого есть свои проблемы, но он избавлял от надобности в ручном удалении объектов. Плюс к тому, для старого C++ был древний трюк для запрета операций копирования:

class nsHtml5AtomEntry : public nsStringHashKey
{
    nsHtml5AtomEntry(const nsHtml5AtomEntry &);
    nsHtml5AtomEntry& operator=(const nsHtml5AtomEntry&);
  public:
    explicit nsHtml5AtomEntry(KeyTypePointer aStr);
    inline nsAtom* GetAtom() { return mAtom.get(); }
  private:
    std::auto_ptr<nsAtom> mAtom;
};

Но нет. Нужно же ждать Servo на Rust-е.

Однако C++ — это трындец, и чем «современней» он становится, тем трындецовей.

Да-да. Продолжайте держать публику в курсе.

Речь шла не про get, а про хранение голого указателя внутри объекта. С надобностью определять деструктор. И с конструктором копирования который явно напоминает говнокод.

Это тривиальный говнокод, написанный в древние времена. В чем смысл твоего улучшения, кроме эстетики?

А конструктор копирования там по факту запрещен, но из-за старости кода всё же реализован.

А unique_ptr и не приводился как инструмент для предотвращения таких ошибок. Это был пример того, что в коде Mozilla есть явные проблемы с качеством.

У них древняя кодовая база, со времен, когда подобный код был нормой.

Но нет. Нужно же ждать Servo на Rust-е.

«Servo на Rust-е» ждут ради конкурентности, а не unique_ptr.

То есть вы считаете это адекватной ценой за теоретическую производительность?

Это тривиальный говнокод, написанный в древние времена.

Он был написан в 2009-ом году.

В чем смысл твоего улучшения, кроме эстетики?

Хватит тупить. Все уже разжевано многократно.

Более чем.

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

Тогда уточните, что вы подразумеваете под буквой. В одну букву такую «й» превращает уже движок текстового лайоута.

Но если нужно - есть unicode_segmentation, хотя он не в std. Он как раз строки возвращает.

Вот как раз в C стандартную библиотеку не переизобретают.

В С вообще нет std.

Улавливаешь?

Уже наелся ваших const char*

Хватит тупить.

Отличный ответ, когда ответить нечего.

Все уже разжевано многократно.

Ничерта. Пока что просто сказано «используйте unique_ptr и будет щастье». Если щастье заключается в отсутствии утечек, то ручной delete его точно так же гарантирует. Если в отсутствии use-after-free - unique_ptr его точно так же не гарантирует.

В С вообще нет std.

И string.h нет? То, что библиотека маленькая - это не значит, что её нет.

Отличный ответ, когда ответить нечего.

Это ответ для тех, кто не хочет читать то, что уже было разжевано. Но, специально для тебя, повторю:

* в C++ уже есть инструменты, которые облегчают жизнь программисту;

* эти инструменты следует использовать. В противном случае высока вероятность сотворить говнокод;

* в коде Firefox-а подобный говнокод отыскивается просто с полпинка. Вот случайно ткнул пальцем и попал;

* соответственно, красочным рассказам Mozilla-овцев о том, как они пытались-пытались сделать распараллеливание на C++, но у них не получилось, не веришь просто по факту наличия говнокода.

Т.е. основная мысль в том, что неудача с распараллеливанием не из-за того, что C++ не позволяет писать параллельный код. А в том, что у Mozill-ы говнокод.

И это все безотносительно того, насколько Rust упрощает написание параллельного кода (и упрощает ли вообще). Было бы очень странно, если бы в него вбухали столько времени и сил, а по итогу бы получилось, что у Rust-а нет никаких преимуществ в этом деле.

Ну и будешь продолжать тупить — будешь общаться сам с собой.

А в том, что у Mozill-ы говнокод.

Напиши в Мозиллу, предложи им возглавить отдел разработки :-) Или возьмите подряд у них всем своим Стиффстримом :-) И тогда кодовая база на цепепе засияет пёстрыми красками и наступит счастье :-) И цепепе тогда будет реабилитирован на весь мир и на все времена :-) Лол :-)

А в том, что у Mozill-ы говнокод.

Напиши в Мозиллу, предложи им возглавить отдел разработки :-) Или возьмите подряд у них всей своей конторой :-) И тогда кодовая база на цепепе засияет пёстрыми красками на базе unique_ptr и прочей RAII-пестроты и наступит счастье :-) И цепепе тогда будет реабилитирован на весь мир и на все времена :-) Лол :-)

Напиши в Мозиллу, предложи им возглавить отдел разработки :-) Или возьмите подряд у них всей своей конторой :-) И тогда кодовая база на цепепе засияет пёстрыми красками на базе unique_ptr и прочей RAII-пестроты и наступит счастье :-) И цепепе тогда будет реабилитирован на весь мир и на все времена :-) Лол :-)

у тебя смайлики текстом отображаются или картинкой?

И в этой статье лучший момент - это:
It replaces approximately 160,000 lines of C++ with 85,000 lines of Rust.

Если взять любой древний код, со всеми его родовыми кривостями и приращениями, и переписать нафиг, то почти наверняка будет заметно меньше строк. Особенно, если тебя не прижимают сроки и нет на руках массы других задач. Не говоря уж про то, что сравнивается код на старом стандарте С++ и новом Rust. Так что это как раз не показатель.

Даже на C++17 будет больше кода. Так что не аргумент.

у тебя смайлики текстом отображаются или картинкой?

Текстом :-) А что? :-) Лол :-)

Текстом :-) А что? :-) Лол :-)

хочу понять как выглядит мир твоими глазами

Даже на C++17 будет больше кода. Так что не аргумент.

Ну да, ведь в Rust есть компактные трейты вместо многословных классов, нет этих вечно попадающихся на глаза неявных кастов, есть удобные лайфтаймы, которые сокращают размер кода и т.д. Просто рай для тех, кто хочет писать минимум кода.

Как минимум не нужно дважды описывать класс и долбаться с хедерами и forward declaration, ибо есть нормальные модули.

неявных кастов

Вы о чём?

Как минимум не нужно дважды описывать класс и долбаться с хедерами и forward declaration, ибо есть нормальные модули.

Это да, но авторы Rust и про тебя не забыли, и ты все-равно дважды «описываешь класс» через impl. А в С++ да, пока с этим плохо, хотя модули уже в разработке.

Вы о чём?

О том, что в Rust их нет, конечно. Как и перегрузки функций. Что рождает массу кода вида:

foo(Some(ILoveRust::new(n as i32)));

вместо:

foo(n)