31:48 This is so true. I'm teaching C and I tell all my students to use it (in the web of cause). I even force it to give errors when compiling my code normally when I work on some project myself or with a group. It even helps to prevent some bugs, like when a scope is closed too early and the dev doesn't realize (which happens more often than you might think).
Yeah surprised he said that, most C++ devs are using EPEL or dev-toolsets also on RHEL. In Ubuntu it's in the Universe repo, which is the equivalent to EPEL on Ubuntu
fish shell with powerline and sshing using mosh, edit with nvim (or vim). Virutal console managed by tmux. also not using qwerty, but dvorak keyboard for faster typing :)
Is there some documentation out there how to build for example an clang compiler for the RaspberryPi as i couldn’t even find a very basic tut and the official one is more or less a very hard to read thing.
The answer might be late, but you can install the tmux theme pack plugin, and also install oh-my-{zsh/bash/fish}. Also install fzf for the best experience
I tried to compile clang as shown in the talk (actually I used commands from official documentation) on Ubuntu 16.04, but it failed to build. This is as far as I got. Distributing binaries *IS* important. It doesn't have to be in the official package repo of the OS, but *please* distribute binaries.
I'm sorry, you are right. I must have ignored those binaries because I wanted to try building myself, like the video encourages. :) Thanks, I'll give it a go!
Just one thing: DO NOT use reinterpret_cast. If you really must do it and you know what you're doing: first read this git.io/Jels3 and then don't do it. If you NEED to use it then maybe some of your code might be wrong to begin with. So whenever that happens consider rewriting the class/struct/function/thing it shouldn't be hard if you have tests. Try to provide explicit conversions. (Yes, it might be slower in some edge-cases but it won't be UB). If you're using it than your code might as well be made up of void pointers.
Clang-format is in fact a pretty stupid tool: it doesn't operate a real C++ AST, just some hacks around a lexer. Hence, you can't get different rules for function calls and macro calls-both look like "some invocation" to clang-format :( So, if you (for some reason) use something like `STRINGIFY(macro-will-turn-this-into-string-literal)`, default settings will turn this into `STRINGIFY(macro - will - turn - this - into - string - literal)`, changing behavior of your code. And it's not just a bug to be fixed-it's not likely to ever change without rewriting clang-format almost from scratch. Of course, using weird macros is a bad idea regardless formatting, but preserving original semantics is kinda reasonable thing to assume about a formatter, which is not the case with clang-format.
For people wondering about clang-tidy missing modernize checks, the build is correct, you just need the -checks="*" option to enable them.
31:48 This is so true. I'm teaching C and I tell all my students to use it (in the web of cause). I even force it to give errors when compiling my code normally when I work on some project myself or with a group.
It even helps to prevent some bugs, like when a scope is closed too early and the dev doesn't realize (which happens more often than you might think).
clang is not installed by default in RHEL. It's available in two ways, first in EPEL(version 3.4), second in Red Hat developer toolsets(versioin 4.0).
Yeah surprised he said that, most C++ devs are using EPEL or dev-toolsets also on RHEL. In Ubuntu it's in the Universe repo, which is the equivalent to EPEL on Ubuntu
Four minutes to compile Clang/LLVM! You'd need half of Amazon's compute cloud to do that today.
Thank you Chandler, excellent talk. Building my own Clang install has long been something I wanted to do but was a tad apprehensive about.
I think one day, clang-format will just write software for you.
Pretty sure it already can, just no one has learned how to ask it nicely.
It's weird to listen to LLVM introduction after using it for a quite long time, including ThinLTO and still learning something new - thread sanitizer
Note that the main LLVM page seems to be using SVN, not Git. The documentation might be outdated.
There are details on the git mirror here: llvm.org/docs/GettingStarted.html#git-mirror
oh fuck, his keyboard layout is US(Dvorak) - nerd clout +9000
What terminal emulator is he using?
fish shell with powerline and sshing using mosh, edit with nvim (or vim). Virutal console managed by tmux.
also not using qwerty, but dvorak keyboard for faster typing :)
Is there some documentation out there how to build for example an clang compiler for the RaspberryPi as i couldn’t even find a very basic tut and the official one is more or less a very hard to read thing.
Use Arch Linux. You get GCC 7.2 and clang 5 by default!
Yeah
10/10 Recommend
I will just use Debian backports.
Clang format performs witchcraft.
anyone knows how to setup tmux like Chandler did? thanks.
The answer might be late, but you can install the tmux theme pack plugin, and also install oh-my-{zsh/bash/fish}. Also install fzf for the best experience
My laptop would be slow here, but we have a machine named after Balerion...
You can fix the first 6 minutes by using a different distro
I tried to compile clang as shown in the talk (actually I used commands from official documentation) on Ubuntu 16.04, but it failed to build. This is as far as I got. Distributing binaries *IS* important. It doesn't have to be in the official package repo of the OS, but *please* distribute binaries.
They do: releases.llvm.org/download.html
I'm sorry, you are right. I must have ignored those binaries because I wanted to try building myself, like the video encourages. :) Thanks, I'll give it a go!
28:05 never use map :)
+asan!
He really use dvorak keyboard layout
He types for a living.
Just one thing: DO NOT use reinterpret_cast. If you really must do it and you know what you're doing: first read this git.io/Jels3 and then don't do it.
If you NEED to use it then maybe some of your code might be wrong to begin with.
So whenever that happens consider rewriting the class/struct/function/thing it shouldn't be hard if you have tests. Try to provide explicit conversions. (Yes, it might be slower in some edge-cases but it won't be UB).
If you're using it than your code might as well be made up of void pointers.
I mean, nice i3wm setup, but it's still cpp.
4 years late (lol), but it's not i3wm, it's awesomwm.
Clang-format is in fact a pretty stupid tool: it doesn't operate a real C++ AST, just some hacks around a lexer. Hence, you can't get different rules for function calls and macro calls-both look like "some invocation" to clang-format :(
So, if you (for some reason) use something like `STRINGIFY(macro-will-turn-this-into-string-literal)`, default settings will turn this into `STRINGIFY(macro - will - turn - this - into - string - literal)`, changing behavior of your code. And it's not just a bug to be fixed-it's not likely to ever change without rewriting clang-format almost from scratch.
Of course, using weird macros is a bad idea regardless formatting, but preserving original semantics is kinda reasonable thing to assume about a formatter, which is not the case with clang-format.