LINUX.ORG.RU

История изменений

Исправление a--, (текущая версия) :

Я Gcc давно не пробовал, так как на нем и собирает долго, и сообщения об ошибках у него отличались особой нечитаемостью, да и крэшился он через версию. ... Так вот, gcc-10/11/12 на Мемории крэшатся.

Присоединяюсь к камушку в огород gcc. Потому что неправильная модель разработки.

Так что не только для тебя мой код труден. Даже компиляторы не выдерживают.

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

Кстати, вот как я переписал твою attach, которую «все равно потом выбросят»: 

void attach(EntryT* entry)
{
  switch(entry->queue_kind)
  {
    case A1i : shift_and_insert< A1i, A1o       >(entry); break;
    case A1o : shift_and_insert< A1o, BlackHole >(entry); break;
    case Am  : shift_and_insert<  Am, BlackHole >(entry); break;
    default  : THROW(__LINE__)                          ; break;
  }
}

Весь класс уменьшился на 40...60 строк.

--------------------------------------------------------------------

И я категорически не согласен с твоей мыслью что потенциальные контрибьютеры «избалованы». Нет, это авторы проектов не уделяют внимания документированию и рассказу своей модели. У авторов, правда, есть некоторые слабые оправдания, но это не повод делать выводы о потенциальных контрибьютерах.

(Чуть вбок: что касается модели мемории, то она мне интересна.)

Я думаю имеет смысл сделать пост на ЛОРе на тему избалованности и моделей.

Исправление a--, :

Я Gcc давно не пробовал, так как на нем и собирает долго, и сообщения об ошибках у него отличались особой нечитаемостью, да и крэшился он через версию. ... Так вот, gcc-10/11/12 на Мемории крэшатся.

Присоединяюсь к камушку в огород gcc. Потому что неправильная модель разработки.

Так что не только для тебя мой код труден. Даже компиляторы не выдерживают.

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

Кстати, вот как я переписал твою attach, которую «все равно потом выбросят»: 

void attach(EntryT* entry)
{
  switch(entry->queue_kind)
  {
    case A1i : shift_and_insert< A1i, A1o       >(entry); break;
    case A1o : shift_and_insert< A1o, BlackHole >(entry); break;
    case Am  : shift_and_insert<  Am, BlackHole >(entry); break;
    default  : THROW(__LINE__)                          ; break;
  }
}

Весь класс уменьшился на 40...60 строк.

--------------------------------------------------------------------

И я категорически не согласен с твоей мыслью что потенциальные контрибьютеры «избалованы». Нет, это авторы проектов не уделяют внимания документированию и рассказу своей модели. У авторов, правда, есть некоторые слабые оправдания, но это не повод делать выводы о контрибьютерах.

(Чуть вбок: что касается модели мемории, то она мне интересна.)

Я думаю имеет смысл сделать пост на ЛОРе на тему избалованности и моделей.

Исправление a--, :

Я Gcc давно не пробовал, так как на нем и собирает долго, и сообщения об ошибках у него отличались особой нечитаемостью, да и крэшился он через версию. ... Так вот, gcc-10/11/12 на Мемории крэшатся.

Присоединяюсь к камушку в огород gcc. Потому что неправильная модель разработки.

Так что не только для тебя мой код труден. Даже компиляторы не выдерживают.

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

Кстати, вот как я переписал твою attach, которую «все равно потом выбросят»: 

void attach(EntryT* entry)
{
  switch(entry->queue_kind)
  {
    case A1i : shift_and_insert< A1i, A1o       >(entry); break;
    case A1o : shift_and_insert< A1o, BlackHole >(entry); break;
    case Am  : shift_and_insert<  Am, BlackHole >(entry); break;
    default  : THROW(__LINE__)                          ; break;
  }
}

Весь класс уменьшился на 40...60 строк.

--------------------------------------------------------------------

И я категорически не согласен с твоей мыслью что потенциальные контрибьютеры «избалованы». Нет, это авторы проектов не уделяют внимания документированию и рассказу своей модели. У авторов, правда, есть некоторые слабые оправдания, но это не повод делать выводы о контрибьютерах.

(Чуть вбок: что касается модели мемории, то она мне интересна.)

Я думаю имеет смысл сделать пост на ЛОРе на тему избалованности и моделей.

Исходная версия a--, :

Я Gcc давно не пробовал, так как на нем и собирает долго, и сообщения об ошибках у него отличались особой нечитаемостью, да и крэшился он через версию. ... Так вот, gcc-10/11/12 на Мемории крэшатся.

Присоединяюсь к камушку в огород gcc. Потому что неправильная модель разработки.

Так что не только для тебя мой код труден. Даже компиляторы не выдерживают.

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

Кстати, вот как я переписал твою attach, которую «все равно потом выбросят»: 

void attach(EntryT* entry)
{
  switch(entry->queue_kind)
  {
    case A1i : shift_and_insert< A1i, A1o       >(entry); break;
    case A1o : shift_and_insert< A1o, BlackHole >(entry); break;
    case Am  : shift_and_insert<  Am, BlackHole >(entry); break;
    default  : THROW(__LINE__)                          ; break;
  }
}

Весь класс уменьшился на 40...60 строк.

--------------------------------------------------------------------

И я категорически не согласен с твоей мыслью что потенциальные контрибьютеры «избалованы». Нет, это авторы проектов не уделяют внимания рассказу своей модели. У авторов, правда, есть некоторые слабые оправдания, но это не повод делать выводы о контрибьютерах.

Я думаю имеет смысл сделать пост на ЛОРе на тему избалованности и моделей.