1. 15
  1.  

  2. 6

    I opened my mouth in shock at the “static_cast<decltype(x)>(x) should be a no-op but it isn’t” paragraph. C++ is… C++ is fuckin’ metal, is what it is

    1. 4

      It reminds me of Scott Meyers’ remark regarding, for example, six (sic!) sets of rules of type deduction in C++.

    2. 2

      I learned something about std::move and std::forward. It also made me appreciate quick compile times in other languages that aren’t C++, even more.

      1. 1

        Wow, very relevant as I just used std::forward for the first time in Oil’s garbage collector! And I’m aiming to have Oil compile faster than bash.

        Instead of new Point(x, y) I use gc_alloc<Point>(x, y), which is hooked up to a tiny garbage collector. I learned that you need variadic templates and std::forward to do that (in idiomatic C++).


        And I’m keeping track of Oil compile times here:

        https://www.oilshell.org/release/0.8.0/benchmarks.wwz/ovm-build/

        Unfortunately oil-native recently surpassed the compile time of both bash and our slice of CPython (~30 seconds on a fast machine, ~90 on a slow one)

        I’m pretty sure it’s all the tiny hand-written translation units, which I can remove by doing something like sqlite’s amalgamation. That, combined with all the templates.

        After that low hanging fruit is removed, it may be worthwhile to try the macro replacement for std::forward :) I agree it’s a bit annoying that it is a function that could show up in the debugger.

        One thing I’ve really enjoyed about generating C++ code is how easy it is to step through in a debugger. It sure beats the experience of debugging Python.

        1. 1

          One thing I’ve really enjoyed about generating C++ code is how easy it is to step through in a debugger. It sure beats the experience of debugging Python.

          Sentences I’d never thought I’d see before.

          1. 1

            I tend not to engage with vague, one sentence replies… If you have details on that opinion, it might be interesting.

            To be clear, I’m talking about the experience of using a debugger, which you don’t need as often in Python.

            Another thing that is nicer about the C++ ecosystem is that the performance tools are way better. Python profilers are not very good IME.

            1. 1

              I had always thought the debugging situation for C++ was traditionally awful due to the low quality of gdb, name mangling, and compiled output complexity; even if you don’t need a debugger often in Python, you’d think it’d be a better experience due to its high level nature

              1. 2

                Name mangling is definitely not a problem in gdb for at least the last 15 years. Maybe it was before then.

                1. 1

                  OK I get where you’re coming from a little more now.

                  Debugging requires some pretty difficult runtime support. For example this EuroPython video shows how it’s even still in flux in a 30 year old language!

                  https://www.youtube.com/watch?v=sAvOZlbh9mQ

                  The fact that Python devs rarely use debuggers means that the debugger support isn’t very good. That’s both in terms of the runtime and the front ends on top of it. On the other hand, C and C++ developers use debuggers all the time.

                  Bash has a debugger, and its runtime support is pretty difficult too:

                  https://github.com/oilshell/oil/wiki/Implementing-Debuggers


                  I would amend the statements as follows:

                  • “low quality of gdb” -> GDB is very high quality, and has gotten a lot better recently, but it has low quality GUIs. I think the best one is probably IntelliJ’s Clion. I used Eclipse and it works well enough, but is far from polished or stable. I also use the GDB command line.
                  • “name mangling” -> not an issue for any debugger I know of. You do need to build your software correctly with symbols, and have those symbols loaded into the debugger, which can sometimes be difficult.
                  • “compiled output complexity” -> I think you mean that the source doesn’t really correspond to the compiled output. That is indeed an issue in C++. Sometimes you get dropped into weird template metaprograms deep in the stack. For Oil’s generated C++, this is less of an issue.

                  One way to think of what I’m doing with Oil is generating some “pidgin C++” at the level of abstraction of say Go. That kind of code is very pleasant to step through, if not to write. (and that’s one reason I’m not writing it directly)

                  Debugging is a pain point in essentially all language ecosystems. It’s difficult and expensive to develop, and open source communities often don’t get around to it. For example, C++ debugging support is head and shoulders above Rust and Go too. So there is a low bar to meet, because debugging C++ can be painful, but most languages don’t meet it! Including Python.

                  1. 1

                    Between GDB’s UI, how many issues I’ve had with things like watchpoints, and the fact I’ve had consistent segfaults with it, I hesitate to call it high quality. (FWIW, I don’t think all C++ debugging experiences are bad - Visual Studio is probably the best debugging experience I’ve had, even with C/C++)

                    1. 1

                      Those things aren’t surprising to me, but I think the bar is low, and Python’s debugging support isn’t any better. Ditto for say Rust or Go. I’d be interested to hear otherwise.

                      I doubt Python debuggers even have watchpoints!

                      I haven’t had any unexpected segfaults with GDB … It seems pretty stable (on Ubuntu – I wouldn’t be surprised if distro support is a little fiddly too). I’ve definitely had tons of crashes with Eclipse and other GUIs.

                      The GDB Python API is pretty awesome now. Someone’s been quietly doing some good work. Example:

                      https://github.com/oilshell/oil/blob/master/devtools/oil_gdb.py

                      C++ is mature, so I think its debugging experience beats other languages along any dimension. Either open source or proprietary. I haven’t used Java debuggers but those could be an exception.


                      I guess I would say that ALL open source debuggers are “challenged”, regardless of language. They are not the most friendly applications. But C++ has the most open source support.

                      If you go proprietary, C++ also has the most support there too! (Java is probably a close contender)

                      1. 1

                        I don’t write code on Windows, so can’t really speak for myself, but Casey Muratori recommended RemedyBG over the Visual Studio debugger which apparently degraded in quality over time (he demonstrated it in a video).

                        Seeing how Casey used RemedyBG made me envious of Windows devs. I can only dream of such experience on Linux. And there wasn’t even anything special shown. It’s just how smooth the experience is. Meanwhile at $dayjob GDB can’t even catch a breakpoint in our code. Forget about smoothly working visual debuggers.

            2. 1

              Oof, while I disagree with his use of move/forward for this (because the opacity of move vs. copy is irksome), especially his choice of language token, I do agree with the general problem.

              The fact that so many parts of the C++ language are pushed into libraries is a significant source of compile time cost and language complexity.