Re: VB6, VB2005, or Something Else?

Dan Barclay wrote:
Andre,

Do not confuse language issues with implementation issues. When using a string within MS Basic for example you do not know how it is maintained nor should you. It *only* matters to the outside world. When you call C++ from VB you are no longer using VB and your C++ code must deal with the implementation.

Sure. I more referred to the variables which don't have a specified type, which automatically convert to any native data type. Or the automatic conversion if you pass an integer to a function needing a string. I don't know VB that well and only have coded some samples for our libraries. That is perhaps a language issue, rather a COM issue, but let's say - this data types are behaving like a COM variant in C++.


Had you called your C++ code from the DOS Basics you'd find that the VB code worked the same even though the string handling and memory management were completely different. The same is true for VB1 through VB3. Using VB itself (and only VB) you would not need to know the implementation.


Even the "variant" like data type could have been supported in VB6.NET. (By the way don't know if they are >not< supported in VB.NET - I only assume it).
But I think it would have been hard to do that in a way, that other .NET languages could also use this data type. Perhaps even native code must have been used for such a data type.

I only stated that it wouldn't have been so simple like in Delphi. Delphi and C# and .NET have been designed by the same developer, so they have more in common than VB and .NET.

Right. One of the most important things I get from Delphi is that I can create code that works in both. Even though I have to rewrite my VB code, when I get finished I can have the same code workable in native and .Net if I want.

It's a very nice feature. But it's not every time a good thing to do so. I read many posts that Delphi.NET programs are really slow, compared to their native compiled versions. And commonly .NET is complained to be the reason for this. But the main reason is that the platforms are very different and need different coding to get the most out of them.
E.g. strings behave very differently in both platforms. Concatenating them in the same way you have done with the reference counted versions in Delphi, you will probably get speed differences in minutes, not seconds, if you compile them for the .NET platform.
This is the main reason why e.g. Chrome is more restrictive in some points than Delphi.

The same would be true for those who heavily used pointers in Delphi. Obviously pointers aren't supported in .Net for any language so that code has to be rewritten. However, you can rewrite it in a way that it will work in both environments and you can do it on an "opportunistic" basis a segment at a time.

Pointers can be used, but for that the objects / data must be pinned and later on released. Delphi can't do that automatically and pinning is not a good thing to do in .NET either, if it can be prevented.

I simply doubt that even in Delphi there is much code that can be used for both platforms, Win32 and .NET. Because of a simple reason. You are too heavily restricted on the Win32 platform. Sure the VCL compensates that somewhat, but if you want to use any sorted list or other .NET components / code you will be incompatible to Win32.
And if you cannot use the .NET platform, there is no reason to compile for it at all ;-).

For business code / formula it makes sense, to have a common code basis but for general coding IMHO it does not make too much sense, performance and restriction wise.

Man, where would we be now if we could have done that with VB. <sigh>

That's another story. For let's say business code / formula it would have been very good. For general coding I doubt it.

Dan

Andre
.

Relevant Pages

  • Re: VB6, VB2005, or Something Else?
    ... Do not confuse language issues with implementation issues. ... which automatically convert to any native data type. ... conversion if you pass an integer to a function needing a string. ... always be platform sensitive to some degree. ...
    (microsoft.public.vb.general.discussion)
  • Re: Why is java considered a language for "web" or "internet" programming?
    ... you would be right in that writing a number cruncher in a dynamically typed language is not very smart or efficient (I would use C. ... I assume what you think is happening is that whenever a variable is used the interpreter has to run through a large if-then-else statement to decide the data type and that that is what will take time. ... A small perl internals tip, when a numerical variable is used in a string context and the value is converted to string, the converted string is cached in the variable object so as to not have to perform the conversion again later on. ...
    (comp.lang.java.help)
  • Re: object and Object
    ... There is no "primitive" types in C#, all the type keywords in the language is mapped to a System.XXXX type, for some it's valuetypes like int, datetime etc, and for others like string it's a reference type, what most people call an object. ... Somehow I got an impression from somewhere before(Maybe another programming language?) that String represent an object data type and string just represent basic data type. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Is there a integer data type of one byte in gcc?
    ... on platforms that support it in the first place. ... writing C code to depend upon the size of a given data type is ... if you want a language that can ...
    (comp.lang.c)
  • Re: object and Object
    ... that String represent an object data type and string just ... the language alias for that type. ...
    (microsoft.public.dotnet.languages.csharp)
Quantcast