ときどきの雑記帖 めぐりあい電脳空間篇

最新ページへのリンク
目次ページへのリンク

一つ前へ 2010年3月(中旬)
一つ後へ 2010年4月(上旬)

ホームへ

2010年03月31日

姜維
書店で見かけたので最初と最後だけちょっと読んでみた。 んーーーー、持ち上げすぎじゃね? 姜維一人が(無謀な北伐で)国を傾けたとは思わないけれども (確か動員した兵力はかなり少なかったはず)、諸葛孔明の遺志を継いで云々というのはどうかなあ とか書いてると命の危険を感じるので止める(笑)

・小説フランス革命
四巻読了。ミラボー退場。 40代前半で死んでたのかこの人は。 ロベスピエールの描写は後半はよくなってた? さて、五巻買うぞ。
議会の迷走―小説フランス革命〈4〉 (小説フランス革命 4) 王の逃亡―小説フランス革命〈5〉 (小説フランス革命 5)

・今月の皇帝陛下
攻城戦

■ COBOL

なにがCOBOLを嫌われ者の言語にしているのか


What makes COBOL such a hated language? - Stack Overflow

I'm rather young and so I haven't experienced the times when COBOL was still in use 
and even going mainstream, maybe you can help me out.

わたしはとても若いので、COBOL がかつて使われていた時代というものを経験していません。
COBOLがメインストリームにあった時代なんてなおさらです。あなたの助けがあるといいのですが。

Everywhere I go and surf I:

    * Am getting told about how horrible COBOL is
    * See sites making fun of COBOL
    * Hear that I should be happy that I don't have to use COBOL, from older programmers
    * See others make anti-COBOL-ist jokes

I don't know much about COBOL, except that it is still used everywhere as many old 
systems haven't got refactored and that it is even still developed and managed. I have 
also looked at some COBOL code examples but it seems like they are as rare and 
expensive as unicorn blood.

    * If you close this question or give me sarcastic, irrelevant answers I'll have to 
      learn COBOL to find it out the hard way. I'm serious.


Some of the stigma comes from Old School COBOL, which was truly painful. I had to 
write COBOL on punchcards for a course years ago. We had terminals and more modern 
languages like PASCAL, but this legacy horror still existed:

   1. Write program out on big sheets of green paper, with character-sized grids, one 
      character to a cell. This was particularly painful, as COBOL was terribly verbose.
      プログラムを、一文字がセルひとつのキャラクターサイズのグリッドがある緑色の紙の
      大きなシートに書く。COBOLは恐ろしいまでに冗長であったので特に苦痛なものでした。

   2. Drop off paper at data center.
      データセンターにその紙を持っていく。

   3. Come back later and pick up stack of cards (your program typed up by the kindly 
      keypunch operators).
      時間が経ってからデータセンターに戻り、カードの山を受け取る(あなたのプログラムは
      親切なキーパンチオペレーターによってタイプされています)。

   4. Check cards for typos.
      カードにタイポがないか確認する。

   5. Use a keypunch machine to redo any cards with errors.
      エラーのあったカードの打ち直しをするためにキーパンチマシンを使う。

   6. Drop batch of cards off at data center.
      データセンターにカードの山を置いてくる。

   7. Come back later and pick up stack of printout, usually errors.
      時間を置いてからデータセンターに戻ってきて、出力結果を受け取る。
      たいていはエラーが出力されている。

   8. Debug errors by inspection.
      推測によってデバッグをする。

   9. Use a keypunch machine to fix cards with bugs.
      バグのあるカードを修正するためにキーパンチマシンを使う。

  10. Go to step 6.
      ステップ6へ。

This certainly wasn't all COBOL's fault. More modern COBOL compilers have improved 
some of the faults of the language, or so I've heard. But after that experience, I 
have no desire to go anywhere near it.

COBOL, Lisp, and FORTRAN are the oldest higher level languages. COBOL is generally 
associated with legacy mainframe applications.

COBOL、Lisp、FORTRAN は最古の部類の高水準言語です。COBOL は一般的に
レガシーなメインフレームアプリケーションに結び付けられています。

It's possible to write clean (and spaghetti) code in any language.

どんな言語であってもクリーンな(あるいはスパゲッティな)コードを書けます。

I believe COBOL has subroutines, so it's possible to write it in a well-decomposed, 
top down, modular style. COBOL that is written using a copy and paste style can be 
voluminous and hard to understand.

わたしは COBOL にはサブルーチンがあるので、well-decomposed されたトップダウンの
モジュラー形式のプログラムを書けると思っています。コピペスタイルを使って書かれた
COBOL は volumious になりがちで、理解するのが難しいものです。

But COBOL's not a joke. It powers a lot of software that runs large companies.

People that write COBOL live in a mainframe world and don't deal with distributed, 
object-oriented ideas that you take for granted in more modern languages. Maybe that's 
why people say you should feel lucky to not write it.


I've never written COBOL; can't read it, either. No desire to learn.

I hated it because COBOL programmers tended to write emails IN CAPS BECAUSE THEY 
FORGOT TO TURN OFF THE CAPS LOCK KEY, AND COULDN'T BE BOTHERED AFTER THEY'D TYPED IN 
HALF THEIR EMAIL ALREADY ANYWAY.

At least I don't have to worry about being shouted at in email any more now that I've 
moved on :-)

ひでえ。

■_ C++ FQA

これで終わり


C++ FQA Lite: Defective C++

** Manual memory management (自動化されていないメモリ管理)

Similarly to low-level built-in types, C++ manual memory management is inherited from 
C without changes (but with the mandatory addition of duplicate syntax - new/delete, 
which normally call malloc/free but don't have to do that, and of course can be 
overloaded).

低水準の組み込み型と同様、C++ のマニュアルメモリー管理はC から変更なしにそのまま受け継
いだものです(ただし、mandatory に重複した構文が使われていて、(新しい構文の) new/delete 
は通常malloc/freeを呼び出しますが、そうしなければならないと言うわけではありません。ま
た、オーバーロードも可能です)。

Similarly to the case with low-level built-in types, what makes sense for a low-level 
language doesn't work when you add higher-level features. Manual memory management is 
incompatible with features such as exceptions & operator overloading, and makes 
working with non-trivial data structures very hard, since you have to worry about the 
life cycles of objects so they won't leak or die while someone still needs them.

低水準の組み込み型と同様に、あなたが高水準の機能を追加したときには低水準言語で有用なも
のが動作しません。例外や演算子のオーバーロードといった機能とマニュアルのメモリー管理と
は incompatible であり、non-trivial なデータ構造と同時に使うことは非常に困難です。オブ
ジェクトのライフサイクルについて注意を払わなければならないので、リークしたりだとか必要
であるときに die するようなことはないでしょう。


The most common solution is copying - since it's dangerous to point to an object which 
can die before we're done with it, make yourself a copy and become an "owner" 
of that copy to control its life cycle. An "owner" is a C++ concept not 
represented in its syntax; an "owner" is the object that is responsible to 
deallocate a dynamically allocated chunk of memory or some other resource. The 
standard practice in C++ is to assign each "resource" (a fancy name for 
memory, most of the time) to an owner object, which is supposed to prevent resource 
leaks. What it doesn't prevent is access to dead objects; we have copying for that. 
Which is slow and doesn't work when you need many pointers to the same object (for 
example, when you want other modules to see your modifications to the object).

最も一般的な solution はコピーです。それは、あるオブジェクトに対して point することは
ポインター経由で操作する前に die してしまうかもしれないとても危険なものだからです。ラ
イフサイクルの制御を握るために自分でコピーを行って、そのコピーの“オーナー”になりまし
ょうこの“オーナー”(owner) というのは、(C++ の)構文で表されるものではない C++ のコン
セプトで、“オーナー”とは、動的に割り当てられたメモリチャンクやその他のリソースの解放 
(deallocate) に対して responsible であるようなオブジェクトです。C++ における標準的な 
practice はリソースリークを防ぐことををもくろんで各“リソース”(大抵はメモリーに対する 
fancy な名前です) をあるオーナーオブジェクトにアサインするものです。すでにコピー済みで
ある死んだオブジェクト (dead objects) に対するアクセスは防ぎません。同一のオブジェクト
に対するポインターを数多く必要としているときこのやり方は遅いし、かつうまく動作しません
(たとえばあなたがそのオブジェクトを変更したことを確認するために他のモジュールを必要と
する場合がそうです)。


An alternative solution to copying is using "smart" pointer classes, which 
could emulate automatic memory management by maintaining reference counts or what-not. 
To implement the pointer classes for the many different types in your program, you're 
encouraged to use...

コピーを行うためのもう一つのソリューションは、参照カウントなどを使うことで自動メモリ管
理をエミュレートできるような“スマート”(smart 賢い) なポインタークラスを使うというも
のです。あなたのプログラム中で多くの異なる型に対するポインタークラスを実装するためにあ
なたが使うことを encourage されるのは…


** Defective metaprogramming facilities (メタプログラミング機能の欠如)

There are roughly two kinds of metaprogramming: code that generates other code and 
code that processes other code. The second kind is practically impossible to do with 
C++ code - you can't reliably process source code due to the extremely complicated 
grammar and you can't portably process compiled code because there's no reflection. So 
this section is about the first kind - code generation.

大雑把には、二種類のメタプログラミングがあります:コードを生成するコード (code that 
generates other code) とコードを処理するコード (code that processes other code)がそれ
です。二番目のものは C++ のコードでは行うことが現実的ではないようなものです。C++ はと
んでもなく複雑な文法なのでソースコードを reliably に処理することはできません。また、コ
ンパイルされたコードを可搬性のある形で処理することはできませんなぜならリフレクションが
ないからです。そこでこのセクションでは第一のもの、コード生成について述べています。


You can generate C++ code from within a C++ program using C macros and C++ templates. 
If you use macros, you risk getting clubbed to death by C++ fanatics. Their irrational 
behavior left aside, these people do have a point - C macros are pretty lame. Too bad 
templates are probably even worse. They are limited in ways macros aren't (however, 
the opposite is also true). They compile forever. Being the only way to do 
metaprogramming, they are routinely abused to do things they weren't designed for. And 
they are a rats' nest of bizarre syntactic problems.

