4 ms·

Note that the example I posted is written in C++, by Jonathan Blow (you do not need to like him but I hope we can agree that he is an accomplished programmer).

Note that the example I posted is written in C++, by Jonathan Blow (you do not need to like him but I hope we can agree that he is an accomplished programmer). And he is still cursing (mostly about other stuff, but about that COM abomination, too). Can we write the COM part of that code in a better way?

pjmlp 7y ago
Surely, by making use of C++/WinRT, C++/CX or VC++ Compiler COM Support mode, who still uses stuff like STDMETHOD outside legacy code?!? And on Embarcadero's side, C++ Builder Component Wrappers. He is so knowledgable about COM, that in 2018 writes ExitScope manually instead of using either ComPtr or _com_ptr_t.
- jstimpfle 7y ago
  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).
- jstimpfle 7y ago
  https://docs.microsoft.com/en-us/archive/msdn-magazine/2017/january/c-introducing-c-winrt https://docs.microsoft.com/en-us/archive/msdn-magazine/2017/... Looks like Microsoft freely admits that its previous Technologies like C++/CX are "clunky" to use (which I wager is PR speak for "impractical bullcrap"). Not to mention other technologies which are officially described as "verbose, tedious and complex". Now it seems like C++/WinRT is the next holy grail and they provide instructions how to port your previous code (which is now obsolete - thanks Microsoft!) from any of the previous technologies to the new blessed one. We'll see how that works out. If I understand correctly, C++/WinRT allows you to write mostly standard-conforming C++, which is an incredible feat! </s>. It might make it easier to write code that is portable between platforms. Meanwhile I'll just continue using plain C, instead of pulling out the last hair I still have on my head. Because nobody's still given me a reasonable argument what's wrong with plain functions and a linker. And nobody has been able to give a good argument why we need an obscure technology like COM to achieve a reasonable amount of compile-time and run-time introspection. Why shouldn't we just be able to specify which sets of plain old functions should be used as constructors and destructors, for example? That would allow to write all kinds of OOP languages on top for anyone who is willing to make the associated tradeoffs.

pjmlp 7y ago

Surely, by making use of C++/WinRT, C++/CX or VC++ Compiler COM Support mode, who still uses stuff like STDMETHOD outside legacy code?!? And on Embarcadero's side, C++ Builder Component Wrappers. He is so knowledgable about COM, that in 2018 writes ExitScope manually instead of using either ComPtr or _com_ptr_t.

jstimpfle 7y ago
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).
jstimpfle 7y ago
https://docs.microsoft.com/en-us/archive/msdn-magazine/2017/january/c-introducing-c-winrt https://docs.microsoft.com/en-us/archive/msdn-magazine/2017/... Looks like Microsoft freely admits that its previous Technologies like C++/CX are "clunky" to use (which I wager is PR speak for "impractical bullcrap"). Not to mention other technologies which are officially described as "verbose, tedious and complex". Now it seems like C++/WinRT is the next holy grail and they provide instructions how to port your previous code (which is now obsolete - thanks Microsoft!) from any of the previous technologies to the new blessed one. We'll see how that works out. If I understand correctly, C++/WinRT allows you to write mostly standard-conforming C++, which is an incredible feat! </s>. It might make it easier to write code that is portable between platforms. Meanwhile I'll just continue using plain C, instead of pulling out the last hair I still have on my head. Because nobody's still given me a reasonable argument what's wrong with plain functions and a linker. And nobody has been able to give a good argument why we need an obscure technology like COM to achieve a reasonable amount of compile-time and run-time introspection. Why shouldn't we just be able to specify which sets of plain old functions should be used as constructors and destructors, for example? That would allow to write all kinds of OOP languages on top for anyone who is willing to make the associated tradeoffs.