Monday, June 8, 2020

Digest for comp.lang.c++@googlegroups.com - 25 updates in 5 topics

Frederick Gotham <cauldwell.thomas@gmail.com>: Jun 08 06:13AM -0700

There is a class which has a Vtable containing the addresses of all the class's (and base classes's) virtual functions.
 
At any given time, there might be about a dozen instances (i.e. a dozen objects) of this class in existence, and objects are continuously being created and destroyed.
 
When a physical pin is set high (i.e. set to 3.3 volts), it will cause an interrupt to fire and so the main program will be frozen. In the interrupt routine, I want to alter one of the addresses in the class's vtable before handing control back to the main program. So from that point forward, any calls to a virtual method will call the new function whose address I have set. If the interrupt fires again in future, I will again change the vtable.
 
Anyone ever done this before?
 
Of course I will have to make sure that there isn't any optimisation where the compiler can predict which function will be called on the current object.
 
The beginning of psuedo-code would be something like:
 
extern int Some_Other_Function(int); // Defined in another file
 
void Interrupt_Routine(void)
{
MyClass obj;
 
VTable &vtable = *reinterpret_cast<Vtable*>(&obj); // std::launder?
 
vtable.SomeFunction = SomeOtherFunction;
}
 
int main(void)
{
Register_Interrupt(PIN4, Interrupt_Routine);
 
for ( ; /* ever */ ; )
{
MyClass obj;
 
obj.SomeFunction(); // Make sure compiler doesn't hardcode func address
}
}
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 08 03:35PM +0200

On 08.06.2020 15:13, Frederick Gotham wrote:
 
> There is a class which has a Vtable containing the addresses of all the class's (and base classes's) virtual functions.
 
> At any given time, there might be about a dozen instances (i.e. a dozen objects) of this class in existence, and objects are continuously being created and destroyed.
 
> When a physical pin is set high (i.e. set to 3.3 volts), it will cause an interrupt to fire and so the main program will be frozen. In the interrupt routine, I want to alter one of the addresses in the class's vtable before handing control back to the main program.
 
No. NO. NO!
 
 
> So from that point forward, any calls to a virtual method will call the new function whose address I have set. If
> the interrupt fires again in future, I will again change the vtable.
 
> Anyone ever done this before?
 
Some colleagues of mine, fresh out of school, decided to make a lot of
trouble for themselves in 1999 or thereabouts. They did the alter-vtable
thing in Visual Basic. And then came to me to ask what on Earth could be
the reason for the mysterious crashes.
 
They failed to add the lunacy of doing this in an interrupt handler.
 
But they did add another sort of same level of dumbness thing, with each
class in its own Windows DLL. They wondered why the app was so slow to load.
 
 
> Of course I will have to make sure that there isn't any optimisation
> where the compiler can predict which function will be called on the
> current object.
 
Just don't.
 
 
 
> obj.SomeFunction(); // Make sure compiler doesn't hardcode func address
> }
> }
 
Don't.
 
 
- Alf
David Brown <david.brown@hesbynett.no>: Jun 08 03:44PM +0200

On 08/06/2020 15:13, Frederick Gotham wrote:
 
> Of course I will have to make sure that there isn't any optimisation
> where the compiler can predict which function will be called on the
> current object.
 
To expand on Alf's comment - don't do it.
 
Whenever you think "I'll have to disable some optimisations for this to
work", your idea is *bad*. Lying to the compiler is not a good idea.
 
Make a single static (probably volatile) variable in the class that
tracks which function you'll want to call. Your virtual function - if
indeed it needs to be virtual - will check that variable to decide what
to do. (Prefer a check on the variable followed by a conditional or
switch to using a function pointer - it's easier to get right, and will
usually be more efficient.)
 
What made you think this could be a good idea in the first place?
"Öö Tiib" <ootiib@hot.ee>: Jun 08 07:38AM -0700

On Monday, 8 June 2020 16:13:59 UTC+3, Frederick Gotham wrote:
 
