хромая логика
От: Кодт Россия  
Дата: 01.12.16 15:38
Оценка:
Из исходников хромиума.

Базовая библиотека геометрии, всё просто и понятно, пастораль и идиллия...
// gfx/geometry/point.h

class GFX_EXPORT Point {
 public:
  constexpr Point() : x_(0), y_(0) {}
  constexpr Point(int x, int y) : x_(x), y_(y) {}
  . . .

// gfx/geometry/size.h

class GFX_EXPORT Size {
 public:
  constexpr Size() : width_(0), height_(0) {}
  constexpr Size(int width, int height)
  . . .

// gfx/geometry/rect.h

class GFX_EXPORT Rect {
 public:
  constexpr Rect() = default;
  constexpr Rect(int width, int height) : size_(width, height) {}
  constexpr Rect(int x, int y, int width, int height)
  . . .


И тут внезапно
// gfx/geometry/insets.h

class GFX_EXPORT Insets {
 public:
  constexpr Insets() : top_(0), left_(0), bottom_(0), right_(0) {}
  constexpr explicit Insets(int all)
      : top_(all), left_(all), bottom_(all), right_(all) {}
  constexpr Insets(int vertical, int horizontal)
      : top_(vertical),
        left_(horizontal),
        bottom_(vertical),
        right_(horizontal) {}
  constexpr Insets(int top, int left, int bottom, int right)
      : top_(top), left_(left), bottom_(bottom), right_(right) {}
  . . .


Уважаемые знатоки! Как вы думаете, почему я обратил на это внимание?
Перекуём баги на фичи!
Re: хромая логика
От: IID Россия  
Дата: 01.12.16 15:43
Оценка:
Здравствуйте, Кодт, Вы писали:

К>И тут внезапно

К>
К>// gfx/geometry/insets.h

К>class GFX_EXPORT Insets {
К> public:
К>  constexpr Insets() : top_(0), left_(0), bottom_(0), right_(0) {}
К>  constexpr explicit Insets(int all)
К>      : top_(all), left_(all), bottom_(all), right_(all) {}
К>  constexpr Insets(int vertical, int horizontal)
К>      : top_(vertical),
К>        left_(horizontal),
К>        bottom_(vertical),
К>        right_(horizontal) {}
К>  constexpr Insets(int top, int left, int bottom, int right)
К>      : top_(top), left_(left), bottom_(bottom), right_(right) {}
К>  . . .
К>


К>Уважаемые знатоки! Как вы думаете, почему я обратил на это внимание?


Длинный (в символах) список инициализации порезали по строкам. А короткий не порезали.
Неаккуратненько ?
kalsarikännit
Re: хромая логика
От: ononim  
Дата: 01.12.16 15:45
Оценка:
К> Базовая библиотека геометрии, всё просто и понятно, пастораль и идиллия...
согласно педивикии пастораль выглядит так:
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? Порядок аргументов придает особую пикантность.
Как много веселых ребят, и все делают велосипед...
Отредактировано 01.12.2016 15:48 ononim . Предыдущая версия . Еще …
Отредактировано 01.12.2016 15:47 ononim . Предыдущая версия .
Re[2]: хромая логика
От: Кодт Россия  
Дата: 01.12.16 15:48
Оценка: +1
Здравствуйте, ononim, Вы писали:

O>вместо x/y/width/height стали юзать left/top/right/bottom?


вместо x/y стали юзать TOP / LEFT.
а вместо width/height — vertical/horizontal, соответственно
Перекуём баги на фичи!
Re[3]: хромая логика
От: ononim  
Дата: 01.12.16 15:49
Оценка:
O>>вместо x/y/width/height стали юзать left/top/right/bottom?
К>вместо x/y стали юзать TOP / LEFT.
К>а вместо width/height — vertical/horizontal, соответственно
да перевернутый порядок я позже приметил и подредактировал мессагу
Как много веселых ребят, и все делают велосипед...
Re: хромая логика
От: Maniacal Россия  
Дата: 01.12.16 15:49
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Из исходников хромиума.


  Скрытый текст
К>Базовая библиотека геометрии, всё просто и понятно, пастораль и идиллия...
К>
К>// gfx/geometry/point.h

К>class GFX_EXPORT Point {
К> public:
К>  constexpr Point() : x_(0), y_(0) {}
К>  constexpr Point(int x, int y) : x_(x), y_(y) {}
К>  . . .

К>// gfx/geometry/size.h

К>class GFX_EXPORT Size {
К> public:
К>  constexpr Size() : width_(0), height_(0) {}
К>  constexpr Size(int width, int height)
К>  . . .

К>// gfx/geometry/rect.h

К>class GFX_EXPORT Rect {
К> public:
К>  constexpr Rect() = default;
К>  constexpr Rect(int width, int height) : size_(width, height) {}
К>  constexpr Rect(int x, int y, int width, int height)
К>  . . .
К>


К>И тут внезапно

К>
К>// gfx/geometry/insets.h

К>class GFX_EXPORT Insets {
К> public:
К>  constexpr Insets() : top_(0), left_(0), bottom_(0), right_(0) {}
К>  constexpr explicit Insets(int all)
К>      : top_(all), left_(all), bottom_(all), right_(all) {}
К>  constexpr Insets(int vertical, int horizontal)
К>      : top_(vertical),
К>        left_(horizontal),
К>        bottom_(vertical),
К>        right_(horizontal) {}
К>  constexpr Insets(int top, int left, int bottom, int right)
К>      : top_(top), left_(left), bottom_(bottom), right_(right) {}
К>  . . .
К>

К>Уважаемые знатоки! Как вы думаете, почему я обратил на это внимание?

Отвечает Александр Друзь!
Re[2]: хромая логика
От: Кодт Россия  
Дата: 01.12.16 15:50
Оценка:
Здравствуйте, IID, Вы писали:

IID>Длинный (в символах) список инициализации порезали по строкам. А короткий не порезали.

IID>Неаккуратненько ?

особенности хромовского стайлгайда (макс. 80 символов в строке), плюс неудачно длинные идентификаторы аргументов.
это неважно, важно — какие там аргументы.
Перекуём баги на фичи!
Re[3]: хромая логика
От: Dair Россия  
Дата: 01.12.16 16:18
Оценка: 1 (1) +1
Здравствуйте, Кодт, Вы писали:

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 у них точно нет.

Николай, не очень понял

Разные классы, разные свойства, названия тоже разные, вполне отражающие смысл.
Re: хромая логика
От: Skorodum Россия  
Дата: 01.12.16 16:29
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Уважаемые знатоки! Как вы думаете, почему я обратил на это внимание?


Ни разу не знаток, но попробую:
0. Зачем Insets? У него какие-то отличные от Rect свойства есть?
1. Не последовательное применение explicit
2. У Insets нет конструктора который принимает Point, Rect.
3. Дефолтный конструктор Rect не инициализирует переменные, а Point, Size и Insets — инициализирует нулями.
Re[2]: хромая логика
От: Dair Россия  
Дата: 01.12.16 16:37
Оценка:
Здравствуйте, Skorodum, Вы писали:

К>>Уважаемые знатоки! Как вы думаете, почему я обратил на это внимание?

S>0. Зачем Insets? У него какие-то отличные от Rect свойства есть?
Примерно все. Два можно притянуть за уши к x и y у rect'а.


S>2. У Insets нет конструктора который принимает Point, Rect.

Каков физический (в данном случае — геометрический) смысл такого конструктора?


S>3. Дефолтный конструктор Rect не инициализирует переменные, а Point, Size и Insets — инициализирует нулями.

Rect состоит из Point и Size — для них вызываются дефолтные конструкторы.
Re[3]: хромая логика
От: Skorodum Россия  
Дата: 01.12.16 16:53
Оценка:
Здравствуйте, Кодт, Вы писали:

К>вместо x/y стали юзать TOP / LEFT.

К>а вместо width/height — vertical/horizontal, соответственно

По такой логике этот конструктор вообще бред какой-то, т.к. мешает координаты и расстояния:

Insets(int vertical, int horizontal)
: top_(vertical),
left_(horizontal),
bottom_(vertical),
right_(horizontal) {}


Там скорее всего top, left, bottom, right — это смещения, которые будут применены к какой-то центральной точке. Тогда все выглядит логично
Re[3]: хромая логика
От: Skorodum Россия  
Дата: 01.12.16 16:57
Оценка:
Здравствуйте, Dair, Вы писали:

D>Примерно все. Два можно притянуть за уши к x и y у rect'а.

Понял уже, и имена параметров вполне преднамеренно сделаны такими.

S>>2. У Insets нет конструктора который принимает Point, Rect.

D>Каков физический (в данном случае — геометрический) смысл такого конструктора?
Ну я это написал под впечатлением комментария Кодта
Автор: Кодт
Дата: 01.12.16
, теперь думаю, что он немного неправильно понял смысл класса Insets.

S>>3. Дефолтный конструктор Rect не инициализирует переменные, а Point, Size и Insets — инициализирует нулями.

D>Rect состоит из Point и Size — для них вызываются дефолтные конструкторы.
Если так, то согласен, но этого не видно по приведенному коду.
Re[4]: хромая логика
От: ononim  
Дата: 01.12.16 16:58
Оценка: +2
S>По такой логике этот конструктор вообще бред какой-то, т.к. мешает координаты и расстояния:
S>

S> Insets(int vertical, int horizontal)
S> : top_(vertical),
S> left_(horizontal),
S> bottom_(vertical),
S> right_(horizontal) {}

Здесь все ок. За исключением заботливо подложенных граблей с порядком координат.
Как много веселых ребят, и все делают велосипед...
Re[4]: хромая логика
От: ononim  
Дата: 01.12.16 17:00
Оценка:
D>Так это ж insets, у них ну ладно ещё x/y (вместо left/top, а что писать вместо right/bottom?), но width/height у них точно нет.
D>Николай, не очень понял
Основной прикол в том что ордината идете впереди абсцисс, пардон май френч.
 constexpr Insets(int top, int left, int bottom, int right)
Как много веселых ребят, и все делают велосипед...
Re: хромая логика
От: andrey.desman  
Дата: 01.12.16 17:13
Оценка: +1
Здравствуйте, Кодт, Вы писали:

К>Уважаемые знатоки! Как вы думаете, почему я обратил на это внимание?


//
// 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.
Re[4]: хромая логика
От: andrey.desman  
Дата: 01.12.16 17:15
Оценка:
Здравствуйте, Skorodum, Вы писали:

S>Там скорее всего top, left, bottom, right — это смещения, которые будут применены к какой-то центральной точке. Тогда все выглядит логично


Это всякие border-width, padding, margin и т.д.
Re[4]: хромая логика
От: Кодт Россия  
Дата: 01.12.16 17:50
Оценка:
Здравствуйте, 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, — чтобы случайно не смешивать вектор точки, вектор размера и вектор смещения.
Перекуём баги на фичи!
Re[5]: хромая логика
От: ononim  
Дата: 01.12.16 18:06
Оценка:
К>Как видно, во второй сигнатуре аргументы идут в естественном порядке.
Я так подозреваю оно и с Inset юзается во многих местах в естественном порядке. В конце концов это лишь названия переменных) Буду удивлен если это не так..
Как много веселых ребят, и все делают велосипед...
Re: хромая логика
От: Слава  
Дата: 01.12.16 18:07
Оценка: +3
Здравствуйте, Кодт, Вы писали:

К>Уважаемые знатоки! Как вы думаете, почему я обратил на это внимание?


Потому что шутки на С++ доступны только Кодту. Остальные такого уровня просветления не достигли.
Re[2]: хромая логика
От: ononim  
Дата: 01.12.16 18:14
Оценка: -1
К>>Уважаемые знатоки! Как вы думаете, почему я обратил на это внимание?
С>Потому что шутки на С++ доступны только Кодту. Остальные такого уровня просветления не достигли.
Остальным доступен лишь пошлый юмор про то как во время секса приезжает сборщик мусора и требут выкинуть презерватив..
Как много веселых ребят, и все делают велосипед...
Re: хромая логика
От: __kot2  
Дата: 01.12.16 18:47
Оценка: +1 -1
Здравствуйте, Кодт, Вы писали:
К>Базовая библиотека геометрии, всё просто и понятно, пастораль и идиллия...
подчеркивания в членах класса — фуу
Re[3]: хромая логика
От: SaZ  
Дата: 01.12.16 18:56
Оценка: +2 :))) :)
Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, ononim, Вы писали:


O>>вместо x/y/width/height стали юзать left/top/right/bottom?


К>вместо x/y стали юзать TOP / LEFT.

К>а вместо width/height — vertical/horizontal, соответственно

Да, как тут когда-то писали — это неполиткорректно. Правильно dimension1, dimension2...
Re[5]: хромая логика
От: Dair Россия  
Дата: 01.12.16 19:05
Оценка:
Здравствуйте, ononim, Вы писали:

D>>Так это ж insets, у них ну ладно ещё x/y (вместо left/top, а что писать вместо right/bottom?), но width/height у них точно нет.

D>>Николай, не очень понял
O>Основной прикол в том что ордината идете впереди абсцисс, пардон май френч.

А, вот это да, в самом деле, косяк.

left, top, right, bottom
Re[2]: хромая логика
От: Dair Россия  
Дата: 01.12.16 19:09
Оценка:
Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, Кодт, Вы писали:

К>>Базовая библиотека геометрии, всё просто и понятно, пастораль и идиллия...
__>подчеркивания в членах класса — фуу

Мне тоже не нравится, особенно в конце, но у каждого свой coding style, и это уже религиозный вопрос
Re[2]: хромая логика
От: Кодт Россия  
Дата: 01.12.16 19:43
Оценка: :))
Здравствуйте, Слава, Вы писали:

С>Потому что шутки на С++ доступны только Кодту. Остальные такого уровня просветления не достигли.


Зато грабли и очепятки доступны всем. К счастью, моя очепятка с использованием инсетов в продакшен не ушла.

Примечание.
Нет, это не мой сон разума породил такие весёлые конструкторы; маньяк сидит где-то в пучинах Гугла, и зовут его Питер Кастинг.

Поправка.
Кастинг не при чём, это другой отецъ-основатель, Бен Гуджер.
Гугл помнит всё! А гит помнит всё о Гугле!
Перекуём баги на фичи!
Отредактировано 01.12.2016 19:50 Кодт . Предыдущая версия . Еще …
Отредактировано 01.12.2016 19:46 Кодт . Предыдущая версия .
Re[3]: хромая логика
От: __kot2  
Дата: 01.12.16 20:10
Оценка:
Здравствуйте, Dair, Вы писали:
D>Мне тоже не нравится, особенно в конце, но у каждого свой coding style, и это уже религиозный вопрос
разумеется. просто предпочитаю не иметь чего-то, чем иметь что-то лишнее, непонятно зачем нужное. а то попахивает "C" перед именами классов

ну и сама реализация класса тоже спорная. я бы лично оставил x и y публичными, чем городить геттеры-сеттеры к ним
https://chromium.googlesource.com/chromium/src/+/lkgr/ui/gfx/geometry/point.h

и, соотв-но передавал бы const Point & туда, где не хотел бы, чтобы кто-то ручками своими поля эти крутил. а читать — на здоровье.
Re[4]: хромая логика
От: Кодт Россия  
Дата: 01.12.16 20:31
Оценка:
Здравствуйте, __kot2, Вы писали:

__>ну и сама реализация класса тоже спорная. я бы лично оставил x и y публичными, чем городить геттеры-сеттеры к ним


У прямоугольника это связано с тем, что его можно хранить как {left,top,right,bottom} или {left,top,width,height}, — поэтому либо одни, либо другие величины будут доступны только через геттер.
А если всё через геттер — то это единообразие.
Перекуём баги на фичи!
Re[3]: хромая логика
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 01.12.16 20:42
Оценка: +1
Здравствуйте, Dair, Вы писали:

D>Здравствуйте, __kot2, Вы писали:

__>>подчеркивания в членах класса — фуу

D>Мне тоже не нравится, особенно в конце, но у каждого свой coding style, и это уже религиозный вопрос


Но зачем в членах класса? Я тоже иногда их использую, когда аргументы конструктора/метода по смыслу совпадают с членами класса. Тогда использую подчеркивания для аргументов, так как аргументы — в одном месте, а для членов класса их везде таскать придется. Да, я знаю, что компилятор (в случае конструктора, как минимум) сам разберется, но парсить глазами всё равно неудобно, поэтому и добавляю
Маньяк Робокряк колесит по городу
Re[5]: хромая логика
От: __kot2  
Дата: 01.12.16 20:42
Оценка:
Здравствуйте, Кодт, Вы писали:
К>У прямоугольника это связано с тем, что его можно хранить как {left,top,right,bottom} или {left,top,width,height}, — поэтому либо одни, либо другие величины будут доступны только через геттер.
тогда логично хранить {left,top,right,bottom} и иметь методы width() и height()

К>А если всё через геттер — то это единообразие.

все сделано через геттеры
Re[4]: хромая логика
От: __kot2  
Дата: 01.12.16 20:46
Оценка:
Здравствуйте, Marty, Вы писали:
M>Но зачем в членах класса? Я тоже иногда их использую, когда аргументы конструктора/метода по смыслу совпадают с членами класса. Тогда использую подчеркивания для аргументов, так как аргументы — в одном месте, а для членов класса их везде таскать придется. Да, я знаю, что компилятор (в случае конструктора, как минимум) сам разберется, но парсить глазами всё равно неудобно, поэтому и добавляю
есть такое древнючее баянское поверье, что приватные члены нужно обозначать с подчеркиванием — до или после. я видел человека, который на полном серьезе рассказывал, что это ему делает код понятнее — видно, что приватное, а что нет
правда, в самой упоротой стадии обычно используется еще суффикс m для членов класса и the для переданных параметров
Re[5]: хромая логика
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 01.12.16 20:49
Оценка:
Здравствуйте, __kot2, Вы писали:

__>есть такое древнючее баянское поверье, что приватные члены нужно обозначать с подчеркиванием — до или после. я видел человека, который на полном серьезе рассказывал, что это ему делает код понятнее — видно, что приватное, а что нет

__>правда, в самой упоротой стадии обычно используется еще суффикс m для членов класса и the для переданных параметров

Суффикс "_m" используется у Микрософта для членов классов с любой видимостью. Тот же WTL, да и MFC вроде тоже
Маньяк Робокряк колесит по городу
Re[6]: хромая логика
От: __kot2  
Дата: 01.12.16 20:52
Оценка:
Здравствуйте, Marty, Вы писали:
__>>есть такое древнючее баянское поверье, что приватные члены нужно обозначать с подчеркиванием — до или после. я видел человека, который на полном серьезе рассказывал, что это ему делает код понятнее — видно, что приватное, а что нет
__>>правда, в самой упоротой стадии обычно используется еще суффикс m для членов класса и the для переданных параметров
M>Суффикс "_m" используется у Микрософта для членов классов с любой видимостью. Тот же WTL, да и MFC вроде тоже
во-во, я и говорю — самые упоротые
вообще, кстати, в хромиуме еще очень странно выглядит использование паскалевского именования. правда, не всегда, но это выглядит еще более странным

https://chromium.googlesource.com/experimental/chromium/src/+/lkcr/ui/gfx/geometry/cubic_bezier.h

double GetX1() const; — фуу, паскаль

double range_min() const { return range_min_; } — ой, нет, Си
Отредактировано 01.12.2016 20:53 __kot2 . Предыдущая версия .
Re[2]: хромая логика
От: Ops Россия  
Дата: 01.12.16 21:10
Оценка:
Здравствуйте, andrey.desman, Вы писали:

AD>Единственная странность, это то, что у них порядок не как в CSS (top, right, bottom, left)


А откуда, кстати, этот порядок в CSS? Какой-то он неочевидный и неинтуитивный.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[2]: хромая логика
От: Ops Россия  
Дата: 01.12.16 21:11
Оценка:
Здравствуйте, __kot2, Вы писали:

__>подчеркивания в членах класса — фуу


ну уж не хуже m_
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[3]: хромая логика
От: CreatorCray  
Дата: 01.12.16 21:50
Оценка: +2
Здравствуйте, Ops, Вы писали:

__>>подчеркивания в членах класса — фуу

Ops>ну уж не хуже m_
Если на то пошло то m_ лучше чем просто подчёркивание.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: хромая логика
От: __kot2  
Дата: 01.12.16 22:17
Оценка: -2
Здравствуйте, CreatorCray, Вы писали:
__>>>подчеркивания в членах класса — фуу
Ops>>ну уж не хуже m_
CC>Если на то пошло то m_ лучше чем просто подчёркивание.
все это разговоры про сорта говна. никакие префиксы не делают код читабельней. они появляются тогда, когда человек открывает для себя новую концепцию — клссов, интерфейсов или приватных членов и начинает везде пихать поначалу
Re[5]: хромая логика
От: CreatorCray  
Дата: 01.12.16 22:55
Оценка: +3
Здравствуйте, __kot2, Вы писали:

__>все это разговоры про сорта говна. никакие префиксы не делают код читабельней.

Таки делает, если употреблять разумно.
В данном случае префикс позволяет понять в какую переменную в данном месте мы лезем: член класса, локальную или, простигосподи, глобальную.
Это единственный случай когда префикс приемлем.
Как только сделают хорошую схему для syntax highlighting которая бы этот вопрос качественно решала без превращения кода в цветомузыку — это применение тоже отсохнет естественным путём.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[6]: хромая логика
От: __kot2  
Дата: 01.12.16 23:23
Оценка:
Здравствуйте, 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; - почему это метод класса а не статич ф-ия?
Отредактировано 01.12.2016 23:34 __kot2 . Предыдущая версия .
Re[3]: хромая логика
От: andrey.desman  
Дата: 01.12.16 23:25
Оценка:
Здравствуйте, Ops, Вы писали:

AD>>Единственная странность, это то, что у них порядок не как в CSS (top, right, bottom, left)

Ops>А откуда, кстати, этот порядок в CSS? Какой-то он неочевидный и неинтуитивный.

Х.з. Может прошлись по часам с полуночи/полудня.
Re[7]: хромая логика
От: CreatorCray  
Дата: 02.12.16 00:17
Оценка:
Здравствуйте, __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, значит пора закрыть эту страницу.
Всем пока
Re[7]: хромая логика
От: Ops Россия  
Дата: 02.12.16 00:29
Оценка: 4 (1)
Здравствуйте, __kot2, Вы писали:

__>
__>constexpr Point() : x_(0), y_(0) {}  - нафиг constexpr. что он дает?
__>


Возможность использовать в других constexpr ?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[8]: хромая логика
От: __kot2  
Дата: 02.12.16 01:26
Оценка:
Здравствуйте, 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 в класс прямо мог только джавист-сишарпник. не должно быть это членом класса по уму
Re[9]: хромая логика
От: CreatorCray  
Дата: 02.12.16 03:40
Оценка:
Здравствуйте, __kot2, Вы писали:

__>что нет? дырка в интерфейсе

Это не дырка, это определённый контракт. Дырка это когда любой может туда ходить как к себе в огород, например взять адрес от public field и передать чёрти куды, откуда в него будут писать.

__>это паскалевсокму компилятору нет разницы, потому что он регистр не различает, а люди мучаются

Мучаются только те странные мазо-аскеты, кто всегда набирает каждую букву руками.

__>а х.з. а зачем такие х.з. методы в Point?

Работают строго с Point, где ж им ещё быть?

__>ну да, влепить tostring в класс прямо мог только джавист-сишарпник. не должно быть это членом класса по уму

Какое либо рациональное объяснение будет?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: хромая логика
От: Dair Россия  
Дата: 02.12.16 05:58
Оценка: +1
Здравствуйте, __kot2, Вы писали:

M>>Но зачем в членах класса? Я тоже иногда их использую, когда аргументы конструктора/метода по смыслу совпадают с членами класса. Тогда использую подчеркивания для аргументов, так как аргументы — в одном месте, а для членов класса их везде таскать придется. Да, я знаю, что компилятор (в случае конструктора, как минимум) сам разберется, но парсить глазами всё равно неудобно, поэтому и добавляю

__>есть такое древнючее баянское поверье, что приватные члены нужно обозначать с подчеркиванием — до или после. я видел человека, который на полном серьезе рассказывал, что это ему делает код понятнее — видно, что приватное, а что нет
__>правда, в самой упоротой стадии обычно используется еще суффикс m для членов класса и the для переданных параметров

Ты так лихо всё раскритиковал (на моей предыдущей работе было принято mClassMember, на нонешней — _classMember; лично мне эстетически первое приятнее), что даже и не знаю, как ты обычно отличаешь параметр от члена класса.
Re[4]: хромая логика
От: Dair Россия  
Дата: 02.12.16 06:00
Оценка: +1
Здравствуйте, __kot2, Вы писали:

__>ну и сама реализация класса тоже спорная. я бы лично оставил x и y публичными, чем городить геттеры-сеттеры к ним


Сеттеры и геттеры нужны для нормального переопределения в потомках.
Например, в сеттере можно ещё дёрнуть уведомление кого-то об изменении параметра.

Хотя в случае всяких простых вещей вроде Point/Rect я бы, конечно, делал их структурами со всеми публичными полями, конечно.
Re[6]: хромая логика
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 02.12.16 06:01
Оценка: +1
Здравствуйте, Dair, Вы писали:

D>Ты так лихо всё раскритиковал (на моей предыдущей работе было принято mClassMember, на нонешней — _classMember; лично мне эстетически первое приятнее), что даже и не знаю, как ты обычно отличаешь параметр от члена класса.


Не знаю, как __kot2, лично я — по именам. Имена такие стараюсь давать, чтобы понятно было. При редких совпадениях — добавляю подчеркивание к параметрам
Маньяк Робокряк колесит по городу
Re[7]: хромая логика
От: Maniacal Россия  
Дата: 02.12.16 06:07
Оценка:
Здравствуйте, __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 и т.п.
Re[2]: хромая логика
От: ononim  
Дата: 02.12.16 08:27
Оценка: +2 :)))
__>Здравствуйте, Кодт, Вы писали:
К>>Базовая библиотека геометрии, всё просто и понятно, пастораль и идиллия...
__>подчеркивания в членах класса — фуу
..сказал человек с двумя подчеркиваниями в нике
Как много веселых ребят, и все делают велосипед...
Re: хромая логика
От: rus blood Россия  
Дата: 02.12.16 09:08
Оценка:
Здравствуйте, Кодт, Вы писали:

