Monday, August 20, 2018

Digest for comp.lang.c++@googlegroups.com - 15 updates in 4 topics

legalize+jeeves@mail.xmission.com (Richard): Aug 20 04:08PM

[Please do not mail me a copy of your followup]
 
It looks like you're trying to do some sort of callback mechanism.
 
IMO, callbacks in C++ are best done without function pointers, lambdas
or std::function<>. Simply use an abstract interface that is consumed
by the notifier and implemented by the recipient. All the crazy
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).
--
"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>
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).
legalize+jeeves@mail.xmission.com (Richard): Aug 20 08:16PM

[Please do not mail me a copy of your followup]
 
Manfred <noname@add.invalid> spake the secret code
 
>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.
 
Actually COM doesn't care -- a function pointer is just a data type
and COM doesn't care about data types. It has a few well supported
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.
 
>Function objects and pointers are IMO a powerful feature of C++ which,
>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. It's been my experience that as soon as you
need one callback, you need a second one in short order. Then there's
the added annoyance that with function pointers you have to go through
hoops to get the 'this' pointer passed around properly and you end up
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. Unless
you're required to have a C style API, it's simply easier to make an
abstract interface that represents the contract for the interaction
between two objects. It's also easier to create mock objects for unit
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. An abstract
polymorphic interface could just as easily have been used. A template
policy class could just as easily have been used. They just didn't use
it because the STL algorithms originate in a functional programming style.
--
"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>
Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 20 08:50PM

On Mon, 2018-08-20, Richard wrote:
> the grammar as a result.
 
> It's been my experience that as soon as you need one callback, you
> need a second one in short order.
 
I don't agree with the rest of your argument, but with this. I think
people are sometimes so eager to use lambdas and std::function and
Boost signals, that instead of passing a pointer to some class Foo,
they pass the N functions of an implementation of Foo instead.
 
Passing more than one function at a time may be a code smell.
 
[snip]
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
scott@slp53.sl.home (Scott Lurndal): Aug 20 08:55PM


>The function pointer syntax is painful and there are some quirks in
>the grammar as a result. It's been my experience that as soon as you
>need one callback, you need a second one in short order.
 
I've used them, on occasion. One becomes accustomed to the syntax.
 
if (branch || !p_fetch_fault) {
failed = (this->*opp->op_insn)(opp);
}
 
This was in an instruction decoder dispatch loop.
 
struct p_op {
const char *op_name; // Opcode name
unsigned char op_opcode; // 2-digit numeric opcode
unsigned char op_operands; // Operand count
unsigned char op_literal:1, // A field literal allowed
op_afindirect:1, // AF indirect allowed
op_bfindirect:1, // BF indirect allowed
op_flags:1, // COM/OVF flags modified
op_bfhex:1, // Treat BF field as hex
op_noafbf:1; // No AFBF field for instruction
bool (c_processor::*op_insn)(struct _op *);
};
 
