What applications, special compilers do I need to make a GUI interface in C coding?
Printable View
What applications, special compilers do I need to make a GUI interface in C coding?
No special compiler needed. You may need some extra tools such as a "resource editor" [that is what you use to design dialogs, icons, menus etc].
Which architecture is this for?
--
Mats
Windows Vista.
What are some good free 'resource editors' ?
Get Visual Studio express - it comes with a good resource editor, compiler and IDE. It's in my opinion the best IDE for Windows.
--
Mats
Thanks again Mats
Will Visual C++ compile C as well?
Yes, but you have to set it to compile the code as C code (otherwise it will happily compile C code that is valid C++, but may choke in cases where C and C++ differ, and produce object code with C++ name mangling). If I remember correctly (but I may be wrong), there is limited or no support for new features introduced in C99.
Actually, it chooses "intelligently" based on the filename. If you call a file "something.c" it compiles as "C", if you choose the name "something.cpp", it will compile as C++.
--
Mats
Also if I'm not mistaken (and I very well could be. :P) using the CL command from the visual studio command prompt compiles C code, at least it doesn't seem to compile any of my C++ code. :p
Why would you want to write a Windows program in C instead of C++?
Because? There's no reason not to use C, after all the Win32 framework is written in C.
If you write it in C++ and plan to have an OO program, you have to create classes that essentially wrap the precedural Windows API functions anyway. You also have to use char arrays (or similar) instead of std::string when using buffers with the Windows API functions that require them. My point is that even if you decide to make an OO framework, you still have to write a relatively decent amount (depending on the size of your framework/program I suppose) of C-style code anyway to glue your OO stuff to the procedural style of the Windows API.
Essentially, depending on what you want to do, you can write Windows GUI code in either C or C++. It doesn't matter how you interface with the API or with your program, except with whatever is easier to write for and interface with from your own perspective.
Sure, if you want to reinvent the wheel for every program you write... There's a lot of code out there that already does most of the work for you (some free, and some for sale).Quote:
Originally Posted by MacGyver
As for passing buffers to C functions, you can use std::vector for that.
That is a silly question. You may as well ask why people use C++ instead of VisualBasic or C#. I've been using straight C since 1998 and have never been limited on resources or code production times. Plus it creates smaller and faster executables.Quote:
Originally Posted by cpjust
Preferance, I guess. I can't see how someone wants to write a C program seeing how it lacks OO and good functionality such as smart pointers, vectors, etc.
Well VB & C# aren't portable. But if you want really small & fast programs, why not go a step further and program in assembly? ;)Quote:
Originally Posted by Welder
I'm not saying there's no use for C. Sometimes you have to use C (or assembly), but since C++ gives you so many more tools to write and manage your code, why wouldn't you take advantage of those tools when the option is available to you? For example, in C you have to write way too much code to check if malloc() failed, free memory before returning, checking errno...
That's just a complaint against C in general. Hardly worth noting for GUI programming more than for CUI programming. ;)
And C is more portable than C++ - be consistent in your argumentsQuote:
Well VB & C# aren't portable
Barely. Unless you're using a brand new platform that doesn't have a C++ compiler yet.Quote:
Originally Posted by vart
A lot of the embedded systems, as in A LOT. There's nothing to gain by using C++ with Win32 just as there's nothing to lose by using C with Win32.
>Preferance, I guess. I can't see how someone wants to write a C program seeing how it lacks OO and good functionality such as smart pointers, vectors, etc.
I can't see how someone doesn't want to drive an automatic car with power steering.
That's a bit of a contradiction. First you say there's nothing to be gained by using C++ with Win32, then you say you can't see how someone doesn't want to drive an automatic car with power steering (i.e. C++).Quote:
Originally Posted by zacs7
As for embedded systems, how many developers actually write software for those compared to real computers (i.e. boxes with a keyboard, hard drive, monitor...)? Also, how often would you need to write software for both embedded systems and normal computers? Most of the time server software is written for Windows & UNIX (and sometimes also z/OS & AS/400), while end user software is made specifically for Windows or Mac.
Actually, I recall some guy who argued that "embedded programmers could build much better systems using C++ rather than C", and thus asked Why are you Still Using C? (Warning: PDF)Quote:
A lot of the embedded systems, as in A LOT. There's nothing to gain by using C++ with Win32 just as there's nothing to lose by using C with Win32.
> That's a bit of a contradiction. First you say there's nothing to be gained by using C++ with Win32, then you say you can't see how someone doesn't want to drive an automatic car with power steering (i.e. C++).
I put your argument metaphorically, because it's silly. The fact is, manual cars are cheaper and some people find them nicer to drive (not to mention they're cheaper to run). You basically said, why bother with gears? And all that shaz, if you can get the car to do it for you.
I still don't know what you're arguing about, C has a purpose just as C++ does. Whether those purposes overlap is relative to the job. Even if you could write must better embedded systems with C++, it doesn't change the fact that C is still widely used for the job.
I believe it started with me asking why you'd want to write a Windows program in C. Although the Windows API calls would be C function calls, the rest of the program would be easier and safer to write in C++ where you can use RAII objects...
But the thing is, even with C++, your "car" can still be made to drive on manual. In other words, you don't need to add "auto" functionality. And to further that silly argument, why do you think there are automatic cards? Because it's convenient, I tell you. People like that.Quote:
Originally Posted by zacs7
And even with an automatic car, what's to stop you from doing everything a "manual" car can? This argument is silly. C++ is pretty much better in all kinds of ways than C. C++ can do everything C does and it can also DO C!
Not to mention that I find it silly when you can create more robust code, getting things out of the door faster, etc. And an "auto" car doesn't necessarily need to cost more or draw more power to run - it's all up to how the design was made.
All in all, I find that argument very silly.
Don't turn this into a C vs C++ argument, it's stupid. It's like comparing pears and apples. A pear can do anything an apple can do (except roll ;)). I know auto's are convenient, but people also like to do things manually... cut out the middle man. FYI, no matter how you put it, the same car in auto vs manual will most likely cost more, more expensive to maintain and reduced performance. Why else do you think 'race' cars' aren't auto?
The car argument was purely a metaphor, don't take it literally. And no I'm not saying C is higher performing than C++, as you said it depends how the design was made. It's like comparing a hammer with a screw driver, sure you can hammer nails in with a screw driver, but why would you?
I'm only arguing that it's perfectly fine and viable to write your Win32 program in C, and there's no reason why you shouldn't. If you say C++ is easier for windows programs, blah blah blah, then why not use C# or even... Visual Basic?
Okay enough of the metaphors :)
I'm gonna go mourn the downfall of my country now... Labor won -- sigh.
Well, the only thing I can say is that there's plenty of reason to write Win32 programming with C++. Even though the API is C, C++ gives you a lot of benefits still. Again, it's just a matter of preferance, but let's not state it's silly to not write Win32 programming in C, which, I believe, was the original argument.Quote:
Originally Posted by zacs7
Please don't tell me we are really arguing over C vs C++? Unfortunately I cannot close a thread on the grounds of it being absurd.
Standard options for GUIs under Windows:
- MFC - Microsoft Foundation Classes
- Pure Win32 code
- C++/CLI
1. MFC is very easy but also very picky. If you are not an adept C++ programmer MFC will give you nightmares (and even sometimes if you are :D).
2. Pure Win32 is not much better and is fairly hideous looking code.
3. C++/CLI - C++ for .NET essentially. The CLI is easy to use but may confuse you when you come back to ISO C++ since C++/CLI is about as far from ISO as you can get. It's not bad for GUIs, it's still inherently C++, and it's very portable across Windows platforms or platforms that support .NET
In short your options for GUI's written in C/C++ are extremely limited and those written in pure C is nearly non-existent. I recommend using C# for GUI apps but if you are deadset on C/C++ I would favor MFC even though it's quite old.
That's just the thing - let's stop arguing by saying it's silly to write something in C++ simply because it's based in C. It works just as well in C++ as C. And let's leave it at that. Preferance.
The reason I use C is because the software I write ALWAYS needs to be fast. I rarely if ever find myself wishing I had OO capabilities. The software I write (or used to when I was in my prime as a programmer) were compilers, emulators/simulators, image/video optimizers and such. In many tests done at my old company C had been proven faster. If you have an app that is all GUI with very little CPU intensive code then C++ is perfect. You won't notice millisecond slowdowns here and there. But when writing a compiler to compile millions of lines of code in the shortest amount of time with the maximum readability of the source code, C is the best choice.
You say why not just use assembly? Well, as far as speed goes, C is the fastest mainstream language next to assembly. I find myself incorporating assembly language into many parts of my programs. But how many of you have had to read over thousands of lines of assembly code written by someone else? Or even yourself months before. I have. I was lucky enough to be the person in charge of converting about 10,000 lines of PowerPC assembly code and several thousand more of ARM7TDMI into C. I tell you, by the time I was done I was eating, sleeping/dreaming, crapping assembly code. I don't care how documented that code is, it leaves you staring and jumping around quite a bit to figure out what is going on. Even for the best assembly language programmers. On top of that, what happens when Microsoft decides to adopt a completely new processor such as Apple did when merging from the 68000 to the PowerPC, and then from the PowerPC to Intel's x86 series processors. Your nearly unreadable code is now completely worthless.
With that said, I am learning C# and Visual Basic .NET as we speak. I have written some code that needs to be fast and have use of pointers in C. I compiled it into a .dll and am writing my interface in Visual Basic and may merge my code over to C# as I am really enjoying it's similarity to my beloved C and C++. Then I just call up my .dll and all is good. :)
But if I had it my way, we would all be using the original object oriented programming language, FORTH. The OOP that was designed years before OOP was even thought about. :)
But I do agree with you that assembly doesn't necessarily need to be faster than optimized C/C++ code. Just remember, kids: the language only does what YOU want it to do! If you want speed akin to assembly or C in C++, then you can have it! :)Quote:
Originally Posted by Welder
I'm with Elysia on this. I have worked on C++ projects that are WELL optimized and would be very hard to manage to do with C - one involved emulating the exact behaviour of a chip, where a 5-bit register had to be a 5-bit register. Doing this:
in C and maintaining a 5-bit value would not be nice.Code:int5 x, y;
...
x = getsomething();
y = getother();
x += y;
I was asked by one of the senior managers if I thought we could speed it up by using C instead. My answer was "Probably less than 5%, and it would take far longer to achieve that, than it would take to save 5% by optimizing certain parts of the code". I spent several weeks profiling, analyzing the profiles, and improving the performance. One of the biggest gains was to put if-statements around certain logging calls [that normally didn't get output, so we'd check the output limit FIRST, then call the logging function ONLY if there was actually going to be an output. Just "calling a function that would just return" caused a whole lot of overhead].
C++ as such is not slow. It can be written in a way that produces slow and bulky code. Using STL is a choice that often introduces extra code and extra execution time - which is fine if your application is not terribly time critical, where time-to-market is more important, etc. As usual, it's often just a small portion of the code that is really performance criticial, and if necessary, you could always write THAT BIT in Assembler, plain C or whatever you think will give sufficient benefit.
--
Mats
The benefits in clarity, maintainability, and extendability that C++ offers to your project far outweigh any small performance degradations you may get.
I had really thought this debate was over a long time ago but I keep seeing it time and time again. IMO C++ has proven itself to be fast enough for the performance based applications. Nearly all of the video games at your local store were coded in pure C++. I doubt seriously anyone is still hanging on to their C API's.
I'm finding more often than not the people who make this claim are the same bunch that love to reinvent the wheel.
That's what engineers do best! :)Quote:
Originally Posted by Bubba
I'm with you Bubba. There was a time, a long while back, when I thought you couldn't write C++ OS code, but I'm convinced now that it's perfectly possible. It just requires a good steady skill of OOD, and some good thinking [and the latter is definitely needed if you want to do an OS in C too!]
Either that, or the people who have yet to do some serious programming in C++.Quote:
Originally Posted by Bubba
And I think, because C++ offers a richer set of functionality to the user, it can be confusing to new users. You definitely need more experience as a C++ programmer than you do as a C programmer, to write and maintain code well. At least, that's my opinion.
--
Mats
On the other hand, C++ code can be much easier to read than eqalient C code, so it's a good thing.
Depends on who wrote it, I'd say - and that goes for both C and C++. You can write messy code in both languages - in fact, it's probably easier to do in C++ [just look at the examples with virtual functions and default arguments for some ways to obfuscate the code].Quote:
Originally Posted by Elysia
--
Mats
Yes, I just saw how messy it can be - C++ almost as C, when making a game -_-
But I think that with polymorphism, classes and C++ functionality, written properly, the code will become easier to read and maintain rather than hard-to-read C. Of course, if using functions properly, you can write clean C, too, but I do think C++ is a little better in that department.