К> Базовая библиотека геометрии, всё просто и понятно, пастораль и идиллия...
согласно педивикии пастораль выглядит так: https://ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%81%D1%82%D0%BE%D1%80%D0%B0%D0%BB%D1%8C#/media/File:Fiesta_campestre.jpg
так что все нормально
К> constexpr Rect(int x, int y, int width, int height) К> constexpr Insets() : top_(0), left_(0), bottom_(0), right_(0) {}
Вместо x/y/width/height стали юзать top/left/bottom/right? Порядок аргументов придает особую пикантность.
Как много веселых ребят, и все делают велосипед...
O>>вместо x/y/width/height стали юзать left/top/right/bottom? К>вместо x/y стали юзать TOP / LEFT. К>а вместо width/height — vertical/horizontal, соответственно
да перевернутый порядок я позже приметил и подредактировал мессагу
Как много веселых ребят, и все делают велосипед...
Здравствуйте, IID, Вы писали:
IID>Длинный (в символах) список инициализации порезали по строкам. А короткий не порезали. IID>Неаккуратненько ?
особенности хромовского стайлгайда (макс. 80 символов в строке), плюс неудачно длинные идентификаторы аргументов.
это неважно, важно — какие там аргументы.
Здравствуйте, Кодт, Вы писали:
O>>вместо x/y/width/height стали юзать left/top/right/bottom? К>вместо x/y стали юзать TOP / LEFT. К>а вместо width/height — vertical/horizontal, соответственно
Так это ж insets, у них ну ладно ещё x/y (вместо left/top, а что писать вместо right/bottom?), но width/height у них точно нет.
Николай, не очень понял
Разные классы, разные свойства, названия тоже разные, вполне отражающие смысл.
Здравствуйте, Кодт, Вы писали:
К>Уважаемые знатоки! Как вы думаете, почему я обратил на это внимание?
Ни разу не знаток, но попробую:
0. Зачем Insets? У него какие-то отличные от Rect свойства есть?
1. Не последовательное применение explicit
2. У Insets нет конструктора который принимает Point, Rect.
3. Дефолтный конструктор Rect не инициализирует переменные, а Point, Size и Insets — инициализирует нулями.
Здравствуйте, Skorodum, Вы писали:
К>>Уважаемые знатоки! Как вы думаете, почему я обратил на это внимание? S>0. Зачем Insets? У него какие-то отличные от Rect свойства есть?
Примерно все. Два можно притянуть за уши к x и y у rect'а.
S>2. У Insets нет конструктора который принимает Point, Rect.
Каков физический (в данном случае — геометрический) смысл такого конструктора?
S>3. Дефолтный конструктор Rect не инициализирует переменные, а Point, Size и Insets — инициализирует нулями.
Rect состоит из Point и Size — для них вызываются дефолтные конструкторы.
Здравствуйте, Dair, Вы писали:
D>Примерно все. Два можно притянуть за уши к x и y у rect'а.
Понял уже, и имена параметров вполне преднамеренно сделаны такими.
S>>2. У Insets нет конструктора который принимает Point, Rect. D>Каков физический (в данном случае — геометрический) смысл такого конструктора?
Ну я это написал под впечатлением комментария Кодта
, теперь думаю, что он немного неправильно понял смысл класса Insets.
S>>3. Дефолтный конструктор Rect не инициализирует переменные, а Point, Size и Insets — инициализирует нулями. D>Rect состоит из Point и Size — для них вызываются дефолтные конструкторы.
Если так, то согласен, но этого не видно по приведенному коду.
D>Так это ж insets, у них ну ладно ещё x/y (вместо left/top, а что писать вместо right/bottom?), но width/height у них точно нет. D>Николай, не очень понял
Основной прикол в том что ордината идете впереди абсцисс, пардон май френч.
constexpr Insets(int top, int left, int bottom, int right)
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Кодт, Вы писали:
К>Уважаемые знатоки! Как вы думаете, почему я обратил на это внимание?
//
// An insets represents the borders of a container (the space the container must
// leave at each of its edges).
//
Единственная странность, это то, что у них порядок не как в CSS (top, right, bottom, left), а совсем наоборот. Может им так удобнее, но в общем он не имеет значения для структуры, которая описывает insets.
Здравствуйте, Skorodum, Вы писали:
S>Там скорее всего top, left, bottom, right — это смещения, которые будут применены к какой-то центральной точке. Тогда все выглядит логично
Здравствуйте, Dair, Вы писали:
D>Разные классы, разные свойства, названия тоже разные, вполне отражающие смысл.
Insets — это прямоугольник наоборот. Пачка координат для описания отступов от края прямоугольника.
И эти классы все взаимодействуют, а не просто так лежат в одной папке.
class Rect {
. . .
// Shrink the rectangle by the given insets.void Inset(const Insets& insets);
// Shrink the rectangle by the specified amount on each side.void Inset(int left, int top, int right, int bottom);
// Move the rectangle by a horizontal and vertical distance.void Offset(int horizontal, int vertical);
void Offset(const Vector2d& distance) { Offset(distance.x(), distance.y()); }
void operator+=(const Vector2d& offset);
void operator-=(const Vector2d& offset);
Insets InsetsFrom(const Rect& inner) const;
. . .
Как видно, во второй сигнатуре аргументы идут в естественном порядке.
Там ещё есть класс смещений, Vector2D, — чтобы случайно не смешивать вектор точки, вектор размера и вектор смещения.
К>Как видно, во второй сигнатуре аргументы идут в естественном порядке.
Я так подозреваю оно и с Inset юзается во многих местах в естественном порядке. В конце концов это лишь названия переменных) Буду удивлен если это не так..
Как много веселых ребят, и все делают велосипед...
К>>Уважаемые знатоки! Как вы думаете, почему я обратил на это внимание? С>Потому что шутки на С++ доступны только Кодту. Остальные такого уровня просветления не достигли.
Остальным доступен лишь пошлый юмор про то как во время секса приезжает сборщик мусора и требут выкинуть презерватив..
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, ononim, Вы писали:
O>>вместо x/y/width/height стали юзать left/top/right/bottom?
К>вместо x/y стали юзать TOP / LEFT. К>а вместо width/height — vertical/horizontal, соответственно
Да, как тут когда-то писали — это неполиткорректно. Правильно dimension1, dimension2...
Здравствуйте, ononim, Вы писали:
D>>Так это ж insets, у них ну ладно ещё x/y (вместо left/top, а что писать вместо right/bottom?), но width/height у них точно нет. D>>Николай, не очень понял O>Основной прикол в том что ордината идете впереди абсцисс, пардон май френч.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Кодт, Вы писали: К>>Базовая библиотека геометрии, всё просто и понятно, пастораль и идиллия... __>подчеркивания в членах класса — фуу
Мне тоже не нравится, особенно в конце, но у каждого свой coding style, и это уже религиозный вопрос
Здравствуйте, Dair, Вы писали: D>Мне тоже не нравится, особенно в конце, но у каждого свой coding style, и это уже религиозный вопрос
разумеется. просто предпочитаю не иметь чего-то, чем иметь что-то лишнее, непонятно зачем нужное. а то попахивает "C" перед именами классов
Здравствуйте, __kot2, Вы писали:
__>ну и сама реализация класса тоже спорная. я бы лично оставил x и y публичными, чем городить геттеры-сеттеры к ним
У прямоугольника это связано с тем, что его можно хранить как {left,top,right,bottom} или {left,top,width,height}, — поэтому либо одни, либо другие величины будут доступны только через геттер.
А если всё через геттер — то это единообразие.
Здравствуйте, Dair, Вы писали:
D>Здравствуйте, __kot2, Вы писали: __>>подчеркивания в членах класса — фуу
D>Мне тоже не нравится, особенно в конце, но у каждого свой coding style, и это уже религиозный вопрос
Но зачем в членах класса? Я тоже иногда их использую, когда аргументы конструктора/метода по смыслу совпадают с членами класса. Тогда использую подчеркивания для аргументов, так как аргументы — в одном месте, а для членов класса их везде таскать придется. Да, я знаю, что компилятор (в случае конструктора, как минимум) сам разберется, но парсить глазами всё равно неудобно, поэтому и добавляю
Здравствуйте, Кодт, Вы писали: К>У прямоугольника это связано с тем, что его можно хранить как {left,top,right,bottom} или {left,top,width,height}, — поэтому либо одни, либо другие величины будут доступны только через геттер.
тогда логично хранить {left,top,right,bottom} и иметь методы width() и height()
К>А если всё через геттер — то это единообразие.
все сделано через геттеры
Здравствуйте, Marty, Вы писали: M>Но зачем в членах класса? Я тоже иногда их использую, когда аргументы конструктора/метода по смыслу совпадают с членами класса. Тогда использую подчеркивания для аргументов, так как аргументы — в одном месте, а для членов класса их везде таскать придется. Да, я знаю, что компилятор (в случае конструктора, как минимум) сам разберется, но парсить глазами всё равно неудобно, поэтому и добавляю
есть такое древнючее баянское поверье, что приватные члены нужно обозначать с подчеркиванием — до или после. я видел человека, который на полном серьезе рассказывал, что это ему делает код понятнее — видно, что приватное, а что нет
правда, в самой упоротой стадии обычно используется еще суффикс m для членов класса и the для переданных параметров
Здравствуйте, __kot2, Вы писали:
__>есть такое древнючее баянское поверье, что приватные члены нужно обозначать с подчеркиванием — до или после. я видел человека, который на полном серьезе рассказывал, что это ему делает код понятнее — видно, что приватное, а что нет __>правда, в самой упоротой стадии обычно используется еще суффикс m для членов класса и the для переданных параметров
Суффикс "_m" используется у Микрософта для членов классов с любой видимостью. Тот же WTL, да и MFC вроде тоже
Здравствуйте, Marty, Вы писали: __>>есть такое древнючее баянское поверье, что приватные члены нужно обозначать с подчеркиванием — до или после. я видел человека, который на полном серьезе рассказывал, что это ему делает код понятнее — видно, что приватное, а что нет __>>правда, в самой упоротой стадии обычно используется еще суффикс m для членов класса и the для переданных параметров M>Суффикс "_m" используется у Микрософта для членов классов с любой видимостью. Тот же WTL, да и MFC вроде тоже
во-во, я и говорю — самые упоротые
вообще, кстати, в хромиуме еще очень странно выглядит использование паскалевского именования. правда, не всегда, но это выглядит еще более странным
Здравствуйте, CreatorCray, Вы писали: __>>>подчеркивания в членах класса — фуу Ops>>ну уж не хуже m_ CC>Если на то пошло то m_ лучше чем просто подчёркивание.
все это разговоры про сорта говна. никакие префиксы не делают код читабельней. они появляются тогда, когда человек открывает для себя новую концепцию — клссов, интерфейсов или приватных членов и начинает везде пихать поначалу
Здравствуйте, __kot2, Вы писали:
__>все это разговоры про сорта говна. никакие префиксы не делают код читабельней.
Таки делает, если употреблять разумно.
В данном случае префикс позволяет понять в какую переменную в данном месте мы лезем: член класса, локальную или, простигосподи, глобальную.
Это единственный случай когда префикс приемлем.
Как только сделают хорошую схему для syntax highlighting которая бы этот вопрос качественно решала без превращения кода в цветомузыку — это применение тоже отсохнет естественным путём.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали: CC>В данном случае префикс позволяет понять в какую переменную в данном месте мы лезем: член класса, локальную или, простигосподи, глобальную.
с учетом того, что большая часть кода работает именно с локальными переменными, имело бы смысл делать префикс скоре не для них, а то весь код в префиксах получается. но все же понимают, что это изврат, потому что без классов такого не было.
вот и решили ввести подчеркивания для приватных.
CC>Как только сделают хорошую схему для syntax highlighting которая бы этот вопрос качественно решала без превращения кода в цветомузыку — это применение тоже отсохнет естественным путём.
у С++ есть одно прекрасное свойство — можно любой обьект вернуть как const и он будет только для чтения разумеется.
не вижу никакой разницы — вызывать p.x() или читать напрямую p.x из const Point &p;
нафиг тогда вообзе p.x() нужен? единственный случай — есть какой-то шаблонный код, который всегда вызывает именно p.x(), который для некоторых обьектов вычисляется. но я не думаю, что это по этой причине сделано.
людям, пришедшим из явы-C# это концепция дается с трудом, но все-таки надо же пользоваться именно инструментами языка, а не писать в стиле другого
вообще, на самом деле к оечно придирабс и хромиум — один из лучших проектов на С++. есть такой мрак, что прямо кровь из глаз течет и ничего — пользуются люди. но если придираться, то я мое ревью бы на Point.h выглядело бы так:
constexpr Point() : x_(0), y_(0) {} - нафиг constexpr. что он дает?
constexpr Point(int x, int y) : x_(x), y_(y) {} - зачем два конструктора, когда одного достаточно с дефолтными параметрами?
constexpr int x() const { return x_; } - убрать нафиг эти методы, сделать члены x и y публичными
constexpr int y() const { return y_; }
void set_x(int x) { x_ = x; } - наркомания!
void set_y(int y) { y_ = y; }
void SetPoint(int x, int y) { - тяжелая наркомания! зачем нужен метод копирующий реализацию конструктора? почему не p = Point(10, 20), зачем вообще нужен этот set?
x_ = x;
y_ = y;
}
почему паскалевское именование в С++ проекте?
void SetToMin(const Point& other); - непонятная фигня. почему это метод класса Point?
std::string ToString() const; - почему это метод класса а не статич ф-ия?
Здравствуйте, Ops, Вы писали:
AD>>Единственная странность, это то, что у них порядок не как в CSS (top, right, bottom, left) Ops>А откуда, кстати, этот порядок в CSS? Какой-то он неочевидный и неинтуитивный.
Здравствуйте, __kot2, Вы писали:
CC>>В данном случае префикс позволяет понять в какую переменную в данном месте мы лезем: член класса, локальную или, простигосподи, глобальную. __>с учетом того, что большая часть кода работает именно с локальными переменными, имело бы смысл делать префикс скоре не для них, а то весь код в префиксах получается.
Ну так и получается. Все локальные (параметры функции — локальные) без префикса, любые мемберы с m_, статики s_, глобальные g_. Больше никаких префиксов не надо.
__>вот и решили ввести подчеркивания для приватных.
ИМХО это как то буэ. Какая разница приватный или паблик? У них разные контейнеры, это как раз и важно видеть.
__>у С++ есть одно прекрасное свойство — можно любой обьект вернуть как const и он будет только для чтения разумеется. __>не вижу никакой разницы — вызывать p.x() или читать напрямую p.x из const Point &p;
Потому что далеко не всегда у тебя есть исключительно const ссылка на объект, и тогда в том месте можно в p.x ещё и писать, что может вызвать совсем не тот эффект, который ожидался. Получается дыра в интерфейсе через которую можно внутрях всё испортить.
Так что нет.
__>людям, пришедшим из явы-C# это концепция дается с трудом, но все-таки надо же пользоваться именно инструментами языка, а не писать в стиле другого
в жабашарпах есть синтаксическая сахарная нашлёпка, называется property. Это автоматически создаваемый getter + setter, который можно переопределить.
__>constexpr Point() : x_(0), y_(0) {} — нафиг constexpr. что он дает?
Мне кстати тоже непонятно.
__> constexpr Point(int x, int y) : x_(x), y_(y) {} — зачем два конструктора, когда одного достаточно с дефолтными параметрами?
Спорно, ну да ладно. Тут скорее вопрос стилистики, единообразия интерфейсов и чистоты кода в более сложных случаях чем этот.
__> constexpr int x() const { return x_; } — убрать нафиг эти методы, сделать члены x и y публичными __> constexpr int y() const { return y_; }
Категорически нет.
Публичные поля в классе — один из признаков говнокода. Хочешь публичные поля — определяй struct.
__> void set_x(int x) { x_ = x; } — наркомания! __> void set_y(int y) { y_ = y; }
Нет.
__> void SetPoint(int x, int y) { — тяжелая наркомания! зачем нужен метод копирующий реализацию конструктора? почему не p = Point(10, 20), зачем вообще нужен этот set? __> x_ = x; __> y_ = y; __> }
Для простого класса с POD типами да, разницы никакой, для более тяжёлых разница начинает появляться. Если стоит задача придерживаться единой стилистики интерфейсов для базовых классов, к которым этот явно относится, то лучше делать единообразно — компилятор потом всё заинлайнит всё равно.
__>почему паскалевское именование в С++ проекте?
А какая компилятору разница?
Что и как называть определяется принятым в команде coding standard.
__> void SetToMin(const Point& other); — непонятная фигня. почему это метод класса Point?
А почему нет? Что оно делает внутри?
__> std::string ToString() const; — почему это метод класса а не статич ф-ия?
А почему это должна быть статическая функция? Её ж пользовать неудобно.
Если чо, это вообще могло бы быть operator std::string () const;
Вообще ветку пора в срачи переносить.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали: CC>>>В данном случае префикс позволяет понять в какую переменную в данном месте мы лезем: член класса, локальную или, простигосподи, глобальную. __>>с учетом того, что большая часть кода работает именно с локальными переменными, имело бы смысл делать префикс скоре не для них, а то весь код в префиксах получается. CC>Ну так и получается. Все локальные (параметры функции — локальные) без префикса, любые мемберы с m_, статики s_, глобальные g_. Больше никаких префиксов не надо.
для глоальных есть префикс :: про статически s_ первый раз слышу. писать m_ это как примерно писать сущ_ перед каждым существительным — удобно только тем, кто привык
__>>не вижу никакой разницы — вызывать p.x() или читать напрямую p.x из const Point &p; CC>Потому что далеко не всегда у тебя есть исключительно const ссылка на объект, и тогда в том месте можно в p.x ещё и писать, что может вызвать совсем не тот эффект, который ожидался. Получается дыра в интерфейсе через которую можно внутрях всё испортить. CC>Так что нет.
так и так дыра есть интерфейсе в виде set. для того, чтобы дыр не было Point должен быть иммутабельным
__>>людям, пришедшим из явы-C# это концепция дается с трудом, но все-таки надо же пользоваться именно инструментами языка, а не писать в стиле другого CC>в жабашарпах есть синтаксическая сахарная нашлёпка, называется property. Это автоматически создаваемый getter + setter, который можно переопределить.
фигня это по сравнению с const
__>> constexpr Point(int x, int y) : x_(x), y_(y) {} — зачем два конструктора, когда одного достаточно с дефолтными параметрами? CC>Спорно, ну да ладно. Тут скорее вопрос стилистики, единообразия интерфейсов и чистоты кода в более сложных случаях чем этот.
можно обьяснить политическим запретом дефолтных значений, но в данном случае уместно по-моему все-таки иметь дефолтные
CC>Публичные поля в классе — один из признаков говнокода. Хочешь публичные поля — определяй struct.
разумеется Point должен быть struct. не должно быть в нем ничего приватного
__>> void set_x(int x) { x_ = x; } — наркомания! __>> void set_y(int y) { y_ = y; } CC>Нет.
что нет? дырка в интерфейсе
__>>почему паскалевское именование в С++ проекте? CC>А какая компилятору разница?
это паскалевсокму компилятору нет разницы, потому что он регистр не различает, а люди мучаются CC>Что и как называть определяется принятым в команде coding standard.
__>> void SetToMin(const Point& other); — непонятная фигня. почему это метод класса Point? CC>А почему нет? Что оно делает внутри?
а х.з. а зачем такие х.з. методы в Point?
__>> std::string ToString() const; — почему это метод класса а не статич ф-ия? CC>А почему это должна быть статическая функция? Её ж пользовать неудобно. CC>Если чо, это вообще могло бы быть operator std::string () const;
ну да, влепить tostring в класс прямо мог только джавист-сишарпник. не должно быть это членом класса по уму
Здравствуйте, __kot2, Вы писали:
__>что нет? дырка в интерфейсе
Это не дырка, это определённый контракт. Дырка это когда любой может туда ходить как к себе в огород, например взять адрес от public field и передать чёрти куды, откуда в него будут писать.
__>это паскалевсокму компилятору нет разницы, потому что он регистр не различает, а люди мучаются
Мучаются только те странные мазо-аскеты, кто всегда набирает каждую букву руками.
__>а х.з. а зачем такие х.з. методы в Point?
Работают строго с Point, где ж им ещё быть?
__>ну да, влепить tostring в класс прямо мог только джавист-сишарпник. не должно быть это членом класса по уму
Какое либо рациональное объяснение будет?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, __kot2, Вы писали:
M>>Но зачем в членах класса? Я тоже иногда их использую, когда аргументы конструктора/метода по смыслу совпадают с членами класса. Тогда использую подчеркивания для аргументов, так как аргументы — в одном месте, а для членов класса их везде таскать придется. Да, я знаю, что компилятор (в случае конструктора, как минимум) сам разберется, но парсить глазами всё равно неудобно, поэтому и добавляю __>есть такое древнючее баянское поверье, что приватные члены нужно обозначать с подчеркиванием — до или после. я видел человека, который на полном серьезе рассказывал, что это ему делает код понятнее — видно, что приватное, а что нет __>правда, в самой упоротой стадии обычно используется еще суффикс m для членов класса и the для переданных параметров
Ты так лихо всё раскритиковал (на моей предыдущей работе было принято mClassMember, на нонешней — _classMember; лично мне эстетически первое приятнее), что даже и не знаю, как ты обычно отличаешь параметр от члена класса.
Здравствуйте, Dair, Вы писали:
D>Ты так лихо всё раскритиковал (на моей предыдущей работе было принято mClassMember, на нонешней — _classMember; лично мне эстетически первое приятнее), что даже и не знаю, как ты обычно отличаешь параметр от члена класса.
Не знаю, как __kot2, лично я — по именам. Имена такие стараюсь давать, чтобы понятно было. При редких совпадениях — добавляю подчеркивание к параметрам
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Marty, Вы писали: __>>>есть такое древнючее баянское поверье, что приватные члены нужно обозначать с подчеркиванием — до или после. я видел человека, который на полном серьезе рассказывал, что это ему делает код понятнее — видно, что приватное, а что нет __>>>правда, в самой упоротой стадии обычно используется еще суффикс m для членов класса и the для переданных параметров M>>Суффикс "_m" используется у Микрософта для членов классов с любой видимостью. Тот же WTL, да и MFC вроде тоже __>во-во, я и говорю — самые упоротые __>вообще, кстати, в хромиуме еще очень странно выглядит использование паскалевского именования. правда, не всегда, но это выглядит еще более странным
В CBOSSе требования к оформлению кода были майкрасофтовские
Название класса обязательно начинается с 'C', структуры с 'S', мемберы с "m_", в начале названия переменной буква, обозначающая её тип: n — для int, b для bool, sz для ASCIIZ-строки, 'a' для массива, "g_" для глобальных переменных, "gc_" для глобальных констант
m_bTerminating, m_nCount, m_szName и т.п.
__>Здравствуйте, Кодт, Вы писали: К>>Базовая библиотека геометрии, всё просто и понятно, пастораль и идиллия... __>подчеркивания в членах класса — фуу
..сказал человек с двумя подчеркиваниями в нике
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Maniacal, Вы писали:
M>В CBOSSе требования к оформлению кода были майкрасофтовские
aka Венгерская Нотация
M>Название класса обязательно начинается с 'C', структуры с 'S', мемберы с "m_", в начале названия переменной буква, обозначающая её тип: n — для int, b для bool, sz для ASCIIZ-строки, 'a' для массива, "g_" для глобальных переменных, "gc_" для глобальных констант M>m_bTerminating, m_nCount, m_szName и т.п.
Это ИМХО удобно и практично!
Хотя, для кого-то может и архаично
Старый конь — борозды не портит!!!
Здравствуйте, Dair, Вы писали:
D>Здравствуйте, ononim, Вы писали:
D>>>Так это ж insets, у них ну ладно ещё x/y (вместо left/top, а что писать вместо right/bottom?), но width/height у них точно нет. D>>>Николай, не очень понял O>>Основной прикол в том что ордината идете впереди абсцисс, пардон май френч.
D>А, вот это да, в самом деле, косяк.
В CSS так. Вероятно разработчики хрома с CSS сталкиваются и запись вида padding: 10px 5px; им понятна, соответственно и конструктор так понятней будет читаться. Хотя с 4-аргументным конструктором порядок немного неправильный, видимо его автор CSS плохо учил.
Здравствуйте, Ops, Вы писали:
AD>>Единственная странность, это то, что у них порядок не как в CSS (top, right, bottom, left)
Ops>А откуда, кстати, этот порядок в CSS? Какой-то он неочевидный и неинтуитивный.
По часовой стрелке. 0(12) часов, 3 часа, 6 часов, 9 часов. Не думаю, что какой-то порядок будет очевидней.
Здравствуйте, CreatorCray, Вы писали: __>>что нет? дырка в интерфейсе CC>Это не дырка, это определённый контракт. Дырка это когда любой может туда ходить как к себе в огород, например взять адрес от public field и передать чёрти куды, откуда в него будут писать.
это достаточно тонкая грань, тут можно долго обсуждать. но то, что вижу я — челы придумали проперти в стиле C#-Java, а в С++ вместо пропертей для контроля доступа используется const, а для изменений обьектов — констукторы и контроллеры. сами проперти вообще возникли из-за необходимости оборажения гуя в классы. менять обьект через set() — самый простой и надежный способ получить неконстистетное состояние системы, поэтому за этим надо очень внимательно следить, а лучше вообще запртить
__>>это паскалевсокму компилятору нет разницы, потому что он регистр не различает, а люди мучаются CC>Мучаются только те странные мазо-аскеты, кто всегда набирает каждую букву руками.
то есть удобнее нажать точку и потом мышкой тыкнуть? я про необходимость нажимать шифт зачем-то каждый раз для набора имени
в паскале почему было так сделано? потому что в то время ты мог забить на шифт и набирать нижним регистром — как тебе удобнее. постоянно нажимать шифт для вызова каждого метода это как раз и есть мазохизм
__>>а х.з. а зачем такие х.з. методы в Point? CC>Работают строго с Point, где ж им ещё быть?
то есть пусть любоей человек добавляет свои непонятные методы в Point если ему так нравится? так на определеннй итерации туда кто-то забацает вообще Point::draw() с блекджеком и opengl
__>>ну да, влепить tostring в класс прямо мог только джавист-сишарпник. не должно быть это членом класса по уму CC>Какое либо рациональное объяснение будет?
любой кто смотрел что такое stl, которая входит в стандарт С++ должен понимать концепцию разделения алгоритмов и данных. Point — данные. там не должно быть никаких tostring, draw, setmin, fromstring и кстати того конструктора с пространными комментами про совместимость с macos тоже по уму быть не должно. не надо захламлять класс данных. представляете, если бы в vector каждый бы из комитета добавил какие-то свои ф-ии, лично ему в его проекте удобные? тоже чего-нить там про конструктор для macos, акой-нить shuffle_step(), или set_min() ?
Здравствуйте, Dair, Вы писали: D>Ты так лихо всё раскритиковал (на моей предыдущей работе было принято mClassMember, на нонешней — _classMember; лично мне эстетически первое приятнее), что даже и не знаю, как ты обычно отличаешь параметр от члена класса.
если не писать обработку данных длинными спагетинами как члены классов данных (тот же самый tostring() у point), то никаких проблем нет
Здравствуйте, Dair, Вы писали: D>Сеттеры и геттеры нужны для нормального переопределения в потомках. D>Например, в сеттере можно ещё дёрнуть уведомление кого-то об изменении параметра.
это неправильное разделение на model-view-controller. это контроллер должен дергать уведомление, а не model в сеттере
D>Хотя в случае всяких простых вещей вроде Point/Rect я бы, конечно, делал их структурами со всеми публичными полями, конечно.
но это я, как уже говорил выше, придираюсь уже. полно нормально работающего кода, сделанного по другому и ничего — живут люди
Здравствуйте, Maniacal, Вы писали: M>Название класса обязательно начинается с 'C', структуры с 'S', мемберы с "m_", в начале названия переменной буква, обозначающая её тип: n — для int, b для bool, sz для ASCIIZ-строки, 'a' для массива, "g_" для глобальных переменных, "gc_" для глобальных констант M>m_bTerminating, m_nCount, m_szName и т.п.
с появлением шаблонов у людей сломался моск как называть такие переменные, потому что они могту быть совсем любого типа и потом уже пришло озарение, что тип не важен, инфа о нем больше даже мешает. масла в огонь подлило то, что размер перестал быть int и стал size_t — который непонятно с каким префиксом писать и где-то с середины 90ых все стали отказываться от венгерской нотации. что она до сих пор жива в 2016ом году в какой-то компании — нууу, это точно не плюс ей в карму
__>Здравствуйте, ononim, Вы писали: O>>..сказал человек с двумя подчеркиваниями в нике __>а почему их два?
видимо, чтобы было длиннее
__>точнее даже так — __kot2 это нормальный идентификатор в С++?
чем бы дитя не тешилось, лишь бы не goto
Как много веселых ребят, и все делают велосипед...
Здравствуйте, 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 файле не сработает? Типа такого:
К>Сработает, наверно (?).
Работать-то оно будет, но вот мне интересно другое: какая экономия размера бинарника может получиться за счёт форсирования реального вызова функции, которая проста, как две копейки?