struct c_processor::p_op c_processor::p_optable[] = {
{ "NUL", OP_nul, 0, 0, 0, 0, 0, 0, 1, &c_processor::op_nul }, // 00
{ "INC", OP_INC, 2, 1, 1, 1, 1, 0, 0, &c_processor::op_inc }, // 01
{ "ADD", OP_ADD, 3, 1, 1, 1, 1, 0, 0, &c_processor::op_add }, // 02
{ "DEC", OP_DEC, 2, 1, 1, 1, 1, 0, 0, &c_processor::op_dec }, // 03
{ "SUB", OP_SUB, 3, 1, 1, 1, 1, 0, 0, &c_processor::op_sub }, // 04
{ "MPY", OP_MPY, 3, 1, 1, 1, 1, 0, 0, &c_processor::op_mpy }, // 05
{ "DIV", OP_DIV, 3, 1, 1, 1, 1, 0, 0, &c_processor::op_div }, // 06
{ "NUL", OP_nul, 0, 0, 0, 0, 0, 0, 0, &c_processor::op_nul }, // 07
{ "MVD", OP_MVD, 3, 0, 1, 1, 0, 0, 0, &c_processor::op_mvd }, // 08
{ "MVL", OP_MVL, 3, 0, 1, 1, 0, 0, 0, &c_processor::op_mvl }, // 09
{ "NUL", OP_nul, 0, 0, 0, 0, 0, 0, 1, &c_processor::op_nul }, // 0a
{ "NUL", OP_nul, 0, 0, 0, 0, 0, 0, 1, &c_processor::op_nul }, // 0b
{ "NUL", OP_nul, 0, 0, 0, 0, 0, 0, 1, &c_processor::op_nul }, // 0c
{ "NUL", OP_nul, 0, 0, 0, 0, 0, 0, 1, &c_processor::op_nul }, // 0d
{ "NUL", OP_nul, 0, 0, 0, 0, 0, 0, 1, &c_processor::op_nul }, // 0e
{ "NUL", OP_nul, 0, 0, 0, 0, 0, 0, 1, &c_processor::op_nul }, // 0f
 
{ "MVA", OP_MVA, 2, 1, 1, 1, 1, 0, 0, &c_processor::op_mva }, // 10
{ "MVN", OP_MVN, 2, 1, 1, 1, 1, 0, 0, &c_processor::op_mvn }, // 11
{ "MVW", OP_MVW, 2, 0, 1, 1, 0, 0, 0, &c_processor::op_mvw }, // 12
{ "MVC", OP_MVC, 2, 0, 1, 1, 0, 0, 0, &c_processor::op_mvc }, // 13
{ "MVR", OP_MVR, 2, 1, 1, 1, 0, 0, 0, &c_processor::op_mvr }, // 14
{ "TRN", OP_TRN, 3, 0, 1 ,1 ,0, 0, 0, &c_processor::op_trn }, // 15
{ "SDE", OP_SDE, 2, 1, 1, 1, 1, 0, 0, &c_processor::op_sde }, // 16
{ "SDU", OP_SDU, 2, 1, 1, 1, 1, 0, 0, &c_processor::op_sde }, // 17
{ "SZE", OP_SZE, 2, 1, 1, 1, 1, 0, 0, &c_processor::op_sze }, // 18
{ "SZU", OP_SZU, 2, 1, 1, 1, 1, 0, 0, &c_processor::op_sze }, // 19
{ "NUL", OP_nul, 0, 0, 0, 0, 0, 0, 1, &c_processor::op_nul }, // 1a
{ "NUL", OP_nul, 0, 0, 0, 0, 0, 0, 1, &c_processor::op_nul }, // 1b
{ "NUL", OP_nul, 0, 0, 0, 0, 0, 0, 1, &c_processor::op_nul }, // 1c
{ "NUL", OP_nul, 0, 0, 0, 0, 0, 0, 1, &c_processor::op_nul }, // 1d
 
...
Thiago Adams <thiago.adams@gmail.com>: Aug 20 02:03PM -0700

On Monday, August 20, 2018 at 5:16:24 PM UTC-3, Richard wrote:
> abstract interface that represents the contract for the interaction
> between two objects. It's also easier to create mock objects for unit
> testing if you follow this strategy.
 
I miss lambdas in C. Even lambdas without capture would
be useful for me.
 
Generally I can represent everything I need using C basic
concepts like structs and functions.
 
But when I need lambdas the sparse representation
in C using structs and functions makes the code much harder
do read and maintain.
 
For instance
 
void Run(void (*callback)(void*), void* data);
 
void F()
{
Run([](void* data){

printf("first");
Run([](void* data){
printf("second");
}, 0);
}, 0);
}
 
Everything is inside F with small scopes.
In case I remove F everything is removed as it should be.
 
 
Comparing with sparse C solution:
 
 
void Run(void (*callback)(void*), void* data);
 
static void _lambda_1(void* data){
printf("second");
}
 
static void _lambda_0(void* data){

printf("first");
Run(_lambda_1, 0);
}
 
void F()
{
Run(_lambda_0, 0);
}
 
 
Now, to delete F, we need to delete _lambda_0 and
_lambda_1, so it is much harder do read and maintain.
The types involved are not in one place with one small
scope. This is much worst with capture.
 
COM interfaces are also much hard do create and maintain
compared with lambdas.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 20 11:17PM +0100

On 20/08/2018 17:08, Richard 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 use COM-like interfaces in my plugin system however I disagree that
abstract interfaces are the "best" way to perform callbacks: they are
but one tool in the toolbox. Signals and slots or more recently signals
and lambdas are just as important a tool as abstract interfaces: they
tend to be more flexible especially when type erasure or generic
algorithms are involved. Forcing a user to create a class that inherits
from an interface just to be notified that the text has changed in a
widget is finicky at best and egregious at worst.
 
Today OOP is not the only way to design software (e.g data oriented ECS
systems) and abstract interfaces are tied to an arguably old fashioned
object oriented way of doing things.
 
In saying all that however "neoGFX" my upcoming C++ GUI library and game
engine uses abstract interfaces extensively (mainly in the widget
library) but it also uses other more modern methods too.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
gazelle@shell.xmission.com (Kenny McCormack): Aug 20 11:36AM

In article <c9adndzDjq80OuXHnZ2dnUU7-eGdnZ2d@giganews.com>,
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:
...
>You don't care about people at all; all you care about is satisfying
>your bloated self-righteous ego.
 
You say tomato, I say tomahto...
 
--
A pervert, a racist, and a con man walk into a bar...
 
Bartender says, "What will you have, Donald!"
gazelle@shell.xmission.com (Kenny McCormack): Aug 20 07:13AM

In article <744af2f3-2714-4078-9cf9-f7dd913198f8@googlegroups.com>,
 
>I, the real Rick C. Hodgin, did not write this. An identity
>thief has posted under my identity.
 
>I apologize for any confusion the thief has caused.
 
You do realize, don't you, that the so-called "impostors" write better and
more eloquently than you? When I read their stuff (that you claim was not
written by you), my opinion of "Rick C. Hodgin" goes up.
 
When I read your stuff (that you claim as your own), my opinion of "Rick
C. Hodgin" goes down.
 
P.S. I'm reasonably sure at this point, that the "Rick C. Hodgin" troll
entity (*) is being run by a group of people. No way a single person could
write all that is written under the name.
 
(*) I.e., the one that claims to be the one and only RCH.
 
--
To my knowledge, Jacob Navia is not a Christian.
 
- Rick C Hodgin -
gazelle@shell.xmission.com (Kenny McCormack): Aug 20 01:46AM

In article <p7q01u$fmf$2@dont-email.me>,
 
>> There have been five distinct ages of man:
>[...]
 
>I asked you a simple question, and got nothing.
 
Which is all you'll ever get from Ricky.
 
--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Security
gazelle@shell.xmission.com (Kenny McCormack): Aug 20 01:56AM

In article <0d24a7f4-4e89-4f3d-b739-01f978d9515f@googlegroups.com>,
 
>https://en.wikipedia.org/wiki/Young_Earth_creationism
 
>I think I'll go with the 99.9 percent of scientists and most modern
>theologians that dismiss Young Earth creationism :-)
 
