Can you, for once, provide a simple example instead of dropping lists of enterprise technologies? I'm very sceptic that I want to add a whole new technology to

Can you, for once, provide a simple example instead of dropping lists of enterprise technologies? I'm very sceptic that I want to add a whole new technology to my build just to read a directory path from the system configuration. You might be able to convince me that it's not just a whole lot more boilerplate to maintain, but you won't convince me by parroting these lists over and over again. I've quickly looked up C++/CX for example, and IT IS A DIFFERENT LANGUAGE WITH DIFFERENT SYNTAX. You have to be kidding me. So am I supposed to learn about this new language and write this one stupid function call that I want to make in a totally separate file and build it with a new build chain? My position is, the task at hand would be so much simpler if we could just call a stupid function that we link to. I don't know a lot of problems with that approach. Tell me the problems, and tell me why COM solves them without introducing a whole bunch of new problems. > He is so knowledgable about COM, that in 2018 writes ExitScope manually instead of using either ComPtr or _com_ptr_t. He is not very knowledgeable about it. He even freely admits that. And he shouldn't be, just to call a friggin' function. Regarding the ExitScope, look closely what he does there. He's building a defer statement into C++. The defer statement, while I dislike cleverness including classes and macros, is an interesting idea because it is general (unlike ComPtr or whatever, or even unique_ptr). It doesn't work just on COM objects. And it allows you to put the code inline like regular code - just closer to the point where you constructed something (not just objects) so you can more easily see it's properly cleaned up. The thing is that, while making a new separate class sort-of guarantees proper construction and destruction, it comes at a cost because it artificially compartmentalizes the code. You get this one property (proper cleanup) but you are forced to take that other property. When defining a separate class, it's very hard to see the context in which this thing will be used. And unless it's used in many places, the idea of a clean abstraction usually doesn't come to realization. You'll just end up with a bunch of garbage class code, and when reading it you have to make some guesses about what you can assume. And you end up with two distinct pieces of code that are likely to fall out of sync. The typical experience I've had with reading such OOP code is that I get dizzy very quickly, and it's extremely exhausting, because at each line I'm reading I have to ask, "where will this line jump implicitly? Which exceptions could it throw?" and if I find the implicit jumps correctly, the whole game just starts over in the next line there. Before I have a rough understanding of what this code does, I'll have opened 123 different files that are each extremely vague on their own. I've seen people making separate C++ classes like "TemporaryLocale" that just switches the locale to "C" and back because there was ONE stupid problem somewhere. There is no good reason to make yet another class unless there are a couple points where this will be used, such that knowing and internalizing the class pays off for the programmer / reader. (And the proper solution would have been to just not use any of the crap that depends on the locale).