Re: VB6, VB2005, or Something Else?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



ralph wrote:

"Andre Kaufmann" wrote:

I will however, mention the following...
COM: You are thinking in terms of implementation. I was thinking in terms of specification and using that specification as a foundation for migration.

..NET is fine with using COM. .NET objects can use COM objects and can be exposed as COM objects, so that VB6 can use them.
It wouldn't just have been a good idea using COM as general basis.

(Oh well, one example, just take a look at "Long").

It wasn't necessary. But doesn't have that impact as it's meant to be.

And no, I would not expect all C++ programmers to treat "VB6->VB.Fred" the same way, but I did expect that "VBness->VBness" would have been preserved or attempted.

Agreed.

As for Variants - again you are thinking in terms of implemenation and not simple conversion - "A variant can be an integer, a string. To which object you would map it to?" - Oh, I don't know, probably to the type it says it is. As for ETC - VBers have been warned about it since VB started. Type differences can always be managed.
And you are correct a Variant Object type would have helped. But they didn't even bother.

Yes, but you compared variants with .NET objects. Objects cannot easily change their type and don't have a fixed size.

IMHO, I believe you are just dedicated to somehow demostrate a superiority of Delphi over VB.

???? Not quite - why should I. I'm using many languages, none of them is current my "real" favorite. Regarding porting code IMHO the MS C++ compiler VC2005 is much superior than Delphi. Since this compiler can generate mixed assemblies, holding native and managed code. Which Delphi can't.

That somehow Delphi is portable and VB was not. Making VB .net aware and even using VB as a .net language was certainly possible, but such a conversion is now difficult either through ignorance, carelessness or evil intent.

Why the missing keywords could be added ? The changes e.g. "long" can surely not be changed.

But it doesn't matter.

May be. The user base of VB.NET is quite large. Larger than the C# one.

-ralph

Andre
.



Relevant Pages

  • Alternative Future of Delphi?
    ... relevant compiler or interpreter... ... No more intricate code generation required for a particular platform ... on the Delphi compiler side. ...
    (borland.public.delphi.non-technical)
  • Re: Which Delphi Version To Buy
    ... Given the fact that Delphi compiler is quick and small, do you see feasible having a runtime compiler/parser enabling what you describe above? ... For example the basic data types processing in Delphi is sensibly superior to .NET's one exactly because is closer to the iron. ... Well, for parallel programming I, for one, certainly feel the need of a VM simply because the actual CPU architecture is far from the way in which humans deal with the reality which is parallel. ... The vast majority of the games you have to deal with /different/ characters doing /different/ actions in parallel, responding each one to the stimuli which comes from the environment. ...
    (borland.public.delphi.non-technical)
  • Re: Version after Version
    ... merely because Delphi has no 64-bit compiler? ... >> targeted instructions and increasing the size of the cache to 32,000 ... >> That has nothing to do with the number of address lines on the CPU ...
    (alt.comp.lang.borland-delphi)
  • D7 revival? stirring the old pot + Delphi 64 suggestion
    ... The new compiler, but with the old IDE, the old help. ... You can check other areas of the site and poster stats, it's not that Delphi posters don't use .Net, it's just that they don't use Delphi for .Net work. ... As for the 64bit debugging, a CPU view debugger would be all that is really needed to get things started (this is for fastcode after all), no need for rich source-level debugging, inspectors, etc. early on. ... Validation could be two-ways: one in the fastcode challenge, another made via CodeGear private unit tests. ...
    (borland.public.delphi.non-technical)
  • Re: Compiler optimisation
    ... > Keep in mind that Delphi is one-pass compiler. ... > limits number of possible optimizations to ones that do not operate ...
    (borland.public.delphi.non-technical)