Google Wants To Make C++ More Fun

[phoronix]

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...

http://www.phoronix.com/vr.php?view=MTEyMTE

[allquixotic]

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).

[jayrulez]

.... 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.

[mirv]

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).

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.

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".

[Ex-Cyber]

Writing C++ is plenty of fun. Maintaining it, not so much. It will be interesting to see what comes out of this effort; there are already proprietary tools that purport to address some of these issues, but they seem to be love-it-or-hate-it depending on whether your project employs tricky techniques that make the tools barf.

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.

Agreed. It's also a barrel of laughs when two different libraries have their own typedefs for the same names (or two different versions of the same library, one of which was forked into somebody's firmware tree years ago and mutated away from being an actual library, which is of course an entirely fanciful scenario that I am in no way actually dealing with right now...). At least we have <cstdint> now (in theory).

[mark45]

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.

Yes, they all also reinvent unicode and threads (pthreads, Glib's threads, Qt's threads, etc). At least C++11 solves this (once and for all I hope).

But we'll still have the filesystem API reinvented in most crossplatform projects.

[elanthis]

Yes, they all also reinvent unicode and threads (pthreads, Glib's threads, Qt's threads, etc). At least C++11 solves this (once and for all I hope).

But we'll still have the filesystem API reinvented in most crossplatform projects.

That's moving towards a TR and eventually integration in C++next, along with a much beefier and mee versatile concurrency stack, networking, and a few other things. They're trying to focus more on libraries rather than major language features for the next standard, which is also intended to have a much shorter development time.

[allquixotic]

The real challenge then is going to be to get all the aforementioned libraries to refactor their code to either deprecate or remove their old types and macros that are obsoleted by C++11 or later standards. Because even if all the targeted compilers perfectly implement standards-compliant, fully viable type system and generic data structures that would indeed work well for everybody, you still have quint32 and QList and gpointer and... need I continue?

[RealNC]

The custom types are useful, because contrary to the Windows-centric developers, some of us care about portability. We *do* need qint32 and all that, so that we can be sure our code works on all supported platforms and compilers.

If you only target one or two platforms and only support very recent compilers, then yes, the types seem redundant. But even then, you don't have to care much. They're just typedefs. Feel free to use other typedefs instead. They are compatible.

In other words, this is not an issue at all. People complaining about it are just nitpicking about things that are of no consequence.

[Cyborg16]

Bah. Typedefs, if there's a tool that hides them so that I don't have to think about them, then yes, fine. It is however a consequence when you have to work out whether somebody else's vector behaves like the standard one, and so on. Go C++11 / future!

Totally agree about headers. Macros too. Can't somebody design a dialect of C++ with no macros or heades? Wait, somebody already did (SPECS). And it was a total flop. Hmm... code copy+paste compatibility means a lot less than ABI compatibility as far as I'm concerned, so long as conversions don't have to be done manually (which was always a pain in D as far as I am aware).