robinm
So cute!
There are 2 metrics that need to be considered:
- easy to read
- easy to modify
The first point is by far the most important. Usually DRY win because less code means less to read so less to put in your head. But if the abstraction is too complicated (for example because there are two many parameteres) then it’s worth considering drying.
And don’t forget the second point, but do not overthing and YAGNI. Sometime a simple comment “don’t forget to update method foobar()
” is enough. Don’t forget either that you can always rewrite the abstraction when you need to modify something (if the original did not fit your new requirements), but for this to be an easy task, the understanding of the original abstraction must be crystal clear. That’s why the first point is so important.
Couldn’t this be solved by having push_back
being an inline function (or at least the check on capacity being inlined and the rest of the non-trivial part being in a sub non-inline function)?
As far as I know, adding the support for restrict didn’t trigger any bugs in GCC
That’s very impressive for gcc. IIRC adding restrict to LLVM triiggered major bugs and miscompilations at least for the first two attempts. As they said they need to do a crater run to be sure, but even passing the initial smoke test is an achievement for gcc.
However, I’m surprised the code is “only” 3% faster using restric annotation. IIRC the speed-ups were about 5% for LLVM so maybe there is still some performance to gain on the gcc side?
The devil is really is the details. One year ago, I felt that the progress was moving so fast I had the feeling that it was close to being finished, but it seems toat it’s much more complex than what I thought. Nonetheless, congratulation to all contributors!
On reddit, someone was always linking to the donation page for antonio. I liked that tradition and hope that someone will continue it on lemmy.