Years ago I was a student at L&N. Back then it was still very experimental. Lots of things being figured out.
It's been a decade and a half since founding. I'd love to check in on things and see what it's like these days.
Anyone that went there wanna chime in? Or perhaps parents of students? I'd love to get an update on anything and everything!
I'm trying to see if there is any prior art in the to-string space that accomplishes a two phase approach. In theory, you could design an API that first asks the data "How many bytes would it take to make you into a string?". From there it could allocate memory with that capacity. Then it could provide that allocation to the same data to populate the bytes.
I want it to be very light weight and easy to add to a type. The `AbslHashValue(...)` API really nails the ergonomics of an extension point in C++, imo. But when it comes to to-string, it gets pretty hairy pretty fast.
`AbslHashValue(...)` benefits from the fact that the resulting hash has a fixed bit width. You just combine/combine_contiguous recursively and you're done.
Some hypothetical `MyToString(...)` would need to likely be split into two functions. `MyToStringSize(...)` and `MyToStringValue(...)` which already makes it more obnoxious to add support for in your type.
But it gets worse. What if inclusion of the type names is important? I can imagine wanting a lever at the top level that says do or do not include them. So for the case where you do include them, how do you succinctly compute the length of namespace + scope-resolution-operator + type name.
And what about templates? Do you also include the angle brackets? Do you recursively include type names between them? And what about potential line noise like allocator types? I can see wanting to include them and not wanting to include them.
Further, what about hashtables? If you store the keys and values in separate ranges for a more data oriented design, how do you model the fact that each K-V pair goes together? You don't want to copy them because that might be expensive. So do you supply a proxy object where it has two pointers? Now that means you have to build an entire TYPE inside your type just to support to-string. Not very ergonomic.
Anyway, wanted to discuss this to see if anyone has ideas in this space. It seems to me that to-string as an operation should be unambiguously single allocation. But unless I'm mistaken, `absl::StrCat(...)` and other such APIs only "limit" the number of allocations and cannot put the upper bound at exactly 1.
I called BestBuy to ask if they had any USBC-HDMI cables/adapters. After fighting the AI assistant I spoke to a real human that was not able to help me.
Then I called Walmart. They instantly picked up, no AI, and they had what I needed. I drove over and got it. Ezpz.
Walmart is the best!
I've used Google's logging library in the past and I would give it a solid B- grade. It gets the job done. I really dislike the streaming operator, but meh it's not that bad. It just feels weird if I concatenate the string beforehand: LOG(INFO) << absl::StrCat(strs...);
As I embark on my new project, I want to make intelligent decisions about what idioms to favor. Logging is a big one, so I'd love to hear what people out there use.
In particular, if there is a library that uses reflection to give named arguments, that would be perfect! My ideal callsite would look like this:
my::LogInfo("Hello, {person}!", {
.person = GetPersonObject(),
});
It would also be cool to get assertions baked into it, though that complicates the design space.
Anyone wanna chime in?
I'd heard about Foothills Milling many times. Finally made it today and really enjoyed it!
Anyone know why they're only open 11am-2pm? Seems... strange?
Edit: I meant Foothills Milling Cafe, sorry
The moderators removed this post for understandable reasons: https://old.reddit.com/r/cpp/comments/1t9792i/ziglike_defer_for_c20_and_above/
But underneath it was a great discussion about the broader defer idea in C++. I'd love to have that conversation.
What do you use for this behavior in your code? What are the pros and cons of the choice you made?
Lambdas do a great job in a lot of cases but sometimes you need a statement expression. Any good content on youtube?
It's been replaced by yet another mattress store 🤮
No idea how long this has been the case but it's still disappointing.
I am a huge fan of the Abseil C++ hashmaps and I'm so glad Rust as a community embraced them in spirit. And the fact that we got multiple implementations out of it is just the cherry on the cake!
I'm considering mapping types from Rust into my C++ codebase. I don't have the time to maintain libraries myself at this stage in my career. But I do want to continue to deliver on my goals as a software engineer. Where I can use good implementations from Rust, I intend to.
But is there any interest in adding an SBO/SSO compile time configuration nob to std::HashMap?
We can start with just making it a global switch to experiment with. And then maybe promote it to a defaulted generic parameter to allow fine grained control at the spellings of the type in the codebase.
Or if the global switch is a bad idea, is there any reason we couldn't just jump to updating the type such that it includes a param for controlling an SBO/SSO buffer size?
API wise I prefer passing in the element count. But I can see an argument for passing on byte count. Either way, some such mechanism would be awesome!
Given some aggregate like this:
struct InitParams {
int size = 0;
int capacity = 0;
};
And given that it is used in some factory function like this:
auto Make(InitParams ip = {}) -> std::optional<MyClass>;
I want to design the aggregate type to allow callsites like...
Make({ .size = 10, .capacity = 20 });
Make({ .size = 10 });
Make({ .capacity = 20 });
Make({});
Make();
But I also want to reject callsites like...
Make({ 10, 20 });
Make({ 10 });
Make({ 20 }); // Oops! This is the size, not the capacity!
I was hoping that reflection would unlock the ability to specify this on the type alone somehow, but I've been unable to figure out how to do it.
I can approximate this behavior using an overload set where a similar-but-different param type is accepted by a different Make overload but then that would result in default construction being ambiguous too. You can see that in action here:
struct DesignatedInitRequired {
int DO_NOT_SPELL_THIS_FIELD_NAME0;
int DO_NOT_SPELL_THIS_FIELD_NAME1;
};
auto Make(DesignatedInitRequired dir = {}) -> void = delete("Use designated init");
Make({ 10 }); // Ambiguous, ill formed (which is what I want)
Make({ 10, 20 }); // Ambiguous, ill formed (which is what I want)
Make({}); // Ambiguous, ill formed (which is NOT what I want)
Make(); // Ambiguous, ill formed (which is NOT what I want)
So I could make something to reflect on InitParams and produce DesignatedInitRequired, but that wouldn't be enough. Every function that accepts InitParams would need an overload for DesignatedInitRequired meaning that it becomes a property of the type AND its users, not just the type itself.
Any ideas on how to achieve my goal?
EDIT: I think this is a sufficient solution! https://godbolt.org/z/h6sbcaTj4
I thanked the person that told me but then they deleted their comment. Anyway...
For those that have built applications on AWS using serverless architecture, what challenges have you faced implementing the business logic in a compiled language?
Serverless is a compelling paradigm because resources can scale up to meet spikes in demand. It's hard to know how a product will be used before launching, so it can be reasonable to reduce development costs by leveraging a managed environment (instead of squeezing perf out of EC2).
In the future, it would be great to drop down to something lower level, but for now I'm trying to get the most benefit out of serverless as I can.
Any advice?
Lightning Talk (C++Now 2019, 8min): https://youtube.com/watch?v=kye4aD-KvTU
In 2019, Chandler presented the above talk describing a C++ map API. It's not compatible with the standard map types, but for greenfield projects I think it's an excellent choice.
I've considered implementing it myself, but hash tables are very subtle and finicky. I'd rather rely on a robust implementation.
Abseil has some excellent hash tables, but to my knowledge they do not support the small size/small buffer optimization. Chandler's hypothetical API does. Would be great to have the SIMD probing algorithm from Abseil implemented for an SSO map type.
My old AirSense 10 was displaying a warning that it was past its useful lifespan and I needed an upgrade.
I purchased a brand new AirSense 10 in August 2025. I bought it in full with cash after uploading my prescription. I don't owe any money on it and it does not have any ties to any third parties (no SIM card, nothing).
Already, my new AirSense 10 is making an obnoxious sound that gets louder the harder I inhale. Makes it very hard to sleep! I reseated the hose and water container. I removed the air filter. I tested it both sitting on a table and held in my hand. Nothing works!
Thankfully I kept my old one around as a backup and it still works, so that's what I'm using at the moment.
What's the most direct path to convince cpap[.]com to send me a replacement device? I would rather not sit on hold forever just to be told I need to call a different person. If anyone knows the right number to call, I'd really appreciate it.
Back in 2018 an engineer/committee member made a splash by introducing CTRE, Compile Time Regular Expressions.
It was implemented using type aliases instead of constexpr function calls meaning it was easy to implement in C++11. Very impressive stuff.
It also gave you a nicer callsite spelling in C++20 leveraging generalized non-type template parameter passing.
I'm curious if anyone is still using it. If no, why not? I'd love to hear!