All streams
Search
Write a publication
Pull to refresh
10
0.1
Send message

Не совсем понял, умеет ли этот сериализатор работать с полиморфизмом?

struct Base {
    virtual int data() {
        return 1;
    }
};

struct Derived : Base {
    int data() override {
        return 2;
    }
};

struct Client {
    Base* data;
};

void test() {
    Client client;
    client.data = new Derived;
    auto text = serialize(client);
    Client* test = deserialize(text);
    std::cout << test->data->data() << std::endl;
}
Сериализует и десериализует Derived или Base?

Жалуется на медленный new. Реализует свой new через виртуальные функции.

"А мы продаём или покупаем"?
Вы вызываете чужой COM-интерфейс или реализуете свой?
Вообще ничего не мешает в заголовочнике COM-интерфейса прописать в сигнатуре функции ссылку вместо указателя, работать будет. Зато всем нормальным пользователям будет понятно, что функция не ждёт NULL.
Вообще, разговор шёл про С++ интерфейсы, которые вы пишете к своему функционалу, а COM, хоть и может вызываться из C++, но всё же скорее некий C-интерфейс.
PS: вы не в 1С случайно работаете? А то в 8ке там всё внутри на COM-интерфейсах...

Какой-то детский лепет и сваливание вины на других, как детский сад, ей богу.
write_file - ваша функция. И вы несете ответственность за то, что она будет правильно работать. Вам уже с cppreference привели цитату, что передавать string_view::data в функции, ждущие const CharT* и нуль-терминированную строку - это ошибка, показали случаи, когда это может вызвать проблемы - а Вы всё еще пытаетесь что-то выдавить. Вместо того, чтобы пойти и исправить ошибку в своей функции.
Аргументы функции - это контракт, который вы обязуетесь выполнять. Если вы принимаете string_view, то у пользователя вашей функции вот совсем не должна болеть голова о том, будет ли его string_view нуль-терминированным или нет.
Принимайте string и не парьтесь. Ну или раз вам подвезли std::filesystem, то filesystem::path.
А чтобы не передавали null, надо не "договариваться", а аргументом делать не указатель, а ссылку

"Все говорят, нельзя баловаться спичками, а я баловался, и ничего не сгорело. Что я делаю не так?"
Вы уверены со стороны вызывающего функцию. А когда вы пишите функцию, надо быть уверенным со стороны вызываемого. То есть если вы параметром принимаете string_view, который не даёт гарантии, что за его концом есть 0, а нужно вам передать в C-API, которое требует нуль-терминированную строку, у вас нет никакого другого варианта, кроме как скопировать символы из string_view в string, и вызвать c_str(). До С++11 data() и в std::string не дает гарантий нуль-терминированности.
Сегодня вы так напишите, а завтра вашему коллеге дадут задачу "записать мета-инфу о файле в файл с тем же именем, но без расширения", и он напишет
write_file({file.name.c_str(), file.name.find_last_of('.')}, .....);
И затрет нахрен исходный файл. И будет прав, потому что ваша функция принимает string_view, и он ей посылает string_view, "как договаривались".
И да, проверять string_view, что за его концом лежит 0 - UB, как чтение за пределами массива.

Из GCC13

      /**
       *  @brief  Create an output file stream.
       *  @param  __s  Null terminated string specifying the filename.
       *  @param  __mode  Open file in specified mode (see std::ios_base).
       *
       *  @c ios_base::out is automatically included in @a __mode.
       */
      explicit
      basic_ofstream(const char* __s,
		     ios_base::openmode __mode = ios_base::out)

Как видите, параметром он требует Null terminated string specifying the filename.
string_view::data не дает гарантий Null terminated.
https://en.cppreference.com/w/cpp/string/basic_string_view/data

Unlike std::basic_string::data() and string literals, std::basic_string_view::data() returns
a pointer to a buffer that is not necessarily null-terminated, for example a substring
view (e.g. from remove_suffix). Therefore, it is typically a mistake to pass data() to
a routine that takes just a const CharT* and expects a null-terminated string.

Так что если уж на то пошло, то лучше передавать filesystem::path.

Вам могут в string_view передать например часть строки, в конце не будет ноля, и всё поломается

Символы из переданного string_view будут внутри всё-равно копироваться в string, чтобы в какой-нибудь fopen или CreateFile передать нультерминированную строку. Учтите, я не говорю об общих случаях, когда нет необходимости модифицировать строку или передавать дальше в стороннее C-API - тогда лучше string_view по значению. Но в этом конкретном случае - выгоды нет.

string_view не даёт гарантий нультерминированнлсти, а значит где-то в глубинах он будет копироваться, ибо API всех ОС ждут C-строку. Так что выгода вряд ли будет.

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

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

Поддерживает ли Аврора GLES3?
Хотел попробовать на нее одну свою игру портировать, а на сайте Авроры пишут только GLES2...

Вот потому что не используете виртуальные функции, у вас и "сотни колбеков вздох". Такой подход я часто видел в C-программах, за неимением интерфейсов весь полиморфизм реализуется передачей колбеков. Часто даже делают аналог vtable, "закат солнца вручную".

Игра с идеально симулированым реальным миром будет ужасно скучной.

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

Это не количество рабочих дней, а просто количество дней без суббот и воскресений. Чтобы это был подсчет рабочих дней, надо хотя бы учитывать страну и производственный календарь с указанием праздничных дней.

Класс, предоставляющий доступ к закрытым данным родительского класса - паттерн "Паблик Морозов"

У Джоэла Спольски была в своё время статья "Верблюды и песочницы", оттуда тезис "Как известно, 80% пользователей используют только 20% программы. Но не думайте, что реализовав 20% фич, вы получите 80% пользователей. Потому что эти 20% у всех разные". То есть каждому будет не хватать какой-то своей фичи, в итоге продуктом будут мало пользоваться.

Это был IT-субботник или рабочее время оплачивалось? Носил ли начальник бревно вместе с пролетариями? Играл ли оркестр туш при вручении вымпелов победителям?
PS: У меня есть папка e:\old_disk\old_disk\from_old_work\старое

"Если в схеме не видишь лоха, значит лох в ней ты"

Это ж обычные фиберы, в Винде они наверное ещё со времён NT, как и в линуксах с их swapcontext. Разрабы джавы не смогли в нормальный планировщик фиберов на пуле потоков? Вообще, переход на асинхронность должен менять мозг разработчиков в части устройства платформы. Для качественной работы там надо убирать все блокировки, заменяя на нотификации, а "спать" реальный поток должен только в одном случае - когда нет заданий в очереди. Не получилось задаче захватить ресурс - подпишись на его освобождение и отдай поток другой задаче.

Information

Rating
4,111-th
Registered
Activity