Перегрузка операторв в С++

программирование программы C++ ООП операторы

Здравствуйте.

вопрос по читабельности кода

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

для удобства доступа к элементам начал перегружать операторы [] и ()
в итоге могу придти к выражениям такого вида Table[1][2][3], что означает 3-й элемент 2-й категрии в 1-ой строке. или даже Table[1](2,3). не странный ли вид? если перетсраться, то можно много забавного увидеть.

может Table[1]->Cell[2][3] будет более читабельно?
или вобще
Column=Table->Get_Column(1);
Cell=Column->Get_Cell(2,3);

где остановится?

или есть другие предложения?



Примечание:
EasyPlaton
у меня набор сенсоров, разделенных на категории. и все это по шагам. :))) программирование промышленного контроллера. не совсем каталог.

доступ без перегрузки выглядит так Table->Get_Step(1)->Get_Cell(2,3)

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

Примечание:
Роман Храбров
готов выслушать предложения

Примечание:
EasyPlaton
самый очевидный вариант написан. он последний. просто расписан по строкам и не пометсился в текст

Примечание:
у меня очень часто будет происходить операция сравнения значения сенсора на разных шагах. те .
if(Table->Get_Step(1)->Get_Cell(2,3)==Table->Get_Step(2)->Get_Cell(2,3)) /*что то делаем*/
вот как то так.... уж очень страшно.... куча символов...и на строчку не влезает

по моему вот это выглядит компактнее. только через месяц я и сам уже не прочитаю что написано :))))))
if(Table[1][2][3]==Table[2][2][3]) /*что то делаем*/

хочу найти комрпромис

Примечание:
EasyPlaton
тоесть предлагаете мне сделать трехмерный список? вынести сенсоры в категории?

я так хотел сделать сначала, но сейчас у меня сенсноры в перемешку с категриями. тот же элемент, но внутренная переменная Type не 1 а 2. сделал так, чтобы было проще сортировать и перемещять сенсоры в категориях. (да. их можно перемещать. каждый раз новые детали :)))) со мной не скучно, да? )
и в основном участке кода (то для чего все сделано) хотел просто проходить по одномерному массиву.

но наверно Вы правы. надо бить ао категориям. последний предложенный вариант хорошо подходит. правда он приводтит виду Table[1][2][3] :)))), просто в Вашем примере мы сначала делаем Step=Table[1]; в потом вызываем Step[2][3].


PS с vector никогда не работал. я так понял, что это библиотека реализации списка? сам обычно все пишу. теперь понимаю что зря.

большое спасибо!
вопрос закрою завтра. если есть какие коментрии пишите.

Примечание:
Все. разобался. понял как буду делать.

сделаю базовый класс. как vector, но с большими возможностями. поиск по имени, переброс ячейки в другой элемент. тем более все равно написал его уже :))) не выкидыват же. хотя может и следовало бы. нефиг библиотеки переписывать.

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

кому интересно могу потом кодом поделится. как хороший или плохой пример. сами решите.

Примечание:
EasyPlaton

table[1][2][3] это конечно table[step][category][sensor], причем step, category и sensor перемнные. согласен, что неправильно ставил вопрос. сначала показалось, что это очевидно. сори.

>Уверен, вы знаете что делаете.
спасибо, но не всегда :)))
Ответы:
Оператор () вообще перегружать не советую, если не функтор создаёшь.
«Оптимизаторы оптимизировали, оптимизировали да невыоптимизировали.»
Я обычно делаю два варианта - и 1-й и 3-й
3-й использую внутри библиотек и классов а 1-й в бизнеслогике
Картина от ваших примечаний улучшилась лишь чуть. :)
Основной посыл был в том, что, да, 3й вариант был самый лучший, но идентификаторы были придуманы не самые очевидные, особенно смущает слово table. Второй вариант посередние, но самый ужасный для читабельности это 1й вариант, особенно для структур данных с таким контекстом: одно дело структура полностью состоящая из однотипных объектов, другое дело, когда структура несколько более сложно организованная. К тому же оператор индексирования лучше применять только в том случае, когда это имеет смысл, а именно для последовательно расположенных в памяти объектов, да и для такого случая этот оператор переопределять не обязательно. Имеет смысл, потому что выполняется лишь арифметика над указателем. В случае с двусвязным списком так или иначе (если это не особый, хитрый список) придётся _искать_ элемент с нужным ключом (обычно это номер по порядку), поэтому лучше не заморачиваться и оставлять человеко-читаемые идентификаторы методов извелечения этих элементов и пользоваться ими.
И кстати, у вас двусвязный список из stl (list)? В таком случае рекомендую итераторы. :) Выглядеть это будет может и менее привлекательно, зато работать будет эффективнее:
>со мной не скучно, да? )
да уж, не соскучишься :)


11 лет назад

RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.

Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.

Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.