タグ

2019年3月22日のブックマーク (9件)

  • SQLQL は GraphQL にとってなんなのか

    14. 少し複雑なクエリ 鍵付きユーザーの「いいね」について名前を 「匿名」にして出している WITH comments AS ( SELECT comments.id, content, users.name AS user_name, comments.created_at FROM comments JOIN users ON comments.user_id = users.id ), likes AS ( SELECT COALESCE(users.name, '匿名') AS user_name, likes.created_at, comment_id FROM likes LEFT OUTER JOIN users ON likes.user_id = users.id ) SELECT comments.id, content, comments.user_name ,

    SQLQL は GraphQL にとってなんなのか
  • C言語の正しいヘッダファイルの書き方 - saito’s blog

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

    C言語の正しいヘッダファイルの書き方 - saito’s blog
    mizdra
    mizdra 2019/03/22
  • clangd導入メモ - Qiita

    clangdとは clangのLanguage Server Protocol 実装。 LSPはMicrosoftが提唱しているIDE支援のための統一プロトコル。 Language "Server"とあるとおり、言語支援のためのサーバーが常駐する。この手の機構を個別に備えた言語として、TypeScriptのtsserverとか、C#のOmniSharpなどが挙げられるけど、それの汎用版。 clangdはLLVMのフロントであるclangをベースとしたサーバーで、LLVMプロジェクトが公式に開発している。 コンパイラなので、コンパイルエラーの検出はもちろん、コード補完やフォーマット、定義ジャンプと参照元ジャンプ等には対応している。 なので、clang-formatやRTagsといったclang系ツールも、LSPクライアントを導入してしまえば、これらの個別設定をしなくてよい。 clangdのイ

    clangd導入メモ - Qiita
  • Makeでヘッダファイルの依存関係に対応する - wagavulin's blog

    CやC++で書かれたプログラムをMakeを使ってビルドする、というのはUnix/Linuxではよく行われていることだが、ちゃんとしたMakefileを書くのは意外と難しい。 例えば以下の3つのファイルからなるプログラムを考える。 foo.h: 関数fooの宣言がある。 foo.c: 関数fooの実装がある。 main.c: 関数fooを呼び出す。 /* foo.h */ void foo(int a); /* foo.c */ #include "foo.h" #include <stdio.h> void foo(int a){ printf("%d\n", a); } /* main.c */ #include "foo.h" int main(int argc, char **argv){ foo(10); return 0; } Makefileは例えば以下のように書ける。 PRO

    Makeでヘッダファイルの依存関係に対応する - wagavulin's blog
  • シンプルで応用の効くmakefileとその解説 - URIN HACK

    makefileは一度作るとそれ以降編集する機会が少なくなるので意外と真面目に考える人は少なく、ネット上でもまとまった情報は多くない。 Linux系OS上(正確に言うとGNU MakeとGCC)で複数のC/C++ソースファイルから1つの実行ファイルを作成(make)するための汎用的なmakefileテンプレートを作った。名前はまだない。適宜ディレクトリ構成や設計などに従ってmakefileをカスタマイズする必要があると思うがそのベースにする。 このmakefileのいいところ コンパイル対象となるソースファイルをワイルドカードで指定できる。 ヘッダファイル、ライブラリ、オブジェクトファイルなどコンパイル、リンクに関連するどのファイルが外部で変更されていてもきちんと 差分 コンパイルされる。 makefile自体に説明書(この記事)がある。 makefile Gistはこちら。 COMPIL

  • Makefileで{単数, 複数}の{依存項目, ターゲット}の書き方 - Qiita

    Makefile で複数の依存項目 (prerequisite; 以降 prereq と表記) や複数のターゲット (target) を扱う場合のまとめ。複数の場合でも基的に単数と同様に書けるが、中身を個別に扱う (multiple [foreach] と表記) 場合にはまとめて扱う (multiple [bulk] と表記) 場合と異なる書き方をしないといけない、という話。 自動変数 ($@, $^, $< など)、組み込み関数、VPATH 等の詳細についてはここでは触れない。 prereq↓ \ target→ single multiple [bulk] multiple [foreach]

    Makefileで{単数, 複数}の{依存項目, ターゲット}の書き方 - Qiita
  • GCC拡張の無効化 (と、それにまつわる細かい話) - 簡潔なQ

    端的に言えば-pedantic-errorsを使えばよい。(できれば-std=...も併用したほうがいいだろう) 以下解説 GCCのC/C++コンパイラは、独自の拡張機能を導入している。これを無効化するオプションには2種類あり、意味が異なる。 C標準と矛盾する拡張機能を無効化する。 (C標準と矛盾しないかもしれない)拡張機能を無効化する/または警告を出す。 実は、C言語の規格は、それぞれのコンパイラの拡張機能を全面的に禁止しているわけではない。「正しいプログラム(strictly conforming program)を正しく動かす」ことさえ満たせばいいので、いくつかの拡張機能が有効化されたままでも、標準に準拠していると言える場合があるのだ。 C標準と矛盾する拡張機能を無効化する C標準と矛盾する拡張機能を無効化するには、 -std オプションでISO C/C++を指定すればいい。 C D

    GCC拡張の無効化 (と、それにまつわる細かい話) - 簡潔なQ
    mizdra
    mizdra 2019/03/22
  • 「技術的負債とはどういうものなのか?」をテトリスに例えるとこうなる

    テトリスは落ちてくるテトリミノを積み上げ、横一列に並べて消すという有名なゲームですが、そのテトリスを例に「技術的負債」がどういうものかたとえた記事を、エンジニアでありコンサルタントでもあるというエリック・ヒギンズ氏が公開しています。 Technical Debt Is Like Tetris – Featured Stories – Medium https://medium.com/s/story/technical-debt-is-like-tetris-168f64d8b700 「技術的負債」とは、ソフトウェアの開発において、時間がかかるより良いアプローチではなく一番早く新機能の実装などの目的を達成できるアプローチを選んでしまったために生じたソフトウェアの複雑さのこと。例えば既存の機能を変更した際に説明書を書きかえなかった場合、後から別の人が動作を把握するにはソースコードを読む作業が

    「技術的負債とはどういうものなのか?」をテトリスに例えるとこうなる
  • 2016年、C言語はどう書くべきか (前編) | POSTD

    (訳注:2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注:著者のMattより、「文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例: 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり

    2016年、C言語はどう書くべきか (前編) | POSTD
    mizdra
    mizdra 2019/03/22