As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
i see that the C gui libraries are very less. Well the most prominent was GTK and alike. i dont see any prominence of C projects with GUI. Either C is not preferred for GUI. I see for like programming languages like C++, Java and Python, there are more GUI libraries and are more abundant. So what i ask is why does C not have a GUI lirary in surplus like others. Is it because of the absence of object orientation? mostly i see C used in console modes. Even in some system programming, other than that its either C++ or something else for GUI programming. Should one stop GUI design in C and go for other languages? I wish to know this in detail.
I'll speak to the Windows API since that's the one I'm familiar with, but I suspect the others are the same. The Windows API is pure C! There's no need for a "library" to wrap it up, you can program to it directly.
The GUI components make for a good object hierarchy, so it's popular to package them in a C++ wrapper to make them easier to work with, but it's not strictly necessary.
Most GUI libraries work with objects (windows, buttons, widgets, frames, etc.) and properties and such. This is hard to emulate in C, while it is much easier in OO languages like C++, Delphi, C# etc. Note that the underlying APIs these frameworks use are often C, but much more awkward to use than the frameworks.
Since C doesn't natively support any kind of GUI calls, you're going to need
to rely on libraries provided by your system (such as the Windows API or the
Mac Toolbox (pre-OS X)) or a third party (GTK, QT).
Based on the very few times I've done it, I'd say that C is absolutely the
wrong tool for writing GUIs. Depending on the library, it can go from being
merely tedious to downright torture. You have memory management issues out
the wazoo, funky data structures, fairly complex pointer expressions
(something like ((*foo)->bar) wasn't uncommon) . You have to ratchet up
your definition of a "small" program by an order of magnitude.
C doesn't include a gui library but neither does C++.
Most GUI libraries are written in C++ because they began in the mid-late 80s at about the same time that OOP became popular. If you are going to invent a new user interface paradigm you might as well use the new programming paradigm - the more buzz words the better.
There are some natural fits between OOP and GUIs, but you can write a GUI in pure C.
C is a language, it's up to an operating system to provide an API to it's GUI interface.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am working with some legacy C code which I need to refactor and generally clean up, to remove spaghetti type programming, adhere to the DRY principle etc.
I was thinking of rewriting using C++, but I don't want to go that far, and would like to remain as close to C as possible (whilst using some OOP concepts [without having to hand code them]).
I recently came across GObject, Vala and Genie. The latter two are fairly recent. Is anyone out there aware of either Vala or Genie being used in production code ?
Last but not the least - is there a list of Pros and cons comparisons between the two languages. I am leaning a bit towards Genie because I love Python and am not too keen on C#, but Genie's (apparent?) insistance on tabs could be a tad annoying in practise - I'd be interested in a list of pros and cons for the two languages (assuming one or both of them are ready for production use).
As an aside, I am developing on Linux, so any windows related issues are not relevant as far as I'm concerned.
Unity, the user interface used by all recent version of Ubuntu, uses Vala.
Here is a list of applications developed using Vala. Some of these are part of the default GUI install of some major GNU/Linux distributions.
And as to Genie: It is another language (with Python like syntax) understood by the Vala compiler. So it really is just a matter of which syntax you prefer (In my opinion). Here is a quote from the Genie language guide, that seems to say the same thing:
Genie is very similar to Vala in functionality but differs in syntax
allowing the developer to use cleaner and less code to accomplish the
same task.
Like Vala, Genie has the same advantages:
Programs written in Genie should have have similar performance and resource usage to those written directly in Vala and C
Genie has none of the bloat and overhead that comes with many other high level languages which utilize a VM (e.g. Python, Mono,
Java)
Classes in Genie are actually GObjects so Genie can be used for creating platform code like widgets and libraries where GObjects are
required for binding to other languages
If you don't like TAB characters, you can use spaces instead:
[indent=2] //two space indent instead of TAB
init
print "Hello World"
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking into a hobby of writing a toy programming language, partly from minor annoyances with other languages, partly so that I can understand what it's like, but mostly just to fool around.
On the off chance that it gets really useful, I don't want it to depend on the run-time of another programming language for programs written in it to run. That is, I want the interpreter / compiler to itself be a program compiled natively into the target OS (language itself may be interpreted / provide a run-time).
Is there any alternative to doing this besides C? What are some advantages / disadvantages or using each?
Clarification 1: I am not intending to go low-level enough to write kernels, filesystems, device drivers, boot loaders. However I would like to be able to manage my own memory.
Clarification 2: Due to a terminology error / misunderstanding, and since I was so used to the C runtime running on various OS's, I said that C does not have a runtime / and or I am not interested in a runtime. A better way to say what I really want is that my programs compile natively into the target (desktop) OS without needing to install additional software from the bootstrapping language.
2.1: if I write the compiler/interpreter in python, I don't want the emitted executables to depend on the python program.
2.2: if I use a compiling step, for instance, to compile the programs using perl, I don't want the emitted executables to depend on a libperl.dll/so.
2.3: the exception is with runtimes is C since the C runtime is usually installed on almost all desktop OS's as many core OS tools depend on it.
You could use any language that has an existing compiler that emits native code without dependencies. C and C++ are pretty good bets because their runtimes are available pretty much everywhere (even more so in C).
One approach in your language build-up that could be well worth trying is this: make your compiler output C (or C++). Then you can use all the existing ecosystem around those languages and their runtimes (linkers, object dumpers, debuggers, etc...), even plan integration with existing code.
Those tools would be useful both for the users of your language, and obviously for yourself while you're experimenting on that toy language.
Once you get to the point where your language is "self-hosted" (i.e. your compiler is written in your own language), you'll be able to start thinking about doing away with the whole C part and write a native code compiler, with its runtime.
Good luck :-)
Also make sure you go look at LLVM. It's a "compiler infrastructure". That is probably the best place to start with these days to implement a new language. The documentation is pretty good, and the tutorials include building a toy language.
C has a runtime... C++ has a slightly bigger minimal run-time than C. Some implementations of Ada have pragmas allowing to check that some features mandating the use of a run-time aren't used (I wonder if they weren't standardized later, I've stopped to follow Ada standardization in the late 90's), making it perhaps having a minimal run-time of the same compexity as C.
PyPy usses RPython to implement python language. Will this work for you?
Haxe is written in OCaml, and I think this is a really good language for writing other languages.
http://haxe.org/
http://caml.inria.fr/
If your going to write bootloaders and kernels then C is your language, otherwise it doesn't matter what language you use to develop your language. Just because your host language has a runtime doesn't automatically mean your target language must have one.
But ofcourse toy languages need a runtime, for example a JVM/LLVM/.NET CLR. Or interpreters. If you don't go for these choices you need to generate machine code that conforms to a ABI, and that is very painfull.
I suggest you look target llvm and generate machine code from there, dalvik might also fit your needs (since it is extremely lightweight).
I think Python is best for you. Python is a programming language that you can work more quickly and integrate your systems more effectively. You can learn to use Python and see almost immediate gains in productivity and lower maintenance costs.
Python, recently, has been ported to the Java and .NET virtual machines.
The most important, Python is free.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Does anyone have any experiences in learning the language Eiffel.
Is the Eiffel Studio like Visual Studio?
Is it a good route to take to learn OOP?
etc.
I learned this language about 15 years ago and never regret it.
Eiffel is a bit different from mainstream languages and features some mechanisms not readily available in other environments. In some sense it's a bit more academic than mainstream.
EiffelStudio environment takes some approaches that are not present in average IDEs as well. (For example, it supports Pick&Drop facility which is similar to Drag&Drop, but does not require to keep mouse button pressed as you drag the selected item.) It provides pretty advanced browsing facilities, so in this sense it's quite close to Visual Studio. It also has several built-ins like Diagram and Metrics tools, recently added AutoTest, etc. You can have a look at EiffelStudio documentation to get an idea about its features.
Since the language lacks hacks to introduce basic types, supports multiple inheritance and generic types and integrates Design by Contract right from the beginning, it is extremely good as a learning tool for OOP even if you do not plan to use it on a day-by-day basis. For that purpose I'd recommend "Object-Oriented Software Construction", 2nd Ed. by Bertrand Meyer. It does not include the most recent additions to the language, but it does provide a good route to OOP as a whole.
I think it's the best route to take for OOP, since it does object orientation very well.
I haven't seen an oop language that is as clean and consistent with regard to object orientation. therefore it's beneficial for a student to see how it should be done right.
As a language, if you contrast it with the scripting languages such as python, rebol etc. it's more heavy-weight. Best for large projects where you want to maintain quality. It focuses entirely on proper object orientation. (so you will not see all concepts of programming, but OO is a major paradigm)
Its speed is very good, as it compiles down to C, so I only meant heavy-weight about the structure.
It promotes iterative development, and thought-out design, so that's also a good technique to have.
You can read the Eiffel Tutorial to get a thorough overview, but take it gently, as it's a hundred pages "tutorial".
I actually think students who are being taught OOP should learn on the easiest language possible so they struggle with the concepts more so than the language. I learned on both Java and C++. The former was OK, but the latter was a nightmare. Python would be my suggestion
With regards to Eiffel, I tried doing my PhD project in Eiffel and I ran into serious problems. I would definitely not recommend using the GUI as there is little to no documentation on it. Also the compiler is very buggy. I was constantly in touch with their support regarding completely bizarre behavior. For example putting a print statement would solve a compile time error!
Eiffel provides some of the best multiple inheritance options, but even that can turn into a nightmare sometimes. I remember inheriting from multiple classes which all inherited from one main class, then having to SELECT one redefined function out of them, or to have to RENAME a function.
The design by contract was a good addition, and the variant helped avoid infinite loops, but at other times you just looked like an idiot when you had checks like these (my Eiffel is a little rusty)
foo (something)
do
x = x + 1
ensure
updated: x == old x + 1
There are other minor problems too. Often times the Eiffel studio would get corrupted and you had to erase certain back up files to get it to work.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I always find good tutorials on the subject, but it almost always is C++. Is it hard or just doesn't make sense to make GUI applications with C?
A good book, guide or a tutorial is fine.
Platform: Linux
Use GTK+. It's written in C and exposes a well-designed C API. Their tutorial is quite excellent.
GTK+ is the toolkit for GNOME, so your applications will fit right in with many Linux desktops.
If you are programming in C on Windows - Petzold's programming windows used to be the bible for C based ui work.
EDIT:
Since I answered my question the post has been updated to be on Linux. I will leave the post here for anybody looking, but it really does not apply to Linux.
Many high quality GUI were written in C with, for example, Windows API. There's no particular reason why not, but object oriented programming was very successful in modeling interactive graphics. GUI elements somehow map naturally into C++ objects that can encapsulate complex behavior behind a simple interface.
It's hard enough (or, mostly, verbose enough) that most people figure it just doesn't make sense. The GUI part of an application (mostly) reacts to user input, so in this area speed is rarely critical -- a difference of a few microseconds (or even milliseconds) rarely makes much difference. As long as responses appear within 100 ms (or so), they're pretty much perceived as "instant".
Dynamic typing also tends to work quite nicely for a lot of GUI programming. C uses only static typing.
Don't.
Use python and then bind the computationally expensive calls written in C.
What is the best way to design GUI Applications with C?
don't, if you don't have to :-)
Is it hard or just doesn't make sense to make GUI applications with C?
It is not necessarily that hard, but a pretty redundant and verbose task (like writing high level programs in assembly language), with lots of repeated boilerplate code.
Personally, I find it more rewarding to simply embed a scripting interpreter (e.g. Lua, Nasal) with bindings for a GUI library and then code the UI in a high level scripting language and code only the core of the application itself in C. Python was previously mentioned, but I think that a dedicated extension language like Lua would be a better fit, because it doesn't bloat your source code and because it does not create any additional requirements (like library dependencies or architectural).
In other words, embedding something like Python, Perl or Ruby may be relatively straight forward (because of good documentation and community momentum), but often these languages are more complex than the host application itself.
This is also the approach taken by the AlgoScore software, which uses an embedded Nasal interpreter with GTK bindings.
If you're on a *nix system, you can use Xlib. But you're probably better off programming in C++ and calling out to your C code.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As a big fan of Charles Petzold's books Code and The Annotated Turing I came across his book Programming Windows which teaches Win32 programming in C. I am a freshman computer science student who learned C first, but I use C# and .NET for Windows programming now, so I was wondering if Win32 is still relevant to professional Windows programs. Would it be worth it to me, as a student who wants to program Windows applications, to learn the Win32 API to the depth that the book covers?
It really depends on the kinds of applications you want to develop. For most purposes these days, C# and .NET are completely suitable. However, there are certain kinds of applications that need as few dependencies as possible (shell extensions come to mind) that are not practical to do as .NET applications. For those you would need Win32.
As always, it pays to have at least a basic understanding of Win32 even if you're using .NET for most of your work.
I completely agree with what Joel Spolsky writes in one of his many great articles. I think it is crucial to know the lower layers of the machine not only to be able to write quality code but to be able to solve problems that will inevitably appear.
So, YES, it is important to at least know the basics of WIN32 API maybe not in depths but at least to know it's there, at the base of everything you will code.
It's very relevant if you are writing C# on Windows. Not all the features of the Win32 have been exposed via the .Net libraries. A concrete example of this is the WM_SETREDRAW message technique I describe here: WM_SETREDRAW. It's also needed at other times for control focus issues.
Also, understanding how Win32 and Windows work will give you a better understanding of various aspects of C#/.Net such as:
What does Control.Invoke() actually do?
What is the difference between Control.BeginInvoke and Control.Invoke?
What actually causes my control's events to fire, e.g. OnClick etc and how can I debug that.
That said, WPF changes all this and if you are only writing .Net 3/3.5 code then my argument loses some its relevance.
In my opinion, no. I learned it a long time ago, so you wouldn't have to!
I think it's great that you learned C first, and I'd keep writing C programs now and then, but I don't see why the win32 API would be useful to dig into. Honestly, it was a big mess.
I think it's important to learn the basics. If you learned just enough to display a window with some fields, some buttons, and a menu. Maybe draw something in a separate window. It would help you learn the fundamentals of how Windows is really working. I believe understanding the message loop and the realization that almost everything you see is a window are fundamental things that everyone should know. My eyes were really opened the first time I realized that a button was it's own window. It then helps you understand that features of things can be turned on and off by sending these windows messages. Subclassing windows let's you get access to features not exposed to you in things like .NET or VB Classic and let's you enhance the window's functionality.
Definitely learn the basics as AlexDrenea mentions. Whilst .NET shields you from a lot of Win32 API Calls. Win32 API is so enormous you're bound to run into situations where .NET hasn't wrapped it for you.
A real life common situation sort arrows on ListViewColumns
I don't really think "learning Win32 API" is realistic for anyone. The APIs (yeah, there's more than one) are huge, and you will hardly ever need to know all of them in detail. I would recommend reading up on some basics (i.e. Window creation, window messaging, window procedures, maybe some GDI, etc.) and using MSDN to look up the rest whenever you need it.
As per Greg's comment, it is to some extent domain dependent. I do a lot of Windows CE / mobile programming, where .NET is too hoggish for many devices and other frameworks such as MFC aren't fully implemented. In this context, much of Win32 is still very relevent.
That said, I wouldn't go learning it all upfront, I'd simply go through the basics, and dig out the rest as and when I needed it. The documentation and examples out there are good enough for this approach, as is the online help available from communities such as this.
Unless you need some functionality that is not in the .NET Framework (such as getting detailed info on printer drivers), no. That's about 99% (of course, an arbitrary value I just made up) of what you'll do.
Even if you were using Win32 and not .NET, is there really a need to learn the same depth as the book? Browse thru the sections, learn that if you encounter some problem in the future you know where to look for it. Then stop. Go in depth when you need it or have the free time.
I think it's already been answered but if you do .NET 2.0 development or anything winforms in .NET, you're bound to run into a lot of problems with how some parts of the framework is wrapping win32 and mfc and you'll need to dig into that to actually get stuff working as intended.
If you're trying to solve Business Problems, then there's better tools out there than C for programming Win32 systems. Clarion. Delphi. And others I have no doubt.
But I guess for learning how things work you're in good stead with C.
Some stuff can not be done without win api calls but with each version of .net those things become less and less so no i would not learn the win api if i where you..
You have to know it exists, since most of the native functions of more "advanced" managed language end up calling them.
Plus it can be encapsulated in script languages like Autoit with DllCall
I'm still earning part of my money using it. We do have a C IDE which is based on the WinAPI. It's now around for 15 years or so, and still running ;-). The complete download of it is around 5 MB for that you do not get anything in the .NET world. So for us it's still a valuable thing....
This has been discussed many times on Professional Win32 api Newsgroup (
news://comp.os.ms-windows.programmer.win32)
(by the greatest gurus and best-sellers authors (Petzold, Russinovich, etc) in the world...)