C ++：好与坏 [英] C++: The Good and Bad

问题描述

C ++是我最喜欢的语言之一。这是因为它有很多不同的优点。但是语言中还有一些瑕疵

- 有些可能是固定的，有些可能不是b $ b。我想开一个关于人们认为什么是关于C ++的好事和坏事的讨论。以下是我的清单：


关于C ++的好东西

---------------------

- 多范式语言。

- const-specifications

- 确定性破坏

- 半强类型（因为允许一些隐式转换）

- 预处理器 - 它强大而不是邪恶。经常使用强大的东西

可用于恶意目的 - 不幸的是，预处理器

有时会以邪恶的方式使用。

- Real多重继承。再一次，它是强大的，而不是邪恶的。

- 模板 - 比其他语言提供的泛型更强大。

- 部分模板专业化。

- 模板元编程。

- SFINAE，RAII，CRTP

- 可移植到比大多数其他语言更多的平台。 （这是

，部分原因是标准库较少。）

关于C ++的坏事

--------- -----------

- 一些''行李''：抛出规格，std :: vector< bool>，''export''，

一些C-行李

- 没有true-typedef; typedef实际上是类型别名。

- 需要学习很多东西

- 由于C ++的发展方式，有些东西比
$ b更复杂$ b他们需要。

- 太多未定义的行为。

- 不支持属性。

- 没有名称修改的标准。

- 没有反射功能。

- 没有垃圾回收。虽然，GC经常被错误地使用，例如

预处理器和多重继承。另请注意，C ++有GC

库 - 但如果将GC添加到语言中，可能会获得一些优势。

