请不要阅读专业的C / C ++程序员）。
在本文中，我表达了我的观点，如果您不同意，请在评论中提出理由。
本文的目的：指出我真的不喜欢C和C ++的缺点，并鼓励您使用该语言的新版本，甚至可能提供一些想法以改进该标准。
好吧，是时候重新点燃霍利瓦尔了。
我想每个人都知道在C ++中有很多可怕的地方。 特别是如果我们在谈论旧类型，则新字符串中的许多问题已得到修复和改进，但是仍然不支持unicode（！）。
在C ++ 20标准中，这有点像输入unicode字符串。
C ++ 20！ 尽管C ++
自1983年以来就已经
存在 。
打开您喜欢的IDE，然后尝试编译以下代码：
#include <iostream> #include <cstdio> int main() { char string [256]; std::cout << ": "; gets(string); std::cout << ": " << string; return 0; }
UPD1：评论员说krakozyabry仅在Windows上。 可以肯定的是，忘记写了。
但是仍然不愉快。
我使用GCC编译器Dev Cpp进行编译。
编译并查看：
屏幕输出良好，是吗？
现在，用char * string替换char string [256]。
我并不是说这应该可行，但是编译器应该抛出尽可能高的错误。
我们挂了一个工作程序。
如果编译器抛出错误会更好。
整个问题是编译器不仅编译了它，还没有编译它
发出警告。
这是另一个笑话：
#include <iostream> using namespace std; int main(){ int arr[100]={}; cout<<arr[101]<<endl; return 0; }
我们期望什么？ 编译器将告诉我们，由于只有100个元素，因此您无法访问数组的101个元素，但是我们进行编译，运行并看到了... 32765（至少在我的硬件上）。
嗯
现在让我们测试以下代码：
int i = 5; i = ++i + ++i; std::cout<<i;
您认为他会带来什么？
正确答案取决于编译器。
在GCC中，该值为14，但取决于优化标志。
在另一个编译器中，它很容易是12 ...
我想每个人都知道，在C语言中以及加号语言中都有一堆语法糖，这远非总是需要的。
例如
std::cout<<4["string"]; 这是有效的代码
它输出n，就像
std::cout<<"string"[4];很好，是吗？
现在关于病人。
C ++和网络。
这是2个匹配性很差的概念。
只需尝试使用标准C ++库从您喜欢的站点下载猫图像。
在采用C ++ 17标准之前这是不可能的。
您不能在同一标准库中使用JSON。
对此很赞。
通常，在C ++中使用JSON就像一场噩梦。
来源您是否认为条件始终为假？
if(sizeof ('a') != sizeof (char)){
不，你错了。
如果将其编译为C ++项目，则很可能不满足该条件。
不应该。[1]
如果像C项目一样，在这种情况下，sizeof（'a'）== sizeof（int）。
这些就是这些。
[1]通常，许多不同的C和C ++编译器也是一个问题。
由于许多解决方案尚未标准化，因此只能在某些编译器中使用。
例如，C ++中的128位数字。 在gcc和clang中有__int128类型，而在Visual Studio中则不是，因为它不是标准类型。 或者，例如，Visual Studio中的字符串。
String^ MyString3 = "Hello, world!";
或者，例如，在老人Borland C ++ Builder中，您可以使用Object Pascal编写代码。
并且有很多这样的时刻。
一个特别的麻烦是缺少C和C ++软件包列表。
随之而来的是什么？ 使用新版本的C ++，例如C ++ 17，将会解决一些问题。
我必须说，在最接近的竞争对手C ++-Rust中，该列表中的问题并不是很多，例如，有一堆很棒的货物，但是当然它也不是完美的。
您知道C和C ++有哪些问题？
在评论中写。
UPD：似乎很多人误解了我的文章：
我绝对不想批评C / C ++并说写在草稿上。
我只是指出C / C ++的缺点，因为它们有一些缺点。
一切都有弊端，我只是分享了自己的想法。
UPD2：
在评论中，许多人写道，黄蜂以这种方式工作，通常这些都是功能。 你们错了。
越来越多的证据表明，您可以制作一种系统编程语言，而用这种语言编程并不容易。
只是C / C ++充满了无人能解决的遗留解决方案，因为它可能破坏向后兼容性。
是的，这是我的看法，这是
主观的 。
如果您不同意-最好发表评论，而不要愚蠢地减去，因为我们所有人的意见
主观上。