头文件名 [英] Header file names

问题描述

我有一个标题，其文件名包含一个嵌入的换行符，我不能

似乎#include它成功。我试过了


#include" my

file.h"


和


#include" my\\\
file.h"


但不起作用。


1。我怎样才能实现这个目标？

2.标准是否限制了

源文件名中可出现的字符范围？ （例如，嵌入的标签似乎没有#include行中的

实际制表符）

解决方案

rb********@mailinator.com 写道：
< blockquote class =post_quotes>
我有一个标题，其文件名包含一个嵌入的换行符，我不能

似乎#include它成功。我试过了

所以不要这样做。


-

Ian Collins。

嗯，那将是一个解决方案......但它并不理想 - 我想要

根据我的首选惯例安排我的文件。


我认为#include" ... \ n ..."不起作用因为东西不是
字符串文字，但是由预处理器解释。


我真的不明白为什么预处理器没有读取，然后查找

a关闭，然后将两者之间的所有内容（换行符或不换行）解释为

文件名。这只是gcc实现的一个问题，还是

标准实际上允许编译器对源文件名中允许的字符进行人为限制

？如果是这样，为什么？


Ian Collins写道：

rb ******** @ mailinator.com 写道：

我有一个文件名包含嵌入式换行符的标题而且我不能...... / b $ b似乎#include它成功了。我试过

所以不要这样做。


-

伊恩柯林斯。

关注行边界的编译器块。

预处理器是行 - 导向;它是为数不多的几个之一。

第6.4.7节第1段。可能的原因是在标题名称中禁止使用

，因为你会在
$中找到b $ b Newlines


并说明为什么顶级帖子不受欢迎。

我希望这个答案能满足你的好奇心，

rb********@mailinator.com 写道：

好​​吧，这将是一个解决方案......但它并不理想 - 我想按照我的首选约定来安排我的文件。


我认为#include" ... \ n ..."不起作用因为东西不是
字符串文字，但是由预处理器解释。


我真的不明白为什么预处理器没有读取，然后查找

a关闭，然后将两者之间的所有内容（换行符或不换行）解释为

文件名。这只是gcc实现的一个问题，还是

标准实际上允许编译器对源文件名中允许的字符进行人为限制

？如果是这样，为什么？


Ian Collins写道：

> rb ******** @ mailinator.com 写道：

>>我有一个标题，其文件名包含一个嵌入的换行符，我似乎无法#include它成功。我试过了

所以不要这样做。

-
伊恩柯林斯。

-

Eric Sosman
es ***** @ acm-dot-org.inva 盖子

I have a header whose filename contains an embedded newline and I can''t
seem to #include it successfully. I''ve tried

#include "my
file.h"

and

#include "my\nfile.h"

but neither works.

1. How can I achieve this?
2. Does the Standard limit the range of characters that can appear in
source file names? (for example, embedded tabs seem to be fine with an
actual tab character in the #include line)

解决方案

rb********@mailinator.com wrote:

I have a header whose filename contains an embedded newline and I can''t
seem to #include it successfully. I''ve tried

So don''t do it.

--
Ian Collins.

Well, that would be one solution... but it''s not ideal - I''d like to
arrange my files according to my preferred conventions.

I think that #include "...\n..." doesn''t work because the thing isn''t a
string literal, but is interpreted by the preprocessor.

I really don''t see why the preprocessor doesn''t read a ", then look for
a closing ", then interpret everything in between (newlines or not) as
the filename. Is this just a problem with gcc''s implementation, or does
the Standard actually allow compilers to place artifical restrictions
on the characters allowed in source file names? If so, why?

Ian Collins wrote:

rb********@mailinator.com wrote:

I have a header whose filename contains an embedded newline and I can''t
seem to #include it successfully. I''ve tried

So don''t do it.

--
Ian Collins.

chunks of the compiler that cares about line boundaries.
the preprocessor is line-oriented; it is one of the few
Section 6.4.7 paragraph 1. The likely reason is that
are forbidden in header names, as you will find in
Newlines

and also illustrates why top-posting is unpopular.
I hope this answer satisfies your curiosity,

rb********@mailinator.com wrote:

Well, that would be one solution... but it''s not ideal - I''d like to
arrange my files according to my preferred conventions.

I think that #include "...\n..." doesn''t work because the thing isn''t a
string literal, but is interpreted by the preprocessor.

I really don''t see why the preprocessor doesn''t read a ", then look for
a closing ", then interpret everything in between (newlines or not) as
the filename. Is this just a problem with gcc''s implementation, or does
the Standard actually allow compilers to place artifical restrictions
on the characters allowed in source file names? If so, why?

Ian Collins wrote:

>rb********@mailinator.com wrote:

>>I have a header whose filename contains an embedded newline and I can''t
seem to #include it successfully. I''ve tried

So don''t do it.

--
Ian Collins.

--
Eric Sosman
es*****@acm-dot-org.invalid

这篇关于头文件名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！