Я писал программу, которая имеет довольно большую структуру, которая передается по ссылке на несколько функций. Однако есть несколько других функций, которым необходим доступ к небольшим частям информации в большой структуре. Это не редактируется, просто прочитайте.
Мой вопрос начинается здесь. Я думал о создании второй структуры, которая просто копирует конкретные части необходимой информации и передает ее по ссылке, а не передает всю структуру по ссылке.
Что мне интересно, так это две вещи:
1) Поскольку я передаю большую структуру по ссылке, это не влияет на производительность. Правильный?
2) Даже если 1) правильно, плохой этикет — обходить структуру, которая не должна редактироваться (даже если она не будет редактироваться, но все же я говорю о принципе здесь).
Более конкретно:
У меня есть структура конфигурации, которая устанавливает конфигурацию программ, вызывая функцию и передавая структуру по ссылке. Есть некоторая информация (имя процесса, аргументы командной строки), которую я хочу использовать только в ознакомительных целях. Я спрашиваю, будет ли плохой практикой обходить структуру, которая не предназначена для того, для чего я хочу ее использовать.
1) Поскольку я передаю большую структуру по ссылке, это не влияет на производительность. Правильный?
Правильный.
2) Даже если 1) правильно, плохой этикет — обходить структуру, которая не должна редактироваться (даже если она не будет редактироваться, но все же я говорю о принципе здесь).
Вы можете позволить своей функции принять ссылку на const
чтобы убедиться, что функция не изменит состояние соответствующего аргумента.
Я спрашиваю, будет ли плохой практикой обходить структуру, которая не предназначена для того, для чего я хочу ее использовать.
Я не уверен, что вы подразумеваете под этим. То, как ты это пишешь, определенно кажется плохой практикой: ты не должен использовать что-то для того, для чего он не предназначен. Это означает искажение семантики объекта. Тем не менее, остальная часть вашего вопроса не подразумевает этого.
Скорее, похоже, что вы обеспокоены передачей ссылки на функцию, потому что это может позволить функции изменять состояние аргумента; но при условии, что функция принимает ссылку на const
, он не сможет изменить состояние своего аргумента. В таком случае, нет, это не плохая практика.
Если вы имеете в виду тот факт, что функция должна работать только с немного членов данных или функций-членов вашей структуры, опять же, это не обязательно плохой дизайн. Было бы глупо требовать, чтобы каждая функция обращалась каждый член структуры данных.
Конечно, это лучшее, что я могу написать, не зная ничего конкретного о семантике функции и конкретной структуре данных.
Правильный.
Передайте это мимо const
ссылка; Вы получите прирост производительности при передаче по ссылке без возможности редактирования.
Кстати, если для этой функции требуется только часть «большой структуры», это может быть индикатором того, что такие поля хранят некоторую информацию «сами по себе», т. Е. Остальная часть «большой структуры» не требуется для интерпретации. их правильно. В этом случае вы можете рассмотреть вопрос о перемещении их в отдельный struct
, который сам будет членом первой «большой структуры».
В качестве следующего шага вы можете хранить такие объекты конфигурации в общем указателе и передавать его в любое место, так что вам не нужно беспокоиться о принадлежности структуры. Таким образом вы гарантируете, что один исходный объект конфигурации является общим для всех компонентов программы.
Как уже говорили другие, используйте const.
Если вы делаете C ++, получите доступ к этим небольшим частям информации с помощью функций доступа. Тогда функциям, которым не нужно изменять состояние вашей структуры, не нужно будет прикасаться к полям-членам, только к функциям-членам.
Как уже упоминали другие, const&
если вы не изменяете данные.
Тем не менее, ваша точка зрения о «я должен скопировать данные в меньший struct
«в основном затушевано. Ответ» возможно «.
Хорошая причина не делать этого — то, что это пустая трата времени — буквально, это стоит времени, чтобы копировать вещи вокруг.
Хорошая причина сделать это состоит в том, что это уменьшает эффективное состояние вашей подпроцедуры. Подпроцедура, которая не имеет доступа к глобальным переменным (и, следовательно, к глобальному состоянию) и не имеет указателей, имеет очень ограниченное состояние. Процедуры с ограниченным состоянием легче тестировать, часто легче понять и, как правило, легче отлаживать.
Часто вы хотите вызывать каждую функцию с абсолютным наименьшим количеством данных, необходимых для этой функции, чтобы решить возникшую проблему. Если вы избегаете передачи «указателя на все» (а ссылки являются указателями) на каждую функцию, вы можете сохранить это правило, и это может часто приводить к коду, который легче поддерживать.
С другой стороны, извлечение данных из большого монолитного состояния в небольшие локальные struct
s может содержать ошибки и ошибки.
Один из способов полностью избежать этой проблемы — избежать большого монолитного объекта состояния со всеми параметрами, смешанными вместе, и если есть некоторые параметры, которые объединены вместе, чтобы ответить на некоторые вопросы, они должны быть в своих собственных подчиненныхstruct
начать с. Теперь вызвать подпроцедуру легко — вы переходите в подпрограммуstruct
который уже имеет параметры в комплекте.