Здравствуйте, Roman Odaisky, Вы писали:
RO>>>>>Я не доверяю гайдам, которые пишут «const string &in». A>>[] RO>>>Разве ты не видишь в этом ни одной — объективной — ошибки? A>>"Объективной" -- ну, я не вижу
RO>Если хорошо подумать, то единственный правильный способ написать это — «std::string const& in».
Роман, если хорошо подумать, то все "единственно правильные способы" идут нафиг, оставляя без внимания возможные "доказательства".
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Roman Odaisky, Вы писали:
RO>> Они должны поддерживать существующий код, не обеспечивающий exception safety. И в этом они правы: исключения нужно использовать или везде, или нигде.
E>Если исключения не начать использовать, то количество существующего кода, не обеспечивающего exception safety будет расти постоянно.
E>Ну это так, ответил банальностью на банальность. Сам я жалею, что в нескольких проектах лет шесть-семь назад не начал использовать исключений. Это была большая ошибка.
А вариантов, кроме переписывания старого кода и отлова всех исключений на границах, в общем-то, нет никаких.
Здравствуйте, Roman Odaisky, Вы писали:
RO>2. const справа позволяет избежать непонимания в случае «const T @ @ something», где «@» — «*» или «&». Сам видел «const T* &something». Что хотели написать и что получилось? То ли дело «T const* & something» или «T * const& something».
В чем разница между "const T * &" и "T const * &"?
RO>3. Приклеивать «*» и «&» к имени — глупо. Ясно, что с обоими пунктуаторами нужно поступать одинаково, но, в то время как «X *x» еще имеет смысл («*x имеет тип X»), запись «X &x» его лишена.
Глупо приколупываться к подобным мелочам и уделять им столь повышенное внимание.
RO>Так что «std::string const& in». Оно и читается удобнее, когда самое важное находится по краям строки, но это уже субъективно. Вроде такого: RO>
RO>ns::foo s = getSomeFoo();
RO>ns::bar t;
RO>ns2::quux u;
RO>const ns::foo v = getSomeFoo()
RO>const ns2::bar w = getSomeBar()
RO>ns::quux x = getSomeQuux();
RO>ns2::quuux y;
RO>ns2::quuuux z = getSomeQuuuux();
RO>
Здесь, по-моему, const только отвлекают внимание.
RO>
RO>ns::foo s = getSomeFoo();
RO>ns::bar t;
RO>ns2::quux u;
RO>ns::foo const v = getSomeFoo()
RO>ns2::bar const w = getSomeBar()
RO>ns::quux x = getSomeQuux();
RO>ns2::quuux y;
RO>ns2::quuuux z = getSomeQuuuux();
RO>
А вот так куда лучше.
А по моему все с точностью до наоборот.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, jazzer, Вы писали:
A>>Как стилевая ошибка может претендовать на объективность?!
J>Легко. Если есть несколько стилевых решений, и в среднем (по ситуациям/программистам) одно ведет к большему количеству ошибок читающего/исправляющего код, чем другие, то оно является объективной стилевой ошибкой.
Даже в этом случае стиль, "лучший" с этой точки зрения для одной группы программистов, может привести, к примеру, к меньшей эффективности другой — например, более опытной группы.
Здравствуйте, Alxndr, Вы писали:
A>Здравствуйте, jazzer, Вы писали:
A>>>Как стилевая ошибка может претендовать на объективность?!
J>>Легко. Если есть несколько стилевых решений, и в среднем (по ситуациям/программистам) одно ведет к большему количеству ошибок читающего/исправляющего код, чем другие, то оно является объективной стилевой ошибкой.
A>Даже в этом случае стиль, "лучший" с этой точки зрения для одной группы программистов, может привести, к примеру, к меньшей эффективности другой — например, более опытной группы.
Здравствуйте, jazzer, Вы писали:
J>>>Легко. Если есть несколько стилевых решений, и в среднем (по ситуациям/программистам) одно ведет к большему количеству ошибок читающего/исправляющего код, чем другие, то оно является объективной стилевой ошибкой.
A>>Даже в этом случае стиль, "лучший" с этой точки зрения для одной группы программистов, может привести, к примеру, к меньшей эффективности другой — например, более опытной группы.
J>конь о четырех ногах, сам знаешь
Так и "сдуру" можно такое поломать, что никакие "объективно лучшие" (по вышеописанному критерию) стили не спасут.
Здравствуйте, jazzer, Вы писали:
E>>Интересно, а как они с RAII при этом рабоьают? Неудобно же. J>А RAII никуда не делась. Просто вместо исключений
Да ясно, что никуда не делось. Но ведь правда неудобно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Roman Odaisky, Вы писали:
RO>Если хорошо подумать, то единственный правильный способ написать это — «std::string const& in».
RO>Потому что: RO>1. «std::» — надеюсь, понятно.
Согласен.
RO>2. const справа позволяет избежать непонимания в случае «const T @ @ something», где «@» — «*» или «&». Сам видел «const T* &something». Что хотели написать и что получилось? То ли дело «T const* & something» или «T * const& something».
Согласен.
RO>3. Приклеивать «*» и «&» к имени — глупо. Ясно, что с обоими пунктуаторами нужно поступать одинаково, но, в то время как «X *x» еще имеет смысл («*x имеет тип X»), запись «X &x» его лишена. Так что «X* x» и «X& x».
Не согласен с выделенным — не глупо, а дело вкуса. Я, к примеру, пишу именно так ("X &x"), поскольку, как гласит буква Стандарта:
8.3.1 Pointers
1 In a declaration T D where D has the form
* cv-qualifier-seqopt D1
and the type of the identifier in the declaration T D1 is “derived-declarator-type-list T,” then the type of the identifier of D is “derived-declarator-type-list cv-qualifier-seq pointer to T.”
Или, другими словами, '*' и '&' являются частью D ("*x"), а не T ("X"), а в Вашей записи выглядит все наоборот Да и вот сразу пример из стандарта (8.3.1/2), где по другому и не напишешь:
const int ci = 10, *pc = &ci, *const cpc = pc, **ppc;
int i, *p, *const cp = &i;
Конечно же, несколько объявлений на одной строке — то еще зло, но все-таки
Names and Order of Includes
▶ Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries' .h, your project's .h.
Забавно. Обычно, для избегания скрытых зависимостей рекомендуют как раз противоположный порядок включения заголовков.
The last good thing written in C was Franz Schubert's Symphony No. 9.
Лично мне Air Vehicle C++ Coding Standards пока что кажется наиболее вменяемым (из того, что я видел, естественно).
Опять таки, бесполезно листать его, не учитывая предметную область (hard real-time, avionics).
[]
RO>Ты же не споришь, что приведенный выше вариант — множественно неправильный?
Лично я — не спорю.
У меня просто идиосинкрозия на "объективность" и "единственно правильность".
Надеюсь, в том примере выше ты просто пошутил (и, на всякий случай, — да, я сам сторонник std::string const& in).
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
E>>>Интересно, а как они с RAII при этом рабоьают? Неудобно же. J>>А RAII никуда не делась. Просто вместо исключений E>Да ясно, что никуда не делось. Но ведь правда неудобно
неудобно, но все же лучше, чем в какой-нть джаве, где исключения есть, а RAII нет
Здравствуйте, Roman Odaisky, Вы писали:
RO>Если хорошо подумать, то единственный правильный способ написать это — «std::string const& in».
В общем случае может быть, а в случае аргумента функции const std::string& мне кажется более правильным — это устоявшаяся форма записи, которая, во-первых, широко применяется, а во-вторых, хотя это возможно связано с предыдущим, это легче читать. Обычно люди все-таки читают слева-направо и, взглянув на объявление, особенно с подсвеченным в IDE const, сразу видно, что это in параметр.
Вообще, мне этот гайд понравился. Это как с ПДД, которые, как известно, написаны кровью. Здесь похоже случай близкий — достаточно, например, попытаться портировать проекты с исключениями или rtti на платформы, где их нет или где они работают криво =)
Здравствуйте, eao197, Вы писали:
E>Глупо приколупываться к подобным мелочам и уделять им столь повышенное внимание.
Думаю, что возьму это и включу самым жирнейшим шрифтом в наши coding conventions.
А то есть тут за соседним столом один кадр, который уделяет повышенное внимание отделению знаков == и = пробелами от аргументов. Ни одного не пропустит, но при этом в код постоянно пролезает такой очевидный ужас, что становится страшно.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, eao197, Вы писали:
E>>
E>>Exceptions
E>>▶ We do not use C++ exceptions.
E>>Сурово.
RO>Они же написали внизу, почему. Они должны поддерживать существующий код, не обеспечивающий exception safety. И в этом они правы: исключения нужно использовать или везде, или нигде.
Нифига. Нужно просто суметь определить границу между кодом, использующим исключения и не использующим. Такой границей может быть, например, экспортируемые из DLL наружу функции.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, eao197, Вы писали:
E>>Глупо приколупываться к подобным мелочам и уделять им столь повышенное внимание.
L>Думаю, что возьму это и включу самым жирнейшим шрифтом в наши coding conventions.
L>А то есть тут за соседним столом один кадр, который уделяет повышенное внимание отделению знаков == и = пробелами от аргументов. Ни одного не пропустит, но при этом в код постоянно пролезает такой очевидный ужас, что становится страшно.
судя по твоим словам, ты еще не читал книжку саттера-александреску по поводу стайл гайдов — рекомендую, там как раз одним их первых пунктов идет "не приколупывайтесь к мелочам!" (ну, может, глагол другой немножко )
Да и вот сразу пример из стандарта (8.3.1/2), где по другому и не напишешь:
