C++20 и 2D Graphics

но для тех задач,в которых я использую кресты мне хватает и 03

И что это за задачи?

Как вообще можно считать нормальными строки, которые представляют собой просто набор байт без указания кодировки?

Опиши, чего по-твоему не хватает в std::string? Неужели одного-единственного поля с указанием кодировки?

Упс: https://github.com/abseil/abseil-cpp/tree/master/absl/strings

Не знаю, скажет ли тебе это о чем-нибудь:

The Abseil library code is collected from Google's own C++ code base

И что это за задачи?

Мелкие системные утилиты

Открыть вам секрет? Новые стандарты C++ как раз и делают для того, чтобы стрелять было сложнее.

Можно уточнить: стрелять вообще или в конкретно взятую ногу?

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

Ну а затем всякие приятные мелочи типа итерирования по буквам, а не байтам, to_lower/to_upper, split, join, trim, pad, etc.

Вообще.

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

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

Модулям, я смотрю, повезло меньше

I do not know whether modules will make the feature cutoff for C++20, but a lot of people are working hard to maximize the chances… we’ll know in another 12-18 months when we reach the C++20 feature cutoff. (c) Sutter

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

Его уже можно без боли использовать с полиморфизмом?

И какие же у вас проблемы с полиморфизмом в unique_ptr?

Ну и? Какие здесь проблемы у unique_ptr?

derivedPointer - это сырой указатель, со всеми вытекающими. Сначала мы делаем обёртку, чтобы не выстрелить себе в ногу, а затем ломаем её, ибо по другому никак.

Если двя ваших задач достаточно - кто же мешает.

Для каких задач по загрузке и растеризации глифов недостаточно stb_truetype?
Для каких задач по загрузке изображений недостаточно stb_image?

Так, а unique_ptr здесь при чем? Вы засунули в unique_ptr указатель на базовый класс. После чего хотите извлечь указатель на наследника. Зачем?

загрузке и растеризации глифов

Когда мне нужно не буковки рядом рисовать, а использовать нормальный лайоут.

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

Лол :-) Тут непонятно :-) Ну вот возьмём для примера хвалёную расхвалёную библиотеку для работы с WebSockets на цепепе :-) Называется сие чудо uWebSockets и позиционируется как «Runs with raw epoll, libuv or ASIO (C++17-ready)» - т.е. типа современная :-) Ок, радости полные штаны - отличная либа, ведь «One million WebSockets require ~111mb of user space memory» умеет, думают пацаны :-) Идём смотреть подробнее - явные delete по всему коду :-) Вот что это, как такое понимать? :-) У либы более 8000 звёзд на гитхабе :-) Т.е. 8000 персон чихать хотели на смарт-поинтеры и какой-то там современный стиль, рекламируемый теми самыми современными гайдлайнами :-) Правильно ли мне понятно сие дивное явление? :-) Лол :-)

Когда мне нужно не буковки рядом рисовать, а использовать нормальный лайоут.

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

derivedPointer - это сырой указатель, со всеми вытекающими

Ты семантику unique_ptr вообще понимаешь? Если тебе надо рядом сделать еще один указатель с другим типом, то конвертишь исходный указатель в std::shared_ptr (у него есть конструктор из unique_ptr) и делаешь std::dynamic_pointer_cast.

то конвертишь исходный указатель в std::shared_ptr (у него есть конструктор из unique_ptr) и делаешь std::dynamic_pointer_cast.

Ох лол :-) А свой my_unique_ptr_cast написать масла в голове не хватает что-ли? :-) Ах да, зачем изобретать велосипед, когда можно через задницу, но с помощью стандартной либы сделать :-) Такие нынче времена, такие нравы :-) Лол :-)

свой my_unique_ptr_cast написать масла в голове не хватает что-ли?

Т.е. твой my_unique_ptr_cast сможет сделать рядом еще один my_unique_ptr_cast с друним типом?

Т.е. твой my_unique_ptr_cast сможет сделать рядом еще один my_unique_ptr_cast с друним типом?

Зачем мне рядом? :-) ТС нафантазировал какую-то мыльную проблему с кастом указателя на B, которым владеет смарт-поинтер к указателю на D, где D наследует B :-) Для этого он тут демонстрирует static_cast<> и unique_ptr::get() и жалуется на то, что он получает сырой указатель :-) Ну так напиши такой my_unique_ptr_cast, который передаст владение от смарт-поинтера на B в смарт-поинтер на D :-) Какой-тут ещё нужен «рядом тип»? :-) Лол :-)

Лайоутом занимается HarfBuzz и Pango.

Его уже можно без боли использовать с полиморфизмом?

Его уже можно без боли использовать с полиморфизмом?

