一つ前へ
2010年3月(中旬)
一つ後へ
2010年4月(上旬)
姜維
書店で見かけたので最初と最後だけちょっと読んでみた。
んーーーー、持ち上げすぎじゃね?
姜維一人が(無謀な北伐で)国を傾けたとは思わないけれども
(確か動員した兵力はかなり少なかったはず)、諸葛孔明の遺志を継いで云々というのはどうかなあ
とか書いてると命の危険を感じるので止める(笑)
・小説フランス革命
四巻読了。ミラボー退場。
40代前半で死んでたのかこの人は。
ロベスピエールの描写は後半はよくなってた?
さて、五巻買うぞ。
・今月の皇帝陛下
攻城戦
なにが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 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
金さえあればなんでもできるというが、どっちかというと、時間さえあればなんでもできる、と、言ったほうがなんかしっくりくるね。世の中時間だよ…
“TSVモード”“CSVモード”は、タブやカンマで区切られたテキスト形式のデータを、列ごとに縦を合わせて表示する編集モード。
マルチスレッドプログラミング相談室 その8 [chaika] 358 デフォルトの名無しさん [sage] 2010/03/29(月) 23:05:41 ID: Be: 「Java並行処理プログラミング」が増刷してる
へえ。
積んでるうちに次が出てしまった小説フランス革命の四巻(議会の迷走)を 読んでいるのですが、ロベスピエールの扱いというか描写が以下略
元記事のページにあるグラフを見ないとたぶん面白くないのでまずはそちらを 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: 何が理解出来ないのかマジで理解出来ないわｗ 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: 工学社は、、、言わなくてもわかるｗｗ 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: 大丈夫。ネイティブの連中も知らんからｗ使うと→(ﾟДﾟ)ﾊｧ? 507 デフォルトの名無しさん [sage] 2010/03/21(日) 03:16:06 ID: Be: なんでもかんでも for item in items でおｋ 508 デフォルトの名無しさん [sage] 2010/03/21(日) 03:44:56 ID: Be: >>506 いや、それは無いだろ・・・え、マジ？ 509 デフォルトの名無しさん [sage] 2010/03/21(日) 04:01:53 ID: Be: data/datasで意味わかるからおｋ 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 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
・パリは燃えているか
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 やりてー。
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:
長所はいろいろな場所で語られているので・・・デメリットをご紹介
もっと安全にするにはどうしたらいいかという事にはみんなエネルギーを注ぐけれど、そろそろこれくらいで十分なんでないのと、 過剰になっているんでないのと、安全でない側にものを考えることはなかなかしない。
しないというより、むしろそう言うことを言い出すと、万が一のことがあったらどうするんだと非難する傾向すらある。
LuaJIT 2.0.0-beta4 — 2010-03-28
しばらくBlogを休みましたが、その間に、Mac OS Snow Leopard上に関数プログラミング言語Haskellの環境の整備をしました。
JPerl is an implementation of Perl written in Java.
渾身の(でもないか)ネタが空振りするととっても悲しい。
推薦図書/必読書のためのスレッド 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: 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(\×2, 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.
って別にあったな
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
まさかの著者登場。
ふと見かけたついーと。
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だｗ 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 すまん。 そうだｗ エッセンス、パクっとるね。 549 532 [sage] 2010/03/28(日) 04:11:12 ID:??? Be: >>542 このスレの住人が自分と同じ世代だとわかってワロタｗ
特に、どうしてもなれないのが、 if --- end です。やはり { ----- } にしてもらいたいです。
♪ブルーレイ～の、蓋の裏にもあぶらむし～
厚い、でかい、でも安い
書店で
Amazon.co.jp： ゲームコーディング・コンプリート 一流になるためのゲームプログラミング
を確認。
これはその方面(どれ?)の人には必読ものじゃないかなあ。
いや、原著の評判とか知らんのですけど。
ざっと目を通しただけなんでちと無責任な物言いですが、ゲームプログラミングは関係ない。
やらない。という人も、読んでみると得るところが多いんじゃないでしょうか。
といいつつ、わたしはまだ買ってなかったりします。
だって、大型本(でしかも800ページ超と分厚い)は置き場所に困るんですよ、マジに ○|￣|＿
・ヴェネツィア
もう一つ書籍ネタ。
「ローマ人の物語」の種本？「ローマの歴史」: わたしが知らないスゴ本は、きっとあなたが読んでいる
を読んでふと思ったんですが、
塩野は学習院出の保守派ですから。ちなみに彼女、寡頭制のベネチア共和国の歴史も書いてますが、そちらの著作でもベネチアの負の面には触れず寡頭制を称揚する態度なのは同じです。
負の側面ってどんなのだろうなあ、何かでまとまって読めるものがあるかなあとか思ったり。
いくつか想像できなくはないんですが。
・反三国志
んで、話をさらに広げるw
どのくらいの人が読んだことがあるのか見当がつきませんが、
「反三国志」という作品があります。
どういう作品かというと、世に伝わっている三国志(三国志演義)のお話は
真っ赤な偽物で、実は蜀漢が天下を統一しました。って話なんですが
(大体関羽の死のあたりから話がねじまがってwいきます)、
読んでみてすげー辛かった(笑)
これでもかってくらい蜀漢陣営を持ち上げておいて、魏(と呉)は…
なんというか「妄想全開」なストーリー全開でした。はい。
んで、それからは三国志演義(とそれを下敷きにした小説など)でさえ、
蜀漢びいきが鼻についてまともに読めなくなってしまいましたとさ(苦笑)
あと、ビジネス書wやらで、～に学ぶとか良くありますが、
あれで正史にはない、演義の作り話を「実話」としてあれこれ偉そうに書かれているのを
読むともう笑いしか出ません。
そういやあ姜維を主役に据えた小説を見かけたけど、あれもどうだかなあ。
一般的に云って、蜀漢陣営の人物の評価は高すぎると思うけどねえ
(もちろん例外もあるけど)。
・理系の人々2
買った。読んだ。
心を込めたコピペや目視で3000件の入力チェックとか泣けた。
まあ、ああいう扱いされれば腐るよねえ。
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 の本で翻訳ものかあ珍しいなあなどと思いつつ
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対抗の企業を起こそうと考えた時に、エンジニアは全部外注で まかなうとか言い出せば、頭がおかしいと思われるのが落ちだろう。
とある製造業の会社での話なんですが、 今から何代か前の社長が新入社員に対する訓示やらなんやらで、 「これからはソフトウェアの重要性は増すことはあっても減ることはない。 ハードウェアが右腕なら、ソフトウェアは左腕であり両方そろって云々」 などとおっしゃられてたんですね。 それからン年。どうなっているかというと…
おや、こんな夜中に誰か来たようだ。 というのは冗談ですが、 その話を嬉しげに友人にしましたらば、 「お前はだから考えが浅いというんだ。結局のところ『利腕』にはなれない ってことじゃないか」と(左利きの方ごめんなさい)。 当時も「ひでえ言い様だな、おい」と返したものの、その後の流れを見ると(省略されました)
これも本題にまったく関係ないんですが
イーモバイル“解約”地獄: たけくまメモ 最近、マイケル・ダグラスの「ウォール街」という映画Ｄで観たら マーティ・シーンがチャーリー・シーンと 「ママの作るスパゲッティは不味い」 「パパ、スパゲッティなんて今は言わないんだ、パスタって言うんだよ」 というシーンがありました。 パスタっつーのはアメリカの金ぴか８０年代ヤッピー達のグルメ文化から広がっていったコトバ ではないかと思いました。
知らなかった。ヤンキーも(スパゲッティを)パスタやら云うのか。 って字幕はそうでも実際のせりふは違うとかはないんだろうか。
板違いのおかげで偶然発見
書店員の情報交換スレ43 779 マロン名無しさん [sage] 2010/03/27(土) 22:59:42 ID:??? Be: コンピュータ書だけど、アスキーの配本多すぎじゃない？ あんなに置けないし、１週間後には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がどうとかいう話を見たなあ。
ソースコードの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 使うのか。
この世界では批判される側に立ったことがない人は無責任に批判するものですし、批判されたことがある人は無責任に批判することはありません。また、成果がない人は批判すらされません。
どの言語も基本Ｃ言語がベースなので本来Ｃ言語から先にやったほうが良いです
少し前までは、自分の中ではJava一択だったのですが、昨今ではCOBOLの需要も相当あるらしいのですが、
コンクリート製でも「枕木」というくらいで、鉄道には素材や様式の伝統を受け継ぐ用語が多い。それも鉄道の面白さかもしれない。
お金を払うのは嫌。でもフリーも嫌。どうしたいんだあんたらは!
やさしい解説とわかりやすいイラストで、初心者も安心して読み進められます。この1冊があれば、C言語の一通りの機能をすべて身につけることができます。
十年近く前の処理系が未だに現役であること。
・溝の口
ついったが縁で知った人たちと鶏団子鍋食ってきました。
何という憂いを秘めた表情
2010年6月30日発売 ￥29,400(税込) ANZX-5071
3枚組のDVD-BOXながら8190円（Amazon価格は6061円）で販売される。
もう一つは、浮動小数点の取り扱いをIEEE（米国電気電子学会）準拠にすることです。
自信がない よく解らない 人に聞いてみよう ってな考えをするような人では駄目です
メモから。順不同。ごっちゃになってます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
くじけてアップロードする前に寝てしまいました(苦笑) レールガンは先週最終回だったしね!
つぶやいて(?)みるもんだ
昨年末に
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 汝ビルドを壊すことなかれ
んーむ、「らしく」訳すのは難しい。
元記事には、それぞれの項目について説明文がこの後に続いてたりしますが それはまたの機会に。
プリンタのメーカーは、技術情報をきちんとインクメーカーに開示して、 特定のプリンタに対して複数の対等な立場のメーカーが消費者にインクを提供するようにすべきではないでしょうか？ その方が、いろいろなインクが1つのプリンタで使えて、消費者としても便利です。
ゲームを作ってみようと思っているのですが、どこから手をつけていいか分からなくて困ってます。 プログラミングのスキルとしては一応授業でＣ言語をある程度やってあるレベルです。
上司がなにやら設定したようなのですが、こっそり解除する方法など無いでしょうか？
GNU findの-deleteオプション
Cygwin 1.7のutf-8環境
Jperlの功績は高く評価しているし、Perl 4の時代にはお世話になったこともあるので悪く言うつもりもないが、 パスを通すのもいやだからバイナリだけコピーしてまわりたいという要望に応えるような記事を連載に入れるつもりはない。 Jperlはバージョン的にも思想的にもモダンPerlのサポート対象外だ。
日時 2007年3月27日（土）13:00～17:00 会場 東京理科大学神楽坂校舎1号館17階記念講堂
これは、3月19日にリリースされたばかりの「一撃殺虫！ホイホイさん LEGACY 1/1 ホイホイさん 重戦闘ver.」のカラーバリエーション。
Perlはたくさんの誤解を受けている言語です。そのためにPerlを知らない人はPerlを過小に見て信用せず、 Perlを知っている人はPerlを過大に評価して平衡を失っています。
僕は今中学２年生で将来プログラマーになりたいと思っています。 今、僕はＣ言語を毎日２時間は勉強してるんですが、応用力がまったく身につきません、 やっぱりプログラミングには向き不向きがあるんでしょうか？
まずはふたつ
Why Perl is not my favourite programming language ≪ The Reinvigorated Programmer Why Perl is not my favourite programming language March 16, 2010 Ahem.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 PythonRemember 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
Why C++ is not my favourite programming language ≪ The Reinvigorated Programmer Why C++ is not my favourite programming language March 16, 2010 Ahem.Case closed. Possibly related posts: (automatically generated) * Multiple Inheritance * C++ concepts * DestructorThe 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.
どうも、言語の作者の発言やら著作での記述をとりあげているのかな? 読んでも理由がよくわからん ○|￣|＿ いやまあPerlのほうは思い浮かばないでもないけど。
・日経ソフトウエア
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 だけれど。錯綜してきたのでまとめて記す。 ＧＣの洋書 ・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年発売予定だったが、現在未出版。 変に論文を漁るよりもはるかに身に着く。 著者のＷｅｂ ページも参考にあたいする。 >>399 この本も読まずに、アルゴリズムを話してもしょうがないだろう。 （日本人が書いたものでは、定番） 記述言語が、Ｐａｓｃａｌ、ＣＬ、Ｃなんて、アルゴリズムやデータ構造を 論じる時に本質的に関係ない。 岩波のこのシリーズは、今、読んでも十分通用する。 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 すまん、ガチで改訂と決定を見間違えてたｗｗｗ Advancedってついてるが続編じゃなくて改訂なのね 413 デフォルトの名無しさん [] 2010/03/24(水) 19:36:29 ID: Be: >>412へ >>404だけれど、決定版はないでしょう。 著者 Richard JonesのＷｅｂ ページも参考あれ。 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: 氏ね言われてもしょうがないｗｗｗ 424 デフォルトの名無しさん [sage] 2010/03/24(水) 23:13:52 ID: Be: >>422 お前がshine カスが 425 デフォルトの名無しさん [sage] 2010/03/24(水) 23:26:04 ID: Be: >>421 横から答えるよ。 単純にこんなアルゴリズムがありますよ、オーダーはこれこれですよ。 普通はこのアルゴリズムを使いましょうね、じゃないということ。 例えば、整列だと、 整列の基本アルゴリズム３つの問題点、 素直な改良を試みる、分割統治で考える。 それぞれのところで改良を計る。 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 で云われている通り。 やたら詳しいんではなく、あの程度は消化していないと、現実の少し大きな プログラム（実用的なプログラム）を作る時に、使うべきアルゴリズムや データ構造をきちんと、自分で吟味して設計出来いないと考えている。 アルゴリズム・データ構造は抽象的なもので、プログラム言語と切り離して 考えるべきだと思う。プログラム言語はそれを具現化する一手段に過ぎない。 プログラムを作るというのは、コードを書く事ではなく、問題の解法（アルゴリズム）を 記述する事であり、その対象を表現するのがデータ構造である。 定番本？を否定はしないが、比較すると、一実装例を解説しているように すぎないとの印象が深い。 あと、定番本？は、グラフ構造、ダイナミッックプログラミング等の 記述が欠けている。
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: (以下略)
いろいろあるんだなあ。
ビジネスロジックの記述には、今後もCOBOLを使い続けます。他の言語にする必要は全く感じていません。理由は二つあります。
4歳の頃からネットと親しんできたというTehu氏は、いったいどんな感覚でリアル社会とネット社会をとらえているのか？ そして、世界中で支持されるアプリを開発した着眼点はどこからわいているのか。
バッファオーバーランなんて、カタカナ使うからいけないんですよ。不法侵入という立派な名称があるんですからｗ
こんな感じで、単純には小さなパターンではONIG_GREP = boost = PCRE = ONIG_RUBY >>> RE2で、 パターンが大きくなってくると ONIG_GREP > boost >> RE2 >>>>> ONIG_RUBY >> PCRE(しかも失格)と言う感じなのかな。
・時差通勤
とある駅で、「時差通勤にご協力ください」みたいなポスターが貼られていたのですが、
あれって、わたしらみたいな実際に満員電車に押し込められる下々のものに見せるんじゃなくて、
勤務時間を決めてるえらい人に見せるべきなんじゃないですかね。
まあ見せてもどうにもならんだろうけど。
効率とか何とか云う理由で、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); のように、固定長バッファをあふれさせないように使う関数だかんね。 リンク先の回答にもあるとおり動的割り当ておｋなら _tcsdup() 使えと。
そいや「誤植」も本来のところからびみょーに範囲が広がっている言葉な気が。
ためしにハンドラー登録関数に NULL を渡してみましたが、トラップされてアボートしました。 むーん。
元ネタはまあ説明するまでもないですが
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神ｗの系列の quickwin 以上に簡単なもの無理じゃないかねぇ >>944,946 wwww F77より後の機能をちゃんと間違えなく使おうとするとF77しらないと、 ということも多いからね。LatexとTexみたいなもので知ってても困らん。 まあ学生のうちに複数の計算機なり人間の言語に触れることは良い事だ 948 デフォルトの名無しさん [sage] 2010/03/22(月) 12:52:03 ID: Be: >>947 しかし、大概の７７のテキストは 100 FORMAT(1H , ・・・・・ などとなっていて、「この１H っては何ですか？」などと聞いてこられるので、 ６６から勉強しろとも言えず、ホレリスからイチイチ説明するのもメンドイので いい加減に流すのであった。ラインプリンタも見ることも無いし。 テキスト書く人は、もう少し頑張って欲しい。 ほとんど情弱化している。 最近出た入門Fortranとか、g95とGNUPlotでFortranとか期待したのに、中身があまりに古くて爆死した。 949 デフォルトの名無しさん [sage] 2010/03/22(月) 13:25:00 ID: Be: なるほど、Hは・・・聞かれるといろいろ困るなｗ どこまで・どこからの線引きは難しいなあ。 Doループも長～いやつだと意図して番号＋Continueするとかあるし・・・ gfortran -Wall だと年代ｗのチェックはしないしねぇ。いいチェッカがあるといいんだけど。 教科書は・・・英字のも含めてあまり進歩はないような。 教科書的なのは儲からんのだろうね。 漫画でわかる・・とかでないといかんのかね。だれか 「やる夫が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略) いまどき固定書式～ 固定書式が許されるのは５０過ぎだけだよね～ ・・・むかつくな
Fortran90だか95の入門書なのに、 掲載されているサンプルプログラムがほとんど77のと変わらないんじゃないか? というのがががが。
・知らなかった
最近ちょっと気になる作家さんの
岩井三四二 - Wikipedia
ですが、『簒奪者』学研(1999)（歴史群像大賞）
これ覚えてる。
確かこの大賞の一回めだか二回目の受賞じゃなかったかなあ。
Rubyについて Part 39 634 デフォルトの名無しさん [sage] 2010/03/22(月) 00:41:24 ID: Be: (´・ω・｀)ﾉｼ (´∀｀)ﾉ (´・ω・｀)ﾉｼ (´∀｀)ﾉ (´・ω・｀)ﾉｼ (´∀｀)ﾉ 【おっさん】 【ヤング】 【おっさん】 【ヤング】 【おっさん】 【ヤング】 アベック カップル チャック ジッパー サジ スプーン ズボン パンツ ズック スニーカー 汽車 電車 ジーパン デニム ラッパズボン ブーツカット 国鉄 ＪＲ 割ぽう着 エプロン 喫茶店 カフェ 寝巻 パジャマ コールテン コーデュロイ チャンネル回す チャンネル変える シャッポ 帽子 えもん掛け ハンガー 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 ところで・・・ジレっておばあちゃんが言ってたんだぜ 二周くらい回ってきたんだな ファッションリーダーさんからジレって聞くたびについ笑いそうになって困るわ まあ普通の名詞だからおかしくはないんだけど、わざわざお洒落ぶって言うところがわらけてわらけてｗ
やっぱり他にも気になる人はいるんだ(笑)
で、str*_s ネタをさらに。
Visual C++ 2005 C/C++ランタイム ライブラリ新機能概要 2005 年 12 月 8 日 はじめに Visual C++の新しいランタイム ライブラリは 従来の標準ライブラリの多くの関数がもつセキュ リティの脆弱性を解決します。 ここでは、Visual C++の拡張されたランタイム ライブラリやクラス ライブラリの機能を紹介します。 新しい関数の形式 デフォルトでは安全性が低い古い形式のC ランタイム ライブラリが使用されていた場合は、コ ンパイル時に警告を表示します。開発者は表示された警告を確認し、使用している関数がコード の安全性に影響を与えるかどうかを確認します。 新しいバージョンの関数は古いバージョンの関数名のあとに Secureを意味する _ｓ の接尾語がつきます。 安全な新しい関数名は、従来の関数名の後に_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 は。
何回かここでも紹介したことのあるblogだと思うんですが、 ここ数日で Why X is not my favourite programming language というパターンのエントリを沢山あげています。
読んでいる余裕がなっしんぐ ○|￣|＿
ありがちダメなコードのダメな理由を書くコーナー。
ついったから。
Twitter / かおりん: 十分な経験を積んだプログラマが使っても、C言語系は、 ... 十分な経験を積んだプログラマが使っても、C言語系は、メモリ破壊、メモリリークなどの地雷 が混入しやすい危険な言語ですよ。ｗ
Twitter / かおりん: 今の時代、初心者/入門者に進めるのは言語道断だと思う ... 今の時代、初心者/入門者に進めるのは言語道断だと思うんですがね。まあ、仕事にするなら知 っといた方がいい言語ではありますけど。
Twitter / かおりん: C言語系を勧める人は、なんでGCなんて仕組みが出てき ... C言語系を勧める人は、なんでGCなんて仕組みが出てきたのか考えた方がいいと思うな。
Twitter / かおりん: 仕事にするつもりなら、かなぁ。趣味でやるぶんにはやら ... 仕事にするつもりなら、かなぁ。趣味でやるぶんにはやらなくてもいいんじゃないかと最近は思 ってる。 RT @code_air_edge: @kaorin_linux 知ってた方がいいってことはやっぱ勧めやすいっ てことじゃないかな？ C#でもJavaでも、解説でよく「Cで言うと～」みた
Twitter / かおりん: 結構、仕事だと、C言語系って避けて通れない場面がある ... 結構、仕事だと、C言語系って避けて通れない場面があるので、これは必須と言ってもいいと思 うんだけど、新人とかに扱わせると、あとの修正が大変とか。ｗ 趣味の範囲なら、わざわざイ マサラという気はしてる。
Twitter / かおりん: C++はともかく、Cだと、じゃあアセンブラからか、と ... C++はともかく、Cだと、じゃあアセンブラからか、とか思っちゃったりするんだけどね。まあ、 これは行き過ぎ。ｗ
まだ「入門書」は C を使ったのが一番多いのかなあ。
・本の処分に困る
スキャンするとかゆー話ではなく、
置き場所がないんだけどすぐに読む余裕はなくて
でも読まずに捨てるのはどーよって話で、さてどうしよう。
Head First Statistics とか
Java のデザインパターン本とか
Effective C# とか
More Effective C# とか。
あ、今日もなんだかんだで shibuya.lisp#5 の話を書く時間がががが ○|￣|＿
Google がそれを採用するのは，それが優れているからではなくて，「いつでも捨てれる」からじゃないのか？
「あのー、ワードやエクセルが入っているのはいいんだけど、パワーポイントって入ってないの？」
昔から数千部しか出ない学術書なんて大して儲かっていなかった。電子書籍やオンディマンド出版によるサンクコストや在庫リスクの低減は、古き良き出版文化や多様性を守り抜く上で、寧ろ福音となる可能性もあるのではないか。
もし iPad が Mac OS X を採用していたら、デベロッパはソフト開発の意欲を失い、かつ満足できるユーザー体験も提供できなかっただろうと Daniel Eran Dilger はいう。
まあ、そのサイトのソースを参考にして、とりあえず作ってみて、どうにも躓くようなら、どの箇所が、どのようにうまくいかないのか、 具体的に質問をすると、アドバイスが得られやすかろう…と想像します。
_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.comI 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. - Arniereply 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. TomI 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. UliThanks 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月(上旬)
メールの宛先はこちら