c语言语法错误和逻辑错误_如果我对c非常错误怎么办

c语言语法错误和逻辑错误

I’ve been running away from C++ for most of my professional career. And I have to admit, in 15 years, I didn’t run away very far.

在我的大部分职业生涯中，我一直都在逃避C ++。 而且我不得不承认，在15年的时间里，我并没有走得太远。

My first full-time job was about maintaining a project written by five different teams over eight years. Every team brought the fad of their own into the project so it had everything from 3-star programming to the Alexandrescu-style template magic. It wasn’t something designed from the top. Or from the bottom. It was more like a scrapheap challenge project.

我的第一份全职工作是在8年的时间内维护由五个不同团队编写的项目。 每个团队都将自己的时尚带入了项目，因此它拥有从三星级编程到Alexandrescu风格的模板魔术的所有功能。 这不是从顶部设计的。 还是从底部开始。 这更像是一个残酷的挑战项目。

By that time, I already had some experience with Delphi, C, Python, and Assembly from academia and part-time jobs but C++ was new to me. Especially the “bring it all, bitch” type of C++.

到那时，我已经在学术界和兼职工作中使用过Delphi，C，Python和Assembly的一些经验，但是C ++对我来说是新手。 尤其是C ++的“混血儿”类型。

Needless to say, I was not impressed by its elegance and simplicity since there was none of the latter or the former. Suddenly, the company needed someone to write shaders in GLSL, and I willfully agreed to give it a try. It couldn’t be worse than C++, right?

毋庸置疑，它的优雅和简单让我印象深刻，因为后者和前者都没有。 突然，该公司需要有人用GLSL编写着色器，我自愿同意尝试一下。 它不会比C ++差，对吧？

And it wasn’t. Next, there were tools in MASM32, tech-demos in plain C, a game scene editor in C#, a game engine in Objective-C, a side project in ActionScript, a documentation system in PHP, some front end works in JavaScript, some back end works in Erlang, a bit of Haskell, a bit of Scheme, C again, Assembly again, Python again and again and again.

事实并非如此。 接下来，有MASM32中的工具，纯C中的技术演示，C＃中的游戏场景编辑器，Objective-C中的游戏引擎，ActionScript中的辅助项目，PHP中的文档系统，一些JavaScript前端工作，后端在Erlang，Haskell，Scheme，C，Assembly，Python一次又一次地工作。

I gathered some of these experiences into essays and even published a free book about this whole adventure. The conclusion, both from the career and the book is, not only all these things are not worse than C++ but C++ is not worse than all these things.

我将其中的一些经验收集到论文中，甚至出版了一本关于整个冒险的免费书。 从职业生涯和本书中得出的结论是，不仅所有这些东西都不比C ++差，而且C ++并不比所有这些东西差。

Or, in other words, they are all equally bad. Or good, it really depends on your perspective.

或者，换句话说，它们都同样糟糕。 还是好，这实际上取决于您的观点。

In my opinion, the whole language design was running in circles for the last 50 years or so. There is no new language that would differ from C++ more than APL (1959) differs from Prolog (1972). There are no distinct advantages in Julia or Rust or even Idris that could make C++ obsolete. There is no reason to invest heavily in a new shiny thing if you’re getting the same assembly with the same effort in it.

我认为，过去50年来，整个语言设计一直在运转。 没有比APL(1959)与Prolog(1972)不同的新语言与C ++的不同。 Julia或Rust甚至Idris都没有明显的优势可以使C ++过时。 如果您以相同的努力获得了相同的组件，则没有理由在新的闪亮产品上投入大量资金。

C++ is fine enough to live and prosper.

C ++足以生存和繁荣。

But what if I am terribly wrong?

但是，如果我错了怎么办？

I mean, I am ok with C++ but I did spend a lot of time practicing C++. I am quite obviously biased by experience. And all the diving into other languages only made this bias worse. For instance, encapsulation in C++ is pretty much like an alcoholic hiding a bottle from the future self. But in Objective-C, it suddenly starts to make sense. Objects are not just structs with functions, they are truly separated entities with thin interfaces.

我的意思是，我对C ++没问题，但是我确实花了很多时间练习C ++。 我显然对经验有偏见。 而所有潜入其他语言的行为只会使这种偏见更为严重。 例如，用C ++进行封装几乎就像一个酒鬼，将酒瓶藏在未来的自我中。 但是在Objective-C中，它突然变得有意义。 对象不仅仅是具有功能的结构，它们是具有瘦接口的真正分离的实体。

Type system in C++ is meant mostly to aggravate people from teams other than yours. But in Haskell, with its type-classes setting explicit relations between types, it really brings value into the design.

C ++中的类型系统主要是为了使除您之外的团队中的其他人更加恼火。 但是在Haskell中，通过其类型类设置类型之间的显式关系，它确实为设计带来了价值。

Unlike in D which allows you meta-programming in D itself, template meta-programming in C++ is alien even to C++. But when you realize that it’s actually a completely different language trying to get out, you see it in another light.

与在D中允许您在D本身中进行元编程的D语言不同，C ++中的模板元编程甚至与C ++无关。 但是，当您意识到尝试脱身实际上是一种完全不同的语言时，您会从另一角度看到它。

So yes, I may have learned a few languages through the years but essentially I just learned C++ better. And now it’s suddenly ok. No wonder.

是的，这些年来，我可能已经学过几种语言，但从本质上来说，我对C ++的学习更好。 现在突然没事了。 难怪。

But what about someone who didn’t have this experience? Do they have to struggle?

但是没有这个经验的人呢？ 他们必须奋斗吗？

How much effort people from all over the world spend fighting the compiler to do things right? Fixing the bugs that didn’t have to occur in the first place? Redesigning the code written back when multiple inheritance was considered cool since Java doesn’t have it?

来自世界各地的人们为与编译器做正确的事情付出了多少努力？ 修复最初不需要发生的错误？ 重新设计在多重继承被认为很酷的情况下写回的代码，因为Java没有它？

Does it really make sense to invest years in mastering a language instead of mastering the domain? Learning all the accidental quirks of it, learning the best practices, learning the pitfalls?

花数年时间掌握某种语言而不是掌握领域真的有意义吗？ 学习所有偶然的怪癖，学习最佳实践，学习陷阱？

From the user’s standpoint, a programming language is about just as relevant to the product as a text editor the programmer uses. It’s just something that automates machine code generation. A transformer that turns programming ideas into an executable thing that does the actual work.

从用户的角度来看，编程语言与产品的相关程度几乎与程序员使用的文本编辑器一样。 它只是使机器代码生成自动化的工具。 一个将编程思想转变为可执行实际工作的可执行文件的转换器。

Work is important, the language isn’t.

工作很重要，语言不重要。

And C++ is just not effective enough in turning programmers’ ideas into products. Its accidental complexity brings too much overhead. If a junior programmer spends half a day working on a problem pen-and-paper style, and then half a day programming it in C++, they only do something that contributes to the world half of the day. Half of the day spent on googling C++ reference is just a waste.

而且C ++不足以将程序员的想法变成产品。 它偶然的复杂性带来了太多的开销。 如果初级程序员花半天时间来研究有问题的纸笔风格，然后花半天时间用C ++对其进行编程，则他们只会在一天半的时间内为世界做出贡献。 谷歌搜索C ++参考上的一半时间只是浪费。

It would have been fine if there were no alternatives to C++ but there are. Some are more prominent than others but they all suffer by the C++ shadow. Remember, from the standpoint of people like me, C++ is fine enough to live and prosper. We’re already too much invested in the current system to learn things that bring no clear benefit for us.

如果没有C ++的替代品，那就可以了。 有些比其他的更为突出，但是它们都受到C ++阴影的影响。 请记住，从像我这样的人的角度来看，C ++足以生存和繁荣。 我们已经在当前系统上投入了大量资金，无法学习对我们没有明显好处的事情。

And now for the big question. I’m honestly on the fence with this one and I’d like to hear from you in the comments or otherwise.

现在是一个大问题。 老实说，我对此感到不满意，希望在评论中以其他方式收到您的来信。

Should we, the experienced C++ programmers, discourage C++ usage among less experienced programmers like long time smokers discourage smoking among the younger generation?

我们这些经验丰富的C ++程序员是否应该劝阻那些经验不足的程序员(如长期吸烟者)使用C ++，以阻止年轻人吸烟呢？

It does hurt right in the ego but it seems the ethical thing to do, too.

它确实伤害了我的自我，但似乎也符合道德规范。

I mean, sure, I’ve wasted a lot of time convincing the compiler not to be a douche, and I learned to find a masochistic pleasure in doing that, but it’s really not what software creation should be about. If there are better tools, if they save time, save frustration, then maybe we should if not adopt them personally then maybe not divert other people from adopting them?

我的意思是，可以肯定的是，我已经浪费了很多时间说服编译器不成问题，并且我学会了在这种方法中找到受虐狂的乐趣，但实际上这并不是软件创作的目的。 如果有更好的工具，如果它们节省时间，节省挫败感，那么也许我们不应该亲自采用它们，也可能不转移其他人采用它们的能力？

Again, it’s not a rhetorical question. I honestly don’t know. If you could convince me that this is the right thing to do, I’ll stop publishing anything C++ related on my https://wordsandbuttons.online.

同样，这不是一个反问。 老实说我不知道​​。 如果您可以说服我这样做是对的，那么我将停止在https://wordsandbuttons.online上发布任何与C ++相关的内容。

P. S. I’ve added a Twitter poll for this question: https://twitter.com/wordsandbuttons/status/1299666634265763842

PS我已经为这个问题添加了Twitter调查： https : //twitter.com/wordsandbuttons/status/1299666634265763842

翻译自: https://medium.com/@okaleniuk/what-if-i-am-terribly-wrong-about-c-77c11ff011ed

c语言语法错误和逻辑错误