К>
К>  constexpr Insets(int top, int left, int bottom, int right)
К>


Обход по кругу против часовой стрелки?
Обычно проход по часовой — left, top, right, bottom.
Имею скафандр — готов путешествовать!
Re[8]: хромая логика
От: AlexGin Беларусь  
Дата: 02.12.16 09:10
Оценка:
Здравствуйте, Maniacal, Вы писали:

M>В CBOSSе требования к оформлению кода были майкрасофтовские

aka Венгерская Нотация

M>Название класса обязательно начинается с 'C', структуры с 'S', мемберы с "m_", в начале названия переменной буква, обозначающая её тип: n — для int, b для bool, sz для ASCIIZ-строки, 'a' для массива, "g_" для глобальных переменных, "gc_" для глобальных констант

M>m_bTerminating, m_nCount, m_szName и т.п.
Это ИМХО удобно и практично!
Хотя, для кого-то может и архаично
Старый конь — борозды не портит!!!
Re[6]: хромая логика
От: vsb Казахстан  
Дата: 02.12.16 11:31
Оценка:
Здравствуйте, Dair, Вы писали:

D>Здравствуйте, ononim, Вы писали:


D>>>Так это ж insets, у них ну ладно ещё x/y (вместо left/top, а что писать вместо right/bottom?), но width/height у них точно нет.

