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.
If IAR was able to make the existing C++ codebase fit in the chip's flash and GCC wasn't, that seems like a win for IAR. If you're selling products in volume, the cost of the IAR license is dwarfed by the amount of money you save by using a part with less flash.
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.
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.
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.
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?
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.
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?
Take this with a grain of salt because it's been about 10 years since I slung serious C++. Just my opinion of course, but if you go all-in with the Qt libraries, it's a lot better (and safer). Most people only think about Qt as a GUI framework, but it's much, much more than that. It's a very rich set of libraries that do way more than just UI. We actually used Qt for our server too!
So I agree with you, Qt tends to be a lot cleaner than standard C++ (or even C++ with Boost). I highly value consistency in a codebase, and Qt really makes that possible.
Modern c++ does some things better than qt, others it is still worse. Just unique ptr is better than qt's parent-child object model (memory management only, parent child is useful for other things)
Everytime a QT post comes someone bitch about the licensing model. And every time I google and try understand what is wrong with the licensing model. And everytime I end up confused about it.
Could you kindly ELI5 me what is wrong with QT licensing model?
Qt (the company) releases MOST of their code under open source licenses, but not all. Qt4 was LGPLv2.1, Qt5 and beyond are under LGPLv3.
In every major Qt release, there's a handful of super useful but kind of niche widgets which aren't released under open source licenses, presumably as a sales tactic as buying licenses gets you these widgets and sometimes that is cheaper than building them yourself, but unless you need these, you probably don't care about this.
Although my experience attempting to buy licenses from Qt is about a decade out of date now, the way it roughly worked was you paid a per-seat-per-year fee to get a developer license or build-machine license. Then you bought bundles of deployment licenses, and the bigger the bundle then the lower the cost per license. If you are buying a bundle of a few thousand devices then you pay more per license than if you're buying a bundle of a few million. Either way, it is a significant chunk of cash you have to front to get your block of licenses and normally embedded projects are EXTREMELY sensitive to per-unit costs.
> And every time I google and try understand what is wrong with the licensing model. And everytime I end up confused about it. Could you kindly ELI5 me what is wrong with QT licensing model?
This right here! We customers and users alike are often confused by QTs piecemeal licensing model.
Nothing's wrong with their licensing model, but they've been known for misrepresenting their licensing model in order to steer people towards their commercial offerings.
If you get confused by it then that's all that needs to be said. The rest has been discussed over and over. I've dropped Qt for other front-end tech and I'm happier now.
From my perspective they spread FUD about open source licensing. QT core is LGPL3. Many applications would be fine with using LGPL3 in commercial applications. Read QT's landing page on licensing, and fossa has a good block post on requirements.
Over the years it has been noted by many that Qt’s wording and warnings about the LGPL amount to spreading FUD or outright misinformation in what seems like an attempt to scare managers and C-suite folks into buying commercial licenses “just in case”.
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.
If IAR was able to make the existing C++ codebase fit in the chip's flash and GCC wasn't, that seems like a win for IAR. If you're selling products in volume, the cost of the IAR license is dwarfed by the amount of money you save by using a part with less flash.
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...
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.
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.
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.
Relevant link regarding Qt moc and reflection https://wiki.qt.io/C%2B%2B_reflection_(P2996)_and_moc
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?
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.
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?
Take this with a grain of salt because it's been about 10 years since I slung serious C++. Just my opinion of course, but if you go all-in with the Qt libraries, it's a lot better (and safer). Most people only think about Qt as a GUI framework, but it's much, much more than that. It's a very rich set of libraries that do way more than just UI. We actually used Qt for our server too!
So I agree with you, Qt tends to be a lot cleaner than standard C++ (or even C++ with Boost). I highly value consistency in a codebase, and Qt really makes that possible.
Modern c++ does some things better than qt, others it is still worse. Just unique ptr is better than qt's parent-child object model (memory management only, parent child is useful for other things)
Two companies with horrendous licensing methods and prices. They'll do great together.
Everytime a QT post comes someone bitch about the licensing model. And every time I google and try understand what is wrong with the licensing model. And everytime I end up confused about it.
Could you kindly ELI5 me what is wrong with QT licensing model?
Qt (the company) releases MOST of their code under open source licenses, but not all. Qt4 was LGPLv2.1, Qt5 and beyond are under LGPLv3.
In every major Qt release, there's a handful of super useful but kind of niche widgets which aren't released under open source licenses, presumably as a sales tactic as buying licenses gets you these widgets and sometimes that is cheaper than building them yourself, but unless you need these, you probably don't care about this.
Although my experience attempting to buy licenses from Qt is about a decade out of date now, the way it roughly worked was you paid a per-seat-per-year fee to get a developer license or build-machine license. Then you bought bundles of deployment licenses, and the bigger the bundle then the lower the cost per license. If you are buying a bundle of a few thousand devices then you pay more per license than if you're buying a bundle of a few million. Either way, it is a significant chunk of cash you have to front to get your block of licenses and normally embedded projects are EXTREMELY sensitive to per-unit costs.
> And every time I google and try understand what is wrong with the licensing model. And everytime I end up confused about it. Could you kindly ELI5 me what is wrong with QT licensing model?
This right here! We customers and users alike are often confused by QTs piecemeal licensing model.
I could be misunderstanding, but my read of the GP is that they aren't confused about the licensing model, they're confused by the hate for it
Nothing's wrong with their licensing model, but they've been known for misrepresenting their licensing model in order to steer people towards their commercial offerings.
If you get confused by it then that's all that needs to be said. The rest has been discussed over and over. I've dropped Qt for other front-end tech and I'm happier now.
I'm curious what you settled on and why. Care to elaborate?
Because it’s unclear and incomplete. Always prone to some KDE whims.
From my perspective they spread FUD about open source licensing. QT core is LGPL3. Many applications would be fine with using LGPL3 in commercial applications. Read QT's landing page on licensing, and fossa has a good block post on requirements.
https://www.qt.io/qt-licensing
https://fossa.com/blog/open-source-software-licenses-101-lgp...
>And everytime I end up confused about it.
I think this is the point. If you're making a real application you may pay for the licensing to avoid the uncertainty/risk.
It’s LGPL mostly, with some non-core libraries that are GPL or use other licenses:
https://doc.qt.io/qt-6/licensing.html
Over the years it has been noted by many that Qt’s wording and warnings about the LGPL amount to spreading FUD or outright misinformation in what seems like an attempt to scare managers and C-suite folks into buying commercial licenses “just in case”.