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.
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.
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.
I have a C++ seasoned colleague who says that It framework went behind the current C++ standard, however I remember Qt Framework much cleaner than C++ itself (by making a sort of a enhanced subset), and would prefer use it. What are your opinions?
I once tried to get a IAR C++ embedded codebase to compile with g++ and it's stdlib on a very small chip. It eventually compiled but never worked. I'll have to rewrite it in C instead.
There were many hacks, like filling the stack with sentinels to detect it at run-time. The linker script was horrible. Rewrote everything from scratch.
The resulting code was many KB too large for the available space, it would have needed to slim down the stdlib. Even with the much better optimizations and LTO it was still too big.
Nice for that time, but essentially unusable. The company needed 10 years for that code, my plan is to rewrite it in 2 weeks.
Why is Qt support so poor on mobile (and especially PyQT)? They're basically just 2 OSes at this point, they've been around for 15+ years. They do change, but they're also quite backwards compatible.
I would imagine that Qt would want to target such a huge market.
Makes business sense. The two companies have similar customer profiles in the embedded space, so this should make for cross selling opportunities both ways. Just being a pre-approved vendor is often a big win, as many times that involves long and costly processes.
10 comments
[ 2.7 ms ] story [ 28.8 ms ] threadTheir 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...
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.
There were many hacks, like filling the stack with sentinels to detect it at run-time. The linker script was horrible. Rewrote everything from scratch. The resulting code was many KB too large for the available space, it would have needed to slim down the stdlib. Even with the much better optimizations and LTO it was still too big.
Nice for that time, but essentially unusable. The company needed 10 years for that code, my plan is to rewrite it in 2 weeks.
Their IDE is horrendous.
Why is Qt support so poor on mobile (and especially PyQT)? They're basically just 2 OSes at this point, they've been around for 15+ years. They do change, but they're also quite backwards compatible.
I would imagine that Qt would want to target such a huge market.