I want to do RAD with C, but the only ones I can find only use C++.
Check out Glade, a UI designer for GTK+.
You may have to define what you expect when you use the term RAD. Technically is is a methodology agnostic of language (see http://en.wikipedia.org/wiki/Rapid_application_development, to understand what I mean).
If you mean "visual development" (which is the context in which it is applied to tools such as Delphi and C++Builder, primarily as marketing buzzwords and because Microsoft had already essentially trademarked "Visual" with respect to development tools), then use of C would require an application framework and tool to support this. There is a reason why such tools are usually implemented with object-oriented languages; it is a much more natural fit for GUI elements. This being the case, a tool vendor would be unlikely to choose C as the basis for such a tool.
Also it may be useful to understand what platform(s) you wish to target.
A judicious bit of Googling threw up a couple of things that may fit your requirements:
Auto-C
MGui
You may use BCX DevSuite Pro. It comes with GUI Designers that produces BCX code. When you compile BCX code, it produces also C code.
Related
I'm getting more and more confused in regards to C's supersets the further I venture into the programming world. There's just so many versions.. C, C++, C#, Objective-C, Objective-C++ and God knows what else.
I only know tidbits about these languages (some are object-oriented, some are procedural, C was originally developed for UNIX, C++ started as an extension and is used primarily on the Windows OS, Objective-C is primarily used on Linux and Mac OS/iOS, etc), but I'm not even sure that what I know is correct.
I would just like someone to shed some light on what I "know" - a little bit more information about which are successive versions, which platforms each are generally used on, which are the best versions to learn, etc if anyone is feeling generous. :)
Update
Also, I hope to eventually start native (without needs of plugins, such as the .NET framework) application development for Windows and Mac, so can anyone confirm that I would need to learn C++ for Windows and Objective-C for Mac?
C++ started life as "C with classes", in which Bjarne Stroustrup working at AT&T sought to add features like methods and inheritance to C structures in a way that requires as little support from a runtime library as possible. The classes added to "C with classes" are very heavily influenced by the Simula language. It's since grown to include a number of other features, some of the important ones being generics, lambda functions and an expressive standard type library.
Objective-C started life not too dissimilar from its current state, except that it was originally implemented as a C preprocessor. Brad Cox, at his company Stepstone, wanted to combine the power of the Smalltalk object-oriented model with the performance of C native execution. Objective-C uses a dynamic message-passing system to dispatch calls to objects, a design that's directly opposed to C++'s goal of doing everything in the compiler. Thus while objc and c++ start from the same base, the results are very different.
Both of the above language authors also published books explaining the design intention behind their respective languages. Cox's book is long out of print, but both are worth reading if you get the chance. Stroustrup's publications list
Objective-C++ relies on the fact that GCC (or LLVM) can generate code in either language, so the compiler writers allow you to use features from both in the same source file. There are some limits on what's possible at the boundary layer, and Objective-C++ is mainly used either to adapt a C++ library to an Objective-C app or to use STL or Boost data types from C++ inside an Objective-C class.
Finally, languages like C# and Java are not C supersets or C descendants at all. They use C-like syntax to provide some familiarity (and perhaps to avoid having to think about designing a de novo language syntax) but are different beasts that work in a very different way.
You're mixing up the name of the language and what that was meant to imply.
C was first, procedural and low level non-generic (at least not type-safe) as you may know.
Then C++ originated as C with classes, and templates. Later this evolved into something that sets itself apart from C more and more, expanding its standard library in each step. C++ is a multi-aradigm language, meaning it has stuff for procedural, generic, functional (a little) and object-oriented programming. Don't forget about Boost as a powerful extension to the Standard library.
Objective-C is a C expanded with numerous runtime facilities (like messages) to ease object-oriented development. Objective-C++ is the same extensions applied to C++, staying compatible as much as possible with the original language.
C# is something entirely different. Think of it as a hybrid between Java and C++, although that will set bad blood with users of all three languages. It has a garbage collector.
(Objective-)C used primarily on Linux is not entirely correct. All of KDE is C++, for one. C++ primarily on Windows isn't entirely true, the OS API is all C. What Microsoft made of a C++ API (MFC/ATL) is a living hell. Microsoft is pushing C#, along with associated .Net stuff a lot. So think of C# as mostly Windows, although there is ongoing effort to create a cross-platform .Net alternative (mono). Apple's Foundation APIs are Objective-C, but the underlying OS APIs are all still C.
"Supersets" is a wrong terminology. C is not a subset of C++. Both share a common subset. Only Objective-C(++) is a pure superset of C(++).
As to the best versions to learn: the latest, obviously, perhaps limited to the compiler support on the various platforms you will write for.
The software's algorithms are all written in C.(gcc compiler). And I need some beautiful and friendly UI for this small software...But I have no idea what language and what library and what tool I should use.
I need some idea from you guys. thanks indeed!
If you can say it more specific, I will thank you more!
It would be better if you are more specific with your question and give more details about your software. Because designing a UI interface depends on a lot of factors.
I am listing some below for your reference:
On what system are people going to use it? (Windows, Linux etc)
Users are novice users or advanced users (You can decide on a CLI for advanced users and more detailed colourful GUI for novice users who need a lot of help)
Do you have any specific requirements like the GUI should be light weight?
So, please determine the requirements first before deciding what language and what library you must use.
For starters, you can look at ncurses library in linux, MFC in Windows. I don't know much about Java, someone else must be able to help you on that.
All the best for your work!
Commonly used libraries for GUIs:
Tk which was written in Tcl and has bindings for Python, Perl, Ruby, Lisp and a few others
GTK, which is written in C (so you could write your GUI in C) and has bindings for most languages under the sun
Qt, which is written in C++ and also has a number of bindings
These are the "big three" for cross-platform toolkits (I know some will disagree). They have their advantages and disadvantages: Tk looks good on some platforms but not others, and there aren't too many bindings for it, GTK looks great on Gnome desktops but so-so elsewhere, and Qt looks good in KDE but okay elsewhere.
You have to ask yourself a few questions: what platform will you be deploying to? What kind of functionality do you need? What languages are you most comfortable writing the interface with?
I'd recommend that whatever language you choose, choose a scripting language of some sort. It's far easier to create interfaces using scripting languages IMO (though Qt makes C++ interface design fairly painless). I'd also recommend you pick a language that will be available on your platform with as few dependencies as possible (so for Linux, Python or Perl would be a good choice).
Are there any plugins for visual studio (any version) or any other ide that can show you the standard library function prototypes and their (examples) , return etc for the standard c library... much like the java code helper found in eclipse if I am not mistaken (I am not a java developer but I think I saw something similar to what I described).
note: I know I can use google or msdn but I am asking about other alternatives.
Visual Assist X is by far the best C/C++ improvement for Visual Studio.
Edit in response to userHel's comment:
I'll give it a shot. but how come nobody came up with a free version
Probably because it's really hard to do well. You practically need an entire compiler just to parse C++ sufficiently to give the kinds of features VA-X does. At the other end of the stack, you would also need an almost flawless integration with Visual Studio. Just imagine what's in between...
This is where firstborn selling comes in...
KDevelop4 has good C++ analysis support which is constantly improving, including features which I think were inspired by VAX. I haven't used VAX so I can't comment on feature parity, but it has all the C++ features I need. Of note is the tooltip when holding the mouse over an identifier, which gives type info as well as links to the definition (and declaration if available).
For linux development, the man pages are excellent. I'd like to know of something similar for Windows.
Is there a pdf or video or some media that can inform me on how to program Winforms with C++. Obviously C++ is the most common programming language and I already have some prior knowledge. But when I try to find media about programming in C++, the examples are usually Console applications. I want some media that can teach me how to program Winforms in C++.
Here's a tutorial showing how to write Windows Forms applications in C++/CLI.
Just be aware that most samples tend to be in C#. Many people purposely use C# for the forms, C++ for their logic, and use C++/CLI to expose their logic as .NET assemblies (For easy use by C#/VB.NET). This helps, since the design-time experience is much nicer in C# or VB.NET for Windows Forms.
Bad idea, IMHO. Managed C++ is ugly; it was never meant to be a garbage-collected language. Its strength lies elsewhere. I recommend C# instead - similar syntax, highly marketable skill.
Preemtive snarky comment: all C++ is ugly.
Have you looked at the MSDN articles? I'm not saying I recommend this, but they do at least give a start.
As far as Seva Alekseyev's comment that all C++ is ugly: it's like the old comment about democracy being the worst form of government except for all the others. He's right that all C++ is ugly, but fails to mention that all the alternatives are even worse.
Just create a new C++ .NET project and start programming your C++. And additional syntax applies to .NET is managed pointers and .NET classes. Information about them you can find in MSDN, including lots of useful examples.
Well, there are opinions all over the place on this topic. My motto is always to use the right size hammer for the job-- and, in general, C++ is the wrong size hammer for making winforms. I love C++, but I only use it when there is an absolute necessity for speed of operations.
C# (or VB.Net, if you must) has MUCH better support for UI creation than C++, though I have noticed that Visual Studio 2010 offers some much needed enhancements to make developing Winforms easier in .NET 4.0. If you MUST stick with C++, look into obtaining a beta version of Visual Studio 2010. Otherwise, use C# as your UI, data access, file manipulation, general purpose language and C++ if you have to write a custom physics engine to go with it.
I am in the beginning stages of creating software for a mISV-to-be. The program is a desktop application and in the long run I want to have a native version for both Windows and OS X (I have a looked at various cross-platform APIs, and none of them meet my needs). Initially though, I don't think it makes sense to develop for two platforms at once. With that in mind, I have been looking at WPF for Windows and Cocoa for OS X, and they seem similar.
Has anyone had experience porting one to the other? Are there particular techniques/paradigms to follow that will make porting easier? Ignoring business considerations, would you recommend developing on one of them first?
Well. Once you've written an app for Cocoa, it is possible to port it to Windows. This could be done using gnustep or Cocotron.
If you do it the other way, WINE is meant to make porting easier.
I would rather write the OSX version first. This is because Windows users have no clear idea what they want an application to look like. In my experience, they are quite able to suffer through all kinds of user interfaces. Consistency has little value to them. Since there is no common agreement, what a Windows app should look like, nothing stops Windows users from actually liking OSX designs, and they even frequently do. iTunes for windows looks like a very typical OSX app and you hear very few complaints that it would not be enough Windows-ish.
Going the other direction, this is not true. OSX users have a clear preference for Cocoa apps and very little tolerance for, as an example, things like GIMP or Inkscape which work under OSX just as well as anywhere else, but look plainly ugly to the OSX trained eye.
I think that you're on the right path by choosing windowing environments that are specific to each platform. This approach allows you to create a user experience on each platform that isn't restricted by the compromises inherent to cross-platform windowing toolkits.
A good first step is to break your design down into two parts: platform specific and platform neutral elements. You can already put any UI code into the platform specific column, but maybe your app will need some data persistence that can be written in platform-neutral C++. What you may find with this approach is that there is quite a bit of logic and infrastructure that you can write in a platform-neutral way, leaving just the UI and glue code as platform-specific.
There was a recent episode of Late Night Cocoa titled Porting Large Applications to the Mac platform. Your app may not qualify as "large" but this podcast gives quite a bit of great porting knowledge from someone that's done it a few times.
I'm currently working on porting tools in this space and have many years of oft-painful experience in either using or writing cross-platform frameworks on Mac and Windows.
One of the biggest problems in the past has been Apple's refusal to open up the nib format for Cocoa (Carbon nibs were open XML files years ago). That changed with XCode 3 and the .xib format, as well explained by Frasier Speirs.
At the basic layout level, at least, there is now an opportunity to automate porting from one XML format to another. I regard WPF (XAML) as cleaner and so I'm using that as my base format and migrating to Cocoa.
When it comes to the code behind, whilst you can use C# under Mono, the CocoaSharp project seems either stalled or very slow and I wouldn't recommend it.
If you are comfortable with C++, consider having as much logic as possible in C++ with a thin platform-specific layer in C# and Objective-C.
Another approach worth investigating is using a dynamic language like Python or Ruby. I'm not sure which is more mature at present between IronPython and IronRuby but both are now supported by Microsoft people. On the Cocoa side, I think the flexibility of Ruby syntax will triumph and RubyCocoa is probably overtaking PyObjC.
Otherwise, work in C# and Objective-C and maintain two completely independent code bases with identical designs. Fortunately the frameworks have comparable semantics for most things, especially if you make use of bindings.
Well, there is not a straightforward path. The best method is to use something like Model-View-Controller pattern or some other architecture to separate business logic and so forth from the presentation. However, unless you are using Mono, there will be very little code for you to share, I think.If you are developing WPF then you surely doing .NET and, other than Mono, Objective-C is the standard programming tool under Mac OS X.
Keep a good design and you can have most of your code simply be an Objective-C version of your .NET code and vice versa rather than trying to find a migration path.