История изменений

Если я правильно помню, то в С++ за это имеется очень жестокая расплата в виде ограничений на конструктор, из-за которых иногда всю голову сломаешь, чтобы придумать, как создать объект.
Хм... о чём речь? На более-менее конкретном примере можно?

Это было давно. Я точно помню, что проблема была в том, что аргументы конструкторов полей передаются в ограниченной конструкции, где нет контекста и нельзя даже завести переменную. Типа такой:

class TRICKY {
  some_class a;
  other_class& b;
public:
  TRICKY(some_class i, other_class &j) : a(i), b(j)

Естественно, при полном доступе на запись к исходникам иерархии классов это можно обойти, но такой доступ не всегда имеется. И если не задано достаточно удобных конструкторов для some_class и other_class, то ситуация может стать безвыходной.

Опять же, в расте основное удобство как раз в том, что ты не можешь «не проверить указатель» (вернее Option).

С этим я не спорю.

Я ищу ответ на вопрос, почему написанный на Расте код обработки ошибок столь страшен.

И вижу причину в enum-ах. Если отделить возврат и ошибку (передавать её хоть через указатель, как бывает в С), то будет проще, мне кажется. Но это нужно пробовать и проверять.

К сожалению, придётся эту тему свернуть. Я уже забыл статью про обработку ошибок в Расте и теперь её надо читать снова. Наверное, это теперь будет не скоро.

Если я правильно помню, то в С++ за это имеется очень жестокая расплата в виде ограничений на конструктор, из-за которых иногда всю голову сломаешь, чтобы придумать, как создать объект.
Хм... о чём речь? На более-менее конкретном примере можно?

Это было давно. Я точно помню, что проблема была в том, что аргументы конструкторов полей передаются в ограниченной конструкции, где нет контекста и нельзя даже завести переменную. Типа такой:

class TRICKY {
  some_class a;
  other_class& b;
public:
  TRICKY(some_class i, other_class &j) : a(i), b(j)

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

Опять же, в расте основное удобство как раз в том, что ты не можешь «не проверить указатель» (вернее Option).

С этим я не спорю.

Я ищу ответ на вопрос, почему написанный на Расте код обработки ошибок столь страшен.

И вижу причину в enum-ах. Если отделить возврат и ошибку (передавать её хоть через указатель, как бывает в С), то будет проще, мне кажется. Но это нужно пробовать и проверять.

К сожалению, придётся эту тему свернуть. Я уже забыл статью про обработку ошибок в Расте и теперь её надо читать снова. Наверное, это теперь будет не скоро.

Если я правильно помню, то в С++ за это имеется очень жестокая расплата в виде ограничений на конструктор, из-за которых иногда всю голову сломаешь, чтобы придумать, как создать объект.
Хм... о чём речь? На более-менее конкретном примере можно?

Это было давно. Я точно помню, что проблема была в том, что аргументы конструкторов полей передаются в ограниченной конструкции, где нет контекста и нельзя даже завести переменную. Типа такой:

class TRICKY {
  some_class a;
  some_class& b;
public:
  TRICKY(int i, int &j) : a(i), b(j)

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

Опять же, в расте основное удобство как раз в том, что ты не можешь «не проверить указатель» (вернее Option).

С этим я не спорю.

Я ищу ответ на вопрос, почему написанный на Расте код обработки ошибок столь страшен.

И вижу причину в enum-ах. Если отделить возврат и ошибку (передавать её хоть через указатель, как бывает в С), то будет проще, мне кажется. Но это нужно пробовать и проверять.

К сожалению, придётся эту тему свернуть. Я уже забыл статью про обработку ошибок в Расте и теперь её надо читать снова. Наверное, это теперь будет не скоро.

Если я правильно помню, то в С++ за это имеется очень жестокая расплата в виде ограничений на конструктор, из-за которых иногда всю голову сломаешь, чтобы придумать, как создать объект.
Хм... о чём речь? На более-менее конкретном примере можно?

Это было давно. Я точно помню, что проблема была в том, что аргументы конструкторов полей передаются в ограниченной конструкции, где нет контекста и нельзя даже завести переменную. Типа такой:

class TRICKY {
  const int a;
  int& b;
public:
  TRICKY(int i, int &j) : a(i), b(j)

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

Опять же, в расте основное удобство как раз в том, что ты не можешь «не проверить указатель» (вернее Option).

С этим я не спорю.

Я ищу ответ на вопрос, почему написанный на Расте код обработки ошибок столь страшен.

И вижу причину в enum-ах. Если отделить возврат и ошибку (передавать её хоть через указатель, как бывает в С), то будет проще, мне кажется. Но это нужно пробовать и проверять.

К сожалению, придётся эту тему свернуть. Я уже забыл статью про обработку ошибок в Расте и теперь её надо читать снова. Наверное, это теперь будет не скоро.