多线程脑袋

我前段时间试过了

是可以使用的.不错o

对于补码、原码的互换，我更支持于符位号一起取反加1，而不是两者分开处理。例如，楼主的：已知一个补码为11111001，则原码是10000111（-7）：因为符号位为“1”，表示是一个负数，所以该位不变，仍为“1”；其余7位1111001取反后为0000110；再加1，所以是10000111。也可以将补码11111001先取反加1，即00000111，然后再确定符号为负，所以是-7。这种方法的好处是避免了当补码为1000 000和1111 1111换成真值时出错，按照楼主的方法做补码1000 0000换成原码，是1不变，其他7位取反加1，则000 0000取反为111 1111再加1，因而发生溢出，结果是错误的。而我的方法是先将补码1000 0000取反0111 1111再加1为1000 0000，再确定符号为负，则为-128。同理1111 1111也会出现这样的错误。

我怎么都看不了啊？

很不错的基础知识文章。谢了

@方法
你找一些shell编程的书看一下，如果你有C/C++基础，基本就能看懂了
再就是要熟悉LINUX中很多小的应用程序
管道和重定向是UNIX-LIKE操作系统中最重要的特性

能解释下么？

顶了 !不错不错啊 ！


：http://www.lovewubi.cn/

： http://www.shoushenmeirong.cn/

真不错，收藏了！thank you！

调用约定啊

通过什么方法能改变readonly设置的变量啊？
这个问题，需要你自己尝试，:-)

若知道答案，请通知我，谢谢！
roofwei2001@yahoo.com.cn

通过什么方法能改变readonly设置的变量啊？
还有，为什么上百度查这个问题，发现所有打开的网页都是一样的内容，倒底是谁抄谁的撒？

会的

我第一次创建博客，大家多提建议。共同交流学习方法！

谢谢！

另外,你也可以到这里
http://www.pconline.com.cn/pcedu/sj/famous/fif/index.html
看下

@MALI
你可以到http://www.verycd.com上下载一些FLASH的视频教程看下

我想学FLASH渐变工具

好动动，3q

bool Register()
{

if(!::RegisterClass(&wc))
{
::MessageBox(hwnd, TEXT("Mybe you need windows 2000"), yourProcess, MB_ICONERROR);
return 0;
}
}
这个函数掉了一句：
return TRUE;
或者是：
return 0;
或者是：
return -1;

首先，要清楚的是必须要有返回，因为不是void类型的，这个函数的
设计要求决定了采用bool比较合适

上面的
return -1; //虽然编译和运行都不会出问题，但是最好不用

因为，在99%的人的认识方面:

-1表示这个功能执行失败了

上面头文件中的
char yourProcess[] = "HelloShanzy";

可以换成：
static char或者const char或者static TCHAR或者const TCHAR

或者你觉得开数组用着不爽，你可以用下面的形式：

char *yourProcess = "HelloShanzy";
类型仍然可以使用上面的各种变换形式

另外我的文章中还有一点不准确的地方，下面是网友在CSDN blog上的回复：
　　>>>
　　@ 2005.5.8 15:58 adoal 发表评论
　　“在DBCS中，GB内码的存储格式始终是big endian，即高位在前”，这种说法并不准确。只有wide char（或者理解为16/32-bit integer）的value才存在endian的概念。而GB之类的编码是multi-otect stream，里面的两个字节并不能理解成一个16位的完整整数。这是wide char和MBCS的重要区别。具体可以阅读Ken Lunde的巨著CJKV Information Processing第3、4章。
　　>>>
　　
　　我的回复如下：
　　>>>
　　@ 2005.5.9 10:45 fmddlmyy 发表评论
　　谢谢adoal的指点。你说的是正确的。我的说法是错误的。
　　GB码确实应该理解为multi-otect stream，而不是一个二进制数。
　　例如UTF-8编码，用多个字节编码一个字符，这多个字节是指定顺序的字节流，而不存在字节序的问题。
　　UTF-16编码是多个word来编码一个字符，word的顺序是编码方式指定的。word内部才有字节序的问题。
　　这个概念，我以前比较模糊，看到你的回复后才想清楚。再次感谢你的指点。
　　>>>
　　
　　再次感谢网友adoal的指点。
控件使用什么字符编码，应该与编译时定义DBCS还是UNICODE有关吧。

好象MS和其他的一些书上把这个delegate叫做“委托”，和C++中的指针类似的东西，不过安全性比较高

但是，到底是因为有GC机制保证？？

还是，delegate本身的实现和指针不同（这个可能性大点）

或者，既与GC有关也和delegate本身的实现也有关（也有这个可能）

在天涯的IT视界，有网友指出我说GB18030属于DBCS是错误的。网友的指教是正确的。在这里也贴一下我在天涯的回复，以纠正原文的错误，同时谈谈关于GB18030的一些看法。如果还有什么说得不对的地方，欢迎大家不吝赐教。


