|
is there any one can help ?
|
|
|
|
|
Hi Friends,
I am writing a MFC Application for UNICODE convertion,
After convertion i need to delete unwanted files in a particular folder.
Could any one tell me how to do that.
Thanks and Regards.
SANTHOSH V
|
|
|
|
|
|
Of course I suggest use of SHFileOperation because it ask of you for confirm.
|
|
|
|
|
Hello everyone,
I am confused what is the type of *this? Type of reference to instance or type of instance?
Looks like both code can compile, no warning messages. Any ideas?
class A{
A& foo1()
{
return *this;
}
A foo2()
{
return *this;
}
};
thanks in advance,
George
|
|
|
|
|
Hi,
The this pointer is a pointer accessible only within the member functions of a class, struct, or union type. It points to the object for which the member function is called. Static member functions do not have a this pointer.
// Example of the this pointer
void Date::setMonth( int mn )
{
month = mn; // These three statements
this->month = mn; // are equivalent
(*this).month = mn;
}
Thanks and Regards.
SANTHOSH V
|
|
|
|
|
THANKS . I am also confused aboout 'this'.but now got it.
|
|
|
|
|
Thanks SANTHOSH,
My question is not what is this pointer, but when we return *this, should we treat return type as reference to object type, object type, or both are ok?
regards,
George
|
|
|
|
|
foo1 returns a reference to the object pointed at by this . foo2 returns a copy of the object pointed at by this .
|
|
|
|
|
Thanks gleat,
You mean if we invoke,
1. fun1, like A& a = fun1(), then return a reference;
2. fun2, like A a = fun2(), return a new copy of instance (invokes assignment operator on A)
Both are good code, right?
regards,
George
|
|
|
|
|
Yep. That's the idea. As for whether its good code or not depends on what you want to do. Some simple thumb-rules are:- Don't pass around data heavy structures by value as the copying overhead can prove to be a performance drain. Be especially wary of passing them via STL (or any other) collection types. Imagine returning a
vector<BigHeavyClass> containing 500 items by value! - When passing around objects by reference remember to use
const if you do not intend to alter the object's state via that reference.
|
|
|
|
|
Thanks for your advice, gleat!
My question is answered.
regards,
George
|
|
|
|
|
George_George wrote: (invokes assignment operator on A)
Not exactly true. It invokes the copy constructor, which is not the same thing.
Software Zen: delete this;
|
|
|
|
|
Thanks Gary, you are correct. I want to confirm with you that,
1.
A a = fun2() will invoke copy constructor on a;
2.
A a;
a = fun2();
will invoke assignment operator on a.
Both are correct?
regards,
George
|
|
|
|
|
Since foo1 returns a reference (which is really just a pointer), it can just return the address of the 'this ' object.
The other function, foo2 actually returns an object of type A . In order to do that, it invokes the copy constructor for A , copying the contents of this to the destination.
Software Zen: delete this;
|
|
|
|
|
Thanks Gary,
How about your comments on my two questions before?
--------------------
1.
A a = fun2() will invoke copy constructor on a;
2.
A a;
a = fun2();
will invoke assignment operator on a.
Both are correct?
--------------------
regards,
George
|
|
|
|
|
I believe your statements are both true. The compiler is supposed to turn #1 into this:
A a(fun2()); automatically, which is a call to the copy constructor.
#2 obviously calls the assignment operator. Note that the default constructor for A is called first, when the variable is declared.
Software Zen: delete this;
|
|
|
|
|
Thanks for your clarification, Gary!
regards,
George
|
|
|
|
|
George_George wrote:
class A{
A& foo1()
{
return *this;
}
A foo2()
{
return *this;
}
};
Well, there's nothing special related to this in the above snippet:
you can do as well:
class B
{
int i;
int * p;
...
int getiValue(){ retirn i;}
int & getiRef(){ return i;}
int getpValue(){ return *p;}
int & getpRef(){ return *p;}
...
}
it is simply C++ syntax for dealing with references.
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.
|
|
|
|
|
Cool, CPallini! Thanks, and my question is answered.
regards,
George
|
|
|
|
|
Hello everyone,
I am reading some code from other people, there are some code like this,
class Foo {
};
Foo& func()
{
Foo foo;
return foo;
}
int main()
{
Foo& foo = func();
return 0;
}
I want to confirm with you that it is not good code, since we return a reference to local object instance, right? Even if the code has expected function currently.
thanks in advance,
George
|
|
|
|
|
Yep! Whatever else it is, it most certainly is NOT good code! The local instance of foo inside func will get deallocated when control returns from func . So the reference foo in main is undefined.
|
|
|
|
|
Thanks gleat,
My question is answered.
regards,
George
|
|
|
|
|
Hi All,,
I have created MFC Activex Control in VS 2005.In that I want to get the instance of the main window.
As like in Win32 Application we can get this instance from Winmain() function like below...
<br />
HINSTANCE hAppInstance;<br />
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)<br />
{<br />
hAppInstance = hInstance;<br />
<br />
}<br />
.. and this Instance I can use in futher application.(for example to create window CreateWindow() function)
Same way how can I get this Instance form MFC Activex Control Application??
Plz suggest me if you know anything about this.
Thanks in Advance.
|
|
|
|
|
I suggest you take a step back and tell us what problem you are actually trying to solve.
The HINSTANCE passed to CreateWindow is used to allow multiple independently-developed libraries to register window classes using the same name. The HINSTANCE differentiates between the different classes. Generally when registering a window class you pass your DLL or EXE's HINSTANCE value, then use the same value when creating a window of that class.
For more see http://blogs.msdn.com/oldnewthing/archive/2005/04/18/409205.aspx[^].
DoEvents: Generating unexpected recursion since 1991
|
|
|
|