为什么C / C ++错误是如此模糊/狡猾？ [英] Why C/C++ errors are SO obscure/devious??

问题描述

您好，


我不是C新手，但我正在教C编程（好吧......第一次...... / b
编程和然后C）这些天对其他人来说，它正在推动我对这种语言的反思。


这种情况​​并不罕见a}编写代码，并在编译时得到

错误之后的18956778行错误，在一个绝对的

正确的代码段中。或者，有时在我的旅程中我收到错误

在文件中报告，检查并发现它是正确的，并发现它是由另一个文件中的错误引起的。总的来说，我注意到很多，

，如果不是全部的话，来自编译器的错误消息非常简短而且神秘，

而有些单词有时可以帮助一个理解很多

什么是错的，在哪里，对于新手来说。好吧，不仅仅是为了他们......也许一个

编译器开关--NOOB_ERR_MSGS对某些人来说非常方便：o）


为什么可以'' ta编译器提供有关错误的更准确的信息？

难道这不是节省时间，压力和金钱吗？


另一个例子：你有没有遇到错误？ line多个定义

of ...                     喜欢

这个：


错误：< variable | function | method>的多个定义X.

X定义：

1）< here1>作为变量

<代码行定义......>

2）< here2>作为变量

<代码行定义...>

3）< here3>作为功​​能

<代码行定义...>

选择合适的定义：


这个是交互式编译，不是吗？为什么不？为什么编译器

不能简单地问我们，有疑问，并且响应修改源

相应的自己，在这种情况下和其他类似的？这将使b / b $ b轻松减轻编程工作量。


您对此事有何看法？

Hello,

I''m not a C newbie, but I''m teaching C programming (well... FIRST
programming and then C) to other guys these days and it''s driving me to
some reflexions on the language.

It''s not uncommon to forget a } writing code, and at compiling time get
an error 18956778 lines after the mistake, in an otherwise absolutely
correct piece of code. Or, sometimes in my journeys I got errors
reported in a file, checked and found it correct, and discovered it was
caused by an error in another file. And in general, I noted that many,
if not all, error messages from the compiler are VERY short and cryptic,
while a couple of words more could sometimes help a lot in understanding
what''s wrong and where, for newbies. Well, not only for them... maybe a
compiler switch --NOOB_ERR_MSGS could be very handy for some people :o)

Why can''t a compiler give more accurate informations about errors?
Shouldn''t this save time, stress and money?

Another example: have you ever met the error line "Multiple definitions
of..."?

For example, why can''t a compiler start a negotiation "on the fly" like
this:

ERROR: Multiple definitions of <variable|function|method> X.
X defined:
1) <here1> as variable
<line of code definition...>
2) <here2> as variable
<line of code definition...>
3) <here3> as function
<line of code definition...>
Choose which definition is the right one:

This is "interactive compiling", isn''t it? Why not? Why the compiler
can''t simply ask us, in doubt, and on response modify sources
accordingly on its own, in this case and in other similar? This would
ease the programming effort a lot.

What are your opinions on this matter?

推荐答案

" Massimo Soricetti" <毫安********** @ hotmail.com>在消息中写道

新闻：IM ********************* @ news4.tin.it ...

"Massimo Soricetti" <ma**********@hotmail.com> wrote in message
news:IM*********************@news4.tin.it...

你好，

我不是C新手，但我现在正在向其他人教授C编程（嗯...... FIRST
编程，然后是C）它正在驱使我对语言进行一些反思。
忘记编写代码并不罕见，
非常罕见......让你的学生养成习惯在键入开头括号后立即键入结束

大括号...然后填写中间。

并且在编译时错误后出现错误18956778行
你的功能太长了;-)

