Questions tagged «headers»

8
在头文件或源文件中记录函数是否更好?
在区分“源”文件和“头文件”(主要是C和C ++)的语言中,最好在头文件中记录函数: (从CCAN窃取) /** * time_now - return the current time * * Example: * printf("Now is %lu seconds since epoch\n", (long)time_now().tv_sec); */ struct timeval time_now(void); 或在源文件中? (从PostgreSQL窃取) /* * Convert a UTF-8 character to a Unicode code point. * This is a one-character version of pg_utf2wchar_with_len. * * No …
86 c++  c  headers 

5
头文件中应该包含什么,不应该包含什么?[关闭]
头文件绝对不应包含哪些内容? 例如,如果我正在使用具有许多常量的已记录的行业标准格式,那么在头文件中定义它们(如果我正在为该格式编写解析器)是否是一种好习惯? 头文件应包含哪些功能? 什么功能不应该?
71 c  headers 

3
为什么我们需要将私有成员放在标题中?
私有变量是一种向类用户隐藏复杂性和实现细节的方法。这是一个相当不错的功能。但是我不明白为什么在c ++中我们需要将它们放在类的标题中。我看到这有两个令人讨厌的缺点: 它使用户的标题杂乱无章 每当修改内部结构时,它将强制重新编译所有客户端库 此要求背后是否存在概念上的原因?仅仅是为了简化编译器的工作吗?
62 c++  headers 

4
为什么#include <iostream.h>不好?
我正在阅读另一个线程,一个人向初学者询问有关C ++的书籍,一个回答的程序员写道: 警告:请避免所有带有“ hello world”字样的书都标明 #include &lt;iostream.h&gt; 我打开了我的C ++书,并确定它像上面的示例一样包含iostream标头。 为什么这么糟?学习C ++时,我还应牢记其他哪些指针? 背景:我精通C语言,下学期将开始学习C ++。

3
源代码中的版权声明[关闭]
自从我开始编程以来,我已经在大多数代码文件的顶部看到一个标头,表明某种版权:例如 /* Copyright (c) 1998 Innotech */ 要么 /* Copyright (c) 1998-2008 Innotech */ 从概念上讲,我有主意...取决于您的需求,它大致可在以下两者之间转换: 嘿,看看!我做的!我真棒! 至 请勿复制/重新分发!如果您愿意,我们的律师将追随您! 一方面,我发现整个过程有些幽默,因为通常这是一个内部开发人员都不会看到的文件,但是假设这一行实际上有一天可能“意味着某事”,我对日期部分感到好奇。 单一日期是否暗示作者从该日期起一直享有版权? 如果使用了日期范围,并且没有保持最新状态,那么开发人员是否已超出该日期范围而使自己的版权无效? 如果没有任何其他形式的法律文件-版权标头是否提供任何形式的实际法律效力?还是我们都在自欺欺人。

7
我如何防止标题地狱?
我们正在从头开始一个新项目。大约有八位开发人员,一打左右的子系统,每个子系统都有四个或五个源文件。 我们怎样才能防止“标题地狱”(又名“意大利面条头”)? 每个源文件一个标头? 每个子系统加一个? 从函数原型中分离出typdef,结构和枚举? 将子系统内部与子系统外部分开? 坚持每个文件,无论标头还是源文件都必须是可独立编译的? 我并不是在寻求“最佳”方法,只是要指出要注意什么以及可能引起悲伤的指针,以便我们可以尝试避免这种情况。 这将是一个C ++项目,但是C信息将对将来的读者有所帮助。
44 c++  headers  include 

8
依靠标头包含传递性是一种好习惯吗?
我正在清理正在处理的C ++项目中的包含,并且我一直在想是否应该将直接使用的所有标头明确包含在特定文件中,还是应该仅包含最低要求。 这是一个例子Entity.hpp: #include "RenderObject.hpp" #include "Texture.hpp" struct Entity { Texture texture; RenderObject render(); } (让我们假设对它的前向声明RenderObject不是一种选择。) 现在,我知道其中RenderObject.hpp包括Texture.hpp-我知道,因为每个人RenderObject都有一个Texture成员。不过,我还是明确地将Texture.hppin 包含在内Entity.hpp,因为我不确定依赖于in是一个好主意RenderObject.hpp。 因此:这是一种好的做法吗?
37 c++  c  headers  include 


