1

Disclaimer: I know purists on either side, C or C++, will not like this. The job needs to get done.

I would like to use as many non-OOP related features of C++ to make my C-like coding (but compiled with a C++ compiler, of course) more enjoyable. The end product should be a C-like library (and an accompanying executable) which is relatively easy to embed in C programs.

What I would terribly need is function overloading, for instance. I guess the client code (written in C) could use libffi or similar to get the mangled named, so the functions can be called.

Other nice features would be default values and perhaps templates.

I wouldn't use any C++ library (only C), no exceptions, no RTTI, and no objects.

  1. What is the complete list of C++ features which are not in C, which I could use under these restrictions, and what are some common libraries and techniques to make it work as painlessly as possible?
  2. What should I pay attention to?

I know about the related question, but as I've said, I don't want any glue code (perhaps with the exception of the mangling part, which the client would have to do if he doesn't use C++), and I wouldn't use any OOP features. I am ready to make compromises.

Community
  • 1
  • 1
Flavius
  • 13,566
  • 13
  • 80
  • 126
  • 2
    I didn't know there was such thing as a C purist anymore. – Aesthete Dec 20 '12 at 09:20
  • @Aesthete There's bunch of them on IRC: #C @ freenode – Flavius Dec 20 '12 at 09:21
  • I don't see any conceptual difference between your question and the related question. The so-called "glue code" is just an `#ifdef __cplusplus extern "C" {` in the files that export functions. – Alex Dec 20 '12 at 09:22
  • @Aesthete depends on what your definition of "purist" is. By the time you get to the latest C standards you've pretty-much sold your soul to the C++ wench anyway. – WhozCraig Dec 20 '12 at 09:22
  • @Alex But can polymorphism be used inside an `extern "C"` block? – Flavius Dec 20 '12 at 09:23
  • Polymorphism is an OOP feature, isn't it? – hate-engine Dec 20 '12 at 09:24
  • 1
    @hate-engine within this discussion, "polymorphic" is restricted to functions. You know, "one function name, different signatures, same purpose". – Flavius Dec 20 '12 at 09:26
  • 2
    @Flavius, what do you mean as "function polymorphism"? Function overloading? It's not supported in C. – hate-engine Dec 20 '12 at 09:28
  • Sounds like it would be neither fish nor fowl. – Peter Wood Dec 20 '12 at 09:29
  • @hate-engine yes. I've fixed my question. I know it's not supported in C. – Flavius Dec 20 '12 at 09:29
  • 5
    I don't understand what the question is, you end up using C++ anyway because you're going to use a C++ compiler? You even explicitly say you want to use templates/overloading, knowing they're not C. If you want to do procedural programming in C++, go ahead, but the only one putting in restrictions is yourself, there is no absolute guideline here. If you want to export a C-library without glue code, bad luck: use C for that. – KillianDS Dec 20 '12 at 09:46
  • 1
    Isn't your question really about how to link a C++ library to a C module? – Kenneth Dec 20 '12 at 09:50
  • @Kenneth yes, but how to write the C++ library such that there's no need for glue code in the C++ library, but only a thin layer in the client code (the "C module"). – Flavius Dec 20 '12 at 09:58
  • @KillianDS I know what I end up doing. I clearly said `C-like`, not `C`. Read my question. – Flavius Dec 20 '12 at 09:59
  • @KillianDS I know there is no formal definition of "C-like", that's why I've clearly described what that means in my question. Read the question, please. – Flavius Dec 20 '12 at 10:03
  • @Flavius See KillianDS' comment. You can't. Best bet would be to compile your C code with a C++ compiler and link it with your lib. – Kenneth Dec 20 '12 at 10:05
  • @Kenneth Not even if I write the C++ code procedural style with function overloading & co, and tell the client that if he wants to call the library from C code, he has to use some sort of `ffi` to get the mangled names and find the pointers to the functions in my C++ library? – Flavius Dec 20 '12 at 10:09
  • @Flavius I believe the FFI that exists between C++ and C is the extern "C" decleration which _disables_ function overloading to make the function callable from C hence defeating your purpose. C++ promises to be 99% compatible with C, so it is a lot safer to program procedurally in C++ with the extra features you like and just be done with it. Even if you could force C to use C++ features it puts all the responsibility for type handling and error checking on your _client_, which is not what you usually want to worry about when using a library. – Kenneth Dec 20 '12 at 10:29
  • @Kenneth the whole point of writing procedural code in C++ was embeddability in C. Are there any other POSSIBLE advantages in writing it procedurally? – Flavius Dec 20 '12 at 10:32
  • 1
    @Flavius That is always a design question. If it makes sense to write it procedurally, do so. If it makes sense to implement an inheritance hierarchy by all means do so. – Kenneth Dec 20 '12 at 10:55

1 Answers1

1

I'll get downvoted a lot for this, because this doesn't really answer the question, but...

  • If you want to be called portably from the outside, use C prototypes. No overloading, no default arguments, no templates, no C++ types. Only C types, ie. integers, floating point numbers and pointers (pointers to opaque incomplete C++ structures are OK). Requiring a client library to use libffi or similar is asking for trouble.
  • If you want to use C++ features and libraries, you can use them and still comply with the above with a little work (don't forget extern "C", and catch all exceptions).

If the client is not willing to use C++ (which is perfectly understandable), you'll have to write glue code anyway. The only solution to minimize glue code is to design a clean API.

It is possible to write the "top layer" (close to the externally visible API) in a way that will require almost no glue, and use C++ for the internals.

Alexandre C.
  • 55,948
  • 11
  • 128
  • 197