C/C++ vs Pascal

[DarknessX]

Ok, well, with all the hype I've been hearing towards and against pascal/c/c++, I just want to know...
What are the exact advantages/disadvantages of Pascal, C, and C++? I don't need to know, oh theres lots of tutorials, thats not a problem... I mean the actual language/compiler advantages.

[WILL]

You know I've not read so much language debate and discussion since... well a long time as I have in this past month. :scratch:

Anyhow.. here are the main differences as I see them and have followed on in the last oh... 10 years. [size=9px](**** I'm getting old )[/size]

First understand that the debate that you are talking about fits roughly into 4 categories of languages, though technically it can span several different dialects. Sound complex? It is.

The most obvious is that C & C++ are 'symbolic' languages where as Pascal & Object Pascal are more 'natural language' languages. The terms might be incorrect, [size=9px](it's been some time since I had that less way back in highschool)[/size] but the idea holds true. Pascal is more like English and C is more symbolic terms that both basically perform the same types of functions.

Another big thing is that the C branch is more dependent on pointers for some things and not so strongly typed, where as Pascal house is strongly typed and offers pointers as an option than a requirement. I'm not so sure how strongly this holds true to Object Pascal today. Perhaps the habit is kept, but the implementation in the compilers has changed. Any FPC guys to back this up?


C has header files and core source files where as Pascal has units and programs. [size=9px](plus libraries which I believe may only be a byproduct of Object Pascal. Someone please prove me right/wrong? I'm not 100% sure here, may have been something back in the TP7 days.)[/size] This is where you get all these "header translation" projects coming from. All these funny .h files allow C programs to access library files. (.DLLs for Win32, .SO for Linux, etc) The Pascal equivilent to this is a unit file which when is based off a 'translated header' is often called a 'wrapper'. Which I guess is some Pascal programmer's way of making fun of C people. *shrug* I dunno...


Those are the big tree off the top of my head, but a few things that I consider moot or irrelevant to the topic of the compiler and more a feature of the IDE and tools around the language it's self are; debugging, linking, machine code optimizations and lack of hardware support. At least where are the topic of language comes to play. I can create a programming language in ancient Egyptian or some alien strange language and it can be as fast or as slow as C, Pascal, Basic or AppleTalk.

[Chebmaster]

Any FPC guys to back this up?

There is a big difference between FPC and Delphi in one aspect.
Free Pascal allows you to perform arithmetic operations with pointers.

var
  p: pointer;
  a, b: integer;
...
p:=p + (a*b);

In Delphi you must add a lot of unnecessary typecasts:

p:=pointer(cardinal(p) + (a*b));

Which is stupid IMO, because the pointers in themselves are a way around the strong typing.

[Colin]

There is a big difference between FPC and Delphi in one aspect.
Free Pascal allows you to perform arithmetic operations with pointers.

var
  p: pointer;
  a, b: integer;
...
p:=p + (a*b);

In Delphi you must add a lot of unnecessary typecasts:

p:=pointer(cardinal(p) + (a*b));

Which is stupid IMO, because the pointers in themselves are a way around the strong typing.

this is incorrect, since delphi 2009 there is a directive to allow pointer maths......

{$POINTERMATH ON}

since i use it all the time....

[phibermon]

I totally agree with chronozphere, Learning lots of languages is the way to go, it does indeed, without a doubt make you a better programmer.

But OOP is my favourite language and it will always be.

From a pure project perspective, if I have a task to complete that requires a native language I can always complete the job faster in OOP. And that's not because it's my strongest language, if anything my strongest language is C++ but when dealing with a large complex system, the OOP style leads to far less bugs which on any sizable project will always be the dominating factor, no matter how good you are.

Of course, if your project is on Windows and doesn't require blistering performance? .NET offers faster development times than both (although not strictly because of garbage collection! believe me, on a large, memory hungry project? it *will* become more trouble than it's worth)

But Native Code? can't beat OOP for time to market, Borland knew this, Embarcadero knows this.

And picking up development on existing project? (other than .NET) OOP wins again, I'd of moved on to the next class in OOP while I'd still be studying the previous one in C++

if it was a subject I knew as well as a C++ competitor? I'd always win in an implementation race.

[Daikrys]

this is incorrect, since delphi 2009 there is a directive to allow pointer maths......

{$POINTERMATH ON}

since i use it all the time....

guys the thread is so old no wonder why since delphi 2009 there are some more stuff

the reason why in theory there are more C++ developer is that it was free from beginning and there was alot of free compilers out there
today its just so that cause of this early matter that most studios use C++ (cause its not only game developer but also engine developer)
newer engines btw. support C++ style language but dont use C++ as common solution (see lua, unreal script etc.)

fun fact is as far as i now there few developers who develope there tool chain in Object Pascal or C#

[Colin]

that may be true, but pascal is by no way a bad choice, there is no performance loss by using delphi vs c++, they both are relatively the same nowadays, but the benifit of delphi is the readability, you could say pascal resembles more assembly than c++ could ever.... readable words are always much easier for the human brain than symbols, i know many people will now argue the toss that c++ is more readable and so on, but that is just because it is their favorite language (which of course is fine - but it still is besides the point)

and yes i know this thread is old, but people still come across this thread and read it so its best for potential new delphi developers not to get the wrong idea.

[Daikrys]

readable words are always much easier for the human brain than symbols, i know many people will now argue the toss that c++ is more readable and so on, but that is just because it is their favorite language (which of course is fine - but it still is besides the point)

thats on of the reasons why I use pascal :>
its fun to code in pascal and easy to understand for me, i still learned a bit of C++ but i really dont like it, i dont like to use pointers and often get confused by these symbolic language when it comes to complex problems (or sometimes even easy ones x) )

[Bijo]

* When you misplace or exclude a ; in C++ it is highly possible or probable you receive unclear compiler errors and perhaps even a lot of them, whereas with Pascal the information is actually more useful and clear.

* Pascal is a safe language, while C and C++ are not.

* Pascal is fit to be used as an effective teaching tool, while C and C++ only make matters unnecessarily difficult.

* Nowadays FPC is the bomb: multi-platform support and very fast.




NOTE for C/C++ programmers: do not mistake * for a pointer! They are merely to signify certain... pointe-- points made

[Chebmaster]

The way of translating C headers is wrong, IMO.
People convert C header into an unit, but the unit is not just the original headers. More often than not it contains a initialization/loading code also, the code that often doesn't work or is incompatible with your project. So you can't just use that unit, you need to modify it. But then the updated version is released, and you need to do it all again. and again.

Why not convert C headers to Pascal, then put it into a unit using {$include ...} ?

he Pascal equivilent to this is a unit

No, it isn't. The units have no equivalent in C/C++.
On the other hand, the C way of headers and core source files is perfectly applicable to Pascal. I use it to compose large units from many small fies using {$include ...}. The Free Pascal RTL is built the same way.