§ imread()
Mat cv::imread ( const String & filename,
int flags = IMREAD_COLOR
)
Python:
retval = cv.imread( filename[, flags] )https://docs.opencv.org/3.4.5/d4/da8/gr … 7b3bbd3a56
Dll Export Viewer показывает:
class cv::Mat __cdecl cv::imread(class cv::String const & __ptr64,int)Через NET Framework Interop (CLR, C#, VB) вообще dll не загружается - выводит ошибку.
https://www.autohotkey.com/boards/viewtopic.php?t=4633
8, 16 и 32 бита разрешены, поскольку эти части 64-битного регистра можно использовать, как самостоятельные регистры. Например, в регистре RAX можно к ним обращаться, как AL, AX и EAX. Так что здесь вы лишнего писать не будете.
]]>такую структуру
struct ST1 {
char c1; 1
short s1; 2
word w; 2
double d; 8
};для 32 бит нужно передавать так?
"int64", c1 | (s1 << 8) | (w << 24), "double" dА для 64 так?
"int64", c1 | (s1 << 16) | (w << 32), "double" d
Для 64 бит нужно передавать ссылкой, так как размер ее не равен 8, 16, 32, or 64 bits.
]]>Сейчас проверил вот эту структуру в Visual C++.
typedef struct tagRAWMOUSE {
USHORT usFlags;
union {
ULONG ulButtons;
struct {
USHORT usButtonFlags;
USHORT usButtonData;
};
};
ULONG ulRawButtons;
LONG lLastX;
LONG lLastY;
ULONG ulExtraInformation;
} RAWMOUSE, *PRAWMOUSE, *LPRAWMOUSE;
Расстояние от начала структуры до ulButtons показывает 4 байта. Значит, выравнивание всё-таки есть и в x86. Видимо, верна моя догадка, что большинство структур так составлено, что выравнивание не требуется, поэтому и нет ошибок, даже если про него не думаешь.
]]>Конечно, можно предположить, что все структуры для x86 WinAPI так организованы, что и выравнивать не надо. Ну, может быть. Я каждую специально на этот предмет не проверял. Но это только гипотеза. Надо смотреть конкретные примеры структур.
]]>struct MixedData
{
char Data1;
short Data2;
int Data3;
char Data4;
};After compilation the data structure will be supplemented with padding bytes to ensure a proper alignment for each of its members:
struct MixedData /* After compilation in 32-bit x86 machine */
{
char Data1; /* 1 byte */
char Padding1[1]; /* 1 byte for the following 'short' to be aligned on a 2 byte boundary
assuming that the address where structure begins is an even number */
short Data2; /* 2 bytes */
int Data3; /* 4 bytes - largest structure member */
char Data4; /* 1 byte */
char Padding2[3]; /* 3 bytes to make total size of the structure 12 bytes */
};
Просто интересно такое поведение.
Ну, видимо, MsgBox тоже использует память.
Так всё-таки почему вы именно на 7 байт больше запрашивали буфер?
Это максимум, на который может сдвинуться вперёд адрес при округлении. Ведь расстояние между круглыми адресами 8 байт.
Кстати, на оффоруме функцию написали, правда для ahk2
При том, что тема была про v1. 
а почему это важно?
Просто интересно такое поведение.
А это реальный случай?
Не, выдуманный.
Так всё-таки почему вы именно на 7 байт больше запрашивали буфер?
Кстати, на оффоруме функцию написали, правда для ahk2:
https://github.com/HelgeffegleH/AHK-mis … all_struct
И почему если мы раскомментируем msgbox то результат будет другим?
Не знаю, а почему это важно?
И создание адреса структуры кратного самому большому элементу необходимо только при посылании структуры как ссылки?
Видимо. В отношении стека я об этом не слышал. Ячейки его и так выровнены.
И например такую структуру для 32 бит нужно передавать так?
А это реальный случай? Что-то я сомневаюсь. Как её передал бы компилятор С, я не знаю. В принципе, наверно, мог бы как угодно, поскольку ведь код той функции, которая эту структуру принимает и использует, тоже он пишет. Он может просто выделить достаточное место в стеке и записать её туда либо ближе к началу этого места, либо ближе к концу, либо посередине. Нам нет смысла гадать.
]]>sruct_size := 16
VarSetCapacity(v1, sruct_size + 7)
; msgbox % &v1
pStruct := ((&v1 + 7) >> 3) << 3
msgbox % &v1 "`n" pStructИ создание адреса структуры кратного самому большому элементу необходимо только при посылании структуры как ссылки?
И например такую структуру
struct ST1 {
char c1; 1
short s1; 2
word w; 2
double d; 8
};
для 32 бит нужно передавать так?
"int64", c1 | (s1 << 8) | (w << 24), "double" dА для 64 так?
"int64", c1 | (s1 << 16) | (w << 32), "double" dЕсли создаёте структуру, то опять же просто выделяете 4 байта памяти и располагаете char и short в правильных местах этого объёма.
Адрес проще всего подгонять под кратный восьми. Судя по моим экспериментам, VarSetCapacity на x64 и так всегда выдаёт адреса, кратные 8. На x86 вижу либо то же, либо иногда бывают кратные 4.
Если нужна стопроцентная гарантия, то запрашивайте буфер на 7 байт больше, чем нужно, потом к адресу переменной прибавляйте 7 и округляйте результат до 8. Этот адрес уже и используйте для структуры.
VarSetCapacity(v1, sruct_size + 7)
pStruct := ((&v1 + 7) >> 3) << 3
Сдвиг на 3 бита вправо равносилен целочисленному делению на 8 (с отбрасыванием остатка), влево — умножению на 8. На 3 потому, что 8 — это третья степень двойки, а биты же двоичные числа.
В cdecl аргументы в стеке размещаются точно так же, как в stdcall. Разница между ними в том, кто их потом оттуда убирает. В cdecl это делает вызвавший функцию код, а в stdcall сама эта функция.
]]>