Lambda the Ultimate

...Scott must work where I do! Well, apart from the "embedded Smalltalk" part.

I can, without exception, second all of Scott's comments. As I've said before, I am perfectly satisfied that C++ is almost surely the wrong language for the server side of my domain. It almost makes sense to me on the embedded side, but so far the compilers and libraries there are abysmal—so much so that I find myself thinking we might be better off with plain C.

But the retraining issue is a totally legitimate one, and it would be politically infeasible to convince the management team that the investment would be repaid in higher-quality products developed more quickly, even if it happens to be true. C'est la vie.

GCC 3.x is available, in some form, for most 32-bit embedded processor families; in many cases embedded OS and RTOS vendors will provide complete C/C++ toolchains. GCC isn't the best C/C++ compiler out there, but it certainly works if nothing else is available. Many platforms have commercial C/C++ compilers as well.

I'm often puzzled by those who prefer C to C++; much advice of that sort seems to be based on myth, bad experiences with early C++ implementations (it took a while to get things like templates and exceptions right) or simple outright dislike for the language. Libraries ought not be an issue; any C library (possibly excluding things dependent on new C99 features like "restrict") should be easily callable from C++ code--even if only available in binary form.

The main exceptions I can think of, where C would be preferable are:

* Team is unfamiliar with C++ and/or OOP.

* VERY tight memory restrictions and/or performance requirements. (In many cases, a selection of C is justified on these grounds, but the justification is groundless).

* Architecture/platform that has a good C compiler but lacks a good C++ compiler (many DSPs, certain small-scale processor families)

* Legacy system issues which prevent or confound introduction of C++.

* A heavily K&R-ish codebase which would make a modern C++ compiler barf (and no desire to port it).

Even if you ignore the OO features (subtyping/inheritance) and program in a procedural or functional style; C++ has lots to offer that C does not. Better typechecking, generics, better metaprogramming support, etc.

At any rate, I checked in the employee database...no, you don't work here. Unless you post to ltu under an assumed name. :)

VERY tight memory restrictions and/or performance requirements. (In many cases, a selection of C is justified on these grounds, but the justification is groundless).

The concern about memory is real in some very small applications. C++ generates a lot of structures (e.g. for exceptions and RTTI) which are still "there" even if you don't use them. If the compiler lets you turn these off, then this isn't such a problem, but then you're using a C++ subset, not C++ proper.

There are a few concerns which are specific to library vendors which may apply:

• Some platforms still have binary compatability issues, such as differing object/vtable layout and symbol mangling.
• Upgrading libraries without requiring clients to be recompiled is harder to do in C++, and sometimes platform-dependent.
• More languages provide easy ways to bind to C libraries than to bind to C++ libraries. (This is more of a concern in the open source world.)

Apart from that, I agree with you. I don't know why most people would prefer C to C++ in this day and age, especially when you consider that most C++ compilers are really C++ compilers with features turned off. Even if you only use C++ as "a better C", you still win.

... is a real issue. While it's true that GCC 3.x is available for many platforms, in one form or another, we do have to concern ourselves with link-time compatibility for our customers, who often aren't willing to migrate away from whatever compiler/library combination the embedded device vendor is hawking.

In any case, having kvetched about it, I should mention that we do, in fact, still code in C++ even on our embedded devices. We just don't enjoy it very much. :-)

I would usually choose C over C++. My reasons are:

• I only ever use C for very small performance critical pieces of code, or to interface with specific libraries etc. Typically, C++ doesn't really add much here.
• From my experience, C++ is a lot less portable than C. What I mean by this is that I have so far been unable to write any C++ code which managed to compile cleanly first time on 2 different platforms. Use of the STL seems to be the kiss of death in this regard. Perhaps this is my own incompetence, but no other language I've used has been this tricky to port.
• Related to the above: the STL seems to be single biggest reason for preferring C++ over C for the work I do. However, I rarely program without having a Tcl library present, so I can get most of what I need from that (e.g. hashtables, dynamic Unicode-aware strings, event loop, simple sockets, GUI, etc), and get a nice, compact configuration language for free!
• Complexity: as mentioned above, my code is generally structured as small packages which are loaded into a Tcl interpreter to be tied together. For these sort of small pieces of code, C++ just adds complexity without really giving much gain. C++ is a much more complicated language than C.

In short: I'm trying to minimise the amount of code I have to write in low-level languages. C++ seems like more of a win if you're writing most, if not all, of your code in C++. That's a situation I'd like to avoid. I'd benefit more, I think, from a nice functional language (e.g. Ocaml, Haskell) with garbage collection, pattern matching, etc. However, I haven't had much luck integrating such a language with Tcl, unfortunately.

What are your problems with integrating Haskell or OCaml with Tcl? Also, why are you mainly writing stuff using Tcl, if I may ask?

What are your problems with integrating Haskell or OCaml with Tcl?

Last time I tried, it was building dynamic libraries, suitable for [load]ing into the Tcl interpreter. You can build a static customized tclsh, with whatever Haskell etc code baked in, but I'd prefer to not have to do that. I came across some code for linking (byte-code compiled) OCaml to Perl, and was going to try and adapt it, but so far haven't got round to it. I notice that GHC now has some preliminary support for dynamic libraries [1], so now might be the time to revisit this (although, I might wait for it to mature a bit first).

Also, why are you mainly writing stuff using Tcl, if I may ask?

Plenty of reasons. Mostly, for the implementation/libraries, which are really very good. It's also pretty good at meta-programming, but prefers using normal (runtime) procedures over Lisp-style macros, and defers interpretation of arguments to individual commands, which avoids some quoting issues. (e.g., there are no special forms in Tcl, beyond the minimal syntax defined in Tcl.n man page). There are warts, and I would personally like to see it move in a more Scheme-like direction (Tcl 8.5/9.0 are doing so, in some ways, with big integers coming in 8.5, some proposals for lambda, and even some preliminary talk of things like closures and continuations on the wiki), while maintaining some of it's more unique aspects.

I sometimes gaze longingly at some particularly elegant piece of Haskell, but mainly as a means of replacing C, rather than Tcl. My ideal language would somehow be able to scale between Tcl's very hands-off approach (interpretation as a technique of last resort, almost), and Haskell's elegant type system.

Perhaps I'm being stupid, but I can't see any doumentation for the C++ libraries for embedding Tcl on http://tcl.tk. Where would I find this?

Tcl is a C library. The docs for the functions it exports are at http://www.tcl.tk/man/tcl8.5/TclLib/contents.htm. There are more docs scattered around the wiki, e.g. this page on C++. The sample chapters from Practical Programming in Tcl/Tk should be useful too.

