Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

GCC Switches From C to C++

Unknown Lamer posted more than 2 years ago | from the break-out-your-pitchforks dept.

GNU is Not Unix 406

According to a post on the GNU Compiler Collection list, GCC is now built as a C++ program by default. This is the fruition of much effort, and the goal now is to clean up the GCC internals that are reportedly pretty type-unsafe by rewriting them using C++ classes and templates.

cancel ×

406 comments

Sorry! There are no comments related to the filter you selected.

too bad GCC is not relevant anymore thanks to LLVM (-1, Troll)

Anonymous Coward | more than 2 years ago | (#40996671)

Stallman blew it with his GPL3 shit, everyone realized it was time to dump the crazy.

Re:too bad GCC is not relevant anymore thanks to L (0, Offtopic)

Anonymous Coward | more than 2 years ago | (#40996697)

This is the first I've heard of anything like this. Did I miss something? Is GCC now GPLv3, and does that mean you can't use it to build non-GPL programs?

Re:too bad GCC is not relevant anymore thanks to L (4, Informative)

Nursie (632944) | more than 2 years ago | (#40996747)

No, no it does not mean anything of the sort.

Re:too bad GCC is not relevant anymore thanks to L (4, Informative)

Carewolf (581105) | more than 2 years ago | (#40996905)

This is the first I've heard of anything like this. Did I miss something? Is GCC now GPLv3, and does that mean you can't use it to build non-GPL programs?

No, it means when you go in and add extra functions to GCC that those would have to be GPLv3 as well, at least if you want to distribute them.

It has NO effect on what the use of the application. In fact that is has no effect on the end user is one of the topmost clause of the GPLs.

Re:too bad GCC is not relevant anymore thanks to L (4, Interesting)

petermgreen (876956) | more than 2 years ago | (#40996973)

AIUI GCC is now GPLv3, the libraries it ships with are GPLv3 with exceptions that allow using them to build non-GPL programs. However they were paranoid about the idea that people would try and save gcc's internal state to disk and then run it through a propietry backend. So they crafted a complex exception that tries to forbid that while allowing most other combinations of gcc with propietry tools.

Re:too bad GCC is not relevant anymore thanks to L (5, Informative)

DeathToBill (601486) | more than 2 years ago | (#40996707)

Irrelevant? Not quite. For your particular use, maybe. But most Linux distros are still built using GCC, and most embedded platforms provide a GCC-based toolchain. So if, by 'irrelevant', you actually mean, 'the compiler with the most-often executed output code on earth', then yes, I guess you're right.

Re:too bad GCC is not relevant anymore thanks to L (3, Insightful)

SharpFang (651121) | more than 2 years ago | (#40996893)

Don't be so bold in claiming most embedded platforms are something.

Most embedded platforms use Keil, Assembler and all kinds of various odd proprietary compiler suites that suit their 8-bit and 16-bit nature better. The elitist, narrow though visible of 32-bit ARM is using GCC.

I assure you your refrigerator temperature thermostat was not programmed in GCC.

Re:too bad GCC is not relevant anymore thanks to L (2)

Lemming Mark (849014) | more than 2 years ago | (#40996971)

I think there are a few non-ARM embedded platforms that use gcc. AVR (even the 8-bit variants) has a good gcc port.

Re:too bad GCC is not relevant anymore thanks to L (1)

skids (119237) | more than 2 years ago | (#40996995)

Also Coldfire, and a bunch of those MIPS spinoffs, IIRC.

Re:too bad GCC is not relevant anymore thanks to L (3, Informative)

keltor (99721) | more than 2 years ago | (#40997069)

Actually a number of the older embedded platforms I've programmed for DID in fact use gcc+patches, usually with proprietary stuff added all around. I believe for most of the microcontrollers supported by Keil, the compiler is based on GCC (often the older 2.x series.)

Re:too bad GCC is not relevant anymore thanks to L (0)

Anonymous Coward | more than 2 years ago | (#40997085)

dont forget broadcom mips is also compiled using gcc, and that is a very large chunk of the embedded market

Re:too bad GCC is not relevant anymore thanks to L (4, Funny)

VortexCortex (1117377) | more than 2 years ago | (#40997157)

I assure you your refrigerator temperature thermostat was not programmed in GCC.

That's because its CPU is a bi-metallic strip wound into a coil, and it's RAM is only one bit. The equivalent of running .configure and make is rotating a dial and tightening a screw.

my fridge thermostat is digital (1, Offtopic)

Chirs (87576) | more than 2 years ago | (#40997351)

It's got digital temp settings for fridge/freezer compartments, an optional "super-cool" for fast-freezing the freezer section after putting a load of groceries into it.

Once of the coolest fridges I've seen (don't own it, too expensive) actually learned your habits--if you always have breakfast at time X and it generally results in the temperature in the fridge warming by a degree, it will pre-cool by an extra degree at time X-1 so that when you open it for breakfast it will warm up to the desired temperature. That fridge also had three separate compressors, one for each side of the fridge and one for the freezer. They were all variable speed, ran just fast enough to keep the desired temperature rather than cycling on/off.

Re:too bad GCC is not relevant anymore thanks to L (4, Interesting)

DeathToBill (601486) | more than 2 years ago | (#40997165)

Well, let's see. I personally work with control systems using x86, MIPS, PowerPC and ARM architectures, running Linux, VxWorks, QNX and WinCE (various combinations). They all have GCC toolchains, although we admittedly don't use it for CE.

If you're thinking microcontrollers, then GCC supports AVR, 68000-series, MicroBlaze, MSP430, ARM again...

Now, personally, my refrigerator has an analog thermostat, so, technically, you are right. If it had a thermostat implemented on a CPU, then I'd think there's a very good chance it was compiled with GCC.

What exactly "programmed in GCC" might mean is left for the reader to speculate on.

Re:too bad GCC is not relevant anymore thanks to L (1)

DeathToBill (601486) | more than 2 years ago | (#40997195)

I also note with curiosity that the one vendor you can actually name with a competing compiler is a development environment aimed primarily at ARM and is, in fact, produced by the "elitist, narrow though visible" ARM.

Re:too bad GCC is not relevant anymore thanks to L (0)

Anonymous Coward | more than 2 years ago | (#40997533)

Rewriting large portions of the program just to have something to do is a classic sign of boredom on the part of the developers. Fixing new obscure bugs will keep them busy for years.

Re:too bad GCC is not relevant anymore thanks to L (0)

Anonymous Coward | more than 2 years ago | (#40997665)

GCC is a large code base with a very long history which predates C++. The move to C++ was done specifically to improve type checking and be able to move from "inheritance in C" to real C++ inheritance. That ignores benefits like being able to refactor the code into classes so it is more clearly organized.

This was not done out of boredom. It was the recognition that C++ provided strong benefits over C for GCC long term.

Re: progress (2, Interesting)

presidenteloco (659168) | more than 2 years ago | (#40997955)

I too would have seen a move from C to C++ as progress...

in 1989.

It took me til about 1990 to realize that C++ was a fundamentally broken and overcomplicated attempt at an object oriented programming language. By attempting too much (OO + C backward compatibility) it achieved, to be kind, something other than safety and elegance.

C++ seems to me like the space shuttle of programming languages; includes a kitchen sink, a tool on board for every purpose, lightning fast, and dangerous as hell.

So tell me, has 22 years more development managed to fix it?

Re:too bad GCC is not relevant anymore thanks to L (2)

keltor (99721) | more than 2 years ago | (#40996815)

While the GPLv3 was the reason Apple suddenly invested in clang (which just happens to ride on llvm), it has little effect on any companies that do what they should do.

Re:too bad GCC is not relevant anymore thanks to L (1)

Carewolf (581105) | more than 2 years ago | (#40996833)

For a compiler? What does a distribution license have to do with a compiler?

You seem to be treating the GPL like cuties.. Who does believes in GPL cuties? Apple, FreeBSD, 6 year olds, anybody else?

libgcc and libsupc++ (3, Interesting)

tepples (727027) | more than 2 years ago | (#40996931)

What does a distribution license have to do with a compiler?

Division support in C on some platforms (such as ARM) and exception support in C++ rely on libraries called libgcc and libsupc++. These libraries are GPLv3 with an exception. Were it not for the exception, anything compiled with the would either be GPL (because of libgcc and libsupc++) or produce a linker error (because the libraries are called and not present). The exception applies only if the compiler has not been modified to introduce non-free optimization passes performed in an independent process. See GCC Exception FAQ [gnu.org] .

Who does believes in GPL cuties? Apple, FreeBSD, 6 year olds, anybody else?

You can add Nintendo. See the case of Pajama Sam for Wii, where Atari was willing to distribute the source code to a GPL interpreter used for the game but Nintendo didn't want GPL software on its platform [slashdot.org] .

Re:libgcc and libsupc++ (1)

Anonymous Coward | more than 2 years ago | (#40997007)

Were it not for the exception, anything compiled with the would either be GPL (because of libgcc and libsupc++) or produce a linker error (because the libraries are called and not present). The exception applies only if the compiler has not been modified to introduce non-free optimization passes performed in an independent process.

Yes, this is true. The intent here is that merely compiling code should not impose any GPL restrictions to the code you're compiling, but if you make improvements to the compiler you should release those improvements back to the community. If you don't like this, you can go and make non-free optimization improvements to somebody else's compiler. The feature is working as intended.

Re:too bad GCC is not relevant anymore thanks to L (1)

Anonymous Coward | more than 2 years ago | (#40997061)

GCC obviously comes with support libraries and tools. Those are covered under the GPL (although there are exceptions for libs used by programs).

This means any distribution that ships GPLv3 binaries has to adhere to the terms of the GPLv3 in terms of distribution of source, etc. So in a perfect world, an embedded platform should not have any toolchain stuff on it, it is a risk that a developer will screw up someday and do it. This precludes the GPLv3 from use in FreeBSD as they are targeting companies like Cisco, Juniper, and of course the code sharing with Apple from time to time.

Licensing is a tough decision and affects who will use your software and how it will be used. Not everyone accepts the GPL and some have irrational fears of it. The mention of the GPLv3 turns of use cases because of misinformation about how bad it is. For me, it took deciding that the tivo clause wasn't all bad to move forward. The patent bits aren't any worse than the Apache 2 license. It's just the image it has combined with the viral tradition it continues. At the end of the day it's not much worse than the GPLv2. Some of us just drew a line in the sand.

Here's a list of BSD projects that ship GPLv3 code in their CURRENT code base:
NetBSD (binutils, gcc, ...?)
DragonFly (binutils, gcc, ...)
MidnightBSD (just gnu diffutils right now, going llvm + clang for compiler)

And GPLv3 avoiders:
FreeBSD (switching to llvm + clang)
OpenBSD (switch to pcc + old gcc?)
MirBSD (old gcc, pcc)
Apple OS X & iOS

unknown but probably gplv3 avoiders:
pfsense
pc-bsd
other distros of freebsd and openbsd

In order to do gcc, you need binutils. Then you might as well add diffutils... then it spirals out of control.

Re:too bad GCC is not relevant anymore thanks to L (1)

shic (309152) | more than 2 years ago | (#40996839)

Does LLVM have features for coverage analysis to compare with GCOV?

Re:too bad GCC is not relevant anymore thanks to L (-1)

fast turtle (1118037) | more than 2 years ago | (#40997769)

LLVM was created by freeBSD due to the continual dropping of support for older hardware by the GCC team. Another issue they had was the optimizations of the software increased the difficulty of debugging things as the optimizations varied every time they compiled the software. Thus LLVM was created with the goal of binary stability that could be easily debugged and that supported the many older peices of kit that freeBSD runs on instead of being forced to use GCC 1.2/1.5/2.1/2.2/2.3 and such.

Re:too bad GCC is not relevant anymore thanks to L (2)

Bill, Shooter of Bul (629286) | more than 2 years ago | (#40996895)

Gcc still blows the crap out of LLVM in several benchmarks. LLVM is great for many things as well. GCC needed competition to make sure it didn't get stagnent. Some of us still remeber the egcs period of time. Unless corperate entities were modifying the sources of GCC, I'm not sure why it matters.

Re:too bad GCC is not relevant anymore thanks to L (1)

larry bagina (561269) | more than 2 years ago | (#40997681)

Apple was contributing to gcc development under the GPL v2 -- ppc optimizations, objective c optimizations, bug fixes, etc.

Major *nix app using C++ (3, Funny)

PhrostyMcByte (589271) | more than 2 years ago | (#40996725)

I'll go get my cats-and-dogs umbrella.

Re:Major *nix app using C++ (1)

Joce640k (829181) | more than 2 years ago | (#40997491)

Linus must be screaming inside.

This is a good thing... (2)

Red4man (1347635) | more than 2 years ago | (#40996733)

.. and will lead to an even more reliable compiler toolchain.

Type unsafe... (1)

Anonymous Coward | more than 2 years ago | (#40996769)

GCC internals are lisp-written-as-C. *cough*

Re:Type unsafe... (2)

Carewolf (581105) | more than 2 years ago | (#40996935)

Yeah, that always freaks me out. GCC backends atleast are configured using LISP wrapped in C. I hope this is one of the things they clean-up, though, it won't be straight forward. LISP is quite powerful and fast as a machine language, it just happens to be unparsable by humans.

Re:Type unsafe... (1)

Anonymous Coward | more than 2 years ago | (#40997101)

((Yes ((LISP( is (quite) unparsable by) humans.))))

Re:Type unsafe... (2, Interesting)

Anonymous Coward | more than 2 years ago | (#40997553)

(not (quite_like (works LISP) you_say))

Re:Type unsafe... (1)

Anonymous Coward | more than 2 years ago | (#40997577)

At least the instruction descriptions could be fairly easily be converted into valid C++.
It would take a lot of work, but the basic structure maps fairly well to C++.
Each instruction is essentially A combination of several properties, each of which could be a field in a class.
The type would simply become the class.
In the simplest case the operand requirements would be a string variable just like they are now, and the predicates a list of function pointers.
More likely these would in turn also be converted into classes.
The actual production rules are already just C functions wrapped in a lisp like format, so no problems there.
The attributes can be again a list of strings.
There are more features, but all in all I don't see any great difficulty on that front.

The far harder part would seem to me, to rewrite the instruction scheduler, combiner and matcher to work on these objects instead of on whatever representation they use at the moment.

Probably even harder is the actual pipeline description.
Converting that into C++ would probably make it far to verbose to be useful, and I think it is mostly fine as is, although, it could definitely add some more support for certain features (or more accurately lack of features).

Incoming Torvalds' post (1)

Anonymous Coward | more than 2 years ago | (#40996777)

Hey folks, bring up your umbrellas, Torvalds has something to say about this.

Re:Incoming Torvalds' post (2, Funny)

Anonymous Coward | more than 2 years ago | (#40996813)

umbrellas? I'm getting some popcorn and a comfortable chair. this is going to be epic.

Next steps (1, Funny)

Anonymous Coward | more than 2 years ago | (#40996825)

The next step is switch from C++ to Java.
Then, finally, switch to PHP as the default language to build GCC.

Re:Next steps (-1)

Anonymous Coward | more than 2 years ago | (#40997011)

Nah, more and more colleges have determined Java is too hard for girls and is driving them away from computer science so now in the interests of diversity GCC will be rewritten in Python.

Re:Next steps (3)

xTantrum (919048) | more than 2 years ago | (#40997331)

I'm a hot chick at college studying computer science using Python. insensitive clod!

Re:Next steps (-1)

Anonymous Coward | more than 2 years ago | (#40997475)

Just because your boyfriend calls it that doesn't mean you're studying the LANGUAGE :D

RTFA (0)

Anonymous Coward | more than 2 years ago | (#40996835)

GCC needs to be compiled by a C++ compiler.

Since the GCC project also have a C++ compiler, I don't see the big deal.

Re:RTFA (1)

Joce640k (829181) | more than 2 years ago | (#40997651)

Listen more carefully. All the C diehards are screaming in rage.

Classes/Templates are not a magic bullet ... (2)

perpenso (1613749) | more than 2 years ago | (#40996849)

Given a collection of developers that write difficult to understand, difficult to maintain and sloppy type unsafe code, going to C++ may not help. The previous problems are problems with the developers not the language. C++ just enables such developers to write even worse code. Hopefully they are also introducing new coding style guidelines, and are willing to enforce such guidelines. If so I'd be more optimistic.

I'd also be more optimistic if by using classes and templates they were really referring to using STL, not writing their own.

Or maybe they just want to use C++ style comments and won't really use classes and templates much. :-)

Re:Classes/Templates are not a magic bullet ... (4, Insightful)

gbjbaanb (229885) | more than 2 years ago | (#40996929)

Bad code is bad code, and you can write it in any language, yes, even visual basic.net.

So the point is not so much "how useless are those lousy GCC devs who will write crappy code", but "how good are those GCC devs now they have a more powerful tool in their hands".

I'd hope they start to discover the STL too, and use the standard containers at the very least - no need to use custom ones unless you either continue to use the existing C-based ones, or you have some very specific performance issues that you absolutely cannot fix any other way (and generally, you don't have this problem with the STL)

Now, sure, I hope they don't discover cool new features like STL algorithms and start to litter the code with lamba-d functors.

bad_alloc (1, Interesting)

tepples (727027) | more than 2 years ago | (#40997025)

or you have some very specific performance issues that you absolutely cannot fix any other way (and generally, you don't have this problem with the STL)

On a platform with no swap file, such as a handheld or set-top device, one of the more common "very specific performance issues" is the ability to handle allocator failures. A program in such an environment is supposed to free cached or otherwise purgeable resources instead of just letting main() catch std::bad_alloc and abort. What are best practices for using the C++ containers if virtual memory is not available?

Re:bad_alloc (2)

squizzar (1031726) | more than 2 years ago | (#40997185)

Is he referring to using containers as part of the target application or as part of the compiler itself? The compiler internals might be much cleaner or there may be less redundant code for the compiler if it used STL rather than alternative or custom containers etc. Your target application would still only be using STL if you wrote code to use it...

Compiler has more RAM than target (1)

tepples (727027) | more than 2 years ago | (#40997555)

As part of the compiler, use of STL templates is perfectly fine because the compiler will be run on an system with plenty of virtual memory. In general, and especially for an embedded target, the machine where a compiler is run will have far more memory than the machine where the target application is run. This is starting to happen even on the PC, where whole-program optimization on a program the size of Firefox requires a 64-bit machine and a 64-bit operating system [slashdot.org] .

Re:bad_alloc (1)

Anonymous Coward | more than 2 years ago | (#40997199)

You're conflating two entirely different issues. C++ only addresses what happens when you run out of memory. Its cares not, and rightfully so, if that happens with or without virtual memory. Its also worth pointing out, many computers, even with paging, do not support Linux's notion of over commit.

Your question is best addressed by simply saying, design your application properly and it won't be an issue. If it persists to be an issue, then by definition, you do not have the proper hardware. Please note, this is at no point in time, a language issue or constraint.

Define properly (1)

tepples (727027) | more than 2 years ago | (#40997479)

Your question is best addressed by simply saying, design your application properly and it won't be an issue.

Thus the question becomes the following: How should an application written in C++ be designed properly for an environment with no paging?

Re:bad_alloc (2)

VortexCortex (1117377) | more than 2 years ago | (#40997339)

You write a damn exception handler block every time you have a "new". If you're using Linux and you run out of VRAM, it just starts killing processes until it has the memory. Its "optimistic" allocator doesn't throw std::bad_alloc -- is some really scary shit.

Re:Classes/Templates are not a magic bullet ... (2)

Rei (128717) | more than 2 years ago | (#40997697)

There are some cases where lambda-d functions improve clarity. For example, lambdas make for very clear, concise threading of simple tasks using the new C++11 threading operations.

Really, many of the new features play so beautifully together. For example, you can write a simple packet reader/parser which:

* Loops indefinitely
* Waits until data can be read
* Spawns the processing of that data in its own thread and resumes holding and processing packets, while in the spawned thread:
* Proper type of packet is determined
* Appropriate packet object is created
* Packet object processed
* Packet object deallocated

Using code one-liners like:

while (true) { auto PacketData=ReadPacket(); thread([]{ MyPacketFactory(PacketData)->RunPacket();}).detach(); }

or

while (true) { thread([](auto PacketData){ MyPacketFactory(PacketData)->RunPacket();}, ReadPacket()).detach(); }

Now, it's stylistically better to spread it out over a couple lines, and the above assumes that you're "using" std, have written your packet factory and socket reader, etc. However, it gives you an idea of how powerful the new features are. In normal code I'd probably write something like:


while (true)
{
      std::string PacketData(ReadPacket());
      std::thread([]{ MyPacketFactory(PacketData)->RunPacket();}).detach();
}

Again, to reiterate, this is just from memory; I've not tried to compile these.

Re:Classes/Templates are not a magic bullet ... (3, Informative)

Marillion (33728) | more than 2 years ago | (#40997001)

The Linux Kernel used the C++ compiler for a while. I believe it was during the 0.99.x era. The goal was to improve the code quality by leveraging C++ compiler features like function name mangling while only using C language features. This, however, looks like they want to use a limited set of C++ language features that would be very handy for experienced C programmers.

Re:Classes/Templates are not a magic bullet ... (5, Informative)

serviscope_minor (664417) | more than 2 years ago | (#40997015)

Given a collection of developers that write difficult to understand, difficult to maintain and sloppy type unsafe code, going to C++ may not help.

It is very difficult to write easy to understand, type-safe, code in C.

The reason being that C requires so much micro-management that you end up with the code for that mixed in with the actual interesting algorithms. C++ basically makes the compiler do an awful lot of what you have to do in C anyway and does it for you automatically while keeping the details neatly out of the way.

It's also very hard to write type safe code properly in C. Just look at the classic example of the unsafe qsort versus the safer and faster std::sort.

I'd also be more optimistic if by using classes and templates they were really referring to using STL, not writing their own.

What on earth is wrong with writing your own classes and templates? They almost certainly already have a healthy collection of structs with function pointers and macros (linux certainly does have poor reimplementations of half of C++ using macros). These are best replaced with classes and templates on the whole.

That's the point. C++ formalises what everyone was doing in C anyway, making it much more uniform, easier to read, shorter and therefore much less prone to bugs.

Re:Classes/Templates are not a magic bullet ... (1)

cras (91254) | more than 2 years ago | (#40997929)

It's also very hard to write type safe code properly in C. Just look at the classic example of the unsafe qsort versus the safer and faster std::sort.

You can do all kinds of nifty stuff with macros and gcc/clang extensions to provide type safety to C. Yeah, if you don't already have a library for that it can be a bit difficult to write one (or find one you like). But once you have the library it's very easy to write (mostly) type safe code with C. For example I have a type safe array_sort() in C.

Re:Classes/Templates are not a magic bullet ... (0)

Anonymous Coward | more than 2 years ago | (#40997133)

I find that jerks who bitch the most are often the worst at writing code, sorry just sayin. Big ego = ass hat to work with and awful at writing code. C# might work out better for ya.

Re:Classes/Templates are not a magic bullet ... (4, Funny)

ArhcAngel (247594) | more than 2 years ago | (#40997361)

I find that jerks who bitch the most are often the worst at writing code, sorry just sayin. Big ego = ass hat to work with and awful at writing code. C# might work out better for ya.

Shouldn't that be:
Big ego == ass hat

Re:Classes/Templates are not a magic bullet ... (4, Funny)

Surt (22457) | more than 2 years ago | (#40997589)

No, it's definitely an assignment.

Re:Classes/Templates are not a magic bullet ... (1)

Joce640k (829181) | more than 2 years ago | (#40997671)

going to C++ may not help.

I dunno. I don't see what business non-C++ programmers have working on a C++ compiler. One of the problems might be that they're still using malloc() and strdup().

Re:Classes/Templates are not a magic bullet ... (0)

TheGratefulNet (143330) | more than 2 years ago | (#40997759)

when I first experienced C++ and the trash that most developers put out, I started calling c++ 'write-only code'. you can write it but you can't ever read it back, years later.

I still stand by some of that. almost any task can be written clearer in c than c++. c++ does not give much, in reality, for 99% of what people tend to use a language for.

having spent a few decades on c and c++, I still prefer c and avoid c++ as much as I can. over time, it just has not won me over.

I don't write 'university code' though; and I'm not out to impress a professor or win 'elegance awards'. I write simple code that runs and is easy to support. the only time I'll choose c++ is if a project is already written in it, and heavily invested in it. any new project of mine will not be c++ based.

been coding since I was in my teens and I'm in my 50's now. years of experience has not shown c++ to be any benefit in any real sense.

In another news... (1)

CuriousKumar (1058312) | more than 2 years ago | (#40996865)

.... In a recent report submitted by group of "Expert Consultants", GCC was found to be "too functional" and having "no orientation", and recommended GCC devs to develop some "Class" within and become more "Object Oriented".. ;-)

Re:In another news... (0)

Anonymous Coward | more than 2 years ago | (#40997819)

Perhaps you could cite something so someone could figure out what the fuck you're talking about.

oh nooos (-1)

Anonymous Coward | more than 2 years ago | (#40996871)

That is a baad idea. C++ adds unnecessary complexity, and in many cases unless the compiler is really smart it wont be able to deduce and short-cut polymorphism etc and you'll end up losing optimization possibilities. Also as a general rule if you're not careful and the programmer tends to get over-enthusiastic with advanced C++ features and you get run-away code: bloat, slowness, polymorphism and other run-time tracking overhead and lost optimizations. Please noooo!

Re:oh nooos (2)

Samantha Wright (1324923) | more than 2 years ago | (#40996957)

RTFS—GCC itself is becoming a C++ program. It'll still compile stuff the same way. (Optimizing your compiler is for Gentoo users and communists.)

Re:oh nooos (2)

petermgreen (876956) | more than 2 years ago | (#40997231)

Which is a complier more likely to be able to optimise? polymorphism that is explicit in the language or polymorphism that is hacked together by creating vtables (which are basically structures full of function pointers) manually? Which is more likely to have mistakes made that associate the wrong vtable with an object?

C++ has it's problems but it's the only widely supported language that both provides OOP features and yet still allows the writing of tight code where needed.

Compiler bootstrapping? (5, Interesting)

Ynot_82 (1023749) | more than 2 years ago | (#40996901)

How will this affect bootstrapping the GCC on bare systems?

Been a while since I've delved into LFS or the like, but I'd think GCC being C++ based would seriously complicate things as it's now got more dependencies.

Re:Compiler bootstrapping? (2, Insightful)

Anonymous Coward | more than 2 years ago | (#40997179)

Not much.

You can cross-compile all you like.

If that fails, and you find yourself on a system with only a K&R C compiler, you bootstrap to
an ANSI C compiler by going to gcc 2.95.n or something like that. Then you use that to get
to a fairly recent C-based gcc and finally use the resulting C++ compiler to compile the
final version of gcc.

More like "C with Classes" (5, Informative)

Megane (129182) | more than 2 years ago | (#40996949)

I've read their guidelines, and they're doing much like I've been doing recently with moving from C to C++ for embedded systems programming, which is to avoid the really crazy shit that you can do in C++. In particular, exceptions and RTTI are absolutely verboten. They're even planning a compiler switch that turns off the features that will be outlawed in the compiler source. Any templates outside of STL are also forbidden ("template hell" sucks), and I won't even use STL myself because I can't count on having a heap. Even iostreams are being frowned on except maybe possibly in debug dump code where no text language translations are needed.

C++ can really tidy up C code that uses any sort of function pointer hooks or object dispatch style switch statements with virtual methods. A class can become a mini-API, and even used as a sort of device-driver, as in the mbed [mbed.org] libraries. Doing this has really helped improve encapsulation in my own code.

OOM inside STL (2)

tepples (727027) | more than 2 years ago | (#40997071)

In particular, exceptions and RTTI are absolutely verboten. [...] Any templates outside of STL are also forbidden

What implementation of STL do you recommend for low-memory systems that have a heap, albeit not a very big one, where you don't want to crash upon running out of memory?

Even iostreams are being frowned on

In my experience (quarter megabyte static hello world), <iostream> would be the first to go, in favor of <cstdio>. See what else I've written about the pitfalls of C++ on small systems [pineight.com] .

Re:OOM inside STL (0)

Anonymous Coward | more than 2 years ago | (#40997471)

Your "Templates" section requires some work. Your first point is completely true and accurate. Your second point, however, is extremely misleading. Your point of contention is in no way specific to C++ nor templates. It equally applies to any langauge which supports structures and/or classes. That's not C++ nor templates specific issue. Period.

Your first point of contention about "Exceptions", is also false. People don't realize that exceptions do carry performance issues. MOST people simply fail to benchmark them properly. Many people are under the false impression that simply using or not using exceptions makes for a valid benchmark. This is almost universally false. Compilers which allow you to disable exceptions typically require an explicit compiler flag to tell it to disable exceptions. This is important as proper exception support requires different stack frames. Thusly, the performance delta stems from entirely different size stack frames, as required to support frame unrolling to support exceptions.

The rule of thumb for GCC based compilers seem to be 8%-10% overhead. Though clearly that will dramatically differ based on how you use exceptions, the depth of calls, and the nature of the specific application in question. Regardless, when properly disabled/enabled, exceptions absolutely do carry a performance penalty. Whether or not the penalty is noteworthy for your specific application is a different story.

Re:OOM inside STL (0)

Anonymous Coward | more than 2 years ago | (#40997487)

Even on a machine with limitless resources iostream should be the first to go, unless you seriously believe that

std::cout (bitshift left) std::hex (bitshift left) std::setfill('0') (bitshift left) std::setw(8) (bitshift left) x (bitshift left) std::dec (bitshift left) std::endl;

is somehow superior to

printf("0x%08xn", x)

(apoligies for the "bitshift left", Slashdot eats up the actual operator.)

Re:More like "C with Classes" (-1)

Anonymous Coward | more than 2 years ago | (#40997255)

I've been using C++ as "C with data structures", i.e. using the STL so I don'thave to write linked lists and stuff from scratch, but keeping my code as close to C as possible. A usable language tends to emerge from the cruft of C++ when I do that. I still have never been convinced C++'s baroque I/O system is any better than printf(). But the STL is better than any data structures I could write based on my Java-saturated, hazy memory of writing a C linked list in the 90s.

Re:More like "C with Classes" (1)

Trepidity (597) | more than 2 years ago | (#40997449)

If you just want more "batteries included" data structures than libc has, rather than anything else from C++ as an actual language, linking with GLib is a common alternative.

Re:More like "C with Classes" (1)

timeOday (582209) | more than 2 years ago | (#40997265)

They're even planning a compiler switch that turns off the features that will be outlawed in the compiler source.

That is an interesting avenue. As languages like C++ and perl can attest, languages can evolve by adding features but it's almost impossible to take them back. Having a compiler flag to enforce a coding standard is a way to do that less coercively.

Maybe this will result in a popular new dialect of C/C++.

Re:More like "C with Classes" (2)

Ed Avis (5917) | more than 2 years ago | (#40997543)

It's a strange mindset to see run-time type information, available by standard in widespread languages such as Java and C#, as 'really crazy shit that you can do in C++'. It carries a runtime cost and the only unusual thing about C++ is that you don't have to pay that cost if you don't use it. There is indeed crazy shit like compile-time Turing-complete template metaprogramming (the 'Vogon liver' that has grown way beyond its original intended purpose) but it's important to distinguish between that and language concepts which are quite normal and accepted in the rest of the world.

Re:More like "C with Classes" (0)

Anonymous Coward | more than 2 years ago | (#40997809)

It's crazy if you have the C programmer's "portable assembly" mindset. I actually learned more C++ before C. When I realized that my array of Boolean objects in C++ was an order of magnitude more memory intensive than the bit-arrays I could create in C, I became a C convert and never looked back. This is what I get for cutting my teeth with the roughly 40k of RAM available for my programs on the C-64. Keeping track of the fact that it's a pointer to a bunch of bits is a small price to pay for being able to reliably filter packets on a high-speed network.

Re:More like "C with Classes" (1)

Anonymous Coward | more than 2 years ago | (#40997937)

An array of Booleans in C is just as memory intensive as an array of booleans in C++. You known you can directly flip bits in C++ too. That's hardly a reason to stop using the language.

Re:More like "C with Classes" (0)

Anonymous Coward | more than 2 years ago | (#40997677)

At Google, exceptions and RTTI are also verboten. The code generated is still a heck of a lot more about C++ than C.

C++ with a style guide is vastly superior to C. Strings and vectors for those of us who do have a heap... private member functions and variables... inline functions instead of macros... namespaces... type safety on stuff like sort and callbacks... Never understood why anyone would choose C over C++. Yes bad people write bad C++ code, but bad people also write bad C code - just with different problems. Get good people and worry about which language is better for good programmers. IMO it's a hands-down win for C++.

Re:More like "C with Classes" (5, Informative)

Aidtopia (667351) | more than 2 years ago | (#40997827)

In particular, exceptions and RTTI are absolutely verboten.

Ignoring RTTI is fine, but forbidding exceptions requires a dangerous sort of doublethink. The language itself, as well as the STL, is defined to generate and use exceptions. By ignoring their existence, you banish yourself to a nonstandard purgatory.

For example, every new now must become new(std::nothrow). For every STL container type, you have to provide a custom allocator that doesn't throw. That's a bit unwieldy.

By denying exceptions, you force everyone to use error-prone idioms. For example, the only way a constructor can signal a failure is to throw an exception. If you forbid exceptions, then all constructors must always be failure-proof. And then you have to provide an extra initializer method to do the real initialization that can fail. Every user of the class must reliably call the init method after construction, which gets cumbersome when classes are nested or when you're putting instances into an STL container. It also means that objects can have a zombie state--that period of time between construction and initialization. Zombie states add complexity and create an explosion in the number of test cases. Separate initialization means you can't always use const when you should.

Exceptions are necessary to the C++ promise that your object will be fully constructed and later destructed, or it will not be constructed at all. This is the basis of the RAII pattern, which just happens to be the best pattern yet devised for resource management. Without RAII, you will almost certainly have leaks. Worse, you won't be able to write exception-safe code, so you are essentially closing the door to ever using exceptions.

Re:More like "C with Classes" (2, Insightful)

VortexCortex (1117377) | more than 2 years ago | (#40998037)

I've gone the opposite direction. Moving more of my C++ code into C by using my own OOP system. Before you say "That's crazy talk", consider that it makes inter-operating with my game's scripting language so much more buttery smooth than in C++ -- It's so nice to just create a new object in either script or C and have them talk to each other without going through a few layers of APIs, passing off dynamically allocated instances and having C free it, or the script GC it automatically.

Don't get me wrong, I love C++, but they have rules that are conflicting when you get "deep" into the language. Try using multiple inheritance and polymorphism... It almost works, but not if you have two base classes with the same virtual function names -- That's just one of many edge cases I ran into... Theres several corners we're forbidden to go where templates, type safety, and inheritance don't play well with each other...

After a while I just scratched my head, "Really C++? Really?!" Why would you have features that are incompatible? So long as I only use some of C++'s features some of the time, then everything is fine, but when I needed to use MOST of the language in the implementation of my scripting language, then shit hit the fan. Many experience people I look up to have told me if I need to use the WHOLE C++ language then I'm doing it wrong. To them I say: If you can't use the entire language at once then the Language is "doing it wrong".

C++ is great if you're only using C++, and C++ constructs. That you have to use extern "C" { ... } to make shared libs that will actually work with other compilers or languages is a serious show-stopper for me. Protip: method names are munged into unique C function names so you can actually compile "C++", ergo they need to standardize name munging rules but to do that would be to admit that C++ is mostly implemented as a fancy pre-processor for C...

Most of my C++ code was contained in extern "C" blocks, and I had abandoned most of the C++ features for my own language's simpler implementations, so one day I woke up and realized I should stop fighting C++ and just use C.

My problem was that I needed a language that let me closely express the construct of another language within it -- embedability was a prime factor. Sure I could write the VM in C++, and have a ton of interfaces and abstraction and overloaded operators, etc, but with C I didn't need to do that.

Some of the reasons I left C++ for are being fixed / added in C++2012, but it's too late for me. I'm not going back. I'll use C++ for my C++ only projects, but for anything that needs to work with other languages (most of my code), then I'll use C. Bonus: Instead of 15 minutes to compile the C++ implementation, it takes just seconds as C.

C has many pitfalls, but at least they're out in plain sight; Unlike the C++ pitfalls, which are hidden in corners, shrouded in "advanced feature" mystery, and blanketed by the fog of denialism -- When things that should work according to spec don't (because of the implementation details), then you do you really have a language, or is it just part of a language?

C++ has the same problem with C that I experienced with C++ -- When you try to implement a language in a way that's really close to another language, so you can use its underlying tool-chain, you run into a point where you must be shackled by the base language's implementation details... You can either build around the limitations (what C++ does), or you can embrace them (what I've done). Unfortunately I couldn't embrace the C++ implementation -- a complete one doesn't exist.

Awesome (4, Insightful)

Carewolf (581105) | more than 2 years ago | (#40996969)

GCC as a compiler and a community seems to really be moving, it is probably due to the competition from LLVM, but atleast for now, GCC is still the better compiler, and I wish them the best of luck.

Good compilers benefits everybody!

GCC should remain small and fast (-1, Troll)

JDG1980 (2438906) | more than 2 years ago | (#40997017)

A shame. I was hoping GCC would remain small and fast. A program written in C++ is going to be slower than an equivalent program written in C, no way around it. And that's without even getting into features like templates, which only five people in the world understand.

Re:GCC should remain small and fast (1)

arse maker (1058608) | more than 2 years ago | (#40997131)

A program written in C++ is going to be slower than an equivalent program written in C, no way around it.

Cite real world benchmarks please.

Re:GCC should remain small and fast (0)

Anonymous Coward | more than 2 years ago | (#40997367)

I know it's something else, but _compiling_ C++ code is sure horribly slow and uses loads of memory.
With gcc 4.7 they started using C++ and I haven't been able to compile that on a PPC Mac mini with 2GB of RAM without disabling any system service I could and not doing anything else on it.
gcc 4.6 could be compiled just fine, and you could even do some browsing at the same time.

Re:GCC should remain small and fast (5, Insightful)

serviscope_minor (664417) | more than 2 years ago | (#40997149)

I used to be more polite to ignorant C++ haters. But I've lost patience.

A program written in C++ is going to be slower than an equivalent program written in C, no way around it.

There is a way around it: by not being an astonishingly incompetent developer.

And that's without even getting into features like templates, which only five people in the world understand.

Don't assume everyone is as dim as you.

Re:GCC should remain small and fast (1)

Anonymous Coward | more than 2 years ago | (#40997389)

don't assume you're as smart as you think you are.

Re:GCC should remain small and fast (1)

xski (113281) | more than 2 years ago | (#40997439)

Thank you.

Re:GCC should remain small and fast (1)

ProzacPatient (915544) | more than 2 years ago | (#40997785)

Don't assume everyone is as dim as you.

Yeah! Not everyone codes in QuickBasic!

Re:GCC should remain small and fast (1)

Anonymous Coward | more than 2 years ago | (#40997261)

Small and fast?
Have you looked at the GCC source code?
I don't know about fast, since I haven't actually compared the performance to other compiler.
However, GCC contains all kinds of code for which using classes would be absolutely ideal.
Basically most things are already programmed into a kind of class, only using C.
By switching to C++ you can formalize all these things.
Instead of having to manually maintain a list with function pointers to specific functions that you need for a certain target,
or a certain scheduling pass you can make it into a class, and the compiler does all the work for you.
That eliminates lots of code right then and there.

For example, every GCC back end has to define specific functions that will be called by the compiler when transforming the RTL into instructions.
So somewhere in every back end there is a file with 100 or more defines of functions to specific macro names, that are in turn used in a different file to map the correct function that you define into an array of function pointers.
If instead you make a class that defines all the functions as abstract methods, all you have to do is inherit from that class and provide the implementation.
For every function that gets rid of one
#undef MACRONAME
and one
#define MACRONAME somefunction

There are examples of things like this throughout the source code.
The other advantage is that you can have the interface of a back end specified in a single class, instead of spread out over several header files that you have to know to look for.

Re:GCC should remain small and fast (1)

AvitarX (172628) | more than 2 years ago | (#40997537)

I guess SSDs change this, but I thought compiling was generally IO bound.

Will keep compiling C properly? (2)

Windwraith (932426) | more than 2 years ago | (#40997031)

That's all I really care about, to be honest. As long as I can keep coding in C, they can do whatever.

GCC Switches From C to C++ (0)

Anonymous Coward | more than 2 years ago | (#40997135)

... and there are still Mayan apocalypse deniers out there ?

captcha : doomsday :D

C++ is Dead, Long Live Java (5, Funny)

Anonymous Coward | more than 2 years ago | (#40997155)

C++ is as good as dead.

Everything should be written in java, since this would give a huge speed increase.

For even more speed, programs could be run on a java interpreter, running on a java interpreter written in java.

Think of the raw speed!

Re:C++ is Dead, Long Live Java (0)

Anonymous Coward | more than 2 years ago | (#40997311)

Agreed. And remember...the very FIRST program you should write in any programming language is "remove comments"...as we all know that spurious comments slow down your program at runtime. Plus, "remove comments" is far more useful than that utterly useless "hello world" program...

Re:C++ is Dead, Long Live Java (1)

BobNET (119675) | more than 2 years ago | (#40997343)

For even more speed, programs could be run on a java interpreter, running on a java interpreter written in java.

It's Java interpreters all the way down!

Stupid Answer Follows (0)

Anonymous Coward | more than 2 years ago | (#40997197)

Aslong I can write my own C Compiler, I do not mind.
I wounder if you other guys can say that about your favorit language?

Re:Stupid Answer Follows (1)

Ash-Fox (726320) | more than 2 years ago | (#40997767)

Could you write a spell checker first?

Are ABI compatibility issues still a problem? (0)

Anonymous Coward | more than 2 years ago | (#40997405)

I remember not too far back, new g++ versions forced all the C++ code to be rebuilt in your distro repository.
Is this a concern any longer?

Why Not (1)

sexconker (1179573) | more than 2 years ago | (#40997631)

Why rewrite GCC in inferior C++?
Why not "fix" GCC in C? Quotation marks because it wasn't broken to begin with (those terrible error messages must be a design decision at this point).

C++? (4, Funny)

Anonymous Coward | more than 2 years ago | (#40997795)

C++? seriously?

That's it, I'm switching to LLVM!

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>