D>>>Николай, не очень понял
O>>Основной прикол в том что ордината идете впереди абсцисс, пардон май френч.

D>А, вот это да, в самом деле, косяк.


В CSS так. Вероятно разработчики хрома с CSS сталкиваются и запись вида padding: 10px 5px; им понятна, соответственно и конструктор так понятней будет читаться. Хотя с 4-аргументным конструктором порядок немного неправильный, видимо его автор CSS плохо учил.
Re[3]: хромая логика
От: vsb Казахстан  
Дата: 02.12.16 11:35
Оценка:
Здравствуйте, Ops, Вы писали:

AD>>Единственная странность, это то, что у них порядок не как в CSS (top, right, bottom, left)


Ops>А откуда, кстати, этот порядок в CSS? Какой-то он неочевидный и неинтуитивный.


По часовой стрелке. 0(12) часов, 3 часа, 6 часов, 9 часов. Не думаю, что какой-то порядок будет очевидней.
Re: хромая логика
От: B0FEE664  
Дата: 02.12.16 11:50
Оценка:
Здравствуйте, Кодт, Вы писали:

К>И тут внезапно

К>
К>  constexpr Insets(int top, int left, int bottom, int right)
К>      : top_(top), left_(left), bottom_(bottom), right_(right) {}
К>  . . .
К>


