General Questions

Discuss anything related to product development

General Questions

Postby dvader » Mon Nov 27 2017 10:18 pm

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.
dvader
 
Posts: 1
Joined: Mon Nov 27 2017 5:30 pm

Re: General Questions

Postby barbara » Tue Nov 28 2017 7:07 am

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/copperspice/blob/cs-1.4.4/src/core/kernel/csobject_macro.h#L298
https://github.com/copperspice/copperspice/blob/cs-1.4.4/src/core/kernel/qmetaobject.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
barbara
 
Posts: 61
Joined: Sat Apr 04 2015 2:32 am


Return to Developers

cron