Re: VB6, VB2005, or Something Else?


"Andre Kaufmann" <andre.kaufmann.bei@xxxxxxxxxxx> wrote in message
news:eDMFUUMQGHA.3192@xxxxxxxxxxxxxxxxxxxxxxx
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.

That's known as ETC (Evil Type Coercion). Don't get me started... it's one
of the changes made at VB4. MSBasic has always allowed coercion of numeric
types, but adding strings to the coercion mix caused more problems than I
care to think about.

Even having said that, ETC didn't break existing code. It was only stupid,
maybe even evil, but not criminal. I don't know anyone writing serious apps
that don't use explicit conversions but I supposed it helped someone
somewhere.

However, at the same time they did break $trings. Prior to VB4 there was no
byte data type so the *only* documented way to handle binary data was with
the $tring. That has been the case since CP/M versions of MSBasic. At VB4
MS *redefined* this fundamental data type to use UNICODE under the hood
along with zillions of calls to WideToNarrow...() and friends at the
boundaries. They documented that this could corrupt binary data. So, along
with ETC we get UNIMESS. You can google on those if you wish.

http://www.google.com/search?hl=en&q=etc+unimess

The first hit reminds me of one of the threads in which I participated.
I'll leave you to figure out which part <vbg>.

http://www.avdf.com/vb4/hum_unimess.html

oh, and my realization that strings were broken shows up in the google as
well...

http://vb.mvps.org/vfred/unimess.asp

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++.

Not even like a COM variant. The language guys actually redefined behavior
of the data types. Nothing to do with COM, everything to do with folks
being in charge who don't understand the language. BTW, they also added
the "&" operator during the same time frame. Proir to ETC the original "+"
for concantenation was fine. ETC added so much confusion that they had to
invent a de-confuser. Personally I still use "+" and avoid mixing data
types.... as it should be.

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.

There are other more fundamental language issues. So much so that a
successful migration convertor has yet to emerge.

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.

RIGHT! Not *every* time, but you can when *you* decide to. With VB you
simply can't do that.

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.

That is important for performance code... probably 10% of most apps at the
most. But, I agree. So, you can use conditional compiles if necessary but
you can use the same source.

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.

I haven't seen that yet, but in some cases it could be an issue. Likewise
you could see differences the other way. When that occurs I suspect you'll
see components built to handle the differences. For example there are VB5
components built to emulate some .net string classes. The .Net classes were
built to overcome some of the grinding there. Tools and techniques will
always be platform sensitive to some degree. However, language *behavior*
should not be. It's one thing to recode for performance. It's quite
another to recode because code is simply broken.

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.

Delphi *doesn't* do that and I hope it never does. To say it can't do that
is incorrect as I'm sure you know. Pointers don't belong in the .Net world
IMHO.

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.

That depends on your code. Many apps contain a lot of business logic code
in pure code. I've got a heck of a lot of MSBasic code that simply doesn't
care if it's executing in Windows or CP/M. That's not by accident. I've
parsed the platform dependent code into its own wrappers as much as I can
get away with.

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 ;-).

I have nothing deployed on .Net but I might want to some day. I want my
library to at least have that ability. I've got a few app ideas that would
depend on my libs<g>.

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.

Yup, thats why it's always a good idea to separate those types of code. To
borrow a term that's got some ugly connotations among some folks here...
some code is code, some code is glue to hold real code together.

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.

The valuable and difficult to reproduce code is business code. That's the
code for which the subject matter expert has disappeared and even the guy
that wrote it doesn't remember all the tweaks done to make it "right".

UI code is easy to reproduce for the most part.

Dan


.

Relevant Pages

  • Re: VB6, VB2005, or Something Else?
    ... When using a string within MS Basic for example you do not know how it is maintained nor should you. ... I more referred to the variables which don't have a specified type, which automatically convert to any native data type. ... 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++. ... But the main reason is that the platforms are very different and need different coding to get the most out of them. ...
    (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: which to learn? C, C#, VB6, VB.Net?
    ... >level language, and you'd find different reditions of it from different vendors ... It is no surprise that a platform change would ... to make changes to a BASIC dialect, they have no understanding of what ... were actually the change of the String data type to mean Unicode ...
    (microsoft.public.vb.general.discussion)
  • 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: Getting font version from TT font
    ... Check TTF spec for language ID, platform ID, and ID for version string. ... table in a truetype font so as to retrieve the version from the font? ...
    (microsoft.public.win32.programmer.gdi)