Excel VBA: マクロをテキストファイルに落とす

今日の今日まで知らなかったのだが、EXCEL マクロのソース・コード記述って、テキスト・ファイルに落とせるんだね。いつも、コピペで対応していたよ。

方法は、簡単。

ブラウザ内で、各モジュール配下のオブジェクトを選択＞右クリック＞ファイルにエクスポート...

で、出力される。

オブジェクトの種類によって、拡張子はいろいろ：.bas, .cls, {.frm, frx} だけどね。
フォームの場合は、ソース・コードそのものとバイナリ・ファイルのペアが出力されるね。
バイナリ・ファイルのほうは、ジオメトリックな情報なんだろうね。

Ruby: rconv

TODO

iTunesのバージョン・アップをしたらSafari

のインストールも促されたので、入れてみた。for Windows

ページのレンダリングは、IE, FireFoxと比較して、一番きれいだな。
少し使い込んで、いろいろ機能を見たいところ。

FireFoxのように、プラグインがいろいろそろっているとよいのだが。
あと、終了したあとも、前回のタブ・セットが残るとよいのだが。

と思っていたところ、どうやら以下のような情報がみつかった：


Safari for プラグインhttp://developer.apple.com/jp/internet/safari/faq.html#anchor11 によると、以下のようらしい：

11. Safariがサポートしているプラグインの種類を教えてください。

Safariのすべてのバージョンで、Netscapeスタイルのプラグインをサポートしています。Safari 1.3以降では、NetscapeスタイルのプラグインとCocoaプラグインをサポートしています。クロスプラットフォームではありませんが、Cocoaプラグインは簡単に作成でき、お使いのプラグインはCocoaのフレームワークのすべてを活用できます。

Cocoaプラグインの作成に関する詳細については、「Web Kit Plug-In Programming Topic」を参照し、Xcodeに含まれているWeb Kitサンプルのディレクトリにあるサンプルプラグインを試してみてください。

タブの復元メニュー＞履歴＞最後のセッションの全ウィンドウを開く、を選択。
すると、前回セッションで使っていたタブ・セットであたらしいSafariが起動するようだ。
→これは、自動でやってほしいところだなぁ

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 ケース・センシティビティ

Ruby: Mechanize GUIDE.txt 日本語訳

追記2010/12/7：本内容は古くなったので、バージョン1.0.0のものに更新予定である。
追記2014-10-13: ここに最新版をおいた: http://voidptrjp.blogspot.jp/2014/10/mechanize-guide.html



http://mechanize.rubyforge.org/mechanize/ にある GUIDE.ｔxt を訳してみた。
チュートリアルとしてよくできていると思う（原文的な意味で）。

• ルー語っぽい箇所などを、若干修正[2008/3/31]


• 訳微修正。SyntaxHighlighterでコード部分を整理[2010/8/5]

---

GUIDE.txt

Path:     GUIDE.txt
Last Update:     Tue Dec 04 19:36:28 -0800 2007

WWW::Mechanizeをはじめよう

このガイドは、Mechanize を使い始めるためのものです。このガイドを読み終わるまでに、ページをフェッチしたり、リンクをクリックしたり、フォームをうめてサブミットしたり、Webページ内から必要なデータを取り出したり、、と、お望みのいろいろな便利なことができるようになるとよいです。このガイドは、Mechanize を使ってできることの、表面的なほんとにちょっとしたスクラッチです。だけども、はじめるには十分な情報となるとよいです！

   

ページをフェッチしよう！

最初のことを最初に。mechanize を require して、新しい mechanizeオブジェクトを生成しましょう:

require 'rubygems'
require 'mechanize'

agent = WWW::Mechanize.new

さて、ページをフェッチするためのエージェントが使えます。グーグルをエージェントでフェッチしてみよう:

page = agent.get('http://google.com/')

なにがおこった？ 我々は mechanize に対して、グーグルのメインページを取ってくるようにたのみました。Mechanize は、任意のセットされたクッキーを格納し、そしてグーグルが送ってきた任意のリダイレクトをたどりました。エージェントは、ページを我々に返しました。このページからデータを取り出したり、クリックするためのリンクを探したり、うめるためのフォームを見つけることができます。



つぎに、クリックするためのいくつかのリンクを探してみましょう。

   

リンクを見つける

Mechanize は、ページをGETしたり、POSTしたり、またはフォームをSUBMITしたとき、ページ・オブジェクトをひとつ返します。ページがフェッチされたら、エージェントはページをパースして、リンクの一覧表をページ・オブジェクト内に作ります。


それでは、グーグルのホームページをフェッチしたので、すべてのリンクを表示してみよう:

page.links.each do |link|
   puts link.text
end

