Schematisch sieht das so aus:

HRESULT MyClass::EventBlubb()
{
   // ...
   Lock();
   IUnknown** pp = this->m_vec.begin();
   Unlock();
   for(; pp != this->m_vec.end(); pp++)
   {
      __WeissNimmerWasGenau(*pp, ...);
   }
   // ...
}

Und ich denke dieser Code ist oberfaul.

In der Funktion wird weder eine lokale Kopie der Daten in m_vec gemacht, noch wird der Lock lange genug aufrecht erhalten (was dann aus anderen Gründen wieder problematisch wäre) -- ruft jmd. in der Zeit wo EventBlubb() läuft also Advise oder Unadvise auf, dann krachts u.U.
(Advise bzw. Unadvise können zum Beispiel dazu führen dass der von m_vec.begin() bzw. m_vec.end() zurückgelieferte Pointer sich ändert, bzw. auch einfach der Inhalt des Vectors).
Und BTW: m_vec ist KEIN std::vector sondern irgendsoein ATL Zeugs, ist aber in dem Fall ziemlich egal, m_vec kümmert sich auch NICHT um irgendwelche Synchronisierungsgeschichten. Könnte es auch garnicht, nicht wenn der Code aussen so aussieht wie er nunmal aussieht.

Ist jmd. von euch schonmal über dieses Problem drübergestolpert? Falls es jmd. interessiert der es noch nicht weiss: den injizierten Code kann man sich z.B. ansehen indem man in den Project-Settings unter "Output Files" die Option /Fx einstellt ("Expand Attributed Source: yes"). Oder indem man mit dem Debugger einfach reinsteppt...

Und wichtiger: weiss jmd. eine Lösung?
Speziell auch für folgenden Fall:

1. Client ruft Advise() auf
2. COM Server fängt an einen Event an alle registrierten Clients zu schicken, holt sich grad den Zeiger auf unseren Client und ...
3. Client ruft Unadvise auf (und Unadvise gibt die Sink-Referenz frei!)
4. Client zerstört seine Sink ("der Sink"/"die Sink" ... ? egal.)
5. COM Server läuft weiter wo er bei 2) stehengeblieben ist, und schickt den Event an den alten Interface Zeiger aus -- die Referenz wurde aber bereits hergegeben, und das Objekt ist schon tot. Pöse

Klar könnte ich die Implementierung von Advise(), Unadvise() und EventXYZ() selbst schreiben so dass das passt, aber irgendwo hatte ich ja doch gehofft dass dieses "attributed C++ COM Zeugs" mir genau sowas abnehmen würde...

p.S.: MSVC7.1 (SP1) generiert bis auf ein kleines (und in dem Fall unwichtiges) Detail genau den selben Code.

IUnknown** pp = this->m_vec.begin();

Und kein CComPtr? Würde mich wundern.

Hast Du ein sample? Muss nicht Multithreaded sen?

Atributed ATL war zum großen Teil zwischen VS2003 und VS2005 nicht komaptibel und es gibt mit dem Zeug Scherereien ohne Ende.

Ich ärgere mich heute noch, dass ich einen Teil der DB Features verwendet habe.

Oder gibt's vielleicht eine einfachere Möglichkeit als ATL? Irgendwas was mir hilft out-of-process COM Server (bzw. evtl. auch mal in-process) mit schönen dualen Interfaces und Events etc. in C++ zu programmieren...

Managed C++ möchte ich eigentlich nicht verwenden, und C++ sollte es auf jeden Fall bleiben (aus verschiedenen Gründen).

----

Hier das gewünschte Beispiel, das ist der Code den MSVC8 (SP1) erzeugt damit ich meine Events verschicken kann:

// in MyClass.h (bzw. MyClass.mrg.h) innerhalb von MyClass:

    HRESULT MyEvent(::LONG i1,::LONG i2,::LONG i3,::LONG i4) 
    {
        HRESULT hrRet = S_OK;
        HRESULT hr = S_OK;
        IConnectionPointImpl<MyClass, &__uuidof(MyNamespace::DMyDualInterface), CComDynamicUnkArray>* p = this;
        VARIANT rgvars[4];
        Lock();
        IUnknown** pp = NULL;
        __try 
        {
            pp = p->m_vec.begin();
        }
        __finally 
        {
            Unlock();
        }
        while (pp < p->m_vec.end()) {
            if (*pp != NULL) {
                IDispatch* pDispatch = (IDispatch*) *pp;
                ::VariantInit(&rgvars[3]);
                rgvars[3].vt = VT_I4;
                V_I4(&rgvars[3])= i1;
                ::VariantInit(&rgvars[2]);
                rgvars[2].vt = VT_I4;
                V_I4(&rgvars[2])= i2;
                ::VariantInit(&rgvars[1]);
                rgvars[1].vt = VT_I4;
                V_I4(&rgvars[1])= i3;
                ::VariantInit(&rgvars[0]);
                rgvars[0].vt = VT_I4;
                V_I4(&rgvars[0])= i4;
                DISPPARAMS disp = { rgvars, NULL, 4, 0 };
                VARIANT ret_val;
                hr = __ComInvokeEventHandler(pDispatch, 151, 1, &disp, &ret_val);
                if (FAILED(hr)) {
                    hrRet = hr;
                }
            }
            pp++;
        }
        return hrRet;
    }

m_vec ist dabei vom Typ CComDynamicUnkArray, und die Advise und Unadvise Funktionen können wie gesagt dazu führen dass die Pointer die .begin() bzw. .end() zurückliefern sich ändern. Der Zugriff auf m_vec innerhalb der Schleife (ohne Lock) ist IMHO also komplett falsch und ziemlich riskant.

MSVC 7.1 lässt das __try und __finally weg, ansonsten ist der Code gleich was ich gesehen habe. Ich hab' zwar kein diff drüber gemacht, aber die Teile um die es mir geht sind gleich.