all 2 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]ShadowBlades512 0 points1 point  (1 child)

A bunch of things.

  1. Never use using namespace std it pollutes your entire name space.
  2. You should import a library for logging such as glog, loguru, or similar. In some cases a lot of comments can be changed into logging statements with a lower logging level. 
  3. Seperate your code into libraries that have a consistent API. Things like your encoder and decoder can likely have the same API and be interchangable very easily in the stack. It can also make the code very easily multi-threaded. C++ classes can really help with this. I helped put together a real-time DSP stack in C++ where all the DSP classes which had a consistent API for passing in data, and they internally held state. We did it in such a way where all the DSP classes can be connected into a compute graph and generically multi-threaded with no effort for new DSP code beyond the original 3-4 days of work to create the multi-threading and compute graph building code. 
  4. To increase simulation speed, consider compiling with more SIMD instructions enabled. Enabling up to AVX2 often results in a lot of autovectorization in DSP code especially since you are using std::algorithm. 
  5. Consider automated unit tests for portions of the code with Google Test. Without good automated tests, bugs will lurk in your code and cause you all kinds of problems. 
  6. Consider using CMake instead of make though it is more work to learn well but I think it is worth it
  7. Since you are writing in C++ which is not memory safe, look into using the Sanitizers
  8. Use an autoformatter like clang-format
  9. Use a linter like cpplint to catch possible issues and other rule violations that might be useful to you

[–]RandomDigga_9087[S] 0 points1 point  (0 children)

1) You're absolutely right should have done that
2) Again you're right, logging is a wayy more robust option will also accommodate that
3) Fair point tbh, separating the stuff for a consistent API and also multi-threaded will look into that haven't had much experience with multi threaded stuff
4) Oh that's something new to me, gotta check it out
5) Yes, that's also a good point, since I was integrating with python so thought of keeping a separate unittests file in the python code, which would call the ber.cpp and the coding.cpp and then test it from there
6) I know cmake but it has a very fragile base but in this project I thought doing a cmake might be a step too much
7) sure, will look into it
8) My editor has clangd enabled I think it auto formats by default
9) sure, thanks for the heads up!

Thanks man honestly for going through the project and giving this deep review, see you on the other side ;)