> Or were you asking if it leaks memory?
yeah,
If variable c where of type void* instead of duck<Container>, the assignment on line 13 would leak the memory used by the vector<int>.
1,713 karma · joined December 16, 2012
I enjoy Rock Climbing, Go, Software Engineering, and Buddhism.
dilapidated homepage: https://slow.camp
yeah,
If variable c where of type void* instead of duck<Container>, the assignment on line 13 would leak the memory used by the vector<int>.
Thanks for the blog post.
```
10: rjk::duck<Container> c{std::vector<int>{1, 2, 3}};
11: c.size(); // 3
12:
13: c = std::string{"hello"};
```
Does the assignment on line 13 call the destrucor for the vector of ints created on line 10?
Nope. I was on a Python project in 2006 and earned a paycheck doing so.
Really great advice. Last week I configured my wifi router at home to block youtube entirely. I literally feel like a different person in just a week. I have so much more free time and I am so much less anxious.
> Avoid even audiobooks.
Controversial. I suppose I used to not have an opinion at all on this topic, until I saw an interview with Salman Rushdie after the failed attempt on his life. He said he since the attack, and loosing his right eye, he reads with enormous fonts on an ipad, or yes, he even listens to audio books now.
If audiobooks are good enough for a seven time nominee of the Booker prize, who am I to quibble?
I do not have exponential funds in my allowance...
safety stilts.
No thank you.
Humorously, whether I choose to participate in this hypothetical or not, I am already betting my ass.
This whole situation feels like the game [1].
There are huge numbers of users (myself included) that do have an exact idea of what inference costs are - on open models. We can buy tokens from 3rd parties that have no motivation to subsidize our use. That's to say, there's a fair marketplace[1] and we're hanging out there.
If you want to say "I don't think anyone has a firm grasp on actual inference costs on these proprietary/closed models", then I could agree with that.
It sounds like you are a strong candidate to try out the new improvements mentioned in this devlog and see what benefits you can get for yourself.
I’ve literally never heard this from anyone before, and I have to admit, I’m curious enough to try it for myself.
The last time I tried FreeBSD was 2001.
Your agent harness, brokk, looks great. I’m going to try it this morning.
The article is about an open source agent harness, Reasonix, that is built to leverage the DeepSeek native api.
There’s no company here. No design budget. These people are graciously sharing a project they made in their free time.
From the FAQ, I see:
>Can I point it at a self-hosted / private DeepSeek endpoint?
>Yes. Since 0.30 we accept non-standard key prefixes for self-hosted DeepSeek endpoints. Just point `baseUrl` at your internal address — the loop, cache strategy, and tool protocol are unchanged.
But my question is: If I use Reasonix to talk to a deepseek endpoint through openrouter, am I still getting the cache-hit benifits of this agent harness?
Anyhow, I'm pulling myself up by my own bootstraps.
For me a 5% overhead is fine... if it gives me better visibility of this rapidly moving field.
I love that you are both making this argument and that you have a link to a boutique C compiler written in assembly on your home page.
While I'm commenting on your home page - I recognize that photo as being Red Rock. Possibly pine creek? but can I ask which route specifically?
I can't claim it's "the best"...
But the Pi.dev and OpenRouter combo is what I'm doing at home, and I love it. Setup was easy, I can use /model to switch between any of the openrouter models and whatever I'm hosting locally via VLLM.
I run small models at home, so I'm very curious.
So we shouldn’t be comparing it to the cost of open router api access at all, we should be comparing it to the cost of a 4 credit university course.
-- So is deepseek-tui.
I run dgx spark, and the results here are soooo incomplete for my platform that I can’t trust this site (for my usecase).
I'll just point out that Lakos updated his work with a new edition in 2019:
Large-Scale C++ Volume I: Process and Architecture
and there's scattered evidence that Volume II might be published in Feb. 2027 [1]
Large-Scale C++ Volume II: Design and Implementation
[1]: https://www.amazon.co.uk/Large-Scale-Implementation-Addison-...