【C？】最初の言語に何を選ぶか【Haskell？】
■ このスレッドは過去ログ倉庫に格納されています
>>25
スタックポインタの復帰にpopを使う方法もありだが
例えばメジャーな86系でメジャーなやり方なら別レジスタに退避させるのがメジャーな方法なのでmovになる
他にも完全にコントロールできるならスタックポインタの数値加算(スタックが0方向に伸びる場合)で復帰もあり
いずれにせよスタック上にローカル変数などの領域確保はスタックポインタの数値減算(同上)で行うのがメジャー
そしてスタック上のその領域の解放はスタックポインタの復帰(上述)で終わる 説明に必要な抽象度を調節できない人ってプログラマーに向いてないよね スタック上で関数ローカル変数の領域は
・スタックを伸ばして領域を確保
・スタックを戻して領域を解放
極めてシンプル つまりまず最初にC言語をやるべきだな。
次にアセンブリ言語というよりCPUの共通的な概要仕組み。
そのあとHaskellかRustなどの強力な静的型付けプログラミング言語へ進むのが良いだろう。 じじぃが最期の言語に何を選ぶか
にしたら
どうしようもない耄碌ばかりだ >>26
SP復帰はLEAVE命令だろ
と思った俺は古過ぎるのか 1.Python
2.Haskell or Go
3.Rust or やりたいことに応じてjsとか
これやろ >>33
Pythonみたいなクソ言語はありえない
残りの4つはアリ 関数型が全然わからない
ocamlやhaskell触ってみたけど手も足もでなかった
あれってすべて適用した引数ベータ展開しながら簡約していった結果をコーディング中に頭の中でシミュレーションしていかないと書けない代物なのか？
それじゃあワイできないよ
後型システムの振る舞いがなんにもわからないわ
あれってocamlは型推論あるけど型が明示的に表記されない代わりは自分自身で頭の中に型付け規則を当てはめながら追っていくしかないんか？
それじゃあワイできないよ
以上のような理由からワイは例えばfixという不動点コンビネータの高階関数とかわからなかった
とにかく自分にはお手上げやわ >>35
Haskellの型クラスやモナドを採り入れつつCと同じ手続き型言語のRustからまずは入ってみたらどうでしょうか？
Rustのコンパイラは賢くフレンドリーなので型のミスも細かく教えてくれます >>36
rustは式指向って言ってもラムダ計算ではないのでそっちはかろうじて理解できます
理解できないのはラムダ計算ベースの関数型です >>26
pop というのは機械語（ニモニック）レベルではなかったような。
sp（スタックポインタ）から sub するか（できるのか？）、
sp の値をアキュムレータに持ってきて sub して書き戻すか
（フラグの中身が変わったり、アキュムレータの中身を堆肥させたり
ちょっと面倒臭そうだ）、
小さい言語処理系を開発するときは、FORTH のインタプリタを実装して
その上にコンパイラを被せるとかいうのは二度ほどやったことがある。
「Make 10」パズルの全数解を求める、とかいった場合だと、
けっきょくそれをやるのが素朴だと思う。 関数型とかラムダ計算とかいっても、
遅延評価がないと実行効率がそんなに上がらないんだよね。
「これ、前にやったことがある」「だから、前にやった結果を
そのまんま使おう」というのが遅延評価なのだけれど、うーんと
末端のほうだと、「前にやったことがあるんだっけ？」という
探索に時間がかかっちゃうので、探索効率と組合せ論的な爆発の間の
トレードオフになっちゃうので、手続き型と関数型のどっちを
選ぶかというのは、ある程度実効機序が解ってないと難しいんだよね。
そういう意味では C 言語とか FORTH とかいった、コンピュータ・
アーキテクチャべったりの言語から始めたり、古いタイプの高級言語から
入るのもひとつのやりかただと思う。
そういう意味では Java とか C♯とかは、プロ用には向いてるけど
基礎を知らないと難しいかも。
昨今は F1 のトランスミッションもオートマチックだそうだしなぁ。
昔のマニュアル車やゴーカートから始めてみるのもいいんじゃない？ マニュアル車は、
少し低めのスピードで高速ギアにしたり、エンジンブレーキかけたりできるからね。
渋滞時だけは、面倒。
少し加速して、すぐニュートラル。
ようするに、燃費をいかに少なくするか？なのだけど。 スポットから始める、練習から始める、ってことかな？ >>38
嶋正利さんが設計したインテル8080からスタック操作のpush/pop命令はずっとあるよ
もちろんZ80でも86系でも同様
実はアセンブラ使ったことないの？ >>42
昔、『I/O』の附録だった、Z80 とか 6809 のお経本
（インストラクション・セット・サマリ）とか久しく
見てないからなぁ。
push とか pop とかの引数をどこから取ってくるのか、
といったところまでは思い出せない。 >>44
引数ってなんだ？？
当時のpush/pop (6809だとpush/pull)は
レジスタをスタックへ退避と復帰のみだぞ >>42
68000からアセンブラやり始めたとかかもw sp をインクリメント／デクリメントするだけで１命令なのか …
それは大変だな。 >>34
じゃあ
1.Go
2.Haskell
3.Rust or やりたいことに応じてPython, js, C# >>44
I/Oとかクソ懐かしいな30年以上ぶりに聞いたわ
高校の時にZ80やった
ちなみにオススメはプロでやりたいならJavaかJSかC#
言語マニアの話とか聞いてもマニアになりたいんじゃない限り意味ないぞw >>51
オートマだとドライブ一直線だが、
神岡ターンではクリッピングポイントをクリアしてから
「一瞬、ギアをリアに入れる」というとかいったコトをやっている。
C 言語でも、C のコンパイラが吐いたアセンブラのコードを見て、
「ここはステート数が縮められる」みたいなマッドな野郎どもが
昔はいたんだよ。
そういう言語マニアにとっては C 言語なノスタルジックな言語では
あるんだけれども、C++ というのは、マネージャーとかいった
そのあたりの美学を理解しない連中が権勢を揮っているので、
「いい言語」と言っていいとは思わない。 >>54
> Javaでプロωとかωω
> 土方まっしぐらωωω
あんた病んでるよ。
だけど反社会性パーソナリティ障害障害って、
治療法がないんだよね。
最近の精神科のクリニックは薬物療法が主なので、
カウンセリングはあんまり主流じゃないから期待しないほうがいい。
松沢病院とか受診してみれば？ >>53
「I/O」は今でも書店に並んでるぞ？
「らんだむ・あくせす・でぃくしょなりぃ」とか懐かしいな。
宮永さんが、ナショナル・セミコンダクタ（通称ナショセミ。
以下 NS）の「SC/MP」（通称「スキャンプ」）の２が出たときに、
煙草の箱サイズの自作パソコンを作って製作記事で紹介していたのだけれど、
「入力はスイッチ一つでいいんだけれど、タイミングを取るのが
大変だからスイッチを二つに増やした」「出力は、ラインを触って
ビリッときたら 1 で、こなかったら 0 だと思ったけど、涙を呑んで
電球をつけた」（当時は LED は一般的ではなく、出力は 5.5 ボルト
だったので電球もついた）とかいう生々しいレポートがあった。
あのころは楽しかったなぁ。
> ちなみにオススメはプロでやりたいならJavaかJSかC#
> 言語マニアの話とか聞いてもマニアになりたいんじゃない限り意味ないぞw
なるほど。マニアになりたい奴には意味があるし、開発の現場では
言語マニアにも居場所があったりする可能性は認めてもらえるんだよな？ >>49
そういえば、オペコード（オペレーション・コード）って言葉を
久しく聞いていないな。
いまどきアセンブラとかやってる奴がいないせいだろうか。 ネイテイブコードでかかれたゲームクライアントが少なくなったせい？
ゲーム解析でアセンブラとかOSの動作を覚えたｗ >>60
それはフロッピーディスクのコピープロテクトが
一般的でなくなったからだと思う。
あの頃の激戦区は、（参戦はしなかったけど）
楽しかった記憶がある。 >>58
まだ売ってるのか良くもったな
例えばJavaの現場でHaskellとかできてもどうにもならないが趣味でマニアな分には
その場合Javaさえできるなら当然問題はない
ただそういう人は変な事する場合があるから言語以外の普通の開発手法とかデザインパターンとかはちゃんとしてね このスレで書き込みしている人達ってやっぱ平均年齢50超えてる？ やっぱなんだかんだ言ってもCが1番
ダイテル本みっちりやればよろし >>63
> このスレで書き込みしている人達ってやっぱ平均年齢50超えてる？
よくわからんが三十代か六十代の、いわゆるスキマ世代が多いんじゃないかな？
読んでるひとは十代とかだったりしそうだけど、
おっさん世代の愚痴やら説教やらを聞いてくれるヒトがいるというのは、
喜ばしいことだと思う。 高級言語から始めてもいずれ「ポインタって何に使うの？」って絶対に聞くんだから最初からアセンブリやっとけよ
つまんない意地はんなや >>67
「C プログラミング初心者あるある」だな。
「値呼び」とか「番地呼び」とか「名前呼び」とか
文字列を含む可変長データの管理とかで悩んだときに
アセンブラにまで立ち戻って考えると確かに理解しやすい。
クヌスの「コンピュータ・プログラミングの技法」とかは
手がかりになりそうだ。 習得順序がBASIC→アセンブリ→Cであった頃は何の問題もなかった
最初の言語はコンピュータの仕組みや計算機科学べったりでない方がよい
そんなのは2つ目以降で考えればよいこと >>69
> 習得順序がBASIC→アセンブリ→Cであった頃は何の問題もなかった
> 最初の言語はコンピュータの仕組みや計算機科学べったりでない方がよい
> そんなのは2つ目以降で考えればよいこと
その点については全面的に同意する。
たぶん三十代の遣える方だと思う。
ただ、Pascal の P-System とか、
BCPL とかいった「仮想マシンのアセンブラ」とかいった
いったコンパイラ言語を経験している若者が少ないんだよね。
「コンパイラ → マクロアセンブラ → アセンブラ → 機械語」
とかいった経験を積まないと、システム屋としては未熟だと思う。
そういった経験を積んだ人にとっては、「イマドキの若者」っていうのは
腹立たしいとは思うんだけど、そこは生温かく見守ってあげようよ。 >>69
多分高級言語こそ全てのプログラミングの基本であり真髄みたいに考えてるんだろうけど逆だよ
そもそもプログラミングってコンピューター使わなくてもできるからな？ >>71
コンピュータ使わずにできるプログラミングとBASICは似てるって主張ではないのかな？
つまり、Cやアセンブリはコンピュータに相当忖度しなくちゃ動かないけど、BASICはアルゴリズムを記述したら動く、と。
ローカル変数ないじゃん、とか、構造化プログラミングできないじゃん、みたいのはBASICだと流石に出てきちゃうけど
ソフトウェアエンジニアでC書けない人は本物じゃないと思うけど、プログラミングはソフトウェアエンジニアだけのツールじゃないからねえ。 そのあたりは、REAL BASIC の開発者の意見もあるだろうと思う。
行列の積とかもフツーに計算できる機能もあったはずだ。
Ｆortran 77 じゃないけど、複素数演算もできたと思う。
つーても、演算子の拡張というのはあまり必要がなかったようで、
現在では使われていないようだ。 >>72
> ローカル変数ないじゃん、とか、構造化プログラミングできないじゃん、
> みたいのはBASICだと流石に出てきちゃうけど
だからこそ悪辣な面白いこともできる、というのは C と同様だぞ（笑）。
文字列領域にマシンコード突っこんで直接コールするとか、
グラフィック用のビットマップ領域を利用してプリンタ用のバッファに使うとか、
「今から三十年くらい昔にはよくやったもんだ（笑）」という話は
先達からいろいろ聞かされている。
昔の「I/O」とか「THE BASIC」とか読むと、その手の話はけっこう出ていると
思う。 >>71
初心者が真髄なんてものに触れる必要はないというのが論旨なのだが たとえば、無条件ジャンプ（いわゆる GOTO 文）と
条件ジャンプ（たとえば CALL文。BASIC では GOSUB）は、
番地フラグとして、同じ「ラベル」というのを指定できる。
そうすると、飛び先が同じでも GOTO なのか GOSUB なのかで
挙動が追いにくくなる。
BASIC ならまだしも高級言語だから追いやすいが、アセンブラで
これをやられると、本当にややこしくなる（実際に、追っかけているうちに
訳がわからんことになり、しかも途中でプログラムの自己書換えとかが入って
いて、「一ヶ月くらい悩んだ」という奴がいた。じつはタイマ割込みがセット
されていて、それは単なる「ゲームのイニシャルローダが発売されてから
解読されないための時間稼ぎ」でしかなかったのだが）。
これで「八人の女王」プログラムを書いて褒められたことがある。
C 言語やアセンブラだと、ROM に焼くのと RAM 上に置くのでは挙動が
違うので（ROM に焼くと自己書換えができないが、RAM 上では書換えができる）
とかいった より悪辣なことができるので、C やアセンブラはとても愉しい
言語だと思う。
だけど ANSI-C は牙を抜かれて飼いならされてしまったので、
「ANSI-C は家畜化されて牙を抜かれたブタであって、オリジナルの C は
猪だ」という意見はあったりもする。 業務で書く分にはわかりやすさ重視で凝ったアルゴリズムは敢えて使わないな
今や凝らなくても余裕があるし、メンテしようと自分で見返したときに思い出すのに時間がかかるし
詳細仕様とか文書を書き起こす方に時間がかかって大変だからｗ >>69
自分もこのルートだったけど、なんでもアセンブリとかメモリマップに落として考えるようになってしまい、その後クロージャとかコルーチンとか出てきたときにかえって分からなくなってしまった
いい年になってから計算機プログラミングの構造と解釈を読んでようやく前に進めた >>78
規模の大きいプロジェクトで、支援で突っ込まれると、かなり地獄です。
だいたい、『人月の神話』で「途中で人を突っこまれると余計に
プロジェクトの進行が遅れる」というのは常識のはずなんですけどね。
>>77 さんは『ソフトウェア作法』のほう（構造化）に向かっていて、
前に進めたあなたは（本来の意味での）システムエンジニアへの道が
拓（ひら）けた、ということではないでしょうか。
> いい年になってから
と仰（おっしゃ）いますが、三十五歳を過ぎてからが働き盛りですよ？ >>69
一理あるな。アセンブラはさすがに現代すっ飛ばすとして、VBAあたりから
入門して「これ、・・・・・駄目じゃない？」レベルまで行けたら
Cは仕組み知るには素晴らしいけどなんか組むには素朴すぎるし、C++は
増築繰り返して化け物化したWin3.1みたいだし、オブジェクト指向バリバリの
JAVAとC#は時代に遅れそうになって増築しすぎの兆しが見えるし…。
Rust？ >>80
漏れも同じことを考えたので禿同なのだが、
Rust は局所変数の扱いを文法で縛っているという
印象があるので、言語処理系（自然言語処理ではなく、
いわゆるインタプリタやコンパイラ）を「意識しない」
という方向性については いまひとつ疑問がある。
「うちらは幸せな時代に生きてきたんだなぁ」とか思ったりする。
マイクロプロセッサの黎明期に秋葉原をうろついていて、
p-code Pascal とかを体感してきたんだから。 >>81
私の世代の場合、まだ世間がNiftyとか言ってるあいだに大学でインターネット、emailに触れ、
Windows95が出た頃には自宅でBSD unixをPCで動かしてXWindow立ち上げてvi/emacsでプログラム書いてgccできたので、まぁ面白い時代だったです >>82
うらやましいな。
おれは unix には触ったことがないので、rogue もプレイしたことがない
（知らない人のためにひとこと。rogue のアクション操作はエディタ vi と
いっしょ）。
そういえば、パロディ判アスキーに、「UNI+」（ユニプラス）という
unix 風のシェルが載ってたな。 >>7
PHPはHTML必須なので進めない
javascriptはさほど汎用的でない（javascriptでないと使わない独特技法がある）
学習情報が整理されてるpythonかrubyがおすすめ
それらで基本構文などを習得してからweb行くならJS、PHP
アプリならjava-kotlinなど選べばいい >>83
職についちゃうとその業務で極めようとするからなかなか＞＜
今の人だとスマホで劇的な変化を体験したんだろうか
rogueというかSunOS/Solarisだとhack?
マシンごとにランキングが残るんだけど、誰もやってなかったｗ JUNETでUUCPでmailとnetnewsが来てfj.*を読み書きしてた頃か
インターネット接続になってそれら便利になるとともに多様化で消えていった uucpの頃がuuencode/uudecodeか
base64に飲み込まれたな もうおじいちゃん達の懐古主義はお腹いっぱい
昔を懐かしみたいのなら別スレ建てたら？ 当時似たような unix 風のシェルがあって、
「UNI十（ユニクロス）」とか「UNI×（ユニッペケ）」とかあったんだよ。
たしか当時はまだインターネットが普及してなくて、公衆回線を
使った草の根 BBS のころで、
うんと底のほうのルーチンで回線断されると、longjump で上の方に戻ろうと
するといろいろとトラブルが起きたんだ。
そんなわけで、キャッチ＆スローみたいなことをやろうというときに、OS で
コプロセスを起動するということを考えたひとがいて、それがシェルもどきに
なったという経緯があったりする。
知人の unix 使いが「Mimic」というシェルもどきを書いてたっけなぁ。
「mimic」とタイプすると、「It's Me!」と返してくる。
いや、おれは rogue やってないから知らないっつーの (^_^!)。
いまどきの若者は『ダンジョン飯』とか読んでいるので常識っぽい
らしいが。 >>93
数学だなあ。今モナドの説明読んで理解しようとしてるけど
頭がパンクしそうだ。
ただ、「圏論学ぶと人生観が変わるくらいものの見方が変わる」
らしいからなんとかそこまでたどり着きたいなあ。
最初の言語としては全くお勧めしないｗ
そもそも「他の言語を何か使えること」がほぼ前提の言語だし。 >>96
まぁ……数学がわかんなくても遅延評価がうまいこと
やってくれるので、運がよければ組合せ論的爆発を
避けることができる、というのが取り柄かな。
トランプや麻雀のプログラムとか、選挙の議席数によって
どれくらい影響力があるか（シャープレイ＝シュービック
指数という。単独過半数だと面白くもなんともないが、
二大政党の議席数が拮抗してて野党がキャスティング・ボウトを
握っていたりすると、いろいろ面白い結果が出たりする）とかの
話だと、Haskell は強力かもしれない。 C や C++ って、記述の粒度が細かすぎて
全体像が掴みにくいんだよな。
オブジェクト志向になると、モジュール化がしやすいから
全体構造はいくらか見えやすいんだが、こんどは
いろいろと制約っつーか縛りがきついので、C とかから入ったひとは
「これでホントにシステム組めるのか？」とか面喰ったりする。
何人くらいのチームで、どれくらい知識が共有できててスキルがあるのか、
とかいった観点から言語を選ぶのも、ひとつの選択だと思われる。 >>98
その点はJavaと全く同じ
Javaしかやったことないからそんな意味不明なことを言ってる
勉強しなさい >>98
> 「これでホントにシステム組めるのか？」とか面喰ったりする。
以前LavVIEWをちょこっと触ったときには少々面食らったw
Cコードに展開させてみて、はぁそういうもんかと理解した >>99
C とか C++ とかって大勢でプロジェクトを張ってると、
なんか真っ裸で職場をうろついているような気分になるんだよね。
昔の先輩（女性）は「毎日端末の前で脳内ストリップをやっているのよ！」
と仰っていたし。
> 勉強しなさい
修羅場で場数を踏みなさい。 >>103
当然C++の方がJavaより幅広い分野をカバーできる
どちらも徐々にRustに置き換わっていくだろうが 今まで色々なプログラミング言語が注目されては下火になるのを繰り返してきた。
そして、結局なんだかんだ言われながらC/C++が残っていくのでしょうね。
米粒みたいなワンチップマイコンから富岳まで、ほぼ全てのレンジでCコンパイラは用意されてるし。 >>105
C/C++と同じことが出来て、なおかつ、メモリ安全性を保証できるプログラミング言語Rustが登場したので
C/C++は各分野で徐々にRustへと置き換わりつつある >>106
今まで色々な言語が出る度にそういう主張は目にしてきたわ。
まあ、そういうかなり乱暴なこともできるのがCのいいところでもあるんだけどね。
とりあえずLinux互換のOSをRustで記述して、Rustならこんなにシンプルで高速になりますって見せてみたら良いんでない？ >>107
今までそのようなプログラミング言語は存在しない
初めて出現したのがRust
Linux OS開発でもCからRustへ徐々に置き換えて行く方法について議論がなされている Rust推しウザい
議論じゃなくて実際に置き換えてから来てくれ >>107
Linux互換OSどころかLinux自体がRustで記述されるプロジェクトがLinux開発チームで動いてるよ
トップのLinusもそれに対して対応すべき項目を挙げたのでその対処が進められているよ GoogleもAndroid OSをRustベースにしたいと言って色々やってるしな。 願望だけでまだ何一つ置き換えられていないRust
まるでチョン君の永遠の10年後と一緒だなw Facebook、開発言語に「Rust」採用 次期ビルドシステムの開発で
https://www.itmedia.co.jp/news/articles/2107/28/news152.html
Rustを用いることで、どのような利点があるのか。Facebookは記事の中で次の4つの項目を挙げています。
①Rustのasync/awaitシンタックスは、非同期のコードをとてもスムーズに記述できますし、Rustは複雑な並行処理の詳細を正しく理解するのに役立ちます。
BuckのJavaの計算を一つ一つ並行処理に移行するのは数カ月に及ぶ困難な作業でしたし、シングルスレッドの大きなボトルネックがまだ存在しています。
②Rustには、開発をより簡単で楽しいものにしてくれる多くの高レベルな言語機能があります。
それらはenum、パターンマッチング、trait、手続き型マクロなどで、Rustの開発者の多くに愛されています。
③Rust はメモリの割り当てをより細かく制御することができます。
ガベージコレクションのある言語では、たとえジェネレーショナルコレクションであっても、Buckが行うようなインクリメンタルな演算に対応するのは困難です。
④Rustは高性能です。
Rustに移植することで劇的な性能向上を私たちは見てきました。 半年付き合って親御さんと顔合わせを済ませて婚姻届に署名捺印して金庫にしまってからでないとコンパイルできないRustちゃんは男女の抱えるトラブルのかなりの部分を解決するけど
浜辺で出会って月明かりの元すぐコンパイルできるCちゃんがいることで維持できる物語もあるんだよ Rust推しは確かにウザいが、大手での使われ方が今までの言語とはっきり違うので
無視して良いものではないけどなあ >>116
実際に書いてみると慣れだけの問題でそんな違いは出てこないよ
むしろRustは後発言語なだけあって他の言語のそれぞれ良い部分を洗練して取り入れた面もあってプログラミングはCより遥かにしやすいね Rustはしばらく半信半疑で様子見されてきていたけど、ここにきてようやく試験に合格したような雰囲気があるな。 今現在C/C++はほぼあらゆる場で使えるしなあ。リアルタイムOSもLinuxもとりあえずCを身につけてたら読めるしね。
SystemCでハードウェアまで含めたシミュレーションや論理合成まで繋げられるから、C++でアルゴリズムを検証した後、負荷の重い部分をSystemC環境に移してFPGA化して高速化するなんていう具合にハードウェアとソフトウェアをシームレスに繋げられるのも利点だよね。
Cの悪名高きポインタも、あれのおかげでハードウェアのレジスタアクセスなんかが簡単に記述できるんで、とってもありがたい存在なのよね。 Visual Studio が標準で Rust をサポートしたら本気出す
まあ公式がこんなドキュメント出してるくらいだからそのうち標準になるんじゃないかと楽観視してる
https://docs.microsoft.com/ja-jp/windows/dev-environment/rust/setup 1970年代に生まれたC言語が現在でもよく使われているのは、ハードウェアに直接アクセスできる基礎的な言語であるためだが、
メモリー関連の脆弱性が発生しやすいという問題も抱えている。
Mozillaが支援し、開発されたRustは、システムプログラミングでC言語の代わりになる言語として期待されている。
例えば、Googleが一部で「Android」の開発にRustを導入しつつあり、
RustをLinuxカーネル開発の第2言語に採用しようとする活動も進んでいる。
またAmazon Web Services（AWS）はインフラ開発にRustを使用しており、
Microsoftにも「Windows」や「Azure」の開発にRustを使い始めている。
このようにIT業界が一斉に同じ新たなプログラミング言語を採用するのは史上初のことであり、
メモリ安全性を保証しつつC言語が担ってきた分野を完全に置き換え可能なRust言語が新たに時代を変えつつある。 着替えが上手ければ更衣室行かなくてもいいよねというCちゃんが胸チラマンチラしながら教室で着替えるからこそ
ガードの固いRustちゃんの振る舞いが周りに受け入れられるんだよ
CちゃんがいなければRustちゃんはただのめんどくさい子 ■ このスレッドは過去ログ倉庫に格納されています
