Why an object cannot be its own enumerator

Date:March 22, 2004 / year-entry #110
Tags:code
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20040322-00/?p=40143
Comments:    3
Summary:I've seen people using the following cheat when forced to implement an enumerator: class MyClass : public IDataObject, public IEnumFORMATETC, ... { ... HRESULT EnumFormatEtc(DWORD dwDirection, IEnumFORMATETC** ppenumOut) { _dwDirection = dwDirection; Reset(); *ppenumOut = this; AddRef(); return S_OK; } }; Why create a separate enumerator object when you can just be your own enumerator?...

I've seen people using the following cheat when forced to implement an enumerator:

class MyClass :
  public IDataObject, public IEnumFORMATETC, ...
{
  ...
  HRESULT EnumFormatEtc(DWORD dwDirection,
                 IEnumFORMATETC** ppenumOut)
  {
    _dwDirection = dwDirection;
    Reset();
    *ppenumOut = this;
    AddRef();
    return S_OK;
  }
};

Why create a separate enumerator object when you can just be your own enumerator? It's so much easier.

And it's wrong.

Consider what happens if two people try to enumerate your formats at the same time: The two enumerators are really the same enumerator, so operations on one will interfere with the other. For example, consider this odd code fragment (error checking deleted for expository purposes) which looks to see if the data object exposes the same data under multiple aspects:

IDataObject *pdto = <MyClass instance>;

// Obtain two enumerators since we will run
// each one independently.

IEnumFORMATETC* penum1;
IEnumFORMATETC* penum2;
pdto->EnumFormatEtc(DATADIR_GET, &penum1);
pdto->EnumFormatEtc(DATADIR_GET, &penum2);

FORMATETC fe1, fe2;
while (penum1->Next(1, &fe1, NULL) == S_OK) {
  penum2->Reset(); // start a new pass
  while (penum2->Next(1, &fe2, NULL) == S_OK) {
    if (fe1.cfFormat == fe2.cfFormat &&
        cf1.dwAspect != cf2.dwAspect) {
        // found it!
    }
  }
}
penum1->Release();
penum2->Release();

When the code does a penum2->Reset(), this also inadvertently resets the first enumerator. The loop runs through penum2 (which therefore also runs through penum1), and when it's done, the enumerator is left at the end of the list.

Then we loop back and call penum1->Next(), which immediately returns failure since the inner loop ran it to completion.

Result: The loop fails to find anything because the second enumerator corrupted the first.


Comments (3)
  1. Dmitriy Zaslavskiy says:

    Same issue pertains to .NET

  2. Tim Smith says:

    This mistake was made in the original OPC (OLE for Process Control) standard. It didn’t cause too many problem since every client was given their own server instance. However, it made it impossible for the same client to have more than one enumeration. The work around was to create multiple server objects when a client needed multiple enums.

    *sigh*

  3. One word: Whoops :) Guess I’ve got to rewrite that class :)

    Thanks Raymond.

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index