VC ++的新版本仍然停留在函数原型中？ [英] New versions of VC++ still stuck with function prototypes?
问题描述
鉴于VS2005已经努力清理VC ++的语法
（在C ++ / CLI中），是否有任何未来计划取消功能
protos，ala C＃/ VB？这些天他们需要什么？
_R写道：鉴于VS2005已经制作了努力清理VC ++的语法
（在C ++ / CLI中），有没有未来计划取消功能
protos，ala C＃/ VB？
你的意思是删除头文件？我希望他们永远不会这样做！
这些天他们需要什么？
- 清晰分离界面和实现（不够清楚恕我直言，
但仍然优于C＃或VB）。
- 修改实现时需要重新编译的限制
详细信息：C＃编译模型不能很好地扩展，因为每次你修改程序集中最细微的细节时，你需要重新编译所有
相关代码。使用C ++，您只需要重新链接依赖项。虽然C＃
或VB.NET编译器比C ++编译器更快（因为语法很简单），但这意味着构建一个庞大的项目可能很困难。 C＃
或VB。
Arnaud
MVP - VC
Arnaud Debaene写道：_R写道：
鉴于VS2005已经努力清理VC ++的语法
（用C ++ / CLI），有没有未来计划取消功能
protos，ala C＃/ VB？
你的意思是删除头文件？我希望他们永远不会这样做！
我希望他们会（试着）支持未来的标准，因为那个
可以大大提高编译速度。
这些天他们需要什么？
- 清洁分离界面和实现（不够清晰恕我直言，
但仍然比在C＃或VB中。
为此，您不需要任何头文件。与其他语言相比，C ++不提供任何更好的分离。如果你大量使用
模板，你实际上无法将界面与
实现分开，或者必须使用代码分离技巧。喜欢pimpl
成语。
有些语言将他们的代码文件分成两半。一个
接口部分和一个实现部分。我没有看到任何
的原因，为什么不能用C ++和AFAIK来完成IBM已经提供了一个
专有的C ++解决方案。我认为这将提供更好的处理和模板界面，并且不需要
导出关键字。
- 修改实现时需要重新编译的限制
详细信息：C＃编译模型不能很好地扩展，因为每次修改程序集中最细微的细节时，都需要重新编译所有
依赖代码。使用C ++，您只需要重新链接依赖项。虽然C＃
或VB.NET编译器比C ++编译器更快（因为语法更简单），但这意味着用C＃
或VB构建一个庞大的项目可能很困难。
如果你有一个大的C ++项目，你必须迟早使用
预编译的头文件来加速编译。当你触摸一个
单头文件时，C ++编译器必须重新编译整个
项目。没有比其他语言好多了。
C ++编译器的语法很复杂，但这不是唯一的原因
为什么C ++编译器需要这么多时间，而不是C＃或VB编译器。
除了更好的优化外，主要原因是分成
标题和实现文件。
是 - 通常应该只有头文件中的接口，
但实际上你还要在头文件中包含实现代码（模板，stl，
windows.h）文件。如果项目增长，你必须永久地想到代码分离，这样编译
的速度不会太慢。
不要误会我的意思，我喜欢C ++的很多方面，但有时我仍然因为编译速度而需要其他语言。
如果我的C＃ 200个单元的项目编译速度比我项目的单个
C ++单元更快，还有200个单元和头文件，这两个文件中明确分离的优点是什么？
如果实现或接口发生变化，C ++编译器可以自动检测（对于
C ++编译器来说不是一件容易的事）。
标记对象文件，如果实现或接口已更改。
每个其他C ++文件包括更改的单元（标头+实现）
文件可以简单检查接口是否已更改。如果没有
则不需要重新编译该单元。
这只能工作，如果宏的使用受到限制并且支持
$ b不允许$ b效果。
这也许可以提高模板的编译速度
，也许这将是比export关键字更好的解决方案。
我不知道C ++语言是否可以通过这种方式进行更改，如果它可以提高编译速度，就像我期望的那样。
我们会知道，如果另一种语言提供模板，C ++提供的方式也是b $ b b b bb ;-)
必须有一个原因，为什么（AFAIK）IBM试图在他们的C ++编译器中实现类似的东西。
Arnaud
MVP - VC
Andre
Andre Kaufmann写道：Arnaud Debaene写道：_R写道：
鉴于VS2005已经努力清理VC ++的语法
（在C ++ / CLI中），是否有任何未来计划取消功能
protos ，ala C＃/ VB？
你的意思是删除头文件？我希望他们永远不会这样做！
我希望他们（尝试）支持未来的标准，因为
可以大大提高编译速度。
当然不会。可以（并且确实）大幅改进的东西是b / b
编译时间是接口与实现的完全分离。
这种分离可以通过正确设计的头文件完成，
但它实际上是一种语言外的黑客攻击。正如您在下面指出的那样，IBM的Visual
Age C ++产品试图为
C ++提供更清晰的模块定义，但到目前为止还没有获得这样的定义。 C ++社区的势头。
不要误会我的意思，我喜欢C ++的许多方面，但有时我还是因为编译速度而更喜欢其他语言。
如果我的话具有200个单元的C＃项目比我项目的单个C ++单元编译速度更快，还有200个单元和头文件，这两个文件中明显分离的优势是什么？
如果是这样的话会很好，但根据我的经验，它不是。我经常工作的一个
项目是一个C＃应用程序，包含大约2000个
类（和文件）。事实上，在一个叶子类的次要改变之后进行构建的时间几乎与进行重建的时间相同。
整个应用程序说明了C＃没有有效的增量构建
系统。
C ++中的相同应用程序，我强烈怀疑，处理增量
在微小变化之后构建比C＃快得多，而完整的
重建可能需要更长的时间，因为增加了语言
复杂性。
我也希望有一天能为C ++创建一个良好的清洁模块概念，并通过标准组织发布
。就我个人而言，我并不希望它会发生，但你永远不会知道。在C和C ++中有如此多的传统，这是基于顺序处理
文本文件的想法，以产生一个编译的应用程序，它''很难打破
离开。我希望我们会看到一种具有C ++表现力的新语言
，但在我们看到标准C ++中的这些特性之前，我们会使用一个干净的模块概念。
-cd
Given that VS2005 has made an effort to clean up the syntax of VC++
(in C++/CLI), is there any future plans to do away with function
protos, ala C#/VB? What are they needed for these days?
_R wrote:Given that VS2005 has made an effort to clean up the syntax of VC++
(in C++/CLI), is there any future plans to do away with function
protos, ala C#/VB? You mean remove the header files? I hope they will never do it!
What are they needed for these days?
- Clean separation of interface and implementation (not clear enough IMHO,
but still better than in C# or VB).
- Limitation of what need to be recompiled when you modify an implementation
detail : C# compilation model doesn''t scale well because each time you
modify the slightest detail in an assembly, you need to recompile all
dependent code. With C++, you need only to relink dependencies. Although C#
or VB.NET compilers are faster than C++ compiler (because the syntax is much
simplier), it means that it can be difficult to build a huge project with C#
or VB.
Arnaud
MVP - VC
Arnaud Debaene wrote:_R wrote:Given that VS2005 has made an effort to clean up the syntax of VC++
(in C++/CLI), is there any future plans to do away with function
protos, ala C#/VB?
You mean remove the header files? I hope they will never do it!
I hope they will (try to) support that in a future standard, since that
could drastically improve compilation speed.
What are they needed for these days?
- Clean separation of interface and implementation (not clear enough IMHO,
but still better than in C# or VB).
For that purpose, you don′t need any header file. C++ doesn′t offer any
better separation than the other languages. If you make heavy use of
templates you effectively cannot separate the interface from the
implementation, or have to use code separation "tricks" like the pimpl
idiom.
Some languages are separating their code files into 2 halves. One
interface section and one implementation section. I don′t see any
reason, why that cannot be done in C++ and AFAIK IBM has offered a
proprietary C++ solution. I think that would offer a much better
handling and for template interfaces there wouldn′t be a need for an
export keyword.
- Limitation of what need to be recompiled when you modify an implementation
detail : C# compilation model doesn''t scale well because each time you
modify the slightest detail in an assembly, you need to recompile all
dependent code. With C++, you need only to relink dependencies. Although C#
or VB.NET compilers are faster than C++ compiler (because the syntax is much
simplier), it means that it can be difficult to build a huge project with C#
or VB.
If you have a large C++ project, you′ll have to use sooner or later
precompiled header files to speed up compilation. And when you touch a
single header file, the C++ compiler has to recompiled the whole
project. Not much better than in other languages.
The syntax of the C++ compiler is complex, but it′s not the only reason
why a C++ compiler needs so much more time, than a C# or VB compiler.
Besides better optimization, the main reason is the separation into
header and implementation files.
Yes - normally there should be only the interface in the header file,
but effectively you will have also implementation code (templates, stl,
windows.h) to include in the header files. And if the project grows, you
have to permanently think of code separation, so that the compilation
speed won′t be too slow.
Don′t get me wrong, i love C++ in many aspects, but sometimes i still
prefer other languages because of compilation speed.
If my C# project with 200 units compiles faster completely than a single
C++ unit of my project with also 200 units and header files what is the
advantage of a clear separation in 2 files ?
The C++ compiler could automatically detect (ok not an easy task for a
C++ compiler) if the implementation or the interface has changed and
mark the object file if the implementation or the interface has changed.
Each other C++ file including the changed unit (header + implementation)
file could then simply check if the interface has changed or not. If not
there wouldn′t be a need to recompile the unit.
This could only work, if the usage of macros is restricted and side
effects are disallowed.
And this would perhaps allow to improve compilation speed of templates
too, perhaps this would be a better solution than the export keyword.
I don′t know if the C++ language could be changed that way and if it
would increase compilation speed that much as i would expect.
We will know it if another language offers templates, the way C++ offers
them, too ;-)
And there must be have been a reason, why (AFAIK) IBM tried to implement
something similiar in their C++ compiler .
Arnaud
MVP - VC
Andre
Andre Kaufmann wrote:Arnaud Debaene wrote:_R wrote:Given that VS2005 has made an effort to clean up the syntax of VC++
(in C++/CLI), is there any future plans to do away with function
protos, ala C#/VB?
You mean remove the header files? I hope they will never do it!
I hope they will (try to) support that in a future standard, since
that could drastically improve compilation speed.
Of course it wouldn''t. The thing that can (and does) drastically improve
compilation time is a clean separation of interface from implementation.
This separation can be accomplished through properly designed header files,
but it''s really an extra-lingual hack. As you point out below, IBM''s Visual
Age C++ product made an attempt at providing a cleaner module definition for
C++, but so far no such definition has gained momentum in the C++ community.
Don′t get me wrong, i love C++ in many aspects, but sometimes i still
prefer other languages because of compilation speed.
If my C# project with 200 units compiles faster completely than a
single C++ unit of my project with also 200 units and header files what is
the advantage of a clear separation in 2 files ?
It would be nice if that were so, but in my experience, it isn''t. One
project I work on regularly is a C# application consisting of around 2000
classes (and files). The fact that the time to do a Build after a minor
change of a leaf class is nearly the same as the time to do a Rebuild of the
entire app deomnstrates that C# does not have an effective incremental build
system.
The same application in C++ would, I strongly suspect, handle incremental
builds after minor changes much more quickly than C# does, while a full
rebuild would likely take significantly longer due to the increased language
complexity.
I too hope that some day a good clean module concept is created for C++ and
promulgated through the standards organization. Personally, I don''t hold
out much hope that it''ll ever happen, but you never know. There''s so much
tradition in C and C++ that''s based around the idea of sequential processing
of text files to produce a compiled applicaiton that it''ll be hard to break
away. I expect that we''ll see a new language with the expressiveness of C++
but with a clean module concept before we see such featues in standar C++.
-cd
这篇关于VC ++的新版本仍然停留在函数原型中？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
