[vintagedave]

I'm familiar with the normal MSVC/Clang/GCC/EDG C++ compilers, but not IAR's. They seem to make C++ compilers for embedded systems. Does anyone know if these are their own, or based on something like Clang?

Their supported standards list 'libc++' [1] which implies LLVM and potentially Clang. I could not find info online.

"IAR Embedded Workbench C++ is dialectal and contains some features not part of standard C++." [2] Their extensions seem to be to relax some awkward syntax, and for embedded systems support such as memory positioning (?)

Qt is huge in the embedded space, such as automotive, where I see IAR is as well. Makes sense as an acquisition. I used to work as the C++Builder product manager, which has custom C++ language extensions, and I always personally (not a statement from my prior employer in any way) wondered if Qt might someday look to that toolchain too -- it does not target embedded computing, but it has excellent expertise in custom compiler changes including extensions to address exactly the same problems (as I understand) that Moc tries to solve. In general especially with the state of the C++ committee, and Qt dealing with some custom handling, I would expect owning a compiler toolchain with a willingness to customise the language to be highly beneficial for them.

[1] https://www.iar.com/embedded-development-tools/iar-embedded-...

[2] https://en.wikipedia.org/wiki/IAR_Systems#IAR_Embedded_Workb...

[thadt]

It's been a few years since I've slung code with it, but I'm pretty sure IAR had their own compiler (along with it's own special occasional bugs). Of the IDE's I've used, it wasn't that bad. But QT Creator was better. Bringing together IAR's tech and reach with QT's expertise does make a lot of sense.

[pjmlp]

Currently the way out of moc is C++26 reflection, there is only the question if it covers all required use cases, and when it becomes widely available across the compilers used by Qt's customer base.

https://wiki.qt.io/C%2B%2B_reflection_(P2996)_and_moc

C++ Builder still has a special place on my heart, Microsoft has never managed to create something as good on their C++ stack for doing GUI applications in C+*, there is nothing visual about Visual C++, unfortunely they seem not able to deliver anything better than MFC.

C++/CLI never had the same access to the GUI tooling used by VB and C#, C++/CX got sabotaged by an internal group that rather write IDL files in Notepad and push that experience to everyone, than caring about paying customers.

Regarding IAR, maybe it is a way to solidify their offering, and counter advances from Android, Electron and Flutter being adopted on the same industries.

[bobmcnamara]

IAR has their own backend and I believe front-end as well.

They routinely smoked GCC and Clang, and sometimes ARMs tools on a variety of tasks.

I'm not sure I see the advantage on Qt owning a compiler though - one of Qt's strengths is portability.

[bluGill]

The advatage might be they can ensure the compiler supports the new features qt wants to use.

reflection could replace moc, (likely c++29 needed) but if compilers don't implement that part of reflection qt can't use it. If qt can get compilers updated that helps them.

[maleldil]

Relevant link regarding Qt moc and reflection https://wiki.qt.io/C%2B%2B_reflection_(P2996)_and_moc

[Palomides]

I'm not sure there's much overlap in use cases, considering the two very separate classes of 'embedded'; Qt is used on Linux capable devices and IAR is MCUs

why would Qt want to customize a compiler when they still need to support llvm/gcc/msvc?

[ndiddy]

There's a class of high-spec microcontrollers that have a ton of RAM and flash and built-in support for stuff like touchscreens. It looks like Qt is able to run on these: https://www.qt.io/platform/develop-software-microcontrollers... . I'm not sure how much of their business is people targeting bare-metal microcontrollers, but there is at least some overlap.

[HeyLaughingBoy]

Maybe better tooling to manage both? My $DAYJOB builds systems where we use Qt as the Linux GUI, with real-time processing outsourced to a microcontroller and the toolkit on that side is usually IAR. It's a pretty common configuration across industry, TBH.

My first thought is that they can extend Qt's test library to also manage test data across a pipe to the embedded processor.