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."
Order by: Score:
performance?
by sergio on Thu 13th Sep 2012 22:53 UTC
sergio
Member since:
2005-07-06

Well... I hope the performance of Clang compiled FreeBSD 10 will be on par with gcc compiled FreeBSD 9.

This kind of decisions remind me a lot to the "eat your own dog food" attitude so common in big IT companies... now Open Source world is suffering the same affection.

Reply Score: 1

RE: performance?
by ssokolow on Thu 13th Sep 2012 23:52 UTC in reply to "performance?"
ssokolow Member since:
2010-01-21

I think you're mixing up your terms.

NIH (Not Invented Here) is an affliction.

Eating your own dogfood is a praise-worthy quality that means that you're less likely to ship garbage because the people most able to fix problems that annoy them are full-blown users.

Reply Score: 12

Comment by gloucestershrubhill
by gloucestershrubhill on Thu 13th Sep 2012 23:10 UTC
gloucestershrubhill
Member since:
2010-08-10

Affliction?

Reply Score: 1

C++
by kwan_e on Fri 14th Sep 2012 01:26 UTC
kwan_e
Member since:
2007-02-18

Ironic, now that the biggest projects written in C are compiled with something written in C++ (or, increasingly so, in GCC's case).

Reply Score: 3

RE: C++
by satsujinka on Fri 14th Sep 2012 03:02 UTC in reply to "C++"
satsujinka Member since:
2010-03-11

There's nothing ironic about it. Different projects use different languages.

Reply Score: 2

v RE[2]: C++
by kwan_e on Fri 14th Sep 2012 06:02 UTC in reply to "RE: C++"
RE[3]: C++
by satsujinka on Fri 14th Sep 2012 06:43 UTC in reply to "RE[2]: C++"
satsujinka Member since:
2010-03-11

Irrational? Hardly. My argument against C++ is/was always about complexity.

Regardless of your views on my views, my participation has nothing to do with irony. I was merely correcting your misuse of the word.

Reply Score: 2

RE[4]: C++
by kwan_e on Fri 14th Sep 2012 10:01 UTC in reply to "RE[3]: C++"
kwan_e Member since:
2007-02-18

Irrational? Hardly. My argument against C++ is/was always about complexity.


There exists other languages that promote complexity much more than C++. eg, Java and C, IRONICALLY. But what makes your arguments irrational are your supporting arguments. It's not irrational to argue against complexity, but it is irrational to bring up irrelevant and downright unsafe practices as proof of a language's unnecessary complexity.

If I may remind you, you plainly stated that it was preferable (to you) to risk buffer overruns with array management than using slightly more complex but safer features of a language.

That is highly irrational.

Regardless of your views on my views, my participation has nothing to do with irony. I was merely correcting your misuse of the word.


It has everything to do with irony. I just looked up a couple of explanations of the concept "situational irony". This situation fits, and even more so with your involvement.

Reply Score: 2

RE[5]: C++
by dnebdal on Fri 14th Sep 2012 11:10 UTC in reply to "RE[4]: C++"
dnebdal Member since:
2008-08-27

"Irrational? Hardly. My argument against C++ is/was always about complexity.


There exists other languages that promote complexity much more than C++. eg, Java and C, IRONICALLY. But what makes your arguments irrational are your supporting arguments. It's not irrational to argue against complexity, but it is irrational to bring up irrelevant and downright unsafe practices as proof of a language's unnecessary complexity.
"

I don't know - Java does encourage over-design, but C++ encourages nigh-unreadable template fun and magical mystery action-at-a-distance.

Of course, C++ in the right hands is fine, and it does also depend on what you're coding against (Qt code tends to look good to me), and dash of C++ can remove a lot of pain from a C project.

Reply Score: 2

RE[6]: C++
by kwan_e on Fri 14th Sep 2012 12:59 UTC in reply to "RE[5]: C++"
kwan_e Member since:
2007-02-18

I don't know - Java does encourage over-design, but C++ encourages nigh-unreadable template fun and magical mystery action-at-a-distance.


Nothing about C++ encourages templates. Most of the useful template stuff is already expressed in the standard library. Programmers who aren't cowboy coders won't use metaprogramming - and we must use non-cowboy-coders as a standard candle because cowboy coders can do damage in any language equally.

I would say that RAII prevents most occurrences of mystery action-at-a-distance. Resources have limited scope and are cleaned up once out of scope, reducing chances of mystery action-at-a-distance.

Conversely, Java lacking destructors and relying on cleanup functions being called explicitly in finally blocks fails to improve upon C++ as was the aim. Overreliance on inheritance as a way of extending functionality is error-prone, and in Eclipse, for example, often requires looking at code of the superclass to make sure your extensions don't break it. That's extreme mystery action at a distance.

Reply Score: 2

RE[7]: C++
by moondevil on Fri 14th Sep 2012 14:16 UTC in reply to "RE[6]: C++"
moondevil Member since:
2005-07-08

Conversely, Java lacking destructors and relying on cleanup functions being called explicitly in finally blocks fails to improve upon C++ as was the aim.


Since Java 7 you can make use of try-with-resources, which pretty much covers the RAAI scenarios.

Overreliance on inheritance as a way of extending functionality is error-prone, and in Eclipse, for example, often requires looking at code of the superclass to make sure your extensions don't break it. That's extreme mystery action at a distance.


Blame the programmers, not the language.

I can also give examples of C++ frameworks, which rely on inheritance to death, coupled with nice touches of multiple inheritance.

Reply Score: 3

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

If I may remind you, I plainly stated that there is no risk of buffer overflows if you follow correct practices. At no point in time did I encourage unsafe practices. I spelled out for you exactly what must be done. And even with that in mind, it is not only simpler to do it my way but it also produces easier to read and understand code.

You've obviously found poor references for irony. There's simply no expectation that a C project would not be compiled with a compiler written in C++. Thus there cannot be any irony when it happens (and it happens all the time, further removing it from the realm of irony.)

Similarly, my participation is not ironic because there's no basis to expect that I wouldn't participate in correcting a misuse of an overly misused word.

Reply Score: 3

RE[6]: C++
by kwan_e on Sat 15th Sep 2012 13:29 UTC in reply to "RE[5]: C++"
kwan_e Member since:
2007-02-18

If I may remind you, I plainly stated that there is no risk of buffer overflows if you follow correct practices.


You keep forgetting we live in the real world where even the best programmers make mistakes. Do you know what a mistake is? People don't have to intentionally diverge from correct practices to make a security error.

At no point in time did I encourage unsafe practices. I spelled out for you exactly what must be done.


You encourage it by enabling the mindset that people should make security a matter of ego and pride at being able to claim mastery over manual buffer management. Encouraging manual buffer management (because of your dislike of C++) is reckless.

From the point of everyone who is not a developer: they don't care. What they see is a security flaw and their wasted money.

And even with that in mind, it is not only simpler to do it my way but it also produces easier to read and understand code.


Since when has manual anything been simpler and easier?

You've obviously found poor references for irony. There's simply no expectation that a C project would not be compiled with a compiler written in C++. Thus there cannot be any irony when it happens (and it happens all the time, further removing it from the realm of irony.)

Similarly, my participation is not ironic because there's no basis to expect that I wouldn't participate in correcting a misuse of an overly misused word.


What makes it ironic is that Linus Torvalds and people like you have said that C++ is a bad language and that C is preferable to C++. I'm pretty sure the BSD people hold similar views. Then you get compilers written in a language you despise compiling your programs written in a language you prefer over the compiler's implementation language.

Your preferred language has basically become possible only because of a language you hate, and it's happened to the biggest projects with the greatest haters. Irony.

And the "expectation" criteria of irony is not an empirical one but a vaguely narrative one. For example, say we're both watching a movie. Something happens which you don't expect to follow from what has happened, while I fully expected it to because I understand the narrative structure. Does that make not ironic simply because I expected it, even though you didn't expect it and it was certainly the writer's intention of it being ironic?

Of course not. Irony is a literary or narrative property that applies whether or not an actual person actually expects it or not.

Reply Score: 2

RE[7]: C++
by satsujinka on Sat 15th Sep 2012 23:13 UTC in reply to "RE[6]: C++"
satsujinka Member since:
2010-03-11

Oh hey, the security circus is back in town. I've already dealt with the issues you bring up, but here we go again.

Mistakes get checked by others. Don't release software before hand.

Using arrays is not a matter of pride, but one of humility. Other people have to read the code. Use something easy to read.

Manual can be easier if it makes things easier to understand. In this case, arrays have special syntax that makes them easier to understand than vectors. Thus even though it's manual, it's still easier.

The language of the compiler is irrelevant. Most projects just use the most popular compiler. It simply makes rational sense to do so, as popular compilers have more extensions, optimizations, and (hopefully) less bugs (or they'll be fixed sooner.)
It is entirely possible to compile linux or freeBSD with tcc or pcc. Both of which are written in C. Therefore, it is not true that C requires C++.
It is also important to point out, that using a program is in no way, shape, or form a validation of the language used to write it.

In order to hate, one must have passion. I certainly don't. I don't go around trying to stop people from using C++, it's their choice they can use what they like.
Personally, I find C++ to be an ugly language. It tries to do too many things at once and ends up being overly verbose in everything it does. This makes it harder to read. Which makes it harder to understand.
I much prefer using smaller, more concise languages. Yes, that's languages plural.

Lastly, irony. Irony is all about expectation. If you don't understand this then, please, stop using the word. Specifically, Irony is about averaged expectation, also known as common sense. Something can be ironic only if the average person wouldn't have expected that outcome.
Also, expectation is empirical. You can go out and ask people what they expect.

Reply Score: 2

RE[4]: C++
by boldingd on Fri 14th Sep 2012 20:24 UTC in reply to "RE[3]: C++"
boldingd Member since:
2009-02-19

No man, if you don't think his favorite language is the best language for all projects, then you're clearly an idiot.

Reply Score: 3

RE[5]: C++
by kwan_e on Sat 15th Sep 2012 03:11 UTC in reply to "RE[4]: C++"
kwan_e Member since:
2007-02-18

No man, if you don't think his favorite language is the best language for all projects, then you're clearly an idiot.


No, my favourite language is C++PythonAda, but no such language exists.

Reply Score: 2

RE[6]: C++
by satsujinka on Sat 15th Sep 2012 23:21 UTC in reply to "RE[5]: C++"
satsujinka Member since:
2010-03-11

So your favorite language is two parts bloat to one part batteries included?

No wonder we disagree. That's pretty much the definition of the worst language ever.

Reply Score: 2

RE: C++
by moondevil on Fri 14th Sep 2012 07:26 UTC in reply to "C++"
moondevil Member since:
2005-07-08

I think people are slowly accepting that C++ eventually gets to replace C in most areas where C is still relevant in the desktop/server.

MacOS X device drivers are done in C++ (IOKit).

Most of the Win32 APIs since Windows 2000 are actually COM based and Microsoft publicly announced that C is only relevant for legacy code and they rather focus in C++. More so in Windows 8.

Symbian and BeOS are done in C++.

Only Linux and BSD are still have pure C/ASM kernels. I don't know about Aix, HP-UX and Solaris.

Now for embedded systems C still have a place, as many of them are still coded in Assembly and companies are now slowly moving up to C.

Of course C will exist for decades still, as it does not make sense to rewrite code that works just for changing language.

Reply Score: 12

RE[2]: C++
by Valhalla on Fri 14th Sep 2012 14:12 UTC in reply to "RE: C++"
Valhalla Member since:
2006-01-24

I think people are slowly accepting that C++ eventually gets to replace C in most areas where C is still relevant in the desktop/server.

I seriously doubt that, not only from my own experience but also from what I've see of the language popularity benchmarks C is holding on as strong as ever (it recently beat Java for the top spot on Tiobe).


MacOS X device drivers are done in C++ (IOKit).

Actually it uses a subset of C++ with no exceptions, no templates, no multiple inheritance etc, which kind of begs the question why they couldn't just settle with plain C to begin with for those drivers.

C is here to stay, it's the lowest common denominator as far as high level languages go, supported by pretty much every platform, and useable from just about any other language.

That doesn't mean it's the best choice for every project, there are certainly areas in which other languages like C++, Java, C#, Python, Go, etc are likely better choices as they offer a higher level of abstraction.

A particular area in which I wager C will always reign supreme is in library/framework code, the reason projects like zlib, flac, libjpeg, png, sdl, audio/video codecs, lzma, etc etc are written in C is because it's A) fast and small memory footprint B) callable from just about anything.

Also none of the 'new' languages really compete with C, new languages like Go, Rust are higher level and compete primarily with C++ or even higher level languages.

Reply Score: 3

RE[3]: C++
by moondevil on Fri 14th Sep 2012 14:20 UTC in reply to "RE[2]: C++"
moondevil Member since:
2005-07-08

C is here to stay, it's the lowest common denominator as far as high level languages go, supported by pretty much every platform, and useable from just about any other language.


It is only the lowest common denominator on the operating systems that happen to have C as their API.

In Symbian you need a C++ compiler, even C code gets compiled by C++ compiler.

Starting with Windows 8, WinRT comes into the picture as the future direction of the operating system API.

Eventually C++ will be the lowest level API you can get on Windows.

Reply Score: 2

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 Score: 2

RE[5]: C++
by satsujinka on Fri 14th Sep 2012 22:09 UTC 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 Score: 2

RE[5]: C++
by moondevil on Sat 15th Sep 2012 06:53 UTC 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 Score: 2

RE[6]: C++
by boldingd on Sat 15th Sep 2012 08:34 UTC 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 Score: 2

RE[7]: C++
by moondevil on Sat 15th Sep 2012 14:02 UTC in reply to "RE[6]: C++"
moondevil 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.

Reply Score: 2

compare
by krzabr on Mon 17th Sep 2012 16:45 UTC
krzabr
Member since:
2009-09-14

http://lists.freebsd.org/pipermail/freebsd-current/2012-September/0...

Simple comparasion of freebsd built by clang and gcc

Reply Score: 1