К>Уважаемые знатоки! Как вы думаете, почему я обратил на это внимание?

Перечисление отступов против часовой стрелки.

Интересно, а они действительно поддерживают отрицательные отступы?
И каждый день — без права на ошибку...
Re[6]: хромая логика
От: flаt  
Дата: 02.12.16 12:17
Оценка:
Здравствуйте, Marty, Вы писали:

M>Суффикс "_m" используется у Микрософта для членов классов с любой видимостью. Тот же WTL, да и MFC вроде тоже


Только не суффикс, а префикс, и не "_m", а "m_"
Re[10]: хромая логика
От: __kot2  
Дата: 02.12.16 13:28
Оценка:
Здравствуйте, 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() ?
Re[6]: хромая логика
От: __kot2  
Дата: 02.12.16 13:44
Оценка:
Здравствуйте, Dair, Вы писали:
D>Ты так лихо всё раскритиковал (на моей предыдущей работе было принято mClassMember, на нонешней — _classMember; лично мне эстетически первое приятнее), что даже и не знаю, как ты обычно отличаешь параметр от члена класса.
если не писать обработку данных длинными спагетинами как члены классов данных (тот же самый tostring() у point), то никаких проблем нет
Re[5]: хромая логика
От: __kot2  
Дата: 02.12.16 13:46
Оценка:
Здравствуйте, Dair, Вы писали:
D>Сеттеры и геттеры нужны для нормального переопределения в потомках.
D>Например, в сеттере можно ещё дёрнуть уведомление кого-то об изменении параметра.
это неправильное разделение на model-view-controller. это контроллер должен дергать уведомление, а не model в сеттере

