back
user profile
uecker
2,145karma·1,822submissions·April 14, 2020
about
Computational Magnetic Resonance Imaging, Real-time Magnetic Resonance Imaging, GCC Contributor, BART Toolbox, Member of ISO C WG14
recent activity (1,822 total)
comment
The other point: For interoperability with other languages you often need to construct function calls at run-time. For this one needs to be able to describe types. Adding this by external libraries is…
comment
There is no other languages with the same advantages as C and a good type system.
comment
Me too.
comment
I switched back to C from C++. The reasons were that C removes a lot of unnecessary complexity which helps concentrating at the problem at hand. It also removes a lot of features that when used incorr…
comment
Having switched from C++ to C, I think C is a lot less weird than C++. But I also observed that C++ programmers usually do not "get" C (but think they do, because "it is just a subset&q…
comment
No.
comment
I don't think this is a deficiency, but an inherent property of powerful type systems. If you make them very expressive, then you can not have full type checking at compile time. On the other han…
comment
Note that a type system with polymorphic and dependent type system is far more powerful than generics or simple templates. In my opinion monomorphization is rather bad, because it creates a lot of com…
comment
What is wrong with multi-dimensional arrays in C? It works far better than in C++: void foo(int X, int Y)
{
double a[X][Y];
..
} In fact, this is one reason I switched away from C++, because arrays …
comment
1. Type safety for generic interfaces such as qsort.
2. Language interoperability. Then you need to have a dynamic framework for constructing types and function calls.
comment
The attack is the idea that everybody needs to have the same priorities that Rust has and so everybody else is wrong. With regard to memory safety, this even something I could partially agree with, bu…
comment
One problem is that the important compilers are today mostly controlled by C++ people, and smaller C compilers and C users are underrepresented. Every change in C that is different to what C++ has al…
comment
I agree. Nested functions are very useful often lead to substantially better code. With GCC 14 you can also create heap trampolines, so an executable stack is not required anymore when you take the ad…
comment
The cost of pumping a C++ version is also much higher. For C, you lose support for older compilers and minor platforms that haven't catched up, but if this isn't a problem, then only very mi…
comment
While true, compared to some of the other languages C code is still relatively close to source, e.g. it will not completely change your data types behind your back etc.
comment
In my opinion, companies should consider C for new projects. Many people know it, the tooling is excellent, there is long-term stability, compile times are fast. With other languages you run into c…
comment
While I agree that there is some value in putting an existing extension into the standard as is, not doing so would not mean that everybody has to rewrite their code. Code that already uses a non-stan…
comment
I fully agree that this is the cardinal sin of C++. I think that C still offers much better encapsulation by using interfaces based on incomplete struct types. While I understand your point regarding …
comment
What is wrong with "inline"? I do not think it is feasible to maintain all language versions in parallel for eternity. What would make porting this code to a newer standard difficult in th…
comment
I now regret helping with this effort, since people use it as arguments against using VLAs in general, although in my opinion this is clearly the wrong conclusion outside of the kernel. VLAs are basic…
comment
Not my proposal, but what exactly do you dislike about it? cleanup is unlikely to be standardized exactly as implemented as it would violate the rule that standard attributes can be removed from a cor…
comment
Do you have link? BTW: I was tangentially involved in this effort...
comment
Memory bugs very often allow exploitation which is not always the case for other types bugs. Although it is of course true that other types of bugs can also be serious, memory safety violations tend t…
comment
The VLA security problems are a bit of a myth. In the kernel it may be some problem, but with stack clash protection (which one should activate anyway) there isn't really a inherent security issu…
comment
Well there is a new one: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3199.htm But calling things "stupid" is relatively useless internet noise…
comment
There are tools to make C safe and for some industry use this will work. I also agree that rewriting in Rust is often a mistake. But NSA is already advising against the use of C: https://ww…
comment
Microsoft and Google mainly use C++.
comment
This is Rust marketing but not reality. There are tools that ensure memory safety in C. Just - unfortunately - not open-source tools.
comment
Microsoft declared C dead and wanted that everybody transitions to C++. Luckily this changed a bit and MSVC now supports newer standards. Also there are now other alternatives on Windows. So I do not …
comment
I think if C does not evolve, some people with giant C codebases will find themselves in the unfortunate position that they suddenly will be shut out of a market by regulators, because the C code is c…