Параметры, передаваемые методу с аннотацией @Query
, должны использоваться в запросе, в вашем примере это должно выглядеть примерно так:
@Query(value = "SELECT c FROM Child c where c.parent.id =:id")
public List<Child> findChildById(@Param("id") String id);
Определена ли функция в заголовочном файле? Таким образом, фактический код дается непосредственно в функции, например, так:
static int addTwo(int x)
{
return x + 2;
}
Тогда это просто способ предоставления полезной функции для множества различных C-файлов. Каждый файл C, который включает в себя заголовок, получит свое собственное определение, которое он может вызвать. Это, конечно, тратит впустую память, и (на мой взгляд) это довольно уродливая вещь, так как наличие исполняемого кода в заголовке, как правило, не очень хорошая идея.
Помните, что #include
: ing заголовок в основном просто вставляет содержимое заголовка (и любые другие заголовки, включенные в него) в файл C, как это видит компилятор. Компилятор никогда не знает, что одно конкретное определение функции взято из заголовочного файла.
ОБНОВЛЕНИЕ : Во многих случаях это хорошая идея сделать что-то подобное выше, и я понимаю, что мой ответ звучит очень черно-белым об этом, что немного упрощает вещи. Например, код, который моделирует (или просто использует) встроенные функции , может быть выражен, как указано выше, и с явным ключевым словом inline
даже:
static inline int addTwo(int *x)
{
__add_two_superquickly(x);
}
Здесь __ add_two_superquickly ()
функция является вымышленной, и, поскольку мы хотим, чтобы вся функция в основном компилировалась в одну инструкцию, мы действительно хотим, чтобы она была встроенной. Тем не менее, вышеупомянутое является более чистым, чем использование макроса.
Преимущество перед простым использованием встроенной функции, конечно, состоит в том, что обертывание его в другом уровне абстракции позволяет создавать код на компиляторах, в которых отсутствует эта конкретная встроенная функция.
Он будет эффективно создавать отдельную статическую функцию с тем же именем внутри каждого файла cpp, в который он включен. То же относится и к глобальным переменным.
As others are saying, it has exactly the same meaning as a static
function in the .c
file itself. This is because there is no semantic difference between .c
and .h
files; there is only the compilation unit made up of the file actually passed to the compiler (usually named .c
) with the contents of any and all files named in #include
lines (usually named .h
) inserted into the stream as they are seen by the preprocessor.
The convention that the C source is in a file named .c
and public declarations are in files named .h
is only a convention. But it is generally a good one. Under that convention, the only things that should appear in .h
files are declarations so that you generally avoid having the same symbol defined more than once in a single program.
In this particular case, the static
keyword makes the symbol be private to the module, so there isn't a multiple-definition conflict waiting to cause trouble. So in that one sense, it is safe to do. But in the absence of a guarantee that the function would be inlined, you take the risk that the function would be instantiated in every module that happened to #include
that header file which at best is a waste of memory in the code segment.
I am not certain of what use cases would justify doing this at all in a generally available public header.
If the .h
file is generated code and only included in a single .c
file, then I would personally name the file something other than .h
to emphasize that it isn't actually a public header at all. For example, a utility that converts a binary file into an initialized variable definition might write a file that is intended to be used via #include
and could very well contain a static
declaration of the variable, and possibly even static
definitions of accessor or other related utility functions.
Нет семантической разницы в определении в исходном файле или файле заголовка, в основном оба означают одно и то же в простом C при использовании ключевого слова static, которое ограничивает область видимости.
Однако есть проблема при записи этого в файл заголовка, потому что каждый раз, когда вы включаете заголовок в исходный файл, вы У меня будет копия функции с той же реализацией, которая очень похожа на обычную функцию, определенную в файле заголовка. Добавляя определение в заголовок, вы не достигнете того, для чего предназначена статическая функция.
Поэтому я предлагаю вам иметь свою реализацию только в исходном файле, а не в заголовке.