C++ Builderを使うべき理由


2016.12.3更新

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 10.1 Berlin Starter Edition
最下位エディションですが最新バージョンの10.1 Berlinが無料になりました。
制限はありますが最新バージョンで今まで有料だったものです。


なぜC++ Builderか?
  1. C++で最高のビジュアルプログラミングができる。
  2. GUIプログラム開発の効率が高く複雑な画面設計も容易。
    C++ Builderと同レベルのC++のRADは他には無いと思う。
  3. 高速動作するネイティブバイナリを出力。
  4. LGPL、GPLなどのオープンソースライセンスを気にしなくてよい。
  5. この利点は計り知れない。
    ソースを公開する必要もなく、面倒なオープンソースライセンスを遵守しなくていい。
    オープンソースライセンスの開発環境では、プログラミングの勉強とは別にライセンスについての勉強が必要な場合が多い。
    不用意にオープンソースライセンスの環境に手を出して裁判沙汰になったり非難されたりするリスクをC++ Builderでは回避できる。
  6. 逆コンパイルが不可能。解析、リバースエンジニアリングされにくい。
  7. 作ったソフトウェアは.NETのしがらみを受けない。
  8. 作ることができるプログラムの種類に制限がほぼなく、実行環境に.NETは不要。
  9. 用途に合わせて二種類のGUIライブラリが選べる。
  10. Windows固有の機能をフルに使いやすいVCLライブラリとクロスプラットフォームのFireMonkey(FMX)の二つを用意。
  11. 一応はクロスプラットフォーム対応。(Windows、Mac OS X、iOS、Android)
  12. (総合的判断ではQtのほうがいいような気がしています。)
  13. 日本語版がある。
  14. 日本語メニュー、日本語ヘルプ、日本語ドキュメント、日本語ホームページ、日本語サポートなど。

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がインストールされていない動かないことです。
解析が簡単なので何もしないでソフトを配布した場合はソースを公開していることとほぼ同じです。
難読化はできるけども、逆コンパイルされるリスクは防げないので、ソース保護したいなら最初から使わないほうがいいと思います。
難読化ソフトのDotfuscatorを別途買えば基本パッケージだけで1,050,000円。(百五万円)
クロスプラットフォーム性には疑問があります。
Javaとは違い基本はWindowsに強く依存しています。
monoとかXamarinとかありますけども、WindowsでのC#とその他のOSでのC#との互換性については懐疑的になったほうがいいと思います。


別のC++コンパイラとQtではだめなのか?
Qtのほうが良い場合もあります。ケースバイケースです。
Qtは高機能ですしクロスプラットフォームに強いです。
C++ Builderも昔のVer 6ではCLXというQtベースのクロスプラットフォームのGUIライブラリを持っていました。
  1. 難しい。敷居が高い。
  2. ちょっと難しいかな。
    壁を乗り越えられれば特に難しく感じないし良いものだとは思います。
    C++ Builderや、Visual StudioでC#をするみたいな感じですんなり入れないと思う。
    難しい簡単は主観だと思いますが、C++ Builderとはタイプが違うのは事実です。
  3. ビジュアルプログラミングの能力
  4. Qt Creatorでは、C++ Builderに勝てない。
    開発効率、生産性は、C++ Builderのほうが上だと思う。
    Qt Creatorはイベントにあまり連動していないんですよね。
    イベントとの連動が強化されていないビジュアル画面設計というのは邪魔かもしれない。
    Qt Creatorを使わないで作ったほうがよほど簡単なような気も。
    情報もサンプルプログラムもQt Creatorを使わないものばかりというのもQt Creatorが使えない大きな理由のひとつです。
  5. Windowsに特化したGUIライブラリがない
  6. C++ BuilderにはクロスプラットフォームのGUIライブラリとは別にWindowsに特化したGUIライブラリのVCLがありますがそれに相当するものはQtにはありません。
    QtはクロスプラットフォームのGUIライブラリです。
    クロスプラットフォームは大きな利点ですが、Windows固有の機能を使うのに制限ができたり、難しくなる場合があります。
  7. LGPLライセンスによる縛り
  8. 年間3540ドル(1ドル104円換算で36万8160円)の商用ライセンス料金を払いたくないならLGPLというオープンライセンスの一種になります。
    昔はGPLだったので制限はかなり緩和されていますが、それでもやはり使いにくいライセンスになります。
    LGPLのライブラリを使用した場合のソース公開は必須ではないのですが、制限がありライセンス違反にならないように気をつかう必要があります。
    年間3540ドルの商用ライセンス料金を払ってもC++コンパイラの商用ライセンスは付いてこない。
  9. C++コンパイラは別
  10. 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++コンパイラはセットにしてくれたほうが分かりやすいです。
  11. 日本語での公式情報なし
  12. 公式ドキュメントとか公式ホームページとかは全て英語です。
    英語とにらめっこすることは避けられないと思う。
    最悪は翻訳ソフトにかければいいし、高度な英語能力は必要ないと思いますが日本語の情報はあるにこしたことはないです。
    Qtの敷居を高くしてしまっている一因でもあります。

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いいと思います。
ただJava VMの言語にC/C++を選べないのが非常に残念です。
C言語標準ライブラリもC++標準ライブラリもデフォルトで使えないというのはかなり厳しい制限になります。
GUIライブラリは高機能。
デスクトップOS間のクロスプラットフォームに強いです。
C#と違ってWindowsに依存した機能がなくGUIの部分も各デスクトップOS間で互換があります。
Windows以外のデスクトップOS用のソウトウェアをバイナリで配布する場合に向いています。
一度コンパイルすればそのバイナリをOSを超えてディストリを超えて配布できるのは魅力です。
各OSや各ディストリごとに開発環境を構築するとか各OS各ディストリごとにコンパイルする必要はないです。
OSがバージョンアップしても再コンパイル無しで同じバイナリが動きます。
特にディストリが乱立するGNU/Linux向けのソフトを個人が配布するのに効果があると思う。
Windowsだけで動けばいいプログラムを作る場合は欠点のほうが目立ちます。
JREのインストールが必要とか、起動が遅い、動作が遅いとなるとユーザーには敬遠されやすい。
C#と同じように解析が簡単なので何もしないでソフトを配布した場合はソースを公開していることとほぼ同じです。
難読化はできますがほとんど効果ない難読化ソフトも多いです。
Java VMで動く言語にC/C++が含まれていないので別の開発環境間とのプログラム移植が困難です。


Gtk+またはwxWidgetsではだめなのか?
使いこなせるならいいんじゃないでしょうか。
RADは使えないでしょう。
あまり高機能じゃないというイメージですがどうなんでしょうか。
Gtk+はUNIXライクOSでは普及していますがライバルのQtのほうがGtk+より機能が上なのは事実だと思います。
あとはC++ Builderと比較すると、LGPLという面倒くさいライセンスと付き合う必要が出ます。


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 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言語の話


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