In C, can you create a dictionary? I come from a Objective-C background so I would like to know if there is anything similar to NSDictionary.
You can create anything you want in C. You just won't have native language support for most of it.
You can create a dictionary in C, but there is no dictionary built in to the standard C library.
A quick search on Google code shows that there are open-source (and generously licensed) C dictionary implementations here and here.
Posix does have a limited hash table -- see hcreate(), hsearch() and hdestroy() that can be used by a C program.
A discussion of the limitations appears in this stackoverflow question.
Without OOP and templates, it would be hard to implement a hash table or a balanced tree that is truly general, easy to use and performant, and therefore worthy to be in the run-time library that comes with the language.
That being said, you can always implement your own, or just use C++ (see unordered_map or map).
Related
I am implementing a lisp interpreter in C, i have implemented along with few primitives like cons , car, cdr , eq, basic arithmetic stuff.
Just before i was starting to implement define and lambda it occurred to me that i need to implement an environment. I am unsure if i could implement it in lisp itself.
My intent is to implement minimal amount of lisp so that i could write extension to the language in itself. I am not sure how much is minimal, Would implementing FFI Qualify as minimal ?
The answer to your question depends on the meaning that you give to the word “minimal”.
Given your question, and assuming that you don't want to make an implementation competing with the nowdays fine implementations of Common Lisp and Schema, my hypothesis is that with “minimal” you intend: Turing complete, that is capable of expressing any computation expressible in a general purpose programming language.
With this assumption, you need to implement three other things:
conditional forms (cond)
lambda expressions (lambda)
a way of defining recursive lambda expression (labels or defun)
Your interpreter then should be able to evaluate forms. This should be sufficient to have a language equivalent to the initial LISP, that allow to express in the language any computable function.
First off, you are talking about first writing a LISP interpreter. You have a lot of choices to take when it comes to scoping, LISP1 vs LISP2 since these questions alter the implementation core. An interpreter is a general purpose program that reads and evaluates code. It can support abstractions but it won't extend itself by making more native stuff.
If you are interested in such stuff you can perhaps make a compiler instead. Eg. there are many Sceme like subsets that compiles to C or Java code, but you can make your own VM. Thus it can indeed compile itself to be run on it's own target machine (self hosting) if all the forms and procedures you use has been implemented using the primitives supported by the compiler.
Making a dumb compiler is not much difference from making an interpreter. That is very clear if yo've watched the SICP videos (10A is about compilation, 7A-B is about interpreters)
The environment can be a chain of pairs just as in a LISP interpreter. It would be difficult to implement the environment of itself in LISP without making it a very difficult Lisp language to use (unless it's compiled that is)
You may use the data structures of lisp and the primitives from the C code though.
Making a FFI is a fast way to give your language lots of features. It solves the chicken and egg problem by using other peoples work from within your language. In fuses the top (primitives and syntax) and the bottom layer (a runtime) of your system. It's the ultimate primitive and you can think of it as system call or message bus to the runtime.
I strongly suggest to read Queinnec's book: Lisp In Small Pieces. It is a book dedicated entirely to answer your question, and it explains in detail the many trade-offs and the internals of Lisp implementations and definitions, by giving many explained examples of Lisp interpreters and compilers.
You might also consider using libffi. You could be interested in the internals of M.Serrano's Bigloo & Hop implementations. You might even look inside my MELT lisp-like language to customize the GCC
compiler.
You also need to learn more about garbage collection (you might read the GC handbook). You could use Boehm's conservative Garbage Collector (or something else, e.g. my Qish or MPS) or write your own GC.
You may want to learn more about Chicken, Scheme 48, Guile and read their papers and look inside their code.
See also J.Pitrat's blog: it is not about Lisp (but about bootstrapping strong AI) and has several fascinating entries related to bootstrapping.
For my own learning experience, I want to try writing an interpreter for a simple programming language in C – the main thing I think I need is a hash table library, but a general purpose collection of data structures and helper functions would be pretty helpful. What would you guys recommend?
libbasekit - by the author of Io. You can also use libcoroutine.
One library I recommend looking into is libgc, a garbage collector for C.
You use it by replacing calls to malloc, realloc, strdup, etc. with their libgc counterparts (e.g. GC_MALLOC). It works by scanning the stack, global variables, and GC-allocated blocks, looking for numbers that might be pointers. Believe it or not, it actually performs quite well (almost on par with the very good ptmalloc, which is the default (non-garbage collected) malloc implementation in GNU/Linux), and a lot of programs use it (including Mono and GCJ). A disadvantage, though, is it might not play well with other libraries you may want to use, and you may even have to recompile some of them by hand to replace calls to malloc with GC_MALLOC.
Honestly - and I know some people will hate me for it - but I recommend you use C++. You don't have to bust a gut to learn it just to be able to start your project. Just use it like C, but in an hour you can learn how to use std::map<> (an associative container), std::string for easy textual data handling, and std::vector<> for a resizable heap-allocated array. If you want to spend an extra hour or two, learn to put member functions in classes (don't worry about polymorphism, virtual functions etc. to begin with), and you'll get a more organised program.
You need no more than the standard library for a suitably small language with simple constructs. The most complex part of an interpreted language is probably expression evaluation. For both that, procedure-calling, and construct-nesting you will need to understand and implement stack data structures.
The code at the link above is C++, but the algorithm is described clearly and you could re-implement it easily in C. There again there are few valid arguments for not using C++ IMO.
Before diving into what libraries to use I suggest you learn about grammars and compiler design. Especially input parsing is for compilers and interpreters similar, that is tokenizing and parsing. The process of tokenizing converts a stream characters (your input) into a stream of tokens. A parser takes this stream of tokens and matches it with your grammar.
You don't mention what language you're writing an interpreter for. But very likely that language contains recursion. In that case you need to use a so-called bottom-up parser which you cannot write by hand but needs to be generated. If you try write such a parser by hand you will end up with a error-prone mess.
If you're developing for a posix platform then you can use lex and yacc. These tools are a bit old but very powerful for building parsers. Lex can generate code that implements the tokenizing process and yacc can generate a bottom-up parser.
My answer probably raises more questions than it answers. That's because the field of compilers/interpreters is quite complex and cannot simply be explained in a short answer. Just get a good book on compiler design.
I was wondering if you knew of a robust implementation of a hashtable in C. I'm looking for something other than ghashtable in glib.
Thanks.
I've heard good things about the GLib Hash Table.
In C:
As previously mentioned g_hash_table in gLib:
http://library.gnome.org/devel/glib/stable/glib-Hash-Tables.html
uthash: https://github.com/troydhanson/uthash
khash in klib: https://github.com/attractivechaos/klib
cdada_map in libcdada: https://github.com/msune/libcdada (C API, backend C++)
If you can/want to use C++:
std::map in libstdc++ (look into std::unordered_map too)
As noted before (updated link) sparsehash: https://github.com/sparsehash/sparsehash (look into dense too)
Will this hashtable work? (got the link from the second post of this thread)
Perhaps this one will?
(got the above from a Google search for "hashtable in c", am not a C programmer)
For a hash table I'd use google-sparsehash
PD: I don't know your requirements, but take a look at HDF5, bear in mind it exists just in case.
update
Memory Structures Library (MemSL2), o MemSL2 in another link
it has implementations (one in pure C and wrappers for C++) of structures, for example, AVL trees, threaded trees, ..., and
Hash Tables with Separate Chaining,
Hash Tables with User-Defined Paging
Hash Tables with Dynamic Paging
A simple one in libc, see <hsearch.h> and man hsearch.
Update: just found that you can implement hashtable very easily with the help of hlist from Linux kernel. Take a look at <list.h> in Linux kernel source code for hlist_head/node and their operations.
You might want to look into using the Apache Portable Runtime? It's license is very liberal and it provides a decent hashtable implementation:
http://apr.apache.org/docs/apr/1.3/group__apr__hash.html
At the risk of oversimplifying something I'm worried might be ridiculously complex, what should I be aware of when mixing C and Objective-C?
Edit: Just to clarify, I've never worked with C before, and I'm learning Objective-C through Cocoa. Also I'm using the Chipmunk Dynamics engine, which is C.
I'd put it the other way around: you might be risking overcomplicating something that is ridiculously simple :-)
Ok, I'm being a bit glib. As others are pointing out, Objective-C is really just a minimal set of language extensions to C. When you are writing Objective-C code, you are actually writing C. You can even access the internal machinations of the Objective-C runtime support using some handy C functions that are part of the language (no... I don't recommend you actually DO this unless you really know what you're doing).
About the only time I've ever had mildly tricky moments is when I wanted to pass an Objective-C instance method as a callback to a C function. Say, for example, I'm using a pure-C cross platform library that has functions which accept a callback. I might call the function from within an object instance to process some data, and then want that C function to call my instance BACK when its done, or as part of getting additional input etc etc (a common paradigm in C). This can be done with funky function wrapping, and some other creative methods I've seen, and if you ever need to do it googling "objective-c method for c callback" or something like that will give you the goods.
The only other word of advice is to make sure your objects appropriately manage any manually malloced memory that they create for use by C functions. You'll want your objective-c classes to tidy up that memory on dealloc if, indeed, it is finished.
Other than that, dust off any reference on C and have fun!
You can't 'mix' C and Objective-C: Objective-C is a superset of C.
Now, C++ and Objective-C on the other hand...
Objective C is a superset of C, so it shouldn't conflict.
Except that, as pointed here pure C has different conventions (obviously, since there is no built-in mechanism) to handle OO programming. In C, an object is simply a (struct *) with function pointers.
Just because I'm curious--is there any C analog to the functionality of the STL in C++? I've seen mention of a GTK+ library called glib that a few people consider fills the bill but are there other libraries that would provide STL functionality in C?
Yes, glib is a pretty good choice: it includes a lot of utilities for manipulating containers like linked lists, arrays, hash tables, etc. And there is also an object-oriented framework called GObject that you can use to make objects with signals and slots in C (albeit with rather verbose function call names like gobject_set_property, since C doesn't have any syntax for objects). And there is also code for main loops so you can write event-driven programs.
For more info see wikipedia: https://en.wikipedia.org/wiki/GLib
Glib was originally part of GTK, but the non-GUI code has been completely factored out so that you can use it in command-line programs: http://library.gnome.org/devel/glib/stable/
CLIB
Adding another option (full disclosure, I am the author); if you can compile and link C++, you can have a look into libcdada, which has a pure C API, but uses libstdc++ as a backend for most of the containers:
https://github.com/msune/libcdada
Well since STL's very nature is based on templates which C doesn't have, it would be difficult to even come close to the STL in C. The best you could hope for is some collection classes which manipulate void* pointers to unknown object.