Показываю как надо, чтоб не жевать сопли с обработкой ошибок по всему коду
template <class T>
class DirectXPrt // Ценноссть только в деструкторе
{
public:
typedef T* Pointer;

virtual ~DirextX() { if (ptr) SAFE_RELEASE(ptr); }

// This garbage only for backward compatibility

Pointer operator->() { assert(ptr); return ptr; }
Pointer getPtr() { assert(ptr); return ptr; }
operator T*() { assert(ptr); return ptr; }
protected:
DirectXPtr() { ptr = 0; }
DirectXPtr(Pointer* p) { ptr = p; }
Pointer* ptr;
};

class DirectXFilePtr : public DirectXPtr<LPDIRECTXFILE>
{
public:
DirectXFilePtr();

DirectXFileEnumPtr makeFileEnum(LPSTR s);
void registerTemplates(LPVOID, size_t); // из исходника не ясен 2 параметр
};

class DirectXFileEnumPtr : public DirectXPtr<LPDIRECTXFILEENUMOBJECT>
{
public:
typedef DirectXPtr<LPDIRECTXFILEENUMOBJECT> Parent;
DirectXFileDataPtr getNext();
private:
friend class DirectXFilePtr;
DirectXFileEnum(Pointer p) : parent(p) {}
};

class DirectXFileDataPtr : public DirectXPtr<LPDIRECTXFILEDATA>
{
public:
typedef DirectXPtr<LPDIRECTXFILEDATA> Parent;
GUID getType() const { if (!id) load(); return *id; }
const std::string& getString() const { if (!id) load(); return name; }
private:
friend class DirectXFileEnumPtr;
DirectXFileDataPtr(Pointer p) : parent(p), id(0), name("") {}

void load();

const GUID* id;
std::string nane;
}

// Классы исключений сами допишите, не маленькие
class DirectXFatalException : public std::exception
{
};

class DirectXEnumException : public std::exception
{
};

class DirectXDataException : public std::exeption {};

//------------------------------------------------------------------------------------------
DirectXFilePtr::DirectXFilePtr()
{
if (FAILED(DirectXFileCreate(&ptr))
throw DirectXFatalException();
}

DirectXFileEnumPtr DirectXFilePtr::makeFileEnum(LPSTR s)
{
LPDIRECTXFILEENUMOBJECT p;
if ( FAILED(this->CreateEnumObject((LPVOID)s, DXFILELOAD_FROMFILE, &eptr.get())) )
throw DirectXEnumException();
return DirectXFileEnumPtr(p);
}

void DirectXFilePtr::registerTemplates(LPVOID p, size_t sz)
{
if(FAILED(this->RegisterTemplates(p. sz)))
throw DirectXFatalException();
}

DirectXFileDataPtr DirectXFileEnumPtr::getNext()
{
LPDIRECTXFILEDATA p;
if( FAILED(this->GetNextDataObject(&p)) )
throw DirectXEnumException() ;
return DirectXFileDataPtr(p);
}

void DirectXFileDataPtr::load()
{
if ( FAILED(fileData->GetType(&id)))
throw DirectXDataException();
DWORD size;
if ( FAILED(lpDXFileData->GetName(0, &dwNameSize)) )
throw DirectXDataException();
char buf[128];
if ( FAILED(lpDXFileData->GetName(buf, &size)))
throw DirectXDataException()
name = buf;
}
//------------------------------------------------------------------------------------------
// Зато какая красота в прикладном коде

void LoadLevelFromX(LPCSTR lpszXFile)
{
// Ну это не мое
char szbuf[128];
char szbuf2[128];
ExtractFileName(szbuf2, lpszXFile);
sprintf(szbuf, "%s%d", szbuf2, rand());//GetTickCount());

// А это уже мое, такое даже секретарша поймет
DirectXFilePtr fileApi;
fileApi.registerTemplates((LPVOID)D3DRM_XTEMPLATES, D3DRM_XTEMPLATE_BYTES));
DirectXFileEnumPtr fileEnum = fileApi.makeFileEnum(lpszFile);

try
{
while(true)
{
DirectXFileDataPtr fileData = fileEnum.getNext();
if ( fileData.getType() == TTD__D3DMRFrame && )
{
if (fileData.getName() == "SceneRoot")
{
_D("SceneRoot found\n");
GameLevel_LoadLevel_RootLoop(lpDXFileData);
}
}
else
_D ("Not TID_D3DRMFRAME\n");
}
}
catch ( DirectXEnumException e)
{
;
}
}
// А это не мое
//--------
// Если молния в лоб угодит,
// Значит просто подставлен лоб,
// Или волосы действуют словно магнит,
// Или тело похоже на столб...

