3 ms·

It may well be that I missed an important development, but the underlying cruft of course didn't change. It's DLL based object code, just like regular C code, e

It may well be that I missed an important development, but the underlying cruft of course didn't change. It's DLL based object code, just like regular C code, except that a lot of boilerplate is required to be a "blessed COM" DLL. https://en.wikipedia.org/wiki/Component_Object_Model#Technical_details https://en.wikipedia.org/wiki/Component_Object_Model#Technic... > No one uses MFC to create COM nowadays, unless they are dealing with mid-90's code. I guess that's what I was given... Now tell me what will be easier to call from my hobby programming language, COM or regular object code? > because a component based ABI > It is modern, because a component based ABI, with language interoperability in mind, is much better than a fossiled ABI designed for PDP-11 clones. It is literally the same "fossiled ABI", wrapped in more shitrolls to hold all the crap. If you just mean the APIs are more pleasant to use, then maybe that is so, due to the structured objects system, if you have all the tooling in place. I'm not sure I've ever used it from a managed language, and in general, hiding cruft by adding more cruft is not my cup of tea. Here is one example that I recently found. It shows the bullshit you have to go through to interface with COM as a C programmer: https://pastebin.com/3YvWQa5c https://pastebin.com/3YvWQa5c

pjmlp 7y ago
The boilerplate is what happens when some people insist in using C instead of C++ or other modern languages to use COM, so they need to write manually what the compiler would do for them in more modern alternatives.
- deleted 7y ago
  [deleted]
- jstimpfle 7y ago
  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).

pjmlp 7y ago

The boilerplate is what happens when some people insist in using C instead of C++ or other modern languages to use COM, so they need to write manually what the compiler would do for them in more modern alternatives.

deleted 7y ago
[deleted]
jstimpfle 7y ago
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).