NguyenMai
asked on
Visual C++.NET for GUI
Hello,
I have some knowledge of standard C++ but now I have to develop some application with GUI. Please tell me if I can do this with Visual C++.NET without too much pains (I would like to devote more of my time to back-end algorithms if possilbe) if I have no prior knowledge of MFC?
Or do I need to switch to C# (easier language with more GUI supports?, but takes sometime too).
Is that right that algorithms need be written entirely in C++ for speedy performance?
Please give my your BEST REFERENCE BOOK(s) to base your ideas.
Thanks a lot for your help.
NM.
I have some knowledge of standard C++ but now I have to develop some application with GUI. Please tell me if I can do this with Visual C++.NET without too much pains (I would like to devote more of my time to back-end algorithms if possilbe) if I have no prior knowledge of MFC?
Or do I need to switch to C# (easier language with more GUI supports?, but takes sometime too).
Is that right that algorithms need be written entirely in C++ for speedy performance?
Please give my your BEST REFERENCE BOOK(s) to base your ideas.
Thanks a lot for your help.
NM.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>Why not write you GUI in C# or even VB.NET and then use managed/unmanaged C++ to write your algorithms ?
I disagree with this comment. In my experience is a bad choice, and make learning curve longer.
If you don't need high performance, use a high level language, but just one.
If you need it, select a middle level language like C++. But notice that C# don't have a better GUI than C++ since C++ can invoke every graphical object that C# can do, and even every feature of operating system, whatever it is.
There are hundreds of questions in EE every week related to guys that are trying to combine languages. Also the interface between both could be a bottle neck.
I disagree with this comment. In my experience is a bad choice, and make learning curve longer.
If you don't need high performance, use a high level language, but just one.
If you need it, select a middle level language like C++. But notice that C# don't have a better GUI than C++ since C++ can invoke every graphical object that C# can do, and even every feature of operating system, whatever it is.
There are hundreds of questions in EE every week related to guys that are trying to combine languages. Also the interface between both could be a bottle neck.
the interface between them ? if you are using MANAGED c++ its transparent as simple as calling another C# object ... switching to unmanged is not trivial but fairly easy within your C++ code
the whole point in using something like C# or even vb.net for the interface would be because it offers a much simpler interface for doing so ... tus limiting the time you spend working on the interface.
Only you have to see Visual Basic forum as an example. There are hundreds of question where the solution is to use WinAPI functions, causing too much trouble to programmers because of Variant conversions, pointers confusion, bad WinAPI function declarations, etc.
Maybe it is easier to program a Form in VB (just a bit), but drawing functions are not complete, and ActiveX control interface have a very poor performance. The same situation happens with C#, VB.net, etc.
Interface IT IS a bottleneck because you have to make some conversion between C++ variables and the other language variables, specially with strings.
Maybe it is easier to program a Form in VB (just a bit), but drawing functions are not complete, and ActiveX control interface have a very poor performance. The same situation happens with C#, VB.net, etc.
Interface IT IS a bottleneck because you have to make some conversion between C++ variables and the other language variables, specially with strings.
what are you talking about ... KEYWORD here MANAGED C++ ... you have to do no marshalling ... you would only Marshall within your C++ code when you felt the need to be running unmanaged code.
managed c++ creates IL (managed dlls) therefor there is no need to marshall between managed C++ / c# / vb.net ... all are running within the CLR and datatypes can (for the most part) be passed freely between (so long as you are CLR compliant). The marshalling of data into unmanaged c++ code should be taken as overhead and should as such be considerred when designing the interfaces to the unmanaged code (if unmanaged code is deemed necesary due to performance reasons)
You are talking about managed C++, I am talking about non C++ languages. Mine is not a managed/unmanaged issue commentary.
BTW. Managed code is slower than unmanaged, specially in C# and VB.net. Just read performance statistics in the internet.
BTW. Managed code is slower than unmanaged, specially in C# and VB.net. Just read performance statistics in the internet.
To be clearer. I never recommend to combine two languages, as explained. To combine managed and unmanaged is another issue.
your reasons listed for not mixing languages are:
1) There are hundreds of question where the solution is to use WinAPI functions, causing too much trouble to programmers because of Variant conversions, pointers confusion, bad WinAPI function declarations
This is not the case when dealing with CLR based languages ... they are transarent ..
2) Interface IT IS a bottleneck because you have to make some conversion between C++ variables and the other language variables, specially with strings
This is only an issue when dealing with managed/unmanaged code NOT managed only
As I stated above managed code is slower ... I know this ... as I suggested if speed were absolutely necessary you should THEN switch to unmanaged code btw: .net generally benchmarks at about 85% compared to native code depending on the operations ... some are very close to equal some fall back almost 25-30% there are few applications which this matters to though in comparison with algorithm design ...
Writing an interface in managed code can be done substantially faster than unmanaged C++ if for no other reason than the framework, my advice has and always will be use the right tool for the job ... to "never recommend combination" is equivalent to saying "you have a bunch of nails, some screws, and some thumbtacks ... here have a screwdriver it will 'work' on all of them". The entire point of the .net framework is to allow the various managed languages operate together ... the only place you would have any 'difficult' code is in your C++ code _IF_ you decided that you absolutely needed unmanaged code for that spot, this however should happen very rarely as the problem space that requires this level of control is rather small (a chess engine or graphics library would be a good example but at that point I would say C/C++ with aseembler calls).
1) There are hundreds of question where the solution is to use WinAPI functions, causing too much trouble to programmers because of Variant conversions, pointers confusion, bad WinAPI function declarations
This is not the case when dealing with CLR based languages ... they are transarent ..
2) Interface IT IS a bottleneck because you have to make some conversion between C++ variables and the other language variables, specially with strings
This is only an issue when dealing with managed/unmanaged code NOT managed only
As I stated above managed code is slower ... I know this ... as I suggested if speed were absolutely necessary you should THEN switch to unmanaged code btw: .net generally benchmarks at about 85% compared to native code depending on the operations ... some are very close to equal some fall back almost 25-30% there are few applications which this matters to though in comparison with algorithm design ...
Writing an interface in managed code can be done substantially faster than unmanaged C++ if for no other reason than the framework, my advice has and always will be use the right tool for the job ... to "never recommend combination" is equivalent to saying "you have a bunch of nails, some screws, and some thumbtacks ... here have a screwdriver it will 'work' on all of them". The entire point of the .net framework is to allow the various managed languages operate together ... the only place you would have any 'difficult' code is in your C++ code _IF_ you decided that you absolutely needed unmanaged code for that spot, this however should happen very rarely as the problem space that requires this level of control is rather small (a chess engine or graphics library would be a good example but at that point I would say C/C++ with aseembler calls).
Well, I guess it is the moment where author must tell us which kind of application has in mind.
ASKER
Thanks a lot for your informative discussion. My application is hospital scheduling problem, where I need to :
1-develop very efficient scheduling algorithms for NP-hard problems
2- and GUI to manipulate data (room available time, surgeons, patients...), and Gantt chart to present schedules graphically. This chart can be passive or interactive (allow users to change schedule directly on the Gantt chart).
Your guidance is important since as for operations researchers, backend algorithms are very decisive, while GUI needs be intuative to users.
1-develop very efficient scheduling algorithms for NP-hard problems
2- and GUI to manipulate data (room available time, surgeons, patients...), and Gantt chart to present schedules graphically. This chart can be passive or interactive (allow users to change schedule directly on the Gantt chart).
Your guidance is important since as for operations researchers, backend algorithms are very decisive, while GUI needs be intuative to users.
GUI final result will be identical in C#, VB or C++.
If your scheduling algorithms don't have a high load (by ex., just a dozen per day) or have a few elements (let say, 500) then you can think in C# or VB.net
If your scheduling algorithms don't have a high load (by ex., just a dozen per day) or have a few elements (let say, 500) then you can think in C# or VB.net
yeah this does not sound like a problem where a 15% loss due to managed code will severely hurt your system, as for the GUI I would recommend managed code simply for speed of development through use of the framework.
ASKER
Thanks for your replies. Actually the workload is very high with thousands of scheduling resources in conflict. The GUI is expected to support decision maker (it is a DSS). My concern is that which is better between developping GUI by C# (learning from scratch) and the one of Visual C++.NET or MFC in terms of:
1-learning curve
2- maintenance (especially integration between the frontend and the backend)
3- future compatibility ?
1-learning curve
2- maintenance (especially integration between the frontend and the backend)
3- future compatibility ?
1-learning curve (about the same maybe a slight + for C#)
2- maintenance (especially integration between the frontend and the backend) (If you do the backend in C# not at all ... in unmanaged C++ slightly faster, you would need to deal with a bit of marshalling) One comment on this ... would you be open to actually seperating the front end and backend i.e. they run in different processes and talk via COM, database, or some other method of IPC seperating them would have the integration equal and would probably provide a more rebust system (i.e. it could if designed right support multiple clients)
3- future compatibility ? (definately a + for C#)
2- maintenance (especially integration between the frontend and the backend) (If you do the backend in C# not at all ... in unmanaged C++ slightly faster, you would need to deal with a bit of marshalling) One comment on this ... would you be open to actually seperating the front end and backend i.e. they run in different processes and talk via COM, database, or some other method of IPC seperating them would have the integration equal and would probably provide a more rebust system (i.e. it could if designed right support multiple clients)
3- future compatibility ? (definately a + for C#)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
there is no shortage of C# documentation: MS has been doing their own development in C# ... there is a TON of C# documentation.
a quick quote :
C# versus C++
Although it has some elements derived from Visual Basic and Java, C++ is C#'s closest relative.
In an important change from C++, C# code does not require header files. All code is written inline.
As touched on above, the .NET runtime in which C# runs performs memory management, taking care of tasks like garbage collection. Because of this, the use of pointers in C# is much less important than in C++. Pointers can be used in C#, where the code is marked as 'unsafe' (lesson 5), but they are only really useful in situations where performance gains are at an absolute premium.
Speaking generally, the 'plumbing' of C# types is different from that of C++ types, with all C# types being ultimately derived from the 'object' type (lesson 4). There are also specific differences in the way that certain common types can be used. For instance, C# arrays are bounds checked unlike in C++, and it is therefore not possible to write past the end of a C# array.
C# statements are quite similar to C++ statements. To note just one example of a difference: the 'switch' statements has been changed so that 'fall-through' behaviour is disallowed (lesson 10).
As mentioned above, C# gives up on the idea of multiple class inheritance. Other differences relating to the use of classes are: there is support for class 'properties' of the kind found in Visual Basic, and class methods are called using the . operator rather than the :: operator.
For more comparison of C# and C++ see:
http://msdn.microsoft.com/msdnmag/issues/01/07/ctocsharp/default.aspx
http://windows.oreilly.com/news/hejlsberg_0800.html
a quick quote :
C# versus C++
Although it has some elements derived from Visual Basic and Java, C++ is C#'s closest relative.
In an important change from C++, C# code does not require header files. All code is written inline.
As touched on above, the .NET runtime in which C# runs performs memory management, taking care of tasks like garbage collection. Because of this, the use of pointers in C# is much less important than in C++. Pointers can be used in C#, where the code is marked as 'unsafe' (lesson 5), but they are only really useful in situations where performance gains are at an absolute premium.
Speaking generally, the 'plumbing' of C# types is different from that of C++ types, with all C# types being ultimately derived from the 'object' type (lesson 4). There are also specific differences in the way that certain common types can be used. For instance, C# arrays are bounds checked unlike in C++, and it is therefore not possible to write past the end of a C# array.
C# statements are quite similar to C++ statements. To note just one example of a difference: the 'switch' statements has been changed so that 'fall-through' behaviour is disallowed (lesson 10).
As mentioned above, C# gives up on the idea of multiple class inheritance. Other differences relating to the use of classes are: there is support for class 'properties' of the kind found in Visual Basic, and class methods are called using the . operator rather than the :: operator.
For more comparison of C# and C++ see:
http://msdn.microsoft.com/msdnmag/issues/01/07/ctocsharp/default.aspx
http://windows.oreilly.com/news/hejlsberg_0800.html
actually the source quoted from also a good tutorial http://www.softsteel.co.uk/tutorials/cSharp/lesson2.html
ASKER
Thank you very much, gregotyyoung and jaime olivares (you are francophonist, I suppose).
I'd like to broaden my programming knowledge with C#, but for me, as an OR guy, algorithm is the core and I love C++ for doing this. I do not think I can make a better GUI than some CS guy, so I'd better stay on my niche ;-)
I'd like to broaden my programming knowledge with C#, but for me, as an OR guy, algorithm is the core and I love C++ for doing this. I do not think I can make a better GUI than some CS guy, so I'd better stay on my niche ;-)
About algorithm, C++ is one of the fastest languages to make calculations, because it is near to the machine language (strong data type checking, registers vars, etc.)
In case of MFC, there are many books in amazon.com, but codeproject.com and codeguru.com will bring you ready-made advanced examples.