- 缺少库:(但是，有许多广泛可用的

跨平台库可以填补空白）

*没有标准化的线程模型/库

*没有标准的GUI库。但是，我们应该注意，标准的

GUI'通常不会用于最先进，看上去很棒的应用程序。

Java标准没有''支持OSX的最新GUI功能，

Windows Vista，OpenGL或DirectX。

*标准库不包括一些非常常见的东西，比如/>
十进制和大整数类型，能够处理目录

结构等....

*没有标准方法来获取堆栈跟踪。

解决方案

Kevin Hall写道：

C ++是其中之一我最喜欢的语言。这是因为它b / b
有很多不同的优点。但是语言中还有一些

的瑕疵 - 有些可能会被修复，有些则不可能是
。我想开一个关于人们怎么想的讨论

是关于C ++的好事和坏事。以下是我的清单：


关于C ++的好东西

---------------------

- 多范式语言。

- const-specifications

- 确定性破坏

- 半强类型（因为有一些隐含的转换

允许）

这是件好事吗？如果是，为什么半？一件好事？将

简单的强打字与所有转换明确是一件更好的事情吗？

- 预处理器 - 它的强大而不是邪恶。经常使用强大的东西

可以用于恶意目的 - 不幸的是，预处理器

有时会以邪恶的方式使用。

我不相信预处理器足够强大。

- 真正的多重继承。再一次，它是强大的，而不是邪恶的。

除了真实之外是否还有其他类型？还有什么其他的多重继承

？

- 模板 - 比其他提供的泛型更强大

语言。

哎呀...你的意思是在这里比较语言吗？阅读常见问题。

- 部分模板专业化。

- 模板元编程。

- SFINAE， RAII，CRTP

- 可移植到比大多数其他语言更多的平台。 （这是

，部分原因是标准库较少。）

不仅是库。缺少明确大小的类型也很重要

。

关于C ++的坏事

- ------------------

- 一些''行李''：抛出规格，std :: vector< bool>，''export'' ，

一些C-baggage

Hos是C行李坏事吗？你有没有想过多少代码可以简单地带来，编译，从不担心？

- 没有真正的typedef; typedef实际上是类型别名。

不确定你的意思。什么是真实的你需要typedef吗？

- 要学习很多东西

你不需要很多东西要学习。看优势＃1，你只需要
需要了解你将要应用的内容。

- 由于C ++的方式进化过来，有些事情比他们需要的要复杂得多。

喜欢什么？请记住需要提供向后兼容性。

- 太多未定义的行为。

你会做什么？定义它并限制

优化器工作的机会，或者定义它并限制平台数量

C ++可以实现吗？

- 不支持属性。

你的意思是什么？

- 没有名称修改的标准。

你为什么需要它？ C ++是可移植的源代码。你为什么要
需要标准名称修改？

- 没有反射功能。

你的意思是，内置，对吧？那么，你需要多少提供

吗？毕竟，程序员是什么？

- 没有垃圾回收。虽然，GC经常被错误地使用，例如预处理器和多重继承。另请注意，有一些用于C ++的
GC库 - 但如果将GC添加到该语言中，可能会获得
的一些优势。

喜欢什么，例如？

- 缺少库:(尽管有很多可用的库）

填补空白的跨平台库）

*没有标准化的线程模型/库

C ++涵盖的平台数量并不多。

*没有标准的GUI库。但是，我们应该注意，标准的

GUI'通常不会用于最先进，看上去很棒的应用程序。

Java标准没有''支持OSX的最新GUI功能，

Windows Vista，OpenGL或DirectX。

同样，它只适用于极少数平台。为什么

你想要定义一些无法在任何地方使用的东西

哪里可以使用这种语言？

*标准库没有涵盖一些非常常见的东西，比如

十进制和大整数类型，处理目录

结构等的能力...... 。

什么是十进制类型？大整数类型是特定于平台的，

和C ++并不禁止它们的存在。大多数实现都提供了一些额外类型的

，它们工作得很好。制作

这些语言的一部分根本不可能，而且不会牺牲编译器执行优化

程序所需的能力。

*无法获得堆栈跟踪的标准方法。

为什么你需要它？这不是调试器的用途吗？


这听起来好像你在<插入你的解释

语言中生活得太多了。抢购它！


V

-

请在回复e-时删除资金'A'邮件

我没有回应热门帖子回复，请不要问

Victor Bazarov写道：

Kevin Hall写道：

>> - 没有名称修改的标准。

你为什么需要它？ C ++是可移植的源代码。你为什么要在b
中使用标准名称？

我可以配合这个，尝试链接用编译器构建的库X />
进入使用编译器B构建的应用程序。


< OTA是一个真实的例子，看看KDE，一个很棒的桌面，但如果你想

构建链接到其库的东西，或者Qt，你必须使用

用于构建它们的相同编译器。 < / OT>


-

Ian Collins。

Victor Bazarov写道：

Kevin Hall写道：

- 半强类型（因为有一些隐含的转换
允许
）这是件好事吗？

如果是，为什么半？一件好事？将

简单的强打字与所有转换明确是一个更好的事情？

有一些隐式转换是可以的（例如，整数到双倍

转换）。但我很欣赏其他地方的强类型。

- 预处理器 - 它的强大而不是邪恶。经常使用强大的东西

可以用于恶意目的 - 不幸的是，预处理器

有时会以邪恶的方式使用。

我不相信预处理器足够强大。

是的，它可以更强大。 C99带来了更多的功率。但是

标准化的功能更强大。

- 真正的多重继承。再一次，它是强大的，而不是邪恶的。

除了真实之外是否还有其他类型？还有什么其他的多重继承

？

是的，有很多人说继承多个接口是一种

类型的MI并且足够好（有些人甚至说它'更好）。我不同意。

- templates - 比其他

语言提供的泛型更强大。

哎呀...你的意思是在这里比较语言吗？阅读常见问题。

不是什么是更好的 - 语言X或C ++。但是如果

可以从其他语言实现的功能中学到一些东西，那么它就是b $ b。 （此外，这个

未经审核的小组没有''官方''常见问题 - 尽管有一些常见问题解答声称。这个讨论已经讨论了

不久前在这个论坛。）

- 可移植到比大多数其他语言更多的平台。 （这是

，部分原因是标准库较少。）不仅是库。

缺少明确大小的类型也很重要。

True。当C ++ 0x标准化时，C99'< stdint.h会有所帮助

C ++使用它。

- 一些''行李''：抛出规格，std :: vector< bool>，''export''，

一些C-行李

Hos是C行李坏事吗？你有没有想过多少代码

可以简单地带来，编译，从不担心？

请注意我说''some'' - 不是全部。我认为倒退

与C的兼容性是一件很棒的事情。但是众所周知，C ++与B $ 100不兼容，不会与C语言100％兼容。'\\''''是C ++中的一个字符，而它是一个int

in C.


无论如何，我很难想到我的

头部的顶部示例，但是有些东西从C继承而来比起兼容性已被删除更令人烦恼

。

- 否真实的typedef; typedef实际上是类型别名。

不确定你的意思。什么是真实的你需要typedef吗？

" true typedefs"意味着typedef及其基本类型在语言类型系统中是不同的
类型。换句话说：''bar Foo（bar）;''和

''int Foo（int）;''描述两个不同的函数，如果bar是typedef''ed

作为一个整数。


网上有很多文章，书中有关于真实的部分书籍

typedef。这是一个在线参考（在页面中间看）：
http://www.artima.com/cppsource/typesafety3.html

- 很多事情要做学习

你不需要学习很多东西。看到优势＃1，你只需要b $ b需要了解你将要应用的内容。

True。

- 由于C ++的演变方式有些事情比他们需要的要复杂得多。

喜欢什么？请记住需要提供向后兼容性。

我理解向后兼容是一件好事。尽管如此，

也存在不利因素。的std ::矢量< BOOL取代。就是这样一个例子。

据我所知，在标准最终发布之前就知道了std :: vector< boolcould不能完全像一个容器，

但无论如何它都被保留了。如果你真的需要一个真正的矢量
布尔然后你必须通过箍来获得一个。

- 太多未定义的行为。

你会做什么？定义它并限制

优化器工作的机会，或者定义它并限制平台数量

C ++可以实现吗？

我说''太多''，而不是''C ++有UB''。即使是那些符合标准的人也会像其他人一样担任C ++专家，比如

Alexandrescu说有太多* UB。


我不认为需要一些UB。

- 不支持属性。

你是什么意思？

请参阅MS的__declspec（属性）：
http://msdn2.microsoft.com/en-us/lib...hd(VS.80).aspx


同样，有很多关于如何使用b $ b模拟C ++属性的书籍和章节。

- 没有名称修改的标准。

你为什么需要它？ C ++是可移植的源代码。为什么你要b $ b需要标准的名称修改？

为了支持编译器间的库，使用其他语言的标准方法来获取C ++的API。其他语言通常只能使用声明为externC的

函数。如果有一个名称

mangling的标准，那么更容易使用C ++接口。

- 没有反射功能。

你的意思是，内置，对吧？那么，你需要多少提供

吗？毕竟，程序员是为了什么？

是的，我的意思是内置。反思会使一些事情变得更容易

- 例如找到枚举值的名称。

- 没有垃圾收集。虽然，GC经常被错误地使用，例如预处理器和多重继承。另请注意，有一些用于C ++的
GC库 - 但如果将GC添加到该语言中，可能会获得
的一些优势。

比如说什么？

COW字符串（和其他COW对象）更容易实现。

- 缺少库:(但是，有许多广泛可用的

跨平台库填补了空白）

*没有标准化的线程模型/ libraryThere并不是像C ++所涵盖的平台那么多。

*没有标准的GUI库。但是，我们应该注意，标准的

GUI'通常不会用于最先进，看上去很棒的应用程序。

Java标准没有''支持OSX的最新GUI功能，

Windows Vista，OpenGL或DirectX。

同样，它只适用于极少数平台。为什么

你想要定义一些无法在任何地方使用的东西

哪里可以使用这种语言？

定义一些不能用的东西

无处不在。如果你需要做一些事情，并且某些东西是可用的，那么有一种标准的方法可以使用它。 POSIX标准

非常受欢迎，但它无法在任何地方使用。


其他一些语言在标准GUI上蓬勃发展 - 甚至<虽然这些图形用户界面的外观和感觉似乎很过时，但是b / b
。

*标准库不在t涵盖一些非常常见的东西，比如

十进制和大整数类型，处理目录

结构等的能力....

什么是十进制类型？

http://www.google.com/search?hl=en&p...a+type& spell = 1 。

大整数类型是特定于平台的，

和C ++并不禁止它们的存在。大多数实现都提供了一些额外类型的

，它们工作得很好。制作

这些语言的一部分根本不可能，而且不会牺牲编译器执行优化

程序所需的能力。

为什么会牺牲编译器做他们需要的能力

优化程序？


std :: complex<标准化了。 STL是标准化的。为什么我们没有b $ b我们有一个大的整数模板？

*没有标准的获取方式堆栈踪迹。

为什么你需要它？这不是调试器的用途吗？

*叹息* ...堆栈跟踪对于登录向客户发布

的应用程序非常有用。当附加到例外情况时，它们对于跟踪客户体验到的间歇性错误非常有用。

C++ is one of my favorite languages to work in. This is because it has
so many differrent strengths. But there is also a number of blemishes
in the language -- some could potentially be fixed, others are not
likely. I wanted to open a discussion on what people think are the
good and bad things about C++. Here are my lists:

Good things about C++
---------------------
- multi-paradigm language.
- const-specifications
- deterministic destruction
- semi-strong typed (since there are some implicit conversions allowed)
- preprocessor -- it''s powerful not evil. Powerful things just often
can be used for evil purposes -- and unfortunately, the preprocessor
sometimes is used in evil ways.
- Real multiple inheritance. Again, it''s powerful, not evil.
- templates -- more powerful than generics provided by other languages.
- partial template specialization.
- template meta-programming.
- SFINAE, RAII, CRTP
- Is portable to more platforms than most other languages. (This is
due in part to having fewer standard libraries.)
Bad things about C++
--------------------
- Some ''baggage'': throw specifications, std::vector<bool>, ''export'',
some C-baggage
- No true-typedefs; typedefs are really type aliases.
- A lot of things to learn
- Due to the way C++ has evolved, some things are more complicated than
they need to be.
- Too much undefined behavior.
- No support for properties.
- No standard for name mangling.
- No reflection capabilities.
- No garbage collection. Though, GC is often used incorrectly like the
preprocessor and multiple-inheritance. Also note that there are GC
libraries for C++ -- but there are potentially some advantages to be
gained if GC were added to the language.
- Missing libraries: (though, there are many widely available
cross-platform libraries that do fill in the gaps)
* No standardized threading model/library
* No standard GUI library. However, we should note that standard
GUI''s are typically not used for state-of-the-art, fancy looking apps.
The Java standard doesn''t support the newest GUI features of OSX,
Windows Vista, OpenGL, or DirectX.
* The standard libraries don''t cover some very common things, like
decimal and large-integer types, the ability to handle directory
structures, etc....
* No standard way to obtain stack-traces.

解决方案

Kevin Hall wrote:

C++ is one of my favorite languages to work in. This is because it
has so many differrent strengths. But there is also a number of
blemishes in the language -- some could potentially be fixed, others
are not likely. I wanted to open a discussion on what people think
are the good and bad things about C++. Here are my lists:

Good things about C++
---------------------
- multi-paradigm language.
- const-specifications
- deterministic destruction
- semi-strong typed (since there are some implicit conversions
allowed)

Is that a good thing? If it is, why is "semi-" a good thing? Would
plain strong typing with all conversions explicit be a better thing?

- preprocessor -- it''s powerful not evil. Powerful things just often
can be used for evil purposes -- and unfortunately, the preprocessor
sometimes is used in evil ways.

I don''t believe the preprocessor is powerful enough.

- Real multiple inheritance. Again, it''s powerful, not evil.

Is there any other kind besides "real"? What other multiple inheritance
can there be?

- templates -- more powerful than generics provided by other
languages.

Oops... Did you mean to compare languages here? Read the FAQ.

- partial template specialization.
- template meta-programming.
- SFINAE, RAII, CRTP
- Is portable to more platforms than most other languages. (This is
due in part to having fewer standard libraries.)

Not only libraries. Absence of explicitly sized types plays big part
in that too.

Bad things about C++
--------------------
- Some ''baggage'': throw specifications, std::vector<bool>, ''export'',
some C-baggage

Hos is C baggage a bad thing? Have you any idea how much code was
possible to simply bring over, compile and never worry?

- No true-typedefs; typedefs are really type aliases.

Not sure what you mean here. What "true" typedefs do you need?

- A lot of things to learn

You don''t need a lot of things to learn. See advantage #1, you only
need to learn what you''re going to apply.

- Due to the way C++ has evolved, some things are more complicated
than they need to be.

Like what? Keep in mind the need to provide backward compatibility.

- Too much undefined behavior.

What would you do instead? Define it and limit the chances for
optimizers to work, or define it and limit the number of platforms
C++ would be possible to implement on?

- No support for properties.

What do you mean?

- No standard for name mangling.

Why would you need it? C++ is source-code portable. Why would you
need standard in name mangling?

- No reflection capabilities.

You mean, built-in, right? Well, how much do you need provided for
you? After all, what are the programmers for?

- No garbage collection. Though, GC is often used incorrectly like
the preprocessor and multiple-inheritance. Also note that there are
GC libraries for C++ -- but there are potentially some advantages to
be gained if GC were added to the language.

Like what, for example?

- Missing libraries: (though, there are many widely available
cross-platform libraries that do fill in the gaps)
* No standardized threading model/library

There isn''t any across as many platforms as C++ covers.

* No standard GUI library. However, we should note that standard
GUI''s are typically not used for state-of-the-art, fancy looking apps.
The Java standard doesn''t support the newest GUI features of OSX,
Windows Vista, OpenGL, or DirectX.

Again, it would only be applicable to a very few platforms. Why
would you want to define something that cannot be used everywhere
where the language can be used?

* The standard libraries don''t cover some very common things, like
decimal and large-integer types, the ability to handle directory
structures, etc....

What''s a decimal type? Large-integer types are platform-specific,
and C++ doesn''t prohibit their existence. Most implementations have
some additional types provided, and they work just fine. Making
those part of the language is simply impossible without sacrificing
the ability of the compilers to do what they need to optimize the
programs.

* No standard way to obtain stack-traces.

And why do you need that? Isn''t that what the debuggers are for?

It all sounds like you''ve lived too much in <insert your interpreted
language hereland. Snap out of it!

V
--
Please remove capital ''A''s when replying by e-mail
I do not respond to top-posted replies, please don''t ask

Victor Bazarov wrote:

Kevin Hall wrote:

>>- No standard for name mangling.

Why would you need it? C++ is source-code portable. Why would you
need standard in name mangling?

I can go along with this one, try linking library X built with compiler
A into an application built with compiler B.

<OTAs a real example, look at KDE, a great desktop, but if you want to
build something to link into its libraries, or Qt, you have to use the
same compiler that was used to build them. </OT>

--
Ian Collins.

Victor Bazarov wrote:

Kevin Hall wrote:

- semi-strong typed (since there are some implicit conversions
allowed)Is that a good thing?

If it is, why is "semi-" a good thing? Would
plain strong typing with all conversions explicit be a better thing?

There are some implicit conversions which are OK (integer to double
conversion for example). But I appreciate the strong typing elsewhere.

- preprocessor -- it''s powerful not evil. Powerful things just often
can be used for evil purposes -- and unfortunately, the preprocessor
sometimes is used in evil ways.

I don''t believe the preprocessor is powerful enough.

Yes, it can be more powerful. C99 brings a tiny bit more power. But
something more powerful that is standardized would be nice.

- Real multiple inheritance. Again, it''s powerful, not evil.

Is there any other kind besides "real"? What other multiple inheritance
can there be?

Yes, there are many people that say inheriting multiple interfaces is a
type of MI and is good enough (some even say it''s better). I disagree.

- templates -- more powerful than generics provided by other
languages.

Oops... Did you mean to compare languages here? Read the FAQ.

Not in the sense of ''what is better -- language X or C++''. But if
something can be learned from features implemented in other languages,
then so be it. (Besides, there is no ''official'' FAQ for this
unmoderated group -- despite what some FAQs claim. This was discussed
not too long ago in this forum.)

- Is portable to more platforms than most other languages. (This is
due in part to having fewer standard libraries.)Not only libraries.

Absence of explicitly sized types plays big part in that too.

True. C99''s <stdint.hwill help a little bit when C++0x standardizes
C++''s use of it.

- Some ''baggage'': throw specifications, std::vector<bool>, ''export'',
some C-baggage

Hos is C baggage a bad thing? Have you any idea how much code was
possible to simply bring over, compile and never worry?

Please note that I said ''some'' -- not all. I think that backwards
compatibility with C is a wonderful thing. But as we all know, C++ is
not 100% compatible with C. ''\0'' is a char in C++, whereas it is a int
in C.

Anyway, I''m having trouble thinking of the examples of the top of my
head, but there are some things inherited from C that are more vexing
(to me anyway) than if that compatibility had been dropped.

- No true-typedefs; typedefs are really type aliases.

Not sure what you mean here. What "true" typedefs do you need?

"true typedefs" means that a typedef and its base type are different
types in the language type-system. In otherwords: ''bar Foo(bar);'' and
''int Foo(int);'' describe two different functions if bar is typedef''ed
as an int.

There are many articles online and parts of books written about "true"
typedefs. Here''s one online reference (look halfway down the page):
http://www.artima.com/cppsource/typesafety3.html

- A lot of things to learn

You don''t need a lot of things to learn. See advantage #1, you only
need to learn what you''re going to apply.

True.

- Due to the way C++ has evolved, some things are more complicated
than they need to be.

Like what? Keep in mind the need to provide backward compatibility.

I understand backward compatibility is a good thing. Nevertheless,
there are downsides to it too. std::vector<bool>. is one such example.
As far as I can tell, it was known before the standard was finally
released that std::vector<boolcould not fully act like a container,
but it was kept anyway. And if you really need a genuine vector of
booleans then you have to jump through hoops to get one.

- Too much undefined behavior.

What would you do instead? Define it and limit the chances for
optimizers to work, or define it and limit the number of platforms
C++ would be possible to implement on?

I said ''too much'', not ''C++ has UB''. Even people on the standards
comittee and other people commonly held up as C++ experts like
Alexandrescu say there is *too much* UB.

I don''t argue that some UB is needed.

- No support for properties.

What do you mean?

See MS''s __declspec(property):
http://msdn2.microsoft.com/en-us/lib...hd(VS.80).aspx

Again, there are many articles and chapters of books written on how to
simulate properties to C++.

- No standard for name mangling.

Why would you need it? C++ is source-code portable. Why would you
need standard in name mangling?

To support inter-compiler libraries, a standard way for other languages
to tap into C++''s APIs. Other languages usually can only tap into
functions declared as ''extern "C"''. If there were a standard for name
mangling, then it would be easier to tap into C++ interfaces.

- No reflection capabilities.

You mean, built-in, right? Well, how much do you need provided for
you? After all, what are the programmers for?

Yes, I meant built-in. Reflection would make some things a lot easier
-- for example finding the names of enumeration values.

- No garbage collection. Though, GC is often used incorrectly like
the preprocessor and multiple-inheritance. Also note that there are
GC libraries for C++ -- but there are potentially some advantages to
be gained if GC were added to the language.

Like what, for example?

COW strings (and other COW objects) would be easier to implement.

- Missing libraries: (though, there are many widely available
cross-platform libraries that do fill in the gaps)
* No standardized threading model/libraryThere isn''t any across as many platforms as C++ covers.

* No standard GUI library. However, we should note that standard
GUI''s are typically not used for state-of-the-art, fancy looking apps.
The Java standard doesn''t support the newest GUI features of OSX,
Windows Vista, OpenGL, or DirectX.

Again, it would only be applicable to a very few platforms. Why
would you want to define something that cannot be used everywhere
where the language can be used?

There are advantages to defining something that can''t be used
everywhere. If you need to do something, and that something is
available, then there is a standard way to use it. The POSIX standard
is very popular, but it can''t be used everywhere.

Some other languages have thrived on having standard GUIs -- even
though the look and feel of those GUIs seem quite dated.

* The standard libraries don''t cover some very common things, like
decimal and large-integer types, the ability to handle directory
structures, etc....

What''s a decimal type?

http://www.google.com/search?hl=en&p...a+type&spell=1.

Large-integer types are platform-specific,
and C++ doesn''t prohibit their existence. Most implementations have
some additional types provided, and they work just fine. Making
those part of the language is simply impossible without sacrificing
the ability of the compilers to do what they need to optimize the
programs.

Why would it sacrifice the ability of compiler to do what they need to
optimize the programs?

std::complex<was standardized. The STL was standardized. Why can''t
we have a large integer template?

* No standard way to obtain stack-traces.

And why do you need that? Isn''t that what the debuggers are for?

*sigh*... stack-traces are very useful for logging in applications that
are released to customers. When attached to exceptions, they are also
very useful in tracking down intermittent errors customers experience.

这篇关于C ++：好与坏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！