框架以操作系统的速度和混淆为代价简化了编码。随着摩尔定律的通过，我们认为可能会偏离框架吗？

我怀疑Vista未能获得成功的原因之一是它的运行速度比XP慢得多，并且由于计算机的速度没有过去提高那么快，所以这种改变似乎是倒退了一步。

多年来，CPU的速度超过了软件的速度，因此添加了OS混淆和膨胀层的新框架几乎没有什么害处。试想一下Windows 95在当今的硬件上运行的速度(考虑到一些内存调整)。从Win2K到WinXP都是重大改进，由于计算机速度更快，我们可以忍受它们变慢。

但是，即使在几年前，我也注意到用MS基础类编写的程序似乎不像直接将相同的代码编写为API的代码那么清晰。由于.Net等框架的泛滥只会使这种情况变得更糟，我们是否有可能发现能够直接在Win32 API(或者其他操作系统中的等效语言)中以" C"编写代码将即使需要花费更长的时间才能成为强大的竞争优势？还是在更长的开发时间内进行权衡是不值得的？

解决方案

回答

脱离框架将是一个倒退，我认为并希望不会发生这种情况。

回答

如果存在使应用程序更快运行的选择性压力，我认为人们会变得更好地编写框架来封装功能，而又不会减慢系统速度。

处理像素的Boost :: Gil框架是一个很好的基于模板的系统，可以归结为许多内联函数，编译器将创建与没有像素包装并且直接访问值的输出相同的输出。

关于问题，我认为应该由框架编写者来负责，以确保他们的框架既快速又精简。这可能意味着他们检测到正在使用的功能，并删除与未使用的功能有关的代码。

回答

存在用于封装通用功能的框架；这永远不会改变

是什么让我们认为摩尔定律已死？麻省理工学院的学生们正在培养能够自我组装纳米线电路的细菌，摩尔还没有死...

回答

我们所说的"框架"到底是什么意思。这个词在我们的行业中太多了。如果我们指的是MFC或者.Net之类的东西，那么我认为它们将继续存在。它们与运行时的性能无关。它们与代码重用，可维护性和关注点分离有关。

顺便说一句，Vista并不慢，因为它使用框架。它之所以缓慢是因为它使用了许多无用的框架，例如DRM。我还认为，由于MS逐渐成为一家更具官僚主义的公司，因此它也可能遭受质量低下的困扰。 Vista也缺乏目标。它没有带来任何值得升级的东西。它试图弥补GUI结霜。

回答

我认为要实现这一目标的挑战将是找到足够的开发人员，他们有信心编写代码，而又没有当今众多框架的"拐杖"。越来越多的计算机科学/软件工程学术课程无视C语言的发展，转而使用Java和.NET(并不是说我有反对Java或者.NET的经验，我肯定以.NET为生。 ，许多其他公司也这样做)，因为这是当今行业的需求。

结果，应届毕业生认为许多框架都是理所当然的(除非他们有足够的兴趣自己找出"幕后"发生的事情)。自学成才的开发人员也很可能会选择易于学习和使用的东西。同样，尽管有这样的人，他们真的很热衷并乐于了解他们使用的任何框架的幕后情况。

因此，我同意之前的文章，可能是框架的作者提出了创新的方法来确保其内容高效运行。我的印象是，相当多的开发人员对框架如何执行X并没有真正的兴趣，他们只是希望框架能够为他们做X，从而帮助他们更快地完成工作。在我看来，对于许多人而言，必须摆脱框架并不容易。

回答

"这个词在我们的行业中是如此繁重。如果我们指的是MFC或者.Net之类的东西，那么我认为它们将继续存在。它们与运行时的性能无关。它们与代码重用，可维护性和关注点分离。"

我不得不说，在许多情况下，它们确实与运行时的性能有很大关系。即使我们调用了框架，并且直接调用了API调用(在这种情况下也没有意义，但这是速度的最佳可能情况)，但额外的函数调用仍然会降低性能，这可能有时很重要。

另外，我不得不承认，希望尊重原始的海报，Vista是一个步骤。由于DRM之类的东西不是"功能"，因此速度很慢。实际上，Windows XP在许多方面都比Windows 2000快。 Vista当然不是。

回答

对于许多软件而言，性能不是问题，现在该是上市的时候了。通常在"内部"情况下，团队可能更在乎如何快速将应用程序的初始版本展示在用户面前，而不是关注应用程序的速度(或者稳定性)。除此之外，一个写得很好的框架将简化作为框架设计目标的应用程序的开发，并且如果可能的话，我们经常会生气，不要使用该框架。当然，我们冒着这样的风险，即该框架会让我们达到目标的80％的方式，然后又使自己变得干and，但是，通常，我们可以通过在框架之外进行最后的工作来缓解这种情况20％。就像软件中的所有优点一样，它通常都是关于分层的。我们可能首先选择.Net作为"框架"，然后决定对应用程序的某些部分使用特定的.Net GUI"框架"，然后对其他部分使用单独的套接字"框架"。或者，我们可能决定使用C ++并使用boost作为框架，或者选择一个更集中的框架，该框架为我们提供更多的抽象和(希望)更快的编码速度。

问题通常是选择正确的框架并确定为简化开发我们愿意牺牲多少性能。