C のマクロや C++ のテンプレートを使った C++ プログラムかで C++ のコードが生成できます
もしマクロを使っているのなら、あなたは C++ の fanatics によって clubbed to death され
る危険を冒しています。彼らの馬鹿げた行動は別としても、そういった人たちの主張には一理あ
ります。C のマクロはとても lame (役立たず、時代おくれ) であるし、ひどすぎるテンプレー
トはおそらくさらに悪いです。テンプレートはマクロが制限されていない部分で制限が加えられ
ています(が、その反対もまた真であったりするのですが)。
They compile forever.
メタプログラミングを行うただ一つの方法として、それ向けに設計されていないものが日常的に
悪用 (abuse) されています。そしてそれは奇妙な構文的問題 (bizarre syntactic problems) 
の鼠の巣 (rats' nest) なのです。


That wouldn't necessarily be so bad if C++ didn't rely on metaprogramming for doing 
essential programming tasks. One reason C++ has to do so is that in C++, the common 
practice is to use static binding (overload resolution, etc.) to implement 
polymorphism, not dynamic binding. So you can't take an arbitrary object at run time 
and print it, but in many programs you can take an arbitrary type at compile time and 
print objects of this type. Here's one common (and broken) application of 
metaprogramming - the ultimate purpose is to be able to print arbitrary object at run 
time:

C++ が essential なプログラミングタスク を行うためにメタプログラミングに頼る必要がない
のであれば、このことはそれほどひどくはならなかったでしょう。C++ がこれを行わなければな
らない理由の一つは、C++ では多態を実装するために動的バインディングではなく(オーバーロ
ードの解決などの)静的バインディングを使うことが common practice となっているからです。
ですからあなたは、実行時に任意のオブジェクトを受け取ってそれを出力するといったことはで
きませんが、多くのプログラムではコンパイル時に任意の型を受け取ってその型のオブジェクト
を出力することはできます。ここにひとつのよくある(そして壊れている)メタプログラミングの
アプリケーションがあります。その究極的な目的 (ultimate purpose) は実行時に任意のオブジ
ェクトを出力できるようにするということです:

// an abstract base class wrapping objects of arbitrary types.
// there can be several such classes in one large project
// 任意の型のオブジェクトをラッピングする抽象ベースクラス。
// ひとつの大きなプロジェクトに属するような複数のクラスの可能性もあります
struct Obj {
  virtual void print(std::ostream&) const = 0;
};
template<class T> struct ObjImpl : Obj {
  T wrapped;
  virtual void print(std::ostream& out) const { out << wrapped; }
};
// now we can wrap int objects with ObjImpl<int> and string objects
// with ObjImpl<std::string>, store them in the same collection of Obj*
// and print the entire collection using dynamic polymorphism:
// これで int のオブジェクトを ObjImpl<int> で
// string のオブジェクトを ObjImpl<std::string>, でラップして、それを
// 同一の Obj* のコレクションに収めれられるようになり、そしてコレクション全
// 体を動的多態 (dynamic polymorphism) を使ってprint できるようになります。

void print_them(const std::vector<Obj*>& objects) {
  for(int i=0; i<(int)objects.size(); ++i) {
    objects[i]->print(std::cout); // prints wrapped ints, strings, etc.
    std::cout << std::endl;
  }
}

Typically there are 10 more layers of syntax involved, but you get the idea. This sort 
of code doesn't really work because it requires all relevant overloads of 
operator<< to be visible before the point where ObjImpl is defined, and that 
doesn't happen unless you routinely sort your #include directives according to that 
rule. Some compilers will compile the code correctly with the rule violated, some will 
complain, some will silently generate wrong code.


典型的には十を越える syntax involved のレイヤーが存在していますが、you get the idea.こ
の種のコードは実際には動作しません。なぜならそのコードは operator<<のすべての 
relevant overloads が、ObjImpl が定義されている場所よりも前で可視であることを要求して
いるからですそして、あなたが自分の #include ディレクティブをルールに従って routinely 
にソートしない限りそれは起こりません。一部のコンパイラーはルールを破ってそのコードを正
しくコンパイルしますし、中にはこっそりと間違ったコードを生成するものもあるでしょう。


But the most basic reason to rely on the poor C++ metaprogramming features for 
everyday tasks is the above-mentioned ideological decision to avoid adding high-level 
built-in types. For example, templates are at the core of the...


しかしすべてのタスクに対する貧弱な C++ のメタプログラミング機能に依存する最も根本にあ
る理由とは、先に言及した高水準の組み込み型の追加を避けるためのideological な決定なので
す。たとえば、コアに位置するテンプレートは…


** Unhelpful standard library (不親切な標準ライブラリ)

Most things defined by the C++ standard library are templates, and relatively 
sophisticated ones, causing the users to deal with quite sophisticated manifestations 
of the problems with templates, discussed above. In particular, a special program 
called STLFilt exists for decrypting the error messages related to the C++ standard 
library. Too bad it doesn't patch the debug information in a similar way.

C++ 標準ライブラリで定義されていることの大半はテンプレートであり、そして相対的に知識の
足りない人物が、ユーザーに先に論じたようなテンプレートにまつわる問題の quite 
sophisticated manifestations  を取り扱わせるのです。特に、C++ の標準ライブラリに関連し
たエラーメッセージの decrypting のためにSTLFilt と呼ばれる特別なプログラムが存在してい
ます。同様の方法でデバッグ情報をパッチしないことはとても悪いことです。

Another problem with the standard library is all the functionality that's not there. A 
large part of the library duplicates the functionality from the C standard library 
(which is itself available to C++ programs, too). The main new thing is containers 
("algorithms" like max and adjacent_difference don't count as 
"functionality" in my book). The standard library doesn't support listing 
directories, opening GUI windows or network sockets. You may think that's because 
these things are non-portable. Well, the standard library doesn't have matrices or 
regular expressions, either.

標準ライブラリに関するもう一つの問題は、functionality のすべてがそこにあるわけではない
というものです。ライブラリの大部分は C の標準ライブラリ (C++ プログラムからも使えます)
と機能的に重複しています。新しいことの主たるものはコンテナー (contrainers) です(max や 
adjacent_difference のような“アルゴリズム”(algorithms) はこの本では "functionality"
とは数えません)。標準ライブラリはディレクトリのリスティングもサポートしていませんし、
GUI ウィンドウを開いたりネットワークソケットをオープンすることもサポートしていません。
あなたはこれらのことがらがポータブルでないためだと考えるかもしれません。また、標準ライ
ブラリには行列や正規表現などもありません。


And when you use the standard library in your code, one reason it compiles slowly to a 
large binary image is that the library extensively uses the...

そして、あなたが自分のコードで標準ライブラリを使ったときに大きなバイナリイメージを作っ
てコンパイルが遅くなる理由の一つがそのライブラリが extensively に使っているものがある
からなのです…


** Defective inlining (インライン化の不足)

First, let's define the terms.

まずは用語から定義しましょう


"Inlining" in the context of compilers refers to a technique for 
implementing function calls (instead of generating a sequence calling the 
implementation of the function, the compiler integrates that implementation at the 
point where the call is made). "Inlining" in the context of C++ refers to a 
way to define functions in order to enable (as opposed to "force") such 
implementation of the calls to the function (the decision whether to actually use the 
opportunity is made by the compiler).

コンパイラーについての文脈での“インライン化”とは、関数呼び出しを実装するための技法の
ことを指します(関数の実装を呼び出すシーケンスを生成するのではなく呼び出しを行ったその
位置に関数の実装をコンパイラーが展開する)。C++ における“インライン化”とは先の意味で
言うところのインライン化された関数を呼び出すための実装を有効にする(“強制する”のでは
ありません)ような関数の定義方法のことを指します(実際にインライン化を行うかどうかの決定
はコンパイラーによって行われます)。

Now, the major problem with this C++ way to enable inlining is that you have to place 
the definition of the function in header files, and have it recompiled over and over 
again from source. This doesn't have to be that way - the recompilation from source 
can be avoided by having higher-level object file formats (the way it's done in LLVM 
and gcc starting from version 4). This approach - link-time inlining - is one aspect 
of "whole program optimization" supported by modern compilers. But the 
recompilation from source could also be avoided in simpler ways if C++ had a way to 
locate definitions instead of recompiling them, which, as we've seen, it hasn't.

さて、インライン化を可能にするためのこの C++ 方式の主な問題は関数の定義をヘッダーファ
イルに置く必要があり、そのためにソースから何度も何度も再コンパイルされてしまうというこ
とです。高水準なオブジェクトファイルフォーマットがあれば、ソースからの再コンパイルは避
けることができ、このような方法をとる必要もありません(高水準オブジェクトファイルフォー
マットを使うやり方は LLVM で採用されていて、gcc もバージョン4から採用しています)。この、
リンク時インライン化 (link-time inlinig) はmodern なコンパイラによってサポートされてい
る"whole program optimization" (プログラム全体に対する最適化) の一側面です。
しかしソースからの再コンパイルは、C++ が再コンパイルする以外の定義を特定する方法を採っ
ていればもっと単純な方法によっても避けることができるのです。そしてその方法はすでに見て
きたように採用されていません。


The crude support for inlining, designed with a traditional implementation of a C tool 
chain in mind, wouldn't be as bad if it wasn't used all the time. People define large 
functions inline for two reasons. Some of them "care" (emotionally) about 
performance, but never actually measure it, and someone told them that inlining speeds 
things up, and forgot to tell them how it can slow them down. Another reason is that 
it's simply annoying to define functions non-inline, since that way, you place the 
full function definition in a .cpp file and its prototype in a .h file. So you write 
the prototype twice, with small changes (for example, if a class method returns an 
object of a type itself defined in the class, you'll need an extra namespace 
qualification in the .cpp file since you're now outside of the namespace of the class). 
Much easier to just have the body written right in the .h file, making the code 
compile more slowly and recompile more frequently (changing the function body will 
trigger a recompilation).

インライン化に対する crude (大まかな、粗雑な) support はC の tool chaing の 
traditional implementationを使った設計が念頭にあったためであり、それが all the time で
使われることがなければそれほど悪くはなかったでしょう。ユーザーには、大きな関数をインラ
インで定義する理由が二つあります。一部のユーザーは性能に関して (感情的に)“気にする”
のにそれを計測する手段はけして持っておらず、誰かが遅くなる可能性もあるという部分を伝え
忘れてインライン化によって処理速度が向上すると彼らに話してしまったのです。もう一つの理
由は、インライン化しない場合にはfull な関数定義を .cpp ファイルに置くと同時にそのプロ
トタイプを .h ファイルに置くことになるのでインライン化しない関数定義をただ単に無視 
(annoying) しているというものです。この場合あなたはプロトタイプをほんのちょっとの違い
を持って二度記述することになります(たとえばあるクラスメソッドがそのクラスで定義されて
いるある型のオブジェクトそれ自身を返すときに、そのクラスの名前空間の外側にいるので.cpp 
ファイルでは名前空間による修飾が必要になります)。もっと簡単なのは関数の本体を .h ファ
イルに書いてしまうことです。それでコンパイルがさらに低速になり再コンパイルの頻度が高く
なります(関数の本体を変更することが再コンパイルの引き金になります)。


And you don't even need to actually write any inline functions to get most of their 
benefits! A large subset of the inline functions of a program are...

インライン関数の恩恵のほとんどは、それを得るために実際にインライン関数を記述する必要す
らありません!プログラム中にあるインライン関数群の大きなサブセットは…


** Implicitly called & generated functions (関数の暗黙の呼び出しや生成)

Here's a common "design pattern" in C++ code. You have a huge class. 
Sometimes there's a single pseudo-global object of this class. In that case, you get 
all the drawbacks of global variables because everybody has a pointer to the thing and 
modifies it and expects others to see the changes. But you get no benefits of global 
variables since the thing is allocated on the stack and when your program crashes with 
a buffer overflow, you can't find the object in a debugger. And at other times there 
are many of these objects, typically kept in a pseudo-global collection.

C++ のコードには一般的な“デザインパターン ”(design pattern) があります。あなたが巨大
なクラスを使っているとして、さらにそのクラスの一つだけの疑似グローバルオブジェクトがあ
ったとしましょう。その場合、あなたはグローバルオブジェクトの drawbacks をすべて受ける
ことになります。それは誰もがそのグローバルオブジェクトに対するポインターを持っていて、
そのオブジェクトを変更したらその変更を他の誰かが確認することを期待しているからです。し
かしあなたはグローバル変数による恩恵を受けることはありません。なぜならそのようなものは
スタックに割り当てられているので、バッファーオーバーフローでプログラムがクラッシュした
ときにデバッガーからそのオブジェクトを見つけることができないからです。そしてこの種のオ
ブジェクトが多く存在している場所で、典型的には疑似グローバル (pseudo-global) コレクシ
ョンに収められています。

Anyway, this huge class has no constructors, no destructor and no operator=. Of course 
people create and destroy the objects, and sometimes even assign to them. How is this 
handled by the compiler?

いずれにしても、この巨大クラスにはコンストラクターもデストラクターもoperator= もありま
せん。もちろんユーザーはこのオブジェクトを生成し、破棄しますし、ときにはオブジェクトに
対して代入することすらもあるでしょう。ではコンパイラーはそれをどのように扱っているので
しょうか?


This is handled by the compiler by generating a gigantic pile of code at the point 
where it would call the user-defined functions with magic names (such as operator=) if 
there were any. When you crash somewhere at that point, you get to see kilobytes of 
assembly code in the debugger, all generated from the same source code line. You can 
then try and figure out which variable didn't like being assigned to, by guessing 
where the class member offsets are in the assembly listing and looking for symbolic 
names of the members corresponding to them. Or you can try and guess who forgot all 
about the fact that these objects were assigned to using the "default" 
operator= and added something like built-in pointer members to the class. Because that 
wouldn't work, and could have caused the problem.

これはユーザー定義の関数が (operator= のような) magic name によって呼び出されるであろ
う箇所に巨大なパイル (pile) を生成することを通じてコンパイラーによってハンドルされます
そういった場所でクラッシュしてしまったとき、すべて同一のソースコードファイルから生成さ
れたkilobytes of assembly code をデバッガーで確認することになるでしょう。あなたはそれ
から、どの変数が代入されなかったのかのようなことをクラスメンバーのオフセットをアセンブ
リリストで推測してそれに対応するメンバーのシンボル名の探索を試みることによって突き止め
ることができます。あるいはこれらのオブジェクトが“デフォルト”の operator= を使って代
入されてているということやそのクラスに対する組み込みのポインターメンバーのようななにか
を追加されているという事実を忘れてしまっているのが誰かなのかを調べたり推測することがで
きます。なぜならそれはうまく動作しない可能性があって、問題を起こすかもしれないからです。


Implicit generation of functions is problematic because it slows compilation down, 
inflates the program binaries and gets in the way when you debug. But the problem with 
implicitly calling functions (whether or not they were implicitly generated) is 
arguably even worse.

暗黙の関数生成は problematic です。それはコンパイル速度を低下させたり、バイナリのサイ
ズを増大させ、デバッグをするときに gets in the way になるためです。しかし暗黙の関数呼
び出しに伴う問題は(呼び出す関数が暗黙のうちに生成されたのかどうかには関係なく)、
arguably even worse なのです。


When you see code like a=f(b,c) (or even a=b+c, thanks to operator overloading), you 
don't know whether the objects are passed by reference or by value (see 
"information hiding"). In the latter case, the objects are copied with 
implicitly called functions; in the former case, that's possible, too, if implicit 
type conversions were involved. Which means that you don't really understand what the 
program does unless you know the relevant information about the relevant overloads and 
types. And by the way, the fact that you can't see whether the object is passed by 
reference or by value at the point of call is another example of implicit stuff 
happening in C++.


a=f(b,c) (あるいはオペレーターオーバーロードによってa=b+c のようなものであってさえも) 
のようなコードがあったとき、そのオブジェクトが参照によって渡されるのかあるいは値によっ
て渡されるのか(see "information hiding") のどちらなのかはあなたにはわかりま
せん。後者のケースでは、オブジェクトは呼び出される関数によってあんもくのうちにコピーが
行われます。暗黙の型変換が行われた場合には、前者のケースでも同じく暗黙の関数呼び出しと
オブジェクトのコピーが発生する可能性があります。これは relevant overloads and types に
ついての relevant information を知らない限りあなたはプログラムが行っていることを本当に
は理解していないことを意味します。ところでその呼び出しの場所でオブジェクトが参照によっ
て渡されたのか値によって渡されたのかを区別することができないということは C++ における 
implicit stuff happening (陰でこっそり起きていること) のもう一つの例です。


One more problem with automatically generated functions (such as constructors and 
destructors) is that they must be regenerated when you add private members to a class, 
so changing the private parts of a class triggers recompilation... Which brings us 
back to square 1.

コンストラクターやデストラクターのように自動的に生成される関数にまつわるもう一つの問題
は、それらの関数はあるクラスにプライベートメンバーを追加したときに再生成されなければな
らないということです。つまり、あるクラスのプライベート部を変更することは再コンパイルの
引き金を引くことであり … そしてその引き金はわたしたちを振り出し (square 1) へと引き戻
すものなのです。


Copyright c 2007 Yossi Kreinin
revised 30 August 2008 

■_ 本日の巡回から

■_ 増刷


マルチスレッドプログラミング相談室 その8 [chaika]
358 デフォルトの名無しさん [sage] 2010/03/29(月) 23:05:41 ID: Be:
    「Java並行処理プログラミング」が増刷してる 

へえ。

2010年03月30日

■_

積んでるうちに次が出てしまった小説フランス革命の四巻(議会の迷走)を 読んでいるのですが、ロベスピエールの扱いというか描写が以下略

■_ Never trust a programmer who says he knows C++

元記事のページにあるグラフを見ないとたぶん面白くないのでまずはそちらを lbrandy.com » Blog Archive » Never trust a programmer who says he knows C++


lbrandy.com » Blog Archive » Never trust a programmer who says he knows C++

I've been in an interviewing mindset for awhile and I've come to realize something 
important about C++ in particular. C++ is a “two peak” language. That is to say C++ 
is the only language I know of where two very different sets of programmers consider 
themselves well versed in the language. Let me show you in fake graph form:


Programmers (especially those coming from C) can very quickly get up to speed in C++ 
and feel quite proficient. These programmers will tell you that they know C++. They 
are lying. As a programmer continues in C++, he goes through this valley of 
frustration where he fully comes to terms with the full complexity of the language. 
The good news is that it's really easy to tell the difference between C++ programmers 
pre- and post- valley (in an interview, in this case). Just mention that C++ is an 
extremely large and complex language, and the post-valley people will give you 127 
different tiny frustrations they have with the language. The pre-valley people will 
say “Yea, I guess. I mean, it's just C with classes.”. 

そしてredditでのスレッドの発言は400オーバー。 Never trust a programmer who says he knows C++ : programming



Never trust a programmer who says he knows C++ : programming
I agree with the theory of that graph, but those steps he mentioned should all be near 
the top. Here are some steps you hit as you descend further:

    * WTF is this syntax for a pointer to a member function
    * Why doesn't "Object object = value;" use operator=() ?
    * Oh sweet, overloading the cast operator is fun
    * Oh my god, overloading the cast operator has made my life hell
    * WTF is placement new?
    * Oh my god, there are two kinds of exceptions on Windows
    * Oh cool I need to write my accessor functions twice, one for const
    * Should I write my templates with 'class' or 'typename'?
    * How come remove_if doesn't ever remove anything?
    * WTF is SFINAE?

Operator overloading: The gift that keeps on giving!

Soon to become a "three peak" language when C++0x is finally standardized.

C++ こわい。

■_

読んだことのない本を薦めるとか、薦めるといっても目次を書き写して あとちょこっとだけしか書いてないとか以下略


推薦図書/必読書のためのスレッド 55
171 デフォルトの名無しさん [sage] 2010/03/20(土) 03:14:51 ID: Be:
    何で読んだことが無い本すすめるの?
    ばかなの?
    しぬの?

172 デフォルトの名無しさん [sage] 2010/03/20(土) 03:20:28 ID: Be:
    何で読んだことがない本は勧めちゃいけないんだ、ちょマジで俺理解出来ない 

173 デフォルトの名無しさん [sage] 2010/03/20(土) 04:43:00 ID: Be:
    中身知らないで勧めるとかありえないだろ
    どんだけ無責任なの 

174 デフォルトの名無しさん [sage] 2010/03/20(土) 07:59:43 ID: Be:
    何が理解出来ないのかマジで理解出来ないわw 

175 デフォルトの名無しさん [sage] 2010/03/20(土) 08:19:52 ID: Be:
    とりあえず>>172はこのスレから消えるべきだな。
    無価値ではなく有害だから。 

176 デフォルトの名無しさん [sage] 2010/03/20(土) 16:29:30 ID: Be:
    釣られ過ぎだろ 

177 デフォルトの名無しさん [sage] 2010/03/20(土) 19:13:17 ID: Be:
    ほかの人が薦めていたとかでも薦める理由にはなるんじゃない?
    その旨明記するのは当然だと思うけど 

178 デフォルトの名無しさん [sage] 2010/03/20(土) 21:04:06 ID: Be:
    「良さそう」も推薦理由だと思う 

179 デフォルトの名無しさん [sage] 2010/03/20(土) 21:08:07 ID: Be:
    結局、自分で中身見てから買うから「良さそう」でもあげてくれたほうが
    何もあがらないよりはいいかな 

180 デフォルトの名無しさん [sage] 2010/03/20(土) 21:12:18 ID: Be:
    「良さそう」だけで良いなら尼で検索するだけで良いんじゃね
    問題なのは良さそうだと思う理由だろ 

181 デフォルトの名無しさん [sage] 2010/03/20(土) 21:20:32 ID: Be:
    読んでもいない本を推薦するなんて、普通できないでしょうね。 

182 デフォルトの名無しさん [sage] 2010/03/20(土) 21:24:15 ID: Be:
    凡人には出来ない 

183 デフォルトの名無しさん [sage] 2010/03/20(土) 22:27:53 ID: Be:
    じゃあ転載なんじゃね? 

184 デフォルトの名無しさん [sage] 2010/03/20(土) 22:28:36 ID: Be:
    お、上手い 

185 デフォルトの名無しさん [sage] 2010/03/20(土) 22:30:52 ID: Be:
    つか、碌に読んでもない奴があーだこーだ批判する方が圧倒的に多いのでどうでもいい 

186 デフォルトの名無しさん [sage] 2010/03/20(土) 22:48:08 ID: Be:
    本当に役に立つ本を見ず知らずのやつに教えるわけないだろw
    適当に読んだことない本をさも読んだかのように語るのがこのスレ 

187 デフォルトの名無しさん [sage] 2010/03/20(土) 22:59:30 ID: Be:
    amazonで検索して目次とレビューで判断するとかもできない
    情弱をだまして遊ぶスレ。 

188 デフォルトの名無しさん [sage] 2010/03/20(土) 23:04:43 ID: Be:
    オライリーとオーム社のIt系(情熱プログラマ含む)は、大体ほめときゃ間違いない 

189 デフォルトの名無しさん [sage] 2010/03/20(土) 23:06:36 ID: Be:
    あと、オライリーの中でも白い本(アートオブシリーズ)とかもほめときゃ大体間違いない 

190 デフォルトの名無しさん [sage] 2010/03/20(土) 23:08:11 ID: Be:
    今度のThoughtWorksの本いいねって言っとくのもあり 

191 デフォルトの名無しさん [sage] 2010/03/20(土) 23:08:47 ID: Be:
    Head Firstはクセがあるけど良書が多いとか言っとけば間違いない 

192 デフォルトの名無しさん [sage] 2010/03/20(土) 23:14:48 ID: Be:
    秀和システムはダメだよねって言っておけば大体間違いない 

193 デフォルトの名無しさん [] 2010/03/20(土) 23:18:21 ID: Be:
    工学社は、、、言わなくてもわかるww 

194 デフォルトの名無しさん [sage] 2010/03/20(土) 23:19:01 ID: Be:
    アート・オブ・SQLは良かったけど、
    アート・オブ・アプリケーションパフォーマンステストは糞だった。 

195 デフォルトの名無しさん [sage] 2010/03/20(土) 23:44:28 ID: Be:
    秀和は最近がんばってるようなきがす 

196 デフォルトの名無しさん [sage] 2010/03/20(土) 23:54:33 ID: Be:
    忍者向けの本が出たね

    jQuery: Novice to Ninja 

そういや、Head First シリーズで、Excel が出るらしい。 あ、英語版の話です。

Ruby のブロック変数(でいいんだっけ?)の名前付けでも jijix さんあたりが悩んでいなかったっけか? 別の人だったかな。


くだすれPython(超初心者用) その6
490 デフォルトの名無しさん [sage] 2010/03/20(土) 21:28:49 ID: Be:
    for x in なんちゃら って、だいたいの人がx使ってるのはなんでだろう。
    代入してxを宣言しなくても怒られないのは何でだろう。
    そういうもんだと使ってたけど、ふと思うと気になってくる。 

491 デフォルトの名無しさん [sage] 2010/03/21(日) 00:15:26 ID: Be:
    へ?
    俺は慣習的にiを使う事が多いけどな。 

492 デフォルトの名無しさん [sage] 2010/03/21(日) 00:41:01 ID: Be:
    for 単数形 in 複数形:
    かな。個人的に i は極力使わないようにしてる 

493 デフォルトの名無しさん [sage] 2010/03/21(日) 00:50:40 ID: Be:
    俺も最近は492
    HaskellやCloujureで推奨されてるみたいだし
    enumerateでインデックス取ってくるときは i か idx を使うな

494 デフォルトの名無しさん [sage] 2010/03/21(日) 01:08:12 ID: Be:
    iのほうが押しやすいという理由でi
    小指と薬指のキーは嫌い、特に下段w 

501 デフォルトの名無しさん [sage] 2010/03/21(日) 01:26:56 ID: Be:
    >>490
    明示的に代入(もっとPython風に言うと、名前への値の束縛)をしなくてもいいのは、
    for x in l自体がxに値を束縛するって意味を含んでいるから。
    def func()だって、funcに関数を束縛するって意味だから、funcに前もって代入しなくてもいい。

    俺も>>492のいう単数形 in 複数形を心がける事が多いなぁ。
    iは、ループカウンタとしての使い方、値はどうでもよくて回数のみが重要なときと
    リストなどのインデックスとして使うときは極力使い、そうでないときは極力使わないようにしてる。
    インデックスとしての利用はなんとなくPythonらしくない気がするので避けてるけど、
    その方が楽そうなときは無理には避けない。 

502 デフォルトの名無しさん [sage] 2010/03/21(日) 01:33:24 ID: Be:
    その日の気分で大文字でAとかBとかやってみたりする事もあるな。
    思考が止まるから深く考えた事無いや 

503 デフォルトの名無しさん [sage] 2010/03/21(日) 01:38:30 ID: Be:
    >>500
    2ストロークはタイプ自体は苦痛じゃないけど
    数が多すぎて覚えられないのが苦痛だな
    いや、別に、良く使うやつだけ覚えておけばいいんだけど
    あと、右AltはIME切り替えに割り当ててるんで
    Alt+左手キーがムチャクチャ押しにくいw
    Python関係なさすぎ

    >>501
    単数形 in 複数形スタイルは時に自分の英語力の無さに絶望することになる
    『dataの単数形ってなんだっけ?』みたいな 

504 デフォルトの名無しさん [sage] 2010/03/21(日) 01:40:10 ID: Be:
    dataの単数形なんて知らないから for d in data: にしちゃうよ 

505 デフォルトの名無しさん [sage] 2010/03/21(日) 01:45:25 ID: Be:
    まぁ単数形自体は "datum" なんだけど
    タイプ量も増えちゃうし
    俺は data という単語自体を敬遠するようになったw 

506 デフォルトの名無しさん [sage] 2010/03/21(日) 02:22:02 ID: Be:
    大丈夫。ネイティブの連中も知らんからw使うと→(゚Д゚)ハァ? 

507 デフォルトの名無しさん [sage] 2010/03/21(日) 03:16:06 ID: Be:
    なんでもかんでも for item in items でおk 

508 デフォルトの名無しさん [sage] 2010/03/21(日) 03:44:56 ID: Be:
    >>506
    いや、それは無いだろ・・・え、マジ? 

509 デフォルトの名無しさん [sage] 2010/03/21(日) 04:01:53 ID: Be:
    data/datasで意味わかるからおk 

510 デフォルトの名無しさん [sage] 2010/03/21(日) 04:04:58 ID: Be:
    日本人が荻と萩の区別をつけにくいというのと同じような意味だ 

511 デフォルトの名無しさん [sage] 2010/03/21(日) 04:52:01 ID: Be:
    剥げと禿げ 

512 デフォルトの名無しさん [sage] 2010/03/21(日) 09:43:53 ID: Be:
    indexの複数形がindicesってのも、知らない人多いよな。 

513 デフォルトの名無しさん [sage] 2010/03/21(日) 11:44:45 ID: Be:
    mouse の複数形とか 

514 デフォルトの名無しさん [sage] 2010/03/21(日) 11:49:00 ID: Be:
    ペゾルト本でそんなネタがあったね

    ところでおまいら補償と保証と保障の区別はつきますか 

「保証」を使うべきところで「保障」にしちゃっている人は結構多いような気がする。 あと、イテレートでは e とかも良く使うかなあ(Element)。

どこかで、x:xs のような規約?はどこから出て、どういう意味なんだろうという 疑問を見たような覚えがあるけどどこだったか思い出せない。

■_ C++ FQA

ところどころ結構悩んだところが。


C++ FQA Lite: Defective C++

** Duplicate facilities (重複している機能)

If you need an array in C++, you can use a C-like T arr[] or a C++ std::vector<T> 
or any of the array classes written before std::vector appeared in the C++ standard. 
If you need a string, use char* or std::string or any of the pre-standard string 
classes. If you need to take the address of an object, you can use a C-like pointer, 
T*, or a C++ reference, T&. If you need to initialize an object, use C-like 
aggregate initialization or C++ constructors. If you need to print something, you can 
use a C-like printf call or a C++ iostream call. If you need to generate many similar 
definitions with some parameters specifying the differences between them, you can use 
C-like macros or C++ templates. And so on.

あなたがもし C++ で配列を必要としているのならC と同様な T arr[] を使ったりや C++ の
std::vector<T> を使ったりできますし、さらに、C++ の標準に std::vector が登場する
以前に書かれた任意の配列クラスを使うことも可能です。文字列が必要なら char * または 
std::string を使うかさもなければ標準以前(pre-standard) の文字列クラスのいずれかを使う
かします。あるオブジェクトのアドレスを取得する必要があるのなら C のようなポインター T* 
や C++ の参照 T& が使えます。オブジェクトの初期化が必要なら、C ライクな aggregate 
initialization やC++ のコンストラクターが使えます。何かを出力する必要があるのなら C ラ
イクな printfの呼び出しや、C++ の iostram 呼び出しを使えます。一部のパラメータだけが異
なっているような似かよった多くの定義を必要とするのなら、CライクなマクロやC++のテンプレ
ートを使えます。

And so on.


Of course you can do the same thing in many ways in almost any language. But the C++ 
feature duplication is quite special. First, the many ways to do the same thing are 
usually not purely syntactic options directly supported by the compiler - you can 
compute a+b with a-b*-1, but that's different from having T* and T& in the same 
language. Second, you probably noticed a pattern - C++ adds features duplicating 
functionality already in C. This is bad by itself, because the features don't 
interoperate well (you can't printf to an iostream and vice versa, code mixing 
std::string and char* is littered with casts and calls to std::string::c_str, etc.). 
This is made even worse by the pretty amazing fact that the new C++ features are 
actually inferior to the old C ones in many aspects.

もちろん、任意のほとんどの言語でも一つのことを複数のやり方で行えます。しかし C++ の機
能の重複はことさら特別なものなのです。第一に、ある一つのことを行う複数の方法はコンパイ
ラーによって直接サポートされている通常の純粋に構文的な選択肢ではありません。あなたは 
a+b を a-b*-1 として計算することができますが、それは一つの言語の中に T* と T& があ
るというのとは違うのです。第二に、あなたもおそらくも気がついているでしょうが C++ は C 
に既にある機能と重複したものを追加しています。この機能は interoperate をそれほどしない
ので重複していることそれ自体がよくないことです(あなたは iostream に printf することは
できませんし、その逆もできません。std::string と char* を混ぜたコードはキャストや 
std::string::c_str などがあふれることになります)。この新しい C++ の機能は実際には古い 
C の対応するものに対する inferior (劣等なもの、下級なもの) なのだというpretty amazing
な事実によって、これはさらに悪化させられました。


And the best part is that C++ devotees dare to refer to the C features as evil, and 
frequently will actually resort to finger pointing and name calling when someone uses 
them in C++ code (not to mention using plain C)! And at the same time they (falsely) 
claim that C++ is compatible with C and it's one of its strengths (why, if C is so 
evil?). The real reason to leave the C syntax in C++ was of course marketing - there's 
absolutely NO technical reason to parse C-like syntax in order to work with existing C 
code since that code can be compiled separately. For example, mixing C and the D 
programming language isn't harder than mixing C and C++. D is a good example since its 
stated goals are similar to those of C++, but almost all other popular languages have 
ways to work with C code.

