Slashdot Mirror
GCC Switches From C to C++
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.
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?
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.
Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
I'll go get my cats-and-dogs umbrella.
.. and will lead to an even more reliable compiler toolchain.
Sock Puppets: damn_registrars=pudge_confirmer=jimmy_slimmy=raiigunner=cml4524=a_klavan=red4men=ronpaulisanidiot
No, no it does not mean anything of the sort.
GCC internals are lisp-written-as-C. *cough*
Hey folks, bring up your umbrellas, Torvalds has something to say about this.
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.
The next step is switch from C++ to Java.
Then, finally, switch to PHP as the default language to build GCC.
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?
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.
Does LLVM have features for coverage analysis to compare with GCOV?
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.
.... 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".. ;-)
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.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
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.
Well.. maybe. Or Maybe not. But Definitely not sort of.
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.
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.
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.
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.
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 libraries. Doing this has really helped improve encapsulation in my own code.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
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.)
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
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!
I think there are a few non-ARM embedded platforms that use gcc. AVR (even the 8-bit variants) has a good gcc port.
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Also Coldfire, and a bunch of those MIPS spinoffs, IIRC.
Someone had to do it.
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?
That's all I really care about, to be honest. As long as I can keep coding in C, they can do whatever.
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.
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.)
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.
dont forget broadcom mips is also compiled using gcc, and that is a very large chunk of the embedded market
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.
... and there are still Mayan apocalypse deniers out there ?
captcha : doomsday :D
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.
SJW n. One who posts facts.
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!
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.
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.
Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
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.
Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
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?
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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.
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.
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.
don't assume you're as smart as you think you are.
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?
Thank you.
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?
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.
I guess SSDs change this, but I thought compiling was generally IO bound.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
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.
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.
Apple was contributing to gcc development under the GPL v2 -- ppc optimizations, objective c optimizations, bug fixes, etc.
Do you even lift?
These aren't the 'roids you're looking for.
Don't assume everyone is as dim as you.
Yeah! Not everyone codes in QuickBasic!
C++? seriously?
That's it, I'm switching to LLVM!
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?
Where are we going and why are we in a handbasket?
LLVM was created by freeBSD due to the continual dropping of support for older hardware by the GCC team.
Wrong!
The LLVM project started in 2000 at the University of Illinois at Urbana–Champaign, under the direction of Vikram Adve and Chris Lattner. LLVM was originally developed as a research infrastructure to investigate dynamic compilation techniques for static and dynamic programming languages.
properly handling C++ template can be a very CPU-bound process unfortunately.
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.
Since when was LLVM created by FreeBSD? o.O
No. 22 more years has seen Challenger and Columbia blow up, and we've learnt some lessons about things we should do and things we shouldn't do. Just as the Challenger investigation didn't conclude, "Ban O-rings," nobody has decided to ban parts of C++, either.
C++ is in some ways like a human language: It has an enormous range of things you can say in it. Some of them are only appropriate in certain situations. Some of them are never appropriate if you want people to take you seriously. Some of them just plain don't make sense.
So quite a lot of the development over those 22 years has been in the community learning idioms that let you use the power of C++ without hurting yourself.
Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
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.
I harbor no thoughts of superiority with C++, but I have used a book called Effective C++: 55 Specific Ways to Improve Your Programs and Designs and get very good results. I haven't benchmarked against equivalent C programs because I am not getting paid to write two versions of the same program. If you have any additional tips for good C++ performance, I would be very grateful.
http://www.boost.org/
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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?
I like cuties. Especially petite brunette ones. I'm not, however, so hung up on what development tools they use. I'm much more interested in their other attributes!
As an aside, I don't think GPL has cooties.
Without C compatibility, there would have been no chance that GCC was ever rewritten in C++. It would have been too much of a task. As is, the C could gradually be amended to be C++ compatible (because C++ is not completely compatible to C) while at the same time continuing normal development, with the only restriction that all new C code must also compile as C++. And now the switch to C++ just means that from now on code that doesn't compile with C will be accepted.
The Tao of math: The numbers you can count are not the real numbers.
A program written in C++ is going to be slower than an equivalent program written in C, no way around it.
Please provide a code example of equivalent code that is faster in C.
I'd actually like to see a real-ish world example of C code that isn't valid C++ code.
It's unlikely it was programmed at all, unless you call calibrating a sensor "programming".
No, you've been trolled.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Does this mean that if decide to use the new GCC, I would be forced to using the GPL v3?
Regards,
MBC1977,
don't assume you're as smart as you think you are.
Who (apart from you) said I claim to be smart.
Without reference to whether I understand templates or not, I know many people who understand templates well and use them happily.
The OP is strongly implies he finds templates hard to understand (unless he's claiming to be at least the 5th smartest person in the world). He must be dimmer than all those people I know who do understand templates, then.
SJW n. One who posts facts.
Not entirely true. Apple always did what they should do, contribuing back their patches, etc. It still affected them. Xcode does all sorts of syntax checking on the fly. That's only possible because Clang allows them to link in its parser as a library. That wouldn't be possible to do with GCC (at least for non-open-source IDEs) because it licensed is under the GPL, not LGPL.
When all one has is a hammer, everything looks like a nail. When all one has is a static type checker, everything looks like a type. For C++ programmers obsessed with type safety, or for people working in a C++-like managed language, the fact that std::hex, std::setfill('0'), std::setw(8), std::dec, and std::endl have definite static types that can be checked at compile time itself makes them superior. But personally, I prefer the std::printf way because the way adds way too much state to a stream.
I harbor no thoughts of superiority with C++, but I have used a book called Effective C++: 55 Specific Ways to Improve Your Programs and Designs and get very good results. I haven't benchmarked against equivalent C programs because I am not getting paid to write two versions of the same program. If you have any additional tips for good C++ performance, I would be very grateful.
You might want to read the book More Effective C++ by the same author.
The Tao of math: The numbers you can count are not the real numbers.
Programmers can lose track of for how many different type combinations they have instantiated a template, causing code size to balloon. There is a common extension called extern template allowing for explicit instantiation, but it's not in C++98, and not all compilers support it.
[This] 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.
I still don't understand what you're trying to say about my point about "different type combinations" being wrong. I was referring to the fact that a lot of compilers instantiate templates by duplicating the object code one for each specialization, and you get one specialization for each combination of types, not just for each type.
That may be true but it was because GPL forced them to give back when Apple was still using gcc. Apple doesn't like giving back. They stated as much as their motivation for using llvm. They said that they did not want to have to share their code generation optimizations as their motivation for abandoning gcc.
If you like parasitic companies (in this case Apple, but there are many) leaching off your work, release with another license, but if you like a healthy community, GPL seems to be the best choice.
Although this whole thread seems to have veered way OT!
Apple started sponsoring LLVM long before the GPLv3 came about.
You're correct, but you didn't explain why and you're being a dick about it. I don't know why you are +5 informative when you should be -1 flamebait.
I could simply say, "haters gonna hate" :) .. however..
C++ haters by and large have good reasons. They may be ignorant but perhaps that's just because they haven't found the right reasons to give voice to their displeasure. I don't condone bigotry of any sort (even language bigotry), but the whole OOP push of the nineties with C++ at the forefront largely failed to deliver on its promises.
And I'm sorry, but even very intelligent teams of developers usually create a kind of OO spaghetti with C++. And I would not call them 'astonishingly incompetent'. Just normal. So C++ in my mind has proven itself NOT to be the right language for 'normal' developers.
Also a lot of the myths around C++ are not questioned enough by the rest of the community. Hence, sites like http://yosefk.com/c++fqa/
Basically it is assumed that Stroustroup and co. are gods and we're all blasphemers to question their direction.
And the whole "if you don't like it, don't use it" counterargument doesn't wash either. Many people are forced to use C++ and its esoteric feature set due to circumstances outside of their control. So they learn to hate. And they come here and post. So suck it up.
C++: "We only blew up a shuttle or two."
I don't know if this is the best hill to build your fort on, but as you will ..
In other news, Linux Mint forks GCC, calls it Angel Hair Pasta.
If you cannot alloc an object of 20 bytes or so, you've got problems no exception handling will solve.
One can in theory solve a failure to allocate 20 bytes by discarding a cached 1 MB object, which should allow a few myriad more such allocations.
Stallman is a gentleman with a name.
You on the other hand are a confused big mouth coward.
That may be true but it was because GPL forced them to give back when Apple was still using gcc. Apple doesn't like giving back. They stated as much as their motivation for using llvm. They said that they did not want to have to share their code generation optimizations as their motivation for abandoning gcc.
Do you have a citation for that? And what parts of their code generation are missing from the llvmCore directory of their open-source llvm-gcc or clang's CodeGen directory and not contributed back to the LLVM project?
Interestingly, and not so trollily, this is one fewer reason why clang is not as good as gcc... Clang's website gives a fairly unbiased report of where it's better/worse than gcc, previously, one of only 4 advantages of gcc was that it only needed a C compiler to build it, not a C++ one.
crap.
Any chance of just adding -Wtypedef-types?
Just having a warning for when you use a typedef type in place of an int or vice versa, or a typedef type of a struct or union whose first element matched the type of the parameter its being used in place of would be a huge improvement.
At one point in time, I went through the Mac OS X kernel and dealt with the functions that were supposed to be returning an errno_t value mixing in integers and other values not originally in the errno value range, but later in the range. Being able to typedef an enum to an errno_t and then having the compiler squawk when someone interchanged the value with an int would have been incredibly useful, not to mention fixing a metric buttload of HFS bugs that had to be fixed relatively manually instead.
The way LLVM works, this would be rather trivial (but the request has been outstanding to the Apple LLVM people for 3 years now); I'm told that adding it to gcc would be more difficult because it attempts to dealias things like simple typedef types as early as it can, and the metadata necessary to do warnings (or enforcement, for the -Werror case) is lost before the place it would need to be chacked.
Where by "invest in", you mean "write and give away their source code under the BSD license"... I'm not sure how that's not "what you should do".
Why don't you hang out on comp.lang.c++ and comp.std.c++ and see what "understanding templates" really means.
Most people who say they "understand X" only think they do. Although, usually they understand more than enough to be competent at what they're presently doing.
The actual language rules are vastly more nuanced than you realize. I'd bank on the fact that you're not an expert, because I know experts (even ones on the standards committees), and they don't say things like "I understand templates". And for a language like C++, with a fscking huge standard document, few to none know every little nuance in and out.
Templates are pretty ugly for anything but the common namespace-scoped functions and classes, which in a perfect world, is all you'd use them for. This gets horrible very quickly if they get nested, or, heaven help you, you need to delve into template meta programming.
Thankfully, C++11 added the constexpr keyword, which greatly reduces the amount of shit you need to involve templates in.
It stops you from writing tools, like editors, that use the compiler's various parts to do things like syntax highlight, dynamically show errors/warnings, analyse your source code, etc. without GPLv3ing your own code. Which, is rather exactly how "cuties" behave – the infect everything around them.
However, clang blows the doors off gcc in several different benchmarks... The current generally accepted conclusion is that clang and gcc produce roughly equivalently quick code, though clang produces it significantly faster.
That may be true but it was because GPL forced them to give back when Apple was still using gcc. Apple doesn't like giving back.
Yeh, clearly apple don't like giving back –that's why they wrote clang, and open sourced all of it under the BSD license.
The GPL doesn't force you to give back. You need to have a read of it, it only forces you to "give forward".
Apple has now fully embraced clang/llvm for a couple of reasons: it was legally very difficult to for them to integrate gcc tightly with their IDE (by which I mean they would have to GPL Xcode if they linked directly to gcc); it is technically very difficult to integrate with an IDE - apparently the gcc code base is a complete mess as far as integration with other tools is concerned.
Clang/LLVM is financed by Apple and it is released under an Open Source licence. Call that parasitic if you like but because of Apple (in part) you now have a clean modern compiler toolchain that's a credible open source alternative to gcc. If nothing else, it means that the gcc dev team now have an incentive to improve their product because they have competition.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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.
Actually if it only had near-compatibility with C and OO, it would have been a very nice and useful language. But then things went south and they added too many overloadable operators, a nightmarish jumble of rules for typecasting/overload resolution, exceptions that can't be implemented properly in modern application software, but add a whole new dimension of concerns that the programmer should always be aware of... Then they topped it all off with hideously overcomplicated templates. The standard libraries mostly have crappy and/or misguided design: practically non-extensible, bloat-inducing iostream, the bloatware generation templates that used to be called STL, and so on.
So now, real-world projects that use C++ for the useful things it does provide have to maintain coding guidelines to avoid shooting themselves in the foot too often.
My exception safety is -fno-exceptions.
Hah, Boost is a manifestation of all things that are wrong with C++.
My exception safety is -fno-exceptions.
Actually, no. If you just change 'struct' to 'class', and don't use virtual methods or templates, there is absolutely no bloat vs the same C code.
But to achieve this there is, however, a tradeoff. Which method actually gets used is determined statically at compile time by what you declared it as. If you declare an object pointer CBase* p, and assign a CSubclass* pointer to it, calling p->Foo will always call CBase::Foo and never call CSubclass::Foo. If you can't live with that behavior, then you were probably going to need function pointers anyhow, and for 4 bytes extra per struct you can make as many virtual methods as you want. If you needed more than one, only one vtable is created per class, as opposed to needing 4 bytes per function pointer in every instance of your struct.
When I first used C++ classes, I actually saved memory because it replaced code that had one messy uber-union that covered all kinds of different memory allocations for various sorts of thingies (and therefore enough for the largest was always allocated), and switch statements everywhere. Afterwards, each thingy got exactly the RAM it needed (from a fixed allocation pool managed by the base class, since this was on a SoC with 64K RAM) and the switch statements were replaced with virtual functions for each thingy. The code was significantly more readable, too.
But templates are indeed a mess. They cause code bloat because for every object type you want to use with a template, it generates a completely new function just like the others it created before, with the only changes being for the new type. This is in comparison to the Smalltalk style of Objective C, where you can write a single function to work on (effectively) anonymous objects. And the STL assumes you have a heap, which is often not the case in embedded systems programming. The only template I have used is one I created to handle a fixed length array of flag bits, because it made my code a little easier to read.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Which thesis clearly explains why no one uses Boost and it has zero developers, not to mention a dearth of creative ideas.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I suspect you are getting old. Challenger was actually 26 years (and a half) ago...
A program written in C++ is going to be slower than an equivalent program written in C
You know what? I have partially rewritten FFTPACK (originally Fortran, but there is also C and Java implementation) in C++. Result: source code shrieked to about 75% of C version, additionally I have got all precisions for free. Not only that: speed up from 0 - 10 % (depending on radives and N), mostly due to the use forward/backward transform multiplication factor of (+/-1) as "template value" parameter, which results in NOOP in the machine code. My plan is to to go further and shrink the source using radix as a template parameter, which would not only make the code cleaner but allow also recursively inline code for higher non-prime radix (which could again result in some speed increase).
FFTW is still generally faster (but due to SSE instruction optimizations, not because it is written in C), but FFTPACK is not far behind, for some N (with higher mixed radix of 17, 19, 23) it is actually significantly faster than FFTW (like several times, even with maximum "measured" runtime optimization of FFTW). But FFTW is a few hundred thousand lines (and expensive for commercial use), FFTPACK++ about 4000 lines, public domain. Multi-dimensional another 1000 lines or so. Granted you can "fake" some templates in C using macros but it becomes a mess and lose many template optimizations which c++ will do for you for free.
WTF? Templates are resolver at compile time, no overhead at run-time. Granted, templates can contribute to machine-code bloat (if sloppy written), but can also increase speed if you can use template-value parameter which you would normally use as passed variable (such as +/-1, enumerations, type-resolving variables and switches) . In general by using C++ it is much easier to resolve (once for all) many things at compile time (maybe with some machine code increase penalty, but smaller source code) instead of burning cycles at runtime.
I've never understood the hostility towards OOP. I've always seen it as nothing more than another great tool to use, but so many posters act as if OOP is some false god brainwashing the masses. My theory is they're taking the act of embracing OOP as synonymous with insulting C.
Look at the added java.io.PrintStream.printf() method that uses a variable argument list. Someone had to be a special kind of asshole to adulterate a strongly-typed OO-language with that bullshit when the obvious OO solution is an array for a second argument. That's the kind of modification made when someone is making a political point, not a design improvement.
I swear to God...I swear to God! That is NOT how you treat your human!
The third party libraries for it are pretty nice these days, too. I'd rather do threading in C++ with boost::thread than in Java. I've found boost::regex and boost::program_options to be a joy to work with as well. Eigen is also very nice if you need a math library.
Overall I've been quite enjoying working with it. It's not nearly as intimidating as it first appears, and the stuff you really need to know about it is pretty simple and easy to learn.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
LLVM and clang are library oriented. An IDE can reason a lot about the code using the API, much more than it could ever do if it just fork()'d and exec()'d "gcc" and parsed its warnings and error messages.
STL is ugly. Even the Qt framework provides a much cleaner and consistent alternative, than this "standard" library.
STL is also not good for any performance bound programs, not good at all. You can easily write code that looks nice, but silently kills your performance.
What about portability? C++ is much worse in it, the standard has too many vague or missing parts, particularly templates.
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.
Doesn't help. STL arrays are allocated on the heap, and that's a quite slower and more wasteful allocation form than on the stack. Sure, you can use C arrays, but guess what: out go type safety and STL algorithms and C++ idioms.
If you are writing efficient numerical code dealing with multidimensional arrays, chances are that you are working with a highly sophisticated library incompatible with the array representation of any other library, or having rather slow code, or using extern "FORTRAN", or having totally incomprehensible code with manual index arithmetic.
And don't get me started on the type conversion lattices.
most-often executed output code on earth', then yes, I guess you're right.
Don't forget mars, too. Can't seem to find the source, but pretty sure I read that nasa uses gcc.
I think you meant "standardized" rather than "widely supported." Objective-C can be considerably faster than C++, and the GNU compiler collection (GCC) does provide an implementation of Objective-C. I'd rather use that than C++. However, C++ is standardized by ISO/IEC whereas Objective-C has no comparable formal standard other than the documentation available from Apple. In addition, Objective-C technically has no formal libraries whereas C++ has , , etc. Simply put, C++ is a better choice if moving to an OOP language, even if the features used in the GCC source cause it to build and run more slowly.
I have been a captive in America my entire life. Everybody and everything uses customary units instead of metric.
The best use of classes is to organize code. So from the summary I would say that it is a smart move to be able to organize the code in a way that makes it more readable. You don't have to use all the ugly parts of C++ in order to get some benefit from it. Just stay away from boost/templates and it will be fine.
In fact that is has no effect on the end user is one of the topmost clause of the GPLs.
Not that that fact does much to stop the silly people who develop GPL software for windows from using it as a Click-Through EULA on the installers...
I think most 32-bit embedded still use GCC if they're not x86 based (and really very few are x86). 8 and 16 bit CPUs are more varied though GCC still holds its own. GCC is the most common C compiler ported to new architectures. Sure you can get the chip maker's preferred compiler but too many groups don't have the budget to pay for those especially when they come with a per-seat license. For one company we switched away from a commercial compiler with a good reputation to GCC and got faster and smaller code with amazingly faster compile times (though it was C++ and not C).
If things are in assembler then GNU assembler is just as good as the commercial ones, though it may tweak "official" assembler syntax slightly.
"So now, real-world projects that use C++ for the useful things it does provide have to maintain coding guidelines to avoid shooting themselves in the foot too often."
How is that not the case for _any_ modern language? Anyone write terrible code in any language. I've seen some Python that made me want to rip my eyeballs out (used tons of esoteric functionality... coupled with a design that made me question the person's sanity).
Coding guidelines are a good idea no matter the language. Keep everything consistent and make sure that the code remains maintainable into the future...
And the AVR I have used used a mix of GCC and GNU assembler. I think someone somewhere had an official commercial compiler for it but that doesn't help if it's not licensed for anyone in the company to use.
I have actually seen cases where companies license one commercial compiler for use in production builds while all the developers use GCC, out of concerns that the commercial compiler is more efficient while being too expensive to license more broadly. Over time there's pressure to dump the commercial compiler because it tends to be difficult to debug when the devs don't have access to the production compoiler, and because it turns out the expensive compiler doesn't really generate more efficient code.
"C++ is a horrible language." - Linus Torvalds
Current C++ style has abandoned any pretence of object oriented programming and the zealots will hammer on you until you adopt a bloated generics based programming style.
As for GCC I have noticed a very large decrease in compile times when switching from gcc to g++ on the exact same file, as in an order of ten perhaps. Now that's not such a big deal if it's just gcc being compiled itself by g++, as most people don't care how long it takes a third party to compile their compiler. But people who build their own cross compilers I'm sure will notice the long wait for the build to finish.
google it.
In those 22 years a lot of up and coming kids have decided that all programming should be done in web browsers or with scripting languages.
Of course it's not doom for traditional programmers because someone still has to write the efficient code to implement the scripting languages and their runtime system. (I could be wrong, some professionals who should know better still think reference counting for GC in a VM is a good idea)
How is that not the case for _any_ modern language? Anyone write terrible code in any language. I've seen some Python that made me want to rip my eyeballs out (used tons of esoteric functionality... coupled with a design that made me question the person's sanity).
Coding guidelines are a good idea no matter the language. Keep everything consistent and make sure that the code remains maintainable into the future...
That's true, but I haven't seen guidelines for Python forbidding whole language features for being broken by design. With C++, it's a sad necessity.
My exception safety is -fno-exceptions.
Since yesterday, I realized that `struct {...}` IS also a c++ class :-)
So I've started to re-write all of my source files with `struct` instead of `class` This way I am positionning my self more as in-between an old-geiser C programmer with a taste of the new C++ -- because shit is becoming so obscure and SHIT when used outside of the STL !!!!!!!
TI MSP430 too...
Hence, sites like http://yosefk.com/c++fqa/
Many of the assertions on Yossi Kreinen's C++FQA page have been soundly refuted, and many more are simply opinions (or, less kindly, rants). As with any language, there are valid criticisms of C++; the FQA page is not the best place to go looking for reasonable discussions on such matters.
- T
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.
Well, given that C is also lightning fast and dangerous as hell, all C++ does is bring kitchen sink into the equation. So long as it's a lightning fast kitchen sink, I don't see a problem with that.
Everything that C does, C++ does as well, at least as good, and often better. That's why it's so popular, regardless of being inelegant etc.
"So now, real-world projects that use C++ for the useful things it does provide have to maintain coding guidelines to avoid shooting themselves in the foot too often."
How is that not the case for _any_ modern language? Anyone write terrible code in any language. I've seen some Python that made me want to rip my eyeballs out (used tons of esoteric functionality... coupled with a design that made me question the person's sanity).
Coding guidelines are a good idea no matter the language. Keep everything consistent and make sure that the code remains maintainable into the future...
You are missing the point. Most languages, if not all, have coding guidelines, but compare guidelines for, say, Java, Python, or even C, with existing coding guidelines in C++. You'll see the difference in how much the later cuts through what is available in C++.
Pretty much most C++ coding guidelines (in particular for systems and mission-critical development) cut away templates, STL, i/o streams and exceptions. Boost and RTTI are certainly the most banned of things.
So you end up with a C-like language with native support for object-orientation, which is really not a bad thing. If you are lucky, you might get some limited usage of templates (limited in the sense that you have to demonstrate, but really demonstrate your usage will not *explode* into code bloat via template hoisting or what not). A few of the most used STL template classes, string, auto_ptr, map and list are typically permitted. In many cases, the later three are restricted to instances parameterized to void* or to references to a very restricted, audited set of subclasses.
The lack of exceptions forces a design based on error codes. The later is really not a great choice, but the semantics are clear, far clearer than exceptions as implemented in C++. And that's why sometimes people, out of painful experience, end up choosing C with simulated inheritance as a safer, more cost effective alternative.
One typical counter-argument is that people aren't intelligent enough to use C++ safe. Maybe so, but mental effort should be saved to harness a language most effectively in solving problems in a particular domain, not on knowing how not to blow your toes to pieces.
Actually, STL arrays (as in std::array) can be allocated on the stack. They have no overhead.
It seems you're referring to STL vectors (as in std::vector), which is an implementation of a dynamically-sized container, so, yes, it uses the heap—as does every other dynamic container I know of. That neither makes it significantly slower nor more wasteful.
False on all counts. C arrays can be used with type safety, with STL algorithms, and with C++ idioms.
apparently the gcc code base is a complete mess as far as integration with other tools is concerned
Lots of that was self-inflicted. GCC maintainers did not permit attempts to refactor GCC into smaller reusable component libraries, or import / export abstract syntax tree (AST) data. Granted, these things were difficult due to GCC's legacy codebase problems, but you couldn't even try. Your patches would be rejected.
It was pure Richard Stallman tinfoil hat paranoia. RMS believes that if you make GCC too modular, especially with interfaces that can't propagate GPL virality, it will inevitably become a wedge used to destroy GCC. You see, people could then write non-free programs to extend GCC in useful ways. And under RMS-ism, you can't have that. It's better for holy free software purists to live in hair shirts than to permit changes which might theoretically allow outsiders to tempt them with evil. So RMS used his influence with the FSF and GCC to block attempts to move GCC in that direction.
There was also a lot of provincialism. I believe C++ used to be unthinkable, but that tune may have changed due to the success of clang / LLVM, which use C++ features to good effect. GCC's ancient crufty internals have become a huge barrier to progress, and this sounds a bit like belated recognition of it. (They have to be worried about contributor mindshare going to LLVM family projects merely because they're so much easier to work on.)
Clang/LLVM is financed by Apple and it is released under an Open Source licence. Call that parasitic if you like but because of Apple (in part) you now have a clean modern compiler toolchain that's a credible open source alternative to gcc. If nothing else, it means that the gcc dev team now have an incentive to improve their product because they have competition.
Apple was very frustrated with the state of affairs I described above. They (and many other non-purist GCC contributors from the commercial sector) wanted to modernize GCC to make it more competitive with closed source compilers, but the FSF literally wouldn't let them. See also: the egcs fork, which also had its origins in FSF small-mindedness. However, after egcs effectively won that battle, the FSF was able to bring GCC back under its control. If Apple ever considered a serious attempt to fork GCC, no doubt that outcome played a role in deciding against it.
Ironically, the result is that now we have a complete, high quality alternative to GCC, it's not burdened by a horrible internal design preserved in amber by misguided distrust of outsiders, it's licensed more permissively, it's structured exactly the way RMS feared, it's not rigidly controlled by the FSF (which requires that everything contributed to GCC have copyright assigned to the FSF), deep-pocketed commercial GCC contributors are migrating to it because it's run by sane people, and nobody is using it to force proprietary software on the free software community.
Doesn't help. STL arrays are allocated on the heap, and that's a quite slower and more wasteful allocation form than on the stack.
What is an "STL array"? If you mean std::array, then no, it's allocated on the stack. If you mean std::vector, then that's a dynamically resizable array, and an analogous data structure written in C would still be heap-allocated - you'd just have to do malloc/realloc/free yourself.
Sure, you can use C arrays, but guess what: out go type safety and STL algorithms and C++ idioms.
Again, wrong. Since raw pointers are iterators, you can perfectly well use STL algorithms and other C++ idioms with C arrays. In C++11 it's even easier now that std::begin and std::end are defined as global functions, and overloaded for arrays, so you don't need to much around with pointers at all. Type safety is still there as well, since C arrays are typed.
But templates are indeed a mess. They cause code bloat because for every object type you want to use with a template, it generates a completely new function just like the others it created before, with the only changes being for the new type. This is in comparison to the Smalltalk style of Objective C, where you can write a single function to work on (effectively) anonymous objects.
The Smalltalk/Obj-C/Java approach, on the other hand, has a significant perf hit, because of that extra level of pointer indirection, and the requirement to shove everything onto the heap to get an object reference to it. In this case it's a trade-off between code size (a single implementation working via opaque pointers) and speed (specialized implementations, each working directly on values of the specified type). C++ chooses speed. If you want size, you can still do it without templates, same way as you do it in Obj-C - the standard qsort function shows how.
Gee, I guess shouldn't be using mspgcc with my MSP430's then, boy dp I feel dumb not using Keil.
Yes, but on slashdot everyone appears terrified of it.
Actually the exceptions that allow you to build non-GPL programs aren't necessary. Otherwise all art you produce with GIMP or text you write with Emacs would be GPLed as well. Stallman just added them to stop the FUD against GCC.
Boost has no concept of modularity. Try to distribute just a piece of it. It also gets regularly broken by compiler changes because they like to use bleeding edge constructs. Plus some of the functions are slow as heck because it can contain no assembly. Whereas say memcpy in the C standard library is usually optimized with assembly code. Try reading the includes in Linux for example.
The best implementation of exceptions I have seen is the one in Python. Exception just work. In Java you have to keep writing more and more handling code and the compiler squeals if you don't catch every single little dinky exception. In C++ the exception handling code often causes a SIGSEGV and you wonder what the heck happened in the first place. At least with C you know you don't have exceptions.
I could give a rat's a$$ about GCC. They blew it and will be replaced by LLVM/Clang industry-wide, sooner rather than later on.
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.
The fact that Debian is making it's packages LLVM/Clang ready to build against, especially for the obvious FreeBSD branch it should be abundantly clear that they are aware of the architectural advantages of LLVM/Clang/LLDB/Compiler-RT, etc.
I try to compile my C++ code with clang every single time a new Ubuntu release is launched. Clang is consistently much slower than GCC for me. Sure it compiles quickly with color messages, but the resulting code is slow as heck.
I've never had and of the problems you describe.
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.
Give me one example of a program written in C++ where less than half of the compiled result is bloat.
No, it's a straight-up troll.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
The GPL in general was the reason Apple invested in LLVM and Clang. Jobs has been hostile to Copyleft ever since NeXT was not allowed to get away with violating the GPL with their Objective C frontend. I'm still somewhat surprised that Apple continues to release CUPS under the GPL. Of course the difference there is that they hold the copyright so they can make any part of it proprietary any time they want. They have done so for OSX-specific parts.
I believe that gcc includes libraries that link to your code to make it compile. The analogy to GIMP would hold if gimp shipped with GPL clip art that, if used in your artwork, would force your artwork to be GPL. These libraries (the clip art) need to ship as LGPL / BSD / CC/ or something less copy left to let you use them and still keep your code non-GPL.
I used to be more polite to ignorant C++ haters. But I've lost patience.
Well then you've lost the argument before you've started. No one ever convinced anyone of anything by abusing them.
They should rewrite the thing in python. /ducks
C++ is awesomely powerful, incredibly fast and resource efficient, and between new high performance applications and existing codebases it will continue to be used for decades.
However, it also has a beastly learning curve and lots of corner cases, and while its execution speed is wonderful it's so complex that compilation times for non-trivial applications are slower than equivalent feature (but slower execution) applications written in most other languages. If you really need performance that only C++ can provide, use C++. If you have a team of brilliant C++ developers, use C++.
If you don't have either of those needs, you owe it to yourself to investigate alternatives.
I'm sure the people working on GCC are C++ experts, so I think that's a place where C++ is an optimal or nearly optimal choice.
The Java community is working around some of the design flaws in the language related to exceptions. As you probably know, RuntimeExceptions don't have to be declared or explicitly caught with try/catch, unless the developer wants to catch them. So I've seen tons of code in different open source libraries that wraps the core Java libraries with code that does try { doSomethingWithCoreJavaLibrary(); } catch (Exception ex) { throw new RuntimeException(ex); }
;)
Java keeps evolving, they keep adding new features and offering simpler syntax for common tasks. Maybe by version 11 or 12 it will be a language that won't make experienced Python, Ruby, Perl, and Lisp developers get sick to their stomach just reading it.
Ah, I see you're a conservative software engineer.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Yes, but GGGP said that using C++ would slow down GCC, I said that I thought compiling was IO limited, then GP said template usage is CPU intense (implying that using C++ within gcc could actually slow down a compile).
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
"Which thesis clearly explains why Boost has been used in approximately zero projects of consequence"
FTFY
not to mention a dearth of creative ideas.
Just because one has a creative idea, doesn't mean it should be used in code serving real-world needs. Especially if the code in question is meant to be reusable in a shared library, with a stable ABI and all.
My exception safety is -fno-exceptions.
NeXT bought sole rights to Objective-C from Stepstone long before the Apple merger. They also hold all rights to Objective-C and if they wanted to be vindictive they could cancel its inclusion into GCC, but the don't. Instead, they chose to produce a solution for the entire toolchain in LLVM/Clang. LLVM/Clang has come a long way in a very short time span since Apple invested in it giving us all a choice to leave GCC--a very welcome choice.
NeXT bought sole rights to Objective-C from Stepstone long before the Apple merger. They also hold all rights to Objective-C and if they wanted to be vindictive they could cancel its inclusion into GCC, but the don't. Instead, they chose to produce a solution for the entire toolchain in LLVM/Clang. LLVM/Clang has come a long way in a very short time span since Apple invested in it giving us all a choice to leave GCC--a very welcome choice.
Neither NeXT, Apple nor anyone else can "cancel" a Free Software release whether they hold the copyrights or not. Copyright holders can stop making new releases, but they can't take away code already released under the GPL. NeXT did release their extensions to GCC under the GPL for many years because they were depending on the large amount of work that others had put into it. They clearly valued GCC enough to relase their code under the GPL even though they would have preferred a different license. Just as NeXT benefited from GCC, others continue to benefit from NeXT's and Apple's contributions to it. This is a clear success for Copyleft because everyone benefited.
Now that Apple and others have put a large amount of work in LLVM-based compilers, they may be able to end their reliance on GCC, but it took many years and man-hours of work. Although there are plenty of good technical reasons for LLVM, I'm sure that not being required to share enhancements was a major motivation for Apple. That's not to say LLVM projects are a waste of time. It certainly is good that they exist and there is now more competition in the Free compiler space. Hopefully, LLVM projects will remain healthy despite their licenses. Governance and other aspects of the community are just as important or more so than license and there certainly are plenty of examples of permissively-licensed projects used and contributed to by many which thrive such as Apache and PostgreSQL.
So will gfortran convert in C++ now?
"I'm sure that not being required to share enhancements was a major motivation for Apple."
Probably not but they might have wanted the option. It's not hard to imagine some case where sharing development code might have given competitors information about upcoming Apple hardware designs, and Apple is as freakishly paranoid about that as the FSF is about people using unfree software.
The legal means that GCC used to prohibit various technical circumventions which the FSF believed would benefit "not-free" software, also prohibited a modular design which Apple wanted to, and then later exploited for significant benefit.
The FSF thought that ideology was more important than technical flexibility and capability. As a result, the experience of developing with gcc is about the same as 1989, whereas XCode can do many more things, because compiling programs to machine code is not the alpha and omega of software development tools.
The Java community is working around some of the design flaws in the language related to exceptions. As you probably know, RuntimeExceptions don't have to be declared or explicitly caught with try/catch, unless the developer wants to catch them. So I've seen tons of code in different open source libraries that wraps the core Java libraries with code that does try { doSomethingWithCoreJavaLibrary(); } catch (Exception ex) { throw new RuntimeException(ex); }
It's actually a subject of a holy war between two camps in software design. The "conservatives", should I say, hold that exception types are an important part of an API, and checked exceptions should be exhaustively handled accordingly to their types, possibly by being rethrown as exceptions classified in a higher-level functional domain. Unfortunately, this approach is enforced as applies to the standard libraries, to great inconvenience of the "liberals".
A more balanced approach would have been to allow exception specifications in method signatures, but not to mandate the handling violations to be fatal: the compiler can still generate warnings, and the developers can decide how seriously do they want to treat them.
My exception safety is -fno-exceptions.
"I'm sure that not being required to share enhancements was a major motivation for Apple."
Probably not but they might have wanted the option. It's not hard to imagine some case where sharing development code might have given competitors information about upcoming Apple hardware designs, and Apple is as freakishly paranoid about that as the FSF is about people using unfree software.
I'm hardly the only one to notice Apple's preference for permissively licensed software:
"GCC currently handles all those phases for compiling code within Xcode, Apple's Mac OS X IDE (Integrated Development Environment). However, there are some drawbacks to using GCC. One is that it is delivered under the GPL, which means Apple can't integrate it directly into Xcode without making its IDE GPL as well. Apple prefers BSD/MIT style open source licensees, where there is no limitation upon extending open projects as part of larger proprietary products."
The legal means that GCC used to prohibit various technical circumventions which the FSF believed would benefit "not-free" software, also prohibited a modular design which Apple wanted to, and then later exploited for significant benefit.
The FSF thought that ideology was more important than technical flexibility and capability. As a result, the experience of developing with gcc is about the same as 1989, whereas XCode can do many more things, because compiling programs to machine code is not the alpha and omega of software development tools.
The FSF has always put software freedom as their top priority. The reason we even know who they are is that they produced useful software based on their principles. GCC is certainly an old project that could benefit from newer approaches. Its limitations have much more to do with it being old than anyone's politics. That's why competition from LLVM is good for all of us, whether we use LLVM or GCC, which is being pushed to advance by LLVM. As interesting as LLVM is, far more platforms and developers still depend on GCC so the FSF's dedication to their principles continues to benefit everyone as well.
(XP searches would go dead into my boost zip file, so I erased eventually)
And Slashdot is?
You say they've been soundly refuted. Where? Links please.
If you can convince me that template meta-programming is a great idea, then sir, you have won the debate. Proceed ;)
Objective-C can be considerably faster than C++,
I'd like to see a source for that claim, the wikipedia article implies (but doesn't explicitly state) the opposite.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
And Slashdot is?
Only occasionally. The signal-to-noise ratio is awful, but cruising the C++ language stories (and sometimes Java and so on) at 4 or 5 sometimes leads to worthwhile posts.
You say they've been soundly refuted. Where? Links please.
Google is your friend; start with comp.lang.c++.moderated and go from there.
If you can convince me that template meta-programming is a great idea, then sir, you have won the debate.
Well, I'm not an evangelist, just someone who prefers opinions which are not emotionally based. C++ templates offer a bit more capability overall than C# or Java generics, but arguably less than LISP macros; admittedly, the syntax is ugly. I'd suggest reading Eisenecker & Czarnecki's Generative Programming (if you haven't already), to determine whether you consider generic programming to be useful, then decide whether the C++ approach is palatable to you. I don't know that I would describe C++ template meta-programming as "great" - it's just another tool to be used when appropriate. If it gets overused or inappropriately used by some programmers, that's not the fault of the language, but rather of the programmers, or perhaps of some of the tutorials which have been available.
We can find some definite problems, or at least a lack of specificity, in the C++98 standard with respect to templates and name resolution. For example, check out 9.2.2 and 9.3.5 in Vandevoorde and Josuttis's C++ Templates. AIUI, these were to have been corrected in C++11, but I haven't yet verified that for myself. I'm sure we could agree that no language is perfect. However, I believe we aren't well served by inaccurate, misdirected, and hyperbolic arguments; I hope we could agree on that, also. Unfortunately, the valid or defensible points in Yossi's FQA are buried in the morass, and perhaps this is where we won't agree.
- T
I assure you your refrigerator temperature thermostat was not programmed in GCC.
God I hope not. I don't mind if it's compiled in GCC, but if it's programmed in GCC I am quite concerned.
Even UNIX-types are finally embracing C++. Haha, this feels good.
You mean at compile time, right?
I don't know if it's intelligence that's needed to code C++.
The required credentials rather seems to be a great patience.
There are a few 16 bit platforms that obviously can't use GCC, so maybe most, but not all. Sometimes 32 bits are simply to wide for some embedded projects.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'