brew のバージョンに関する部分のソースを読んでみた

前回の記事 を書くにあたって CLT のバージョンの調べ方について調査し、パッケージ管理ツールのひとつである Homebrew による CLT バージョンの取得方法について、github のソースを探索したときのログです。

String#[/re/], extend を使ったモジュールのメソッド定義、定数のエイリアスといった、ちょっとおもしろい記述方法を見つけました。

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++ ライブラリ パートV チャプター 13. 文字列クラスString Classes

チャプター 13. 文字列クラスString Classes

Table of Contents

シンプルな変換Simple Transformations
ケース・センシティビティCase Sensivitity
任意の文字型Arbitrary Character Types
トークン化するTokenizing
縮めてフィットShrink to Fit
CString (MFC)

シンプルな変換Simple Transformations

Here are Standard, simple, and portable ways to perform common transformations on a string instance, such as "convert to all upper case." The word transformations is especially apt, because the standard template function transform<> is used.
ここに string のインスタンスにおける、標準的でシンプルで、かつポータブルな共通の変換を実施するための方法を、示します。たとえば、「すべて大文字に変換する」といったものです。 単語の変換は、とくに適してます。なぜなら、標準テンプレート関数 transform<> が、使用されるからです。

This code will go through some iterations. Here's a simiple version:
これは、イテレーションをいくつか使用したコードです。シンプルなバージョンです：

#include <string>
#include <algorithm>
#include <cctype> // 古い <ctype.h>

struct ToLower
{
char operator() (char c) const { return std::tolower(c); }
};

struct ToUpper
{
char operator() (char c) const { return std::toupper(c); }
};

int main()
{
std::string s ("Some Kind Of Initial Input Goes Here");

// すべてを大文字に変える
std::transform (s.begin(), s.end(), s.begin(), ToUpper());

// すべてを小文字に変える
std::transform (s.begin(), s.end(), s.begin(), ToLower());

// すべてを大文字に変えるが、変換結果を
// 別の文字列変数に格納
std::string capital_s;
capital_s.resize(s.size());
std::transform (s.begin(), s.end(), capital_s.begin(), ToUpper());
}

Note that these calls all involve the global C locale through the use of the C functions toupper/tolower. This is absolutely guaranteed to work -- but only if the string contains only characters from the basic source character set, and there are only 96 of those. Which means that not even all English text can be represented (certain British spellings, proper names, and so forth). So, if all your input forevermore consists of only those 96 characters (hahahahahaha), then you're done.
気をつけること は、これらの呼び出しはすべてグローバル Cロケールを含むことだ。これは、C関数の toupper/tolower の使用していることによる。 これは絶対的に動くとみなされるが、-- 文字列を構成する文字がベーシック・ソース・文字セット のみ であり、かつそれらの内の96種類の文字 のみ からなる場合 だけ、である。つまり、すべての英語テキストが表示できるわけではない (正式なブリティシュ・スペルや固有名詞など)。 だからもし入力文字列が、かならず96種類の文字だけからなるのであれば、変換される。

Note that the ToUpper and ToLower function objects are needed because toupper and tolower are overloaded names (declared in <cctype> and <locale>) so the template-arguments for transform<> cannot be deduced, as explained in this message. At minimum, you can write short wrappers like
また他に 気をつけることは、 ToUpper と ToLower の関数オブジェクトが必要だということ。なぜなら、 toupper と tolower は、オーバー・ロードされた名前だ（ <cctype>と<locale> に宣言）。だから このメッセージ で説明されているように、 transform<> へのテンプレート引数は省略できない。 最小限では、下記のような短いラッパーが書ける

char toLower (char c)
{
return std::tolower(c);
}

The correct method is to use a facet for a particular locale and call its conversion functions. These are discussed more in Chapter 22; the specific part is Correct Transformations, which shows the final version of this code. (Thanks to James Kanze for assistance and suggestions on all of this.)
正しいメソッドは、特定のロケールのファセットを使い、そのロケールで決められた変換関数を使うことだ。この問題は、チャプター22でより詳細に議論される; パートの 正しい変換 に、このコードの最終版を示す。（これに助言と提案をしてくれたJames Kanzeに感謝。）

Another common operation is trimming off excess whitespace. Much like transformations, this task is trivial with the use of string's find family. These examples are broken into multiple statements for readability:
そのほかの一般にある操作は、不必要なホワイト・スペースのトリミングだ。変換のとき以上に、このタスクはトリビアである。stringの find ファミリを使用する。以下の例では、可読性を考慮して複数のステートメントに分割している。

std::string str (" \t blah blah blah \n ");

// 先頭のホワイト・スペースをトリム
string::size_type notwhite = str.find_first_not_of(" \t\n");
str.erase(0,notwhite);

// 末尾のホワイト・スペースをトリム
notwhite = str.find_last_not_of(" \t\n");
str.erase(notwhite+1);

Obviously, the calls to find could be inserted directly into the calls to erase, in case your compiler does not optimize named temporaries out of existence.
明らかに、コンパイラが存在しない名前つき一時変数を最適化しなければ、 find の呼び出しは、 eraseの呼び出しへと、直接的に挿入できる。

Prev Up Next
パート V. 文字列Strings Home ケース・センシティビティ

g++: GNU C++ ライブラリ パート V （目次）

パート V. 文字列Strings

Table of Contents

13. 文字列クラスString Classes

シンプルな変換Simple Transformations
ケース・センシティビティCase Sensivitity
任意の文字型Arbitrary Character Types
トークン化Tokenizing
縮めてフィットShrink to Fit
CString (MFC)