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

__>

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

Возможность использовать в других constexpr ?

Здравствуйте, 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 в класс прямо мог только джавист-сишарпник. не должно быть это членом класса по уму
Какое либо рациональное объяснение будет?

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

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

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

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

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

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

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

Здравствуйте, 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 и т.п.

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

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

К>

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

Обход по кругу против часовой стрелки?
Обычно проход по часовой — left, top, right, bottom.

Здравствуйте, 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 часов. Не думаю, что какой-то порядок будет очевидней.

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

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

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

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

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

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

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

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

Здравствуйте, 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 я бы, конечно, делал их структурами со всеми публичными полями, конечно.
но это я, как уже говорил выше, придираюсь уже. полно нормально работающего кода, сделанного по другому и ничего — живут люди

Здравствуйте, ononim, Вы писали:
O>..сказал человек с двумя подчеркиваниями в нике
а почему их два?

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

Здравствуйте, 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