|
In iostream library, <xstring> is the internal header file of <string>. But there is not #include <xstring> in file <string>. How do they build up the relationship??
Maxwell Chen
|
|
|
|
|
Maxwell Chen wrote: In iostream library, <xstring> is the internal header file of <string>
How the above comes out (i.e I never heard before, please explain)?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
CPallini wrote: How the above comes out (i.e I never heard before, please explain)?
#include <string>
std::string str;
By right-clicking std::string and choosing [Go to definition], VC++2005 leads you to file <string>. And then by right-clicking basic_string and [Go to definition], you are lead to file <xstring>. In the beginning of <xstring>, it states that it is the internal header file of <string>.
(I am at home and do not have VC++ 2005 now. But it is something the like.)
Maxwell Chen
|
|
|
|
|
The target of my request was the <xstring> :
you said
Maxwell Chen wrote: <xstring> is the internal header file of <string>
but I never heard about <xstring> . How can you affirm that?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
I updated my previous reply.
Maxwell Chen
|
|
|
|
|
as far I can understand, there is a long nesting of includes, starting from <string> that includes <istream> , that includes <ostream> , that includes <ios> , ..., terminating with <stdexcept> that includes <xstring> .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
I'm not sure, but I remember that <string> only includes <xmemory> ...
I do not have VC++2005 at home now. Let me check next week.
Maxwell Chen
|
|
|
|
|
CPallini wrote: starting from <string> that includes <istream>, that includes <ostream>, that includes <ios>, ..., terminating with <stdexcept> that includes <xstring>.
Got it! Thanks!
Maxwell Chen
|
|
|
|
|
(Update: Problem solved)
I'm trying to use CDC::GetWindow to get a pointer to a CWnd object to perform some tests but CDC::GetWindow() returns NULL. I'm trying to derive the CDC from the Graphics object passed into a function as follows...
void SomeFunction(Graphics& graphics)
{
HDC hDC=graphics.GetHDC();
CDC* pDC=CDC::FromHandle(hDC);
if (pDC) {
CWnd* pWnd=pDC->GetWindow();
if (pWnd) {
}
}
graphics.ReleaseHDC(hDC);
}
Can anyone tell me the folly of my ways?
thanks in advance
modified on Friday, December 28, 2007 11:17:40 AM
|
|
|
|
|
Why are you doing that (i.e. have you no control on Graphics object instance?)?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
I'm passing the graphics object around to drawing functions in classes that have no knowledge of who is using them. Those other classes, however, are interested in knowing whether the window the Graphics object is drawing to has the input focus so they can perform their drawing actions differently.
I'm just trying to minimize the number of parameters I'm passing around.
|
|
|
|
|
Well, I don't think that a Graphics object is a good transport medium for a CWnd one. Pass needed parameters packed in a struct.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
I realized what I was doing wrong.
I'm using a memDC so there is no window associated with the underlying DC.
Thanks for the response.
I apologize for my oversight.
|
|
|
|
|
Since the graphics object has the HDC, and the HDC knows which HWND it is associated with (if any) it seems reasonable to say the overhead of digging the HDC out and creating a struct and setting it up are approximately even.
Granted, I screwed it up but the concept seems sound if one can assert the HDC is associated with a window and not just a memory buffer.
Anyway, thanks for your advice as many opinions usually lead to a solution directly or indirectly.
|
|
|
|
|
I'm happy you've found a solution.
BTW a device context maybe associated to the whole screen, so you can get no window anyway (you can state as a precondition that screen DCs are banned!)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Do you want to get handle to a control?
|
|
|
|
|
No, I'm just trying to get a generic window handle for the window the Graphics object drawing commands will effect.
I'm trying to minimize the number of parameters to each function and since the Graphics object is being passed in, I was hoping to use the associated DC to track down the window.
|
|
|
|
|
I realized what I was doing wrong.
I'm using a memDC so there is no window associated with the underlying DC.
I apologize for my oversight.
|
|
|
|
|
Hamid. wrote: Hi CPallini
Happy New Year
I wanted to send the card postal for you but I didnt have your mail address but anyway I wish good year with health for you and your family
I'm sorry, but the link for the above message, is broken hence I cannot reply to the right place. Anyway I'm happy about your message and I wish you and your family a Happy New Year.
Best Wishes Again,
Carlo.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
can anybody tell me
What happens if an exception is throws from an, object's constructor and object's destructor?
thanks in dvance
|
|
|
|
|
Ask George_George: he made a extensive study about...
Seriously, IMHO opinion, the object consumer has to care about of that possibility exactly like it does with standard method thrown exceptions. A difference maybe the fact that object construction/destruction sometimes happens implicitly (and is somehow hidden to the consumer itself).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
[1] Constructor
The object will never be created. Destructor is NOT called. If you allocated ressources before the exception is thrown, they are NOT freed.
[2] Destructors
Technically, the object is left in an undefined state. Likely, Accessing it afterwards will fail, and resources may leak.
Practically, destructors should NEVER throw. It violates even the most basic exception safety guarantee: that objects remain destructable, no matter what.
For lots of more information, try the GOTW columns[^] that deal with exceptions
|
|
|
|
|
Hi all:
I have the following linked list in which head always pointed the last queue item. I'm thinking about the possibility to make the head points to the begining of the queue with the least possible changes.
<br />
class CQueue1 {<br />
public:<br />
CQueue1(int nIndex);<br />
static CQueue1* sm_pHead;<br />
CQueue1* m_pNext; <br />
};<br />
CQueue1* CQueue1::sm_pHead = NULL;<br />
CQueue1::CQueue1(int nIndex)<br />
{<br />
m_pNext = sm_pHead;
sm_pHead = this;
}<br />
Thanks,
|
|
|
|
|
|
Change it as follows
CQueue1::CQueue1(int nIndex)<br />
{<br />
CQueue1** pLast = &sm_pHead;<br />
while( 0 != *pLast )<br />
{<br />
pLast = &((*pLast)->m_pNext);<br />
}<br />
*pLast = this;<br />
m_pNext = 0;<br />
}
|
|
|
|