Besides the stated arguments and the "this" pointer, what other arguments does a c++ (g++) constructor get, in what order?

Question

I want to call a C++ constructor from another language, and need to know what arguments to give it. I think it should be the stated arguments and the "this" pointer. But does the "this" pointer come first or last, in Gnu G++? And are there any other hidden arguments than the "this" pointer?

Other issues such as mangled names are not involved in this question as I already have those issues solved. This question is only about the arguments to a constructor. And the specific language I'm using is not an issue either, as it's a language under development, and this question applies to non-C++ languages in general, not just to a specific language.

Edited to add: This is for an Intel CPU using G++ conventions. That should answer the question of what ABI is involved.

As for "extern C" this is not C++ code. It calls C++ code, but since it's not C++ code itself, it would be meaningless to use "extern C". Also, the C++ code it calls has to be used as-is, without adding stuff to it such as "extern C".

What I'm looking for is not an exact formal definition of calling conventions. I just want some clues to experiment with. Such as, how common is it for C++ compilers to put the "this" pointer at positions other than the first argument? And how common is it for there to be other hidden arguments than the "this" pointer. And if the "this" pointer is not first, is it nearly always last, or is it sometimes in the middle? Etc.

Answer 1

Placement of this pointer within the argument list is implementation-defined. If you would like to interact with another language, add a C wrapper:

// Your class
struct MyClass {
    MyClass(int, int);
    void doSomething(char,int);
};
// C wrapper
void* construct_MyClass(int a, int b) {
    return new MyClass(a, b);
}
void doSomething(void* thisPtr, char c, int a) {
    static_cast<MyClass*>(thisPtr)->doSomething(c, a);
}

This way the compiler would take care of placing the parameters in the expected order, leaving your caller code to interact with C APIs. You would need to use extern C in declarations of your C functions to preserve the name for C linkage.

Answer 2

The C++ standard doesn't define how the this pointer and any arguments are passed to a constructor (or any function for that matter). That is the job of the ABI (Application Binary Interface) and different compilers can - and in the real world, do - use different ABIs. The ABI is not part of the C++ standard.

I'm going to assume both languages you want to use are compiled to machine code using a compiler since that makes discussion easier. Similar principles apply to interpreted and other languages, but the specific details differ.

Generally speaking, to correctly call any C++ function from another language, both languages must either be translated to the same ABI by respective language compilers or there must be a defined/documented means by which two different ABIs interoperate. In other words both compilers - and the machine code they generate - must be designed to interoperate.

Practically, the C++ standard specifies how it interoperates with C at the language level. C can't use all C++ constructs, but extern "C" functions are built by a C++ compiler in a way that allows them to be called from C. Compatible C and C++ compilers - or the code they emit - can therefore interoperate, assuming both compilers support the same ABI. For example, g++ (gnu's C++ compiler front end) and gcc (gnu's C compiler front end) are designed to interoperate, but they do not (necessarily) interoperate with compilers from other vendors. Technically, it might be possible for machine code output by a gnu C compiler to interoperate with code output by a C compiler from another vendor, but doing that requires very detailed knowledge of how the ABIs supported by both compilers work (and deliberate support by both vendors).

For other languages to interoperate with C++, the options are less straight-forward. Generally the common denominator is C - other languages provide a facility to interoperate with C, as does C++, so some C interface is used as an intermediary between the two. For example, code that instantiates an object in C++ may be placed in an extern "C" function. That code can then be compiled using a C++ compiler, and the resultant function has an interface that allows calling it from C code. If the other language (or compiler) has support for interoperating with C (i.e. comply with requirements to interface correctly in order to call a C function) then that C function can be called from other languages.

Answer 3

As for "extern C" this is not C++ code.

C++ code marked extern "C" is C++ code which is callable from C and thus from other non-C++ code. C is kind of lingua franca of inter-language interfaces. If you can talk C, you can talk with anyone who also talks C, which is pretty much everyone in the programming languages world. C ABIs are reasonably straightforward and easy to implement. C++ ABIs, to put it mildly, are anything but (and they are a strict superset of C ABIs so you would have to implement those anyway).

Stick to C-compatible interfaces. You are not the first person in the world who needs to create a C++ object from non-C++ code. Everyone does it via extern "C" code.

the C++ code it calls has to be used as-is, without adding stuff to it such as "extern C".

You don't add anything to existing code in order to interface to it. You write new C++ code, make it call old C++ code, and and mark the new code extern C. The old code is not touched in any way.