Instead of sticking with C/C++ for performance consider:
1.Free Pascal -Small memory use,very fast, easy debug
2.OCaml - medium memory use, fast,very terse, functional and secure.
3.FreeBasic - very fast,easy to use, low memory use, supports QBasic code as dialect. Other Basics to consider: PureBasic/Gambas/PowerBASIC
4.Digital Mars D- fast, easy to write and debug, large library, transition from C/C++ much easier.Garbage collection can be turned off.
Pascal is a dead language. It was one of my first languages and I recently tried going back to it... it's clunky as fuck.
Sorry bro, but I'm sticking with C++ (and learning C++0x), and using Python, Lua, and Scheme for higher level stuff.
Name:
Anonymous2010-07-18 7:08
FreePascal was recently ported to whole range of mobile devices.
As for speed, naive pascal code is optimized much better than most of "Expert C programmer" code. Plus its catches/prevents errors which would take the sanity of C programmers away(pointer typecasts,function pointers,etc) and the code is very readable(even more than Java).
FreeBasic - very fast naive pascal code is optimized much better than most of "Expert C programmer" code code is very readable(even more than Java)
Oh you guys.
Name:
Anonymous2010-07-18 8:14
http://wiki.freepascal.org/Modernised_Pascal
This page was originally a summary from an enthusiast user to "create" a more modern (!?!) Pascal. The suggestions are in practice a mix of random Basic syntax (which is already pretty random in itself), the regularly occuring namespace proposal etc. The page, and the rebutal was left in as an example, since it demonstrates a few traits common in these kinds of requests:
* Random borrowing from other languages on instinct, not reason
* Failure to grasp basic concept of Pascal parsing and philosophy.
* Syntax that saves minor typing, while IDE can do quite complex handling nowadays like declaring vars of for loops (this goes doubly for Pascal since it is parsing model makes it easy for IDEs)
* Missing the consequences (and advantages of) the unit concept.
* Pretty shallow description of the feature, no implementation, minimal code examples only. (see e.g. the elsif. Example what it solves(dangling else) can be found anywhere) It is a long way from idea to final implementation, and most ideas stumble on that road.
* No implementor offered. Who is going to do the hard work is the hard nut to crack. Everybody has more ideas then he can realise, the core developers even more likely so.
Name:
Anonymous2010-07-18 8:30
Hey dudes. You should take a look at FreePascal. It's getting pretty good. Non-standard compliance ftw! Enjoy your stale compilers
I'm one of the maintainers of the backend(ARM, working on NIOS support) ^^
Name:
Anonymous2010-07-18 12:05
Program Lesson1_Program1;
Begin
Write('Hello World. Prepare to learn PASCAL!!');
Readln;
End.
Name:
Anonymous2010-07-18 12:19
>>7
This isn't relevant today, comparing FreePascal to 30-year old standards is asinine. You have to use better sources than old tired arguments which bear no similarity to modern implementation.
Name:
Anonymous2010-07-18 14:21
I found this gem in http://www.ocaml-tutorial.org
OCaml uses one of the bits in an int internally in order to be able to automatically manage the memory use (garbage collection). This is why the basic int is 31 bits, not 32 bits (63 bits if you're using a 64 bit platform). In practice this isn't an issue except in a few specialised cases. For example if you're counting things in a loop, then OCaml limits you to counting up to 1 billion instead of 2 billion. This isn't going to be a problem because if you're counting things close to this limit in any language, then you ought to be using bignums (the Nat and Big_int modules in OCaml). However if you need to do things such as processing 32 bit types (eg. you're writing crypto code or a network stack), OCaml provides a nativeint type which matches the native integer type for your platform.
>>16
I'm not sure which use it for GC, but I've seen quite a few that use the first few bits for type tags
Name:
Anonymous2010-07-18 14:50
>>17
...an 32bit int[4294967296/+-2147483648] with few bits of type tags becomes 29(3bits)~27bits(5bits)=536870912/134217728 unsigned and +-268435456/+-67108864 signed.
>>22
Fine, all the non-retarded users can enjoy writing functions in their Glorious Democratic Republic of OCaml. Both of them.
The others will either:
1.wait for Ocaml update for a fix
2.switch back to C++/Java/.Net
>>24
a quick yum install ocaml, running ocaml with that both at the REPL and in a file gave me the expected result. So, that's either your fault, or your packagers fault
>>13
Tag bits are not unusual, lisp implementations, even high-performance CL ones do use them (unless the compiler can safely optimize them away). The result is having ints of size lesser than the CPU register size. This is a problem if the language can't promote the int to a bignum, and it can be a problem if you're writing crypto code (expected to deal in ints of the same size as the CPU register size) and need it to be efficient. In the second case, some CL compilers can still do it efficiently if you get the compiler to properly assume the types (32 or 64bit) and as long as the values are used in internal operations, it doesn't do needless fixnum<->bignum operations and the final equivalent code is just about as efficient as the C one, however that's not to say it isn't a bit of a pain to make sure the compiler gets it right (unboxed ints), maybe in some cases it's less work to just write this kind of code in C if you want unboxed ints being portable across a large variety of CL implementations (assuming the FFI supports loading your external code).
Name:
Anonymous2010-07-18 18:27
If anything this thread proves C/C++ are irreplaceable.
my 2cents:
1.Pascal is ancient ALGOL BDSM system with tons of boilerplate.
2.Ocaml: Ints which are garbage collected(with tagbits inside the Int) and actually are a castrated version of real ints. A program like "Hello world" fails to run(i have not seen a language (until today) on which canonical Hello World breaks).
3.FreeBasic - Its neither fast or memory efficient enough to compete with C/C++. best BASICs are unfortunately commercial and closed source.
4.Digital Mars D - garbage collection/runtime can't be "just turned off" because the libraries depend on it. Plus its has much more overhead than plain C. There 2 standard libraries and two branches which get in the way.nicer language for large programs than C++.
>>31
O'Caml has bignums and 32bit ints as well. Tag bits are a bit annoying, but they solve a lot more problems than they cause. The major problem they solve is allowing precise garbage collection, but in some other languages like Lisp, they even allow you given any data, to complerly and accurately decode it in full:
I can open any data and get a printed representation of it, or examine it in the debugger and find anything about it. No silly overflow, no silent type errors (allows safety in a dynamically typed language). If you need native ints, you can get them in good implementations.
>>3
CL implementations do have bitvectors of course, they're in the standard. They're also pretty useful. I only mentioned the 32bit int thing because a lot of crypto algos are designed to work with them, so if you want to just port some C crypto code, having efficient 32bit ints is useful.