Speaking of disagreeing with 99.9% of scientists, has Rick ever revealed
his position on global warming/climate change?
 
Given that it is Rick's mission to be wrong about absolutely everything, I
would assume he is a climate change denier.
 
Probably a Holocaust denier, too. Given that virulent anti-semitism is
rarely buried too far below the surface in most Christian fanatics.
 
--
 
"If God wanted us to believe in him, he'd exist."
 
(Linda Smith on "10 Funniest Londoners", TimeOut, 23rd June, 2005.)
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 19 11:03PM -0400

On 08/19/2018 09:56 PM, Kenny McCormack wrote:
> On Sunday, March 11, 2018...
 
Are you just ... what? ... trolling, Kenny?
 
I've told you the truth about sin, salvation, Hell, and Jesus.
And I'll answer any questions you have, but only if you are
seeking to learn the truth. I won't be responding to you just
to be the subject of your mockery.
 
You are in my prayers, Kenny, as are many others.
 
--
Rick C. Hodgin
gazelle@shell.xmission.com (Kenny McCormack): Aug 20 03:15AM

In article <pldb2o$h6s$1@dont-email.me>,
>On 08/19/2018 09:56 PM, Kenny McCormack wrote:
>> On Sunday, March 11, 2018...
 
>Are you just ... what? ... trolling, Kenny?
 
No, just got around to reading this old thread now.
 
>seeking to hear more bullshit. I won't be responding to you just
>to be the subject of your mockery.
 
>You are in my prayers, Kenny, as are many others.
 
As we always say to telemarketers and other phone spammers:
 
Please remove us from your calling list(s).
 
They are legally required to comply with this request. Whether they
actually do so or not is anyone's guess.
 
Anyway, you will kindly remove me from your spamming^Wprayers list.
Thank you.
 
--
The Trump playbook. Every action by Trump or his supporters can be categorized as
one (or more) of:
outrageous, incompetent, or mentally ill.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 19 11:32PM -0400

On 08/19/2018 11:15 PM, Kenny McCormack wrote:
> Anyway, you will kindly remove me from your prayers list.
> Thank you.
 
As you wish, Kenny.
 
Remember this day.
 
--
Rick C. Hodgin
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)