3 ms·
C++ is a beautiful, pragmatic and very efficient language, just constrain your use of it to STL, and avoid Boost and other over-engineered dependencies. The Oc
by andyxor 5y ago
C++ is a beautiful, pragmatic and very efficient language, just constrain your use of it to STL, and avoid Boost and other over-engineered dependencies.
The Ockham's razor principle of code design is not only important but essential when using large mature languages that have many surprising and nuanced ways to skin a cat. Being too clever with C++ is a recipe for disaster.
Avoid OOP (inheritance in particular) and the sacred art of templates metaprogramming, but also avoid the lowlands of using C++ as a version of C language (with malloc everywhere), and you shall be rewarded in this life or next.
- geofft 5y agoI'm not sure I understand your points about Boost - everything the article discusses is in the STL, is it not? I'm also not sure I understand your point about being too clever and template metaprogramming - nothing the article discusses involves template metaprogramming, and I'd say it's doing very straightforward things. Do you think some part of this is too clever? Also, I'm not sure I understand how to reconcile your "Avoid OOP" advice with the advice to use the STL. Doesn't using the STL mean making use of OOP?
- andyxor 5y agoSTL and OOP are orthogonal, e.g. you can use STL without ever using the concept of inheritance. Boost is too popular imo, and many people take it for granted when using C++ that it comes with this nice utility library to complement STL, kind of like another python package, no big deal. From what I've seen on multiple projects it creates an explosion of poorly understood (and often poorly implemented) dependencies which leads to maintenance nightmare, memory leaks and bugs, performance issues and production outages. If you can avoid using an external dependency such as a gigantic library full of experimental features created by thousands of C++ enthusiasts avoid it at all costs. as it tempts the team to use it left and right when it's not really needed, just like templates. Templates, if used without strictly complying to the KISS principle can get unwieldy, full of nuanced, intricate and unnecessary abstraction, and make it hard to understand and maintain the code C++ is a giant language and its use on a particular project has to be very tightly constrained to a very minimal set of features and dependencies.
- solipsism 5y agoWhat do you call "wisdom" that's passed from person to person, so everyone knows it, but it isn't actually true? A huge amount of Boost is nothing but headers. And it's very easy to use those header-only libraries and avoid the rest. Sure, many people have just pulled in the entirety of Boost... but it's really strange to blame Boost for those bad choices. By the way, a lot of what today is standard C++ had its origin in Boost. smart pointers, thread, regex, random, ratio, tuple, etc etc. All came from Boost, and those of us using Boost were happily taking advantage of it, while folks who believe the "wisdom" you just shared were building it yourselves.
- andyxor 5y agowell i've seen it used "enthusiastically" for the lack of better word, i.e. once someone on the team starts using one header, with some relatively well proven and robust feature (like smart pointers), it creates a temptation for them and other team members to use anything else available in that giant library "for free". And some features there could be more experimental in nature and some are either not intended, or not really needed for a simple use case you have at hand, so unless you veto each new #include by a panel, it becomes a giant cluster fsck full of infinite permutations of advanced, and poorly understood features which creates very fragile foundation for the project and maintenance nightmare. Since the good parts of Boost are already in STL, i always recommend to just stick with (very minimal set of) STL, don't use what you don't need right now, and avoid the temptation to throw every available library or "neat" feature at a problem (which might save a bit of thinking time short term but open a can of worms long term)
- jcelerier 5y ago> And some features there could be more experimental in nature and some are either not intended, or not really needed for a simple use case you have at hand, so unless you veto each new #include by a panel, it becomes a giant cluster fsck full of infinite permutations of advanced, and poorly understood features which creates very fragile foundation for the project and maintenance nightmare. how is that better than the usual 2021 project having a package.json with 350 sub-dependencies
- v8dev123 5y agoOOP and Boost also Templates has benefits when it comes to increasing barrier of static reverse engineering. For example, Security researcher "Marcus Hutchins" famously echoed that Boost is a cluster fuck of OOP sadness [0] Similarly, a close friend of mine "Omer Yair" mentioned [1], "A well written OOP malware might be harder to RE statically than a poorly written C code. Writing OOP malware badly though just makes it similar to C code so not sure of the benefits going that route." [0] https://www.malwaretech.com/2017/04/the-kelihos-botnet.html https://www.malwaretech.com/2017/04/the-kelihos-botnet.html [1] https://twitter.com/yair_omer/status/1262020385203200000 https://twitter.com/yair_omer/status/1262020385203200000
- saagarjha 5y agoI mean they do but not by as much as to actually matter.
- gpderetta 5y agothere is very little OOP in boost.
- v8dev123 5y agoI believe he imply two different things. Boost heavy on templates and the malware heavy on OOP. His original comment was, "Using boost to turn the code into a clusterfuck of OOP and sadness)" Whatever. Everything is true because I've done RE my-self. It's hard. Another one also said, "Reverse engineering objective-c code with heavy QT framework usage makes me seriously doubt my life and career choices." I guess the same applies with C++ with heavy QT framework usage.