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/)L
Posts
439
Comments
601
Joined
3 yr. ago

  • Naked pointers are just too stupid for modern C++ ;)

    Anyone who works on real-world production software written in C++ knows for a fact that pointers are a reality.

    Also, there are plenty of frameworks who employ their own memory management frameworks, and raw pointers are perfectly fine in that context. For example, Qt uses raw pointers extensively because It's object system implements an object ownership system where each object can have child and parents, and you can simply invoke deleteLater() to free the whole dependency tree when you no longer need it.

  • Simply taking std::string by value (as it is a memory management class created for that explicit purpose) would have solved the problem without kneecapping every class you make.

    I think you are missing the whole point.

    The blogger tried to make a point about how special member functions can be tricky to get right if you don't master them. In this case, the blogger even presents a concrete example of how the rule of 3/rule of 5 would fail to catch this issue. As the blogger was relying on the implicit special member functions to manage the life cycle of CheeseShop::clerkName and was oblivious to the possibility of copying values around, this resulted in the double free.

    You can argue that you wouldn't have a problem if the string was used instead of a pointer to string, which is a point that the blogger indirectly does, but that would mean you'd be missing the root cause and missing the bigger picture, as you'd be trusting things to work by coincidence instead of actually knowing how they work.

    The blogger also does a piss-poor job in advocating to explicitly delete move constructors, as that suggests he learned nothing from the ordeal. A preferable lesson would be to a) not use raw pointers and instead try to adopt a smart pointer with the relevant semantics, b) actually provide custom implementations for copy/move constructors/assignment operators whenever doing anything non-trivial to manage resources, such as handling raw pointers and needing to both copy them and free them whenever they stop being used.

  • Cloud @programming.dev

    Amazon S3 will no longer charge for several HTTP error codes

    aws.amazon.com /about-aws/whats-new/2024/05/amazon-s3-no-charge-http-error-codes/
  • C++ @programming.dev

    How to avoid one C++ foot gun

    pboyd.io /posts/one-c++-footgun/
  • Cloud @programming.dev

    Deno KV internals: building a database for the modern web

    deno.com /blog/building-deno-kv
  • Any style guide is better than no style guide. Until a better option is presented, something is better than nothing.

  • Data Structures and Algorithms @programming.dev

    Why the CORDIC algorithm lives rent-free in my head

    github.com /francisrstokes/githublog/blob/main/2024/5/10/cordic.md
  • Boy, that joke. How low can you go.

  • TypeScript @programming.dev

    Google TypeScript Style Guide

    google.github.io /styleguide/tsguide.html
  • Data Structures and Algorithms @programming.dev

    Visualizing Packrat Parsing (2021)

    dubroy.com /blog/visualizing-packrat-parsing/
  • Data Structures and Algorithms @programming.dev

    Why are algorithms called algorithms? A brief history of the Persian polymath you’ve likely never heard of

    theconversation.com /why-are-algorithms-called-algorithms-a-brief-history-of-the-persian-polymath-youve-likely-never-heard-of-229286
  • C++ @programming.dev

    Qt and Trivial Relocation (Part 1)

    www.kdab.com /qt-and-trivial-relocation-part-1/
  • Data Structures and Algorithms @programming.dev

    Packrat Parsing from Scratch (2021)

    blog.bruce-hill.com /packrat-parsing-from-scratch
  • C++ @programming.dev

    Results of the Grand C++ Error Explosion Competition

    www.tumblr.com /tgceec/74534916370/results-of-the-grand-c-error-explosion
  • C Programming Language @programming.dev

    A History of C Compilers - Part 1: Performance, Portability and Freedom

    thechipletter.substack.com /p/a-history-of-c-compilers-part-1-performance
  • PostgreSQL @programming.dev

    GitHub - supabase/pg_jsonschema: PostgreSQL extension providing JSON Schema validation

    github.com /supabase/pg_jsonschema
  • C Programming Language @programming.dev

    One year of C (2018)

    floooh.github.io /2018/06/02/one-year-of-c.html
  • Programming @programming.dev

    Lamport timestamp

    en.wikipedia.org /wiki/Lamport_timestamp
  • Data Structures and Algorithms @programming.dev

    Introduction to Loro's Rich Text CRDT

    loro.dev /blog/loro-richtext
  • Git @programming.dev

    Highlights from Git 2.45

    github.blog /2024-04-29-highlights-from-git-2-45/
  • Such gains by limiting included headers is surprising to me, as it’s the first thing anyone would suggest doing.

    Yes indeed. I think this is a testament of the loss of know-how we're seeing in software engineering in general, and how overambitious but underworking developers try to stake claims in technical expertise when they even failed to onboard onto the very basics of a tech stack.

    I'm sure it's a matter of time before there's a new post in Figma's blog showing off their latest advanced technique to drive down build times: onboarding ccache. Followed by another blog post on how Figma is researching cutting edge distributed computing techniques to optimize build times by replacing ccache with sccache.

  • The Philosophy section has quite a few wonky arguments; I’d skip it altogether.

    I agree. I wish they moved that to a standalone section so that it could be easily skipable. Reference docs can and should have a rationale, but a lengthy rant is not what leads people to the site.

  • 16BPP.net: Blog / The Performance Impact of C++'s final Keyword

    Jump
  • As a side note, the final keyword is only tangentially related with inlining. It's killer feature is removing the need to do pointer dereferencing when calling virtual members of instances of classes that no longer require virtualization.

  • Edit: just noticed this post is over 10 years old.

    It would be helpful if the title was edited to feature the release date. Context is king. So many things are absurd with regards to the current state, but are sorely lacking a few years ago.

  • Incidentally, this kind of passive-aggressive pressure is the kind of thing that might be considered a legitimate security threat, post xz.

    Yes, OP's attempt to bully a maintainer into accepting his PR is a very shitty thing to do.

    Throwing veiled personal attacks, such as insinuating a developer is incompetent or dumb, is also very bad form.

    This says more about OP than anything. I hope I never have to work with anyone like that. What a shit show of a person.

  • I don’t really see how it’s daunting enough to avoid mentioning.

    I think it's a good call not to mention them because they are irrelevant given the topic. If your code base and/or the consumers of your code base are using C-style arrays for input and/or output, it's hardly helpful to suggest changing all your interfaces to use another data type. It's outright impossible if you're dealing with extern C interfaces.

  • Why no mention of std::array?

    I think this was focused on maintaining code. Replacing C-style arrays with std::array can be a daunting task, depending on how the project is structured.

  • It might be just me, but I think key bindings should definitely not be easily configurable or even changed across release. They should.be standard, pervasive, and set in stone.

    For those who really want configurable key bindings in Firefox I think there are already a couple of extensions that do this for you.

  • This is a really important principle of making APIs that people don’t really talk about. There’s a fine balance between hardcoded literals and full-gui options menu.

    I think this principle might fly under some people's radar because it has been a solved problem for decades.

    Even Makefiles don't require changes to the file to be configured. They take environment variables as input parameters, an approach that directly and indirectly permeated into high-level build systems. One example is the pervasive use of the VERBOSE flag.

    After all these years I only had to tweak build config files by hand when I wanted them to do something that they were not designed to do. All build tools I know don't require it. The ones linked with IDEs already provide GUIs designed with this in mind.

  • Fair enough.

  • Because you’d have to stash your modifications to be able to switch branch.

    OP said nothing about stashing, only committing WIP commits to feature branches. I don't think none of your remarks apply, because if you really need stuff from the WIP commits you can also cherry-pick them or checkout specific files.

  • git switch and git restore were introduced way back in 2019. I don't think they count as new.

  • When you have 1000+ Cypress tests, for example, it takes time to run, plain and simple.

    It's one thing to claim that tests need time to run.

    It's an entirely different thing to claim that the time it takes to run tests is proportional to test coverage.

    More often than not, you have massively expensive and naive test fixtures in place that act as performance boat anchors and are massive bottlenecks. Thousands of tests run instantly if each test takes around a few milliseconds to run. For perspective, the round trip of network request that crosses the world is around a couple of hundreds of milliseconds. A thousand of sequential requests takes only a couple of minutes. If each of your tests takes that long to run, your tests are fundamentally broken.