D>Хотя в случае всяких простых вещей вроде Point/Rect я бы, конечно, делал их структурами со всеми публичными полями, конечно.

но это я, как уже говорил выше, придираюсь уже. полно нормально работающего кода, сделанного по другому и ничего — живут люди
Re[3]: хромая логика
От: __kot2  
Дата: 02.12.16 13:47
Оценка:
Здравствуйте, ononim, Вы писали:
O>..сказал человек с двумя подчеркиваниями в нике
а почему их два?

точнее даже так — __kot2 это нормальный идентификатор в С++?
Отредактировано 02.12.2016 13:48 __kot2 . Предыдущая версия .
Re[8]: хромая логика
От: __kot2  
Дата: 02.12.16 13:49
Оценка:
Здравствуйте, 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ом году в какой-то компании — нууу, это точно не плюс ей в карму
Отредактировано 02.12.2016 13:59 __kot2 . Предыдущая версия .
Re[4]: хромая логика
От: ononim  
Дата: 02.12.16 13:59
Оценка: :)
__>Здравствуйте, ononim, Вы писали:
O>>..сказал человек с двумя подчеркиваниями в нике
__>а почему их два?
видимо, чтобы было длиннее

__>точнее даже так — __kot2 это нормальный идентификатор в С++?

чем бы дитя не тешилось, лишь бы не goto
Как много веселых ребят, и все делают велосипед...
Re[7]: хромая логика
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 02.12.16 14:25
Оценка:
Здравствуйте, flаt, Вы писали:

M>>Суффикс "_m" используется у Микрософта для членов классов с любой видимостью. Тот же WTL, да и MFC вроде тоже


F>Только не суффикс, а префикс, и не "_m", а "m_"


Ну да, не "Волгу", а сто рублей, не выиграл, а проиграл

Я уже пару лет в WTL не заглядывал, подзабыл что там как
Маньяк Робокряк колесит по городу
Re[7]: хромая логика
От: Кодт Россия  
Дата: 02.12.16 14:54
Оценка:
Здравствуйте, __kot2, Вы писали:

__>вообще, кстати, в хромиуме еще очень странно выглядит использование паскалевского именования. правда, не всегда, но это выглядит еще более странным


Гугловский стиль гласит:
— примитивные функции, особенно инлайновые, (и изредка — неинлайновые геттеры-сеттеры для единообразия с соседними инлайновыми членами) пишутся в змеином_виде
— неинлайновые функции — пишутся в ПаскалевомВиде (они называют это верблюжим, но какой же это верблюжийВид, если с заглавной буквы)

— инлайновыми можно делать только те функции, которые не виртуальные и чьё тело укладывается в одну строчку
Перекуём баги на фичи!
Re[7]: хромая логика
От: Кодт Россия  
Дата: 02.12.16 15:11
Оценка:
Здравствуйте, __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) — это легаси наркомания.
Перекуём баги на фичи!
Отредактировано 02.12.2016 15:17 Кодт . Предыдущая версия .
Re[2]: хромая логика
От: Кодт Россия  
Дата: 02.12.16 15:19
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Интересно, а они действительно поддерживают отрицательные отступы?


В принципе, да. Но только надо очень чётко понимать, к чему приведёт раздувание прямоугольника: не выбежит ли он за допустимые границы.
Перекуём баги на фичи!
Re[8]: хромая логика
От: __kot2  
Дата: 02.12.16 15:26
Оценка:
Здравствуйте, Кодт, Вы писали:
К>Но хромовская политика чистоты кода — начиная с чистоты стиля — делает своё светлое дело.
в принципе, из публичных 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) — это легаси наркомания.

так незачем поощрять наркоманию, даже если это легаси! надо быть сразу бить палкой тому, кто это добавил. явно же не с начала в классе было
Отредактировано 02.12.2016 15:36 __kot2 . Предыдущая версия .
Re[4]: хромая логика
От: Ops Россия  
Дата: 02.12.16 17:47
Оценка:
Здравствуйте, __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.

Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[5]: хромая логика
От: __kot2  
Дата: 02.12.16 18:47
Оценка:
Здравствуйте, 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 — свободен и зарезервирован специально для меня
Re[9]: хромая логика
От: PM  
Дата: 03.12.16 22:02
Оценка: 12 (1) +1
Здравствуйте, __kot2, Вы писали:

__>я, кстати, видел где-то пример кода в стиле


__>
__>struct S
__>{
__>    int x = 10;
__>};
__>

__>это часть нового стандарта? какого именно? или это для простоты обсуждения было?

Это non-static data member initializers, были добавлены в C++11: http://en.cppreference.com/w/cpp/language/data_members#Member_initialization

И класс Point мог бы выглядеть так:

struct Point
{
    int x = 0;
    int y = 0;

    constexpr Point() = default;
    constexpr Point(int x, int y) : x(x), y(y) {}
...
};


Также есть вариант с делегирующим конструктором:

