Description
Please correct me if I am mistaken or let me know whether I am lagging behind the status-quo of cppfront design.
I believe that the success of any new "C++ successor" language will be determined not only how easy and safe it is to write new code but also by how easy it will be gradually translate existing code from C++ to cppfront. The simplest approach of transforming existing code would be to rewrite classes (typically with declaration in *.h and implementation in *.cpp) one by one from C++ to cppfront. This would exactly represent the way of language adoption as expressed by smooth ramp-up line as presented by Herb at the latest CPP conference.
I have read that cppfront is probably aiming to ditch the idea of C++ headers altogether and rely only on modules. I am no expert i modules (so maybe there is some magical solution...) but I think that ditching C++ headers completely may harm the process of cppfront gradual adoption. Simply because existing C++ code expects to include class headers. Majority of existing code is written without modules in mind.
So in my opinion, cppfront should have a way to generate headers alongside with *.cpp files. I do not know how this can be done now. I learned that there i something like *.h2 files. So I experimented with this a bit. I took a very naive (and wrong) approach...
// file widget.h2
Widget: type = {
x : int = 0;
y : int = 0;
sum : (this) -> int; // I naively attempted something like a method declaration here. It does not compile. I know it is wrong.
}
// file widget.cpp2
#include "widget.h2"
// I am naively trying something like a method definition. It does not compile. I know it is wrong.
sum : (this : Widget) -> int = {
return x + y;
}
// file main.cpp2
#include "widget.h2"
main: (args) = {
w := Widget();
std::cout << w.sum();
}
I know this is wrong approach but given the documentation does not exist, I did not discover any other solution which would do the same and would work. I would expect that cppfront would generate widget.h, widget.cpp and main.cpp which would be exactly what a programmer would write in hand with C++, but with cppfront it will be much safer and more concise. The benefit would be that other existing C++ code could also include the generated widget.h if it needs it.
Another possible alternative to the *.h2 files above would be writing just widget.cpp2 which would contain class declarations and implementations at one place but with some magical @... directive added to the class would cause that a *.h file would be generated alongside with *.cpp. The header would contain class definition and method declarations, and cpp file would contain method implementations.
However as I wrote above, maybe some other and better solution already exists in cppfront and I am not aware of it. In that case I would love to learn about how to solve the issue above.
Addendum:
Myself being a Qt-framework fanboy I would love to see adoption of cppfront also within Qt community. By this I do not mean that Qt framework itself would be rewriten to cppfront, this will probably not happen. But I would love to see Qt applcaitions to be written in cppfront.
But the problem is that Qt has it's very special ways... It heavily relies on MOC compiler, which is basically a code generator which parses headers files and based on some macros such as Q_OBJECT it generates additional code necessary for the framework to work. In order to be able to allow interoparability between cppfront and Qt the following 3 steps would need to take place:
- *.cpp2 (and *.h2) files are processed by cppfront. They generate *.cpp and *.h files.
- MOC compiler processes all *.h files in the project and where necessary it generates additional *.cpp files with some Qt "magic".
- All *.cpp and *.h files (i.e. all those generated by cppfront, generated by MOC and handwritten) are compiled and linked together.
So in order for this to work, it is essential in step 1 to be able to generate somehow the header files so that they can be processed by MOC in step 2...