Организация исходного кода базируется при смешивании двух или больше языков (как Java и C++)
Этот ответ должен быть довольно коротким и сладким, чтобы ответить (часть) озаглавленного вопроса. Если вы хотите получить более подробный ответ, объясняющий, почему вы должны их там поместить, пожалуйста, перейдите здесь .
Общее правило для размещения typename в основном, когда вы используете параметр шаблона, и хотите получить доступ к вложенному typedef или с использованием псевдонима, например:
template
struct test {
using type = T; // no typename required
using underlying_type = typename T::type // typename required
};
Обратите внимание, что это также относится к метафункциям или вещи, которые также принимают общие параметры шаблона. Однако, если предоставленный параметр шаблона является явным типом, вам не нужно указывать typename, например:
template
struct test {
// typename required
using type = typename std::conditional::type;
// no typename required
using integer = std::conditional::type;
};
Общие правила добавления определителя template в основном аналогичны, за исключением они обычно включают шаблонные функции-члены (статические или другие) структуры / класса, которые сами шаблоны, например:
Учитывая эту структуру и функцию:
template
struct test {
template
void get() const {
std::cout << "get\n";
}
};
template
void func(const test& t) {
t.get(); // error
}
Попытка доступа t.get изнутри функции приведет к ошибке:
main.cpp:13:11: error: expected primary-expression before 'int'
t.get();
^
main.cpp:13:11: error: expected ';' before 'int'
Таким образом, в этом контексте вам понадобится ключевое слово template заранее и вызвать его так:
t.template get
Таким образом, компилятор будет анализировать это правильно, а не t.get < int.
7 ответов
"Мне не нравилось это, потому что у меня есть только два файла C, и это казалось очень нечетным для разделения исходной основы на уровне языка как это"
Почему это кажется нечетным? Рассмотрите этот проект:
project1\src\java project1\src\cpp project1\src\python
Или, если Вы решаете разделить вещи на модули:
project1\module1\src\java project1\module1\src\cpp project1\module2\src\java project1\module2\src\python
Я предполагаю, что это - вопрос персонального вкуса, но вышеупомянутая структура довольно распространена, и я думаю, что это работает вполне хорошо, после того как Вы привыкаете к нему.
Сгенерированное Знатоками расположение по умолчанию для веб-приложений src/main/java, src/test/java, src/main/resources, и src/test/resources. Я предположил бы, что это примет значение по умолчанию к добавлению src/main/cpp и src/test/cpp также. Это походит на достаточно достойную конвенцию мне.
Хранение их в отдельных папках является хорошей идеей. Это помогает найти, чем ищущие пакеты Java для файлов C, и это также допускает возможность добавления большего количества кода C в будущем, не имея необходимость переместить все это позже.
Лично в случае решений для языка разделения, я сохранил бы их в отдельных проектах или папках.
Один способ посмотреть на проблему состоит в том, чтобы рассматривать классы C как любое другое третье лицо API. Соедините интерфейсом с зависимостями (т.е. избегайте прямых вызовов) в Вашем коде Java, чтобы избежать плотного соединения и сохранить источник C в отдельном проекте/папке от Java.
Лично я разделил бы эти два, возможно даже в их собственные отдельные проекты, но именно тогда они - оба отдельные вещи, во многом как Вы не поместил бы два различных понятия в тот же класс. Это, становятся намного более неопределенными, когда они оба касаются той же концептуальной области. Конечно, всегда существуют проблемы когда дело доходит до создания кода, помещает его в структуру b) возможный, например, не будучи должен сделать все виды приемов, чтобы заставить его компилировать? Вы - планирование использования большего количества C в проекте, в этом случае файлы C распространить на всем протяжении Вашего проекта, если Вы следуете за тем же шаблоном...
Давайте использовать другую терминологию. Существует один продукт, который не является проектом. Продукт состоит из рабочей области Java и рабочей области C/C++, каждый загружаемый от различного IDE. В конечном счете при использовании одного и того же IDE будет только одна рабочая область. Каждая рабочая область состоит из нескольких проектов. Каждый проект имеет свою собственную структуру папок (src, мусорное ведро, res, e.t.c). Таким образом в случае, если это - только одна рабочая область, затем лучше иметь по крайней мере один Java и один проект C/C++ внутри, каждого с различным compile/run/debug/output/... настройки.
Так, я использовал бы:
Product/Workspace(1)/JavaProject1/src
Product/Workspace(1)/JavaProject2/src
Product/Workspace(1 or 2)/CPPproject1/src
Product/Workspace(1 or 2)/CPPproject2/src ...
Таким образом, можно использовать в конечном счете одну и ту же структуру папок для каждого проекта, который более последователен. В основном это - просто еще один уровень абстракции - деление продукта к различным связанным проектам.
В этом случае рассматриваемые файлы не являются просто другим языком, но также и выполненный как отдельная программа, которая взаимодействует через определенный интерфейс. Это означает, что исходные файлы можно рассматривать как отдельный проект и поэтому сохранить в другом месте.
Случай отличается в проектах.NET, которые смешивают C# и ASP.NET (например), в одной кодовой базе. Как люди организуют свой код в таких случаях?