Board index » delphi » Re: Delphi 8 for .Net versus....

Re: Delphi 8 for .Net versus....


2004-01-10 08:09:30 PM
delphi60
Mark writes:
Quote
the Basic language implemented by VB(Visual Basic) is so obfuscated
and spaghetti like -it also does not bode well to OOP , I personally
think C++ is easier compared to VB.
I'm not sure this is fair. While VB(Visual Basic) certainly makes it easier to write
obfuscated code, it does not require or demand it. I have seen some very
well written VB(Visual Basic) code.
Also, VB.NET is object oriented, whereas VB(Visual Basic) was not. I would say that
you're less likely to see obfuscated code in VB.NET if only because to
use it properly you HAVE to understand OOP.
--
Derek Davidson
www.enterpriseblue.com
 
 

Re: Delphi 8 for .Net versus....

Atmapuri writes:
Quote
Consequence. On the paper is C# almost as fast as native code. In
reality. Imagine creating an TObject derived class for every integer
that you declare and let me know where does that bring you.
C# doesn't do that, and neither does Delphi. They use native integers.
Boxing is only done where it is required, i.e. where objects are expected.
--
Rudy Velthuis (TeamB)
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers,
and nobody thinks of complaining." -- Jeff Raskin
 

Re: Delphi 8 for .Net versus....

Dustin Campbell writes:
Quote
Also, generics in C# will help remove many unwanted boxing/unboxing
operations giving even more performance. Using a previous example, the
System.Collections.Stack class has methods that expect System.Object
parameters. Passing integers to these methods of course require boxing
because of the implicit typecast. However, the upcoming generic Stack
class removes the boxing/unboxing operations because the Stack can be
created to only accept integers.
Exactly.
--
Rudy Velthuis (TeamB)
"The backbone of surprise is fusing speed with secrecy."
-- Von Clausewitz (1780-1831)
 

Re: Delphi 8 for .Net versus....

It seems that you missed my point which was that managed C++ will be the
"{*word*155}" language -- not C#. Oh well -- a discussion on boxing it is...
Quote
Yes. And guess what happens if you hide boxing/unboxing away from the
developer? It happens on the fly and very often, especially because
even the basic types can be boxed.

Consequence. On the paper is C# almost as fast as native code. In reality.
Imagine creating an TObject derived class for every integer that you
declare
and let me know where does that bring you.
That isn't quite correct. In C#, you don't create a System.Object for every
integer. It is created on the stack just like in Delphi. Boxing only occurs
when you try to use the integer like an object. For example, if you call a
method on the integer (e.g., System.Int32.ToString) boxing will occur. Or,
if you pass it to a method that requires a typecast to an object (e.g.,
System.Collections.Stack.Push) the integer will be boxed. If you don't do
anything with the integer that requires boxing then it won't happen. It will
remain just four bytes on the stack.
Quote
The problem with C# is that you I have to ilasm to see if what you are
using
is boxed, unboxed, are there any method calls etc... Because its
"hidden"... Same goes for Delphi.NET. On the paper as fast as C#,
but tender as a rose when it comes to performance. You can loose
it in a snap.
I'm assuming that you meant "ildasm" (not "ilasm).
I don't think you really need to disassemble the code to tell whether boxing
operations are taking place or not. it is pretty obvious in your own code
that things are going to be boxed or unboxed. As I mentioned before, calling
methods on the value type will box it. Typecasting to a reference type will
box it. Typecasting from a reference type to a value type will unbox it. You
just have to look out for implicit type casts (like when using
System.Collections classes).
Also, generics in C# will help remove many unwanted boxing/unboxing
operations giving even more performance. Using a previous example, the
System.Collections.Stack class has methods that expect System.Object
parameters. Passing integers to these methods of course require boxing
because of the implicit typecast. However, the upcoming generic Stack class
removes the boxing/unboxing operations because the Stack can be created to
only accept integers.
--
Best Regards,
Dustin Campbell
Developer Express, Inc.
 

Re: Delphi 8 for .Net versus....

