CopperSpice Forum

I truly enjoy this project and I really like the approach of modernizing Qt without replacing it wholesale.
I was watching you presentation two years ago regarding CopperSpice and you mentioned that you replaced moc for its reflection functions. You explained how you made it work for signal and slots and you also pointed out that it was fairly complicated for enums. Could you explain how you got it to work or point to the source code that does that function?
I was also watching the cppcon 2017 presentation called "Effective Qt". They pointed out a whole lot of reasons why they couldn't move away from the Qt containers and strings. Something about cheap copy that people rely on. They also mentioned some other issues regarding the Qt containers not behaving the same as std containers would and people relying on those. The questions that same to mind were:
* How did you get around those issues?
* Why can't two interfaces be provided one with the std containers and one without, specially because they mentioned that they were using std containers internally (I realize you can't answer for them but you might have an idea of why).
* What is preventing Qt from adopting CopperSpice? It seems CopperSpice is taking the right approach of modernizing Qt while re-using a majority of the tools and structure. I'm assuming you had talks with them regarding this.

Thank you so much for this very insightful set of questions.

I was watching you presentation two years ago regarding CopperSpice and you mentioned that you replaced moc for its reflection functions. You explained how you made it work for signal and slots and you also pointed out that it was fairly complicated for enums. Could you explain how you got it to work or point to the source code that does that function?

The main idea behind the code to replace moc and implement reflection in CopperSpice was accomplished by using our compile time counter. We have a recent video on you YouTube channel which explains how this works. https://youtu.be/lCDA3xaLnDg

The problem with enums was related to the inability in C++ to access the enum values at compile time. If you would like to check out some of this code please take a look at the following source on Github.

https://github.com/copperspice/coppersp ... cro.h#L298
https://github.com/copperspice/coppersp ... .cpp#L1704

They pointed out a whole lot of reasons why they couldn't move away from the Qt containers and strings. Something about cheap copy that people rely on. They also mentioned some other issues regarding the Qt containers not behaving the same as std containers would and people relying on those.

The Qt containers are hand rolled and must be fully maintained by their developers. Most of their containers use what is called "copy on write" which is a technique used to copy data only when you write, not read. COW can make copies fast but the extra work on every access can slow down your program. The C++ standard does not allow using COW for any of their classes. They could change Qt and remove COW or even use the STL but from our understanding they are unsure how this would impact the existing users.

Our CopperSpice team decided to discard all of the existing contains and we wrote wrappers for the STL containers. We automatically got all of the new move semantics and years of testing and performance enhancing for free. We did have to change a few internal classes which use to rely on COW. The improved code is actually faster and far more readable. In the process of changing all the CopperSpice containers we updated the API to include both the Qt method names and the STL ones. For example, in the CopperSpice QVector class you can call push_back() or append(), they both work.

What is preventing Qt from adopting CopperSpice? It seems CopperSpice is taking the right approach of modernizing Qt while re-using a majority of the tools and structure.

We do not believe they are interested in using any of our work since Qt wants to maintain backwards compatibility with older tool chains and legacy user code. There are a few areas of C++11 they are unable to leverage since they are supporting older compilers. None of this is inherently bad or wrong, we are just going in a different direction and strongly believe CopperSpice offers C++ programmers a great opportunity to use a GUI library which is keeping up with modern C++.

Please let us know if you have any other questions.

Barbara

The "shallow copy" feature which you call COW (Copy on Write) is relied on by much of the installed base that uses really low powered processors to maximize battery life. Most embedded systems really suck at dynamic allocation. I worked on one medical device project that relied on "shallow copy" as we called it. One of our developers didn't believe that dynamic allocation could suck on a system . . . then he had to parse SVG files containing many images in the XML. The first attempt, pre-loading images alphabetically, took 45 minutes or so just to load. After that he changed the code to load them on a file by file basis. We didn't have a GPU so we had to pre-load images in our own cache and BLIT them onto the screen. Amazingly snappy performance from that tiny little processor sans GPU. Really long battery life too.


I have not yet had time to dig into code and look at actual CopperSpice code but I can tell you the image caching Qt had is horrible for low powered systems. There needs to be a "feature" in CopperSpice where one can tell it to pre-load all images into some cache rather than dynamically manage a subset. That's fine on a high powered desktop but for an embedded system that will never have other images to load, ever, it can really drag performance down. Perhaps a feature to preload a screen at a time?