Форум программистов, компьютерный форум, киберфорум
Наши страницы
С++ для начинающих
Войти
Регистрация
Восстановить пароль
 
 
Рейтинг: Рейтинг темы: голосов - 10, средняя оценка - 5.00
kylroma
Одессит
204 / 75 / 37
Регистрация: 30.12.2013
Сообщений: 277
Записей в блоге: 1
Завершенные тесты: 2
#1

Рекомендация: сначало public, потом protected/private - C++

10.07.2014, 16:15. Просмотров 1791. Ответов 28
Метки нет (Все метки)

На хабре есть статья "90 рекомендаций по стилю написания программ на C++". Интересует вот этот пункт:
44. Разделы класса public, protected и private должны быть отсортированы. Все разделы должны быть явно указаны.
Сперва должен идти раздел public, что избавит желающих ознакомиться с классом от чтения разделов protected/private.


Недавно столкнулся в примере программы. Сначало public, а потом private. Ужасно неудобно читать такую программу. Начинал с конца.
Так вот, действительно, ли является хорошим тоном так писать программы? Или это извращение какое-то?
0
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
10.07.2014, 16:15
Я подобрал для вас темы с готовыми решениями и ответами на вопрос Рекомендация: сначало public, потом protected/private (C++):

Protected Private Public
Возник вопрос, немного наверное бредовый и на практике наврятли применимый, но...

private, protected, public
class test { public: test(); int getPrivate(); int vpublic; protected:...

Не могу разобраться. public/private/protected
#include <iostream> #include <string> #include <time.h> using...

Ключевые слова private, public, protected
Смысл ключевых слов private, public, protected в списке базовых классов при...

Public, Private, Protected (смысл применения)
Прошу Вас пояснить реальный смысл ключевых слов, перечисленных в теме. С...

Наследование. Помогите с этими public, protected. private
Вот код, в нем вылетает ошибка Unit2.cpp(16): E2251 Cannot find default...

28
Voivoid
708 / 280 / 15
Регистрация: 31.03.2013
Сообщений: 1,339
10.07.2014, 16:50 #2
Цитата Сообщение от kylroma Посмотреть сообщение
Ужасно неудобно читать такую программу

Все правильно, сначала public секция, затем все остальное. В идеале вообще в private секцию не нужно смотреть. Инкапсюлация же
0
zss
Модератор
Эксперт С++
6956 / 6518 / 4138
Регистрация: 18.12.2011
Сообщений: 17,208
Завершенные тесты: 1
10.07.2014, 17:02 #3
И все же - это дело программиста.
На мой взгляд, если программу документируем, то сначала надо ознакомиться
с данными класса, а уж потом - что с ними можно делать.
Да и зачем тогда придумали class, осталась бы struct!
0
Voivoid
708 / 280 / 15
Регистрация: 31.03.2013
Сообщений: 1,339
10.07.2014, 17:07 #4
Цитата Сообщение от zss Посмотреть сообщение
сначала надо ознакомиться
с данными класса
Зачем? Как тебе это информация поможет?
0
zss
Модератор
Эксперт С++
6956 / 6518 / 4138
Регистрация: 18.12.2011
Сообщений: 17,208
Завершенные тесты: 1
10.07.2014, 17:13 #5
Цитата Сообщение от Voivoid Посмотреть сообщение
Зачем?
Например, собираемся создать производный класс:
В первую очередь надо определить, какие данные уже есть и какие надо добавить.
0
Voivoid
708 / 280 / 15
Регистрация: 31.03.2013
Сообщений: 1,339
10.07.2014, 17:17 #6
Цитата Сообщение от zss Посмотреть сообщение
В первую очередь надо определить, какие данные уже есть и какие надо добавить.
Какая разница, если они все равно в private секции. Ты до них сможешь добраться только через public или protected интерфейс. А значит опять смысла смотреть в private секцию нет
0
Renji
2138 / 1497 / 456
Регистрация: 05.06.2014
Сообщений: 4,337
10.07.2014, 17:42 #7
Зачем? Как тебе это информация поможет?
Скажем, выяснится что very_slow_method() на самом деле кеширует свои результаты и very slow лишь при первом вызове. Хотя, конечно, по хорошему это должно быть подписано где-то рядышком с объявлением метода.
0
Voivoid
708 / 280 / 15
Регистрация: 31.03.2013
Сообщений: 1,339
10.07.2014, 17:58 #8
Цитата Сообщение от Renji Посмотреть сообщение
Скажем, выяснится что very_slow_method() на самом деле кеширует свои результаты
1) Такие вещи обычно пишут в документации к библиотеке
2) Преждевременная оптимизация - корень всех зол
3) Если все же нужна ультра-производительность, то конечно не грех и в реализацию посмотреть что там да как, но это, согласитесь уж, довольно редкий случай. Имеет смысл только после того, как профайлер показал там узкое место
0
Jupiter
Каратель
Эксперт С++
6568 / 3989 / 400
Регистрация: 26.03.2010
Сообщений: 9,273
Записей в блоге: 1
Завершенные тесты: 2
10.07.2014, 19:06 #9
Цитата Сообщение от zss Посмотреть сообщение
И все же - это дело программиста.
это дело guidelines компании
2
Убежденный
Ушел с форума
Эксперт С++
15941 / 7252 / 1176
Регистрация: 02.05.2013
Сообщений: 11,637
Записей в блоге: 1
Завершенные тесты: 1
11.07.2014, 08:21 #10
Цитата Сообщение от kylroma Посмотреть сообщение
На хабре есть статья "90 рекомендаций по стилю написания программ на C++". Интересует вот этот пункт:
44. Разделы класса public, protected и private должны быть отсортированы. Все разделы должны быть явно указаны.
Сперва должен идти раздел public, что избавит желающих ознакомиться с классом от чтения разделов protected/private.
Опять этот Хабр ! Чего, спрашивается, люди туда лезут как в источник абсолютной истины ?
По поводу сортировки членов класса по уровню доступа - ну бред же ! Быстрый пример:
если у меня некопируемый класс, в котором копирующий конструктор и оператор присваивания
помещены в private-секцию и не имеют реализаций, я помещу эту секцию повыше, чтобы она
бросалась в глаза и читающий сразу понял, что класс копировать нельзя.

И вообще, группировать члены класса лучше по каким-то концептуальным или логически
общим признакам, чем просто по спецификаторам доступа. Ну например: конструкторы-деструкторы,
затем public-интерфейс, дальше перегруженные операторы, потом какие-нибудь там internal-методы, и
потом private-данные. Если у меня какой-то член данных будет в паблике, я не буду его
совать на самый верх из-за того, что так типа правильно. Лучше я сделаю для него отдельную
public-секцию в правильном месте, скажем, сразу над private-данными, и помещу его туда.
5
Renji
2138 / 1497 / 456
Регистрация: 05.06.2014
Сообщений: 4,337
11.07.2014, 09:10 #11
Быстрый пример:
если у меня некопируемый класс, в котором копирующий конструктор и оператор присваивания
помещены в private-секцию и не имеют реализаций, я помещу эту секцию повыше, чтобы она
бросалась в глаза и читающий сразу понял, что класс копировать нельзя.
В C++11 не нужно уже.
C++
1
2
3
4
5
struct my_struct
{
    my_struct(const my_struct&)=delete;
    void operator=(const my_struct&)const=delete;
};
0
Tulosba
:)
Эксперт С++
4746 / 3240 / 496
Регистрация: 19.02.2013
Сообщений: 9,046
11.07.2014, 09:44 #12
Renji, всё же Убежденный (если я правильно понял) сделал акцент на расположении к началу объявления класса, а не на том, в какой конкретно секции это размещать. Потому что в случае с =delete их всё равно есть смысл разместить повыше (опять-таки опираясь на логику Убежденный, с которой я, в принципе, согласен).
1
Kastaneda
Jesus loves me
Эксперт С++
4760 / 2963 / 341
Регистрация: 12.12.2009
Сообщений: 7,524
Записей в блоге: 2
Завершенные тесты: 1
11.07.2014, 09:53 #13
Еще в линуксовых исходниках часто встречаю такое
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
public:
    // что-нибудь
protected:
    // что-нибудь
public:
    // что-нибудь
private:
    // что-нибудь
protected:
    // что-нибудь
public:
    // что-нибудь
// и т.д.
вот это реально жесть, глаза вместе с мозгом ломаются)
0
Tulosba
:)
Эксперт С++
4746 / 3240 / 496
Регистрация: 19.02.2013
Сообщений: 9,046
11.07.2014, 09:57 #14
Цитата Сообщение от Kastaneda Посмотреть сообщение
Еще в линуксовых исходниках
Я что-то сразу подумал про ядро, но оно ж на С.
А подобное расположение тоже встречал, только вот ассоциировать это именно с линуксом, по-моему, немного странно.
0
Croessmah
++Ͻ
14160 / 8085 / 1513
Регистрация: 27.09.2012
Сообщений: 19,926
Записей в блоге: 3
Завершенные тесты: 1
11.07.2014, 10:02 #15
Цитата Сообщение от Kastaneda Посмотреть сообщение
Еще в линуксовых исходниках часто встречаю такое
наткнулся на такое:
C++
1
2
3
4
5
6
7
8
class EnumSet {
public:
   //...
private:
    //...
private:
    //...
};
0
Kastaneda
11.07.2014, 10:33
  #16

Не по теме:

Цитата Сообщение от Tulosba Посмотреть сообщение
только вот ассоциировать это именно с линуксом, по-моему, немного странно.
это да, просто говорю, что там это часто встречается. Еще по долгу службы сейчас OpenJDK ковыряю, там это тоже практикуется. В OpenJDK вообще много странностей)

0
Voivoid
708 / 280 / 15
Регистрация: 31.03.2013
Сообщений: 1,339
11.07.2014, 12:09 #17
Цитата Сообщение от Убежденный Посмотреть сообщение
группировать члены класса лучше по каким-то концептуальным или логически
общим признакам
А чем уровень доступа не признак?

Цитата Сообщение от Убежденный Посмотреть сообщение
конструкторы-деструкторы
Они как правило всегда public

Цитата Сообщение от Убежденный Посмотреть сообщение
затем public-интерфейс
public

Цитата Сообщение от Убежденный Посмотреть сообщение
дальше перегруженные операторы
Тоже как правило public

Цитата Сообщение от Убежденный Посмотреть сообщение
потом какие-нибудь там internal-методы
начался protected/private

Цитата Сообщение от Убежденный Посмотреть сообщение
потом private-данные
private

Цитата Сообщение от Убежденный Посмотреть сообщение
Если у меня какой-то член данных будет в паблике
Ну-у-у, похоже на весьма редкий случай. Обычно или все члены в public или все в private.



Итого по сути и получается сначала public потом private ( ну и protected если уж куда пихать, так между ними ). По-моему все логично и нисколько не противоречит рекомендации с хабра. Не знаю уж где ты нашел намеки на какую-то абсолютную истину. Разве кто-то утверждает, что данной рекомендации стоит следовать абсолютно всегда? Вроде нет

Цитата Сообщение от Renji Посмотреть сообщение
В C++11 не нужно уже.
Есть еще boost::noncopyable
0
John Prick
831 / 764 / 256
Регистрация: 27.07.2012
Сообщений: 2,176
Завершенные тесты: 3
11.07.2014, 12:32 #18
Цитата Сообщение от Kastaneda Посмотреть сообщение
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
public:
* * // что-нибудь
protected:
* * // что-нибудь
public:
* * // что-нибудь
private:
* * // что-нибудь
protected:
* * // что-нибудь
public:
* * // что-нибудь
// и т.д.
Некто Мэтью Уилсон обожает подобный стиль написания. Каждая логически отдельная секция (например, внутренние тайпдефы, конструкторы, изменяющие/константные методы и т.д.) отделяется через public/private. Ну какой-то смысл в этом есть (хотя можно было бы просто пустой строкой отдлять).

Добавлено через 2 минуты
Цитата Сообщение от Voivoid Посмотреть сообщение
конструкторы-деструкторы
Они как правило всегда public
Неужели? По-моему, 50/50, как минимум.
0
Voivoid
708 / 280 / 15
Регистрация: 31.03.2013
Сообщений: 1,339
11.07.2014, 12:48 #19
Цитата Сообщение от John Prick Посмотреть сообщение
Ну какой-то смысл в этом есть (хотя можно было бы просто пустой строкой отдлять).
По-моему фигня какая-то. Вот внутри секции доступа имеет смысл разбивать объявления на логические группы ( скажем сначала typedef'ы, потом enum'ы, потом виртуальные функции и т. д. )

Цитата Сообщение от John Prick Посмотреть сообщение
Неужели? По-моему, 50/50, как минимум.
Не знаю как у тебя такие числа получились. Разве что за счет некопируемых классов. В этом случае да, имеет смысл воткнуть private конструктор на самый верх ( сам я кстати предпочитаю boost::noncopyable ), но это на мой взгляд скорее исключение подтверждающее правило. Ведь никто не писал, что надо отключать голову и тупо следовать рекомендациям, нет ведь?
0
John Prick
831 / 764 / 256
Регистрация: 27.07.2012
Сообщений: 2,176
Завершенные тесты: 3
11.07.2014, 12:52 #20
Цитата Сообщение от Voivoid Посмотреть сообщение
Не знаю как у тебя такие числа получились.
Я о том, что конструкторы и деструкторы, по твоему же собственному выражению, "как правило всегда" public. Это далеко не так, на мой взгляд.
0
11.07.2014, 12:52
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
11.07.2014, 12:52
Привет! Вот еще темы с решениями:

Наследования класса как public, private и protected
Ну допустим у нас есть класс который наследуется как public: class Cylinder...

Для чего нужны модификаторы protected, private, public
подскажите, кто в курсе, зачем вообще нужны эти модификаторы доступа? ведь,...

Классы, назначение спецификаторов доступа private, protected
Зачем в классах параметры доступа private, protected?Если можно написать все в...

Для чего нужно protected и private наследование
для чего нужно protected и private наследование.


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
20
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Рейтинг@Mail.ru