|
You can use a normal application hiding the window. It has been talked about in some messages in this week. Take a look in forum
Greetings.
--------
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
|
|
|
|
|
There is no requirement for a Win32 application to actually create a Window. I'd use the wizard to create an empty Win32 app and start from there with your own WinMain function. That's proper old school Windows programming 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Hello everyone,
Just interested to learn how C++ implements delete this statement internally. From logical point of view, I can not imagine how to implement a component which destroy itself.
What makes me confused is the component is relying on itself even in the process of destroy, how could it destroys itself from itself?
thanks in advance,
George
|
|
|
|
|
George_George wrote: ust interested to learn how C++ implements delete this statement internally.
Internally (simplified!), all functions of an object are global, and take a first, hidden, parameter this, which points to a memory-chunk holding the data-members of the object.
So, when calling the same member function on different instantiations of Object, you are executing the same code with a different this-pointer. Also, delete only frees the memory-chunk the this-pointer points to. It does nothing to the code of a class.
So, a code containing
delete this;
is very possible: delete calls the destructor (with the this-pointer) as usually and then frees the memory-chunk and returns control to the calling code. The object is destroyed like any normal object.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
|
Thanks jhwurmbach,
Your reply is very clear!
regards,
George
|
|
|
|
|
George_George wrote: how could it destroys itself from itself?
Not sure what you mean by that...
Nothing destroys itself "from" itself. Every call chain has its root in the system; every process and thread.
If the process or thread returns from its controlling function, the system will remove it from the scheduler and destroy it.
If you debug your application and have a look in the call stack, you'll see that the first stack frame is from the system.
Don't confuse the code loaded for the component and the object on the heap.
This question could be about COM. It doesn't have to be, but we can use it as an example.
When you call Release on an interface, the reference count is decreased and if it reaches zero the component "destroys itself", i.e. calls delete this and thus removes the object from the heap. When returning from the Release subroutine, the client continues executing. This means that the component is destroyed, but in a call chain that originates from the client. The code for the component would still be there, but the object on the heap is destroyed.
I hope this answers your question.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks Roger,
I think you mean delete this only destroys the data of instance, not the code itself. Right?
regards,
George
|
|
|
|
|
George_George wrote: I think you mean delete this only destroys the data of instance, not the code itself. Right?
Yes, that's one part of my reply.
The other part is meant to explain why an object doesn't "destroy" itself since I interpreted your question as if you worried about something like "what code will be executed after the object is destroyed". But I may have misunderstood you regarding that.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks Roger,
Now I can understand your points since from your help, I know the code and the data of instance are stored separately and destructor only frees the data, not the code.
have a good weekend,
George
|
|
|
|
|
Hello everyone,
From MSDN,
http://msdn2.microsoft.com/en-us/library/ms682583.aspx
parameter fdwReason of DllMain has four values,
DLL_PROCESS_ATTACH
DLL_PROCESS_DETACH
DLL_THREAD_ATTACH
DLL_THREAD_DETACH
I think we could simply understand what MSDN described about the four values in the following way after some experiment (I have read the big table and want to extract some brief and simple information to understand to remember),
DLL_PROCESS_ATTACH: will be called only once when the process loads the DLL for the 1st time
DLL_PROCESS_DETACH: will be called only once when the process unloads the DLL (when process stops)
DLL_THREAD_ATTACH: will be called every time when a thread inside the current process loads the DLL
DLL_THREAD_DETACH: will be called every time when a thread inside the current process unloads the DLL
Is that correct understanding?
thanks in advance,
George
|
|
|
|
|
yes .. ur understanding is correct
Ajay
|
|
|
|
|
Thanks Ajay,
I think the DllMain will be triggered when LoadLibrary (or FreeLibrary) is invoked in a process or a thread inside a process. Are there any other functions which will trigger DllMain other than LoadLibrary or FreeLibrary?
regards,
George
|
|
|
|
|
You're correct for processes but for threads the ATTACH and DETACH calls are made when the thread is started and completed not specifically when the Dll is loaded. In other words you don't load a Dll for each thread that uses it but you should generally load the Dll before any secondary threads that will share it are started.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew,
In your experience, when will DllMain be called with parameter value DLL_THREAD_ATTACH or DLL_THREAD_DETACH? Could you show a simple sample please?
regards,
George
|
|
|
|
|
|
Great article, thanks Nibu!
regards,
George
|
|
|
|
|
I have downloaded an API and to use it in MFC program, the following line must be included.
#include <vips/vips>
using namespace vips;
but shows this error upon build
Cannot open include file : 'vips/vips' : No such file or directory
|
|
|
|
|
This has nothing to do with the namespace. It simply tells you that the file vips (strange, without any extention ?) doesn't exist in the directory vips.
|
|
|
|
|
I tried a test on other namespace like std typing
std::
will display some functions
but typing vips::, gives none
How will i include or make vips a recognized namespace?
What should i do to use it?
Thank you.
|
|
|
|
|
Did you read my post ? 
This has absolutely nothing to do with the namespace. The error is simply there because the file is missing. Even without the namespace you would get the same problem. Just copy the files at the correct location and that should solve the problem.
|
|
|
|
|
Sorry cause I'm not that familiar with this.
How will I do that?
I have included vips.h in solution explorer.
I have downloaded this API from this link.
Hope you can help me.
|
|
|
|
|
Where did you copy the files on your hard disk ? The compiler needs to be able to reach the include files. Just adding them to your workspace doesn't mean that the compiler will be able to find them.
Now, I cannot tell you exactly what you need to do (depends on your project) but you can also add the path to the vips folder in your additional include directories ("Project properties" -> "C/C++" -> "Additional Include Directories".
|
|
|
|
|
BTW, are you sure the file is called vips and not vips.h ?? Because if I look at the examples on their website, for C they are including vips.h so, maybe it is a mistake from them. Check what files exactly are in the vips folder.
|
|
|
|
|
Check your computer for this file and also check path of file.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