そしてその best part はC++ の devotees は C++ の邪悪な機能を参照することにうんざりして
しまい、しばしば誰かが C++ コードでそれらを使っているときに指差しして名前を晒しあげた
りすることなのです(plain C を使っているわけではないのに)!そしてそれと同時に (誤って) 
C++ は C と互換性があり、それは C++ の強みの一つ (one of its strengths) であると彼らは
主張しているのです (はて、Cは邪悪なものだったのでは?)。C++ の中に C の構文が残されてい
る本当の理由はもちろんマーケティング上の都合です。(C と C++ の)コードはそれぞれ分けて
コンパイルできるのですから、既存の C のコードと共存するために C ライクな構文をパーズす
べき技術的な理由は全く*ありません*たとえば C のコードと D のコードを混ぜることは C のコ
ードと C++ のコードを混ぜるよりも難しくはありません。D は C++ と同様な目標を設定してい
ながら、他のほとんどすべてのポピュラーな言語はC のコードと一緒に動作できるような手段を
持っているのでその良い例です。


So IMO all that old syntax was kept for strictly commercial purposes - to market the 
language to non-technical managers or programmers who should have known better and 
didn't understand the difference between "syntax" and "compatibility 
with existing code" and simply asked whether the old code will compile with this 
new compiler. Or maybe they thought it would be easier to learn a pile of new syntax 
when you also have the (smaller) pile of old syntax than when you have just the new 
syntax. Either way, C++ got wide-spread by exploiting misconceptions.

ですからわたしの意見は、古い構文は、技術者でないマネージャたち (non-technical managers) 
や“構文”と“既存のコードに対する互換性”との違いをもっとよく知っておくべきなのに理解
していないただ単に古いコードが新しいコンパイラーでコンパイルできるかだけしか尋ねないプ
ログラマーたちに対してこの言語を売り込むために、まったくもって商業上の目的 (commercial 
purposes) のために残されたものだということです。単に新しい構文を得たときよりも古い構文
のもっと小さな pile も得たときに新しい構文の pile を学ぶのが簡単になるであろうと彼らは
考えたのかもしれません。いずれにしても、C++ は exploiting misconceptions によって広ま
ることとなったのです。


Well, it doesn't matter anymore why they kept the old stuff. What matters is that the 
new stuff isn't really new, either - it's obsessively built in ways exposing the C 
infrastructure underneath it. And that is purely a wrong design decision, made without 
an axe to grind. For example, in C++ there's...

確かに古い stuff を残している理由というのは今となってはもはや重要ではありません。重要
なのは、新しい stuff が本当に新しいものではないということでもなければそれが C のインフ
ラの underneath (下部) を expose (暴露、晒す) した方法で構築されているということであり、
そしてそれは an axe to grind 抜きに決められた純粋に間違った設計上の決定だったのです。

たとえばC++には…


* No high-level built-in types (高水準な組み込み型の欠如)

C is a pretty low-level language. Its atomic types are supposed to fit into machine 
registers (usually one, sometimes two of them). The compound types are designed to 
occupy a flat chunk of memory with of a size known at compile time.

C はとても低水準の言語です。C の atomic types は機械のレジスター (通常は一つですが二つ
のときもあります) にフィットする形でサポートされています。そして複合型はコンパイル時に
サイズがわかるフラットなメモリーのチャンクを占めるように設計されています。


This design has its virtues. It makes it relatively easy to estimate the performance 
& resource consumption of code. And when you have hard-to-catch low-level bugs, 
which sooner or later happens in unmanaged environments, having a relatively simple 
correspondence between source code definitions and machine memory helps to debug the 
problem. However, in a high-level language, which is supposed to be used when the 
development-time-cost / execution-time-cost ratio is high, you need things like 
resizable arrays, key-value mappings, integers that don't overflow and other such 
gadgets. Emulating these in a low-level language is possible, but is invariably 
painful since the tools don't understand the core types of your program.

この設計には virtues (長所、価値) があって、それがコードの性能やリソースの消費量の見積
りを相対的に容易なものにしました。そして遅かれ早かれアンマネージド環境で発生するような
検出するのが難しい低レベルのバグがあったとき、ソースコードの定義と機械のメモリーとの間
の対応が相対的に単純なものなのでデバッグをする助けになります。しかし、開発時間コスト/
実行時間コストの比が高いときに使われることを想定される高水準言語の場合にあなたが、サイ
ズ変更が可能な配列やキー/値のマッピング、オーバーフローしない整数などのガジェット
(gadget) のようなものを必要としているのなら低水準の言語でこれらをエミュレートすること
は可能ですが、例外なく痛みを伴うもの (invariably painful) です。なぜなら、ツールはあな
たのプログラムのコアの型を理解していないからです。


C++ doesn't add any built-in types to C (correction). All higher-level types must be 
implemented as user-defined classes and templates, and this is when the defects of C++ 
classes and templates manifest themselves in their full glory. The lack of syntactic 
support for higher-level types (you can't initialize std::vector with {1,2,3} or 
initialize an std::map with something like {"a":1,"b":2} or have 
large integer constants like 3453485348545459347376) is the small part of the problem. 
Cryptic multi-line or multi-screen compiler error messages, debuggers that can't 
display the standard C++ types and slow build times unheard of anywhere outside of the 
C++ world are the larger part of the problem. For example, here's a simple piece of 
code using the C++ standard library followed by an error message produced from it by 
gcc 4.2.0. Quiz: what's the problem?

C++ は C (の correction) に対して組み込み型の追加は一切していません。すべての高水準の
型はユーザー定義のクラスやテンプレートとして実装されなければなりませんし、これは C++ 
のクラスやテンプレートの defects (弱点、欠点)をその full glory の下で自ら明白なるとき
でもあります。
#苦しい…
高水準の型に対する構文的なサポートの欠如 (std::vector を  {1,2,3}で初期化したり
std::map を {"a":1,"b":2} で初期化することはできませんし、
3453485348545459347376 のような大きな整数定数を使うこともできません)は、この問題の些細
な部分です。暗号めいた複数行とか複数画面にわたるコンパイラからのエラーメッセージ、標準
の C++ の型を表示できないデバッガー、そしてC++世界の外側では聞いたことのないような遅い
ビルド時間といったものが問題の larger part です。例として、C++ の標準ライブラリを使っ
た単純なコード片と、それに対して gcc 4.2.0 が出力したエラーメッセージを掲載します。ク
イズ: 一体何が問題なのでしょうか?

// the code
typedef std::map<std::string,std::string> StringToStringMap;
void print(const StringToStringMap& dict) {
  for(StringToStringMap::iterator p=dict.begin(); p!=dict.end(); ++p) {
    std::cout << p->first << " -> " << p->second << std::endl;
  }
}
// the error message
test.cpp: In function 'void print(const StringToStringMap&)':
test.cpp:8: error: conversion from
'std::_Rb_tree_const_iterator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >' to non-scalar type
'std::_Rb_tree_iterator<std::pair<const std::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >' requested

The decision to avoid new built-in types yields other problems, such as the ability to 
throw anything, but without the ability to catch it later. class Exception, a built-in 
base class for all exception classes treated specially by the compiler, could solve 
this problem with C++ exceptions (but not others). However, the most costly problem 
with having no new high-level built-in types is probably the lack of easy-to-use 
containers. But to have those, we need more than just new built-in types and syntax in 
the C++ compiler. Complicated data structures can't be manipulated easily when you 
only have...

新しい組み込み型を排除するという決定はなんでも throw する能力のような、しかしそれを後
で捕捉するための能力を欠いているという別の問題を産み出しました。コンパイラーによって特
別扱いされるすべての例外クラスのための組み込みのベースクラス Exception はC++ の例外に
よってこの問題を解決できるかもしれません(but not others)。しかしながら新しい高水準の組
み込み型を持たないことに起因する最も costly な問題は、おそらく簡単に使えるような 
(easy-to-use) コンテナーがないということです。しかしそういったコンテナーを持つには、
C++コンパイラーに新しい組み込み型と構文がさらに必要となるのです。複雑な構造のデータは
簡単には操作できません。あなたが持っているものが…だけのときには…

** Manual memory management (自動化されていないメモリ管理)

■_ 本日の巡回から

こんなのが。

http://www.amazon.co.jp/dp/4798118907
Amazon.co.jp: 実用 Common Lisp: ピーター・ノーヴィグ, 杉本 宣男: 本

登録情報

    * 大型本: 928ページ
    * 出版社: 翔泳社 (2010/5/11)
    * 言語 日本語
    * ISBN-10: 4798118907
    * ISBN-13: 978-4798118901
    * 発売日: 2010/5/11

  

2010年03月29日

■_

・パリは燃えているか
パリは燃えているか ― NHKスペシャル「映像の世紀」オリジナル・サウンドトラック完全版
NHKスペシャルの「映像の世紀」でテーマ曲として使われていたもの。 突然聴きたくなったけど手に入るものなのかよくわからなかったので、 とりあえずついったでつぶやいてみたら、今でもサントラが問題なく買えることや タイトルなんかが数分のうちにわかりました。 んで、いくつかあったうちからこいつを選択。

むかーしの大河ドラマのテーマ曲とかでも聴きたいのがあるんだけどこっちは無理かなあ。 いくつか出てはいるみたいだけど。 あと番組名も何も思い出せないんだけど、 海外製作のシリーズもので、第一次世界大戦前後のヨーロッパの歴史を追いかけた 番組があったはずなんだけどもう一度観られないもんかなあ。

■_

今まで見落としていたけど、このスレ結構面白い。


いろんな言語で宿題 第四編
44 デフォルトの名無しさん [sage] 2010/03/20(土) 12:18:58 ID: Be:
    http://pc12.2ch.net/test/read.cgi/tech/1258320456/133
    # 課題2: 文字列が与えられたとして、その最初の2文字と最後の2文字を結合した新たな文字列を作れ。
    # ただし文字列の長さが2文字以下の時は、新たな文字列は空文字となる。

45 デフォルトの名無しさん [sage] 2010/03/20(土) 13:58:03 ID: Be:
    http://pc12.2ch.net/test/read.cgi/tech/1258320456/133
    # 課題 C. 文字列が与えられたとして、その最初の文字と同じ文字がそれ以後に
    # 現れた場合、それをすべて*に置換した新たな文字列を作れ。 

55 デフォルトの名無しさん [sage] 2010/03/21(日) 07:12:19 ID: Be:
    >>44
    使用言語:R

    f <- function(s){
    a <- nchar(s)
    if(a<=2)"" else paste(substr(s,1,2),substr(s,a-1,a),sep="")
    }

    > f("ba")
    [1] ""
    > f("basic")
    [1] "baic"
    > f("bas")
    [1] "baas" 

56 デフォルトの名無しさん [sage] 2010/03/21(日) 07:56:42 ID: Be:
    >>45
    使用言語:R

    f <- function(s){
    n <- nchar(s)
    a <- substr(s,1,1)
    paste(a,gsub(a,"*",substr(s,2,n)),sep="")
    }

    > f("asasas")
    [1] "as*s*s"
    > f("aa")
    [1] "a*"
    > f("a")
    [1] "a" 

57 デフォルトの名無しさん [sage] 2010/03/21(日) 08:26:57 ID: Be:
    >>44
    使用言語:Io

    Sequence f:=method(if(size <= 2,"",slice(0,2).. slice(-2)))

    Io> "basic" f
    ==> baic
    Io> "ba" f
    ==>
    Io> "bas" f
    ==> baas 

58 デフォルトの名無しさん [sage] 2010/03/21(日) 08:55:56 ID: Be:
    >>45
    使用言語:Io

    Sequence f:=method((a:=slice(0,1)) .. slice(1) asMutable replaceSeq(a,"*"))

    Io> "asasas" f
    ==> as*s*s
    Io> "aa" f
    ==> a*
    Io> "a" f
    ==> a 

62 デフォルトの名無しさん [sage] 2010/03/21(日) 16:32:01 ID: Be:
    >>44
    使用言語:Arc

    (def f (s)
    (let n (len s)
    (if (<= n 2) "" (+ (cut s 0 2) (cut s (- n 2))))
    )
    )

    arc> (f "ba")
    ""
    arc> (f "basic")
    "baic"
    arc> (f "bas")
    "baas" 

63 デフォルトの名無しさん [sage] 2010/03/21(日) 16:32:49 ID: Be:
    >>45
    使用言語:Arc

    (def f(s)
    (let a (cut s 0 1)
    (+ a (subst "*" a (cut s 1)))
    )
    )

    arc> (f "asasas")
    "as*s*s"
    arc> (f "aa")
    "a*"
    arc> (f "a")
    "a" 

74 デフォルトの名無しさん [sage] 2010/03/23(火) 09:11:51 ID: Be:
    http://pc12.2ch.net/test/read.cgi/tech/1263824755/962
    # [1] 授業単元: C言語基礎
    # [2] 問題文(含コード&\1リンク):
    # 数値中のすべてのビットを左端までシフトするプログラムを作成しなさい。
    # 例えば、01010110(二進法)は11110000(二進法)となります。 

83 デフォルトの名無しさん [sage] 2010/03/24(水) 13:47:37 ID: Be:
    http://pc11.2ch.net/test/read.cgi/db/1252492296/713
    #
    # A B C
    # - - -
    # 1 3 a
    # 1 5 b
    # 2 8 c
    # 2 4 d
    # 2 6 e
    # 3 3 f
    # 3 1 g
    #
    # 上記のようなSAMPLEテーブルがあるとき、
    # AごとにBが最大となるレコードのCを得たい、
    # つまり、抽出結果を下記のようにしたいと考えています。
    #
    # A C
    # - -
    # 1 b
    # 2 c
    # 3 f

84 デフォルトの名無しさん [sage] 2010/03/24(水) 14:37:06 ID: Be:
    >>83
    % Prolog

    'AごとにBが最大となるレコードのCを得る'(A,B,C) :-
       findsetof(A,'SAMPLE'(A,_,_)),
       findmax([B,A,C],'SAMPLE'(A,B,C),[B,A,C]).

    % findsetof/2 は http://nojiriko.asia/prolog/findsetof.html 参照 

85 デフォルトの名無しさん [sage] 2010/03/24(水) 17:13:49 ID: Be:
    >>82
    たぶんこれで正しいと思う…
    ttp://ideone.com/AAa3g0SM

86 デフォルトの名無しさん [] 2010/03/25(木) 12:15:58 ID: Be:
    >>83
    -- Haskell
    import Data.List (groupBy, maximumBy)
    import Data.Ord (comparing)
    import Data.Function (on)

    fst3 (x,_,_) = x
    snd3 (_,x,_) = x

    t83 = map ((a,_,c) -> (a,c)) . map (maximumBy (comparing snd3)) . groupBy ((==) `on` fst3)

    main = print . t83 $ sample
    where
    sample = [(1,3,'a'), (1,5,'b'), (2,8,'c'), (2,4,'d'), (2,6,'e'), (3,3,'f'), (3,1,'g')]

