关于C ++最糟糕的事情 [英] The worst things about C++
问题描述
不，这不是一个巨魔，我不是在推广Java，C-flat，D，APL，Bash，
Mathematica，SML或LISP。一位大学教师最近向这个
新闻组发帖说她的观察结果显示，选择参加C ++课程的学生人数下降了很多。我只是想要让人们知道我认为是C ++的最大障碍
语言习得，以及该语言的哪些方面使其更少
比它更具吸引力。
这些都不是核心语言的组成部分。 Java和Microsoft的类似Java的伪C ++的典型卖点是垃圾收集，b $ b和没有不安全的访问（指针）。 。我确信这些问题都不是C ++的弱点。与竞争语言相比，这两者实际上都是C ++
的优势。 RAII迫使程序员知道他或她真正在做什么资源，并导致更清晰，更加连贯的代码。当然，如果没有正确处理
，指针可能会导致问题。 OTOH，直接访问可寻址内存使得许多优化和功能可以通过修改语言实现来提供其他语言提供的b
（很可能是
用C ++编写）。有很多编程实践可以保护
免受传统缓冲区溢出问题等的影响。
在学习C ++时我发现最有问题的是，大致按顺序排列
意义：
Cpp。几乎所有关于它的内容从它丑陋的语法到它的野蛮无视程序结构对我来说都是问题。使用Cpp条件读取代码
通常会让人感到困惑，因为必须知道并保持
介意在编译时保持特定构建的条件我们是什么？b $ b正在使用。它会在不考虑程序正确性的情况下削减语法。
它可能会导致意外的行为，这种行为并不明显，因为它的后果是在代码看到的时间之间表现出来的。
程序员和编译器看到它的时间。它可用于任意重新排列和重新定义程序组件的
。即使是#include
机制也可能导致严重问题。例如，当标题保护发生名称冲突时，它们导致难以理解的错误，
编译器通常提供比无用诊断更糟糕的错误。名称
宏之间的冲突也存在很大问题。这些只是我对Cpp使用的一些反对意见。
ODR细微之处的相关问题，链接的确切性质以及/>
翻译单元是我的另一个重大混淆来源。
这也与Cpp的#include机制的使用有关。但它超越了这个价值。翻译单元的概念不是象征性地用语言表示的b $ b，但它在程序的
结构中起着重要作用。静态和外部的意义和含义
对我来说一直模糊不清。直到最近我才真正来到
了解它们。
虽然它在很大程度上超出了
$所解决的范围b $ b编程语言本身，图书馆联动的问题也是我的重要麻烦来源。
核心语言的唯一方面我真的觉得有问题，而且这比上面的任何一个都要重要得多，是与函数的指针相关的语法，以及与传递引用有关的语法
数组。后者是Stroustrup似乎完全从TC ++ PL（SE）中省略了
的东西。
-
名词：1。遗嘱遗留给他人的金钱或财产。 2.从祖先或前任或过去那里下来的东西：b
宗教自由的遗产。 ETYMOLOGY：MidE legacie，副手办公室，来自OF，来自ML legatia的
，来自L legare，以及deute，遗赠。 www.bartleby.com/61/
No, this is not a troll, and I am not promoting Java, C-flat, D, APL, Bash,
Mathematica, SML, or LISP. A college teacher recently posted to this
newsgroup regarding her observation that there has been a significant
decline in the number of students opting to take courses in C++. I just
want to let people know what I believe are the biggest obstacles to C++
language acquisition, and what aspects of the language make it less
appealing than it could be.
None of these are integral to the core language. The typical selling points
for Java and Microsoft''s Java-like pseudo-C++ are "garbage collection"
and "no unsafe access (pointers)". I am convinced that neither of those
issues are weaknesses of C++. Both of these are actually strengths of C++
in comparison to the competing languages. RAII forces the programmer to
know what he or she is really doing with resources, and leads to cleaner,
more coherent code. Certainly pointers can result in problems if not
handled correctly. OTOH, the direct access to addressable memory enables
many optimizations and capabilities which the other languages have to
provide by modifying the language implementation (which is more than likely
written in C++). There are plenty of programming practices which protect
against traditional buffer overrun problems, etc.
What I found most problematic when learning C++ were, roughly in order of
significance:
Cpp. Almost everything about it from its ugly syntax to its brutish
disregard for program structure have been problems for me. Reading code
with Cpp conditionals is often confusing because one must know and keep in
mind what conditions hold at compile time for the particular build we are
working with. It cuts up syntax without regard for program correctness.
It can lead to unexpected behavior which is not obvious because its
consequences are manifested between the time the code is seen by the
programmer and the time it is seen by the compiler. It can be used to
arbitrarily rearrange and redefine program components. Even the #include
mechanism can cause significant problems. For example when header guard
name collisions happen they lead to hard to understand errors for which the
compiler typically provides worse than useless diagnostics. Name
collisions among macros are also significantly problematic. And these are
just a few of the objections I have to Cpp usage.
The related issues of ODR subtleties, the exact nature of linkage and
translation units has been another source of significant confusion for me.
This also ties into the use of the #include mechanism of Cpp. But it goes
beyond that. The concept of a translation unit is not symbolically
represented in the language, but it plays a significant role in the
structure of a program. The meaning and implication of static and extern
have always been nebulous to me. Only recently have I really come to
understand them.
Though it is, to a large extent, outside the scope addressed by the
programming language itself, the issue of library linkage has also been a
significant source of trouble for me.
The only aspect of the core language I really find problematic, and this is
far less significant than any of the above, is the syntax related to
pointers to functions, and the syntax related to passing references to
arrays. The latter is something that Stroustrup seems to have omitted
completely from TC++PL(SE).
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
推荐答案
Steven T. Hatton写道：
Steven T. Hatton wrote:
学习C ++时我发现最有问题的是，大致按照
意义：
Cpp。几乎所有关于它的内容从它丑陋的语法到它的野蛮无视程序结构对我来说都是问题。
What I found most problematic when learning C++ were, roughly in order of
significance:
Cpp. Almost everything about it from its ugly syntax to its brutish
disregard for program structure have been problems for me.
保留向后兼容30年以上工具的成本
和技术。新语言可以定义自己的基础设施。
The cost of retaining backwards compatibility with 30+ year old tools
and techniques. New languages have the luxury of defining their own
infrastructure.
阅读代码
带有Cpp条件的
通常是令人困惑，因为一个人必须知道并保持在
，请注意在编译时我们使用的特定构建的条件是什么。它会在不考虑程序正确性的情况下削减语法。
它可能会导致意外的行为，这种行为并不明显，因为它的后果是在代码看到的时间之间表现出来的。
程序员和编译器看到它的时间。
Reading code
with Cpp conditionals is often confusing because one must know and keep in
mind what conditions hold at compile time for the particular build we are
working with. It cuts up syntax without regard for program correctness.
It can lead to unexpected behavior which is not obvious because its
consequences are manifested between the time the code is seen by the
programmer and the time it is seen by the compiler.
这些问题可以在很大程度上通过使用条件构建来消除，而不是条件编译。条件构建将平台
特定代码拆分到自己的编译单元中。
These problems can largely be removed by the use of conditional builds,
rather than conditional compiles. A conditional build splits platform
specific code into its own compilation unit.
它可用于
任意重新排列和重新定义程序组件。即使是#include
机制也可能导致严重问题。例如，当标题保护发生名称冲突时，它们导致难以理解的错误，
编译器通常提供比无用诊断更糟糕的错误。名称
宏之间的冲突也存在很大问题。这些只是我对Cpp使用的一些反对意见。
It can be used to
arbitrarily rearrange and redefine program components. Even the #include
mechanism can cause significant problems. For example when header guard
name collisions happen they lead to hard to understand errors for which the
compiler typically provides worse than useless diagnostics. Name
collisions among macros are also significantly problematic. And these are
just a few of the objections I have to Cpp usage.
我不能争辩。虽然根据我的经验，这个问题很少见，但是一旦被咬了就会了解症状。
I can''t argue with that. Although in my experience the problem is rare
and once bitten one learns the symptoms.
ODR细微之处的相关问题，确切性质联系和
翻译单位是我的另一个重大混淆来源。
这也与Cpp的#include机制的使用有关。但它超越了这个价值。翻译单元的概念不是象征性地用语言表示的b $ b，但它在程序的
结构中起着重要作用。
The related issues of ODR subtleties, the exact nature of linkage and
translation units has been another source of significant confusion for me.
This also ties into the use of the #include mechanism of Cpp. But it goes
beyond that. The concept of a translation unit is not symbolically
represented in the language, but it plays a significant role in the
structure of a program.
同样，保留与30岁以上的工具和技术的向后兼容性的成本。
Again, the cost of retaining backwards compatibility with 30+ year old
tools and techniques.
>
核心语言的唯一方面我真的觉得有问题，这就是
远比上述任何一个更重要的是与函数指针相关的语法，以及与将引用传递给
数组相关的语法。
>
The only aspect of the core language I really find problematic, and this is
far less significant than any of the above, is the syntax related to
pointers to functions, and the syntax related to passing references to
arrays.
成员指针的声明和使用毫无疑问是b
憎恶。
-
Ian Collins。
The declaration and use of pointers to members is without doubt an
abomination.
--
Ian Collins.
Ian Collins写道：
Ian Collins wrote:
Steven T. Hatton写道：
Steven T. Hatton wrote:
学习C ++时我发现最有问题的是，大致按照
的顺序意义：
Cpp。几乎所有关于它的内容从它丑陋的语法到它的野蛮无视程序结构对我来说都是问题。
What I found most problematic when learning C++ were, roughly in order of
significance:
Cpp. Almost everything about it from its ugly syntax to its brutish
disregard for program structure have been problems for me.
保留向后兼容30年以上工具的成本
和技术。新语言可以定义自己的基础设施。
The cost of retaining backwards compatibility with 30+ year old tools
and techniques. New languages have the luxury of defining their own
infrastructure.
阅读代码
带有Cpp条件的
通常是令人困惑，因为一个人必须知道并保持在
，请注意在编译时我们使用的特定构建的条件是什么。它会在不考虑程序正确性的情况下削减语法。
它可能会导致意外的行为，这种行为并不明显，因为它的后果是在代码看到的时间之间表现出来的。
程序员和编译器看到它的时间。
Reading code
with Cpp conditionals is often confusing because one must know and keep in
mind what conditions hold at compile time for the particular build we are
working with. It cuts up syntax without regard for program correctness.
It can lead to unexpected behavior which is not obvious because its
consequences are manifested between the time the code is seen by the
programmer and the time it is seen by the compiler.
这些问题很大程度上可以通过使用条件构建来消除，而不是条件编译。条件构建将平台
特定代码拆分到自己的编译单元中。
These problems can largely be removed by the use of conditional builds,
rather than conditional compiles. A conditional build splits platform
specific code into its own compilation unit.
它可用于
任意重新排列和重新定义程序组件。即使是#include
机制也可能导致严重问题。例如，当标题保护发生名称冲突时，它们导致难以理解的错误，
编译器通常提供比无用诊断更糟糕的错误。名称
宏之间的冲突也存在很大问题。这些只是我对Cpp使用的一些反对意见。
。
It can be used to
arbitrarily rearrange and redefine program components. Even the #include
mechanism can cause significant problems. For example when header guard
name collisions happen they lead to hard to understand errors for which the
compiler typically provides worse than useless diagnostics. Name
collisions among macros are also significantly problematic. And these are
just a few of the objections I have to Cpp usage.
我不能争辩。虽然根据我的经验，这个问题很少见，但是一旦被咬了就会了解症状。
I can''t argue with that. Although in my experience the problem is rare
and once bitten one learns the symptoms.
ODR细微之处的相关问题，确切性质联系和
翻译单位是我的另一个重大混淆来源。
这也与Cpp的#include机制的使用有关。但它超越了这个价值。翻译单元的概念不是象征性地用语言表示的b $ b，但它在程序的
结构中起着重要作用。
The related issues of ODR subtleties, the exact nature of linkage and
translation units has been another source of significant confusion for me.
This also ties into the use of the #include mechanism of Cpp. But it goes
beyond that. The concept of a translation unit is not symbolically
represented in the language, but it plays a significant role in the
structure of a program.
再次，保留与30岁以上的工具和技术的向后兼容性的成本。
Again, the cost of retaining backwards compatibility with 30+ year old
tools and techniques.
核心语言的唯一方面我真的觉得有问题，而且这比其他任何一个都要重要得多。上面是与
指向函数的指针相关的语法，以及与将引用传递给
数组相关的语法。
The only aspect of the core language I really find problematic, and this is
far less significant than any of the above, is the syntax related to
pointers to functions, and the syntax related to passing references to
arrays.
成员指针的声明和使用毫无疑问是b
憎恶。
-
伊恩柯林斯。
The declaration and use of pointers to members is without doubt an
abomination.
--
Ian Collins.
如果您不喜欢它，您可以从头开始构建它从C ++开始从顶部构建到
底部...试试吧java（或等你不能）。
我喜欢C ++和Java，但它们有自己的用途和用途。此外，如果您是技术领域的新手，并希望成为开发人员，那么您需要学习许多技巧和语言。不要停下来坐下来用
一种语言和框架/平台，学习所有你能做到的事情。
现在公司的三项最强技能是寻找
a dev是：C ++（仍然是第一），Java和C＃。
If you dont like it you can start from scratch and build it from top to
bottom in C++... go try that in java (or wait you cant).
I like C++ and Java but they have their own purposes and uses. Also if
you are new to the technology field and want to become a developer, you
need to learn many techniques and languages. Do not stop and sit with
one language and framework/platform, learn everything you can.
Right now the three strongest skills that company''s are looking for in
a dev is: C++ (still number one), Java and C#.
Ian Collins写道：
Ian Collins wrote:
Steven T. Hatton写道：
Steven T. Hatton wrote:
....
....
成员指示的声明和使用毫无疑问是b
令人憎恶。
The declaration and use of pointers to members is without doubt an
abomination.
您建议的替代方案是什么？
What is your proposed alternative ?
这篇关于关于C ++最糟糕的事情的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
