Any ideas: using zlib in C++ SDK?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/03/2003 at 22:54, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   8.012 
Platform:   Windows  ;   
Language(s) :     C++  ;

---------
Just in case zlib makes no sense, it is a standard compression/decompression used by almost everything (gzip, zip, png, etc).  It is open source and can be checked out at http://www.gzip.org/zlib/.
Sounds simple enough.  It is not.  C4D headers conflict with zlib headers (zlib.h and zconf.h) in a very nasty way - all the way down to MSVC++ Windows headers.  With c4d.h included before zlib.h, the compiler dies on errors.  With zlib.h included after c4d.h, it's only 3 warnings, but 1 error (redefinition of basic type WORD).  I cannot get around this.  Cannot redefine it and cannot fix your SDK nor zlib's static lib (without rewriting it, which is not on my menu this century).
This means that no alternatives are available to me: neither the source code, the dll, nor the static lib.  All require the same headers.
Any brave souls like to tackle this one?
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 02:55, xxxxxxxx wrote:

This is just a standard include problem, zlib is possible to use (I've used it!), two solutions are to use #define to remove name conflicts, or to NOT include the zlib headers in any file using the c4d headers and create a source file with your own functions that wrap the zlib functions so you never need to include the zlib header (the solution I used since I only wanted basic zip/unzip of data). I created a file zip.cpp this the basic outline of it:

    
    
      
    #include <stdio.h>
    
    
    
    
    #ifdef __MAC  
    #include "zlib.h"  
    #include <string.h>  
    #define LONG long  
    #else  
    #include "zip/zlib.h"  
    #endif
    
    
    
    
    int zip_filecompress(char *infile, void *&buf, LONG &dlen, LONG &slen)  
    {  
    ...  
    }
    
    
    
    
    int zip_fileuncompress(char *outfile, void *&sbuf, LONG dlen, LONG slen)  
    {  
     ...}  
    

then when I want to use it just declare the functions:

    
    
      
    int zip_filecompress(char *infile, void *&buf, LONG &dlen, LONG &slen);  
    int zip_fileuncompress(char *outfile, void *&sbuf, LONG dlen, LONG slen);  
    

and let the linker to the rest
This is from S&H, so I know it works
There was a thread about windows headers on plugincafe a while ago, sorry, can't remember when/subject, maybe try a search.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 07:51, xxxxxxxx wrote:

Thanks, David.  I don't normally use third party libs (and SDK's for that matter), so it's not a standard problem for me.
#define can't be used since both zlib and C4D use WORD (alot) and it's a typedef.  So, it's like trying to remove 'int'.  I will have to go the other route by putting my calls to zlib into a different source that doesn't include c4d.h.
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 08:57, xxxxxxxx wrote:

#define can be used, I've done that too its actually very easy, even to replace something as common as WORD, you just insert it before the include of the c4d headers, something like:

    
    
      
    #define WORD C4DWORD  
    #include "c4d.h"  
    

Then provided you use the same header (or put that code at the top of all your source files), and ensure the windows include was before the c4d one, then it works, but I prefer not doing this, sometimes you forget and something nasty happens the wrapping method is generally safer but a bit more work.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 09:12, xxxxxxxx wrote:

I tried that and it still complained (one way or another).  And it is agreed that nasty things can occur still, which is why even getting a clean compile/link wouldn't satisfy me on the issue .
How do you get the C4D file stuff around this though?  I know that I cannot use any C4D SDK calls, classes, etc. because c4d.h will not be included in my "wrapper" class for zlib.  Do you use stdio calls instead for reading and writing?  I was trying to avoid system calls (as stated), but if it is no harm and required...
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 09:32, xxxxxxxx wrote:

There is no problem using standard C/C++ functions, for example stdio for files, these are just routed to the OS, and so are the C4D functions  what is meant by "system calls" is a platform specific function, unless you are only aiming at one platform, the C4D classes/functions are designed to work on both Windows and Mac with no code changes, careful use of standard C/C++ will also do this, you just have to be more careful and test on both. Also, system calls can mean in certain places (like during rendering) you should not do anything that uses the OS (like file access). If you are using any sort of third party DLL/LIB then that will be using the OS or standard C functions anyway, so it is rare to need to use C4D functions in the wrapper.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 10:53, xxxxxxxx wrote:

