Re: 64-bit Windows for AMD 64 is here...
From: Rudy Velthuis (TeamB) (rvelthuis_at_gmx.de)
Date: 03/13/04
- Next message: Rudy Velthuis (TeamB): "Re: Delphi Win32 alongside Delphi for .Net."
- Previous message: Dennis Landi: "Re: 64-bit Windows for AMD 64 is here..."
- In reply to: Eric Grange: "Re: 64-bit Windows for AMD 64 is here..."
- Next in thread: Lord Crc: "Re: 64-bit Windows for AMD 64 is here..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 13 Mar 2004 13:41:00 +0100
At 12:37:50, 13.03.2004, Eric Grange wrote:
> > You are thinking about speed. It may come as a suprise to you, but
> > usually people don't fill listviews with thousands of entries, etc.
>
> You don't need that, adding a listbox with one item that resizes with
> its container form is enough to see a difference.
I don't see any. I just tried. I ported some of my apps to D8 (without
any mods, except replacing ActionManager). I have both versions of one of
them open, and resizing the form does not show any difference. The main
form has three comboboxes and one TreeView with anchors set to resize
(the combo boxes left,top,right, the treeview, left,top,right,bottom). I
don't see any difference, right now.
Can you post an app in D7 and D8 that shows differences?
> > With powerful I mean the features. Of course the VCL for NET is
> > partly slower than its Win32 equivalent.
>
> Okay, features. Shoot.
Do you want me to mention them all?
> You're still being vague. Precise points please, no need for a catalog,
> just a few one that demonstrate obvious and unmatched superiority,
> things one can do and the other cannot.
Apart from the many more components and properties, and the ease of use
(no need to instantiate an object to pass a few parameters, etc.), one
example:
All VCL components that have strings have the consistent interface of
TStrings. Try to find that in WinForms, where each exposes its own list
of items. These don't even have a LoadFromStream/File. Oh, you could
write a function that tries this with IList, but for instance WinForms
text boxes expose an array (an IList), but you can't add to these.
> This is besides the point, are the same things possible or not?
No, it is not beside the point. I was also addressing ease of use. Oh,
BTW, try to do custom drawing in any of the WinForms components.
> Also, note since you don't have to free anything, the code overhead
> when creating a structure isn't very significant, it's just a matter
> of implementing/using the proper constructor.
The code overhead is there, but the time overhead is there as well. To
pass EventArgs, I must first create an instance, passing it all the
parameters it needs. Now this can be passed, and then read via getters.
In the VCL, you simply pass the parameters to delegates directly.
I noticed many similar problems when using or writing components. To pass
parameters, like in the Windows API, .NET is always passing filled
classes (or structs in Win32) around.
The fact that you don't have to do this is exactly why using the VCL is a
lot simpler than using the Win32 API. But the .NET API still requires
this, although not as extreme as the Win32 API.
> All these points are debatable, and have no clear winner anymore.
They are debatable, but there is a clear winner: the VCL.
> There are inconsistencies in the VCL too (f.i. TCollection).
What is inconsistent in the exposure of different items via the same
mechanism and base classes? If anything, it is consistent.
> That Borland doesn't feel compelled to wrap it up anymore in nice
> documented classes, so you have to deal with these directly more often.
Borland wraps the same items up in the same classes as they did before.
They have the same classes in the RTL and the VCL (OK, a few, like
ActionManager are still missing, as I said). But it would be nonsense to
wrap the new FCL classes up with yet other classes.
> > And how was that in Win32?
>
> Misses the point. Not improving over D7 = losing, since the competition
> has improved in other areas.
They have improved greatly over D7, and yet retained the advantages in
the VCL and RTL.
> Good, I simply gave it as an example of the features missing. Someone
> > writing an OPF using interfaces will probably miss it dearly.
>
> Decent string and array handling are a bigger miss :)
Yes, but D8 has decent string and array handling. Oh, I agree that some
bad habits might show problems earlier.
> > I mentioned that one of the strong points of Delphi is is
> > compatibility with Delphi/Win32. The MS .NET languages don't offer
> > that.
>
> C++ does.
Managed C++ and C++ differ as much as VB.NET and VB. Ask anyone who uses
C++ and has tried Managed C++.
> > I never ever promised that. I never said that D8fN is more efficient
> > than Win32. I have no idea how you could read that into everything I
> > said.
>
> Ah, I recognize you here, asserting things but almost never backing
> them with even a glint of a shred of real world bitsies ;)
No, you said I said that D8 was faster than D7. I never said that.
> Here is the flaw in your reasonning: in Delphi, we have this separation,
> but in VS.net, you can cater to both sides. MS is still strong on native
> compilation.
In Managed C++? Yeah. Ask the C++ people what they think of it. BTW,
Delphi is also very strong on native compilation. And, as I said,
compared to Managed C++ vs C++ the differences between Delphi/.NET and
Delphi/Win32 are minor.
AFAIK, not even Managed C++ allows you to expose functions in assemblies
thus that they can be used *directly* from Win32. Delphi 8 does.
> > But compared to other .NET languages, Delphi is more powerful (and I
> > don't mean speed), and so is the VCL.
>
> That's an impression, an opinion. Still waiting for facts.
I gave a lot. But I guess you'd have to use both for a while to see it.
> You don't seem to understand that what it's all about is very simple,
> it's a question of tool choice. The majority wants VS.net, customers,
> management, etc. have nothing against VS.net, that's what they're using.
Same situation as on Win32.
> But with D8FDN, I have no objective argument that can get through
> anymore
You don't? I do. I think that I really need to compile a list, or find
one made by someone else.
> I need ammunition, not vague impressions, unbacked opinions or weak
> "strong points". I don't think I'm the only one in that situation.
Ah, that's it. You need ammunition. I don't. I can see the difference,
and I don't have to convince anyone but me.
> > Your main concern seems to be speed. Sorry, but if you need raw speed,
> > you need contact with the bare metal, and that is currently not what
> > .NET provides.
>
> But VS.Net still does.
Only in Managed C++.
> In case you didn't noticed, in .Net you don't have access to all
> the Win32 APIs via the Framework libraries, far from it.
Yes, I know. For those cases you need to do the same as in Delphi for
Win32 (heck, even the people using C# or VB must do that). But in many
other cases you don't have to do that anymore.
Delphi comes with at least translations of parts of the original SDK.
VS.NET doesn't even do that.
And to access the bare bones, you need C++, evne if you do your normal
programming in C#. In Delphi, you could use D8fN and D7, no need to
switch languages.
> > The hoops being us having to translate all Win32 APIs to Delphi,
> > instead of simply using them as they are, as we can do in .NET.
>
> Except they aren't all there in .Net, and of those that are, many are
> incomplete.
Sure, but that was the same in Win32. And they are incomplete for the C#
and VB people too, now. In Win32, everyone using C++ could access all
these APIs directly, so Delphi was in the disavantage. Now, Delphi
already has standalone functions and existing header conversions,
something the C# people dearly miss. That is why you'll see a lot of
P/Invoke encapsulating classes in C# source that tries anything out of
the blue.
> Finally, I fail to see why generating .Net code would be required to
> interface these automatically, since all the entry points and formats
> are documented, nothing would prevent a native compiler from
> using/importing the .Net entry points directly.
Huh?
> Being able to access .Net APIs/Controls is orthogonal to being forced
> to compile to .Net in your application.
I don't understand. If you must program for .NET, there is no choice. If
you don't need .NET, don't use it.
-- Rudy Velthuis (TeamB) "This book fills a much-needed gap." -- Moses Hadas (1900-1966) in a review
- Next message: Rudy Velthuis (TeamB): "Re: Delphi Win32 alongside Delphi for .Net."
- Previous message: Dennis Landi: "Re: 64-bit Windows for AMD 64 is here..."
- In reply to: Eric Grange: "Re: 64-bit Windows for AMD 64 is here..."
- Next in thread: Lord Crc: "Re: 64-bit Windows for AMD 64 is here..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