> At any given time, there might be about a dozen instances (i.e. a dozen objects) of this class in existence, and objects are continuously being created and destroyed.
 
> When a physical pin is set high (i.e. set to 3.3 volts), it will cause an interrupt to fire and so the main program will be frozen. In the interrupt routine, I want to alter one of the addresses in the class's vtable before handing control back to the main program. So from that point forward, any calls to a virtual method will call the new function whose address I have set. If the interrupt fires again in future, I will again change the vtable.
 
> Anyone ever done this before?
 
 
Why to screw with undocumented features of implementation if it
can be written in fully well-defined manner? Black magic is
generally frowned upon and often considered to be sabotage of
code base.
 
> Of course I will have to make sure that there isn't any optimisation where the compiler can predict which function will be called on the current object.
 
:D Turning off optimizations means that the trash will be
inefficient on top of being buggy.
Paavo Helde <eesnimi@osa.pri.ee>: Jun 08 06:44PM +0300

08.06.2020 16:13 Frederick Gotham kirjutas:
 
> There is a class which has a Vtable containing the addresses of all the class's (and base classes's) virtual functions.
 
> At any given time, there might be about a dozen instances (i.e. a dozen objects) of this class in existence, and objects are continuously being created and destroyed.
 
> When a physical pin is set high (i.e. set to 3.3 volts), it will cause an interrupt to fire and so the main program will be frozen. In the interrupt routine, I want to alter one of the addresses in the class's vtable
 
Do not do that, ever! This is akin to asking whether it is a good idea
to break into a transformer booth and reconnect live wires with bare hands.
 
If you want to change some state in the interrupt, store the state in a
(volatile) enum variable and change that, as suggested by others. You
can dispatch to different functions easily based on that state.
Manfred <noname@add.invalid>: Jun 08 06:29PM +0200

On 6/8/2020 3:13 PM, Frederick Gotham wrote:
 
> There is a class which has a Vtable containing the addresses of all the class's (and base classes's) virtual functions.
 
> At any given time, there might be about a dozen instances (i.e. a dozen objects) of this class in existence, and objects are continuously being created and destroyed.
 
> When a physical pin is set high (i.e. set to 3.3 volts), it will cause an interrupt to fire and so the main program will be frozen. In the interrupt routine, I want to alter one of the addresses in the class's vtable before handing control back to the main program. So from that point forward, any calls to a virtual method will call the new function whose address I have set. If the interrupt fires again in future, I will again change the vtable.
 
Despite the lack of originality, don't do that(!)
 
The main reason is that, although there possibly is a vtable in your
objects, touching anything in that area drowns in undefined behavior -
the language mandates specific rules on how to handle a pointer to an
object for this very reason.
 
If you want, by design, manipulate a function pointer, or an array
thereof, then do just that - set up your own array of function pointers,
and manipulate it according to the language rules.
However, given the possibilities of modern C++ I doubt that it is really
necessary to do even that.
The specifics of interrupt handlers apply on top of the above.
Scott Newman <scott69@gmail.com>: Jun 08 06:43PM +0200

Of course you can customize the vtable this way.
Scott Newman <scott69@gmail.com>: Jun 08 06:54PM +0200

> Of course you can customize the vtable this way.
 
It would be the best to scan the vtable linearly for a known
method-address and replace that address with the method you
like. You can simply take a function whose first parameter
will take the this pointer.
There might be implementations where this won't work, but
currently there isn't any.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 08 06:04PM +0100

On 08/06/2020 14:44, David Brown wrote:
 
> To expand on Alf's comment - don't do it.
 
> Whenever you think "I'll have to disable some optimisations for this to work", your idea is *bad*.  Lying to the compiler is not a good idea.
 
> Make a single static (probably volatile) variable in the class that tracks which function you'll want to call.  Your virtual function - if indeed it needs to be virtual - will check that variable to decide what to do.  (Prefer a check on the variable followed by a conditional or switch to using a function pointer - it's easier to get right, and will usually be more efficient.)
 
