Announcement

Collapse
No announcement yet.

Google Wants To Make C++ More Fun

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

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

  • #2
    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).

    Comment


    • #3
      Originally posted by allquixotic View Post
      .... 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.

      Comment


      • #4
        Originally posted by allquixotic View Post
        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".

        Comment


        • #5
          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).

          Comment


          • #6
            Originally posted by allquixotic View Post
            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.

            Comment


            • #7
              Originally posted by mark45 View Post
              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.

              Comment


              • #8
                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?

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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).

                    Comment


                    • #11
                      I think some people try to compare apples & oranges with C++ vs [whatever]. C++ as a language is fairly portable, but still dependent upon the underlying machine architecture. Not all systems will support STL as well, so it's often useful for some of the more expansive libraries (such as QT) to include their own stuff.
                      Also I think of C++ only for desktop application use - and it's used a lot more than just there. There are environments where some of the things people complain about here are suddenly very, very useful and help keep clean, maintained code.

                      Comment


                      • #12
                        Originally posted by RealNC View Post
                        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.
                        I am not a "Windows-centric developer" nor am I insensitive to portability.

                        My point was not that types that specify things such as signedness or the exact bit width desired are bad. Quite the contrary; being able to specify these things is very useful and essential.

                        What is NOT essential is having a hundred different ways of specifying it! Heaven forbid you try to use code from more than one external library within the same program, and before you know it, you've got dozens of different ways to do the same exact thing. To the extent that they're equivalent, that's nice; but as soon as you move away from integers and start talking about more advanced data types like vectors/lists/tables/whatever, you immediately run into incompatibilities and wasted resources (because you often have to do a deep copy of the elements from one type to another). You also have to deal with different semantics all the time: some libraries expect the caller to take "ownership" of objects they get in out pointers or returned from a function, which means you have to remember to free or delete them. Other libraries just let you borrow their object, but if you free it, the library itself will try to free or access it later and cause a segfault. The fact that these two behaviors are seemingly randomly interspersed in libraries and that code "doing the wrong thing" compiles is braindead stupid. At least in Vala, which eventually compiles to C, it implements things like "unowned" keyword and "out" keyword so that if you make the wrong assumptions about memory management or in/outness of pointers, you get a compile-time error. That's what I like to see. Ideal would be not even having to worry about that stuff at all, but I realize that you'd then be stuck with a VM that has relatively lower performance ceiling than C++, so I'm willing to accept having to deal with these types of things, memory management, ownership, out pointers, etc.... it's just that there's no reason why the compiler can't let you know when you get it wrong.

                        Detecting broken code and producing a compiler error is something that every sane compiled language designer should strive to achieve, regardless of any arguments about performance or anything else. It's absolutely indefensible to argue "no, I want my compiler to accept code that is going to crash". You create language constructs so that doing the wrong thing prevents a binary from being generated. Period. This is bar none the best feature of Java, and something sorely missing from C++ in many cases. And I don't see how having native code that lets you do nasty things is a reason why a C++ compiler couldn't detect things like object ownership semantics. You may have to introduce a new keyword or so to make it happen, but that's called improvement. C++ has basically stagnated and I'm tired of it letting you shoot yourself in the foot with a machine gun when all it needs is a safety lock.

                        Imagine if in Java or C#, every single developer who wrote a Java library had their own utility classes implementing the Collection interfaces? It seems almost unfathomably stupid from the point of view of a Java developer, who takes it for granted that the J2SE classes are acceptable. But for some reason, C++ developers think "OK, I'm writing a library... time to redefine the type system!"

                        To me, the worst part of it is the learning curve and managing the complexity of it... for "elite" programmers who've been working with the same dozen type systems for a decade and know all of them by heart, it's probably not too bad, because they know which types are assignable to which, and so on. But it just introduces a massive and unnecessary learning curve, forcing you to look up docs and to ask yourself "if I assign X type to Y type, will I lose information?" and if the answer is yes, then you have to figure out the best way to handle it, and whether a cast works or converting both to a void pointer and copying bytes or.... let's just say that it's the worst possible situation 9 out of 10 times, and you consider yourself extremely lucky when you can just assign types from one library to another or pass them into a library function.

                        You also probably won't get a lot of pushback about these things from Windows programmers -- if nothing else, folks who code closely against the Win32 API (and only the Win32 API) have it easier than open source programmers, because all Win32 API code uses the same standard set of typedefs and the same programming paradigms. I've no love for Windows, but at least when you're programming native code for Windows, you don't have to re-learn the basics every time you want to do something. Study an API for 5 or 10 seconds and you already know what to do with it, and even the parameter names in MSDN are syntactically standardized enough that looking at the detailed docs is rarely necessary. This is a case where open source fragmentation has killed us, because nobody has agreed on a standard type system, so once the number of #includes in your files exceeds 3 or 4, you're in typedef hell.
                        Last edited by allquixotic; 06-16-2012, 04:35 PM.

                        Comment


                        • #13
                          Originally posted by jayrulez View Post
                          There's the D programming language.
                          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.

                          Comment


                          • #14
                            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.

                            Comment


                            • #15
                              D programming

                              Just for said:
                              - A language with a good productivity
                              - Good performance same as C++ or highter
                              - Easier to use
                              - All code in one file (no .h)
                              - Standard D Library (Phobos) is much better than STL
                              - many feature: metaprogrammig, CFTE ...
                              - easy to write a parallel program
                              - No virtual machine as C# or Java
                              - designed for modern programming

                              And much more ...

                              The name of this language is D, try it.

                              Fedora provide ldc Compiler who use LLVM
                              Last edited by bioinfornatics; 06-16-2012, 04:49 PM.

                              Comment

                              Working...
                              X