Programming

C/C++ の将来性その 2

ちゃっぴ (tyappi@wankuma.com) — Mon, 01 Sep 2008 04:11:00 GMT

多くの人から指摘されましたが、C/C++ はここ数十年では絶対に無くならないと思います。というのは絶対に必須な用途があるからです。

ただ、現在ではそういった用途以外でも利用されていることが多いのではないでしょうか？

正直、そういった用途では C/C++ の未来は暗いと思います。

C/C++がもたらす問題こういった問題があるので。

では、C/C++ の未来は暗いか？自分が発言した内容と矛盾しているようですが、一部のできる人にとって道は明るいかもしれません。

利用者は現在より一層減るでしょうけど、C/C++ programmer の価値は一層高まると思います。限定的な用途となりますが、C/C++ の問題点が一般的に認識されればど素人に扱わせるなんてこと無くなるでしょうから。
# 半ば以上、期待が含まれていることは否めませんが。

それから、必要も無いのに C/C++ で coding することもできれば避けるべきではないかと思います。今後一層 C/C++ programmer で問題なく coding できる人は減るでしょうから、保守で問題を生じる可能性がより一層高まると思われます。同時に費用面で問題が生じるでしょうし。

今後一層 C/C++ を扱う開発は減ってくる流れは強ますでしょう。そういう意味では、C/C++ は大衆受けする機能を盛り込むのではなく、一般的な開発者では扱えない機能をどんどん盛り込むことにこそ未来があるんじゃないかと思います。

C/C++ の将来性

ちゃっぴ (tyappi@wankuma.com) — Sun, 31 Aug 2008 23:16:00 GMT

わんくま同盟横浜勉強会 #1 で話題に上ったこと。

ちゃんと理解していないオイラが書くのもなんですが、やっぱり将来性がないと思う。
# 御大すみません。

多くの人が C/C++ は複雑すぎるというのが理由としてあげていましたが、もっと深刻な問題として security の問題があると思います。

多くの人がご存じのとおり、C/C++ で coding すると buffer overflow の問題を避けて通れません。このことを完璧に理解して、かつ対策を完璧に実践できるのであれば問題はありませんが、この手の問題に完璧はありません。

このことは現時点で最も脆弱性に気を使っていると思われる Microsoft でも脆弱性が無くならないことが証明していると思われます。

知らない人も結構いるでしょうけど、Microsoft は Trustworthy Computing の一環として SDL: Security Development Lifecycle を取り入れていますので、現状では security に関して一歩先に進んでいます。それでも、ご存知のとおり深刻な脆弱性は無くなっていません。
# Check-in するときに security に問題のある code を弾くことをやっているのはすごいですね。
# ぜひ、一般でも扱えるように展開してもらいたいものです。

私は基本的に software を開発する立場ではなく、software を扱う立場ですが、意識の差はあるにしろ少しでも脆弱性が少ない software を扱いたいというのは software を扱う者の共通した願望でしょう。

ということで、performance や機能の問題で C/C++ が必須とされる場合を除き、C#, VB, JAVA 等の memory 管理を自動で勝手にやってくれる言語で書いて欲しいと思っています。

ぶっちゃけ、C/C++ で全く脆弱性の存在しない code を書くのは非常に難しいです。ということで、C/C++ で書くのは本当にどうしようもない場合に限って欲しいなぁというのが願望です。

間違っても、programmer 一年目のど素人とかには絶対に手を出して欲しくないです。扱うなら下記を熟読し、完璧に理解した上で数年みっちり修業し、しかるべき code review を実施した上で release して欲しいものです。

C/C++ 扱う上で気にしなければならない security の問題点が説明されています。また、software の内部動作を理解する上でも役に立つでしょう。

Windows platform を扱うなら絶対に読んで欲しい本。Coding の問題点を指摘する書籍は他にもいろいろありますが、coding 以外の設計等で脆弱性を局所化することを説明している書籍は少ないのでぜひ一読すべき。
# ただし、個人的にはちょっと問題に思える部分があるので鵜呑みにしない方がいいと思われます。もっとも、それを差し引いても概念を理解するためには非常に役立ちます。

VB 暗黙の型変換

ちゃっぴ (tyappi@wankuma.com) — Thu, 12 Jun 2008 12:33:00 GMT

ネタ元: VBがどうにも...

個人的には、暗黙の型変換はあっても問題無いと思います。ただし、型を全く意識しなくてよいというのは違うんじゃないかと。

VB.NET には当然型がありますし、VB 6.0 でも VBScript でも内部形式として型はありますね。これを全く意識しないようでは思わぬ bug を作りこんでしまいます。省略できるから憶えなくてもよいわけではなく、この場合は問題ないから省略できると学習しなければまずいでしょう。これは VB に限った話ではなく、多くの script 言語を扱う場合も同様です。

で、暗黙の型変換について。暗黙の型変換があるのはかまわないですが、そのこときちんと documents に書いて欲しいですね。

VB.NET の reference では下記で説明されています。

