【みんな】Caffeより手軽かつ高速! Cで書かれた必要十分な深層学習フレームワーク darknetを試す【意外と知らない】:電脳ヒッチハイクガイド:電脳空間カウボーイズZZ(電脳空間カウボーイズ) - ニコニコチャンネル:生活
チャオ! オレだ。 深層学習を手軽に使いたいというニーズは日に日に高まっているはずなのに、ガクシャ先生どもと来たら、やれMatlabだ、やれPythonだのと軟弱言語の話しかしやしねえ。どこかに気骨溢れたナイスガイはおらんのか! と思ったら、居た。 それが今回紹介するdarknetだ。 darknetという名前から想像する異常にダークである。 バーン どうよこのダークネス感 いまどき黒いページというのは珍しい。 そして無駄に凝った魔法陣のようなロゴ。ダークだ。 しかしダークネット、厨二満開とせせら笑っていられるのもいまのうちだ。 このダークネット、実に必要十分な機能を最短で試せる超絶優れたツールなのである。 CaffeやTensorFlowほどの知名度はないが、実用性皆無なTensorFlowに比べてdarknetはものすごく実用的。Cが分かる人ならばこれほど使いやすいものもちょっと他にな
C/C++中規模プロジェクトのための超シンプルなMakefile | POSTD
私は多くの小規模プロジェクトで Make を使ってきましたが、より大きな規模のプロジェクトになると、それは非常にうんざりするようなものでした。最近までは、自分のビルドシステムに行いたいことが4つあったのですが、Makeでの方法が分かりませんでした。 out-of-sourceビルド（オブジェクトファイルが、ソースとは分離されたディレクトリにダンプ出力されます） 自動生成される（かつ正確！）ヘッダの依存関係 オブジェクト／ソースファイルのリストの自動的な決定 インクルードディレクトリのフラグの自動生成 以下にこれらの全てを行える、C、C++、およびアセンブリで動作するシンプルなMakefileを紹介します。 MAKEFILE TARGET_EXEC ?= a.out BUILD_DIR ?= ./build SRC_DIRS ?= ./src SRCS := $(shell find $(S
C/C++プログラマのための開発ツール - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズ・ラボの光成です。 先日、社内で主にLinux上でC/C++を用いている開発者向けの講義をしました。 「こんなことができる」と知ってもらい、興味を持てば各自で勉強してもらおうと広く浅くツールを紹介しました。 gtags, ASan, Valgrind, addr2line, cppcheck, SystemTap, perfなどです。 興味があれば講義資料「C/C++プログラマのための開発ツール」をごらんください。 コンパイラオプション 受講者には新人やサイボウズ・ラボユースの学生もいたので基本的なところから紹介しました。 C/C++コンパイラを使うときはできるだけ警告オプションをつけるのが望ましいです。 警告が出るのは自分のコードの書き方に不備があることが多いからです。 gccやclangでは-Wall -Wextraは基本としてそれ以外にも有用なオプションがあります（C++用
C言語1000行以下のエディタ「Kilo」を理解する(1) シンプルな内部構造
以前、Salvatore Sanfilippo氏によって開発されたエディタ「Kilo」を取り上げたところ、高い関心を集めた。Kiloはclocカウントでソースコードが1000行以下で、しかもcursesなどのライブラリも使っていない。VT100の基本的なエスケープシーケンスとlibcで提供されている機能だけを用いて実装されたエディタで、シンタックスハイライトにも対応している。C言語1000行程度でここまで実用的なエディタが開発できるというのは、教育向けの素材として興味深い。 本連載では、Kiloのソースコードを読み、どのような仕組みでエディタが作られているかについて紹介する。C言語でソフトウェアを開発する際に利用する機能が網羅されており、学習素材としてなかなかのポテンシャルを持っている。エディタがどのように実装されているのかを知るためにも、一度は読んで見てほしいソースコードだ。 頭から読む
Checked C（プログラミング言語）
連載目次 Checked Cとは Checked Cは、C言語（以下、単に「C」とする）に境界チェック機能が追加されたもの。マイクロソフトが開発し、オープンソースなプログラミング言語として公開されている。本稿執筆時点（2016年6月28日）では、その仕様書のバージョンは0.5となっている。 Cでは、ポインターと配列を同一視できる（ポインターを使って配列＝メモリ上の連続した領域をアクセスできる）場面がある。このことは、プログラミングを容易にする面がある一方で、バッファオーバーランなどのエラーの種にもなる。Checked Cは配列やポインターでアクセス可能な範囲（境界）を定め、境界チェックを行うことにより、より安全にプログラミングを行えるようにするものだ。 また、Checked Cでは、既存のCコードはその意味を変えることがなく、そのまま実行できることを目指しており、従来のCコードとCheck
Balde — A microframework for C based on GLib and bad intentions.
#include <balde.h> balde_response_t* hello(balde_app_t *app, balde_request_t *request) { return balde_make_response("Hello World! I'm the balde! :D"); } int main(int argc, char **argv) { balde_app_t *app = balde_app_init(); balde_app_add_url_rule(app, "hello", "/", BALDE_HTTP_GET, hello); balde_app_run(app); balde_app_free(app); return 0; } It is designed to be fast, simple, and memory efficient.
2016年、C言語はどう書くべきか (後編) | POSTD
(前編はこちら： 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
how-to-c-response/README.md at master · Keith-S-Thompson/how-to-c-response
Matt (whose web site does not mention his last name as far as I can tell) has written an article "How to C in 2016". It's been linked to from Reddit and from Hacker News; the latter is where I saw it. Update: Matt has been kind enough to add a link to this critique to his article. Update: A couple of people have found Matt's last name from other sites, but since he didn't choose to include it in h
2016年、C言語はどう書くべきか (前編) | POSTD
(訳注：2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注：著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例： 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり
250bpm
← Why should I have written ZeroMQ in C, not C++ (part I) Just to be clear from the very beginning: This is not going to be a Torvalds-ish rant against C++ from the point of view of die-hard C programmer. I've been using C++ whole my professional career and it's still my language of choice when doing most projects. Naturally, when I started ZeroMQ project back in 2007, I've opted for C++. The main
clang/gccに組み込まれたAddressSanitizer/LeakSanitizerでメモリエラーを捕捉する - 千里霧中
C/C++でのユニットテストによるメモリリーク検出 - 千里霧中の補足。 メモリエラーの検出方法についてだけれど、最近のclangやgccだと、AddressSanitizerという動的解析ツールが組み込まれており、それを活用できる。 使用する場合はコンパイラオプション「-fsanitize=address」「-fsanitize=leak」等を指定する。 題材 例えば以下のコードを対象にする。 //main.c #include <stdio.h> #include <stdlib.h> void hoge(void) { int *a_buff = (int *)malloc(5 * sizeof(int)); a_buff[10] = 8; } int main(void) { printf("test\n"); hoge(); return 0; } これを普通にコンパイルして実行
Preface | Scalable C (in progress)
Why This Book Exists The C programming language does not have a sense of humor. If you write in C, you know that it does not forgive mistakes. It does not try to interpret what you mean. It does what you tell it, no more and no less. In return, it gives you full control over the results of your work. Modern languages focus on comfort, abstraction, and automation. C, which was born around 1970, foc
SDL2の紹介
2014年6月に開催されたSSII2014（http://www.ssii.jp/）のチュートリアル講演用資料です． 使用したコード等はこちら． https://github.com/norishigefukushima/SSII2014 アブストラクト 「CPUのクロック数が年月とともに増加する時代は終わり、プログラムの高速化をCPUの性能向上に任せることのできるフリーランチの時代は終わりを迎えています。しかしムーアの法則はいまだに続いており、CPUはマルチコア化、SIMD化という形で高性能化が続いています。本チュートリアルでは、計算コストの高い画像処理を高速化するために、CPUの能力をあますことなく引き出す、マルチコアプログラミング、SIMDプログラミングを解説します。」
template in C - KMC活動ブログ
この記事はKMC Advent Calendar 2015 - Adventar 9日目の記事です。 8日目の記事は、sio_puyoさんの超！エキサイティン！(副題:12月8日は何の日？) - KMC活動ブログでした。 はじめに KMC 4回生のhatsusatoです。 今日はC言語の話です。 最近Cをたくさん書いている*1のですが、Cを書いているとC++が恋しくなってきます。どうしてでしょうか。 その理由の一つに、C言語にはSTLがないことが挙げられると思います*2。 C言語には標準的なコンテナがないので、必要になるたびに自分で用意する必要があります。しかも、要素の型が異なるたびにコンテナの型が変わるので、いちいち作らないといけないです。 面倒くさいです。 C言語にはテンプレートがないので、(型安全な)ジェネリックプログラミングができないから面倒くさいのです。 そこで今日は、なんとかい
ビルドの待ち時間を減らす – ツール編 « Stop Making Sense
August 2011 (1) July 2011 (1) June 2011 (2) April 2011 (2) March 2011 (2) February 2011 (2) January 2011 (6) December 2010 (6) November 2010 (5) October 2010 (8) September 2010 (2) August 2010 (3) July 2010 (9) June 2010 (4) March 2010 (1) February 2010 (7) January 2010 (2) はじめに C/C++とmake使ったプロジェクトのビルド時間短縮について書いてみます。 対象となるのは、 大規模プロジェクトに関わっていて、ビルド時間長すぎ… 少人数だけど、大きなパッケージが絡んでいて、ビルド時間長すぎ… なプロジェクトに関わってい
Linux共有ライブラリの簡単なまとめ - wagavulin's blog
Linuxで共有ライブラリ（*.so）を作るようになったのでちょっと勉強してみた。今までは使うだけだったので、以下のようなことは知っていた。 作るときはgccの-sharedオプションを使う。 使うときはgccの"-lライブラリ名"でリンクするライブラリを指定する。 リンク時のライブラリ探索パスは-Lオプションで指定する。 実行時のライブラリ探索パスは/etc/ld.so.confに書いてあるディレクトリ。環境変数LD_LIBRARY_PATHでも指定可能。 ライブラリを作るときは、.cから.oを作るときに-fPICをつけるといいらしい。 新しくライブラリを入れたときはldconfigするといいらしい。 逆に今まであまり知らなかったこと。 ほとんどのライブラリはlibhoge.so, libhoge.so.1, libhoge.so.1.1のように3つくらいのファイルがあり、libhoge
メモリアライメントを意識した動的確保を行う際は posix_memalign が良いぽい - kawa0810 のブログ
posix_memalign() が良い理由 本ブログでは今まで _mm_malloc() を使用してメモリアライメントを揃えていましたが，posix_memalign() を使用したほうが良いぽいです．理由は _mm_malloc() が Intel CPU 環境でのみ動作するのに対し，posix_memalign() は標準化されているためメインストリームな環境であれば概ね動作するためです．また，posix_memalign() で確保したメモリは free() で解放することができ，_mm_free() が混在しなくなるためコードの保守性の向上が考えられます． posix_memalign の使用方法 簡単な使用方法のみ掲載します． ・インクルードするファイル #include <stdlib.h> ・posix_memalign() の使用方法 int posix_memalign
C/C++でJSONを読み込む(JSON-Cの使用方法まとめ) - Qiita
TL;DR libjson(JSON-C)を使ってJSONファイルをパースする方法を調べたので、記事にしようと思います。 追記 (2016/2/9) C言語向けでも他に jansson または jsmn などもあるようですので、検討しても良いと思います。 振り返って考えると json-c はドキュメントの少なさと実装の癖が強いのであんまりオススメできません・・・。 Big Sky :: C言語から使えるJSONパーサ、jansson がとても直感的で良い Big Sky :: C言語から使えるJSONパーサ、JSMNを試してみた。 C++向けでは picojson あたりが有名ドコロです。C++向けでは検索するといろいろ出てきますので、さほど困らないと思います。 kazuho/picojson: a header-file-only, JSON parser serializer in C
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
C/C++プログラマのための開発ツール
GitHub - arangodb/linenoise-ng: A small self-contained alternative to readline and libedit that supports UTF-8 and Windows and is BSD licensed.
