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"
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 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.
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 10 years ago.
Recently i start to studying C/gtk+ programming. And want to ask one question: what are the IDEs available for C/gtk+ development apart from command line interface?
Thank you.
In my (biased) opinion and experience, you're better off learning GTK by command-line compilation and your favorite editor (gedit, kate, vi, emacs, whatever). This way, you can learn at your own pace rather than trying to grapple with a big complicated IDE that really isn't beginner-friendly. Nonetheless, be aware of devhelp (GTK's development documentation program) and try building a couple GUIs with glade3 and using them in your C programs.
This might not be the answer you want, but I feel that C/C++ GUI IDEs tend to suck, at least for beginners.
Anjuta can do C/GTK+, but I personally wasn't very impressed with it. It asks you what plugin you want to open .glade files with, new projects are built with autoconf (resulting in a mess of over 70 files for a simple "Hello world") and localized with gettext by default (resulting in a bunch of boilerplate code in main.c), and it pops dialogs like this when you invoke weird edge cases such as double clicking a button you just created:
My impression of Anjuta from the perspective of a beginner was, as you can tell, highly negative. It shows a whole lot of advanced options, but doesn't let you do basic tasks without a lot of hassle. Anjuta is not alone. In general, I don't believe I've ever found a (mature) C/C++ IDE for any GUI toolkit that was easy for a beginner like me.
There's really nothing all that special about GTK+, it's a pretty standard C API and so any IDE that lets you program C is going to work well for GTK+. Examples include Eclipse and Code::Blocks.
You can also use Glade as RAD tool for developing GTK+ GUIs in a graphical way. Use of Glade is pretty much IDE-independent, though.
Personally I find that Eclipse CDT and Glade make a pretty good combination. Eclipse doesn't need you to use Autotools, etc. If you're under Debian/Ubuntu, I'd recommend manually installing Eclipse instead of using the repository version.
Eclipse or Anjuta IDE. I found Anjuta IDE comfortable.
NetBeans has a pretty good C/C++ suport and if you want a designer I'd second Glade. I personally prefer Emacs + Semantic + ECB for C development.
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.