У меня структуры дальше второго уровня вложенности не проскакивают, в обычных-то путаюсь.

Нужно ли избавляться от таких цепочек в ущерб читаемости?

Если нормально называть, то читаемость будет только повышаться.

Просто когда вижу что-то типа

warehouse.elem[window].data.win.eventsmask = warehouse.elem[window + 1].data.win.eventsmask + warehouse.elem[window - 1].data.win.eventsmask;
// Пример из головы

с помощью указателей можешь избавиться

а так же выносить изменение параметров в отдельные инлайн функции.

Нужно ли избавляться от таких цепочек в ущерб читаемости?

Это гогно сдеать ещё менее читабельным довольно проблематично. Избавляться от него нужно методом разбиения данных на логические кучки (~объекты) и кода на небольшие операции над ними. Как в этом случае сделать это не ясно, мало данных, с ходу можно только вынести warehouse.elem в отдельный указатель

Называть надо нормально. Единственный минус - долго набирать. А читать просто. Компилятор вообще оптимизирует такие цепочки до одного обращения по адресу.

Почитайте LDD (linux device drivers), а ещё лучше любой сетевой драйвер, например из 802.11 стека - там как раз отлично видно, как с этим бардаком работать. Как выше уже писали - приводить к указателю на самый нижний элемент структуры и обращаться уже к его элементам проще, а самое главное наглядно.

Как дело с этим обстоит у вас?

у нас такое говно невозможно, т.к. private: не даёт доступ.

да что вы говорите!

у нас такое говно невозможно, т.к. private: не даёт доступ.

зато геттеры/сеттеры неплохо справляются с созданием цепочек нечитабельного говна.

warehouse.elem(window).data().win().eventsmask()
warehouse.elem(button).data().btn().window()
warehouse.elem(index).data().btn().geometry().height()
warehouse.elem(image16).data().img().image()->data

У тебя слишком высокая связность кода.

Нужно ли избавляться от таких цепочек в ущерб читаемости?

Будто эта каша хоть сколько-нибудь читаема.

зато геттеры/сеттеры неплохо справляются с созданием цепочек нечитабельного говна.

это точно C++?

это точно C++?

да.

а нахрена это писать? Не, я просто не понимаю, объясни пожалуйста.

У меня в коде на питоне уровне вложенности структур еще больше, я не парюсь.

Для питона это ещё даёт большой оверхед по производительности, он принципиально не умеет оптимизировать такие вещи.

а нахрена это писать? Не, я просто не понимаю, объясни пожалуйста.

Твой пост был о:

у нас такое говно невозможно, т.к. private: не даёт доступ.

невозможно, т.к. private

Так вот private никак не влияет на возможность городить такие цепочки. Зачем так делать мне наплевать.

Так вот private никак не влияет на возможность городить такие цепочки. Зачем так делать мне наплевать.

так вот, private не даст пользователю класса залезть в кишки класса. Т.е. можно только foo.bar, даже если bar что-то там своё имеет. Это AFAIK называется «инкапсуляция», хотя конечно я быдлокодер, и возможно пацаны меня не поймут. Но мне так проще, ибо связанность классов не слишком сильна, и их проще поддерживать.

Всё ИМХО.

И? Расскажите, как инкапсуляция избавляет вас от таких цепочек. Если класс простой (foo.bar), то само собой ничего такого не произойдёт. Но если поля класса сложные объекты (другие классы) со своими геттерами/сеттерами, то получается то же самое. Или же вы отслеживаете подобные вещи и приводите их к простому виду (foo.bar.get.set.add к виду foo.bagetAdd)? Речь ведь о доступе к «кишкам» класса не шла. Речь о цепочках, возникающих из-за сложной структуры.

Или же вы отслеживаете подобные вещи и приводите их к простому виду (foo.bar.get.set.add к виду foo.bagetAdd)? Речь ведь о доступе к «кишкам» класса не шла. Речь о цепочках, возникающих из-за сложной структуры.

