Qt Group Buys IAR Systems Group | Hacker News Reader

Qt Group Buys IAR Systems Group

qt.io

71 pointsshrimp-chimp50 comments

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.

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.

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.

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

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.

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.

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.

True. Always use -Os. Knows nothing about internal crc functionality. Many things need manual assembly.

I've tried sdcc, but this was atrocious in array access for 8bit Atmel. Only solved with asm

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.

No, that's a company firmware we bought with sourcecode to be able to extend it.

I'm pretty sure it's the stdlib, IO probably, which is only needed for debugging anyway.

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.

Most of the time you don't need to do that as qt will work with smart pointers so long as you have create and destroy in the same order. But i agree is annoying. I brought this up with qt last time they visited (my company is one of their larger customers)

I've only used Qt from Python, but I found that a major downside. Qt wants you to program inside Qt and not within your host language. Take, for example, their approach to Python's asyncio. Instead of integrating with Python's default asyncio, they're writing their own version of it.

I tried Qt from Python a few times and definitely concur. It always felt like a major paradigm mismatch.

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.

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.

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.

IAR C was my first embedded compiler, a long time ago, and it just worked flawlessly.

Probably cheaper than buying several IAR licenses…

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?

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?

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!

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.

Replying to this post because the thread's getting too deep.

What was painful about switching to web tech for UI? I've proposed it at work a few times for exactly the same reasons: get away from Qt and ease of finding developers. Since our GUIs all run on Linux (we usually do the realtime stuff on an external ARM processor) it seemed like an easy transition, but I've been shot down every time.

Would be nice to hear what the downsides are.

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”.

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.

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.

> 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

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/ )

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.

Some people don't like to pay for the work of others, while expecting to be paid for their own work.

Qt licensing is rather easy to understand.

Don't want to pay Qt? Then get the same money yourself, zero.

Want to get paid while selling a product based on Qt? Give something to Qt.

Reply on news.ycombinator.com