Redefining S_OK, S_FALSE, SUCCEEDED, and FAILED is not very friendly

Question

Could more FileGDB API-specific names be used instead?

Martin

__11 · Answer

The existing definition (in API 1.3) is a problem, when building with Visual Studio 2010, because if I include winerror.h after FileGDBAP.h I get a macro redefinition warning. In general, I should not have to worry about what order I include the headers. This is especially so when there are multiple headers. My code is not at simple as #include #include "FileGDBAPI.h" It's actually:// in main.cpp ... #include "FileGDBAPI.h" #include "AddFile.h" // in AddFile.h ... #include "RunParameters.h" // in RunParameters.h ... #include "Geo.h" // in Geo.h ... #include // this includes winerror.h, which causes the warning The solution is to #include AddFile.h before FileGDBAPI.h in main.cpp, but I shouldn't have to search through that many layers of header files (each of which has only the #inclusions it needs) to find the problem. Regardless of the complexity of my own code and file structure, I should not have to worry about the order of inclusion of your and Microsoft's header files.

VinceAngelo · Answer

Have you tried using the Beta-3 release?  These macros are all defined appropriately in FileGDBCore.h
(which is included by FileGDBAPI.h).
 
- V

MartinDaly · Answer

I am not sure that I understand the concern.  Can you elaborate on why you think this is a problem, and what you would propose instead?

The way these things have been redefined appears to be totally harmless.  The definitions are 100% consistent and functionally equivalent with the normal definitions in Windows.  It was necessary to do this in order to remove Windows dependencies.

-David

If they are "100% consistent and functionally" equivalent then why bother #undef-ing them first? If they are not there and you want them then check for their existence and only #define them if necessary. That would be 100% friendlier. Any file that #include-s them has messed up Intellisense that refers to your fgdbError.

Finally, they are 100% unused in the SDK-supplied headers; they are only used in the samples. If SDK client code needs them, then SDK client code should be responsible for ensuring their existence.

Martin