да, отслеживаю. bar делается private, потому к нему не обратится напрямую. Только косвенно. Потому что bar.get.set.add(int) может стать bar.get.set.add(double) и всё поломать на много уровней выше.

Я не говорю, что я всегда так делаю, но ИМХО к этому надо стремиться.

Для меня работает такой подход: группировать по задачам, сущностям, функциональности. Чтобы не пришлось «лазить» по всему проекту, когда все разбросано там и сям.

Бить архитектора по почкам и заставлять следовать закону деметры.

так вот, private не даст пользователю класса залезть в кишки класса. Т.е. можно только foo.bar, даже если bar что-то там своё имеет. Это AFAIK называется «инкапсуляция», хотя конечно я быдлокодер, и возможно пацаны меня не поймут. Но мне так проще, ибо связанность классов не слишком сильна, и их проще поддерживать.

private не даёт пользователю залезть в кишки класса, да. Но зачастую акцессоры это свойство как раз таки нарушают. Замена `public: int x;` на `private: int x; public: int getX(); void setX(int)` не меняет ровным счётом ничего. Статейка на тему - why getters and setters are evil. Да, а за байки типа «а мы вдруг внезапно когда-нибудь захотим это поле брать из бд» предлагаю сразу жечь на кострах.

Статейка на тему - why getters and setters are evil. Да, а за байки типа «а мы вдруг внезапно когда-нибудь захотим это поле брать из бд» предлагаю сразу жечь на кострах.

Статью, учитывая мои знания английского, буду мучить долго. Но основной смысл геттеров-сеттеров в проверке вводимого значения, единообразии и расширяемости. И почему жечь на кострах? БД, не БД, но ведь с расширением системы поле может поменять тип, стать куда более сложным. А интерфейс должен остаться интерфейсом.

Замена `public: int x;` на `private: int x; public: int getX(); void setX(int)` не меняет ровным счётом ничего.

меняет.

Статейка на тему - why getters and setters are evil.

может в этой вашей яве и так. Ваши явапроблемы. Да и никто не предлагал на каждый int x делать getters.

Да, а за байки типа «а мы вдруг внезапно когда-нибудь захотим это поле брать из бд» предлагаю сразу жечь на кострах.

жечь нужно за не поддерживаемый говнокод, который ты пишешь.

И почему жечь на кострах?

потому что видимо ява не умеет это инлайтить. И всё тупит.

Use classes, Luke! (Objective-C, к примеру)

Давай, покажи мне реализацию того же самого по Деметре на сях.

Да, слегка запудривает мозг.

Сами пишите на этом говнояблоподелии.

Не, ну можно форматировать, чуть понятней будет:

warehouse.elem[window].data.win.eventsmask = 
   warehouse.elem[window + 1].data.win.eventsmask + 
   warehouse.elem[window - 1].data.win.eventsmask;

Сделай макросом

#define EVENTMASK(w) warehouse.elem[w].data.win.eventsmask

/* ... */

EVENTMASK(window) = EVENTMASK(window + 1) + EVENTMASK(window - 1);

/* ... */
#undef EVENTMASK

Никогда не понимал людей, дающих ссылку на английскую википедию, при наличии нормальной статьи в русской.

Нормальный код.

у нас такое говно невозможно, т.к. private: не даёт доступ.

Автор вроде бы хотел поговорить о C, а не о C++? Или он тег поставил, не подумавши?

sambist, ты ведь Си имел в виду?

Си, разумеется.

