Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C#
  4. C# arrays

C# arrays

Scheduled Pinned Locked Moved C#
csharphelpquestionc++java
2 Posts 1 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • N Offline
    N Offline
    Nick Blumhardt
    wrote on last edited by
    #1

    Ok, something worries me about array types in C#. Two things actually, the first being the concrete type of an array of C# objects. The following:

    SomeClass[] myArr = new SomeClass[10];
    

    creates an object myArr that is of a type derived from System.Array, and specialised for objects of type SomeClass. My first question regards the [] operator. Where does it suddenly spring into the picture? It doesn't exist on objects of type System.Array. The type of the indexer for myArr above is SomeClass it seems, as the compiler won't let me make a statement like:

    myArr[0] = new string;
    

    and quite rightly so, complaining that string cannot be converted into SomeClass. Thus the indexer must be part of the interface of the automatically generated derived array type. The wierdness begins when I do this:

    object[] mySameArr = myArr;
    Console.Write (mySameArr[0]);
    

    Now, this compiles and runs without a problem. How? The interfaces of the derived object[] and SomeClass[] types must be different, because each declares an indexer with a different signature. This probably shouldn't compile, or at least, shouldn't run, because despite SomeClass being derived from object, SomeClass[] is NOT derived from object[]! What's going on? Does the C# compiler fudge this some way, or does the .NET CTS have different relationships between array types that doesn't fit my (somewhat C++ skewed) view? Is this some kind of mock-up of generics that seems like it will be broken once real generics are implemented? My second, and maybe not so confusing, question regards pointers and arrays. This appears in MSDN:

    public unsafe int Read(byte[] buffer, int index, int count) 
    {
       int n = 0;
       fixed (byte* p = buffer) 
       {
          ReadFile(handle, p + index, count, &n, 0);
       }
       return n;
    }
    

    Can anyone tell me where the conversion is made between the byte[] specialisation of System.Array and byte*? Is there a conversion operator defined in that subclass, or is there some other compiler funk going on? Should I be poring through the C# standard? Thanks for any help, and please, if this has come up before (as I'm sure it would have) point me towards the old posting.

    N 1 Reply Last reply
    0
    • N Nick Blumhardt

      Ok, something worries me about array types in C#. Two things actually, the first being the concrete type of an array of C# objects. The following:

      SomeClass[] myArr = new SomeClass[10];
      

      creates an object myArr that is of a type derived from System.Array, and specialised for objects of type SomeClass. My first question regards the [] operator. Where does it suddenly spring into the picture? It doesn't exist on objects of type System.Array. The type of the indexer for myArr above is SomeClass it seems, as the compiler won't let me make a statement like:

      myArr[0] = new string;
      

      and quite rightly so, complaining that string cannot be converted into SomeClass. Thus the indexer must be part of the interface of the automatically generated derived array type. The wierdness begins when I do this:

      object[] mySameArr = myArr;
      Console.Write (mySameArr[0]);
      

      Now, this compiles and runs without a problem. How? The interfaces of the derived object[] and SomeClass[] types must be different, because each declares an indexer with a different signature. This probably shouldn't compile, or at least, shouldn't run, because despite SomeClass being derived from object, SomeClass[] is NOT derived from object[]! What's going on? Does the C# compiler fudge this some way, or does the .NET CTS have different relationships between array types that doesn't fit my (somewhat C++ skewed) view? Is this some kind of mock-up of generics that seems like it will be broken once real generics are implemented? My second, and maybe not so confusing, question regards pointers and arrays. This appears in MSDN:

      public unsafe int Read(byte[] buffer, int index, int count) 
      {
         int n = 0;
         fixed (byte* p = buffer) 
         {
            ReadFile(handle, p + index, count, &n, 0);
         }
         return n;
      }
      

      Can anyone tell me where the conversion is made between the byte[] specialisation of System.Array and byte*? Is there a conversion operator defined in that subclass, or is there some other compiler funk going on? Should I be poring through the C# standard? Thanks for any help, and please, if this has come up before (as I'm sure it would have) point me towards the old posting.

      N Offline
      N Offline
      Nick Blumhardt
      wrote on last edited by
      #2

      For anyone interested, http://www.jaggersoft.com/csharp_standard/19.5.htm[^]

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • World
      • Users
      • Groups