リンクの一覧を表示できます。だけど、Mechanize はクリックするリンクを見つけるのに役立つ、いくつかショート・カットを用意してます。たとえば、テキストが ‘News’ であるようなリンクをクリックしたい、としましょう。ふつうは、このようにしなければなりません:

page = agent.click page.links.find { |l| l.text == 'News' }

でもMechanize には、ショートカットがあります。上記の代わりに、このようにできるのです：

page = agent.click page.links.text('News')

このショートカットは、「名前が ‘News’ であるような全てのリンクを探せ」という意味です。もしかしたら読者は「そのテキストのリンクは、複数ありうるのに！」と考えているかもしれません。そしてそれは正しい！もしクリック・メソッドに、リンクの一覧を渡した場合、Mechanize は最初のひとつをクリックします。もし二つ目のリンクをクリックしたいのなら、このようにやりましょう:

agent.click page.links.text('News')[1]

適切なリンクを以下のように探すこともできます:

page.links.href('/something')

もしくはそれらを一緒につなげて、適切なテキストと適切なhrefのリンクを探すこともできます:

page.links.text('News').href('/something')

これらのショートカットは、frame, iframe, formのようなものをフェッチしたときの任意のリストに対して、使えます。さて我々はリンクのクリックの仕方を知りました。つぎに、フォームをうめるようなもっと複雑なことをやってみましょう。

   

フォームをうめる

グーグルの例の続きをやりましょう。以下がコードです:

require 'rubygems'
require 'mechanize'

agent = WWW::Mechanize.new
page = agent.get('http://google.com/')

もしページが表示できれば、ひとつのfという名前のフォームがあり、２組のボタンと２，３のフィールドがあります:

pp page

いまフォームの名前がわかりましたので、ページをフェッチしてみましょう:

google_form = page.form('f')

Mechanize で、フォーム・インプット・フィールドにアクセスする方法はいくつかありますが、一番便利な方法は、オブジェクトのアクセッサを利用する方法です。では、フォーム上の ‘q’ という名前のフォーム・フィールドに、‘ruby mechanize’と入力して見ましょう:

google_form.q = 'ruby mechanize'

値をセットして、フォームを表示し、以下のような行が見えることを確認してください:

#<WWW::Mechanize::Field:0x1403488 @name="q", @value="ruby mechanize">

名前 ‘q’ に対応する値が変わっていた場合は、成功です！つぎにフォームをサブミットしてボタンを押し、結果を見てみましょう:

page = agent.submit(google_form, google_form.buttons.first)
pp page

今やったことは、検索フィールドに文字をいれて「検索」ボタンを押したのと同じことです。ボタンなしでフォームをサブミットした場合、テキスト・フィールドに入力してリターン・キーを打ったのと同じです。



コードを全部見てみましょう:

require 'rubygems'
require 'mechanize'

agent = WWW::Mechanize.new
page = agent.get('http://google.com/')
google_form = page.form('f')
google_form.q = 'ruby mechanize'
page = agent.submit(google_form)
pp page

ここまでで、スクリーン・スクレーピングをやってみました。フォームについて、もう少し深く見てみましょう。スキップしたくなる前に！

   

フォーム・テクニック応用編

このセクションでは、フォームで可能な入力フォームで違ったタイプの使用法について、触れたいと思う。パスワードやテキストエリア・フィールドは、テキスト・フィールドと同じように扱われ得る。セレクト・フィールドは、テキスト・フィールドにとても似ているが、関連するオプションがたくさんある。ひとつのオプションを選んだとき、mechanize はそれ以外のオプションを非選択にする (マルチセレクトでなければ！)




たとえばリスト上のひとつのオプションを選択しよう:

form.fields.name('list').options[0].select

今、チェック・ボックスとラジオ・ボタンを見てみよう。チェックボックスを選択するには、ただこのようにすればいい：

form.checkboxes.name('box').check

ラジオ・ボタンは、チェック・ボックスによく似ているが、同じ名前のその他のラジオ・ボタンをアンチェックする方法を知っている。チェック・ボタンと同じように、ラジオ・ボタンをチェックしてみよう:

form.radiobuttons.name('box')[1].check

Mechanize はまた、ファイルのアップロードも簡単にできる！ファイル・アップロード・フィールドを探し、ファイル名を教えてやるのだ:

  form.file_uploads.file_name = "somefile.jpg"

   

データをいじる

Mechanize は、HTMLをパースするために hpricot を使っている。これはなにを意味するか？ mechanize で得たページを、hpricotオブジェクトのように扱えるということだ。 Mechanize をデータを取り出したいページのナビゲートに使った後、hpricotのメソッドで取り出せる:

agent.get('http://someurl.com/').search("//p[@class='posted']")

このパワフル・スクレーパに関するさらなる情報については、 HpricotBasics を参照してほしい。

Ruby: OptionParser (optparse.rb) の使い方

