You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

enumで宣言した列挙定数を文字列に変換したいときのためのプチテクニック。 なお逆に、文字列を列挙定数に変換したいときはこちら→文字列を対応する列挙定数(enum)に変換する【C++】 defineマクロの#演算子（文字列化演算子）は、マクロの引数を見たままの文字列リテラルに置き換えてくれるのでこれを利用することで簡単に実装が可能です。 #include <stdio.h> #define STR(var) #var //引数にした変数を変数名を示す文字列リテラルとして返すマクロ関数 int main() { enum color_tag{ RED, BLUE, GREEN }; printf("%s : %d\n", STR(RED), RED); printf("%s : %d\n", STR(BLUE), BLUE); printf("%s : %d\n", STR(GREEN),

公開が遅れましたが 初心者 C++er Advent Calendar 2015 の 12日目の記事です。 C++ の良い点として、 clang-format のようなフォーマッタがある点だと思っています。 golang でも gofmt というフォーマッタがありますが、あんなかんじのやつです。 clang-format を使うことで、C/C++/Objective-C/Java/JavaScript/ProtocolBuffer などのコードフォーマッティングができます。 また、フォーマットの設定ををいろいろ変更でき、チームで設定を共有することで、 統一されたコードスタイルを実現することが可能です。 id:rhysd さんの vim-clang-format をvimに導入することで vimからも使えます。 github.com ClangFormatスタイルオプション - Algo13

(前編はこちら： 2016年、C言語はどう書くべきか (前編) ) (編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) システム依存の型 まだ「32 bitのプラットフォームでは32 bitのlong型、64 bitのプラットフォームでは64 bitのlong型がいい」という不満があるようですね。 プラットフォームに依存する2つの異なるサイズを使うため、 故意に コードを難しくすることを考えたくなければ、システム依存の型のために long を使おうとは思わないでしょう。 この状況では、プラットフォームのためにポインタ値を保持する整数型、 intptr_t を使うべきです。 モダン32-bitプラットフォームでは、 intptr_t は int32_t です。 モダン64-bitプラットフォームでは、 intptr_t は int64_t です。 int

最近、仕事でC言語での組み込み系の開発に携わっています。 開発中のコードを眺めていると、ヘッダファイル内にstatic関数のプロトタイプ宣言を記述していたり、ヘッダファイル内で不必要に他のヘッダファイルをインクルードしているなど、ヘッダファイルの書き方が分かっていないと思われる箇所が多々見られました。 実際、C言語の入門書でもヘッダファイルの書き方を詳しく説明しているものは、僕の知っている限りでは存在しないので、C言語を使っていてもヘッダファイルの正しい書き方を知らない人が少なくないのではないかと思われます。 そこで、このエントリでは、C言語のヘッダファイルの書き方について、僕が知っているテクニックをまとめてみました。 インクルードガードを書く ヘッダファイルファイルで他のヘッダファイルをインクルードしていると、いつの間にか同じヘッダファイルを2回インクルードしてしまうことがあります。 例

Insecure Interaction Between Components（6 errors） ソフトウェアコンポーネント間のセキュアでないやりとり SQLインジェクションやクロスサイトスクリプティング（XSS）のような類の脆弱性 Porous Defenses（11 errors） 不完全な防御策 認証関連の不備や暗号化機能の不適切な使い方など Risky Resource Management（8 errors） リソース管理の問題 バッファオーバーフローや整数オーバーフロー、書式指定文字列の脆弱性など 1つ目に分類されているSQLインジェクションやXSS（クロスサイトスクリプティング）などは、やりとりされる情報の意味がコンポーネント間で変わることから問題が発生するパターンです。 例えば、入力データからSQL文を組み立てるコンポーネント、そのSQL文を受け取ってデータベースから必要

現在、C言語でマイクロマウスの開発をしているプログラミング初心者(@morikentiger)が、プログラミングの作法(とくに変数の扱い)について教えを請う。構造化プログラミング、変数のスコープ(有効範囲)や記憶域期間(staticだと永久に保持されるなど)について。

Cコンパイラといえばとてつもなく複雑なプログラムというイメージがあります。ところが、このCコンパイラを(サブセットとはいえ)わずか500行ほどのCのソースコードで実現した「CC500」名付けられたプログラムが公開されています。 ソースコードは可読性を維持するためにつけられた空行やコメントを含めると、実際は750行ほどになるそうですが、それでもこれだけコンパクトなソースコードで実行可能なELFバイナリ(Linux用のバイナリ)を生成できるのは興味深いのではないでしょうか。 以下実際にLinuxでコンパイルしてみました。 自己コンパイルできる このコンパイラはC言語のサブセットで、自分自身のソースコードをコンパイルできるところがおもしろいところです。まず「cc500_1」という実行ファイルを生成します。 gcc cc500.c -o cc500_1 生成された実行ファイル「cc500_1」を使