You can either embed Tcl in your program, or you can restructure your program to be a set of Tcl-loadable packages and use tclsh (or wish, or tclkit...) as your "main". The latter is generally the preferred approach these days, for various reasons.

Thanks.

Portability (through time and space) is important, and C++ is far worse than C here, but the primary reason I prefer not to use C++ is that it's so bug-prone. http://www.parashift.com/c++-faq-lite/ is a several-hundred-page document that consists mostly of "gotchas" in C++ --- subtle bugs that mostly can't happen in C. In some applications, these subtle bugs are outweighed by C++'s support for higher-level idioms not supported at all in C.

However, I mostly use C as a slightly-higher-level version of assembly language. In this application, C++'s advantages are not very compelling, but some of its disadvantages remain. Generally I write higher-level code in Python.

(In Wheat, however, we're using C++ to implement the virtual machine. And by "we", I mostly mean Mark. But I think it's probably the right choice.)

Or, to use a popular mixed metaphor, "C gives you enough rope to shoot yourself in the foot; C++ gives you a bazooka."

My big personal peeves are:

• Scoping. When I see some code referring to "foo", is it a member variable, or a global (or static or class) variable? Or does it belong to some superclass? I keep writing "this->" in front of everything, just so I can keep track of it. ("But you don't need to do that!" "I know; I want to; I wish you'd do it, too.") Yes, there are naming conventions, but they're often not followed (especially in the older and cruftier bits of the code base), and they're different in every code base, anyway. You can do horrible things in C with macros, but everyone knows that you use ALL_CAPS unless you're damn sure that you've made them behave like normal variables and/or functions.
• Auto-typedef-ing. The single biggest wart in the C grammar is the type name syntax and "typedef" introducing an unbounded number of new keywords. So C++ goes and makes it worse. I like writing "struct" in front of everything. It tells me that this object has complex internal state. I like writing "class" in front of everything, too, which attracts the same comments as the above. I only use typedef when I really need an arithmetic type and I really can't use a built-in one. Indeed, in C, I often write "foo_frob(struct foo *foo, arg1, arg2, ...)", which drives C++ programmers crazy.
• The syntax. In the 90s, I remember people wondering if it was possible to parse C++ unambiguously, or if there was an unresolvable corner case. Maybe X3J16 solved that, but it can still be a remarkable pain, especially combined with the above two issues. By fitting into the corners of C, already a fairly densely-encoded language, it's possible to approach Perl 5 regular expressions for clarity. And some people seem to like writing that way.

Now, automatic constructors and destructors are rather handy, and for some mathematical-type code, operator overloading is a wonderful syntax convenience, but if I'm doing high-level programming, I'll use a high-level language.

But other than that, the only thing I find worthwhile about C++ is the STL. Which is a very good thing, but the cost at which it was bought... now J. Random Cruftycoder can obfuscate his wierd, special-purpose and buggy data structure by wrapping it in template syntax and feel virtuous that he's writing "reusable code".

I don't deny that C++ is a powerful tool, able to span from low to fairly high levels, but I have seen it in the hands of idiots too often.

Thus, I hate implicit allocation. I have a strictly finite amount of RAM available, and that's it. I preallocate when possible, and cleanly back out when not.

It's not a case of "tight" memory - I usually have over a megabyte - but the fact that I can't just print "out of memory" and return to the shell.

Not to mention, I have to provide the run-time, as well. Remote fimware upgrade is always fun, particularly when you don't have enough non-volatile storage for two full copies. A nice simple run-time has advantages there.

I am not sure what your requirements are, but I suggest checking out Ada.

The only systems which made wide-spread use of Objective-C appear to be Next and now Apple, but it is quite elegant and useful. Portable too, as part GCC. The GnuStep framework is available for Linux and Windows, and Apple has open-sourced their lower-level libraries for writing portable Objective-C code.

It is a thin layer on top of C, providing Smalltalk-like behaviour. Being a dynamic runtime system, it is much easier to link to other dynamic languages (Python, Lisp, Ruby, etc.) than C++ or even C.

I personally agree. I use both C++ and OCaml rather heavily and most of the things I do in C++ I could do with less difficulties and less run-time errors in OCaml -- if the libraries I'm using weren't C++-specific, that is.

I look forward to using Mono + F# or OCamlIL and being able to use all these libraries in a language-neutral way.

GCC 3.4.3's support for the standard is quite good, and GCC 4.0's will be even better. Also, GCC 4.0's codegen for C++ is vastly improved over GCC 3's. Either compiler does just fine with various C++ acid tests (Boost, Crypto++, etc.)

thanks!

James Hague: I'd appreciate pointers to high-level language implementations designed for embedded systems (I know about Lua, but that's a "scripting" language by design, not something you'd want to write the bulk of your code in.)

How about MLKit?

"All memory allocation directives (both allocation and de-allocation) are inferred by the compiler, which uses a number of program analyses concerning lifetimes and storage layout. The ML Kit is unique among ML implementations in this respect... Programmers who are interested in real-time programming can exploit the absence of garbage collection: there are no interruptions of unbounded duration at runtime."

I occasionally build low-cost robots in my spare time and it'd be fun to try some functional reactive programming in the real thing. Some of my robots only have a few hundred bytes of RAM so there's probably not much hope there. But one has 512K and it'd be cool to find a nice functional language that runs in that space. Even better, an interactive interpreter that runs in 512K so I can control it 'live'.

There are a number of projects to run functional stuff on bare PC metal - such as movitz, or the Haskell projects mentioned here in the last couple of days. It's probably worth checking to see if there's a practical way of using scheme on the metal.

I know that Zhanyong Wan and Paul Hudak worked on real-time functional reactive programming for industrial robots. You can find more info on Zhanyong Wan's publications, especially his PhD thesis.

--Shae Erisson - ScannedInAvian.com

We think occam is really best suited for programming robots, because robots always have to deal with lots of stuff at the same time. Therefore, we've also made it possible to write occam programs to control the LEGO Mindstorms. Give it a try; you'll love it.

As occam closely models the CSP calculus, we can write clean, concise, concurrent programs that can then be executed anywhere---on Mac OS X, Windows, *NIX, on handhelds and clusters, and yes, little robots too.

Also, Danny Dubé did BIT, "A Very Compact Scheme System for Embedded Applications", and with Marc Feeley, PICBIT, a Scheme interpreter for PIC chips (also covered in Running Scheme on a PIC microcontroller).

