LucaSas

Speaker here, hope you enjoy the talk.

I also gave an updated version of the talk at embo++ with some small updates and fixes to some code examples, not sure if that will be on youtube but you can see the slides here: https://docs.google.com/presentation/d/1tHdUBWSf8oVbX8Oe4V15...

This popped up on youtube today, it's a Livestream with 24k live viewers, claiming to be a Linux Foundation Livestream that gives free bitcoin to people who send them some first.

This pops up again from time to time, I think what people should take away from this is that garbage collection is not just what you see in Java and other high level languages.

There are a lot of strategies to apply garbage collection and they are often used in low level systems too like per-frame temporary arenas in games or in short lived programs that just allocate and never free.

I believe the person who started this is just a bad actor. Surely he must have known that this will only lead to more outrage and hatred. Now we need to have the whole "war on xmas" and "political correctness gone crazy" debates, just because there is one idiot out there that people decided to listen to instead of ignore.

I think the Rust standard library is actually a liability in this case, not an advantage. The rust stdlib will essentially be an extra dependency and also the rust standard library doesn't have allocators, so unless you are very careful you might violate the principle of not doing allocations for the user. Also, even if it did have allocators, passing allocators from to Rust via a C interface would probably be awkward.

So if you do choose to make the implementation in another language, there are extra considerations that you have to take into account.

Thanks for the comment, I might steal your "subset of C99 which compiles both in C and C++ mode on GCC, clang and MSVC" quote and put it in the article if that's ok ;)

Hi, the reason for using C99 is that it is fully compatible with other languages. If you write a library in Rust you might be tempted to use Rust only feature which will then make it hard to wrap the library for other languages. And if you don't use those features from Rust in your library people will comment that your library isn't Rust enough. Same thing applies to C++. To that extent my advice is to write C in C rather than C in Rust or C++.

Also if people don't have a Rust toolchain setup, compiling the library and using it from source would be hard. In some cases integrating Rust in their toolchain could be hard.

Regarding metal and vulkan I will edit the article to mention Vulkan there too alongside metal. Thanks for your feedback.

Thanks a lot for your feedback. I decided to remove that since I think you are right about indicating personal preference. I do not want this article to be a list of preferences but rather an analysis of the considerations that popular C libraries make (eg: stb, sokol, etc) and that new authors should also reason about.

Hi, I mention in the article that "It is easier in general for a C++ user to use a C library than it is for a C user to use a C++ library." which is where the advice comes from.

As a good resource for learning C I would recommend Casey Muratori's tutorials: https://www.youtube.com/watch?v=F3ntGDm6hOs&list=PLEMXAbCVnm...

If you are interested in learning more about writing complex software in C consider checking out HandmadeHero.

Sadly there need to be more good resources on learning how to write good C and low level software. I am hoping my article can be a starting point for people who wish to learn about library design for example.

Hi, thanks for your feedback. I am the original author.

Regarding prefixes, I advice that you start by writing the library in C and then wrap it in C++ for a variety of reasons that you might want to consider. In C++ you should indeed always use namespace.

Header guards have the advantage over pragma once that they are standard and you can also use them to check if a library is included. I might remove that since maybe it's not that important and people might different views.

Regarding constants, I was referring to things such as numeric constants for which you would constexpr in C++. Maybe I can be more explicit there. Thanks for the feedback.

Hi, I am the author of the article. Regarding RAII, what I mention in the article is that it is ok to provide RAII wrappers as long as you also provide C++ wrappers for the non-RAII plain structs and functions from C. I think this is the best way to satisfy everyone.

When it comes to exceptions and rtti the sad reality is that about 50% of the C++ community doesn't use (for one reason or another), so if you do use them in a library it can have an impact.