|
Well, why does the customer tell you what technology to use to build a software? Shouldn't you (the developer) be suggesting what's best for accomplishing a given task?
You could wrap your C++ image processing code into a COM dll and use it from C#, instead of writing the whole thing from scratch in C#.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Rajesh R Subramanian wrote: You could wrap your C++ image processing code into a COM dll and use it from C#, instead of writing the whole thing from scratch in C#.
Why bother with COM? It's simple enough to write DLLImport statements and use a native C++ DLL as is.
L u n a t i c F r i n g e
|
|
|
|
|
by writing functionalities in COM u'll be able to build it as server components and call them in any technology(e.g C#)as client and can perform out of process calling easily..
DLL's always not allow you out of process calling untill RPC which's tough to manage.
So I think writing COM dll in VC++ idea is better and integrating it with C# will blend things moore significant way..
|
|
|
|
|
Thank you very much for the advice.Well,if i develop the software using
VC++(MFC) in Visual Studio 2008 IDE, will it be built on .Net framework.Why i ask is because i have good experience in VC++(MFC).
Thanks,
Ashwath.
|
|
|
|
|
ashwath1979 wrote: Well,if i develop the software using
VC++(MFC) in Visual Studio 2008 IDE, will it be built on .Net framework
What are you talking about? Unless you target one of those versions of the .NET framework and write managed code, your application would remain native. Just because you use the VS 2008 IDE doesn't mean your application is built on .NET framework.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Thanks Rajesh for the answer.If i develop a VC++.Net application(Form type),will it be developed on .Net framework.
|
|
|
|
|
You mean a managed c++ (C++/CLI) application? Then yes, it would be using the .NET framework.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Yes, i have choosen the "windows forms application"(Managed c++/cli) type project in the "new project" menu.This is built on top of .Net framework right?
Please advice,
thanks,
Ashwath
|
|
|
|
|
Yes Ashwath, you're correct. If you choose the c++/cli type project, then that would be using the .NET framework.
PS (Shameless plug): May I ask you to kindly mark the helpful replies by clicking "Good Answer" on the reply posts? 
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
definitely C#.net as suggest earlier
and surely OpenGL.
And if you use nvidia GPU then performance of 3D rendering will be very high, [^].
But surely difficult to write the programe with GPU
Величие не Бога может быть недооценена.
modified on Friday, January 15, 2010 7:29 AM
|
|
|
|
|
Hi
My application is such that I have a main dialog class which interacts with the User, at the same time another complete class that performs all background functions needs to be running simultaneously.
Please suggest a method of how that can be executed. On start of application both classes have to be initialised. The background class cannot be called by a button or any other user interface method.
Thanks a ton
Regards
Darshi
|
|
|
|
|
Then you have to make two classes
one on main thread, and another on worker thread.
Where main thread should interact with the user actions, while the background processing is done by worker thread.
On the OnInitdialog of main dialog, you can start the worker thread.
Worker thread can be created using AfxbeginThread or CWinthread [^]
Величие не Бога может быть недооценена.
|
|
|
|
|
Thanks adam
can you also help me with the syntax of the thread function and how the class should be called from the thread function
|
|
|
|
|
|
Multithreading is a fairly complex subject. While you may get away writing multithreaded code by reading online articles, I strongly recommend that you read a book chapters devoted to this subject.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Adam Roderick J 09 wrote: Worker thread can be created using AfxbeginThread or CWinthread [^]
If a worker thread is what is needed, then AfxBeginThread() and a thread function is the ONLY correct way to go (as far as MFC usage is concerned).
Deriving from CWinThread is needed only when a message pump for the thread is needed (so called "UI thread").
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
As already suggest, you should use a worker thread. Have a look at the classic J.M.Newcomer's article: "Using Worker Threads".
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I would not recommend multi-threading. Don't go there, it won't do you any good. If you need to perform several tasks at once, you are MUCH better off using "idle time processing" using CWinApp::OnIdle() and calling Continue() in the worker object where you perform one little piece of work each time, using a state variable or similar.
Multi-threading should be avoided at all costs. It's hopeless to debug, a maintenance nightmare and you get absolutely no performance benefits from it, except in very special cases (number crunching on a multi CPU, low-level drivers or things like that). Do not use multi-threading, I cannot stress this enough. I speak from bitter experience
|
|
|
|
|
Mattias G wrote: Multi-threading should be avoided at all costs. It's hopeless to debug, a maintenance nightmare and you get absolutely no performance benefits from it, except in very special cases (number crunching on a multi CPU, low-level drivers or things like that). Do not use multi-threading, I cannot stress this enough. I speak from bitter experience Smile
Quote Selected Text
I don't agree at all... Mutli-thread can't be avoided in some cases. Of course, you shouldn't overuse it but there are a lot of cases where it simply can't be avoided.
I agree that this is something hard to learn and difficult to debug but it is sometimes necessary. If it was that bad, why would it be so widely used ?
|
|
|
|
|
Could you provide an example of where multi-threading is a good idea? Would be interesting to hear from someone with good experiences from threads ...
|
|
|
|
|
There are a lot of cases where multi-threading is an advantage.
For instance, when you have a server (probably even without a UI) that should accept different clients at the same time. I can't imagine doing something like that without mutli-threading.
Another example: if you have an application which has to execute tasks (which can be a lenghty operation) and you don't want to freeze the UI. Of course, you could use the OnIdle but this becomes quickly difficult to manage. It is much easier to have a queue object in which you can enqueue the tasks when needed and the queue object processes these tasks in a separat thread, independantly of the UI.
Of course, there are much more examples than that.
|
|
|
|
|
The simplest case would be where you have to wait on a port for data, or you've to wait for an operation to complete, or you have to do a lengthy processing, while still having to keep the GUI responsive.
"Avoid multithreading at all costs" is probably the worst advice I've ever seen here.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Have a look at Idle Loop Processing, namely:
Many applications perform lengthy processing "in the background." Sometimes performance considerations dictate using multithreading for such work. Threads involve extra development overhead, so they are not recommended for simple tasks like the idle-time work that MFC does in the OnIdle function. This article focuses on idle processing. For more information about multithreading, see Multithreading Topics.
Some kinds of background processing are appropriately done during intervals that the user is not otherwise interacting with the application. In an application developed for the Microsoft Windows operating system, an application can perform idle-time processing by splitting a lengthy process into many small fragments. After processing each fragment, the application yields execution control to Windows using a PeekMessage loop.
Aside of performance considerations, I've underlined the key concept behind idle time processing: you need to fragment a lenghty operation. That means you've to build a state machine. Of course it is a viable approach but using a separate thread means that, conceptually, the execution flow is never broken.
Multithreading requires care, I admit, but you cannot deduce by your bad experience with, that multithreading is bad.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
(Late reply, but anyways) Ok, multi-threading isn't always bad It's just that I have seen very few examples where multi-threading brings any real benefits -- a server app as mentioned above might be one, a device driver might be another. On the other hand, I've seen a few extremly tricky maintenance and debugging problems due to MT. For starters, it can be almost impossible just to reproduce a certain behaviour or error in a application with multiple threads. I would probably prefer a state machine in 9 out 10 cases.
/M
|
|
|
|
|
State machines are good. But, for many programmers counter-intuitive.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
