В чем фишка массивов? Хороший вопрос

В программировании мне ни разу не приходилось сталкиваться с ситуацией,
когад массив был бы лучшим решением для хранения информации, чем любая иная
его форма. Я думал, что добавочные «фишки» в языках программирования улучшили
массивы и, тем самым, их заменили. Теперь я вижу, что они не заменены, а, наоборот,
обрели, так сказать, новую жизнь

http://stackoverflow.com/questions/392397/arrays-whats-the-point

Я увидел это сообщение на Реддите и реакия была далеко не благосклонной. Большая часть обсуждения сконцетрировалась на том, насколько глуп сам вопрос, и на ошибках образовательного и профссиональных сообществ, которые привели к тому, что такие базовые вещи не известны. К сожалению, моя первая реакция была такой же.

После некоторого размышления я понял, что вопрос не такой уж и глупый. Я понял, что я не использую массивы в Эрланге, они там просто не нужны. Программируя на С и С++, я постоянно их использовал, потому что я был практически вынужден их использовать. Но в Эрланге на передний план выходят списки. В Эрланге есть средства для работы с массивами, но максимум, на который я приближаюсь к использованию их — это в использовании маленьких кортежей фиксированой длины. Странно, но я только сечас заметил, насколько редко я использую массивы. Единственно место, где я их применяю, программируя на Эрланге, это для организации поиска по двоичным ключам в коде двоичных деревьев в CouchDB.

Правда состоит в том, что, если вы не занимаетесь низкоуровневым программированием, массивы (и даже векторы) редко необходимы или оптимальны дл большинства задач. Самая яркая особенность массивов — это константное время доступа к любому значению по порядковуму номеру. Проблма состоит в том, что мало какая задача требует константного времени доступа к значениям по порядковым значениям. Массивы в основном применяются как коллекции данных, для чего больше подходит список.

// bad design
public class Order {
  public List<OrderItem> Items { get { ... } }
}
// good design
public class Order {
  public Collection<OrderItem> Items { get { ... } }
}

public List<T>(IEnumerable<T> collection) {
  // check if it implements ICollection
  ICollection<T> col = collection as ICollection<T>;
  if (col != null)
    this.Capasity = col.Count;
  foreach (T item in collection)
    Add(item);
}

// bad design
public class Order {
  public Collection<OrderItem> Items { get { ... } set { ... } }
  ...
}
// good design
public class Order {
  public Collection<OrderItem> Items { get { ... } }
  ...
}

IEnumerable<string> list = GetList();
foreach (string name in list) {
  ...
}

public class Directory {
  public Directory(string root);
  public IEnumerable<FileInfo> Files { get; } // live
  // or
  public FileInfoCollection GetFiles(); // snapshot
}

// bad design
for (int index = 0; index < customer.Orders.Length; index++)
  Console.WriteLine(customer.Orders[i]);

S>Здесь будет одинаково уместно использовать T[] или List<T>, но List<T> удобнее, т.к. у него больше сервисов, потребитель метода сможет что-то с результатом сделать по своему усмотрению. Здесь главное не мешать массивы с листами, т.к. у одного Count а у другого Length

IEnumerable<string> Names {
  get {
    for(var s in smth()) {
      yield return "_" + s;
    }//for
  }
}

M>>А как часто вы используете массивы?

template < class It >
void variable_arg_num_func( It i_argListBegin, It i_argListEnd )

So why are arrays covariant? According to the CLI Annotated Standard, for the first edition the designers wished to reach as broad an audience as possible, which included being able to run code compiled from Java source. In other words, .NET has covariant arrays because Java has covariant arrays — despite this being a known “wart” in Java.

get { return _fooList.AsReadonly(); }

IList<T> не нужен практически никогда … Если ты в своём коде используешь IList<T>, то скорее всего, его нужно заменить либо на IEnumerable<T> … либо на List<T>…

/* Хотя эта функция и принимает IList<T>, но в действительности сюда нужно передавать не любую реализацию индексируемого списка,
а лишь ту, что обеспечивается константное время доступа.
Т. е. вероятнее всего вам придётся передать сюда List<T>, т. к. LinkedList<T> понизит скорость с константной до кубической,
ибо в функции есть тройной цикл. */
int SomeFunc(IList<T> list);