这篇文章的本意是介绍UCS的基础知识。在写到汉字编码时，因为这部分我以前比较熟悉，就多写了两句，也没有仔细查证。关于GB18030的一些文字是不正确的。这里就GB18030再做一些说明：
　　
　　从汉字字汇上说，GB18030在GB13000.1的20902个汉字的基础上增加了CJK扩展A的6582个汉字（Unicode码0x3400-0x4db5），一共收录了27484个汉字。
　　CJK就是中日韩的意思。Unicode为了节省码位，将中日韩三国语言中的文字统一编码。GB13000.1就是ISO/IEC 10646-1的中文版，相当于Unicode 1.1。
　　GB18030的编码采用单字节、双字节和4字节方案。其中单字节、双字节和GBK是完全兼容的。4字节编码的码位就是收录了CJK扩展A的6582个汉字。
　　例如：UCS的0x3400在GB18030中的编码应该是8139EF30，UCS的0x3401在GB18030中的编码应该是8139EF31。
　　我的文章中关于GB18030有两点描述是不准确的：
　　1、我说中文Windows的内码可以通过升级到GB18030，事实上中文Windows的内码还是GBK。
　　2、我说GB18030属于DBCS，事实上GB18030是4字节字符集。
　　
　　下面再谈谈微软对GB18030问题上的处理：
　　
　　我之所以会有中文Windows的内码已经升级到GB18030的印象是因为GB18030是中国的强制标准,而微软既提供了GB18030的升级包,我就以为升级后的内码可以支持GB18030。但经过查证发现升级后，Windows内码还是不支持GB18030。
　　其实NT架构的内核已经是Unicode编码。传统意义的内码是通过code page实现的。例如GBK对应的code page就是CP936。
　　微软确实为GB18030增加了一个code page：CP54936。但是这个code page是无法真正使用的。无法使用的原因在微软网站上就有详细的解释：
　　Is GB18030 replacing the Windows Simplified Chinese code page (CP936)?
　　No, Windows code pages must be either one byte (SBCS) or a mix of one and two bytes (DBCS). This requirement is reflected throughout our code e.g. in data structures, program interfaces, network protocols and applications. The existing code page for Simplified Chinese, CP936, is a double byte code page. GB18030 is a four–byte code page i.e. every character is represented by one, two or four bytes. To replace CP936 with GB18030 would require rewriting much of the system. Even if we were to do this, such a system would not run regular applications nor interoperate with regular Windows.
　　微软目前的代码只支持DBCS和SBCS，无法支持4字节字符集。这也就是我前面谈到的对DBCS的解析，DBCS通过对高字节最高位的判断区分两字节编码，如果要支持4字节编码，例如8139EF30，就必须全面修改相关代码。微软认为这样的改动即困难又没有意义。
　　微软的GB18030升级包主要有3点内容：
　　1、提供了一套支持CJK扩展A的6582个汉字的新字体：新宋体-18030
　　2、增加了不能使用的code page：CP54936
　　3、提供了一个有几个4字节编码转换函数的DLL和一个GB18030和Unicode编码的转换程序。
　　说起这个转换程序，还有一点比较可笑。我用这个转换程序试着转换CJK扩展A的几个字符，源文件的16进制是：
　　FFFE 0034 0134 0234 0334 0434 0534
　　这是一个Little-Endian的Unicode文本文件，转换得到的结果是：
　　8139 EE39 8139 EF30 8139 EF31 8139 EF32 8139 EF33 8139 EF34
　　事实上，根据GB18030，UCS的0x3400的编码应该是8139EF30。这个转换程序的结果是正确结果-1。
　　
　　从以上分析可见，微软只是提供了GB18030要求的字汇，根本不能支持GB18030的编码。但微软网站上却是说自己的方案已经 Approved by the Chinese testing agency. 而且微软对GB18030问题的应付显然是很马虎的。连一个很简单的转换程序都有明显的错误。
　　
　　我对GB18030并没有什么好感，它对CJK扩展A的6582个汉字进行4字节编码，虽然编码设计上有很好的扩展性，但显然没有考虑到如何兼容当前的软件平台。
　　但GB18030既然是一个国家的强制标准，但在执行时又敷衍了事，而没有明确的说法。这种出尔反尔的做法，实在不是什么光彩的事情。

我靠，BIN\DEBUG\*.EXE
OBJ\DEBUG\*.EXE

我靠，简直是浪费空间，应该什么地方可以改？？？

这是鸟的什么语言啊，一点都不严格

(1) public static void Main()
(2) private static void Main()
(3) protected static void Main()

我靠，居然都能通过编译！！

难道,public 是默认的，那么其他的能通过编译是什么原因？？？？

郁闷，MSDN中竟然说Console是“类”，我狂晕啊

难道，所有的工程类型都成了“类”了？？？？？？？？？？？？

要求的东西还挺多，真不爽啊

（1）static void Main()----------3个东西都不能变化
（2）ReadLine()--------面向行的“读”
（3）ReadLine()函数都换成Read()函数，得到的效果和
C语言中的system("PAUSE");效果相同，不过不是汉字罢了