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.
Methinks you were targeting some wierd-ish ISA that had near/far addressing and a larger memory space than the but core could address directly. Those have all sorts of quirks needed to make code work properly, quirks GCC probably never bothered to implement or optimize for. It's also probably why it never worked. Oh... you have a pointer? That's nice, but this is a near pointer and the data is outside of how much it can express.
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.
Depends on what volume means. I would argue most people aren't working on projects in the million of units volume where that cost savings isn't worth it.
Lots of people are. It's usually small systems. Think PIC or RL78, 16 bit MCU's maybe some Cortex M. But they're everywhere and sold in the millions and you never even think about it unless something goes wrong and then you cuss at them.
Honestly I'd be willing to blame GCC for that one. IME its output is atrocious for embedded stuff. Few optimizations for the chips I use and absolute nonsense assembly trying to emulate CPU instructions GCC doesn't know exist in hardware. Binaries are regularly 3x larger than they should be. It's so awful I had to end up writing my tight loops in straight assembly because GCC couldn't handle incrementing a damn pointer in a sane way.
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?
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.
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)
It kind of drives me crazy trying to have a modern C++ codebase which uses smart pointers everywhere, yet every touch point with Qt involves manually allocating memory and passing the pointers into some magical Qt blackbox which hopefully frees the memory when appropriate.
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.
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.
A big one that I've heard, is that they are funny about you developing with it under an open source license and then buying a commercial license. I.e. if you would potentially want to use something that's under the commercial license then you need to buy it when you start development instead of when you find you want the commercial side. I don't know if this is still the case, though.
> 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.
I work on equipment that can't open itself under LGPL3 rules. So I had to stop Qt use at 5.15, which went under maintenance support over 3 years ago.
I've switched to vanilla web technologies. Node, React, etc. It's painful and it sucks but hardware keeps getting faster and cheaper. I can find contractors easily and I don't need an increasingly expensive subscription^H^H^H^Hcontract with Qt to keep my developer seat hot. They tried multiple times to get me to abaondon my Qt5 license to switch to their new revenue model. I told them to fuck off.
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.
Methinks you were targeting some wierd-ish ISA that had near/far addressing and a larger memory space than the but core could address directly. Those have all sorts of quirks needed to make code work properly, quirks GCC probably never bothered to implement or optimize for. It's also probably why it never worked. Oh... you have a pointer? That's nice, but this is a near pointer and the data is outside of how much it can express.
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.
Depends on what volume means. I would argue most people aren't working on projects in the million of units volume where that cost savings isn't worth it.
Lots of people are. It's usually small systems. Think PIC or RL78, 16 bit MCU's maybe some Cortex M. But they're everywhere and sold in the millions and you never even think about it unless something goes wrong and then you cuss at them.
Honestly I'd be willing to blame GCC for that one. IME its output is atrocious for embedded stuff. Few optimizations for the chips I use and absolute nonsense assembly trying to emulate CPU instructions GCC doesn't know exist in hardware. Binaries are regularly 3x larger than they should be. It's so awful I had to end up writing my tight loops in straight assembly because GCC couldn't handle incrementing a damn pointer in a sane way.
I haven't found that it's that bad but I have seen that IAR is a bit better at optimising for code side, to the tune of ~10-20% or so.
Their compiler(s) are... fine, I guess. Maybe it makes fast code (didn't do a whole lot of profiling), but compiling with it is slow as hell.
Their IDE is horrendous.
Used to work at a big IAR shop. Compiler is whatever, it works. Hated supporting that IDE. We supported way too many versions.
There's a VSCode IAR plugin that makes life a bit less painful.
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?
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.
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)
It kind of drives me crazy trying to have a modern C++ codebase which uses smart pointers everywhere, yet every touch point with Qt involves manually allocating memory and passing the pointers into some magical Qt blackbox which hopefully frees the memory when appropriate.
Somewhat related but not quite:
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.
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.
A big one that I've heard, is that they are funny about you developing with it under an open source license and then buying a commercial license. I.e. if you would potentially want to use something that's under the commercial license then you need to buy it when you start development instead of when you find you want the commercial side. I don't know if this is still the case, though.
> 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?
I work on equipment that can't open itself under LGPL3 rules. So I had to stop Qt use at 5.15, which went under maintenance support over 3 years ago.
I've switched to vanilla web technologies. Node, React, etc. It's painful and it sucks but hardware keeps getting faster and cheaper. I can find contractors easily and I don't need an increasingly expensive subscription^H^H^H^Hcontract with Qt to keep my developer seat hot. They tried multiple times to get me to abaondon my Qt5 license to switch to their new revenue model. I told them to fuck off.
Not OP, but some users migrated from Qt to Slint and are happy with it. [https://slint.dev] (I'm one of the Slint developers.)
I'm rooting for you guys. Keep going!
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.
Because it’s unclear and incomplete. Always prone to some KDE whims.
KDE is an independent project from Qt and the only say they have is they have the right to release Qt under a BSD license if Qt Group removes the GPL option ( https://kde.org/community/whatiskde/kdefreeqtfoundation/ )
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”.