Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: c? c++?

  1. #11
    Senior Member
    Join Date
    Jun 2002
    Posts
    165
    Mankan, having been sheltered from .NET thus far, i have a few questions related to the runtime architecture with regard to pre-existing COM stds, specifically:

    - do .NET classes expose public interfaces derived from IUnknown?
    - automation, and dual interfacing capabilities
    - hosting options; COM+ or other surrogates
    - registry or COM+ application registry dependence (guid, clsid, appid, etc.)

    i guess the simple answer if it all fits together nicely is that it's all supported; but if there are keynote differences that you can think of without digging through whitepapers - i'd really enjoy getting some feedback on it.

    tia.
    -droby10

  2. #12
    I will give an example of the difference between c and c++

    /* C Code */
    struct stack
    {

    An example
    /* C code*/

    struct stack
    {
    int elt[100];
    int top ;
    }s;

    void push(int x)
    {
    /* code to push*/
    }

    int pop()
    {
    /* code to pop*/
    }

    void main()
    {
    int i;
    s.push(100);
    i = s.pop();
    }

    // c++ code
    class stack
    {
    private :
    int elt[100],top;
    public:
    void push();
    int pop();
    } s;
    main()
    {
    int i;
    s.push(100);
    i = s.pop();
    }
    U can clearly see that in C++ , not only the properties(say variables), but also the methods(functions) to act on those variables are part of the datatype.

  3. #13
    Senior Member
    Join Date
    Feb 2002
    Posts
    170
    Originally posted here by droby10
    Mankan, having been sheltered from .NET thus far, i have a few questions related to the runtime architecture with regard to pre-existing COM stds, specifically:

    - do .NET classes expose public interfaces derived from IUnknown?
    - automation, and dual interfacing capabilities
    - hosting options; COM+ or other surrogates
    - registry or COM+ application registry dependence (guid, clsid, appid, etc.)

    i guess the simple answer if it all fits together nicely is that it's all supported; but if there are keynote differences that you can think of without digging through whitepapers - i'd really enjoy getting some feedback on it.

    tia.

    Introduced with the .NET architecture is the concept of assemblies. Each compilation results in an Assembly, shared or private but I will get to this in a moment. The Assembly is numbered a.b.x.y where x and y are regarded as smaller differences and the assembly will be backwards compatible. a and b are used for larger changes. The code might break so the actual dll is never replaced but a side by side execution takes place.

    An assembly is totally selfcontained with metadata code and everything it needs. It can, but doesn't have to span multiple physical files. Think of it as a logical dll. There are some benefits that comes with this. - First, there is no more DLL-hell. No registration process takes place and two assemblys with the same name can exist and execute side by side (as long as their respective a and b numbers in the version number is different). Oh, and another feature is drag n' drop (or xcopy if you're into DOS) deployment.

    No .NET classes expose the traditional COM interfaces because there is no need to do so. There is however possible to wrap a .NET class in a COM-wrapper give it a typelib a public key and what not and then register. The .NET class will then operate and behave as any normal COM object. The performance overhead for doing this is quite severe though.

    What have been said so far is espesially true for private assemblies which are stored at whatever destination that was chosen at the installation. The DLL is the Assembly remember?

    There are as earlier mentioned something called shared asseblies as well. These coud be morethought of as shared libraries in Unix. They are self contained but stored in the GAC, the Global Assembly Cache where other .NET programs all can interact with it.

    The security thinking behind assemblies is also really nice since it is possible to set permissions on each assembly.

    Assemblys can also be downloaded and installed on demand so the initial installation can be smaller and features that are never used might never download.

    Maybe I should edit this some and put it as a tutorial instead? It got kinda long. Anyway, I hope you get the big picture. The thought of assemblies is really nifty and certainly a more enjoyable way to work than the old COM objects.

    Cheers,
    Mankan

    \"The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.\"
    - Edsger Dijkstra

  4. #14

    Talking

    ok.. thanks for everyones excellent replies

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •