Hi i really wanted to know if i am in the right section or not to ask this question how ever ...

I have already learned the basics of C++ and C++/CLI i have learned C++ for building gui for desktop applications 
and now i am just learning the basics of java nothing more just to use Android studio to build android apps 

how ever now i am having some problems with the desktop applications for building gui ...
 which is the best and faster language C++ / C# or java ?
I am currently using C++/CLi  (Clr) in C++ but i see many peoples says that Qt is better i have already used Qt but i didn't like Qt and i like clr much more and i also see that many people says that for building gui C# is the best choice while the others says that C++ is faster than C# so what is the best way i have to choose ...
Do i have to complete in learning C++/CLi and continue bulding gui apps in it or i have to learn C# or i have to use Qt answer me please

C++ has the potential for better performance.

You can try to write perfect code or you can write code that is good enough to get the job done. I would suggest the latter.

My point is...choose whatever language you are comfortable with that will result in a finished product. I would submit that focusing on readability of code and a well thought out, well executed, and extensible design is more important than performance.

About writing a GUI...nothing says you can't write the GUI in one language which is well suited to high level GUI stuff and the logic in a different language well suited to performance.

In the example of a web application...you can write the back-end code (where speed matters) in C++, the web app code in Python and the GUI in JavaScript/XHTML markup.

3 hours ago, User134 said:

how ever now i am having some problems with the desktop applications for building gui ...
 which is the best and faster language C++ / C# or java ?

Interesting jump in thinking.

So you think switching to another language will make code run magically fast enough? Sorry, but that will not work, in general.

Some languages have compilers that generate very fast implementations of your program, for a certain area of problems. To get there, you must have a problem that fits in that area, and you must have deep understanding of the language, the compiler, and the computer hardware. By smart combining this knowledge, and organizing your code such that all three things work together, some magic can happen.

That is about it.

If you have a problem that doesn't fit in that area, or you have no clue how a compiler translates your program or you have no idea how to exploit your hardware for maximum efficiency, it won't fly.

Is all lost then?

No, it is not. What I was talking about above is the last 10% of speed, AFTER you already made sure your code has a proper design, and is efficient in itself. The latter saves you 20-10000% (or more) in speed, and works for any language. It also works for any problem area.

The basic idea is

• Solve the problem in the right way,
• Don't write stupid code.

And reading it like that makes it look much more trivial than it really is

The first item is about how to structure your code, and when to do what and where. The second item is about algorithms and data structures. If you have to compute something, setup your data in a smart way so it can find the right things quickly.

