u/mathlontrades

I’m working on a small portable C library where only about five functions need to be implemented differently depending on the platform or the user’s needs. Three of them need to be overridden, while the other two could have weak default implementations.

At the moment I’m defining them as weak symbols and letting the application provide strong implementations. For such a small number of hooks, this seems convenient and keeps the API simple. I can see now that it’s not very obvious to the user that some of these functions are expected to be overridden.

Is using weak symbols like this a reasonable approach for a portable C library, or would something like a struct containing function pointers be more idiomatic? What is recommended?

Just wondering since the team I work with on embedded systems at university don't really plan the architecture / tasks etc, they plan more what it must be able to do rather then how. There are like the pre and post conditions as in GPIO/peripheral configs from the electronical team and requirements from the contractor, but other than that I feel like we all just miscommunicate and code from what our idea of the project is individually which I think is not optimal. I feel like currently we use the code we write as documentation of the architecture. Not the other way around, so just wondering how you all take on this problem I have.

[supprimé]