Delphi vs C#

[Guest]

Hi All,

I'm not so good in Delphi...
Some time ago i want to add an event to my form class
(in Builder C++) and i failed.

Could somebody that knows Delphi/BulderC++ give me an example
, how to add new event?

Thanks!

Marcin

 

[Jochen Kalmbach]

you don't have to == you are not required to

I think it is NOT equal...

you don´t have to == you have not to


you have not to == du darfst nicht
you have to == du musst


Summary:
In english:
Opposit from "must" is "must not"

In german:
Opposit from "muss" is "darf nicht"!!! and not "muss nicht" !!!



--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp


Do you need daily reports from your server ?
http://sourceforge.net/projects/srvreport/

 

[Kiran]

One thing that I really miss so far is the Interface delegation, which makes
your code so simple & easy to maintain in Delphi.

if I have a interface "IMyInterface1= IInterface" and a Class TMyClass1
which realizes that interface I could have a code like This


TMyClass2 = class(TABC,IMyInterface1,IMyInterface2 )
:
FmyClass1 : TMyClass1 ;
:
property MyClass1 : IMyInterface1 read FmyClass1 write FmyClass1
implements IMyInterface1;
:
:
end;
This makes u r code & design so elegant. If you ever had to code & maintain
this you will see how simple this is... I wonder how this feature could be
missing in C# so far.

Only thing that I really liked in c# so far is that I don't have to care too
much about memory and memory leaks apart from the reason as u r preference
.

regards
Kiran

 

[Michael Moreno]

I miss the array property a lot more myself like :

property MyArray[i,k : integer] : double read GetArray write SetArray;

instead os having to create an entire class in C# :-(

Same with property with get public and set protected or private... There are
so many things that the list is too long to be worth writing it!

 

[Morten Wennevik]

I think it is NOT equal...

you don´t have to == you have not to

No, in English the opposite of "you don't have do" ("you do not have to")
is "you have do" = "you are required to"

You can't say you "have not to", but the meaning of something like that
would be "you should not" or "you must not" which would be the same as "du
darfst nicht".

you have not to == du darfst nicht
you have to == du musst


Summary:
In english:
Opposit from "must" is "must not"

Yes, and the opposite of "have" is as you say "have not" or "don't have"
but used in a sentence like
"You don't have to do this" it means "you do not have to perform this
action" == "you are not required to do this"

In german:
Opposit from "muss" is "darf nicht"!!! and not "muss nicht" !!!

Possibly, and "have to" == "must" but "don't have to" != "must not"

 

[Jochen Kalmbach]

Possibly, and "have to" == "must" but "don't have to" != "must not"

man lernt nie aus... danke.



--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp


Do you need daily reports from your server ?
http://sourceforge.net/projects/srvreport/

 

[codymanix]

One thing that I really miss so far is the Interface delegation, which
makes

your code so simple & easy to maintain in Delphi.

if I have a interface "IMyInterface1= IInterface" and a Class TMyClass1
which realizes that interface I could have a code like This


TMyClass2 = class(TABC,IMyInterface1,IMyInterface2 )
:
FmyClass1 : TMyClass1 ;
:
property MyClass1 : IMyInterface1 read FmyClass1 write FmyClass1
implements IMyInterface1;
:
:
end;

Huh? Iam not sure if I understood what you mean. Could you please explain
this feature again?

 