I'm not sure about the availability of source code with any of these.

The last time I talked to Transterpreter folks (a few months back now), they said they had no plans to make the source code for the Transterpreter generally available. However, they did mention that they'd be happy to supply the source code to people who had a genuine interest in working on the code base.

Here's a Scheme compiler for Lego Mindstorms, which comes with source in Scheme. The source is only 1570 lines -- the compiler was apparently written by three students in three days. How hard could it be to retarget for another CPU? ;)

Of course, the Transterpreter is apparently written in C, so if the target CPU has a C compiler, then porting that ought to be easier, if the source can be obtained.

Yep; although, that particular compiler is actually a cross-compiler, so unfortunately it isn't going to be particularly portable to new platforms. It was, as the pages said, a proof-of-concept. But, it was impressive to see happen. :)

Regarding porting the Transterpreter, we've had good success porting it to other platforms.

http://www.transterpreter.org/blog/archives/2005/02/portable_you_be.html

We have a port to the Sharp Zaurus completed as well (which took almost no time), and a few other platforms in various stages of partial completion. Again, people who are interested in working on ports are welcome to contact us, and we can find ways of getting them involved.

(Hm. An awful lot of posts for me today...)

Apologies for not keeping up on all-things-LtU!

I should say that our intentions are to release the source, but both of the primary authors of the Transterpreter (myself and Christian) are within 6 months of writeup for our PhDs. Supporting a source code release is not, we don't think, a good idea at this time.

We have the infrastructure in place (version control in a place we can create accounts, etc.), but are not ready for any of the administrative overhead at this time. We won't let it bitrot, though, we promise.

Most of what you say makes no sense whatsoever. For example, what "intelligent things" can C++ do that Java or C# can't?

Signals and slots are not directly supported by anything in the C++ standard - they are not a language feature. Conversely, there is no reason why a C# or Java library could not support them as well as a C++ library does.

I could go on, but I won't.

"For example, what "intelligent things" can C++ do that Java or C# can't?"

Check out templates for starters. There is a rich field of fancy stuff to be discovered which can't be done "similarly enough" in Java (always think about compile time vs. runtime, for instance) :o)

"Signals and slots are not directly supported by anything in the C++ standard - they are not a language feature. Conversely, there is no reason why a C# or Java library could not support them as well as a C++ library does."

You are assuming that the expressiveness of both languages is close enough ("Conversely, there is no reason why a BASIC library could not support them as well as a C++ libary does.")

I don't agree with many points of Achilleas, but at least we should make some effort in disagreeing :)

Ok, leaving aside the fact that Java does not have compile-time metaprogramming, I see no justification for the idea that there are "intelligent thigns java cannot do", nor that Java cannot support Slots or any otehr architectural pattern in a way that is easy to use.

As regards compile-time evaluation, for the vast majority of applications in C++, if not all, a reflective capability only as powerful as Java's is quite enough to allow programming the same kinds of patterns in a way that is no less concise or easy. Java generics cover the simple uses of templates.

I see no need to enter into deep arguments about capabilities with someone who is ignorant of the basics.

I see no need to enter into deep arguments about capabilities with someone who is ignorant of the basics.

Personally, I think anyone that can program in C++ effectively is, by definition, pretty smart - you have to be smart to figure out and keep track of all the intracacies. Me, I'm a dumb programmer who likes to not worry about a lot details simultaneously - which is why I don't get along well with the likes of C or C++.

Sure - but I'm not going to argue about what Java or any other language can or cannot do with someone who appears to be wilfully ignorant of it, making claims that have no basis in fact whatsoever, providing no evidence because they have none.

The person you're arguing with? Or the smart people? Or the dumb people? Or yourself? Can't say I blame you for wanting to optimize your time, but why the caustic nature of these posts?

Not that it makes any difference, but Java is way too clever for me as well.

[...]Java is way too clever for me as well.

Really? I find that Java stops me from shooting myself in the foot with things like accidentally passing pointers to short-lived char* buffers, while also preventing me from easily creating well-factored, generic code.

Library implementors do need a little bit more of what it takes to create something good in Java, to be sure. Doesn't mean that it can't be done, or that once it has been, downloading and using a Java library is harder than downloading and using a C++ library.

I do find Java programming easier because it has built in GC and doesn't use memory pointers. However, Java's got its own set of warts. For example, how do you determine when a type should be constructed as a class hierarchy (limited to single inheritance) and when should it be an interface (no code inheritance)? Whichever path you choose, you'll be fighting it all the way along. Also there's the distinction between primitive types and object types?

May just be me, but I find that all the programs I construct are heavily reliant on the construction of Types. Get the types right and everything else falls into it place (somewhat akin to getting a database design correct). If I have to fight the Type system, then I find myself in a pitched battle with my software, never really being satisfied with the tradeoffs.

Many people are bothered at the distinction between objects vs primitive types (int, boolean, double, etc.) in Java; it is often suggested that a major deficiency of Java is that not everything is an object (as opposed to Smalltalk, for example, where everything is).

In C++, the problem is (at first glance), worse. Not only are the primitives not objects, but the language happily allows you to manufacture MORE things which aren't objects--unions, structs, enums, and pointers/arrays to such. (We'll gloss over struct vs class for now).

However--the C++ approach seems more natural to me. Why? In Java, objects and non-objects have differing semantics and (in general) cannot be interchanged. Intrinsics live "on the stack", whereas objects live in the heap. One object cannot be embedded in another without a level of indirection. Pre Java 5, one couldn't use a primitive in an object context without an explicit cast to a class such as Integer, Boolean, etc. Primitive types cannot be aliased without wrapping them in a containing object of some sort.

In C++, on the other hand; the polymorphic objects, the primitive types, and the non-polymorphic aggregations all exist on the same plane. One can use any type in C++ as a template paramter; or as the basis for overloading. All types can be allocated in any memory region, or embedded "inline" within another object. In short, whereas the primitives and the objects are segregated in Java; in C++ they are not--something which I thinks makes C++ more expressive.

Of course, that comes at a price--the C++ solution permits references to out-of-scope objects to be created. By allowing internal pointers, it makes implementing GC much more difficult.

Thoughts?

