As you know, C and C++ are sister languages that have a lot in common, but that drifted quite apart over the years. In general, neither code of one language can be compiled as the other language, there are too many mayor and minor twists that make this impossible. Not only are there syntax differences between the two, some common syntax can actually have diverging semantics. So generally, it makes no sense to compile C code with a C++ compiler, and you should look with suspicion at any code or programmer that claims to do so.
Where C and C++ usually agree, though, is on the ABI, the application binary interface, so data structures and functions of one language can be used by the other to some extent. C and C++ also kept a sufficiently wide intersection in there respective specification of interfaces, such that one header file can be used from both.
In this post I try collect those parts that are in that intersection, and I propose some coding style that should accommodate both worlds suitably well. But as my personal history goes, this will merely be a POV of a C programmer that wants to provide interfaces for C++.
Continue reading “cross-language interfaces between C and C++”
When compiling position independent code, PIC, the gcc compiler fails to inline many functions that have an external name, that is that are not declared
static. While this is conforming to the C standard, this is a complete blow to a lot of optimization efforts that I have put into my code in many places.
Continue reading “gcc doesn’t inline position independent code properly”
C11 has added a certain level of Unicode support to C, but I think for C2x it will be time to go a step further and put C in line with general usage of special characters as they are normalized by Unicode. In particular, it is time to get rid of restrictions in operator naming that stem from the limited availability of special characters 30 years ago, when all of this was invented.
Continue reading “Unicode operators for C”
Some time ago I had advertised for one of my new toys, Modular C, an extension of the C language aiming for modularity, and, more generally for an easier use. Since then it has gained some new features and I have rounded up some edges, so you all should definitively have another look 🙂
Among the new features are
- complete Unicode support (identifiers, operators)
- finite code unrolling (
- programmable expression contexts (e.g for modulo arithmetic or string operations)
Also, there is now some concise documentation, at
You find the latest version of my book at the usual place at
This now contains all the material that I plan to put into it. New are “experience” parts about performance, function-like macros and
_Generic, control flow, threads and atomics. There is in particular a section about memory consistency, probably the most difficult write-up for this book.
These higher level parts have not yet have had the reading they hopefully deserve, so please give it a try. As before, constructive feedback is highly welcome. Thanks to everybody who already did send me comments and corrections!
Constructive comments to this blog are welcome.
This is not the right place for
- feedback about details (missing commas, spelling errors). If you have such details, please collect them and send them to me directly.
- rants against the C standard. This is not the place to let off steam nor to compare to whatever other programming language you prefer. If you have criticism about the C standard, please contribute. The C standards committee is a nice batch of people, don’t be afraid. And if you have concrete proposals, also it would be much better to contact me (or any other member of the committee) directly and see how you may invest yourself in the ISO process.
Also, comments that come from real people are highly preferred.
With this post I will start to discuss a series of modifications of the C standard that I have (or will) propose for C2x. As a starting point there is the observation that the passage from one C standard to the next was not easy in the past. This, neither for implementers of C compilers nor for users, because it was not easy to capture partial improvements. Basically for gcc, e.g., you had to add
-std=c11 or similar, and then test for the version number to see if a particular feature is implemented. This task then was even more complicated because some of the new features are language, and some are library.
This was tedious and error prone, and I think we should avoid such difficulties in the future.
Continue reading “Ease the transition between C standards”
I already have posted about the evilness of cast some time ago, but recently I have seen that there is still much confusion out there about the C rules that pointer casts, also called type punning, break. So I will try to give it a more systematic approach, here.
In fact, I think we should distinguish two different sets of rules, the effective type rules that are explicitly written up in the C standard (6.5 p6 and p7), and the strict aliasing rules that are consequence of these, but that concern only a very special use case of type punning. They represent only one of the multiple ways a violation of the effective type rules can damage the program state.
Continue reading “Effective types and aliasing”