[Development] Could support for C be added to Qt?

[Karl Semich]

On Sat, Sep 10, 2022 at 2:14 PM samuel ammonius <sfammonius at gmail.com> wrote:
>
> > First, your own example of not having compile-time checking of the means that
> > those programmers are accepting less security for the sake of staying in the
> > same language.
>
> How? It's just the equivalent of static_cast(), and I'm talking about types with
> the same sizes. If the types were of different sizes, the cast would cause a
> warning.

This is something where C and C++ developers learn very different
philosophies that they have each put a lot of effort into. In C++,
casting between pointer types is considered quite dangerous if the
compiler doesn't check for human error. This is a basic concept
learned early on and adhered to in standard C++ codebases. I have not
experienced the warning you describe.

My impression of C is that there may be much stronger value around
encouraging devs to develop understanding and skills that prevent
problems, rather than relying on compiler checks, which may be seen as
only protecting against surface issues.

Regardless, note that each warning category can be disabled build-wide
with compiler flags. Many other C/C++ differences have a compiler flag
too, I suspect.

> > Second and most importantly, they don't need to switch the entire code base.
> > They need only to add some C++ source files to their software so they can use
> > Qt from there. Their existing logic can remain in C as much as they'd like. It

C developers who don't like C++ as much as C++ developers don't like C
will be more conducive to welcoming Qt into their projects if C
headers are already available. They may be resistant to adding C++
code, with its slow compile speed and incompatibilities with archaic
platforms they may still support, just as a C++  project may be
resistant to turning all their templates into macros.