>>> But you created an object in C++; exposed it to worthless QML; being >>> worthless QML handed it off to JavaScript. Now three different garbage >>> collection systems believe they "own" it. On a gasping for its last breath >>> undersized processor to extend battery life, everything is fine because >>> garbage collection never runs. Move your code to a really good processor >>> and suddenly things crash all over. The object got deleted yet QML and >>> JavaScript each think they own it. When they try to reference (or double >>> delete) it fails.
You don't need to make your object all be declare into Qml, only the Gui should be in Qml in a normal design, keep your controler, models and everything else into C++. You also can check and change the ownership of each object from C++ or to Javascript if you want to swing them. Nothing too difficult there. The Qml object follow the parent just like any other QObject. QQmlEngine interpret the declarative code (and soon will compile it to C++ into Qt6), what wrong with it? If you have double delete, you have bad design or you have mutliple owner of an object (just like you can do with C++ and the unique_ptr, shared_ptr). Qml only simplify the writing of connection between the GUI and the core of the application (business logic, true code). Normally if your application is well design, you can strip the Qml layer and make a command line interface without change to your core code or you can swap the Qml layer with QWidgets one (and take a close look at how much more code you will need to achieve the same results and reactivity). The extra mile to expose the C++ object to meta is not great but also offer other options, Qt meta allow a lot of reflection to C++. One day we can get ride of it when the C++ refelection make it to the standard (there something on the near horizon fromwhat I saw), but I would not put too much effort on it until they do, no need to rewrite 3x the meta/moc. As for RAM usage I agree, device have become very hungry, but on the other hand you can make something consume a lot of ram and still run quickly, nobody want to pay top dollars to optimize the assembly anymore, the RAM price is so cheap compre to developr time price, the resulting business will easily go screw optimization and just crank up the specs of the hardware (this is often cheaper and make more sense business wise). -----Original Message----- From: Interest <interest-boun...@qt-project.org> On Behalf Of Roland Hughes Sent: June 18, 2020 1:27 PM To: Matthew Woehlke <mwoehlke.fl...@gmail.com>; interest@qt-project.org Subject: Re: [Interest] [Development] Windows 7 support will be, dropped in Qt 6 On 6/18/20 11:17 AM, Matthew Woehlke wrote: > On 18/06/2020 11.11, Roland Hughes wrote: >> Could someone from such a background learn enough C syntax to write a >> student C program like this one? >> [example program elided] > > Maybe. To the point various others are making, just because someone > hasn't learned the fundamentals doesn't mean they're incompetent. > > OTOH, not everyone can learn competence. The point is, *you just don't > know*. The point is we are the sum of our training and experience. Without the formal training there is an incredibly high probability one will end up in an AGILE shop instead of a Software Engineering shop. In an AGILE shop, their "experience" won't be good stuff promoting professional growth. As to "various others making" I get this via digest unless someone direct includes me. I will see the "various others making" at some point over the next few days when I have time to look at the digest. Trying to add Debian build support to Gede right now. Not a difficult thing, just needs focus. > >> Could that same person write a page swapping system for a Linux-like >> OS from scratch? No. > > Again, *maybe*. Not, perhaps, without learning the fundamentals first, > but as noted, just because they haven't learned *yet* doesn't mean > they can't. But, again, there are plenty of people that can muddle > through basic stuff with "training wheels" languages that *can't* > grasp the fundamentals well enough for such tasks, and that's the > point you (Roland) and I are making. I guess I should have added "in under a year." There is a time thing on the front end too, I just don't want to put any thought into what it is right now. The longer you spend in an AGILE shop where nobody was professionally trained, the more bad practices and habits you pick up. There comes a tipping point where you physically can't go back and learn the fundamentals because they are contrary to what you do each and every day. > > To be fair, I might be in the latter category. I don't recall > *formally* learning much about memory management (although there was > some generic algorithms stuff); nevertheless, my first professional > job was pure C and I managed well enough. I'd like to think I'm > competent, if not amazing. You are probably way better than I. The point is when you take someone from a training wheels environment where all memory manage is handled for them and drop them into C or any other language where formal training really is required; they don't have memory "leaks" in their programs they have memory rivers. Most will attempt the Microsoft solution; "Throw hardware at it!" Suddenly the Television remote control they are working on needs 24Gig of RAM so it can go a month between reboots. > > As an example, I don't consider deleteLater a major source of > headaches (and most of my stuff *does* run on reasonably modern > machines). Almost always if I use deleteLater, it's because I *know* > that I can't just delete it *now*. I'm aware of needing to ensure that > objects are either a) not deleted while in use, or b) are always > referenced through *checked* weak pointers. > But you created an object in C++; exposed it to worthless QML; being worthless QML handed it off to JavaScript. Now three different garbage collection systems believe they "own" it. On a gasping for its last breath undersized processor to extend battery life, everything is fine because garbage collection never runs. Move your code to a really good processor and suddenly things crash all over. The object got deleted yet QML and JavaScript each think they own it. When they try to reference (or double delete) it fails. One cannot safely add virtual machines (plural) to a compiled language if one or more tools used in the compiled language provide some level/type of garbage collection. We are all just waiting on KDE to pull the trigger and tell us what library(ies) will be used in the post-Qt world. The current licensing and royalty situation make Qt unusable going forward. -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
