Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualHodgman

Posted 13 December 2012 - 03:53 AM

One of the few major reasons that I've committed to C is the lack of name mangling, which means I can link code compiled with different compilers. I know you can extern "C" in C++, and achieve the same effect, but if I implement all of the logic in C++, there's a limit to what I can expose with a C interface.

It's surprisingly common for C++ code bases to provide a C interface or "wrapper". Even as a C++ developer, it's sometimes really nice to find that some library has a well thought out C API, so that knowledge is still handy Posted Image

Another is the lack of any realloc() like function. Perhaps at some point, I can override new with my custom allocator, which could be used to implement realloc().

If you want to manage a resizable block of memory in C++, the standard solution is to use std::vector, which does the right thing™ by the C++ class model, calling constructors/destructors on each of the objects within the block as required.
However, even though C++ gives you the option of having "higher level" classes, with operators and constructors, etc... plain old data (POD) types are still common/useful in C++ code, just like in C code. So, if you have a situation where the simplest solution is using a POD struct and realloc, it's fine to do so.

requiring a C++ runtime feels as if it would add bloat to the basic requirements

Some compilers will (by default) require your users to install a C++ runtime, but you should also have the option of statically linking the parts of the runtime that you actually use into your binaries too.

My basic question is at what point do I give up portability, distributivity, and compatibility for ease of use, power, and flexibility?

As above:
* If you're writing a library and want to distribute a binary version that's as widely usable as possible, then a C interface over your C++ code might still be useful.
* You can usually statically link to the runtime to simplify distribution of applications.
* C++98/C++03 is very widely supported now (except for a few dark corners of the spec which nearly every compiler failed to implement and nobody uses as a result), nearly as much as C89! C++11 compilers are still being developed, so C++11 code is definitely less portable than C.

#1Hodgman

Posted 13 December 2012 - 03:51 AM

One of the few major reasons that I've committed to C is the lack of name mangling, which means I can link code compiled with different compilers. I know you can extern "C" in C++, and achieve the same effect, but if I implement all of the logic in C++, there's a limit to what I can expose with a C interface.

It's surprisingly common for C++ code bases to provide a C interface or "wrapper". Even as a C++ developer, it's sometimes really nice to find that some library has a well thought out C API, so that knowledge is still handy Posted Image

Another is the lack of any realloc() like function. Perhaps at some point, I can override new with my custom allocator, which could be used to implement realloc().

If you want to manage a resizable block of memory in C++, the standard solution is to use std::vector, which does the right thing™ by the C++ class model, calling constructors/destructors on each of the objects within the block as required.

However, even though C++ gives you the option of having "higher level" classes, with operators and constructors, etc... plain old data (POD) types are still common/useful in C++ code, just like in C code. So, if you have a situation where the simplest solution is using a POD struct and realloc, it's fine to do so.

requiring a C++ runtime feels as if it would add bloat to the basic requirements

Some compilers will (by default) require your users to install a C++ runtime, but you should also have the option of statically linking the parts of the runtime that you actually use into your binaries too.

My basic question is at what point do I give up portability, distributivity, and compatibility for ease of use, power, and flexibility?

As above:
* If you're writing a library and want to distribute a binary that's as widely usable as possible, then a C interface over your C++ code still be useful.
* You can statically link to the runtime to simplify distribution of applications.
* C++98/C++03 is very widely supported now (except for a few dark corners of the spec which nearly every compiler failed to implement and nobody uses as a result), nearly as much as C89! C++11 compilers are still being developed, so C++11 code is definitely less portable than C.

PARTNERS