LINUX.ORG.RU
Форум — Development  

Как избавляться от длинных цепочек xxx.yyy.zzz и надо ли?

 


0

2 
...
warehouse.elem[window].data.win.eventsmask
warehouse.elem[button].data.btn.window
warehouse.elem.elements[index].properties[WIDTH].value
warehouse.elem[index].data.btn.geometry.height
warehouse.elem[image16].data.img.image->data
...

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

Сабж.

★★
← Вставка своего кода в Linux ELF файл (или как добавить новую секцию или расширить существующую)
Опенсорс для работы с данными →
  1 2 →

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

А где тут читаемость? Я её в упор не вижу. Да нужно, нужно не писать так, а писать нормально.

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

Я даже представить не могу как такое можно сотворить - хотя я помню тебя ты создавал фейспалм тему с image16 и image32. Учит писать, man c99, указатели, динамические структуры.

anonymous
()
Ответ на: комментарий от anonymous

спасибо. Но совсем я буду вам благодарен после того, как вы зарегистрируетесь, и я перестану вас путать с адекватными людьми.

emulek ★
()
Ответ на: комментарий от emulek

я в курсе про cpp. Но вы сами-то видели? Посмотрите...

в коде вешается 1 ключ-комментарий, сед, после cpp, вырезает все, что идёт до этого ключа и код становится аналогичным исходному, но с развёрнутыми макросами. проблема опять надумана.

Stil ★★★★★
()
Ответ на: комментарий от Stil

в коде вешается 1 ключ-комментарий, сед, после cpp, вырезает все, что идёт до этого ключа и код становится аналогичным исходному, но с развёрнутыми макросами. проблема опять надумана.

нет. Не надуманна. ТС поставит Over9000 макросов, ведь у него таких разных строчек Over9000, и для каждого доступа нужен свой макрос. И потом найти нужный макрос будет решительно невозможно. Проблема тут в том, что код зависит от Over9000 деталей и разных модулей. Одно описание структуры ТС занимает Over9000 строк, раскиданных наверное ещё и по куче файлов.

Макросы конечно на первый взгляд помогают, но это не решение.

emulek ★
()
Ответ на: комментарий от emulek

Видел, мало того, писал отлаживал конструкции типа: 

578	    /* Цикл по схемам расчета */
579	    uint32_t marker = 1;
580	    for (i = 0; i < (sizeof(schemes) * 8); i++)
581	    {
582	        if (schemes & marker)
583	        {
584	            switch (marker)
585	            {
586	            /* Выбор функции расчета */
587	            #define DEF_CO(PNAME, SHNAME)                \
588	            eval##SHNAME##PNAME(data, result,            \
589	                                getSchemeIndex(#SHNAME), \
590	                                getParamIndex(#PNAME));
591	
592	            /* Выбор схемы расчета    */
593	            #define DEF_SL(SNAME, SVALUE)  \
594	            case SVALUE :                  \
595	                init##SNAME(data, result); \
596	                CALC_ORDER_##SNAME(SNAME)  \
597	                break;
598	
599	            SCHEMES_LIST
600	
601	            #undef DEF_SL
602	            #undef DEF_CO
603	            }
604	            /* Развернется в :
605	            switch (marker)
606	            {
607	            case (SIMPLE) : // Простая схема
608	                initSIMPLE(data, result);
609	                evalSIMPLEFr(data, result, getSchemeIndex("SIMPLE"), getParamIndex("Fr"));
610	                evalSIMPLECt(data, result, getSchemeIndex("SIMPLE"), getParamIndex("Ct"));
611	                evalSIMPLETg(data, result, getSchemeIndex("SIMPLE"), getParamIndex("Tg"));
612	                evalSIMPLERd(data, result, getSchemeIndex("SIMPLE"), getParamIndex("Rd"));
613	                ...
614	                break;
615	            case (MARTYN) : // Схема Мартина
616	                initMARTYN(data, result);
617	                evalMARTYNFr(data, result, getSchemeIndex("MARTYN"), getParamIndex("Fr"));
618	                ...
619	                break;
620	            case (MLCIRC) : // Многоконтурная схема
621	                initMLCIRC(data, result);
622	                evalMLCIRCFr(data, result, getSchemeIndex("MLCIRC"), getParamIndex("Fr"));
623	                ...
624	                break;
625	            case ...
626	            } */
627	        }
628	        marker <<= 1;
629	    }
630	
631	    return CR_SUCCESS;
632	}

sambist ★★
() автор топика

Это быдлокод. Гордись.

anonymous
()
Ответ на: комментарий от emulek

и какой в этом профит?

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

sambist ★★
() автор топика
Ответ на: комментарий от Weres

А как реализовать это без них?

Честно говоря, не понимаю, что за «это» мы обсуждаем. Речь про акцессоры зашла в контексте замены вот этого:

warehouse.elem[window].data.win.eventsmask

на

warehouse.elem(window).data().win().eventsmask()

Что с ними, что без, очевидно, что код - говно. Но, почему-то, выдавая второй вариант, автор зачастую считает, что построил крутую объектную модель. Если вы считаете, что геттеры в данном примере действительно улучшают код - давайте подискутируем :)

Laz ★★★★★
()
Ответ на: комментарий от emulek

С++ и VisualDSP плохо дружат. Переходить на C++ -> переписывать сотни тысяч строк легаси кода для других устройств, ибо код расчетчика один для всех.

sambist ★★
() автор топика
Ответ на: комментарий от Laz

Это:

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

Дискутировать не отважусь. Опыта мало, стараюсь прояснить некоторые моменты. Не более того. Вот геттеры, в принципе, а не в данном примере, позволяют обеспечить расширяемость и проверку значения. Согласен, код они не улучшают, в инкапсуляции ради инкапсуляции смысла я не вижу. Вы же писали, что

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

Вот мне и любопытно почему они это самое затрудняют и каковы альтернативы. А в примере ТС, как мне думается, проблема в организации самих структур.

Weres ★★★
()
Ответ на: комментарий от sambist

ничем не могу помочь. Макросы == рак. Если ты начал их юзать, тебе уже не остановится, разве что переписывать ВСЁ с нуля.

Это ещё одна причина того, что я их недолюбливаю, и юзаю только в виде 

#define XYZ 123
(да, это конечно в идеальном мире, в котором мне хочется жить)

emulek ★
()
Ответ на: комментарий от emulek

Макросы == рак

Почитайте про XMACRO, есть вещи, которые можно решить только макросами. А если вам хочется бриться топором потому что вы не хотите видеть бритву - удачи.

sambist ★★
() автор топика
Ответ на: комментарий от sambist

Почитайте про XMACRO, есть вещи, которые можно решить только макросами. А если вам хочется бриться топором потому что вы не хотите видеть бритву - удачи.

если бриться можно бритвой, это не повод идти с бритвой в лесоповал.

emulek ★
()

Expert C Programming: Deep C Secrets By Peter van der Linden

Koenig, Andrew. C traps and pitfalls.

очевидно ведь.

qulinxao ★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 →
← Вставка своего кода в Linux ELF файл (или как добавить новую секцию или расширить существующую)
Development
Опенсорс для работы с данными →