Good Book about Low-Level C++ [from a quant dev] 

Quantitative

@@ANKUSHKUMAR-ek7yh what is quantitative

​@@stefanplusplus917quanti with a tative

​@@stefanplusplus917literal definition is measurement of quantity. Like when I say 3 apples, you think about 3 apples, notice here I haven't defined the size, color or taste which are qualitative properties. But here in this video it's much related to high frequency trading, search this on Google for more info. Hope this helps

Yes, OOP is still very much around. Unless you are on the hot path, the additional overhead of a vtable is usually acceptable

note that OOP doesn't inherently add overhead. C++ is statically compiled so unless you are utilising forms of dynamic dispatch, it doesn't really matter as all the OOP relating information is stripped at compile time.

@@ghdshds1899 i agree with you there, and I am curious if its DOD based, would it gain more performance since OOP is already performant enough, since HFT is competitive and all. Performance aside, I am also curious in terms of complexity, following rhe idea of the hardware is the platform, not the software or code, purposed by Mike Acton, I wonder if it would help simplify things for maintainability. Anyway I do think abstractions does help with accessibility, for better or for worse, idk. It is the reality we live in and its either we work in an environment that prefers one or the other. Just curious about this not expexting any answers.

@@gabrielkwong1878 I think first its worth noting that quant and HFT aren't the same thing, in the sense of all HFT firms are quantitative firms but not all quantitative firms are HFT and hence won't care too much about latency. But that's a nitpick, so to your actual question, DOD and OOP aren't mutually exclusive at all! OOP describes a technique of arranging and organising code, not the data structures and algorithms that power the business logic. DOD is a performance and simplicity driven design philosophy but it doesn't necessarily obstruct OOP. You can certainly design your object constructs to be mindful of the benefits of DOD, but maintain key OOP mechanisms like inheritance and encapsulation (and even statically decided polymorphism). Typically I see codebases that avoid the flamboyant mechanisms of OOP that make things difficult to read and follow, because the code needs to be maintainable and easy provable, but you can do this whilst still using some elements of OOP. TLDR: You don't need to prescribe yourself any one programming/design paradigm, and when performance and validity is critical you should definitely not constrain yourself to any, and instead do whatever meets your actual goals.

Glad to hear it!

I think this book is for a specific subject after you are familiar with c++, go with c++ primer for beginner.

@@HappyFatso Thank you so much mate

I agree, although the book I suggest briefly covers C++ fundamentals, it's not suited if you are not at all familiar with C++ programming

@@TheQuantDev Thank you buddy

Definitely. good luck!

i took a microcontroller course. it was so good

@@mango-strawberry yep, I specialized in it. It's a different world than quant finance. That's why it's strange for him to suggest this book. Judging by his refusal to reply or acknowledge the comment, I'm right. Goes to show really that getting into quant is more about luck than reading textbooks.

@@stanleyaj oh def. getting into quant finance is more about what college you went to + luck like you said rather than reading specific textbooks

Indeed, micro controller-specific knowledge is not directly relevant to HFT, but good understanding of low-level C++ is. However, in the video, I suggest specific sections of the book that are helpful for quant dev interviews. It's one of the few books I quite liked personally due to its structure and having a lot of code examples. I also agree you always need a bit of luck when it comes to your career.