预处理器实现GURU问题 [英] preprocessor implementation GURU question
问题描述
我正在努力解决朋友之间的分歧 - 数字火星
和BOOST--关于预编译器在特定情况下应该做什么：
当我尝试使用DM编译器编译一个boost示例程序
时出现问题，以及由
a设置的文件名macros，结果是，
.... \ ... \ list10 .cpp
vs.
.... \ ... \ list10.cpp
（注意期间前的空格）
宏在哪里问题发生在一个名为
" ... boost \\\ [！list.hpp"的文件中，其中包括：
#define MPL_AUX_LIST_HEADER
BOOST_PP_CAT（list，BLAH_LIST_SIZE）.hpp \
/ ** /
我能够解决的问题添加##，例如：
BOOST_PP_CAT（list，BLAH_LIST_SIZE）##。hpp \
/ ** /
我报告了增加邮件的问题列表，并且他们说
编译器不应该添加空格。
我向Digital Mars人员报告了这一点，他们说这是只有
连接的合法方式是##。
我再次报告提升，他们说上面没有
涉及串联，因为它不会导致令牌合并。
我向DM报告了这一点，并且他们坚持认为这是
'的旧版本'并置连接''。
我报告这是为了提升，他们说DM编译器依赖于纯粹文本处理的旧版本，而令牌化应首先发生
。
我认为我同意提升。鉴于，
#defina a（x）x
a（the_file）.ext
应该导致
the_file.ext
但是如果我写的话，我不确定编译器应该怎么做，
a（the_file）ext //没有点
有人可以在他们拍摄
信使前点亮这个问题吗？ >：^ 0提前致谢。
I''m trying to resolve a disagreement between friends --Digital Mars
and BOOST-- about what the precompiler should do in a given situation:
The problem arose when I was trying to compile a boost example program
with the DM compiler, and the name of a file which was put together by
a set of macros, ended up as,
....\...\list10 .cpp
vs.
....\...\list10.cpp
(notice the space before the period)
The macro where the problem occurs is in a file called
"...boost\mpl\list.hpp", which goes:
# define MPL_AUX_LIST_HEADER
BOOST_PP_CAT(list,BLAH_LIST_SIZE).hpp \
/**/
which I was able to work-around by adding the ##, such as:
BOOST_PP_CAT(list,BLAH_LIST_SIZE)##.hpp \
/**/
I reported the problem to boost mailing list, and they said that the
compiler shouldn''t be adding a space.
I reported this to the Digital Mars people and they say that the only
legal way to concatenate is with ##.
I reported again to boost, and they say that the above does not
involve concatenation, as it does not cause tokens to merge.
I reported this to DM and they insist that that is the old kludge of
''concatenation by juxtaposition''.
I reported this to boost and they say the DM compiler is relying on
the old kludge of pure textual processing, whereas tokenization should
happen first.
I think I agree with boost. Given,
#defina a(x) x
a(the_file).ext
should result in
the_file.ext
But then I''m not sure what the compiler should do if I write,
a(the_file)ext //no dot
Could someone please shed light on this issue before they shoot the
messenger? >:^0 Thanks in advance.
推荐答案
Dan W.写道：
... 。
Dan W. wrote:
....
我认为我同意提升。鉴于，
#defina a（x）x
a（the_file）.ext
应该导致
the_file.ext
但是我不知道如果我写的话编译器应该怎么做，
a（the_file）ext //没有点
可以有人请在拍摄
信使前解释这个问题吗？ >：^ 0提前致谢。
I think I agree with boost. Given,
#defina a(x) x
a(the_file).ext
should result in
the_file.ext
But then I''m not sure what the compiler should do if I write,
a(the_file)ext //no dot
Could someone please shed light on this issue before they shoot the
messenger? >:^0 Thanks in advance.
我不知道答案是什么，但是，你需要提升。
a）拍摄提升因为这种行为的使用是如此的好b / b $ b不常见，你必然会提出这样的问题。如果boost对容易出错的功能依赖
，它的使用将受到限制。
b）我不确定，你可能需要拍摄DM。他们应该考虑可能出错的可能性。 " ##"一直是标准化的方式连续一段时间，我怀疑这可能比普遍支持的更多是b / b
。
Dan W.在新闻中写道：ce ****************************** **@4ax.com:
[snip]
Dan W. wrote in news:ce********************************@4ax.com:
[snip]
我认为我同意提升。鉴于，
#defina a（x）x
a（the_file）.ext
应该导致
the_file.ext <但是，如果我写的话，我不确定编译器应该做什么，
a（the_file）ext //无点
I think I agree with boost. Given,
#defina a(x) x
a(the_file).ext
should result in
the_file.ext
But then I''m not sure what the compiler should do if I write,
a(the_file)ext //no dot
它应该产生输出the_fileext。 （不是引号），但是
这是2个预备用标记（尽管只有一个C ++标识符）。添加：
#define the_fileext扩展
#define B（）a（the_file）
B（）
应该产生：the_fileext不是扩张。
I.e。并置适用于生成C ++令牌，但不适用于
预处理器令牌（即可自行扩展的令牌）。
前##方式类似于：
#define cat（a，b）a / ** / b
#define XY Expanded
cat（X，Y）
生成Expanded。
这就是（IMO）##旨在解决的问题。
Rob。
-
http://www.victim-prime.dsl.pipex.com/
2003年12月3日美国东部时间16:23:57，Gianni Mariani< gi ******* @ mariani.ws>
写道：
On 03 Dec 2003 16:23:57 EST, Gianni Mariani <gi*******@mariani.ws>
wrote:
我不喜欢知道正确的答案是什么，但是，你需要提升。
a）拍摄提升，因为这种行为的使用是如此罕见，你必然会提高像这样的问题。如果boost依赖于容易出错的功能，它的使用将受到限制。
b）我不确定，你可能需要拍摄DM。他们应该考虑可能出错的可能性。 " ##"一直是连接的标准方式，我怀疑这可能比提升所依赖的更为普遍支持。
I don''t know what the right answer is, however, you need to boost.
a) Shoot boost because the usage of this kind of behaviour is so
uncommon that you''re bound to raise issues like this. If boost relies
on bug prone features, it''s use is going to be limited.
b) I''m not sure, you might need to shoot DM. They should be considering
the possibility they might be wrong. "##" has been the standard way of
concatenating for a while, I suspect that this is probably more
universally supported than what boost is relying on.
是的，我会把它们都射杀;我只是不想让世界末日重新开始
一个空白区域;-)
但问题是，提升家伙可能是对的。他们所说的是
标记化应该在宏替换之前进行，并且##
的##仅适用于令牌的情况，否则
由空格分隔，应该强行违反合并。
Juxtaposing" .ext"不违反令牌，因此不会因为##而使用
。因此，使宏像
#define filename（name，num，ext）name ## num ##。## ext
也不完全正确;也许它甚至不应该编译。
然而我看到DM的观点：允许，
#defina a（x）x
a（b）c
将产生
bc
因此允许并列连接。
但话说回来，这可能不是precomp的责任。
提升家伙说，在整个
标准中显示一个地方，它说编译器应该添加一个空格。
事情是，我不知道标准是什么样的，如果我踩到它的话。 （我应该得到一份副本，其中一天。）
干杯！
Yeah, I''d shoot them both; I just don''t want Armageddon to start over
a blank space ;-)
But the thing is, the boost guys may be right. What they say is that
tokenization should come before macro substitution, and that the use
of ## is prescribed only for situations where tokens, otherwise
separated by white space, should be forcibly violated into a merger.
Juxtaposing ".ext" does not violate the tokens, therefore does not
justify the use of ##. So, making the macro like
#define filename(name,num,ext) name##num##.##ext
would not exactly be right either; maybe it shouldn''t even compile.
And yet I see DM''s point: Allowing,
#defina a(x) x
a(b)c
would produce
bc
and therefore allow concatenation by juxtaposition.
But then again, this may not be the precomp''s responsibility. The
boost guy said, paraphrasing, "Show me one place in the entire
Standard where it says that the compiler should add a space."
And the thing is, I wouldn''t know what the Standard looks like if I
stepped on it. (I should get a copy, one of these days.)
Cheers!
这篇关于预处理器实现GURU问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
