Building your own debugger is a powerful way to understand Linux internals.
From forking and tracing to handling signals and interacting with registers, you'll gain practical insight into how debuggers actually work.
It’s also a solid exercise in writing clean, testable C++ systems code.
Dare I admit that I don't really understand what std::move() does? Of course I dare. #CPlusPlus
Reading the "Move: What it is, and how to use it" section on https://herbsutter.com/2020/02/17/move-simply/ , and comparing to the codebase I am working on, I think I see a clear discrepancy. The code uses std::move() a *lot*.
This is cool: A user-defined string literal operator that turns string literals into their (compile-time) hash codes. Might be useful in some codebases to avoid having to maintain unique numerical values for a bunch of identifiers.
(But it might be that in large codebases, the time to run all these compile-time hash functions adds up to be unbearable.)
(I was specifically thinking of the "slot IDs" in #LibreOffice that have to be manually maintained.)
Go home, Clang, you are drunk!
Ang journey sa libo ka linya sa #code 
magsugod sa usa ka #HelloWorld! 
Mao ni akong #Cplusplus setup sa #VSCode 
Gusto pud ko makakita sa journey sa uban ug makakat-on sa ilang tips sa kini nga field 
The pre and post increment operators in C++ are two different operators, so if you overload them you could make i++ and ++i do completely different things - assuming you hated the person who would have to maintain your code.
I wish the C++ standard had chosen a different term than
noexcept(false)
to indicate a function can throw. Why couldn't we use throw() and throw(...) instead for doesn't throw or throws some exceptions? The former is identical to before, and the latter was invalid before, wasn't it?
And it would be similar to catch(...) !
Say, is there a trick in C++ to make to_string() work for any type?
If I have
using namespace std;
and then just write
to_string(foo)
it will prefer my local namespace's to_string(MyClass) and error when given an int, instead of picking std::to_string(int) for those.
Do I really have to add all variants of
inline string to_string(int n) { return std::to_string(n); }
to my namespace to be able to just say to_string(foo) for any type and make it work?
Some nice additions for annotating C++ code to make it import better into Swift:
I'm starting to decommission std::format because of a disagreement with the C++ committee #programming #cplusplus
Oh, I forgot my other complaint.
4) The reference implementation Radicle client is written in #Rust. Not necessarily a problem, since if the protocol takes off there will certainly be implementations in more mature languages like #Python or #CPlusPlus, but I don't love the extra bit of uncertainly with a new language along with a new protocol.
My notes from May 2025 include a list of tech jobs for good, more problems with LLMs, and a sick C++ burn. https://evanhahn.com/notes-from-may-2025/
Hmm… just realized, there is a 5:
5. Forward-declare a struct that you define nowhere, and to which you keep a pointer in the context.
That way, no need for dynamic_cast<>, # define or generics, and you still get type-checking. The app just has to know to define that type.
#CPlusPlus mavens!
I have an "interpreter context" in my programming language. The data structure that contains the stack, current instruction register etc.
I'd like to let apps that embed my compiler/VM attach their own data structure to each such context.
What's a good solution?
1. templated context, (means the entire interpreter becomes templated)
2. void* that the app dynamic_cast<>s to its type
3. # define for the app-specific field's type (interpreter has to ship as source now)
4. ?
#engineering #commonLisp #smallWeb #Cplusplus #insane #future #clKitten https://screwlisp.small-web.org/momentary/screwlisps-cl-kitten-future-theory/
in which I lay out a terrifying nine step complete overhauling of present popular #software #technology. I named it my Insane Fairy Godmother theory.
@uliwitness
Nobody stops you from writing:
class Foo {
public:
int _bar;
Foo(int _bar) : _bar(_bar) {}
};
There you have it, no new language required.
Things I wish they fixed in C/C++:
When you init an instance variable from a parameter, you often copy-paste the name of the instance variable into the parameter. This allows you to accidentally forget editing code and generate perfectly compiling but wrong code like:
class Foo {
public:
int _bar;
Foo(int bar) : _bar(_bar) {}
};
accidentally initializing a variable with itself instead of the parameter. (Thank goodness we have an "unused parameter” warning)
I wish I weren't a snob about such things, but the fact that most examples of breakthroughs in C++ are coming from the banking and fintech sectors isn't something that makes me more excited about the language.
"Check out this cool thing. We've used it to improve the efficiency of our HFT platform."
... gooooooooooooooood.
I know I follow a lot of indie game makers here, but I have little idea of what engines any of of you use. Anybody here know about C++ compiling? @josemachete79 is working on building his own version of #Angband from a cloned repo, and is running into issues compiling.
Any help anyone can offer would be much appreciated- I've played a test build or two of the game and it's working great except for these final compiling issues. Hit him up!
(The image below is a screenshot of the starting character I randomly generated to use when testing one of the builds.)
modules addict) 
