精通C语言 [英] Proficient at C

问题描述

当我们想聘请C程序员时，我们不可避免地会收到那些声称自己精通C的人的简历，或者说b
b 。


对于那些声称自己精通C的人来说，有什么好的问题可以让他们确定他们是否真的。精通

C"正如他们所说的那样？


我能想到一个好问题：


哪个

便携式标准C实现可以接受以下主要定义？


A. int main（void）{/*...*/ }

B. void main（void）{/*...*/}

C. int main（int argc，char * argv []）{/ * ... * /}

D. void main（int argc，char * argv []）{/*...*/}

E. int main（ int argc，char ** argv）{/*...*/}

F. int main（int count，char ** args）{/*...*/}

G.以上都不是。

H.以上所有。


那里有什么其他好的简单基本问题（例如，不要施放

malloc）？


谢谢

- -

jay


BTW，上述问题的正确答案是A，C，E和F.

When we are looking to hire C programmers, we inevitably receive
resumes from people who claim they are "proficient at C", or something
to that extent.

For those who claim they are "proficient at C", what are some good
questions to ask them to determine if they are really "proficient at
C", as they claim?

I can think of one good question:

Which of the following definitions of main are acceptable by a
portable Standard C implementation?

A. int main(void) { /*...*/ }
B. void main(void) { /*...*/ }
C. int main(int argc, char *argv[]) { /*...*/ }
D. void main(int argc, char *argv[]) { /*...*/ }
E. int main(int argc, char **argv) { /*...*/ }
F. int main(int count, char **args) { /*...*/ }
G. None of the above.
H. All of the above.

What other good simple, basic questions are there (e.g., don''t cast
malloc)?

Thanks
--
jay

BTW, the correct answer to the above question is A, C, E and F.

推荐答案

在文章< 55 ******************************** @ 4ax .com>，

jaysome< ja ***** @ hotmail.comwrote：

In article <55********************************@4ax.com>,
jaysome <ja*****@hotmail.comwrote:

>我能想到一个好的问题：

>I can think of one good question:

>
便携式标准C实施可以接受以下哪些主要定义？

>Which of the following definitions of main are acceptable by a
portable Standard C implementation?

> A. int main（void）{/*...*/}
B. void main（void）{/*...*/}
C. int main（int argc，char * argv []）{/*...*/}
D. void main（int argc，char * argv []）{/*...*/}
E. int main（int argc，char ** argv）{/*...*/}
F. int main（int count，char ** args）{/*...*/}
G.以上都不是。
H.上述所有的。

>A. int main(void) { /*...*/ }
B. void main(void) { /*...*/ }
C. int main(int argc, char *argv[]) { /*...*/ }
D. void main(int argc, char *argv[]) { /*...*/ }
E. int main(int argc, char **argv) { /*...*/ }
F. int main(int count, char **args) { /*...*/ }
G. None of the above.
H. All of the above.

> BTW，上述问题的正确答案是A，C，E和F.

>BTW, the correct answer to the above question is A, C, E and F.

这取决于实施所遵循的标准版本

。你的定义都没有从main返回一个值，所以

行为是实现定义的（或者是未定义的，我会用

来检查确切的措辞） C89 / C90。在C99中，这样的情况会自动从$ main返回0，从而使行为定义明确。


-

我们可能会从历史中收集一份政策，通过比较和其他男人用我们自己喜欢的错误和不值得的错误来应用其他男人的预防性苦难。 - 沃尔特·罗利爵士

It depends which version of the Standard the implementation adheres
to. None of your definitions return a value from main, so the
behaviour is implementation defined (or is it undefined, I''d have
to check the exact wording) in C89/C90. In C99 such cases automatically
return 0 from main, rendering the behaviour well-defined.

--
"We may gather out of history a policy, by the comparison and
application of other men''s forepassed miseries with our own like
errors and ill deservings." -- Sir Walter Raleigh

" jaysome" < ja ***** @ hotmail.comwrote in message

news：55 ************************* ******* @ 4ax.com ...

"jaysome" <ja*****@hotmail.comwrote in message
news:55********************************@4ax.com...

当我们想聘请C程序员时，我们不可避免地收到

从声称自己精通C的人那里获得简历，或者在某种程度上获得
。


对于那些声称自己精通的人C，有什么好的

问题，要求他们确定他们是否真的精通

C，正如他们声称的那样？


我可以想到一个好问题：



便携式标准C实现可以接受以下哪些主要定义？


A. int main（void）{/*...*/}

B. void main（void）{/*...* /}

C. int main（int argc，char * argv []）{/*...*/}

D. void main（int argc，char * argv []）{/*...*/}

E. int main（int argc，char ** argv）{/*...*/}