By contrast, Java holds your hand very tightly, which can incur performance penalties, and makes the language more confusing to learn (it took me ages to work out why I couldn't use 'new' on int). However, I've never found that this aspect makes it harder to actually achieve a particular end (except, of course, in relation to performance).

For example, how do you determine when a type should be constructed as a class hierarchy (limited to single inheritance) and when should it be an interface (no code
inheritance)?

I don't really see the problem in making that decision. In Java, I think of all types as being interfaces in principle — classes are really about implementation. I think possibly the reason confusion arises is that when a class will have a single interface that won't be used anywhere else, you can save time and keystrokes and maybe some mental overhead by simply defining the class without an explicit interface. But in that case, the class still has an implicit interface. You could define the interface explicitly, change all references to the classname (where used as a variable type) to use the interface instead, and the design and semantics of the program wouldn't change.

Whichever path you choose, you'll be fighting it all the way along.

The fighting happens because you can't reliably use subclassing for implementation inheritance when you need to implement multiple interfaces. You either need to pretend Java is C and use lower-tech reuse mechanisms, like composition and delegation; or use the new generics stuff, Java version permitting; or use some kind of metaprogramming, like AOP. Either way, I agree it's a fight.

• They solve real-world problems: object persistence and distributed computing.
• They take throughput and scalability seriously.
• They take standards (OMG, J2EE) seriously, at least enough so to play nicely with other children.
• They take the cost of developer time seriously.

Technically speaking, what these systems seem to have in common is getting extreme leverage from Java's reflection, dynamic proxies, and in some cases the availability of high-quality bytecode-generation libraries to, as transparently as possible, minimize both the cognitive distance between task and accomplishment and the amount of repetitive, tedious, error-prone glue code often required to bridge task and accomplishment.

There's a lesson in here, as well as in systems like Ruby on Rails, for fans of statically-typed languages that lack reflection and/or easy in-place code generation, IMHO. In my own thinking about having a "slider" from static to dynamic typing, I need to remember that just having that slider isn't enough, but that the space on either side of the knob needs programmatic access to the space on the other side in order for the full potential power of the slider to be realized.

Your foot will thank you for not using char * buffers and using std::vector instead. Failing that std::auto_ptr, or boost::shared_ptr.

I was talking about Java 1.4. I haven't tried Java 1.5, and using Java 1.5 a non-argument, because our projects date back from 1998. And Java generics are much less powerful than C++ templates, especially because one can not use primitives in collections.

Here is a real-life example: on OpenGL display built with Java uses Ids (of type 'int') for display objects. Whereas in C++ these ids are kept in a simple map (with no run-time overhead for insertion-removal-search), in Java 1.5 there is an Integer object created every time there is a display action, in order to create the key to search the map for which Java object was clicked. In a display with real-time video (real-time plots fed from the actual radar), we had to use a two-processor system to achieve a good frame rate with Java. The previous version, made with C++, needed only one CPU.

There's a fast way to map integers to objects, and it's called an array. You may have heard of this datastructure.

it's called an array. You may have heard of this datastructure.

I have this theory that postings seem more collegial and less snarky when posted with less anonymity. (Not sure what causes this perception; must be some deep human factor. ;-) )

Most of us here post with our real, full names as a sign that we are prepared to stand behind our opinions.

Might I recommend this practice to you, too, Marcin?

Surely the question is why you're uncomfortable with me challenging nonsense?

...it's a contradiction. (via Monty Python sketch).

Guess we could get into an argument about Turing completeness meaning that anything from one language can be expressed in any other Turing complete language. But then we'd back into the subjective argument about which language makes it "easier".

Personally, I find language advocacy to be a non-productive avenue of exploration. Original poster thinks he's most productive in C++. You think you're most productive in Java. To each his own. What is rubbish is the pretense that either C++ or Java must be defended. If the language does what you want and you find yourself productive, then that's all there is to say.

It's simply disingenuous to say that Java is inferior because a bad way of coding something, for which an alternative which is as easy to use exists, performs badly. I don't like it, and I see no reason to let that kind of thing pass.

I'm still going to call someone who comes up with unsubstantiated rubbish, though.

By all means do. I have observed, however, that doing so in a collegial manner tends to have better effects both on the discourse and on the interlocuters.

Just a suggestion.

Surely the question is why you aren't willing to challenge nonsense?

You're right; I never give anyone a hard time here. I really should be ashamed of myself. ;-)

But seriously, when discussing PL preferences, there is always more than a pinch of "de gustibus non est disputandum".

There is a terrible habit I've observed in myself (and perhaps other programmers as well) to over-generalize one's experience as typical of all programming environments and problems.

When someone says that they find a particular language better suited to "serious problems", they usually mean the serious problems that THEY routinely run into, which may be quite different in their requirements from mine, even nominally in the same field of effort.

So I try not to get too worked up about such things, I'm more interested to see if I can detect any substantive features of PL design that demonstrably contribute to particular suitabilities.

Sometimes such things ARE to be found.

I think you'll find that I've never said in general (nor, at all, in this topic) that one language is superior to another. Only that certain criticisms are patently unfounded and based on ignorance.

Ignoring your ironic tone, I should say that you have not understood the problem at hand at all. Let me state it again: a radar generates plots (lots of plots per second), these plots are mapped onto an interactive OpenGL display, where the user can do various things. There are various labels attached to each plot, and various user actions. Each OpenGL object on the screen is identified by a unique integer Id generarated automatically; this unique id must be associated with a Java object. An array can not be used in this situation, simply because the range of ids given by the OpenGL library is not known, and OpenGL objects and their ids are destroyed at some point in time. An array is simply not a good data structure; an associative array is.

Allocate an array of size MAXID+1, where MAXID is the biggest possible id number (I'm guessing that it's MAX_INT). This will work just fine, will be faster than any hashtable, but will take more memory (unless, of course, you normally have very many handles open at one time). Otherwise, it will have the same functionality as a hashtable, for example it will still hold references to objects after they have become invalid.

Haha, this was funny.

Pray tell why?

It won't work on architectures where sizeof(int) == sizeof(size_t):

$ cat foo.c
#include <stdlib.h>
#include <limits.h>

int main(int argc, char ** argv) {
   int * arr;
   int i;

   printf("Trying to allocate %d * %d = %lu bytes\n",
          INT_MAX, sizeof(int), INT_MAX * sizeof(int));
   arr = malloc(INT_MAX * sizeof(int));
   if (arr == NULL) {
      puts("NULL");
   }
}
$ gcc -o foo foo.c
$ ./foo
Trying to allocate 2147483647 * 4 = 4294967292 bytes
NULL
$

I don't think java will handle allocting an array twice the size of virtual memory any better.
And even on architecturs where it works (like AMD64), allocating 8GB to hold a few thousend handles seems excessive.

It is true that it is rather annoying to have to write your own hashtable implementation for integers, no matter how simple it is.

