JavaScriptによるデータ可視化ライブラリ：InfoVis の概要訳

InfoVisは、JavaScriptで記述されたデータ可視化ライブラリである。この種のライブラリは、Javaであれば、例えば、JUNG(http://jung.sourceforge.net/)などが存在する。

InfoVisにおいて、可視化対象のデータは、JSON形式のものを扱う。このため、このライブラリにはJSONを扱うためのAPIを含む(TreeUtil)。可視化関連のものは、Core.jsにて提供される。


InfoVisの概要が示されたページについて、日本語訳をおこなったのでここに示す。

url:
http://thejit.org/

download:
http://thejit.org/downloads/Jit-1.1.3.zip

license:
BSD(http://thejit.org/docs/files/Core-js.html)

概要:
http://thejit.org/docs/files/Core-js.html

---

●Core
Core.js
説明（Description）
JSONツリー構造を操作する共通ユーティリティ関数と、ライブラリとして、内部で使
用されているクラス・オブジェクトを提供する。
また、JSONツリー構造を操作する TreeUtil オブジェクトを、提供する。

作者（Author）
ニコラス・ガルシア・ベルモンテ(Nicolas Garcia Belmonte)

コピーライト（Copyright）
Copyright 2008-2009 by Nicolas Garcia Belmonte

ホームページ（Homepage）
http://thejit.org

バージョン（Version）
1.1.3

ライセンス（License）
BSD License
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the organization nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY Nicolas Garcia Belmonte ``AS IS'' AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL Nicolas Garcia Belmonte BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


サマリ（Summary）

Core.js 共通ユーティリティ関数とライブラリ内部で使用されるクラス・
オブジェクトを提供

TreeUtil 共通JSONツリー操作メソッドをいくつか
Functions
prune ツリー上でmaxLevelより大きな深さを持つノードを、クリアする
getParent idの識別子を持つノードの、親ノードを、返す
getSubtree 指定したidにマッチするサブツリーを、返す
getLeaves ツリーの葉を、返す
eachLevel ツリー上の相対的に指定した深さ以下の深さのノードを、イテレートする
each ツリーのイテレータ
loadSubtrees requestメソッドによって新たにリクエストされたサブツリーを、葉に追加する


TreeUtil
共通JSONツリー操作メソッド。

サマリ（Summary）
Functions
prune ツリー上でmaxLevelより大きな深さを持つノードを、クリアする
getParent idの識別子を持つノードの、親ノードを、返す
getSubtree 指定したidにマッチするサブツリーを、返す
getLeaves ツリーの葉を、返す
eachLevel ツリー上の相対的に指定した深さ以下の深さのノードを、イテレートする
each ツリーのイテレータ
loadSubtrees requestメソッドによって新たにリクエストされたサブツリーを、葉に追加する

CString (MFC)

CString (MFC)


A common lament seen in various newsgroups deals with the Standard string class as opposed to the Microsoft Foundation Class called CString. Often programmers realize that a standard portable answer is better than a proprietary nonportable one, but in porting their application from a Win32 platform, they discover that they are relying on special functions offered by the CString class.
いろんなニュース・グループで、同じような慷慨が見られる。Microsoft Foundation Class のCStringのかわりに、標準文字列クラスをつかったときの話題だ。 プログラマはよく、プロプラエタリ・ノンポータブルな解よりもスタンダード・ポータブルな解のほうがよいものとする。 しかし、アプリケーションをWin32プラットフォームからポーティングするにあたって、 CStringクラスの特殊な関数を使ってしまっていることに気づくのだ。

Things are not as bad as they seem. In this message, Joe Buck points out a few very important things:
このことは彼らが思っているほど悪くない。 このメッセージ では、Joe Buck がいくつか重要なことを明らかにしている：

• The Standard string supports all the operations that CString does, with three exceptions.
  標準 string は、３つの例外を除いてCStringのすべての操作をサポートしている。

• Two of those exceptions (whitespace trimming and case conversion) are trivial to implement. In fact, we do so on this page.
  ��つの例外のうち２つ（ホワイト・スペースのトリミングとケース・コンバージョン）は、造作もなく実装できる。実際、このページでも扱っている。

• The third is CString::Format, which allows formatting in the style of sprintf. This deserves some mention:
  ��つめは CString::Format で、これはsprintf タイプのフォーマットを可能にする。これはいくつか注意を要する：

The old libg++ library had a function called form(), which did much the same thing. But for a Standard solution, you should use the stringstream classes. These are the bridge between the iostream hierarchy and the string class, and they operate with regular streams seamlessly because they inherit from the iostream hierarchy. An quick example:
古い libg++ ライブラリは、form()とよばれる関数を持っていた。これは同じことをするものだった。しかし現在の標準の解としては、stringstreamクラスを使えばいい。これらはiostream階層とstringクラスのブリッジであり、通常のstreamをシームレスに操作する。なぜならstringstreamは、iostreamクラス階層から継承されているからである。単純な例：

#include <iostream>
#include <string>
#include <sstream>

string f (string& incoming) // incoming は "foo N"
{
istringstream incoming_stream(incoming);
string the_word;
int the_number;

incoming_stream >> the_word // "foo" を抽出
>> the_number; // "N" を抽出

ostringstream output_stream;
output_stream << "The word was " << the_word
<< " and 3*N was " << (3*the_number);

return output_stream.str();
}

A serious problem with CString is a design bug in its memory allocation. Specifically, quoting from that same message:
CStringの深刻な問題は、メモリ・アロケーションの設計バグである。正確には、同メッセージから引用する：

CString suffers from a common programming error that results in
poor performance. Consider the following code:
CString は、プアなパフォーマンスとなる一般的なプログラミング・エラー
の影響をうける。以下のコード例をかんがえよう：


CString n_copies_of (const CString& foo, unsigned n)
{
CString tmp;
for (unsigned i = 0; i < n; i++)
tmp += foo;
return tmp;
}

This function is O(n^2), not O(n). The reason is that each +=
causes a reallocation and copy of the existing string. Microsoft
applications are full of this kind of thing (quadratic performance
on tasks that can be done in linear time) -- on the other hand,
we should be thankful, as it's created such a big market for high-end
ix86 hardware. :-)
この関数は O(n^2)であって、O(n)ではない。理由は、ループ中毎回+=演算子が
メモリの再アロケーションと既存の文字列のコピーをおこなうからだ。Microsoftの
アプリケーションはこの類の問題に満ちている（線形時間で解ける問題が
��乗オーダの性能）--ただ一方でこれは感謝すべきなんだ。ハイ・エンドのix86
ハードウェアの巨大市場を創出しているんだからね(笑)。

If you replace CString with string in the above function, the
performance is O(n).
上記関数で CString を string に置き換えれば、パフォーマンスは O(n) だ。

Joe Buck also pointed out some other things to keep in mind when comparing CString and the Standard string class:
Joe Buck はまた、 CString と 標準stringクラスを比較するにあたり、他にもいくつか気に止めておくべきことを明らかにしている。

• CString permits access to its internal representation; coders who exploited that may have problems moving to string.
  CString は内部表現へのアクセスを許している；それを利用するコーダーは、string に変換するときに問題となるかもしれない。

• Microsoft ships the source to CString (in the files MFC\SRC\Str{core,ex}.cpp), so you could fix the allocation bug and rebuild your MFC libraries. Note: It looks like the CString shipped with VC++6.0 has fixed this, although it may in fact have been one of the VC++ SPs that did it.
  Microsoft は CString のソース・コードを配布している（ファイルはMFC\SRC\Str{core,ex}.cpp）。だから自前でアロケーション・バグを修正し、リビルドすることができる。 注意： VC++6.0のCStringは、バグが修正されているように見える。サービス・パックでかもしれないが。

• string operations like this have O(n) complexity if the implementors do it correctly. The libstdc++ implementors did it correctly. Other vendors might not.
  このような string のメソッドは、O(n) の複雑度を持つ。 実装者が正しくやれば。 libstdc++ の実装者は、これを正しく実装している。他のベンダは、そうでないかもしれない。

• While parts of the SGI STL are used in libstdc++, their string class is not. The SGI string is essentially vector<char> and does not do any reference counting like libstdc++'s does. (It is O(n), though.) So if you're thinking about SGI's string or rope classes, you're now looking at four possibilities: CString, the libstdc++ string, the SGI string, and the SGI rope, and this is all before any allocator or traits customizations! (More choices than you can shake a stick at -- want fries with that?)
  SGI STLの複数の部分は libstdc++ に使われているが、stringクラスはそうではない。 SGI stringは本質的に vector<char> であり、かつ一切リファレンス・カウントをしていない。libstdc++ はしているが。(O(n)だけれども )。だからもしSGIのstring かまたは ropeクラスを考えているのなら、４つの選択肢がある：CString, libstdc++, SGI string, SGI rope である。そしてこれは一切、アロケータ、トレーツのカスタム化以前である！
  (いろいろ取り揃えてございます。ご一緒にポテトもいかがですか？)

Prev Up Next
縮めてフィット Home パート VI. ローカライゼーション

g++: GNU C++ ライブラリ パート II チャプター 4. 型

チャプター 4. 型

Table of Contents

基本型Fundamental Types
数値的プロパティNumeric Properties
NULL

基本型Fundamental Types

C++は、下記の組込み型を持ちます：

• char

• signed char

• unsigned char

• signed short
• signed int
• signed long
• unsigned short
• unsigned int
• unsigned long
• bool
• wchar_t
• float
• double
• long double

これらの基本型は、ヘッダファイルのインクルードなしでいつでも使用可能です。これらの型は、C++またはCでまったく同じです。

これらの型のライブラリの部分を特定することは、禁止されます：その代わりPODを使います。

g++: GNU C++ ライブラリ パートI チャプター 2. セットアップ

とちゅう

g++: GNU C++ ライブラリ 日本語訳(目次)

探してたのだがどうにも見つからなかったので、やってみた(まだ目次のみ)。
原書は、"The GNU C++ Library" (http://gcc.gnu.org/onlinedocs/libstdc++/manual/spine.html)
まだ途中です。適宜アップデート予定。
長すぎる、とSeeSaa様に怒られてしまったので、付録以降はとりあえず本稿では省きました。

---

GNU C++ ライブラリ

Copyright (c) 2008 FSF

Japanese Translation Copyright (c) 2008 もふもふ

ライセンス

Table of Contents

I. イントロダクション

1. ステータス

実装ステータスImplementation Status

C++ 1998
C++ TR1
C++ 200x

ライセンス

コード: GPL
ドキュメンテーション: GPL, FDL

バグ

実装のバグ
標準ライブラリのバグStandard Bugs

2. セットアップ

ビルド構成の設定Configure
ビルド

必要なお膳立てPrerequisites
Make

テスト

構成Organization
命名規則
ユーティリティ
テスト・スイートの実行
新しいテスト・ケース
テスト・ハーネス詳細
これから

3. つかい方

ライブラリ・バイナリ・ファイルのリンク
ヘッダ

ヘッダ・ファイル
ヘッダの混載Mixing Headers
C ヘッダと std名前空間
コンパイル済みヘッダ

名前空間

使用可能な名前空間
std名前空間
名前空間を組み合わせて使うUsing Namespace Composition

マクロ
同時性Concurrency

必要なお膳立てPrerequisites
スレッド安全性
アトミック
IO
コンテナ

「例外」安全性Exception Safety
デバッギング・サポート

g++ の使用
デバッグバージョンのライブラリ・バイナリ・ファイルDebug Versions of Library Binary Files
メモリ・リーク狩りMemory Leak Hunting
gdb をつかう
捕らえなかった例外を追う
デバッグ・モード
コンパイル時間のチェックCompile Time Checking

II. サポート

prefaceTODO:
4. 型Types

基本の型Fundamental Types
数値プロパティNumeric Properties
NULL

5. 動的メモリ
6. 停止Termination

停止ハンドラTermination Handlers
くどくどしい停止ハンドラVerbose Terminate Handler

III. 診断

7. 例外

例外クラス
例外にデータを追加する
打ち消しCancellation

8. コンセプト・チェッキング

IV. ユーティリティ

9. ファンクタ
10. ペア
11. メモリ

アロケータ

要求仕様Requirements
設計上の問題点Design Issues
実装
スペシフィック・アロケータをつかう
カスタム・アロケータCustom Allocators
エクステンション・アロケータ

auto_ptr

制限
コンテナ中での使用

shared_ptr

要求仕様Requirements
設計上の問題点Design Issues
実装Implementation
使用法Use
謝辞

12. Traits

V. 文字列Strings

13. String クラス関連Classes

シンプルな変換Simple Transformations
大文字小文字の区別Case Sensivitity
任意の文字型Arbitrary Character Types
トークナイジングTokenizing
縮めてフィットShrink to Fit
CStringクラス (MFC)

VI. ローカライゼーション

14. ロケール関連

ロケールlocale

要求仕様Requirements
設計Design
実装Implementation
これからFuture

15. ファセット aka カテゴリFacets aka Categories

ctype

実装
これから

codecvt

要求仕様Requirements
設計Design
実装Implementation
使用法Use
これからFuture

messages

要求仕様Requirements
設計Design
実装Implementation
使用法Use
これからFuture

VII. コンテナ関連

16. シーケンスSequences

リストlist

list::size() は 計算量O(n)

ベクタvector

空間オーバヘッドの管理

17. 連想配列Associative

挿入のヒントInsertion Hints
ビットセットbitset

サイズ変数Size Variable
Type String

18. Cとの連携Interacting with C

コンテナ vs. アレイContainers vs. Arrays

VIII. イテレータIterators

19. 定義済みPredefined

イテレータ vs. ポインタIterators vs. Pointers
ひとつ越えたらOne Past the End

IX. アルゴリズムAlgorithms

prefaceTODO:
20. ミューテイティイングMutating

スワップswap

特殊化Specializations

X. 数値型Numerics

21. 複素数型Complex

complex の処理

22. 一般化した操作Generalized Operations
23. Cとの連携Interacting with C

数値型 vs. アレイNumerics vs. Arrays
C99

XI. 入力と出力

24. Iostream オブジェクト
25. Stream バッファ

streambuf 派生クラス関連
バッファリング

26. メモリ・ベースのストリーム

strstream との互換性

27. ファイル・ベースのストリーム

ファイルをコピーする
バイナリ入力と出力
さらなるバイナリ入力と出力

28. Cとの連携

ファイルポインタFILE* とファイルディスクリプタを使うFILE* and file descriptors
パフォーマンス

XII. 拡張Extensions

prefaceTODO:
29. コンパイル時間のチェックCompile Time Checks
30. デバッグ・モードDebug Mode

Intro
セマンティクスSemantics
つかい方Using

デバッグ・モードを使う
Using a Specific Debug Container

設計

目的Goals
方法
他の実装Other Implementations

31. 並列モードParallel Mode

Intro
セマンティクスSemantics
つかい方Using

並列モードを使うUsing Parallel Mode
特殊並列コンポーネントを使うUsing Specific Parallel Components

設計Design

基本インタフェースInterface Basics
構成とチューニングConfiguration and Tuning
名前空間の実装Implementation Namespaces

テスティングTesting
Bibliography

32. アロケータ

mt_allocator

Intro
設計上の問題点Design Issues
実装
単一スレッドの例
複数スレッドの例

bitmap_allocator

設計
実装

33. コンテナ

ポリシーベースのデータ構造Policy Based Data Structures
HP/SGI
Deprecated HP/SGI

34. ユーティリティ
35. アルゴリズムAlgorithms
36. 数値型Numerics
37. イテレータIterators
38. 入力と出力

filebufs の派生

39. 曖昧性除去Demangling
40. 同時性Concurrency

設計

ロックとミューテックスへのインタフェースInterface to Locks and Mutexes
アトミック・ファンクションへのインタフェースInterface to Atomic Functions

実装

ビルトインのアトミック・ファンクションをつかうUsing Builitin Atomic Functions
スレッド抽象化

使用法