-
Notifications
You must be signed in to change notification settings - Fork 769
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. |
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.
Copied the code, but forgot to update the error message. Now it's fixed.
I'm seeing a lot of if statements without explicit curly brace blocks. This is confusing and I'm sure it's disallowed by our c++ style guide which I'm sure we have (and is aligned perfectly with my own internal, shifting preferences. If not I'm happy to ninja edit it after any disagreements once I find it). |
If a person can't read, how will he understand that a |
Is there an ETA for this being merged? We need the C++ port so we can make a python wrapper for this library. Thanks. |
Since we are already on the subject of switching to a compiled language, perhaps we should shoot 2 pedestrians with 1 airstrike, and pick a memory safe compiled language. There are multiple options. There is also Zig, but it is not mature enough. Hence it is also ruled out, as we do not allow minors in our company. Then there is Go |
Please read my previous post highlighting the selling points of Go. We might want to deprecate the C++ version and rewrite our project in Go for memory safety, speed, fast compilation times, cross platform-ness, and Simplicity of our business logic. Go is already used within the industry, mostly in small businesses like Shopify, Google, Netflix, Meta, X, and such. |
My program is memory safe. At least I believe that it is. The things that are not memory safe in C++ are mostly C remnants. In C++ variables get deallocated automatically when they are no longer required, you have lists of different types that get deallocated automatically, you have |
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.
Not quite over the line yet, but if we circle back I think we can really get this whipped into shape. Some action points for our standup tomorrow, so we'll circle the wagons and take a brainstorming session before we wrap up.
The pull request seems to be ready for merging. For people who want to contribute, I'm attaching the AMD programming manual: |
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?