Ты определись сначала, что тебе надо. Если ты хочешь рядом создать еще один указатель, то ты не понимаешь сути пустоши unique_ptr. А если ты хочешь преобразовать исходный указатель, то тебе нужен не get, а release и результат сохранится не в сырой указатель, а в новый unique_ptr.

Вы все еще не можете объяснить, откуда тут боль. И, видимо, в очередной раз публично обсираетесь. Как это уже было в данной теме с самодельным классом строки в Abseil.

Главное, что вы по-прежнему уверены в собственной правоте =)

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

А по поводу динамического полиморфизма и unique_ptr... Мне вообще еще не довелось высказать своего мнения, поскольку вы не можете объяснить, в чем же проблема.

Так что может я бы и хотел оказаться прав, но пока не в чем, вы обосрались совершенно самостоятельно.

Или нет? Или найдете мозги чтобы описать _свою_ проблему с динамическим полиморфизмом у unique_ptr?

Вам так хочется, чтобы вас похвалили? =)

Все свои претензии я уже описал. Если вы не считаете это проблемой - рад за вас. С++ два вас идеален, никто в этом и не сомневался.

Все свои претензии я уже описал.

Это вам так кажется. Здесь никто не понял, чего именно вы хотели.

Если вы не считаете это проблемой - рад за вас.

Проблема пока в том, что не понятно, что такое «это».

С++ два вас идеален, никто в этом и не сомневался.

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

Если вы не считаете это проблемой - рад за вас

Ты лучше расскажи зачем в твоем любимом Rust нужны костыли вроде:

https://crates.io/crates/downcast-rs

вывод прост - ты не знаешь C++. Про то, что ты знаешь Rust и D тоже большие сомнения.

Все свои претензии я уже описал.

вангую отсутствие у тебя высшего образования, у тебя слишком ярко выражен эффект Даннинга—Крюгера. Ты похож на эдакую хабалку от программирования, причем не только в темах связаных с плюсами

Доооо... C++ дискредитируют те, кто не потратил на его изучение 20 лет.

Ваша ванга сломалась, мой юный троль.

Ваша ванга сломалась, мой юный троль.

и что же ты оканчивал?

Какое отношение это имеет к вашей неспособности связно излагать свои мысли?

Не знаю. Я дин. полиморфизм там не использовал.

То же, что и ваши попытки доказать, что C++ «не виноват».

Может мне ещё скан диплома выложить?

Хотя апелляция к ВУ сама по себе прекрасна.

Может мне ещё скан диплома выложить?

без него тебе никто все равно не поверит

В очередной раз обосрались и слились.

И когда вы уже на свой Rust свалите полностью? Язык специально для таких дебилоидов был сделан. Не тратьте свое время.

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

Только после того, как вы предоставите справку из дурдома.

ну выпилится автор - и что? его код сразу же протухнет?

а, может, у кода есть срок действия?

Вообще говоря, для набора байт есть массивы. А строки - это что-то про текст. Без кодировки текст из байт не получится.

Не знаю. Я дин. полиморфизм там не использовал.

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

dynamic_pointer_cast<Bird>(animal)

П.С. А вот так предлагается писать на расте:

#[macro_use]
extern crate downcast;

use downcast::Any;

/* Trait */

trait Animal: Any {}

downcast!(Animal);

/* Impl */

struct Bird;

impl Animal for Bird {}

impl Bird {
    fn wash_beak(&self) {
        println!("Beak has been washed! What a clean beak!");
    }
}

/* Main */

fn main() {
    let animal: Box<Animal> = Box::new(Bird);
    {
        let bird = animal.downcast_ref::<Bird>().unwrap();
        bird.wash_beak();
    }
    let bird = animal.downcast::<Bird>().ok().unwrap();
    bird.wash_beak();
}

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

Только в Rust это редкость, а в C++ - необходимость.

И переведенная вами задача в Rust решается через трейты.

ну выпилится автор - и что? его код сразу же протухнет?

Кому направлять багрепорты? :-) Кому направлять заявки на доработку? :-) С кого спрашивать вообще? :-) Кому надо форкать чей-то проект? :-) Мне не надо, у меня хватает :-)

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

А использовать либы от Васи - да пожалуйста, это можно :-) Но какие тут гарантии? :-) Да никаких :-)

Только в Rust это редкость, а в C++ - необходимость.

В С++ описанная тобой ситуация - тоже редкость. Кроме того в Rust это редкость именно из-за ограниченности языка, в Swift, например, есть не только трейты, но и классы, но никто не называет даункаст необходимостью.

И переведенная вами задача в Rust решается через трейты.

Приведенная мной задача как раз показывает, что трейты и рождают эту задачу.