ときどきの雑記帖 i戦士篇

31 Oct 2009 19:48

2009年10月31日

読んだこういうのを読むと、経済学のえらいセンセのいうことに疑いの目を向けたくなったりするんだよな (まあ色々宗派? があるみたいですけど)。

・皇帝戦士ビッグバン・ベイダー東スポのプロレスのコラム欄で取り上げているのが前回からベイダーなんですが、結構面白い。日本初登場のときがアレだったのでイメージが悪くなってる気がしますが、結構な実力者なんですよね。しかし、最初は全日本のリングに上がるという話だったとは。

・買ったもの昨日、買ったとだけ書いたのは実はこれでした→ Twitter / TWOTOP秋葉原本店: 音々ちゃんPC残り6台となりました！発売終了日が11 ... 10/22(たぶん)の深夜の発売開始に行けなかったのでこりゃあダメだとあきらめてたのですが、台数があったせいか(各店あわせて400台とか)木曜日の夜の段階でもまだ秋葉原で売っているところがある。でもこの週末で売れ残っている分があっても大阪に引き上げてしまうという話を聞きまして金曜日の終業後にダッシュでアキバの某店へ行きましたとさ。

Twitter / Hirofumi Saito: CSVをテキストの表に変換するテキストテーブル - ... tbl。は troff コマンド(に見えるもの)を食わせるんだっけ。 Vector：tbl (MS-DOS / ユーティリティ) - ソフトの詳細

・mawk FreeBSD だかできちんとメンテナーがついてがしがしパッチやら取り込んでるらしいですね。というわけでということではないのですが、以前とは別のやり方で日本語対応(とマルチバイト文字対応)をしようかと考えてたりするんですが、実装がちと面倒。鬼車とかのライブラリに乗せかえようという話が以前あったような気がしますが、それはちょっと負けになるのでやだなあと(笑)。わりと珍しいつくりの正規表現エンジンだと思うので、残せるなら残したいのですよね。

■_

最初だけ勢いがあって現在休眠状態のスレだけど、こんなのがあったとは。 Part 2 へ行けるのか(dat落ちでなしに)?

----Ovenの概要ようするに、| 演算子でパイプ(Unix的なあれ)を作ったC++テンプレートライブラリ。ほう。そういうものだったのか。


Oven/Egg総合スレ part1

1 デフォルトの名無しさん [] 2009/01/04(日) 23:54:01 ID: Be:

    ■関連サイト■
    http://p-stade.sourceforge.net/ 

3 デフォルトの名無しさん [] 2009/01/06(火) 01:08:05 ID: Be:
    こんな変態でマイナーナの、努力しないとあっという間にDAT落ちするぞ。

    ----Ovenの概要
    ようするに、| 演算子でパイプ(Unix的なあれ)を作ったC++テンプレートライブラリ。
    #include <iostream>
    #include <boost/foreach.hpp>
    #include <pstade/oven/sorted.hpp>
    int main() {
      using namespace pstade::oven;
      int a[] = {1, 9, -5, 10, -2, 6, 4};
      BOOST_FOREACH(int x, a | sorted) {
        std::cout << x << ' ';
      }
      std::cout << std::endl;
    }
    出力: -5 -2 1 4 6 9 10
    a | sortedってのがOvenを使った部分。sortedは名前通り入力をソートした結果を返すというものだ。

    このように入力も出力もRange。
    Rangeを知らなければここ読め。ようするに配列やSTLコンテナなど。BOOST_FOREACHできるやつと思っても可。
    http://www.kmonos.net/alang/boost/classes/range.html 

