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, значит пора закрыть эту страницу.
Всем пока
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.