|
True enough. But her main problem is that for whatever reason, good or bad, the derived classes shouldn't be able to see the private parts of the base class. Seems like a poor design to me but then it's not really clear why the requirement. Might just be a matter of documenting it so future developers know the runs on how to use the class and why. That stuff most developers never do.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
Tim Craig wrote: But her main problem is that for whatever reason, good or bad, the derived classes shouldn't be able to see the private parts of the base class. Seems like a poor design to me but then it's not really clear why the requirement.
That requirement happens quite often for classes that deal with hardware. The base class implements the hardware interaction and the derived classes add all the validation / formatting / UI error handling / data processing on top of the hardware interaction. It's a hierarchy of adding functionality as you derive.
Think of the base class as an engine and the derived class as a car. The car must contain the functionality of the engine but it doesn't need access to the firing rate of the spark plugs and the gas flow regulator. It just needs a function that says SetOutputPower. Each different car will use the same engine.
I write lots of code that talks to hardware and usually, I don't have this problem. This situation is slightly different because of the way the interaction through the OS happens for this given piece of hardware. A solution is easy -- move those base-class members that the OS-triggered callbacks touch into module-level static variables (outside the base class) in the source file with the base class. I was seeing if there was a way to avoid this since it messes up the data encapsulation of the base class.
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
I've dealt with a lot of hardware, too. Primarily instrumentation and now robots, that's why I suggested the "has-a", or maybe in this case "uses-a" or "controls-a", relationship with your hardware class. Instead of inheriting from the hardware, the more abstract class simply contains an instance of hardware class or a pointer to "the" instance depending on whether you allow more than one instance of the hardware to exist at a time. This way it only can use the public interface you provide yet still. It isn't a hardware abstraction class but a hardware control class.
In your car class, the car isn't really an engine, it's a collection of parts of which the engine is simply one. The car "has-a" engine. Maybe one of the more important parts but just a part like wheels, tires, windows. In your model the driver would inherit from car while in mine the driver becomes the car controller. The driver doesn't have to know or access all the nitty gritty details of how a car works (that make us MEs drool) but just understand the interface to drive it. Just like the car itself doesn't have to know what kind of engine it has, just the interface to the throttle, fuel system, etc, to get it running and control it.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
We're taking a different philosophical approach (a pointer to a class versus deriving from a class) to the same domain but it still won't work. Or I can't find a way to finesse the compiler to make it work which is why I asked the question in the first place. Whether the "derived" class inherits from the base class (my way) or is its own class with a pointer to the "base" class (your way), the problem will always exist if I try to put the data items that are modified by the OS callbacks in the "base" class. In order for the callbacks to access the data items in the class, the data must be public. Data hiding dictates that the items are not public since no user / derivative of the class should manipulate them. Hence the conflict.
I've worked around it be making the items static at the module-level in the compilation unit that contains only the "base" class. As I said, I wasn't expecting a solution, but I asked just in case I had missed something.
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
Hi all,
please help,
i have got this error.
when i compile the program.
so i m not able to run my application.
when i want to open resources from resource view it display the message
"A resource in this file uses an unknown language: English(U.S.)(unknown sub-lang:0X10).Unable to open this."
so i m not able to open resource file.
please help me for this.
and provide me any solution to run my application and open resource file.
thanks.
|
|
|
|
|
It looks like you created this file using some other editor, and you used some text encoding that the editor you are using now cannot understand. You need to open it in your previously used editor and clean up the offending text to solve the problem.
|
|
|
|
|
Did you manually edited the resource file? or you may have copied the string tables to use other languages.
HTH
A
|
|
|
|
|
|
transoft wrote: Can .Net wrappers be used as COM? If yes, how to do it?
We have a forum for COM and another for .NET related queries. This is the C++ forum.
PS: You have very little scope of getting an answer there too, because your query is vague. You might want to read up on COM Interop though...
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
|
transoft wrote: I think my query is very clear.
You sure can have your opinion, but you'll know if the community thinks your query is clear when they balance out your 1 votes on my posts.
Not to mention you posted a COM question on the C++ forum.
transoft wrote: Just because you don't know it?
I mentioned COM Interop in my previous post. Did you even bother reading up on that, instead making of affronting comments?
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Rajesh R Subramanian wrote: You sure can have your opinion, but you'll know if the community thinks your query is clear when they balance out your 1 votes on my posts.
I think this is very rude and uncalled for.
M.
This signature was proudly tested on animals.
|
|
|
|
|
You did not have a chance to read his entire post, did you?
Maximilien wrote: I think this is very rude and uncalled for.
You know what is rude? Posting a completely vague query on a wrong forum, and insulting someone who tells you to post it in the correct forum (that, I told along with a suggestion on what should he start reading up on) is rude.
I only said that if everyone else agrees with me, they'll balance out his unjustified low-votes. I don't see how was that rude, but if that's rude, so be it. I'm done with this thread.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Hi
I know when you create a object
on the stack e.g CDialog mydailog
whitin a method of another Dialog
and method ends the object you created
whitin it is destroyed
However what if you create the object
on the heap e.g. Via new operator
would the object remain
I guess you create a thread via
AFXbeginthread it rerun a pointer
to a CWinThread and I have noticed that
after the object which created it end
the thread is stil around
|
|
|
|
|
AFXbeginthread creates an object on the heap.
so what is the question ?
This signature was proudly tested on animals.
|
|
|
|
|
So when the function that creates it goes
the Thread still exists
|
|
|
|
|
Yes, if you create an object on the heap, it will remain until you clear it off manually (I mean - by using delete if created with new or with fr ee if created with malloc ).
ForNow wrote: I guess you create a thread via AFXbeginthread it rerun a pointer to a CWinThread and I have noticed that after the object which created it end the thread is stil around
No, after the thread function returns, the CWinThread object delete s itself (unless you manually set the m_bAutoDelete to false ).
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Rajesh R Subramanian wrote: Yes, if you create an object on the heap, it will remain until you clear it off manually (I mean - by using delete if created with new or with free if created with malloc).
An addendum, if I may...
If you create an object on the heap, it'll remain there until you clean it up... or the process under which it was allocated is terminated, at which point it'll be cleaned up by the OS.
The critical point to understand is this. If you allocate memory once in the course of your program and don't delete (or free, whichever is appropriate) it, it's not a big deal - the OS will clean it up. You get into trouble when you allocate blocks repeatedly and don't free (or delete) them. It's true that the OS will still clean it all up when the process terminates, but the longer the process runs the more memory it 'leaks', with detrimental effect on the whole system for the duration of the process' lifetime. This is why it's considered to be good form to always free any memory you've allocated.
L u n a t i c F r i n g e
|
|
|
|
|
LunaticFringe wrote: at which point it'll be cleaned up by the OS.
I had kept that off deliberately in order for the OP to come up with a query of "What happens if I do not clean it up?". Also, it would do good go the OP if you replied to his query directly (because he will receive an email notification - now, I've received it).
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Rajesh R Subramanian wrote: I had kept that off deliberately in order for the OP to come up with a query of "What happens if I do not clean it up?".
Sorry I messed up your subtle plotting.
Rajesh R Subramanian wrote: Also, it would do good go the OP if you replied to his query directly (because he will receive an email notification - now, I've received it).
Meh. My reponse was meant to be an addendum to your response - it's at the right place in the thread as far as I'm concerned. If the OP turns out to be too lazy to read the thread he started, I'm not going to lose sleep over it.
L u n a t i c F r i n g e
|
|
|
|
|
Well, usually a new heap creation should be ended with a free , delete and/or other "destructions" to avoid overflow or undesired remanence. Specially with pointers.
Regards.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.
modified on Tuesday, December 22, 2009 2:04 PM
|
|
|
|
|
Nelek wrote: Well, usually a new creation should be ended with a free, delete and/or other "destructions" to avoid overflow or undesired remanence.
Well, except for the fact that memory allocated with new should be cleaned up with delete , and NOT with free ...
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Right. Instead of "new" should be "heap". My bad
Regards.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Hehe. But I am not going to miss a good chance to nitpick.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
I am launching a worker thread . Inside the thread function i open CDialog's using DoModal().There is no problem in the first launch of the thread.
But in second launch the stack seems to get corrupted, the CString member variable of the Dialogs show values like "C4".. "D5" etc before even they r initialized in the Dialogs contructor(i.e when the execution is within the constructor).Even after Initializing the dialog's CString variables in constructor the variables do not get initialized, they still show "C4" etc
psuedo code below:
line 1:CWelcomeDlg dlg;
line 2:dlg.SetTitle(strDialogTitle);//Set the dialog Title
line 3 :ret = dlg.DoModal();//show dialog
//Constructor
CWelcomeDlg::CWelcomeDlg(CWnd* pParent /*=NULL*/)
: CDialog(CWelcomeDlg::IDD, pParent)
{
m_strData1=_T("");---->m_strData1 shows value "C4" and cannot b initialized to empty string.
m_strData2=_T("");--->m_strData1 shows value "C4"
m_strData3=_T("");--->m_strData1 shows value "C4"
}
|
|
|
|