89 デフォルトの名無しさん [sage] 2010/03/27(土) 00:52:57 ID: Be:
    >>74
    使用言語:J

    f=:dyad def '([:#.x{.1#~+/)#:y'

    8 f 86
    240

    (8#2)#:86
    0 1 0 1 0 1 1 0
    (8#2)#:240
    1 1 1 1 0 0 0 0

    「左端」はbit数で変わってしまうので、bit数も引数にしました。 

90 デフォルトの名無しさん [sage] 2010/03/27(土) 13:25:18 ID: Be:
    >>74
    使用言語:J

    A=:;/1 1 2 2 2 3 3
    B=:;/3 5 8 4 6 3 1
    C=:' ' cutopen 'a b c d e f g'
    ]data=:A,.B,.C
    +-+-+-+
    |1|3|a|
    +-+-+-+
    |1|5|b|
    +-+-+-+
    |2|8|c|
    +-+-+-+
    |2|4|d|
    +-+-+-+
    |2|6|e|
    +-+-+-+
    |3|3|f|
    +-+-+-+
    |3|1|g|
    +-+-+-+
    /:~(#~[:~:{."1)\:~data
    +-+-+-+
    |1|5|b|
    +-+-+-+
    |2|8|c|
    +-+-+-+
    |3|3|f|
    +-+-+-+ 

91 デフォルトの名無しさん [sage] 2010/03/27(土) 15:48:05 ID: Be:
    >>90
    アンカー間違えました。>>83 でした。 

94 デフォルトの名無しさん [sage] 2010/03/28(日) 05:33:50 ID: Be:
    >>74
    使用言語:Io

    f:=method(n,b,
    n asString toBase(2) alignLeft(b, "0") sort reverse fromBase(2)
    )

    Io> f(86,8)
    ==> 240 

95 デフォルトの名無しさん [sage] 2010/03/28(日) 14:21:04 ID: Be:
    JとかIoって趣味でさわってるんですか? 

96 デフォルトの名無しさん [sage] 2010/03/28(日) 16:22:28 ID: Be:
    >>95
    はい。簡単なのしかできません。 

97 デフォルトの名無しさん [sage] 2010/03/28(日) 18:14:05 ID: Be:
    Prologも? 

98 デフォルトの名無しさん [sage] 2010/03/28(日) 19:21:02 ID: Be:
    prolog は問題をだしている人だと思います。 

99 デフォルトの名無しさん [sage] 2010/03/29(月) 05:56:03 ID: Be:
    >>97 99%のPrologコードは私が書いています。このスレでは仕様から
    直感的に得られるプログラムパターン上のラベル(述語名、論理変数名)に
    仕様の断簡を載せたらどうなるかを、露悪"趣味"的に追求しています。
    したがってここのコードは趣味として書かれています。職業的には
    この25年間Prolog以外のコードを書いたことはありません。 

J やりてー。

■_ void context →

Perl 6。


Journal of chromatic (983)

The Perl 6 design team met by phone on 02 December 2009. Larry, Allison, Patrick, Will, 
and chromatic attended.

(略)

Larry:

    * renamed void context to sink context
    * appears to have worked
    * working out the semantics of higher-level abstract conversions with the lower-level ones
    * the method conversions .Num, .Str, .Bool are low-level
    * the abstract ones are conversions to roles, like + to Numeric
    * the generic role is in charge of which conversion to use
    * seems to map better to what people expect
    * started to straighten out .true versus .Bool
    * renamed is ref to is parcel
    * made it synonymous with backslash
    * did more work on the Rat semantics to separate out what we originally called Ratio
    * now called FatRat
    * looked at all of the mentions of context in the spec
    * removed overloaded meanings
    * dynamic contexts are now call frames
    * contextual variables are now dynamic variables
    * context means two things now, the old list versus scalar notion and some notion
      of a thread's context (left those alone)

Allison:

    * "call frame" makes a lot of sense
    * we may kidnap that

Larry:

    * Damian has sent in various spec tweaks, as we gear up to do a Perl 6 book
    * kicked the p5=> out of the core into something supplied as a macro by a translator
    * ranges now preserve interval semantics when you do math on ranges
    * renamed blorst to blast so we can talk about phaser blasts
    * worked on the nature of constants
    * constant declaration is now in the same category as the subset keyword and othe declarators
    * now have an anon declarator
    * it confused people to misuse my or our in a situation without a name
    * had added an else to go with also, as Damian suggested
    * removed both of those in favor of a new metaoperator which guarantees sequential evaluation of the arguments
    * the S metaoperator
    * after deciding that undef is a lousy concept in Perl 6 -- it turns out to mean five or six different things -- we decided to untangle all of them
    * temporarily renamed Object to U, for the most generic undefined
    * then revised, per Damian's suggestion, to Mu
    * that represents the most generic undefined value and the type from which all other classes derive
    * one use of undef was in smart matching
    * added a .notdef method for the convenience of testing definedness
    * possible to write longer versions which work with smart match
    * a convenience method felt nicer
    * used heavily in the test suite
    * can test something directly with the method without having to use smartmatch
    * worked on the Rats of unusual precision (not ROUSes)
    * some confusion as to when things get limited to 64-bit denominators
    * clarified that only the user-visible results use that limit
    * intermediate calculations performed by an operator which can and must exceed that limit temporarily
    * added a scaling option to the round function
    * easy to round to a particular rational value
    * after lots of carping about how ill-defined enums are, I rewrote that spec
    * they're no longer roles
    * the but and does infix operators still can intuit an attribute property mixin
    * that's a function of operator DWIMmery though
    * enums, to the first approximation, are simply collections of constants
    * they also supply a method, .mapping, which returns a hashlike mapping
    * that takes care of most of the special cases
    * STD now forces the symbols it matches into strings
    * lots of hacking to track spec changes, such as renames
    * complex number literals now parse the initial plus or minus as part of the complex
    * prevents tragedy in negating the wrong part of the number
    * need to nail down pure versus impure ideas to move that into constant folding
    * infix operators couldn't accept assignment operator forms for baseops with square bracket or hyperoperator forms; fixed that
    * worked on error messages, especially the Borg forms
    * removed some redundant rules and the term lexer decreased in size by two-thirds
    * added a warning about the use of undef; gives a long list of things you might mean instead
    * if you use ** in a range in a regex, but you mess it up where it parses .. as matching anything, you now get a malformed range warning
    * added a few missing things to the CORE setting, such as range iterator
    * now trims pi and e to fit in to a Rat64
    * tweaked viv to support code production of infix operators
    * don't have to grovel around to find the operator

(略)

void context から変えるのはまあいいとして、 sink context って?

■_ 八つの

本文訳している余裕がががが


8 reasons for re-inventing the wheel as a programmer

26 March, 2010

8 reasons for re-inventing the wheel as a programmer
プログラマーとして車輪を再発明する八つの理由

Again and again I read somewhere around the net that 're-inventing the wheel' is one 
of the worse errors a programmer can fall into. In fact, I've read it so often that 
the only thought of doing it makes me re-think over and over other ways of solving (or 
ignoring) the problem. But here, I advocate my pro's (the cons can be found elsewhere) 
for re-inventing the wheel, or at least not being frightened of it.

んで、項目だけ挙げるとこんなんです。

1. I don't like the default wheel color:

2. I want a bigger wheel:

3. I am a wheel engineer:

4. I want to know how does the wheel work:

5. My wheel is better than your wheel:

6. Proprietary vs free:

7. Create a new wheel:

8. Boredom:

■_ 本日の巡回から

2010年03月28日

■_

渾身の(でもないか)ネタが空振りするととっても悲しい。

■_


推薦図書/必読書のためのスレッド 55
515 デフォルトの名無しさん [sage] 2010/03/28(日) 00:31:27 ID: Be:
    GCの本糞って言った奴
    謝れよ 

516 デフォルトの名無しさん [sage] 2010/03/28(日) 01:03:13 ID: Be:
    ごめん 

517 デフォルトの名無しさん [sage] 2010/03/28(日) 01:07:29 ID: Be:
    ごめんなさい 

518 デフォルトの名無しさん [sage] 2010/03/28(日) 01:12:04 ID: Be:
    ごみん 

519 デフォルトの名無しさん [sage] 2010/03/28(日) 01:20:49 ID: Be:
    (m´・ω・`)m ごめんね 

520 デフォルトの名無しさん [sage] 2010/03/28(日) 01:29:36 ID: Be:
    ごめんください 

521 デフォルトの名無しさん [sage] 2010/03/28(日) 01:31:59 ID: Be:
    糞って言ったやつこんなにいたのか
    ほんとに糞なんだな 

522 デフォルトの名無しさん [sage] 2010/03/28(日) 03:03:51 ID: Be:
    俺的C++名著

    Effective C++
    C++ Coding Standards
    Modern C++ Design
    Exceptional C++
    C++の設計と進化
    Effective STL

    これで貴方も最強のC++プログラマー 

523 デフォルトの名無しさん [sage] 2010/03/28(日) 03:07:11 ID: Be:
    おい、ロベールが抜けてるぞ 

524 デフォルトの名無しさん [sage] 2010/03/28(日) 03:11:29 ID: Be:
    >>522
    C++ Templates
    C++ Templates Metaprogramming
    を抜かしておいて、何が最強だ?
    Modern C++ Designは、もはやモダンでも何でもないぞ。
    まあ、この二冊も、もう古いんだが。 

525 デフォルトの名無しさん [sage] 2010/03/28(日) 03:13:01 ID: Be:
    肝心のロベールを忘れてたわ。
    最初の一冊にどうぞ。

    C++入門講座(ロベール)
    Effective C++
    C++ Coding Standards
    Modern C++ Design
    Exceptional C++
    C++の設計と進化
    Effective STL

526 デフォルトの名無しさん [sage] 2010/03/28(日) 03:13:20 ID: Be:
    言語自体が古い。 

527 デフォルトの名無しさん [sage] 2010/03/28(日) 03:17:23 ID: Be:
    今はagdaですかそうですか 

536 デフォルトの名無しさん [sage] 2010/03/28(日) 12:16:27 ID: Be:
    いまだにModern C++ Desginを推薦する奴は
    本当の所はtemplateのパラダイムについてこれていないだろ 

537 デフォルトの名無しさん [sage] 2010/03/28(日) 12:34:24 ID: Be:
    >>536がC++の書籍を紹介してくれるそうです。 

謝罪が続く流れw

■_ Scala は

まあそこかしこに穴がありますが。

Scala: Post-Functional, Post-Modern, or Just Perl++?

Scala: Post-Functional, Post-Modern, or Just Perl++?

By Robert Fischer | March 6th, 2010

Let's start with some background.

I complained that Scala did not seem to be very functional to me, but I didn't really 
know how best to express what was fundamentally wrong with it. I did know that if 
“functional languages have a fixed set of features” like Scala's creator, Odersky, 
claims, then it wasn't simply “first-class functions in there, function literals, 
closures”, “types, generics, [and] pattern matching”. Scala has missed the 
functional boat in some basic way.

わたしは、自分にとっては Scala が very functional ではないように思えるという表明をしま
した。しかし、わたしは実際のところ根本的にどこが間違っているのかどのように表現するのか
がわかっていませんでした。わたしは Scala の creator である Oderskt が主張するように
“functional languages have a fixed set of features” (関数プログラミング言語は機能の
fixed set を有している) であっても、それはただ単に “first-class functions in there,
function literals, closures”(first-class の関数、関数リテラル、クロージャ) だとか、
“types, generics, [and] pattern matching” (型、総称関数、パターンマッチング) といった
ものではない。ということを知っていました。Scala はいくつかの basic wayにおいて
fuctional boatを間違っているのです。


After a kerfuffle in the comments, Brian enlightened us all by telling us what is a 
functional programming language. His explanation (while being a self-admitted 
generalization) is summarized as follows:

コメント欄で行われた空騒ぎの後、関数型のプログラミング言語がどういったものであるかを
わたしたちに伝えることで Brian は皆を enlightened (啓蒙、明らかにする) しました。彼の
説明 (while being a self-admitted generalization) をまとめると概ねこういったものです:


    So, what is it that differentiates the functional programming languages from all the
    other programming languages? It is simply this: the functional programming languages
    use, as their fundamental model of computation, the lambda calculus, while all the
    other programming languages use the Turing machine as their fundamental model of
    computation.

    では一体、関数型のプログラミング言語 (functional programming launagess) とそれ以外の
    すべてのプログラミング言語とを区別するものとはなんなのでしょうか? それは簡単に言うと
    こうです: 関数型プログラミング言語ではその fundamental model of computation (計算の
    基礎モデル or 根本モデル) として λ算法 (lambda calculus) を使っているのに対して、他
    のプログラミング言語では fundamental model of computation として、チューリングマシン
    (Turing machine) を使っています。


Six months later, Odersky responds with a very interesting post, which actually agrees 
that Scala is not a functional language in Brian's sense, but instead argues that any 
language is functional if it “makes programming centered around functions easy and 
natural”. He then runs through a list of features which is in common with functional 
languages, noting that Scala has them within handwave enough (more on that later). He 
ends wishing that people would “stop thinking of functional programming as a 
different, novel, or exotic way to code”. Even more, though, Scala is apparently
“an early example of a new breed of postfunctional languages”.


六ヵ月後、Odersky は Brian の sense においては Scala は関数型言語ではないということに
同意する very interesting post で応えました。しかし代わりに主張したのが
“makes programming centered around functions easy and natural”
(関数を中心とするプログラミングを簡単かつ自然になものにするもの)であればどんな言語も関
数型であるというものでした。彼はそれから関数型言語に一般的な機能のリストをなめていきま
したが、Scala が has them within handwave enough (more on that later) なものはありませ
んでした。彼は最後にユーザーが
“stop thinking of functional programming as a different, novel, or exotic way to code”
(関数プログラミングが異質であったり、novelであるとか、あるいはexotic なコーディングの
手法であると考えることを止める)ように希望しました。であるにも関わらず、さらに
Scala は “an early example of a new breed of postfunctional languages”.
(ポスト関数型言語の新しい系統における最初の一例) のようであると主張したのです。

And that gets us to this blog post.

そしてこの blog post に至ったというわけです。

First of all, Odersky is still missing the point. It's not about whether you use fold, 
map, and iter, or whether you can write closures easily. It's not even really about 
pure functions vs. side-effects. To code in a functional style is a fundamentally 
different way of thinking about problems: instead of thinking about problems as nouns 
that are doing things, functional programming views a problem as a series of 
transformations to the world which results in an answer. This is why functional 
programming is considered “a different, novel, or exotic way to code”: it is a 
different, novel, and (as of yet) exotic way to code. It's as different, novel, and 
exotic from OO as OO was from procedural. It's a different way of thinking about the 
entire issue. You can check out this snippet of an IRC conversation from #ocaml for 
more on that.

まず一点目として、Odersky はまだ話のポイントをはずしています。あなたが fold や map、
iter を使えるかどうかあるいはクロージャを簡単に記述できるかどうかということについての
話ではないのです。また、pure functions か副作用があるのかという話でもありません。関数
スタイルでコーディングするのは問題について考える根本的に異なったやり方なのです:関数プ
ログラミングでは、問題を行うこと (doing things) を表す名詞として考えるのではなく、
series of transformations to the world which results in an answer (回答の結果である世
界に対する変形の連なり)として見るのです。これが関数プログラミングが“a different, 
novel, or exotic way to code” (独特で、奇抜で、風変わりなコーディングのやり方)と考え
られている理由です:そしてそれは、オブジェクト指向プログラミングを手続き型のプログラミ
ングと比較したときに、オブジェクト指向プログラミングが独特で、奇抜で、風変わりであった
ということと同じことなのです。それは全く異なる思考方法なのです。
You can check out this snippet of an IRC conversation from #ocaml for more on that.
IRC の #ocmal で行われた議論の詳細をチェックできます。


The paragon of this way of programming is point-free programming, where you are quite 
literally building up a mega-function that describes how your program works, and then 
executing that one, single function when you run that program. If your language 
doesn't lead people to re-discover point free programming at least in the small, then 
the language really isn't taking function manipulation and functional language type 
conceptions seriously. And that's the case with Scala: even Odersky admits that in 
Scala, “currying is more verbose and much less used than in other functional 
languages”. (Protip to Scala people: If one of the fundamental stunts of a style is 
pervasive in all the code but yours, you're not in the same style of programming.)

この手法でのプログラミングの paragon (試金石?) は、きわめてリテラル的にあなたのプログ
ラムがどのように動作するかを記述するあなたがプログラムを実行したときに実行される一つの
関数である巨大関数 (mega-function) を組み上げるポイントフリープログラミングです。もし
あなたの使っている言語が (at least in the small) ユーザーにポイントフリープログラミン
グを再発見させるようなものでないのなら、その言語は実際には function manipulation や関
数型言語の type conceptions をきちんと取り入れていないのです。そして Scala の場合はこ
うです: Odersky でさえ
 “currying is more verbose and much less used than in other functional languages” 
「(Scalaにおいては)カリー化は他の関数型言語よりもさらに冗長でありあまり使われていない」
ということを認めています。(Scala ユーザーに対する Protip: もしスタイルの根本的な stunts
の一つがあなた以外のすべてのコードにおいて広く浸透したものであるのなら、あなたは同じ
スタイルのプログラミングをしていないのです)


What really gets me, though, is the claim that Scala is “an early example of a new 
breed of postfunctional languages”, because aside from the static typing, all the 
language features that Odersky trots out already exist in Perl. It's hard to be a 
vanguard of a new breed of programming languages when there's prior art from the 1980s.

しかし本当にわたしが気になったのは、 cala が
“an early example of a new breed of postfunctional languages”
(ポスト関数型言語の新しい breed (種類、系統) の early example)
であるという彼の主張でした。なぜなら、静的型付けを除けばOdersly が trots out した言語
機能はすべてすでに Perl にあるものだったからです。1980年代からprior art (先行技術?) が
存在してるのですから、(現時点で) プログラミング言語の新しい breed  の vaugurad (先遣隊、
先頭) であるのは困難なことです。


Don't believe me? The existence of a book on the topic unconvincing? Then let's run 
the list of functional language features from Odersky.

信じられませんか?
The existence of a book on the topic unconvincing? 
では Odersky による関数型言語の機能リストを見てみましょう。


    * Functions as first class values: check.
      first class の値としての関数: あり。

      sub apply(&$) {  # Take a function as an argument no problem
        $_[0]->($_[1]);
      }
       
      sub times2($) {  # Create a function to take
        print $_[0]*2 . "\n";
      }
       
      apply(\&times2, 3);

    * Convenient closure syntax: check
      便利なクロージャ構文: あり。

      my $x = 2;
      apply { print $_[0]*$x . "\n" } 3;
       
      my $times_x = sub($) {
        print $_[0]*$x . "\n";
      };
      $times_x->(3);

    * List comprehensions: check. (See perlfunc on list data.)
      リスト内包: あり。

    * “Curried” function definitions and applications: check-ish.
      “カリー化された”関数の定義とアプリケーション: check-ish
      Okay, so calling this a “check” on Scala is a bit of a reach (cite, cite, although
      note this—here is a more sympathetic run-down on Scala currying). Ignoring 
      the foo(2,_:Int) syntax for a moment, we can implement basically the same style of 
      “‘curried' function definitions” such as Scala's List#foldLeft.

Okay, 
so calling this a “check” on Scala 
is a bit of a reach 
(cite, cite, although note this—here is a more sympathetic run-down on Scala currying). 
とりあえずは foo(2,_:Int) 構文を無視することでわたしたちは Scala の List#foldLeft のよ
うな「“カリー化”された関数の定義」を基本的に同じ形式で定義できるようになりました。


      sub add {
        my $x = shift;
        return sub { $x + shift };
      }
      add(2)->(3);  # Okay, so you do need an extra ->

      In the case of our apply function above (where we take a function as the first 
      argument), it's even easier.

      上述のわたしたちの apply 関数 (その第一引数として関数を受け取る) の場合、格段に
      簡単なものです。

      apply { print $_[0]*$x . "\n" } 8;

      Now, there isn't really argument skipping (i.e.: foo(_:Int,3)) as a syntax feature,
      and there isn't a built-in curry function, but if you want Scala's Function.curried
      in perl, here it is:

      現時点では、構文機能としての本当の引数スキップ(i.e.: foo(_:Int,3)) はありませんし、
      組み込みの curry 関数もありません。しかし、Perl に Scala の Function.curried  が欲し
      いのならこういったものがあります:


      # This code released under Creative Commons 0 and WTFPL.
      sub curry(&@) {
        my($f,@args) = @_; 
        return sub { $f->(@args, @_); };
      }
       
      sub add($) {
        return $_[0] + $_[1];
      }
       
      my $curried = curry(\&add, 2); 
      print $curried->(3) . "\n";

    * Lazy evaluation: check. See Scalar::Defer for lazy val equivalents and 
      Tie::LazyList for lazy seq equivalents. People generally use a double-return approach 
      for generators (which I realize are different than lazy seqs and only kinda-sorta lazy).

      遅延評価: あり。遅延された val equivalents については Scalar::Defer を、遅延された
      seq equivalents については Tie::LazyList を参照してください。ユーザーは一般に、ジェネ
      レーター (which I realize are different than lazy seqs and only kinda-sorta lazy)
      のためのダブルリターンアプローチ (double-return approach) を使います。

    * Pattern matching: check (okay, check-ish). See Switch. The decomposition isn't there,
      which is the biggest weakness. But the general cumbersomeness and lack of real algebraic
      data types hamstrings the coolest parts of pattern matching anyway, so I'm calling it a
      draw. (This should be read as a generous and sympathetic ruling for Scala: Cedric Beust,
      for instance, rails against pattern matching/case classes and says “it's hard for me to
      see case classes as anything but a failure“.)

      パターンマッチング: (限定された意味で)あり。Switch を参照してください。最大の弱点である
      decompression はありません。しかし一般的な扱いにくさと、real algebraic data types の欠如
      はパターンマッチングのもっとも cool な部分を妨害するものですから、わたしはこれを draw
      (引き分け?) と呼びます。(これは Scala に対して寛大で好意的な (generous and sympathetic)
      ruling と読むべきです: たとえば Cedric Beust はパターンマッチングや case class に対して
      毒づいて (rails) こう発言しています。“it's hard for me to see case classes as anything
      but a failure”)

In addition, perl's got a few features in its favor for functional programming, like 
more flexible arguments, autovificiation, list/argument coercion, and dynamic symbol 
table mangling. Since perl also has OO capabilities, perl is at least as convincing a 
“post-functional language” as Scala. But there's even more in common between the two 
than that.

これに加えて、perl は、より柔軟な引数、autovificiation, リストや引数の coercion (強制
的な型変換)、動的なシンボルテーブルの mangling といった新しい機能を関数プログラミング
のために取り入れました。perl は OO 能力も持っていますから、Scala と同じ程度には perl 
も “ポスト関数型言語”なのです。
But there's even more in common between the two than that.
しかし、より一般的な観点で言えば二つの間にあるものでしょう。

Odersky's “post-functional language” is really a subtype of Larry Wall's
“post-modern language”: it's an attempt to create a language that is a grab-bag of 
multiple paradigms. And when you do that, you're just begging for the complaints that 
you hear leveled against both perl and Scala: it's too complicated, its syntax is 
weird, it's too magical, people write in entirely distinct subsets of the language, 
etc. (cite, cite, cite) Now, those who master the language (or master their favorite 
subset of it) love the TIMTOWTDI aspect. But it also means that the language is left 
as a jack-of-all-trades, master of none. Yes, Scala and perl integrate a lot of 
powerful tools from functional languages—but learning OCaml still blew my mind, 
despite knowing perl for years. As I started off saying, Scala is not a functional 
programming language. It is a statically typed object oriented language with closures.


Odersky のいう “post-functional language” とは、実際のところ Larry Wall の
“post-modern language”の subtype であり、複数のパラダイムの grab-bag である言語を作り
出そうという試みです。そしてそれをあなたがそれを行ったとすると、Perl と Scala の両方に
対しての、複雑すぎるだとか、構文が醜い、魔術的過ぎる、ユーザーはその言語の entirely 
distinct subsets でしか書かない。などなどの、あなたが聴いた不満の begging をあなたがす
ることになるでしょう:現在この言語 (もしくは彼らの favorite subset) をマスターしている
人たちは TIMTOWTDI aspect が大好きです。しかし同時にそれはその言語が left as a 
jack-of-all-trades, master of none  (器用貧乏なまま終わってしまうようなもの) であるこ
とも意味しているのです。なるほど Scala と Perl は関数型言語から得た多くの強力なツールを
integrate しましたが、Perl をずいぶん以前から知っていても OCaml を学ぶことは今でも
blew my mind です。最初にわたしが言ったとおり、Scala は関数型言語ではありません。
Scala は静的に型付けを行う、クロージャを備えたオブジェクト指向言語なのです。


Now, there is a sense in which Odersky is really onto something. The world of 
programming is forever transformed with closures and list comprehensions as being 
mandatory for new high-level languages, even if they're otherwise object oriented. And 
software developers are going to need how to work with them effectively if they want 
to read code moving forward. Yes, after 20+ years, the rest of the programming world 
finally caught up to one of perl's fundamental insights.

さて、Odersky が本当に onto something な sense があります。たとえそれがオブジェクト指
向以外のなにかであったとしても、プログラミングの世界はクロージャや新たな高水準言語に必
須な要素としてのリスト内包による forevaer trasform です。
そして they want to read code moving forward
であれば、ソフトウェア開発者たちは今あげたものの効果的な使い方が必要になるでしょう。
確かに 20年以上経った後には rest of the programming world は
最終的に perl's fundamental insights の一つへと収束するのでしょう。


©2006-2010: See the License page for details. Powered by WordPress.
Built on the Thematic Theme Framework. Design+Code by Graphic Karma Inc.	

■_ LoL

って別にあったな


Land of LISP: Is it still going to be released in March? : lisp

Land of LISP: Is it still going to be released in March? (amazon.com)


Hi Guys- I'm Conrad, the author of the book.

It's very close to being finished- Just a few more chapters need to complete their 
editing. I am really happy with the book, even if it's delayed. It's going to be a FAT 
book with lots of game examples and many illustrations. I'm sorry it's taking me so 
long, but it just took this long for me to write the book to the best of my abilities. 
I can't give you an exact release date- It might take a couple extra months or so. 
Sorry for the delay!

"I love deadlines. I like the whooshing sound they make as they fly by." - 
Douglas Adams

まさかの著者登場。

■_ match any char (include newline)

ふと見かけたついーと。


Twitter / javascripter: 改行を含む任意の一文字にマッチする正規表現、[\s\ ...

改行を含む任意の一文字にマッチする正規表現、[\s\S]じゃなくて[^]のほうが短い。

どうもJavaScript の人らしいのだけど、中身が空の文字クラスってエラーにならないのかなあ? 伝統的な正規表現だと、[ の直後に ] が来るとそれは文字クラスを閉じるものではなく、 そのキャラクターそのものとして解釈されたりするし。

>python
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.compile('[]')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\PYTHON26\lib\re.py", line 190, in compile
    return _compile(pattern, flags)
  File "C:\PYTHON26\lib\re.py", line 245, in _compile
    raise error, v # invalid expression
sre_constants.error: unexpected end of regular expression
>>> re.compile('[]]')
<_sre.SRE_Pattern object at 0x00AB7BA8>

いけね。2.6.5 に上げてない。

■_ ネタ


C言語なら俺に聞け(入門編)Part 62 
352 デフォルトの名無しさん [sage] 2010/03/27(土) 18:23:54 ID: Be:
    メモリのポインタは tibet にするといいよ。
    free(tibet);
    これで、このソースは中国政府自らの手により検索規制され、
    ソースのコピーをしばらくの間防ぐことが出来る。 

Lisp Scheme Part29 

860 デフォルトの名無しさん [sage] 2010/03/27(土) 21:36:11 ID: Be:
    「初めての人のためのLISP」を流れでgetしちゃったんだけど
    これホントに初めての人に最適でしょうか?
    他に良い書籍あったら教えてください。 

軍オタが好きな名言、名ゼリフ 6 
532 名無し三等兵 [sage] 2010/03/26(金) 19:51:57 ID:??? Be:
    苦しいこともあるだろう。

    言い度いこともあるだろう。

    不満なこともあるだろう。

    腹の立つこともあるだろう。

    泣き度いこともあるだろう。

    これらをじっとこらえてゆくのが
                      
    男の修行である。

    山本五十六 

533 名無し三等兵 [sage] 2010/03/26(金) 21:28:09 ID:??? Be:
    >>532
    知人が就職試験の面接の時に相当嫌味な質問とかされたりして腹立ったらしいけど、偶然この言葉が書いてあった掛け軸?だかを見て堪えたって言っていたの思い出した 

536 名無し三等兵 [sage] 2010/03/27(土) 02:15:55 ID:??? Be:
    >>533
    そんなもん掛けてある時点で偶然じゃねえだろどう考えても…… 

538 名無し三等兵 [sage] 2010/03/27(土) 04:22:52 ID:??? Be:
    >>532-533
    こういう言葉を上の奴が下の奴に押しつけるようになった時が、
    その組織の衰退の始まりだな。
    下の方から自発的にこういうのが出てくるんなら、
    組織の発展の始まりなんだが…… 

542 名無し三等兵 [sage] 2010/03/27(土) 10:59:18 ID:??? Be:
    >>532
    このセリフに酷似したアニメのEDソングだったか無かった?
    昭和時代の。

    苦しいこともそりゃあるさ~♪

    泣きたいこともそりゃあるさ♪  みたいな曲が脳内で流れ始めたんだが。。 

543 名無し三等兵 [sage] 2010/03/27(土) 11:02:34 ID:??? Be:
    思い出した。

    トムとジェリー のEDだw 

544 名無し三等兵 [SAGE] 2010/03/27(土) 11:30:32 ID:??? Be:
    ひょっこりひょうたん島では? 

545 名無し三等兵 [sage] 2010/03/27(土) 18:25:07 ID:??? Be:
    苦しいことも あるだろさ
    悲しいことも あるだろさ
    だけど ぼくらは くじけない
    泣くのはいやだ 笑っちゃお
    進めー 

546 名無し三等兵 [sage] 2010/03/27(土) 18:31:51 ID:??? Be:
    ひょっこりひょうたんじーま♪
    ひょっこりひょうたんじーま♪
    ひょっこりひょーたんじーまー♪ 

547 名無し三等兵 [sage] 2010/03/27(土) 20:15:43 ID:??? Be:
    >>544
    すまん。 そうだw  

    エッセンス、パクっとるね。  

549 532 [sage] 2010/03/28(日) 04:11:12  ID:??? Be:
    >>542
    このスレの住人が自分と同じ世代だとわかってワロタw

■_ 本日の巡回から

2010年03月27日

■_

厚い、でかい、でも安い
書店で Amazon.co.jp: ゲームコーディング・コンプリート 一流になるためのゲームプログラミング を確認。 これはその方面(どれ?)の人には必読ものじゃないかなあ。 いや、原著の評判とか知らんのですけど。 ざっと目を通しただけなんでちと無責任な物言いですが、ゲームプログラミングは関係ない。 やらない。という人も、読んでみると得るところが多いんじゃないでしょうか。 といいつつ、わたしはまだ買ってなかったりします。 だって、大型本(でしかも800ページ超と分厚い)は置き場所に困るんですよ、マジに ○| ̄|_

・ヴェネツィア
もう一つ書籍ネタ。 「ローマ人の物語」の種本?「ローマの歴史」: わたしが知らないスゴ本は、きっとあなたが読んでいる を読んでふと思ったんですが、 塩野は学習院出の保守派ですから。ちなみに彼女、寡頭制のベネチア共和国の歴史も書いてますが、そちらの著作でもベネチアの負の面には触れず寡頭制を称揚する態度なのは同じです。 負の側面ってどんなのだろうなあ、何かでまとまって読めるものがあるかなあとか思ったり。 いくつか想像できなくはないんですが。

・反三国志
んで、話をさらに広げるw どのくらいの人が読んだことがあるのか見当がつきませんが、 「反三国志」という作品があります。 どういう作品かというと、世に伝わっている三国志(三国志演義)のお話は 真っ赤な偽物で、実は蜀漢が天下を統一しました。って話なんですが (大体関羽の死のあたりから話がねじまがってwいきます)、 読んでみてすげー辛かった(笑) これでもかってくらい蜀漢陣営を持ち上げておいて、魏(と呉)は… なんというか「妄想全開」なストーリー全開でした。はい。 んで、それからは三国志演義(とそれを下敷きにした小説など)でさえ、 蜀漢びいきが鼻についてまともに読めなくなってしまいましたとさ(苦笑) あと、ビジネス書wやらで、~に学ぶとか良くありますが、 あれで正史にはない、演義の作り話を「実話」としてあれこれ偉そうに書かれているのを 読むともう笑いしか出ません。 そういやあ姜維を主役に据えた小説を見かけたけど、あれもどうだかなあ。 一般的に云って、蜀漢陣営の人物の評価は高すぎると思うけどねえ (もちろん例外もあるけど)。

・理系の人々2
買った。読んだ。 心を込めたコピペや目視で3000件の入力チェックとか泣けた。 まあ、ああいう扱いされれば腐るよねえ。
理系の人々 2

■_ 七つの

Seven Languages - takkan_mのNo planな日常 から。 まあすぐに翻訳されそうな気もするんだけど。


The Pragmatic Bookshelf | Seven Languages in Seven Weeks

About this Book

Ruby, Io, Prolog, Scala, Erlang, Clojure, Haskell. With Seven Languages in Seven Weeks, 
by Bruce A. Tate, you'll go beyond the syntax—and beyond the 20-minute tutorial you'll
find someplace online. This book has an audacious goal: to present a meaningful 
exploration of seven languages within a single book. Rather than serve as a complete 
reference or installation guide, Seven Languages hits what's essential and unique 
about each language. Moreover, this approach will help teach you how to grok new 
languages.

For each language, you'll solve a nontrivial problem, using techniques that show off 
the language's most important features. As the book proceeds, you'll discover the 
strengths and weaknesses of the languages, while dissecting the process of learning 
languages quickly—for example, finding the typing and programming models, decision 
structures, and how you interact with them.

Among this group of seven, you'll explore the most critical programming models of our 
time. Learn the dynamic typing that makes Ruby, Python, and Perl so flexible and 
compelling. Understand the underlying prototype system that's at the heart of 
JavaScript. See how pattern matching in Prolog shaped the development of Scala and 
Erlang. Discover how pure functional programming in Haskell is different from the Lisp 
family of languages, including Clojure.

Explore the concurrency techniques that are quickly becoming the backbone of a new 
generation of Internet applications. Find out how to use Erlang's let-it-crash 
philosophy for building fault-tolerant systems. Understand the actor model that drives 
concurrency design in Io and Scala. Learn how Clojure uses versioning to solve some of 
the most difficult concurrency problems.

It's all here, all in one place. Use the concepts from one language to find creative 
solutions in another—or discover a language that may become one of your favorites.

ふむふむ。 あー、iPhone に転びそうだ。

■_ C

新刊やら近刊をチェックしてて見つけたもの。 C の本で翻訳ものかあ珍しいなあなどと思いつつ

Amazon.co.jp: 標準講座 C: スティーブン・G・コーチャン, 中尾 真二: 本
登録情報

    * 大型本: 544ページ
    * 出版社: 翔泳社 (2010/4/15)
    * 言語 日本語
    * ISBN-10: 4798119717
    * ISBN-13: 978-4798119717
    * 発売日: 2010/4/15"

元の本どんなんだろうとおもって調べてみたら、これっぽい。 Amazon.com: Programming in C (3rd Edition) (0752063326664): Stephen G. Kochan: Books

Amazon.com: Programming in C (3rd Edition) (0752063326664): Stephen G. Kochan: Books
Editorial Reviews

Product Description

Learn C programming from one of the best. Stephen Kochan's Programming in C is 
thorough with easy-to-follow instructions that are sure to benefit beginning 
programmers. In its third edition, the style in this book remains true to the simple, 
instructional style of previous editions. It provides you with updated and relevant 
examples of how C programming can be used with small, fast programs, similar to the 
programming used by large game developers such as Nintendo. If you want a 
one-stop-source for C programming, this book is it!

Programming in C, Third Edition is a revised edition of a classic programming title. 
Author Stephen Kochan's style and thorough explanations have earned him a place among 
the most respected of computer book authors. Although the C programming language 
hasn't undergone any major changes, it's enjoying new life among game programmers and 
small device programmers, where its simple elegance makes it the ideal choice for 
small fast programs. Large game developers, such as Nintendo, use C almost exclusively. 
This edition combines the time-tested instructional style of Stephen Kochan with 
updated and relevant examples.

(略)

表紙に見覚えがあるなあ。新宿のジュンク堂辺りで見かけたような。

■_ ハードとソフト

本題じゃないところなんですが。


製造業とソフトウエア/トヨタ・リコール問題を考えるにあたって - 風観羽 情報空間を羽のように舞い本質を観る

トヨタに限らず、日本の製造業の多くはソフトウエアを本業として取組んで来たわけではないし、
ソフトウエアの国際競争力比較という観点でも、日本が劣位にあることは残念ながら今や事実と
して認めないわけにはいかない。(電機業界とて事情は同じだ。)特に高いレベルの業務に対処
できるソフトウエアエンジニアは質量ともに不足している。製造業の国際競争力の低下の見逃せ
ない原因の一つに『ソフトの弱さ』があることは明白だ。しかも、さらに問題なのは、そういう
製造業はソフトウエアエンジニアが喜んで入社し、活き活きと生きがいを持って働き、満足でき
る処遇を与え、定着させることができる環境とは考えにくいことだ。試しに、日本のトップレベ
ルのソフトエンジニアに、どの会社に入りたいか聞いてみればいい。大抵は、Googleであり、
Appleと答えるのではないのか。苦手な部分は外注なり、協業で切り抜ければいいではないか、
というのはこの場合に適当な議論ではない。会社のコアの部分を外注でまかなえるほど市場の競
争は甘くない。たとえば、Google対抗の企業を起こそうと考えた時に、エンジニアは全部外注で
まかなうとか言い出せば、頭がおかしいと思われるのが落ちだろう。

とある製造業の会社での話なんですが、 今から何代か前の社長が新入社員に対する訓示やらなんやらで、 「これからはソフトウェアの重要性は増すことはあっても減ることはない。 ハードウェアが右腕なら、ソフトウェアは左腕であり両方そろって云々」 などとおっしゃられてたんですね。 それからン年。どうなっているかというと…

おや、こんな夜中に誰か来たようだ。 というのは冗談ですが、 その話を嬉しげに友人にしましたらば、 「お前はだから考えが浅いというんだ。結局のところ『利腕』にはなれない ってことじゃないか」と(左利きの方ごめんなさい)。 当時も「ひでえ言い様だな、おい」と返したものの、その後の流れを見ると(省略されました)

■_ ぱすた

これも本題にまったく関係ないんですが


イーモバイル“解約”地獄: たけくまメモ
最近、マイケル・ダグラスの「ウォール街」という映画Dで観たら
マーティ・シーンがチャーリー・シーンと

「ママの作るスパゲッティは不味い」
「パパ、スパゲッティなんて今は言わないんだ、パスタって言うんだよ」

というシーンがありました。

パスタっつーのはアメリカの金ぴか80年代ヤッピー達のグルメ文化から広がっていったコトバ
ではないかと思いました。

知らなかった。ヤンキーも(スパゲッティを)パスタやら云うのか。 って字幕はそうでも実際のせりふは違うとかはないんだろうか。

■_

板違いのおかげで偶然発見

書店員の情報交換スレ43
779 マロン名無しさん [sage] 2010/03/27(土) 22:59:42 ID:??? Be:
    コンピュータ書だけど、アスキーの配本多すぎじゃない?
    あんなに置けないし、1週間後には7割返すんだけどあんなに刷って大丈夫なのか 

780 マロン名無しさん [sage] 2010/03/27(土) 23:11:37 ID:??? Be:
    >>779
    一般書籍板にもスレあるよ

    書店統合スレッド 本屋のホンネ 第52刷
    http://love6.2ch.net/test/read.cgi/books/1268549256/ 

781 マロン名無しさん [sage] 2010/03/27(土) 23:58:47 ID:??? Be:
    ここは、漫画板だからな。 

アスキーといえば、The Art of Computer Programming の1がどうとかいう話を見たなあ。

■_ re2

ソースコードのtar 玉配布してないので手に入れるのに手間かかったけど、 まだ見てないや


Cygwin + MinGW + GCC 相談室 Part 5 
12 デフォルトの名無しさん [sage] 2010/03/25(木) 02:39:43 ID: Be:
    Google RE2 ビルド可能ですか? 

13 デフォルトの名無しさん [sage] 2010/03/25(木) 07:02:35 ID: Be:
    もちろん 

15 12 [sage] 2010/03/25(木) 10:27:55 ID: Be:
    *.aが出来たんですが、mingwでDLLにするにはどうしたらいいですか 

16 12 [sage] 2010/03/25(木) 11:17:27 ID: Be:
    エクスポートする関数のdefファイル作らんとだめですか。
    どれが必要なのかわからないときは片っ端にやるんですか 

17 デフォルトの名無しさん [sage] 2010/03/25(木) 12:14:17 ID: Be:
    他環境でDLLとか.soを作ったことあるの?
    基礎がわかってないと、エクスポートしてから動かなくなって
    ナニが悪いのかわからなくなるオカン。 

20 12 [sage] 2010/03/25(木) 20:00:25 ID: Be:
    自動ではエクスポートされないな
    defか関数前にエクスポートの表示書くしかないか
    えらく面倒 

21 デフォルトの名無しさん [sage] 2010/03/25(木) 20:02:01 ID: Be:
    ヘッダファイルからもれなく関数名抜き出すツール無いですか
    そしたらdef作れるんですが 

22 デフォルトの名無しさん [sage] 2010/03/25(木) 20:10:32 ID: Be:
    オーバーロードしているので
    __declspec(dllexport)でないと駄目そう 

23 デフォルトの名無しさん [sage] 2010/03/25(木) 21:39:54 ID: Be:
    DLLのGoogleRE2は需要ある
    ビルド求む 

24 デフォルトの名無しさん [sage] 2010/03/25(木) 22:34:47 ID: Be:
    MSYSの派生ビルドとかないのかな? 

25 デフォルトの名無しさん [sage] 2010/03/26(金) 01:22:22 ID: Be:
    >>23
    cvs -d :pserver:anoncvs@sourceware.org:/cvs/pthreads-win32 checkout pthreads
    hg clone https://re2.googlecode.com/hg re2
    cd pthreads && make clean GC && cd ..
    cd re2 && gunzip -c < ../re2_hg_20100326.diff.gz | patch -p1 && make && cd ..

    ↓をuudecodeね。
    begin-base64 0 re2_hg_20100326.diff.gz
    H4sIAAAAAAAAC+1WbW/bNhDu1+hXXLC0sCtTb47lWokBZ27SBUi7Iu6wfigQ
    UBJtq5FJg6TWeEP++460ktixkxVFsRVY7oNEHnl3D5+7oyRZdDGdXERBGATt
    KPbyYjx+9p0FXcdxDM8CK3dvWEo7DvchDNudqBu0O+0IcLLf6cL3hrFdKqWp
    REhSCP3vRPyhxOQbiIR4TDv7vTRtpyyHt/SSjYuSOYQQoP7NdOdEFrgmIexB
    FCadOMHEmcoBEnSDwHFdF9LN3VEMQZB0OkkQL3e7QQ93DwZAolYXXPMYDBz4
    CX5TDMQY9LRQoEQlMwaZyBngdCL+YJIjtnQBFH4evSZKLxAhWpVFxjha6inV
    kFEOKYOxqHgOBUclg7PT4fG70TEYVJ4DDqFlmYBIP/tlkUoWedRxN1Srk7ws
    0QxDaQFpVZQ50AktuNLwfniOfoUEzZQu+ARwmDKeTWdUXuK8ZawqnonZjHFt
    0XB2hYMvAnFzpiwNYbcVg4vPV5aIo/OTs6M3o75UmQPv3vb5zLyWOjJ33OHH
    j3bi9oGcep4/11PJaK4c9+z1zcKK2pyiHr8ZmsPiUX45OT07HvU/ObBT6aL0
    qWScetNPSzjhK4snClo9C2hnMLvMCwlkbljB+V7j6LwJ5mnjNdeZ22v8at03
    MZK7TmOysujuTLIMiJpi8ByIuMf43U4c1QdrAimVzjMsNPJ72SJEVJoUszla
    tdatTU4d69Fkxn++Jbk48uu0+c89gVE+HI8+3MQ0Oyw1Zosn7pNg1ZaJ4bBp
    wO8NNpzuvfwnr+ugSFmnafXAZmiqrOlsbVUTT2mJ4eYFy5g3rXt2Q/91zfuw
    2SNdjLc1Vq5rXrGtF4CR9fHe+ABVpeiyoYo/2YVezBnMhWrB3ZRDHzjqmtjs
    2FMHDlwfmC69BvB94HTG1JyiH8TmEAdSIUoQcyapFrLfb1gjs5gkK1FfwFUL
    HlpaNE0AvB5MC6473P1Gh/BX3cmhbZ24V/cy4G5dSQ67jSs4XEa+Nn2x7XRY
    sajDq0h8WWPQXDsMSjGZsNwBvD/wKgTsgyQRyCyjsxe3+A8PG/cWHkZtU2yp
    2Fpatk5XiyHL6uLasvJ15fWY4WMFZr8T4c2H4pZTUZNJttfE9uxtJs615paf
    b/aBoAq84EtmqvnKM9XdMNSiegwNo97tw6LW1wa35xjTUrED57/+F3iSJ3mS
    /5f8DfpBoAoADgAA
    ==== 

26 デフォルトの名無しさん [sage] 2010/03/26(金) 01:45:53 ID: Be:
    サンクス
    できたら報告しますね 

27 デフォルトの名無しさん [sage] 2010/03/26(金) 02:02:42 ID: Be:
    >>25
    駄目だったよ。
    自分がやったのと同じサイズの同じエクスポートのDLLが作られた。
    必要な関数がエクスポートされていないんです。 

28 デフォルトの名無しさん [sage] 2010/03/26(金) 02:04:47 ID: Be:
    これが動けばいいんですが

    #include <iostream>
    #include "re2/re2.h"
    #pragma comment(lib, "libre2.lib")
    using namespace std;

    int main(){
    int number;
    RE2::FullMatch("abc", "[a-z]+(\\d+)?", &number);
    } 

29 ◆grDYeooZwg [sage] 2010/03/26(金) 08:24:07 ID: Be:
    >>24
    派生じゃないが、詰め合わせたものならある。追加したり削除するのめんどいし。
    http://file.logue.be/dl/f/AwnFXj4p87

    ※インストーラーのpostinstallにバグあり。 

30 デフォルトの名無しさん [sage] 2010/03/26(金) 16:57:18 ID: Be:
    >>28
    gccで作ったC++なDLLはVisual C++とかからじゃ使えない(名前修飾その他)
    んで、DLL化するメリットはあまりないかも。
    ↓Visual C++ でコンパイルするためのファイル(バイナリも付属)。
    ttp://www1.axfc.net/uploader/Sc/so/96674.7z
    強引にコンパイルとかやってるんで、動作保証なし。 

31 デフォルトの名無しさん [sage] 2010/03/26(金) 20:45:35 ID: Be:
    サンクス
    libの競合が起こったけど何とかやってみます。あと無いエクスポートが一つ出たけど
    前よりかは良くなりました。原因解明していきます、 

32 デフォルトの名無しさん [sage] 2010/03/26(金) 21:11:44 ID: Be:
    STL使わないでC言語のみならコンパイルと実行は出来たけど
    肝心の正規表現が動いてない。
    だれか>>30動作したひといますか。
    mingwのDLLはvc++で読めるはずなんですが。 

33 デフォルトの名無しさん [sage] 2010/03/26(金) 23:13:46 ID: Be:
    >>30のエクスポートし過ぎをちと修正。
    ttp://www1.axfc.net/uploader/Sc/so/96798.7z

    うちでは>>28が普通に動くけど。"abc123" とかじゃないから、
    numberは不定になるが。 

34 デフォルトの名無しさん [sage] 2010/03/26(金) 23:39:37 ID: Be:

    char c, f;
    f=RE2::FullMatch("redcap 100", ".*([0-9]*)", &c);
    printf("%d\n",f); ここで0になっとる
    printf("%d\n",c); 

35 34 [sage] 2010/03/26(金) 23:53:44 ID: Be:
    関数のエクスポートは出来てるけど、return 0(失敗)なんだ。
    これは引数、呼び出し方の問題なのか。 

36 34 [sage] 2010/03/27(土) 08:31:54 ID: Be:
    ふたたびやったけど、コンパイルは通るが実行できない。リターン0。

    #include <stdio.h>
    #include "re2/re2.h"
    #pragma comment(lib, "libre2.lib")

    int main(){
    int f;
    char ch[100];
    f=RE2::FullMatch("redcap 100", "(.*)", ch);
    printf("%d\n",f);
    printf("%s\n", ch);
    } 

37 デフォルトの名無しさん [sage] 2010/03/27(土) 11:30:25 ID: Be:
    >>36

    流れ読まずにレス

    たしかmingwで使うmsvcランタイムとVCで使うランタイムが違う関係で
    returnでは値がうまく返せなかったと思う。
    グローバル変数をエクスポートしてその変数使って値を返すとかしないと
    無理かも。

38 デフォルトの名無しさん [sage] 2010/03/27(土) 22:37:02  ID: Be:
    MSYS-1.0.14-1に差し替えて作り直した。
    http://file.logue.be/dl/f/lvXniSkhMA
    今度は、postinstallもちゃんと動く。

    入っているもの:
    http://logue.be/MinGW.html#z9bb55a6 

39 デフォルトの名無しさん [] 2010/03/28(日) 03:38:36 ID: Be:
    >>38
    サンキュー。MSYSちゃんと動いたお

pthread 使うのか。

■_

2010年03月26日

■_

・溝の口
ついったが縁で知った人たちと鶏団子鍋食ってきました。

■_ 今日の巡回から

■_ shibuya.lisp#5

メモから。順不同。ごっちゃになってますw

defstruct
Gray Stream (オブジェクト指向的なストリーム)

シーランド公国からきました
キャラチェンジ
リスト ()
ベクター []
マップ {}
セット #{}
シーケンスとは first/rest/cons が定義されているもの
ref/atom/agent
エージェントに対する「信頼」
Lisp といえばEmacs Lisp
DSLといえばLisp
関数型言語はクセの強いものが多い
悪のいない楽園へ逃げ込んじゃった
地獄の門番 Monad
Haskell は使い手の手足を縛って夢の世界へいった言語
OCamlは

Ocaml ←→ Haskell

Clojureの思想
immutable は善
mutable は悪 時には必要 → だから使いにくいようにしておく
clojure-user.org つくりました

温故知新 MapReduce 80年代末
GPGPU ベクトル計算機

ペアノの公理

Nu
Objective-C

■_

くじけてアップロードする前に寝てしまいました(苦笑) レールガンは先週最終回だったしね!

2010年03月25日

■_

つぶやいて(?)みるもんだ
昨年末に What Should We Teach New Software Developers? Why? | January 2010 | Communications of the ACM すげー面白そうなんだけど、copyright ACMだし勝手に訳しちゃまずいよなあ。ぐし。 などと愚痴ったりしたわけなんですが、これを、 すぽすっぽ先生ばかりかACMにもきちんと話を通して訳したという方が現れました。 何を新しいソフトウェア開発者に教えるべきか?なぜ? みなでありがたく拝読しませう。

■_ 単なる勘違いでした

油断するとつっこみががが。



melancholic afternoon
_s の戻り値としてそれが返ってきているのはなんかよろしくない気が
??? MSDNに

errno_t strcpy_s(
   char *strDestination,
   size_t numberOfElements,
   const char *strSource 
);
>正常終了した場合は 0 を返し、それ以外の場合はエラーを返します。
>実行の継続が許可された場合、これらの関数は EINVAL を返し、errno を EINVAL に設定します。

と明記されている以上, 問題は全くないように思いますが, 何にひっかかってらっしゃるのでしょう. 

はい。 記憶の中で strlcpy あたりと合体していました。

On-line Manual of "strlcpy

戻り値
    strlcpy() および strlcat() 関数は、それらが作成しようとした文字列の合計の
    長さを返します。 strlcpy() では、 src の長さを意味します。 strlcat() で
    は、初期の dst の長さプラス src の長さを意味します。これが多少混乱させる
    ように思われる一方、それは切捨て検知を単純にするために行なわれます。

正直な話、str*_s はほとんど使ってません ○| ̄|_ 使っても戻り値捨てちゃってるなあ。 いかんいかん。

そこの良い子は、こういうことをまねしちゃだめだよ!(笑)

■_ 今日の十

十戒。 あ、これ「じっかい」であって「じゅっかい」じゃないからね。 そこんとこよろしく。

The 10 Commandments of Being the Junior Programmer | Chad Stewart: Game Programmer
So it was written and so it shall be. I hand these down to you to do what you will with them.

   1. Thou Shalt Learn
       汝、学ぶべし

   2. Thou Shalt Learn Some More

   3. Remember the Code Review to Keep It Holy

   4. Understand Thy Code Base
       汝のコードベースを知れ

   5. Honor Knowledge, Keep Reading Books

   6. Thou Shalt Ask for feedback

   7. Thou Shalt Be Wrong

   8. Liketh Nike, Just Do It

   9. Thou Shalt Comment
       汝コメントすべし

  10. Thou Shalt Not Break The Build
       汝ビルドを壊すことなかれ

んーむ、「らしく」訳すのは難しい。

元記事には、それぞれの項目について説明文がこの後に続いてたりしますが それはまたの機会に。

■_ 本日の巡回から

■_ なぜわたしは X が好きでないのか

まずはふたつ


Why Perl is not my favourite programming language ≪ The Reinvigorated Programmer

Why Perl is not my favourite programming language
March 16, 2010

Ahem.

    Remember the following important rule: There is no rule that relates the behavior of
    an expression in list context to its behavior in scalar context, or vice versa. It 
    might do two totally different things. Each operator and function decides which sort 
    of value it would be most appropriate to return in scalar context. Some operators 
    return the length of the list that would have been returned in list context. Some 
    operators return the first value in the list. Some operators return the last value in 
    the list. Some operators return a count of successful operations.

    In general, they do what you want, unless you want consistency.

Larry Wall, the Perl functions manual page, perlfunc
  
Case closed. Possibly related posts: (automatically generated) * AjSharp programming language: a C#-like dynamic language * Returning values in PHP * Quibble, a Damn Small Query Langauge (DSQL) Using Python

Why C++ is not my favourite programming language ≪ The Reinvigorated Programmer

Why C++ is not my favourite programming language

March 16, 2010

Ahem.

    The body of a destructor is executed before the destructors for member objects. 
    Destructors for nonstatic member objects are executed before the destructors for base 
    classes. Destructors for nonvirtual base classes are executed before destructors for 
    virtual base classes. Destructors for nonvirtual base classes are executed in reverse 
    order of their declaration in the derived class. Destructors for virtual base classes 
    are executed in the reverse order of their appearance in a depth-first left-to-right 
    traversal of the directed acyclic graph of base classes; “left-to-right” is the 
    order of appearance of the base class names in the declaration of the derived class.

Bjarne Stroustrup, The C++ reference manual, section 12.4.
  
Case closed. Possibly related posts: (automatically generated) * Multiple Inheritance * C++ concepts * Destructor

どうも、言語の作者の発言やら著作での記述をとりあげているのかな? 読んでも理由がよくわからん ○| ̄|_ いやまあPerlのほうは思い浮かばないでもないけど。

2010年03月24日

■_

・日経ソフトウエア
BMPファイルを圧縮・解凍するプログラムを作ってみましょう …解凍?

■_ 岩波

このシリーズは自分もほめたことがががが。 でも今でも買えるところってほとんどないような希ガス。


推薦図書/必読書のためのスレッド 55 
399 デフォルトの名無しさん [sage] 2010/03/24(水) 13:22:26 ID: Be:
    おそらくここでは初出だと思うけど、岩波講座 ソフトウェア科学シリーズの

    『アルゴリズムとデータ構造』
    ttp://www.iwanami.co.jp/.BOOKS/01/1/0103430.html

    は傑作だと思う。岩波で、500ページ強で、なんかとっつきにくそうだと思うけど、
    実は基本的なアルゴリズムについてじっくり文章や図を使って説明している。
    アルゴリズムで躓く人って、薄くて簡単そうな本を選んで、その説明とかの飛躍
    でわかんなくなっていること多いと思うんだよね。
    この本はアルゴリズムの勉強の仕方とか、理解したとはどういうことかについて
    も著者の考えが書いてあって昔影響を受けた。
    もう昔の本だからあるのかな、と思ってたらまだあったので紹介。 

400 デフォルトの名無しさん [sage] 2010/03/24(水) 13:29:59 ID: Be:
    >>399
    Pascalが分からん 

401 デフォルトの名無しさん [sage] 2010/03/24(水) 13:36:52 ID: Be:
    >>400
    目次見たら、CとLispによるコードが付いてるみたいだ。 

402 デフォルトの名無しさん [sage] 2010/03/24(水) 13:42:41 ID: Be:
    >>400
    Algol系どうしなら見た目の違い何ぞ大した問題にならんと思うがなー。

403 デフォルトの名無しさん [sage] 2010/03/24(水) 14:10:37 ID: Be:
    >>401
    全部じゃないみたい。

    >>402
    Cが分かれば、コード追っていけるかな。

404 デフォルトの名無しさん [] 2010/03/24(水) 16:17:39 ID: Be:
    >>393 だけれど。錯綜してきたのでまとめて記す。
    GCの洋書
     ・Garbage Collection: Algorithms for Automatic Dynamic Memory anagement
     (ハードカバー) Richard Jones (著), Rafael Lins (著)
     ・改定版【決定版じゃないよ】
      Advanced Garbage Collection: Algorithms for Automatic Dynamic Memory
      Management (Chapman &\1 Hall/Crc Applied Algorithms and Data Structures
      Series) (ハードカバー) Richard Jones (著), Antony Hosking (著),
       Eliot Moss (著)
      当初2009年発売予定だったが、現在未出版。
      変に論文を漁るよりもはるかに身に着く。

      著者のWeb ページも参考にあたいする。

    >>399
       この本も読まずに、アルゴリズムを話してもしょうがないだろう。
       (日本人が書いたものでは、定番)
       記述言語が、Pascal、CL、Cなんて、アルゴリズムやデータ構造を
       論じる時に本質的に関係ない。

       岩波のこのシリーズは、今、読んでも十分通用する。 

405 デフォルトの名無しさん [sage] 2010/03/24(水) 16:19:35 ID: Be:
    左罹ってるけどね 

406 デフォルトの名無しさん [sage] 2010/03/24(水) 16:21:13 ID: Be:
    そういう理由で岩波を読みたくないやつは、一生一冊も読まんでいい。 

407 デフォルトの名無しさん [sage] 2010/03/24(水) 16:21:27 ID: Be:
    >>399
    どっかの大学で教科書に採用してたような希ガス 

408 デフォルトの名無しさん [sage] 2010/03/24(水) 16:27:56 ID: Be:
    アルゴリズムイントロダクションでもいいでしょ
    基礎の1巻は集中すれば1週間で終えられる 

409 デフォルトの名無しさん [sage] 2010/03/24(水) 16:29:40 ID: Be:
    あれ一週間で終わらせられる人はこんなとこいないよ。 

410 デフォルトの名無しさん [sage] 2010/03/24(水) 16:30:46 ID: Be:
    岩波講座  ソフトウェア科学
    ■構成 全17巻
    長尾 真,前川 守,川合 慧,
    所 真理雄,米澤 明憲 編集委員
    ソフトウェアの作成は人間的な作業で,信頼性や生産性の点でいまだに手工業の域にある.
    こうした現状をふまえ,ソフトウェア作成の方法を示すとともに,その理論と知識を整理し,新しい学問体系として提示する. 

411 デフォルトの名無しさん [] 2010/03/24(水) 16:33:46 ID: Be:
    >>407 へ
     >>393 >>404  だけれど、大学の教科書としてだけでもなく
     十分通用するよ。

      ソースコードを追いかけるのが、『アルゴリズムとデータ構造』の
      本質じゃないだろう。図と的確に記述できる疑似言語があれば
      十分じゃやないのか。
      実装段階で、処理系を通るように書き換えるだけのはなしでは。
      全体からみれば、それは、些末な話し。
      

412 デフォルトの名無しさん [sage] 2010/03/24(水) 16:43:41 ID: Be:
    >>404
    すまん、ガチで改訂と決定を見間違えてたwww
    Advancedってついてるが続編じゃなくて改訂なのね 

413 デフォルトの名無しさん [] 2010/03/24(水) 19:36:29 ID: Be:
    >>412へ

    >>404だけれど、決定版はないでしょう。


    著者  Richard JonesのWeb ページも参考あれ。 

414 デフォルトの名無しさん [sage] 2010/03/24(水) 19:47:06 ID: Be:
    ロベールは良書だよ 

415 デフォルトの名無しさん [sage] 2010/03/24(水) 19:50:22 ID: Be:
    >>399,404
    個人的には
    『定本 Cプログラマのためのアルゴリズムとデータ構造』
    で実用性は十分だと思っていますけど、この本(あるいは同等のレベルの本)と比べて
    具体的にはどういったところが優れていますか?
    そして、アルゴリズムの専門家でない普通のプログラマにとって、改めて読むほどの価値は
    ありますか? 

419 デフォルトの名無しさん [] 2010/03/24(水) 22:09:00 ID: Be:
    >>415 へ >>393 >>404 >>411 >>413 だけれど。長文です。

    > 『定本 Cプログラマのためのアルゴリズムとデータ構造』
     も存在は否定しませんし、それで事足りるのであれば・・・。

     データ構造といえば、『配列・スタック・リスト・キュー・構造体・木』
     アルゴリズムと云えば『探索・整列・ 文字列の探索』  程度で終わってしまい、
     それを特定の言語でサンプルを示して解説する といった作りですよね、極論すれば。

     要は、最初にアルゴリズムありきで それを理解せずに、特定の
     プログラミング言語での記述例を記した本を読んでも底が浅いと
     思いますが。
     そういう意味で、岩波のあの本は、珍しくデータ構造や
     アルゴリズムが前面に出て、きちんと書かれています。

    > で実用性は十分だと思っていますけど、この本(あるいは同等のレベルの本)と比べて

     実用がなにを指すか不明ですが、現実の問題は、
     などのきれいな話し、ばかりではないでしょう。
     組わせて、問題に適した構造を作る必要があると思っています。
     
    > そして、アルゴリズムの専門家でない普通のプログラマにとって、改めて読むほどの価値は
    > ありますか?

     「アルゴリズムの専門家」 新しい問題やアルゴリズムを改良・発見する・計算量を考察する人
     「プログラマ」  上で書いたようなアルゴリズムを、特定のプログラミング言語で表現する人 
     
     と、定義すれば、岩波の本に書いてある程度の事を、身につけておくべきではないかと
     思います。なにも、『発見・改良しろ』とは思っていません。

      

421 415 [sage] 2010/03/24(水) 23:03:45 ID: Be:
    >>419
    返答ありがとうございます。
    ただ、喧嘩を売るようで申し訳ないですが(というかちょっと売りますけど)、
    もう少し具体的・論理的にお願いします。

    最も知りたいのは
    「データ構造やアルゴリズムが前面に出ている」とは具体的にどういうことか?
    ということです。

    それを書かずに「底が浅い」や「岩波の本に書いてある程度の事を、身につけておくべき」
    などと書いても意味がないでしょう。
    また、全体的に論理的な繋がりが感じられませんし、「実用がなにを指すか…」以下は
    文章にさえなっていません。

    プログラムという、ことさら論理性が求められる分野なのですから、こうしたコメントにも
    もう少し気を配るべきではないかと思います。 

422 デフォルトの名無しさん [sage] 2010/03/24(水) 23:11:22 ID: Be:
    >>421
    氏ね 

423 デフォルトの名無しさん [] 2010/03/24(水) 23:13:05 ID: Be:
    氏ね言われてもしょうがないwww 

424 デフォルトの名無しさん [sage] 2010/03/24(水) 23:13:52 ID: Be:
    >>422
    お前がshine
    カスが 

425 デフォルトの名無しさん [sage] 2010/03/24(水) 23:26:04 ID: Be:
    >>421
    横から答えるよ。
    単純にこんなアルゴリズムがありますよ、オーダーはこれこれですよ。
    普通はこのアルゴリズムを使いましょうね、じゃないということ。
    例えば、整列だと、
    整列の基本アルゴリズム3つの問題点、
    素直な改良を試みる、分割統治で考える。
    それぞれのところで改良を計る。 

426 415 [sage] 2010/03/24(水) 23:33:09 ID: Be:
    >>425
    ありがとうございます。
    ただ、定本の方もそれに近い構成になっています。
    特に「文字列探索」は顕著で、最後は正規表現まで(プログラム例付で)載っています。
    そういった点で他の類似書よりも優れていると思っています。 

427 デフォルトの名無しさん [sage] 2010/03/24(水) 23:42:27 ID: Be:
    定本よりずっと細かいところまで解説してるよ。
    本屋で確認して来いというか、俺も言ってやるが氏ね。 

428 デフォルトの名無しさん [sage] 2010/03/24(水) 23:46:19 ID: Be:
    もう満足したみたいだし流そうぜ 

429 デフォルトの名無しさん [sage] 2010/03/24(水) 23:47:05 ID: Be:
    >>427
    お前も具体的に言えよ
    それにそこらの本屋には置いてないだろ
    お前も氏ねよ 

定本~で実装した正規表現は「実用的」かつーとちょっと疑問だけどなあ。 NFAを経由してDFAまで変換するんだけど、 そのDFAでは単純な linked list を使ってたりするのでねえ。 分かりやすくはあるんだけど、DFAにしている意味がなくなりかねないような。

推薦図書/必読書のためのスレッド 55
432 デフォルトの名無しさん [sage] 2010/03/25(木) 00:51:54 ID: Be:
    >>399
    の本は扱っている範囲としては定本とそれほど変わらないんだよね。
    ただPascalとか擬似コードを使っての解説がやたら詳しい。あえて広さより深さを
    選んだ感じ。初学者は絶対こっちの方がいいと思うが、印象から初学者が手に
    取りづらいという残念な結果になっていると思う。
    岩波って他にも結構良書でていると思うが、あんまり取り上げられないよな。
    埋もれた名作あれば紹介希望。 

433 デフォルトの名無しさん [sage] 2010/03/25(木) 00:55:48 ID: Be:
    お前が紹介しろよ 

435 デフォルトの名無しさん [] 2010/03/25(木) 01:37:47 ID: Be:
    >>421 へ >>419 から。
    両方の本が机の上にあって読み比べてみた。

    レスがついたようだけど、非論理的な文章と言われたので補足する。

    ・前面に出ている ⇒ >>425 ,>>427 、特に>>432 で云われている通り。

      やたら詳しいんではなく、あの程度は消化していないと、現実の少し大きな
      プログラム(実用的なプログラム)を作る時に、使うべきアルゴリズムや
       データ構造をきちんと、自分で吟味して設計出来いないと考えている。
       アルゴリズム・データ構造は抽象的なもので、プログラム言語と切り離して
       考えるべきだと思う。プログラム言語はそれを具現化する一手段に過ぎない。

       プログラムを作るというのは、コードを書く事ではなく、問題の解法(アルゴリズム)を
       記述する事であり、その対象を表現するのがデータ構造である。
       

      定番本?を否定はしないが、比較すると、一実装例を解説しているように
      すぎないとの印象が深い。

      あと、定番本?は、グラフ構造、ダイナミッックプログラミング等の
      記述が欠けている。

■_ GNU grep

2.6 でてた。

NEWS:

GNU grep NEWS                                    -*- outline -*-

* Noteworthy changes in release 2.6 (2010-03-23) [stable]

** Speed improvements

  grep is much faster on multibyte character sets, especially (but not
  limited to) UTF-8 character sets.  The speed improvement is also very
  pronounced with case-insensitive matches.

** Bug fixes

  Character classes would malfunction in multi-byte locales when using grep -i.
  Examples which would print nothing for LC_ALL=en_US.UTF-8 include:
  - for ranges, echo Z | grep -i '[a-z]'
  - for single characters, echo Y | grep -i '[y]'
  - for character types, echo Y | grep -i '[[:lower:]]'

  grep -i -o would fail to report some matches; grep -i --color, while not
  missing any line containing a match, would fail to color some matches.

  grep would fail to report a match in a multibyte character set other than
  UTF-8, if another match occurred earlier in the line but started in the
  middle of a multibyte character.

  Various bugs in grep -P, caused by expressions such as [^b] or \S matching
  newlines, were fixed.  grep -P also supports the special sequences \Z and
  \z, and can be combined with the command-line option -z to perform searches
  on NUL-separated records.

  grep would mistakenly exit with status 1 upon error, rather than 2,
  as it is documented to do.

  Using options like -1 -2 or -1 -v -2 results in two lines of
  context (the last value that appears on the command line) instead
  twelve (the concatenation of all the values).  This is consistent
  with the behavior of options -A/-B/-C.

  Two new command-line options, --group-separator=ARGUMENT and
  --no-group-separator, enable further customization of the output
  when -A, -B or -C is being used.

** Other changes

  egrep accepts the -E option and fgrep accepts the -F option.  If egrep
  and fgrep are given another of the -E/-F/-G options, they print a more
  meaningful error message.

* Noteworthy changes in release 2.5.4 (2009-02-10) [stable]

  - This is a bugfix release. No new features.

Version 2.5.3
  - The new option --exclude-dir allows to specify a directory pattern that
    will be excluded from recursive grep.
  - Numerous bug fixes

Version 2.5.1
  - This is a bugfix release. No new features.

yagrep にはあんまり関係なさげ。 正規表現マッチングの高速化つーても、エンジン取り替えちゃってるからなあ。

あとこれからの方針とか?

TODO:

  Copyright (C) 1992, 1997-2002, 2004-2010 Free Software Foundation, Inc.

  Copying and distribution of this file, with or without modification,
  are permitted in any medium without royalty provided the copyright
  notice and this notice are preserved.

===============
Short term work
===============

See where we are with UTF-8 performance.

Merge Debian patches 55-bigfile.patch, 69-mbtowc.patch and
70-man_apostrophe.patch.  Go through patches in Savannah.

Cleanup of the grep(), grepdir(), recursion (the "main loop") to use fts.
Fix --directories=read.

Write better Texinfo documentation for grep.  The manual page would be a
good place to start, but Info documents are also supposed to contain a
tutorial and examples.

Some test in tests/spencer2.tests should have failed!  Need to filter out
some bugs in dfa.[ch]/regex.[ch].

Multithreading?

GNU grep does 32-bit arithmetic, it needs to move to 64-bit (i.e.
size_t/ptrdiff_t).

Lazy dynamic linking of libpcre.

Check FreeBSD's integration of zgrep (-Z) and bzgrep (-J) in one
binary. Is there a possibility of doing even better by automatically
checking the magic of binary files ourselves (0x1F 0x8B for gzip, 0x1F
0x9D for compress, and 0x42 0x5A 0x68 for bzip2)?  Once what to do with
libpcre is decided, do the same for libz and libbz2.

==================
Matching algorithms
==================

Check <http://tony.abou-assaleh.net/greps.html>.  Take a look at these
and consider opportunities for merging or cloning:

(以下略)

いろいろあるんだなあ。

■_ 本日の巡回から

2010年03月23日

■_

・時差通勤
とある駅で、「時差通勤にご協力ください」みたいなポスターが貼られていたのですが、 あれって、わたしらみたいな実際に満員電車に押し込められる下々のものに見せるんじゃなくて、 勤務時間を決めてるえらい人に見せるべきなんじゃないですかね。 まあ見せてもどうにもならんだろうけど。 効率とか何とか云う理由で、F とか N とか C とかフレックスタイムを軒並み廃止しましたし。

■_ ツッコミいただきました

melancholic afternoon
3月22日_
str*_s系
>なんだこの 22 は
Invalid argumentを表すerrnoですね. *_s系は失敗するとerrnoが設定されるのでそれを見れば原因が分かる.

    printf("err%s\n", strerror(22));
    >Invalid argument

_snprintf_sでも同じです(cf. 例外ハンドラ).

なるほど 22 の意味はわかりましたが、 strcpy_s の戻り値としてそれが返ってきているのはなんかよろしくない気が。

        ret = _tcscpy_s(NULL, bytes, c ); //実行しないでください
        printf("ret=%d\n", ret);

ででた値なので。

めもがき:2010年3月22日分
○[C1X] *cpy_s in TR24731-1

_tcscpy_sネタ。

ISO/IEC TR24731-1[pdf]では以下の場合、set_constraint_handler_s(3)でセットした例外ハン
ドラを呼ぶことになってますな。

(手元のNetBSD用に 以前書いた実装をみて書いてるので最新は知らんがな)

    * 第1引数のコピー先がNULLの場合
    * 第2引数が0あるいはRSIZE_MAXの場合(VC++にはrsize_tがないのでどうしてるかは知りません)
    * 第3引数のコピー元がNULLの場合
    * 第1引数(コピー先)と第3引数(コピー元)がオーバーラップする場合

TR24731-1では例外ハンドラはデフォではNULLなのでそのまま処理続行のはず。
まぁVC++だとデフォでabort_handler_s(3)がセットされてるのじゃないでしょうか。

まぁそれはおいといて、元の質問見たけど

     numberOfElements

        コピー先の文字列バッファのサイズ。

をバイト数と勘違いする人がいるのだなぁと、あくまでコピー先の文字型の配列長でんがな。
これを誤植とかもうね(以下略

    int bytes = ( ( _tcslen(c) + 1 )*sizeof(TCHAR) );
    if ( fn = (TCHAR*)malloc( bytes ) ) _tcscpy_s( fn, bytes, c );

じゃなくて

    int len = ( ( _tcslen(c) + 1 ) );
    if ( fn = (TCHAR*)cmalloc( len, sizeof(TCHAR) ) ) _tcscpy_s( fn, len, c );

だぁね、つか長さ調べてその分アロケートするなら_tcscpy_s使う意味ないし、この関数は

    TCHAR buf[BUFSIZ];
    _tcscpy_s(buf, BUFSIZ, c); 

のように、固定長バッファをあふれさせないように使う関数だかんね。
リンク先の回答にもあるとおり動的割り当ておkなら _tcsdup() 使えと。 

そいや「誤植」も本来のところからびみょーに範囲が広がっている言葉な気が。

ためしにハンドラー登録関数に NULL を渡してみましたが、トラップされてアボートしました。 むーん。

■_ PHPって…

元ネタはまあ説明するまでもないですが


PHP 6 has been trashed... in its current state. : programming

PHP 6 has been trashed... in its current state. (news.php.net)


PHP has been trashed for years. Now it's starting to sober up and regret some of the 
things it did.


PHP is what happens when C knocks up m4.


Sounds like, as usual, it is more fun to write new features than to fix the Unicode problem.


It's actually an old topic in open source projects: there are some tasks where (nearly) 
everybody agrees that they are crucial, and still nobody actually does it, because 
it's hard, not very rewarding, or just not an interesting task.

If you declare that feature a blocker, then people will get frustrated, and either 
leave the project, or try to work around that blocker - sometimes by not obeying the 
rules.

So, what went wrong? I think it's wrong to promise a feature for a particular release, 
and stick to that promise even if it turns out not have enough support within the 
developer community of that project.

I am aware of the importance of Unicode, but if nobody implements support for it, well, 
then there will be none. Period. If people really care, they have to JFDI, or find a 
company who pays some developers to JFDI.

In most web apps, mb_* is sufficient. Lack of unicode strings by default would not be 
the number one reason to not use PHP (ask any experienced PHP dev).

PHP is just a (simple, yet powerful) tool and tools require skill to be used properly.

We only support Haskell and Python on reddit, because we are so cool.


I have a better one: 99% of users flame PHP on reddit, but only 1% of those 99% are actually programmers.


I have an even better one, we hate PHP because we actually had to use it.


It's hard not to laugh at PHP people though.

ひでえなあ、みんなして(笑)

■_ あえて書名とかは明かしませんが

くだすれFORTRAN(超初心者用)その4 
944 デフォルトの名無しさん [sage] 2010/03/21(日) 17:50:52 ID: Be:
    毎年入ってくる新入生がfortranを勉強しようと77の本を手に取るのを
    黙って見過ごすのはえも言われぬ空しさがある・・・
    嗚呼負のスパイラル 

945 デフォルトの名無しさん [sage] 2010/03/21(日) 19:03:59 ID: Be:
    Visual Basic のように簡単に Windows用 GUI アプリケーションが作れる Fortran のベンダーを知りませんか。
    Intel の Visual Fortran だとなんだか難しそうで‥‥。
    Absoft Pro Fortran や PGI Visual Fortran なら簡単にできますか?

946 デフォルトの名無しさん [sage] 2010/03/21(日) 20:51:54 ID: Be:
    >>944
    これ以上77なソースを増やさないでくれ
    たのむ 

947 デフォルトの名無しさん [sage] 2010/03/22(月) 08:06:59 ID: Be:
    >>945
    DEC神wの系列の quickwin 以上に簡単なもの無理じゃないかねぇ
    >>944,946
    wwww
    F77より後の機能をちゃんと間違えなく使おうとするとF77しらないと、
    ということも多いからね。LatexとTexみたいなもので知ってても困らん。
    まあ学生のうちに複数の計算機なり人間の言語に触れることは良い事だ 

948 デフォルトの名無しさん [sage] 2010/03/22(月) 12:52:03 ID: Be:
    >>947
    しかし、大概の77のテキストは

    100 FORMAT(1H , ・・・・・

    などとなっていて、「この1H っては何ですか?」などと聞いてこられるので、
    66から勉強しろとも言えず、ホレリスからイチイチ説明するのもメンドイので
    いい加減に流すのであった。ラインプリンタも見ることも無いし。


    テキスト書く人は、もう少し頑張って欲しい。
    ほとんど情弱化している。
    最近出た入門Fortranとか、g95とGNUPlotでFortranとか期待したのに、中身があまりに古くて爆死した。

949 デフォルトの名無しさん [sage] 2010/03/22(月) 13:25:00 ID: Be:
    なるほど、Hは・・・聞かれるといろいろ困るなw

    どこまで・どこからの線引きは難しいなあ。
    Doループも長~いやつだと意図して番号+Continueするとかあるし・・・
    gfortran -Wall
    だと年代wのチェックはしないしねぇ。いいチェッカがあるといいんだけど。

    教科書は・・・英字のも含めてあまり進歩はないような。
    教科書的なのは儲からんのだろうね。
    漫画でわかる・・とかでないといかんのかね。だれか
    「やる夫がFortranで何かするようです」でも作ってよ。 

950 デフォルトの名無しさん [sage] 2010/03/22(月) 13:58:59 ID: Be:
    やる夫がやる気のない教科書を参考にしたようなコードを書こうとする度に
    やらない夫のツッコミが入るとかw 

951 デフォルトの名無しさん [sage] 2010/03/22(月) 18:35:01 ID: Be:
    >>947
    >F77より後の機能をちゃんと間違えなく使おうとするとF77しらないと、
    “ちゃんと”学ぶのであればそれでいいんだけど、大半はそこまでの探求心を持たないんだよね。
    つーかこの手の問題はFortranに限った話じゃないのかもしれん・・・ 

952 デフォルトの名無しさん [sage] 2010/03/23(火) 04:15:24 ID: Be:
    (AA略)
    いまどき固定書式~
    固定書式が許されるのは50過ぎだけだよね~

    ・・・むかつくな 

Fortran90だか95の入門書なのに、 掲載されているサンプルプログラムがほとんど77のと変わらないんじゃないか? というのがががが。

■_

2010年03月22日

■_

・知らなかった
最近ちょっと気になる作家さんの 岩井三四二 - Wikipedia ですが、『簒奪者』学研(1999)(歴史群像大賞) これ覚えてる。 確かこの大賞の一回めだか二回目の受賞じゃなかったかなあ。

■_ ネタ

Rubyについて Part 39 
634 デフォルトの名無しさん [sage] 2010/03/22(月) 00:41:24 ID: Be:
    (´・ω・`)ノシ     (´∀`)ノ       (´・ω・`)ノシ     (´∀`)ノ         (´・ω・`)ノシ     (´∀`)ノ
    【おっさん】     【ヤング】      【おっさん】     【ヤング】        【おっさん】     【ヤング】
    アベック       カップル       チャック       ジッパー         サジ         スプーン
    ズボン         パンツ        ズック        スニーカー        汽車        電車
    ジーパン       デニム        ラッパズボン    ブーツカット       国鉄        JR
    割ぽう着       エプロン       喫茶店       カフェ           寝巻        パジャマ
    コールテン      コーデュロイ    チャンネル回す  チャンネル変える    シャッポ      帽子
    えもん掛け     ハンガー       Ruby        Python          前掛け       エプロン
    レコード       CD          デザート      スイーツ         突っかけ      サンダル
    スパゲッティ     パスタ        パンティ       ショーツ         トレパン       ジャージ
    とっくりセーター   タートルネック    ビフテキ      ステーキ         ランニング     タンクトップ
    セコハン       ユーズド       ハイヤー      タクシー         チョッキ       ベスト 

635 デフォルトの名無しさん [sage] 2010/03/22(月) 01:45:44 ID: Be:
    意外と役に立ちそうなリストだな
    ただこうやって並べると、その「ヤング」の方が語彙が少ないだけな気がしてくる不思議 

636 デフォルトの名無しさん [sage] 2010/03/22(月) 01:49:13 ID: Be:
    ジッパー → ファスナー
    ショーツ → パンツ
    かなぁ

    タクシーとハイヤーはそもそも別モンなんじゃないの? 

637 デフォルトの名無しさん [sage] 2010/03/22(月) 01:54:39 ID: Be:
    Ruby2.0には

    String#ossan
    String#yangu

    が追加されます。

638 デフォルトの名無しさん [sage] 2010/03/22(月) 02:01:18 ID: Be:
    "something".ossan.to_english.to_kana == "somethig".yangu 

639 デフォルトの名無しさん [sage] 2010/03/22(月) 02:32:47 ID: Be:
    ハイヤーは hire で、営業所待機してるのを呼びつけて使う。
    タクシーは流しで客待ちするもの。

    高級だから higher なんだと思っていた中学生の頃の思い出。

640 デフォルトの名無しさん [sage] 2010/03/22(月) 04:29:19 ID: Be:
    誰か突っ込んでやれ 

641 デフォルトの名無しさん [sage] 2010/03/22(月) 08:34:56 ID: Be:
    何かと思ったら、rubyとpythonを混ぜてあるのか
    それはともかく、たいそうエプロンが好きなようだから、「駐機場」とかも入れときゃいいのにな 

642 デフォルトの名無しさん [sage] 2010/03/22(月) 08:45:39 ID: Be:
    >>641
    ttp://alfalfa.livedoor.biz/archives/51518091.html 

表を見てつっこみたくなったことがあるのだけど、


じぇねれーしょんぎゃっぷ。:アルファルファモザイクだった

1012  学名ななし  :2009年10月28日 06:55  ID:yjgHjI8S0
パスタ ⊇ スパゲティ
1013  学名ななし  :2009年10月28日 06:55  ID:yjgHjI8S0
パスタ ⊇ スパゲティ

1024  学名ななし  :2009年10月28日 08:19  ID:C2bBNU.R0
スパゲッティーはパスタの一種だろうが

1044  学名ナナシ  :2009年10月28日 11:14  ID:2Uj82hpq0
だからパスタは誤用だろ

1072  学名ナナシ  :2009年10月28日 21:06  ID:H509AK1t0
おっさんがパンティって呼ぶのは
若者は インナー って呼ぶよ


パスタ=スパゲティもだけど
スイーツ(イタリア語)
デザート(英語)
なのにマスゴミがダサい言葉って変換して迷惑だよね
1073  学名ナナシ  :2009年10月28日 21:45  ID:KE.Da7Pc0
スイーツがイタリア語だったとは驚きだ
1074  学名ナナシ  :2009年10月28日 22:24  ID:T8wgd4ya0
ドルチェ…
1075  学名ナナシ  :2009年10月28日 22:40  ID:77whonsc0
スパゲティ結構太いの
リングィネうすべったいの
フィットチーネ平べったいの
カッペリーニほっそいの

いや米1072、パスタイコールじゃないだろ
ペンネもマカロニもラビオリもパスタだしょ
まー基本的に形が違うだけだがなっ!
1076  学名ナナシ  :2009年10月28日 22:42  ID:77whonsc0
ところで・・・ジレっておばあちゃんが言ってたんだぜ
二周くらい回ってきたんだな
ファッションリーダーさんからジレって聞くたびについ笑いそうになって困るわ
まあ普通の名詞だからおかしくはないんだけど、わざわざお洒落ぶって言うところがわらけてわらけてw

やっぱり他にも気になる人はいるんだ(笑)

■_

で、str*_s ネタをさらに。


Visual C++ 2005  C/C++ランタイム ライブラリ新機能概要

2005 年 12 月 8 日

はじめに

Visual C++の新しいランタイム ライブラリは 従来の標準ライブラリの多くの関数がもつセキュ
リティの脆弱性を解決します。

ここでは、Visual C++の拡張されたランタイム ライブラリやクラス ライブラリの機能を紹介します。


新しい関数の形式
デフォルトでは安全性が低い古い形式のC ランタイム ライブラリが使用されていた場合は、コ
ンパイル時に警告を表示します。開発者は表示された警告を確認し、使用している関数がコード
の安全性に影響を与えるかどうかを確認します。

新しいバージョンの関数は古いバージョンの関数名のあとに Secureを意味する _s の接尾語がつきます。
安全な新しい関数名は、従来の関数名の後に_sをつけるだけなので、容易に新しい形式の関数へ置き換えることができます。

_s がついた新しい関数は、バッファーのサイズに対する安全性の検証の他に従来リエントラン
トではなかった関数にはリエントラントな機能を提供します。

セキュアな関数の例
従来の関数 	セキュアな関数
strcpy 	strcpy_s
strncpy 	strncpy_s
printf 	printf_s
asctime 	asctime_s
ctime 	ctime_s

古い形式の関数を明示的に使用する際に、警告を表示しないようにすることができます。 警告 
4996をdisableにするように、プラグマを指定すると、古い形式の関数の使用警告を無効にする
ことができます。


  // 古い形式の関数の使用警告を表示しないプラグマ
  #pragma warning(disable : 4996) 

 

不正パラメータ処理のハンドラー定義

_set_invalid_parameter_handlerは入力パラメータ エラーが発生した場合に、標準Cランタイム
のパラメータ ハンドラをユーザー定義関数の実行へと変更します。

使用例


// ユーザー定義の不正パラメータ処理関数
void my_invalid_parameter_handler (const wchar_t* expression, 
                                   const wchar_t* function, 
                                   const wchar_t* file, 
                                   unsigned int line, 
                                   uintptr_t reserved) 
{ 
        wprintf(L"Invalid parameter detected in function %s. File: %s Line: %d\n",
                function, file, line);
 
        wprintf(L"Expression: %s\n", expression); 
}

int main(int argc, char **argv)
{
	_invalid_parameter_handler old_handler;

	old_handler = _set_invalid_parameter_handler(my_invalid_parameter_handler);

	// バッファの確保
	char buf[32];


ここでは、my_invalid_parameter_handlerがユーザーが作成したパラメータ エラー処理関数です。

パラメータの不正によるエラーが発生すると、ユーザーが定義した関数が実行されます。

(略)

このユーザー定義ハンドラーを書いてやれば終了せずに続行もできるのかな?


bytes=12
Invalid parameter detected in function (null). File: (null) Line: 0
Expression: (null)
ret=22

なんだこの 22 は。

■_ Why X is not my favourite programming language

何回かここでも紹介したことのあるblogだと思うんですが、 ここ数日で Why X is not my favourite programming language というパターンのエントリを沢山あげています。

読んでいる余裕がなっしんぐ ○| ̄|_

■_ 本日の巡回から

■_ C について

ついったから。


Twitter / かおりん: 十分な経験を積んだプログラマが使っても、C言語系は、 ...

十分な経験を積んだプログラマが使っても、C言語系は、メモリ破壊、メモリリークなどの地雷
が混入しやすい危険な言語ですよ。w


Twitter / かおりん: 今の時代、初心者/入門者に進めるのは言語道断だと思う ...

今の時代、初心者/入門者に進めるのは言語道断だと思うんですがね。まあ、仕事にするなら知
っといた方がいい言語ではありますけど。


Twitter / かおりん: C言語系を勧める人は、なんでGCなんて仕組みが出てき ...

C言語系を勧める人は、なんでGCなんて仕組みが出てきたのか考えた方がいいと思うな。


Twitter / かおりん: 仕事にするつもりなら、かなぁ。趣味でやるぶんにはやら ...

仕事にするつもりなら、かなぁ。趣味でやるぶんにはやらなくてもいいんじゃないかと最近は思
ってる。 RT @code_air_edge: @kaorin_linux 知ってた方がいいってことはやっぱ勧めやすいっ
てことじゃないかな? C#でもJavaでも、解説でよく「Cで言うと~」みた


Twitter / かおりん: 結構、仕事だと、C言語系って避けて通れない場面がある ...

結構、仕事だと、C言語系って避けて通れない場面があるので、これは必須と言ってもいいと思
うんだけど、新人とかに扱わせると、あとの修正が大変とか。w 趣味の範囲なら、わざわざイ
マサラという気はしてる。


Twitter / かおりん: C++はともかく、Cだと、じゃあアセンブラからか、と ...

C++はともかく、Cだと、じゃあアセンブラからか、とか思っちゃったりするんだけどね。まあ、
これは行き過ぎ。w

まだ「入門書」は C を使ったのが一番多いのかなあ。

2010年03月21日

■_

・本の処分に困る
スキャンするとかゆー話ではなく、 置き場所がないんだけどすぐに読む余裕はなくて でも読まずに捨てるのはどーよって話で、さてどうしよう。 Head First Statistics とか Java のデザインパターン本とか Effective C# とか More Effective C# とか。

あ、今日もなんだかんだで shibuya.lisp#5 の話を書く時間がががが ○| ̄|_

■_ 昨日今日の巡回から

■_ str*_s

_tcscpy_s(wcscpy_s)の第二引数って(1/1) | OKWave の話のつづき。

#define _UNICODE
#define UNICODE
#define WIN32_MEAN_AND_LEAN
#include <windows.h>
#include <tchar.h>

TCHAR *fn;

void
OMG(LPCTSTR c)
{

    int bytes =  (_tcslen(c) + 1 )*sizeof(TCHAR);
    int ret;
    
    printf("bytes=%d\n", bytes);
    if ( fn = (TCHAR*)malloc( bytes ) ) {
        ret = _tcscpy_s(fn, bytes, c ); //実行しないでください
        printf("ret=%d\n", ret);
    }
    else {
        return;
    }

    /* fnを使用 */

    free(fn);
    fn=0;

}

int
_tmain()
{
    OMG(_TEXT("HELLO"));
}

と、テキトーに _tmain() やら追加して試してみると、_UNICODEでもそうでなくても パラメーターによっては「_tcscpy_s()の中で落っこちる」(実態は strcpy_s か wcscpy_s) のが確認できました。んで、ソースをみると(2005のものです)

/***
*strcpy_s.c - contains strcpy_s()
*
*   Copyright (c) Microsoft Corporation. All rights reserved.
*
*Purpose:
*   strcpy_s() copies one string onto another.
*
*******************************************************************************/

#include <string.h>
#include <internal_securecrt.h>

#define _FUNC_PROLOGUE
#define _FUNC_NAME strcpy_s
#define _CHAR char
#define _DEST _Dst
#define _SIZE _SizeInBytes
#define _SRC _Src

#include <tcscpy_s.inl>

/***
*tcscpy_s.inl - general implementation of _tcscpy_s
*
*       Copyright (c) Microsoft Corporation. All rights reserved.
*
*Purpose:
*       This file contains the general algorithm for strcpy_s and its variants.
*
****/

_FUNC_PROLOGUE
errno_t __cdecl _FUNC_NAME(_CHAR *_DEST, size_t _SIZE, const _CHAR *_SRC)
{
    _CHAR *p;
    size_t available;

    /* validation section */
    _VALIDATE_STRING(_DEST, _SIZE);
    _VALIDATE_POINTER_RESET_STRING(_SRC, _DEST, _SIZE);

    p = _DEST;
    available = _SIZE;
    while ((*p++ = *_SRC++) != 0 && --available > 0)
    {
    }

    if (available == 0)
    {
        _RESET_STRING(_DEST, _SIZE);
        _RETURN_BUFFER_TOO_SMALL(_DEST, _SIZE);
    }
    _FILL_STRING(_DEST, _SIZE, _SIZE - available + 1);
    _RETURN_NO_ERROR;
}


となっていて、どーしたってオーバーラン起こして落ちるようには見えない。 なんだろなあと思いつつ、デバッグモードでコンパイルして落ちた場所を確認すると

_VALIDATE_STRING(_DEST, _SIZE);

で、例外ハンドラーに飛んでいました。んじゃあとさらにソースを追いかけると

/***
*internal_securecrt.h - contains declarations of internal routines and variables for securecrt
*
*       Copyright (c) Microsoft Corporation. All rights reserved.
*
*Purpose:
*       Declares routines and variables used internally in the SecureCRT implementation.
*       In this include file we define the macros needed to implement the secure functions
*       inlined in the *.inl files like tcscpy_s.inl, etc.
*       Note that this file is used for the CRT implementation, while internal_safecrt is used
*       to build the downlevel library safecrt.lib.
*
*       [Internal]
*
****/

#pragma once

#ifndef _INC_INTERNAL_SECURECRT
#define _INC_INTERNAL_SECURECRT

#include <internal.h>

(略)

/* validations */
#define _VALIDATE_STRING_ERROR(_String, _Size, _Ret) \
    _VALIDATE_RETURN((_String) != NULL && (_Size) > 0, EINVAL, (_Ret))

#define _VALIDATE_STRING(_String, _Size) \
    _VALIDATE_STRING_ERROR((_String), (_Size), EINVAL)

(略)

_VALIDATE_RETURN は別のファイルにあって、

internal.h

/*
 * Assert in debug builds.
 * set errno and return value
 */

#ifndef _VALIDATE_RETURN
#define _VALIDATE_RETURN( expr, errorcode, retexpr )                           \
    {                                                                          \
        int _Expr_val=!!(expr);                                                \
        _ASSERT_EXPR( ( _Expr_val ), _CRT_WIDE(#expr) );                       \
        if ( !( _Expr_val ) )                                                  \
        {                                                                      \
            errno = errorcode;                                                 \
            _INVALID_PARAMETER(_CRT_WIDE(#expr) );                             \
            return ( retexpr );                                                \
        }                                                                      \
    }
#endif  /* _VALIDATE_RETURN */

こんなの。コメントを信じると、 リリースモードなら例外を送出しそうにないんですが、うーむ。

strcpy_s really safe? in VC Language
strcpy_s really safe?
richard posted on Thursday, February 15, 2007 10:21 AM

I get a fatal error in both debug and release mode using strcpy_s function
with the following code.
Same problem in VS2005 and VS2005 SP1


char sTest[5];
strcpy_s(sTest,5,"0123456789");

I think it should in this case only copy the 4th first characters together
with a '\0' character at the end...but having my application crashing is
quirte unexpected!


strcpy_s really safe?
P.J. Plauger posted on Thursday, February 15, 2007 11:58 AM

strcpy_s in this case should report a runtime constraint violation,
which may be the "crash" you're witnessing. If the constraint handler
returns, the function stores a null character at sTest[0] and returns
a nonzero value.

At least that's the behavior required by TR24731, and I think Microsoft
conforms in this regard.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
I cannot believe it's a normal behaviour getting a fatal error from strcpy_s
richard posted on Thursday, February 15, 2007 12:39 PM

The strcpy_s doens't returns anything, it just crashes
This function is quite easy to understand, it copies bytes by bytes as long
it doesn't overlap.
In case of buffer overlap, that is the case in my sample, it should return
something, at least a return value ....
I never saw so far a function that voluntarily make the program crash with a
fatal error!
This is not an exception, it cannot be even catched by try method

strcpy_s function :

_FUNC_PROLOGUE
errno_t __cdecl _FUNC_NAME(_CHAR *_DEST, size_t _SIZE, const _CHAR *_SRC)
{
_CHAR *p;
size_t available;

/* validation section */
_VALIDATE_STRING(_DEST, _SIZE);
_VALIDATE_POINTER_RESET_STRING(_SRC, _DEST, _SIZE);

p = _DEST;
available = _SIZE;
while ((*p++ = *_SRC++) != 0 && --available > 0)
{
}

if (available == 0)
{
_RESET_STRING(_DEST, _SIZE);
_RETURN_BUFFER_TOO_SMALL(_DEST, _SIZE);
}
_FILL_STRING(_DEST, _SIZE, _SIZE - available + 1);
_RETURN_NO_ERROR;
}

reply
strcpy_s really safe?
Arnie posted on Thursday, February 15, 2007 3:26 PM

Tou're misunderstanding how it's supposed to work.  Check the VS 2005
documentation for strcpy_s.  Especially the part that says:

If strDestination or strSource is a null pointer, or if the destination
string is too small, the invalid parameter handler is invoked as described
in Parameter Validation. If execution is allowed to continue, these
functions return EINVAL and set errno to EINVAL.
- Arnie
reply
strcpy_s really safe?
Tamas Demjen posted on Thursday, February 15, 2007 5:41 PM

The behavior that you're looking for can be implemented using strncpy.
Note, however, that strncpy won't NUL terminate your string if it runs
out of the buffer. Take a look at this:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_strncpy.2c_.wcsncpy.2c_._mbsncpy.asp

The strncpy function copies the initial count characters of strSource to
strDest and returns strDest. If count is less than or equal to the
length of strSource, a null character is not appended automatically to
the copied string. If count is greater than the length of strSource, the
destination string is padded with null characters up to length count.

What Microsoft calls a null character is actually a NUL (the '\0').

What you want to achieve can be done this way:

char sTest[5];
strncpy(sTest, "0123456789", 5);
sTest[4] = '\0'; // <- yes, this is necessary too!

Finally, there's also an strncpy_s function.

Tom
I cannot believe it's a normal behaviour getting a fatal error from strcpy_s
Tim Roberts posted on Friday, February 16, 2007 1:24 AM

No, it shouldn't.  strcpy_s is merely an implementation of strcpy, and the
ISO definition of strcpy says that the behavior when the strings overlap is
undefined.  That means it can do anything it wants, including crashing the
program.

What are you expecting it to do?


No, but it can certainly be detected before calling the function.  If you
need to strcpy overlapping strings, you'll need to do this:

int x = strlen(src);
memmove( dst, src, x+1 );
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

I cannot believe it's a normal behaviour getting a fatal error from strcpy_s
Ulrich Eckhardt posted on Friday, February 16, 2007 3:26 AM

Firstly, did you read and understand what this 'constraint handler' is? Now,
two things:
1. It's not strcpy_s that makes your program not work but it is your code.
You are simply supplying invalid parameters that, if used with strcpy,
would have invoked undefined behaviour but are caught by strcpy_s. It
doesn't change the fact that your code is buggy though.

2. When strcpy_s detects that the calling code is buggy (as it is the case
in your example), what should it do? Should it just do "something" and then
return to the caller, possibly facing buffer overruns and the resulting
exploits? No, when it detects this, it simply aborts the process, because
when the process is already in an inconsistent state, there is nothing left
it could do.

Without looking at TR24731, I guess that it first calls the constraint
handler, which still gives you a way to customise what happens.


Ah well, how many people check the returnvalue of functions that "obviously
can't fail" because "no user will ever enter something that is longer than
200 characters".


Then take a look at the assert() macro. Aborting when nothing is left to be
saved is the only sane way to handle such errors.


An exception in C? Or are you using C++, then I wonder why you aren't using
std::string anyway.


Uli

Thanks for your help tamas demjen, tim roberts and Ulrich, indeed your are all
richard posted on Friday, February 16, 2007 4:08 AM

Thanks for your help tamas demjen, tim roberts and Ulrich, indeed your are
all right.
I simply misunderstood the function


ぷろーがー先生のリプライに At least that's the behavior required by TR24731, and I think Microsoft conforms in this regard. ってあるんですよねえ。 そらまあ、忘れた頃にこけるよりは百倍ましなんでしょうけども。 でもそうだとしても、MSDNにある記述とつじつま合ってないんじゃなかろうか…

■_ これはいかねば


遠藤諭の東京カレー日記: パソコンの元祖TK-80・実演とシンポジウム

 東京理科大学近代科学資料館が、情報処理学会の「分散コンピュータ博物館」に認定されたの
を記念した一連の催しがあるのですが、これの第一弾が3月27日(土)の「パソコンの元祖TK-80・
実演とシンポジウム」です。この日の詳細がようやく決まってきました。

第一部:パネルディスカッション「TK-80とは何だったのか?」
 登壇者:後藤富雄(TK-80開発者)
     渡辺和也(TK-80プロジェクト責任者)
     榊正憲(『復活!TK‐80』著者)
     ※敬称略
 司会:遠藤諭(元『月刊アスキー』編集長/アスキー総研)

(略)

 個人的には、一連の催しの中で6月5日(土)・6日(日)に「タイガー計算機実演指導」も、
お勧め。これをやられるのが、機械式計算機の会(http://keisanki.on.coocan.jp/)の渡辺祐
三さんです。今回も、渡辺さんのお誘いでこのイベントに関わらせてもらうことになりました。

(略)

3/27 って次の土曜日かっ


一つ前へ 2010年3月(中旬)
一つ後へ 2010年4月(上旬)

ホームへ


Copyright (C) 2010 KIMURA Koichi (木村浩一)
この文書の無断転載はご遠慮ください(リンクはご自由にどうぞ)。

メールの宛先はこちらkbk AT kt DOT rim DOT or DOT jp