| |||||||||||||
Re: Will therefore GDB utilize C++? Not.Re: Will therefore GDB utilize C++? Not.Posted Apr 12, 2012 14:54 UTC (Thu) by smurf (subscriber, #17840)In reply to: Re: Will therefore GDB utilize C++? Not. by Cyberax Parent article: Re: Will therefore GDB utilize C++? Not.
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.
(Log in to post comments)
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 (✭ supporter ✭, #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 (✭ supporter ✭, #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
|
|||||||||||||