Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Ez a témakör a Hibakereső C++ adatmodelljének fogalmait ismerteti.
Az adatmodell fogalmai
Az adatmodell szintetikus objektumai gyakorlatilag két dolgot jelentenek:
- Kulcs/érték/metaadat hármasok szótára.
- Az adatmodell által támogatott fogalmak (interfészek) készlete. A fogalmak olyan felületek, amelyeket az ügyfél (szemben az adatmodellel) implementál a szemantikai viselkedés meghatározott halmazának biztosításához. A jelenleg támogatott fogalmak listája itt található.
| Koncepciófelület | Leírás |
|---|---|
| IDataModelConcept | A koncepció egy szülőmodell. Ha ez a modell automatikusan csatlakozik egy natív típushoz egy regisztrált típuskódon keresztül, a rendszer automatikusan meghívja az InitializeObject metódust minden alkalommal, amikor egy ilyen típusú új objektumot példányosít. |
| IStringDisplayableConcept | Az objektum megjelenítendő sztringgé alakítható. |
| IIterableConcept | Az objektum egy tároló, és iterálható. |
| IndexelhetőKoncepció | Az objektum egy tároló, amely egy vagy több dimenzióban indexelhető (véletlenszerű hozzáféréssel érhető el). |
| IPreferredRuntimeTypeConcept | Az objektum többet tud az abból származtatott típusokról, mint amennyit az alapul szolgáló típusrendszer képes biztosítani, és szeretné kezelni a saját statikusról futásidejű típusra való konvertálását. |
| IDynamicKeyProviderConcept | Az objektum a kulcsok dinamikus szolgáltatója, és szeretné átvenni az összes kulcslekérdezéseket az alapvető adatmodellből. Ezt a felületet általában a dinamikus nyelvek, például a JavaScript hidaként használják. |
| IDynamicConceptProviderConcept | Az objektum a fogalmak dinamikus szolgáltatója, és szeretné átvenni az összes fogalom-lekérdezést az alapvető adatmodellből. Ezt a felületet általában a dinamikus nyelvek, például a JavaScript hidaként használják. |
Az adatmodell fogalma: IDataModelConcept
Minden olyan modellobjektumnak, amely szülőmodellként egy másik modellobjektumhoz van csatolva, közvetlenül támogatnia kell az adatmodell koncepcióját. Az adatmodell koncepciója az alábbiak szerint definiált IDataModelConcept interfész támogatását igényli.
DECLARE_INTERFACE_(IDataModelConcept, IUnknown)
{
STDMETHOD(InitializeObject)(_In_ IModelObject* modelObject, _In_opt_ IDebugHostTypeSignature* matchingTypeSignature, _In_opt_ IDebugHostSymbolEnumerator* wildcardMatches) PURE;
STDMETHOD(GetName)(_Out_ BSTR* modelName) PURE;
}
Az adatmodellek regisztrálhatók canonical visualizerként vagy egy adott natív típus bővítményeként az adatmodell-kezelő RegisterModelForTypeSignature vagy RegisterExtensionForTypeSignature metódusain keresztül. Ha egy modell regisztrálva van ezen módszerek bármelyikével, az adatmodell automatikusan szülőmodellként lesz csatolva minden natív objektumhoz, amelynek típusa megegyezik a regisztrációban átadott aláírással. Azon a ponton, ahol a melléklet automatikusan létrejön, a rendszer meghívja az InitializeObject metódust az adatmodellen. A rendszer átadja a példányobjektumot, a mellékletet okozó típus-aláírást, valamint egy számba vevőt, amely létrehozza a típuspéldányokat (lineáris sorrendben), amelyek megfelelnek a típusaírásban szereplő helyettesítő karaktereknek. Az adatmodell implementációja ezt a metódushívást használhatja a szükséges gyorsítótárak inicializálására.
Ha egy adott adatmodell egy alapértelmezett név alatt van regisztrálva a RegisterNamedModel metóduson keresztül, a regisztrált adatmodell IDataModelConcept felületének ezt a nevet kell visszaadnia ebből a metódusból. Vegye figyelembe, hogy teljesen jogos, hogy egy modell több név alatt legyen regisztrálva (az alapértelmezett vagy legjobbat itt kell visszaadni). Előfordulhat, hogy egy modell teljesen névtelen (feltéve, hogy nincs regisztrálva egy név alatt). Ilyen körülmények között a GetName metódusnak E_NOTIMPL kell visszaadnia.
A sztring megjeleníthető fogalma: IStringDisplayableConcept
Egy objektum, amely megjelenítendő sztringkonvertálást kíván biztosítani, az IStringDisplayableConcept felület implementálásával implementálhatja a sztring megjeleníthető koncepcióját. Az interfész a következőképpen van definiálva:
DECLARE_INTERFACE_(IStringDisplayableConcept, IUnknown)
{
STDMETHOD(ToDisplayString)(_In_ IModelObject* contextObject, _In_opt_ IKeyStore* metadata, _Out_ BSTR* displayString) PURE;
}
A ToDisplayString metódust akkor hívjuk meg, amikor egy ügyfél egy objektumot megjelenítendő sztringgé szeretne alakítani (konzolra, felhasználói felületen stb.). Ez a sztringátalakítás nem használható további programozott manipulációk alapjául. A sztringátalakítást mélyen befolyásolhatják a híváshoz átadott metaadatok. A sztringátalakításnak minden kísérletet meg kell tennie a PreferredRadix és a PreferredFormat kulcsok betartására.
Az Iterable Concept: IIterableConcept és IModelIterator
Az olyan objektumok, amelyek más objektumok tárolói, és szeretnék kifejezni, hogy képesek iterálni ezen tárolt objektumok felett, támogathatják az iterálható koncepciót az IIterableConcept és az IModelIterator interfészek implementálásával. Nagyon fontos kapcsolat van az iterable koncepció támogatása és az indexelhető koncepció támogatása között. Az olyan objektumok, amelyek támogatják a tartalmazott objektumokhoz való véletlenszerű hozzáférést, az iterálási koncepció mellett az indexelhető fogalmat is támogathatják. Ebben az esetben az iterated elemeknek egy alapértelmezett indexet is létre kell hozniuk, amely az indexelhető fogalomnak való továbbításkor ugyanarra az objektumra hivatkozik. Az invariáns teljesítésének elmulasztása a hibakeresési gazdagép nem definiált viselkedését eredményezi.
Az IIterableConcept a következőképpen van definiálva:
DECLARE_INTERFACE_(IIterableConcept, IUnknown)
{
STDMETHOD(GetDefaultIndexDimensionality)(_In_ IModelObject* contextObject, _Out_ ULONG64* dimensionality) PURE;
STDMETHOD(GetIterator)(_In_ IModelObject* contextObject, _Out_ IModelIterator** iterator) PURE;
}
Az IModelIterator koncepció a következőképpen van definiálva:
DECLARE_INTERFACE_(IModelIterator, IUnknown)
{
STDMETHOD(Reset)() PURE;
STDMETHOD(GetNext)(_COM_Errorptr_ IModelObject** object, _In_ ULONG64 dimensions, _Out_writes_opt_(dimensions) IModelObject** indexers, _COM_Outptr_opt_result_maybenull_ IKeyStore** metadata) PURE;
}
Az IIterableConcept GetDefaultIndexDimensionality függvénye
A GetDefaultIndexDimensionality metódus a dimenziók számát adja vissza az alapértelmezett indexhez. Ha egy objektum nem indexelhető, ennek a metódusnak 0 értéket kell visszaadnia, és sikeresnek kell lennie (S_OK). Bármely objektum, amely nem nulla értéket ad vissza ebből a módszerből, egy protokollszerződés támogatását deklarálja, amely a következőt állítja be:
- Az objektum az IIndexableConcept támogatásával támogatja az indexelhető fogalmat
- Az iterálható koncepció GetIterator metódusából visszaadott IModelIterator GetNext metódusa minden előállított elemhez egyedi alapértelmezett indexet ad vissza. Az ilyen indexben a dimenziók száma az itt leírtak szerint jelenik meg.
- Ha az IModelIterator GetNext metódusából visszaadott indexeket az indexelhető koncepció GetAt metódusának (IIndexableConcept) átadja, az ugyanarra az objektumra fog hivatkozni, amelyet a GetNext előállított. Ugyanez az érték lesz visszaadva.
IIterableConcept GetIterator
Az iterálható koncepció GetIterator metódusa egy iterátorfelületet ad vissza, amely az objektum iterálására használható. A visszaadott iterátornak emlékeznie kell a GetIterator metódusnak átadott környezeti objektumra. Nem kerül átadásra az iterátor metódusainak.
IModelIterator alaphelyzetbe állítása
Az iterálási koncepcióból visszaadott iterátor alaphelyzetbe állítási metódusa visszaállítja az iterátor helyét arra a helyre, ahol az iterátor először létrejött (az első elem előtt). Bár erősen ajánlott, hogy az iterátor támogassa az Alaphelyzetbe állítás metódust, nem szükséges. Az iterátor egy C++ bemeneti iterátor megfelelője lehet, és csak egyetlen továbbítási iterációt engedélyez. Ilyen esetben előfordulhat, hogy a Reset metódus sikertelen lehet E_NOTIMPL.
IModelIterator GetNext
A GetNext metódus előre helyezi az iterátort, és lekéri a következő iterált elemet. Ha az objektum az iterálás mellett indexelhető is, és ezt jelzi a GetDefaultIndexDimensionality argumentum, amely nem nulla értéket ad vissza, ez a módszer opcionálisan visszaadhatja az alapértelmezett indexeket, hogy visszakerüljenek az indexelő által előállított értékre. Vegye figyelembe, hogy a hívó dönthet úgy, hogy 0/nullptr értéket ad át, és nem kér le indexeket. A hívó számára illegálisnak minősül részleges indexek kérése (pl. kisebb, mint a GetDefaultIndexDimensionality által előállított szám).
Ha az iterátor sikeresen előrehaladt, de hiba történt az iterated elem értékének beolvasásában, a metódus hibát adhat vissza, és az "objektumot" hibaobjektummal töltheti ki. Az iterátor a tartalmazott elemek iterációjának végén E_BOUNDS-t ad vissza a GetNext metódusból. Minden további hívás (hacsak nem történt beavatkozó visszaállítási hívás) szintén visszaadja az E_BOUNDS értéket.
Az indexelhető fogalom: IIndexableConcept
Az olyan objektumok, amelyek véletlenszerű hozzáférést szeretnének biztosítani egy tartalomkészlethez, támogathatják az indexelhető koncepciót az IIndexableConcept felület támogatásával. A legtöbb indexelhető objektum az iterálási koncepció támogatásával is iterable lesz. Ez azonban nem kötelező. Ha támogatott, fontos kapcsolat van az iterátor és az indexelő között. Az iterátornak támogatnia kell a GetDefaultIndexDimensionalitást, nullától eltérő értéket kell visszaadnia a metódusból, és támogatnia kell az ott dokumentált szerződést. Az indexelő koncepciófelülete a következőképpen van definiálva:
DECLARE_INTERFACE_(IIndexableConcept, IUnknown)
{
STDMETHOD(GetDimensionality)(_In_ IModelObject* contextObject, _Out_ ULONG64* dimensionality) PURE;
STDMETHOD(GetAt)(_In_ IModelObject* contextObject, _In_ ULONG64 indexerCount, _In_reads_(indexerCount) IModelObject** indexers, _COM_Errorptr_ IModelObject** object, _COM_Outptr_opt_result_maybenull_ IKeyStore** metadata) PURE;
STDMETHOD(SetAt)(_In_ IModelObject* contextObject, _In_ ULONG64 indexerCount, _In_reads_(indexerCount) IModelObject** indexers, _In_ IModelObject *value) PURE;
}
Alább látható egy példa az indexelő használatára (és az iterátorral való kölcsönhatására). Ez a példa egy indexelhető tároló tartalmát iterálja, és az indexelővel visszatér az imént visszaadott értékhez. Bár ez a művelet funkcionálisan haszontalan, mint írva, bemutatja, hogyan működnek ezek a felületek. Vegye figyelembe, hogy az alábbi példa nem foglalkozik a memóriafoglalási hibával. Azt feltételezi, hogy egy új dobás (amely a kód meglétének környezetétől függően rossz feltételezés lehet – az adatmodell COM-metódusai nem tartalmazhatnak C++ kivételeket):
ComPtr<IModelObject> spObject;
//
// Assume we have gotten some object in spObject that is iterable (e.g.: an object which represents a std::vector<SOMESTRUCT>)
//
ComPtr<IIterableConcept> spIterable;
ComPtr<IIndexableConcept> spIndexer;
if (SUCCEEDED(spObject->GetConcept(__uuidof(IIterableConcept), &spIterable, nullptr)) &&
SUCCEEDED(spObject->GetConcept(__uuidof(IIndexableConcept), &spIndexable, nullptr)))
{
ComPtr<IModelIterator> spIterator;
//
// Determine how many dimensions the default indexer is and allocate the requisite buffer.
//
ULONG64 dimensions;
if (SUCCEEDED(spIterable->GetDefaultIndexDimensionality(spObject.Get(), &dimensions)) && dimensions > 0 &&
SUCCEEDED(spIterable->GetIterator(spObject.Get(), &spIterator)))
{
std::unique_ptr<ComPtr<IModelObject>[]> spIndexers(new ComPtr<IModelObject>[dimensions]);
//
// We have an iterator. Error codes have semantic meaning here. E_BOUNDS indicates the end of iteration. E_ABORT indicates that
// the debugger host or application is trying to abort whatever operation is occurring. Anything else indicates
// some other error (e.g.: memory read failure) where the iterator MIGHT still produce values.
//
for(;;)
{
ComPtr<IModelObject> spContainedStruct;
ComPtr<IKeyStore> spContainedMetadata;
//
// When we fetch the value from the iterator, it will pass back the default indices.
//
HRESULT hr = spIterable->GetNext(&spContainedStruct, dimensions, reinterpret_cast<IModelObject **>(spIndexers.get()), &spContainedMetadata);
if (hr == E_BOUNDS || hr == E_ABORT)
{
break;
}
if (FAILED(hr))
{
//
// Decide how to deal with failure to fetch an element. Note that spContainedStruct *MAY* contain an error object
// which has detailed information about why the failure occurred (e.g.: failure to read memory at address X).
//
}
//
// Use the indexer to get back to the same value. We already have them, so there isn't much functional point to this. It simply
// highlights the interplay between iterator and indexer.
//
ComPtr<IModelObject> spIndexedStruct;
ComPtr<IKeyStore> spIndexedMetadata;
if (SUCCEEDED(spIndexer->GetAt(spObject.Get(), dimensions, reinterpret_cast<IModelObject **>(spIndexers.get()), &spIndexedStruct, &spIndexedMetadata)))
{
//
// spContainedStruct and spIndexedStruct refer to the same object. They may not have interface equality.
// spContainedMetadata and spIndexedMetadata refer to the same metadata store with the same contents. They may not have interface equality.
//
}
}
}
}
A GetDimensionality metódus az objektum indexelt dimenzióinak számát adja vissza. Vegye figyelembe, hogy ha az objektum iterábilis és indexelhető is, a GetDefaultIndexDimensionality implementációjának meg kell egyeznie a GetDimensionality implementációjával abban, hogy az indexelő hány dimenzióval rendelkezik.
A GetAt metódus lekéri az értéket egy adott N-dimenziós indexben az indexelt objektumon belülről. Támogatni kell az N dimenziók indexelőit, ahol az N a GetDimensionality függvénytől visszaadott érték. Vegye figyelembe, hogy egy objektum különböző tartományokban különböző típusok szerint indexelhető lehet (például a sorszámokon és sztringeken keresztül is indexelhető). Ha az index kívül esik a tartományon (vagy nem érhető el), a metódus hibát ad vissza; ilyen esetekben azonban előfordulhat, hogy a kimeneti objektum hibaobjektumra van állítva.
A SetAt metódus megkísérli beállítani az értéket egy adott N-dimenziós indexben az indexelt objektumon belülről. Támogatni kell az N dimenziók indexelőit, ahol az N a GetDimensionality függvénytől visszaadott érték. Vegye figyelembe, hogy egy objektum különböző tartományokban különböző típusok szerint indexelhető lehet (például a sorszámokon és sztringeken keresztül is indexelhető). Egyes indexelők írásvédettek. Ilyen esetekben a SetAt metódus bármely hívására E_NOTIMPL lesz visszaadva.
Az előnyben részesített futtatókörnyezettípus fogalma: IPreferredRuntimeTypeConcept
Egy hibakereső gazdagép lekérdezhető annak érdekében, hogy megpróbálja meghatározni egy objektum valódi futásidejű típusát a szimbolikus információk közül előkerülő statikus típus alapján. Ez az átalakítás teljesen pontos információkon alapulhat (például: C++ RTTI), vagy olyan erős heurisztikai adatokon alapulhat, mint például az objektumon belüli virtuális függvénytáblák alakja. Egyes objektumok azonban nem konvertálhatók statikusról futtatókörnyezet-típusra, mert nem férnek bele a hibakeresési gazdagép heurisztikus funkcióiba (például nem rendelkeznek RTTI- vagy virtuális függvénytáblákkal). Ilyen esetekben egy objektum adatmodellje dönthet úgy, hogy felülbírálja az alapértelmezett viselkedést, és deklarálja, hogy többet tud egy objektum "futtatókörnyezeti típusáról", mint amennyit a hibakereső gazdagép képes megérteni. Ez az IPreferredRuntimeTypeConcept felület előnyben részesített futtatókörnyezet-típuskoncepciója és támogatása révén történik.
Az IPreferredRuntimeTypeConcept felület a következőképpen van deklarálva:
DECLARE_INTERFACE_(IPreferredRuntimeTypeConcept, IUnknown)
{
STDMETHOD(CastToPreferredRuntimeType)(_In_ IModelObject* contextObject, _COM_Errorptr_ IModelObject** object) PURE;
}
A CastToPreferredRuntimeType metódust akkor hívjuk meg, ha egy ügyfél statikus típusú példányból az adott példány futtatókörnyezettípusára szeretne konvertálni. Ha a szóban forgó objektum támogatja (az egyik csatolt szülőmodellen keresztül) az előnyben részesített futtatókörnyezettípus-koncepciót, a rendszer meghívja ezt a metódust az átalakítás végrehajtásához. Ez a metódus visszaadhatja az eredeti objektumot (nincs átalakítás vagy nem elemezhető), visszaadhatja a futtatókörnyezet típusának egy új példányát, nem szemantikai okokból meghiúsult (például: nincs memóriája), vagy E_NOT_SET ad vissza. A E_NOT_SET hibakód egy nagyon speciális hibakód, amely azt jelzi az adatmodellnek, hogy az implementáció nem szeretné felülbírálni az alapértelmezett viselkedést, és hogy az adatmodellnek vissza kell esnie a hibakereső gazdagép által végzett bármilyen elemzésre (például: RTTI-elemzés, a virtuális függvénytáblák alakjának vizsgálata, stb...)
A dinamikus szolgáltató fogalmai: IDynamicKeyProviderConcept és IDynamicConceptProviderConcept
Bár maga az adatmodell kezeli az objektumok kulcs- és koncepciókezelését, vannak olyan esetek, amikor ez a fogalom nem ideális. Különösen, ha egy ügyfél hidat szeretne létrehozni az adatmodell és valami más között, amely valóban dinamikus (például: JavaScript), értékes lehet átvenni a kulcs- és koncepciókezelést az adatmodell implementációjától. Mivel az alapvető adatmodell az IModelObject egyetlen és egyetlen implementációja, ez ehelyett két fogalom kombinációján keresztül történik: a dinamikus kulcsszolgáltató koncepciója és a dinamikus koncepció szolgáltatói koncepciója. Bár jellemzően mindkettőt vagy egyiket sem implementálják, nincs szükség ilyenre.
Ha mindkettő implementálva van, a dinamikus kulcsszolgáltató koncepcióját hozzá kell adni a dinamikus koncepció szolgáltatói koncepciója előtt. Mindkét fogalom különleges. Hatékonyan állítanak át egy kapcsolót az objektumon, amely a "statikusan kezelt" értékről a "dinamikusan kezelt" értékre módosítja azt. Ezek a fogalmak csak akkor állíthatók be, ha nincsenek az objektum adatmodellje által kezelt kulcsok/fogalmak. Miután hozzáadta ezeket a fogalmakat egy objektumhoz, a művelet visszavonhatatlan.
További szemantikai különbség van az IModelObject bővíthetősége között, amely egy dinamikus fogalomszolgáltató, és amely nem. Ezek a fogalmak lehetővé teszik az ügyfelek számára, hogy hidakat hozzanak létre az adatmodell és a dinamikus nyelvi rendszerek, például a JavaScript között. Az adatmodell olyan bővíthetőségi koncepcióval rendelkezik, amely alapvetően különbözik a JavaScripthez hasonló rendszerektől, mivel a szülőmodellek faja nem lineáris lánc, mint a JavaScript-prototípuslánc. Az ilyen rendszerekkel való jobb kapcsolat érdekében egy dinamikus koncepciószolgáltatóként működő IModelObject egyetlen adatmodell-szülővel rendelkezik. Az egyetlen adatmodell szülője egy normál IModelObject, amely tetszőleges számú szülőmodellt tartalmazhat az adatmodellhez megszokott módon. A rendszer automatikusan átirányítja a dinamikus fogalomszolgáltatóhoz a szülők hozzáadására vagy eltávolítására irányuló kéréseket az egyetlen szülőre. Kívülálló szempontjából úgy tűnik, mintha a dinamikus koncepciószolgáltató a szülőmodellek normál fastílusú láncával rendelkezik. A dinamikus koncepciószolgáltatói koncepció implementátora az egyetlen objektum (az alapadatmodellen kívül), amely ismeri a köztes egyetlen szülőt. Az egyetlen szülő összekapcsolható a dinamikus nyelvi rendszerrel, hogy hidat biztosítson (például: a JavaScript prototípusláncba helyezve).
A dinamikus kulcsszolgáltató fogalma a következőképpen van definiálva:
DECLARE_INTERFACE_(IDynamicKeyProviderConcept, IUnknown)
{
STDMETHOD(GetKey)(_In_ IModelObject *contextObject, _In_ PCWSTR key, _COM_Outptr_opt_result_maybenull_ IModelObject** keyValue, _COM_Outptr_opt_result_maybenull_ IKeyStore** metadata, _Out_opt_ bool *hasKey) PURE;
STDMETHOD(SetKey)(_In_ IModelObject *contextObject, _In_ PCWSTR key, _In_ IModelObject *keyValue, _In_ IKeyStore *metadata) PURE;
STDMETHOD(EnumerateKeys)(_In_ IModelObject *contextObject, _COM_Outptr_ IKeyEnumerator **ppEnumerator) PURE;
}
A dinamikus fogalomszolgáltató koncepciója a következőképpen van definiálva:
DECLARE_INTERFACE_(IDynamicConceptProviderConcept, IUnknown)
{
STDMETHOD(GetConcept)(_In_ IModelObject *contextObject, _In_ REFIID conceptId, _COM_Outptr_result_maybenull_ IUnknown **conceptInterface, _COM_Outptr_opt_result_maybenull_ IKeyStore **conceptMetadata, _Out_ bool *hasConcept) PURE;
STDMETHOD(SetConcept)(_In_ IModelObject *contextObject, _In_ REFIID conceptId, _In_ IUnknown *conceptInterface, _In_opt_ IKeyStore *conceptMetadata) PURE;
STDMETHOD(NotifyParent)(_In_ IModelObject *parentModel) PURE;
STDMETHOD(NotifyParentChange)(_In_ IModelObject *parentModel) PURE;
STDMETHOD(NotifyDestruct)() PURE;
}
IDynamicKeyProviderConcept KulcsLekérése
A dinamikus kulcsszolgáltató GetKey metódusa nagyrészt az IModelObject GetKey metódusának felülbírálása. A dinamikus kulcsszolgáltató várhatóan visszaadja a kulcs értékét és a kulcshoz társított metaadatokat. Abban az esetben, ha a kulcs nem található (de más hiba nem történik), a szolgáltatónak hamis értéket kell visszaadnia a hasKey paraméterben, és az S_OK-kal kell sikerrel járnia. Ennek a hívásnak a sikertelensége a kulcs lekérésének meghiúsulását jelenti, és kifejezetten leállítja a kulcs keresését a szülőmodell láncolatán keresztül. Ha hamis értéket ad vissza a hasKey-ben, és a siker folytatódik, a kulcs keresése folytatódik. Vegye figyelembe, hogy a GetKey teljesen legális, ha kulcsként egy dobozolt tulajdonság-hozzáférőt ad vissza. Ez szemantikailag megegyezik az IModelObject GetKey metódusával, amely tulajdonság-tartozékot ad vissza.
IDynamicKeyProviderConcept SetKey
A dinamikus kulcsszolgáltató SetKey metódusa tulajdonképpen az IModelObject SetKey metódusának felülbírálása. Ez beállít egy kulcsot a dinamikus szolgáltatóban. Ez tulajdonképpen egy új tulajdonság létrehozása a szolgáltatón. Vegye figyelembe, hogy egy olyan szolgáltatónak, amely nem támogatja az olyan fogalmakat, mint a expando tulajdonságok létrehozása, itt E_NOTIMPL kell visszaadnia.
IDynamicKeyProviderConcept EnumerateKeys
A dinamikus kulcsszolgáltató EnumerateKeys metódusa valójában az IModelObject EnumerateKeys metódusának felülbírálása. Ez felsorolja a dinamikus szolgáltató összes kulcsát. A visszaadott enumerátor számos korlátozással rendelkezik, amelyeket a megvalósításnak tiszteletben kell tartania:
- Az EnumerateKeys hívásaként kell viselkednie, nem pedig az EnumerateKeyValues vagy az EnumerateKeyReferences metódusnak. Vissza kell adnia azokat a kulcsértékeket, amelyek nem oldanak meg semmilyen mögöttes tulajdonhozzáférést (amennyiben létezik ilyen fogalom a szolgáltatóban).
- Egyetlen dinamikus kulcsszolgáltató szempontjából illegális több azonos nevű kulcs számbavétele, amelyek fizikailag különálló kulcsok. Ez a szülőmodell-láncon keresztül csatolt különböző szolgáltatókon fordulhat elő, de egyetlen szolgáltató szempontjából nem.
IDynamicConceptProviderConcept GetConcept
A dinamikus fogalomszolgáltató GetConcept metódusa tulajdonképpen az IModelObject GetConcept metódusának felülbírálása. A dinamikus koncepciószolgáltatónak vissza kell adnia egy felületet a lekérdezett fogalomhoz, ha létezik, valamint az adott fogalomhoz társított metaadatokat is. Ha a fogalom nem létezik a szolgáltatón, akkor azt a hasConcept argumentumban visszaadott hamis értéken és egy sikeres visszatérésen keresztül kell jelezni. Ennek a módszernek a sikertelensége a koncepció megragadásának kudarcát jelenti, és kifejezetten leállítja a koncepció keresését. Ha a hasConcept hamis értéket és sikeres kódot ad vissza, a koncepció keresése a szülőmodell fáján keresztül folytatódik.
IDynamicConceptProviderConcept SetConcept
A dinamikus koncepciószolgáltató SetConcept metódusa gyakorlatilag a SetConcept metódus felülbírálása az IModelObjecten. A dinamikus szolgáltató hozzárendeli a koncepciót. Továbbá, ez az objektumot iterálhatóvá, indexelhetővé, és szöveggé alakíthatóvá teheti, stb. Vegye figyelembe, hogy egy olyan szolgáltatónak, amely nem teszi lehetővé a fogalmak létrehozását, itt E_NOPTIMPL értéket kell visszaadnia.
IDynamicConceptProviderConcept NotifyParent
A dinamikus koncepciószolgáltató értesítési kérését az alapadatmodell használja az egyetlen szülőmodell dinamikus szolgáltatójának tájékoztatására, amely azért jött létre, hogy lehetővé tegye az adatmodell "több szülőmodell" paradigmajának dinamikusabb nyelvekre való áthidalását. Az egyszülős modell bármilyen manipulálása további értesítéseket fog eredményezni a dinamikus szolgáltatónak. Vegye figyelembe, hogy ezt a visszahívást azonnal végrehajtjuk, mihelyt hozzárendelésre kerül a dinamikus fogalomszolgáltató fogalma.
IDynamicConceptProviderConcept NotifyParentChange
A dinamikus fogalomszolgáltató NotifyParent metódusa az alapvető adatmodell visszahívása, amikor az objektum egyetlen szülőmodelljének statikus kezelése történik. Minden hozzáadott szülőmodell esetében ezt a metódust először akkor hívja meg a rendszer, amikor az említett szülőmodellt hozzáadják, majd másodszor, ha/amikor az említett szülőmodellt eltávolítják.
IDynamicConceptProviderConcept NotifyDestruct
A NotifyDestruct metódus egy visszahívásnak minősül a dinamikus fogalomszolgáltató esetében, amelyet az alapvető adatmodell az objektum megsemmisítésének kezdetén hajt végre. További tisztítási lehetőségeket biztosít az ügyfelek számára, amelyek megkövetelik.
--
Lásd még:
Ez a témakör egy olyan sorozat része, amely leírja a C++-ból elérhető felületeket, a C++ alapú hibakeresőbővítmények készítésének módját, valamint azt, hogy miként használhat más adatmodell-szerkezeteket (pl. JavaScript vagy NatVis) egy C++ adatmodell-bővítményből.
Hibakereső adatmodell C++ áttekintése
Hibakereső adatmodell C++ interfészei
Hibakereső adatmodell C++ objektumai