Потрібно використовувати тільки перший метод. Другий метод це страшно брудний підхід. Кримінал. Розстріл.
Що стосується питання про впливу значення cElements в момент звільнення пам'яті - питання цікаве. Сам процес знищення масиву потрібно розділити на дві фази.
Перша фаза - це зачистка контенту масиву. Якщо це масив об'єктів, посилання будуть занулені, буде викликаний IUnknown :: Release. Якщо це рядки, буде викликаний SysFreeString для кожного елемента. VariantClear для варіантів. І тому подібне. На цю фазу, безумовно, значення cElements впливає.
Інша справа, що функції SaMap і SaUnmap (а саме так я назвав функції в своїх цеглинах. Відповідають за проектування SAFEARRAY-масиву на довільний регіон пам'яті) зазвичай приймають посилання на масив ByRef. При цьому вони не знають, хто є власником масиву (власник відповідає за створення і знищення). Вони не знають, чим користувався власник для створення і виділення. Тому вони не можуть зі стовідсотковою впевненістю покладатися на те, що для звільнення пам'яті буде використаний метод IMalloc :: Free.
З іншого боку, можна уявити собі вилку варіантів: якщо SaMap приймає масив ByRef, то значить є VB-шная змінна-масив. Значить або масив був виділений самим VB, або залишається варіант, що масив сконструювала третя сторона (можливо, користуючись нестандартним способом управління пам'яттю) і записала покажчик на SA-дескриптор в VB-шную змінну. Але варто пам'ятати, що в другому випадку автоматичне видалення масиву силами VB піде за сценарієм oleaut32.dll, тобто пам'ять буде звільнена з допомогою IMalloc: Free незалежно від того, як вона була виділена. Так що якщо VB-шную змінну-масив встановлює третя сторона, то і зачистку вона повинна робити. І з такими масивами не потрібно використовувати трюки з підміною cElements.
-We separate their smiling faces from the rest of their body, Captain.
-That's right! We decapitate them.