メモリモデル？なにそれ？おいしいの？ - yohhoyの日記（別館）
この記事はC++ Advent Calendar 2014の21日目にエントリしています。 内容はC++メモリモデルと逐次一貫性についての概説記事となっています。 flickr / nomadic_lass もくじ 忙しい人のための「C++メモリモデル」 C++メモリモデル一問一答 ソフトウェアからみた「C++メモリモデル」 “メモリ”という共有リソース C++ソースコードが実行されるまで メモリの一貫性と整合性 逐次一貫性モデル is Easy ハードウェアからみた「C++メモリモデル」 ハードウェア・メモリ一貫性モデル C++コンパイラの責任と自由 強いメモリモデル vs. 弱いメモリモデル 逐次一貫性モデル is Hard （本文のみ約9600字） まえがき When your hammer is C++, everything begins to look like a thumb
DCL13-C. 関数の引数が関数自身によって変更されない値を参照するポインタならば、関数の引数をconstとして宣言する
HOME公開資料を見るDCL13-C. 関数の引数が関数自身によって変更されない値を参照するポインタならば、関数の引数をconstとして宣言する DCL13-C. 関数の引数が関数自身によって変更されない値を参照するポインタならば、関数の引数をconstとして宣言する 関数の引数を const として宣言すると、その関数が引数の値を変更しないことを約束するということを意味する。 C 言語では、関数の引数は参照ではなく値として渡される。関数は渡された値を変更するかもしれないが、これらの値は、ひとたび関数が呼び出し元に戻ると破棄される。そのため、多くのプログラマは、関数はその引数を変更せず、関数の引数を const として宣言する必要はないと考えがちである。 void foo(int x) { x = 3; /* 関数が exit するまで有効 */ /* ... */ } ポインタも同様の動
Use C++ with Cocoa Instead of Objective-C?
You cannot write a Cocoa application entirely in C++. Cocoa relies heavily on the late binding capabilities of Objective-C for many of its core technologies such as Key-Value Bindings, delegates (Cocoa style), and the target-action pattern. The late binding requirements make it very difficult to implement the Cocoa API in a compile-time bound, typed language like C++ⁱ. You can, of course, write a
静的ライブラリのリンク時にundefined referenceエラーが出る(gcc)
静的ライブラリのリンク時にundefined referenceエラーが出る(gcc) 概要 gccでリンク時にundefined referenceエラーが出る場合がある。 通常はオブジェクトやライブラリの指定忘れが原因であるが、 静的ライブラリをリンクする順番に間違いがあって出る場合もある (自分でMakefileを書く場合にこのミスをすることが多い) リンクの順番には依存性があり、あるオブジェクトが静的 ライブラリ内の関数を呼び出すときには呼び出される側の ライブラリは「後で」リンクする必要がある。 例えば foo.o が静的ライブラリ libfoo.a 内の関数を使用している、つまり foo.o → libfoo.a という依存関係があるとき、 g++ -o foo libfoo.a foo.o とするとundefined referenceエラーが出る。従って g++ -o fo
Cling
What is Cling Cling is an interactive C++ interpreter, built on the top of LLVM and Clang libraries. Its advantages over the standard interpreters are that it has command line prompt and uses just-in-time (JIT) compiler for compilation. Many of the developers (e.g. Mono in their project called CSharpRepl) of such kind of software applications name them interactive compilers. One of Cling’s main go
江添亮のC++入門
序 本書はプログラミングの経験はあるがC++は知らない読者を対象にしたC++を学ぶための本である。本書はすでに学んだことのみを使って次の知識を説明する手法で書かれた。C++コンパイラーをC++で書く場合、C++コンパイラーのソースコードをコンパイルする最初のC++コンパイラーをどうするかというブートストラップ問題がある。本書はいわばC++における知識のブートストラップを目指した本だ。これにより読者は本を先頭から読んでいけば、まだ学んでいない概念が突如として無説明のまま使われて混乱することなく読み進むことができるだろう。 C++知識のブートストラップを意識した入門書の執筆はなかなかに難しかった。ある機能Xを教えたいが、そのためには機能Yを知っていなければならず、機能Yを理解するためには機能Zの理解が必要といった具合に、C++の機能の依存関係の解決をしなければならなかったからだ。著者自身も苦し
インクルードガードとpragma once - にゃははー
C++ Advent Calendar 2015の5日目です。 前C++時代から近代C++に至るまで、ヘッダファイルの重複インクルード排除のために通称インクルードガードというものが使われてきました。 #ifndef YOUR_VERY_VERY_AWESOME_LIBRARY_HEADER_H #define YOUR_VERY_VERY_AWESOME_LlBRARY_HEADER_H #endif // YOUR_VERY_VERY_AWESOME_LIBRARY_HEADER_H しかしこれはファイルの前後に書かないといけないという制約や、他のヘッダとトークン列が一致してしまうと意図せずヘッダがインクルードされないという問題がありました。 これに対してたった1行で書いて終わりの#pragma onceは、標準化を求める声も多く、目的が明確で、実装もあるにも関わらず、標準に入る気配すら
extern "C"の意味
extern "C"の意味について調べてみました。 １．はじめに CプログラムからC++の関数を起動することを確認するため、下記のサンプルを作りました。 foo.h class Foo { private: int number; public: Foo(int num); int print(void); }; void construct(); void foo_print(); void destruct(); foo.cpp #include "foo.h" #include <iostream> Foo::Foo(int num) { number = num; } int Foo::print(void) { std::cout << number << '\n'; } Foo *foo; void construct() { foo = new Foo(100) ; } vo
register指定子
１．register指定子 C言語の関数では仮引数やローカル変数は通常、主記憶上のスタックエリアに割り当てられる。 コンピュータにはメインメモリやキャッシュメモリよりももっと 高速にアクセスできるレジスタと呼ばれるメモリがある[1]。 register指定子は仮引数やローカル変数をなるべくレジスタに割り当てるように指定するものである。 レジスタの数には限りがあるため、レジスタに割り当てられない場合もある。 コンパイラによっては、register指定子を無視するコンパイラもある。 レジスタには名前が付けられており、メインメモリのようにアドレスがあるわけではない。 したがって、レジスタ変数(register指定子を付けた変数)のアドレスを求めることはできない。 例えば、 register int n; のように宣言した場合、int *p = &n; のようなプログラムは書けなくなる。 ２．使用
引数をとらない関数の仮引数にvoidを書くべきか、書かざるべきか？ - 新・日々録 by TRASH BOX@Eel
本エントリ名のような質問にたいする回答をよく忘れてしまうので、ここにメモしておく。 仮引数にvoidを書く／書かないについては、C言語とC++で言語仕様での扱いが異なる。C言語の場合は、関数の宣言か定義かによっても差異がある。 この違いを表にするとこんな感じ。 言語 宣言／定義 f(void) f() C言語 関数宣言 引数なし（ANSI Cのプロトタイプ宣言） 任意の個数の引数（K&Rの頃の伝統的な宣言） C言語 関数定義 引数なし（ANSI Cの関数定義） 引数なし（K&Rの頃の伝統的な関数定義） C++ 関数宣言 引数なし（プロトタイプ宣言） 引数なし（プロトタイプ宣言） C++ 関数定義 引数なし（関数定義） 引数なし（関数定義） C言語のみを使う場合 ANSI Cでコードを書いているならば、引数をとらない関数の仮引数にvoidを書くべきだ。 関数の宣言・定義ともに、仮引数にvoi
CentOS 7 でblas(cblas)を使う方法 - コンピュータ将棋 Qhapaq
CentOS(wiki)はそのサポート期間の長さから、企業や大学のサーバによく用いられるOSです。 CentOSはパッケージ一つ入れるだけでも検索戦争に耐えねばなりません。というのも、シェアが少ない故に情報に乏しいことに加え、tensorflowなどの近代的なパッケージはubuntuでの利用を想定していることが多いからです。故にCentOSを個人が使う理由はないと思っているのですが、残念ながら上の人間（組織）からCentOSを使うことを強いられるシーンは多々あります。 以下のシンプルなcblasのc++用のサンプルコード(sample.cpp)を動かすことを考えましょう。 因みに筆者はこれで3時間ぐらいを溝に捨てました。 #include <cblas.h> #include <stdio.h> // based on https://github.com/xianyi/OpenBLAS/
Visual StudioユーザーがReleaseビルドをするときに必ずやってほしい2つの設定 - Qiita
はじめに 前からちょくちょく見受けられたけれども、やはりやってしまう人は多いようなので 自戒の念と共にここに記しておきます。 ソフトウェアをDLして解凍またはセットアップしたexeのところに、appname.vshost.exeとかappname.pdbとか見かけたことはありませんか？ これらはVisual Studioでビルドする際に、Debugビルドでは非常に有効なファイルですが、Releaseビルドでは不要なファイル達だったりします。 なので、必ず下記の２つの設定をReleaseビルド構成に施しておきましょう。 1. ホスティングプロセスを無効にすること これはあまり見かけなくなったけど、やはりやってしまう人はいるようです。 プロジェクトのプロパティでデバッグページにある Visual Studio ホスティング プロセスを有効にする（O） のチェックを外して Visual Stud
C言語のバグ回避をするための習慣 - Qiita
概要 C言語でコーディングする上で気をつけている点などをまとめて見ました。 但し、書き方は人それぞれなので違和感を覚える人もいるかもしれませんが、 もし間違っている点がありましたらご指摘お願い致します。 目的 C言語について文法はある程度理解はしたが、その先がわからない。 という人向けにこんな感じでコーディングすればバグが減るかも。 という指針的なものを提供したかったです。 条件判定時の習慣 基本的にはテストを行う部分ではありますが、急いでいたりすると 意外な盲点に気付かずにそのままスルーしてしまう事がよくあります。 多少面倒かもしれませんがちょっと書き方を工夫する事でミスを事前に回避できます。 変数の位置 条件判定の時、変数を左に書きたくなります。皆さんその方が理解しやすいと思います。 でも以下の書き方はやらない方が良いです。 何故ならうっかりミスで==を=にしてしまった時に気付かない可
MALLOC
時事ネタ いや、「今、fj.comp.lang.cが熱い!」という話は ちょっと前から聞き及んではいたのですが、 流量が尋常じゃないらしいので、 忙しさもあって読むのを控えていたんですけど、 先日、大筋を拾い読みしてみました。 確かに熱いですねえ。 いったん収束するかなあ、と思ったら、なんかまた泥沼の気配が(^^; fjを読んでない人のために説明すると(って、 私も普段はあんまり読んでないんですが)、 「malloc()で確保した領域は、必ずfree()で解放しなきゃいけないか?」という 話題でして、「exit()する時には、OSが解放してくれるんだから 別にfree()しなくてもいいじゃん」という主張と、 「いや、malloc()には常に対になるfree()があるべきだ」という主張があって、 議論を呼んでいたのでした。 んで、私がどう思うかなんですが、 私は面倒臭がりなので、free()
ポインタ型記法のススメ ─ int* p; int *p; 空白をどちらに挿入するか | MaryCore
C言語におけるポインタ変数の書き方には複数の記法あります。 char* p = "s"; // ① charポインタ型の変数p char *p = "s"; // ② char型のポインタ変数p 書き方や言い方が違うだけでいずれも全く同じ意味で同じ動作をします。 私自身はポインターの前にスペースを挿入する②char *p、いわゆるポインタ変数記法を支持していますが、最近は①char* pのポインタ型風の記法も悪くないと思うようになりました。そこで今一度ポインタ型記法の有効性を検証してみましょう。 ただし本来、ポインタは変数に対して与えられる概念であるため、アスタリスクは型側ではなく変数側に寄せるのが自然です。 目次 ポインタ型記法のメリット ポインタ型記法のデメリット そもそもポインタ型記法を使ってる人はいるのか 有名プロジェクトでの使用例 ポインタ型記法のメリット 文字数の削減ができる
fflush
バッファのフラッシュを行う 【書式】 #include <stdio.h> int fflush(FILE *fp); 【説明】 バッファに格納されているデータを吐き出します。 例えば、scanf関数で"%c"変換指示子を指定した場合には、すでに標準入力がある場合には、入力バッファに残っている'\n'を処理するため、正常な入力が行われません（「５－４．scanf（）関数の注意事項」を参照のこと）。このような場合には、fflush(stdin); を実行し、標準入力のバッファフラッシュを行います。（ただし、入力バッファのフラッシュは一般的には未定義です。LSIC-86のようにユーザーズマニュアルに記されている場合のみ使用すべきでしょう。各自確認してください。） また、setbuf関数でユーザバッファを出力バッファに設定した場合などにも、このfflush関数を用いてバッファフラッシュを行わせる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Undefined, unspecified and implementation-defined behavior
Keeping the Console Window Open in Visual Studio 2017 by Ken Gregg at Bytellect LLC
What does "static" mean in C?
C/C++ 危険な書き方について
