Что означает combaccessrules в Eclipse classpath?
Способ иметь отдельную реализацию выглядит следующим образом.
//inner_foo.h
template <typename T>
struct Foo
{
void doSomething(T param);
};
//foo.tpp
#include "inner_foo.h"
template <typename T>
void Foo<T>::doSomething(T param)
{
//implementation
}
//foo.h
#include <foo.tpp>
//main.cpp
#include <foo.h>
inner_foo имеет форвардные объявления. foo.tpp имеет реализацию и включает inner_foo.h; и foo.h будет иметь только одну строку, чтобы включить foo.tpp.
Во время компиляции содержимое foo.h копируется в foo.tpp, а затем весь файл копируется в foo.h после который он компилирует. Таким образом, ограничений нет, и именование согласовано в обмен на один дополнительный файл.
Я делаю это, потому что статические анализаторы для кода разбиваются, когда он не видит передовые объявления класса в * .tpp. Это раздражает при написании кода в любой среде IDE или с помощью YouCompleteMe или других.
3 ответа
При правильном использовании правил доступа вы можете предотвратить использование "внутренних" и / или "не-api" классы и методы. Когда вы добавляете класс или пакет как Forbidden или Discouraged , компилятор показывает ошибку или предупреждение, когда вы используете этот класс или класс из указанного пакета. Для более подробного ознакомления с правилами доступа вы должны прочитать эту короткую статью .
Для использования комбинированных правил доступа представьте следующую ситуацию:
- У вас есть 2 проекта, A и B.
- На сайте classpath проекта A есть экспортированный файл jar. Jar содержит несколько общедоступных классов «стабильный api», «нестабильный api» и «не-api».
- Проект B зависит от проекта A.
Вы не разрешаете использовать классы «не-api» в проекте A, поэтому вы устанавливаете некоторые Запрещенные правила доступа для этих классов / пакетов.
В проекте B вы не разрешаете использовать «не- api ", но вы хотите получать предупреждение при использовании" нестабильного api ". В этом случае в проекте B вам нужно только установить дополнительные правила доступа Discouraged , если вы отметите Combine rules с правилами доступа для экспортированных записей проекта .
хотя я никогда не использовал его сам, но можно найти немного здесь .
следует ли комбинировать правила доступа экспортируемых записей проекта с правилами доступа этой записи
, правила доступа будут выглядеть примерно так: «com / tests / **»
Правила доступа - удобные мелочи, но опасные. Они исключают исходный файл из компилятора проекта, но оставляют файл нетронутым в файловой системе.
Проект, над которым я работаю, имеет класс начальной загрузки в одной из наших исходных папок, но если мы включим всю папку, путь к классам проекта выиграл » t compile (это долгая история, и процесс сборки справляется с этим).
Итак, мы используем правило доступа eclipse, чтобы исключить его, и это никогда не беспокоит нас во время разработки. Это означает, что мы не можем легко изменить код, но это один из тех классов, который буквально не затрагивался годами.
Правила доступа Combine, судя по JavaDoc, являются реальным вариантом использования на границе. Для его использования вам понадобятся: