
GCC switches from C to C++ - Xyzodiac
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2b15d2ba7eb3a25dfb15a7300f4ee7a141ee8539
======
parfe
>>we'd have to get used to using auto_ptr

>auto_ptr is broken. We should use shared_ptr instead

It has begun!

One of the most enjoyable features of C++ is the arguing over which parts of
the language should be allowed.

~~~
Negitivefrags
Just to be clear, the replacement for auto_ptr is unique_ptr, not shared_ptr.

The vast majority of allocated objects have unique ownership semantics, not
shared. If you use shared_ptr everywhere, it's far too easy for your design to
degenerate into object soup.

~~~
TillE
> If you use shared_ptr everywhere, it's far too easy for your design to
> degenerate into object soup.

You mean that it's usually better design to have only one "owner" of an
object? That's true.

It's worth noting that shared_ptr is also necessary for containers, so you
might get into a habit of using it even if you're not creating multiple
references.

~~~
shrughes
shared_ptr isn't necessary for containers, it's only necessary for bad
containers.

Edit: Of course I'm being a bit stupidly snarky here, obviously if you have a
standard container you need a shared_ptr, or an intrusive_ptr, or some other
pointer, the moral of the story is that std containers aren't good for holding
owned pointers in C++03.

I don't think boost ptr_containers are particularly good either, but that's
mostly because of the huge cost of putting the string '#include "boost/' in
your code.

------
twoodfin
A useful discussion of the conversion and its motivation in the GCC Wiki:

<http://gcc.gnu.org/wiki/cxx-conversion>

~~~
emelski
Here's the rationale from that document:

* C++ is a standardized, well known, popular language.

* C++ is nearly a superset of C90 used in GCC.

* The C subset of C++ is just as efficient as C.

* C++ supports cleaner code in several significant cases.

* C++ makes it easier to write and enforce cleaner interfaces.

* C++ never requires uglier code.

* C++ is not a panacea but it is an improvement.

It's interesting to me how defensive many of those justifications are. "It's
just as efficient!" or "It's just a superset anyway!" Not until halfway
through the list do we get any real description of expected benefits: C++
makes it easier to write and enforce interfaces, and C++ supports cleaner code
in several significant cases. The last item is the most telling though: it's
clear that these developers feel they've hit a point of crisis, and they are
willing to take risks like this in order to lift themselves out of the
problem.

~~~
comex
> * C++ never requires uglier code.

No... but it sure tends to encourage it.

~~~
quotemstr
You've not seen ugly code until you've read 90s-era Win32 UI code written with
Hungarian notation everywhere. Ugly code comes from the programmer, not the
language.

~~~
sriramk
I blame the early Windows team by mistaking what Simonyi meant with Hungarian
notation by misunderstanding what 'type' means. Which is why Office uses his
notation in a much cleaner fashion.

~~~
oh_sigh
Can you give an example(or a link to an article discussing this)? I've never
had the displeasure of working with the Windows API(though I often shook my
head when I saw code for it)

~~~
sriramk
Basically he intended 'type' as not 'datatype' as in 'dwSomething' (for double
word) but the purpose of the variable. For example, if you're using an integer
variable to store the length of some entity, you would name it something like
'lenSomething' as opposed to 'dwSomething'.

Storing the type of the variable makes little sense as in most cases it is
only a quick grep away.

~~~
flogic
In the example you used, "context" seems to be a more appropriate word than
"type".

------
thefooest
this is apalling. The argumets seem to boil down to "I don't like VEC and how
hash-tables are done". Oh and the usual bs about interfaces. The result is
that now there is a monstrous dependency (a c++ compiler) in place of
something that an undergrad can build for a class (a basic C compiler).

I wonder what rms thinks of this. Too bad he is not calling the shots in gcc
anymore.