Given the difficulties of making a fast, thread-safe and memory efficient hashtable for production usage I would just use one of the many libraries that have already implemented this. For instance: http://trove4j.sourceforge.net/overview.shtml

The fact you did not understand what I was saying does not mean I was wrong. 'Intelligent things' are all the template/operator overloading tricks one can do, which Java can't do. For example, boost::spirit or boost::functional can not be done with Java.

Signals and slots are not a language feature, but the language allows for a good implementation. On the other hand, Java can't do signals and slots, because it lacks templates and function/member pointers. The observer/observable pattern leads to the ugly solution of using a flag to notify the observer about the kind of update that hapenned in the observable, which leads to spaghetti 'if-then'/'switch' blocks.

C# has events right into the language, but as I said earlier, for the kind of job I do, C# can not be used.

Please explain the difference between a function pointer and a pointer to an object with a known interface. (Hint: Lexical closure)

A function pointer (in common terminology) lacks the state to be an object.

Correct; however, there is no reason why an object has to have state.

smart and efficient data structures (no need to copy stuff over and over, as in functional languages), etc etc...

You might be interested in this posting (from this thread, respectively).

In any case, the idea that you have to copy excessively in FPLs is a gross misconception.

Basically, the poster of the posting you posted is cheating a little:

The poor performance of the STL compared to OCaml's library is, in this case, directly due to the imperative design of the STL and the functional design of OCaml's set implementation and not to do with any given implementation. Functional programming is simply vastly more efficient in this case.

Cheat number 1: two different algorithms are compared, not two different programming languages. The non-copying style of O'caml can easily be done with C++. But that implies the data are static, i.e. they don't change.

Specifically, due to its imperative design, the STL's set_union function must explicitly copy all elements in both sets as the originals are mutable and, therefore, may be changed. In contrast, referential transparency allows OCaml's Set.union function to refer back to branches of balanced binary tree in the input sets whenever they can be reused.

But if you add elements to those data, your data will be copied. Whereas in C++, they won't. Let's say you have a huge data set of 10000 records, and you want to sort it. The functional way will copy the 10000 record array again and again, whereas in C++ the sorting happens in place. I doubt the functional algorithm will not run out of memory.

I see comparisons of apples and oranges here. It's not fair.

Cheat number 1: two different algorithms are compared, not two different programming languages.

He does not primarily compare languages, rather trade-offs of paradigms - which is a useful comparison to a certain extent.

You claimed that one needed to "copy stuff over and over" in FPLs and silently implied that this was a grossly inefficient approach. The article shows by anecdote that (1) this statement is not true, and (2) that overuse of stateful data structures for alleged efficiency can actually backfire big time.

The non-copying style of O'caml can easily be done with C++. But that implies the data are static, i.e. they don't change.

Sure it can be done - though not that easily, because it is much harder to achieve properly without garbage collection.

But point is, it is not done in C++, because of the wide-spread naive believe in the superior efficiency of stateful data structures.

But that implies the data are static, i.e. they don't change.

But if you add elements to those data, your data will be copied. Whereas in C++, they won't. Let's say you have a huge data set of 10000 records, and you want to sort it. The functional way will copy the 10000 record array again and again, whereas in C++ the sorting happens in place.

No, the "functional way" won't copy everything over and over again, simply because it wouldn't use arrays. ;-) For most tasks, including sorting, there are efficient algorithms that do not rely on in-place update.

Besides, all functional languages provide means to implement imperative algorithms efficiently, e.g. by providing imperative arrays. Some of them even manage to do this without loosing the nice properties of being "pure".

A tree is not an array ;0)

That should have been: an array is not a tree. Ah, well ;-)

but all three can be used in terms of each other. More specifically, an array is an indexed list. And a list or an array can easily be represented as a tree. From an abstract data type standpoint, any of these forms can be used to store the data, using accessors to hide the internal representation.

I agree! . . . . . Que?

...for the emoticon impaired. :-)

...I can only conclude that O'Caml needs better marketing, especially if you believe that Qt is the best piece of software ever written. :-) And aren't you conveniently ignoring that Qt requires the use of a preprocessor to overcome C++ deficiencies?

I've written quite a bit about O'Caml—recently, even—so I won't rehash it here. Suffice it to say that if you don't think it has good GUI support albeit for GTK rather than Qt, "non-copying" data structures, "value classes," OpenGL support, etc. then you really should look more closely.

As for syntax, all syntax looks weird at first, and I definitely can't help you if you think O'Caml's syntax is even weirder than Perl's!

The only point that I think we agree on is that it would be nice to see G'Caml again, but truthfully I don't even find myself thinking about that most of the time when I'm writing in O'Caml. On the other hand, I don't find myself thinking about it much when I'm writing in C++, either, so maybe the take-away from that is that I don't do much scientific/numerical computing and therefore don't suffer much from not overloading operators.

But all of this misses the main point, which in my case is that O'Caml continues to let me write correct code vastly faster than C++ does, and generally speaking the performance of that correct code is within epsilon of the performance of the C++ code. Even when I have to tune the O'Caml code, it's vastly easier to do that than it is to make an arbitrary body of broken C++ code correct.

It pains me, as basically a free-market absolutist, to have to say this, but given that I keep hearing the same essential mythology about alternatives to C++ in general, and O'Caml in particular, I have to wonder whether the solution to the imbalance won't have to consist of someone starting a software company that simply disallows the use of C++ in their products. I would actually rather take a group of experienced programmers, in any language, and teach them O'Caml for, say, two months after hiring them, having them create no work product during that time, than have them hit the ground running in C++. Unless I've been fortunate enough to hire a company of Meyers, Alexandrescus, Sutters, and Parents, I pretty much guarantee you the team will still be more productive than a C++ team would.

For all practical purposes, Qt is the best library there is. Qt needs a pre-processor, but only because Trolltech wanted to easily convert between text (.ui files) and code; otherwise, they would have used templates.

I would be more than happy if you post some links with good O'caml libraries in the sections I referred above.

I still maintain that "all practical purposes" is far too broad, but if Qt is working for you, that's great.

Achilleas: Qt needs a pre-processor, but only because Trolltech wanted to easily convert between text (.ui files) and code; otherwise, they would have used templates.

Assuming templates existed when they started. I dunno. I've looked at Qt many times over the years and never came away impressed. Obviously, your milage varies. :-)

Achilleas: I would be more than happy if you post some links with good O'caml libraries in the sections I referred above.

Happy to oblige:

1. signals and slots, for doing model-view-controller apps.

   On the (un)reality of virtual types

