- Creating lambdas in static factory function - 6 Updates
- Should you use constexpr by default? - 3 Updates
- Standardization - 10 Updates
| scott@slp53.sl.home (Scott Lurndal): Aug 20 05:16PM >function pointer business disappears from your code, the abstract >reads clean and there isn't any worries about ABI either. This is one >reason why COM uses interfaces for callbacks (e.g. Connection Points). Now here, I agree 100%. However, the 'No Multiple Inheritance' police may object. |
| Manfred <noname@add.invalid>: Aug 20 07:56PM +0200 On 8/20/2018 7:16 PM, Scott Lurndal wrote: >> function pointer business disappears from your code, the abstract >> reads clean and there isn't any worries about ABI either. This is one >> reason why COM uses interfaces for callbacks (e.g. Connection Points). I would not agree on this. Interface pointers are a replacement for callback functions in COM because there is no such thing as a function object (or pointer) in COM. Function objects and pointers are IMO a powerful feature of C++ which, as all power features, need to be known how to use properly. They are essential in writing effective generic algorithms as one example. > Now here, I agree 100%. However, the 'No Multiple Inheritance' police may > object. Well, pure abstract interfaces usually benefit from pardon by such police (and BTW this is the rule in .NET). |
| Manfred <invalid@add.invalid>: Aug 21 02:32AM +0200 On 08/20/2018 10:16 PM, Richard wrote: > data types that don't require custom marshalling to move across object > boundaries, but there is nothing preventing you from using COM method > calls that accept or return function pointers. Actually this is not correct: there is no way you can marshal a function pointer across process boundaries in COM - this needs to end up with a RPC call for which COM needs an interface pointer. (In-process COM objects are functionally equivalent to DLLs, so, however common they may be, I don't consider them representative of what COM is for - its main value feature-wise being inter-process and inter-host communication in my experience) >> as all power features, need to be known how to use properly. > The function pointer syntax is painful and there are some quirks in > the grammar as a result. Function objects and lambdas were introduced to ease their coding, besides other goals of course. It's been my experience that as soon as you > need one callback, you need a second one in short order. That may be true, but I think it depends on the application domain. Then there's > writing two methods on a C++ object for every callback method you > implement -- once for a static "C" style function pointer that > delegates to an instance method and the instance method. If you need a 'this' pointer, then pointer-to-members are the answer; although I have to admit that whenever there is a 'this' pointer involved, then OOP gets more in the picture, so I find myself too wrapping the callback into and abstract interface. Unless > testing if you follow this strategy. >> They are essential in writing effective generic algorithms as one example. > They are not essential for making generic algorithms. I wrote /effective/ generic algorithms - stuff like std::sort works best with function objects rather than interfaces. An abstract |
| legalize+jeeves@mail.xmission.com (Richard): Aug 21 08:37PM [Please do not mail me a copy of your followup] Manfred <invalid@add.invalid> spake the secret code >Actually this is not correct: there is no way you can marshal a function >pointer across process boundaries in COM - this needs to end up with a >RPC call for which COM needs an interface pointer. You can do it with custom marshalling, which you would need because as you say COM doesn't know how to marshall a function pointer. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Manfred <noname@add.invalid>: Aug 21 11:19PM +0200 On 8/21/2018 10:37 PM, Richard wrote: >> RPC call for which COM needs an interface pointer. > You can do it with custom marshalling, which you would need because as > you say COM doesn't know how to marshall a function pointer. Er no, not even with custom marshaling - a function callback pointer (note: callback) is defined in the context of the address space of the process passing the pointer. As the receiving process gets the pointer (with custom marshaling), it would have no way to invoke the callback on the other process - it would need to perform a COM call which requires an interface pointer. |
| legalize+jeeves@mail.xmission.com (Richard): Aug 21 10:34PM [Please do not mail me a copy of your followup] Manfred <noname@add.invalid> spake the secret code >(with custom marshaling), it would have no way to invoke the callback on >the other process - it would need to perform a COM call which requires >an interface pointer. You basically do it by brewing up remote transparency for a local function pointer yourself. At any rate, I don't see the point in delving further into this discussion since it is way off tangent for the original topic. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Juha Nieminen <nospam@thanks.invalid>: Aug 21 03:58PM A good programming practice that has existed in C++ since the beginning (or, more precisely, since this was supported) is to always make your class member functions const by default, unless they really need to modify the the contents of the object in question (or need to call other non-const member functions). (One way to follow this principle is "always put 'const' at the end of member function declarations unless that makes it not compile.") Personally I have gone even further with this "always use const by default" principle (something that I was taught as a good practice): Whenever I declare a function-local variable, I declare it const unless I really need to modify it (again, same principle: "Make it const unless that stops it from compiling.") The idea with this is, of course, that it will catch unintentional modifications of those variables. Now that constexpr is a thing, I'm wondering if this principle should be extended to that. Should all functions (and member functions) be declared as 'constexpr' by default (unless that makes it not compile)? I can't think of any drawbacks of this. If I understand correctly, there can only be performance benefits from it, never drawbacks. (Even if the constexprness never realizes itself at compile time, you haven't lost anything in terms of performance.) |
| "Öö Tiib" <ootiib@hot.ee>: Aug 21 10:45AM -0700 On Tuesday, 21 August 2018 18:58:26 UTC+3, Juha Nieminen wrote: > Whenever I declare a function-local variable, I declare it const > unless I really need to modify it (again, same principle: "Make it > const unless that stops it from compiling.") That is very good principle to favor immutability where possible. > there can only be performance benefits from it, never drawbacks. > (Even if the constexprness never realizes itself at compile time, > you haven't lost anything in terms of performance.) In theory the constexpr lets to test and to catch defects compile-time. So that can supposedly help us to fail faster. OTOH in practice I have noticed that C++ compilers are slow when running functions compile time. So simple functions that compiler will likely inline and optimize anyway are OK to mark as constexpr but deeper algorithms are cheaper to test with usual unit-tests and keeping those non-constexpr in debug builds can speed development process somewhat. |
| Vir Campestris <vir.campestris@invalid.invalid>: Aug 21 08:57PM +0100 On 21/08/2018 18:45, Öö Tiib wrote: > deeper algorithms are cheaper to test with usual unit-tests and > keeping those non-constexpr in debug builds can speed development > process somewhat. Whether of course this is a problem or not depends entirely on your environment. We use Ice Cream distributed builds. https://github.com/icecc/icecream We've found that once you get past about 100 cores the improvements in performance are minimal. That's 100 times parallel compilation, spread around all the workstations in the office. The build times is down by about 50 or so for the parallel parts, and 5 fold for the whole thing. (we're now down to 10 minutes, which is little enough that we're not bothering to try too hard to improve it). OTOH that code is run on embedded ARM CPUs. Middle of the range ARMs, not top end ones. So it's worth a bit of pain at build time. Andy |
| woodbrian77@gmail.com: Aug 20 08:49PM -0700 https://www.reddit.com/r/cpp/comments/98j03j/a_bug_in_the_c_standard/ Howard Hinnant replies with: A bug in the C++ standard?!!! http://www.youtube.com/watch?v=SjbPi00k_ME&t=0m10s http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html :-) ------------------------------------------------------------ SteeleDynamics replies to Howard with: Who knew constructing a logical set semantic rules would be so hard? ----------------------------------------------------------- Then I reply to SteeleDynamics with: How many committee members drink too much or use illegal drugs? I'm not advocating for drug testing, but self sabotage is probably a problem. ------------------------------------------------------------ If the need for a royal priesthood (those who are being rescued from various afflictions) wasn't clear before, I hope that will change. The standardization process hasn't been a total failure, but it hasn't gone real well either. Ebenezer Enterprises - "But you are a chosen people, a royal priesthood, a holy nation, G-d's special possession, that you may declare the praises of Him who called you out of darkness into His wonderful light." First Peter 2:9 https://github.com/Ebenezer-group/onwards |
| Melzzzzz <Melzzzzz@zzzzz.com>: Aug 21 04:02AM > declare the praises of Him who called you out of darkness into His > wonderful light." First Peter 2:9 > https://github.com/Ebenezer-group/onwards I see, you are on drugs already... -- press any key to continue or any other to quit... |
| woodbrian77@gmail.com: Aug 20 09:29PM -0700 On Monday, August 20, 2018 at 11:02:34 PM UTC-5, Melzzzzz wrote: > I see, you are on drugs already... Possibly you would say Ben Shapiro is also on drugs as he's an Orthodox Jew. But nothing could be further from the truth. He thinks that smoking pot is a sin. I used to drink too much in college, but now I only drink a little and I've never done illegal drugs. Brian Ebenezer Enterprises http://webEbenezer.net |
| Melzzzzz <Melzzzzz@zzzzz.com>: Aug 21 04:36AM > from the truth. He thinks that smoking pot is a sin. > I used to drink too much in college, but now I only > drink a little and I've never done illegal drugs. So when marijuana becames legal you will smoke? -- press any key to continue or any other to quit... |
| woodbrian77@gmail.com: Aug 20 09:48PM -0700 On Monday, August 20, 2018 at 11:37:06 PM UTC-5, Melzzzzz wrote: > So when marijuana becames legal you will smoke? If it were legal I wouldn't smoke it. It's a waste of money. |
| scott@slp53.sl.home (Scott Lurndal): Aug 21 12:55PM >On Monday, August 20, 2018 at 11:02:34 PM UTC-5, Melzzzzz wrote: >> I see, you are on drugs already... >Possibly you would say Ben Shapiro is also on drugs This has nothing to do with C++. Look up sanctimonious sometime. It's not a complimenatary descriptor. |
| woodbrian77@gmail.com: Aug 21 08:08AM -0700 On Tuesday, August 21, 2018 at 7:55:24 AM UTC-5, Scott Lurndal wrote: > >Possibly you would say Ben Shapiro is also on drugs > This has nothing to do with C++. Look up sanctimonious sometime. It's > not a complimenatary descriptor. I think we might agree that virtue is important to any endeavor. |
| scott@slp53.sl.home (Scott Lurndal): Aug 21 03:12PM >> This has nothing to do with C++. Look up sanctimonious sometime. It's >> not a complimenatary descriptor. >I think we might agree that virtue is important to any endeavor. I think we might all agree that is a non sequitor, and not relevent to C++. |
| woodbrian77@gmail.com: Aug 21 09:20AM -0700 On Tuesday, August 21, 2018 at 10:13:11 AM UTC-5, Scott Lurndal wrote: > >I think we might agree that virtue is important to any endeavor. > I think we might all agree that is a non sequitor, and not relevent > to C++. OK, so I maintain that self sabotage is a problem for people on the committee and you disagree. Brian Ebenezer Enterprises - In G-d we trust. https://github.com/Ebenezer-group/onwards |
| jameskuyper@alumni.caltech.edu: Aug 21 12:18PM -0700 > > to C++. > OK, so I maintain that self sabotage is a problem > for people on the committee and you disagree. Just to clarify - self-sabotage is a problem for any person whose activities should not be sabotaged, and he's said nothing to suggest that he disagrees with you about that. However, you're presented no reason for thinking that any such problem is relevant to C++. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment