> On Thursday 05 March 2009 02:15:20 Pal-Kristian Engstad wrote: > > Jon Harrop wrote: > > > On Wednesday 04 March 2009 23:18:21 Pal-Kristian Engstad wrote: > > >> Sure -- those are probably not jobs that require performance, nor have > > >> resource constraints. > > > > > > I do not believe that C++ is significantly faster or better at handling > > > resources than higher-level languages. > > > > Have you ever tried to conform to a specific memory layout? We are often > > talking directly to hardware, and in those cases it is a prerequisite to > > be able to produce data that is in the exact format prescribed. Often > > these things are, put an 17-bit ID followed by a 3-bit CODE followed by > > a 12-bit LENGTH field, after which follows LENGTH items each of size > > that is some-function-of CODE. > > > > This is usually not a problem when a small part of your data needs to be > > described this way, but when a large portion of your data needs this > > formatting, you can see that OCaml or Haskell records simply doesn't > > work very well. > > I agree with the symptoms but not with C++ as the treatment. Granted you > cannot write such code directly in OCaml or Haskell but you can generate the > code using tools like LLVM
Come on, can you stop all those stuff about LLVM. The guy works in a game company with people knowing C/C++ for decades, with quite a lot of legacy code I guess, and you arrive with your "hey you should use LLVM" that almost nobody knows about. Oh, and by the way, in which programming language is written LLVM ? :) Valgrind is written in C (and julien seward, its author knows very well Haskell), Qemu is written in C, because I guess indeed C struct and union and bitfields makes it easy to match directly to the hardware (no marshalling, there is direct mapping). > It doesn't need to be a JIT and, actually, HLVM already supports both JIT and > standalone compilation. So what you propose to his company is to switch from C++ to HLVM ? :) Be serious. _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