ぶっちゃけ、わかりやすいものでは無いと思いますし、説明が非常に不十分だと思います。Visual Basic を扱う人の対象として本職の programmer 以外を想定していますので、もう少しわかりやすく書かないとダメだと思いますが。

個人的には、型の組み合わせによる変換表が最低限必要だと思うんですが。

Integer + Long = Long みたいな。

拡大変換と縮小変換に一応変換表らしきものはありますが、これではすぐにわかりませんよね。

VB 6.0 のときもそうですけど、ここら辺もう少しちゃんと解説してもらいたいものです。

Junction が倒せない

ちゃっぴ (tyappi@wankuma.com) — Sat, 07 Jun 2008 16:31:00 GMT

Scripting.FileSystemObject の DeleteFolder method で junction を削除しようとしたんですが。

書き込めませんだってさ！

DeleteFile も Scripting.Folder class の Delete method もちろん NG。

さてどうやって消したもんかな。。。

一応 rmdir command は利きますが。。。

PowerShell での Enumeration

ちゃっぴ (tyappi@wankuma.com) — Fri, 23 May 2008 02:53:00 GMT

めちゃくちゃ気持ち悪いんですけど。

function WriteEventEntry(
	  [System.String] $strMessage
	, [System.Diagnostics.EventLogEntryType] $logType = 'Error')
{
	Set-Variable -Name 'strSource' -Value 'Test' -Option 'Constant';
	Set-Variable -Name 'strLogName' -Value 'Application' -Option 'Constant';
	
	$eventlog = New-Object `
		-TypeName 'System.Diagnostics.EventLog' `
		-ArgumentList $strLogName;
	$eventlog.Source = $strSource;
	$eventlog.WriteEntry($strMessage, $logType);
}

こんな関数書いたんですが、なんで下記のようによびださなければならないの？

WriteEventEntry 'Message' 'Information'

こうゆう呼び出しできるようにしてほしいんですけど

WriteEventEntry 'Message' [System.Diagnostics.EventLogEntryType]::Information

なんで、文字列で指定するの？

Windows での folder path 指定の問題点

ちゃっぴ (tyappi@wankuma.com) — Sat, 10 May 2008 14:39:00 GMT

ネタ元: SHFileOperation関数について

UNIX では path で direcotry を明示的に指定するためにこのような表記をします。

/dir1/dir2/

最後に '/' をつけるのがミソですね。Windows ではどうでしょう？

この表記方法が使える場合もあるし、使えない場合もある。扱う API によってまちまちです。

例えば、ネタ元の SHFileOperation function。これ、SHFILEOPSTRUCT structure の pTo に "C:\Folder1\Folder2\" のような感じで指定して copy を行うと

ダメだってさ。。。orz

ちなみにこの path 指定方法は絶対に利用できないわけではなく、一部の API や command では利用可能だったりします。たとえば、XCOPY。こちらは "C:\Folder1\Folder2\" のような指定をするべき仕様になっていて、省略する場合には "/i" switch を指定するのが正しい方法です。

しかしまぁ。統一感の無いこと。。。Path の仕様があいまいなんで、それを利用する application を作成するときにめちゃくちゃ苦労します。とはいえ、これ確か MS-DOS の頃からのしがらみなんですよね。。。

こういうところが随所に見られるので Windows 嫌いという人もまた多いんじゃないでしょうか？

現状では、こちらを抜本的に見直すのは互換性の問題があるので不可能だと思いますが、願わくば新しいものを作る時には直していただきたいんですよね。

と思って、MSDN Library 覗いてみると Windows Vista では、SHFileOperation function が IFileOperation Interface に置き換わっているらしい。調査してみるか。。。

WOW64 を使って VC++ 2008 で作成した 32bit application を実行するには 32bit 版の CRT が必要

ちゃっぴ (tyappi@wankuma.com) — Tue, 29 Apr 2008 15:33:00 GMT

Visual Studio 2008 で C++ を使い作成した application を実行するには、CRT (C RunTime Library) が必要になります。ということで下記を install。

Microsoft Visual C++ 2008 再頒布可能パッケージ (x64)

で、実行したところ system event log に CRT が見つからないとの error が。Compile option ちゃんと確認してみたら、32bit で compile していた。。。orz

WOW64 (Windows on Windows 64) を使って 32bit application を動かすわけだからよく考えれば当然 32bit 用の CRT が必要になるわけで。

ということで下記を install。

Microsoft Visual C++ 2008 再頒布可能パッケージ (x86)

無事動作しました。

x64 の OS を使っている場合には、x64 版だけでなく場合によっては x86 版も install しておくほうが良いという教訓でした。

GetLogicalProcessorInformation

ちゃっぴ (tyappi@wankuma.com) — Tue, 29 Apr 2008 14:45:00 GMT

Windows Server 2003 から CPU の情報を取得する関数として GetLogicalProcessorInformation function が導入されました。ちなみに Windows XP でも Service Pack 3 を適用すれば利用可能です。

名前に logical (論理) とついていますが、この function を利用して physical processor 数を取得することができます。

ただし、Windows Server 2003 環境では注意が必要です。

[KB932370] The number of physical hyperthreading-enabled processors or the number of physical multicore processors is incorrectly reported in Windows Server 2003

こちらで説明されているように Windows Server 2003 環境では physical processor 数を正確に取得できないことがあります。

試しに Windows Server 2003 Enterprise x64 Edition Service Pack 2 で MSDN の sample code を実行したところ、下記結果が返ってきました。

Core 2 Duo E6600 1 個搭載

Number of NUMA nodes: 1
Number of cores: 1
Number of physical packages: 0
Number of caches: 3

解消方法としては、KB932370 で提供されている hotfix を適用することになります。この hotfix は kernel module を変更し、この問題の修正だけでなく、他の kernel に修正も含まれていることに注意してください。Kernel に対する変更であるため、hotfix に問題が含まれる場合甚大な被害を被る可能性があります。置き換える対象の file version を注意深く確認し、この hotfix を適用することによって発生する既知の不具合がないか確認したほうがよいでしょう。

なお、この hotfix を適用すると GetLogicalProcessorInformation function だけではなく、WMI Win32_Processor class および Win32_ComputerSystem class に関する変更も行われています。

Class	Property	Before	After
Win32_ComputerSystem	NumberOfProcessors	Retun number of logical processors	Retun number of physical processors
	NumberOfLogicalProcessors	N/A	Available
Win32_Processor	NumberOfCores	N/A	Available
	NumberOfLogicalProcessors	N/A	Available

これらの変更は Windows Vista 以降の OS ではもちろん、Windows XP Service Pack 3 でも行われています。

Hungarian notation (ハンガリアン表記法)

ちゃっぴ (tyappi@wankuma.com) — Sat, 19 Apr 2008 20:26:00 GMT

忌み嫌っている人も多いようですが、私の個人的な意見。嫌いじゃありません。

多くの人は "System Hungarian" は絶対に使うべきではない、"Application Hungarian" を利用すべきと言いますがどんな状態でもそれが正しいでしょうか？

確かに C# のような完全に type safety が保証されている言語では、"Application Hungarian" で問題が無い場合も多いでしょう。

ただし、C# のような完全に type safety が保証されている言語でも cast 前後でそれぞれ変数に割り当てるとなると "Application Hungarian" ではきつくなりますね。扱うものは同じですから、頭に付くか後ろに付くかもしくは真ん中に含めるかどうでもいいですが、型を変数名に含めないといけないでしょうから。まあ、そういう例外を除き "System Hungarian" を積極的に利用する利点が無いわけですから、この場合にはあえて規約として強制すべきではないというのには同意です。

ですが、type safety が保証されていない言語ではどうでしょう？ "System Hungarian" 強制したほうがいい場合がありませんか？

例えば、dynamic な言語。多くの dynamic 言語では型の存在が隠蔽されています。そういう言語を扱う場合、明確に型を識別するため "System Hungarian" を利用してやりたくなります。

ちなみに VBS や C を使うときにはガリガリの "System Hungarian" 利用しています。C# で書くときはやらないけど。

scanf って教える必要ある？(初心者に教えるときでも最初から脆弱性が発生しない方法を教えよう)

ちゃっぴ (tyappi@wankuma.com) — Sat, 29 Mar 2008 22:30:00 GMT

上記で話題になった記事ですけど、他のも覗いてみた。

C/C++のデータ型と書式を知る：入力の書式

    #include <STDIO.H>
      ..........
    char a[11];            /* 半角10文字分の文字列を保持する変数(配列) */
    scanf( "%s", a );      /* 変数aに文字列を入力 */
    printf( "%s\n", a );   /* 変数aの値を出力 */

おい！ scanf って教える必要がある？教えるなら、fgets でしょう。

 char buffer[11];
 fgets(buffer, sizeof(buffer), stdin);
 printf("%s\n", buffer);

慣れている人ならば、sscanf も加えるかもね。

 char buffer1[11];
 char buffer2[11];
 fgets(buffer1, sizeof(buffer1), stdin);
 sscanf(buffer1, "%s", buffer2);
 printf("%s\n", buffer2);

なぜ scanf を使わないか？というと buffer overflow する可能性があるから。元記事の sample 11文字以上の入力があった場合には、buffer overflow します。
これ見て C 覚えようとしている人どうなるんだろ？Bug の発生だけでなく脆弱性にもなるんですけど。
初心者にわかりやすく解説したいというのはわかります。でも、脆弱性が絡む部分は後から教えるではダメだと思う。脆弱性が発生する原理は後追いで解説するのはかまわないとしても、脆弱性を生む要因を教える時に脆弱性を回避する方法を一緒に教えないと。もしくは脆弱性が発生しない方法のみ教える。

どうしても scanf を使って簡単に説明したいというなら、書式指定文字で size を制限する。

 char buffer[11];
 scanf("%10s", buffer);
 printf("%s\n", buffer);

次の page に書式指定文字の解説が書いてあるんですが、説明ないですねぇ。