How I use C++: a line-by-line code review
Vložit
- čas přidán 5. 08. 2024
- Let's walk through quick-lint-js, a 100k-line C++ project, and talk about the code style and design decisions.
Links:
Stewart Lynch's Sane C++ series: • 10x: Sane C++ Live Str...
C++ Core Guidelines: isocpp.github.io/CppCoreGuide...
decode_utf_8_result design help from u/LegionMammal978: / j3b6afz
00:00:00 dev environment
00:00:36 font
00:00:55 editor
00:01:24 terminal
00:01:48 copyright comments
00:03:39 reduce clutter
00:05:05 copyright year
00:05:57 copyright checker
00:06:19 source file generator
00:06:37 how I write new code
00:07:09 includes
00:07:38 .h next to .cpp
00:08:40 namespace
00:10:19 citation comment
00:10:57 naming style
00:11:36 preferred style
00:13:09 custom syntax highlighting
00:15:06 char8_t
00:16:25 char8_t vs char
00:17:55 nested functions
00:19:08 number literals
00:19:38 raw pointers
00:20:35 smart pointers
00:22:04 anonymous namespace
00:22:55 which compiler?
00:23:37 compiler warnings
00:25:02 returning classes
00:25:35 struct vs class
00:26:02 better design
00:27:23 char8_t confusion
00:28:34 designated initializers
00:29:22 zero initialization
00:30:01 assert
00:30:18 QLJS_ASSERT
00:30:51 custom assert message
00:31:46 better assert debugging
00:32:16 cassert sucks to debug
00:34:40 if variables
00:37:25 casting
00:39:22 in_range
00:40:53 narrow_cast debugging
00:42:05 source_location
00:42:36 __builtin_LINE
00:43:33 narrow_cast performance
00:44:25 todo comments
00:45:16 issue tracking
00:46:49 performance notes
00:47:23 column limit
00:48:24 screen size
00:49:02 monitor aspect ratio
00:49:43 hard column limits
00:52:06 type inference
00:53:46 object initialization
00:54:30 explicit
00:55:01 implicit
00:57:06 no implicit in Rust
00:58:21 Rust ..
00:58:40 most vexing parse
01:00:13 header file
01:00:29 include guards
01:01:45 include guard fixer
01:02:40 messy #include guards
01:03:18 file organization
01:04:52 #include
01:05:17 namespace references
01:06:46 code formatting
01:07:28 legacy headers
01:08:37 #include order
01:11:00 #include style
01:12:15 header organization
01:12:29 macros in headers
01:13:19 header example
01:14:02 blank lines
01:15:03 forward declarations
01:15:52 simdjson-fwd
01:18:04 portability and the standard library
01:19:06 working around compiler bugs
01:20:07 port folder
01:21:18 binary bloat
01:22:45 binary size data
01:24:07 std::filesystem::path bloat
01:25:12 #if defined
01:26:41 platform-specific files
01:27:31 everything is compilable
01:28:28 std::filesystem::path
01:30:08 why not std::filesystem
01:32:40 exceptions & error handling
01:33:45 why use C++ exceptions?
01:34:37 try_catch_stack destructors
01:35:34 result
01:36:57 static and dynamic analysis
01:37:45 clang-tidy
01:38:47 warnings in CI
01:40:04 what's next - Věda a technologie
Just found your channel and I have to say, I could sit and listen to you for hours, you are very articulate and explain things very nicely. Defiently sticking around for a while since I have picked up C++ recently!
Cool! Follow me on Twitch if you want to listen to me for hours.
This is the type of video i love to watch. Raw explanation and code and no fluff. You just won another sub!
Indeed a good video to watch if you have insomnia and can
@strager I just found your channel, I watched this video the other day. I'm learning C++ at the moment coming from a C background. Just wanted to say this is the best video I've seen for just going through and talking about code structure and why you do certain things and don't do others. I found it really helpful.
You're welcome!
Font choice: The most important features are that the numeral 1 and the lower-case l are readily distinguishable, and that the zero and the capital O are distinguishable. Your IDE should alert you to these things. Also, it's interesting how so many of the problems we struggle with in C++ in 2023 are the result of choices that should have been made when C was first developed.
The point people make oftentimes is not to never use raw pointers, but to never use *owning* raw pointers. And I find it to be very beneficial to me.
Good distinction! Yeah, I generally agree with you about trying to not use owning raw pointers. I'm not 100% sold though.
@@strager_ I made a library that uses raw pointers and I changed it to smart pointers to fix something. The smart pointers honestly provided nothing useful. From within the library, there's no need to either take ownership of or use reference counting for an object. I don't really see any situation where you would lose track of something so much that you can't tie its destruction to whatever is using it or explicitly destroy it.
For those reasons, since raw pointers are not only easier to work with but also don't cause unexpected behavior by mangling your objects, and because they do the exact same things, I say smart pointers are dumb.
@Pupper Gump For a small project not using smart pointers is usually not a problem, though I would still recommend it. If working on any larger project it helps a lot. When working with raw pointers you need to be very careful taking everything into consideration and if the project is large that can be very difficult.
For example if you have a class that has a raw pointer which it owns and the destructor is responsible of deleting it. Do you every time remember to implement the copy, move constructors and assignment operators to make sure nothing bad happens or at least mark them as deleted. And even if you do this it is a lot unnecessary work. If you instead used unique pointers then copy constructors would be implicitly deleted(you can explicitly define it if you really needed it) and move constructor is implicitly defined and it uses the move of the unique pointer. So in case you don't need to do anything special you don't have to define any of the constructors, assignment operators and destructor and you are guaranteed to not have a memory leak and everything with out writing a single line of code.
Also declaring pointer as unique pointer indicates clearly which object owns it and is very useful for others reading the code to know who owns it. In general when you see unique_ptr you know you own it and when you see * you know you are borrowing it from some other object.
And in case unique pointers are not enough, that is there is no clear owner of the pointer then using shared pointers instead of raw pointers becomes even more important. Handling the raw pointers and doing some sort of manual reference counting to make sure when to delete the pointer is prone to errors if you ever forget to decrement the count you run into a memory leak and in some cases these can be very hard to find especially since they can happen only in very rare cases that are hard to reproduce. Shared pointers are not going to solve everything as they have their own issues like circular references, so you have to still be careful when using them but at least you have one degree of freedom less to keep track of.
And if you consider the performance I doubt there is going to be a situation in which using smart pointers is going to be (significantly)slower compared to using raw pointers. Unique pointer is more or less zero cost while shared ptr keeps reference count but you most likely would anyways need to keep it up by your self. And in that special case where the almost non existent performance benefit matters, is most likely some algorithm that is only a very small part of the code in which case I suppose you could consider not using smart pointers, and even in that case I would profile whether it has any benefit.
Anyhow you should always use unique_ptr whenever it is possible. If you need shared_ptr try to think if you can do something to only need unique_ptr and if it seems completely impossible then use the shared_ptr. There are also different types of smart pointers but in case you need to use those(or raw pointers) the architecture is probably not very good at that point(maybe in some case you could actually have some good reason to use them but unless you can tell a very good reason to your self: why you need to use them, why nothing else works and why nothing can be done differently then you shouldn't)
@@XD82ful In my case, smart pointers appear unnecessary for a lot of the pointer operations I'm doing. My project is a gui, so I take objects the user instantiates and store their pointers inside a vector of pointers. On top of that, an object's pointer can also be held by another object through binding, which might be a good case to use shared pointers without ownership.
On top of that, to make creating new objects easier, I give objects a vector to store their own instantiations of other objects, which is then accounted for in the update/draw loop.
Because of all of this, I've created many functions to abstract any pointer operations. And I haven't had any issues with them for a long time. I think what you're talking about are projects that use many classes from many libraries and the programmer really just mixes them together, but my case is just using one specific library and adding on top of it.
Of course, maybe I'm gonna regret using raw pointers in the future, but here's the project if you really wanna tell me off: github.com/PupperGump/gui/tree/master/gui
@@puppergump4117 I took a quick look and I think you are basically thinking of a different thing here takin a reference like for example having Button b; Object* o = &b; is not actually something where you need a smart pointer, here the memory is in stack and it cannot even leak as it will be released as it goes out of scope. By not using smart pointer one means that you directly do something like Object* o = new Button(); so that you are dynamically allocating memory and you need to release it by calling delete o; In these cases instead of using new and delete you want to use smart pointers in which case you would have something like std::unique_ptr oo = std::make_unique(); this creates object in dynamic memory using new internally and then releases it using delete internally without you having to call it explicitly. So basically using raw pointers is fine even if you are using smart pointers(and in fact necessary) the point is that you won't call new and delete by your self. And in above example you can get the raw pointer by calling oo.get() which returns Object*. Anyways good luck with your gui project :)
This is the perfect video for someone with enough experience looking for a tour of actual C++ code and not just cookie cutter tutorials. Super valuable! Thank you :)
This whole video was one rabbit hole after another, for me.
.
I think it’s helping to get me up to speed with the programming skillsets.
This video was a goldmine of professional and robust practices. Thank you very much, I learned many a new thing!
You're welcome. I hope you don't borrow my bad practices too! 😆
Very cool walkthrough! Definitely a little bit insane, but aren't we all a bit insane in our own ways ;) Thank you for the delightful view into your coding workflow!
Nice vid man- very cool to see someone be honest about what's working and what's not with their setup/code. Oftentimes I see programmers (especially young ones) assert that everything they are doing is correct and if you do it differently you're just plain wrong.
My style evolves with every project.
Good comment.
Awesome channel, top work! I'd love to watch all your videos since I have the time.
You seem to care about performance, so just a small tip which I discovered when I updated my old word count (wc) utility to count utf8 letters instead of bytes:
Casting the input array to signed char allowed me to detect all follower bytes with (c < -64) instead of checking two boundaries (c >= 0x80 && c < 0xC0).
Next I split the processing into chunks of 128 bytes (or any other small multiple of 16) and stored the count as a byte: At this point the autovectorizer would generate pretty much perfect code, i.e. 16-byte (or 32 for AVX2) loads, followed by a simd compare and a simd subtract (since the compare results are -1,0 instead of 1,0). It ran in ~0.3 clock cycles/byte.
> Casting the input array to signed char allowed me to detect all follower bytes with (c < -64) instead of checking two boundaries (c >= 0x80 && c < 0xC0).
That's pretty cool! Clang does this optimization, but GCC doesn't: godbolt.org/z/rGGjdK7xo
@@strager_ Yeah, I am using Rust on Windows and since MSVC can compile with either their own or the Clang back end, I believe that is what I'm seeing. (I use cargo-asm for disassembly listings)
18:24, I agree. I think outside is prone to errors, because it can be called in an unexpected situation, which currently you are unaware. Before lambdas, I rather even make it a macro, to use inside the f(), only, and #undef it right after the f(). Although I relax if the f() is called by more than 1 f() - this case, it's not technical internal complexity, it has probably a higher-level meaning.
21:20, nowadays, MemorySanitizer catches this.
23:20, I benchmark Clang vs GCC on switch vs if-block vs array vs bitfield. Sometimes 1 was better for some cases, other for other cases.
Nice video. Very interesting perspective. Thank you for your time.
The legend is back!
51:20, although I'm not a fan of vertical code, this is a good exception:
- The vertical alignment allows to quickly spot some errors, like lack of bits, even if an operator disalignment was seen 1st, for instance.
- Double click in a keyword, and all its occurrences on the block will appear, helping spot errors too - _if the code editor has this feature_ .
- The single line would be too large. I use to go towards the right margin, using commands of the "same kind": variable declarations (of any type), tiny lambda definition, loop-if-consequence ("same thing" to me), and so on.
52:17, auto can be:
- "Refactorer": if the returning type ever changes, you don't need to hunt its occurrences.
- Defensive: avoids you from mistaking the returning type, getting an inplict conversion, which can lead to problems.
- Elegant (at least I think so): getting "the same face" for declarations.
I have been using it on all places, like a rain, and curiously I'm not running into issues.
I find auto (or var in C#) very hard to read. It's very often not clear the type that is returned, and I prefer not having to hover over every identifier to see it.
@@Katniss218 In this case, when the f() is already fixed, auto may be replaced by a typedef. But when the f() is being developed, auto is more productive.
Btw, its absence for return in Carbon is my main complain against the new language.
I'm so glad I only write programs for myself, some simple and less than a thousand lines of code and others with tens of thousands of line, BUT apart from a couple of small business friends, I'm the only one who uses them. And I've used Visual Basic 6 and Access Databases for all of them and they are plenty fast enough! With the ability to write your own User Controls, the maintainability and convenience is amplified even more. But, I don't need it to be accessible to any other coders and I don't need it to run on anything but Windows.
Yeah, portability is a small burden but it's all over my code. =\
The most impressive part of this video is your control over Vim
Clangformat: I exist to solve formatting problems
This video: is about formatting problems
:D
1:14:00, I rather a compact block of declaring f()s:
- Blank lines become begin/end of a block section, which is much more meaningful than just separating cmd lines.
- Result in compact code, which raises the likelihood of fitting the block in a screen.
- According to Kate Gregory, who worked "rescuing abandoned projects" (due to lost of control over them): _"Those blank lines dividing sections of code help us a lot! Please use them."_ (for this propose).
1:26:09, the Codeblocks IDE I use puts a comment after the #endif, referencing its #if argument. It's handy when the block is big.
> 1:26:09, the Codeblocks IDE I use puts a comment after the #endif, referencing its #if argument. It's handy when the block is big.
Yeah, that does sound super handy! Code Biscuits does this for many languages in many editors: github.com/code-biscuits/
your code is amazing and fabulous!!!
I like the syntax highlighting, makes it a lot better imo. Also would find it pretty hard not to have go to definition/implementation/type definition. I use neovim with all this. I could live without auto completion though
Usually C++ code is ugly. But this one is just outrageous. Make a custom execution with UB ( 1:35:26 ) and be proud of it
I am in love with the monospaced Comic Sans. I feel like society would shame me but I can't look away
use what you like, screw what other people think, they're not the ones staring at it 10 hours a day
Came here from you big O video where I thought you were programming in Comic Sans, but it looked monospace so I brushed it of as my imagination.
It's nice to know it actually was a Comic inspired font and that I'm not going mad.
Yup, it's Comic Code. I love it! tosche.net/fonts/comic-code
While I know comments are normally suboptimal, I might’ve put a comment at 37:00 explaining what `size` meant in this case. Or add a comment on the definition of the struct, but if `size` doesn’t always mean how much you skip then I’d just put above line 96 in this file
Yeah, my util/utf-8 module does need to be improved. Same with every other module... 😅
Usually structs are classes without invariants and when I hear struct, I assume it has no invariants, i.e. it's just a bunch of data without methods that do anything overly interesting or complicated.
What roadmap / books would you recommend to learn modern C++ for an intermediate Python / Kotlin programmer? Don't want to risk reading a 1000 page book that teaches bad habits
I recommend against roadmaps.
I suggest picking a project idea and working on it.
I don't know you, CZcams just recommended this video. And, I liked your environment
35:30 - I like that style a lot. It really helps when learning unfamiliar code, or when you inherit something and the original author is long gone.
regarding usage of raw pointers: use them when you don't care about ownership; so an owning class uses unique ptr, but when passing it to other functions for usage it should just pass raw pointers or references
Your voice is so good it always help me fall asleep.
I'm sorry that I am so boring 😭
@@strager_ You voice is absolutely amazing.🫀
I didn't realize I cared so much about font until I saw this, this font would drive me crazy :x
This kind of font is very readable, I use Fantasque Sans Mono for the same reason. Many "normal" programming fonts have characters that look too samey, made of repeating identical angles.
@@vytah i can't get with it, i feel like there's a lot more fonts that are easier to read but i'm not one to care for them too much; that being said I would care if this was the font set and switch it to something else xD
I looked at this code for two seconds and dipped… this is one way to give your senior software engineers a stroke
1h and 40m of Strager? Yes pls.
Also, nice shirt
When it comes to identifier style, I follow Qt's style guide. The fact that this largely agrees with most other modern languages (C# choosing to use initial caps on functions and properties is annoying) is a plus, even though I was using C++ first. (I learned C++ in 1997. The keen-eyed among you may notice this is before the language was standardized.) This has become mildly irritating as C++ gets better and Qt starts using more out of std::, but what can you do?
Great Video :)
This thumbnail is a mood
Very nice! impressive.
You are sooooo close to Unix beard! Keep going!
I would love a vid or stream about your general workflow😢
When I use CamelCase, each block only contains 1 uppercase letter that way it is mappable to the subset of lower snakecase. i.e. not HTTPWriter but HttpWriter would be equivalent to http_writer.
blasphemy
That is the only way to use camelcase.
@@puppergump4117 nah, mixed-case letters in an initialism just looks so wrong. If something is common enough that you can use the initialism without a question of whether or not the reader will understand, then you can be assured that the reader will also be able to separate the blocks correctly. If you don't think the initialism is recognizable enough, don't use it at all.
@@tissuepaper9962 Semantics are tough so here's the breakdown. When you use an ide, most of the time you will just type a few letters of the function or variable and hit enter to get the whole thing. The advantage of camelcase is that it lets you just say httpwr and it autocompletes. Or even htpwr.
With snake case, you can only type a single word separated with underscores. So it would be http_wr instead. This is useful to filter out variable names such as members of classes.
🧑🏽💻Thanks this was great🏆
About the qualification of identifiers (where you actually talks about using multiple namespaces), you may actually have clashes with ADL, which is annoying. So, qualifying identifiers is a good thing for libraries at least where you don't know what else code may be included in the same translation unit.
Yup! Luckily I don't have to deal with that much because I am making an application, not a generic library.
37:18 why do you prefer to have an if/else when you return in the if? Dropping the else would reduce the nest level
In this case, I think it's easier to read similar code if they're at the same nesting level.
at 17:38, about pointer aliasing: can't this also be solved by doing it in pure C and using restricted pointers?
I'm in C++, not C, so no 'restrict'.
Even if I had 'restrict', I cannot use 'restrict' on struct members.
Often I use pairs of pointers (e.g. a source_code_span has a begin and an end), and 'restrict' is not allowed for those kinds of things.
Would it be possible to get that selection/range highlighting where the token colour gets taken in and used as the background colour in VSC?
I don't know about Visual Studio Code extensions, sorry. Maybe it's possible with a color scheme.
I really wanted to see how you navigate the codebase without LSP and such, do you talk about that at all in this video? I don’t see anything in the chapter titles.
I didn't talk about code navigation in this video. (I think...)
@strager - In your opinion, what are the uses for a programmer nickname? In this case, it's not for anonymity. Follow up question, Is it something you would like to be called in the workplace or just by friends?
Thank you for this video and your content. Much appreciated. I enjoyed this one particularly and seeing your take on C++.
If you are referring to 'strager', I consider that my name, not a 'programmer nickname'.
> Follow up question, Is it something you would like to be called in the workplace or just by friends?
I go by 'strager' everywhere not-legal, but sometimes I use 'Matthew' if I think someone would have a hard time pronouncing or remembering my name. (I should get around to changing my legal name...)
@@strager_ lol That'd be awesome. Thank you for the reply. Just curious is all. The more I get into programming, web development, and showcasing my projects I have been considering adapting a media name of sorts or alias.
I have seen cybersecurity professionals and hackers also use tech names for anonymity, but I have yet to think of a name. In college I had a nickname from friends, but other than that I have had no other aliases other than just youtube or video games. I constantly change these names though, there hasn't been one alias I've stuck on.
Again, thank you for the reply, I appreciate you.
My favorite part of this video is the Hooli shirt. Gavin Belson would be very proud. Where can I get this shirt?!
It's a custom shirt. Not for resale!
7:14 For the header if you include it first this ensures that it doesn't have any dependency on other includes for it to compile. This is especially important in the library case you mention.
8:47 The point of namespaces is to avoid clashes and unwanted interaction with other code you have no control over. Making sub-namespaces like util adds none of this value because you're the author of all the code and can thus ensure it works well together in a single namespace.
> if you include it first
This is a good idea. However, usually my build system uses precompiled headers which makes you trick not work as desired. I've found it better to write a separate tool which #include-s all public headers and doesn't use my build system.
> The point of namespaces is to avoid clashes and unwanted interaction with other code you have no control over.
Exactly!
I don't want *my* code having symbol collisions which I need to manually resolve. That's confusing!
@@John-kd3bfWho hurt you?
Really the only times that I use nested namespaces is to define a ''NAMESPACE_implem'' within the primary namespace that holds things not necessarily meant to be used as part of the public interface; usually something like a templated base class meant to be inherited and expanded upon, or free helper functions.
In these situations, you can just add ''using namespace NAMESPACE_implem;'' within the block scope of your primary namespace and it won't leak out to elsewhere - and then you don't need to type NAMESPACE_implem when using that stuff in your intended-public-facing classes/functions.
Technically yes, the primary purpose of namespaces is to help avoid naming collisions, and may very likely never be an issue in a personal project; but I think it's a good tool for organizing things, as well as removing clutter from the global or individual namespaces. Even in the situation of having multiple contributors, there is a big advantage in being more verbose/concise with naming and structure and what not.
You can't ''using namespace'' in a class, but you CAN do it inside of a function. typedef's can also be quite useful, although slightly straying off topic maybe: ''typedef MyPersonalNameSpace::implem::MyClass_Base CLASS_BASE;'' and now you have an alias called CLASS_BASE for your more verbose alternative of a templated class that can be used anywhere the first one would have been used.
@@sebastiangudino9377 who asked?
How about ending type names with "_t"? decode_utf8_result_t, uint8_t, etc... It would make names consistent (decode_utf8_result_t decode_utf8_inline() { ... }) and wouldn't force you to think about how to capitalize acronyms (and would make it very easy to highlight as well).
_t types are reserved by the POSIX standard and you shouldnt define your own to prevent future overlap in namrd
@@WoD2008 Thank you for the comment, I didn't know that, I only knew about C's reserved underscore prefixes. I wonder if there are any other reserved naming conventions.
I don't like it.
@@WoD2008 That's a really unreasonable paranoia imho. If you happen to write a language feature outside of any namespace that happens to exactly match a future posix type and you hapoen to update to that posix standard, then you probably hit the 0.0001 percentile case. I would play the lottery with this kind of thinking. Besides, if you happen to declare the exact same type chances are you can now deprecate your own lib in favor of the new posix standard. Wouldn't it be nice if the compiler sends some error down the lines to inform you about this?
Tldr; i use _t all the time, never had any hickups
27:05 literally me, the classic "it works for now" (i'm never going to fix it)
if it works don't fix it
If you have the short preamble at the top of the file, then have it add if missing at the end....
Or add the short license base on the LICENSE file in the root of the project.
Sounds like a short little tool to write
At the start, the assert in the 'byte' lambda is incorrect. It's off by one.
You're right! I'll fix it.
Classic off-by-one error.
github.com/quick-lint/quick-lint-js/commit/e9fccba1f9f842dab130f559e0562a0e40a1542a
There's a project, a serious project, that tries to remake comic sans. And the font looks cool imo. They're considering making the monospace version but they're busy with fixing the font.
Have you switched to polyglot or tree-sitter for your syntax highlighting yet? It's so worth it.
why name the type 'decode_utf_8_result' instead of 'decoded_utf_8_bytes'?. I am amateurish so may be missing something, but I think of verbs as methods ('decode') so would change to an adjective('decoded') and am not familiar with utf-8 so using 'bytes' helps me personally(not sure if it's helpful though).
EDIT: understand better now, watched a bit longer and realized it's metadata of the 'decode_utf_8' method results, not the resultant bytes...
> why name the type 'decode_utf_8_result' instead of 'decoded_utf_8_bytes'?.
Your name makes sense, but when I see "bytes" I expect to see an array or something.
I use [functionname]_result in a few other places in my code. It's a convention I picked up from somewhere and never noticed until you made me think about it.
This is good, clean code that I would be happy to work with or contribute to. Pragmatism over dogmatism, I like it!
I wouldn't call it clean! 🤣
What are your thoughts on C++ core guidelines? I see you use orthodox(not 100% for your case) C++, I mean a lot of professionals still use orthodox C++ but will you guys ever get on to ISO C++ and C++ core guidelines? This is probably the larges rift in C++ community right now, everyone can write in their own sets of rules, It definitely has a benefit but it's also a problem right?
Why is it a problem? Maybe an annoyance for a week or two if you move from one job to another while you learn the nuances, but that’s the same thing in every lang no?
> This is probably the larges rift in C++ community right now
The coding style things which the C++ core guidelines discusses are minor.
Learning libraries (especially for concurrency) and the architecture is a much harder part of switching codebases than code style.
> What are your thoughts on C++ core guidelines?
The C++ code guidelines has good advice, but it doesn't change how I code much.
Some advice, such as "ES.11: Use auto to avoid redundant repetition of type names" and "ES.20: Always initialize an object" and "ES.23: Prefer the {}-initializer syntax", are stupid. I tried it and didn't like it.
Other advice, such as "ES.12: Do not reuse names in nested scopes" and "ES.26: Don’t use a variable for two unrelated purposes", is good and can sometimes be compiler-checked (thus enforced).
@@strager_ I do like the auto style. Not for everything, but it's a consistent line style and you can specify type on the right side. Most code analysis tools can tell you the type if you aren't clear, and C++ doesn't have multi-line inference like rust. It _does_ decrease code changes needed when changing the type in other parts of the code base. I don't personally use {} for everything myself.
@@Tyler11821 not a fan of needing IDE features to be able to tell what type is returned. I legitimately see no reason why you would want to abbreviate the function definition with auto. If you're in double-colon hell, use auto-complete or simplify the structure of your namespaces. Make a recognizable alias, if you don't like the other two solutions.
Was wondering what font you use, 49secs in I got an answer. I use MS Comic Sans (since the 95 odd) for the same reason. I find it very readable and natural. But the one your using looks better.
Comic Code: tosche.net/fonts/comic-code
@@strager_ cheers have already bought and installed in Rider. Looks very readable.
Galvin Belson himself approved this code.
I forgot about the anonymous namespace thing. I would recognize it if I saw it, I know the semantics without having to think about it... But I could be using it in my code and I tend to forget. ^^()
u r amzng bruhhh ❤
bruuuuhhhh🤯
@@discotecc fr bruh is kinda bussin no cap
@@bithon5242 free online learning resources.. its lit💯
God mode! ❤
Put jump short hash/text above the copyright, so you can quickly get to it with a shortcut key attached to a find script? Obvious I know! Huge fan!
Are you saying I should put the copyright stuff in a separate file, and just link to it from the top of the file?
I could do that, but if someone copy-pastes the entire file into their project, the relationship is lost.
@@strager_ I was suggesting that you put a comment beneath your code that you put in all your code like a signature. Like #end-5437 , then put a shortcut key in your editor attached to find feature that automatically jumps to this code bottom rather than bottom of license which is after the code, simple and probably stupid for some reason I haven’t thought of, this assumes your editor supports macros
@@wanfuse you could jump to the end and scroll back once or twice
what font is this . Looks really good. Also great vid btw. learned a lot .
That's like the first thing in the video, how'd you miss it? :)
thoughts on #pragma once? very well supported by compilers, no need for header guards matching directories and filenames (which kinda eases refactoring of file names and dirs) and avoid's the need of a tooling script to fix it.
I'm a long time user of header guards, but recently changed to #pragma once. Just wanned to check if you see a reason for not to prefer it.
For this project, I prefer to stick to standard C++ unless there's a good reason to deviate.
I don't have any good technical to avoid #pragma once.
@@strager_ You'll intentionally invoke UB just to avoid exceptions but pragma once is too radical?
I want this t-shirt!
It's MINE!
i dont understand anything what the hell is going on
I'd like to see you use vscode for 1 month
cringe
I would probably name decode_UTF_8_result the same as you (I may remove the _ between the F and 8) But if it doesn't have any acronyms in it, I would just use camel case
If it's truly a helper function, having it defined as a lambda inside of the function that it's helping seems better to me ...
You're supposed to use std: unique
11:16 And on top of that I'm not always looking at my source control, which is why putting some sort of identifier there is a good idea
Why not make char8 alias unsigned char when char8_t in unavailable? That should avoid all the casting issues.
String literals are const char*, not const unsigned char*. 😬
But you do bring up a good point. I could use a string operator thingy to fix this problem... 🤔
1:18:30 This is why i always use my own prefixed name for some questionably portable functions. So if i have to work around it, i don't have to go replace the name everywhere.
For me, the problem isn't changing the codebase to use the new function. The problem is remembering to use my version in 6 months when I forgot I had to work around the bug. 🙈
@@strager_ One problem i have with code is that useless and outdated things don't look out of place at a glance. Sometimes i honestly leave snippets of code around because i quickly needed to go solve another problem and forgot to continue the previous one.
You don't need to write util:: everywhere, you just need using directives. But if your utils are not imported/shared/common/conflicting, then you don't need to bother.
The naming convention I personally favor in C++ is snake_case for everything that's not a type and Snake_case for types. This way I get the readability of snake_case with the benefits of distinguishing types from other things, like getting to use the very common pattern Foo = foo();. I hold to this even if the name contains acronyms; so a frobnicator for UTF-8 characters would be called a Utf_8_frobnicator. This avoids having to come up with unnatural names to prevent any class names ending up in ALL_CAPS, which to me looks like a macro.
Hmm, this makes sense. I might try it some day.
I prefer camel case, maybe because I am a Java nerd... Hate the underscores.
I agree with you on most of what you said what's your opinion about modern C++ and the zealot who think about doing just that and never use old c/c++ like you said earlier they think of never using normal old pointer or managing memory by hand etc I think it's starting to be a bit ridiculous etc... can't wait to see what A.I. will do to the field ...lots of devs are afraid of AI since they are just typing text in a file thinking about it
I prefer C, really. I like how GLib implements objects in C which can be called from C++. Also, I like the explicitness of manual malloc.
@@____-pn8yb loool from what I understand and I read online now from C++ guru's most of the people who didn't move from C are dinosaur who didn't learn modern C++ correctly... who don't like change etc
I lol's at the squirrel
omg I want your shirt!!!!!!!!!!!
The heck is that VIM setup out of 1950 without any LSP, Syntax Highlighter or anything... At that point in time might as well use notepad for writing code.
Notepad doesn't support tabs.
this is good
2:20 you've come such a long way
"I disagree with Zifre. Any repeated license at the top is irritating for me. -
strager
May 10, 2009 at 19:55"
What.
You wrote "Any repeated license at the top is irritating for me." May 10th, 2009. I was making a joke.
all i want to know what IDE he is using ? and how is he so efficiency on the keyboard?
Vim.
I'm efficient after over 20 years of use and practice.
@@strager_ I spent a year or two getting used to vscode instead of vim... but I still sometimes type :w in my files by muscle memory and sprinkle some extra "i" characters around
4:30 I always found it stupid to add the same copyright notice in every file. Even if one copies the code, they would not copy this message, would they?
Copying a file is easier than copying a file + editing out the copyright notice.
@@strager_ When I copy code, I normally remove the comments first, then reformat, then rename variables and functions so it's easier to understand for me, or to fit my coding style better, I also do a bit of small refactors in cases where I don't like their coding style or it's difficult to understand.
Your code will run faster if you reduce the font size......
j/k.
Thanks for sharing.
My code would be so fast I can't even see it!
37:25 If I feel tempted to nest ternary operators, I turn it into an immediately invoked lambda instead. Honestly also in a significant part because clang-format poops its pants consistently otherwise, as you have demonstrated.
Hmm, I don't know how I feel about it. I think immediately invoked lambda expressions are kind of ugly in C++, and that outweighs the ugliness of the conditional operators. What do you think? github.com/quick-lint/quick-lint-js/commit/463ca5ee1d4093221a0718ea0ebb9190041a5840
@@strager_ One thing you can do when clangformat craps its pants is to use empty // to add newlines in the appropriate places. It's ugly still, but better than bad formatting, and way better than /* clang-format off */ nonsense. I found most instances of bad formatting could be turned into something acceptable with this (not sure there's much it can help re nested ternaries though)
1:30:15, D.R.Y. assassination?
1:38:14, does deleting 'x' content is the same as 2 identical blocks? Will it execute 'X' if it's in 'x' case?!
> 1:30:15, D.R.Y. assassination?
I wouldn't say "assassination". It's not that bad, really. But yes, the copy paste should be fixed.
> 1:38:14, does deleting 'x' content is the same as 2 identical blocks? Will it execute 'X' if it's in 'x' case?!
Yes. C++ has case fallthrough by default.
@@strager_ I thought fallthrough would still check the case for 'X'. And shouldn't you use the [[fallthrough]] (C++17)?
> I thought fallthrough would still check the case for 'X'.
Nope. That doesn't make sense, because only one case can equal the switch's input.
> And shouldn't you use the [[fallthrough]] (C++17)?
[[fallthrough]] is unnecessary if cases are right next to each other.
Computer Jesus! I found you!!!
At 28:30, you're expressing concern about "older compilers" and `char` vs `char8_t`.... Why? You're using designated initializers, which is a C++20 feature and requires a newer compiler _anyway._
what do you do for go to definition?
I don't.
😭
Either I know what file the definition is (in which case I open that file and search) or I use a project-wide string search (which finds more than just the definition).
@@strager_ Bruh, that's alot of wasted time.
Yup.
That shirt!
Works do in fact become public domain after copyright expires.
Have you tried treesitter for highlighting?
Nope, not yet! I want to try it though.
Just saying because of the highlighting issues you highlighted (scuze da pun 😅)
Using treesitter solved some highlight issue I used to have on neovim.
BTW, I am using the same font as you. I agree it is easier to read. Though I hope one day I'll have the time to patch it with my own handwriting LoL
7:05 inline namespace on ondemand
Long hair programmers.. are OP af
love that shirt.
Couldn't you make helper-functions static?
A lambda that does not capture anything is stateless, so making it static is pointless.
I could make certain helper functions static, yes. What advantage would that have?
Holy hell
How cool is this guy, i'll get anxiety working with this large of a codebase. Btw which keyboard is that?
It would seem that he truly is a C++ guru.
can i steal his thread implementation?
No. Stealing is wrong.