Sorry for not being clear enough. The malloc() and free() example has been my way to tell you that you just need to document what users of your lib have to take care. You can't take care of everything where a user of your lib may fail. But you can contract what your lib does and what the user is responsible to do.
I'm not trying to take care of everything, I'm simply trying to prevent predictable scenarios that ARE possible to catch, just because something is difficult to do does not mean it isn't worth doing, innovation hinges on that fact, additionally I don't think I'm re-inventing the wheel here, I'm sure someone else ran into this problem before too, perhaps the devs of pthreads ran into that very problem themselves and have their own solution under the hoodOriginally Posted by aGerman
Why bother supporting such an old version of the C standard? Since no existing code will be using your library (in other words, only new code will use your library), I fail to see the point in supporting C89. Even something less old like C99 would be better, and that's 24 years old at this point. And C11 is already 12 years old.
Do you really expect users of your library to be stuck with '80s/'90s compilers? Are you planning to support obsolete platforms like PalmOS?
Because like the devs of lua I like my code to be compilable under any standards complaint compiler, one of the benefits is that my code is happy with both c & c++ compilers whereas code that requires later standards sometimes has the issue of not compiling with a c++ compiler, that and it's more interesting to support old standards then it is to force newer standards, also tends to force you to really understand what you're doing with your code.
Sure, but keep in mind that Lua started development in 1993, when the only C standard that existed was C89, so any later standard wasn't even an option.
But why would you need to compile C code (especially something like a library) with a C++ compiler? If you want the library to support both C and C++, compile it with the correct compiler (i.e., a C compiler) and make the header files usable in both C and C++ (hint: use extern "C" when a header is used in C++, i.e., when the __cplusplus preprocessor macro is defined). You can even define macros in a common header to simplify this:
And then put CPP_START at the top and CPP_END at the bottom of each header file. I do things like this often and it works fairly painlessly.Code:#ifdef __cplusplus # define CPP_START extern "C" { # define CPP_END } #else # define CPP_START # define CPP_END #endif
The reason I want it to compile under c++ also is because I cannot garuntee that some dev or group or company somewhere will feel like compiling it as c++ instead and just using it in their c++ code directly, unlikely I agree but one never knows, and also I know about the extern "C", that was one of the 1st things I wrapped in my headers using PAW_OPEN_C_API/PAW_SHUT_C_API & PAW_OPEN_CPP_API/PAW_SHUT_CPP_API
You can easily guarantee that people won't compile it as C++ if it doesn't compile as C++.
If I don't need the constraint then why should I put it in there when the only thing it does is make development easier, if the same problem can be solved without the constraint then it is poor programming to do it with the constraintYou can easily guarantee that people won't compile it as C++ if it doesn't compile as C++.
