| |||||||||||||
Re: Will therefore GDB utilize C++? Not.Re: Will therefore GDB utilize C++? Not.Posted Apr 13, 2012 1:14 UTC (Fri) by kjp (subscriber, #39639)In reply to: Re: Will therefore GDB utilize C++? Not. by wahern Parent article: Re: Will therefore GDB utilize C++? Not.
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.
(Log in to post comments)
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;
|
|||||||||||||