7
当仅包含.cpp文件时,一切正常时,为什么需要包含.h?
为什么我们需要同时包含.h和.cpp文件,而仅通过包含.cpp文件就可以使其起作用? 例如:创建一个file.h包含声明,然后创建一个file.cpp包含定义,并将两者都包含在中main.cpp。 或者:在中创建一个file.cpp包含声明/定义的声明(没有原型)main.cpp。 两者都为我工作。我看不出有什么区别。也许对编译和链接过程有一些了解可能会有所帮助。
18 c++  c  headers  linking  include 

1
放置API密钥的位置:自定义HTTP标头与自定义方案的Authorization标头
我正在设计一个通过API密钥使用授权/身份验证的REST API。 我试图找出最合适的位置,然后发现许多人建议使用自定义HTTP标头ProjectName-Api-Key,例如: ProjectName-Api-Key: abcde 但在Authorization标头上使用自定义方案也是可能的,从思想上来说也是正确的,例如: Authorization: ApiKey abcde 另一方面,我发现一个考虑,自定义授权方案可能出乎意料,并且不受某些客户端支持,并且无论如何都会导致自定义代码,因此最好使用自定义标头,因为客户对此没有任何期望。 您希望以哪种方式发送API密钥?

4
在C ++中组织接口和实现的方法
我已经看到,在C ++中,关于头文件中的内容和cpp文件中的内容有几种不同的范例。AFAIK,大多数人,尤其是具有C背景的人会: foo.h class foo { private: int mem; int bar(); public: foo(); foo(const foo&amp;); foo&amp; operator=(foo); ~foo(); } foo.cpp #include foo.h foo::bar() { return mem; } foo::foo() { mem = 42; } foo::foo(const foo&amp; f) { mem = f.mem; } foo::operator=(foo f) { mem = f.mem; } foo::~foo() {} …

4
为什么我们需要编写头文件?
在您提出尖刻的评论之前,我知道-这是一个nooby问题。这是我第一次使用基于C的语言。 我是一名本科生,正在学习有关移动开发的计算机科学课程的目标C。我知道,在学术环境中,由于您正在构建较小的项目,在较小的团队中工作等,因此不需要很多现实世界的考虑。 但是我们的教授要求-并且XCode支持-每个.m实现文件的.h头文件。对我来说,这似乎是忙碌的工作。我必须确保将每个方法签名和实例变量都复制到另一个文件中。如果更改一个文件,则必须确保它与另一个文件一致。好像只是一堆小麻烦。 但我知道,必须有一些现实世界中使用的头文件。一个很好的答案将解决这两个问题: 对于不适合实现文件的头文件有什么用?目的是什么? 为什么我们作为程序员必须手动编写头文件?看来它们很容易自动生成。 提前致谢!

3
通过HTTP标头传输访问令牌是否安全?
这是第一个RESTful Web服务,我担心安全性问题。通过HTTP标头传输访问令牌是否安全?例如: POST /v1/i/resource HTTP/1.1 Content-Type: application/x-www-form-urlencoded Api-key: 5cac3297f0d9f46e1gh3k83881ba0980215cd71e Access_token: 080ab6bd49b138594ac9647dc929122adfb983c8 parameter1=foo&amp;parameter2=bar 连接已建立SSL。另外,需要定义什么作为scope每个属性access token


2
在REST API中自定义使用Authorization标头
我正在构建一个REST api,其中使用客户端证书对客户端进行身份验证。在这种情况下,客户端不是单个用户,而是某种表示层。使用自定义方法对用户进行身份验证,表示层有责任确保此方法正确完成(注意:我知道这不是正确的方法,但api不公开)。 我想传递每个请求的用户名(而不是密码),但是我不确定在哪里执行此操作。使用Authorization标头是个好主意吗?
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.