Это было в 1989 году, класс MSX был в местном пединституте. У нашего мат.класса это была "производственная практика", по четвергам у нас там было 6 уроков, на весь день. Сначала обучили на калькуляторах БЗ-34, потом на ямахах. В 1990 году уже у нас в школе поставили класс на Атари, занимались уже в школе.
Тогда только появился игровой автомат "Городки". Вверху перемещается влево-вправо картинка с фигурой из городков, внизу вращается бита, которую тоже можно двигать влево-вправо. По нажатию кнопки бита летит вверх. Надо попасть по фигуре. Делал на спрайтах, в MSX-BASIC есть событие при столкновении спрайтов.
"А мы продаём или покупаем"? Вы вызываете чужой 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)
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, чтобы в какой-нибудь fopen или CreateFile передать нультерминированную строку. Учтите, я не говорю об общих случаях, когда нет необходимости модифицировать строку или передавать дальше в стороннее C-API - тогда лучше string_view по значению. Но в этом конкретном случае - выгоды нет.
string_view не даёт гарантий нультерминированнлсти, а значит где-то в глубинах он будет копироваться, ибо API всех ОС ждут C-строку. Так что выгода вряд ли будет.
Так там основная сложность не с прошивкой, а с первым запуском после нее, когда шлем требует подключится к экстремистской организации, и без этого не хочет дальше работать. Или в последних прошивках этого уже нет?
Для отслеживания рук применяется камера смартфона или отдельная? Если смартфона, то как решается отслеживание контроллеров вне поля зрения?
И она вам сможет два символа в один сконвертировать? Или один в два? И с utf-8 умеет работать?
А в чем проблема собеседоваться на другую работу с текущего рабочего места? Стесняетесь?
Это было в 1989 году, класс MSX был в местном пединституте. У нашего мат.класса это была "производственная практика", по четвергам у нас там было 6 уроков, на весь день. Сначала обучили на калькуляторах БЗ-34, потом на ямахах. В 1990 году уже у нас в школе поставили класс на Атари, занимались уже в школе.
Тогда только появился игровой автомат "Городки". Вверху перемещается влево-вправо картинка с фигурой из городков, внизу вращается бита, которую тоже можно двигать влево-вправо. По нажатию кнопки бита летит вверх. Надо попасть по фигуре. Делал на спрайтах, в MSX-BASIC есть событие при столкновении спрайтов.
В школе из игр делал "Городки" на Yamaha MSX2, пытался Lode Runner сделать. Всякими спрайтами целые тетрадки были изрисованы. Хорошее было время...
"Проводились активности по удалению" - это какой-то новый канцелярит?
Жаль fossil не взлетел. Один экзешник, один файл репозитория, селф-хостед веб-морда. Использовал для своих проектов.
Жаловаться на Дзен на Хабре? А почему не в Спортлото?
У Яндекса все исходники пару лет назад утекли в сеть, нашли там что-нибудь этакое?
Точка с запятой после for
Не совсем понял, умеет ли этот сериализатор работать с полиморфизмом?
Жалуется на медленный 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
Как видите, параметром он требует Null terminated string specifying the filename.
string_view::data не дает гарантий Null terminated.
https://en.cppreference.com/w/cpp/string/basic_string_view/data
Так что если уж на то пошло, то лучше передавать filesystem::path.
Вам могут в string_view передать например часть строки, в конце не будет ноля, и всё поломается
Символы из переданного string_view будут внутри всё-равно копироваться в string, чтобы в какой-нибудь fopen или CreateFile передать нультерминированную строку. Учтите, я не говорю об общих случаях, когда нет необходимости модифицировать строку или передавать дальше в стороннее C-API - тогда лучше string_view по значению. Но в этом конкретном случае - выгоды нет.
string_view не даёт гарантий нультерминированнлсти, а значит где-то в глубинах он будет копироваться, ибо API всех ОС ждут C-строку. Так что выгода вряд ли будет.
Так там основная сложность не с прошивкой, а с первым запуском после нее, когда шлем требует подключится к экстремистской организации, и без этого не хочет дальше работать. Или в последних прошивках этого уже нет?