Modern GUIS and C++
-
cwp42 wrote:
C# is easy to learn
I don't agree. It's sure much easier than c++, but not more than basic. Even for a programmer with c++ background, it takes a good amount of time to learn. Farther more what you are going to do is Visual c# .net for Windows os, which is different from plain c# and makes it times more difficult because one should also get familiar with thousands of events and their parameters and arguments plus working with controls and other os specific materials.
cwp42 wrote:
the Framework provides all its functions very comfortable to me
Sure.
cwp42 wrote:
C# is slow
Yes.
cwp42 wrote:
this[IL] is one of the negativest features to the Basic language(s)
And the best benefit at the same time. It helps to be platform independent which is critical in special works like parallel programming. It increase performance by a just in time compilation for the particular machine it runs on. It (with a common type system)helps interoperability between different languages which is a benefit in team working, etc.
cwp42 wrote:
we came to (unmanaged) C++
So did I, but not because of IL, or .Net being bad. Because I'm a standalone programmer, my apps don't need to be multi platform, I had to have a lot prerequisites installed, customers needed a lot of memory(RAM) and a descend machine, my apps are not large, I didn't like it nor did my customers, it was slow and I hadn't enough reasons to stop using what I learned during years. I earn money with MFC and my customers don't care what I use if the result is the same.
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
}Hamed Mosavi wrote:
cwp42 wrote: we came to (unmanaged) C++ So did I, but not because of IL, or .Net being bad. Because I'm a standalone programmer, my apps don't need to be multi platform, I had to have a lot prerequisites installed, customers needed a lot of memory(RAM) and a descend machine, my apps are not large, I didn't like it nor did my customers, it was slow and I hadn't enough reasons to stop using what I learned during years. I earn money with MFC and my customers don't care what I use if the result is the same.
Odd because these are the reasons I decided to go with .net: Rarely do our customers now not already have .net installed (it was part of windows update after all), our apps are *incredibly* smaller than they were in the mfc days because we don't have to distribute so many damned .dll's and the assemblies are tiny in comparison to comparable stuff we wrote for mfc (and I do mean comparable because we ported existing apps to .net), I've found no practical difference in speed in our ported apps and in fact the .net apps are quite a lot faster because in the days of our mfc apps the hardware was much slower so the end result is the end user gets a much smaller app which is easy to download, it runs to them as fast or faster than the older mfc app they used to use. Of course you must use what works in your situation but I find my experience to be different than yours. However the fact that customers don't care what we use is absolutely true and something I wish more developers here understood. Customers only really truly care about features and hassle. They want the features but the sure thing to get them pissed off is *any* amount of hassle, however minor seeming. And this brings up the most critical point for why we switched to .net and continue to think it's the best choice: The hassle level is reduced by many orders of magnitude for the end user. No more .dll hell, our tech support levels have gone down considerably. In the old days we had to distribute a lot of native and 3rd party .dll's there were often conflicts, that's just all vanished now.
Modo vincis, modo vinceris.
-
You are right, C# is dead slow, especially on graphics, about 10 times, it is the software GDI+ rendering. WPF is even slower, can be upto 5 times in comparison to WinForms and you will experience awful start up times and huge RAM consumption. btw, C# is compiled at runtime not interpreted but JIT doesn't help any serious performance you are probably looking for. It is so obvious and you can easily see it with IDEs that drag themselves to oblivion. I'd forget the .NET hopefuls trying to pursuade you, if you are doing any decent app that won't slam your target audience machines, then C++ is the way to go. It is harder but you do it like a man without a helping hand of a Java-like mentality somehow thinking managed is cool. Porting to C# abstraction is easy and you have plenty of articles here that will help you build your own framework (you will need one). I'd use a OpenGL and DirectX layer, just look at what MS did with new Messenger, and of course whenever it makes sense XHTML. Those "errors in judgement" hardly quantify any functional requirements, and if you have one for a fast and well-behaved GUI (imagine 10 .NET apps running at the same time, machine becomes unusable), than C# or any .NET stuff can hardly teach you anything 99% of people chase and end up with what? The same 'technology' bloat, but sure you will be more productive and perhaps .NET technology is good for an initial stage of design. Up to you really, it is easy to port between implementations but lets not kid ourselves, .NET is rendering and working as heavy as Java did back in 1998; and its performance is pathetic in comparison to anything C++ (85% yeah sure, in your dreams pedro).
User of Users Group wrote:
imagine 10 .NET apps running at the same time, machine becomes unusable
Then you've only used .NET apps written by horrible coders. My shop has written some two dozen .NET apps that are ALL doing real-time data acquisition, signal processing, and plotting, and we regularly run 10+ of them on one machine at the same time, with absolutely no noticeable lag. It's hard work of course, but that's the nature of programming in general. .NET makes making the GUI easier; it does not relieve you of your responsibility to make the application efficient.
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee
-
Amen! I'm competing my C++ app against a new whiz-bang .NET app and the customer is ready to throw out the .NET app as unusable while still desk testing. I've been running in the production environment for a while. Doing some fairly simple basic math with file look-ups is waaay slow on the .NET app. Can't vouch for the actual code, but the customer only sees the end product. The competitor is a BIG national provider, however. We're running on a mobile device which doesn't have the GHz horsepower of PCs. MFC for the GUI worked well, with several hundred different screens in the app. All user response times should be sub-second - anything longer needs recoded! Sometimes, we just need the ability to get as close to the CPU as possible.
Gary
ghle wrote:
Doing some fairly simple basic math with file look-ups is waaay slow on the .NET app.
This is why for anything mathematics oriented, you would generally use native dll's written in C or C# and use PInvoke to access those functions. We do that for some of our applications and it works out beautifully. We can do some fairly sophisticated math in our .NET gui's by breaking the more complex math out into native code (I'm not talking about multiplication and addition, though - I'm talking about things like signal processing, FFTs, the sort of things that require MKL and IPP no matter WHAT development system you're using).
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee
-
Amen! I'm competing my C++ app against a new whiz-bang .NET app and the customer is ready to throw out the .NET app as unusable while still desk testing. I've been running in the production environment for a while. Doing some fairly simple basic math with file look-ups is waaay slow on the .NET app. Can't vouch for the actual code, but the customer only sees the end product. The competitor is a BIG national provider, however. We're running on a mobile device which doesn't have the GHz horsepower of PCs. MFC for the GUI worked well, with several hundred different screens in the app. All user response times should be sub-second - anything longer needs recoded! Sometimes, we just need the ability to get as close to the CPU as possible.
Gary
ghle wrote:
All user response times should be sub-second - anything longer needs recoded!
very true, but even java should be capable of writing a GUI with that as the only limitation. C# will beat Java hands down, and C++, although faster, will sometimes generate slower code for GUIs depending on the API chosen. The rest of the results are completely in the air depending on the programmer. Bad code can be written by anyone, including and experience programmer when he steps out of his speciality. Life in the real-time world rarely has UIs, but I have done enough of them to use a large variety of environments including C#, though I have delivered no C# GUIs to any customer yet. As long as you don't do something obviously detrimental to speed, and the programmer is competent (those two kind of go hand in hand, but every programmer, even experienced ones sometimes make silly mistakes), you should be able to get a GUI to subsecond response on any modern language. The back-end stuff is where the details are. And depending on the needs you can call a power-number-mashing DLL from C# (or Java as one of our team has done). So the real queston on which primary language to use is a very difficult one to answer, partly depends on the skill sets you have, and also depends on the over all goals of the project and the company. If you want everything uniform, do you stick with C++ with C++ GUI operations? do you hybridize your operatons with core functionality in C++ called from a C# front-end? That is where you start aligning pros and cons to each and the significant cost associated in man-hours. C# GUI's are cheap in labor costs, but learning curves for retraining for the larger core sets would be more significant, and not always worthwhile to the run-tme operations speed. Hybrdizing is a cheap alternative, but cheap GUIs up front, hard-won DLLs on the back. C++ all the way around may be desireable because of one language, one training set, one, one, one. Not a bad idea in some situations. The hard decision is what is good for your project or your company, the impossible decision is what one choice is good for everyone. There is no answer for EVERYONE, there is only the answer for each person, each group, each company.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Hamed Mosavi wrote:
cwp42 wrote: we came to (unmanaged) C++ So did I, but not because of IL, or .Net being bad. Because I'm a standalone programmer, my apps don't need to be multi platform, I had to have a lot prerequisites installed, customers needed a lot of memory(RAM) and a descend machine, my apps are not large, I didn't like it nor did my customers, it was slow and I hadn't enough reasons to stop using what I learned during years. I earn money with MFC and my customers don't care what I use if the result is the same.
Odd because these are the reasons I decided to go with .net: Rarely do our customers now not already have .net installed (it was part of windows update after all), our apps are *incredibly* smaller than they were in the mfc days because we don't have to distribute so many damned .dll's and the assemblies are tiny in comparison to comparable stuff we wrote for mfc (and I do mean comparable because we ported existing apps to .net), I've found no practical difference in speed in our ported apps and in fact the .net apps are quite a lot faster because in the days of our mfc apps the hardware was much slower so the end result is the end user gets a much smaller app which is easy to download, it runs to them as fast or faster than the older mfc app they used to use. Of course you must use what works in your situation but I find my experience to be different than yours. However the fact that customers don't care what we use is absolutely true and something I wish more developers here understood. Customers only really truly care about features and hassle. They want the features but the sure thing to get them pissed off is *any* amount of hassle, however minor seeming. And this brings up the most critical point for why we switched to .net and continue to think it's the best choice: The hassle level is reduced by many orders of magnitude for the end user. No more .dll hell, our tech support levels have gone down considerably. In the old days we had to distribute a lot of native and 3rd party .dll's there were often conflicts, that's just all vanished now.
Modo vincis, modo vinceris.
John Cardinal wrote:
The hassle level is reduced by many orders of magnitude for the end user. No more .dll hell, our tech support levels have gone down considerably. In the old days we had to distribute a lot of native and 3rd party .dll's there were often conflicts, that's just all vanished now.
Here's our difference. My project are small enough (I don't remember any project more than 23,000 LOC) that I code alone or with one more programmer. We rarely need to use third party libraries( except for UltimateToolBox ). I don't remember to be using dlls more than in three or four projects and I really like MFC. All in all,you are absolutely right. The problem I encountered in .Net, actually, is lack of knowledge:sigh: I was lazy or busy enough or had not enough confidence to start a real project in C#. For example I know what exactly is happening when I pass a pointer to an object as a parameter of a function, but in .Net I don't know which method is safe or has best performance. It took years to learn these in C++. I think I need to read a really good, in debt book about it, and I think it'll take a long time, I don't have enough reasons to go there yet, because I'm not sure what benefits I get in return. By the way, how long did it take to learn c# for you?
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
} -
John Cardinal wrote:
The hassle level is reduced by many orders of magnitude for the end user. No more .dll hell, our tech support levels have gone down considerably. In the old days we had to distribute a lot of native and 3rd party .dll's there were often conflicts, that's just all vanished now.
Here's our difference. My project are small enough (I don't remember any project more than 23,000 LOC) that I code alone or with one more programmer. We rarely need to use third party libraries( except for UltimateToolBox ). I don't remember to be using dlls more than in three or four projects and I really like MFC. All in all,you are absolutely right. The problem I encountered in .Net, actually, is lack of knowledge:sigh: I was lazy or busy enough or had not enough confidence to start a real project in C#. For example I know what exactly is happening when I pass a pointer to an object as a parameter of a function, but in .Net I don't know which method is safe or has best performance. It took years to learn these in C++. I think I need to read a really good, in debt book about it, and I think it'll take a long time, I don't have enough reasons to go there yet, because I'm not sure what benefits I get in return. By the way, how long did it take to learn c# for you?
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
}Hamed Mosavi wrote:
We rarely need to use third party libraries
Yeah that's a *major* difference, we used to have *many* third party libraries for everything from reporting to encryption. Many of those were no longer required in .net because they were built in, however we probably have even more third party libraries now with all the new features, but they are never an issue like they used to be.
Hamed Mosavi wrote:
It took years to learn these in C++.
I know what you mean, but once you get into .net you will realize how much of that knowledge is just not relevant or required. There is no where *near* the learning curve, particularly if you are an experienced c++ developer. I continually found my barrier was thinking "it can't just be that simple" when learning c# and overthinking the whole process. I found this book invaluable when learning c#: A programmers introduction to c#[^] It's clean, simple and gets to the point without replicating a lot of stuff you already know. The biggest thing to learn in c# isn't really the language itself, you can pick that up in a couple of days if you're an experienced c++ programmer, it's the .net api which is huge, however that's the good thing about it since it contains so much stuff you never need to write yourself. My productivity shot up with .net compared to c++ / mfc. It's not at all an exageration to say that I can develop an equivalent project in quarter or less time (my gut feeling is a tenth) than it used to take with MFC / C++. That's from the original idea on paper to delivered into end users hands debugged and stable. It took me about a week to learn enough to start writing winform apps in c# and the rest I pick up as I need it. Asp.net was actually the hardest thing to learn at first and even that was a dream compared to classic asp which I found a horrible nightmare of complexity. Whether it's a good fit for what you do or not you'll only know if you take the time to make a project of some kind with it, just something for fun. I find learning out of a book pretty much useless for retention, it's great for an overview to know what is out there, but nothing substitutes for jumping in and making an a
-
ghle wrote:
All user response times should be sub-second - anything longer needs recoded!
very true, but even java should be capable of writing a GUI with that as the only limitation. C# will beat Java hands down, and C++, although faster, will sometimes generate slower code for GUIs depending on the API chosen. The rest of the results are completely in the air depending on the programmer. Bad code can be written by anyone, including and experience programmer when he steps out of his speciality. Life in the real-time world rarely has UIs, but I have done enough of them to use a large variety of environments including C#, though I have delivered no C# GUIs to any customer yet. As long as you don't do something obviously detrimental to speed, and the programmer is competent (those two kind of go hand in hand, but every programmer, even experienced ones sometimes make silly mistakes), you should be able to get a GUI to subsecond response on any modern language. The back-end stuff is where the details are. And depending on the needs you can call a power-number-mashing DLL from C# (or Java as one of our team has done). So the real queston on which primary language to use is a very difficult one to answer, partly depends on the skill sets you have, and also depends on the over all goals of the project and the company. If you want everything uniform, do you stick with C++ with C++ GUI operations? do you hybridize your operatons with core functionality in C++ called from a C# front-end? That is where you start aligning pros and cons to each and the significant cost associated in man-hours. C# GUI's are cheap in labor costs, but learning curves for retraining for the larger core sets would be more significant, and not always worthwhile to the run-tme operations speed. Hybrdizing is a cheap alternative, but cheap GUIs up front, hard-won DLLs on the back. C++ all the way around may be desireable because of one language, one training set, one, one, one. Not a bad idea in some situations. The hard decision is what is good for your project or your company, the impossible decision is what one choice is good for everyone. There is no answer for EVERYONE, there is only the answer for each person, each group, each company.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
El Corazon wrote:
very true, but even java should be capable of writing a GUI with that as the only limitation.
Which reminds me of one more limitation. Writing code for handheld devices, I don't have the plethora of languages available for the PC. Starting out in Windows CE, it was VC++ only, then Visual Basic was added, then later upgrade to WinCE OS and VB support went away. Then VB was back. Finally, MS ported over development from separate IDE to VS 2005 which opens the doors to other languages. (Personal feeling was it was done to foist C# and .NET upon us.) But still supporting older stuff, VC++ & VB are the only available languages to us. Monopolies suck! Anyone know of alternatives to MS for Mobile development for WinCE? :mad:
Gary
-
El Corazon wrote:
very true, but even java should be capable of writing a GUI with that as the only limitation.
Which reminds me of one more limitation. Writing code for handheld devices, I don't have the plethora of languages available for the PC. Starting out in Windows CE, it was VC++ only, then Visual Basic was added, then later upgrade to WinCE OS and VB support went away. Then VB was back. Finally, MS ported over development from separate IDE to VS 2005 which opens the doors to other languages. (Personal feeling was it was done to foist C# and .NET upon us.) But still supporting older stuff, VC++ & VB are the only available languages to us. Monopolies suck! Anyone know of alternatives to MS for Mobile development for WinCE? :mad:
Gary
ghle wrote:
Anyone know of alternatives to MS for Mobile development for WinCE?
not really alternatives per se, but different. WxWidgets uses native code as the base, so it is the same as coding on the platform, but it is a common method of doing so on multiple platforms.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
If you want the speed of C++ and create modern GUIs, take a look at Delphi from CodeGear. There's a free version around too so you can experiment (google Turbo Delphi Explorer, too lazy too lookup the url myself rightnow)
> Then you've only used .NET apps written by horrible coders. I will make this dead simple and easy then. Show me the RAM utilisation and CPU utilisation under medium to high load of those 10+ apps that are so carefuly written. I will bet the average commit will be at least 250MB (probably far, far higher) out which 200MB (calculate the % yourself ) is nothing but bloat. Does that not show you there is no quality and lasting love in another Java revolution? : ) Serious though, I hope a screenshot of task manager at high frequency updating is not too much to ask for, and forget your sleeps to 0 and 100 if you can (large desktop, decent size windows, no clipping-tricks ). > with absolutely no noticeable lag. You just chose to ignore it, try harder :) count the page faults, number of times and average time GC took for all, swap hits, try use explorer or file open dialog at the same time, peaks especially, you can use perf counters. There is a lag in the best of apps out there, and there is RAM commit that swaps the cache most of the time. And if those apps are of any decent complexity you will see what it means to be cache, RAM and graphics efficient in native mode and speed up of around 100 fold for carefully written stuff as you say. It is possibly to write GDI this way (windowless and with DirectX, Bjarne showed it first I guess), and see what it means to be 'cache resident'. GDI+ is mathematics, and bad C++, that poor bridge to enabling those WinForms in .NET. > It's hard work of course, but that's the nature of programming in general. .NET makes making the GUI easier; it > > does not relieve you of your responsibility to make the application efficient. I agree but the problem is you do not control any of it nor its destiny. It is already widely consider legacy in WPF community (elite of higher order bloat) and even slower variant is what you will be sooner or later forced into. I will agree though Mark Up (the anti WinForm/Swing/WFC camp) has been the way forward since before XAML, and .NET for that matter but if you introduce runtime, you shall pay beyond what machines will ever handle, price for poor scalability of System.Object kind and silly startup times of basic things such as a single button and a tab on a Window. Oh yes and writing something as silly as new Rectangle, new Size :-) That is the only GUI or non-GUI trend I see (and yes I write WinForm bits, to keep up with whatever next 'cool bloat' wave might be, however you are likely to port into yet another wild
-
Hamed Mosavi wrote:
We rarely need to use third party libraries
Yeah that's a *major* difference, we used to have *many* third party libraries for everything from reporting to encryption. Many of those were no longer required in .net because they were built in, however we probably have even more third party libraries now with all the new features, but they are never an issue like they used to be.
Hamed Mosavi wrote:
It took years to learn these in C++.
I know what you mean, but once you get into .net you will realize how much of that knowledge is just not relevant or required. There is no where *near* the learning curve, particularly if you are an experienced c++ developer. I continually found my barrier was thinking "it can't just be that simple" when learning c# and overthinking the whole process. I found this book invaluable when learning c#: A programmers introduction to c#[^] It's clean, simple and gets to the point without replicating a lot of stuff you already know. The biggest thing to learn in c# isn't really the language itself, you can pick that up in a couple of days if you're an experienced c++ programmer, it's the .net api which is huge, however that's the good thing about it since it contains so much stuff you never need to write yourself. My productivity shot up with .net compared to c++ / mfc. It's not at all an exageration to say that I can develop an equivalent project in quarter or less time (my gut feeling is a tenth) than it used to take with MFC / C++. That's from the original idea on paper to delivered into end users hands debugged and stable. It took me about a week to learn enough to start writing winform apps in c# and the rest I pick up as I need it. Asp.net was actually the hardest thing to learn at first and even that was a dream compared to classic asp which I found a horrible nightmare of complexity. Whether it's a good fit for what you do or not you'll only know if you take the time to make a project of some kind with it, just something for fun. I find learning out of a book pretty much useless for retention, it's great for an overview to know what is out there, but nothing substitutes for jumping in and making an a
Thanks John. It was really helpful. Thanks for the book as well. At the moment I'm reading a design pattern book, thanks to CP guys to help me find a good book. As soon as I finish the book, I'll try to work with .net, again and more seriously.
John Cardinal wrote:
The biggest thing to learn in c# isn't really the language itself
Absolutely, I misused the word. This is what I say to most of my friend, and now I'm making the same mistake:doh:. In fact I now a little bit of c#, what frightens me is .net and huge set of functions, managing events, threads, sockets, etc. Main concern about memory will fade out soon, with memory getting cheaper every day. Less development time would be the tempting goal towards learning the new framework and language. Anyway this was really informative. Thanks.
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
} -
Thanks John. It was really helpful. Thanks for the book as well. At the moment I'm reading a design pattern book, thanks to CP guys to help me find a good book. As soon as I finish the book, I'll try to work with .net, again and more seriously.
John Cardinal wrote:
The biggest thing to learn in c# isn't really the language itself
Absolutely, I misused the word. This is what I say to most of my friend, and now I'm making the same mistake:doh:. In fact I now a little bit of c#, what frightens me is .net and huge set of functions, managing events, threads, sockets, etc. Main concern about memory will fade out soon, with memory getting cheaper every day. Less development time would be the tempting goal towards learning the new framework and language. Anyway this was really informative. Thanks.
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
}Events and threading is so dead easy in .net it's unbelievable. Trust me it won't take you any amount of time at all to get up to speed on it. Sockets I've never worked with directly in .net as there are so many high level network related methods.
Hamed Mosavi wrote:
Less development time would be the tempting goal towards learning the new framework and language.
Yeah, for me that's critical, we have a small shop and .net allows us to put out some pretty impressive and large scale apps that would really be nearly impossible in any kind of reasonable time frame in mfc / c++. Also the 3rd party stuff like reporting and UI is so easy to work with in .net and easy to deploy and support etc that I've gone from using 3rd party stuff as sparingly as possible to now having a policy of not writing a line of code for anything I can just buy which speeds up development that much more again. Anyway, good luck with it and at the very least you'll know enough to know it won't work for you if that's the case.
Modo vincis, modo vinceris.
-
cwp42 wrote:
C# is slow
Yes, C# is slow, but the question is about GUIs. There is no such thing as a real-time GUI per se. User operations are signficantly slower than any well designed implimentation in C# or Java making interface-majority work fast enough by a significant margin. You don't get into speed differences until you start handling major 3D or mathematical operations. For instance coding a particle system with proper variable G based on altitude above the earth for high altitude motion models combined with atmospheric effects (also variable based on altitude) such as drag, and air resistance. Once you get into the higher math on large numbers of objects the speed loss of C# becomes significant. But under a GUI, I doubt even I could tell the difference and I know what to look for. A GUI is limited by the user and therefore the computer is idling more than 99% of the time waiting for user response. A computer, no matter how you slice it, is still faster than the eye-hand response time. If there is a reason other than a GUI for speed, then fine, there is a large majority who make fun of me for using C++, when I list all the features there is usually a snippy response "well if you are doing that you should expect a slow-down anyhow." or maybe even a slight give-in and an exception made. Still, there is a reason why a new version of C++ is coming, there are is a significant enough market for real-time or extremely fast operation environments where C# is just not good enough. But GUIs are definitely in the C# wins over C++ category.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Sounds interesting. Do you think that it is a good way / usuall way to create the GUI in C# and the programming logic in C++ ?
cwp42
cwp42 wrote:
Do you think that it is a good way / usuall way to create the GUI in C# and the programming logic in C++ ?
good is a relative term, and outside of jokes or a nudge in the ribs, you won't get me to say one thing is always better than another. Is it useful? yes. Is it always the best approach? no. Is it a good idea? maybe, sometimes.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)