-
Notifications
You must be signed in to change notification settings - Fork 763
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite the very real enterprise project of totally not a satire project to C++ (real) #694
base: uinverse
Are you sure you want to change the base?
Conversation
// isn't this supposed to be easy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few things. would be cool to have CMake support and C++23 too.
We upgraded the project standard to C++23. Thanks for the suggestion about using CMake, however, our very serious totally not satire company only uses serious business tools, such as Microsoft Visual Studio 2022, and not Linukz KitWare CMake. |
Requesting a review because changes were done to |
@GEOEGII555 have you considered that C++ is older than Java? Shouldn't migration efforts be directed towards newer technologies? Company wants us to use the latest and most hyped technologies to keep our stack more competitive in the future. |
Please keep in mind that C++ is used to this day. I saw a popular commonly used project which is still on C++11 (August 2011)! Can't remember the exact name though. This PR uses a newer version of C++.
If you look at the latest update release date, both are new. If you look at the date of the initial release, we should be moving away from Java to a new programming language no one else uses. Currently, C++23 is used. It was released in December 2023, which is a year ago. It's relatively new compared to the C++ versions other commercial products use. |
We should consult some tech leads that will decide if raw c++ is secure enough for this software. I guess some parts could be written in rust to make is more secure. |
While I'm not a Rust developer in any kind, in my opinion, combining Rust and C++ would be more unsafe than using raw C++ or raw Rust. Also please keep in mind that Rust compilation is slow. |
Hmmm, needs some dependency injection via templates |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The patch looks good indeed. I just have a few stylistic remarks.
#include <algorithm> | ||
#include <ranges> | ||
|
||
_console::_console() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For internationalization, it may be useful to switch the console window to UTF-8. I did a proof of concept a few years ago. My approach is not very enterprisey, but maybe you can convert it to something more professional.
Copied the code, but forgot to update the error message. Now it's fixed.
Hello,
At enterprise quality programming Co. LTD, performance is one of the top priorities that a company would have. The slower the performance is, the less clients a company would have. It's one of our top goals to maximize the performance.
That being said, while Java is a great programming language, it can't beat the speed of C and C++.
So, in order to maximize the performance of the fizz buzz: enterprise edition, and to beat the competitors, we need to rewrite Fizz Buzz: Enterprise Edition in C++.
While it's possible to write assembly code that has better performance than C++, it would cost too much. Most C++ compilers, such as the Microsoft MSVC compiler, generate very fast executables, where optimizing it further is not worth it.
Since we are on C++, our very serious enterprise project only supports the very serious enterprise platform called "Windows NT", we can leverage:
We also don't have to worry about destroying the performance and significantly increasing the dependency count when leveraging:
The only downside of this is that we will be using the Windows API, which means that if some company ever decides to use Linukz as their operating system, even though it's not a serious business environment, they won't be able to use our project, which will lead to revenue loss.
This pull request closes #693.
There's one question: do we add tests?