GCC switches from C to C++
gcc.gnu.org
gcc.gnu.org
>auto_ptr is broken. We should use shared_ptr instead
It has begun!
One of the most enjoyable features of C++ is the arguing over which parts of the language should be allowed.
The vast majority of allocated objects have unique ownership semantics, not shared. If you use shared_ptr everywhere, it's far too easy for your design to degenerate into object soup.
You mean that it's usually better design to have only one "owner" of an object? That's true.
It's worth noting that shared_ptr is also necessary for containers, so you might get into a habit of using it even if you're not creating multiple references.
Edit: Of course I'm being a bit stupidly snarky here, obviously if you have a standard container you need a shared_ptr, or an intrusive_ptr, or some other pointer, the moral of the story is that std containers aren't good for holding owned pointers in C++03.
I don't think boost ptr_containers are particularly good either, but that's mostly because of the huge cost of putting the string '#include "boost/' in your code.
Consider a helper function that returns a heap-allocated object and think whether auto_ptr or shared_ptr better modeled the function's intent of giving ownership of the object to the caller.
The real problem with auto_ptr is that if anything emits a call to auto_ptr destructor at the point where the object pointed to is incomplete (forward-declared), the destructor code won't run, only memory would be freed.
* C++ is a standardized, well known, popular language.
* C++ is nearly a superset of C90 used in GCC.
* The C subset of C++ is just as efficient as C.
* C++ supports cleaner code in several significant cases.
* C++ makes it easier to write and enforce cleaner interfaces.
* C++ never requires uglier code.
* C++ is not a panacea but it is an improvement.
It's interesting to me how defensive many of those justifications are. "It's just as efficient!" or "It's just a superset anyway!" Not until halfway through the list do we get any real description of expected benefits: C++ makes it easier to write and enforce interfaces, and C++ supports cleaner code in several significant cases. The last item is the most telling though: it's clear that these developers feel they've hit a point of crisis, and they are willing to take risks like this in order to lift themselves out of the problem.
No... but it sure tends to encourage it.
Storing the type of the variable makes little sense as in most cases it is only a quick grep away.
http://en.wikipedia.org/wiki/Hungarian_notation#Systems_vs._...
Java doesn't have typedefs, and most everyone agrees that's a language bug.
Also ugly code is less of an issue of an ugly design as you can look past how the code looks if the design of the program is sound.
But ugly is in the eye of the beholder and in that maybe more people are growing up with C++ and with a later dealing with C as apposed to the other way around. So maybe it is in many ways the mindset of the average age of the programmers around today are more comfortable with C++ as apposed to C and in that could see nicely laid out C code as having ugly bits as its easier for them to do it prettier in C++ and a biased C programmer will see it compeletly from the other perspective.
So its one of those debates were the best move is to get the popcorn as some people see ugly code were others see something nice and some will see C++ as better than they would C and vice versa. Just be glad i'm not involved or I'd be mentioning COBOL as a reality check :).
Code is where conventions are important, within comments I really wouldn't be upset if someone called Objective-C "Objective C".
I wonder what rms thinks of this. Too bad he is not calling the shots in gcc anymore.
He didn't even finish his parser for C++ though.
http://forum.gwan.com/index.php?p=/discussion/587/its-bs-bec...
Basically, his entire argument is the slippery slope fallacy based on assumptions that may never occur. Plenty of great software is written in C++, even using STL, that doesn't lead to software that is any more difficult to maintain than the equivalent C program. For one thing, refactoring due to design change is a pain in the ass with or without objects. He also doesn't address the fact that polymorphism is very unwieldy in C. While it's very defensible to NOT use C++, I don't think that saying that "C is the only sane language" is fair. That, or Apple, Google, Microsoft, Oracle, and Facebook are full of people who are barking mad.
However, in an environment like Linux and git where code practices may be less restrictive than a corporate or authoritarian environment, the natural restrictions of C (i.e. lack of easy-to-abuse features) may seem like a feature in itself.
> Plenty of great software is written in C++, even using STL, that doesn't lead to software that is any more difficult to maintain than the equivalent C program.
I don't deny that great software is written in C++, but what is your evidence that C and C++ have the same maintenance burden.
Anyway, I thought the OP meant he was prolific in his tirades, which is very true.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/57643 /focus=57918
As it is, for the kernel you'd be crazy to use something other than C.
And you would be wrong:
My feeble point is that the kernel (and git) are computer programs for computer people doing computer stuff.
Subsurface I'll give you. Mostly.
Later versions of GCC are available as packages or ports but they aren't included in the main system.
I don't think they would switch to clang. LLVM is also c++.
That's a shame. PCC seemed an interesting alternative to gcc, though I do recall PCC's v1.0 "revival" coinciding with an April Fools day several years ago. Perhaps it always was to be taken as a joke.
OpenBSD's simplicity in implementation is laudable. The less moving parts there are the less parts there are to break. It's the same philosophy that keeps me driving my 25-year old pickup.
- they have to maintain their own gcc version (the last GPL2 one)
- the licensing for clang and LLVM fits the BSDs better than the licensing for gcc.
If they want to keep the ability to bootstrap from a C compiler, they should consider creating a good C backend (configurable with such things as the size of a long) for LLVM. That way, they could convert any C++ code (including clang and LLVM) to C, and thus bootstrap a C++ compiler on a system that only has a C compiler.
Does anybody see problems with that approach?
One of the reasons to install gcc on a machine is the absence of a descent C++ compiler. 20 years ago, the C compiler of Sun was completely broken and we were happy to have gcc.
But it sure as hell isn't pleasant. ;)
Nowadays pretty much everyone has access to a Windows or Linux PC, or an OS X Mac, and so has ready access to good compilers. The way you'd handle that Sun nowadays is to build a cross compiler for Sun on your Windows or Linux PC or your Mac, and then use that to build the compiler for your Sun.
It's pretty hard to find a platform for which you can't find a pre-compiled gcc. This was not always the case.
Sun's CC -> Old GCC -> New GCC
While it doesn't require a C++ compiler, in the last few years it has required an increasing list of fairly modern libraries. I don't think requiring a C++ compiler will make things that much harder.
Their goal here is to make it easier for new developers to write their own passes or front ends or whatever. GCC may be more mature, but Clang/LLVM are way easier to dive into.
Surely you must be joking... do you have a reference for this? Sure, I sometimes the motives of the FSF but this would be quite outrageous from a software engineering perspective.
Of course, the AGPL might not have existed in 2000, but I haven't heard about GCC moving to the AGPL since then either.
If GCC was dying as you said, nobody would be interested in such large refactors that have no point other than to make development easier.