With the advent of Modern C++, it is very easy to use the power of C++ in the form of web-services which can easily be access through javascripts and other languages by REST API calls. Here is a plan with a real world example on how to go about it:
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (9)
Just goes to show my yearning for a PHD degree, now uploading papers in Academia ..
FYI, here's a full C++ web framework, like Flask for Python.
I was looking for something to play with that would help me re-learn C++ (my day-to-day is all managed), and implementing a web-app backend with that seems like a perfect fit for me.
Thanks for referencing it!
Yes, Crow is what inspired me to take it one step further.
Because we have a modern webserver like Crow, I wanted to take it one more level and act as an ORM framework, pretty much what you can do with loopbackjs or Django. The idea is very much in its initial phase, will share more as it gets more concrete.
Why use
C++overGolangor evenRust?Performance, breadth/depth of existing libraries, C-interop, and flexibility to name a few.
Not saying you HAVE to use C++ for those reasons, but depending upon your requirements the usability of Go or the robustness of Rust may not be enough to close the capability gap with C++.
Are Go or Rust lacking in performance? Not rhetorical. I don't know the answer to this.
C++ tries very, very, very hard to be as performant as possible; trying to leave no room for devs forced to consider using different languages to eke out more performance. That's one of the reasons that C++11 introduced move semantics in the form of rvalue references, despite how much of a burden it imposes. Without rvalue references, there was a critical disadvantage that C++ had against other languages like FORTRAN. And one of the reasons that the C++ standard leaves so many parts of the language declared as "undefined behavior" or as "platform specified behavior". C++ is not a hand-holding nanny language! The C++ knife is very sharp, and devs can easily cut themselves if not careful.
Granted, C++ does have a vast variety of existing libraries / frameworks / SDKs covering all sorts of problem domains. For example, Boost is a smorgasbord of functionality.
Rust interops with C. Go interops with C.
Ironically to me, C++ interops with C, but C++ does not interop with C++.
By that I mean if I have C++ compiled with GCC g++, and C++ compiled with Visual Studio's CL.EXE, unless the two halves bridge through a C ABI barrier they won't interop. And even if I use a specific version of GCC g++, different compiler flags can make different parts of the code C++ ABI incompatible with one another. In practice, it is merely a bit of a bother and just takes the dev to pay a little attention to avoid the pitfalls.
The reason so many languages interop with C is that the C ABI is well established.
Are Rust and/or Go inflexible? Also not rhetorical, I don't have enough practical experience with Rust and Go to decry either of them as inflexible. I've only written small programs with them, for educational purposes.
Clearly I was not clear enough about what I was trying to communicate 😀
When I mentioned requirements a large part of what I meant was the cutting yourself problem you mention. Even modern C++ is not particularly forgiving so you need to have a clear evaluation of whether that cost and risk are worth it for you.
I also probably shouldn't have used the term interior. My bad. Compatibility is probably a better term, since C++ can literally #include C code. Yes, it will be compiled differently but depending upon what you are trying to reuse that could be better.
The performance angle is a tricky one. Various benchmarks I've seen have C++ > Rust > Go. Are they artificial? Is there difference due to the current optimisers instead of inherent language design? Given the skill set could you have people who could write faster Rust programs than C++?
I think the answer to all of those questions is maybe?
For flexibility, the only thing that Go lacks is templates/generics and that's being worked on. For Rust I've had discussions with colleagues who write high performant C++ for a living, where I asked their opinion of if it could live up to its promise of providing the same performance with better safety. Their assessment, which could be biased, is that for Rust code to match the same performance your have to use so much unsafe code that you lose the benighted is it being Rust.
I thought your prior post and this follow-up post are very good.
Provocative statements, which made me think about things. Those things I posted about, prior. And a nice follow-up answering my non-rhetorical questions. :-)
I'm a programming languages wonk. However, I don't have enough practical experience with Go or Rust. I have decades of practical experience with C++, and profess a love-hate relationship with C++.
In my experience, 95% of most AAA-titled programs can be written in a "safe" language. The 5% of the program that has to be absolutely as performant as possible can be written in an appropriate highly performant language.
My current project is 80-90% C++, if one counts lines-of-code. But all-in-all, it uses about 30 different languages. (I consider C, C++, Objective-C, Objective-C++ as different languages. I consider EcmaScript 3, EcmaScript 5, EcmaScript 6, ExtendScript, ActionScript as different languages. I'm considering pre-standard C++, C++98, C++11, C++14 as the same language. I consider DSLs such as GLSL as a different language.)
A different team wrote 95% of their highly performant AAA-title program in a scripting language. The last 5%, the performant core, was written in C (...but only because the principle developer for that last 5% loves C and loathes C++).
Right tools for the job. Alas, most projects use the tools that are most familiar rather than most suitable. And yes yes yes, familiarity with a language by the dev team is a point in favor of that language as being suitable. But only one point. Developers can pick up a new language, ramp up and become productive in it in a very short order - a few months. I've seen that over-and-over again.