在一段绝对正确的代码中。或者，有时在我的旅途中，我在文件中报告错误，检查并发现它是正确的，
并发现它是由另一个文件中的错误引起的。总的来说，
我注意到编译器中的许多（如果不是全部）错误消息非常简短且含糊不清，而更多的单词有时可以帮助很多人理解什么对于新手来说，这是错误的。那么，不仅仅是因为它们......也许是编译器开关--NOOB_ERR_MSGS对某些人来说非常方便：o）

为什么编译器不能提供更多有关错误的准确信息？
这不应该节省时间，压力和金钱吗？
您对C标准有何疑问？ （这是新闻组的主题

）

另一个例子：你有没有遇到错误行多个定义
...？
Nope。

例如，为什么编译器无法在运行中开始协商？喜欢
这个：

错误：< variable | function | method>的多个定义X.
X定义：
1）< here1>作为变量
<代码行定义......>
2）< here2>作为变量
<代码行定义...>
3）< here3>作为函数
<代码行定义...>
选择合适的定义：

这是交互式编译，不是吗？ ？为什么不？为什么编译器不能简单地询问我们，有疑问，并且响应在其自身上相应地修改源，在这种情况下和其他类似的？这样可以大大简化编程工作。

您对此事有何看法？

Hello,

I''m not a C newbie, but I''m teaching C programming (well... FIRST
programming and then C) to other guys these days and it''s driving me to
some reflexions on the language.
It''s not uncommon to forget a } writing code, Very uncommon... get your students in the habit of typing the closing
brace immediately after typing the opening brace... then fill in the middle.
and at compiling time get an error 18956778 lines after the mistake Your functions are too long ;-)
in an otherwise absolutely correct piece of code. Or, sometimes in my
journeys I got errors reported in a file, checked and found it correct,
and discovered it was caused by an error in another file. And in general,
I noted that many, if not all, error messages from the compiler are VERY
short and cryptic, while a couple of words more could sometimes help a lot
in understanding what''s wrong and where, for newbies. Well, not only for
them... maybe a compiler switch --NOOB_ERR_MSGS could be very handy for
some people :o)

Why can''t a compiler give more accurate informations about errors?
Shouldn''t this save time, stress and money? What is your question relating to the C standard? (which is the topic of
this newsgroup)
Another example: have you ever met the error line "Multiple definitions
of..."? Nope.
For example, why can''t a compiler start a negotiation "on the fly" like
this:

ERROR: Multiple definitions of <variable|function|method> X.
X defined:
1) <here1> as variable
<line of code definition...>
2) <here2> as variable
<line of code definition...>
3) <here3> as function
<line of code definition...>
Choose which definition is the right one:

This is "interactive compiling", isn''t it? Why not? Why the compiler can''t
simply ask us, in doubt, and on response modify sources accordingly on its
own, in this case and in other similar? This would ease the programming
effort a lot.

What are your opinions on this matter?

我不想修改编译器我自己的消息来源！

我更愿意看到有能力的老师教授的学生......

这样可以简化编程工作！ :-)


Mark

I don''t want the compiler modifying my sources on it''s own!
I''d prefer to see students taught by competent teachers...
That would ease the programming effor a lot! :-)

Mark

>我不是C新手，但我在教C编程（好吧...... FIRST

>I''m not a C newbie, but I''m teaching C programming (well... FIRST

编程，然后C）这些天给其他人，它正在驱使我对语言做出一些反思。

忘记编写代码并且在编译时错误地在错误之后得到错误18956778行并不常见，在一段绝对正确的代码中。


编译器不知道这是}缺少的地方。那里

可能是其他几个也是正确代码的地方。

或者，有时在我的旅程中我收到错误
在文件中报告，检查并找到它是正确的，并发现它是由另一个文件中的错误引起的。总的来说，我注意到许多，如果不是全部，来自编译器的错误消息非常简短和含糊不清，而有些单词有时可以帮助很多人理解
什么对于新手来说，这是错误的。那么，不仅仅是为了他们......也许一个
编译器开关--NOOB_ERR_MSGS对某些人来说非常方便：o）


更改的内容：

undefined symbol _main

to

undefined symbol _main - 你忘了定义main（）吗？


可能帮助，但在很多情况下，编译器错误消息将启动

如果它试图产生详细消息

但是仍然反映编译器不知道如何类似法律文档你犯了多少可能的错误

错误。甚至上面，它可能不知道main（）应该是一个函数，而不是局部变量。


一个例子：几乎每次我在系统提供的

包含文件中获取语法错误（不是ANSI C标题，而是与

OS一起提供的文件），这是因为我忘记了包括一个预先标题（通常是

< sys / types.h>），在此标题之前输入*之前的*。但编译器永远不会建议：b / b
< sys / proc.h>中的第115行语法错误，
可能pid_t应该是typedef但是不是吗？在这种情况下，

我想知道它会提出多少错误建议，当一个

包含文件真的丢失但它必须猜测应该有什么

是否在其中？

为什么编译器无法提供有关错误的更准确信息？


编译器不是通灵的。它通常无法判断你是否使用错误的类型声明变量，或忘记了一个级别

的间接引用它。

难道这不是节省时间，压力和金钱吗？


当它猜错时，它会造成压力，浪费时间和金钱。

另一个例子：你有没有遇到错误行多个定义<例如，为什么'''''''''''''''''''''''''''''''''''''''''''''''''''''''喜欢
这个：

错误：< variable | function | method>的多个定义X.
X定义：
1）< here1>作为变量
<代码行定义......>
2）< here2>作为变量
<代码行定义...>
3）< here3>作为功​​能
<代码行定义...>


到目前为止，这将是一个很好的消息，列出所有

定义。

选择哪个定义是正确的一个：


我怎么回答这个问题来表明（3）是一个错字和（2）

应该被宣布为静态？我没有记住参考文献中所有

的位置，所以我不能说哪个参考应该是

哪个功能脱了我的头脑。还有一些方法

来回答这样的两条消息（关于相同的函数/变量）

其中我的答案无法用有效的C语言编码全局

重命名其中一个函数/变量。哦，是的，当编译器

正在编译foo.c时，它不知道如果它执行全局重命名

函数，它必须修复bar.c中的参考文献，在另一个国家的另一台计算机上开发的一组客户b / b
和CD-ROM上的分发磁盘。


我不想让编译器在编译

开源软件包时尝试交互。最有可能的配置脚本包括错误的库或包含文件，并且您建议的消息

将完全具有误导性。另外，我不希望它出于任何原因写在我背后的源代码上。

这是交互式编译，不是吗？


我希望我的源代码能够反映使用的实际源代码，而不是

略微接近它。

为什么不呢？为什么编译器不能简单地问我们，有疑问，以及响应修改源自相应的，在这种情况下和其他类似的？这将大大减轻编程工作量。


如果编译器修改了源代码，那就更好用了

* MY * style和ONLY * MY * style。

您对此事有何看法？

programming and then C) to other guys these days and it''s driving me to
some reflexions on the language.

It''s not uncommon to forget a } writing code, and at compiling time get
an error 18956778 lines after the mistake, in an otherwise absolutely
correct piece of code.
The compiler doesn''t know that this is where the } is missing. There
may be several other places that would also be correct code.
Or, sometimes in my journeys I got errors
reported in a file, checked and found it correct, and discovered it was
caused by an error in another file. And in general, I noted that many,
if not all, error messages from the compiler are VERY short and cryptic,
while a couple of words more could sometimes help a lot in understanding
what''s wrong and where, for newbies. Well, not only for them... maybe a
compiler switch --NOOB_ERR_MSGS could be very handy for some people :o)
Something like changing:
undefined symbol _main
to
undefined symbol _main - Did you forget to define main()?

might help, but in many cases, the compiler error message would start
to resemble legal documents if it tried to produce a detailed message
but still reflect that the compiler DOES NOT KNOW which of many possible
mistakes you made. Even above, it may not know that main() is supposed
to be a function, not a local variable.