I know this, but am not certain about the stability.  For instance, right now, I'm getting an error on compile:
error C2065: 'DC' : undeclared identifier
for all of my original classes (DC is in c4d_tools.h).  Why?  I have created a separate class for zlib (with no references to c4d.h whatsoever) and make only one reference to zlib.h (in that class) and this occurs.  If I remove the zlib lib and class, everything compiles/links perfectly, flawlessly as before.
Again, I know how to program.  I don't know how to get around these conflicts between libs (which is one reason why I moved away from C/C++, and especially 3rd party libs, to Java - no conflicts or they are extremely rare). 
<rant>
You can't tell me that mixing 3rd party libs is not an ongoing, ever-present pain in the ass. It was ten years ago and is obviously still.  This is why I never completed 3D graphics programs for MSDOS some time ago.  All of the 3rd party libs conflicted and, buf of course, when discussing these issues with the lib creators, it's the other guy's fault.  I hate to rant, but the idea here was to move away from programming to 3D CG.  For this plugin effort, I don't mind as much, but if I have to spend six months (my entire spring and summer) indoors trying to make a single function work without resolutions, I remember painfully why I'm moving in the first place.  I despise sitting 10-12-16-20 hours a day in front of a computer trying to trace esoteric errors and fix problems not induced by me (note that - these aren't my errors and, being lazy by nature, I don't intend on fixing them for them).  Don't mind normal errors caused by myself.
This could be a problem with the zlib lib and not the includes. (?)  I'd hate to have to recompile it along with my plugin code.  Do you use the lib or the dll?  Have you recompiled the code for the static lib?  Is there some MSVC setting that needs to be set or unset?  I'm not a mind reader and errors like the one above leave little to fish for (and I don't like fishing either).
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 11:00, xxxxxxxx wrote:

Actually, never mind.  I think that I found the problem (and it's not me).  How swell.  I just updated to 8.100 and the error seems to be a result of this and not the zlib stuff.
Anybody care to explain?
Damnit.  I'm having enough trouble (2 days just trying to get zlib implemented) and don't need more problems introduced.  Fix this now.
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 11:12, xxxxxxxx wrote:

Yes, this is a problem with the update. They have updated the SDK (and failed to mention it, I did read the PDF before installation).  The libs are out of date and cannot be recompiled without errors.  There is no update to the SDK here at the PluginCafe, so I seem to between an impossibility and a discontinuation.  I can no longer develop without a working SDK.
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 13:18, xxxxxxxx wrote:

I can't confirm or deny the API problems (yet), all I know is mine is fine, but I haven't used the installer. I will test/enquire about this issue immediately, can anybody else confirm an API LIB problem? if it is any help, the DC should be defined in ge_vector.h:

    
    
      
    enum _DONTCONSTRUCT{DC};  
    

it is basically 0.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 13:56, xxxxxxxx wrote:

Aaaargghhh!!! No, it is not there, nor is it in ge_math.h or ge_win_math.h. Nor is it in ANY of the source.  Methinks that they split out some stuff and forgot to include the new files that the split it into.
Can you say "8.1001"?
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 14:07, xxxxxxxx wrote:

Oh really!!! I've been told that yes, there is a problem and it is under review to be correct asap! maybe we can upload the libs for you, but you'll need the headers too, so maybe a full SDK upload to plugincafe, best thing you can do for now is grab the 8.012 SDK (if you can), the LIB and headers will be fine to use under 8.100.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 14:30, xxxxxxxx wrote:

I never download anything without keeping a copy for my archives.   So, I already have the original 8.012 SDK available - with line-endings fixed ;P.  So, you think that I can just remove the current stuff (ie: back it up), reinstall the SDK, and get back to work?  I certainly hope so!
A message about success will be forthcoming.
Might I add that all else appears to have updated properly.  I already know about the BLURPS issue.
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 14:53, xxxxxxxx wrote:

The API is independent of C4D really (from compiling plugins pov), so if you rename/remove the new 8.100 API folders and put back your 8.012 ones, you -should- be fine to use the 8.012 API (I'm still using an older API and LIB since I don't like swapping mid-development the compiled plugins will run under 8.100 but you won't get any bug fixes/changes from the new SDK (there are some nice new functions!), but a fixed 8.100 API will be available soon, so then you can update to it. We are sorry for the glitch, guess sometimes errors happen, shame it was at this point, but we're getting it sorted as fast as we can.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 15:31, xxxxxxxx wrote:

No problem there.  Just wish that the update had been mentioned so that preparations could have been made.
And, yes, some nice features.  I like the inclusion of true HDRI support, at least from a user perspective.
Robert

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 12/03/2003 at 16:57, xxxxxxxx wrote:

As a follow up: Success.  Backed up the 8.100 api stuff and replaced with 8.012 api stuff and am back in the bizz.
Thanks,
Robert