2014-05-13追記: 最新の OptionParser の網羅的機能については、「Ruby OptionParser クラスのリファレンス」 を参照してください。

OptionParser: コマンドライン・オプション解析のためのクラス

コマンドライン・オプションを解析するための方法として、従来からGNU の getopt 系のAPIが使われてきた (Getopt，GetoptLong)。Ruby ではこれらに加えて、optparse.rb の OptionParser クラスを利用する方法があるようだ。

ドキュメントは、たとえば http://stdlib.rubyonrails.org/ などに見つけることができる。

ここでこの OptionParser クラスは、従来の getopt 系クラスと使い勝手がだいぶ違うため、使いにくいという意見が散見される。実際、私も使ってみてその感があった。そこで、リファレンス・ドキュメントから主要な機能を抜き出して、使い方をまとめてみた。

OptionParserクラスの主要な機能および記述の方法

OptionParser は、コマンドラインの配列 ARGV を与えられると、その配列を解析しオプションのタイプに応じた処理を行う。ここで、「オプションのタイプに応じた処理」とは、実際には実装者が作りこむものである。

具体的には以下の３点を記述することになる：

• オプションの定義
• 定義されたオプションを指定したときの処理の定義
• ヘルプ・メッセージの定義

以下にサンプルコードを示す。

#! /usr/bin/ruby
#filename: test-optparse.rb
#author: http://voidptr.seesaa.net
#date: Mar. 11th, 2008
#desc:
#ref.: http://stdlib.rubyonrails.org
#
####
require 'optparse';
require 'ostruct';
require 'pp';
#### Option Parse Method.
def option_parse( args )
#Prepare.
ost         = OpenStruct.new;
#default option values.
#
#
ost.help    = "";
ost.file    = "";
ost.kind    = "";
ost.logfile = "test.log";
ost.verbose = false;
ost.arr     = [];
#
op = OptionParser.new do |opars|
opars.banner = "NAME "+" #{$0} [options]";
opars.separator "";
opars.separator "";
#display -h description at tail of the help message.
#
#
#on_headだと、help表示のとき他のオプションとの間に改行される。
#お好みで。
#opars.on_head( "--version", "show the version." ) do
opars.on( "--version", "show the version." ) do
puts "green 1.0.0";
exit 1;
end
#オペランドありオプション(基本形; オペランドFILEは、必須)
#
#
opars.on( "-f FILE", "specify a file" ) do |f|
ost.file = f;
end
#オペランドありオプション(基本形+; オペランドKINDは必須で、値は選択式・短縮形も可)
#-k a で、-k afterと同じ。-k b で、-k before と同じ意味。
#
#
opars.on( "-k KIND", [:before, :after], "select a kind {before, after}" ) do |k|
ost.kind = k;
end
#オペランドありオプション(基本形++; オペランドは、省略可)
#
#
#
opars.on( "-l [LOGFILE]", "specify the logfile." ) do |l|
if ( l != nil ) then
ost.logfile = l;
end
end
#フラグタイプのオプション (オプションは長い形式もあり; offの形式も同時に定義)
#
#
opars.on( "-v", "--[no-]verbose", "verbose mode switch." ) do |v|
ost.verbose = v;
end
#フラグタイプのオプション
#  on_tail で、オプション定義の〆
#
opars.on_tail( "-t", "--tasukete", "show this message." ) do
puts opars;
exit 1;
end
end  #endof do |opars|.
####
#オプションなしの場合.
#
#
if ( args == [] ) then
#ヘルプを表示。
puts op;
exit 1;
end
#
op.parse!( args );
#必須オプションのチェック
#
#
if ( ost.file == "" ) then
e = OptionParser::ParseError.new;
e.reason = "file was NOT specified (#{ost.file}).";
throw e;
exit 1;
end
#
ost;
end  #endof option_parse
#### Do.
options = option_parse(ARGV)
#### Result.
pp ARGV;
puts "";
pp "Dumper #{options}"
puts "name: #{$0}";
####endof filename: test-optparse.rb

コードについて

OptionParser を newする際に、コード・ブロックを渡している。このコード・ブロック内でオプションの定義、処理、ヘルプメッセージの定義を記述する。

これら３要素は、このコード・ブロック内にすべてまとめて記述することになる —-つまり、ロジックとデータは煮込みすぎたスープのようにどろどろに熔けてしまっている。これは、OptionParserの特徴だ。

一般的には、このようなかたちはプログラミング・ポリシーとしてもオブジェクト指向的にもよろしからざることと思われる。グット・デザイン教会からは破門されるかもしれない。

ただ、ことコマンドライン・オプション処理に限っていえば、この方式はとても楽なのだ； 各オプションとそれらの説明を、一元管理できる。

---

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)

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. セットアップ

とちゅう