Can I add g++ created objects to my Pelles C project?

[x79]

I want to include some c++ parts of 7-zip in my project. I would prefer to not have a separate 7z.dll. Instead I would like to have a static build. I can use g++ to build object files but can these be used in my Pelles C project? Is there a better way to do this? I don't need the entire 7-zip project: I only need the Deflate encoder.

[TimoVJL]

Could you use zlib deflate ?

[x79]

Actually, my plan is to include MiniZ, Zopfli, and 7-zip deflate algorithms and let the user decide which to use. 7-zip gives much better compression ratios at the expense of CPU/time. Zopfli squeezes a little more compression ratio but takes a very long time to do it. MiniZ is comparable to Zlib. I searched google for hours and have not found where anyone else extracted just the deflate portion.

[Stefan Pendl]

ANSI C is older than C++ so it knows nothing about C++.
There is no way of using C++ files with a pure ANSI C compiler.

[Bitbeisser]

ANSI C is older than C++ so it knows nothing about C++.
There is no way of using C++ files with a pure ANSI C compiler.

The issue at hand has nothing to do with "ANSI C being older than C++", it is rather that C++ compilers use "name mangling" in order to create unique names for objects/functions/variables at link time. Other programming languages (not only ANSI C) don't do that (at least not in the same way), hence linking C++ object files to any other language is pretty much impossible.
Your only option here would be to try and see if you can "demangle" (you can Google for that term!) the particular object file you are creating with G++. I had that problem years ago and pretty much gave up on that option and recreated the needed code in plain ANSI C...

Ralf

[x79]

TYVM, Bitbeisser. It looks like my best option here is to require the external dll for said functionality. I will look up demangling but at this point, I don't think it would be wise to spend much more time on it.

[x79]

great information here http://bingbots.com/questions/711582/how-to-combine-different-programming-languages

The "standard" is to use non-mangled names when combining programs from different languages. Name mangling can be turned off for specific symbols in C++ by declaring them with extern "C". C does not mangle names.

All library executables contain some type of interface. If they did not, no software would be able to work with them. It is more likely internal methods get changed to be more efficient. In addition, many languages allow you to turn off "mangling" at the compiler level.

Linking, as a simple explanation (I will probably get dinked for this?), is packaging into a single file. The classes retain the same interface as non-linked libraries, at least from an external programming standpoint.

Different languages can definitely use the same libraries. On the old Windows Visual Basic it was quite common to dynamically load Windows API functions, for instance.

All you need for inter-language linking is an agreement on the function's calling conventions, along with knowledge of the function names. The former has to be done by looking up the documentation; the latter has to be looked up in the compiler that created the objects or libraries. For example, gcc will compile C without mangling names, so you can refer directly to the function names as they are in your C source, while g++ will compile C++ code with mangled names and you're best off exposing C functions via extern "C" declarations.

Basically, as long as your objects or libraries expose only the C ABI, there should be widespread support for binding to other languages. It's a lot more difficult if you want to use a native C++ library, for instance, since in that case your foreign languages have to implement the correct C++ ABI. It's similar for exporting code from, say, Fortran, but I believe that one can be made to just uses the C ABI.

The issue with linking different object files together generally comes down to subroutine calling conventions. Basically, when you make a call to a routine located in another object file, your compiler will have to know what that other object file will name its routine internally, how to pass all its parameters, and what (if any) setup and cleanup code the routine will require. All this stuff is generally grouped together under the heading of calling conventions.

Each compiler has its own calling conventions it likes to use for subroutines. Note I said "compiler", not language. The C calling convention in Linux is different than the C calling convention on Windows.

So when you mix languages, you need some way to tell the compiler for either the calling or the called subroutine to use the other language's calling convention. C's convention is a popular one to use as sort of a "lingua franca", as just about every platform has a C compiler. However some platforms (eg: Windows) have multiple popular calling conventions.

So now we ask the question you asked in the comments:

    Is there a common way to "tell the compiler to use the other language's calling convention"?

And the answer is, "No, not really". Some languages do have defined ways of using specific other language's calling conventions. For example, C++ allows you to to put extern "C" on declarations to tell the compiler that the declaration(s) in question use the C calling convention. Ada accomplishes the same thing with pragma Convention (X,...), where X is the convention name. C, Fortran, and Cobol are defined by the language, but anything else supported (eg: Windows' Stdcall) is implementation defined.

However, if you have a pair of languages whose compiler writers never thought of each other, then you have no choice but to tell both to use some third convention that they both know about (usually C's). For example, to get standard C++ and Ada to interoperate, you'd have the server code export its routines using the C convention, and tell the client code that the routines it is calling are using the C convention.