Size: a a a

2020 August 22

A

Anton in supapro.cxx
Здравствуйте!
Подскажите, пожалуйста, как правильно написать:
uint8_t U_BUFo[FIXED_CONTROL_ENDPOINT_SIZE] __attribute__ ((aligned (2)));
uint16_t tmp16;
..............
tmp16 = *(uint16_t*)(&U_BUFo[wLengthL]);
Ругается: Warning - dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
источник

W

Wild_Wind in supapro.cxx
Alexander Potapov
@alex_0v у тебя в CMake есть include_directories() в него ты подаешь все хедер файлы, которые должны быть видны в твоем проекте
Да хватит уже юзать глобальные include_directories и link_libraries.
Уверуйте в таргеты и добавляйте только для них.
Не срите в глобалспейс. Юзайте:

add_executable(some.bin
main.cxx
foo.cxx
bar.cxx
)

target_include_directories(some.bin PRIVATE
some_header.hxx
some2_headr.hxx
foo.hxx bar.hxx
${libastral_INCLUDE_DIRS}
)

target_link_libraries(some.bin libastral i_love_read_fucking_mamual
usai_modern_cmake_blet111
)
источник

AS

Arsen Stotskyi in supapro.cxx
Anton
Здравствуйте!
Подскажите, пожалуйста, как правильно написать:
uint8_t U_BUFo[FIXED_CONTROL_ENDPOINT_SIZE] __attribute__ ((aligned (2)));
uint16_t tmp16;
..............
tmp16 = *(uint16_t*)(&U_BUFo[wLengthL]);
Ругается: Warning - dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
правильно написать так, чтобы не ругалось
источник
2020 August 23

ПК

Побитый Кирпич... in supapro.cxx
Anton
Здравствуйте!
Подскажите, пожалуйста, как правильно написать:
uint8_t U_BUFo[FIXED_CONTROL_ENDPOINT_SIZE] __attribute__ ((aligned (2)));
uint16_t tmp16;
..............
tmp16 = *(uint16_t*)(&U_BUFo[wLengthL]);
Ругается: Warning - dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
std::memcpy(&tmp16, U_BUFo + wLengthL, FIXED_CONTROL_ENDPOINT_SIZE);
источник

A

Anton in supapro.cxx
Побитый Кирпич
std::memcpy(&tmp16, U_BUFo + wLengthL, FIXED_CONTROL_ENDPOINT_SIZE);
Может: std::memcpy(&tmp16, U_BUFo + wLengthL, 2);
источник

ПК

Побитый Кирпич... in supapro.cxx
может
источник

A

Anton in supapro.cxx
Спасибо:)
источник

ДК

Денис Кузнецов... in supapro.cxx
Ребята, у меня вопрос в большей степени к архитектуре, чем к коду.
Вот есть у меня состояния объекта. Например, объект способен принимать данные, или временно занят.
Или например, сами типы объектов - объект может быть А, Б, В, Г, Д типа (каждый инстанс определяет в себе свой тип).

И возник такой диссонанс. Я все время делал подобные вещи в виде енумов.
Но возникли некоторые требования, которые заставляют эти енумы динамично в рантайме расширять (добавлять новые типы), что по законам C++ нельзя делать. Резонно стал вопрос делать это в виде int-ов. То есть, вместо четких енумов делать не совсем четкие int-ы. Не четкие, потому что они предполагают, что программист обязан знать, к какой цифре какой тип пренадлежит и делать проверки - не выходит ли текущий int за пределы доступного диапазона чисел, когда как енумы позволяли это отобразить в названии элемента самого енума и всегда быть точными, без ошибок.

Нормальная ли практика определять типы по инт-ам? Мне кажется, что это менее безопасный код, и хотелось бы получить на эту тему какой-то фидбэк.
источник

TS

Till Schneider in supapro.cxx
Денис Кузнецов
Ребята, у меня вопрос в большей степени к архитектуре, чем к коду.
Вот есть у меня состояния объекта. Например, объект способен принимать данные, или временно занят.
Или например, сами типы объектов - объект может быть А, Б, В, Г, Д типа (каждый инстанс определяет в себе свой тип).

