Pierre Phaneuf&#39;s Diary

yeah. and apparently several key developer agree with it, porting g++ to C++.

From:

I meant "porting gcc to C++"

From:

There's an "edit" feature on LJ now, by the way! Super handy for those quick slips. :-)

From:

only on paid accounts.

From:

Really? Bastards!

From:

not even plus. Yeah, bastards.

From:

The slides I linked to were in fact from one of the key developer doing it. All paid for by Google. ;-)

From:

Thanks. I know who is Ian Taylor, and who cuts his paycheck. I still haven't tried gold but that's because I'm very lazy (ie to rebuild the binutils)
http://www.figuiere.net/hub/blog/?2008/03/23/604-new-gnu-linker

And as for key developers, I meant "other than him", which means a larger inertia. Something required to introduce such a major change in the code base.

From:

This second article is awesome.

From:

He has the same employer as Taylor. ;-)

Incidentally, he's credited with coming up with the "don't be evil" motto. He's also the author of Solar Realms Elite, an awesome classic BBS door game which many of my friends wasted their time on.

From:

you should give a seminar to the Google HR drone. They seem to have a lot of things to learn on how to convince people.

From:

I think a bunch of the recruiters are contractors. Oh well.

What I personally like is that if I have a deep Unix question, I could ask Ken. If I have a hard C question, I could ask Brian. If I have a trick AWK question, I could ask any of Alfred, Peter, or (again) Brian. If it's about the inner workings of Mac OS X, Amit's the man, when it's more of a Linux thing, then Andrew's available (although I have to admit that just standing up in building 43 and stating your question out loud works just as well). Jeff Dean and Rob Pike are so smart, if they start thinking hard at the same time, time and space bends. On my second week, someone asked me if I knew whether we did XYZ, and my response was that I don't think XYZ is even possible, but I thought the same about ABC a week ago, and it turns out we've been doing it for a while!

It's just a plain ridiculous place. It's so crazy, they negociated my salary up. That's how wacky it is. Nothing makes any sense here.

From:

what I was saying. they should build new HR drone.

From:

I think one of my co-workers is right on it. :-)

From:

I'm afraid I still can't agree with you. C++ has weaker typechecking than C, since it is prone to chaining automatic type conversions (and the one example you cite of the converse is silly—why would you code 'void *' unless you meant 'void *'? You can use 'char *' if for some perverse reason you want to force casts), it has always been bloaty and now, with templates (the one semi-good feature, I grant), is exponentially so, and it is not, as C++ boosters always pretend, a C superset (it has different type conversions, different enums, a different interpretation of what 'struct' and 'union' declare, and lacks structure and array displays, among other things), and above all is too complex to write without the manual on your desk (consider, for example, something as usually simple as resolving an identifier).

I think the real proof that C++ is less than it should be is that its proponents are always dishonest in this way....

From:

The problem is not really when char* gets converted to void* (that's allowed in C++, even), but rather, when you specify that you need a Foo*, and it lets you throw about any random void* in. If I had meant to say that void* was okay, I would have said that. I'm afraid we're in disagreement on the point of finding casts evil, I think of casting as saying that, yes, I want hot sauce on that onion soup (you really don't want that to happen randomly, IMHO!).

I'm personally not claiming it's a C superset. If it were, obviously, any C program would compile straight off, but it doesn't. It just so happens that the bits that don't compile often are the bits that I didn't want to compile in the first place (any random integral junk passing off for my enum_t? I think not!).

You seem to refer to the bloat of the feature set, and personally, as long as compilation times do not suffer too much (and compiling a C-style program is pretty much the same), I'm personally fine with features I don't use existing. I'm pretty open minded when it comes to allowing difference to exist.

What I do find annoying is your last point. Complexity is bad, and you probably had something like argument dependent name lookup here, which is admittedly kind of nuts. I understand it was borne out of practicality, but eww.

But I have a really hard time believing that there's a significant number of practical programs that can be expressed in C and cannot be expressed in an equivalent way in C++.

