I have been handed a good-sized chunk of c-code that would be better packaged as an ios framework, that our apps may choose to embed in their projects or, potentially, distribute to 3rd party.
While following the instructions # https://github.com/jverkoey/iOS-Framework#first_parties, the question i am asking popped up in my mind especially that the idea of a rewrite in objective-c is daunting, given the schedule and my current level of objective-c expertise.
A minimal set/amount of Objective-c is fine, if necessary for language binding or some such thing.
The original code is written in C (it's designed to be portable) but makes extensive use of gcc macros and extensions.
Your advice would be highly appreciated!
Yes, the straightforward (though possibly non-trivial) approach is simply to write a wrapper around the C library. If you need to support Obj-C and C developers down the road, I'd move the very-core functionality into a C only library, and the write better libraries to access the core feature set for both Obj-C and C (if this is even needed), so that there's less extra "wrapping" happening.
The original code is written in C (it's designed to be portable) but makes extensive use of gcc macros and extensions.
Clang has a pretty good attitude and approach to supporting the GCC extensions. I'd keep an eye out for anything very esoteric, but you should be OK.
Related
What programming Shapr3D ipad app is written in?
I doubt it would be in Swift?
Previous versions of Shapr3D relied on C++ framework Open CASCADE Technology, and latest versions use Parasolid API (Parasolid kernel become available on iOS much later than open-source OCCT), which is referred as C-callable in some references. So I would guess that many portions of application should be written in C++.
The bindings to UIKit, however, should be written in either Objective-C/C++ or Swift, as Apple left no other choice to developers. The latter one requires more efforts for incorporating C++ code and I don't know if Swift gives any solid advantages over Objective-C++ for GUI development to make these extra efforts worthwhile.
These are just my guesses for a closed-source application.
I think that asking the same question on application's forum would have more chances to get reliable answer (although I barely see any use of such knowledge).
I've been browsing the DeHL repository on GoogleCode, and it looks really good to me.
Many interesting features that make basic programming tasks easier; Some neat things that are in the DotNet FCL, but are missing from the Delphi RTL can be found in this library;
Coded in a modern way, making good use of new language features;
Each class, record type, member function and parameter is documented in such a way that it'll show in the code completion of the Delphi IDE;
Well-organized and clean code;
Plenty of unit tests;
Open source and Free;
Basically, it looks like this library should've been included with Delphi, as part of the RTL.
One major drawback: The project has been discontinued. :-(
Now my question is:
Would it be safe to rely on this library for future projects, and use it as a base framework to build upon?
Basically I'd like to hear from somebody who's actually used this library whether or not it's worth it to invest time in getting to know this library, and why.
IIRC the project was discontinued because it was an over-engineered first attempt and a lot of its features turned out really messy and bloated. You should look at Alex Ciobanu's second attempt, which is simply called Collections. It contains most of the interesting features from DeHL, but leaner.
Be careful, though. It still makes heavy use of generics, which will make your binary size really big if you use it a lot, because the compiler team hasn't implemented a way to collapse duplicate code yet.
I'm new to Vala. I'm not familiar with GObject. As I understand it, GObject was spun off from the GLib project from GNOME. Correct me if I'm wrong.
I do like the syntax and implementation of Vala very much, yet it is not in my intentions to write desktop applications for GNOME.
I also know (think I know) that Vala does not have a standard library other than GObject itself.
So my question is: Can Vala be used without GObject and if it can, is it usable (are there optimal and maintained base libraries for common things like type conversions, math, string manipulation, buffers, etc... available)?
There is some other Vala profiles like Dova and Posix.
TLDR: I recommend using Vala with GLib/GObject, because it was designed on top of them.
While there may be alternative profiles for valac they are either unfinished or deprecated.
The whole point of Vala is to reduce the amount of boilerplate required to write GLib and Gtk+ applications in C.
It also adds some nice other improvements over C, like string and array being simple data types instead of error prone pointers.
It mostly wraps all the concepts present in GObject like:
classes
properties
inheritance
delegates
async methods
reference counting (which is manual in C + GObject, and automatic aka ARC in Vala)
type safety of objects
generics
probably much more ...
All of these concepts can be implemented without using GObject/GLib/Gio, but that would mean to basically rewrite GObject/GLib/Gio which doesn't make much sense.
If you don't want to write GUI applications GLib can be used to write console applications as well, using GIO or GTK+ is optional in Vala, applications work on a headless server as well.
I think that there is even some effort in Qt to eventually switch to the GLib main loop, which would make interoperability of Qt and GLib much easier.
A good example of a framework that uses GLib is GStreamer which is used across different desktop environments as well.
In summary:
GLib is a basic cross platform application framework
GObject is the object system used by the GLib ecosystem
GIO is an I/O abstraction (network, filesystem, etc.) based on GLib + GObject
GTK+ is a graphic UI toolkit based on GLib + GObject + GIO + others
GNOME is a desktop environment based on all the "G" technologies
Vala is a high level programming language designed to reduce the boiler plate neded to use the "G" libraries from the C language.
GTK+ originally came from GIMP and was since split into the different "G" libraries that are the basis for GNOME today.
Vala also has very powerful binding mechanisms to make it easy to write so called "VAPI" files for any kind of C library out there.
With the correct VAPI bindings you don't have to worry about manual memory management, pointers, zero termination of strings and arrays and some other tedious things that make writing correct C code so difficult.
Here is another profile that you can use Aroop. (Note it is still under heavy development). What I hope is it is good if you need high performance. Please check the features here.
I've written a Haskell library I would like to include in an iPhone app. It makes heavy use of Haskell's functional abilities, currying, etc. and rewriting in Objective-C would be tough.
Is it possible to automatically translate Haskell to C? or dig out an intermediate C representation from one of the compilers?
Apple's developer agreement forbids statically linking one of the lightweight Haskell interpreters, not that I'm keen on that solution.
I haven't used it but there is
http://projects.haskell.org/ghc-iphone/
http://repetae.net/computer/jhc/ compiles to fairly standard C. It might be possible to use it.
Have a look at the ghc-ios project:
http://www.reddit.com/r/haskell/comments/1lboh4/announcing_ghc_ios/
I have recently spent several years translating legacy FORTRAN into Java. Prior to that, I found myself translating FORTRAN into C (for which I wrote a simple translation tool). After all this work, I find myself wondering how many others are doing similar language-to-language translations and whether an automated way of doing so would be beneficial.
I know about F2C, For_C, F2J and others, as well as some of the translation sites, but none seem to be all that successful. Having seen output from For_C, I can see why it just hasn't taken off. While it is technically correct, it is very difficult to maintain.
So, I guess what I am wondering is if there were are tool that produced more maintainable, more grok-able code than the code I have seen, would developers use it? Or are developers as jaded as many posts seem to indicate and unwilling to use generated code as it could never be as good as their manually translated code?
In short, no. Obviously time restraints necessitate it sometimes, but...
Rarely is code written in one language going to translate well to another - every language has certain ways of doing things that are more suited to the constructs available / common libraries / etc.
Consider for example a program written in C as compared to something written in Python - certainly you can write for loops and iterate through things in Python just as easily as you can in C, but it is much simpler to use list comprehensions and take advantage of the features the language provides.
I'd be surprised to see an example of a reasonably sized program written in any language that could be translated into 'correct', well-maintainable code in any other.
This was already covered to some extent in Conversion of Fortran 77 code to C++, but I'll take a stab at it here.
I think there's a lot of time wasted translating legacy code to new languages. It takes a phenomenal amount of time and energy to do, and you introduce new bugs when you do it.
Joel mentioned why rewriting from scratch is a horrible idea in Things you Should Never do Part I, and though I realize that translating something to a new language isn't quite the same as rewriting from scratch, I claim it's close enough:
Automated translation tools aren't wonderful because you don't get anything maintainable out of them. You pretty much have to know the old code to understand the new code, and then what have you gained?
To port something manually, you have to know how the code works to do it well. Rewriting code is seldom done by the original developers, so you seldom get people who understand everything that's going on to do the rewrite. I worked at a company where an outsource team was hired to translate an entire website backend from ColdFusion to JSP. That project kept getting delayed and delayed because the port team didn't know the code at all. Our guys never quite liked their design, and they never quite got it right, so there was constant iteration as everyone worked out all the issues that were solved in the original code. Then, the porting itself took forever.
You also need to be familiar with really technical inconsistencies between languages. People who are very familiar with two languages are rare.
For Fortran specifically, I now work at a place where there are millions of lines of legacy Fortran code, and no one here is about to rewrite it. There's just too much risk. Old bugs would have to be re-fixed, and there are hundreds of man-years that went into working out the math. Nobody wants to introduce those kinds of bugs, and it's probably downright unsafe to do it.
Instead of porting, we have hybrid codes. After all, you can link Fortran and C/C++, and if you make a C interface around your Fortran code, you can call it from Java. Modern codes here have C/C++ components that make calls into old Fortran routines, and if you do it this way you get the added benefit that Fortran compilers are screaming fast, so the old code continues to run as fast as it ever did.
I think the best way to handle this is to do any porting you need to do incrementally. Make a lightweight interface around your old fortran code and call the pieces you need, but only port things as you need them in the new part. There are also component frameworks for integrating multi-language applications that can make this easier, but you can check out Conversion of Fortran 77 code to C++ for more on that.
Since programming is hard, no such tool can really exist.
If it was trivial to change one language into another, the idea of "compiler" would be moot. You'd just map the language you liked into the language of the hardware, press the button and be done.
However, it's never that simple. Each VM, each language, each API library adds nuances that are just impossible to automate.
" I can see why it just hasn't taken off. While it is technically correct, it is very difficult to maintain."
Correct for F2C as well as Fortran to machine language. The object code generated from most compilers can't easily be read by people. Either it's cruddy or it's highly optimized. Either way, it doesn't look a thing like an expert human would write in the assembler language for that hardware.
If only compiling could be reduced to some XSLT-like transformations that preserved the clarity of the old language in the new language. If there was only some universal Lingua Franca of computing that would be the Rosetta Stone of programming.
Until someone invents that Lingua Franca of computing, every language translation job will be hard and will lead to code that's "difficult to maintain" in the new language.
I've used f2c, and I agree with whoever wanted to name it cc2fc instead. It isn't a way of transforming Fortran into anything vaguely usable as C. It's a way of taking a C compiler and making a Fortran compiler out of it.
It did work just fine at taking that Fortran code and turning it (through C) to a Macintosh library I could call from Macintosh Common Lisp. Those were the days.