locoDog
Thanks, wouldn't char parStatus[2048]; hold it on the stack?
std::format I'll look into, stringstream was taught to me very early. I learn bits of the std library from time to time when I get sick of reinventing the wheel with primitives, I never got there with stringstream because it was pretty straight forward.
**EDIT** std::format, just as easy, I just need to use it 50 times and I might remember it.
std::format I'll look into, stringstream was taught to me very early. I learn bits of the std library from time to time when I get sick of reinventing the wheel with primitives, I never got there with stringstream because it was pretty straight forward.
**EDIT** std::format, just as easy, I just need to use it 50 times and I might remember it.
Posted Wed 13 Dec 23 @ 7:03 pm
Adion
When using char parStatus[2048]; it just means that it's part of CMyPlugin8 storage.
It then depends on how the memory for CMyPlugin8 is created on where that is stored.
If you would create the plugin in a function like:
Then it would indeed be on the stack, and that would indeed be problematic if it's big.
But myPlugin can also be created on the heap, like CMyPlugin8 *myPlugin = new CMyPlugin8() in which case that is no concern.
There's 2 reasons you can know CMyPlugin8 is created like that.
-A plugin object needs to exist for a long time, so unless a new thread is created with its own stack just to hold the stack object alive, it would have to be stored on the heap
-VirtualDJ doesn't even know the specifics of CMyPlugin8, all it knows is that there is a function DllGetClassObject that can be used to create the plugin. And it turns out that that function is completely in your control, and indeed creates the CMyPlugin8 on the heap :)
It then depends on how the memory for CMyPlugin8 is created on where that is stored.
If you would create the plugin in a function like:
void myfunction()
{
CMyPlugin8 myPlugin;
}
Then it would indeed be on the stack, and that would indeed be problematic if it's big.
But myPlugin can also be created on the heap, like CMyPlugin8 *myPlugin = new CMyPlugin8() in which case that is no concern.
There's 2 reasons you can know CMyPlugin8 is created like that.
-A plugin object needs to exist for a long time, so unless a new thread is created with its own stack just to hold the stack object alive, it would have to be stored on the heap
-VirtualDJ doesn't even know the specifics of CMyPlugin8, all it knows is that there is a function DllGetClassObject that can be used to create the plugin. And it turns out that that function is completely in your control, and indeed creates the CMyPlugin8 on the heap :)
Posted Thu 14 Dec 23 @ 6:36 am
locoDog
Ahh ok, makes sense, all the tutorials I dip in & out of are general stand alone things, I never considered the implications of it being called by another program.
thanks
One final question; How would a mac user bypass the security hand holding employed for unregistered programs?
$100 (or whatever apple charge now) isn't much but I'm still completely against it on principle. [ It's like something out of UBIK, if you know Philip K Dick Sc-Fi ]
thanks
One final question; How would a mac user bypass the security hand holding employed for unregistered programs?
$100 (or whatever apple charge now) isn't much but I'm still completely against it on principle. [ It's like something out of UBIK, if you know Philip K Dick Sc-Fi ]
Posted Thu 14 Dec 23 @ 7:05 am
Adion
I don't think there's a way to really disable the mac security, so if you want to create programs/plugins for other people you most likely will need to join the apple developer program yes.
Posted Thu 14 Dec 23 @ 7:19 am
I'm glad to hear that the potential stack overflow issue isn't a concern with the way CMyPlugin8 is created on the heap.
Posted Tue 06 Feb 24 @ 1:45 pm