4 デフォルトの名無しさん [] 2009/01/06(火) 01:24:05 ID: Be:
    #include <iostream>
    #include <iterator>
    #include <string>
    #include <vector>
    #include <cctype>
    #include <pstade/oven/transformed.hpp>
    #include <pstade/oven/copied.hpp>
    #include <pstade/oven/copied_to.hpp>
    int main() {
      using namespace pstade::oven;
      std::string s = "HogeFooBar";
      std::vector<char> v = s | transformed(std::toupper) | copied; //当然パイプにパイプを重ねることが可能
      v | copied_to(std::ostreambuf_iterator<char>(std::cout));
      std::cout << std::endl;
    }
    出力: HOGEFOOBAR
    transformedやcopied_toのように、関数呼出の形で引数を与えるものもある。

    transformedは各要素に与えられた関数を適用したレンジを返す。Lispでいうmapだな。
    もちろん関数オブジェクトも可。Boost.Lambdaもいけるはず。

    copiedはここで打ち止めの意、vectorなどのコンテナへ初期化・代入できるようになる。ただし、std::stringへは上手くいかないようだ。
    Ovenで | を通した結果の型はテンプレートの塊なので、どんな型か考えない方がいい。この点、C++0xのautoがやや待ち遠しい。

    copied_toは指定された出力イテレータにコピーを送る。それは副作用としてなので、さらにパイプを続けられたはず。 

5 デフォルトの名無しさん [] 2009/01/06(火) 01:45:57 ID: Be:
    >>1のリンク先から辿れるけど、ダウンロードページへのリンクがあるこっちも挙げておいたほうが親切だと思う。
    http://sourceforge.net/projects/p-stade/
    解凍したら、コンパイラのインクルードパスに通すだけで使える。事前ビルド不要。

    これくらい書けば1晩は越せるかな。 

6 デフォルトの名無しさん [] 2009/01/06(火) 21:53:27 ID: Be:
    どう書く？orgからネタをもらう。
    http://ja.doukaku.org/comment/7652/
    #include <cmath>
    #include <iostream>
    #include <iterator>
    #include <pstade/oven/counting.hpp>
    #include <pstade/oven/filtered.hpp>
    #include <pstade/oven/copied_to.hpp>
    #include <pstade/oven/taken.hpp>
    bool t(unsigned n) {
      return (static_cast<unsigned long long>(std::pow(30., static_cast<double>(n))) % n) == 0;
    }
    int main() {
      using namespace pstade::oven;
      unsigned n;
      std::cin >> n;
      counting(1u, max_count)
        | filtered(t)
        | taken(n)
        | copied_to(std::ostream_iterator<unsigned>(std::cout, "\n"));
    }
    こういうのでは、出力に無理してcopied_to使わずにBOOST_FOREACHやBoost.RangeExのfor_eachを素直に使う方がいいと思う。 

7 デフォルトの名無しさん [] 2009/01/06(火) 23:53:54 ID: Be:
    そういえば、countingはまだ紹介していない種類だった。
    counting(m, n)はmからnまで1ずつ増加するレンジを作るというもの。max_countは最大値までの意。
    そういうわけで、これまでのと違って|の左側に置いている。

    そうそう、遅延評価風味。foreach類やcopied(_to)などを使わないと動かない。
    次のコードでは何も出力されない。
    #include <iostream>
    #include <pstade/oven/transformed.hpp>
    int f(int x) {
      std::cout << x << std::endl;
      return x;
    }
    int main() {
      using namespace pstade::oven;
      const int a[] = {1, 2, 3};
      a | transformed(f);
    } 

8 デフォルトの名無しさん [] 2009/01/07(水) 00:01:30 ID: Be:
    逆に、次のコードでは2回ずつfが呼ばれる。
    要素を参照するときに評価が起こると思えばいい。
    #include <iostream>
    #include <algorithm>
    #include <boost/range.hpp>
    #include <pstade/oven/transformed.hpp>
    void dummy(int) {}
    int f(int x) {
      std::cout << x << std::endl;
      return x;
    }
    template<typename Range>
    void g(Range const& r) {
      std::for_each(boost::begin(r), boost::end(r), dummy);
      std::for_each(boost::begin(r), boost::end(r), dummy);
    }
    int main() {
      using namespace pstade::oven;
      const int a[] = {1, 2, 3};
      g(a | transformed(f));
    } 

