C++ Builderを使うべき理由


2018.2.14更新
C++ Builder Berlin Starter
(画像はC++ Builder 10.1 Berlin Starterです。)

C++ Builderとは
C++ Builderは1997年からあるWindows向けのC++の統合開発環境です。
Turbo C(1987年が初版)の流れを組んでいて歴史があります。
ビジュアルな(視覚的な)操作でGUIプログラミングができる一流のRADを持ったC++ 開発環境は、C++ Builderしかないと思います。
Turbo Cの時代から日本語版がありました。
C++ Builderを使うとGUIブログミングの開発が無駄なく速いです。
おそらくどの開発環境よりも。
C++ Builderには強力なRADがあります。 画面設計がマウス操作でグラフィカルにできます。
画面配置だけでなく各種イベントへの連動が簡単にできるのでスムーズにプログラムを作れます。
画面の配置ができる統合開発環境は多いですがイベントへの連動ができないとか貧弱だと、かえって開発に時間がかかる場合もあります。
C++ Builderとほぼ同じことができるものとしてはVisual StudioのC#があります。
ただC#はC#であってC/C++ではないですからね。
Visual StudioではでC/C++でRADは使えません。
C/C++で強力なRADを使いたい場合は、C++ Builder以外に選択肢はないですね。


無料になったC++ Builder Starter Edition
最下位エディションのStarter Editionで10.1 Berlinのバージョンから無料になりました。
現在は10.2 Tokyoが最新バージョンですが無料は継続されています。
制限はありますが最新バージョンで今まで有料だったものです。
C++ Builder Starter Edition ダウンロード


なぜC++ Builderか?
  1. C++で最高のビジュアルプログラミングができる。
    2. GUIプログラム開発の効率が高く複雑な画面設計も容易。
    C++ Builderと同レベルのC++のRADは他には無いと思う。
  2. 言語はメジャーなC/C++
    3. 他の開発環境にも手を出した時の苦労は軽減されます。
    Visual C++、Qt、Gtk+、WxWidgets、Xcode、Android NDK、GCC、clang、WebAssembly、Emscriptenなどの多くのメジャーな開発環境がC/C++をサポートしています。
    複数の開発環境を使ったり別の開発環境に乗換える場合に便利です。
    もしC#をメインに使っていると後でQtを使えとか言われても今まで蓄積してきたノウハウは全て無駄になります。
  3. 非常に長い実績
    4. 初版は1997年。前身のTurbo Cは1987年から。
    C#よりも古くからある開発環境です。
  4. 高速動作するネイティブバイナリを出力。
  5. 省メモリで動作するネイティブバイナリを出力。
  6. LGPL、GPLなどのオープンソースライセンスを気にしなくてよい。
    7. この利点は計り知れない。
    ソースを公開する必要もなく、面倒なオープンソースライセンスを遵守しなくていい。
    オープンソースライセンスの開発環境では、プログラミングの勉強とは別にライセンスについての勉強が必要な場合が多い。
    不用意にオープンソースライセンスの環境に手を出して裁判沙汰になったり非難されたりするリスクをC++ Builderでは回避できる。
    オープンソースライセンスではライセンス違反をしていなくても疑惑をかけられるリスクがある。
    面倒なトラブルに巻き込まれるリスクを回避できる意味は大きい。
  7. 逆コンパイルが不可能。解析、リバースエンジニアリングされにくい。
  8. 作ったソフトウェアは.NETのしがらみを受けない。
    9. 作ることができるプログラムの種類に制限がほぼなく、実行環境に.NETは不要。
  9. 用途に合わせて二種類のGUIライブラリが選べる。
    10. Windows固有の機能をフルに使いやすいVCLライブラリとクロスプラットフォームのFireMonkey(FMX)の二つを用意。
  10. 一応はクロスプラットフォーム対応。(Windows、Mac OS X、iOS、Android)
    11. (総合的判断ではQtのほうがいいような気がしています。)
  11. 日本語版がある。
    12. 日本語メニュー、日本語ヘルプ、日本語ドキュメント、日本語ホームページ、日本語サポートなど。
  12. 作ったプログラムがGNU/Linux上のwineで動く可能性がある。
    13. C++ Builderで作ったプログラムは内容によりますがwineを使えばGNU/Linuxでも動く場合があります。
    もし動かなくても知りませんが。
    QtやGTK+などの普通のGNU/Linuxの開発方法ではどのディストリでも動くバイナリパッケージを配布することがパッケージシステムの違いやライブラリの依存関係の違いなどで難しいです。
    そしてほぼ全てのGNU/LinuxのディストリがAndroidのGoogleプレイストアのような個人がプログラムを登録する場所や手段を提供しておらず、個人のプログラム配布方法が技術的に確立されていません。
    それなら普通にC++でWindowsプログラムを作ってwineでの動作を期待するのもありということです。
    C# + monoやJavaと比べてどちらのほうがいいのかは場合や趣味によると思います。
    Androidが同じLinuxをカーネルを使っているのにGoogleプレイストアのような個人がプログラムを配布する場所を作れたのはJava言語をメインにしたこととC言語ライブラリにGPLライセンスのglibcではなくBSDライセンスのBionicを採用したらだと思います。
    意外と個人がLinux向けのプログラムを配布するならQtとGTK+ではないほうが都合がいいことが多いです。
  13. 一応はWindowsストアに登録できるUWPアプリに対応
    14. C++ Builder Berlin 10.1 Update 2以降のバージョンでProfessional以降のエディションではWindows 10 Anniversary Update以降のDesktop Bridge機能を利用したUWPアプリの作成ができます。
    無料のStarterエディションではこの機能はありません。
    ただしどのバージョンやエディションでもDesktop BridgeのDesktop App Converterを使えば自分でUWPに変換できると思います。(要対応インストーラー。未確認)
    なぜ一応なのかと言うと、Desktop Bridge機能を利用するUWPアプリしか作れません。
    パソコンのWindows 10 Anniversary Update以降のソフトしか作れません。
    ARM CPUやWindows 10 Mobileに対応していません。

C++ Builderはこれからも開発販売され続けるのか?
近いうちに終焉を迎える可能性については否定しませんが、プログラマーの知識として、一度はC++ BuilderのRAD、ビジュアルプログラミングを体験しておくべきだと思います。
C++ Builderを開発販売している会社の経営は大丈夫なのかとか、すぐ倒産して開発中止するのではという意見はかなり前からあります。
その割には開発中止するどころか大進化を遂げて、Mac OS X、iPhone、iPad、Androidにまで対応したというのが現在までの結果です。
現在までの結果で言うとかなり以前からあった否定的な予想は大外れでした。
これから先のことは分かりません。
C++ Builderの権利が買収されて別企業に移ったり会社自体が買収されたりしてきたので不安視するのは当然かと思います。
万一、開発中止販売中止になったとしても、今既にC++ Builderを持っている人はWindowsのプログラムについては特に困らないと思っています。
WindowsはOSをバージョンアップしても過去のソフトウェアが動きますからね。
最新のWindows10でも20年以上前のWindows 95のソフトが動くぐらいです。
15年前のC++ BuilderでもUnicodeに対応しなくていいWindowsソフトなら今でも新規開発に十分使えます。
Mac OS X、iOS、Androidではこういうことは無理かな?
C++ Builderは、C++なんで、C++に対応したVisual C++、Qt、Gtk+、WxWidgets、Xcode、Android NDKなどの開発環境を使う必要が出た時の労力も軽減されると思います。
正直私自身もC++ Builderの今後は大丈夫なのかという気持ちがあります。
しかし、C++ Builderは言語がC++でです。
C#と違っていくらでもつぶしが効くし、いくらでも逃げ道があります。
QtやXcodeがC#を標準サポートしていない状況でC#を使うことのほうが私にとってはよほど恐ろしいことです。


開発環境の選択は宗教
最終的に本人がいいと思えばそれが正解だと思います。
何ヶ月か経って、あるいは何年何十年と経ってから後悔する可能性はありますが。


Visual StudioでC++ではだめなのか?
Visual Studioでは、名前に反してC++でビジュアルプログラミングができません。
だから余裕でだめでしょう。


Visual StudioでC#ではだめなのか?
C++で作りたいという希望がない人にとってはだめではないと思います。
お好きならどうぞ。
マイクロソフト純正の開発環境という利点は多いにあると思います。
少なくともWindowsでは将来も安泰だと思います。
C#を使う場合、受け入れないといけない欠点もあります。
例えば、ソースを非公開にしていても逆コンパイル、解析されてソースを見られてしまうリスクとか、 実行速度が遅いとか、.NETに依存し対応するバージョンの.NETがインストールされていない動かないことです。
(.NETが必須なことはWindowsの場合は.NETがマイクロソフト純正なので普及しており大きな問題ではないと思います。)
解析が簡単なので何もしないでソフトを配布した場合はソースを公開していることとほぼ同じです。
難読化はできるけども、逆コンパイルされるリスクは防げないので、ソース保護したいなら最初から使わないほうがいいと思います。
難読化ソフトのDotfuscatorを別途買えば基本パッケージだけで1,050,000円。(百五万円)
ソースを解析されやすい問題に対する反論はいくつかあります。
  1. Windows 10上のUWPアプリケーションでは .NETネイティブによりネィティブコンパイルすればいい。
  2. 重要ルーチンをC++で書いてC#から呼ぶようにすればいい。
1の方法ではWindows 7やWindows 8.1では使えない上にタブレット向けのUIで使うことになりデスクトップアプリとしては苦しくなります。
Windows 10タブレット、Windows 10 Mobile搭載のWindows Phoneでも動くのかも知れませんがタブレット、スマホ分野はAndroid、iPhone、iPadにほぼ市場を奪われており今のところはWindows 10 Mobileへの対応は無意味に近いです。
そしてC#の利点であったGNU/Linuxなどへのクロスプラットフォーム性は捨てることになります。
Windowsストアに登録できるという利点はあります。
(C++ Builderなどで作ったソフトもWindows 10のDesktop Bridge機能でUWPに変換は可能。C++ BuilderはバージョンやエディションによりUWP出力機能を持っているが対応していないバージョンやエディションもDesktop BridgeのDesktop App Converterを使って自分で変換することはできる。(要対応インストーラー)ただしDesktop BridgeではIntel/AMD系CPUのパソコン専用でWindows 10のみに対応する。)
2の方法によりC++で書いた部分についてはソース保護されるので有効な対処方法だと言えます。
ただしC++で書いていない部分はソース保護されませんし複数の言語をミックスするのは手間であり分かりにくく面倒くさく開発効率にも保守効率にも問題が出ます。
どのみちC++を使わなくてはならないのなら最初から全部C++で書いたほうが楽かと。
またC#で作ったプログラムにクロスプラットフォームでのバイナリ互換を求める人にはC++を混ぜる方法は使えません。
C#のクロスプラットフォーム性は元々疑問があります。
Javaとは違い基本はWindowsに強く依存しています。
monoとかXamarinとかありますけども、WindowsでのC#とその他のOSでのC#との互換性については懐疑的になったほうがいいと思います。
しかしながらWPFなどのWindowsでしか使えないライブラリを使うことを諦めるならC#はGNU/Linuxのプログラムを作る方法のひとつの選択肢になります。


別のC++コンパイラとQtではだめなのか?
Qtのほうが良い場合もあります。ケースバイケースです。
Qtは高機能ですしクロスプラットフォームに強いです。
C++ Builderも昔のVer 6ではCLXというQtベースのクロスプラットフォームのGUIライブラリを持っていました。
  1. 難しい。敷居が高い。
    2. ちょっと難しいかな。
    壁を乗り越えられれば特に難しく感じないし良いものだとは思います。
    C++ Builderや、Visual StudioでC#をするみたいな感じですんなり入れないと思う。
    難しい簡単は主観だと思いますが、C++ Builderとはタイプが違うのは事実です。
  2. ビジュアルプログラミングの能力
    3. Qt Creatorでは、C++ Builderに勝てない。
    開発効率、生産性は、C++ Builderのほうが上だと思う。
    Qt Creatorはイベントにあまり連動していないんですよね。
    イベントとの連動が強化されていないビジュアル画面設計というのは邪魔かもしれない。
    Qt Creatorを使わないで作ったほうがよほど簡単なような気も。
    情報もサンプルプログラムもQt Creatorを使わないものばかりというのもQt Creatorが使えない大きな理由のひとつです。
  3. 実行ファイルの配布ファイルサイズが巨大になる
    4. Qtライブラリのサイズが大きすぎますが添付しないと動きません。
    極小のプログラムでも必要なQtライブラリの合計だけで60MBぐらいになったりします。
    (Qt 5.2 Windows+mingw 32bitでwindeployqtコマンドが集めたDLLの場合)
    この巨大で大量のQtライブラリファイルをWindowsやMac OS Xでは一緒に配布しないと動きません。
    C++ Builderなら極小のプログラムなら全部込みの実行ファイルが2MBぐらいです。
    QtがデフォルトでインストールされていないWindowsやMac OS Xではこれは大きな問題になります。
    配布サイズが小さくて済むC++ Builderでないと用が足せないことが多いです。
    配布ファイルサイズもプログラムの質に入ります。
    ダウンロードサイズが大きいだけでなくハードディスクの容量を浪費してしまいます。
    Qtがインストールされているのが普通のGNU/Linuxではこの問題はないですが、Qtライブラリを添付しない場合はインストールされているQtライブラリのバージョンの違いによって動作しない可能性があります。
  4. ファイル一個だけの実行ファイルを作れず配布が難しい。
    5. Qtでは実行ファイルの他ダイナミックライブラリファイル(DLLやsoファイルなど)が大量に必要です。
    これは配布する時に非常に面倒になります。
    C++ BuilderのようにGUIライブラリをスタティックリンクしてEXEファイルひとつだけを配布ということが(多分)Qtではできません。
    ファイル数が数え切れないほど大量にあるため管理が難しいです。
  5. Windowsに特化したGUIライブラリがない
    6. C++ BuilderにはクロスプラットフォームのGUIライブラリとは別にWindowsに特化したGUIライブラリのVCLがありますがそれに相当するものはQtにはありません。
    QtはクロスプラットフォームのGUIライブラリです。
    クロスプラットフォームは大きな利点ですが、Windows固有の機能を使うのに制限ができたり、難しくなる場合があります。
  6. LGPLライセンスによる縛り
    7. 年間3540ドル(1ドル104円換算で36万8160円)の商用ライセンス料金を払いたくないならLGPLというオープンライセンスの一種になります。
    昔はGPLだったので制限はかなり緩和されていますが、それでもやはり使いにくいライセンスになります。
    LGPLのライブラリを使用した場合のソース公開は必須ではないのですが、制限がありライセンス違反にならないように気をつかう必要があります。
    年間3540ドルの商用ライセンス料金を払ってもC++コンパイラの商用ライセンスは付いてこない。
  7. C++コンパイラは別
    8. Qtは自前のC++コンパイラがありません。
    Qtとは別製品で別ライセンスのC++コンパイラを使うことになります。
    すると、Qtのライセンスとは別にC++コンパイラのライセンスの制限も受けてしまう。
    ライセンスがややこしくなります。
    Qtの商用ライセンスを買ってもC++コンパイラにg++を使って、LGPLライセンスのC言語標準ライブラリ(glibcなど)を使ってしまうと、結局LGPLの縛りを受けてしまう。
    (mingwはC言語標準ライブラリにglibcを使わずwindows標準のC言語標準ライブラリのmsvcrtを使うのがデフォルトみたいでGPLv3のC++標準ライブラリのlibstdc++は、GCC Runtime Library ExceptionというGPL適応を逃れる例外に該当するみたい。)
    Visua Studioの無料版を使った場合もそのライセンスの縛りを受けます。
    C++コンパイラはセットにしてくれたほうが分かりやすいです。
  8. 日本語での公式情報なし
    9. 公式ドキュメントとか公式ホームページとかは全て英語です。
    英語とにらめっこすることは避けられないと思う。
    最悪は翻訳ソフトにかければいいし、高度な英語能力は必要ないと思いますが日本語の情報はあるにこしたことはないです。
    Qtの敷居を高くしてしまっている一因でもあります。
  9. GNU/Linux向けへのバイナリ配布が難しい
    10. ほとんどのGNU/LinuxディストリはGoogleプレイストアのような個人がプログラムを配布する場所や手段を提供していない。
    パッケージシステムやライブラリの依存関係やライセンスの問題でプログラムのバイナリの配布が難しい。
    これならC++ Builderで作ってwineでGNU/Linux上で動作させることを期待したほうがまだましかも知れない。
    もっともwineでは動くかどうか怪しいですが。

HTML5ではだめなのか?
オンラインサービスならいいですがデスクトップアプリケーションには向いていません。
基本的にはインターネット接続しないと動きません。
HTML5はあくまでウェブブラウザの上で動くものでセキュリティー上の懸念から制限がたくさんあります。
各ブラウザの互換性が低くこっちのブラウザでは動くがこっちのブラウザでは動かないという問題は避けられません。
多くのブラウザ、さらにその多くのバージョンで動作テストする必要があり開発コストがかかります。
割り切ってブラウザを限定する方法もありますがプログラムとしての価値が大幅に下がってしまいます。
HTML5のクライアント側で主に使われるプログラミング言語のJavascriptは癖が強すぎて開発効率が悪く他の言語間との移植性も低いです。
WebAssemblyが普及すればJavascriptを介さずに直接C/C++でクライアント側の処理が書けるので今よりは状況はよくなると思います。
それでもローカルファイルをいじることは基本的にはできません。
サーバーとクライアントに別れたプログラムでないとできることが大幅に少なくなります。
かといってわざわざインターネット上にサーバーを設置して各ユーザーごとのデータを保管し続けるのはお金も手間もかかります。
ローカルにHTTPサーバーを設置する方法もありますが無駄に大掛かりになります。
多くのエンドユーザーはHTTPサーバーをローカルに設置する知識はないでしょう。

Delphiではだめなのか?
統合開発環境であるDelphiの言語をDelphi言語(Object Pacal)からC++に変えただけのものが、C++ Builder。
言語以外の部分はC++ Builderと同じです。
言語はどちらのほうがいいかという問題ですが、
Visual Studio、Qt、Gtk+、WxWidgets、Mac OS Xの標準開発環境のXcode、GNUコンパイラコレクション、clang、Android NDKなどの有名開発環境が対応しているC++と、それらが一切対応していない独自のDelphi言語(Object Pascal)のどちらを取るべきかは言うまでもないでしょう。
C言語標準ライブラリもC++標準ライブラリもデフォルトで使えないというのはかなり厳しい制限になります。


Lazarusではだめなのか?
Object Pascalに対応しC/C++に対応していない。
C言語標準ライブラリもC++標準ライブラリもデフォルトで使えないというのはかなり厳しい制限になります。
LGPLのライブラリを静的リンクしたプログラムを作るため、リバースエンジニアリングを許可し、ソースまたはオブジェクトファイルの公開が必須になります。


Javaではだめなのか?
Javaいいと思います。
JavaFXのことはよく知らないけどもJavaの旧GUIライブラリのSwingは歴史が長く日本語の情報が多いので開発しやすいと思います。
ただJava VMの言語にC/C++を選べないのが非常に残念です。
C言語標準ライブラリもC++標準ライブラリもデフォルトで使えないというのはかなり厳しい制限になります。
GUIライブラリは高機能。
デスクトップOS間のクロスプラットフォームに強いです。
C#と違ってWindowsに依存した機能がなくGUIの部分も各デスクトップOS間で互換があります。
Windowsとは別にMac OSまたはLinuxにも対応したい場合に有利になります。
Windows以外のデスクトップOS用のソウトウェアをバイナリで配布する場合に向いています。
一度コンパイルすればそのバイナリをOSを超えてディストリを超えて配布できるのは魅力です。
各OSや各ディストリごとに開発環境を構築するとか各OS各ディストリごとにコンパイルする必要はないです。
OSがバージョンアップしても再コンパイル無しで同じバイナリが動きます。
特にディストリが乱立するGNU/Linux向けのソフトを個人が配布するのに効果があると思う。
Windowsだけで動けばいいプログラムを作る場合は欠点のほうが目立ちます。
JREのインストールが必要とか、起動が遅い、動作が遅いとなるとユーザーには敬遠されやすい。
(20年前のパソコンと今のパソコンでは能力差が大きく現在速度が問題になることはまずないが20年前についたイメージがなかなか消えない感じです。)
C#と同じように解析が簡単なので何もしないでソフトを配布した場合はソースを公開していることとほぼ同じです。
難読化はできますがほとんど効果ない難読化ソフトも多いです。
Java VMで動く言語にC/C++が含まれていないので別の開発環境間とのプログラム移植が困難です。
Javaは大普及しておらずJava実行環境(JRE)をインストールしていない人とかインストールしたがらない人が多くいるのが現状です。
その問題についてはJREごと配布することである程度解決できます。
javapackagerというコマンドで配布ソフト専用のJREを含んだ各種OSのインストーラーまたはパッケージがを作成できます。
Windowsの場合はJRE込みのexeの自己解凍型インストーラーまたはmsiファイルを作成できます。
ユーザーから見ると普通のWindows専用ソフトのようになります。
しかしJRE込みなので小さいプログラムでも配布ファイルは解凍前46MB、解凍後177MB(Windows,Java8 32bit)のように巨大になりすぎるという欠点があります。
自分で使うのはいいけども配布を考えるとJavaは不利になります。
一言でJavaと言っても開発環境や実行環境の選択肢が多くこれが利点なのか欠点なのか良く分かりません。
話せば長くなりますがSwingかJavaFXか、コマンドライン開発かIDEか、IDEなら何を使うべきかの選択には悩まされます。


GTK+またはwxWidgetsではだめなのか?
目的の範囲内で動作し使いこなせるならいいんじゃないでしょうか。
RADは使えないと思います。
GTK+は(特にUNIXライクOSで)メジャーですがwxWidgetsはマイナー過ぎる感じです。
そのためwxWidgetsは多くの場合選択肢には入らないと思います。
Gtk+には足りない機能もあるので作る物によっては選択肢に入らないことがあります。
Gtk+よりQtやJavaのSwingのほうが高機能です。
LGPLなどのライセンスの問題はあります。
あとはC++ Builderと比較すると、LGPLという面倒くさいライセンスと付き合う必要が出ます。
GTK+はバージョン間での互換性が低く混乱気味のような気がます。


Valaではだめなのか?
マイナー過ぎる気がします。
LGPLなどのライセンスの問題はあります。
Valaとは独自なプログラミング言語です。
C#に似た言語と言われています。
GUIはGTK+を使用しますがGTK+の標準言語はC言語でありValaでGTK+を使う方法を調べるのは大変かも知れません。
他の言語とは互換性がないのが難点だと思います。
C/C++/C#ではないほうがいいと思う人にはいいかも知れませんが、
なぜC/C++/C#ではいけないのかをよく考える必要があると思います。
ValaはコンパイラではなくVala言語をC言語に変換するトランスレーターです。
しかしValaはC++とは違ってC言語との親和性は低いです。


C++ Builderはクロスプラットフォーム開発におすすめか?
正直あまりおすすめしない。
各OS純正の開発環境かその他の別の開発環境のほうがいいかも知れない。
基本的な機能で満足し、ターゲットOSがバージョンアップした時に今まで作ったプログラムが動作しなくなったり、開発で使うターゲットOSをバージョンアップした時にコンパイルできなくなるリスクに了承できるならいいと思う。
FireMonkey(FMX)はVCLとの互換性が低く、サポートしていない機能がある。
作りたいプログラムによっては機能上の制限によりFireMonkeyは使えない。
例えば、FireMonkeyはTStringGridの仕様がVCLのものとは極端に違い一行選択カーソルにすることができない。
他にはTFontDialogがないとか、TWebBrowserのプロパティやイベントやメソッドが少なくできることが限られる。
C++ Builder XE4で作ったソフトが、Mac OS X 10.9 Mountain Lionでは動くが、Mavericksでは動かないということがあった。
XE8で作ったソフトはサポート外である割と新しいMac OS Sierraでも動作したので、最近のC++ BuilderのバージョンではMac OS Xでは高いバイナリ互換があると思います。
(もっと新しいMac OS High Sierraでどうなるかは知りません。)
(サポートしているMac OS Xを使って作ったプログラムが将来のMac OSのバージョンで動くかという話であり、サポート外のMac OS (X)のバージョンで開発できるかどうかはまた別問題です。)
今でもC++ Builder XE4はMac OS X 10.9 Mavericksをサポートしていない。
C++ Builder XE8はAndroid 5をサポートしているがAndroid 6.xをサポートしていない。
XE8で作ったAndroidプログラムはAndroid 6.0ではインストール時にエラーが出てインストールできない。
XE4やX8に限らずどのC++ BuilderのバージョンもターゲットOS一部のバージョンしかサポートしていない。
サポートしていないだけで実際は動くのならいいのだが、もし動かないことを把握しているのに放置してサポートしていないのなら問題だ。
ターゲットOSがバージョンアップした時に一旦動かなくなって、C++ Builderのアップデートで対応されるとしても、一旦動かなくなることが問題。
事後対応ではなく、最初から動作しないという事件が起こらないようにしてくれないと困る。
Javaだと配布したバイナリがターゲットのデスクトップOSのバージョンアップで動かなくなることはない。
20年前に作ったプログラムでも今の最新OSで動くからJavaはすごいと思う。
Qtはどうなんだろう。


C++ Builderサンプルプログラム

C言語の話


あーすブラウザ
オンライン鍋田辞書
鍋田辞書トップ