2. networking.

   If you mean basic IETF protocol stuff, I'd suggest ocamlnet. If you're referring to process group communication in distributed systems, let me highly recommend Ensemble. If you're talking about CORBA, try CamlORBit.

3. memory mapped data structures.

   Please see the O'Caml standard library's Bigarray module. Look for the "map_file" function. That, coupled with O'Caml's standard marshaling functions, might do. You might also find this post helpful.

4. multitasking.

   I refer you to O'Caml's standard "Thread," "Condition," "Event," "Mutex," and "ThreadUnix" modules.

5. a rich GUI.

   LablGTK is quite nice, and also integrates nicely with LablGL.

6. value classes.

   This is addressed quite nicely with O'Caml's module language. The example they give is using floats to implement currencies, but to have specific currencies, e.g. dollars and euros, be incompatible types to avoid errors.

7. operator overloading.

   We saw these, and more, in G'Caml, but so far it hasn't gotten past the prototype stage. I'm still frankly not convinced that operator overloading is a big win.

8. XML and databases.

   Boy, where to begin? OCaml-MySQL, OCaml-Sqlite, OCamlBDB, or just go straight to OCamlODBC and talk to any database with an ODBC driver? For XML, you can start with the expat wrapper or go whole-hog to PXP. If that's still not enough, how about CDuce or, if a new O'Caml-derived language seems like cheating, just OCaml + CDuce, which just embeds some critical CDuce features into the O'Caml 3.08.2 compiler?

9. clever and efficient data structures and algorithms support.

   Once again, where to begin? Baire perhaps, or ExtLib, or Okasaki's Purely-Functional Data Structures? Maybe you just want a nice Trie implementation? Or perhaps you need some nice graph theory support?

Shouldn't it tell you something that just by following links from the O'Caml site over lunchtime that I was able to address all of your points, and that only the operator overloading response seems the least bit lacking? Doesn't it bother you at all that the multitasking and memory-mapped data structures questions are answered within the context of O'Caml's standard libraries, and that the "rich GUI" question is one link away and also refers to OpenGL?

It's stuff like this that persuades me that many (most?) people who claim to have "investigated alternatives" and "found them lacking" are lying.

Thanks a lot for the links. I'll try to check them out all.

Assuming templates existed when they started. I dunno. I've looked at Qt many times over the years and never came away impressed. Obviously, your milage varies. :-)

What was the part that you had a problem with?

Here is my thoughts on the material from links you have given me. Please allow for a margin of corrections, since I am not familiar with O'Caml and I need to learn the language in parallel with the examples.

signals and slots, for doing model-view-controller apps. On the (un)reality of virtual types

The link you have given me presents a typical observer-observable pattern as found in Java. Here is what I think about it:

1) it's not signals and slots, because the interface between observers and obervables is fixed. I want to have a parameterized interface, like in C# events or Qt signals and slots.

2) it's not something used throughout all other libraries.

3) Documentation is not formal. Is it a library or a research paper?

networking. If you mean basic IETF protocol stuff, I'd suggest ocamlnet. If you're referring to process group communication in distributed systems, let me highly recommend Ensemble. If you're talking about CORBA, try CamlORBit.

Ocamlnet is a fine library, but it offers a subset capabilities of the Java SDK/Qt. CGI is not relevant anymore, since more advanced technologies exist. The documentation quality differs wildly from part to part: some parts are documented with ocamldoc, others aren't.

Ensemble seems a fine library if one wants to build a communication mechanism with different protocols, but I failed to see how it is useful in practical applications: how do I do basic stuff like open a TCP/IP port, wait for connections, how to connect, errors reporting etc. I have to say I did not understand much of Ensemble, but I suspect this is because it is an entirely different and irrelevant domain from my line of work. Documentation of it is in PDF format.

Camlrobit seems like a good wrapper around Corba's Orbit, but the documentation is again in a different format.

memory mapped data structures. Please see the O'Caml standard library's Bigarray module. Look for the "map_file" function. That, coupled with O'Caml's standard marshaling functions, might do. You might also find this post helpful.

I don't see anything related to memory mapped data structures. I see information on memory mapped files though, from a guy that wants his app to have full state persistence. What I talked about is encoding of binary messages as data structures. ADA is the best language for this, since developed from the start with that mentality, and C++ comes closely second.

LablGTK is quite nice, and also integrates nicely with LablGL.

LablGTK is a very nice wrapping around GTK, but the problem is GTK itself: Swing and Qt are much better toolkits. GTK does not follow the model-view-controller paradigm (from what I know so far), and the LablGTK documentation is unfinished (and yet in another HTML style).

value classes. This is addressed quite nicely with O'Caml's module language. The example they give is using floats to implement currencies, but to have specific currencies, e.g. dollars and euros, be incompatible types to avoid errors.

Nice example, but how are ML modules any different than C++ classes? I can do in C++ the exact same thing.

operator overloading. We saw these, and more, in G'Caml, but so far it hasn't gotten past the prototype stage. I'm still frankly not convinced that operator overloading is a big win.

Consider the following C++ code:

Vector r = a + b - c;

And the following Java code:

Vector r = new Vector;
r.add(a, b);
r.subtract(c);

Not only it takes much longer to write, but it is not as elegant as the C++ version.

Now consider a two-page algorithm like a fighter trajectory computation, and you will see why operator overloading is really important.

Operator overloading goes hand-in-hand with value classes: Why shouldn't the Currency type (in the context of an example above) be used with operators? it's a number anyway.

XML and databases. Boy, where to begin? OCaml-MySQL, OCaml-Sqlite, OCamlBDB, or just go straight to OCamlODBC and talk to any database with an ODBC driver? For XML, you can start with the expat wrapper or go whole-hog to PXP. If that's still not enough, how about CDuce or, if a new O'Caml-derived language seems like cheating, just OCaml + CDuce, which just embeds some critical CDuce features into the O'Caml 3.08.2 compiler?

Ocaml-mysSQL / Ocaml-ODBC: same api as C, even with the lowercase keywords, and yet another documentation style.

PXP: almost the same api as Qt: document class, node class, etc etc.

CDuce: extension language. As you said, it does not count.

clever and efficient data structures and algorithms support. Once again, where to begin? Baire perhaps, or ExtLib, or Okasaki's Purely-Functional Data Structures? Maybe you just want a nice Trie implementation? Or perhaps you need some nice graph theory support?

Baire: In the writer's own words: Baire is a data structures library for the Caml language. Please note that Baire is an ongoing work, even if already quite usable. Not good enough for big commercial projects. Documentation is in French and non-existent.

