2009-11-23 3 views
0

Я наткнулся на это.Лучше делать const pass по ссылкам на не-const pass по ссылкам?

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Reference_Arguments#Reference_Arguments

Согласно руководству по стилю, только константные ссылки разрешены в качестве параметров. (Вот что я понял)

Хотя, похоже, мне не нравится этот подход.

Комментарии?

+0

Дубликат: см. Http://stackoverflow.com/questions/1322517/passing-a-modifiable-parameter-to-c-function/1322547#1322547 – ChrisW

ответ

5

Вот несколько правил большого пальца, что может быть полезным при выборе между вашими вариантами:

Если вы сделать не необходимости изменять объект передается в функцию, считают ли от размера объект меньше или равен размеру указателя. Если это так, перейдите по значению; в противном случае, перейдите по ссылке const.

Если вам необходимо изменить объект, передаваемый в функцию, рассмотрите, является ли параметр необязательным (то есть, null является допустимым аргументом). Если да, перейдите по указателю; в противном случае, передать неконстантную ссылку.

6

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

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

Car c; 
foo(c); 

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

void foo(Car c); 
void foo(const Car &c); OR 
void foo(Car &c); 

Теперь рассмотрим

Car c; 
foo(&c); 

Миновав адрес вашего объекта, его легче увидеть (с точки зрения абонентов) или нет функция может изменить свой объект. Разумеется, это не гарантия того, что это так, как может быть указателем на объект const, но с точки зрения рецензентов кода легче обнаружить, что этот объект может быть изменен, поскольку функция передается указателем. Когда предложение Google строго соблюдается, объект, переданный через указатель, всегда будет изменяемым, а все, что не передается через указатель, будет const. (либо по const &, либо b/c пропуска по значению)

Насколько это лучше или не является спорным. Я бы решил, как вы себя чувствуете и будьте последовательны в своей команде.

+0

Хорошее объяснение, но в эпоху сложных IDE, проходящих указатели ради читаемости представляется сомнительной практикой. – Duck

+2

Это практика Google. У них довольно сильные идеи о многом ... например, использование неполных конструкторов и методы 'init' ... Иногда мне кажется, что они программируются на C или C++ –

1

также позволяет, что вы можете сделать

недействительных х (константный зЬм :: String & х)

х ("привет");

без const это не сработает.

+1

Почему бы и нет? Я не понимаю, что вы получаете, можете ли вы расширить это? –

+0

@Newton Falls: Я думаю, что он означает сказать, что «временные значения rvalues ​​не могут быть связаны с непостоянными ссылками» –

1

Это предпочтение, как я могу сказать, что это предпочтение:

void align_left(); 
// vs. 
void alignLeft(); 

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

t_result getDate(t_string& outString) const; 

Название указывает на мутацию. Это может быть немного обманчиво, если вы очень редко проходите по ссылке в своей кодовой базе, но в конечном итоге «отлично» и имеет достаточно положительные последствия. Что касается стиля, многие из них возвращаются к последовательности. Поскольку программы действительно расширяются (IMO), это может действительно помочь - просто убедитесь, что цель вашей программы понятна, и стиль согласован (по крайней мере, вы хотите читать документы стиля, прежде чем писать огромную базу кода).

Смежные вопросы