Result

MS가 IE8 출시를 2년 후 정도로 보고 있네요 - Microsoft hints at general plan for IE8

아래 Builder AU의 news에 따르면 MS가 IE7의 relase (올해 10월) 이 후 2년 후에 IE8 을 만들것이라고 합니다. (IE6에서 IE7의 기간이 얼마인진 모르겠으나) 빠른 것 같습니다.

IE7 처럼 "강력한 보안"과 "사용하기 쉽고 웹 개발이 편한" 것에 중점을 둔다고 합니다.

그리고 layout과 CSS 2.1에 좀 더 투자하고 타 브라우저와의 연동에도 더 신경을 쓰고 그외에도 여러 표준들을 잘 따르는 (착한) IE8을 만들 거라고 하는 군요.

지금까지의 MS를 보면 표준을 따르는 것 처럼 보이지만 자신들 맘대로 해버리는 성향이 있었던 것 같은데, 좀 착해지려나 봅니다.

Internet 관련 분야에서 Google이나 Mozilla 등에 당한게 많아서 많이 뉘우치고 있는 것 같습니다. 그리고 "표준" 이라는 것에 대해서도 반성하고 있는 듯 하구요.
※ Vista에서도 phython 등의 script 언어 들을 대폭 수용한 것을 봐도 그렇고..

하지만 좀 늦은 감이 있기도 합니다.

From: BuilderAU News
http://www.builderau.com.au/news/soa/-Microsoft-hints-at-general-plan-for-IE8/0,339028227,339275254,00.htm

Microsoft hints at general plan for IE8

do {} while(false) for macro

The following url say the reason.

http://c-faq.com/cpp/multistmt.html

iostream library on VxWorks

vxWorks에서 iostream 사용 관련.
iostreams Library
This library is configured into your VxWorks system with the INCLUDE_CPLUS_IOSTREAMS component.
For the GNU toolchain, the iostreams library header files reside in installDir/host/hostType/include/g++-3 directory. For the Diab toolchain, the iostreams library header files reside in the installDir/host/diab/include/cpp directory.

WARNING: Each compiler automatically includes the directories containing the header files for these libraries. You should never explicitly add those directories to your compiler include path. If you get warnings about missing headers, it probably means you are using the -nostdinc flag. This flag should never be used with this release of Tornado.
To use this library, include one or more of the header files after the vxWorks.h header in the appropriate modules of your application. The most frequently used header file is iostream.h, but others are available; see a C++ reference such as Stroustrup for information.
The standard iostreams objects (cin, cout, cerr, and clog) are global; that is, they are not private to any given task. They are correctly initialized regardless of the number of tasks or modules that reference them and they can safely be used across multiple tasks that have the same definitions of stdin, stdout, and stderr. However they cannot safely be used when different tasks have different standard I/O file descriptors; in such cases, the responsibility for mutual exclusion rests with the application.
The effect of private standard iostreams objects can be simulated by creating a new iostreams object of the same class as the standard iostreams object (for example, cin is an istream_withassign), and assigning to it a new filebuf object tied to the appropriate file descriptor. The new filebuf and iostreams objects are private to the calling task, ensuring that no other task can accidentally corrupt them.
ostream my_out (new filebuf (1)); /* 1 == STDOUT */
istream my_in (new filebuf (0), &my_out); /* 0 == STDIN;
* TIE to my_out */
For complete details on the iostreams library, see the GNU ToolKit User's Guide.

Hi,~~