71–80 of 129 posts
And then the author provides example where there’s Dear IMGUI which is c++.
For usage from C code, there's cimgui, which is an automatically generated C-API wrapper:
Earlier quoted context omitted.
Other than UNIX like kernels and tiny PIC micro-controllers no one else should still be programming in straight C in 21st century.
I agree that "straight C" is not the best choice anymore... but C++ isn't great either. It inherits most of C's weaknesses and for libraries, it makes it very difficult to use the code from languages other than C++. By making a library in C++ you are basically limiting it to being used only in C++ projects. (Yes, wrapper generators for C++-to-whatever exist, but my experience with using e.g. Qt from other languages h…
However given that at least C++ does support ways to tame C, after all the whole purpose was for Bjarne never to repeat his Simula into BCPL rewrite experience ever again, it is up for security conscious to decide what legacy they want to leave, when the option is between both those languages.
On the other hand maybe C should be used to write Skynet, so that we stand a chance.
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.
FWIW I’ve never been at a job that allows exceptions...but smart pointers and RAII are great.
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…
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 may…
It’s very hard to write correct C code which does IO and supports multithreading. Take a look at Microsoft’s implementation of fprintf, copy-pasted from Windows 10 SDK: https://gist.github.com/Const-me/f1bb320969adde6c79694265ea6... They use RAII to set & revert the locale, and to lock RAM buffer to avoid corruption by another threads. They use C++ lambda for exception handling. They even use C++ template to avoid code duplication between printf and wprintf.
But these C++ shenanigans are not exposed to user, user calls their `printf` (possibly in a code built by C compiler) and it just works.
Make is a much the lingua franca of build systems as C is for programming, so there's no reason not to provide a (simple) makefile. The alternative they suggest is worse anyway.
Windows is the reason make is not a good choice. Visual Studio is a de-facto standard for Windows development and it's not exactly makefile-oriented. The lowest common denominator for build instructions that works everywhere is literally "set your include paths like so and compile these sources".
GameObject_Init(GameObject &obj) GameObject_Destroy(GameObject &obj) GameObject_Update(GameObject &obj)
Is just C++ with extra steps
Earlier quoted context omitted.
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 may…
I advise you start by writing the library in C++ and then wrap it in C if you need C ABI of the library. It’s very hard to write correct C code which does IO and supports multithreading. Take a look at Microsoft’s implementation of fprintf, copy-pasted from Windows 10 SDK: https://gist.github.com/Const-me/f1bb320969adde6c79694265ea6... They use RAII to set & revert the locale, and to lock RAM buffer to avoid corrupti…
This is just a random unsubstantiated statement. There's nothing particularly "hard" about writing IO libraries that is language-specific. Multithreaded or not.
It always baffles me when a library comes with its own arcane build code. Instructions like "Requires Python" invariably turn out to actually mean "Requires hours of debugging".
IMO the ideal way to get your library used is to generate a single .h and .c file.
Earlier quoted context omitted.
C++ features don’t help when you’re programming in straight C, as the article advises.
Other than UNIX like kernels and tiny PIC micro-controllers no one else should still be programming in straight C in 21st century.
C is a perfectly fine language for tasks of all kinds. The fact that it expects programmers to take greater care when using it is not a reason enough to dismiss it as a general-purpose language. Not everyone needs (or wants) to ride a tricycle wearing knee pads and a helmet to get from A to B.
> Not everyone wants to use C++ (some prefer C). This could be very well flipped over. If I have the source available, I'd much rather deal with C++ bindings.
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.