User: Password:
|
|
Subscribe / Log in / New account

Re: Will therefore GDB utilize C++? Not.

From:  John Gilmore <gnu-AT-toad.com>
To:  Phil Muldoon <pmuldoon-AT-redhat.com>
Subject:  Re: Will therefore GDB utilize C++? Not.
Date:  Thu, 05 Apr 2012 17:34:50 -0700
Message-ID:  <201204060034.q360Yo0m007419@new.toad.com>
Cc:  mark.kettenis-AT-xs4all.nl, gdb-AT-sourceware.org
Archive-link:  Article

I introduced many of the "tables of C pointers" into GDB.  I could've
opted to switch to C++ at that point.  I did not and am happy that I
did not.  The paradigms we introduced were simple, maintainable,
useful, and documented.  I see nothing wrong with writing in C and
occassionally using a table of pointers (like the dispatch tables in
BFD, or the target selectors) where appropriate.  Just because you
sometimes call through a pointer, or arrange values in data
structures, doesn't mean you need to "move to an object oriented
language".  People who can't do object-oriented programming in a
procedural language perhaps don't understand object-oriented
programming, which is not about syntax, nor about enforcement, but
about deliberately choosing a narrower subset of mechanisms to produce
programs that are easier to maintain.

One of our original reasons for sticking with C is less relevant
today.  GDB is one of the first programs you want to bring up on a new
system, since it can help you debug itself and every other program.
To be useful for that, it needed to be compilable with a very broad
spectrum of relatively simple compilers.  Being written in C++ would
have foiled that.  Nowadays we merely cross-compile and cross-debug,
or emulate the target system from some well-supported host system.
Avoiding the need for a tricky, complicated, and working compiler to
compile GDB is less of a constraint.

I have not yet found an easy-to-maintain large production C++ program;
not in 1991 and not in the intervening 20 years.  I've written a
medium sized C++ program (smqueue).  Based on that experience, I was
never tempted to write a large program in C++.  I have found many C++
programs that are hard to maintain.  Hard to understand, hard to
compile, hard to debug.  As an example, I am currently wrestling with
a commercial success, a production program running at thousands of
sites, that took 12 years of a team of half a dozen programmers to
write and maintain in C++.  It now no longer even compiles, because
the recently graduated programmers who wrote it embedded questionable
C++ constructs deep into its infrastructure, and failed to document
the structures they were building.  I could and will rewrite the
broken parts, but it's very painful to even understand what they were
TRYING to do, because it's undocumented and wrapped up in layer after
layer after layer of templates and inclusion and C++ junk.  They
aren't making objects that have accessors and such; they're using a
"pattern language" that abuses C++ objects to do cheap runtime
type-checking -- or something!  It took hours to just narrow the
program down to a one-page program that would reproduce the compiler
error while being something a human could grasp.  Of course every C++
programmer denies that they are designing or writing a monster like
that.  However, a surprising number end up that way.  It is much
harder to screw up a C program beyond human recognition.  There's not
even a contest for Obfuscated C++, since it's trivial to do without
even intending to!  C++ fails at simplicity and predictability.

The 1990's idea that C++ was the obvious successor to C has clearly
been proven false over the last 25 years.  C is still here and going
strongly.  C++ was an experiment that disproved its thesis -- a
valuable contribution, certainly, but not an example to follow.  Even
the thesis that objected oriented programming is superior to
traditional procedural programming has been disproved (in my mind), or
is at least unresolved at this date.  I would say that over the last
20-40 years the key new insights in programming have been in
portability, simplicity, and pan-global collaboration of focused teams
(version control, automating distributed discussions and bug reports,
distribution, packaging, etc).  The mainstream of system and
application development continues in directions other than C++, such
as C, Java, and Python, not to mention big corners like PHP, C# and
Objective-C.

If you ended up writing parts of GDB in C++ and other parts in C,
anyone who did maintenance on it would have to understand both.  But
C++ is full of ugly traps for the unwary, and things seldom mean what
they appear to a C programmer to mean.  You'd narrow your potential
pool of talented contributors.  And you'd be basing your core debugger
on one of the least well supported parts of C++ -- its
interoperability with traditional C code.

I do not recommend that GDB use C++.

	John



(Log in to post comments)

Re: Will therefore GDB utilize C++? Not.

