Hacker News Reader

Comment by bsenftner | Hacker News Reader

About 16 years ago I started working with a tech company that used "C++ as C", meaning they used a C++ compiler but wrote pretty much everything in C, with the exception of using classes, but more like Python data classes, with no polymorphism or inheritance, only composition. Their classes were not to hide, but to encapsulate. Over time, some C++ features were allowed, like lambdas, but in general we wrote data classed C - and it screamed, it was so fast. We did all our own memory management, yes, using C style mallocs, and the knowledge of what all the memory was doing significantly aided our optimizations, as we targeted to be running with on cache data and code as much as possible. The results were market leading, and the company's facial recognition continually lands in the top 5 algorithms at the annual NIST FR Vendor test.

View on HN

Funnily enough, 16 years ago, I too was in exactly this type of company. C++, using classes, inheritance only for receiving callbacks, most attributes were public (developers were supposed to know how not to piss outside the bowl), pthreads with mutexed in-memory queues for concurrency, no design patterns (yes we used globals instead of Singleton) etc. So blazingly fast we were measuring latencies in sub 100-microseconds. Now, when modern developers say something is "blazingly fast" when it's sub-second, I can only shake my head in disbelief.

Yes, very similar. We had pthreaded mutexed queues too, and measured timings with clock_gettime() with CLOCK_MONOTONIC. Our facial template match runs at 25M compares per second per core, and simply keeping that pipeline fed required all kinds of timing synchronizations.

The only community I know that produces developers that know this kind of stuff intimately are console game programmers, and then only the people responsible for maintaining the FPS at 60. I expect the embedded community knows this too, but is too small for me to know many of them to get a sense of their general technical depth.

Also the old school HFT community (which I'm from).

An even smaller community too. I spent time in that community, very briefly around '89. I was not of the mindset to be interested in the stock market at that time, and left for the animation industry.

This however, is an implementation strategy, that most business/"enterprise" developers will fight to the teeth, because they believe, that OOP is the only workable way to create abstractions and that any successful project must have inheritance in it. They never learned another way.

Actually Rust goes a long way towards a similar strategy, by avoiding inheritance and instead relying on structs and traits. That already avoids a lot of BS programming. I am very glad they threw out inheritance and classes. Great design decision right there. I wish FP was made more convenient/possible in Rust though.

Sounds like they know what they are doing. How is using c++ with only data classes different from using c with struct

Slightly better ergonomics I suppose. Member functions versus function pointers come to mind, as do references vs pointers (so you get to use . instead of ->)

Yeah, slightly better ergonomics. Although we could, we simply did not use function pointers, we used member functions from the data class the data sat inside. We really tried to not focus on the language and tools, but to focus on the application's needs in the context of the problem it solves. Basically, treat the tech as a means to an end, not as a goal in itself.

Namespaces are useful for wrapping disparate bits of C code, to get around namespace collisions during integration.

Templates (without crazy metaprogramming stuff) can be a godsend for basic data structures.

Also fast to compile!

Reply on news.ycombinator.com