| News | Features | Interviews |
| Blog | Contact | Editorials |
| FreeBSD moves away from GCC, embraces Clang |
| By special contributor R_T_F_M on 2012-09-13 21:19:45 |
| "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." |
|
| RE[4]: C++ |
| By boldingd on 2012-09-14 20:24:13 |
| No man, if you don't think his favorite language is the best language for all projects, then you're clearly an idiot. |
 - Score: 3 |
| RE[4]: C++ |
| By boldingd on 2012-09-14 21:07:33 |
|
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. |
| - Score: 2 |
| RE[12]: C++ |
| By boldingd on 2012-09-14 21:45:48 |
|
> As for inheritance abuse in Java, it is true that a lot of people do it, but you can also have quite nice arquitectures using interfaces instead. Java was initially designed around inheritance abuse. Inheritance is all over Java's oldest APIs; note for example that Java's original Vector class holds Objects (and not a specific type), which means that you can shove any java Object into them, and that you can't shove a bare scalar type into them (yes, I know that Integer is an object that just thinly wraps around an int). This makes these things extremely type-unsafe; if you want to constrain the types you put in a Java vector, you have to enforce those constraints yourself explicitly, in your code, and you always have to explicitly type-cast the things you get out before you use them. Essentially, Sun was trying to use polymorphism to provide a flexible, generic container without actually including generics in the language, and the result was a mess. And while Java has proper generics now, that heritage is definitely still in the language. Java by design puts a lot of weight classes, objects and polymorphism. I might also point out that, at least at my school, we actually teach in some of our courses that "inheritance is a functionality extension and code-reuse mechanism, and you should use the hell out of it." And while I think that's insane, I think that view is one of the fundamental assumptions that went into Java. > Sadly, many developers don't know any better, and you tend to be forced to abuse inheritance as soon as you start incorporating a lot of 3rd party libraries. In C++ you can find such examples in ATL, MFC, OWL and TurboVision and most game engines. OOP and inheritance is sometimes the right metaphor, but not always. It's great in game engines, because you often find yourself building large trees of heterogenious but semantically-related types (i.e. large trees of objects that are renderable, but have different render methods). Ditto for UI frameworks, where you find yourself adding lots of different types that are all widgets. But, "look, this technique is used a lot in C++, too!" is not the same as "look, C++ over-uses this technique!" OOP is Java's central organizing metaphor, whereas C++ is a multi-paradigm language that also supports imperative-style code and template meta-programming where those make more sense. |
| - Score: 3 |
| RE[5]: C++ |
| By satsujinka on 2012-09-14 22:09:36 |
|
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.) |
| - Score: 2 |
| RE[5]: C++ |
| By kwan_e on 2012-09-15 03:11:30 |
|
> 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. |
| - Score: 2 |
| RE[5]: C++ |
| By moondevil on 2012-09-15 06:53:27 |
|
> 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? |
| - Score: 2 |
| RE[13]: C++ |
| By moondevil on 2012-09-15 07:10:24 |
|
Everything you said about Java I can say about C++. I started using C++ in 1992, on those days C++ was still "C with classes", and everything you complain about Java is how C++ was used on those days. Everyone was blindly trying to do Smalltalk in C++. My first compiler with basic support for templates, which were still being standardized, was Turbo C++ 3.1 for Windows 3.x, bought in 1994. Templates were only working properly across major C++ compilers around 2004. Still some edge cases of the C++98 were not fully implemented across all major compilers. And even afterwards there were many companies that disallowed the use of templates in their production code. Which means in many enterprises out there, C++ developers have been writing C++ code the same way, you Java forces people to do so. Actually, what happened is that many early adopters of Java, were C++ developers that were never able to use templates, and carried on coding in Java as they always did before in C++. You say yourself that there are better ways to code in Java, but you teach your students otherwise. How can the tool be blamed? |
| - Score: 3 |
| RE[6]: C++ |
| By boldingd on 2012-09-15 08:34:40 |
|
> > 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. |
| - Score: 2 |
| RE[14]: C++ |
| By boldingd on 2012-09-15 08:51:47 |
| Not exactly. Yes, C++ developed slowly. Yes, early compilers supported different sub-sets of it, so yes, different developers make wildly different uses of the language even today. And yes, C++ as a language has its own set of flaws, some of them quite severe. But the generic containers in the C++ standard library have been (comparatively-)type-safe templates for forever, and C++ has been multi-paradigm for most of its history. Java as a platform needed to suffer a dramatic loss of developer mind-share before its developers finally relented, compromised the language's elegant OO design and grudgingly started to add support for a lot of features that C++ (and Python and Ada and C#) have had forever. We had to wait way to long for generics, and absurdly long for RAII. |
| - Score: 2 |
| RE[6]: C++ |
| By kwan_e on 2012-09-15 13:29:36 |
|
> 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. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |