Как построить большой проект C ++ с несколькими внутренними зависимостями с Cmake? [Дубликат]
Для тех, кто использует CanCanCan:
Вы получите эту ошибку, если CanCanCan не сможет найти правильный метод params.
Для действия :create CanCan попытается инициализировать новый экземпляр с дезинфицированным вводом, если ваш контроллер будет реагировать на следующие методы (по порядку):
-
create_params -
_params -
resource_params(универсальный метод, который вы могли бы указать в каждом контроллере)
Кроме того, load_and_authorize_resource теперь можно использовать возьмите опцию param_method, чтобы указать пользовательский метод в контроллере для запуска для дезинфекции ввода.
Вы можете связать параметр param_method с символом, соответствующим имени метода, который будет вызван:
class ArticlesController < ApplicationController
load_and_authorize_resource param_method: :my_sanitizer
def create
if @article.save
# hurray
else
render :new
end
end
private
def my_sanitizer
params.require(:article).permit(:name)
end
end
источник: https://github.com/CanCanCommunity/cancancan#strong-parameters
1 ответ
Чтобы сделать одно ясно: вы a.cpp скомпилированы в lib «A». Это означает, что любому пользователю A нужно будет указать target_link_libraries с A. Никоим образом не обойти его. Если у вас 10 приложений, использующих A, вам нужно будет указать target_link_libraries десять раз.
Мой ответ касается второй проблемы вашего вопроса, и я считаю, что это более важно:
Как избавиться от цепочки включений?
Включив ah в bh и используя свой метод в bh, вы добавляете «неявную» зависимость. Как вы заметили, любой пользователь b.h также нуждается в a.h. Вообще говоря, существует два подхода.
Хороший подход:
Это не имеет ничего общего с CMake, но касается инкапсуляции. Пользователям вашей библиотеки (включая вас самих) не нужно беспокоиться о ее внутренней реализации. Это означает: не включать b.h в a.h.
Вместо этого переместите include в файл .cpp. Таким образом, вы нарушаете цепочку. Например. что-то вроде
// b.h
void f();
struct X
{
void g();
};
// b.cpp
#include b.h
#include a.h
void X::g( )
{
f();
}
Таким образом, использование a.h «содержится» в файле cpp, и любой, кто использует вашу библиотеку, должен включать только b.h и ссылку на b.lib.
Альтернатива:
Теперь есть ситуации, когда вам приходится принимать такую «зависимость» или где она является сознательным выбором. Например. когда у вас нет контроля над A или когда вы решили создать библиотеку, определенную в терминах классов / структур, внутренних для A.
В этом случае я предлагаю вам написать кусок кода CMake, который подготавливает все необходимые включенные в цепочку. Например. определите переменную «YOURLIB_INCLUDES» и «YOURLIB_LIBRARIES» в «YourLibConfig.cmake» и укажите, что любой пользователь вашей библиотеки должен импортировать «YourLibConfig.cmake». Это подход, который берут на себя несколько проектов на основе cmake. Например. OpenCV устанавливает файл OpenCVConfig.cmake, VTK устанавливает VTKConfig.cmake и подготавливает файл UseVTK.cmake