In short their answers were useful and highly aligned, not just with with my thinking but with one another. There wasn't consensus, this is the internet, but there were was remarkable consistency.
"...painless cross-platform-ness, obviously. One should not need to dip into the underlying Win32 on Windows, say, basically ever to do typical things."
Agreed! We should be able to create substantial applications without consideration for which OS they're going to run on. Most of the languages our applications talk these days, from Unicode to OpenGL, to gRPC are standardised across operating systems and even across programming languages. With a little bit of work to smooth over the idiosyncrasies of individual operating systems we aught to be able to program in terms of these standards without worrying about the target platform on which they'll end up running.
In practice of course that 'little bit of work' could end up being rather large but perhaps it can be done.
"Must support CMake find_package vcpkg instrumentation..."
Agreed! We love to hate CMake but it is what the industry is settling around. We build with CMake and package with vcpkg. It doesn't solve all our problems or make delivering C++ software easy but it works well enough and will likely get the focus and feedback required to keep making it better.
"License must be something like BSD..."
Agreed! Boost license, MIT license and BSD licenses so that the project can be used commercially without caveats or concerns. Anyone can contribute, including companies and everyone who wants to commercialise their own fork can. No fuss, no argument licensing makes adoption much smoother and therefore much more likely.
"All C++...", "No DSL...", "No extra pre-processor stage..."
Agreed! C++ can do anything so if we're doing something, we're doing it in C++. Especially for a C++ framework. That includes Signals and Slots. DSLs are the temptation ever in the corner of the eye. Goading us make things look simpler while destroying discoverability and imposing new vocabulary on our users.
"Must not be header only..."
Agreed! Gigantic header only libraries are a menace. They slow build times, often hide bad code, leak definitions, have unclear APIs and all contain similar but not quite the same, boiler plate for platform and compiler support. Duplicated code that makes them inconsistent with one another and undermines your platform support from below while preventing you from centralising it.
Boost was originally intended to be a header only framework and it still suffers from the consequences today with header dependency chains reaching out across multiple libraries to things you never intended to depend on. It's getting better but their moving away from header only should be a lesson learned.
"Native C++ database (scalable)..with non SQL interface."
Not a big ask at all then ;-) However it is something we could do with. Many years ago I worked with a multi dimensional BI database written in Fortran that ran rings around Oracle and made SQL Server look silly. It was definitely non SQL although it did have it's own somewhat arcane query language. Something like that in modern C++ with simplified queries would be awesome.
Then there's the UI of course.
"MUST support a declarative GUI language that’s transpiled to a compiled language like C++, so no js framework in between."
"If you are going to have a separate WPF-style layout language (please don't use XML), allow the user to opt out of it. Don't make it mandatory. That is, allow the user to create UIs by just nesting together controls using normal C++ code if that is what they want to do."
"Make it possible, if not necessarily easy, to construct 100% custom controls."
"...support a dark theme out of the box."
"...supports WebAssembly ... so that we can create amazing ..native C++ websites."
"WinForms + designer but for C++"
So we want an optional declarative GUI language that can be generated from an interactive designer, hand written, or bypassed altogether to create completely custom controls, mixed in with the provided ones. The GUI that results must run natively and in a browser using WASM.
"Like Dioxus for Rust"
as someone noted.
Last but not least.
"...with the compile times of C#."
Of course, no problem ;-)
You'll notice that while there are a lot of big asks here and this is not every response I got. There is very little in the way of contradictory requirements. In principle we could have the C++ framework we want. Cross platform, comprehensive and flexible. We'd just have to write it.
So what are your MUST HAVEs and MUST NOTs for an all new, top of the line, C++ Application Framework?
Do you believe such a project is possible and would you be interested in contributing?
Top comments (0)