also ich denke mal es gibt hier bestimmt einige COM-Spezis die mir da evtl. weiterhelfen können...

1.) Wenn man innerhalb eines COM-Objektes Speicher alloziiert und diesen an den Client gibt, sollte man das ja grundsätzlich mit CoTaskMemAlloc machen, richtig oder?

2.) Wenn man das innerhalb eines COM-Objektes tut, aber man genau weiß, dass der Client auch ein C++ Client ist (auch derselbe Compiler, also z.B. MSVC8), kann man eigentlich auch auf CoTaskMemAlloc verzichten und genauso gut new verwenden, auch richtig?

3.) Und das ist eigentlich meine eigentliche Frage:
Angenommen ich habe eine einfache C-Funktion (welche ich in einem COM-Objekt kapseln will), z.B. so:

void func(char** ppData, int* pDataLen) {...}

Der C-Aufrufer benutzt die Funktion dann so:

int nDataLen = 10;
char* pData = new char[nDataLen];
func(&pData, &nDataLen);
...

In der Funktion "func" können dann in den übergebenen Speicherbereich irgendwelche Daten geschrieben werden, oder wenn der übergebene Speicherbereich zu klein ist, wird dieser einfach erst gelöscht und dann neu allokert und dann kommen die Daten rein. Wichtig ist halt, dass der Aufrufer(Client) eigentlich zuerst Speicher bereitstellt, und dieser dann erst bei Bedarf in der Funktion func gelöscht/neu allokiert wird.

Wenn ich diese Funktionalität jetzt in einem COM-Objekt bereitstelle, muss ich für die Speicherreservierung dann auch CoTaskMemAlloc verwenden, oder würde es new auch tun? (vorrausgesetzt, dass ich dieses COM-Objekt dann auch in anderen Sprachen wie VB,C#, usw... benutzen will)

Und solche rohen Zeiger sind IIRC nicht "automation compatible" sobald sie auf mehr als ein Element zeigen. (Bzw. auch Zeiger auf Zeiger sind nicht "automation compatible" wenn der primäre und/oder sekundäre Zeiger auf mehr als ein Objekt zeigt.)

Eine Möglichkeit wäre BSTRs zu verwenden, mit SysAllocStringByteLen o.ä. Übergeben würdest du dann einen "[in, out] BSTR*", und die Funktion könnte den alten BSTR falls nötig freigeben und durch einen neuen ersetzen.

Eine andere Möglichkeit wären variant arrays/safearrays.

Noch eine andere Möglichkeit wären Streams (IStream, ggf. mit CreateStreamOnHGlobal einen "Memory-Stream" anlegen).
Allerdings: ich weiss nicht ob IStream funktioniert wenn der Interface Pointer zwischen Apartments/Prozessen/Systemen gemarshalt wird -- denke eher nicht. Weiss also nicht ob das so eine gute Idee ist

SAFEARRAYS verwende ich bei ein paar anderen Dingen bei mir auch schon... Aber wenn ich grad dabei bin... können die nachträglich noch wachsen? Ne oder?

Danke auf jeden Fall schon mal

SysAllocString wenn der "Quellstring" nullterminiert ist und "Text" enthält,
SysAllocStringLen wenn der "Quellstring" nicht nullterminiert ist aber auch "Text" enthält,
und SysAllocStringByteLen wenn der "Quellstring" keinen Text enthält sondern irgendwelche Binärdaten die du 1:1 so rumreichen willst (d.h. wo eine Konvertierung nach UNICODE so garnicht erwünscht ist).

Innerhalb der Implementierung der COM-Funktion kann ich dann ja meinen eigenen Speicher anlegen benutzen und damit meine alte C Funktion aufrufen.

Jo, genau.

Das Ergebnis könnte ich dann ja in meinen BSTR Parameter kopieren. Sehe ich richtig oder?

Mit dem Ergebnis kannst du dann SysAllocStringXxx aufrufen. Dann gibst du den alten BSTR frei (SysFreeString), und überschreibst ihn mit dem neuen BSTR.

SAFEARRAYS verwende ich bei ein paar anderen Dingen bei mir auch schon... Aber wenn ich grad dabei bin... können die nachträglich noch wachsen? Ne oder?

Da bin ich im Moment überfragt.
Falls nicht könnte es immernoch mit einem Zeiger auf ein variant-array/safearray gehen -- also quasi gleich wie mit dem BSTR.

Also nur mal so zum Topic, hab ich grade gesehen: SAFEARRAYs können nicht dynamisch wachsen.

Können sie doch:
http://msdn2.microsoft.com/en-us/library/ms221002.aspx