ну в Pure C это ИМХО тоже быдлокод, т.к. нельзя выпячивать наружу внутренности структур. ИМХО в этом случае всё должно делаться через структуру-интерфейс, а лучше через нестатические функции-интерфейс. А если это вредит производительности, то обработка должна быть реализована в одном модуле сборки. В одном *.c/*.obj файле. Тогда компилятор инлайтит внутренние статические функции, и в итоговом машинном коде нет никакого оверхеда от инкапсуляции.

Опять: ИМХО. Если кто не согласен, то пожалуйста приведите пример, в котором я не прав. А лолки стройными рядами идут прочь.

это у тебя такое:

stuct a
{
  struct b
  {
    struct c
    {
      struct d
      {
        int e;
      }f[7];
    }g[2];
  }h[18];
}i[7756];

да?

Никогда не понимал людей, дающих ссылку на английскую википедию, при наличии нормальной статьи в русской.

обычно на русской говно, а не статья. Потому, ссылка на русскую вику пруфом не является.

Сделай макросом

нахрена, если можно сделать статическую функцию? Сейчас не 20й век, компилятор её заинлайтит даже лучше твоего макроса.

Почти. В общих чертах - да.

ну никому не показывай. Засмеют. Кроме шуток.

Порежь это всё на функции.

Почитай вот вику для начала: http://ru.wikipedia.org/wiki/Рефакторинг

вот оказывается есть и статья говнокод там же. А я и не знал...

нахрена, если можно сделать статическую функцию? Сейчас не 20й век, компилятор её заинлайтит даже лучше твоего макроса.

Э? У вас контекст в голове держится? Напоминаю, вопрос был про то как сделать длинные «цепочки» более читаемыми. Это можно делать макросами, например, о чем я и написал. И привел небольшой пример

Давай, покажи мне реализацию того же самого по Деметре на сях.

а вот как раз на сях это ещё более важно. В C++ это само собой получается, а в сишечке нужно усилия прилагать. Можно не прилагать, вот только ничего сложнее хэлловорлда на 100 строк ты не напишешь. Увы.

Э? У вас контекст в голове держится? Напоминаю, вопрос был про то как сделать длинные «цепочки» более читаемыми. Это можно делать макросами, например, о чем я и написал. И привел небольшой пример

это НЕЛЬЗЯ делать макросами. Потому что макросы только заметают мусор под ковёр. Тут проблема совсем не в читаемости. Читаемость(нечитаемость точнее) только одно из следствий проблемы. Если хреново с английским, я проверил, на русской вике есть годная статья про LoD.

У концепции LoD есть недостатки, но если пользоваться современным gcc, то это мелочи, и на них не стоит обращать внимание. За счёт более лучшей и удобной архитектуры код будет работать на порядок быстрее, невзирая на какие-то потери каких-то трёх тактов.

К тому же, отход от LoD это преждевременная оптимизация, ещё один 146% детектор говнокодера.

основной смысл геттеров-сеттеров в проверке вводимого значения, единообразии и расширяемости

Это цель любого адекватного проектировщика. К сожалению, зачастую акцессоры этому воспрепятствуют.

с расширением системы поле может поменять тип, стать куда более сложным

Например, было int, стало float? Сомневаюсь, что акцессоры здесь помогут.

Например, было int, стало float?

Например, было int стало struct. С использованием акцессоров и перегрузки операций (в си её нет, но я не про него) можно оставить как старый вариант, только снабдить его умолчательными значениями, так и новый используемый, например, для более тонкой настройки.

К сожалению, зачастую акцессоры этому воспрепятствуют.

А как реализовать это без них? Принцип, на который вы ссылались выше, минимизирует количество кода, который придется переписывать при расширении программы, но акцессоры видятся мне более правильным и элегантным решением. Приведите, пожалуйста, альтернативу им.

это НЕЛЬЗЯ делать макросами

Гм. Неловко спрашивать, но вы вообще на С программировали?

А вот такая хрень как в ОПе, лучше?

Гм. Неловко спрашивать, но вы вообще на С программировали?

а вы? Уверен — нет. Ибо поиск ошибки в макросе — вам это не знакомо. А её хрен найдёшь, т.к. код отлично собирается, и даже работает. Но работает НЕ ТАК. Потому что макрос не так развернулся. И за макросом этого НЕВИДНО.

Ну ничего, вы ещё попомните, если в профессии останетесь...

Гм. Неловко спрашивать, но вы вообще на С программировали?

а вы?

Ясно. Простите, больше не буду вас беспокоить