[C# Learner]

OF COURSE IT IS !! In Delphi, you don't HAVE to add the () to an
"empty" method call, but you damn well can, if you insist......

I'll have to give this a try...

 

[Daniel O'Connell [C# MVP]]

Daniel O'Connell [C# MVP] wrote:

[...]

Actually requires it. A method identifier without a () at the end refers
to the method itself, not a call(as used in delegate syntax).

I understand that. The point I was trying to make was that Delphi doesn't
allow calls to use parentheses when no parameters are being passed (unless
the routine returns a value and that value gets assigned to a variable)*,
but C# does.

i.e. the following wouldn't be legal Delphi code:

procedure Foo;
begin
end;

procedure Bar;
begin
Foo();
end;

* Well, I believe this to be the case, but can't test this tonight, due to
a lack of a Delphi compiler here. It's standard in Delphi not to use
parentheses unless the you're passing a value, so I can't say I've ever
tried using them in this scenario

There is a considerable difference in allowing parentheses and requiring
them. I think the distinction is worth mentioning.

Cheers

[...]

 

[C# Learner]

Daniel O'Connell [C# MVP] wrote:

[...]

- the fact that C# method calls allow parentheses even when the
method doesn't have arguments (C3 - D5);

Actually requires it. A method identifier without a () at the end refers
to the method itself, not a call(as used in delegate syntax).

I understand that. The point I was trying to make was that Delphi doesn't
allow calls to use parentheses when no parameters are being passed (unless
the routine returns a value and that value gets assigned to a variable)*,
but C# does.

i.e. the following wouldn't be legal Delphi code:

procedure Foo;
begin
end;

procedure Bar;
begin
Foo();
end;

* Well, I believe this to be the case, but can't test this tonight, due to
a lack of a Delphi compiler here. It's standard in Delphi not to use
parentheses unless the you're passing a value, so I can't say I've ever
tried using them in this scenario

There is a considerable difference in allowing parentheses and requiring
them.

No doubt.

I think the distinction is worth mentioning.

Why? My post was comparing Delphi and C#, and I can't see how it wasn't
obvious that I meant that Delphi doesn't allow the parentheses whereas
this is /not/ the case with C#.

I guess this has something to do with my anti-.NET posts from a while ago

 

[C# Learner]

OF COURSE IT IS !! In Delphi, you don't HAVE to add the () to an
"empty" method call, but you damn well can, if you insist......

Okay, I tried this out, and you're right.

I'm 95% sure that I've read that this is illegal in a book. Hmm...

 

[Daniel O'Connell [C# MVP]]

Daniel O'Connell [C# MVP] wrote:

[...]

- the fact that C# method calls allow parentheses even when the
method doesn't have arguments (C3 - D5);

Actually requires it. A method identifier without a () at the end refers
to the method itself, not a call(as used in delegate syntax).

I understand that. The point I was trying to make was that Delphi
doesn't allow calls to use parentheses when no parameters are being
passed (unless the routine returns a value and that value gets assigned
to a variable)*, but C# does.

i.e. the following wouldn't be legal Delphi code:

procedure Foo;
begin
end;

procedure Bar;
begin
Foo();
end;

* Well, I believe this to be the case, but can't test this tonight, due
to a lack of a Delphi compiler here. It's standard in Delphi not to use
parentheses unless the you're passing a value, so I can't say I've ever
tried using them in this scenario

There is a considerable difference in allowing parentheses and requiring
them.

No doubt.

I think the distinction is worth mentioning.

Why? My post was comparing Delphi and C#, and I can't see how it wasn't
obvious that I meant that Delphi doesn't allow the parentheses whereas
this is /not/ the case with C#.

By my reading, I thought you were implying that C# doesn't require the ()'s.
I merely pointed out that it does.

I guess this has something to do with my anti-.NET posts from a while ago

No, it doesn't. I would have corrected anyone, as I considered it a factual
error. Sorry if I seemed offensivve.

 

[C# Learner]

By my reading, I thought you were implying that C# doesn't require the ()'s.
I merely pointed out that it does.

Okay, fair enough.

No, it doesn't. I would have corrected anyone, as I considered it a factual
error. Sorry if I seemed offensivve.

Maybe I was being a little over-sensitive. Thanks

 

[Tim Jarvis]

I'm outlining a chapter on choosing between Delphi and C# for .NET
programming.

Why ?

To me one of the greatest strengths of the .NET framework is the level
playing field for all the different languages available for the
platform.

Language preference is exactly that, a preference, in the case of .Net
languages, there is IMO not much that is truly compelling to choose one
over the other, apart from personal preference. ok, there are some
minor issues, but by and large it's a subjective thing.

In my case, the first language I learnt was C, my degree was in
Electronic Engineering, In late 1994 I started using the Beta of Delphi
1 and have been a Delphi programmer ever since, however in the last
year or so, I have mostly been using C#, and I must admit personally I
prefer C#, almost certainly because I started my programming life as a
C programmer and didn't do the Pascal thing in Univercity.

I would be willing to bet though that there are a lot of Delphi guys
out there who came from a pascal background, who would much prefer
Delphi, and to be honest for my money, why should anyone care. I can
still use their code in my projects if I like, the same thing goes for
VB.NET.

If it were me writing this chapter, I would not try to make a case for
one language over another, I would try to pick out one or 2 nuggets
that a particular language is good for, and then show how you can
interoperate between them, flex some of the power of the .NET framework.

For example, one cool feature of Delphi that is a Pascal specific thing
is Sets, very powerful and way cool, another is reverse p/invoke
(allowing an assembly to export a function that can be called directly
from win32 code), these things can sit fine right along side my C#
assemblies, why should I constrain myself to one language ?

I don't know VB.NET very well, but I did use something from a VB
namespace recently, can't remember what it was, something financial I
think, and to be honest I don't really care what language the class was
written in.

And lastly, Did you know the the original chief architect of Delphi is
one of the Chief Architects of C#, Anders Hejlsberg. An interesting
fact is this, Delphi programmers coming to C# and .NET find it very
familier, most things are basically the same, or a natural evolution
and improvement (multicast events for example). If you are employing
newbies I can guarantee you, that the Delphi guys will get up to speed
real quick.

Rgds Tim.

 

[Tim Jarvis]

Hi All,

I'm not so good in Delphi...
Some time ago i want to add an event to my form class
(in Builder C++) and i failed.

Could somebody that knows Delphi/BulderC++ give me an example
, how to add new event?

Thanks!

Marcin

This question would be much better in the Borland newsgroups, you would
get a much better response.

Delphi events are quite similar in concept to .net events, except that
they are single cast only. In order to add an event to a class
(including forms) you simply declare it like you would a property,
except in this case the property type is of type procedure or function
of object, in other words a method.

So step one create a method type that has the signature that you need
for your event..(or use one of the pre-existing ones)

Type

TMyCustomEvent = procedure(Sender : TObject; EventParams : TObject);

then in your class create a property of that type

TMyFormClass = class(TForm)
....
....
private
FMyCustomEvent : TMyCustomOvent;
...
...
public
property OnMyCustomEvent : TMyCustomEvent read FMyCustomEvent write
FMyCustomEvent;
...
...
end;

then somewhere in your code call the event, if a procedure that matches
the method signature has been assigned to it.

procedre MyFormClass.FireTheEvent(EventParams ; TObject);
begin
if Assigned(FMyCustomEvent) then
FMyCustomEvent(self,EventParams);
end;

As you can see, this is not 1000 miles from what you do in .net IMO the
eventing pattern in .net is a natural evolution of what was designed in
Delphi, Delegates and multicasting are a very elegant progresion. But
hey for its time, events in Delphi were way ahead of the game, you
gotta remember this was done way back in 1995. (well a little earlier
in the beta's) the coresponding COM eventing (and before that, VBX)
pattern was diabolical.

Rgds Tim.

 

[Jon Shemitz]

One thing that I really miss so far is the Interface delegation, which makes
your code so simple & easy to maintain in Delphi.

Yes, but D8 doesn't support this, either.

 

[Jon Shemitz]

Why ?

Because language choice is important - and expensive. I think I
deliver value to my readers if they can make that choice on the basis
of something more than inertia.

To me one of the greatest strengths of the .NET framework is the level
playing field for all the different languages available for the
platform.

A level playing field means that languages compete on merit. Do you
think that C# and D8 are "equally good"?

And lastly, Did you know the the original chief architect of Delphi is
one of the Chief Architects of C#, Anders Hejlsberg.

Of course. It feels very good to be using an Anders language again. I
think (and I may be indulging in hero worship) that his touch shows
very strongly in the coherence of the language.

 

[Tim Jarvis]

Jon Shemitz wrote:


comments inline

Because language choice is important - and expensive

This is where I guess we disagree, I simply don't think that it is
important and expensive any more, I think that in the Win32 world this
was true, but I don't think it is in the .NET arena, the things that
made language interoperability in win32 are largely dealt with, the big
ticket items IMO were type compatability and calling conventions, this
defintely was expensive to deal with, but no longer an issue.

What is it in the .NET world that you think is expensive when mixing
languages. Are you truly going to advocate that one language is the way
to go when developing for the .NET platform, and is superior to all
others ? Doesn't this fly in the face of what the whole platform is all
about ? In my view this is just asking for a language war.

My view (and apparantly Microsoft's) is that solving these issues has
actually made the use of multiple languages with a common type system
and interoperability a cheaper option in some scenarios, off the top of
my head, code re-use, skills re-use, Morale for your development team
(Delphi and VB die hards will love being allowed to use their preferred
tool).

A level playing field means that languages compete on merit. Do you
think that C# and D8 are "equally good"?

Absolutely, don't you ?

Both have cool features, both are elegant (the Anders factor I guess)
and either is an accepateble choice in my view. I would play to the
strengths of both. ( I would most likely even say the same about VB.NET
if I knew anything about it )

Rgds Tim Jarvis

(By the way, I work for Borland. I don't intend to sound specifically
like a Delphi advocate, I do love Delphi...but I also love C#, both are
in my toolbox)

 

[Jon Shemitz]

This is where I guess we disagree, I simply don't think that it is
important and expensive any more,

I was referring to product price, Tim.

Absolutely, don't you ?

No.

 

[Tim Jarvis]

I was referring to product price, Tim.

What ?

Borland Delphi professional - new user RRP $999.00
Visual Studio professional new user RRP $1049.00

(prices from the Borland and Microsoft website)

Jon I don't mean to sound combative. But honestly if you see a $50
dollar price difference as important, then I guess it pointless me
saying anything more on it.

If I was reading a book that was trying to make a comparison between
languages, then to be honest I would want to see what the total cost of
ownership was, and frankly initial purchase price rarely plays a
significant role in that.

No.

Well, I don't know what to say about that. What is it that makes you
think one of the languages is better than the other ? I still believe
that this is largely a subjective argument. I have given you my
reasons, what are yours ?

I have written commercial applications in both Delphi and C#, the
differences in the languages at no time caused me to feel i could have
done it better in a different language.

There have definately been times that I have done similar tasks
differently, to take advantage of a language feature, a good example is
the initialization and finalization features of Delphi units, lend it
to a neat registration mechanism for factory patterns. In c# doing the
same task the same way is a little more difficult, but the same result
can be achieved by using reflection and have the factory class do the
registering, the same result achieved in a different way, and to be
honest both are elegant and flexable mechanisms, just different.

Rgds Tim.