Browse thread
[Caml-list] More OCaml+windowing system questions
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Warp <warplayer@f...> |
| Subject: | Re: [Caml-list] More OCaml+windowing system questions |
> > However, C and C++ are extremely portable, which is very > > appealing to me. > > Sorry, I cannot resist commenting on that particular statement, because > it still seems to be such a frighteningly common misconception. And so can't I resist to comment your comment :) > This statement confuses two issues: portability and availability. C > certainly is available on pretty much every system. But this says > nothing about portability of C code - C and C++ are definitely among the > least portable languages in use today. There effectively is no > non-trivial C program that is portable according to the language > standard (ie. does not explore undefined/unspecified behaviour one way > or the other - most times you are not even aware). I think that all the features of the C/C++ languages ARE portable. Why shouldn't they be ? All you have to do is to compile with the good compiler ( gcc for instance ). BUT then, you have to be aware of some things that are not permitted ( like DWORD access on odd memory addresses on Solaris ) and to use a portable API - like ACE, or OpenGL - to do "special" things. In fact, the limits of portability C/C++ are in the choice of the API you make, and in the fact you CAN write very-low-level code when you should use an API. Thus, there is a big difference between portabily ( source code can be recompiled on another machine and will work fine ) and "super-portability" compiled code will work fine - if you got the 'launcher' ) : and that's one of the reasons of Java's sucess Warp ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr