#include责任摘要 [英] A summary of the #include liability
问题描述
我是在邮件列表上发表评论请求的一部分。我知道它总结了我在C ++中使用
#includes所说的大部分内容。我不是要求在这个
新闻组中提供同样的反馈，正如我在邮件列表中所要求的那样。我想在这里问的是
我所描述的可能替代方案实际上是''模块''
支持 - 正如WAG建议的那样。我不相信。我实际上相信
这是对C ++代码处理方式的一个更为适度的改变。
我已经说服自己#include可能是C ++''最大的
责任。其中很大一部分来自于我在学习C ++时学习使用头文件时遇到的困难。但我不喜欢
#inclusion在我的新手阶段幸存下来。我仍然相信它是kludge
等待解决方案。以下是我认为它们的一些原因
坏：
* #includes模糊了翻译的概念，因为它们可以嵌套;
*这使得文件范围的概念在许多情况下都不清楚;
*单个#include可以彻底改变翻译的内容单元
使解析翻译单元更加困难，因为
代码完成或有效性检查
* #including is单片并在翻译单元中引入大量多余的b $ b内容，迫使编译器或IDE解析和
否则考虑的内容远远超过用户代码<支持
* #including是多余的，因为它是将内容引入
a翻译单元的一种方式，这个内容是已经由类型bei的
完全限定标识符唯一指定ng进口。这意味着
程序员和/或IDE必须操作比逻辑上更多的信息
。
Java和C＃都有将实施的负担放在基于
/ / import / statement或完全限定标识符的出现的解析完全限定标识符和外部实体之间的
映射上br />
代码正文中。我相信这可以为C ++完成，因为
。我也相信它会大大提高
语言的可用性，还可以提高编译器和工具的性能，例如提供代码完成和验证的
IDE。 />
这个模块是否支持我要求？
-
" [M] y不喜欢对于预处理器而言是众所周知的。 Cpp在C / $
编程中是必不可少的，并且在传统的C ++实现中仍然很重要，但
它是一个hack，大多数依赖它的技术也是如此。 ......我认为
是时候认真对待无宏C ++编程。 - BS
Steven T. Hatton写道：
Java和C＃都有将实施的负担放在了解决完全限定标识符和外部实体之间的映射，基于
/ import /语句，或者完全限定标识符的出现在
体内。码。我相信这可以为C ++完成。我也相信它会大大提高
语言的可用性，还可以提高编译器和工具的性能，例如提供代码完成和验证的IDE。
这是模块支持我要求？
您正在比较语言与框架。在.NET下的C ++（用于.NET
工具）中，你可以：
#using< mscorlib.dll>
using namespace System;
使用命名空间System :: Forms;
等
-
Ioannis Vranos
http：//www23.brinkster .com / noicys
Ioannis Vranos写道：
Steven T. Hatton写道：
< blockquote class =post_quotes> Java和C＃都给实现带来了负担，以解决基于/ import / statement或者import / statement的完全限定标识符和外部实体之间的映射问题。完全合格的
标识符在代码正文中。我相信这可以为C ++完成。我也相信它会大大提高
语言的可用性，还可以提高编译器和工具的性能，例如提供代码完成和验证的IDE。
这是模块支持我要求？
您正在比较语言与框架。
是和否。是的，需要一个由
实现提供的框架来支持指定的语言功能。不，我不是建议C ++ 0x标准的
应该指定这个框架应该如何提供
。我确实认为标准描述一个
''的作用是合理的，因为这个实现具有一定的实际基础。
在.NET下的C ++中。 NET
设施）你这样做：
#using< mscorlib.dll>
使用命名空间系统;
使用命名空间System :: Forms;
等。
我相信你所说的不仅是可行的，而且已经完成了 - 在
限制区域。据我所知，.NET不会给我标准的
库。这是正确的吗？
我（几乎）永远不会使用使用命名空间导入整个命名空间
系统;如果我可以导入单个标识符，例如使用
System :: FooClass;。我不是导入java.net。*在Java中，即使那是
是一种常见的做法。在标题中提供的文件中明确提及所使用的所有标识符
是一种强大的通信工具。但是，这比我认为C ++应该先行的一步还要多。我宁愿不用
详细说明语言没有明确支持的功能的理想用法。
我相信一种机制将适用于现有的C ++代码库，以提供支持的最基本形式我建议将研磨
我的#include路径中的所有标题并制作像标签数据库
，将资源映射到头文件名。然后我可以得到一些东西
就像#prgama no_headers一样。在我的所有文件中。这会调用某种
程序来为我做#include。
我会授予你这个并不能解决很多问题我真的想解决的问题。
但是，我相信制作这样一个工具的行为将证明
对如何采取下一步措施非常有启发性/>
理想的解决方案。
-
[M]不喜欢预处理器是众所周知的。 Cpp在C / $
编程中是必不可少的，并且在传统的C ++实现中仍然很重要，但
它是一个hack，大多数依赖它的技术也是如此。 ......我认为
是时候认真对待无宏C ++编程。 - BS
Steven T. Hatton写道：
我相信你说的是，不仅仅是它是可行的，它已经完成 - 在一个有限的区域内。据我所知，.NET不会给我标准的图书馆。这是正确的吗？
我（几乎）永远不会使用using namespace
System导入整个命名空间。如果我可以导入单个标识符，例如using
System :: FooClass;。我不是导入java.net。*在Java中，即使这是一种常见的做法。明确提及标题中可用文件中使用的所有标识符是一种强大的通信工具。但是，这超出了我认为C ++应该先行的一步。我不想详细说明语言没有明确支持的功能的理想用法。
我相信一种适用于现有C ++代码库的机制提供
支持的最基本形式我建议将研磨我的#include路径中的所有标题，并制作像标记数据库那样将资源映射到头文件名。然后，我可以拥有像#prgama no_headers这样的东西。在我的所有文件中。那将会调用某种程序为我做#include。
我会告诉你，这并没有解决我真正想要解决的许多问题。但是，我确实相信，制作这样一个工具的工作对于如何采取下一步的理想解决方案是非常有益的。
不，你错过了重要的事情！有一个即将推出的C ++ / CLI标准。
查看我一直在准备的页面作为它的介绍：
http://www23.brinkster.com/noicys/cppcli.htm
C ++ / CLI将使C ++成为CLI（和.NET）的最佳语言：
http://microsoft.sitestream.com/Tech...V333_Sutte.ppt
http://www.accu.org/ conference / prese ...主题演讲％29.pdf
另外在我的网站上我有更多关于C ++ / CLI的信息（不是广告，<事实上我创建了这些页面，因为我经常在这里遇到这种类型的
问题。
-
Ioannis Vranos
http://www23.brinkster.com/noicys
I wrote this as part of a request for comments on a mailing list. I
realized it summarizes much of what I''ve been saying about the use of
#includes in C++. I''m not asking for the same kind of feedback on this
newsgroup as I requested on the mailing list. What I want to ask here is
whether what I am describing as a possible alternative is actually ''module''
support - as one WAG suggested. I don''t believe it is. I actually believe
it is a far more modest change in how C++ code is processed.
I have convinced myself that the #include is perhaps C++''s greatest
liability. Much of this comes from the difficulty I had in learning to
work with ''header files'' when first learning C++. But my dislike for
#inclusion has survived my newbie phase. I still believe it is kludge
waiting for a solution. Here are some of the reasons I believe they are
bad:
* #includes obscure the concept of translation because they can be nested;
* this makes the concept of ''file scope'' unclear in many contexts;
* a single #include can drastically change the content of a translation unit
making it far more difficult to parse translation units for purposes of
code completion or validity checking
* #including is monolithic and introduces significant amounts of superfluous
content into the translation unit forcing the compiler or IDE to parse and
otherwise consider far more content than is relevant to the user code being
supported
* #including is redundant in that it is a means of introducing content into
a translation unit, and this content is already uniquely specified by the
fully qualified identifier of the type being imported. This means the
programmer and/or IDE must manipulate more information than is logically
required.
Both Java and C# have placed the burden on the implementation to resolve the
mapping between fully qualified identifiers and external entities based on
an /import/ statement, or the occurrance of the fully qualified identifier
in the body of the code. I believe this could be accomplished for C++ as
well. I also believe it would greatly improve the usability of the
language, and also improve the performance of compilers and tools such as
IDE that provide code completion and validation.
Is this module support I''m asking for?
--
"[M]y dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++ implementations, but
it is a hack, and so are most of the techniques that rely on it. ...I think
the time has come to be serious about macro-free C++ programming." - B. S.
Steven T. Hatton wrote:
Both Java and C# have placed the burden on the implementation to resolve the
mapping between fully qualified identifiers and external entities based on
an /import/ statement, or the occurrance of the fully qualified identifier
in the body of the code. I believe this could be accomplished for C++ as
well. I also believe it would greatly improve the usability of the
language, and also improve the performance of compilers and tools such as
IDE that provide code completion and validation.
Is this module support I''m asking for?
You are comparing a language vs frameworks. In C++ under .NET (for .NET
facilities) you do:
#using <mscorlib.dll>
using namespace System;
using namespace System::Forms;
etc.
--
Ioannis Vranos
http://www23.brinkster.com/noicys
Ioannis Vranos wrote:
Steven T. Hatton wrote:Both Java and C# have placed the burden on the implementation to resolve
the mapping between fully qualified identifiers and external entities
based on an /import/ statement, or the occurrance of the fully qualified
identifier
in the body of the code. I believe this could be accomplished for C++ as
well. I also believe it would greatly improve the usability of the
language, and also improve the performance of compilers and tools such as
IDE that provide code completion and validation.
Is this module support I''m asking for?
You are comparing a language vs frameworks.
Yes and no. Yes, there would need to be a framework provided by the
implementation to support the specified language feature. No, I am not
proposing the C++0x Standard should specify how this framework shall be
provided. I do believe it is reasonable for the Standard to describe a
''works like this'' implementation with some basis in reality.
In C++ under .NET (for .NET
facilities) you do:
#using <mscorlib.dll>
using namespace System;
using namespace System::Forms;
etc.
I believe what you are saying is, not only is it doable, it''s done - in a
limited area. As I understand things, .NET won''t give me the Standard
Library. Is this correct?
I would (almost) never import an entire namespace with "using namespace
System;" if I could import a single identifier such as "using
System::FooClass;". I don''t "import java.net.*" in Java, even though that
is a common practice. Having explicit mention of all the identifiers used
in a file available in the heading is a powerful communication tool. But
that''s one step beyond what I believe C++ should go first. I''d rather not
elaborate on ideal usage of a feature which the language does not
explicitly support.
I believe a mechanism that would work for existing C++ code bases to provide
the most elementary form of the support I''m suggesting would be to grind up
all the headers in my #include path and make something like a tags database
that would map resources to header file names. I could then have something
like "#prgama no_headers" in all my files. That would invoke some kind of
program to do the #including for me.
I''ll grant you this doesn''t solve many of the problems I really want solved.
I do, however, believe the exercise of producing such a tool would prove
invaluably instructive regarding how to take the next steps toward the
ideal solution.
--
"[M]y dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++ implementations, but
it is a hack, and so are most of the techniques that rely on it. ...I think
the time has come to be serious about macro-free C++ programming." - B. S.
Steven T. Hatton wrote:
I believe what you are saying is, not only is it doable, it''s done - in a
limited area. As I understand things, .NET won''t give me the Standard
Library. Is this correct?
I would (almost) never import an entire namespace with "using namespace
System;" if I could import a single identifier such as "using
System::FooClass;". I don''t "import java.net.*" in Java, even though that
is a common practice. Having explicit mention of all the identifiers used
in a file available in the heading is a powerful communication tool. But
that''s one step beyond what I believe C++ should go first. I''d rather not
elaborate on ideal usage of a feature which the language does not
explicitly support.
I believe a mechanism that would work for existing C++ code bases to provide
the most elementary form of the support I''m suggesting would be to grind up
all the headers in my #include path and make something like a tags database
that would map resources to header file names. I could then have something
like "#prgama no_headers" in all my files. That would invoke some kind of
program to do the #including for me.
I''ll grant you this doesn''t solve many of the problems I really want solved.
I do, however, believe the exercise of producing such a tool would prove
invaluably instructive regarding how to take the next steps toward the
ideal solution.
No you are missing important things! There is an upcoming C++/CLI standard.
Check a page I have been preparing as an introduction to it:
http://www23.brinkster.com/noicys/cppcli.htm
C++/CLI will make C++ the best language of CLI (and .NET):
http://microsoft.sitestream.com/Tech...V333_Sutte.ppt
http://www.accu.org/conference/prese...keynote%29.pdf
Also in my site I have some more info on C++/CLI (not an advertisement,
in fact I created those pages because I come across this type of
questions quite often in here).
--
Ioannis Vranos
http://www23.brinkster.com/noicys
这篇关于#include责任摘要的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
