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

Merge создаёт новую картинку, а не лист. Однако же, про порядок это ценная информация, спасибо, я подумаю над этим.

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

создает картинку, которую хранит листе. глянул на msdn щас

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

И чо тогда будет — непонятно %)

если в исходной картинке (иконке) была нужная глубина, она вставится, если нет - не помню, сорь )

У меня происходит вообще непонятный эффект: - при 24-битном цвете листа всё работает как положено (на картинку A накладываем картинку B с учётом прозрачностей) - при 32-битном цвете операция Merge почему-то делает всё шиворот-навыворот: вырезает из картинки A непрозрачную часть картинки B, делая в картинке A прозрачную дырку с соответствующим контуром

без учета альфа-канала накладывает, там где дырка - там "смесь" должна быть

Погодити, как это без учёта?

Мб он маски учитывает?

А альфа-каналы не учитывает?

ну вот по маске и вырезает

Это бы... ничего не объяснило, на самом деле. Но тоже интересная мысль, щас попробую разобраться.

а по альфа каналу накладывать поверх с учетом прозрачности должен

то есть там, где маски совпадают

Чуваки, кто-нибудь разбирается в легаси-WinAPI штуках? Я второй день себе ломаю голову об ImageList_Merge и то, как он работает с прозрачностью на объединяемых картинках. Почему-то при переключении листа на 32-битный цвет из этого ImageList_Merge полезли небывалые артефакты.

Ну?

ImageList_Merge это в винапи? чот я не припомню там такого именования функций

Это макрос -враппер для посылки сообщения объекту ImageList...

Ну, мб не совсем винапи. На самом деле я, грешным делом, вообще не знаю, что такое винапи, и какие функции туда следует относить, а какие нет %)

Это самое что ни на есть WinAPI

Это макрос -враппер для посылки сообщения объекту ImageList...

Ну, с точки зрения языка это не макрос, это настоящая функция. В моей версии SDK, по крайней мере.

Это макрос -враппер для посылки сообщения объекту ImageList...

ооок

Это макрос -враппер для посылки сообщения объекту ImageList...

нет, большая часть api ImageList_* являются настоящими функциями, (и только пару врапперов), это все остальное в commctrl.h является врапперами над посылкой сообщений, т.к. оперирует контролами windows. Но ImageList ни разу не контрол

/warn а вот и правила

Nikita has been warned (2/5)

нет, большая часть api ImageList_* являются настоящими функциями, (и только пару врапперов), это все остальное в commctrl.h является врапперами над посылкой сообщений, т.к. оперирует контролами windows. Но ImageList ни разу не контрол

Может быть, там легко перепутать....

uint32_t thing; stream.read(reinterpret_cast<int8_t*>(&thing), 4); Коллеги, насколько валидно так читать числа (в двоичном представлении) из потока? В потоке (файле) лежат байты: 0x00 0x00 0x30 0x39. Я хочу прочитать их как число 12345 (uint32_t). P.S. "endianess" не волнует.

> P.S. "endianess" не волнует. а зря

uint32_t thing; stream.read(reinterpret_cast<int8_t*>(&thing), 4); Коллеги, насколько валидно так читать числа (в двоичном представлении) из потока? В потоке (файле) лежат байты: 0x00 0x00 0x30 0x39. Я хочу прочитать их как число 12345 (uint32_t). P.S. "endianess" не волнует.

А что смущает? Всё нормально. Кроме кроссплатформенности. Где записал - там нормально прочитаешь.

Ну, целевая архитектура — x86, а она, насколько мне известно, little-endian. ARM — bi-endian, если уж вдруг. Архитектуры, которые в основном используются в устройствах вроде роутеров изначально не поддерживаются, ибо код не предназначен для использования там.

В потоке (файле) лежат байты: 0x00 0x00 0x30 0x39. Я хочу прочитать их как число 12345 (uint32_t). а прочитаешь 0x39300000 - если это то что тебе надо, то пожалуйста

Ну, я это в примере написал не так, ладно.

Ну, целевая архитектура — x86, а она, насколько мне известно, little-endian. ARM — bi-endian, если уж вдруг. Архитектуры, которые в основном используются в устройствах вроде роутеров изначально не поддерживаются, ибо код не предназначен для использования там.

bi-endian не значит что оно одновременно может в обе полярности читать и писать, если что. это через MCR переключается (ака под супервизором)

Гм... Интересно.

Ладно, думаю есть смысл тогда учесть этот фактор.

Ну, целевая архитектура — x86, а она, насколько мне известно, little-endian. ARM — bi-endian, если уж вдруг. Архитектуры, которые в основном используются в устройствах вроде роутеров изначально не поддерживаются, ибо код не предназначен для использования там.

нужна кросплатформенность, после чтения что-то типа thing = le32_to_cpu(thing) макрос вставь, на le платформе бесплатно будет, на be - swap32

Вот, так и сделаю.

ntohl() это называется

htonl() для наоборот

ntohl() это называется

это наоборот называется

но оно network order подразумевает

который be

как вменяемый для транспорта/хранения

который be

я знаю

ntohl() это называется

network to host, ага.

я знаю

ну тогда зачем советуешь то, что не подходит? )

network byte order — это у нас little-endian, так?

Ага.

нет

А что?

network byte order — это у нас little-endian, так?

big endian

А, ясно.

ERROR: S client not available

network byte order = big endian

ну тогда зачем советуешь то, что не подходит? )

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

ну и в примере он как раз big endian сторадж нарисовал)

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

ок, как с помощь hton*/ntoh* конвертировать прочитанный le в host byte order? :)

Ну, целевая архитектура — x86, а она, насколько мне известно, little-endian. ARM — bi-endian, если уж вдруг. Архитектуры, которые в основном используются в устройствах вроде роутеров изначально не поддерживаются, ибо код не предназначен для использования там.

Пример процессора ARM с поддрежкой bi-endian можно узнать?

Я, честно, не знаю ни одного. Просто спрашиваю

Я, честно, не знаю ни одного. Просто спрашиваю

Cortex-A8 пойдет?

You can change data access endianness using the SETEND instruction: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489f/Cjacabbf.html

Пример процессора ARM с поддрежкой bi-endian можно узнать?

Сам не знаю, в википедии написано, что bi-endian

https://en.wikipedia.org/wiki/ARM_architecture

Endianness Bi (little as default)

Сам не знаю, в википедии написано, что bi-endian

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

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

я выше скинул команду. она влияет только на данные, код всегда LE

Cortex-A8 пойдет?

Подойдет любая модель которую можно купить в магазе

Подойдет любая модель которую можно купить в магазе

отлично, тогда Cortex-A8 подходит

отлично, тогда Cortex-A8 подходит

Любой Cortex-A8 какой найду?

можно даже не покупать, он скорее всего у тебя в телефоне уже

ОБижаешь

У меня не такое старье

детский сад

Ясельная группа

Добрый вечер!

если мне нужна mini как минимальная строка в векторе, то пойдет ли такая реализация?

mini = *std::min_element(slicedPerf.begin(), slicedPerf.end());

при учете, что mini — std::vector<double>