~~~
klodolph
It would take a smart undergrad a bit of hand-holding to write a C complier in
say, less than a year. (If you can write a C compiler, you should probably be
in the Masters' program.)

~~~
lmm
A nonoptimizing C compiler is pretty easy (a friend of mine wrote one in high
school), and that's all you need to bootstrap GCC.

He didn't even finish his parser for C++ though.

~~~
duaneb
Strictly speaking, C++03 can't be parsed, only interpreted (into a typed AST);
it is not a context free grammar.

~~~
klodolph
You can parse languages that are not context-free. "Parse" just means that you
figure out the structure of the file, the word has nothing to do with the
techniques used.

------
arturadib
"What would Linus do?"

~~~
emmelaich
I'm going to go out on a limb here and say that if he was writing a 'normal'
application or even a compiler he'd be tempted to use some subset of C++ or
maybe even Java.

As it is, for the kernel you'd be crazy to use something other than C.

~~~
luriel
> I'm going to go out on a limb here and say that if he was writing a 'normal'
> application or even a compiler he'd be tempted to use some subset of C++ or
> maybe even Java.

And you would be wrong:

<http://harmful.cat-v.org/software/c++/linus>

~~~
emmelaich
Well maybe. We won't and cannot know, because Linus will never be programming
websites for a bank or writing games for Windows.

My feeble point is that the kernel (and git) are computer programs for
computer people doing computer stuff.

Subsurface I'll give you. Mostly.

------
kingmanaz
It will be interesting to see the OpenBSD project's response to this.

~~~
dmm
OpenBSD has been using their own fork of GCC since the switch to GPL3. They
still use the last version on GPL2, 4.2.1.

Later versions of GCC are available as packages or ports but they aren't
included in the main system.

~~~
kingmanaz
I wouldn't be surprised if the folks at the project abandoned their branch of
gcc in order not to be "tainted by association". There is a revulsion to C++
that is close to the core to OpenBSD's philosophy. Perhaps pcc or clang will
get more attention.

~~~
dmm
The people in the OpenBSD project seem pretty happy with their toolchain. pcc
was removed from the source tree due to lack of progress. Making a really good
c compiler is hard and I don't think they have the people or interest at this
time.

I don't think they would switch to clang. LLVM is also c++.

~~~
kingmanaz
>pcc was removed from the source tree due to lack of progress.

That's a shame. PCC seemed an interesting alternative to gcc, though I do
recall PCC's v1.0 "revival" coinciding with an April Fools day several years
ago. Perhaps it always was to be taken as a joke.

OpenBSD's simplicity in implementation is laudable. The less moving parts
there are the less parts there are to break. It's the same philosophy that
keeps me driving my 25-year old pickup.

------
reacweb
build change to require a C++ compiler is a no go.

One of the reasons to install gcc on a machine is the absence of a descent C++
compiler. 20 years ago, the C compiler of Sun was completely broken and we
were happy to have gcc.

~~~
molo
Converting the stage 1 bootstrapping compiler to C++ is a bad idea IMO. There
any many embedded platforms without a C++ compiler (except perhaps downrev
gcc).

~~~
eliasmacpherson
so cross compilation is the only option for these embedded platforms?

~~~
mbreese
Don't you generally cross compile on embedded platforms anyway?

~~~
mansr
If you don't cross-compile, I would say it's not an embedded platform.

------
yason
The demise of gcc has begun. Not because I don't particularly like C++ but
because the folks actually have an interest to gradually start moving a C
codebase into C++ as if they didn't have better things to do. Sure, some
syntactic things will look cleaner (let's just exclude those that will look
uglier for the sake of fairness)--in five years or whenever their transition
could be considered complete.

~~~
klodolph
The GCC folks are feeling the pressure from Clang/LLVM, which is a good thing.
Under the guidance of the FSF, GCC has intentionally tangled the front end
with the back end. The purpose of this was to make it hard to modularize GCC,
because if GCC were modular, then you could write a proprietary component for
it (like you can write proprietary Linux modules).

Their goal here is to make it easier for new developers to write their own
passes or front ends or whatever. GCC may be more mature, but Clang/LLVM are
way easier to dive into.

~~~
ninjin
> Under the guidance of the FSF, GCC has intentionally tangled the front end
> with the back end. The purpose of this was to make it hard to modularize
> GCC, because if GCC were modular, then you could write a proprietary
> component for it (like you can write proprietary Linux modules).

Surely you must be joking... do you have a reference for this? Sure, I
sometimes the motives of the FSF but this would be quite outrageous from a
software engineering perspective.

~~~
mansr
<http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html>

~~~
noahl
Just out of curiosity, couldn't the FSF release GCC under the AGPL or
something like that and then modularize it all they want? That was my first
thought when reading that message. That way they can promote freedom and still
have modular software.

Of course, the AGPL might not have existed in 2000, but I haven't heard about
GCC moving to the AGPL since then either.

------
duaneb
Wow, I honestly never thought I'd see the day.

