Linked by R_T_F_M on Thu 13th Sep 2012 21:19 UTC
FreeBSD "For the past several years we've been working towards migrating from GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD 10.0 with Clang as the default compiler on i386 and amd64 platforms. To this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 platforms on November 4th."
Thread beginning with comment 535111
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: C++
by boldingd on Fri 14th Sep 2012 21:07 UTC in reply to "RE[3]: C++"
boldingd
Member since:
2009-02-19

Ever tried to link a program unit written in C++ into a project written FORTRAN? It's possible, but ugly. It's much easier to link a C program unit into a FORTRAN project.

C has a lot of other use cases too, of course, but C-style linking is definitely still the lingua franca of multi-language projects. Most languages and compiler suites support C linking, and if you're going to mix multiple languages in a single project (which happens, I've worked on a project that mixed C, C++, Ada and Fortran), you're likely to be exporting everything with C linking at the boundaries where those languages meet.

Reply Parent Score: 2

RE[5]: C++
by satsujinka on Fri 14th Sep 2012 22:09 in reply to "RE[4]: C++"
satsujinka Member since:
2010-03-11

I really wish someone would do something about that... I mean it's not so bad when you can generate the C bindings, but it's still a pain.

Using JVM/.Net languages you can sort of avoid the issue because they're all represented the same way... but that doesn't help me if I want to make Haskell and Python talk.

I could make a library that would know how to dynamically look up information, but that would basically involve imbedding Python in Haskell (or vice versa.) And it probably wouldn't perform well. It may almost be less effort to create 2 languages with similar characteristics and build in the cross talk functionality (allowing the compiler/interpreter to do optimization.)

Reply Parent Score: 2

RE[5]: C++
by moondevil on Sat 15th Sep 2012 06:53 in reply to "RE[4]: C++"
moondevil Member since:
2005-07-08

Ever tried to link a program unit written in C++ into a project written FORTRAN? It's possible, but ugly. It's much easier to link a C program unit into a FORTRAN project.


extern "fortran" ....

C has a lot of other use cases too, of course, but C-style linking is definitely still the lingua franca of multi-language projects.


On the operating systems, where the ABI == C linkage model.

On Lilith for example, you would need to use Modula-2 linkage module. In Native Oberon, the ABI is Oberon based. In Spin it is Modula-3 based and so forth.

You can argue they are all dead, but lets take Windows 8. On the platforms where the only Windows ABI is WinRT like the ARM tablets, the lowest API is COM and the only native code compiler C++.

In this case, your languages need to communicate via the COM bindings, there is no C interop any longer.

Sure you can still use C, but it will be C communicating via the COM API.

This means in the long run, C++ replaces C as the lowest API on Windows, if WinRT is sucessfull.

In Symbian likewise, if you're using some C stuff, you're actually compiling C like code in a C++ compiler, because the ABI and exposed interfaces are all C++ based.

Again, C as lingua franca only works if C is the language exposed by the operating system. Lets not forget there were system programming languages before it, and after it, why should C exist forever?

Reply Parent Score: 2

RE[6]: C++
by boldingd on Sat 15th Sep 2012 08:34 in reply to "RE[5]: C++"
boldingd Member since:
2009-02-19

"Ever tried to link a program unit written in C++ into a project written FORTRAN? It's possible, but ugly. It's much easier to link a C program unit into a FORTRAN project.


extern "fortran" ....
"

Unless the C++ program unit has global static instances of classes with default ctors that need to run; then your compiler and linker need to know to find those initializers and run them.

"C has a lot of other use cases too, of course, but C-style linking is definitely still the lingua franca of multi-language projects.


On the operating systems, where the ABI == C linkage model.

On Lilith for example, you would need to use Modula-2 linkage module. In Native Oberon, the ABI is Oberon based. In Spin it is Modula-3 based and so forth.

You can argue they are all dead, but lets take Windows 8. On the platforms where the only Windows ABI is WinRT like the ARM tablets, the lowest API is COM and the only native code compiler C++.
"

The problem isn't only the system API, the problem is things like pre-main initialization. Other languages have state that the system needs to keep track of; maybe they have a GC that needs to be updated, maybe they have pre-main initializers that need to happen, maybe they have some other structure that the language run-time is supposed to keep track of. C doesn't do any of that; when you link in a C library written in C, you know that there's no implicit pre-main that you need to call, and no GC whose state needs updating, and etc.

(Yes, C libraries can have init routines, but they're explicit and part of the documented API; if you get someone else's C++ library, that isn't supposed to be linked into C or FORTRAN or Ada code, and try to link it in anyway, you have to figure out what your compiler and platform name the premain, hunt it down, and invoke it explicitly, which is a large part of what I was referring to when I said "it was nasty". And if more than one premain initialization routine was generated, you get to worry about that, and if the order in which they're called is constrained, you get worry about that.)

In this case, your languages need to communicate via the COM bindings, there is no C interop any longer.

Sure you can still use C, but it will be C communicating via the COM API.

This means in the long run, C++ replaces C as the lowest API on Windows, if WinRT is sucessfull.


We're talking about different things. COM is an object-communication system, not a library linking system. As far as I can understand it (and I'm not a Windows developer), COM would take care of the problem of communicating objects between heterogeneous languages, but it's not an ABI or linking standard and it wouldn't take care of actually linking the program units in the first place.

Which, you're right, would make cross-language linking much easier if you're working with Microsoft's native tools and the set of languages that it's build system and platform well-support, but won't help you at all if you're trying to link in an Ada or FORTRAN unit.

In Symbian likewise, if you're using some C stuff, you're actually compiling C like code in a C++ compiler, because the ABI and exposed interfaces are all C++ based.

Again, C as lingua franca only works if C is the language exposed by the operating system. Lets not forget there were system programming languages before it, and after it, why should C exist forever?


And the system-development languages before it blew, which is why C was developed. And the system-development languages used after it have to be restricted; remember the above post about how C++, when used as a kernel language, can't make use of a laundry-list of features? That's because of the same problem; you can't use features that would require the generation of implicit premains, or would refer to state that the underlying system is supposed to maintain (because in a kernel, there is no underlying system). The system-development-safe part of C++ you end up with isn't much larger or much different than C.

Reply Parent Score: 2