Posted Apr 12, 2012 7:25 UTC (Thu) by wahern (subscriber, #37304) [Link]

I'd agree with most of what was said whole heartedly except that so many people have drunk the C++ kool-aid that I'd fear for my family's safety. I'd disagree on the success of C++, however. The C++ user base is sort of like China; an inevitability looming on the horizon. Slower in coming than once thought, but unflagging all the same. Some of the last bastions of the C/Unix kingdom are falling beneath its penumbra.

The fact that it's mostly required at Google is a huge loss. Open source programmers, students, and schools are taking up C++ in droves, and unlike with the Java hysteria C will become a real victim. Though very few will ever get hired at Google, they and similar companies establish expectations regarding programming preferences and experience.

For example, the recent mosh announcement today... here we have a traditional BSD sockets and ncurses based program which requires, of all things, Boost! Seriously!? The end is nigh.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 12, 2012 9:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

And that's good!

Let's retire all the existing C programmers and move to something more secure. Finally.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 12, 2012 14:54 UTC (Thu) by smurf (subscriber, #17840) [Link]

Programming in C++ may or may not be "more secure". For some value of 'secure', anyway.
However, this is about programming and sanity.
Boost is a case in point. It consists mostly of Deep Template Magic. Debugging a program that uses Boost is an exercise in hair-pulling, assuming that you have any left.

Thanks, but no thanks.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 12, 2012 15:52 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

There are deeply magical parts of Boost. But most other parts are pretty useful. For example, variant types are great and easy to understand.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 14, 2012 16:45 UTC (Sat) by jzbiciak (subscriber, #5246) [Link]

To me, Boost demonstrates what can be achieved with a powerful metaprogramming language, and makes a strong argument for designing a strong, capable metaprogramming language into any new language.

It also demonstrates what talented hackers can achieve with mechanisms that were never intended to be used this way.1 They abuse the C++ type system and name resolution in ways that turn it into a poor-mans functional programming environment. It's a cute and useful hack when it works, but anyone who's looked at three pages of error-spaghetti when they make a 1-character typo understands that it's incredibly fragile.

I personally use both C and C++. My normal use model for C++ is to not get too fancy beyond what C can do, and mainly just rest on its stronger type checking to catch my errors. I also love namespaces for segregating symbols from each other. I also do the occasional templates to reduce case-and-paste when I need to implement the same function for multiple types, and the function is bigger than what you might put in a macro. Otherwise, for random programs, I fall back to C or Perl depending on the need.

In fact, the features I use the most in C++ (namespaces, stronger type checking, template functions, overloaded functions) could find a home in C without really breaking C, if they brought them in carefully enough. Although, I can see reasonable people disagreeing, strongly even.


1 The C++ type and name resolution system was discovered to be a functional programming environment almost entirely by accident. Famously, its computational capabilities were first demonstrated at a standards committee meeting, where Erwin Unruh demonstrated a program that produced prime numbers in error messages at compile time.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 15, 2012 12:27 UTC (Sun) by jwakely (subscriber, #60262) [Link]

> It also demonstrates what talented hackers can achieve with mechanisms that were never intended to be used this way.

But those clever hackers influenced the future direction of the language, making metaprogramming an integral part that _is_ intended to be used that way now, so C++11 provides variadic templates and extended SFINAE and cleans up a number of warts, all making the mechanisms more regular and more powerful. (Which may well make some people like C++ even less, but noone forces you to use those features, they're there for library authors to simplify writing the kind of libraries found in Boost.)

> It's a cute and useful hack when it works, but anyone who's looked at three pages of error-spaghetti when they make a 1-character typo understands that it's incredibly fragile.

Things should (I hope) improve. The ability for library authors to remove functions from overload resolution (à la enable_if) are a sort of "concepts-lite" that can prevent cascade of unrelated errors, static assertions can reduce an invalid instantiation to a single error. Library writers have more tools available to make more robust template libraries with more user-friendly failure modes. And compilers can do more to help too.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 15, 2012 14:20 UTC (Sun) by jzbiciak (subscriber, #5246) [Link]

Hopefully things will improve. But, for much of the C++ I write (on an embedded DSP, or on an embedded ARM using an outdated version of RVCT), C++11 will remain a fairy tale for some time. I don't expect to be able to write a lambda expression on either for another few years at a minimum.

But those clever hackers influenced the future direction of the language, making metaprogramming an integral part that _is_ intended to be used that way now, so C++11 provides variadic templates and extended SFINAE and cleans up a number of warts, all making the mechanisms more regular and more powerful.

It will remain true, though, that they had to fit within the existing C++ framework, and not break (too much) existing C++ code. If you were to design a powerful metaprogramming language to overlay onto a C++-like language from scratch, would it look like C++11? (Say, start with C++ of a few years ago, subtract whatever you like, and then add a proper metaprogramming environment of your own design.) There is some ugliness in C++ that can't be deprecated without breaking compatibility with C++ as it is.

Scott Myers' books are invaluable for understanding the best ways to use these features, IMHO. C++ definitely gives you more than enough rope to let you shoot yourself in the foot. In fact, it can take your whole leg off while you trip over it.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 16, 2012 11:58 UTC (Mon) by jwakely (subscriber, #60262) [Link]

It might look like Vandevoorde's Metacode, but that stalled
http://www.vandevoorde.com/Daveed/News/Archives/000015.html

Re: Will therefore GDB utilize C++? Not.

Posted Apr 12, 2012 16:24 UTC (Thu) by tshow (subscriber, #6411) [Link]

Something more secure, sure. But it won't be C++. C++ is a security disaster.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 12, 2012 17:02 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

C++ is certainly better than C in security matters.

Just the ability to use real strings does wonders.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 13, 2012 1:14 UTC (Fri) by kjp (subscriber, #39639) [Link]

c++ #1 feature: destructors. c code is a mind numbing percentage of gotos and error cleanup.

strings, containers are alright. std::string badly needs someone with a clue to add some more useful methods. templates good when needed.

But yes, c++ does WAY too many things for you that you usually do not want. conversions, copy & assignment, not zero initializing memory... why can't people make things safe and simple by default?? It's also **extremely** hard to parse, which is why things like cppcheck still can't reliably find simple uninitialized problems... static analysis of c++ is too damn hard.

I'm not terribly excited about go either, unfortunately.

Maybe what I want is a language that has the syntax of go but "compiles" to straight c++ source code, after doing sanity checks that c++ *should* have done.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 13, 2012 1:22 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Unfortunately, most of complexity of C++ stems from its manual memory management.

Automatic conversions are needed to create wrappers automatically, for example. Copy/assignment/moving are necessary to keep track of wrapped objects in a natural way.

Try to do a mental experiment - create a language with manual memory management and automatic destructors. You'll get something that is quite close to C++.

But yeah, templates could use some overhaul along with non-zero-initialized POD members of structs/classes.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 13, 2012 9:08 UTC (Fri) by dgm (subscriber, #49227) [Link]

If you cannot have automatic destructors without foobaring the language, then let's have them manual and keep simplicity. Simplicity trumps all.

Regarding automatic-anything, actually it's one of my few gripes with C++. It does too much behind your back, to the point of being surprising sometimes (automatic copy constructors is my favorite pet peeve).

An ideal C++ alternative should try less hard to automate, and instead focus on being simple and predictable.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 13, 2012 15:58 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

"Simplicity is worse than thievery" - Russian proverb.

'Simple' C code rarely is. It just has to do everything manually or use less efficient mechanisms.

>Regarding automatic-anything, actually it's one of my few gripes with C++. It does too much behind your back, to the point of being surprising sometimes (automatic copy constructors is my favorite pet peeve).

C++ doesn't do a lot behind your back and autogenerated copy constructors are about the only part where C++ compiler does something complex and explicit.

Other than that, C++ gives a programmer tools to allow thinking on higher levels about the problem at hand. And it helps - look at Mesa, for example.

>An ideal C++ alternative should try less hard to automate, and instead focus on being simple and predictable.

That's C.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 13, 2012 16:51 UTC (Fri) by jwakely (subscriber, #60262) [Link]

Now that C++11 provides an explicit way for you to say you want the compiler to define a copy constructor for you:
   Foo(const Foo&) = default;
the implicit declaration of a copy assignment operator is deprecated. And vice versa. So (hopefully) in a future version of C++ if you have declared a copy constructor the compiler will not implicitly declare an assignment operator and vice versa (on the basis that if you needed to write one manually then implicitly-defining the other one probably won't do the right thing.)

It's also now simple to tell the compiler not to generate them implicitly if you don't want them:

   Foo(const Foo&) = default;
   Foo& operator=(const Foo&) = default;

Re: Will therefore GDB utilize C++? Not.

Posted Apr 12, 2012 22:18 UTC (Thu) by ncm (subscriber, #165) [Link]

Language wars are dull, but quarrels over how to implement "object-oriented" designs are ever so much worse (though still less bad than those over box-and-arrow modeling conventions). Object-orientedness is just nowhere near as interesting as the book trade and the Java promoters insisted in the '90s. C++ developers spent their '90s on other topics.

You might think of O-O as the Monorail of the programming world.

Re: Will therefore GDB utilize C++? Not.

Posted Apr 13, 2012 16:42 UTC (Fri) by jwakely (subscriber, #60262) [Link]

Quite. I couldn't figure out why he kept talking about OO in a post about C++.


Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds