Достало писать кучу boilerplate'а - C/C++

Достало писать кучу boilerplate'а.

В старом недобром С++03 нужно для классов было определять: копирующий констркутор, конструктор по умолчанию, оператор присваивания. Ещё терпимо. В С++11 сюда ещё добавился конструктор перемещения и оператор присваивания с перемещением. Уже достаёт — в классе из четырёх строчек получается строк 20 стандартного кода.

А ещё есть операторы сравнения и присваивания. Что есть хорошего, разумного, вечного для одоления этого недуга?

Заодно вечная проблема с дублирующимися методами:

  const std::string& get_str() const { return str_; }
  std::string& get_str() { return str_; }

тоже уже достала.

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

C>В старом недобром С++03 нужно для классов было определять
Не нужно, а можно. И если поведение должно отличаться от дефолтового, то что иначе как не писать код? Компиляторы других языков читают мысли программиста?

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

C>Достало писать кучу boilerplate'а.
C>Что есть хорошего, разумного, вечного для одоления этого недуга?

Есть Java, C# и другие удобные языки.

Через 3 недели как-никак 2012 год наступит. Кто еще пишет low-level в век, когда космические корабли бороздят просторы Большого Театра?

в гугл-стайл большинство классов включают макрос DISALLOW_COPY_AND_ASSIGN или DISALLOW_EVIL_CONSTRUCTORS

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

C>>В старом недобром С++03 нужно для классов было определять
Х>Не нужно, а можно. И если поведение должно отличаться от дефолтового, то что иначе как не писать код? Компиляторы других языков читают мысли программиста?
Да, я подразумеваю value-классы, понятное дело.

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

D>в гугл-стайл большинство классов включают макрос DISALLOW_COPY_AND_ASSIGN или DISALLOW_EVIL_CONSTRUCTORS
Плевать на гугл-стайл.

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

C>Достало писать кучу boilerplate'а.

C>В старом недобром С++03 нужно для классов было определять: копирующий констркутор, конструктор по умолчанию, оператор присваивания. Ещё терпимо. В С++11 сюда ещё добавился конструктор перемещения и оператор присваивания с перемещением. Уже достаёт — в классе из четырёх строчек получается строк 20 стандартного кода.

в С++11 добавили "=default;"

Что качается остального, единственный вариант — это переходить на другой язык. Или принять реальность такой какая она есть, и не писать сюда того что и без вас все знают. Да, все ненавидят С++, но юзают его потому что других вариантов-то сейчас нету.

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

C>>В старом недобром С++03 нужно для классов было определять: копирующий констркутор, конструктор по умолчанию, оператор присваивания. Ещё терпимо. В С++11 сюда ещё добавился конструктор перемещения и оператор присваивания с перемещением. Уже достаёт — в классе из четырёх строчек получается строк 20 стандартного кода.
A>в С++11 добавили "=default;"
Вот как раз то что нужно. Жаль, что в MSVC не поддерживается.

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

C>В старом недобром С++03 нужно для классов было определять: копирующий констркутор, конструктор по умолчанию, оператор присваивания. Ещё терпимо. В С++11 сюда ещё добавился конструктор перемещения и оператор присваивания с перемещением. Уже достаёт — в классе из четырёх строчек получается строк 20 стандартного кода.

А шо делать?

C>А ещё есть операторы сравнения и присваивания. Что есть хорошего, разумного, вечного для одоления этого недуга?

Visual Assist для генерации объявлений в хедере и заглушек реализации в *.cpp
Особенно удобно при подходе, кода одна пара *.h/*.cpp определяет один класс и имя класса совпадает с именем файла.

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

C>>В старом недобром С++03 нужно для классов было определять: копирующий констркутор, конструктор по умолчанию, оператор присваивания. Ещё терпимо. В С++11 сюда ещё добавился конструктор перемещения и оператор присваивания с перемещением. Уже достаёт — в классе из четырёх строчек получается строк 20 стандартного кода.
L>А шо делать?
Набросал макросы пока что. Что-то типа такого получается:

struct point {
  int x, y;

  DEF_VALUE_OBJECT(point, (x)(y));
};

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

L>>А шо делать?
C>Набросал макросы пока что. Что-то типа такого получается:
C>

C>struct point {
C>  int x, y;

C>  DEF_VALUE_OBJECT(point, (x)(y));
C>};
C>

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

= default;

C> Уже достаёт — в классе из четырёх строчек получается строк 20 стандартного кода.

C>А ещё есть операторы сравнения и присваивания. Что есть хорошего, разумного, вечного для одоления этого недуга?

= default

C>Заодно вечная проблема с дублирующимися методами:
C>

C>  const std::string& get_str() const { return str_; }
C>  std::string& get_str() { return str_; }
C>

C>тоже уже достала.

Ну тут извините, совершенно разное использование подразумевается. Неконстантный get_str это уже не геттер вовсе, он подразумевает что строку будут таким образом менять.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>А ещё есть операторы сравнения и присваивания. Что есть хорошего, разумного, вечного для одоления этого недуга?

дык известно что -- макросы.
ну, про =default уже писали.

C>Заодно вечная проблема с дублирующимися методами:
C>тоже уже достала.

макрос на объявление свойства.

On 12/14/2011 01:57 AM, Cyberax wrote:

> В старом недобром С++03 нужно для классов было определять: копирующий
> констркутор, конструктор по умолчанию, оператор присваивания. Ещё терпимо. В
> С++11 сюда ещё добавился конструктор перемещения и оператор присваивания с
> перемещением. Уже достаёт — в классе из четырёх строчек получается строк 20
> стандартного кода.

Так это ж не в каждом классе нужно писать. И конструкторы, и операторы
присваивания нужно писать только там, где это реально нужно.

Posted via RSDN NNTP Server 2.1 beta

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

C>

C>struct point {
C>  int x, y;

C>  DEF_VALUE_OBJECT(point, (x)(y));
C>};
C>

Я так понимаю, что DEF_VALUE_OBJECT разворачивается в частности в get_point/set_point. А зачем, если поля и так открыты для прямого доступа?

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

C>Заодно вечная проблема с дублирующимися методами:
C>

C>  const std::string& get_str() const { return str_; }
C>  std::string& get_str() { return str_; }
C>

Перегружать разные по логике методы — это диверсия.

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

A>Перегружать разные по логике методы — это диверсия.
Это не диверсия, а не более чем перверсия, родом из STL (см. begin(), end(), front(), back())

Её смысл — только в углублении константности.
У прямых членов-данных константность глубокая (константность хозяина влечёт константность элементов), у косвенных (включая вычисляемые) — поверхностная. Если хочется эмулировать глубокую константность для косвенных членов, приходится делать вот так.

Заметим, что в примере с get_str мы не снимаем константность, а накладываем, т.е. делаем более строгий контракт.
Предположительно, str_ объявлен как string& либо mutable string.

Cyberax:

C>Заодно вечная проблема с дублирующимися методами:
C>

C>  const std::string& get_str() const { return str_; }
C>  std::string& get_str() { return str_; }
C>

C>тоже уже достала.

Я собирался предложить комитету ввести параметризуемые cv-квалификаторы и соответствующий вывод аргументов в шаблонах

namespace std {

    enum const_qualification { non_const_q, const_q };
    enum volatile_qualification { non_volatile_q, volatile_q };

    template <class Container>
        using iterator_of =
            typename conditional<is_const<Container>{}, typename Container::const_iterator, typename Container::iterator>::type;

}


template <class T>
    class Vector
{
    using iterator = T *;
    using const_iterator = T const *;

    template <std::const_qualification cq>
        using iterator_type = std::iterator_of<Vector const<cq>>;

    template <std::const_qualification cq>
        iterator_type<cq> begin() const<cq>;

    const_iterator cbegin() const
    {
        return begin<std::const_q>();
    }

    template <std::const_qualification cq>
        T const<cq> &front() const<cq>;

    // ...
};

но пока не знаю, стоит ли.

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

M>Cyberax:

C>>Заодно вечная проблема с дублирующимися методами:
C>>

C>>  const std::string& get_str() const { return str_; }
C>>  std::string& get_str() { return str_; }
C>>

C>>тоже уже достала.

M>Я собирался предложить комитету ввести параметризуемые cv-квалификаторы и соответствующий вывод аргументов в шаблонах

M>    template <std::const_qualification cq>
M>        iterator_type<cq> begin() const<cq>;

M>но пока не знаю, стоит ли.

как то хрево выглядит. нам точно нужен именованный параметр?
что-нибудь вроде:

     iterator_type< Vector auto > begin() auto;
     T auto & front() auto;

не подойдет?

	От:	Cyberax
	Дата:	13.12.11 21:57
	Оценка:

	От:	Хвост
	Дата:	13.12.11 22:07
	Оценка:	+1

	От:	DorfDepp
	Дата:	13.12.11 22:09
	Оценка:

	От:	dilmah
	Дата:	13.12.11 22:11
	Оценка:

	От:	Cyberax
	Дата:	13.12.11 22:35
	Оценка:

	От:	night beast
	Дата:	14.12.11 03:45
	Оценка:	+1

	От:	MasterZiv
	Дата:	14.12.11 05:41
	Оценка:

	От:	alsemm
	Дата:	14.12.11 06:28
	Оценка:

	От:	alsemm
	Дата:	14.12.11 06:30
	Оценка: