• 0 Posts
  • 16 Comments
Joined 1 year ago
cake
Cake day: September 2nd, 2023

help-circle

  • And unfortunately, this means that WG21, the C++ committee, has to take action because people are demanding it

    Why does this mean that they have to take action? Why do they need to make C++ memory safe?

    C++ was not designed to be memory safe. If you try to make C++ memory safe, you’ll have to break retro compatibility. If you’re going to break retro compatibility, can you say it’s still C++? Or another language called C++2? At that point, why not just use another language that was designed from the start to be memory safe?

    The action that should be taken is to completely avoid starting any new project in C++, and let the language die. A programming language is nothing more than a tool, once the tool no longer works, you search for another that does.

    C++ should go the way of fortran and cobol. The only development of C++ should be done is to maintain existing huge codebases that would be too expensive to rewrite.


  • I have had many mouses. Most of them broke the side buttons. The scroll wheel usually lasts as much as the side buttons. After that. The left/right main buttons fail.

    I have never had a mouse with a broken sensor though. I would look for solutions in the software (calibration and settings). But it’s not impossible that it’s broken.






  • Editor/IDE, whatever. People claim both about jetbrains.

    If you want a purely editor-thing:

    Whatever vscode does with Ctrl+D (I don’t know the name). Ctrl+D is probably the hotkey I use most in vscode (probably more than Ctrl+S), yet CLion doesn’t have that. I’ve searched multiple times the whole settings for it.

    Those two examples are just the ones that most recently occurred to me, it has a lot more issues. For example the lack of a staging area. You can’t “git stage” in CLion.

    And I don’t think that the git integration is free from criticism. Git integration is one of the most important features of IDEs. It’s absolutely valid to criticize it.

    The autoformatter also doesn’t work correctly when developing in remote. Which means that unless I want my PRs to have thousands of lines of whitespace changes, I can’t use the auto formatter.

    Now I don’t know if this is a CMake issue or CLion. But at one point It was "#include"ing a struct from a header file I had deleted 1 hour previous to the build failing. The only way to fix that was to create the file again and delete it again.

    These complaints might seem small. But put together they are hours of wasted time that you don’t expect from the “best” of something.


  • Don’t need to go all the way there. I always heard that jetbrains make the best editors. Yet when my job forced everyone to use CLion I saw that it was just a lie. The editors aren’t good, they are just expensive.

    There are 2 easy examples:

    1. Remote developing sucks. Loading a remote cmake project takes ages. Yet if you remove the temp directory it’s almost instantaneous. Except when you do it too often and clion refuses to sync the files, then you’re fucked because there isn’t a “sync” button, it only happens automatically.

    2. The commit log is awful. It doesn’t by default show you the commit/branch you’ve checked out, it shows the chronologically most recent commit. There’s no “go to checked out commit” button either, you have to write the hash in the search field. Which btw the search is trash. If you write 6 of the characters of the hash it shows “there are no results”, yet when you write the 7th, suddenly your commit appears.



  • The thing about UB is that many optimizations are possible precisely because the spec specified it as UB. And the spec did so in order to make these optimizations possible.

    Codebases are not 6 lines long, they are hundreds of thousands. Without optimizations like those, many CPU cycles would be lost to unnecessary code being executed.

    If you write C/C++, it is because you either hate yourself or the application’s performance is important, and these optimizations are needed.

    The reason rust is so impressive nowadays is that you can write high performing code without risking accidentally doing UB. And if you are going to write code that might result in UB, you have to explicitly state so with unsafe. But for C/C++, there’s no saving. If you want your compiler to optimize code in those languages, you are going to have loaded guns pointing at your feet all the time.


  • I recently came across a rust book on how pointers aren’t just ints, because of UB.

    fn main() {
        a = &1
        b = &2
        a++
        if a == b {
            *a = 3
            print(b)
        }
    }
    

    This may either: not print anything, print 3 or print 2.

    Depending on the compiler, since b isn’t changed at all, it might optimize the print for print(2) instead of print(b). Even though everyone can agree that it should either not print anything or 3, but never 2.


  • If you want to use instructions from an extension (for example SIMD), you either: provide 2 versions of the function, or just won’t run in some CPUs. It would be weird for someone that doesn’t know about that to compile it for x86 and then have it not run on another x86 machine. I don’t think compilers use those instructions if you don’t tell them too.

    Anyway, the SIMD the compilers will do is nowhere near the amount that it’s possible. If you manually use SIMD intrinsics/inline SIMD assembly, chances are that it will be faster than what the compiler would do. Especially because you are reducing the % of CPUs your program can run on.




  • Git is not the only version control software out there, and not the first one either.

    Facebook for example is famous for not using git. Because their own modified copy of mercurial fits their needs better.

    Microsoft didn’t use git until relatively recently either. They had to make some big contributions to make it work for their system.