Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)R
Posts
2
Comments
133
Joined
2 yr. ago

  • 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!

  • 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?

  • You have not read enough code from IOCCC.

  • And cgdb is kind of the same but with better controls and syntax coloration.

  • That's totally right but I thought you were talking about signed numbers since you said “integer overflow”. I forgot that len is usually unsigned in C++.

  • emplace controls the construction of the object added to the collection. It's also important but not related to the problem exposed by OP which is “how to remove the capacity check when we know statically that there is enough space”.

  • I use win+arrow key quite a lot too.

  • In C++ integer overflow is UB so this edge case cannot exist

  • 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)?

  • 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.

  • There is no need for personnal attacks when someone is wrong.

  • And you should not forget that Emacs is way harder when you are 4 because your hands are smaller!

  • So cute!

  • It's also quite opinated (which I consider a good thing) so that what the author of lib.rs considers relevant crates are shown first.