Linked by R_T_F_M on Thu 13th Sep 2012 21:19 UTC
"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 535171
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-08
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.
Since when? COM is all about libraries.
Your COM components can exist in separate executables, for more security. In this case a kind of local RPC is used.
However, most COM components are actually dynamic libraries that get dynamically linked with your application and follow the same format as C++ VMT. No communication going on here.
In Windows 8 COM got extended. Now with WinRT, COM makes use of .NET metadata for language interoperation.
If Metro succeeds, many Windows developers believe Win32 might be in the legacy path, with WinRT taking over the full spectrum of Windows APIs.
"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. "
C got developed, because of UNIX. If UNIX had failed in the market, most probably no one would be talking about C today.
Now UNIX got successfull, everyone wanted to have UNIX like utilities and C started to be ported everywhere.
The day, operating system vendors start using another language for systems programming, like Microsoft is doing now with Windows 8, then C starts to loose its influence in this area as well. At least in the desktop area.
If the operating system vendor does not offer you a C compiler, or C like APIs, then there is not a C interface to talk about.
You FORTRAN compiler, Ada compiler will need to support another type of interface.
This is nothing new. From what I know, there are no C like interfaces in mainframe systems, and you are forced to use whatever call convention the OS vendor decided upon.
Member since:2009-02-19
Since when? COM is all about libraries.
Your COM components can exist in separate executables, for more security. In this case a kind of local RPC is used.
However, most COM components are actually dynamic libraries that get dynamically linked with your application and follow the same format as C++ VMT. No communication going on here.
In Windows 8 COM got extended. Now with WinRT, COM makes use of .NET metadata for language interoperation.
If Metro succeeds, many Windows developers believe Win32 might be in the legacy path, with WinRT taking over the full spectrum of Windows APIs.
Your COM components can exist in separate executables, for more security. In this case a kind of local RPC is used.
However, most COM components are actually dynamic libraries that get dynamically linked with your application and follow the same format as C++ VMT. No communication going on here.
In Windows 8 COM got extended. Now with WinRT, COM makes use of .NET metadata for language interoperation.
If Metro succeeds, many Windows developers believe Win32 might be in the legacy path, with WinRT taking over the full spectrum of Windows APIs.
I'm not a Windows dev, but from what I'm reading, COM isn't a calling convention, it's an object serialization technique. You're right that it will help different OOP languages on the same underlying platform swap objects easily, but that's not the only problem I'm talking about. That works because COM support is pushed into the language run-time and underlying platform, and handled by the compiler; things change when one of the languages you're using isn't object-oriented or doesn't have usable COM bindings, like Fortran, Ada or C. Exactly the reason that C is the common language for multi-language linking is that C linking is the lowest common denominator among calling conventions, and that's still going to be true even on a platform that makes heavy use of COM in its low-level APIs.
C got developed, because of UNIX. If UNIX had failed in the market, most probably no one would be talking about C today.
Now UNIX got successfull, everyone wanted to have UNIX like utilities and C started to be ported everywhere.
The day, operating system vendors start using another language for systems programming, like Microsoft is doing now with Windows 8, then C starts to loose its influence in this area as well. At least in the desktop area.
If the operating system vendor does not offer you a C compiler, or C like APIs, then there is not a C interface to talk about.
You FORTRAN compiler, Ada compiler will need to support another type of interface.
This is nothing new. From what I know, there are no C like interfaces in mainframe systems, and you are forced to use whatever call convention the OS vendor decided upon.
Now UNIX got successfull, everyone wanted to have UNIX like utilities and C started to be ported everywhere.
The day, operating system vendors start using another language for systems programming, like Microsoft is doing now with Windows 8, then C starts to loose its influence in this area as well. At least in the desktop area.
If the operating system vendor does not offer you a C compiler, or C like APIs, then there is not a C interface to talk about.
You FORTRAN compiler, Ada compiler will need to support another type of interface.
This is nothing new. From what I know, there are no C like interfaces in mainframe systems, and you are forced to use whatever call convention the OS vendor decided upon.
"C exists because of Unix" is historically true, but you're missing the point. The reason that C came into existance was that B and BCPL - and pretty much all low-level system languages - sucked. C became popular because there was a huge need for a portable, high-level language that could still be used for low-level work. C and Unix answered real needs in the market that nobody else did; it's not as if they became popular by coincidence or clever marketing.
Features
Linked by Thom Holwerda on 05/20/13 11:29 UTC
The day has finally come! Jolla has finally announced the launch device for its Sailfish operating system - and by god this is a looker. It's decidedly different from other phones out there, but it has good specifications and carries a relatively reasonably price tag - EUR 399, and it's up for pre-order today, shipping in the fourth quarter of this year.
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Why does Google get so much credit in the technology industry? Why, despite the company's many obvious failings, do many geeks and enthusiasts still hold a somewhat positive view on the all-knowing technology giant? A specific talk at Google I/O this week provides the answer.
Linked by David Adams on 05/16/13 4:23 UTC
OSNews is a sponsor of this year's O'Reilly OSCON in Portland, Oregon, USA. A lucky OSNews reader will win a free three-day pass, including two tutorials days. To win the pass, post a comment on this story saying something about Open Source Software or OSCON. We'll pick a winner at random next week. If you don't have an OSNews account, you may email us your entry. Part of the conference is the 9th annual Open Source Awards, and today the 16th is the deadline for nominations. If you'd like to nominate an outstanding open source contributor, do it here. Read on for more information about OSCON. Update: The 20% discount code for OSNews readers is "OSN."
Linked by Thom Holwerda on 05/11/13 21:41 UTC
"Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening." That's one way to start an insider explanation of why Windows' performance isn't up to snuff. Written by someone who actually contributes code to the Windows NT kernel, the comment on Hacker News, later deleted but reposted with permission on Marc Bevand's blog, paints a very dreary picture of the state of Windows development. The root issue? Think of how Linux is developed, and you'll know the answer.
Linked by Thom Holwerda on 05/08/13 14:22 UTC
This is one of those news items that's fun to write, fun to read, fun to comment on, and where no one will be able to say anything unkind. It's all just one big ball of awesome fluffiness. TuneTracker, the BeOS radio automation software, has just released something very special: TuneTracker System 5, the first version designed entirely and specifically for Haiku. In fact, it actually includes Haiku in the software package. Better yet, TuneTracker also unveiled several system-in-a-box products - which have Haiku and TuneTracker pre-installed.
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Exactly twenty years ago, a document was published that played a huge role in establishing the web as we know it today. Twenty years later, and this simple and straightforward document is proof of an irrefutable fact: while closed technologies can change markets, open technologies can change the world.
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Oh multitasking. That staple of computing that got thrown out the window with many modern smartphones. We got some rudimentary thing in its place - but even as multitasking on phone and tablets improves, its user-visible side remains cumbersome. Windows 8 has a neat implementation, and now it's time Android follows in it footsteps.
Linked by Thom Holwerda on 04/24/13 22:24 UTC
They're here! Whether that excites you or not remains to be seen, but the Galaxy S4, which will most likely become the best selling Android smartphone of the year by a huge margin, has been reviewed by all the major sites, and there's lots of interesting conclusions in there - although I think most of you will get the gist.
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Nokia has posted its quarterly results for the first quarter of 2013, and just like the quarters that came before, there's not a whole lot of good news in there. The rise in Lumia sales still can't even dream of making up for the sales drop in Symbian phones, and when broken down in versions, the sales figures for Windows Phone 8 Lumias in particular are very disappointing. In North America, Nokia is getting slaughtered.
Linked by Thom Holwerda on 04/16/13 9:29 UTC
The day has finally come: Google has started shipping Google Glass to the lucky few early adopters. Now that it's shipping, Google has also unveiled a lot more about the API and the specifications of the device itself. While the company had already given out substantial details at earlier occasions, there are still a few surprises here.More Features »
Sponsored Links
Member since:
2009-02-19
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.
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.)
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.
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.