几天前，当我不得不将C ++文件引入Java项目时，我遇到了一个问题。它首先需要测量Java进程的CPU使用率，并决定使用JNI来调用用C编写的本机库（Unix机器上的共享库）。问题是找到一个合适的位置将C文件放入源存储库（顺便说一下Clearcase），它只包含Java文件。
我想到了几个选择：
（a）创建一个单独的目录，用于将C文件（特别是一个.h文件和一个.c文件）放在源代码库的顶部，如：
/的VOB / myProduct的/ javasrc /的VOB / myProduct的/ cppsrc
我不喜欢这个，因为我只有两个C文件，在这样的语言级别拆分源代码库似乎很奇怪。如果项目的大部分内容在C ++和Java中或多或少地写得相同，那么这可能没问题。
（b）将C文件放入使用它的Java包中。
我在/ vobs / myproduct / com / mycompany / myproduct / util /中调用了Java类，C文件也在那里。
我不喜欢这个，因为我认为C文件不属于Java包。
以前有人解决过这样的问题吗？通常，在组织混合两种或更多种语言的代码库时，要遵循什么样的策略？
更新：我没有计划在我的项目中使用任何C或C ++，也许是一些Jython，但你永远不知道我的客户何时需要一个只能通过使用C解决的功能或者最好用C解决
答案 0 :(得分：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
我想这是个人品味的问题，但上述结构相当普遍，我认为一旦你习惯它就会很好用。
答案 1 :(得分：4)
Maven为网络应用生成的默认布局为src/main/java，src/test/java，src/main/resources和src/test/resources。我认为它也会默认添加src/main/cpp和src/test/cpp。这对我来说似乎是一个不错的约定。
答案 2 :(得分：1)
将它们保存在单独的文件夹中是个好主意。它比查找C文件的Java包更容易找到它，并且它还允许在将来添加更多C代码而不必在以后全部移动它。
答案 3 :(得分：0)
就个人而言，我将两者分开，甚至可能分成他们自己独立的项目，但那时他们都是分开的事情，就像你不会在同一个班级中放入两个不同的概念一样。当它们都触及相同的概念区域时，它会变得更加模糊。当然，在构建代码时总会出现问题，例如将其放在结构b）中是否可能，而不需要做各种各样的技巧来编译代码？您是否计划在项目中使用更多C，在这种情况下，如果您遵循相同的模式，C文件将遍布整个项目......
答案 4 :(得分：0)
就分裂语言解决方案而言，我会将它们保存在单独的项目或文件夹中。
查看问题的一种方法是像对待任何其他第三方API一样对待C类。在java代码中输出依赖项（即避免直接调用）以避免紧密耦合并将C源保存在java的单独项目/文件夹中。
答案 5 :(得分：0)
让我们使用不同的术语。有一个产品不是项目。该产品由Java工作区和C / C ++工作区组成，每个工作区可从不同的IDE加载。最终，如果您使用同一个IDE，则只有一个工作区。 每个工作区由几个项目组成。每个项目都有自己的文件夹结构（src，bin，res，e.t.c）。因此，如果它只是一个工作区，那么最好至少有一个Java和一个C / C ++项目，每个项目都有不同的编译/运行/调试/输出/ ......设置。
所以，我会用：
Product/Workspace(1)/JavaProject1/src
Product/Workspace(1)/JavaProject2/src
Product/Workspace(1 or 2)/CPPproject1/src
Product/Workspace(1 or 2)/CPPproject2/src ...
这样，您最终可以为每个项目使用同一个文件夹结构，这样更加一致。基本上这只是一个抽象层次 - 将产品划分为不同的相关项目。
答案 6 :(得分：0)
在这种情况下，所讨论的文件不仅仅是一种不同的语言，而且还作为一个单独的程序运行，该程序通过定义的界面进行交互。这意味着源文件可以被视为一个单独的项目，因此保存在其他地方。
在一个代码库中混合使用C＃和ASP.NET（例如）的.NET项目中的情况不同。在这种情况下，人们如何组织代码？