What century is this? Use std::atomic not volatile.
 
 
> What made you think this could be a good idea in the first place?
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne 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."
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 08 06:06PM +0100

On 08/06/2020 17:54, Scott Newman wrote:
> will take the this pointer.
> There might be implementations where this won't work, but
> currently there isn't any.
 
Either:
 
a) you are trolling;
 
or:
 
b) you are a fucking idiot.
 
DO NOT DO THIS -- IT IS UNDEFINED BEHAVIOUR *AT BEST*.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne 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."
Scott Newman <scott69@gmail.com>: Jun 08 07:20PM +0200

> DO NOT DO THIS -- IT IS UNDEFINED BEHAVIOUR *AT BEST*.
 
All C++-compilers handle vtables in a similar way.
If you stick to one implementation that's quite manageable.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 08 06:34PM +0100

On 08/06/2020 18:20, Scott Newman wrote:
>> DO NOT DO THIS -- IT IS UNDEFINED BEHAVIOUR *AT BEST*.
 
> All C++-compilers handle vtables in a similar way.
> If you stick to one implementation that's quite manageable.
 
Except there is no good reason to even do this; none at all.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne 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."
Manfred <noname@add.invalid>: Jun 08 07:36PM +0200

On 6/8/2020 7:04 PM, Mr Flibble wrote:
>> or switch to using a function pointer - it's easier to get right, and
>> will usually be more efficient.)
 
> What century is this? Use std::atomic not volatile.
 
Actually, an interrupt handler is exactly the purpose that volatile is
designed for: it tells the compiler that a variable may change its value
outside the flow of operation as seen by the compiler.
 
The fact that the keyword has been used in the context of multithreading
as a surrogate for atomic access is the tangent side use.
 
However, I am not totally with David Brown on preferring a conditional
to a function pointer - of course it depends on the specific case, and
it may be a matter of taste.
Scott Newman <scott69@gmail.com>: Jun 08 07:39PM +0200

>> All C++-compilers handle vtables in a similar way.
>> If you stick to one implementation that's quite manageable.
 
> Except there is no good reason to even do this; none at all.
 
In most cases you only use one compiler.
So in most cases there's not a problem with this.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 08 06:40PM +0100

On 08/06/2020 18:39, Scott Newman wrote:
 
>> Except there is no good reason to even do this; none at all.
 
> In most cases you only use one compiler.
> So in most cases there's not a problem with this.
 
So my conclusion is that you are a troll.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne 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."
Bonita Montero <Bonita.Montero@gmail.com>: Jun 08 07:40PM +0200

Use non-virtual functions which dispatch according to your
own virtual function tables.
Scott Newman <scott69@gmail.com>: Jun 08 07:41PM +0200

>> In most cases you only use one compiler.
>> So in most cases there's not a problem with this.
 
> So my conclusion is that you are a troll.
 
No, I am a practitioner while you are a theorist.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 08 06:49PM +0100

On 08/06/2020 18:36, Manfred wrote:
 
>>> Make a single static (probably volatile) variable in the class that tracks which function you'll want to call.  Your virtual function - if indeed it needs to be virtual - will check that variable to decide what to do.  (Prefer a check on the variable followed by a conditional or switch to using a function pointer - it's easier to get right, and will usually be more efficient.)
 
>> What century is this? Use std::atomic not volatile.
 
> Actually, an interrupt handler is exactly the purpose that volatile is designed for: it tells the compiler that a variable may change its value outside the flow of operation as seen by the compiler.
 
Nonsense. Disable interrupts much? std::atomic is the superior solution for ISRs these days. Stop living in the past.
 
 
> The fact that the keyword has been used in the context of multithreading as a surrogate for atomic access is the tangent side use.
 
The fact that people write shite code is orthogonal to this discussion.
 
 
> However, I am not totally with David Brown on preferring a conditional to a function pointer - of course it depends on the specific case, and it may be a matter of taste.
 
Indeed.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne 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."
David Brown <david.brown@hesbynett.no>: Jun 08 07:52PM +0200

On 08/06/2020 19:36, Manfred wrote:
 
> Actually, an interrupt handler is exactly the purpose that volatile is
> designed for: it tells the compiler that a variable may change its value
> outside the flow of operation as seen by the compiler.
 
Exactly. "Atomic" would be slightly inappropriate (though it would
probably work fine here).
 
 
> However, I am not totally with David Brown on preferring a conditional
> to a function pointer - of course it depends on the specific case, and
> it may be a matter of taste.
 
Of course it can vary by detail of the case, and personal preference.
As a general rule, I usually choose a conditional or switch rather than
a function pointer because it gives the compiler far more information
for optimisation purposes, and it makes it much easier to follow the
flow of the code when reading it, generating call graphs, etc. If your
code has no function pointers (or none of a particular type), then it's
easy to find every part of your code that calls the function "foo" - you
just search for all calls to "foo". If "foo" might have been assigned
to a function pointer, such searches are a lot more complicated.
 
It does come at the cost that it can lead to more inter-dependencies
between modules that could be avoided by function pointers and
call-backs, so there are pros and cons.
 
But since the OP is talking about interrupts, I'm assuming it will be a
low-level program and probably fairly small, so I'd start with a
variable and conditionals until convinced function pointers are better.
alelvb <alelvb@inwind.it>: Jun 08 03:33PM +0200

Il 06/06/20 17:40, Öö Tiib ha scritto:
 
> Did you ask that if we suppose that you did not make the error then
> how are we supposed to spot problem we just supposed that you did
> not introduce? It is impossible to spot errors that weren't made.
 
My sentence was written after Dash replied to my message in which
I wrote the code with the correction spot by Mr. Helde was finally
working. Dash wrote that the code still get a bad message and I thought
He did the modification But still getting the error message. Since on my
computer the code (not corrected) still worked for dimensions less than
or equal to 3 I wrote what I wrote. That's all.
 
 
> If you want to get exceptions for out-of-bounds accesses use
> vector::at; if you want to get guaranteed crashes (like Paavo
> demonstrated) use debug version of standard library.
 
made the substitution after you told me this possibility.
Thank you.
queequeg@trust.no1 (Queequeg): Jun 08 12:10PM


>> And what exactly does it have to do with C++?
 
> Fuck. Off.
 
I guess another moron has to land in a killfile.
 
--
The only valid generalization that can be made about scientists is
that they require unlimited resources for improbable projects of
interminable gestation periods.
rick.c.hodgin@gmail.com: Jun 07 07:10PM -0700

On Tuesday, April 10, 2018 at 10:34:54 AM UTC-4, Rick C. Hodgin wrote:
> possibility that God exists and created more than a mere video game
> using His ability to instantiate everything, and you do so solely
> because of sin and your love of sin ahead of truth.
 
I post this reply not for Leigh Johnston, but for other people who
would've read his posts previously and come away with the idea that
the speed of light precludes our universe being created in the literal
six-days of creation.
 
I was listening to this video today and came across this part:
 
Creation or Evolution -- Begins at 4:37:
https://www.youtube.com/watch?v=YEOxqWbeLcA&t=4m37s
 
"If the sun that God created was older, and remember that He
created full-blown reproducing things. So, He didn't create a
baby star growing up, He created a star at the right maturity."
 
This relates to the idea of how we instantiate games for game play.
We don't load things that then take thousands of light years to get
from one part of the game play field to the other. Everything's all
where it's supposed to be once the game loads.
 
When God created the universe, everything was where it was supposed
to be after He created it there. Everything was at its point and
place of maturity, of full function, of God-created ability.
 
And the fossils we find in the ground were deposited by the flood,
and not by millions of years.
 
I urge each of you to watch the DTBM channel on YouTube. You will
have the multitude of lies perpetrated by the enemy throughout your
entire lives undone one by one by one and you'll be taught the truth
of God given unto mankind for all those who will be saved.
 
To each of you: Be one who is saved. You are valuable, precious,
and I want to see you thriving in Heaven after you leave this world,
able to move and do without limitation of resources, and at the full-
est extent of your maximum abilities unencumbered by the weaknesses
inherent in our flesh here in this world. In Heaven, we're all at
the top of our game continually, because it's the realm of God, and
it's how He set it up to be.
 
The Lord Jesus Christ is ready, willing, and able RIGHT NOW to for-
give your sin. You know you have sin. You know what those sins
are. Ask Him to forgive you today and be set free from judgment and
condemnation, and begin your new life, your new journey, as one who
is redeemed by our great and precious Lord and Savior, Jesus Christ.
 
There's no shame in having rejected Him throughout your life. He
knew that would happen, and it's to be expected because of sin and
sin's influence in our lives. But do not stay in that old place.
Take a step forward to the Lord and watch Him work a miracle in your
eternal life. You'll be filled with joy to such an extent that you
did.
 
You are each valuable, amazing creations of God. Receive His free
gift of salvation today. You are not promised tomorrow. But He
does promise eternity for all who recognize their sin, repent, and
ask Him to forgive them.
 
Looking for that Fountain of Youth? Eternal life in a body with
the fullest faculty and ability? Learn about what Jesus brings
to the table. He's got game.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 08 01:09PM +0100


> Looking for that Fountain of Youth? Eternal life in a body with
> the fullest faculty and ability? Learn about what Jesus brings
> to the table. He's got game.
 
Assertions made without evidence can be dismissed without evidence. Now fuck off.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne 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."
Sam <sam@email-scan.com>: Jun 07 09:53PM -0400

Manfred writes:
 
 
> This is what GC is for: you get a reference to an object and you don't care
> about its ownership: you let the language destroy it as soon as (well, soon-
> ish) all of its references go out of scope.
 
Well, smart pointers definitely destroy the object when all references to
the object go out of scope. This seems to be perfectly compliant with this
particular definition of "garbage collection".
 
> objects is explicitly defined, and known" - great, all I'm saying is that
> this doesn't play well with your wish that "It doesn't matter" where
> ownership is assigned.
 
No, the two concepts do not conflict with each other.
 
Entity A produces a temporary object B which gives me access to object C. I
need B to access C.
 
I don't know whether C is owned by A or B. If it's owned by A, B can simply
give me a reference to C, before B vanishes in a puff of smoke. If C is
owned by B, B can return C directly, not a reference.
 
If the returned value from C is assigned to a reference, the ownership model
can be changed without changing the API. If B returns a reference it's
assigned to a reference, and that's it. If B returns an object, its lifetime
is extended to the lifetime of the reference.
 
In all cases, the lifetime of all objects is well defined, and does not
require garbage collection.
"Öö Tiib" <ootiib@hot.ee>: Jun 07 11:25PM -0700

On Monday, 8 June 2020 04:53:42 UTC+3, Sam wrote:
 
> I don't know whether C is owned by A or B. If it's owned by A, B can simply
> give me a reference to C, before B vanishes in a puff of smoke. If C is
> owned by B, B can return C directly, not a reference.
 
What is the resulting ownership? Does the entity that needs
"C" (you call it confusingly "I" and "me") have potentially shared
ownership of "C" with "A" or does it on all cases have full ownership
of passed "C"?
 
> is extended to the lifetime of the reference.
 
> In all cases, the lifetime of all objects is well defined, and does not
> require garbage collection.
 
When ownership is unclear then lifetime of objects is also unclear and
needs garbage collection. Ownership model can not be dynamic or unclear,
it has to be something. Clarity of it is better also in garbage
collected languages. It may actually be somehow clear to you but for
whatever strange reasons you refused to discuss it rudely.
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)