Quote
The language barried, top 1. No matter if a monkey is dress with gold,
is still a monkey. C# had stupid things like Case-sensitive, the current
Yep. You're right on this.
Quote
editor in VS.NEt is worse than VB.NET, and the focus of the language
I have never tried VB.NET. I don't find the C# editor to be a bad editor,
but it may be because I haven't tried VB.NET.
Quote
is not he way of Delphi, VB(Visual Basic) is not the way of Delphi, but is more close.
C'mon :) Do you mean, with that forced and weird exception handling?
Quote
The whole logic, the kind of community, the way in that the components
and aplications are developed, the paradigm, all is influenced by
language. Chose a language is more important than normaly is accepted.
That's true...
Quote
>What's non-RAD about C#?
Anything. All rad in c# than is equal in VB.NET is because the plataform
(like, for example, ASP.NET) but code in C# still take more time. The
language itself is not RAD by self, simply inherit the .NET.
I don't share this point of view. When you mention this, I can only think on
event autowiring (mainly, from previous VB(Visual Basic) editions).. that is not a very
good idea (it required tricks like control arrays). And even, event
autowiring is available for C# in ASP.NET (though not recommended for any
language, btw). Except for this, I can not remember any important difference
between C# and VB.NET. Of course, I may be wrong.
Quote
>If Delphi 8 wizards as as "terse" as C#Builder's, I am afraid I disent.
I know your work. I recommend "La Cara Oculta" to everybody and not
Well, thanks <g>
Quote
understand why you worry about wizards. By the way, ECO is the "go" and
the best thing by now in the hands of Borland, plus ALM, if you want to
consider a kind of "wizard"
I chosed the wrong word. I am talking about this:
- Take a C#Builder personal edition. Mine is a brand new install, on a
{*word*269} machine, with the Borland's published Update Pack.
- Create a new Windows Forms project. You won't have those BDP components,
but we'll use SqlClient.
- Drop a SqlConnection, and try to configure its ConnectionString property.
There's no component or property editor for this. you will have to type the
whole connection string, for instance:
database=northwind;trusted_connection=yes (a local MSDE engine)
- Drop a SqlDataAdapter. Of course, we don't have a Database Explorer, but
we can assume this, because this is a free version. Anyway, the $100 Visual
C# Standard does provides a Server Explorer, though limited.
- Now, try to connect sqlDataAdapter1.SelectCommand.Connection to
sqlConnection1. There's no dropdown list! Type 'sqlConnection1', sigh, and
continue.
- Generate a typed dataset. Call it any way you like, and please check that
"Add instance to designer" checkbox. Accept.
- Boom. C#Builder refuses to compile the new class (though it has generated
the corresponding XSD), and it reports it cannot add the instance.
This is functionality already available in VS.NET that crash inside
C#Builder. Let's assume you switch to BDP (paying for a whole priced
version), and you configure succesfully the corresponding components. Now
what? I did expected more from Borland: I thought Borland would allow me to
create data binding controls as in Delphi 7, using drag&drop. Negative. I
thought Borland would allow me to create event handlers for individual
collection items (how do you create at design time an event handler for a
DataTable?). Yes, it is true that VS.NET doesn't support this right now, but
that's the kind of things I was expecting from the VS.NET competition.
Quote
than can be build in .NET. Winforms is very limited and requiere more,
That's true, again. I can only but think they were thinking on Avalon, and
didn't put their bests in GUI programming. Anyway, Whidbey will be more
comprehensive in this sense.
Quote
SO MUCH code than a "normal" people can learn fast. Databinding is hard,
But more powerful!!! You can bind a control to a custom data structure.
Quote
still the same DataSet-DataControl of Delphi 1 work best than any
ofering of MS, .NET included.
Data binding, per se, is uglier, OK. But I do prefer, after playing with it,
the DataSet model from .NET. It separates the "row" concept from the "row
collection" concept. As a matter of fact, Delphi's TDataSet was an ultimate
hack from Anders Heljsberg, and it is not a good programming example. There's
no direct access to a row w/o selecting it first (and firing in consequence
a lot of events in background). I have tried to develop some grid
components, just for fun, for Delphi Win32 and for C#, and believe me,
despite some minor details (the {*word*193} DataSource/DataMember trick, and the
lack of predefined property editors for these), .NET version was a pleasure
to write.
Quote
second place, Visual FoxPro. For my, the life is so short for code in C.
:) Well, I assume you will never buy my new book on C#. So, if you send me a
delivery address to my personal email account, I will send you, as a present,
a copy of the new book, when ready (a week more, or so). If you don't
finally like it, you could always give it to a friend (that's marketing!).
Ian
 

Re: Delphi 8 for .Net versus....

On Fri, 09 Jan 2004 14:27:28 -0500, mamcx <XXXX@XXXXX.COM>writes:
Quote
>>Delphi programmers, myself included, C# isn't really the main
>Why?

The language barried, top 1.
Uhm, I did a flawless port of several apps to c# without any language
issues (only some minor framework issues). One of these consists of a
mere 50 lines of UI code, and closer to 10k of c# code to do the dirty
work (it's a raytracer). Again, the primary issues was framework and
not language (fast bitmap access etc). The longest i spent was to
figure out how to implement the initalization section like feature of
delphi. Took me a day before i learned how to use attributes and
reflection to enable the same functionality. I dont consider myself a
"top coder" by any means, so i find it hard that language would be the
top 1 item why c# isn't the main choice. I would say it is, i feel it's
very close to delphi in how it works.
Oh, and i find VS very productive. I started out with a fresh vs
install, and a blank c# solution on the 1st day of xmas. Having spent
what would be a typical working week with c#, i feel im pretty much up
to speed. Not 100% yet, but close enough to do real work.
Note: I have never coded in c or c++ before, only read c/c++ code.
- Asbjørn
 

Re: Delphi 8 for .Net versus....

A few years ago when I decided to write my application generator, I
tried out all the languages I could get my hands on. These included
C++, Java, VB, FoxPro, Delphi 3 and T-SQL
By far, I found that Delphi was the easiest and most productive for
creating user interfaces and T-SQL was the best for creating the
business logic.
All the Delphi and T-SQL code I have written then still compiles under
the latest versions of the languages today. To me this says that the
languages are very mature.
I will admit that I have never tried any of the dot net stuff because
I could never find a practical reason to do so. Delphi and T-SQL have
never disappointed me and I have never found anything that I couldn't
do with these two.
The only difficulty that I have is marketing my DotNetless technology
because so many developers are afraid to stray to far from Microsoft.
But to tell you the truth, I consider DotNet, nothing more than
marketing. And I for one will never choose marketing over
functionality
Best, John
 

Re: Delphi 8 for .Net versus....

Hi!
Quote
That isn't quite correct. In C#, you don't create a System.Object for
every
integer.
True. But you said that boxing is implicit. You dont get to see which
operations
will uncluding automatic boxing or unboxing.
Quote
You
just have to look out for implicit type casts (like when using
System.Collections classes).
Exactly. For example:
IntegerInt := IntPtrInt; //?
Boxed or unboxed? Implicit conversions between
types hide away not only the code complexity but also the "time"
complexity. If the code complexity is well hidden, people tend
to forget all about the time required to execute that.
Quote
Also, generics in C# will help remove many unwanted boxing/unboxing
operations giving even more performance.
True. But not yet available. Even with generics, its not a walk in the park.
In Delphi W32, you can debug your code down to the asm function. With
Delphi.NET you dont see even with the CPU view, if the there are
any "hidden" conversions taking place.
The first few programs I wrote with .NET, I was fishing out implicit
code, because there were performance drains somewhere..
If you dont keep the .NET source under strict benchmarks, you
can get in to performance issues much quicker than with Delphi W32.
Regards!
Atmapuri
 

Re: Delphi 8 for .Net versus....

Atmapuri writes:
Quote
Hi!

>That isn't quite correct. In C#, you don't create a System.Object for
every
>integer.

True. But you said that boxing is implicit. You dont get to see which
operations will uncluding automatic boxing or unboxing.
You do. Every operation which expects a System.Object and gets an integer
will box that integer. It is plain to see where that could be.
Quote
IntegerInt := IntPtrInt; //?
What is that? It is not an integer.
Quote
True. But not yet available. Even with generics, its not a walk in the
park. In Delphi W32, you can debug your code down to the asm function.
With Delphi.NET you dont see even with the CPU view, if the there are
any "hidden" conversions taking place.
But you can see what happens in ILDAsm and in Roeder's Reflector.
Quote
If you dont keep the .NET source under strict benchmarks, you
can get in to performance issues much quicker than with Delphi W32.
It is a different platform, and there are different issues with it. A
little experience and common sense will tell you what to look for, and
what to avoid.
--
Rudy Velthuis (TeamB)
"One of the symptoms of an approaching nervous breakdown is the belief
that one's work is terribly important."
- Bertrand Russell (1872-1970)
 

Re: Delphi 8 for .Net versus....

On Sat, 10 Jan 2004 11:58:27 +0100, "Atmapuri"
<XXXX@XXXXX.COM>writes:
Quote
On the paper is C# almost as fast as native code
I just made some tests porting my vector class to c# from delphi, and
if i adjusted the syntax to allow for a more precise "low level"
translation (ie, function foo: TRec; in delphi is translated to "void
foo(ref Rec result); in c#, as that is what delphi basically does), it
performed within a few % of the delphi code.
- Asbjørn
 

Re: Delphi 8 for .Net versus....

Captain Jake writes:
Quote
But if you had been using C++ for years ..<snip>
And if I had wheels, I would be a wagon.
--
"The system is less energetic when domains of opposite direction
alternate." - Dr. Memory
 

Re: Delphi 8 for .Net versus....

Brion L. Webster writes:
Quote
Richard Grossman writes:


>But VB.Net 1 is a step up from VB(Visual Basic) 6. Except they took the best
>thing about VB(Visual Basic) out: debug and continue.


I can not find a good way to open this - something like I respect
what you've posted elsewhere, but...

Debug & continue was the second largest source of squirrly bugs I
have ever seen with VB. The first being that the compiler doesn't
catch a darned thing when you run your VB(Visual Basic) code in the first place.
Debug & continue does not force all of your data structures to be
what they would have been. It is all too easy to set yourself in
an intermediate state that could never have been achieved starting
the program with the modified code from the beginning. Meanwhile,
Joe Average Programmer happily goes along thinking he's fixed
something, while in reality he's broken something completely
different, and releases it to the user.
I guess I am not "Joe Average Programmer" <sniff>.
<g>
Seriously, I concede your point that it may be a "bad thing" as a
general practice, but personally I always know when it is a little goof I
can fix with debug and continue versus when to abort and start over.
--
"The system is less energetic when domains of opposite direction
alternate." - Dr. Memory
 

Re: Delphi 8 for .Net versus....

Dustin Campbell writes:
Quote
>But VB.Net 1 is a step up from VB(Visual Basic) 6. Except they took the best thing
>about VB(Visual Basic) out: debug and continue.


Edit and continue is back in Whidbey.
Yeah, I read that in VS mag.
--
"The system is less energetic when domains of opposite direction
alternate." - Dr. Memory
 

Re: Delphi 8 for .Net versus....

Brion L. Webster writes:
Quote
Debug & continue was the second largest source of squirrly bugs I
have ever seen with VB. The first being that the compiler doesn't
catch a darned thing when you run your VB(Visual Basic) code in the first place.
Tangential point:
IMHO, when you program in VB, it is very important to just write simple
programs, even if there is a lot of cut&paste versus object usage. If
you write down to the language, and don't try to make it do the things
it was not originally designed to do, nor use the things that were
tacked on, you have fewer problems.
It's like knowing not order the steak au poivre in a roadside diner (in
the US that is) - stick with the pancakes, and you will be fine.
--
"The system is less energetic when domains of opposite direction
alternate." - Dr. Memory
 

Re: Delphi 8 for .Net versus....

Richard Grossman writes:
Quote
I guess I am not "Joe Average Programmer" <sniff>.

<g>

Seriously, I concede your point that it may be a "bad thing" as a
general practice, but personally I always know when it is a little
goof I can fix with debug and continue versus when to abort and
start over.
Thank you. My experience has been most VB(Visual Basic) programmers do not know
the difference. Granted, I have tried to minimize that experience,
after being burned both by in-house developers and commercial
vendors for our Police Department, of all places :( . But I'll
concede that edit & continue could be a useful thing in some cases.
-Brion