11–20 of 129 posts
Since this article lays so much emphasis on C, I have an honest question to everyone. What is a good way for a beginner to learn C in the current time? The minefield of undefined behavior is really overwhelming to a beginner. Are there any good resources that teach C the right way with good advice and best practices to navigate the UB minefield?
This is bad advice on the c++ part. If you don't use RAII, then you could've just not done the c++ lib (and have just a c lib). Exceptions, raii and smart pointers are what makes modern c++ so pleasant, next to templates.
Since this article lays so much emphasis on C, I have an honest question to everyone. What is a good way for a beginner to learn C in the current time? The minefield of undefined behavior is really overwhelming to a beginner. Are there any good resources that teach C the right way with good advice and best practices to navigate the UB minefield?
Writing Secure Code
https://www.amazon.com/Writing-Secure-Second-Developer-Pract...
Secure Programming Cookbook for C and C++
http://shop.oreilly.com/product/9780596003944.do
SEI CERT C Coding Standard
I don't see it mentioned, but it's important to note that you don't have to write your library in the same language that you expose to your users. You can write everything in C++/Rust/Python and expose something compatible with the C ABI and people will be able to use it (provided they have your toolchain…)
Anyone providing a library written in pure C, better be serious about security and prove that they have taken all the required steps to handle memory corruption and UB exploits.
We really need more liability on software development.
> Always prefix your names to avoid name collisions
Solved by C++ namespaces.
> Use header guards instead of #pragma once.
#pragma once is supported by all mayor compilers, header guards can introduce bugs, also #pragma once builds measurably faster: https://github.com/electronicarts/EASTL/blob/3.15.00/include...
> Expose constants to the user using constexpr variables.
Modern C++ has strongly-typed scoped enums for such constants.
Some of these recommendations are awesome, others aren’t good, IMO. > Always prefix your names to avoid name collisions Solved by C++ namespaces. > Use header guards instead of #pragma once. #pragma once is supported by all mayor compilers, header guards can introduce bugs, also #pragma once builds measurably faster: https://github.com/electronicarts/EASTL/blob/3.15.00/include... > Expose constants to the user using…
Some of these recommendations are awesome, others aren’t good, IMO. > Always prefix your names to avoid name collisions Solved by C++ namespaces. > Use header guards instead of #pragma once. #pragma once is supported by all mayor compilers, header guards can introduce bugs, also #pragma once builds measurably faster: https://github.com/electronicarts/EASTL/blob/3.15.00/include... > Expose constants to the user using…
C++ defines don’t respect namespaces so you are pretty much screwed in anycase.
I don't see it mentioned, but it's important to note that you don't have to write your library in the same language that you expose to your users. You can write everything in C++/Rust/Python and expose something compatible with the C ABI and people will be able to use it (provided they have your toolchain…)
Functions and opaque handles are often way simpler for the user.