15 デフォルトの名無しさん [] 2009/01/09(金) 20:09:33 ID: Be:
    なぜかすっかり忘れていたけど、Ovenの元ネタはこれ。
    Range Library Proposal
    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1871.html
    Ovenのマニュアルにも冒頭に「Oven is an advanced implementation of Range Library Proposal」と書いている。
    http://p-stade.sourceforge.net/oven/doc/html/ 

16 デフォルトの名無しさん [] 2009/01/09(金) 23:38:57 ID: Be:
    作者不在で、ovenやeggの更新が止まってるのが残念 

17 デフォルトの名無しさん [sage] 2009/01/10(土) 03:09:10 ID: Be:
    ちょｗなんというマイナーライブラリスレ 

18 1 [] 2009/01/10(土) 10:28:38 ID: Be:
    誰か語って 

19 デフォルトの名無しさん [sage] 2009/01/10(土) 12:33:52 ID: Be:
    Ovenは慣れれば便利だよな
    変態だけど

    Egg？ｼﾗﾈ 

20 デフォルトの名無しさん [] 2009/01/10(土) 15:16:38 ID: Be:
    >>17
    >>3-9の間、誰にも邪魔されなかったほどに過疎っている。

    >>18
    自分からもネタふりしてくれ。 

21 デフォルトの名無しさん [] 2009/01/11(日) 21:04:17 ID: Be:
    <pstade/oven/algorithm.hpp>と<pstade/oven/numeric.hpp>には、
    それぞれ<algorithm>と<numeric>のRange版が収録されている。
    （もちろん名前空間pstade::oven）

    例えば、>>4のv | copied_to(std::ostreambuf_iterator<char>(std::cout));は、
    copy(v, td::ostreambuf_iterator<char>(std::cout));と書き換えることが可能。

    もちろん、Boost.RangeExでもいいわけだけど。むしろRangeExのほうがコンパイル速いし。 

22 デフォルトの名無しさん [] 2009/01/11(日) 22:03:35 ID: Be:
    日本語版のドキュメントが欲しくね？
    あと、もう少し詳しく書いて欲しくね？（俺だけか・・・）
    慣れればどれも同じ様な使い方だからなんとか使えるけど。

    あと、pstade::oven::regular ってどういう動作するの？

23 デフォルトの名無しさん [sage] 2009/01/12(月) 01:08:55 ID: Be:
    >>22
    確かにHamigakiは日本語文書があるのがやや有難いとは思う。
    ドキュメントを読んでわからないときは、libs\oven\example\を参考にすることが多い。

    どういう動作かって？実装のことならソース嫁で頼む。 

31 デフォルトの名無しさん [sage] 2009/01/26(月) 02:49:20 ID: Be:
    そろそろ即死から逃れられる頃合いか？ 

32 デフォルトの名無しさん [] 2009/01/29(木) 17:06:39 ID: Be:
    保守age 

33 デフォルトの名無しさん [sage] 2009/02/02(月) 19:30:41 ID: Be:
    保守 

34 デフォルトの名無しさん [] 2009/02/05(木) 17:21:50 ID: Be:
    保守ついでにany_rangeから目次順に取り上げることを目標にする。

    というわけでまずはany_indexed。
    any_rangeのランダムアクセス特化版、らしい。 

35 デフォルトの名無しさん [] 2009/02/10(火) 16:19:16 ID: Be:
    void print( pstade::oven::any_indexed<int> r)
    {
    std::copy(r.begin(), r.end(), std::ostream_iterator<int>(std::cout, "\n"));
    }

    std::vector<int> v(boost::counting_iterator<int>(0),boost::counting_iterator<int>(10));
    pstade::oven::any_indexed<int > ai(v);
    print(ai); 

36 デフォルトの名無しさん [] 2009/02/11(水) 14:31:46 ID: Be:
    pstade::oven::identitiesってなにするもん？ 

