Они же написали внизу, почему. Они должны поддерживать существующий код, не обеспечивающий exception safety. И в этом они правы: исключения нужно использовать или везде, или нигде.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, eao197, Вы писали:
E>>
E>>Exceptions
E>>▶ We do not use C++ exceptions.
E>>Сурово.
RO>Они же написали внизу, почему. Они должны поддерживать существующий код, не обеспечивающий exception safety. И в этом они правы: исключения нужно использовать или везде, или нигде.
Здравствуйте, Roman Odaisky, Вы писали:
RO> Они должны поддерживать существующий код, не обеспечивающий exception safety. И в этом они правы: исключения нужно использовать или везде, или нигде.
Если исключения не начать использовать, то количество существующего кода, не обеспечивающего exception safety будет расти постоянно.
Ну это так, ответил банальностью на банальность. Сам я жалею, что в нескольких проектах лет шесть-семь назад не начал использовать исключений. Это была большая ошибка.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, night beast, Вы писали:
RO>>Я не доверяю гайдам, которые пишут «const string &in».
NB>ну вот, начинается :) NB>щас кто-нибудь не согласится, и понеслась...
Разве ты не видишь в этом ни одной — объективной — ошибки?
Здравствуйте, Roman Odaisky, Вы писали:
RO>>>Я не доверяю гайдам, которые пишут «const string &in».
NB>>ну вот, начинается NB>>щас кто-нибудь не согласится, и понеслась...
RO>Разве ты не видишь в этом ни одной — объективной — ошибки?
я такой стиль не применяю, но если дать компилятору эту строку, он ее скомпилирует.
значит объективных ошибок нет.
Здравствуйте, night beast, Вы писали:
RO>>>>Я не доверяю гайдам, которые пишут «const string &in». NB>>>ну вот, начинается :) NB>>>щас кто-нибудь не согласится, и понеслась... RO>>Разве ты не видишь в этом ни одной — объективной — ошибки?
NB>я такой стиль не применяю, но если дать компилятору эту строку, он ее скомпилирует. NB>значит объективных ошибок нет.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, night beast, Вы писали:
RO>>>>>Я не доверяю гайдам, которые пишут «const string &in». NB>>>>ну вот, начинается NB>>>>щас кто-нибудь не согласится, и понеслась... RO>>>Разве ты не видишь в этом ни одной — объективной — ошибки?
RO>Не ошибок компиляции, а стилевых.
Главное — не забывать, что этот документ (как и все документы подобного рода) пишется, исходя из конкретной ситуации, в которой находились писавшие, поэтому слепо брать подобные документы в свой проект просто потому, что это Google/MS/whatever, нельзя, потому что в твоем проекте ситуация наверняка будет другая.
Здравствуйте, Roman Odaisky, Вы писали:
RO>>>Разве ты не видишь в этом ни одной — объективной — ошибки?
NB>>я такой стиль не применяю, но если дать компилятору эту строку, он ее скомпилирует. NB>>значит объективных ошибок нет.
RO>Не ошибок компиляции, а стилевых.
Как стилевая ошибка может претендовать на объективность?!
E>Сурово.
+1
Интересно, а как они с RAII при этом рабоьают? Неудобно же.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Alxndr, Вы писали:
RO>>>>Я не доверяю гайдам, которые пишут «const string &in». A>[] RO>>Разве ты не видишь в этом ни одной — объективной — ошибки? A>"Объективной" -- ну, я не вижу :???:
Если хорошо подумать, то единственный правильный способ написать это — «std::string const& in».
Потому что:
1. «std::» — надеюсь, понятно.
2. const справа позволяет избежать непонимания в случае «const T @ @ something», где «@» — «*» или «&». Сам видел «const T* &something». Что хотели написать и что получилось? То ли дело «T const* & something» или «T * const& something».
3. Приклеивать «*» и «&» к имени — глупо. Ясно, что с обоими пунктуаторами нужно поступать одинаково, но, в то время как «X *x» еще имеет смысл («*x имеет тип X»), запись «X &x» его лишена. Так что «X* x» и «X& x». Пробелы с обеих сторон, как правильно заметили, придают объявлению вид выражения:
template <class Archive>
void serialize(Archive& archive, unsigned const version)
{
archive & m_something; // это что?
Archive & oops; // а вот это?
}
Пробелы разве что полезны тогда, когда объявление многоуровневое, вроде X * const* * * const* * x. (А typedef еще полезнее. :-)
Так что «std::string const& in». Оно и читается удобнее, когда самое важное находится по краям строки, но это уже субъективно. Вроде такого:
ns::foo s = getSomeFoo();
ns::bar t;
ns2::quux u;
const ns::foo v = getSomeFoo()
const ns2::bar w = getSomeBar()
ns::quux x = getSomeQuux();
ns2::quuux y;
ns2::quuuux z = getSomeQuuuux();
Здесь, по-моему, const только отвлекают внимание.
ns::foo s = getSomeFoo();
ns::bar t;
ns2::quux u;
ns::foo const v = getSomeFoo()
ns2::bar const w = getSomeBar()
ns::quux x = getSomeQuux();
ns2::quuux y;
ns2::quuuux z = getSomeQuuuux();
Здравствуйте, Alxndr, Вы писали:
A>Как стилевая ошибка может претендовать на объективность?!
Легко. Если есть несколько стилевых решений, и в среднем (по ситуациям/программистам) одно ведет к большему количеству ошибок читающего/исправляющего код, чем другие, то оно является объективной стилевой ошибкой.
Обычно этот критерий можно свести к количественному такому: "О скольких закоулках синтаксиса должен помнить человек, чтобы без ошибок понимать данный код?" Этот критерий проще, но исключает факторы типа визуального шума и графической похожести, которые могут замазать ошибку/опечатку (например, f(1) всегда должно быть вызовом с аргументом единица, а не с переменной l-маленькое).
Похожий критерий: "сколькими способами можно трактовать данный код?" Тот код, который дает меньший простор воображению, также является стилистически лучшим.
Здравствуйте, Erop, Вы писали:
E>Интересно, а как они с RAII при этом рабоьают? Неудобно же.
Надо полагать, что они практикуют двух-фазную инициализацию объектов. Простой конструктор + все действия в методе Init(), который уже возвращает код ошибки.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Alxndr, Вы писали:
RO>>>>Разве ты не видишь в этом ни одной — объективной — ошибки? NB>>>я такой стиль не применяю, но если дать компилятору эту строку, он ее скомпилирует. NB>>>значит объективных ошибок нет. RO>>Не ошибок компиляции, а стилевых.
A>Как стилевая ошибка может претендовать на объективность?!
