[C++] Developing Windows applications with forms

[whitebread]

I want to develop a (native) Windows application in C++ with forms. Right now I am using CodeBlocks as my IDE. I found this link (http://www.winprog.org/tutorial/) under the thread titled "Newbie C++ Help" but I have heard that the tutorial is not very good (plus, it is in C not C++).

What is the best way to learn how to write C++ Win32 applications with forms? Is there an IDE available that can automate the generation of the code when designing the form?

Edit: Would Visual C++ 6 (before all this .NET crap started) be the best way to go?

[boogerjones]

  On 13/12/2011 at 07:55, Dr_Asik said:

You're referring to C++/CLI, which is a different language. It's not C++. Microsoft did not introduce non-standard features in C++: they created their own language to interface with .NET, while providing a standard C++ implementation as well.

He's actually referring to C++/CX, which is not a different language, but a Microsoft-authored extension to C++ for interfacing with WinRT when targeting Windows 8 Metro-style applications. It's syntax is very similar to C++/CLI, but the underlying implementation is different.

[articuno1au]

  On 13/12/2011 at 00:35, xorangekiller said:

Fair enough. I don't really program too much in Windows anymore (at least with GUI's) and I have never really liked "the Microsoft way". That said, a GUI may be useful for some things, such as your example of ASP.net (which I have never used, and probably never will).

I completely agree with this. What works for me is not a cookie cutter layout. Every programmer needs to find his stride -- and stick with what works best for him. We are not programmers because we enjoy doing things the way everyone else does them. We are programmers because we enjoy creating new things. If something doesn't work as desired, the average user will either accept it or work around it; the average programmer will try to improve it.

Really? I have always thought that the debugger was its greatest strength. Don't get me wrong, I think that intellisense (and to a lesser extent, the error messages) are great too, but Microsoft really does have a nice debugger. I love GDB, and use it on a regular basis, but there is just something about the ease-of-use of Visual Studio's debugger that is really appealing.

You love me, I can tell :p

The intellisense is practically a tutorial in the sense that it allows you to work through the methods/properties in a particular class until you find what you need.

If you will excuse me dropping back into C#.net for my example:

System.Threading.Thread..

->http://msdn.microsoft.com/en-us/library/system.threading.thread.aspx

You can work through it by pressing down until you find what you want and then work with it.

I am fully aware that other IDEs allow you to do this so long as the class is properly commented, but MS has gone to the effort to do so.

I do also agree the debugger rocks, which is what I was (trying to/) getting at with the last part of my post >.<

[iKenndac]

OT: Why all the .NET hate here?

Answers from people who've used it and have an opinion based on experience appreciated!

[articuno1au]

Same question from me.. First page in fact.

I've never understood it.

[KomaWei]

  On 13/12/2011 at 10:58, iKenndac said:

OT: Why all the .NET hate here?

Answers from people who've used it and have an opinion based on experience appreciated!

The only reason I hate it is because Microsoft devotes all their time to that, rather than fix their broken crappy native api's. Instead of creating a modern api, they do everything for .NET, while native developers get screwed over.

[Karl L.]

  On 13/12/2011 at 10:58, iKenndac said:

OT: Why all the .NET hate here?

Answers from people who've used it and have an opinion based on experience appreciated!

At least for me, its not really the content or idea of .NET that I don't like, its the implementation. Essentially, .NET is a "just another library" that is designed to aid the developer with designing his application. I have no problem with that. In fact, I think that you will have a hard time finding any self-respecting C++ developer who refuses to use third-party libraries to get the job done. On the other hand, .NET does some things that other libraries do not do -- its bad practice. For instance, if you look at the design of the widely respected Boost libraries, they strive to implement everything using standard C++ syntax, accepted convention (that of the C/C++ standard library), and to be as low-resource as possible.

Microsoft, on the other hand, likes to use their own, often awkward, syntax in .NET classes and functions that, while technically legal, is not nice.

Although .NET (and Microsoft in general) does not use the naming convention of the standard library, I could excuse that if they were consistent. I am of the firm opinion that it doesn't matter what your naming convention is, but it is critical to pick one and keep it. Although, as far as I can tell, .NET's naming convention is consistent within each version (.NET 4, for example), they like to change things and cause breakage between versions. (To their credit, however, they do a good job of keeping MSDN up-to-date when they make changes.)

So far, everything that I have mentioned is annoying, but workable. The thing that bothers me the most about .NET, and the main reason I don't use it, is how resource-heavy and non-portable it is. In some cases, its integration can be a good thing, but in most cases it is not. In my opinion, it is just another (heavy) layer that sits between my program and the operating system. While it does some nice things, I won't sacrifice the extra overhead and extreme lack of portability for a little bit of extra functionality (which I can usually get using standard libraries or the win32 API).

  On 13/12/2011 at 11:58, KomaWeiss said:

