сравнение переменных UDT

[Space]

А почему нельзя сравнивать элементы массива User Define Type целиком, а только по полям? Если значения всех полей равны - True, иначе False...

[alibek]

Можно, вообще-то.

[Space]

почему тогда вылетает ошибка?

Код: Выделить всё

Dim My As struMy
Private Type struMy
    b1 As Long
    b2 As Long   
End Type

Private Sub Form_Load()
Dim a1 As struMy
If a1 = My Then
End If
End Sub

[alibek]

А ты сравнивай через RtlCompareMemory.

[Space]

а что ж на If не сделали, мелкософтовцы...

[ANDLL]

А ты сравнивай через RtlCompareMemory.

Так, сравнение через RtlCompareMemory это вовсе не то же самое, что почленное сравнение
Для структур вроде struMy конечно реузльтат будет один, но для боле сложных структур(содержащих объекты там, строки, или просто невыровненную компибнацию integer'ов и long'ов) придется все равно сравнивать по одному

[alibek]

Для чисел вполне можно обойтись. Для строк/вариантов/объектов/массивов, понятно не подойдет.

[ANDLL]

Для чисел вполне можно обойтись. Для строк/вариантов/объектов/массивов, понятно не подойдет.

Для структуры вроде
type x
a as integer
b as long
end type
уже нельзя обойтись

[alibek]

Разве?

[ANDLL]

Разве?

Угу. Если UDT както обрабатывалась вне VB, то да(а так как в общем случае за этим легко не уследить, то лучше особо и не конкретезировать)

[alibek]

Угу.

Если предполагать, что UDT может меняться где-то снаружи, то этот UDT и так будет выровненным.
Если же UDT изменяется только из VB, то RtlCompareMemory подойдет.

[ANDLL]

Ты видимо меня не понял.
Я говорю о том, что в некоторых структурах(подобным той которую я привел) есть незначащие байтики, которые не учитываются при обычном сравнении и учитываются при сравнении через ComapreMemory
Более того, ничего в плане спецификации не гарантирует что неиспользуемые байты буду одинаковыми. Поэтому использовать для сравнения таких структур ComapreMemory нельзя.
А так как среднестатистический программист на VB ничего не знает про неиспользуемые байты, то совет использовать ComapreMemory можно назвать мягко говоря сомнительным для написания стабильных приложений.
Фразу

Если предполагать, что UDT может меняться где-то снаружи, то этот UDT и так будет выровненным.

я не понял. Проблемы возникают именно потому, что все UDT в VB выровнены

[alibek]

Да я понял, и я именно об этом.
Если UDT не выровнена, то в ней могут быть байты, содержимым которых из VB управлять невозможно. И действительно, нет спецификаций, в которых описывается, что с этими неиспользуемыми байтами происходит. Но есть здравый смысл:
1. При объявлении переменной она инициализируется нулями. Нет ни одной разумной причины, по которой инициализировались бы отдельные мемберы UDT, а не весь блок памяти, занимаемый UDT. Стало быть, неиспользуемые байты в UDT всегда будут одинаковы (нули).
2. При изменении значений мемберов UDT нет ни одной разумной причины, чтобы изменялись неиспользуемые байты. Стало быть, пока UDT используется внутри VB, неиспользуемые байты не будут изменять своих значений.
3. Неиспользуемые байты в UDT могут быть изменены снаружи. Однако когда UDT предполагается использовать снаружи, как правило следят за выравниванием. Во всяком случае в файле WIN32API.TXT большая часть UDT объявлена так, чтобы не было проблем с выравниванием.
Так что при условии, что в UDT нет строк, объектов, вариантов и т.п., RtlCompareMemory нормально будет работать.

Проблемы возникают именно потому, что все UDT в VB выровнены

Ну да. Имелось ввиду, что UDT будет объявлена таким образом, чтобы избежать проблем с выравниванием.