これは、 C++ でコンパイル時に出力まで済ませようとした話です。 コンパイラは GCC に限ります。 はじめに もうすぐクリスマスですね! クリスマスにすることといえば……、 そう、コンパイル時処理ですね!! コンパイル時処理 C++ のコンパイル時処理は非常に強力で、様々なことがコンパイル時にできてしまいます。 普通はコンパイル時に決まる定数の計算に使われますが、これを悪用利用してコンパイル時に処理がすべて終わるようなものも書くことができます。 例として、コンパイル時 FizzBuzz を書いてみます。 #include <array> #include <string_view> #include <algorithm> #include <concepts> #include <iostream> template <std::unsigned_integral T> conste
def check(n) s = "*"*n f = open("test.cpp","w") f.puts <<EOS #include <cstdio> int main(){ (#{s}printf)("Hello World\\n"); } EOS f.close() return system("clang++ test.cpp") end check(ARGV[0].to_i) $ ruby check.rb 10000 clang: error: unable to execute command: Illegal instruction: 4 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 10.0.1 (clang
OpenCVをVagrant + Chef + CentOS6.5の開発環境にインストールするのに結構なハマり所が多かったので、メモしておきます。 OpenCVをインストールするレシピ 以下がopencvをインストールするためのレシピです。 for_opencv_pkgs = %w( gcc gtk+extra gtk+extra-devel pkgconfig python python-devel numpy libavc1394 libavc1394-devel libdc1394 libdc1394-devel libjpeg-turbo libjpeg-turbo-devel libpng libpng-devel sqlite-devel ) for_opencv_pkgs.each do |pkg| package pkg do action :install end end
CERNが2つのチャームクォークを含む新物質「Ξcc++」を発見したとEPS会議で発表しました。これまで存在が予想されていた「2つの重いクォークを持つバリオン」が初めて発見された例です。 Observation of the doubly charmed baryon Xicc++ - lhcb_paper_2017.07.06.pdf (PDFファイル)http://press.web.cern.ch/sites/press.web.cern.ch/files/file/press/2017/07/lhcb_paper_2017.07.06.pdf LHCb announces a charming new particle | CERN https://home.cern/about/updates/2017/07/lhcb-announces-charming-new-particl
目的 #ifdefが複雑にネストしているCソースファイル中で、どの部分が有効かを簡単に調べたい。 背景と動機については id:taiyo:20080202#p1 などを参照。 結果 C FAQ(Question 10.18)で紹介されている3つのツールと、手元にあったツール1つを試した。 名前 処理可能なディレクティブ 処理方法 感想 rmifdef #ifdef, #ifndef, #else 不明(バイナリ配布) 判定対象が狭く、あまり使い出がない unifdef #ifdef, #ifndef, #else 独自の文字列処理 出力エラーでソースが乱れるのが致命的 scpp 全ディレクティブ lex&yac マクロ展開までされるのと、#if 0を処理しないのがやっかい pcpp 全ディレクティブ 不明(バイナリしか持ってない) 不都合は今のところみつからず pcppが、機能面では不満が
何の変哲もないHelloWorld。 #include <iostream> int main() { std::cout << "Hello, おにいちゃん!!" << std::endl; return 0; }こいつをclangをつかってコンパイル。 # clang -xc++ hello.cpp /tmp/cc-x0SPbV.o: In function `__cxx_global_var_init': hello.cpp:(.text+0xc): undefined reference to `std::ios_base::Init::~Init()' hello.cpp:(.text+0x30): undefined reference to `std::ios_base::Init::Init()' /tmp/cc-x0SPbV.o: In function `main':
STLFilt: An STL Error Message Decryptor for C++ Open Source Freeware by Leor Zolman, Supporting: Comeau C++ gcc 2.95.x/3.x/4.x (Dev-C++ compatible) MSVC++ 6/7/8/9 (incl. Dinkum Libraries) Metrowerks CodeWarrior Pro 7/8 Borland C++ / C++Builder Intel C++ 7/8 EDG Front End (Generic) Digital Mars C++ Please Note: Active Development on STLFilt has ended. The author sincerely hopes the C++ Standards Co
わざわざ独自定義する以上は、__nullはポインター長の独自の型として振る舞い、int型への代入でエラーになることが期待されるところである。しかし、そのように動くかどうかは、環境による。 32ビット環境では、現実には(int)0と同じ扱いである。 次のコードはエラーにならない。 int i = __null; そして、typeid(__null).name()で__nullの型を調べると、「int」と出力される。32ビット環境では、__nullはint型なのである。 __nullが存在するのは、64ビット環境への対応のためである。64ビット環境では、NULLと0は同一とは限らない。 #include <iostream> int main() { std::cout << "sizeof(NULL) : " << sizeof(NULL) << std::endl; std::cout <
こいつにずいぶんと悩まされたのでついカッとなって記事に "ISO C++ forbids declaration of 'class name' with no type"とは ISO C++は型のない変数の宣言を禁止しているぞと。いう意味になります。 例えば、 auto x = 0; // Error intなど型の指定のない宣言でこのエラーは出ます。。。 それと、コンパイラ(g++?)は理解できない構文要素を無いものとして読むので指定した型(クラス)が本当にスコープ上にあるかもポイントです。 このエラーが出る型はポインタとして使われている場合が多いようです。 (このときアスタリスクをはずすと、ちゃんと見つからない旨のエラーを吐いてくれます。) 同様の理由でテンプレートクラスなどでこのエラーが出る場合は typenameキーワード を使って解決する場合もあるようです。各自ググられたし。。
C++0x で提案されているユーザー定義のリテラルを使用すると以下のようなことができるようになる "Hello"s // std::string 101011100011b // binary literals 123km // unit is kilometers リテラルを定義するには、以下のような演算子を定義する X operator""suffix(const char*); X x = 1234suffix; // operator"suffix"("1234"); この場合、operator""suffixの引数は NULL 終端の文字列となる Variadic Templates を併用すると、リテラルを char 型の コンパイル時定数とすることができる template <char...> X operator""suffix(); X x = 1234suffix; /
gccとVC x86/x64環境で開発する上で, gccとVCはどちらも非常に優れたC/C++コンパイラです. ただLinuxとWindowsのどちらの環境でも動作するようなC/C++コードを書くためには, gccとVC, およびそれらが動作するOSの違いが問題になることがあります. ここではそれらの違いについてまとめていきたいと思います. なお説明を簡単にするためにマクロを多用していますが実際には可能なら別の手段をとるか, 名前がぶつからないような命名規則に則ったマクロ名をつけることをお薦めします. 対象 定義済みマクロ 有用なマクロ コンパイルオプション 演算子の代替表現の抑制 日本語のコメント 型 pragma attributeとdeclspec ファイル入出力 テキストとバイナリ 巨大なファイル static変数の初期化 snprintf 例外ハンドラ intrinsic関数
古来より、関数スコープの静的なオブジェクトを作るのは危険 void foo() { static CBar bar; // こんなの とされています。foo()が初めて呼ばれたタイミングでbarのコンストラクタが走るわけですが(C++規格でそう決まっている)、foo()の初回呼び出しが2つのスレッドでほぼ同時に行われると、barのコンストラクタが複数回走ってしまったりと、不可解な動作をすることが知られています。 参考サイト: http://blogs.msdn.com/oldnewthing/archive/2004/03/08/85901.aspx (引用するの何度目だろ) ところが、最近のg++には -fthreadsafe-statics っていうオプションがあって、この初回のコンストラクタ呼びをスレッドセーフに行ってくれるようになりました。手元のgcc3.4.3ではデフォルトでon
あったあった. When you link a multithreaded application, you will probably need to add a library or flag to g++. This is a very non-standardized area of GCC across ports. Some ports support a special flag (the spelling isn't even standardized yet) to add all required macros to a compilation (if any such flags are required then you must provide the flag for all compilations not just linking) and link-lib
Boostは便利だけど、ちょっと使っただけでビルド時間が一気に長くなってしまうので、何とかならないか調べてみた。 まず、最近のgccではプリコンパイル済みヘッダ(PCH)が使えるらしい。しかし、ヘッダをプリコンパイルしたときのオプションが本番のコンパイル時と違う場合、プリコンパイル済みヘッダは利用されない可能性が高いとのこと(http://d.hatena.ne.jp/rero/20080609/p1)。リリース時のみ使うか、VCで言うところのstdafx.hのようにプロジェクトごとのプリコンパイル済みヘッダを用意する、ということになりそう。 次に、以前から名前は知っていたccacheを見つけた。(本家、windows版) これはヘッダをプリプロセスした結果をキャッシュするツールで、使い方は単に $ ccache gcc foo.c とすれば二度目からコンパイルを高速化してくれる。 こっち
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く