z****e
发帖数: 54598 | 1 atoi主要是java里面有实现了，所以一般java面试也不考这个
就像wwzz说的Integer.parseInt
人家要真写出这个来，总不能说是错的吧？ |
|
z****e
发帖数: 54598 | 2 cocoa2d我看了看，觉得不比我手写爽多少，就先不用了
手写也没有难到哪里去，我也认为应该考点实际的
atoi其实已经够实际了，不过做手游，我感觉还是直接给他24小时
然后要求他实现一个游戏的prototype就好了，如果要找ios的就让他在ios上实现
如果要找android的就让他在android上实现，这样考比考比算法实在
而且国内有试用期，招进来不行就让走人就是了，三个月也足够看出行还是不行了
当然美帝更狠，at will随时滚蛋 |
|
q*c
发帖数: 9453 | 3 学习不是啥孤立的问题， 学各种 framework 快速，反而学简单到死的 atoi 就学不会？
这两个是正相关，不知道为啥大家要割裂对立起来。
吧。 |
|
h*****a
发帖数: 1718 | 4 是啊，真搞不懂反对的人都想什么。atoi这种基本的东西不是考算法，就是考一个IT从
业人员的智商。如果连这样的test都过不了，就像一个不会算加法的人要去攻克黎曼猜
想，创新和framework这些东西根本就无从谈起。 |
|
d****i
发帖数: 4809 | 5 你这个完全错误，好的Java程序员象goodbug这样的，对C，C++这样的底层语言都是很
了解的，虽然可能现在工作中不怎么用可能会生疏一点，但是明白了基础的一些概念对
理解上层的语言的概念帮助是非常大的，Java, Python等应用层语言都是建立在C的基
础上的。你不明白C里面的char实际上对应的是ASCII的8位整数，你对atoi就无从下手。
C学不好的更需要java.你的例子沒说服 |
|
c*******9
发帖数: 9032 | 6 答不上atoi的应该不是不明白char对应的是ascii的8位整数，而是忘记具体的对应，这
个其实有一定随意性，不反应程序语言的实质。goodbug 的c c++水平我不清楚，认识
的人里鼓吹java的基本对c的细节避之不及。
手。 |
|
L*****e
发帖数: 8347 | 7 解atoi为啥要知道具体的ascii对应？
★ 发自iPhone App: ChineseWeb 8.2.2 |
|
d***a
发帖数: 13752 | 8 不懂你的问题。解atoi，Java和C不是差不多吗？这也用不到class。
当然Java不能用指针就是了。 |
|
z****e
发帖数: 54598 | 9 atoi和reverse linked list在java面试比较少考
这两个都有现成的api
Integer.parseInt和LinkedList类
后者是双链表，要reverse太容易了
所以为了防止有人写出这种答案，一般都不考了
没有太大意义 |
|
|
q*c
发帖数: 9453 | 11 是啊，所以这些同学说 java 马工就该不懂 atoi 我不理解。 |
|
c******3
发帖数: 296 | 12 LZ如果非要通过atoi来看看来面试的人是不是懂“ - '0'”的技巧，LZ还是先关了公司
，学学唐增，去向烙印取经吧。 |
|
c******3
发帖数: 296 | 13 这个梦话是给LZ的。LZ这样的无名小公司很难找到算法大牛。面试就别学Google了。即
便历经千辛万苦找到了，市场时机也错过了。
LZ的公司不是做基础软件的，其实也不需要算法大牛，懂基本编程就行了。最重要的能
力是会用现成的工具，快速而又简单明了地解决问题。用Java的话，Integer.parseInt
足够了。
其实就是找个头脑灵活的堆工。atoi的事情，或Integer.parseInt内部是怎样的，就让
SUN的工程师去烦恼吧。
记住堆工会给你的公司堆出金山，算法大牛只会把SUN算得倒闭了。 |
|
p*u
发帖数: 2454 | 14
parseInt
able 2 figure out atoi() in a few mins == 算法大牛??? |
|
q*c
发帖数: 9453 | 15 atoi 都是大牛算法了。
我看来不是地球人哈， 天顶星人神族， 妥妥的。 大家膜拜吧。
parseInt |
|
b*******s
发帖数: 5216 | 16 连atoi都不会写的，招进来也是trouble maker
parseInt |
|
c*******9
发帖数: 9032 | 17 作为小公司的老板应该就不能怕trouble maker了，trouble maker不一定能力不强，只
不过缺点严谨，也比较容易
不服管，对付不了这样的人就别创业了。创业经常需要这样的草莽，什么条件都好的不
可能去这样的小公司，atoi这些很熟练的不是去大公司就是实际能力太差。 |
|
|
t****t
发帖数: 6806 | 19 我上次需要写一段code读一堆大文件, 文件里全是floating point number. 我一开始就
拿标准的strtod/atof写, 发现很慢. 后来到网上搜了一段code 代替strtod, 发现效率
提高400%以上... |
|
a*****e
发帖数: 1700 | 20 这位同学基本功还需要加强啊... 先写个 integer 的 regular expression 来看看，
就知道错在哪里了。 |
|
d****i
发帖数: 4809 | 21 你这个把很多边角情况考虑了，zlike要的版本可能不需要那么复杂，另外你的code有
错，cast的时候应当是res = res*10 + (int)(str[i]-'0'); 其实也不需要cast，char
自动promote成int. |
|
|
N******K
发帖数: 10202 | 23 我基本不用*pointer
*这个看起来就是乘法符号 |
|
|
d****i
发帖数: 4809 | 25 以前一些老的C compiler，用指针access element确实比用index快，所以经常有*p++
= *q--这样的convention，后来的编译器把a[i]优化得和*(a+i)生成的机器码完全一摸
一样了。 |
|
t****t
发帖数: 6806 | 26 a[i]从最开始就是完全等同于*(a+i)的, 你这说的完全不靠谱.
+ |
|
x****u
发帖数: 44466 | 27 STL iterator的i++和++i完全等价，也有很多人不知道。 |
|
N******K
发帖数: 10202 | 28 这种
for(int* p=&str[0]; p<=&str[Max]; ++p)
{
p[0]=1;
}
是不是比
for(int i=0; i<=Max; ++i)
{
str[i]=1;
}
快? |
|
t****t
发帖数: 6806 | 29 我说的是语法层面, 你说的是优化层面. 这两不是一回事. |
|
|
|
t****t
发帖数: 6806 | 32 这个基本上不行. 代码写得太怪异编译器不会优化反而更慢. |
|
N******K
发帖数: 10202 | 33 我最近发现 写矩阵运算 那么写会快很多 vs2013 |
|
T********i
发帖数: 2416 | 34 我基本不相信编译器的优化。尤其是有template参与的情况。
如果没有loop优化，当然*p++快很多。p[i]这种寻址要多两条指令。 |
|
|
|
|
x****u
发帖数: 44466 | 38 老问题了，矩阵为什么不用库，为什么不用GPU？ |
|
T********i
发帖数: 2416 | 39 Thrust，
能不能share一下你在网上搜到的code? 我看看是不是比我现在用的快？
始就 |
|
x****u
发帖数: 44466 | 40 细谈为什么i++和++i等价，可以作为一道面试题了。大部分看了入门C++书的人都会告
诉你要用后者。 |
|
|
d****i
发帖数: 4809 | 42 我的记忆中好像当i是iterator的时候，i++要多加一次调用++i，所以后者稍微更
efficient一点，不是到是不是这样，现在的C++编译器应该优化过了没区别了。 |
|
|
T********i
发帖数: 2416 | 44 我现在最爱用C macro。简直是神器。
我曾经有上千行代码用macro取代template以后，速度快了2倍。 |
|
N******K
发帖数: 10202 | 45 设计新算法 哪里找库？
我说的矩阵运算可不是矩阵之间的+-*/
你们这些全堆程序猿 是不能理解的
不是所有计算都适合GPU |
|
d****i
发帖数: 4809 | 46 haha, using a lot of C macro is considered to be bad practice in C++ |
|
x****u
发帖数: 44466 | 47 Iterator是有意设定成完全等价于简单类型的，所以临时变量从一开始就不会有。 |
|
T********i
发帖数: 2416 | 48 说那话的都是无知的表现。你千万不要相信那些砖家。 |
|
x****u
发帖数: 44466 | 49 不管是什么运算GPU或者DSP都更有效率，原因在基础课里面讲了。
如果你是试验性质的，也犯不着优化这点东西。 |
|
|
