Am Samstag, dem 09.05.2026 um 11:08 +0200 schrieb Arsen Arsenović: > Martin Uecker <[email protected]> writes: > > > What I find unlucky, for example, is that we do have a generic > > tree data structure with a lot of imlicit assumptions and lot > > of issues if those are violated. So encapsulating this properly > > in abstract data types would be really helpful. But we could do > > this also in C, while the switch to C++ apparently did nothing > > to address this. > > Indeed, adding '-x c++' doesn't automatically fix existing code. > > However, C++ enables other things to be done here. For instance, at > one of the Office Hours, a mechanism for encoding tree types (without > requiring rewriting massive amounts of code) was proposed. It relied on > templates, and it compiles down to the same code as today, and can > provide a bridge for existing code. Essentially, it allowed us to > specify types such as 'ttree<one_of<PLUS_EXPR, MINUS_EXPR>>' or such, > and could automatically insert (and elide) gcc_asserts that check for > those tree codes. > > I don't recall who proposed it or if it ever was sent, but a similar > thing wouldn't be possible in C.
It isn't clear to me what that removing gcc_asserts by a complicated type (that then may be hidden behind "auto" because typing it out is to cumbersome) is necessarily an improvement. The issue with C++ is that people get overly excited about the impressive capabilities of the language (and don't get me wrong, there was a time in my life where I was too!), and in toy examples this always looks cool, but then if you look at actual code in a larger project it is often much harder to understand. What we would need in my opinion would be simply struct expression; struct type; struct statement; etc. wrappers aroung tree nodes and a set of helpers function to operate on such data types without breaking their invariants, nothing more and nothing less. In C FE it looks somebody was starting to introduce such wrappers, but apparently never made a lot of progress. But anyhow, we do not need to discuss this further. I only wanted to point out that for libubsan some people would be more happy with a lean C version, and raise the question whether this is relevant for libgomp or not. Martin > > It looked like something I sketched at one point, but I never finished > the implementation, unfortunately, so there's nothing for me to share. > Apologies.