И возник такой диссонанс. Я все время делал подобные вещи в виде енумов.
Но возникли некоторые требования, которые заставляют эти енумы динамично в рантайме расширять (добавлять новые типы), что по законам C++ нельзя делать. Резонно стал вопрос делать это в виде int-ов. То есть, вместо четких енумов делать не совсем четкие int-ы. Не четкие, потому что они предполагают, что программист обязан знать, к какой цифре какой тип пренадлежит и делать проверки - не выходит ли текущий int за пределы доступного диапазона чисел, когда как енумы позволяли это отобразить в названии элемента самого енума и всегда быть точными, без ошибок.

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

ДК

Денис Кузнецов... in supapro.cxx
Till Schneider
Новые типы в рантайме добавлять нельзя
Это понятно. Поэтому я и пишу о том, что мы будем переводить, по всей видимости, в int-ы.
Например, добавлен в программу модуль пользователем, который расширяет эти типы и добавляет возможности к объекту (в игре пример - DLC).
Вот чтобы не допиливать заранее енумы - остается переводить на инты. Но тогда повышается риск ошибок.
Как лучше в таких ситуациях поступать? И что делают обычно супапро? =)
источник

TS

Till Schneider in supapro.cxx
Денис Кузнецов
Это понятно. Поэтому я и пишу о том, что мы будем переводить, по всей видимости, в int-ы.
Например, добавлен в программу модуль пользователем, который расширяет эти типы и добавляет возможности к объекту (в игре пример - DLC).
Вот чтобы не допиливать заранее енумы - остается переводить на инты. Но тогда повышается риск ошибок.
Как лучше в таких ситуациях поступать? И что делают обычно супапро? =)
И как ты эти инты в дальнейшем собираешься использовать? Зачем они вообще нужны?)))
Почему без них нельзя?
источник

SS

Sergey Sobolev in supapro.cxx
Денис Кузнецов
Это понятно. Поэтому я и пишу о том, что мы будем переводить, по всей видимости, в int-ы.
Например, добавлен в программу модуль пользователем, который расширяет эти типы и добавляет возможности к объекту (в игре пример - DLC).
Вот чтобы не допиливать заранее енумы - остается переводить на инты. Но тогда повышается риск ошибок.
Как лучше в таких ситуациях поступать? И что делают обычно супапро? =)
Поконкретнее, A, B - это енумы внутри объекта, от него зависит поведение объекта?
источник

ДК

Денис Кузнецов... in supapro.cxx
Sergey Sobolev
Поконкретнее, A, B - это енумы внутри объекта, от него зависит поведение объекта?
Да, зависит.
Например, Объект - огнестрельное оружие в игре.
Инстансы - дробовик, пистолет, автомат.

Три типа, по которым определяется что-то там.
И вот я хочу добавить в ДЛС Гранатомет. Но не хочу создавать отдельный класс или дописывать в енум тип, потому что этот ДЛС может быть, а может и не быть, поэтому основной игре незачем знать об этом типе до тех пор, пока не будет добавлено ДЛС. А когда оно будет удалено - игра просто забудет о нем, как о страшном сне.

В таком ключе енумы не подойдут. Остается вариант с int
источник

ДК

Денис Кузнецов... in supapro.cxx
Till Schneider
И как ты эти инты в дальнейшем собираешься использовать? Зачем они вообще нужны?)))
Почему без них нельзя?
Выше Сергею Соболеву написал пример применения и почему тип объекта имеет смысл, а без них нельзя.
источник

TS

Till Schneider in supapro.cxx
Денис Кузнецов
Выше Сергею Соболеву написал пример применения и почему тип объекта имеет смысл, а без них нельзя.
Все равно не понятно, зачем тебе инты)))
источник

TS

Till Schneider in supapro.cxx
И енумы))
источник

ДК

Денис Кузнецов... in supapro.cxx
Till Schneider
Все равно не понятно, зачем тебе инты)))
А какой вариант определения типа объекта может быть? И при этом, чтобы он был динамичным?
источник

TS

Till Schneider in supapro.cxx
Денис Кузнецов
А какой вариант определения типа объекта может быть? И при этом, чтобы он был динамичным?
Определение типа: задача полиморфизма
источник

ДК

Денис Кузнецов... in supapro.cxx
Till Schneider
Определение типа: задача полиморфизма
Например?
источник

O

Ofee in supapro.cxx
Денис Кузнецов
А какой вариант определения типа объекта может быть? И при этом, чтобы он был динамичным?
Если неизвестен тип, то как же он может обрабатываться остальным кодом? Либо вопрос идентификации излишен, либо явно не продумана ключевая часть функционала
источник