One example: almost every time I get a syntax error in a system-supplied
include file (not the ANSI C headers, but ones that come with the
OS), it''s because I forgot to include a prerequesite header (often
<sys/types.h>) that typedef''d something *BEFORE* this header. But
the compiler never suggests: syntax error on line 115 in <sys/proc.h>,
possibly pid_t should be a typedef but isn''t? In such a situation,
I wonder how many WRONG suggestions it would come up with, when an
include file really is missing but it has to guess what should have
been in it?
Why can''t a compiler give more accurate informations about errors?
The compiler is not psychic. It often can''t tell whether you
declared the variable with the wrong type, or forgot one level
of indirection on the reference to it.
Shouldn''t this save time, stress and money?
When it guesses WRONG, it will cause stress and waste time and money.
Another example: have you ever met the error line "Multiple definitions
of..."?

For example, why can''t a compiler start a negotiation "on the fly" like
this:

ERROR: Multiple definitions of <variable|function|method> X.
X defined:
1) <here1> as variable
<line of code definition...>
2) <here2> as variable
<line of code definition...>
3) <here3> as function
<line of code definition...>
Up to this point, this would be a nice message, listing all the
definitions.
Choose which definition is the right one:
How would I answer this to indicate that (3) is a typo and (2)
should have been declared static? I have not memorized where all
of the references are, so I can''t say which reference should go
with which function off the top of my head. There are also ways
to answer TWO messages like that (about the same function/variable)
where my answers cannot be coded in valid C short of globally
renaming one of the functions/variables. Oh, yes, when the compiler
is compiling foo.c, it DOESN''T know that if it does a global rename
of a function, it has to fix up the references in bar.c, a bunch
of clients being developed on another computer in another country,
and the distribution disk on CD-ROM.

I don''t want the compiler to try to be interactive when I''m compiling
an open-source package. Most likely the configure script is including
the wrong libraries or include files, and the message you suggest
will be entirely misleading. Also, I don''t want it writing on
source code behind my back for any reason.
This is "interactive compiling", isn''t it?
I want my source code to reflect the actual source code used, not
a slight approximation to it.
Why not? Why the compiler
can''t simply ask us, in doubt, and on response modify sources
accordingly on its own, in this case and in other similar? This would
ease the programming effort a lot.
If the compiler modifies source code, it had darn well better use
*MY* style and ONLY *MY* style.
What are your opinions on this matter?

提供更多详细信息的更清晰的错误消息通常会有所帮助。

我想我是''已经看到了抱怨

变量类型的消息（在包含许多变量的行上）而没有命名

变量。


修改源代码的编译器是个坏主意。唯一的例外

我将为void main（），编译器应该* DELETE *

违规的源代码。

Gordon L. Burditt

Clearer error messages that give more details would often help.
I think I''ve seen messages that complain about the type of a
variable (on a line with many variables in it) without naming the
variable in question.

Compilers modifying source code is a bad idea. The only exception
I''ll make is for void main(), where the compiler should *DELETE*
the offending source code.

Gordon L. Burditt

Massimo Soricetti写道：

Massimo Soricetti wrote:

为什么可以编译器能否提供更准确的错误信息？
这不应该节省时间，压力和金钱吗？

Why can''t a compiler give more accurate informations about errors?
Shouldn''t this save time, stress and money?

为什么要提供简明准确的信息？你可以这样做：

http://www.ralentz.com/old/mac/humor/mpw-c-errors.html


是的，我必须工作与MPW一段时间，我在这一次或另一次获得了大部分

。 *非常*非常*很快*。

Why give concise and accurate messages when you can do this instead:

http://www.ralentz.com/old/mac/humor/mpw-c-errors.html

And yeah, I had to work with MPW for a while, and I got most of those
at one time or another. It got *very* old *very* quickly.

这篇关于为什么C / C ++错误是如此模糊/狡猾？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！