F. int main（int count，char ** args）{/*...*/}

G.以上都不是。

H.以上所有。


还有哪些其他好的简单基本问题（例如，不要施放

malloc）？

When we are looking to hire C programmers, we inevitably receive
resumes from people who claim they are "proficient at C", or something
to that extent.

For those who claim they are "proficient at C", what are some good
questions to ask them to determine if they are really "proficient at
C", as they claim?

I can think of one good question:

Which of the following definitions of main are acceptable by a
portable Standard C implementation?

A. int main(void) { /*...*/ }
B. void main(void) { /*...*/ }
C. int main(int argc, char *argv[]) { /*...*/ }
D. void main(int argc, char *argv[]) { /*...*/ }
E. int main(int argc, char **argv) { /*...*/ }
F. int main(int count, char **args) { /*...*/ }
G. None of the above.
H. All of the above.

What other good simple, basic questions are there (e.g., don''t cast
malloc)?

我认为让那些能够实际编程的人比那些记住某种语言更精细点的人更重要。我有人

谁不知道什么是函数指针谁是更好的编码器和

知道如何查找某些东西并在他们没有时学习它我知道。所有知道的人都知道关于C的一切，但不知道如何使用它

来实际解决问题。我会更多地关注他们如何实现算法或解决问题的问题。他们将如何使用动态

分配和链接列表等。他们将如何查找stdlib

函数以查看其工作原理。在哪里可以确定有什么东西是

便携式等等。也许我只是说，因为我编码C多年没有

知道只有C是有效的而且E不是。

I think it WAY more important to get people who can acutally program rather
than those who remember some of the finer points of a language. I had people
who didn''t know what a function pointer were who were way better coders and
knew how to look up something and learn it when they didn''t know. All the
people who did know knew everything about C, but had no clue how to use it
to actually solve a problem. I would focus questions more around how they
would implement an algorithm or solve a problem. How they would use dynamic
allocation and linked lists etc. What they would do to look up a stdlib
function to see how it works. Where to look to make sure something is
portable etc. Maybe im just saying that because I coded C for years without
knowing only C was valid and E wasn''t.

jaysome说：

jaysome said:

当我们想聘请C程序员时，我们不可避免地收到

从声称自己精通C的人那里获得简历，或者在某种程度上获得
。


对于那些声称他们的人是精通C，有什么好的问题要求他们确定他们是否真的精通

C，正如他们声称的那样？ br />

我能想到一个很好的问题：




可以接受以下哪种主要定义？便携式标准C实现？


A. int main（void）{/*...*/}

B. void main（void）{/ * ... * /}

C. int main（int argc，char * argv []）{/ *。 .. * /}

D. void main（int argc，char * argv []）{/*...*/}

E. int main（int argc，char ** argv）{/*...*/}

F. int main（int count，char ** args）{/*...*/}

G.以上都不是。

H.以上所有。

When we are looking to hire C programmers, we inevitably receive
resumes from people who claim they are "proficient at C", or something
to that extent.

For those who claim they are "proficient at C", what are some good
questions to ask them to determine if they are really "proficient at
C", as they claim?

I can think of one good question:

Which of the following definitions of main are acceptable by a
portable Standard C implementation?

A. int main(void) { /*...*/ }
B. void main(void) { /*...*/ }
C. int main(int argc, char *argv[]) { /*...*/ }
D. void main(int argc, char *argv[]) { /*...*/ }
E. int main(int argc, char **argv) { /*...*/ }
F. int main(int count, char **args) { /*...*/ }
G. None of the above.
H. All of the above.

A，C，E，F，虽然为了获得最大的可接受性，您需要在这些括号之间放置一个

返回语句。 。


我会扩展列表以包含argv的const修饰符，如果有人

特别标记为/ right /或as / wrong / （而不是只选择G / H
），我会问他们为什么。他们很可能得到可接受性

方面的错误，但这是一个很好的理由。请记住，你不是完美的，但是在熟练之后。


否则，上述问题并不能真正处理熟练程度，尽管

它确实可以帮助你消除不称职的人。

A, C, E, F, although for maximum acceptabilititude you will want to put a
return statement in between those braces...

I would extend the list to include a const modifier for argv, and if anyone
specifically marked it either as /right/ or as /wrong/ (as opposed to just
choosing G or H), I''d ask them why. They might well get the acceptability
aspect wrong, but for an excellent reason. Remember, you''re not after
perfection, but after proficiency.

Otherwise, the above question doesn''t really deal with proficiency, although
it does help you to weed out the incompetent.

还有哪些其他好的简单基本问题（例如，不要投

malloc）？

What other good simple, basic questions are there (e.g., don''t cast
malloc)?

嗯，你可以说得更好。例如：

的实践投射返回void *的函数的返回值，例如malloc，是古老而广泛的b / b
。这有必要吗？如果是这样，为什么？如果没有，为什么不呢？

过去是否有必要？如果是这样，为什么？这是好习惯吗？如果是这样，为什么？

如果没有，为什么不呢？"


这是另一个，它有几个部分。


考虑一个由以下数据结构描述的帧缓冲区：


struct gfx_fb_

{

unsigned long ** buffer;

size_t rows;

size_t columns;

};


typedef struct gfx_fb_ gfx_fb;


像素（x，y）由缓冲区[y] [x]表示。


你有五个分钟。用这个界面写一个函数：


int floodfill（gfx_fb * fb，size_t x，size_t y，unsigned long color）;


to用作为

第四个参数传入的新颜色替换一个连续的颜色补丁。


（显然我们不能指望五个完美的工作分钟，但是我们会期待

基础知识。几乎可以肯定，候选人会选择执行天真的递归

，理由是其他任何东西都可能带他更多

超过五分钟！）


后续（这是重要的）：看看你刚才的代码>
写的 - 你会说它有什么问题？


熟练的C程序员会：


*指出任何明显的语法错误，基本上快速执行clc;

*显示递归是如何被破坏的（如果确实是这样）;

*解释如何，给定更多时间，他会使功能更强大（对于

例如，代码是否脱落图像的边缘？不用担心，如果它b $ b确实如此，但他是否*发现它确实存在？）;

*说明了如何提高效率。


你在这里寻找的是批评一个人自己的代码的能力，这对于b $ b来说太罕见但绝对必要。您还在寻找

快速生成代码的能力。洪水填充示例是一个很好的例子，因为候选人不需要太多的图书馆电话。 （事实上​​，他不需要查看任何东西。）


然后你可能想问他一个类似的问题/最大化/需要

查看内容。写一些有意义但有些可怕的功能使用函数

，如strpbrk，strtok（！），fmod和modf（绝对是这两个），和

也许div，并问他修改代码以添加这样一个功能。

在桌面上放一个K& R，但不要向他提起。看看他是否b $ b询问他是否可以使用它。 （合适的候选人会这样做，除非他有一个非常好的记忆。）他多久需要查阅一本书？他找到东西的速度有多快？他如何理解他的内容？


-

Richard Heathfield< http://www.cpax.org.uk>

电子邮件：-http：// www。 + rjh @

谷歌用户：< http://www.cpax.org.uk/prg/writings/googly.php>

Usenet是一个奇怪的放置" - dmr 1999年7月29日

Well, you could word it better than that. For example: "the practice of
casting the return value of functions returning void *, such as malloc, is
ancient and widespread. Is this necessary? If so, why? If not, why not? Was
it ever necessary in the past? If so, why? Is it good practice? If so, why?
If not, why not?"

Here''s another, which is in several parts.

Consider a frame buffer that is described by the following data structure:

struct gfx_fb_
{
unsigned long **buffer;
size_t rows;
size_t columns;
};

typedef struct gfx_fb_ gfx_fb;

Pixel (x, y) is represented by buffer[y][x].

You have five minutes. Write a function with this interface:

int floodfill(gfx_fb *fb, size_t x, size_t y, unsigned long colour);

to replace a contiguous patch of colour with the new colour passed in as the
fourth parameter.

(Obviously we can''t expect a perfect job in five minutes, but we''d expect the
basics. Almost certainly the candidate will go for the naive recursive
implementation, on the grounds that anything else is likely to take him more
than five minutes!)

Follow-up (and this is the important one): look at the code you''ve just
written - what would you say is wrong with it?

A proficient C programmer will:

* point out any obvious syntax bugs, basically doing a quick clc on it;
* show how the recursion is broken (if indeed it is);
* explain how, given more time, he would make the function more robust (for
example, does the code "fall off" the edge of the image? Not to worry if it
does, but does he *spot* that it does?);
* illustrate how the efficiency might be improved.

What you''re looking for here is the ability to criticise one''s own code, which
is all too rare but absolutely essential. You are also looking for the
ability to produce code quickly. The floodfill example is a good one because
the candidate won''t need much in the way of library calls. (In fact, he
shouldn''t need to look up anything at all.)

Then you might want to ask him a similar question that /maximises/ the need to
look stuff up. Write something meaningful but scary-looking using functions
such as strpbrk, strtok(!), fmod and modf (definitely both of these), and
perhaps div, and ask him to modify the code to add such-and-such a feature.
Have a K&R right there on the desk, but don''t mention it to him. See if he
asks whether he can use it. (The right candidate will do so, unless he has a
phenomenal memory.) How often does he need to consult the book? How quickly
does he find stuff? How well does he interpret what he reads?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

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