|
Object instance is of D but object type is B.
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|
|
Because p is not a D*. It is a B*, which happens to be pointing to an instance of D. Nonetheless, the type of the pointer has not changed.
In other words, it's catching B* because that's what you're throwing. If you want it to catch D*, then you should throw D*.
e.g.: throw static_cast<D*>(p);
It's worth noting that you cannot use dynamic_cast here, because B is not considered a polymorphic type. i.e. It has no virtual functions.
|
|
|
|
|
Hi !
Here is a problem I'm not sure what would be the right way to solve it. I have a class which represents an operation and this operation has a duration. I want to be able to read the duration of the operation with the function getDuration(). As computing the duration is a long process, I don't want to do it before it is asked for, and I don't want to recompute it each time it is asked for. The code below is basically how I implemented it :
class Operation
{
public:
Operation() { m_DurationCalculated=false;} ;
~Operation();
long getDuration()
{
computeDuration();
return m_Duration;
};
private:
long m_Duration;
bool m_DurationCalculated;
void computeDuration()
{
if (!m_DurationCalculated)
{
m_Duration=;
m_DurationCalculated=true;
}
}
};
It works fine except that I want now the function getDuration() to be const, because, from an external point of view, getDuration() doesn't change the operation.
The problem, when making getDuration() const, is that it calls computeDuration(), which, I guess, should be const as well, and as m_Duration and m_DurationCalculated might be changed in a const function, I guess I have to put the mutable keyword in front of these member variables.
This is where I'm not sure : is it the correct way to solve this ? It looks strange to me that computeDuration, which really is not a const function, should be const in order to be called by the getDuration function.
What is the correct way to solve my problem ?
Thanks for your help !
Jerome
|
|
|
|
|
If you dont want to change computeDuration to constant function, you can follow this trick:
<br />
.........<br />
long getDuration() const{ <br />
((Operation*)this)->computeDuration();<br />
return m_Duration;<br />
}<br />
........<br />
|
|
|
|
|
Actually, I thought about this trick, but I would like to make sure that it is a correct way to handle this problem and I also wanted to know what would be the recommended way.
Jerome
|
|
|
|
|
Casting off the const-ness is a nasty hack. It's also undefined if the object you're casting was originally allocated as a const object.
A cleaner way to do it is to declare computeDuration as a const function, and declare m_Duration and m_DurationCalculated to be mutable (i.e. they can be modified by const functions).
e.g.
void computeDuration() const
{
// safe to modify mutable variables
}
mutable long m_Duration;
mutable bool m_DurationCalculated
|
|
|
|
|
Thanks for your answer.
I have another question regarding the constness of 'computeDuration()' : if I make it const, each function called in computeDuration would also have to be const which, in my real application would be at least 4 or 5 more functions. These functions are clearly modifying the object, but would have to be const. This seems strange to me. Is it the correct way to do it ?
Thanks !
Jerome
|
|
|
|
|
Hmm. Sounds to me like you've got a design problem. If computeDuration() is calling functions which actually modify the object, then no, it should not be declared const. That means computeDuration() is indirectly modifying the object by calling those other functions. But by the same token, getDuration() is modifying the object by calling computeDuration(), and shiuld also not be declared as const.
Anything which changes the fundamental state of the object, directly or indirectly, should not be const. If a call to getDuration() is going to change anything fundamental, it shouldn't be const at all.
If it needs to be const for some specific reason, then I'd say you probably need to restructure the code and somehow separate the call from its dependencies on the other non-const functions. Otherwise, you'll have to take the other route and cast off the const-ness of the object, but I think most programmers will agree that it's poor style to do that. (Because if the call actually changes anything, it shouldn't be declared that it doesn't.) And additionally, it's undefined behavior if this happens on an object originally allocated as const.
|
|
|
|
|
Ofcouse, you should choose the way that you think it's the best.
|
|
|
|
|
|
|
Hai,
I need to know how to insert an JPG image in the Picture control in the MFC of VC++.
If Anybody knows Kindly reply me as soon as possibly...
bsujin
|
|
|
|
|
First using IPictureDisp or GDI+ library load the Jpeg Image.
and using the Exposed Bitmap Handle by above display picture in picture Control!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
Hi all;
I have followed the instructions in MSDN for creating a bitmap button on a dialog box:
that is, I have drawn my bitmaps and named them accordingly with suffixes "U", "D", "F" and "X".
Then I have drawn my button on the dialog box, checking "Owner draw" in properties and with caption the name of the bitmaps without the above suffixes.
I have named a variable of type CBitmapButton in the dialog class and called the AutoLoad in 'OnInitDialog()' function as follows:
VERIFY(okBtn.AutoLoad(IDOK, this));
And I get an "ASSERT" error at this line:
ASSERT(FromHandlePermanent(hWndNew) == NULL);
What's the problem and what can I do?
Can somebody please help me??
_Lostris.
|
|
|
|
|
CBitmapButton can be cantankerous. You either need to call AutoLoad() before calling OnInitDialog(), or call LoadBitmaps() after calling OnInitDialog().
Have you tried Joe's button class?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I've got a situation where we are running two redundant data servers where one should take over when the other fails. Our problem is in keeping the two servers synchronized when there may a thousand updates per second, and the order in which the updates arrive is very important and messages arriving in different orders to the two servers will cause problems. It is not a standard database (it's proprietary format), and everything is stored in memory. Basically, any data loss during the failover should be kept to a minimum. Some is allowed, but there are no guidelines on this. Less is better of course...
Obviously this problem has been overcome for large databases, but my search of google for algorithms has so far been fruitless. Does anyone have any information on synchronization algorithms that may help?
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Friends i want to display a 48*48 icon on the dialog window. For this purpose i first created the desired icon, Then i placed a picture control on dialog and given it, the path to my icon. But the problem is that, the picture control shrinks my icon and unable to display it in the original size of 48*48. Can anyone tell me abt the problem here?
Imtiaz
|
|
|
|
|
specify to the ressource editor that the icon is 48x48 instead of 32x32.
do this in the combobox up to the area you edit your icon in VC++. if this doesn't apear in the choices, click the button next to it.
TOXCCT >>> GEII power
|
|
|
|
|
I have taken a CView class and ripped it apart head to toe keeping only those few things I need for dynamic creation pretty much.
Why would IMPLEMENT_DYNCREATE cause a memmory leak???
The debugger is indicating a leak and points to this line
#ifndef CREATE_STATIC
IMPLEMENT_DYNCREATE(CMyOwnViewCls, CWnd)
#endif
What a bummer 
Any ideas???
How do I print my voice mail?
|
|
|
|
|
Did you close your app prematurely?
This macro defines the function that creates the window dynamically - something like return new CMyOwnViewCls. If you don't allow the app to exit normally, the window won't be deleted and the debugger will complain that this line allocated memory that wasn't freed.
Remember that everything in the macro expands to a single line, so everything in the macro is on the same line.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Got it!!! Thanks for the help
EDIT: Weird, I just inserted a AfxMessageBox() inside OnCreate and it isn't called, so i guess my object has no connection with CView anymore and it's something else in the framework causing the TRACE to display
nope closed it normally...
For some reason, even though I stripped out all referecne to CView and replaced with CWnd....I still get an TRACE warning saying View created without a CDocument...which is weird, cua like I said my new class is small so i'm positive i'm not missing anything...and yet this TRACE is found inside CView viewcore.cpp line 99 and my class n longer derives from CView so I have no idea why CView::OnCreate is getting called... 
How do I print my voice mail?
|
|
|
|
|
Hockey wrote:
How do I print my voice mail?
no you dont print a voice mail, you rewind and replay the voice mail.;P
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|
|
Most if not all MFC classes call delete this; in the WM_NCDESTROY message handler. So if you stripped that out the actual deletion of the object will probably no longer be done. Check the MFC source for PostNCDestroy() function.
Roger Allen - Sonork 100.10016
Strong Sad: I am sad I am flying
Who is your favorite Strong?
|
|
|
|
|
I finally figured out what was causing the leak and that was it!!! It was so small I just kinda ignored it or didn't see it...
How do I print my voice mail?
|
|
|
|
|
Can anyone help me explaining what the below macro is supposed to do.
#define OFF(type, field) ((LONG)(LONG_PTR)&(((type *)0)->field))
d2hes
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
Casting tricks are not the way to solve design issues.