Delphi as an Object Oriented Language...


This question isn't about solving a problem or something like that.  I should probably have posted it in a newsgroup or something but since you guys are actually the best experts on the whole web (!!!), I'll give 50pts to the first 2 of you guys giving me a complete anwser to my question.  OK ? So here it is....

I'm teaching a class on basics of Delphi (loops, arrays, real basics!).  The students are programmers which a used to code VB and some C++.  I presented Delphi as an Object Oriented and some of my students asked me how is Delphi different than C++ regarding Objects.  They seemed to think there was a huge difference between the 2 language (they were kind of splitting Objects in two categories: Delphi's way and the others!)  

The thing is that I always thought that Delphi's way of doing it isn't very different than C++ does.  The only big difference I see is that there is no multiple heritage in Delphi.  

So you see my question comming, aren't you ?  There it is:  what are the difference between Delphi's way of handelling Objects and C++ one ?

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Well i dono really, u see i too was a C++ addept and i tought it was just the best thing ever, then after stubbling a couple of times w memory allocation problems,
i decided to change to delphi, thinking it would be better. I though that because often in the C++ Builder help u see that most of the o-o classes, such as AnsiString, are derived from Delphi classes, so i tought it would automaticly be better.

So after week of translating my code to delphi, i stumbled against the same problems, memory out of bound access and repeated crashes. So u imagine how i kinda felt, so i tried everything to find a colution, seeing that allocating records on the heap (structures in C++) was the source of all my problems, and having no one else to blame but myself (cuz before i switched, i blamed C++, lol) so i tried using TTables and db acess, but those only allow to store one table by file, wich was a big dropback for what i wanted to do (i had about 10 tables).
i am now programming my records into classes, and it seams to be running alot better ... for now.

Anyway what i wanna say is that i did OO before, in Java, i never actually used in in C++, but its about the same i guess, just like its about the same in delphi, and u know for many years now, thanks to Borland, the "owner", almost, of C++ and delphi, they have been progressing paralely, so the technology in both is very similar now, and seriously, i kinda like delphi better.

Well i think u want to know how it works down deep in memory and all, that i dono, but i guess its very similar, that is if u use c++ builder. But the way u work with OO is the same as in C++, and in Java too, O-O really has standards in every language, using objects in c++, pascal or C++ really is the same, well for me at least, aside from the languages differences.

I hope this gives the information u wanted.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
well there are no mayor differences between C++ and Delphi regarding how oo works

As much as i know delphi has 2 details it does not support
the first is what you already mentioned the multile heritage of classes(but if you ask me this is not a disadvantage it's an advantage of Delphi because multiple heritage of classes often leds to a bad design and unmaintainable systems) and you are still able to get the same results with better design patterns
and the second one are static variables wich are not supported by delphi. This is sad but true but also not a real problem after you can still simulate the benifits of class variables with unit private variables.
There's nothing more. What your students told you is nothing but usual C++ programmers snobism ... Tell them to give objective reasons for their opinion, they'll not be able to i bet ;-))
no much c++ experience,
therefore listening with interest

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

Take a look at this....

Maybe it will be some good to you

Good luck
one comment about multple heritage..You can simulate this in Delphi useing interfaces, but its only simulation not real multiple heritage. Now about OO prgraming, object oriented programming is nothing more but the way You design applications and I will be surprised if one day I'll find some major differences between OO in Delphi and other languages. Delphi is great because its RAD (Rapid Application Development) and its RAPID! (I remeber my first "Hello World" app in VC++ with MFC :-) ), but OO is just a method, You design objects and dependencies between them. I'll risk saying that good designed app can be implemented in any OO language, so if You have good project its up to You wich language to use.
In delphi you can't have object created on the stack - they all come from the heap.

In C++ you can do things like

class tSomeClass
  ... stuff in here

void TestFunction()
  tSomeClass X;    // on the stack
  tSomeClass *Y;   // on the heap - need 'new'

  Y = new tSomeClass;

where X gets 'freed' automatically.

In delphi, you can't do the first. Eveything is created on the heap and you need to use 'Create' or some other constructor.

So in Delphi, all your objects are actually pointers to objects, which is a little confusing.... especially if you mix them with records which really _are_ proper records on the stack....
OO is methodology or if You want philosophy and its got nothing to do with stachs, heaps, constructors or destructors, such details are matter of syntax not methodology.
one of the biggest benefits of oo programming is that you do _not_ have to think about memory! (Something C(++) programmers do hard with). In the oo-sense there is no stack existing and also no heap! That means it's not a matter of oo or not! To be precise the possibility of choosing a memory segment in C++ breaks an oo-paradiga. Not the opposite!

btw just to add some polemic: It's a matter of C++'s history, that the most C++ programs are not ++ but C+ programs. The fact, that you still have to care for the memory for native types semms to make it very hard to lot's of C(++) programmers to begin to think in an oo way they do still see just bytes everywhere they have to keep track for ;-)

oo is not a methodology (while OOM,OOD,OOP, OOSWE or Booch are) but it's a theory. But in the sense i guess you meant it you are totally right: There is no "oo-program" whithout an oo-method and all these stuff has nothing to do with binary memory allocation and such stuff!!!
sfock maybe methodology is wrong word, thats due to my poor english :-), but I'm glad You understood what I meant.
qasAuthor Commented:
Thanks alot!

As promised, 50pts will be posted for sfock' answer too.

Thanks again!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.