int SomeFunc(List<T> list);

Если ты в своём коде используешь IList<T>, то скорее всего, его нужно заменить либо на IEnumerable<T> (если обращение по индексу никогда не используется, а используется только перечисление), либо на List<T> (если обильно используется случайный доступ по индексу, то лучше входной параметр функции фиксировать этой конкретной реализацией IList'а, чтобы пользователь функции не мог передать связный список и поиметь падение производительности).

#if MOON_PHASE == 0
typedef std::vector<X> range_type;
#elif MOON_PHASE == 1
typedef std::deque<X> range_type;
#elif MOON_PHASE == 2
typedef std::list<X> range_type;
#elif MOON_PHASE == 3
typedef boost::iterator_range<some_iterator> range_type;
#else
typedef boost::iterator_range<any_iterator<X> > range_type;
#endif

range_type get_a_sequence_of_X();

rep
movsl

I often hear people saying that interfaces specify contracts. I believe this is a dangerous myth. Interfaces, by themselves, do not specify much beyond the syntax required to use an object. The interface-as-contract myth causes people to do the wrong thing when trying to separate contracts from implementation, which is a good engineering practice. Interfaces separate syntax from implementation, which is not that useful, and the myth provides a false sense of doing the right engineering.

In reality, the contract is semantics, and these can actually be nicely expressed with some implementation.

interface ICountable<T> : IEnumerable<T> {
  int Count { get; }
}

interface IIndexable<T> : ICountable<T> {
  T this[int i] { get; }
}

struct ArrayBox<T> : IIndexable<T>
{
    private T[] array;

    public ArrayBox(T[] a)
    {
        if (a == null) throw new ArgumentNullException("a");
        array = a;
    }

    public T this[int i] { get { return array[i]; } }
    public int Count { get { return array.Length; } }

    public static implicit operator ArrayBox<T>(T[] array)
    {
        return new ArrayBox<T>(array);
    }

    public IEnumerator<T> GetEnumerator()
    {
        return new Enumerator(array);
    }

    System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }

    struct Enumerator : IEnumerator<T>
    {
        T[] array;
        int i;

        internal Enumerator(T[] a)
        {
            array = a;
            i = -1;
        }

        public T Current
        {
            get { return array[i]; }
        }

        public void Dispose()
        {
        }

        object System.Collections.IEnumerator.Current
        {
            get { return array[i]; }
        }

        public bool MoveNext()
        {
            int tmp = i + 1;
            if (tmp < array.Length)
            {
                i = tmp;
                return true;
            }

            return false;
        }

        public void Reset()
        {
            i = -1;
        }
    }
}

G>template < class It >
G>void variable_arg_num_func( It i_argListBegin, It i_argListEnd )
G>

G>И где у нас разница между массивом и списком? Что хошь, то и передавай. То же касается ленивости итераторов и прочего перечисленного. Эт конечно дремучий С++, но разве в новомодных С# нельзя делать так же?

void variable_arg_num_func<T>(IEnumerable<T> args) { ... }
void variable_arg_num_func<T>(params T[] args) { variable_arg_num_func((IEnumerable<T>)args); }

V>interface ICountable<T> : IEnumerable<T> {
V>  int Count { get; }
V>}

V>interface IIndexable<T> : ICountable<T> {
V>  T this[int i] { get; }
V>}

V>    public IEnumerator<T> GetEnumerator()
V>    {
V>        return new Enumerator(array);
V>    }

V>    struct Enumerator : IEnumerator<T>

V>>>    public IEnumerator<T> GetEnumerator()
V>>>    {
V>>>        return new Enumerator(array);
V>>>    }

V>>>    struct Enumerator : IEnumerator<T>

_FR>>"Косвенность" таки наблюдается в том, что происходит боксинг Enumerator-а. Зачем было оптимиздить© до структуры

перебрать сплошной массив памяти можно с помощью одного индексного регистра, которые к тому же почти всегда имеют команду приращения без задействования аккумулятора

a = *ptr++;

a = ptr->data;  // a = *ptr++
ptr = ptr->next; // tmp = *ptr; ptr = tmp;

А как часто вы используете массивы?