Cool! Follow me on Twitch if you want to listen to me for hours.

Indeed a good video to watch if you have insomnia and can

You're welcome!

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 :)

You're welcome. I hope you don't borrow my bad practices too! 😆

My style evolves with every project.

Good comment.

> 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)

Yeah, my util/utf-8 module does need to be improved. Same with every other module... 😅

I recommend against roadmaps. I suggest picking a project idea and working on it.

I don't know about Visual Studio Code extensions, sorry. Maybe it's possible with a color scheme.

Yup, it's Comic Code. I love it! tosche.net/fonts/comic-code

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

I'm sorry that I am so boring 😭

@@strager_ You voice is absolutely amazing.🫀

Yeah, portability is a small burden but it's all over my code. =\

> 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/

I didn't talk about code navigation in this video. (I think...)

In this case, I think it's easier to read similar code if they're at the same nesting level.

use what you like, screw what other people think, they're not the ones staring at it 10 hours a day

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

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.

You're right! I'll fix it. Classic off-by-one error. github.com/quick-lint/quick-lint-js/commit/e9fccba1f9f842dab130f559e0562a0e40a1542a

Comic Code: tosche.net/fonts/comic-code

@@strager_ cheers have already bought and installed in Rider. Looks very readable.

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.

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.

Yup! Luckily I don't have to deal with that much because I am making an application, not a generic library.

_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

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

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 wouldn't call it clean! 🤣

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.

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

That's like the first thing in the video, how'd you miss it? :)

It's a custom shirt. Not for resale!

> 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?

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

It's MINE!

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.

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

It would seem that he truly is a C++ guru.

if it works don't fix it

I don't need no trendy bells and whistles!

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

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

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?

No. Stealing is wrong.

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

Hmm, this makes sense. I might try it some day.

I prefer camel case, maybe because I am a Java nerd... Hate the underscores.

What.

You wrote "Any repeated license at the top is irritating for me." May 10th, 2009. I was making a joke.

I rarely deal with Java. I haven't written even 10k lines of Java, let alone 100k lines. So I think a Java video wouldn't be insightful. xD I do like IntelliJ for Java though.

​@@strager_ IntelliJ is god

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.

My code would be so fast I can't even see it!

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)