After a few decades of programming, I know how to avoid "write stupid code" pretty well, the "solve in the right way" is more tricky, but generally works, and the speedup of the last 10% I know somewhat, but I never really bothered about. A new computer generally helps more (for as long as Moore's law holds), so it's not worth my time.

Back to your problem, a Gui application is generally not time critical, so if you need more speed, you're likely doing something not right in the 20-10000% range of speed. The last 10% speedup of switching to another language won't rescue you even if you had all the knowledge that you need.

So I would suggest, attack the performance problem by trying to understand why it is not as fast as you want it. You may want to take that piece of code out of the Gui (assuming it's a computation you're doing) and run eg a profiler on it to see where it spends its time. That should give you ideas how to speed it up.

If it is an intrinsically long computation, you may want to change how you organize the Gui code, you may want to investigate how to combine long calculations with the Gui code that you use.

You guys didn't actually get what i meant i see that people says that c++/cli is not the same for c++ like gcnew , ^ pointer etc ...

And they says mfc or qt is better i have already used both of them mfc and qt but i didnt like both of them so i can continue on using clr ? 

1 hour ago, User134 said:

And they says mfc or qt is better i have already used both of them mfc and qt but i didnt like both of them so i can continue on using clr ? 

So, your question is basically I've been using this stuff to build GUIs, but there's some people that say that other stuff is better, what should I use?

To which my answer is: use whatever you like. There's always going to be lots of options and people with different preferences than you. If you like working with C++/CLI and it does the job, what's holding you back?

If high performance does not really worry you or you are going to craft some tools or desktop applications (you didnt say it will be for games) I would use C# (.Net) or Java (JavaFX or Swift).

You can build a tottally user friendly (well, it depends on your usability skills) GUI like any Windows desktop application in 1-2 days, using standard controls and windows. I've never worked with Qt, but I heard its a bit tricky, and .Net is easy cake (I mean development and learning curve will be much lower than Qt).

Im not sure if you were talking about that

1 hour ago, User134 said:

You guys didn't actually get what i meant i see that people says that c++/cli is not the same for c++ like gcnew , ^ pointer etc ...

And they says mfc or qt is better i have already used both of them mfc and qt but i didnt like both of them so i can continue on using clr ? 

How about you put all the back-end low level logic (the stuff that you want to run fast) in a C++ DLL. Then write your GUI (the stuff that can run slow because humans will always run slower) in the high level language of your choice. Then call the C++ DLL from your GUI code. Gives you total freedom to code in the GUI language of your choice without effecting performance. Added bonus is that as long as the interface that the DLL and front-end GUI code does not change, you can change the code in either piece without having to recompile everything.

On 8/5/2017 at 8:51 AM, Avalander said:

So, your question is basically I've been using this stuff to build GUIs, but there's some people that say that other stuff is better, what should I use?

To which my answer is: use whatever you like. There's always going to be lots of options and people with different preferences than you. If you like working with C++/CLI and it does the job, what's holding you back?

This is one of the forever on going comments made by other programmers. "Don't use x language because x language is better." When you're dealing with what I call main stream programming languages, for just GUI based applications it all comes down to using the language that lets you make the application on your target platform, and use what you know if you can.

You can get the job done in so many ways, and I wouldn't be focused on this ongoing debate with language wars. I've built 2D level editor applications through C#, C++, JAVA! Doesn't matter! I've used different APIs, heck I've used the Allegro Library and programmed my own GUI classes for buttons, menus, text input, event managers, ect... The programming language itself is a tool you use to craft your application, so don't get caught up in which language is better, it's so minimal with languages like C++, C#, and JAVA.

Focusing on objective requirements and constraints instead of tastes should be more productive.

• Are you writing a portable application, a Windows-only one or a Linux-only one? The choice of GUI frameworks depends on their availability.
• Do you need (or prefer) a desktop GUI, or a somewhat interactive web application? There's little overlap of suitable technologies.
• Not clear from your post: did you learn real C++ or C++/CLI? If the latter, why didn't you just learn C# instead? Are you restricted to .Net technology?
• Would you be comfortable and productive with Java or Python? If not, the respective very good and very portable GUI frameworks are not an option.

On 5/8/2017 at 4:28 AM, User134 said:

I have already learned the basics of C++ and C++/CLI i have learned C++ for building gui for desktop applications  ...  i see many peoples says that Qt is better

I always found Qt nonsense to say the least - it carried on because it's slightly better than the alternatives but it's a behemoth in itself. If you're doing GUI apps C++ is most likely the worst language/ecosystem you can pick. 

When you talk GUI, the solution is very well established IMHO: Angular. Wait, what?

When I first heard of Flash to be used for game GUI years ago I thought it was terribad idea. But then there has been CSS3, V8 performance improvements, browsers are the most powerful layout engines around they can do everything you want, with HTML5 you're pretty much done across all operating systems and sorta recent browsers. Qt can follow as much as they want but browsers can be compiled in the app nowadays. How does Atom work being CoffeeScript and Javascript and what I'm shooting at?

Under no circumstance I will consider GUI part of my application Never, ever again. 3D we can talk but GUI stuff, I won't touch those things anymore with a ten foot pole. I'm doing "service" style apps right now so I have it easy: pop out an HTTP/websocket server and have the GUI in the browser. If I'll have to do a stand-alone web app I'll look into electron, let it put it bluntly: the GUI wars are over, browsers are the winners and your users expect it too. As far as I am concerned any GUI not running in a browser is dead or a dinosaur allowed to live in some specific ecosystem. 

Or, you could elaborate on your true, specific needs. Perhaps that would get us somewhere.