Что делать, если параметры библиотечной функции не постоянны

Question

Большая часть моей кодовой базы неизменна; однако из-за особенностей дизайна языка я не могу пометить свои переменные const.

В подавляющем большинстве случаев, особенно при взаимодействии с кодом C, параметры функций не помечены как const, хотя они, как и предполагалось, не изменяют их. Одним из таких примеров является fts_open (...) . На этом этапе компилятор вынуждает меня утомительно удалять квалификаторы const из больших частей моего кода, тем самым устраняя предложенную им безопасность.

Одним из тривиальных решений является компиляция с -fpermissive, но это полностью противоречит моим намерениям.

Помимо переписывания каждой когда-либо написанной библиотеки C, что я могу сделать, чтобы по-прежнему получать преимущества от использования компилятора?

т.е. этот тип кода не работает:

void function(immutable_type const &param)
{
    char const * const fts_arg[2]{std::data(param.path), nullptr};
    FTS *tree = fts_open(fts_arg, FTS_OPTIONS, nullptr);
    ...
}

На данный момент мне нужно:

• Удалить const из переменной fts_args.
• Удалить const из параметра функции.
• Удалите const из path в определении типа данных.
• Удалить const из переменной, передаваемой в function.
• Рекурсивно удалить const s из всей цепочки вызовов.

Спасибо. :)

Answer 1

Это именно то, для чего const_cast. Если вы абсолютно точно знаете, что функция не изменит указанный / ссылочный объект, тогда все в порядке с const_cast константностью вашего указателя / ссылки, чтобы передать ее в эту функцию, несмотря на обращение к объекту const.

не const_casting из const неопределенного поведения?

Нет. const_cast само по себе никогда не бывает UB. Но изменение объекта const есть. Поэтому, если вы не можете доказать, что функция, принимающая неконстантный указатель / ссылку, не модифицирует объект, тогда небезопасно передавать ссылку const_cast ed в эту функцию.

Также рассмотрите возможность изменения реализации в будущем для использования неконстантности.

---

В случае, если вы не можете доказать, что неконстантально указанный / заостренный объект не будет изменен, вы можете сделать локальную копию константно ссылаемого аргумента вашей функции-оболочки. Издержки этой копии могут быть тривиальными (int) или нетривиальными (long std::vector).

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