Здравствуйте, flаt, Вы писали:
M>>Суффикс "_m" используется у Микрософта для членов классов с любой видимостью. Тот же WTL, да и MFC вроде тоже
F>Только не суффикс, а префикс, и не "_m", а "m_"
Ну да, не "Волгу", а сто рублей, не выиграл, а проиграл
Я уже пару лет в WTL не заглядывал, подзабыл что там как
Здравствуйте, __kot2, Вы писали:
__>вообще, кстати, в хромиуме еще очень странно выглядит использование паскалевского именования. правда, не всегда, но это выглядит еще более странным
Гугловский стиль гласит:
— примитивные функции, особенно инлайновые, (и изредка — неинлайновые геттеры-сеттеры для единообразия с соседними инлайновыми членами) пишутся в змеином_виде
— неинлайновые функции — пишутся в ПаскалевомВиде (они называют это верблюжим, но какой же это верблюжийВид, если с заглавной буквы)
— инлайновыми можно делать только те функции, которые не виртуальные и чьё тело укладывается в одну строчку
Здравствуйте, __kot2, Вы писали:
__>вообще, на самом деле к оечно придирабс и хромиум — один из лучших проектов на С++.
Лучший, но тем внезапнее видеть такие косяки.
На самом деле, если задаться целью, то выловить можно много косяков.
Но хромовская политика чистоты кода — начиная с чистоты стиля — делает своё светлое дело.
__> есть такой мрак, что прямо кровь из глаз течет и ничего — пользуются люди. но если придираться, то я мое ревью бы на Point.h выглядело бы так:
__>constexpr Point() : x_(0), y_(0) {} - нафиг constexpr. что он дает?
Во-первых, это такое поветрие, переезжать на C++14.
Во-вторых, это позволяет писать constexpr-функции, которые внутри занимаются геометрическими расчётами.
__> constexpr Point(int x, int y) : x_(x), y_(y) {} - зачем два конструктора, когда одного достаточно с дефолтными параметрами?
А вот это — нафиг-нафиг! Ты же не можешь сделать функцию, у которой либо-ноль-либо-два параметра.
Получается, невольно разрешишь запись Point(x), которая обозначает Point(x,0). Кому-то специально нужны точки с нулевой ординатой?
Да ещё и без explicit, это вообще незащищённый секс.
__> constexpr int x() const { return x_; } - убрать нафиг эти методы, сделать члены x и y публичными
__> constexpr int y() const { return y_; }
Единообразие с другими геометрическими классами, особенно — с прямоугольником. Иначе было бы rect.width и rect.right() либо rect.width() и rect.right.
Наркомания с групповым сеттером — какое-то легаси. Может быть, делалось для единообразия с подобными модификаторами прямоугольников и инсетов, так и осталось.
__>почему паскалевское именование в С++ проекте?
По нормативам. Змеи для инлайнов, паскали для громоздкого.
__> void SetToMin(const Point& other); - непонятная фигня. почему это метод класса Point?
Фигня как раз понятная, — нахождение левой верхней точки, например, при объединении и пересечении прямоугольников.
Почему не в виде функции LeftTopMost(const Point& a, const Point& b) — это легаси наркомания.
Здравствуйте, Кодт, Вы писали: К>Но хромовская политика чистоты кода — начиная с чистоты стиля — делает своё светлое дело.
в принципе, из публичных code style гугловский и правда самый вменяемый. конечно, смущает, что они не осилили исключения и по мелочам, но в общем он лучше остальных
К>А вот это — нафиг-нафиг! Ты же не можешь сделать функцию, у которой либо-ноль-либо-два параметра. К>Получается, невольно разрешишь запись Point(x), которая обозначает Point(x,0). Кому-то специально нужны точки с нулевой ординатой? К>Да ещё и без explicit, это вообще незащищённый секс.
да, согласен. это аргумент делать два конструктора. я лично в совсем небольшом проекте предпочту один (вдруг добавлю новое поле и проинициализировую только в одном конструкторе, про второй забуду — такое бывало), но при работе нам большим проектом большой командой лучше иметь два
я, кстати, видел где-то пример кода в стиле
struct S
{
int x = 10;
};
это часть нового стандарта? какого именно? или это для простоты обсуждения было?
К>Единообразие с другими геометрическими классами, особенно — с прямоугольником. Иначе было бы rect.width и rect.right() либо rect.width() и rect.right.
ну, это тоже как бы, повод для обсуждения
можно, например rect представить в виде пары pos, dimensions — соотв-но pos будет Point. то есть будет r.pos.x — не нужно городить единообразие, оно натуральным образом возникает. но, возможно, в некоторых случаях стоит иметь какие-то соглашения насчет x() и y(), хотя логичнее иметь скорее соглашение насчет pos()
К>По нормативам. Змеи для инлайнов, паскали для громоздкого.
странные нормативы. скорее всего написаны C# товарищами. по ходу пришли из попыток присобачить проперти к С++. надо было им лучше плюсовиков найти для написания style guide
К>Фигня как раз понятная, — нахождение левой верхней точки, например, при объединении и пересечении прямоугольников.
а я вот не догадался
К>Почему не в виде функции LeftTopMost(const Point& a, const Point& b) — это легаси наркомания.
так незачем поощрять наркоманию, даже если это легаси! надо быть сразу бить палкой тому, кто это добавил. явно же не с начала в классе было
Здравствуйте, __kot2, Вы писали:
__>точнее даже так — __kot2 это нормальный идентификатор в С++?
По рукам бить
Each name that contains a double underscore __ or begins with an underscore followed by an uppercase
letter (2.12) is reserved to the implementation for any use.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали: Ops>По рукам бить Ops>
Ops>Each name that contains a double underscore __ or begins with an underscore followed by an uppercase
Ops>letter (2.12) is reserved to the implementation for any use.
вот тут та же система — ник kot на всех форумах занят, а __kot — свободен и зарезервирован специально для меня
Здравствуйте, PM, Вы писали:
PM>Ещё странно, что гугловцы выбрали путь дублирования кода и наделали пар Point/PointF, Size/SizeF и т.п. вместо шаблонов.
Это не странно. Гугловцы настойчиво любят пихать функции в отдельные единицы компиляции, чтобы уменьшить распухание экзешника и избежать ада статических переменных при компонентной сборке.
У них, например, недавно был приступ паранойи — явно забанить все конструкторы, генерируемые компилятором.
Здравствуйте, Кодт, Вы писали:
PM>>Ещё странно, что гугловцы выбрали путь дублирования кода и наделали пар Point/PointF, Size/SizeF и т.п. вместо шаблонов.
К>Это не странно. Гугловцы настойчиво любят пихать функции в отдельные единицы компиляции, чтобы уменьшить распухание экзешника и избежать ада статических переменных при компонентной сборке.
К>У них, например, недавно был приступ паранойи — явно забанить все конструкторы, генерируемые компилятором. К>
К>С шаблонами такой фокус, ясное дело, не провернёшь.
К>И обратите внимание на то, что Point сотоварищи имеет атрибут GFX_EXPORT — это старый добрый __declspec(dllexport) из модуля gfx.dll
А разве explicit instantiation в .cc файле не сработает? Типа такого:
// .hpptemplate<typename T>
struct PointT
{
T x = {};
T y = {};
PointT();
PointT(T x, T y);
};
using Point = PointT<int>;
using PointF = PointT<float>;
// declare explicit instantiationextern template PointT<int>;
extern template PointT<float>;
// .cpptemplate<typename T>
struct PointT<T>::PointT() = default;
template<typename T>
struct PointT<T>::PointT(T x, T y) : x(x), y(y) {}
// define explicit instantiationtemplate PointT<int>;
template PointT<float>;
Здравствуйте, PM, Вы писали:
К>>С шаблонами такой фокус, ясное дело, не провернёшь. К>>И обратите внимание на то, что Point сотоварищи имеет атрибут GFX_EXPORT — это старый добрый __declspec(dllexport) из модуля gfx.dll PM>А разве explicit instantiation в .cc файле не сработает? Типа такого:
Сработает, наверно (?). Но гугл пошёл другим путём.
Надо поизучать, как атрибуты экспорта накладываются на явное воплощение шаблонов. Может быть, у gcc и VC есть расхождения в этих делах, и поэтому гугловцы решили не наступать на тонкий лёд.
Кодт:
К>>>И обратите внимание на то, что Point сотоварищи имеет атрибут GFX_EXPORT — это старый добрый __declspec(dllexport) из модуля gfx.dll PM>>А разве explicit instantiation в .cc файле не сработает? Типа такого:
К>Сработает, наверно (?).
Работать-то оно будет, но вот мне интересно другое: какая экономия размера бинарника может получиться за счёт форсирования реального вызова функции, которая проста, как две копейки?
Перекуём баги на фичи!