37 デフォルトの名無しさん [sage] 2009/02/11(水) 20:33:18 ID: Be:
    single pass range conceptを満たすものからiterator_rangeを作って返すものっぽいな
    io.hppのinspect機構はiterator_rangeに対して働くものだから
    single(ryを満たすコンテナのままでは動作しないわけだ
    さらに引数を指定することによって元のコンテナがsingle pass rangeでもrandom access rangeのように見せかけたりできると
    マニュアルやソース、テストを見る限りそう読みとれた 

38 デフォルトの名無しさん [sage] 2009/02/11(水) 22:09:21 ID: Be:
    STLスレからやってきたのか。
    あのコードだと、(v|ov::identities)をov::make_range(v)にしても動くな。
    どっちを使うかは好みの問題かな。 

46 デフォルトの名無しさん [] 2009/03/02(月) 20:43:29 ID: Be:
    http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/67a593c8e747b97c#
    RangeExがレビュー入りだってさ。
    レンジアダプタ（ | 演算子のやつ）も入っているよ！ 

48 デフォルトの名無しさん [sage] 2009/07/29(水) 13:03:13 ID: Be:
    保守

これでも落ちないってのはム板ならではだなー。もっと上があるけど。


Lisp Scheme Part28 
429 デフォルトの名無しさん [sage] 2009/10/28(水) 07:54:06 ID: Be:
    そんなことよりもSICPの日本語の新訳が早く出ないと色々滅びると思う。
    独習Lispとか独習Schemeとか出てほしいよ。良い文献は洋書しかない。
    とにかく若い人に使ってもらいたい。 

430 デフォルトの名無しさん [sage] 2009/10/28(水) 08:02:54 ID: Be:
    でもSICPはScheme勉強のための本じゃないでしょ？ 

431 デフォルトの名無しさん [sage] 2009/10/28(水) 08:52:25 ID: Be:
    滅びる?
    20年くらい前に比べたらずいぶんと流行ってるけど。
    むしろ流行りすぎ。 

432 デフォルトの名無しさん [sage] 2009/10/28(水) 10:02:00 ID: Be:
    俺も最近はSchemeブームなんだと思ってたｗ 

433 デフォルトの名無しさん [sage] 2009/10/28(水) 11:13:47 ID: Be:
    > 日本語の新訳

    和田先生の訳が気に入らない一部の人でしょ。どう見ても。 

434 デフォルトの名無しさん [sage] 2009/10/28(水) 11:55:29 ID: Be:
    現存のSICPスレに別訳を幾つか書いた者だけれど、
    確かに序文の翻訳には酷いものが含まれてると思う。
    訳本の序文は読まないか、理解できなくても気にしない方がいい。

435 デフォルトの名無しさん [sage] 2009/10/28(水) 14:15:07 ID: Be:
    嫌なら旧訳を探して買えば良いのに 

436 デフォルトの名無しさん [sage] 2009/10/28(水) 22:59:40 ID: Be:
    正直、和田訳はだめ。

437 デフォルトの名無しさん [sage] 2009/10/31(土) 01:11:30 ID: Be:
    和田先生の訳を受け付けないのは数学書なんかの固い専門書を読み慣れていない人？ 

438 434 [sage] 2009/10/31(土) 08:20:41 ID: Be:
    序文の翻訳は下手だよ。
    文章が固いとかそういうレベルじゃない。 

439 デフォルトの名無しさん [sage] 2009/10/31(土) 09:58:42 ID: Be:
    本文で身につけたい物が身につけばいいじゃん、だいたい翻訳が気に入らないなら原書読めばいいだけの話

440 デフォルトの名無しさん [sage] 2009/10/31(土) 10:15:40 ID: Be:
    ご飯がまずくて食べられなければパンを食べればいいのに。 

441 デフォルトの名無しさん [sage] 2009/10/31(土) 11:17:18 ID: Be:
    原文の意味を変えないようにすれば正確な文章になるとは限らないし、
    正確な文章であれば読み易いとも限らない。
    間違ってるなら論外だけど、
    結局は何に重点を置くかってことなんじゃないかなぁ。 

442 デフォルトの名無しさん [sage] 2009/10/31(土) 11:19:23 ID: Be:
    バブル世代より上は翻訳脳が欠落してんだよ
    今は翻訳自体のプロでなくても翻訳センスある人多い 

443 デフォルトの名無しさん [sage] 2009/10/31(土) 11:29:57 ID: Be:
    http://iiyu.asablo.jp/blog/2005/10/11/105359#c359800 

444 デフォルトの名無しさん [sage] 2009/10/31(土) 11:50:18 ID: Be:
    ttp://www.alu.org/pipermail/alu-discuss/2009-October/000004.html
    くるかしらね？

最後のこれは…?

■_

まあ実際、gcなしの環境で malloc失敗したら基本的には実行を終了するよりないような。下手にリカバリーしようとするとドツボにはまりそうな気がする。もちろん、そういう『悪足掻き』をしなきゃならないものや局面はあるのだろうけど。



Eli Bendersky’s website

Handling out-of-memory conditions in C

October 30th, 2009 at 7:57 am

We've all been taught that when malloc returns 0, it means the machine ran out of 
memory. This case should be detected and "handled" by our application in 
some graceful manner. But what does "handled" mean here? How does an 
application recover from an out of memory (OOM) condition? And what about the 
increased code complexity of checking all those malloc return values and passing them 
around?

In this article I want to discuss the common policies of handling OOM conditions in C 
code. There is no single right approach. Therefore, I will review the code of several 
popular applications and libraries, to find out how they do it in order to gain useful 
insights for my own programming.

Note that I focus on desktop & server applications here, not embedded applications, 
which deserve an article of their own.

The policies

Casting minor variations aside, it's safe to say there are three major policies for handling OOM:

→ メモリ確保に失敗した場合の対処ポリシーは大別して三種類。

recovery

The recovery policy is the least commonly used because it's the most difficult to 
implement, and is highly domain-specific. This policy dictates that an application has 
to gracefully recover from an OOM condition. By "gracefully recover", we 
usually mean one or more of:

    * Release some resources and try again
    * Save the user's work and exit
    * Clean up temporary resources and exit

Recovery is hard. To be certain that your application recovers correctly, you must be 
sure that the steps it takes don't require any more dynamic memory allocation. This 
sometimes isn't feasible and always difficult to implement correctly. Since C has no 
exceptions, memory allocation errors should be carefully propagated to the point where 
they can be recovered from, and this sometimes means multiple levels of function calls.

→ 「リカバリー」は難しいやり方。

abort

The abort policy is simple and familiar: when no memory is available, print a polite 
error message and exit (abort) the application. This is the most commonly used policy 
- most command-line tools and desktop applications use it.

→ メモリ確保に失敗したら、メッセージを出して実行を中断。

As a matter of fact, this policy is so common that most Unix programs use a gnulib 
library function xmalloc instead of malloc:

void *
xmalloc (size_t n)
{
  void *p = malloc (n);
  if (!p && n != 0)
    xalloc_die ();
  return p;
}

When this function is called, its return value isn't checked, reducing the code's 
complexity. Here's a representative usage from the find utility:

cur_path = xmalloc (cur_path_size);
strcpy (cur_path, pathname);
cur_path[pathname_len - 2] = '/';

segfault

The segfault policy is the most simplistic of all: don't check the return value of 
malloc at all. In case of OOM, a NULL pointer will get dereferenced, so the program 
will die in a segmentation fault.

→ もっとも単純な対処法(?)。ぬるぽを返してそれをデリファレンスしたところでこけるに任せる。

If there are proponents to this policy, they'd probably say - "Why abort with an 
error message, when a segmentation fault would do? With a segfault, we can at least 
inspect the code dump and find out where the fault was".

Examples - libraries

In this section, I present the OOM policies of a couple of well-known libraries.

(以下略)

これってどれが一番強いの？:アルファルファモザイク - ２ちゃんねるスレッドまとめブログ

社団法人情報サービス産業協会が、残業代ゼロのホワイトカラーエグゼンプションを推し進めていた件 - 404 ないわー (・∀・)キムティ♪ Not Foundの日記

Permalink | View Entire Page

Search the Site

Custom Search

Page2RRS