ExtList: exactly the same stuff as Qt or JDK.

Shouldn't it tell you something that just by following links from the O'Caml site over lunchtime that I was able to address all of your points

Unfortunately, you did not address any of my points. There are several drawbacks in all the above links that still prohibit me for going to my boss and suggest O'caml.

Doesn't it bother you at all that the multitasking and memory-mapped data structures questions are answered within the context of O'Caml's standard libraries, and that the "rich GUI" question is one link away and also refers to OpenGL?

What standard libraries? all I saw is a bunch of individuals, each one doing his own thing, possibly intersecting with other people's areas (in data structures, for example). If you would like to call these libraries "O'caml standard libraries", then perhaps I should call the entire Sourceforge catalog as C++ standard libraries, since many of the O'caml libraries are in Sourceforge, actually. I will not do it though: C++ has only one standard library, the STL, and Java has the JDK.

It's stuff like this that persuades me that many (most?) people who claim to have "investigated alternatives" and "found them lacking" are lying.

Ok, it's reality time. Since you accuse me of lying (rather politely), let me tell you that you have no knowledge of the requirements for commercial projects like defense applications or Hospital information systems. These projects are never gonna be done on development environments like the one you suggest. The O'caml language is fine, but the development environment is not only the language: it's the libraries, the support, the documentation, the availabity of information. So here is reality, for you:

From one side, we have mature environments like C++ and Java with a few number of libraries developed by corporations that base their existence on these libraries (Trolltech, Sun) that cover most of our needs, with consistent architecture, consisent documentation and huge support.

From the other hand, we have (mature ?) environments like O'caml, with lots of little libraries, spread over the web, with no immediate visibility, with support left at the hand of individuals who code away on their free time, with various architectural designs not compatible between themselves most of the time, with incosistently presented documentation.

Furthermore, O'caml libraries are not vastly different than C++ or Java libs. I would say that they are 90% similar.

Conclusion: which one would I choose to base my defense contract on? or my Hospital information system on? or my web store? certainly not O'caml in the way you have presented. It's too much a risk for business environments.

Achilleas, I believe that the above pointers only meant to show you that there are ways of doing the things you wanted in OCaml as in C++, not necessarily that they are better. This was an answer to your

I have searched for example desktop apps in LISP/ML/Haskell/OCaml that support the above, but I have found nothing. All I find is broken links, 100 ways to code the factorial function, insane amounts of work on how continuations are the best thing since sliced bread, etc etc.

And yes, the absence of Qt bindings for OCaml is a shame -- I personally prefer Gtk to Swing, though. Ymmv.

The standard library is documented on OCaml's website. You'll find low-level networking, concurrency, marshalling/serialization, data structures...

As you write yourself, you are obviously not familiar with OCaml, which makes this whole discussion pointless. Obviously, for any task, you will use the tools you know best and trust. For most tasks, you will use C++, the STL and Qt. For most tasks, I would rather use OCaml, its standard library and Gtk. Note that I have experience with C++ and STL (and only toy experience with Qt).

P.S. :

I still do not understand what you mean by "memory-mapped data structures". Unless perhaps you want to do some low-level DMA transfers or something similar, I believe this is a standard case of marshalling.

As David said, I was (as always) reacting to overly-strong claims of "I couldn't find that for O'Caml," and my reaction can be summed up as "then you didn't try very hard." Elsewhere I've already acknowledged the marketing difficulty related to languages other than C/C++ in certain domains. With respect to the standard libraries, my point was that the threading support and memory-mapped file support is included in O'Caml's standard libraries, so asking about them suggests that you (Achilleas, not David) couldn't even be bothered to look at the standard libraries. etc.

People do use O'Caml in commercial production environments. Obviously, this isn't happening on a scale that looks impressive from a pure numbers perspective—rather akin to Apple selling computers and operating systems compared to Microsoft selling operating systems—but it's plain ignorant to suggest that O'Caml isn't suited for production work.

Achilleas: Ok, it's reality time. Since you accuse me of lying (rather politely), let me tell you that you have no knowledge of the requirements for commercial projects like defense applications or Hospital information systems. These projects are never gonna be done on development environments like the one you suggest.

I'm glad that you feel I was polite. In fairness, I now see that your concerns aren't actually about available features or libraries, but rather uncertainty about or disagreement with their relative level of maturity. I would argue that those concerns are existential: if I find a third-party C++ library, I have just as much effort to vet it as I do an O'Caml library. I'm just as (more, actually) concerned about quality of implementation, documentation, throughput, scalability...

Now let me tell you that if you think I've never done commercial projects like defense applications or hospital information systems, you're wrong, and if you think those systems have always been done in C/C++ or even Java, you're wrong again. Let me also tell you that if I ever find out I've been cared for in a hospital that uses a C/C++ system, I'll sue for criminal negligence. There's no excuse for using such radically unsafe technology in an environment in which people's health or even lives could be at stake.

I'm curious: aren't hospitals running computers and embedded CPUs on which OSes are written in C ?

Note that this is not a troll. Rather a question related to hardware/OS trust (which might be better suited for a forum topic).

David Teller: I'm curious: aren't hospitals running computers and embedded CPUs on which OSes are written in C ?

Note that this is not a troll. Rather a question related to hardware/OS trust (which might be better suited for a forum topic).

Right on both counts, IMHO: I'm stipulating that the OS is part of the Trusted Computing Base, and I'll refrain from commenting on why that might or might not be wise on a per-OS basis. :-)

Software for things like MRI machines has certainly been written in C/C++. Of course, a malfunctioning MRI probably won't kill you, at least not directly.

In fact, I suspect your list of potential targets for lawsuits on this basis is longer than you could pursue in a lifetime. Perhaps you've finally found the way to break the mainstream language stranglehold. You could turn C/C++ into every lawyer's favorite language. "I don't know what C++ is, I just know I get rich suing anyone who uses it!" However, I'd watch out for those silently overflowing integers in OCaml — you could be next!

Anton van Straaten: Perhaps you've finally found the way to break the mainstream language stranglehold. You could turn C/C++ into every lawyer's favorite language. "I don't know what C++ is, I just know I get rich suing anyone who uses it!"

That was exactly the 75% tongue-in-cheek point, very much inspired by the anti-Supers lawsuits in "The Incredibles." :-)

Anton: However, I'd watch out for those silently overflowing integers in OCaml — you could be next!

Indeed, so I'd use this Overflow module and OcamlExc to check my code for uncaught exceptions. :-)

