c++ class 没有 header
c++ class without header
好的,所以我没有问题,但是有一个问题:
使用c++时,可以将class传输到另一个文件并包含它而不创建header,像这样:
foo.cpp :
#include <iostream>
using namespace std;
class foo
{
public:
string str;
foo(string inStr)
{
str = inStr;
}
void print()
{
cout<<str<<endl;
}
};
main.cpp :
#include "foo.cpp"
using namespace std;
int main()
{
foo Foo("That's a string");
Foo.print();
return 0;
}
所以问题是:这种方法比使用 header 文件差吗?它更容易也更干净,但它是否更慢,更多 bug-inducing 等?
我已经搜索了这个主题很长时间了,但考虑到这个甚至是一个选项,我在互联网上还没有看到一个主题...
将文件命名为 .cpp
或 .hpp
(或 .c
/ .h
)之间没有语义差异。
人们会对#include "foo.cpp"
感到惊讶,编译器不关心
您仍然创建了一个 "header file",但您已为其指定了“.cpp”扩展名。文件扩展名是给程序员的,编译器不关心。
从编译器的角度来看,你的例子和
没有区别
foo.h :
#include <iostream>
using namespace std;
class foo
{
//...
};
main.cpp :
#include "foo.h"
using namespace std;
int main()
{
// ...
}
A "header file" 只是一个包含在开头的文件,即另一个文件的头部(从技术上讲,headers 不需要在开头,但有时不需要通常它们是,因此得名)。
您刚刚创建了一个名为 foo.cpp
的 header 文件。
使用通常用于源文件的扩展名命名 header 文件不是一个好主意。某些 IDE 和其他工具可能会错误地假设您的 header 是一个源文件,因此尝试编译就好像它是源文件一样,如果没有别的就是浪费资源。
更不用说它可能给您的同事带来的困惑了。源文件可能具有 C++ 标准允许仅定义一次的定义(请参阅一个定义规则,odr),因为源文件不包含在其他文件中。如果您将 header 命名为源文件,有人可能会认为他们可以在那里拥有 odr 定义,而实际上他们不能。
So the question is: is this method any worse than using header files?
您可以考虑复习一下 "C++ translation unit" 的中心思想。
在您的示例中,预处理器所做的就像将 foo.cpp 的副本插入到 main.cpp 的内部副本中一样。预处理器执行此操作,而不是编译器。
所以...当它们是单独的文件时,编译器永远不会看到您的代码。提交给编译器的正是这个单一的、串联的 'translation unit'。 .hh 和 .cc 没有什么神奇之处,只是它们满足您同事(或老板)的期望。
现在想想你的问题……翻译单元既不是你的源文件,也不是你的任何系统包含文件,而是一个文本流,一个东西,由预处理器放在一起。那么它会更好还是更坏呢?
It's much easier and much more clean,
可以。在我的 'private' 编码工作中,我经常采用这种 'different' 方法。
当我快速评估在阶乘中使用 gmpxx.h (mpz_class) 时,我确实采用了这些快捷方式,并且不需要 .hpp 文件来正确创建我的编译单元。仅供参考 - 12345 的阶乘超过 45,000 字节。读字符也是没有意义的。
A 'more formal' 的努力(工作、合作等),我总是使用 header 的,并单独编译,并构建一个对应用程序有用的函数库作为其中的一部分事情应该做。特别是如果我可能会共享此代码或为公司档案做出贡献。我有太多充分的理由来描述为什么我建议你学习这些问题。
but is it any slower, any more bug-inducing etc?
我认为不是。我觉得不是。编译单元只有一个,拼接起来一定要对,不过我觉得不难。
I've searched for this topic for a long time now but I haven't seen a single
topic on the internet considering this even an option...
我也不确定我是否见过有人讨论过它。我已经获得了信息。单独的编译和库开发通常被认为可以节省开发时间。 (时间就是金钱,对吧?)
此外,图书馆和 header 文件是您打包成功供他人使用的方式,以及您如何提高您对团队的价值的方式。
如果您曾经构建过一些更大的项目,您将会清楚两个主要区别:
如果您将您的代码作为库提供给其他人,您必须向他们所有您的代码 - 您所有的 IP - 而不仅仅是 [=公开的 类 的 28=] 加上已编译的库。
如果您更改任何文件中的一个字母,您将需要重新编译所有内容。一旦大型项目的编译时间达到几分钟,您的工作效率就会大大降低。
否则当然行,结果一样
好的,所以我没有问题,但是有一个问题: 使用c++时,可以将class传输到另一个文件并包含它而不创建header,像这样:
foo.cpp :
#include <iostream>
using namespace std;
class foo
{
public:
string str;
foo(string inStr)
{
str = inStr;
}
void print()
{
cout<<str<<endl;
}
};
main.cpp :
#include "foo.cpp"
using namespace std;
int main()
{
foo Foo("That's a string");
Foo.print();
return 0;
}
所以问题是:这种方法比使用 header 文件差吗?它更容易也更干净,但它是否更慢,更多 bug-inducing 等? 我已经搜索了这个主题很长时间了,但考虑到这个甚至是一个选项,我在互联网上还没有看到一个主题...
将文件命名为 .cpp
或 .hpp
(或 .c
/ .h
)之间没有语义差异。
人们会对#include "foo.cpp"
感到惊讶,编译器不关心
您仍然创建了一个 "header file",但您已为其指定了“.cpp”扩展名。文件扩展名是给程序员的,编译器不关心。
从编译器的角度来看,你的例子和
没有区别foo.h :
#include <iostream>
using namespace std;
class foo
{
//...
};
main.cpp :
#include "foo.h"
using namespace std;
int main()
{
// ...
}
A "header file" 只是一个包含在开头的文件,即另一个文件的头部(从技术上讲,headers 不需要在开头,但有时不需要通常它们是,因此得名)。
您刚刚创建了一个名为 foo.cpp
的 header 文件。
使用通常用于源文件的扩展名命名 header 文件不是一个好主意。某些 IDE 和其他工具可能会错误地假设您的 header 是一个源文件,因此尝试编译就好像它是源文件一样,如果没有别的就是浪费资源。
更不用说它可能给您的同事带来的困惑了。源文件可能具有 C++ 标准允许仅定义一次的定义(请参阅一个定义规则,odr),因为源文件不包含在其他文件中。如果您将 header 命名为源文件,有人可能会认为他们可以在那里拥有 odr 定义,而实际上他们不能。
So the question is: is this method any worse than using header files?
您可以考虑复习一下 "C++ translation unit" 的中心思想。
在您的示例中,预处理器所做的就像将 foo.cpp 的副本插入到 main.cpp 的内部副本中一样。预处理器执行此操作,而不是编译器。
所以...当它们是单独的文件时,编译器永远不会看到您的代码。提交给编译器的正是这个单一的、串联的 'translation unit'。 .hh 和 .cc 没有什么神奇之处,只是它们满足您同事(或老板)的期望。
现在想想你的问题……翻译单元既不是你的源文件,也不是你的任何系统包含文件,而是一个文本流,一个东西,由预处理器放在一起。那么它会更好还是更坏呢?
It's much easier and much more clean,
可以。在我的 'private' 编码工作中,我经常采用这种 'different' 方法。
当我快速评估在阶乘中使用 gmpxx.h (mpz_class) 时,我确实采用了这些快捷方式,并且不需要 .hpp 文件来正确创建我的编译单元。仅供参考 - 12345 的阶乘超过 45,000 字节。读字符也是没有意义的。
A 'more formal' 的努力(工作、合作等),我总是使用 header 的,并单独编译,并构建一个对应用程序有用的函数库作为其中的一部分事情应该做。特别是如果我可能会共享此代码或为公司档案做出贡献。我有太多充分的理由来描述为什么我建议你学习这些问题。
but is it any slower, any more bug-inducing etc?
我认为不是。我觉得不是。编译单元只有一个,拼接起来一定要对,不过我觉得不难。
I've searched for this topic for a long time now but I haven't seen a single topic on the internet considering this even an option...
我也不确定我是否见过有人讨论过它。我已经获得了信息。单独的编译和库开发通常被认为可以节省开发时间。 (时间就是金钱,对吧?)
此外,图书馆和 header 文件是您打包成功供他人使用的方式,以及您如何提高您对团队的价值的方式。
如果您曾经构建过一些更大的项目,您将会清楚两个主要区别:
如果您将您的代码作为库提供给其他人,您必须向他们所有您的代码 - 您所有的 IP - 而不仅仅是 [=公开的 类 的 28=] 加上已编译的库。
如果您更改任何文件中的一个字母,您将需要重新编译所有内容。一旦大型项目的编译时间达到几分钟,您的工作效率就会大大降低。
否则当然行,结果一样