[OT] 为什么国外统计C最流行，而国内对java需求却远大于C呢？
none_nobody
Shell Xu
元芳不懂英文。
from miui
元芳，你怎么看？
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
--
-- You received this message because you are subscribed to the Google Groups Shanghai Linux User Group group. To post to this group, send email to sh...@googlegroups.com. To unsubscribe from this group, send email to shlug+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/shlug?hl=zh-CN
SuperCat
Chaos Eternal
Xiangfu Liu
> 纯C控路过~~~
纯C控写着C路过。。。
Li Zhu
--
Li Zhu (朱黎), grad. student
Jilin University, China
SuperCat
Xiangfu Liu
> 俺是上班写C++，下班后写C~~~
俺是上班写C，下班还写C ：）
Franks Wu
java coder for android
孑影
benluo
AleiPhoenix (A.K.A Areverie)
twitter: @areverie
wikipedia: AleiPhoenix
blog: weblog.areverie.org
wiki: wiki.areverie.org
Chaos Eternal
call/cc tco神马的特别酷。
liyaoshi
z7z8th
2012/10/22, liyaoshi <liya...@gmail.com>:
林孟潇
Xidorn Quan
写成 Linux 核心的代码规范，什么中高级语言都能看懂……
Shell Xu
blog: http://shell909090.com/blog/
twitter: http://twitter.com/shell909090
z7z8th
文档太少也是很要命的，很多时候概念都搞不清楚，只能一点一点慢慢啃代码
2012/10/28, Xidorn Quan <quanx...@gmail.com>:
Fan Yang
Xidorn Quan
C++ 啃代码都啃不懂。你要说自己的规范绝对是 Java 做得比 C++ 好得多。
Xidorn Quan
C++ 是世界上最难的编程语言没有之一……
--
z7z8th
none_nobody
On Sunday, October 28, 2012 12:07:29 PM UTC+8, z7z8th wrote:
C++是难学易用的语言。java是拿来烧硬件的。
Yongwei Wu
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
不过，这主要是历史原因造成的：“Our advice against using exceptions is not predicated
on philosophical or moral grounds, but practical ones.... Things would
probably be different if we had to do it all over again from scratch.”
而且，Herb和Andrei有本书就叫C++ Coding Standards。
> -- You received this message because you are subscribed to the Google Groups
> Shanghai Linux User Group group. To post to this group, send email to
> sh...@googlegroups.com. To unsubscribe from this group, send email to
> shlug+un...@googlegroups.com. For more options, visit this group at
> https://groups.google.com/d/forum/shlug?hl=zh-CN
>
>
--
URL: http://wyw.dcweb.cn/
x11
在 2012年10月27日星期六UTC+8下午9时12分57秒，z7z8th写道：
SuperCat
可读性。。。和c还是c++有关系？硬要说的话，c++代码可读性恐怕还不如c代码
在 2012年10月27日星期六UTC+8下午9时12分57秒，z7z8th写道：C的代码实在是让人阅读艰难，dbus的代码看着真痛苦，不过它注释较多，还好一点，像bluez那种基本没有注释的就。。。兼顾性能、可读性和开发效率，还是C++比较好。
--
Chaos Eternal
Ma Xiaojun
> C++木锟斤拷C锟矫讹拷 +1
C++锟斤拷锟絰锟皆诧拷锟斤拷锟斤拷锟叫科學锟斤拷锟斤拷锟侥ｏ拷
AA BB(CC); 啥锟斤拷思锟斤拷锟斤拷
锟矫匡拷锟斤拷锟斤拷锟侥ｏ拷
Zhang Cheng
Google的C++规范还可以啊。我以前部门的编码规范就是我参考Google的写的。唯一我猛烈反对Google的地方是它禁止使用异常。
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
不过，这主要是历史原因造成的：“Our advice against using exceptions is not predicated
on philosophical or moral grounds, but practical ones.... Things would
probably be different if we had to do it all over again from scratch.”
而且，Herb和Andrei有本书就叫C++ Coding Standards。
SuperCat
Xidorn Quan
Ma Xiaojun
> Ҫ֪���ϲ���׳���Щexception�ɲ������ɵ������ء�������һ��С�ľ�abort()��~~~
˭�����ң���ô֪��Python�ĺ�����׳���Щ�쳣��
Chaos Eternal
Help 之。
On 10/29/12 1:43 AM, SuperCat wrote:
> 要知道上层会抛出哪些exception可不是轻松的事情呢…………一不小心就给abort()了~~~
谁告诉我，怎么知道Python的函数会抛出哪些异常？
Ma Xiaojun
> Help ֮��
û�ܺ��ĵ����أ���ʵ�Ҽǵ���ǰ�������й�ٷ����ĵ�����һ��ȫ�������㡣
Chaos Eternal
那就换一个不用exception 的语言吧。
比如用scheme...
On 10/29/12 6:46 PM, Chaos Eternal wrote:
> Help 之。
没很好文档的呢？其实我记得以前有人吐嘈过，官方的文档都不一定全部告诉你。
Alex Zhang
你见过国内做核心技术的么？
--
Difan Zhang (@tifan)
System Administrator | Google Inc.
http://difan.org.cn/ | http://blog.osqdu.org/
2012/10/29 Chaos Eternal <chaose...@shlug.org>:
Shell Xu
On 10/29/12 6:46 PM, Chaos Eternal wrote:
> Help 之。
没很好文档的呢？其实我记得以前有人吐嘈过，官方的文档都不一定全部告诉你。
--
-- You received this message because you are subscribed to the Google Groups Shanghai Linux User Group group. To post to this group, send email to sh...@googlegroups.com. To unsubscribe from this group, send email to shlug+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/shlug?hl=zh-CN
Yongwei Wu
那是没用好吧。可能是在用C的思维写C++代码。看国内还到处用MSVC6就知道有些人在这方面是多落后了。
没有异常，C++根本无法做到返回对象，表达力大大下降。
On 29 October 2012 11:32, Ma Xiaojun <damag...@gmail.com> wrote:
> On 10/28/12 9:38 PM, SuperCat wrote:
>> C++木有C好读 +1
>
> C++可讀性不好是有科學依據的：
> AA BB(CC); 啥意思啊？
> 得看上下文！
C很直白，写得是什么，意思就是什么。说得好是容易理解，说得难听就是抽象性差。要抽象得自己来，弄得不好，一个更改要改动一大堆代码。
C++抽象性很强。所谓抽象，另一种说法就是隐藏，把不需要的信息收起来，写得好的代码，能以比C好很多倍的方式清晰地告诉读者这儿是在“做什么”。缺点是费脑子，特别是当你修改代码时。
另外，C++是一种很强的语言。强意味着你可以写出表意的代码，也意味你可以写出佶屈聱牙的代码。多说无益，给出一个我常给的例子，给定一个UTF-8的字符串，在Linux上不作任何处理，在Windows上动态转成UTF-16的字符串，以正确访问含有非ASCII字符的文件名。
我先写出使用的代码，类和宏的定义稍长些，放在最后。
std::ifstream ifs;
ifs.open(Utf8FileStreamPath(utf8_file));
大家想想，用C怎么写吧。最大的可能性是，使用了C，你就根本不会使用这样的设计，所以你的代码可能不太跨平台，或者处理中文字符有问题……
有兴趣深入了解的话，可以看看我在09年的一篇演讲稿：
http://vdisk.weibo.com/s/gTNoB
最后放代码：
class Utf8ToWideString {
public:
explicit Utf8ToWideString(const char* utf8_string);
~Utf8ToWideString();
operator const wchar_t*() const;
private:
wchar_t* wide_string_;
DISALLOW_COPY_AND_ASSIGN(Utf8ToWideString);
};
#ifdef _WIN32
#if defined(_MSC_VER) && _MSC_VER >= 1400
/**
* Type for the name passed to fstreams. This implementation converts
* the UTF-8 string to a wide string.
*/
typedef Utf8ToWideString Utf8FileStreamPath;
#else
/**
* Type for the name passed to fstreams. This implementation converts
* the UTF-8 string to an `ANSI' string.
*/
typedef Utf8ToAnsiString Utf8FileStreamPath;
#endif
#else /* _WIN32 */
/**
* Function for the name passed to fstreams. This implementation returns
* the file name intact.
*/
inline const char* Utf8FileStreamPath(const char* filepath)
{
return filepath;
}
#endif /* _WIN32 */
Xidorn Quan
我总是说 C++ 是一个高不成低不就的语言。论抽象性，随便找个脚本语言都可以比 C++ 隐藏多得多的东西，抽象化和对象间的解耦都比 C++ 做的彻底得多。C++ 上比抽象和表达简洁比不过脚本语言，下比清晰明白直接比不过 C。我实在不知道 C++ 除了方便编译闭源之外，它比脚本语言配合运算密集部分 C 改写有任何其他优势么？
Zind
> 要知道上层会抛出哪些exception可不是轻松的事情呢…………一不小心就给abort()了~~~
catch(...) 能捕获所有类型的异常，与所有类型的异常都匹配。
但是，不知道具体是哪种异常类型。。。当然，也就不能更有针对性地处理之。。。
z7z8th
你说的“方便编译闭源”，是指c++ name mangling吗？mangling是有标准的，demangling很容易。
>它比脚本语言配合运算密集部分 C 改写有任何其他优势么？
对于百万千万行级别的程序，密集部分怎框定？
Zind
> 你说的“方便编译闭源”，是指c++ name mangling吗？mangling是有标准的，demangling很容易。
不是吧。。。
他的意思可能是说 C++ 是编译型语言，编译生成可执行文件，不容易被反编译；
而解释型语言或者混合型语言（eg. Java），有生成中间码（eg. Java bytecode），反编译相对容易些
Shell Xu
系统异常除外。。。
from miui
SuperCat
ifs.open(Utf8FileStreamPath(utf8_file));
filename = g_filename_from_utf8(utf8string, -1, NULL, NULL, NULL);
GFile *file = g_file_new_for_path(filename);
g_free(filename);
GFileInputStream *stream = g_file_read(file, NULL, NULL);
g_object_unref(file);
搞定~
Yongwei Wu
catch(...)几乎没有用处。正常情况下，你应该知道发生了什么异常。在里面，唯一合理的处理大概也就是记个日志，然后终止程序或者继续往外抛。
Windows下有一个特别用处，就是你可能可以用这个来捕获系统的异常，如Access
Violation。可能会有用，但也很危险，我碰到过catch(...)掩盖了程序中的错误，本来程序早崩掉的话就可以更早调试出来了。
Yongwei Wu
Yongwei Wu
Bjarne自己在“Evolving a language in and for the real world: C++
1991-2006”<url:http://www.stroustrup.com/hopl-almost-final.pdf>里是这么写的：
Application languages gain their advantages through specialization,
through added conveniences, and through eliminating difficult to use
or potentially dangerous features. Often, there is a run-time or space
cost. Often, simplifications are based on strong assumptions about the
execution environment. If you happen to need something fundamental
that was deemed unnecessary in the design (such as direct access to
memory or fully general abstraction mechanisms) or don’t need the
“added conveniences” (and can’t afford the overhead they impose), C++
becomes a candidate. The basic conjecture on which C++ is built is
that many applications have components for which that is the case:
“Most of us do unusual things some of the time”.
...
If it was easy and cheap to switch back and forth among applications
languages and general-purpose languages, we’d have more of a choice.
However, that is rarely the case, especially where performance or
machine-level access is needed. In particular, using C++ you can (but
don’t have to) break some fundamental assumption on which an
application language is built. The practical result is that if you
need a systems programming or performance-critical facility of C++
somewhere in an application, it becomes convenient to use C++ for a
large part of the application — and then C++’s higher-level
(abstraction) facilities come to the rescue. C++ provides hardly any
high-level features that are directly applicable in an application.
What it offers are mechanisms for defining such facilities as
libraries.
“如果在应用语言和通用语言之间切换非常容易、不需要代价的话，我们的选择就多了。可惜，很少会是这样，特别是需要机器层面的访问性能时……”
2012/10/30 Xidorn Quan <quanx...@gmail.com>:
SuperCat
SuperCat
Yongwei Wu
所以，理论上没什么不可以。实践上，对于Linux来说还有理念上（Linux几乎是痛恨C++），内核开发C++不太适用。
Chaos Eternal
插个嘴，hurd 就是c++的。还有，gcc 的代码已经全部切换到c++了。
Yongwei Wu
下面代码主要也不是命名空间的问题，而是资源的手工管理（free/unref），和不得不深入到一些莫名其妙的细节（-1和NULL跟我要的东西有啥关系？）里去。
SuperCat
Yongwei Wu
我个人并不建议用C++写操作系统核心层代码。用户态应该没什么问题。
2012/10/30 SuperCat <superca...@gmail.com>:
Ma Xiaojun
> C��ֱ�ף�д����ʲô����˼����ʲô��˵�ú���������⣬˵��������dz����ԲҪ������Լ�����Ū�ò��ã�һ�����Ҫ�Ķ�һ��Ѵ��롣
�䌍�ɣ��]���fC�ij����Ժܺá�
> C++�����Ժ�ǿ����ν������һ��˵���������أ��Ѳ���Ҫ����Ϣ��������д�úõĴ��룬���Ա�C�úܶ�ķ�ʽ����ظ��߶���������ڡ���ʲô����ȱ���Ƿ����ӣ��ر��ǵ����Ĵ���ʱ��
>
> ���⣬C++��һ�ֺ�ǿ�����ԡ�ǿ��ζ�������д������Ĵ��룬Ҳ��ζ�����д��٥�������Ĵ��롣��˵���棬���һ���ҳ�������ӣ���һ��UTF-8���ַ���Linux�ϲ����κδ��?��Windows�϶�̬ת��UTF-16���ַ�����ȷ���ʺ��з�ASCII�ַ���ļ���
�䌍���Լ�����C++��ȱ�c�f�ò���ˣ����Լ��܌��e���ŵĴ�a�����ˣ���
�ú�����ǧ��ٹֵ�lib����ˣ�
> ����д��ʹ�õĴ��룬��ͺ�Ķ����Գ�Щ���������
>
> std::ifstream ifs;
> ifs.open(Utf8FileStreamPath(utf8_file));
��������̫���ˣ���һ�ۿ��^���벻��Utf8FileStreamPath߀���ǂ�class��
> ������룬��C��ôд�ɡ����Ŀ������ǣ�ʹ����C�������ʹ���������ƣ�������Ĵ�����ܲ�̫��ƽ̨�����ߴ��������ַ������⡭��
C�Z����malloca��alloca�����Ԍ�������Ҳ�]ɶ�y�ġ���heap��new��free�䌍Ҳ
���Dz��ܽ��ܵ����顣
http://msdn.microsoft.com/en-us/library/5471dc8s.aspx
http://www.kernel.org/doc/man-pages/online/pages/man3/alloca.3.html
> ���Ŵ��룺
Ma Xiaojun
> C�Z����malloca��alloca�����Ԍ�������Ҳ�]ɶ�y�ġ���heap��new��free�䌍Ҳ
> ���Dz��ܽ��ܵ����顣
> http://msdn.microsoft.com/en-us/library/5471dc8s.aspx
> http://www.kernel.org/doc/man-pages/online/pages/man3/alloca.3.html
���^�f�����䌍��һ�����}�����քӹ���new��free�����أ�߀��˼�����������
�L�ڌ�һЩ�dz���Ĵ�a�����أ�
Chaos Eternal
2012/10/30 SuperCat <superca...@gmail.com>:
Alex Zhang
另外，我们在 Google 确实很依赖 C++。
[G:difan@hydrogen ~/Develop/c] % gcc -nostdlib -g test.c
[G:difan@hydrogen ~/Develop/c] % ldd a.out
not a dynamic executable
[G:difan@hydrogen ~/Develop/c] % file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=0x8f20757a85c112f030f2d80665ce5902004b11e1, not stripped
[G:difan@hydrogen ~/Develop/c] % gdb ./a.out
GNU gdb (GDB) 7.5-gg4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux".
<http://wiki/Main/GnuDebugger FAQ: http://go/gdb Email: gdb-team IRC: gdb>
Reading symbols from /usr/local/google/home/difan/Develop/c/a.out...done.
(gdb) l
1 int _start() {
2 int a, b, c;
3 a = 2;
4 b = 32;
5
6 c = a + b;
7 asm("movl $1, %eax;"
8 "xorl %ebx, %ebx;"
9 "int $0x80"
10 );
(gdb) b 7
Breakpoint 1 at 0x400161: file test.c, line 7.
(gdb) r
Starting program: /usr/local/google/home/difan/Develop/c/a.out
Breakpoint 1, _start () at test.c:7
7 asm("movl $1, %eax;"
(gdb) i locals
a = 2
b = 32
c = 34
(gdb) q
A debugging session is active.
Inferior 1 [process 4860] will be killed.
Quit anyway? (y or n) y
--
Difan Zhang (@tifan)
System Administrator | Google Inc.
http://difan.org.cn/ | http://blog.osqdu.org/
SuperCat
superlynx@superlynx-server-develop:~/src$ g++ -nostdlib -o test2 test2.cpp
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000400144
/tmp/cchYrmsW.o: In function `main':
test2.cpp:(.text+0xe): undefined reference to `operator new[](unsigned long)'
test2.cpp:(.text+0x2c): undefined reference to `operator delete[](void*)'
/tmp/cchYrmsW.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
Xidorn Quan
对于这个来说……你可以自己重载 new 和 delete 运算符，这完全不是问题，只要你愿意。就像 C 的 malloc 和 free 一样也是依赖 libc 的，但你可以自己写。
Yongwei Wu
>> 我先写出使用的代码，类和宏的定义稍长些，放在最后。
>>
>> std::ifstream ifs;
>> ifs.open(Utf8FileStreamPath(utf8_file));
>
你使用时不需要知道这是class还是function。
>> 大家想想，用C怎么写吧。最大的可能性是，使用了C，你就根本不会使用这样的设计，所以你的代码可能不太跨平台，或者处理中文字符有问题……
>
> C語言有malloca、alloca，所以寫個函數也沒啥難的。用heap來new、free其實也
> 不是不能接受的事情。
> http://msdn.microsoft.com/en-us/library/5471dc8s.aspx
> http://www.kernel.org/doc/man-pages/online/pages/man3/alloca.3.html
罗嗦，看代码时没法一眼看到核心逻辑。
>> 最后放代码：
> 你這代碼的可讀性怎麼樣我都不想說了……
虽说C++的工具类代码一般是比较搞一点（口号是方便用户，而不是方便自己:-)），我还没写出实现代码呢，你就看不下去了？你倒具体说说哪儿有可读性问题。
即使有，又怎么样？Boost的代码很多确实看起来很累，但用户一般不需要去看。C++允许这样的叠加和抽象，而不需要复杂的跨语言调用机制。
Ma Xiaojun
> ��ʹ��ʱ����Ҫ֪������class����function��
��������ҵ�����function���ҿ��ܻ��������Dz����ڴ�й¶����
> ���£�������ʱû��һ�ۿ�����������
C����ȷʵ��ˡ�
> ��˵C++�Ĺ��������һ���DZȽϸ�һ�㣨�ں��Ƿ����û������Ƿ����Լ�:-)�����һ�ûд��ʵ�ִ����أ���Ϳ�����ȥ�ˣ��㵹����˵˵�Ķ��пɶ������⡣
���ע�Ͷ����?����һ����δ�������㵽��������Ϊʲôһ��Ҫ��classһ
��ֻ��function��ʵ�������˶��Զ�������������Щ����һ�����ô���Ҳ�֪����
> ��ʹ�У�����ô��Boost�Ĵ���ܶ�ȷʵ���������ۣ����û�һ�㲻��Ҫȥ����C++��������ĵ��Ӻͳ�����Ҫ���ӵĿ����Ե��û��ơ�
Boost����ijһ�ſε���ҵ�д����ã����ֺܶණ�������棬������IJ��Ǻ�����
Ȥȥ�о������ԭ�?
C++�����úܲ����ŵķ�ʽʵ�ֺ����ŵij�������ã����������ά���أ���
������Boost����һЩţ�˰�ʵ��ά�������ˣ�������ֻ���þͿ����ˡ�
Yongwei Wu
>> 虽说C++的工具类代码一般是比较搞一点（口号是方便用户，而不是方便自己:-)），我还没写出实现代码呢，你就看不下去了？你倒具体说说哪儿有可读性问题。
>
> 个只是function？实践中人人都对对象生命周期那些东西一清二楚么？我不知道。
这个恐怕只能靠加文档和注释了。我漏拷了几行注释，但目前我确实也还没在里面具体描述生命周期的问题。我另外有简单的文档描述怎么使用这些东西。当然，更多靠项目里大家的使用经验。
>> 即使有，又怎么样？Boost的代码很多确实看起来很累，但用户一般不需要去看。C++允许这样的叠加和抽象，而不需要复杂的跨语言调用机制。
>
> Boost我在某一门课的作业中大量用，发现很多东西很神奇，但是真的不是很有兴
> 趣去研究背后的原理。
> C++可以用很不优雅的方式实现很优雅的抽象，抽象好用，问题是如何维护呢？除
> 了向用Boost那样，一些牛人把实现维护都包了，其他人只管用就可以了。
C++实际上允许你在一种语言里做不同抽象层次的事情。从写代码的角度来讲，确实可能有几种不同层次的代码。技巧够的做一些库层次的东西，技巧弱的就把C++作高级语言用就行了。至少你不需要去搞跨语言调用的麻烦事。
你如果问题域清晰、平台稳定、有一个厉害的架构师的话，另一种做法就是用C（也可以考虑C++）写出底层的库，然后用一种高级语言让其他程序员做上层开发。云风就这么干过。但这种方法灵活性差些，很多情况下不见得适用。
SuperCat
none_nobody
C++的异常处理机制却无法满足这个要求。C++的异常机制对于确保程序不会失败是非常有效的——只要将主函数包装在try/catch块中，然后你就可以在一个单独的位置处理所有的错误。然而，当你的目标是确保没有未定义行为发生时，噩梦就产生了。C++中引发异常和处理异常是松耦合的，这使得在 C++中避免错误是十分容易的，但却使得保证程序永远不会出现未定义行为变得基本不可能。
在C语言中，引发错误和处理错误的部分是紧耦合的，它们在源代码中处于同一个位置。这使得我们在错误发生时能很容易理解到底发生了什么：C代码的可读性明显高的多；
但是，各位，我想C 和 C++ 还是较贴近的，我是说JAVA JA...JA...JA..JA...VA...VA...VA
Alex Zhang
Yongwei Wu
错误处理对于长期运行的应用程序来说至关重要，错误处理必须是非常明确的而且对错误应该是零容忍的。
C++的异常处理机制却无法满足这个要求。C++的异常机制对于确保程序不会失败是非常有效的——只要将主函数包装在try/catch块中，然后你就可以在一个单独的位置处理所有的错误。然而，当你的目标是确保没有未定义行为发生时，噩梦就产生了。C++中引发异常和处理异常是松耦合的，这使得在 C++中避免错误是十分容易的，但却使得保证程序永远不会出现未定义行为变得基本不可能。
在C语言中，引发错误和处理错误的部分是紧耦合的，它们在源代码中处于同一个位置。这使得我们在错误发生时能很容易理解到底发生了什么：C代码的可读性明显高的多；
我想你说明了C的可调试性比C++好。可读性还是有区别的。在需要理解程序做什么的时候，我并不想看到一大堆错误处理的东西。
我们做BIOS的同事还抱怨C的代码调试起来没汇编好调呢，特别是UEFI里面用了面向对象的封装之后。
Chaos Eternal
OT 一下，
http://www.soimort.org//posts/124/index.html
元芳，你怎么看？
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Ma Xiaojun
> 我想你说明了C的可调试性比C++好。可读性还是有区别的。在需要理解程序做什么的时候，我并不想看到一大堆错误处理的东西。
這個同意。
> 我们做BIOS的同事还抱怨C的代码调试起来没汇编好调呢，特别是UEFI里面用了面向对象的封装之后。
Assembly語義無比清晰……就是只見樹木不見森林……
Julian Wong
--
-- You received this message because you are subscribed to the Google Groups Shanghai Linux User Group group. To post to this group, send email to sh...@googlegroups.com. To unsubscribe from this group, send email to shlug+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/shlug?hl=zh-CN
Xiang Wang
Fengyuan
Sent from my iPhone
Yongwei Wu
Kang-Hao (Kenny) Lu
> 国内都在做外包，因为外包开发人员普遍素质很低，使用Java最合适，因为Java培训起来方便，开发者也便宜。
> 你见过国内做核心技术的么？
有啊，MarkMail 搜 from:intel.com[1]不是机器人的第一名吴峰光如果我没弄错
就是。估计是跟在这个邮件群发过招聘信[2]的 Huang Ying（第八名）是同一个团
对的，在上海。
[1] http://markmail.org/search/?q=from%3Aintel.com
[2] https://groups.google.com/forum/#!topic/shlug/8QNeoDiltuU/discussion
以上
Kenny
--
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/
yiyang tian
国内都在做外包，因为外包开发人员普遍素质很低，使用Java最合适，因为Java培训起来方便，开发者也便宜。
你见过国内做核心技术的么？
--
Difan Zhang (@tifan)
System Administrator | Google Inc.
http://difan.org.cn/ | http://blog.osqdu.org/
2012/10/29 Chaos Eternal <chaose...@shlug.org>:
> 那就换一个不用exception 的语言吧。
> 比如用scheme...
>
> On Oct 30, 2012 8:01 AM, "Ma Xiaojun" <damag...@gmail.com> wrote:
>>
>> On 10/29/12 6:46 PM, Chaos Eternal wrote:
>> > Help 之。
>>
>> 没很好文档的呢？其实我记得以前有人吐嘈过，官方的文档都不一定全部告诉你。