Questions tagged «c++»

根据我所读的内容，编译器没有义务用其主体替换内联函数的函数调用，但是如果可以的话，它将这样做。这让我开始思考-如果是这种情况，为什么我们要使用内联词？为什么不将所有函数默认设置为内联函数，并让编译器确定它是否可以用函数主体替代调用？

19 c++  language-design  optimization  compilation 

有传言说，早期的C ++实现已经使用点运算符来访问名称空间。有观点认为，点比现代双冒号运算符更方便。 引入双冒号背后的原因是什么？

19 c++  language-design  history 

关于这两种做法仅仅是同一枚硬币的两个方面，还是一个真的更好，我正在和我的朋友进行辩论。 我们有一个函数，该函数需要一个参数，填写其中的一个成员，然后返回它： Item predictPrice(Item item) 我相信，由于它可以处理传入的同一对象，因此没有必要继续返回该项目。实际上，从调用者的角度来看，如果有任何事情，它将使您感到困惑，因为您可以期望它返回一个新项目，而不会。 他声称这没有什么区别，即使它确实创建了一个新Item并返回它也没有关系。我强烈不同意，原因如下： 如果您对传入的项有多个引用（或使用指针或其他方式），则分配一个新对象并返回该对象具有重要意义，因为这些引用将是不正确的。 在非内存托管语言中，分配新实例的函数声明了内存的所有权，因此我们将必须实现在某个时候调用的清理方法。 在堆上分配可能很昂贵，因此，对于被调用函数是否执行此操作很重要。 因此，我认为能够通过方法签名查看是修改对象还是分配新对象非常重要。结果，我认为由于函数仅修改传入的对象，因此签名应为： void predictPrice(Item item) 在我使用过的每个代码库中（公认的C和C ++代码库，而不是Java，这都是我们正在使用的语言），上述样式基本上得到了遵守，并且由经验更为丰富的程序员所遵循。他声称，由于我的代码库和同事的样本量在所有可能的代码库和同事中所占的比例很小，因此，我的经验不能真正表明一个人是否优越。 那么，有什么想法吗？

19 java  c++  coding-style  method-chaining 

我试图了解如何构建堆栈框架以及哪些变量（参数）以什么顺序被压入堆栈？一些搜索结果表明，C / C ++编译器根据函数内执行的操作进行决策。例如，如果假定该函数只是将传入的int值加1（类似于++运算符）并返回它，则它将把该函数的所有参数和局部变量放入寄存器中。 我想知道哪些寄存器用于返回或按值传递参数。引用如何返回？编译器如何在eax，ebx，ecx和edx之间进行选择？ 我需要了解什么才能了解​​函数调用期间如何使用，构建和销毁寄存器，堆栈和堆引用？

19 c++  c  compiler  stack 

我在大学这个学期的C ++课程中有一个面向对象的编程，我们正在学习有关朋友函数的知识。 我本能地讨厌它们绕过封装和数据隐藏所提供的安全性的能力，我在互联网上读了几篇文章，有些人认为这是一个合法使用的好主意。 OOP专家会对C ++中的好友功能怎么说？我应该浏览一下还是应该了解更多？

19 c++  object-oriented  friends 

我从来不明白为什么C和C ++编译器会尝试从错误中恢复并继续解析。几乎总是，第一个错误会生成一系列伪错误，这些错误会在第一个错误修复后立即消失。经过几年的经验，我只是停止查看除每个文件的第一个错误以外的任何错误。我重新运行编译器，然后再次执行该操作，直到没有更多错误为止。这是常见的做法吗？

19 c++  c  error-messages  compiler 

我知道“惯用语”是一种常见的操作或模式，在某种特定语言中并没有通过核心语言语法来简化，例如整数增量： i = i + 1; 在C ++中，此惯用法由运算符简化： ++i; 但是，当有人使用“惯用”一词时，我不确定该如何理解。是什么使一段代码“惯用”？

19 c++  idioms 

为什么我们需要同时包含.h和.cpp文件，而仅通过包含.cpp文件就可以使其起作用？ 例如：创建一个file.h包含声明，然后创建一个file.cpp包含定义，并将两者都包含在中main.cpp。 或者：在中创建一个file.cpp包含声明/定义的声明（没有原型）main.cpp。 两者都为我工作。我看不出有什么区别。也许对编译和链接过程有一些了解可能会有所帮助。

18 c++  c  headers  linking  include 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 6年前关闭。 我无法解决这个问题。如果使用了很多C，但不是C ++，有人可以向我解释使C比C ++更常用的最重要原因吗？这些C代码在哪里写？ 这是否与高度依赖命令式编程但不能承受实现或调整C ++编译器的成本的工业部门有关？有那么多内核黑客吗？ tiobe是否相关？我从没涉足任何文章，也没有发表评论或解释tiobe的排名是多少，它实际上表明了该行业的喜好，以及它可以表明该行业的实际用途，从而确定了该行业的实际需求。很难解释。 我只是觉得奇怪，即使这些C / C ++职位很烂，许多公司也想要C＃，php，java职位，而不是C或C ++职位（只是与我的失业状况和我的采访有关）。我会选择那些。还是这意味着语言炒作在这里起着重要作用？

