|
No worries just remember classes always push a self pointer down to the call stack before any call to a function.
That is something a static function pointer can not do and why it needs special syntax.
If you just think of a class as a glorified C struct that can hold code as well as data and you will have an exact
understanding of what is happening. The code block in two instances of the class run exactly the same code the
only thing that changes is the code pulls back different self pointers which where pushed down to make the call.
So the same code on different class instances changes data in two different memory blocks because "self" changed.
In vino veritas
|
|
|
|
|
Leon,
I did check couple of "assigning pointers to class functions" articles.
I'll need some time to digest it. Pretty strange syntax.
I can see how "function to function" works, my problem is the way the original code was I have to eventually pass the pointer to struct and now it is in "standard" function pointer format ()(*)() . So I can either add a new member into the control struct ( it passes it to the ISR) or figure out how to convert the "member pointer" to it, if there is a need to do that.
So I really need to study this first.
Still makes me wonder why I picked such obscure "feature". Oh well.
Cheers
Vaclav
|
|
|
|
|
So if that is the case you have a structural problem in how you organized code. However don't panic first get the
code running and the easy way to do that is pass the whole class in to functions as a pointer .. it's only 4 bytes.
You can pass the class pointer freely into another class lets say USBD needs HCD
void USBD:: SomeFuncThatNeedsHCD (HCD* hcd){
hcd->SomeHCDFunction();
}
or you can pass it to a static code block, lets say some static block needs HCD access
static void SomeStaticCodeWhoAccessHCD (HCD* hcd){
hcd->SomeHCDFunction();
}
As I said it's a symptom of a structural problem but a class is nothing more than a fancy struct it is
legal to pass the class around as a pointer just like you did the original struct ... We just frown on it 
Yes you can even pass the class pointer to an interrupt just make sure it is valid before the ISR uses.
That usually means set it to NULL and the ISR checks for a non NULL value before it uses.
In vino veritas
|
|
|
|
|
Just an update.
After all this messing around, I came to realize it all boils down to "plain" function pointer usage.
I need to pay more attention to hardware instead of software.
I essentially have two processes - one runs the video display and the other collects the video data using hardware interrupt.
And there is the culprit - the hardware interrupts fires via single function pointer, and nothing but function pointer. No members function pointers, no class to class access via pointers - its all pretty much "down the hill" after the type of interrupt is determined.
But I have learn few things and that is much appreciated.
Thanks
|
|
|
|
|
Yes but that is easy to deal with fire the interrupt to a static function then kick it to the object. That solution is trivial.
PSOMECLASS* TheClassObject = NULL;
static void InterruptComesInHere (void){
if (TheClassObject) {
TheClassObject->CallSomeMethod();
}
}
All you have to do once you have your object initialized ready to receive is set the pointer to the created object using the & symbol.
I would disable interrupts while you do the pointer set
All it really does is makes the interrupt a couple of cycles slower. The harder part by far is dealing with the interupts in
windows which is nowhere near as easy as DOS.
I assume this is a windows app and I wonder have you got the interrupt working because that isn't easy on windows 7,8 & 10
Windows uses hardware interrupts internally and does not let applications mess with them. You need to create a write a kernel-mode driver for that which is not trivial.
To be honest in Windows at your level it would be easier to simply create a thread and poll the hardware for data and get rid of the interrupt all together.
If you are trying to do this sort of thing commercially you are better off porting the IO onto a USB because they have raw block transfer mechanisms and the USB interface can be bought off the shelf. If you look up EasyCap for example which sells for about $10-$15 will drag normal S video into windows via the USB using exactly that trick.
In vino veritas
modified 19-Oct-16 14:02pm.
|
|
|
|
|
Hi,
I developed a software presentation. I wanted to distribute it using cd's & dvd's.
But, the problem is piracy.
so, i wanted to know the different kinds of ways to provide security to my software.(presentation).
Please . Help me. i need a solution.
Thankyou
|
|
|
|
|
|
You first need to be absolutely sure the thing is worth the effort to protect because any protection scheme software or hardware has a cost and it isn't cheap.
Even just putting a software decrypt key that gets stored in the registry or a hidden file means you have a way to produce the keys in some sort of program. That means time and effort to develop the key release program and then physically handle requests by people for a key. It's all cost.
The physical hardware key solution suggested is not cheap either and not much more difficult to break than a software key. I can de-hasp a program in about 30min because it's dead easy to intercept the communication with the hasp plug with a special driver. Many of the pirates you refer too will be able to do the same.
Often you are better off just leaving a nag screen in for products that are low dollar and try and guilt the users into purchase.
There are two alternative marketing tricks
1.) Make the thing so big with graphics and the like that you need multiple DVD roms to distribute and makes torrenting the thing awkward. It becomes such a pain people just go and buy the disk it isn't worth the effort to pirate.
2.) Keep putting out frequent updates even if small, it keeps the pirates disinterested in it.
So are you sure the product is worth the effort?
In vino veritas
|
|
|
|
|
<b>Never mind, instead of trying to find the bug in my code I am going to rebuild the classes,
they need clean-up anyway.</b>
I have , so far , two relatively similar classes dealing with embedded processor hardware.
Here is a code snippet,
....
class IDE_USBD;
class IDE_HCD;
class IDE_ILI9341
{
public:
class IDE_HCD hcd;
class IDE_USBD usbd();
....
If I do not include parenthesizes in implementation of class IDE_USBD I get this error
IDE_ILI9341.h:371: error: field 'usbd' has incomplete type
class IDE_USBD usbd;
^
exit status 1
field 'usbd' has incomplete type
If I add them to class IDE_HCD hcd(); than I get this error:
gpf_isr = hcd.UOTGHS_Handler;
^
IDE_ILI9341.h:2351: error: '((IDE_ILI9341*)this)->IDE_ILI9341::hcd' does not have class type
hcd.HCD_Init();
^
exit status 1
'((IDE_ILI9341*)this)->IDE_ILI9341::hcd' does not have class type
Both classes have #include files before the IDE_ILI9341 gets implemented , I checked that.
Now adding or removing parentheses makes it work, it ain't broke , but why are the parenthesizes needed for IDE_USBD?
BTW that class has only default constructor implemented at this time.
Help solving this puzzle will be appreciated.
Cheers
Vaclav
-- modified 12-Oct-16 23:13pm.
|
|
|
|
|
First you don't put the word "class" in front when using a class, the compiler already knows what IDE_USBD & IDE_HCD are.
However the main problem is you can't forward declare a class and use it as a member
If you don't know these are forward declarations .. you are telling compiler you have a class IDE_USBD & IDE_HCD
class IDE_USBD;
class IDE_HCD;
The problem is it doesn't tell the compiler how big they are and so it can't size them to use as a member. So you need
at least the class data and prototypes to be above where you try and include them into another class
class IDE_USBD {
public:
int Hello(void);
};
class IDE_HCD {
};
class IDE_ILI9341
{
public:
IDE_HCD hcd;
IDE_USBD usbd;
};
int IDE_USBD::Hello(void) {
}
Now the second option is close to your original but it has advantages and disadvantages you need to weight up.
That is turn the entries to pointers to the classes. The compiler will be happy because it knows the size of a
pointer.
class IDE_USBD;
class IDE_HCD;
class IDE_ILI9341
{
public:
IDE_HCD* hcd;
IDE_USBD* usbd;
};
class IDE_USB {
};
class IDE_HCD {
};
The advantages are you can have the classes in whatever order you want. You can change the
class objects on the fly if you need or not even create instances of them if not required.
So you get a fair amount of flexibility.
The downside is you have to call the class functions by pointer hcd->function(blah blah)
from within your class. That makes the code ever so fractionally slower than the other.
We aren't talking very much and the flexibility sometimes makes it very attractive.
The big thing in this form is that class IDE_USB and IDE_USBD will not auto create (its
only a pointer after all). You need to make sure you manually create an instance of the
classes to the pointer in your constructor of IDE_ILI9341. So your constructor must contain
the two lines to actually create the classes to the pointers
hcd = new IDE_HCD ( );
usbd = new IDE_USB ( );
You should also dispose of them in IDE_ILI9341 destructor. As the construction used new it
becomes your responsibility to destroy them as they have no scope to auto dispose.
In vino veritas
modified 13-Oct-16 0:29am.
|
|
|
|
|
The reason for the different error messages when you have parentheses or not are down to what you are declaring (I've removed the "class" from in front of hcd and usbd to leave the relevant parts):
class IDE_USBD;
class IDE_HCD;
class IDE_ILI9341
{
public:
IDE_HCD hcd;
IDE_USBD usbd();
...
Here hcd doesn't have parentheses, so it is a member variable. The compiler needs to know the size of the IDE_HDC class to store the variable in the IDE_ILI9341 class, which is why you get the "incomplete type" error.
The usbd declaration does have parentheses, so it is a member function returning an instance of the IDE_USBD class. The compiler doesn't need to know the size of the IDE_USBD class in this case because it doesn't affect the amount of space taken up in the class by usbd. You will run into problems later when you try to use usbd as a variable though (because it isn't one).
|
|
|
|
|
Hi,
I am developing an app for mobile using C++, I am calling DownloadManager from Homectrl.CPP, Then came to my mind, which will one will efficient and object will be nullified.
What is the exact difference between
DownloadManager objDownloadManager;
and
DownloadManager *objDownloadManager;
Which one will be used?
Some good insight will be appreciated.
|
|
|
|
|
It makes no difference whether you are dealing with an object or a standard item like an int, float or double.
This form you have created the item type ... these all do the same
int i;
double d;
DownloadManager objDownloadManager;
This form you have created a POINTER TO THE ITEM ... it's most likely just 4 bytes (assuming 32bit compilation).
As we haven't set them to anything they are effectively undefined and could be pointing anywhere.
int* i;
double* d;
DownloadManager* objDownloadManager;
So they are vastly different and not something you should ever be confused about .. NOT EVER.
So if you like the second form is like the address to your house, the first form is your ACTUAL PHYSICAL house.
What you are doing is telling me that if I write text for the address of a house I can live in the text because
it's the same thing as a physical house and it's confusing to you.
You use the pointer form for the same reason you use a written address for you house. Its a bit tiresome and hard
to carry the whole house around just so people can send you mail. The alternative reason might be because your
house hasn't yet been built to carry around
In vino veritas
modified 11-Oct-16 11:56am.
|
|
|
|
|
|
Hi,
Some practical thinking:
Case 1. You declare 'DownloadManager' as a member of another class:
The object declaration (DownloadManager objDownloadManager) means, objDownloadManager has the same life time of your parent (the class in which you have declared it) class. But, pointer member means objDownloadManager will live even if his parent die.
Case 2. You declare 'DownloadManager' in a function:
The object gets destructed just after function scope. But the pointer declaration, can live until you delete it either inside or outside the function scope (provided you keep the address).
Thats all I know.
|
|
|
|
|
|
One other point to remember - if you declare a pointer to the object (the second declaration), you need to explicitly call the constructor and destructor. When declaring it as an instance (first declaration), the constructor is called automatically at the point of the declaration, and the destructor is called when it goes out of scope.
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
|
i am a C++ student and i was reading some source code and found this :
void FGAPIENTRY glutMenuStateFunc( FGCBMenuState callback )
{
FREEGLUT_EXIT_IF_NOT_INITIALISED ( "glutMenuStateFunc" );
fgState.MenuStateCallback = callback;
}
in the code above , the return type is void and the function name is glutMenuStateFunc() .. what does FGAPIENTRY stand for and where dois it come from?? I've also seen some similar stuff wile reading a tutorial in win32 api
|
|
|
|
|
FGAPIENTRY is defined somewhere in your header chain (you have to look there to find it) as an attribute of the function.
On Windows code a similar define is often used to add dllexport/dllimport attribute to the same function, depending on the kind of build you are performing (the DLL itself or the application using the same DLL). See, for instance c++ - Macro for dllexport/dllimport switch - Stack Overflow[^].
|
|
|
|
|
The FGAPIENTRY prefix is a macro that declares the calling convention for the generated code. It is similar to the WINAPI macro as described in Windows Data Types (Windows)[^].
|
|
|
|
|
Ratul Thakur wrote: ...what does FGAPIENTRY stand for...
Look in your project's header files. It resolves to this.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Here is the error from compiler I need assistance with deciphering.
I did try different type in the pointer declaration and it did just generated different errors.
I tried without specifying parameters - no char * - and obviously got different errors .
After removing the parameters from Process_INHERITANCE_A( Text); I got same error.
Help would be appreciated.
Thanks
Inheritance_A.h:27: error: void value not ignored as it ought to be
FunctionPointer_B = Process_INHERITANCE_A( Text);
Here is the stripped down code
void (*FunctionPointer_B)(char *);
class INHERITANCE_A : public INHERITANCE_B , public INHERITANCE_C
{
public:
void Process_INHERITANCE_A(char *Text);
};
bool INHERITANCE_A::TestFunctionPointer(char*Text)
{
FunctionPointer_B = Process_INHERITANCE_A( Text);
This is the only offending code line
return true;
}
void INHERITANCE_A::Process_INHERITANCE_A(char *Text)
{
}
^
|
|
|
|
|
You need to add the class declaration to the definition of the pointer, or make the function static.
See https://isocpp.org/wiki/faq/pointers-to-members[^].
[edit]
FunctionPointer_B = &INHERITANCE_A::Process_INHERITANCE_A;
FunctionPointer_B(Text);
modified 10-Oct-16 5:01am.
|
|
|
|
|
Richard,
setting the class function to static breaks calls from class A to class D , no biggie.
I need to fix this pointer first.
Adding class name to the funtion I wnat to point too got me this error:
cannot convert 'INHERITANCE_A::Process_INHERITANCE_A' from type 'void (INHERITANCE_A: ()' to type 'void (*)()'
Removing the function parameter - char* - created this error . I interpter iot as missing char.
// bool (*FunctionPointer_A)(void);
FunctionPointer_B = &INHERITANCE_A::Process_INHERITANCE_A; // (Text);
ketch/Inheritance_A.h: In static member function 'static bool INHERITANCE_A::TestFunctionPointer(char*)':
Inheritance_A.h:27: error: invalid conversion from 'void (*)(char*)' to 'void (*)()' [-fpermissive]
FunctionPointer_B = &INHERITANCE_A::Process_INHERITANCE_A; // (Text);
^
This is getting frustrating , but still this is only a test.
I am hoping to be able to have access from one class in inheritance chain to another member of the inheritance chain.
I do not like this dependencies / calls between the classes in the inheritance chain , but I kinda of inherited that. No pun intended.
I got it working going down the chain, now I need to go up the chain and hoping class pointers will work.
Sorry for this mess.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
