Closed m-7761 closed 5 years ago
Every directory in src
is compiled to a static library. Though I think they all have classes as part of the ABI (and plugins require using classes too) so I'm not sure how extern "C"
helps with compatibility.
It's for dynamically loading procedure addresses as far as I know. If the procedures aren't supposed to be dynamically loaded, then they should not be marked with it. I ask because I'm not sure, but I think it should probably be removed. Except for the plugin API.
(EDITED: It doesn't make procedures dynamically loadable... it just removes "mangling" from the procedure's name.)
(If extraneous this is a pretty obvious case of extraneous code that raises a red flag in the mind of readers, so they are interrupted. But any kind of extraneous code, down to single tokens have the same effect. Like for example, some programmers make a habit of defaulting to prefix ++ in C++. But that is red-flag implying there is a reason to use prefix ++. So it makes code unreadable. If prefix ++ is the default, the language would be called ++C.)
EDITED: The only thing I can think of is it's for binding to scripting languages. If so, the binding is implemented by an external tool with an external description. I think the existing script code hooks the script module up to its procedures from inside the application.
I understand why the plugin APIs use
extern "C"
but I don't understand why it's used elsewhere, in many places. Is the code meant to be dynamically linked to? If so, by what?