18 programming-languages  c++  c  history 

为什么书会说“编译器为内存中的变量分配空间”。难道不是可执行文件吗？我的意思是，例如，如果我编写以下程序， #include <iostream> using namespace std; int main() { int foo; return 0; } 并编译它，并获得一个可执行文件（将其命名为program.exe），现在，如果我运行program.exe，该可执行文件本身将命令为变量foo分配一些空间。不是吗 请解释为什么书中总是说“编译器会执行此操作...”。

18 c++ 

我在C ++和Java世界中看到许多没有任何状态的可实例化类。 我真的不知道为什么人们这样做，他们只能在C ++中使用带有自由函数的名称空间，或者在Java中使用具有私有构造函数和仅静态方法的类。 我能想到的唯一好处是，如果您以后决定在某些情况下需要不同的实现，则不必更改大多数代码。但这不是过早设计的情况吗？当/如果合适的话，以后可以将其变成一堂课。 我搞错了吗？如果我不将所有内容都放入对象（即实例化类）中，这不是OOP吗？那么，为什么在C ++和Java的标准库中有如此多的实用程序名称空间和类？ 更新： 在以前的工作中，我当然已经看过很多这样的例子，但是我一直在努力寻找开放源代码的例子，因此也许毕竟不是那么普遍。不过，我想知道人们为什么这么做，以及这种做法有多普遍。

18 java  c++  object-oriented  class  object 

在c ++中，*运算符可以重载，例如使用迭代器，但是箭头（->）（。*）运算符不适用于重载*运算符的类。我认为预处理器可以轻松地用（* left）.right替换->的所有实例，这将使迭代器更易于实现。->与众不同是不是有实际的原因，还是仅是语言/设计者的特殊性？

18 c++  operators 

我真的很喜欢C的简单和透明的性质：当我编写C代码时，我不受“泄漏抽象”的束缚，并且几乎总能对我正在生成的程序集做出精明的猜测。我也喜欢C的简单，熟悉的语法。 但是，C没有C ++提供的这些简单，有用的东西，例如类，简化的非字符串处理等。我知道可以使用跳转表之类的东西在C中实现，但这有时有点麻烦，并且出于各种原因也不是很安全的类型。 不过，我不喜欢过分强调C ++中的对象，并且我对“ new”运算符等不屑一顾。例如，C ++似乎有太多的障碍，无法用作系统编程语言。 在小部件和小工具的规模上是否存在介于C和C ++之间的语言？ 免责声明：我的意思是纯粹是事实问题。我不想激怒您，因为我不同意您的观点，即C {，++}足以胜任我计划的一切。

18 c++  c 

我一直在Channel9上观看Herb Sutter的一次采访，他在视频的结尾提到，对于将来的C ++标准，从左到右的语言语法将是他的愿望清单上的第一名（尽管他承认以这种方式修改C ++会造出完全不同的野兽）。 除了： 人类更容易理解，肉眼更清晰；例如 //C syntax /*pointer to function taking a pointer to function(which takes 2 integers as arguments and returns an int), and an int as arguments and returning an int*/ int (*fp)(int (*ff)(int x, int y), int b) //Go analogous syntax which is left to write …

18 c++  c  programming-languages  go 

我越了解不同的编程范例（例如函数式编程），就越开始质疑OOP概念（如继承和多态性）的智慧。我最初在学校学习继承和多态性，当时，多态性似乎是编写允许轻松扩展的通用代码的绝妙方法。 但是面对鸭子类型（动态和静态）以及诸如高阶函数之类的功能特性，我已经开始将继承和多态性视为基于对象之间脆弱的一组关系施加了不必要的限制。多态性背后的一般想法是，您只需编写一次函数，以后便可以在不更改原始函数的情况下向程序中添加新功能-您要做的就是创建另一个实现必要方法的派生类。 但是，无论是使用动态语言（例如Python）还是使用静态语言（例如C ++），通过鸭子输入都可以轻松实现这一点。 例如，请考虑以下Python函数，后跟等效的静态C ++： def foo(obj): obj.doSomething() template <class Obj> void foo(Obj& obj) { obj.doSomething(); } 相当于OOP的类似于以下Java代码： public void foo(DoSomethingable obj) { obj.doSomething(); } 当然，主要区别在于Java版本需要先创建接口或继承层次结构，然后才能起作用。因此，Java版本涉及更多工作，并且灵活性较差。此外，我发现大多数现实世界中的继承层次结构都有些不稳定。我们都已经看到了人为的形状和动物的示例，但是在现实世界中，随着业务需求的变化和新功能的添加，很难真正完成任何工作，然后才能真正扩展子类，或者重新建模/重构层次结构以包含更多的基类或接口，以适应新的需求。使用鸭子类型，您无需担心要建模的任何事情-您只需要担心所需的功能。 但是，继承和多态性是如此流行，以至于我怀疑将它们称为可扩展性和代码重用的主要策略是否过于夸张。那么，为什么继承和多态性如此成功呢？我是否忽略了继承/多态性比鸭子类型具有的一些重要优势？

18 java  c++  python  object-oriented  type-systems