Google Wants To Make C++ More Fun
Phoronix: Google Wants To Make C++ More Fun
Following the recent Phoronix article about an LLVM/Clang server (ClangD), here's some slides from a talk by a Google engineer about re-factoring C++ to make it more fun for developers...
I would use C++ more often (rather than C#, Java, or pretty much any other language) if:
1. Every single library didn't reinvent its own type system for integers and pointers. Seriously guys, just pick ONE nomenclature, ONE set of macros or whatever and stick with it! I'm tired of Boost, GLib, Qt, Mozilla, OpenSSL and a gazillion other projects having their own way of saying "I want an 8-bit integer" or "I want a 32-bit unsigned integer". It's absolutely ridiculous. This goes for standard data structures, too, like automatically growing heap-managed doubly linked lists. What's so special about you (some library writer) that you have to create your own list implementation? When it comes to data structures, unless you're doing something that makes an order of magnitude performance difference, you need to stop doing it and use STL... or we need to improve STL to the point that everyone can use it for their needs.
2. Header files were eliminated. Frankly, they are wasted keystrokes. Java doesn't need them; C# doesn't need them; and they both provide similar levels of object oriented features (or even more) than C++. For cases where you want to create a stable public API, you write an interface. It's still a separate file, but interfaces are much simpler than C++ headers, and you don't have to define an interface for every class, even the classes that you want to be callable by other classes. It takes twice as long to update an API in C++ than it does in Java or C# for no good reason. If the current language design requires headers to implement certain esoteric features like partial classes or having a bunch of symbols declared in one file and implemented in a bunch of different files, that's fine -- I'd say trash whatever language specifications that allow brain damage like that and design a language that doesn't need headers. We need a native programming language with high performance that gets object oriented code right (i.e. easy and low typing).
There's the D programming language.
Originally Posted by allquixotic
Agreed. D is a great language that hasn't got the following it deserves. I'm a Python man at heart, but if I have to go low-level, D is where I want to go.
Originally Posted by jayrulez
If there's a whole heap of different semantics when using libraries...that's not the fault of C++. That's the fault of the people making them, or the people trying to mesh them together. C++ won't hold your hand and won't try to force "proper programming principles" onto you - and this is on purpose. I recommend reading some of Stroustrup's FAQ for the reasons on why C++ is the way it is.
The fact that every single library redefines fixed-width integer types indicates a fundamental issue in the design of C++. Spinning this as a "feature" flies into the face of qint32, int32_t, boost::int32, GLint, DWORD and the dozens of other custom types that are written to work around this issue.
Originally Posted by mirv
The "performance" argument for is laughable at best. Using a native int type will not magically make your code faster when you recompile on a 16bit architecture - it will merely break your code, because a++ will suddenly overflow at 2^16 instead of 2^32 (and if you check for overflow then your code will be slower than if you used the correct fixed-width time from the beginning).
In short, bollocks. Every well-written portable library (re)defines the same basic fixed-width integer types and uses them exclusively instead of "int", "short" and the like. C99 realized this problem and introduced <stdint.h>. It's high time C++ did the same.
(As an interesting aside, the CLR handles fixed vs native integers in an even better way: integers are all fixed-width by default (int8, int16, int32, int64) and theres is a special "native int" type that conforms to the bitness of the underlying platform (and has properties like Size that you can query). Best of both worlds, since you get correct code by default and you can explicitly drop down to native int when necessary (and it almost never is).)
D programming language - It fixes the outstanding issues of C++, adds safty and many innovative features (contracts, slices, scopes, templates, mixins, CTFE, UFCS, etc...), is easy to use (GC *optional*) with a familiar and clean syntax, and without sacrificing native power or efficiency.
Nimrod programming language - also a very innovative and unique language with native power, great meta programming, and an awesome GC. It's as expressive as Lisp, as efficient as C, and the syntax is something similar to Python.
forced garbage collection, unstable (d2 came out very fast and breaks compat with d1). I'd say 'd is more like modern version algol in trying to do too much. I'm not very interested and c++11 just about removes most motivation for using D.
Originally Posted by Lattyware
I'd rather build on something more innovative like clay, although I have yet to fully test drive it.
Last edited by bnolsen; 06-16-2012 at 08:17 PM.
1) work in the embedded field a little, you'll know why people create a sort of "wrapper" for 8/16/32/64bit signed/unsigned integers. The term "unsigned int" may not always be the same length. Having said that, there is a standard way present in most operating systems and C/C++ environments: #include <stdint.h> // if I remember rightly. It will give you uint8_t, int8_t, etc. Everyone can use STL. It's powerful and fairly straight forward, and very generic. Sometimes you get better performance by having a custom structure however. Please note however that STL is not a part of the language itself - anyone is welcome to use it, or not.
Originally Posted by allquixotic
2) there's nothing stopping you from declaring an entire class within the header file. Indeed, it's typically easier to do that with small template classes. Headers are very good when distributing libraries however, and don't require class names and file names to be the same. So there are pros & cons. There's also the misconception that C++ is an object orientated language. It's not. Think of it more as "C, with objects".