That was exactly the 75% tongue-in-cheek point, very much inspired by the anti-Supers lawsuits in "The Incredibles." :-)

Indeed, so I'd use this Overflow module and OcamlExc to check my code for uncaught exceptions. :-)

Hmm. I must confess this gives me deja vu. The language has fast, unchecked integers because people demand performance (as evidenced by the other thread about C-class performance). The performance is one factor which drives its acceptance for some real applications. But then we need to start retrofitting solutions to the problems which were created by the pursuit of performance. Sound familiar?

This is not particularly a critique of OCaml itself, which is obviously fulfilling many people's wants. (Note I didn't say "needs".) Other statically typed functional languages also have usability problems when it comes to mixing numeric data types, for example. I think I'm going to remain holed up in my bunker with Scheme's seamless, non-overflowing, dynamically typed numeric tower for a while longer, at least until I can get one of those famous sliders to smoosh all the numeric types into a single one.

Anton van Straaten: I'm apparently behind on the relevant "literature"! I'll have to go find a 5 year old mentor to help get me up to speed.

Oh, "The Incredibles" is far from appropriate for 5-year-olds. It is deservedly Pixar's first PG-rated film. I personally would agree with 13-and-over.

Anton: Hmm. I must confess this gives me deja vu. The language has fast, unchecked integers because people demand performance (as evidenced by the other thread about C-class performance). The performance is one factor which drives its acceptance for some real applications. But then we need to start retrofitting solutions to the problems which were created by the pursuit of performance. Sound familiar?

Certainly. My once again somewhat tongue-in-cheek point was only that if in a certain domain you can't afford silent overflow, then you can make it "unsilent." Of course, you can also use the Big_Int or Num modules for arbitrary-precision integral or rational arithmetic. So there are actually a range of choices here, which can be made on a per-project basis according to requirements and what's learned from the appropriate combination of experience and profiling.

Anton: This is not particularly a critique of OCaml itself, which is obviously fulfilling many people's wants. (Note I didn't say "needs".) Other statically typed functional languages also have usability problems when it comes to mixing numeric data types, for example. I think I'm going to remain holed up in my bunker with Scheme's seamless, non-overflowing, dynamically typed numeric tower for a while longer, at least until I can get one of those famous sliders to smoosh all the numeric types into a single one.

You're not going to hear me argue that the Scheme numeric tower isn't a thing of wonder from a conceptual point of view, and if you care strictly about correctness over performance it is, AFAIK, the only game in town. All I was saying was that it isn't necessarily the case that O'Caml's overflows on its int types were silent, and therefore I could balance safety and performance according to my needs. Having said that, I'd be very interested in seeing what a good optimizing Scheme compiler like Stalin did with some heavy numerical code.

The language has fast, unchecked integers because people demand performance (as evidenced by the other thread about C-class performance). The performance is one factor which drives its acceptance for some real applications. But then we need to start retrofitting solutions to the problems which were created by the pursuit of performance. Sound familiar?

This kind of retrfitting wouldn't be a problem in a language with adequate support for reflection-oriented programming. Does ocamlp4 actually provide this support, I wonder?

would argue that those concerns are existential: if I find a third-party C++ library, I have just as much effort to vet it

That's why I said "C++ + Qt" and "Java + SDK", simply because they minimize the need for 3rd party libraries.

if you think those systems have always been done in C/C++ or even Java, you're wrong again

I never said that they weren't. But why does C++ has to be slammed so hard, to the point of ironically asking "why do people use C++?". They use it because it is one of the best languages, that's why. If O'Caml is not used, it is because it's no better than C++, plain and simple.

There's no excuse for using such radically unsafe technology in an environment in which people's health or even lives could be at stake

The 'unsafeness' is in your mind, mostly. C++ is as safe as you care to make it. Put some effort in it, and it becomes totally safe. Remember that no algorithm can be proven 100%, so why should OCaml be safer? just because it does not have pointers? a pointer is a kind of value! wrap that up in a safe pointer class and you are done!

Let's also not forget that operating systems used in critical environments like Solaris or BSD or Linux are programmed in ...C. There are unsafe programmers, not unsafe programming languages.

P.S. :

I still do not understand what you mean by "memory-mapped data structures". Unless perhaps you want to do some low-level DMA transfers or something similar, I believe this is a standard case of marshalling.

I think he means something like this (be warned: have not written Ada in a while, hw manipulation in Ada less so)...

type mouse_data is record
   x : integer range 0 .. 128; -- mouse for very small screen ;)
   y : integer range 0 .. 128;
   button_status : status;
end;

for mouse_data use
   x at 0 range 0 .. 7;
   y at 1 range 0 .. 7;
   button_status at 2 range 0..15;
end;

for mouse_data'size use System.storage_unit * 4; -- constrain to 4 units of memory (usually bytes).

for mouse_data'alignment use 8; -- byte alignment (packed).
...

main_mouse : mouse_data;
for main_mouse'address use some_intrinsic_sys_routine(16#000000ff#);

procedure initialise_driver is
   main_mouse.x := 0;
   main_mouse.y := 0;
   -- ...
end initialise_driver;

This uses two aspects of Adas HW support. First it uses a representation clause to layout the structure we expect (for blah use ...) and secondly it maps a record to an address (for blah'address use ...). Ada allows you to map this to a pointer (or access type) and manipulate it safely (and back).

Ada's hw support is about giving you the ability to do hw level manipulation with some level of safety. You can with the right code map records (structures) to physical memory, but you get static checks on the structures you manipulate (you can fly without the checks if you really really want to, but i ain't getting in that plane ;) ).



I stopped using Ada a while ago, but am thinking of going back to it for a toy project. Be interesting to see what's happening with GNAT in Gcc 4.0 and what's going on with Ada 2006.

Chris

p.s. the best reference on Ada's low level facilities is Cohens "Ada as a second language", but I couldn't find anything online to give you a flavour. Perhaps Ehud knows of a better example?

p.p.s. the compiler doesn't have to honour representation clauses to be an Ada compiler, but something like GNAT will unless it's just plain odd.

Okay, thanks. That's the kind of think I hadn't seen used since... well, since I last programmed hardware "drivers" under MS-DOS in Turbo Pascal.

I thought the original poster was referring to making use of mmap() etc from C. This provides the ability to efficiently map data living on disk (for example) into your address space. It's used a lot for low-level database routines etc, from what I gather. I've never used it myself (directly), and may be wildly off-mark here.

Achilleas, I believe that the above pointers only meant