Point::Point() : Point(0, 0) {}


Ещё странно, что гугловцы выбрали путь дублирования кода и наделали пар Point/PointF, Size/SizeF и т.п. вместо шаблонов.
Re[10]: хромая логика
От: Кодт Россия  
Дата: 05.12.16 12:40
Оценка:
Здравствуйте, PM, Вы писали:

PM>Ещё странно, что гугловцы выбрали путь дублирования кода и наделали пар Point/PointF, Size/SizeF и т.п. вместо шаблонов.


Это не странно. Гугловцы настойчиво любят пихать функции в отдельные единицы компиляции, чтобы уменьшить распухание экзешника и избежать ада статических переменных при компонентной сборке.

У них, например, недавно был приступ паранойи — явно забанить все конструкторы, генерируемые компилятором.
// .h

class Foo {
 public:
  Foo(const Foo&); // = default
  . . . .
 private:
  int x_, y_, z_;
};

// .cc
Foo::Foo(const Foo&) = default;


С шаблонами такой фокус, ясное дело, не провернёшь.

И обратите внимание на то, что Point сотоварищи имеет атрибут GFX_EXPORT — это старый добрый __declspec(dllexport) из модуля gfx.dll
Перекуём баги на фичи!
Re[11]: хромая логика
От: PM  
Дата: 06.12.16 08:11
Оценка:
Здравствуйте, Кодт, Вы писали:

PM>>Ещё странно, что гугловцы выбрали путь дублирования кода и наделали пар Point/PointF, Size/SizeF и т.п. вместо шаблонов.


К>Это не странно. Гугловцы настойчиво любят пихать функции в отдельные единицы компиляции, чтобы уменьшить распухание экзешника и избежать ада статических переменных при компонентной сборке.


К>У них, например, недавно был приступ паранойи — явно забанить все конструкторы, генерируемые компилятором.

К>
К>// .h

К>class Foo {
К> public:
К>  Foo(const Foo&); // = default
К>  . . . .
К> private:
К>  int x_, y_, z_;
К>};

К>// .cc
К>Foo::Foo(const Foo&) = default;
К>


К>С шаблонами такой фокус, ясное дело, не провернёшь.


К>И обратите внимание на то, что Point сотоварищи имеет атрибут GFX_EXPORT — это старый добрый __declspec(dllexport) из модуля gfx.dll


А разве explicit instantiation в .cc файле не сработает? Типа такого:

// .hpp
template<typename T>
struct PointT
{
    T x = {};
    T y = {};

    PointT();
    PointT(T x, T y);
}; 

using Point = PointT<int>;
using PointF = PointT<float>;

// declare explicit instantiation
extern template PointT<int>;
extern template PointT<float>;

// .cpp
template<typename T>
struct PointT<T>::PointT() = default;

template<typename T>
struct PointT<T>::PointT(T x, T y) : x(x), y(y) {}

// define explicit instantiation
template PointT<int>;
template PointT<float>;


Надо будет с dllexport попробовать.
Re[12]: хромая логика
От: Кодт Россия  
Дата: 06.12.16 10:37
Оценка:
Здравствуйте, PM, Вы писали:

К>>С шаблонами такой фокус, ясное дело, не провернёшь.

К>>И обратите внимание на то, что Point сотоварищи имеет атрибут GFX_EXPORT — это старый добрый __declspec(dllexport) из модуля gfx.dll
PM>А разве explicit instantiation в .cc файле не сработает? Типа такого:

Сработает, наверно (?). Но гугл пошёл другим путём.
Надо поизучать, как атрибуты экспорта накладываются на явное воплощение шаблонов. Может быть, у gcc и VC есть расхождения в этих делах, и поэтому гугловцы решили не наступать на тонкий лёд.
Перекуём баги на фичи!
Re[13]: хромая логика
От: N. I.  
Дата: 07.12.16 09:51
Оценка:
Кодт:

К>>>И обратите внимание на то, что Point сотоварищи имеет атрибут GFX_EXPORT — это старый добрый __declspec(dllexport) из модуля gfx.dll

PM>>А разве explicit instantiation в .cc файле не сработает? Типа такого:

К>Сработает, наверно (?).


Работать-то оно будет, но вот мне интересно другое: какая экономия размера бинарника может получиться за счёт форсирования реального вызова функции, которая проста, как две копейки?
Re: хромая логика
От: c-smile Канада http://terrainformatica.com
Дата: 08.12.16 00:58
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Из исходников хромиума.


Эта муть из CSS тянется...


background-size: 300px 100px;       /* width->300, height->100 */

/* but! */

padding: 1.6em 20px;        /* top and bottom (vertical) 1.6em, left and right (horizontal) 20px margin */
padding: 1em 3px 30px 5px;  /*  top    1em  padding  */
                            /*  right  3px  padding  */
                            /*  bottom 30px padding  */
                            /*  left   5px  padding  */
Re[2]: хромая логика
От: Dair Россия  
Дата: 08.12.16 05:50
Оценка:
Здравствуйте, c-smile, Вы писали:

К>>Из исходников хромиума.

CS>Эта муть из CSS тянется...

Ничего, ничего хорошего из web не пришло.

Kill it with fire.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.