Эта краткость обманчмва. Когда надо будет написать ну одну такую функцию обертка сыграет свою роль

daevaorn ErV blindedКогда надо будет написать ну одну такую функцию обертка сыграет свою роль
Когда будет использоваться 50 разных интерфейсов, написание обертки для каждого замедлит работу... (у вас в примере ряд функции имеют надстройки над стандартными функциями)
Опять же, это ИМХО...
а почему нельзя написать обобщенную обертку для схожих интерфейсов?
Наверное можно, я же не изучал эту библиотеку, да и изучать никакого желания. Все знания извлечены из приведенного автормо куска кода. Потом библиотека написана несолько в ином стиле. хотя бы одно то что производящие методы возвращают код ошибки а указатель на созданный объект записывается в переменную переданную по адресу, не дает возможности безопасно ее обернуть.
Но игра стоит свеч, ежели посмотреть на "клиентский код" то можно заметить что там вообще указателей нет. Нет места для потенциальной ошибки.

White Owl blindedПоказываю как надо, чтоб не жевать сопли с обработкой ошибок по всему кодуВот за такой код я и не люблю С++. В примере ErV четко видны блок инициализации, блок работы и блок деструктор. А в этом наборе темплейтов и классов найти что-либо даже с десятого взгляда не представляется возможным. Это тот самый стиль программирования "лапша" за который ругают оператор goto. Код в котором может разобраться только автор и только в течении ближайшей недели после написания.

Ну кому же чужой код-то нравится, это понятно. А вот что касается лапши - ну не согласен, категорически, каждый класс имеет свою отвественностьи все ясно и понятно, есть файл с объектами, есть перечисление по нему, элемет данных. У каждого класса свой конструктор и деструктор... И вообще это все должно быть разнесено по разным файлам и даже библиотекам...
И потом на вкус и цвет ... У меня вообще один знакомый есть у него подход оценка качества ПО совсем простая - работает и ладно.

White Owl
Добавляем в него исключения и уже сам черт ногу сломит разбираясь как и куда там передается управление, что за чем вызывается.
Священая война против goto началась с утверждения что goto перекидывает управление далеко-далеко по коду. Исключения делают тоже самое, но не по линейному коду а по стеку вызовов.

Проблема есть, но совсем не в этой области. Как правило код писанный для себя очень плохо задукоментирован, и никогда не знаешь точно какого исключения ждать.

White Owl
daevaornа почему нельзя написать обобщенную обертку для схожих интерфейсов?Можно. Проблема только в том, что это очень сложно.
Сложно сделать удобную обертку для чего бы то ни было. Чтобы суметь ее сделать, надо на уровне эксперта разбираться в том для чего делается обертка, а в этом случае обертка уже обычно не нужна. А если ты не эксперт - ты сделашь вместо обертки уродца годного только для сиюминутной задачи. Потащишь этого уродца во второй проект - чуть-чуть облагородишь его, но изначальное уродство заложеное не знанием предмета будет оставаться очень-очень долго. С течением лет это уродство станет почти не заметным, но будет оставаться. В любом случае, чтобы сделать хорошую обертку нужно несколько лет.
Не, не несколько лет. Чтобы первую версию написать месяц, ну и полгодика в эксплуатации вытащат наруже большую часть недостатков. Тут вопрос такой стоит ли овчинка выделки? Если сделать и забыть, то по-видимому нет. А вот есжели придется сталкиваться с подобными задачами достаточно часто или еще того хуже придется сопровождать один проект несколько лет, тады ой.
А что касается уродства сего упражнения, дык я энтой библиотеки в глаза не видел, все наваял исключительно глядя в представленный пример, да и времени то потратил - пару часов, в течении которых еще и поужинать успел.

Мы несколько отклонились от темы. Вообще-то разговор шел об исключениях. И мне кажется что при правильном их использовании код значительно упрощается. Во всяком случам получившаяся LoadLevelFromХ выглядит значительно менее устрашающе чем исходный вариант, я не говорю об обертке.
А что касается библиотеки DirectX я с ней не пересекаюсь, ибо живу на Unix'e.