The only reason I hate it is because Microsoft devotes all their time to that, rather than fix their broken crappy native api's. Instead of creating a modern api, they do everything for .NET, while native developers get screwed over.

This I disagree with. Although Microsoft does devote extra resources to .NET, they certainly don't neglect the win32 API. In fact, how could they, considering that their operating system is written in C? Every new release of Windows has added new functionality to the API, including Windows Vista and Windows 7. Although I'm not exactly sure what your definition of a "modern API" is, I suspect that it has something to do with object orientation. Considering the language that Microsoft has chosen for their win32 API up to this point, that doesn't seem likely. In fact, if MFC is an indication of what they would do with object orientation, I don't think I want it.

[Joey S]

  On 13/12/2011 at 10:58, iKenndac said:

OT: Why all the .NET hate here? Answers from people who've used it and have an opinion based on experience appreciated!

For me, if I'm going to take the time to learn a VM/interpreted language, then I'd rather learn/use one that is well supported across all platforms. For instance, Ruby, Java, Python, Perl, Scheme. All of those truly open and patent unencumbered. DotNET multi-platform support/compatibility is flaky at best, and non-existent at worst.

[Karl L.]

  On 13/12/2011 at 16:26, Joey S said:

For me, if I'm going to take the time to learn a VM/interpreted language, then I'd rather learn/use one that is well supported across all platforms. For instance, Ruby, Java, Python, Perl, Scheme. All of those truly open and patent unencumbered. DotNET multi-platform support/compatibility is flaky at best, and non-existent at worst.

I knew that .NET was implemented that way when used in C# and VB.NET, but I didn't know it worked that way with C++ as well. One of the things that makes C++ so nice is the execution speed. One more black mark against .NET, I guess.

[Max Norris]

  On 13/12/2011 at 16:26, Joey S said:

For me, if I'm going to take the time to learn a VM/interpreted language, then I'd rather learn/use one that is well supported across all platforms. For instance, Ruby, Java, Python, Perl, Scheme. All of those truly open and patent unencumbered. DotNET multi-platform support/compatibility is flaky at best, and non-existent at worst.

The platform isn't virtual or interpreted; the compilers generate a platform/CPU agnostic binary that's compiled again at runtime into native code on the client machine so it's optimized for whatever it happens to be running on. Obviously not as fast as a purely lower level language, as that's not what it was built for, more for easy portability between platforms (web, mobile, and desktop can use the same code) and development speed. As far as multiplatform goes, no arguments there, but that's really Mono's fault, not Microsoft's. Mono has a lot of catching up to do. Good stuff for desktop/web applications that are 99% of the time waiting on user input anyway, not so much for stuff that's performance intense.

[iKenndac]

  On 13/12/2011 at 14:58, xorangekiller said:

(snip)

Thanks for your detailed and thoughtful post! :) It's very interesting to hear, and I can't really disagree with any of it, especially coming from the C++ point of view.

I've only used .NET with the C# language, and I quite enjoy it there - but then again C# and .NET were kinda designed for each other, I feel.

Anyway, I'll stop derailing the thread now. Sorry!

[articuno1au]

  On 13/12/2011 at 14:58, xorangekiller said:

At least for me, its not really the content or idea of .NET that I don't like, its the implementation. Essentially, .NET is a "just another library" that is designed to aid the developer with designing his application. I have no problem with that. In fact, I think that you will have a hard time finding any self-respecting C++ developer who refuses to use third-party libraries to get the job done. On the other hand, .NET does some things that other libraries do not do -- its bad practice. For instance, if you look at the design of the widely respected Boost libraries, they strive to implement everything using standard C++ syntax, accepted convention (that of the C/C++ standard library), and to be as low-resource as possible.

Microsoft, on the other hand, likes to use their own, often awkward, syntax in .NET classes and functions that, while technically legal, is not nice.

Although .NET (and Microsoft in general) does not use the naming convention of the standard library, I could excuse that if they were consistent. I am of the firm opinion that it doesn't matter what your naming convention is, but it is critical to pick one and keep it. Although, as far as I can tell, .NET's naming convention is consistent within each version (.NET 4, for example), they like to change things and cause breakage between versions. (To their credit, however, they do a good job of keeping MSDN up-to-date when they make changes.)

So far, everything that I have mentioned is annoying, but workable. The thing that bothers me the most about .NET, and the main reason I don't use it, is how resource-heavy and non-portable it is. In some cases, its integration can be a good thing, but in most cases it is not. In my opinion, it is just another (heavy) layer that sits between my program and the operating system. While it does some nice things, I won't sacrifice the extra overhead and extreme lack of portability for a little bit of extra functionality (which I can usually get using standard libraries or the win32 API).