はじめまして。サーバサイドエンジニアの @DQNEO です。 今日はGitのつくりかたをご紹介します。 C言語学習教材としてのGit Gitと同じものをゼロから作って何の意味があるのか？と思いますよね。 私がこの再発明をやり始めた動機は「C言語を書けるようになりたい」でした。 実際に途中までやってみたところ、 C言語がチョットデキるようになった Gitの内部構造に詳しくなった というメリットが得られました。 C言語を勉強する題材は、テトリスとかWebサーバとか他にいくらでもあるのですが、Gitを実装してみるのはかなりおすすめです。理由は下記の通りです。 内部構造が意外と単純 (ローカルで動かす分には)ネットワークの知識が不要 普段使っているツールで外部仕様がわかっているので、やるべきことが明確 余談ですが、本家Gitのソースコードを参考にしようと思って読んでいたら、Linus Tovals

以前に8ccというCコンパイラをゼロからひとりで開発していたときのログです。40日でセルフコンパイルできるところまで到達しています。日付はすべて2012年です。コードとヒストリはすべてGitHubで見れます。 3月4日 というわけでコンパイラを作っているわけだけど、1000行くらい書いたらそれなりに動き始めてきた。こんなのも動くし： int a = 1; a + 2; // => 3 こういうのも通る。 int a = 61; int *b = &a; *b; // => 61 文字列は文字の配列として扱っていて、配列をポインタに成り下げる振る舞いも実装しているので、こういうのも通る。関数呼び出しもある。 char *c= "ab" + 1; printf("%c", *c); // => b 前回もこのあたりはがんばって実装したからここまで作るのはわりと単純作業かも。二回目だから配列とか

問．Cでオブジェクト指向プログラミングを行なえ。ただし「オブジェクト指向プログラミング」とは、次のような特徴を持つプログラミング技法であるものとする： オブジェクトの実装はオブジェクトのユーザーからは隠蔽される（カプセル化／隠蔽） 同一型のオブジェクトと同一メソッドを与えた時、実際のメソッドの動作はオブジェクトの内容により変化する（ポリモーフィズム／多態性） なお、ユーザーが既存のオブジェクトをカスタマイズして新たなオブジェクトを作成する機能は、必要ないものとする。 この問いの狙い よく、「オブジェクト指向プログラミング」と「オブジェクト指向言語」は混同されます。が、前者はプログラムを設計する上での考え方で、後者はその考え方を容易にソースコードに書けるような仕様になっている言語の事で、全く違うものを指しています。 その証拠を示すため、「非オブジェクト指向言語」たるC言語で「オブジェクト指向

バッチのまとめTOPへ 「コードの読みやすさ」は，非常に重要だ。 ソースコードが読みづらくなると，コードが「仕様を表現」しなくなる。 簡単にバグが混入され，埋もれてしまう。それに気付きもしなくなる。 保守や改良ができなくなる。 プロジェクトが行き詰まる。 デスマーチが始まる。 ・・・ 逆に，「読みやすいコード」でさえあれば， どれほど多くのバグが混入しているとしても，容易にすばやく修正できる。 保守性が高いのである。 「読みやすいコード」は「仕様を明快に表現しているコード」なので， 他の人が読んだ時，仕様の誤解が起こらない。手をつけやすい。 「把握しやすいコード」は「変更しやすいコード」なので，プロジェクトがどんどん前に進む。 でも，それを確保するにはどうしたらよいのか？ 「コードの読みやすさ」を確保するには どうしたらよいか ひとつの方法 補足 「コードの読みやすさ」を確保するには 上級

はじめに 僕がプログラミングを始めてから、もうすぐ12年になろうとしています。 この12年間、いろんな技術書を読んだり、仕事やプライベートでたくさんコードを書いたりしてきました。 最初に入ったSIerでは主にJavaを、前職の社内SE時代はC#をメインのプログラミング言語として使ってきました。 現在はRubyをメインで使っていますが、言語が変わっても、また何年経っても「これはあのとき学んだ知識が役に立ってるよなあ」と思う瞬間がときどきあります。 そこで今回はこれまでに読んだ技術書を一通り振り返り、「この本で学んだことは今でも役に立ってる」と思うものを17冊ピックアップしていきます。 おことわり (2014.09.29 20:00追記) このエントリのタイトルは「10年経った今でも役に立っている」という意味で付けています。「今から10年後まで役立つ」という意味ではありません。（紛らわしくてご