my local experiments showed any tricky scheme I could come up beaten by plain large window zstd. both on speed and resulting size (memory needed for the window is another matter completely). zstd also was beating the git xdelta+deflate.
The most "free lunch" actually is compressing fast export (or similar format) — if the goal is packing repo as small as possible, then all the SHA in commits and tree objects are derivative incompressible data, and plain references like in fast export can even halve archive size
Same. After this, it becomes "abuse department" skit from monty python. The model constantly generates strongly abusive language (weaponized incompetence after user detects that model was lying and fabricating success reports, and had made fake work; blaming user; mansplaining its own hallucinations -- all the while user is forced to consume that because the important information is not located at predictable position in output text), but usually it was possible to temper the model behaviour by calling out such behaviour out in very strong terms.
If now that is being disabled, then using Anthropic models becomes such high mental hazard, it simply is not worth any percieved benefit.
I made my own with AI! It does the thing I need that no existing software does!
I do not however feel urge to upload it an ask strangers to look at what code tool assembled from bits and pieces of existing software by hallucinating into compiler.
It is objectively bad. Also very fun. Even useful. I do not understand the bit about publishing though.
Once this starts being actual pain, we will each vibe the replacement index creator (git already supports replacement objects), for back-forth conversion, populated on pack and object indexing.
For massive perf and mem use damage. But oh well. And then we will wait for official version
RPKI is great, and I use it for everything except for two /24's that I got pre-ARIN. However, RPKI won't help with the situation where some kind of compromised host is worming its way through the internet running nmap against everything. Most of the IP addresses showing up in our dragnet are in fact announced by the very ISPs that own them. Most of these do not appear to be bogons.
Was not groundwork laid when people were talking for decades about legal entities using such language? Look at the posts here. Microsoft always acts like that, Meta like this, Apple did that, Nvidia never does this. In a tone that ascribes agency and accountability to a company name. Even though it is always individuals that are responsible, not "company".
"This article was originally published in Polish in issue 4/2013" — a lot of excellent advice. Sad to see C++ have moved in last decade in a direction that makes writing efficient, simple low level code harder and harder :(
Writing clear, concise, and efficient code in C++ has never been simpler or easier. The improvements in C++ over the last 15 years have been qualitative.
So many complex, esoteric, and difficult to maintain incantations that used to be required for efficient code generation are no longer necessary.
That was addressed circa C++17 IIRC, same with all of the technically UB surrounding DMA memory. You needed non-obvious incantations for some use cases but they were expressible. C++23 eliminated most of those incantations. Before all of this you had to use “blessed” incantations that were technically UB but which compilers needed to allow because the code was expressing a valid use case.
I find it crazy that popular systems languages didn’t have an explicitly valid way to deal with all of these ambiguous ownership and lifetime issues around memory until relatively recently.
Can you give some specifics? I feel like this is adjacent to my work and I'm not sure what you're referring to which makes me feel I've missed something important.
Not OP but I believe this is referring to defining a `volatile const` for a read only register which C++ does not allow because you would need to initialize a const. Not sure what the C++17 solution would be
C++ implementations don't make any sort of special or unique accommodations for UNIX/POSIX APIs. For the most part calls into external libraries are firewalled and not optimized in a way that typically engenders undefined behavior, so POSIX APIs tend to work. But any external library would also work since it's not like POSIX is exclusively shielded or singled out in any particular way.
You can try to request a refund for free software but the terms of the compiler explicitly state that undefined behavior is permitted to "time travel" and that there's nothing faulty about it. That's C++ for you ;P
I think it has become EASIER: for instance, since C++23 Rust-like move semantics can be used, which provides the compiler with extra information that can be leveraged for the generation of better code.
Or take constexpr - it permits to move computations to compile time that are complex and in older versions either had to be done at runtime, or an ugly workaround had to be used (e.g. assigning a mysterious literal pre-computed in another run or by hand).
The closest thing I can think of is trivial relocation [0] which matches the bitwise copy + no destructor on moved-from bits of Rust's moves, but that was only added to the draft for C++26 and was removed late in the process anyways [1].
There are so many things that are expressible in C++ now that could not be without writing much more code or using per-compilation tools back then. The ability to run code at compile time that is not run at runtime is huge, #embed lets us make other tools output available without linker scripts or compiler specific tools that.
Also, most of the code from the past still works(from 10 years ago definitely works)
Shot in the dark, but maybe the OP is referring to the fact that these code conventions are explicitly discouraged by the C++ core guidelines. The SoA example falls afoul of the rule requiring T* to be used only for singular object pointers, for example.
Not a regular C++ programmer but wouldn’t you use std::span here instead? Sure it’ll carry a few redundant lengths but it makes using functions that take spans easier. When I do write C++ it’s usually for speed so I’m often working at the intrinsics level, though AI has gotten good enough at it that I now generally delegate this work to an agent.
Okay? The point of the guidelines is to document principles the committee's thinks "good" C++ should follow, within the much larger universe of possible C++ code.
Yes? Instead, we have committee declaring large bodies of existing code invalid and non-conformant, because it does not fit their spherical cow C++. You would think, with amount of no-exceptions and no-rtti code out there, and feature being present in most compilers for decades, they would take a hint and reflect actual usage in their standard? No, why would they. Any C++ that has no exceptions, rtti or std:: namespace is invalid. Not even against guidelines.
To summarize, the grandparent comment lamented how it's sad that the modern language has diverged from the code in the article. Someone else pointed out that the code still works. I suggested that the complaint remains valid in spite of that because the language committee's core guidelines prohibit it. Notice I haven't mentioned my opinion at all.
You've responded to that suggestion with seemingly irrelevant comments. Do you see why I'm confused?
For what it's worth, my actual opinion is that the committee is usually wrong/misguided.
eh, yes-ish, but only thanks to compiler writers. at one point committee went all-out enforcing their lifetime model, making bit_cast not an option. If your code accesses same data using different types, you are spelunking ruins with snake pits and lava. more and more stuff needs magic support code in std::, making no-lib code less and less possible (it used to be that with no-rtti and no-exceptions, you could use all c++ features and only needed cxa_at_exit, operator delete, and few other little things. NOT ANY MORE).
On one hand, you have consteval and stuff, letting you FINALLY initialize data at compile time (hey, 20 years late but still!)
on other hand, it is done in most non-debuggable way possible. try setting breakpoint or adding print to constexpr function that causes your requires clause to fail...
so no, newer C++ the language is not possible to use for low level work. The dialects that compiler makers support are. We will see for how long
In my domain, code size is critical, so we use -fno-exceptions and -fno-rtti from necessity, for a good reason. Which means our code is non-conformant C++. Committee forces everyone to have exceptions and rtti always.
OK. I would expect those flags to be required for most embedded work.
But I could imagine use cases for new-ish constructs like `constexpr`, `std::variant`, template constraints, and so on.
I don't quite follow what you are saying about the compilers. Are you saying that in future, compilers will have to choose between supporting new features and allowing non-conformant code?
Because of the elitist, exclusionist air it has gathered around itself, I guess. Trying to get something to work with zero knowledge about it is a maze of twisty passages, all alike.
After following breadcrumbs across blogs, I found the proper incantation, executed it, got "too many arguments" from shell, along with multi-megabyte error wall, did not find anything related to the issue, wrote my own slop-makefile.
it can not not? moreover, it can totally ruin existing invariants, introduce dead code, falsify tests and sabotage further work by poisoning comments and documentation in a few hours.
Although I don't fully agree. With AI the focus now shifts a lot from 'being able to implement the thing' to 'being able to know/figure out exactly what you want the thing to look like', also against the siren song of the LLMs constantly having ideas of what you could _also_ build.
So, I agree that it's not a direct translation from 'pro pizza cook' is 'pro pizza orderer', but I'm quite sure the pro pizza cooks would generally have the better pizzas in the end, if there were infinite variations of pizza on the menu and the ordering agent was constantly trying to upsell you on slathering on another layer of sauce and cheese.
Which is not to say there aren't exceptions in both directions, because as a pro pizza connoisseur you could even be better positioned to 'know exactly what you want', without ever having made a pizza; and as a pro cook you might still be overwhelmed by the ordering process.
Though all of this still assumes of course that we are in the 'complexity region' where we can expect the LLM/the pizza agent to deliver _exactly_ what we wanted, without issue. As soon as we leave that region (though it expands every week, it feels like), the skills of the cook are still very much necessary to make sure things are as they should be, and fix them if not.
there are two completely different activities both called "writing software using AI".
At work, for important stuff, I go through every change, mine or LLM's, edit it, clean it up, rewrite, until I am satisfied with the code.
At home and for one-off unimportant stuff I go "computer make me sandwich".
The second is nothing like the first. No amount of design and pro I have can make sure stuff coming out of LLM actually implements it, as opposed to me be tricked into thinking it does. After all, that is exactly the training criteria – convince the "eval" that task is accomplished, isn't it?
And the second kind of activity takes skill that no amount of "I am pro dev" can compensate.
The most "free lunch" actually is compressing fast export (or similar format) — if the goal is packing repo as small as possible, then all the SHA in commits and tree objects are derivative incompressible data, and plain references like in fast export can even halve archive size
reply