This I disagree with. Although Microsoft does devote extra resources to .NET, they certainly don't neglect the win32 API. In fact, how could they, considering that their operating system is written in C? Every new release of Windows has added new functionality to the API, including Windows Vista and Windows 7. Although I'm not exactly sure what your definition of a "modern API" is, I suspect that it has something to do with object orientation. Considering the language that Microsoft has chosen for their win32 API up to this point, that doesn't seem likely. In fact, if MFC is an indication of what they would do with object orientation, I don't think I want it.

I disagree with the "just another library" part. While that certainly is a part of .net, the bigger part is managed memory, CLR, CodeToWeb etc etc.

It's the functionality that allows you to develop rapidly, and deploy semi optimised code across the board. The CLR environment certainly slows things down, but not by as much as a lot of people think. Back when .net released there was HUGE slowdowns across the board. Over time Microsoft have been making it better and better. The best part of CLR, however, is the ability to debug code JIT with SERIOUS debug information and full stack trace without having to rely on static symbols.

This means if a program spazzes out, you can really "step in" (hurr) to the program and work out what's going on.

I recently saw a development experiment where a group wrote a game in C#.net with DirectX and a parallel C++ execution. The game was fairly small (due to it being written twice >.>) but it performed well inside the boundaries you would expect a C++ game to run, and within 3-4% of the C++ version. Before you ask for sources, I am going to jump in and say I can't provide it :\ I just don't have it any more and haven't been able to track it down without access to my University's library.

There are a lot of more recent looks into CLR and performance degradation that show minimal slow downs.

Regarding Porting: Inside the Windows ecosystem, it's fully portable. Outside of it :| I also blame mono.

Lastly: LINQ. Love it. LOVE IT LOVE IT. Have my babies LINQ! :p

  On 13/12/2011 at 17:44, xorangekiller said:

I knew that .NET was implemented that way when used in C# and VB.NET, but I didn't know it worked that way with C++ as well. One of the things that makes C++ so nice is the execution speed. One more black mark against .NET, I guess.

As above >.<

  On 13/12/2011 at 18:08, Max Norris said:

The platform isn't virtual or interpreted; the compilers generate a platform/CPU agnostic binary that's compiled again at runtime into native code on the client machine so it's optimized for whatever it happens to be running on. Obviously not as fast as a purely lower level language, as that's not what it was built for, more for easy portability between platforms (web, mobile, and desktop can use the same code) and development speed. As far as multiplatform goes, no arguments there, but that's really Mono's fault, not Microsoft's. Mono has a lot of catching up to do. Good stuff for desktop/web applications that are 99% of the time waiting on user input anyway, not so much for stuff that's performance intense.

This. So many people do not understand what .net is from a CLR stand point.

The performance part is becoming less and less true, but /shrug.

  On 13/12/2011 at 21:28, iKenndac said:

Thanks for your detailed and thoughtful post! :) It's very interesting to hear, and I can't really disagree with any of it, especially coming from the C++ point of view.

I've only used .NET with the C# language, and I quite enjoy it there - but then again C# and .NET were kinda designed for each other, I feel.

Anyway, I'll stop derailing the thread now. Sorry!

I don't think this thread is derailed. I think this is exactly what a forum should be about >.<

We've answered the question and the topic has evolved :)

I'm quite enjoying this conversation :p It's nice having someone like Orange/Max to talk to/debate with.

Very interesting to get other perspectives :)

[Andre S. Veteran]

  On 13/12/2011 at 08:44, boogerjones said:

He's actually referring to C++/CX, which is not a different language, but a Microsoft-authored extension to C++ for interfacing with WinRT when targeting Windows 8 Metro-style applications. It's syntax is very similar to C++/CLI, but the underlying implementation is different.

Oops, looks I didn't keep up with the news lately. Thanks!

  Quote

The thing that bothers me the most about .NET, and the main reason I don't use it, is how resource-heavy and non-portable it is.

Apart from some specific libraries (WPF, Winforms), .NET is portable to any OS that runs Mono: Windows, Mac OSX, Linux. If you're going to use Win32, you're stuck on Windows anyway...

As for using a lot of resources... .NET has some very smart resource management and in C++ you'll have to do it yourself anyway. Possibly better, but possibly a lot worse. Assuming you didn't override operator new, this:

MyType m = new MyType();[/CODE]

is orders of magnitude slower in C++ than in C#. C++ will actually make a call to the OS who has to find enough contiguous space on the heap. And then you have to remember to free it (which also takes time), and then you still have to deal with fragmentation. In C#, this operation amounts to incrementing a pointer, and memory freeing and compaction is done in batches, automatically. It's not free, but it's done well. If you want similar performance in C++ you'll have to implement something equivalent yourself. C++ is not, by itself, any faster, much the opposite in fact.