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. (**** I'm getting old :P)

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, (it's been some time since I had that less way back in highschool) 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. (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.) 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. :P

[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.

[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 :D

[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.

[DarknessX]

Hmmmm, ok. So basically, everything between C/C++ and pascal are nearly identical, except with different syntax, and more/less support available. So technically, anything possible with C/C++ is possible with Pascal?

Thats good to know... It means I don't need to go in-depth on learning C/C++.

[Chebmaster]

So basically, everything between C/C++ and pascal are nearly identical, [...] So technically, anything possible with C/C++ is possible with Pascal?
No.
They are *mostly* the same, but there are things you can do with C that you cannot with Pascal, and vice versa.
Of course, this relates to some pretty advanced stuff, you should be quite experienced in programming to get grip of it.

C has multiple inheritance and tons of other techniques (perverted IMO) you can't easily replicate in Pascal. Also, C has generics and Pascal doesn't (yet). I cannot be of much help here because I'm not familiar with C/C++ myself.

Pascal has metaclasses - a unique feature you won't find in C++. So, for example, my persistency system would be impossible to create with C++.
Metaclasses are quite powerful feature, allowing to decide created object's type at runtime in a very easy and elegant manner. Metaclasses also allow you to write, for example, methods for class to clone itself that will work correctly with all its descendants:


type
TFrog = class
constructor RibbitCreate; virtual;
function OneMore: TFrog;
end;
CFrog = class of TFrog;

TToad = class(TFrog);
...

function TFrog.OneMore: TFrog;
begin
Result:=CFrog(Self.ClassType).RibbitCreate;
//Typecast to CFrog is required here because ClassType() returns TClass,
// but TClass doesn't have the RibbitCreate constructor
end;

If you call TToad's OneMore you will get TToad, not TFrog, despite the fact that the method is inherited from TFrog unchanged.

AFAIK, you can't do such things in C.

[dmantione]

Why such advanced things? One can give much more practical examples, units for example.

I.e. the following isn't possible in C:


procedure write(l:Pmy_linked_list;var f:file);

begin
if l<>nil then
begin
system.write(f,l^.data);
write(l^.next);
end;
end;


Summing it up, in C you are constantly evading already existing identifiers. In Pascal, hakuna matata!

[Bijo]

I'm no specialist or professional, but I've had a little share of C, C++ and Pascal (but not Object Pascal).

To me it's those little things like ranges or subranges like 0..17 or something like that which -- as I remember -- cannot be done in C or C++.

Or what about...

with Thing do begin
value1 := 7;
value2 := 10;
value3 := 1;
value4 := 2;
value5 := 344332;
{etcetera}
end;

...that instead of...

Thing.value1 := 7;
Thing.value2 := 10;
Thing.value3 := 1;
Thing.value4 := 2;
Thing.value5 := 344332;
{etcetera}


If I recall correctly a similar thing -- the use of with-do -- cannot be done in C or C++. It's just a beautiful simple elegant touch that is effective as I see it.

[Robert Kosek]

You can actually use the with-do in functions ... :twisted:

with TObject.Create do begin
func_param1 := 'abc';
AOwner := Form1;
end;

In C/C++ (AFAIK) you cannot do:// Read until INI-File style comments. :D
repeat
inc(i);
until (inStr[i+1] in [#13,#10,#0,';']);

In fact, I even coded a semi-complete 3 byte (YES!) variant system for a variant stack for scripting! In four hours!!

I work in ANSI-C for CGI scripting for a web interface as a part of my work. It's ugly, instable, requires work-a-rounds, and really hard to keep up to date without breaking anything. I could rewrite our whole interface in Pascal -- ignoring the time to get adjusted to Pascal CGI -- in less than half the time it has taken them to add pages and maintain the present beast.

[Bijo]

Heh heh, what a great topic, people. I rejoice when I notice criticism (or the likes) on C/C++, heh heh :D


DarknessX, check out this link: http://www.zel.org/oberon/fromctoo.htm : it's about Oberon-2 and such and C and C++. It might prove you useful.

[Setharian]

procedure GetRawData(const F: Single): Integer; inline;
var
I: Integer absolute F;
begin
// returns binary representation of a float in an integer
Result := I;
end;
absolute keyword, I am not aware of an equivalent in C....aliasing one variable over another is considered hacky, but sometimes it has its uses :)

also you forgot about the best, built-in support for strings and dynamic arrays with reference counting....something C(++) can only dream of (it is possible by using smart pointers in C++ but it's ugly and not used)...next extremely fast compilers compared to C++ ones (C ones can be quite fast because it's actually a lot cleaner than the monster C++ is)...then support for method pointers (function(Args): ResultType of object) which is also missing in C(++)....sets, subrange types (already mentioned), interfaces (those can be simulated with abstract base classes combined with multiple inheritance in C++)....and I guess one may find even more things which are better in Object Pascal than in C(++)....

sometimes I wish OP would allow some equivalent for C's bitfields in structures with automatic shifting/masking to get the correct results on set/get possibly enhanced by OP's range checks....that would be cool ;)
class allocation on the stack is also a nice feature, on the other and it makes C++ classes just a bit more than structs and forces you to use pointers everywhere (explicitly) while in OP class instances are implicitly pointers and save you a lot of headaches.....

all in all I'd say OP has more features which C(++) does not than C(++) has and OP doesn't have...that combined with a much less confusing syntax and easily readable code makes it a perfect choice for development....

[dmantione]

sometimes I wish OP would allow some equivalent for C's bitfields in structures with automatic shifting/masking to get the correct results on set/get possibly enhanced by OP's range checks....that would be cool ;)


✓ Check :twisted:

Try {$bitpacking on}, then declare a packed array or record.

[JernejL]

Try {$bitpacking on}, then declare a packed array or record.

which compiler supports that?

[Setharian]

no idea what that directive does....it would seem it reduces sizes of structures to a bare minimum but since I know no syntax with which I could declare fields with size of X bits I'm not sure how I can I make use of it...it isn't documented in the online documentation...besides I'm using Delphi IDE with DCC :)

[dmantione]

Simple, with bitpacking the compiler does not allocate more than needed, so use 0..1 for 1 bit, 0..3 for 2 bits, 0..7 for 3 bits etc.


{$bitpacking on}
program bitpackingtest;

type two_nibbles=record
a,b:0..15;
end;

begin
writeln(sizeof(two_nibbles));
end.


... will output 1. It is a new feature of FPC 2.1.4 we coded for Mac Pascal compatibility. Make Borland a feature request :)

[Setharian]

refer to CodeGear now :) still I doubt they'll listen...I haven't seen them implement a new feature users requested for a long time...only features added were just to bridge with Delphi.NET more or less....nonetheless it's a nice feature you added to FPC ;)

[JernejL]

You guys actually implemented bit-aligned record fields? do they also pack together on bit level or are padded to next byte? what does sizeof return for them?

[dmantione]

They are bit aligned. Don't save the last byte of memory, save the last bit of memory :rambo:


program bitpack;

{$bitpacking on}

var a:packed array[0..15] of 0..63;

begin
writeln(sizeof(a));
end.


daniel@laptop:~> ./bitpack
12
daniel@laptop:~>

[WILL]

You know thats actually quite handy if you're working with things like older tracker module formats and the like.

How long until you think that FPC is going to start giving the current Delphi compiler a run for it's money? :) Besides .NET and the fact that FPC has a huge platform support base comparable to no other than GCC.

[dmantione]

In what way is the current Delphi compiler still superior? So, I think when has to be answered with "now" if we are looking at the compilers.

[JSoftware]

I think the Delphi compiler has a few things I would miss in FPC. But most of those are the new additions like class variables and all the OOP goodness

On the RTL side I think FPC is still a bit more clunky and heavy to work with. On several occasions I've managed to crash the compiler when working with some exotic libraries and stuff. (This is a while back so I don't know if the problem persists and didn't know where to report such bugs)

The FPC community also seems a little hidden and/or old-fashioned. Is there actually a specific Freepascal community? :P

[dmantione]

Well, the mailing lists and 800 and 500 members and get hundreds of messages per month. There are 12000 user accounts in the community system with a about 200 messages per month. The Wiki is actively used. So, yes, I think there is a Free Pascal community and it is rather large.

There is and has always been a link to the bug tracker on the front page, so I don't think it can be so hard to find out how to report a bug.

[wodzu]

What I don't like on freepascal site is the forum engine. It has not changed from years. Any particular reason to stick with it instead of some newer engines? I think community suffers a bit because of it. Or maybe its only me;-)

[dmantione]

There are more people have that commented on the forums both in positive as in negative way. Technically the system is one of the most advanced you can find; it wouldn't make sense to drop it, but there is quite a bit you can do with the UI, i.e. http://www.virtualmin.com/forums/ has the same engine, but a totally different presentation.

I prefer the categorized Q&A over for example a threaded or UBB styled UI like PGD has though. If somebody has ideas, they are welcome though.

[Robert Kosek]

There are more people have that commented on the forums both in positive as in negative way. Technically the system is one of the most advanced you can find; it wouldn't make sense to drop it, but there is quite a bit you can do with the UI, i.e. http://www.virtualmin.com/forums/ has the same engine, but a totally different presentation.

I prefer the categorized Q&A over for example a threaded or UBB styled UI like PGD has though. If somebody has ideas, they are welcome though.Categorized Q&A is good for nothing if there is no age sorting, and no answers. I asked something a long, long time ago and was never answered. The wiki-esque forum is horrible to anyone not already used to using it. I won't pretend to like phpBB, I loathe it in fact, but there is a distinct difference. The Virtualmin forum is superior to the FPC one as it still retains some similarities with a forum. My only advice to you is to try this forum, punBB (http://punbb.org/), if you like the style -- if I wanted to use FPC's forum I'd sooner go to a newsgroup.

This isn't meant to be insulting, but to give a hint as to why I'm just not interested in learning FPC if I feel the support structure largely isn't there. Going through 3 ]extremely[/i] disappointed. After about 3 times of just me asking, plus the 8 other requests by other people, CodeGear still has not said what their plan for the turbo line is.

I think I like FPC's operator overloading better, if I can overload the implicit/explicit operators then I love FPC's operator overloading, and the ability to use the -=/*= style assignments like C. But it isn't enough to get me to come over yet. Lazarus creates bloated applications, and FPC's smallest Hello World application turns into a 230kb app. I wrote a tokenizer and basic program/scripter based off console input in Delphi and it compiled to about 42kb -- no comparison there.

But, again, considering the future direction and subsequent descent of Delphi, Lazarus and FPC may become our only hope. I hate selling my hope on one compiler -- that's what has happened with Delphi and look where it is going now.

[Setharian]

FPC is a bit superior to the D06 lineup, specifically the Turbos in my case, as it is more stable. Turbo Delphi will crash easily for me, without trying even, and I get stuck with all sorts of bogus errors that prove that Delphi was indeed written in C++. But, I heard that D07 was incredibly stable in comparison to its predecessor. Having looked at the roadmap for the future releases of Delphi I can only say I'm am extremely disappointed.
in the first sentence you meant Lazarus and not FPC I guess :) FPC IDE cannot be even compared to the Delphi one :) I own D2007 and I am very satisfied with it, so far no crashes at all....I got 3 exceptions, 2 of them were caused by the fact that some files were marked as read-only and they could not be overwritten.....it's also fast (apart from Code Completion :S), load times are also a lot better than previous versions (if you spend 2 hours rebasing packages the IDE loads it's even better :) )...so overall it's a very good product (finally), yet it can get even better....when it comes to the roadmap - I don't like it neither, all "goddies" are planned for next year or the year after which is kinda too far away, people have waited long enough....on the other hand you also have to take into consideration that they are a new company and Highlander was already being worked on in the "old Borland" with clear .NET focus and it wouldn't make sense to abandon almost finished features....Unicode VCL and RTL are great and I think CG cannot bring those features any sooner than next year considering all the facts but Win64 support in 2 years is the main "show-stopper" for most of the people....I hope they'll at least release DCC64 pre-release or something with Tiburon....

operator overloading in FPC is nice yet maybe too "non-OOPish" :) but it does its job well....when it comes to +=, -=, etc. operators, I really do not like them that much, they should have stayed with C....there is one thing I like about FPC and that it is commited to be a competitor with C/C++ more than with C#...as a result it is introducing features which helps you write faster code in a nice manner unlike CG which is fighting with C# and it is bringing OOP features which are nice but either result in slower code or are just syntactic sugar...

[WILL]

Daniel is right, the FPC/Laz site is very well integrated together with everything that the developers are hooked into. Though I can't say I share the same love for the UI. :P

What might help is some sort of alternative interface or 'skinning' where a participant can choose their preferred UI for the forums. Unfortunately, that would mean adding some new scripts to the site. It really would help to welcome new users though.

But anyways getting back on topic; The IDE is not a part of the compiler it's self. Nor is it a factor into the language. It only goes to implementation which is a fruitless point to argue when discussing like things.

[JernejL]

They are bit aligned. Don't save the last byte of memory, save the last bit of memory :rambo:


program bitpack;

{$bitpacking on}

var a:packed array[0..15] of 0..63;

begin
writeln(sizeof(a));
end.


daniel@laptop:~> ./bitpack
12
daniel@laptop:~>

so, what does it return for just 4 bits in the record?

also, FPC & LAZ have pretty active IRC channels.

[dmantione]

In such case, sizeof will return 1.

[wodzu]

[quote="dmantione"]

FPC is a bit superior to the D06 lineup, specifically the Turbos in my case, as it is more stable. Turbo Delphi will crash easily for me, without trying even, and I get stuck with all sorts of bogus errors that prove that Delphi was indeed written in C++. But, I heard that D07 was incredibly stable in comparison to its predecessor. Having looked at the roadmap for the future releases of Delphi I can only say I'm am extremely disappointed. After about 3 times of just me asking, plus the 8 other requests by other people, CodeGear still has not said what their plan for the turbo line is.


Why extremely dissapointed? Of course every of us (CG think different here;P ) would like to have more focus on Win32 but if they have puted so much effort into .NET let them finish this 2.0 release. Than will come time to Win32 and improvements, I hope ;-) If you can test D2007 do it, you will see its a really nice edition.

The one thing which amaze me is that how single user can contribute to the Delphi. First new memory manager and now Generics
:shock: . 1 year before CG :) Personally I don't care about that. I care for faster Win32 compiler but will it ever happen? It seems FPC is gaining advantage here with every release which is great. If it will only have better GUI :(

[Robert Kosek]

I'm disappointed because CodeGear thinks .Net is important, and is delaying the next VCL/Pascal Delphi version to ~2 years away. And worse still, the added features are nothing big, helpful, or worthwhile in the long run. I have never actually made a cent from what I do with Delphi, so unless they update the Turbo line (like I hope they will) I'm stuck with a hugely buggy compiler. I honestly don't know what to do. I like Delphi and want to continue using it ... but the price tag on 2007 is kind of crippling for little improvement aside from a more stable IDE and additional VCL components. Etc.

That's why I'm disappointed. I don't really want to switch to FPC because, like I said before, I feel like the support structure isn't there. The fact it is and works for those already using it is irrelevant -- as leaving it there will never encourage newbies like myself to take the step.

[dmantione]

You sound a bit like the guy that kept insisting for 10 years that Free Pascal was no viable alternative for Turbo Pascal because it couldn't compile his 16-bit assembler code. :wink:

[Robert Kosek]

No, I'm a guy who wouldn't mind the change, if he felt there were actually enough people to answer his questions. And yeah, I have read a lot of the FPC documentation -- but I'm still left with many questions. If I have a problem or Delphi related question I know 4x as many places to ask as I do for FPC; not to mention the fundamental differences between FPC and Delphi.

I've written a few FPC applications already which you can find here, and formerly on my own site. But it takes me almost 3x as long to program just because of language differences.

I already know, and have known for a good 2 years, that FPC is viable and a decent alternative. Barring filesizes and enhanced XP skinning compatibility in Lazarus (try the demo of WindowsBlinds with Lazarus and you'll see why I don't use it; my custom skins freak the whole application out) of course. I have already threatened CodeGear that I'll go full out FPC if they don't tell me what they're going to do with Turbo Delphi -- no update, - 1 User.

[DarknessX]

I actually prefer plain old FPC. Not sure why, but in the long run, it will help me a lot. Only thing, is I have no clue just how to use the debugger, so I don't use it at all :O It makes bug-finding annoying, but when you finally track down the bug, its so fulfilling :D

[dmantione]

Debugging is indeed the achilles heel of FPC; the GNU debugger has proven to be one big annoyance. But using it can't be the problem I think as both the text mode IDE and Lazarus provide the well known TP/Delphi debugging keys. The best debugging experience is probably the textmode IDE, as there is a lot of code in it to circumvent GDB limitations.

[DarknessX]

Well, I don't even use the debugger, so it doesn't bug me much. For that matter, I only recently found that the debugger was there :D

Thanks for all the comments though. I would like to see a couple 'upsides' to C/C++ though, just to see if its worth my while to try learning it...

[Bijo]

"Upsides?" What upsides? Heh heh :D

[wodzu]

Thanks for all the comments though. I would like to see a couple 'upsides' to C/C++ though, just to see if its worth my while to try learning it...

It will be hard and my end with endless thread... :wink:

However I think that there is one undisputed 'upside': compilation speed :D

[WILL]

The speed at which a language compiles it dependent on the compiler it's self, thus a moot point. I'd say at best it's a temporary/replaceable plus.

[Bijo]

True.

Nevertheless it is an important point regarding the languages. Therefore might I suggest we compare certain mostly used compilers of C, C++ and Pascal and Object Pascal? I am myself not too knowledgeable regarding the compilers but with a wild guess I would say those mostly used are the following (please correct or add if required):

For (Object) Pascal:
* FreePascal
* "Delphi"

For C/C++ :
* GCC / G++
* Microsoft Visual C++



EDIT:
http://www.kuro5hin.org/story/2004/2/7/144019/8872
This article was residing among my bookmarks. Perhaps it will prove useful to anybody here.

[JSoftware]

Compilation time for pascal is great because most compilers are one-pass. This disallows funny/unfunny stuff like macros. As a uC programmer, this is a must have. If there ain't macros the compiler will need hardcoded syntax extensions

[DarknessX]

So what exactly IS a macro? That's something I'm not sure about, but i think it is something that does repetitive work for you.

[Chebmaster]

{$define <identifier> := <some complex expression>}

After that, every time the compiler sees that identifier it treats it as that complex expression. Not a much by itself, but when combined with conditional compiler directives macro can become a very powerful tool.

I, for example, built with their help something akin to generics in FPC 1.1 (there wasn't even 1.9 yet!) . Of course, handling it all is a pain, compiler (at least its earlier versions) could not pinpoint the error location properly if macros are involved, the code completion in Lazarus died trying to parse that stuff... But it worked, and helped me a lot.

[JSoftware]

{$define <identifier> := <some>}
isn't that just a compiletime variable? I define a macro as either a compiletime variable or compiletime inline function.

{$define <identifier>(parameters) := <some>}
{$define <identifier> := <some>}

[Legolas]

{$define <identifier> := <some>}
isn't that just a compiletime variable? I define a macro as either a compiletime variable or compiletime inline function.

{$define <identifier>(parameters) := <some>}
{$define <identifier> := <some>}

AFAIK fpc does not allow parameters (in libnds conversion I had to change a lot of defines to inline functions). Maybe do you mean in Delphi?

[JSoftware]

{$define <identifier> := <some>}
isn't that just a compiletime variable? I define a macro as either a compiletime variable or compiletime inline function.

{$define <identifier>(parameters) := <some>}
{$define <identifier> := <some>}

AFAIK fpc does not allow parameters (in libnds conversion I had to change a lot of defines to inline functions). Maybe do you mean in Delphi?
No, I mean I could use something like that :P

[Ingemar]

I generally avoid discussions like this, but at least this is in the right forum for avoiding stupid pro C++ arguments like comparing C++ to Pascal of the 70's. They always do that because they don't know Pascal, they just want to flame it and giving themselves a reason to forget the question.

But I have a special reason to wake up this old thread. We teach OpenGL in C (not because I like it but because it is the closest to a common denominator language for students with no nice teaching language in their background). I chose that simply because I need to fight one battle at a time. I feel that it could work so much better if we used FPC, and a decent IDE, but the rest of the university seems to hate my ideas. They seem to prefer Emacs + Unix terminal, students that can't debug, Java and C++.

But the other day some students questioned the choice. Well, no wonder, I don't like C myself. (They should see my anti-C T-shirts. How about "C is a grade" on a T-shirt? I have it...)

I have been collecting arguments. What features are important in a teaching language? Portability? No problem for FPC. Readability, intutive syntax? I think FPC is superb in that respect but how do you measure it? Language features? I think FPC has plenty (operator and function overloading, automatic namespaces, dynamic arrays, some garbage collection - but not for everything) but what am I missing? It even has portability to C/C++/Java as a bonus, anyone knowing FPC well will learn C/C++/Java easily (but might not like it).

I think that OOP being an optional feature in FPC programs is a great thing. Teaching can start out procedural, students who work more efficiently without it or by mixing the two methods may do that as they please. That is IMHO much better than using a stupid language like Java that tries to force people into the "only way". I hate that and believe the very idea, locking in the thoughts of students in One Ring To Rule Them All, should be banned from universities. (So even C++ is better in that respect.)

So... are there other arguments that would help me speak in favor of FPC, or pitfalls that I should prepare myself for?

[chronozphere]

The main issue here is that C/C++ is more widely used, which means it shows up more often in research papers and more people at universities know how to read/write it. FPC would be a good alternative, but it's hard to convince people because pascal became populair in the 80s and most people still have that picture in mind. If it was something brand new, it would be way easier.

One thing that strikes me though, is that most people here seem to think that pascal is "the" language (ok, it's a pascal forum haha) and also that learning languages is hard. I've experienced that once you know the concepts it's not that hard to learn C/C#/Java/Python/Ruby etc etc.. I'd advice everyone to do so. I see languages as tools and every tool has it's pro's and con's. Knowing a bunch of them makes you a better programmer, because you will see how each language would solve a problem, which allows you to pick the right tool for the right job.
It's true that pascal has a lot of features and power, but it's not neccesarily a reason to "not learn" other languages. :) The biggest advantage of having a "big toolbox" is that you can easily work together with other programmers, and have fun (which is where programming is all about ;) ) , without having to debate about the language to use. There is no "best" language.

[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&#58; pointer;
a, b&#58; integer;
...
p&#58;=p + &#40;a*b&#41;;


In Delphi you must add a lot of unnecessary typecasts:

p&#58;=pointer&#40;cardinal&#40;p&#41; + &#40;a*b&#41;&#41;;

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. :D

[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) )

[LP]

Why are you still debating Pascal vs C/C++? Why not English vs French?

For beginners, the language itself does not matter as long as it can be represented in a fairy readable way and it mostly depends on who is teaching this subject.

In professional sphere, as long as you took enough software engineering courses, the language also does not matter because it's just a low-level way of representing your final application's architecture. You'll be spending time doing other things anyway, such as designing UML diagrams, etc. Converting the properly-written diagrams to code is mostly a trivial task and there are IDEs that do this for you.

In any case, a proficient developer will use almost any programming language as a powerful tool. Well, the only exception is probably Lotus Notes Script. :P

The only thing that makes the difference is the compiler itself and the development IDE. The first can make your application execute faster (though in many cases these days raw execution speed is no longer an issue) and the second saves time when writing and/or modifying code.

I think latest versions of Visual Studio and Delphi XE 2 work very well in terms of compiler, and they have excellent IDEs. Even for PHP, there are some excellent IDEs, like Nusphere's PhpEd.

For beginners I think C#, Delphi's Pascal and PHP are all excellent candidates to start with.

[chronozphere]

@LifePower: I completely agree with what you are saying. :) Learning a new language is mostly about the syntax, while most of the semantics are shared between different languages, making it easier to learn a whole bunch of them.



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


OOP is not a language. It's a paradigm. ;) The paradigm is "used" in different language. JAVA is entirely based on OOP, but Pascal/C++ are so called multi-paradigm languages, supporting both the "procedural programming paradigm" and the "object oriented programming paradigm".

[code_glitch]

Although I'm not an advocate of reviving very ancient threads (a bit like this one now I think of it... ;D) I simply can't resist the temptation :D:

FPC AND PASCAL OVER C++ ANYDAY!!!!
PASCAL FTW!

In seriousness, code readability is a big thing for me - counting curly brackets, and cryptic loops and typecasts simply fails to appeal to me for some reason :)

[User137]

I never really got into C++ classes and templates... they turn my head in. Simple thing as pointer usage itself is much more confusing.

[LP]

Just wanted to add something constructive to the discussion. Strictly speaking, deciding to use certain language in some cases does mean the explicit use of certain IDEs. For instance, if you want C#, most likely you will work in Visual Studio; on the other hand, if you want to work with Pascal, most likely you'll end up using Delphi or FPC/Lazarus.

In my own case, when I started learning to program, the only choices were Basic and Pascal. Later on, when I got my hands on C/C++ compiler/IDE, I didn't like the idea of separating class's headers in separate files, in most cases it was more nuisance than useful; many source code files can become difficult to organize. Later on, Delphi appeared. For quite some time, Visual C++ didn't allow WYSIWYG interface design and its own visual library was difficult to use, so I stayed with Delphi.

Roughly ten years ago C# appeared and they finally got rid of the separate header files and added class properties, something that was really missing in C/C++ for quite some time and it's an important design feature in software engineering (there are ways to overcome this in C++ for some versions of Visual Studio by using templates and so on, but it's not standard among different compilers). However, it has its own nuisances as you always have to distribute .NET and/or .NET profile packages because rarely people will have the latest .NET installed on their machine.

Right now, I'm still sticking with Delphi because of the native compiler. In my case, for scientific applications I need real-time speed; for game development it is also important. Suffice to say, we would not be able to create Aztlan Dreams using C# or Java: the AI makes 3-4 turn predictions with 8-level branching (this doesn't sound too much, but think of the fact that for each combination you need to model the entire 64x64 map and its scripts) using multi-threading on multi-core CPUs, which will be difficult to solve in real-time on a virtual machine.

In our institute, the administration department always thought that Java (and other VM-based languages) will take over the world. Apparently, this did not happen. Yes, Java right now is on the majority of the cell phones (Blackberry, Android, etc.), but that is because of the engineering design: it is much easier to make a short portion of OS, implement VM and then run all existing code in Java, rather than to create native compiler for every possible hardware combination. In this case, Java is used mostly for historical reasons; they could pretty much use C#, JavaScript or even Lua for that matter.

[code_glitch]

AirPas: Wouldn't that be NASM? ;) I believe nothing is faster than ASM on x86... Although I'm more of a devcpp/gcc fan myself...

[Daikrys]

Yuriy got some good points

C# disadvantage is the .NET framework, you sometimes have to download packages that arent include in youre version or if its included in the installation it make it often bigger then the game itself

when i started with Java in my schooling i found Java really slow and some stuff was really complex to code, it was said that Java will be the magic language and in 5-10years it will be the common programming language (what a joke)

i still wait to see if HTML5 can manage to take the lead in smartphone developement
do anyone think HTML5 is just another hype or will it become a good standart for web and crossplattform developement?
only tried a few games written in HTML5, havent read that much about it yet

[Cybermonkey]

Yuriy got some good points

C# disadvantage is the .NET framework, you sometimes have to download packages that arent include in youre version or if its included in the installation it make it often bigger then the game itself

when i started with Java in my schooling i found Java really slow and some stuff was really complex to code, it was said that Java will be the magic language and in 5-10years it will be the common programming language (what a joke)

i still wait to see if HTML5 can manage to take the lead in smartphone developement
do anyone think HTML5 is just another hype or will it become a good standart for web and crossplattform developement?
only tried a few games written in HTML5, havent read that much about it yet
At the moment I am digging into Javascript/HTML5 and I think (if the mobile browsers/machines become faster) it will dominate the game development on smartphones. If I may post some links here:
http://www.brighthub.com/hubfolio/matthew-casperson/blog/archive/2009/06/29/game-development-with-javascript-and-the-canvas-element.aspx
http://kevs3d.co.uk/dev/asteroidsbench/ (Interesting benchmark, FF seems totally slow when it comes to the canvas element).
http://sebleedelisle.com/2011/04/html5javascript-platform-game-optimised-for-ipad/

Okay, enough off topic, I've just realized this topic is about C/C++ vs Pascal. ;-)

[Colin]

if you chose any language , you will win things and losing things .
in windows os i belive that VC++ produce the most optimized code .

i think you may be right if you spoke of vc 2003, but later editions have gone dreadfully down hill, latest tests showed gcc provided better assembled code than vc 2005, 2008+

[thegilb]

Hello PGD Community. As a professional game developer I felt compelled to offer some insights into this topic from a different point of view.

The natural reaction is to defend whichever language presents the least resistance, which isn't a bad reaction but it's not necessarily right because this opinion is biased by whichever language you know the best. From the average PGD visitor that language will be Pascal, but Pascal as well as other languages can offer interesting and unique low resistance solutions to certain problems.

There are pros and cons to using any language. Off the top of my head I can think of at least a dozen problems with C++ as a language, maybe more if I put my mind to it, so why do we use it? In priority order, they are:

Every platform supports it (PC, Consoles).
Everyone already knows it.
One way or another it does everything you need it to.


I'm not saying any one of those is a hands down winning reason, though it does help a lot if your team all know (and use) the same language. What we're talking here is the path of least resistance. I think there are several reasons why C (and then by evolution, C++) became prolific, but none so important as the venerable Unix - the first OS to be written in C, which went on to become an open standard. I'm not saying C/C++ has popularity for the right reasons, but it is arguably very popular. Maybe less so now that other languages exist that solve some of C/C++'s more difficult problems, but those that still use it have a good reason, which ultimately comes down to taking the path of least resistance so they can get their job done to the required standard.

Speaking of performance in C++ is a moot topic. Most often the biggest performance win is gained by carefully choosing your data structures and algorithms, which applies to any language. In more recent versions of the Visual C++ compiler (2008, 2010), the biggest performance gains from plain old compiler output are in runtime analysis aka profile guided optimization, but often the compiler you use is not a choice you make, you work with the tools you have and the job of the engineer is to make the most of those tools and the target platform architecture. So whether it's GCC or Visual C++ doesn't really matter, you will always find a way to get the best performance out of either or the other. That's our job.

If you're talking about something other than console games, then other languages apply just as easily. For example C# is the language for Unity, XNA, MonoTouch, and of course C# is great for developing desktop and web applications. In fact the games industry uses C# for tool development, but as is often the case, it varies from one developer to another. Epic for example choose to use C++ and wxWidgets for UnrealEd, but then for them that fulfilled their goals and offered the path of least resistance. However, you wouldn't catch Zynga using C++ to write their social games, because that would conflict with their goals.

HTML5 is becoming increasingly important in the social games battlegrounds. Though Flash (and even Java) offers a more predictable platform, though more of a desktop platform, Flash is currently the default choice. As social games begin to transition to mobile as well, HTML5 is growing in significance, but in practical use it's difficult because of radically unpredictable performance and sporadic vendor support - though that is changing all the time, and in my opinion will become the default choice for social developers in the near to mid future.

If your goal is simply pleasure, there is no good reason not to use whatever language suits you best. Good games can be written in any language, including Pascal. What really matters most is that you're doing something you enjoy.

[code_glitch]

Erm... This is beating around the bush after its empty (or at least feels like it) and of course, welcome to PGD glib, but I can't help noticing:





Every platform supports it (PC, Consoles).
Everyone already knows it.
One way or another it does everything you need it to.

[QUOTE]
1. Pascal (and dialects) are supported on GBA/NDS/ARM/X84/X86_64/Wii/GameCube/PS2/Xbox. Thats most of them done is it not? There are rumours about the PS3/PSP
2. If your school where you learnt C/C++ did not teach you pascal - I'd be surprised. Aside, Pascal is C/C++ just without the confusing syntax no?
3. What does pascal not do one way or the other?


The old arguement was the C/C++ was faster than pascal - now if we benchmark the new C variants that are in the Visual Studio suites its hard to find one instance where .NET is left out of it - and .Net is not exactly the fastest horse in the race...

I guess you could always use the XNA and framework argument - BUT I find pascal easy enough to use we don't need a framework like XNA to make it easier, plus we have the Direct3d bindings if thats what floats your boat...

My problem with flash is that the (cough cough) supplied (choke) hardware arghhhh-celeration is dodgy at best... My ATI HD4330 plays a lot of games in med/high, yet battles with some flash games!?! Sort of the same problem for Java. I mean, how does C&C3 in med/high use less power than miniclip?

Not saying you're wrong or anything, just continuing the jist of the thread - C/C++ is just chosen out of popularity over pascal, its not really down to propper reason in many cases.

[LP]

Thegilb, thanks for some interesting points! I'd like to discuss some of them.


The natural reaction is to defend whichever language presents the least resistance, which isn't a bad reaction but it's not necessarily right because this opinion is biased by whichever language you know the best. From the average PGD visitor that language will be Pascal, but Pascal as well as other languages can offer interesting and unique low resistance solutions to certain problems.
In this context and considering what you said, for what language is your own opinion biased to?


There are pros and cons to using any language. Off the top of my head I can think of at least a dozen problems with C++ as a language, maybe more if I put my mind to it, so why do we use it? In priority order, they are:
Every platform supports it (PC, Consoles).
Everyone already knows it.
One way or another it does everything you need it to.
Well, it will be somewhat difficult to actually prove all of these points literally. However, the truth is that this is a very common fallacy, Argumentum ad populum/numerum (http://en.wikipedia.org/wiki/Argumentum_ad_populum). Many people knowing it, or using it does not make it the best choice, even for those people themselves.


I think there are several reasons why C (and then by evolution, C++) became prolific, but none so important as the venerable Unix - the first OS to be written in C, which went on to become an open standard. I'm not saying C/C++ has popularity for the right reasons, but it is arguably very popular.

Actually, the fallacy I've mentioned above is also called "Appeal to Popularity". C/C++ being popular at some point in history does not mean it was the best language or even the best choice at that time.


Speaking of performance in C++ is a moot topic.[...performance discussion...]
You have agreed yourself that the performance is gained by choosing data structures and algorithms carefully, which applies to every other language; therefore, I don't understand why you keep discussing C++ performance alone. No comparison was made to "Pascal" performance, you simply acknowledged that compiler optimizations that are present in Pascal compilers are also present in C/C++ compilers.



If your goal is simply pleasure, there is no good reason not to use whatever language suits you best. Good games can be written in any language, including Pascal. What really matters most is that you're doing something you enjoy.
According to the above, if the pleasure is NOT one of your goals and/or if you are not doing something you enjoy, then what language should you use?

[SilverWarior]

My problem with flash is that the (cough cough) supplied (choke) hardware arghhhh-celeration is dodgy at best... My ATI HD4330 plays a lot of games in med/high, yet battles with some flash games!?! Sort of the same problem for Java. I mean, how does C&C3 in med/high use less power than miniclip?

Most off flash games doesn't even use full hardware support, like OpenGL or DirectX. That's why CPU load is alway high while playing theese games. Also another drawback are browsers. Why? Not all browsers support full hardware support for any flash game. For instance there is a big difference between Internet Explorer 8 and internet Explorer 9. Why? Internet Explorer 9 is using DirectX surface for renderning page graphics (including graphics of flash applications) . Becouse of this the renderning itself is done with the help of a graphic card, wich leaves more CPU power to proces something else. In Internet Explorer 8 the pages were renderned on a normal window surface (exuivalent to canvas), wich is much slower and uses much more CPU power.


Now for the main subject of the theme.
I like Pascal much better than C/C++ even thou I first started programing in C++. Why?
1. Pascal sintax is much more comprehensive for me
2. Delphi IDE wich I'm using has many neat fetures and even a good runtime optimizer.
3. I like the ability to be able to declare local variables wich are accesible only from certain function oz procedure. I also like when theese variables are being automaticly freed when function or procedure ends (ending in regular way or by some exception). This helps alot in lowering memory leaks.
4. I like how projects are being precompiled and then linked. This way only the units wich has been changed from the last compilation are being recompiled, all other units are just being linked into the application. This enables much faster compilation, and actualy alows you to build an application wich is in a signle file.
5. I DON'T like tha fact that it is sometimes very hard to find some code samples, due to lower popularity of Pascal, especialy if you are trying to looking for the code wich utilizes latest technological fetures. I especially don't like when I find some poor C++ or VisualC to Pascal translation, becouse most of the times the code doesn't work as efficient as the one in C++ or VisualC, and all off this only becouse off a poor translation.

[WILL]

I'll chirp in only to say that a lot of what was Pascal way back when, is not Pascal now. A lot has changed for all the fun variations of Pascal in the last 5 to 10 years. Too many to list in a small post. By popularity there is approx. 4 different standards or "languages" based off of the original Pascal langauges; Classic(Borland) Pascal, Object Pascal, Objective-Pascal and (most recently declared) Oxygene. Then there are all those new and fun differences based off the various compilers. (Free Pascal and Delphi specifically)

Pascal is now everywhere where as 10 years ago it was not. There is a bit of a curve for the computer science public to catch up to a new state of things as information doesn't always get passed on about Pascal since we are coming from a very small set of communities and are steadily growing.

Just wait one of these days in the future there will be some crazy guy whos like me, running their own small C-based community long after the Pascal language has taken over the industry. ;)

[thegilb]

Thegilb, thanks for some interesting points! I'd like to discuss some of them.

Sure, I've got a bit of time to kill.



In this context and considering what you said, for what language is your own opinion biased to?

It really depends on the project. Based on the task in hand, I might choose from Actionscript, PHP, Javascript, C/C++, Pascal, Java, Ruby, Python, C#, Assembly (80x86, x64, PPC, ARM), Objective C. Those are all of the most common languages I work with, though more recently I have been learning Erlang, io and Go.



Well, it will be somewhat difficult to actually prove all of these points literally. However, the truth is that this is a very common fallacy, Argumentum ad populum/numerum (http://en.wikipedia.org/wiki/Argumentum_ad_populum). Many people knowing it, or using it does not make it the best choice, even for those people themselves.

I agree, but conversely that doesn't necessarily make it a bad choice, if both languages are similarly capable. The language will not itself write good programs for you, it is in the hands of the engineer to write good code.



You have agreed yourself that the performance is gained by choosing data structures and algorithms carefully, which applies to every other language; therefore, I don't understand why you keep discussing C++ performance alone. No comparison was made to "Pascal" performance, you simply acknowledged that compiler optimizations that are present in Pascal compilers are also present in C/C++ compilers.

I'm not defending C++ or Pascal here. Performance alone is not necessarily a good reason for choosing a language. If performance was of paramount importance then we'd all be working in Assembly language. However, since we're not, what's the reason for that? The simple answer is that put simply, a program that takes 6 months to write in Assembly can be written in a week in a high level language such as C or Pascal. Considering the size and complexity of your average console game, you could be looking at development times that run into decades and only written by immortals.

The modern developer will often rely on the compiler to produce optimal code, but no compiler is perfect. Some careful profiling can yield a few fps boost in problem areas, but often the biggest gains are in careful choice of algorithms and data structures. Nearly all programming languages allow developers to make these choices, after all, that's their job. It is up to the engineer to write optimal code, the compiler is just a tool to help.



According to the above, if the pleasure is NOT one of your goals and/or if you are not doing something you enjoy, then what language should you use?

Well, then it's time to consider a career change ;)

[thegilb]

Just wait one of these days in the future there will be some crazy guy whos like me, running their own small C-based community long after the Pascal language has taken over the industry. ;)

You have a cool community here, you guys are going from strength to strength, and it's great to see the enthusiasm on here.

When the day comes that Pascal takes over the world, you guys are well prepared! ;)

[mobilus]

Epic for example choose to use C++ and wxWidgets for UnrealEd, but then for them that fulfilled their goals and offered the path of least resistance.

TS - Tim Sweeney

"-Wow, Pascal.
TS: Yeah, it was a good language. It was more rigorous than C++. When I moved from Pascal to C++ to create Jill of the Jungle, it was a real shock that people would actually be using a programming language that was so bad for large-scale development. To think that operating systems are built in that sort of language was really terrifying.
-So you think Pascal is more ideal to work in than C?
TS: It forced the programmer to be more structured and to avoid low-level hacking as much. It's not the best way to get maximum performance, but I think people tend to write much cleaner code when working in a language like Pascal than in C++. It influences your whole way of thinking about systems when you're writing code in a really structured way like that."
Source: http://www.gamasutra.com/view/feature/4035/from_the_past_to_the_future_tim_.php?page=4


As you can see, Pascal as a programming language was never a problem... even for real game developers. You should rather look for tools, for your arguments, but you will fall again ;) - today and tomorrow.



"It really depends on the project. Based on the task in hand, I might choose from Actionscript, PHP, Javascript, C/C++, Pascal, Java, Ruby, Python, C#, Assembly (80x86, x64, PPC, ARM), Objective C. Those are all of the most common languages I work with, though more recently I have been learning Erlang, io and Go."
"You have many slaves, Xerxes, but few warriors" :D

[Ingemar]

As a little update to this thread, I have thought things over and pretty much decided on the following for my CG course (starting in january):

Instead of offering the labs in C only, I will give them a choice: C or FPC. To me that's a no-brainer choice, but I will just let them decide, and recommend FPC for those who have little experience in working with pointers or who just prefer a language with fewer traps. And if they prefer C, be my guest.

The course is about CG and OpenGL, not about messing with pointers and learning C, and quite a few students don't have sufficient C skills anyway. Maybe I can help a few people and make the course a little bit more fun for me at the same time.

[LP]

By the way, Delphi has won two consecutive Annual Members Choice Awards on Code Project (http://www.codeproject.com) for 2010 (http://www.codeproject.com/PressReleases/2407/THE-CODE-PROJECT-ANNOUNCES-SECOND-ANNUAL-MEMBERS-C.aspx) and 2011 (http://www.codeproject.com/PressReleases/3935/The-Code-Project-Announces-Third-Annual-Members-Ch.aspx) years (see Programming Languages category).


Instead of offering the labs in C only, I will give them a choice: C or FPC. To me that's a no-brainer choice, but I will just let them decide, and recommend FPC for those who have little experience in working with pointers or who just prefer a language with fewer traps. And if they prefer C, be my guest.
Speaking about scaring the students of the programming languages... Why not teaching something modern like C# and XNA?

By the way, Delphi has some interesting CG stuff on Efg's Lab (http://www.efg2.com/Lab/index.html).

[marcov]

One thing that strikes me though, is that most people here seem to think that pascal is "the" language (ok, it's a pascal forum haha) and also that learning languages is hard. I've experienced that once you know the concepts it's not that hard to learn C/C#/Java/Python/Ruby etc etc.. I'd advice everyone to do so. I see languages as tools and every tool has it's pro's and con's. Knowing a bunch of them makes you a better programmer, because you will see how each language would solve a problem, which allows you to pick the right tool for the right job.


I've learner many languages in my life, and IMHO the languages barely matter. Pascal is an exception because I think its string type is the easiest, yet fast and productive.

For serious use, it is more often the complete picture (language+framework+library+compiler+community) that matters.



It's true that pascal has a lot of features and power, but it's not neccesarily a reason to "not learn" other languages. :) The biggest advantage of having a "big toolbox" is that you can easily work together with other programmers, and have fun (which is where programming is all about ;) ) , without having to debate about the language to use. There is no "best" language.

This sounds awfully like a recited lesson. Is this really own experience, or something you heard in class? :-)

I've heard it over and over in the last few years, and I think the whole concept that language is the most important bit is overrated.

Sure, extremely simplistic, obfuscated or defective (*) languages are a problem, but once you get to a certain minimal level, other factors are more important than language

(*) vote is still out on C. IMHO it is defective (the main issue is because == is so easily and silently confused with =), but the other factors (compiler availability most notably) is more important

[hwnd]

Old thread but what i really miss in delphi is STL. there are generics in XE but still nothing special.
atm im using stl through DLL. lots of useful stuff in STL and its fast.
Reason why i thinked about switching to C++, many times

[User137]

They are implemented in freepascal (hence usable with Lazarus)
http://wiki.freepascal.org/Generics
http://wiki.freepascal.org/Templates

Oh, but i don't believe it makes code any faster at all. Just might make it easier for programmer.

[hwnd]

what about std.map, std.vector. there is decal but doesnt satisfy me

[LP]

Old thread but what i really miss in delphi is STL. there are generics in XE but still nothing special.
atm im using stl through DLL. lots of useful stuff in STL and its fast.
Reason why i thinked about switching to C++, many times
What's so special about STL?

[hwnd]

speed and neat things like std:map. i tried xe tdictionary but it was unable to make same work as my c++ code. i got wrong results. dunno if tdictionary allows using custom sort routine.
i think problem was exactly in that.

[LP]

speed and neat things like std:map. i tried xe tdictionary but it was unable to make same work as my c++ code. i got wrong results. dunno if tdictionary allows using custom sort routine.
i think problem was exactly in that.
TDictionary uses hash table for storing key/value parameters. I don't know how or why would you need to sort hashed entries unless there are collisions. There is also ToArray function, which returns TArray, the last one does support custom sorting routine.

P.S. In my experience with TDictionary and XE 3, it is surprisingly fast, even with Unicode strings. I would definitely recommend it.

[hwnd]

Yes, for this project i needed only unique items to be added to std::map.
http://www.sgi.com/tech/stl/Map.html

It takes a custom sort routine and thanks to this i get only unique items.
XE TDictionary is also fast enough, but it isn't able to get me same results as std:map.
Probably because it doesn't handle collisions so well or something..

I don't know. I even tried Decal and other std:map like things for XE and none of them were able to produce same results.

Thas why i asked if it's possible to pass him some my own sort routine. So it handles collisions better and more precicely or something like that.


Atm im just passing my data to DLL from Delphi and DLL uses std::map to make the processing of data.
Works fine, but i wish i could do it without DLL's. Too bad, that Delphi is not able to link C++ .obj files, specially with STL code in them.




TDictionary uses hash table for storing key/value parameters. I don't know how or why would you need to sort hashed entries unless there are collisions. There is also ToArray function, which returns TArray, the last one does support custom sorting routine.

P.S. In my experience with TDictionary and XE 3, it is surprisingly fast, even with Unicode strings. I would definitely recommend it.

[User137]

I just stumbled across fpc version of map, called TFPGMap. Something like:

TMyMap = specialize TFPGMap <TObject, TObject>;

It's hard to find any documentation about it though, last post in this message-chain seems relevant:
http://web.archiveorange.com/archive/v/sKIuEe12vEIenhSBOh3g
I'm also unsure what version of FPC is needed.

[hwnd]

I found this for D7:
http://www.vanwal.nl/rbtree/

But i didn't try it properly.

Also found this for FP 2.7.1
http://www.lazarus.freepascal.org/index.php?topic=17902.0

FPC 2.7.1 is needed to compile it. The older versions will not compile this one.

Also this:
http://code.google.com/p/stlpascal/

Will try it later. Maybe i will have to port my editor to FreePascal / Lazarus to use this neat stuff. Dunno.


Also i don't understand, why is FP 2.7.1 only available with Lazarus 1.1 (which btw, just crashes like crazy for me, i can't even use it) but not also as individual download?

[User137]

2.7.1 is propably not considered stable yet. What i read quickly about TFPGMap too, is that there is no documentation yet because they're not even sure if they'll keep the syntax like that. It is the SVN version of freepascal, which i actually use along with SVN of Lazarus. Getting them compiled and running might be a little tricky though, but propably worth the effort.

If you want to compile fpc from source code, you need to do that with previous earlier stable release of FPC. For FPC 2.7.1 you propably need to download FPC 2.6.0 (or 2.6.1?) and compile SVN with that. There can be a bit fiddling with fpc.cfg configs, system PATH-variables and so on. I don't like to do that often... It's easier to update SVN Lazarus, assuming those fpc.cfg and PATH's are set right to point the SVN version FPC.