The GNOME people, in particular, seem to be extremely hypocritical, as they are in the process of inventing their own object-oriented language that compiles to C. That kind of reminds me of Cfront, personally. Next, they'll be all happy about compiling straight to assembly, and will be talking of adding generics, I can see it right from here. You're quite right in that we could do much better, but if one is going to reinvent a crappy version of C++, bloody hell, C++ is right here, use it and shut up already...

From:

I'm certainly not advocating inventing anything worse than C++, but good grief, man, it isn't hard to come up with something better!

As to bloat, no, I was thinking of memory consumption. C++ is, contrary to initial expectation, a terrible enemy of code reuse, especially at the object level.

Finally, or perhaps initially, as regards void *: my point was that if you don't want the automatic conversion property, you are free not to code with void *! It's merely a kind of type conversion that is bound to the data instead of to the code, in case you want that. Certainly the language would, in the abstract, be better off without it, but the alternative would be parametric types and a distinct type for slabs of raw storage. That would be yummy, but C doesn't have it and nor does C++.

From:

The memory consumption of C++ when used in "C style" doesn't seem to be notably worse. There's some waste related to RTTI and exceptions, which you could turn off if you really don't use, and get back to pretty much the same as C.

When you get templates in there, though, yeah, it's not pretty.

It certainly is a solid case of "worse is better", but my opinion is that C++ is well within what C can do, plus some other stuff which I can use or not, to my fancy, so it's just like having more tools in the toolbox.

If it doesn't let code that calls a function but forgot to include its header (and therefore lets you call it with whatever you please!) compile as well, then so much the better. There's some compiler flag to make GCC behave in a similar way, but that's just silly.

From:

Well, the usual advice with C is to turn on all warnings and require clean compilation. The only thing that strikes me as ill-chosen in gcc's warnings is that for some reason they think that p && q || r is 'ambiguous,' which to me rather implies that someone was sleeping through ten years of schooling. But aside from that, I don't think it's silly at all.

As I say, the real objection to C++ is the extra debugging burden. When my C code compiles clean, it is normally correct. With C++, I haven't found the same thing. Now, maybe you have a point, in that if I were really determined never to use constructors, for example, then I wouldn't get perverse conversion chains. If I were really determined not to use templates, I wouldn't get strange name captures and compiler-specific failures to expand. If I were really determined not to use visibility control, I wouldn't have to deal with the rules about visibility from nested scope. But then, why am I not just using C, which doesn't have these flaws?

The problem is that none of the ways in which C++ extends C is really of high enough quality to motivate its use, and they all seem to introduce exposures in terms of code that does not do what it appears to do, ones that are often really hard to debug. I would rather just not have them present.

Perhaps what it comes down to is this: to me, programming is a sufficiently intellectual activity that I want to minimise the extraneous distractions and unnecessary complexities. The fact that writing C++ requires more non-problem-oriented concentration than writing Perl (and that is my experience) just amazes me, and is just not acceptable.

From:

Yeah, I often compile my C (and my C++!) with a dizzying array of -W options, including but not limited to: all, extra, error, strict-prototypes, missing-prototypes, undef... You still get a few extra warnings and errors in C++ (the latter demonstrating that it is not a superset, in a good way!).

You don't have to be all that determined to not use templates, not use constructors and so on. I find that just sitting in front of the monitor and doing nothing accomplishes that, which is not very much determination at all!

In a way, what I'm saying is related to turning on all the warnings: with GCC, "-x c++" is a fine diagnostic option to turn on for your C code. There's a few valid things that could be spurious (like a variable named "class" or something like that), but that particular cost is minimal compared to the return I get for it.

I've had cases where someone pretty smart had been debugging C code for a couple of days, and I found the problem in minutes that way. They were trivial buglets, but they were also buried in thousands of lines of code, which the compiler is much better suited to groveling over than even the smartest human.

I don't have a problem ignoring extra features, if they have no cost when left unused, I think that's the main difference in opinion that we have.

From: