はじめに
第1章 概要
第2章 コマンドラインでC言語ライブラリを作る
第3章 MakefileでC言語ライブラリを作る
第4章 ライブラリに関するTips
第5章 C++でライブラリを作る
第6章 Qtでライブラリを作る
本書を手に取っていただき、ありがとうございます。
本書は、C/C++のライブラリを作ったり、使ったりするためのノウハウを詰め込んだ技術書です。あいまいになりがちなライブラリの種類の区別を、サンプルコードを元にはっきり区別できるよう説明していきます。インターネット上には、ライブラリに関する多くの情報がありますが、開発環境はOSごとに個別の情報しか載っていないことが多く、横断的に扱う情報はなかなか見つかりません。そこで本書では、Cygwin(Windows10)、MinGW(Windows10)、Ubuntu(Linux)、macOSの4つの開発環境を横断的に扱うアプローチをしています。
扱うプログラミング言語はC言語とC++(C++11)です。といっても、ほとんどプログラムの知識がなくても、Hello Worldレベルの知識があれば読むことができます。コンパイラはGCCのみを扱います。同じGCCを使用しているのに、環境によってどのような差分があるのか、そのあたりを説明していきます。開発環境は基本的に、GCCコンパイラとテキストエディターがあれば動作できます。最後の章に、クロスプラットフォームな統合開発環境のQt(キュート)も扱います。
本書を読んで、少しでも、ライブラリを作ることに興味を持っていただければ幸いです。
本書のサンプルコードは、GitHubに登録してあります。GitHubにはサンプルコードだけなく、本書に関する動作環境や誤植などの情報も上げていきます。参考にしてみてください。
サンプル > ch01 > HelloWorld
は、サンプルコードの場所が
[サンプルコードのトップディレクトリーのパス]/ch01/HelloWorld
にあることを示しています。「サンプル」というディレクトリーがあるわけではありません。
・本書は、著者が独自に調査した結果を出版したものです。
・できるだけ自分の開発環境で動作検証し、ソースコード自身を確認し、万全を期して作成したつもりですが、ご不明な点なども出てくるかと思います。その場合、Twitterで「@argama147」に対してメッセージを送っていただくか、GitHubのIssueにコメントいただければ、何らかのフォローができるかもしれません。ただし、ものぐさな筆者のため、回答が返せない場合もあるかと思いますので、その点はご承知ください。
・本書の内容に関して、なんらかの保証をするものではなく、内容やサンプルプログラムにもとづくいかなる運用結果に関しても、いっさいの責任を負いませんし、負えません。
・本書に記載されたURLやソフトウェアの内容は、将来予告なく変更される場合があります。
本文に登場する社名、システム名、商品名はそれぞれ、各社の商標および登録商標です。本文中における商標マークは省略しています。
本書を商業化する機会をいただいた、インプレスR&D山城様に感謝します。ファンタジーの図書館を表紙のテーマにするというリクエストに、見事に応えていただいたイラストレーターのはる様に感謝します。技術的なアドバイスをしていただいた、日本Qtユーザー会会長の鈴木様に感謝します。そして、本書を手にとってくれたあなたに感謝します。
筆者が動作確認した環境です。
・Cygwin
─OS:Windows10 Pro
─Version:3.1.4
・MinGW
─OS:Windows10 Pro
─Version:8.1.0
─Qtにバンドルされているものを使用
・Linux
─OS:Ubuntu
─OS Version:20.04.1LTS
・macOS
─OS:macOS Catalina
─OS Version:10.15.6
本章は、ライブラリの概要を説明します。
ライブラリとは、「ある特定の機能を持ったコンピュータープログラムを他のプログラムから呼び出して利用できるように部品化し、そのようなプログラム部品を複数集めて、ひとつのファイルに収納したもの」1です。ライブラリには、オブジェクトコード(機械語などで記述されたプログラム)が格納されていますが、それ単体で起動して実行することはできず、他の実行可能ファイルに連結されて利用されます。
そもそも、なぜプログラムをライブラリにする必要があるのでしょうか。開発経験のある方は、ソースコードをいちいちライブラリ化するのは面倒、というイメージをお持ちかもしれません。少し筆者の考えを述べたいと思います。
自分(自社)で、他者(他社)が持っていない機能を開発できたとしましょう。他者(他社)に、この機能をソースコードで提供してしまうと、仮に他者(他社)と秘密保持契約をしたとしても、自分(自社)が開発した機能(技術)を盗まれるリスクがあります。そこで、自分(自社)が開発した機能(ソースコード)をオブジェクト化し、他者(他社)から使用されるインターフェースをAPIという形で提供する。この形であれば、他者(他社)に自分(自社)の機能(技術)を盗まれるリスクが減ります。勿論ライブラリが「配布しやすい形」であることもメリットのひとつです。