Re: Error message about my user defined type

From: NickHK (TungCheWah_at_Invalid.com)
Date: 09/17/04 

Date: Fri, 17 Sep 2004 12:47:07 +0800

Ulrich,
You've probably forgotten more on this than I'll ever know..

>From what you're saying though, it would practicable for someone (not me) to
write a compiler that allow a true VB(Classic)7 to run on the .Net platform
?

NickHK

"Ulrich Korndoerfer" <ulrich_wants_nospam@prosource.de> wrote in message
news:4148AA4C.F2F38D@prosource.de...
> Hi Hanna-Barbera,
>
> Hanna-Barbera wrote:
>
> > the name comes from the makers of Scooby Doo actually.
>
> I am afraid I do not understand this. What is Scoopy Doo? A television
> series? I am missing the sharing of your cultural surrounding ;-)
>
> > The thing is, I prefer to design my program by defining things like UDT
and
> > classes each in their own files, and then
> > I would like the ability to declare and use one in the other.
>
> That's ok.
>
> > It's the kind of programming I do in C++ and that involved header files
and
> > implementation files and the #include directive.
> >
> > In VB, it has to make everything available automatically, but if I
> > understand you correctly, VB6 has some issue with COM?
>
> I will try to explain in a nutshell:
>
> COM is a convention, defining how binary (compiled) objects have to
> behave to be able to be accessed (instantiated and used). This
> convention does not say, how to and in which language the object has to
> be implemented. COM objects can be implemented using many languages,
> among them VB and C++.
>
> C++ has its own vision of objects. A plain C++ object is not a COM
> object. But one can add additional C++ code, to turn a C++ object into a
> COM object. So in C++ one has simple plain C++ objects and COM objects.
>
> If a C++ programmer wants to use objects, which he will never share with
> others programs in compiled binary form, he writes common simple C++
> objects. If he wants to use them in its own projects, he uses header
> files and the source code of the object and instantiates them and
> accesses their methods with the given C++ mechanisms.
>
> If he wants to share his *compiled* objects (in binary form) with
> others, he has to write extra code to turn them to COM objects. Then,
> when he or others wants to use those COM objects, they must use COM
> mechanisms (that is mechanisms obeying the COM conventions but
> programmed with C++), not C++ mechanisms (like new and dispose).
>
> For this to work there must be a way to give the user of a COM object
> the same information like he needed when using a simple object in
> direct, that is kind of a header file defining the type of the object
> (including its methods and variable types it uses).
>
> This is where type libraries come into play. COM objects are gathered in
> a Dll along with a type lib (embedded as resource in this dll). The type
> lib is sort of a compiled header file. When one wants to use a COM
> object, the type lib delivers to the compiler all necessary information
> like a header file would do.
>
> The inventors of VB decided to make their objects being always COM
> objects. So each object (that are classes, forms, user controls,
> basically anything that is not residing in a .bas module) also has to
> have a typelib accompanying it, which publishes the necessary
> informations. And when a VB programmer uses an object, it is always done
> by using COM mechanisms.
>
> So VB is a first class member of those programming environments, which
> can *make* and *consume* (not only its own ones) COM objects. And it
> does the necessary plumbing almost automatically behind the scenes,
> making it very easy to create and use COM objects. In fact so easy and
> so hidden, that most VB programmers do not even know that they are doing
> COM programming all day long. And if they put their code exclusively
> into .bas modules, they even do not use COM.
>
> Now, as COM mechanisms have been invented to provide a means for others,
> to use your objects, all type informations along with the objects have
> to be made public available. This is the intention of COM.
>
> But that is not necessarily always wanted, when you are a VB programmer.
> If you are doing a so called standard exe, all what you want is to make
> and use objects, but not to publish them to the outside.
>
> There you have a contradiction. VB is based on COM. When you are doing
> objects, it uses COM. COM is for making and using objects from all of
> the public outside a project, but in this case you do not want
> publicity.
>
> The solution VB took is to make two kinds of projects available
> (basically because of compatibility reasons to former VB versions, which
> did not use COM):
>
> - standard exes: they use internally COM, but do not publish to the
> outside
> - COM servers (ActiveX dlls and ActiveX components (.ocx)): use COM and
> publish
>
> This is, where the scope of objects come into play. VB objects can have
> private scope (their type is not published) or public scope (their type
> is published). As standard exes do not allow public scope, there also is
> no choice for the programmer to choose between them in the classes
> property window.
>
> To make things a little bit more complicated, the VB team decided (for
> various reasons, among them performance), to implement its own COM
> mechanism handler.
>
> There are then two COM mechanism handlers, which help in using COM
> objects:
>
> - the "official" ones (as implemented in OLExxx.dlls). They are system
> wide available to any programming language who wants to use them. They
> are full fledged and implement all aspects of COM.
>
> - the VB one. This one is a little bit sloppier and implements (residing
> in the VB runtime dll) just enough functionality for doing basic COM,
> such being not compatible to the "official" ones. In special it does not
> use or make typelibs.
>
> So, if a VB project is of kind "standard exe", where all COM objects are
> hidden to the outside, VB can use exclusively its own build in COM
> handler, and does so.
>
> This all works quite fine. But sometimes the COM base shines through the
> mist. That is then when a VB programmer gets being startled because
> suddenly things seem to become quite complex, as he was not aware that
> he is using COM.
>
> > What about VB .NET?
>
> .NET does not use COM anymore (so some say: COM is dead as it is not
> pushed further by MS).
>
> The intention of COM was to unify access and use of compiled objects, no
> matter what programming language was used to declare and compile the
> object. It was an attempt to make code reuse working, despite the fact
> that each programming language (and their accompanying runtimes) have
> their own ideas of what an object is and how it is build and accessed.
> COM lays an additional, separate, programming language or runtime
> inspecific layer over language specific objects to establish
> unification.
>
> .NET goes the other way round to establish code reuse. It uses *one*
> runtime (the CLR) and *one* language (the MSIL) for declaring and using
> objects. Objects are expressed and used only and only again by using the
> CLR and the MSIL. There is no way to declare objects and use objects
> other than using the CLR and the MSIL. So all the differences arising
> from using different programming languages and environments has gone. No
> more different languages to use for creating objects. There is only one
> way to create and handle objects: by using the CLR and the MSIL. Period.
>
> But what is with the former used languages like C++, VB and so on (all
> languages which are able to create objects)? Are they broken now? Do we
> have to program using MSIL (btw, Microsoft Intermediate Language, if you
> don't know) exclusively?
>
> Indeed, you can *all* do what has to be done and can be done in .NET by
> using Notepad and writing some MSIL code, compiling it with the MSIL
> assembler. MSIL is a low level, assembler like, but much much more
> expressive and also object oriented (right, object oriented assembler
> :-) ) language. There is some room left for traditional assembler, but
> only little.
>
> But fortunately as .NET programmer you don't have to use MSIL in direct
> ;-). Some guys at MS decided to rewrite their C++ and VB compilers so
> that they spit out MSIL assembler (in case of C++ at least if you use it
> in managed mode, otherwise it behaves as a traditional C++ compiler)
> instead of machine assembler code. They also created a complete new
> language, called C#, for those who like Java-like programming. And many
> other companies decided to rewrite their compilers too. So actually you
> also can use Fortran, Cobol, Perl (!), Python (I think), Eiffel, Delphi
> (I think available now) and more languages. MSIL is mighty enough
> (indeed MSIL and the CLR are the shining diamonds in .NET) to allow
> these languages to express themselves with mostly all of their
> pecularities.
>
> And on top of this they build a completely new, MSIL based, vast
> framework. As it is build using MSIL and the CLR (and a little bit
> traditional assembler, aka unmanaged code), it can be used from all
> languages that are able to deal with MSIL and the CLR.
>
> This eliminates another annoying aspect, when it comes to code reuse
> (from the programmers viewpoint, it is rather knowledge reuse): you have
> to learn only *one* framework, no matter which programming language you
> use (as long as you do MS Windows programming, of course).
>
> So say goodbye to C runtimes, STL, MFC, ATL, WTL, VB runtimes and all
> other frameworks doing like jobs in different ways.
>
> Looks like I am a .NET afficionado. In a sense, I am. *Technically*, to
> my oppinion, it is brilliant. Not that there are not other like
> brilliant things out there (need to say Java?). But there are
> differences and that ugly real world breaks into when one has to decide
> what to use :-)
>
> --
> Ulrich Korndoerfer
>
> VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
>

Relevant Pages

  • Re: [EGN] Numerical Accuracy
    ... The advice worked because in fact the Microsoft compiler had a bug. ... The capabilities of the optimizer are not so ... The language standard itself says ... of "programming" as a nonprofession. ...
    (comp.programming)
  • Re: Learning C++?
    ... >> abide such rules or there are people who don't know the rules. ... > programming is excellent, and its object-oriented support is quite ... code, like Java or Ada or what else, but no language can prevent the ... This is also something the compiler should be ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Beyond CL?
    ... around in the internals of the language. ... as the programmable programming language; ... Eventually a bank of many users' optimizations could be ... approach the fabled "sufficiently smart compiler". ...
    (comp.lang.lisp)
  • Re: Error message about my user defined type
    ... the type lib delivers to the compiler all necessary information ... COM programming all day long. ... wide available to any programming language who wants to use them. ... CLR and the MSIL. ...
    (microsoft.public.vb.general.discussion)
  • Re: Can you write code directly in CIL ???
    ... >> Cab you write code directly in the Common Intermediate language? ... >> optimize a critical real-time function. ... compiler translate this into assembly language. ... > 2- C# compiler is as clever in generating msil as anyone can possibly get. ...
    (microsoft.public.dotnet.languages.csharp)