Ruby 初心者スレッド Part 65

2018/12/22(土) 04:43:34.03

プログラミング言語 Rubyについての、初心者向けスレです。質問・要望・雑談などをどうぞ

質問するときは、OSやRubyのバージョン、エラーメッセージを書いて下さい。
Ruby on Rails については、WEBプログラミング板で

前スレ
Ruby 初心者スレッド Part 64
https://mevius.5ch.net/test/read.cgi/tech/1535797516/

るりまサーチ　（リファレンス検索）
http://rurema.clear-code.com/

Rubyist Magazine - るびま
http://jp.rubyist.net/magazine/

逆引きRuby
http://www.namaraii.com/rubytips/

Ruby コミュニティ公式
https://www.ruby-lang.org/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2019/08/05(月) 13:47:09.02

そろそろこっちでやれ
アンチということではなく本スレの代わりとして
Rubyについて（アンチ専用） Part005
https://mevius.5ch.net/test/read.cgi/tech/1555162340/

2019/08/05(月) 13:52:01.39

しかし>>569に書いたようなことを公式で言うとマジキチだから
静的型を導入しない理由を聞かれると、いつも適当なことを言って言葉を濁しているわけ
これでRuby3.0で導入されるといわれる型チェックが
どうしてああいう感じになってるか良くわかるでしょ

2019/08/05(月) 13:52:35.64

型を書きたくないんじゃなくて、Rubyの設計上、型を書こうとすると
設計レベルで作り直さなきゃいけなくなるから面倒くさいだけだよ。

2019/08/05(月) 14:07:53.55

Perlも6で詰んだしな
*byも脱皮失敗で死亡
pythonは2->3でヨタヨタだがうまく離陸してくれ

2019/08/05(月) 14:08:47.58

単純に全体の完成度がバージョン0.8くらいに戻るよね
そこまでして「わざわざRubyに」導入するべきものでもないということではあろう
昔ならともかく今は他の言語もあるのだから
これ言うと揉めるけどな

2019/08/05(月) 14:14:45.71

1. 型を導入すると良いものになる。
2. だけど全体を再設計しなければならない。（面倒くさい）
3. その上、使いやすくすると、言語がガラリと変わる
4. ユーザーもその「使いやすい言語」に乗り換えるのが面倒くさい
5. 結果使われなくなるのがわかっている。
6. Ruby離れを防ぎつつ、型を導入するには、コレしかなかった

2019/08/05(月) 14:23:24.52

型無し*byに不満な人はElixirやればいい

2019/08/05(月) 14:27:47.88

LISP や Smalltalk が好きな人にとって使いやすい Perl の代替となるスクリプト言語なんだから、型欲しい人は他の言語使えば？と言うだけの話。
型を導入すると対話環境での使い勝手が悪くなり、書き捨てのプログラムを書く際の手間が増える。それは楽しくない。

型を使うと速くなる？そんなに速度が要求される要件に使うなんて決定をする奴がおかしい。型を使うとバグが減る？そんなにレベルの低い人は使わなければいい。
妥協できるラインが、今の、書きたいやつは書けば良いんじゃない？でも、文法を拡張して既存コードとの非互換生むような修整は受け入れられない。
と言う話でしょ。

2019/08/05(月) 14:32:38.11

>>576
そう。 Elixir なり Crystal なりを使えばいいだけの話。
なんでRubyに型を導入することにこだわるんだろう。

2019/08/05(月) 15:48:35.23

ドキュメントに型を書くことになるんだから、そこの仕様をしっかり決めるべきだった

2019/08/05(月) 16:30:50.53

>>577
> 型を導入すると対話環境での使い勝手が悪くなり、書き捨てのプログラムを書く際の手間が増える。それは楽しくない。

それはstrictモードを作ればいいだけなんよ

2019/08/05(月) 16:33:24.89

>>577
> 型を使うと速くなる？そんなに速度が要求される要件に使うなんて決定をする奴がおかしい。
> 型を使うとバグが減る？そんなにレベルの低い人は使わなければいい。

その二つ、論点のすり替えだよね？

型を使うと速くなる？ → それは事実 → だから人間の問題にすり替える。
型を使うとバグが減る？ → それは事実 → だから人間の問題にすり替える。

事実ならまず「それは事実だね」って言ってみようか？
事実に対して反論するかと思いきや、反論しないんだもの（笑）

2019/08/05(月) 16:34:57.91

> でも、文法を拡張して既存コードとの非互換生むような修整は受け入れられない。

結局本音はそこ。

速くなるとかバグが減るという "事実" は存在するが、
既存コードの非互換性をうむから、改善できない。

2019/08/05(月) 17:42:09.05

>>581
型を入れてもオープンクラスな言語では大して速度は上がらない。精々一部のループの速度が上がるだけ。それは事実。java みたいに final や primitive 型入れれば効果は相当あると思うけど、それは Ruby を否定することになる。
型を入れると未熟なプログラマでもコンパイル時に分かる程度のバグなら発見できることはある。それは事実。でも実行時例外の回避は出来ないし、オープンクラスを使ったダックタイピングという Ruby の言語デザイン自体を否定することになる。

> 事実に対して反論するかと思いきや、反論しないんだもの（笑）

反論もなにも、自分はこのスレッドで >>344 >>577 >>578 しか書いてないよ。
だから、なんらかの反論を待ってるならその相手は自分ではない。

自分は Ruby に非互換を生む型の導入を期待するくらいなら、型有りの別の言語で書けばいいじゃんという立場。

>>580
この場合の strict モードって何を指してるの？
RPython 的に SRuby 作って型使いたい人は SRuby 使えってこと？同一バイナリにしてモード切り替えするとしたら、パーサも VM もほぼ別物レベルになると思うけど。
共有できるとしたら、pure ruby で書かれたごく一部のライブラリ程度じゃない？

2019/08/05(月) 17:55:40.47

型を入れてもオープンクラスな言語では大して速度は上がらない
→オープンでない言語なら速度は上がる
→速度を上げるためにはオープンでなくすれば良い
→そのような改善方法は存在するが、非互換性をうむから、取り入れられない。
→まつもと「Rubyでは改善はなんです。諦めてください」

2019/08/05(月) 17:55:56.86

→まつもと「Rubyでは改善は無理なんです。諦めてください」

2019/08/05(月) 17:58:22.53

>この場合の strict モードって何を指してるの？

適切な型を書いたものがstrictモード

だがどのオブジェクト指向でも、基底クラスのobject型として扱うことはできる。
暗黙的にobject型の変数を使ってるとみなしているのが今のRuby。

変数の型をobject型と書く（もしくは省略）か、適切な型を書くかの違い。

2019/08/05(月) 18:29:24.24

> 実行時例外の回避は出来ないし

は？

2019/08/05(月) 18:55:01.90

Rubyの癌は、型を指定できないことよりも、宣言ができないこと。
型を指定できないのは、宣言ができないことによる副産物。

宣言は、ここからこのオブジェクトを使うで、ということを明確にできてわかりやすいのに、何で嫌がってんだか。

2019/08/05(月) 19:04:12.59

>>586
strict モードにしたら
Class が凍結されるの？
途中でモードを切り替えられるの？
そのスコープは？
マルチスレッド時の挙動は？
Object クラス(Kernelも？)への継承関係がなくなるの？
データは VALUE 型じゃなくなるの？
オブジェクトのデータ構造は自分で C で定義するの？
既存CAPIとの整合はどう取るの？
そのコードを古いインタプリタに食わせたらどうなるの？
また分断するの？(想像するに1.4->1.6 や 1.8->1.9 より大きそうだけど)
strict にしたら何がどう変わるのかわからん。
過去に例示してあるのなら参照求む。

>>585
そう。大抵の要望は Crystal で解決されてると思う。
速度欲しいなら Elixir 。もしくは C で FFI。

2019/08/05(月) 19:13:25.94

>>589
うん？だからそういう問題が発生するから、
Rubyでは型という素晴らしい道具を導入することが
設計上不可能って話をしてるんだが？

2019/08/05(月) 19:28:52.54

>>590
そのかわり型ということを考えなくても計算機と対話することができる日常用途に便利な言語になったわけだ。

2019/08/05(月) 19:32:29.27

Rubyにも型があるんだから、型考えてるでしょｗ
それともどんな型を入れても、エラーにならずに動くコードかいてんのか？

2019/08/05(月) 21:15:23.92

型チェックが欲しい人は他の言語使えって言ってるけど
Ruby3.0で型チェックが導入されるんだからそこは前向きに検討しようよwww

matzが言うようにRubyに型が指定できるようになったら、指定すべきという勢力も
出てくるだろうし、一方でわざと型を書くのが億劫になる仕様にしてあるし
どちらの勢力が勝つか未知数というか
平行線が続いて空中分解してクラッシュするかもしれないし
ここでも今そういう意見があるように、今までは型チェックが欲しい人は他の言語使え
だったわけだけど、Ruby3.0からはそうじゃなくなるから更にカオスになるだろう
今までは型を書くべきかどうかはRuby 対他の言語って感じだったけど
これからはRubyの中でそれが起こる
楽しみだね
このへん、言語仕様で初めからどちらかに決まっていた方がスッキリしていたかもしれないね

2019/08/05(月) 21:19:04.07

それに加えて型定義ファイルの自動生成の話もあるが
まぁ最初は使い物にならないだろうからそれも含めてカオスになる
それがRuby3.0

静的型言語も動的型言語を取り入れてるっていうけど
こっちは何の問題もなく行われてて全くの静寂なのが笑える
まぁ型推論はコンパイラが型を推論してくれるというだけで
型は静的に決定されているわけだから当たり前なんだけど

2019/08/05(月) 21:29:41.54

型は書いたほうが良いが今更自然な形での導入は難しい
しかし3.0で書きにくいけど書けるようになる
書けるようになるなら書いたほうが良い
でも書きにくい
でも書かなきゃ
でも書きにくい
書きたくない
でも書かなきゃ
でも書きにくい

これがRuby3.0

2019/08/05(月) 21:34:38.65

型注釈、PythonとRuby両方でやってみたけど
Pythonの方が全然完成度高い
試験的な実装とはいえRubyの方は複雑になるとチェック通せなくなる

2019/08/06(火) 15:11:10.96

実行時まで型が決まらない

ひとことで言え

2019/08/06(火) 17:04:56.96

実行時まで型が決まらないと言うが、
コードは特定の型もしくは特定のインターフェースを備えた
型であるという前提になってるんだよなｗ

2019/08/06(火) 18:28:14.04

perl5の末期に登場したのがuse strictとuse warningだよ
それを順当に真似てるだけだ
他意は無い

2019/08/06(火) 20:21:21.15

前々からの、掛け違えたボタンの、いよいよ一番上を閉めようとしている段階なのだよ
そんなことは出来ないか、不格好か、首が絞まるか
何にせよ、こういう仇花的なことをしなければならない状況に追い込めたのは
日々のみんなの空気づくりのおかげであって、いわば人類側の勝利だよ
おめでとう

2019/08/06(火) 20:25:09.69

まずはモンキーパッチを抑制するオプションを追加して
静的に解析できるようにするのが先でしょ

2019/08/06(火) 20:27:16.73

>>599
Perl5に「末期」なんかないぞ。
まだまだ現役だからな。ｗ

2019/08/06(火) 20:34:15.67

モンキーパッチ（オープンクラス）ができるのはメリットではあるが、
通常はそんなことしないので、小さなメリットのために
大きなデメリットが発生してるんだよな。
最終手段を取るしか無いところだけ、unsafeとかマークを付けて対応すればよかった。

2019/08/07(水) 18:14:09.58

>>596
>Pythonの方が全然完成度高い

当然の感想だよ
そもそも静的型付けは大きく以下の２つに分類される
・明示的(explicit)な型付け
・暗黙的(implicit)な型付け

前者の明示的型付けはプログラマが型定義を手書きすることを前提としており、
Fortran/Cobolといった1950年代の太古の時代から培われてきた「枯れた技術」である
Python の型アノーテーションも明示的型付けに分類される
従って、完成度が高いのも当然、できて当たり前と言える

後者の暗黙的型付けは堅牢な型システムを前提とし、処理系が「型推論」と呼ばれる技術により
コードから型定義を自動的に決定するものであり、1980年代にMLで開発され、近年、明示的型付けを
主としながら部分的に暗黙性を取り込む次世代言語が次々に登場するなど、急速に普及が進みつつある

MatzがRubyKaigi 2019で語った：
https://logmi.jp/tech/articles/321280
「最近は静的型がすごくホットで、2010年代のプログラミング言語はみんな静的型言語で、…」
というホットな静的型言語も、後者の暗黙的型付けを指す
同時にMatzが語った：
「もう、われわれもやろうか。PHPもPythonもやってるし」って言うんだけど、正直やりたくない……。」
の「やりたくない」のは前者の(プログラマが型定義を手書きしなければ型検査が働かない)明示的型付けを指す
つまり意訳すると：
　Rubyでも明示的型付けをやろうと思えばいつでもできるけど、今さら時代に逆行したできて当たり前の事を
　やるなんてつまんない、それより今まで誰もやったこともない血が湧き立つような挑戦をしてみたい、
　それがRubyらしさだよ
そして、この後、「動的型付け言語であるRubyにおける暗黙的な静的型付けの導入方針」として、
(型推論の代用である)「型プロファイラ」と呼ぶ新技術の紹介が続くわけだ

2019/08/07(水) 18:42:31.98

>>604
なにかごちゃごちゃ語ってるけど、

マッツが言った「やりたくない」は
面倒くさいって意味だよ。

血が湧き立つような挑戦なんてものを思いついていたら
それを理由にするだろ。そんなもんないからさｗ

2019/08/07(水) 19:39:46.36

そら掛け違えたボタンの一番上を締めるのは
血が逆流するほど苦しくて沸き立つだろうな
こんなもんは北朝鮮とか共産党とかの言ってる理想みたいなもので
最初に掛け違えてるからそういう夢を見なきゃいけない羽目になってるだけで
大人になったらさらっと流さなきゃね

2019/08/07(水) 19:40:25.87

マルクスとかに感化されて
血が沸き立つような挑戦
って言ってるようなものなんよ

2019/08/07(水) 20:15:49.09

他は学生運動とかかな>血が湧き立つような
俺は世代じゃないからよく知らんけど、映像見る限り、かなり湧き立ってるな

後単に、「血が湧き立つようなっ」て表現面白い(こわッ

まぁそういうのはあるよ
最初を掛け違えたため人生台無しになるっていう
大概の人はどこかで気づいて掛け直すから大事には至らないけど
物事を考える最初の起点が一つズレて、以降思考が全部ズレる
ゴールにたどり着けないもんだから、ゴールのさらに先へ行こうと夢見る
そうやってたぶらかす
共産党みたいな輩

根本の問題だからなぁ
悪人は悪人にしかなれないってわけじゃないけど
気づけなきゃ悪人のまま終わるよね

2019/08/08(木) 10:01:50.60

すげえ馬鹿な質問するけど
x = [nil, "hoge", 42, 3.14].sample
みたいなのがあった時って型推論ってどうなるの？

2019/08/08(木) 10:56:04.30

rubyに限らずスクリプト系はlispが基準だろ
だからリストにはなんでも入れれる

2019/08/08(木) 12:56:56.32

>>609
理想としてはArray<nil|String|Integer|Float>みたいな感じかね

2019/08/08(木) 15:33:58.94

C#的にはエラー(推論不可)だな。
それでいいと思う。

2019/08/08(木) 21:48:40.95

TypeScriptは型システムの表現が凄すぎて
大抵の言語に型付けできそう
パクればRubyにも型付けできるんじゃね

2019/08/08(木) 22:17:23.13

Haxe では、Array<Dynamic> で、何の型でも入る、配列を定義できる

これは型推論しないから、できる限り避けるべき！
これは、設計ミスかも知れない

2019/08/11(日) 09:42:24.48

typescript なら [ null, string, number, ‘foo’ | ‘bar’, 1 | 2 ]
のように定義できるしね

2019/08/12(月) 10:28:41.63

そうやって夢を見ておけばいい
その方が落胆が大きくなるだろうから

2019/08/12(月) 21:41:57.67

とにかくTSからパクれるものは全部パクった方がいいと思うんだが
JSに無理やり型付けするために生み出されたキメラなのだから
参考になる部分だらけなはず

2019/08/12(月) 22:34:28.71

全然違う方向へ向かってるから無理

2019/08/13(火) 09:14:00.33

TSで書いてRuby吐くコンパイラω

2019/08/17(土) 14:16:33.22

>>617
JavaScriptはそもそも静的型付け言語であるCやJavaの構文を参考にして設計された言語だ
医学部卒のプロ棋士が引退して医師に転向することは容易だが、中卒には不可能である

2019/08/17(土) 16:35:39.55

>>620
> JavaScriptはそもそも静的型付け言語であるCやJavaの構文を参考にして設計された言語だ
大嘘つくなよ
似てるのは中括弧を使ったブロックとかの見た目だけじゃん

2019/08/17(土) 16:44:03.64

>>621
だから構文の話をしてるんだろ

2019/08/17(土) 16:58:40.60

jsは構文でもJavaと似ても似つかないぞ

2019/08/17(土) 17:04:14.21

惜しい
jsですら似ても似つかないなら、Rubyだったらどうなのか考えてみよう
基準はあくまでRubyであることを忘れないようにしましょう

2019/08/17(土) 17:16:36.20

話を逸らすのはチョン國人の手口

2019/08/17(土) 19:31:09.99

>>622
中括弧使ってセミコロン使えば静的型付けになるのかよｗ
的外れもいいとこ

2019/08/17(土) 19:37:00.00

>>625
死ねよネトウヨ
お前もチョンがどうのとか言って話そらしてんじゃん

2019/08/17(土) 21:08:03.39

>>624
JavaScriptに比べたら、Rubyのほうがまだ似てるんだよなあ。ｗ

JavaScriptのクラス定義を見たことがあるか？プロトタイプベースなので、ほかではなかなか見られないぞ。

2019/08/17(土) 22:01:43.78

JavaScriptのクラス定義は、C++やJavaにそっくり

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Classes

class Rectangle {
　constructor(height, width) {
　　this.height = height;
　　this.width = width;
　}

　// ゲッター
　get area() {
　　return this.calcArea();
　}

　// メソッド
　calcArea() {
　　return this.height * this.width;
　}
}

const square = new Rectangle(10, 10);

console.log(square.area); // 100

2019/08/17(土) 22:03:16.05

プライベートフィールドはちょっと変わってる。

class Rectangle {
　#height = 0;
　#width;
　static #depth = 1;

　constructor(height, width) {
　　this.#height = height;
　　this.#width = width;
　}

　volume(){
　　return this.#height * this.#width * Rectangle.#depth;
　}
}

2019/08/17(土) 22:03:58.27

JavaScriptの継承もC++やJavaとそっくり

class Dog extends Animal {
　constructor(name) {
　　super(name); // 親クラスのコンストラクタを呼び出し、name パラメータを渡す
　}

　speak() {
　　console.log(`${this.name} barks.`);
　}
}

2019/08/17(土) 23:51:47.98

Node.js は、Ruby のコピー。
npm, yarn も、Bundler のコピー

CakePHP は、Rails のコピー

2019/08/18(日) 00:59:22.65

> Node.js は、Ruby のコピー。
間違い。Node.jsは言語ではなく実行環境（≒ライブラリを提供してる）

Rubyという言語をコピーするわけないじゃないですか（笑）

ツールやフレームワークに価値はあって、そっちはコピーしたとしても
Rubyという言語にコピーする価値はないですからねｗ

2019/08/18(日) 01:51:43.24

>>629
つい最近そうできるようになっただけやけどな。ｗ

2019/08/18(日) 01:59:35.72

>>634
つい最近 = 4年も前

それを今知ったんかい？ｗ

2019/08/18(日) 03:22:24.68

元から似せて作ってないって話でしょ

**632** (ﾜｯﾁｮｲ 132c-BF++) · 2019/08/18(日) 08:06:58.21

Node.js は、Ruby 実装系のコピーだろ。
npm, yarn も、Bundler そっくり！

npm, yarn のlockfile とか、Bundler のlockfileと同じ

Ruby, Node.js も、サーバー側プログラミング

2019/08/18(日) 08:22:32.26

> Node.js は、Ruby 実装系のコピーだろ。

全く違う。似てるところが一つもないと言っていいレベル
つーか、Rubyにぱくれるところなんてなにもない

2019/08/18(日) 09:44:57.54

ちょっとこの信者なんとかしてくれない？
スキルセットがRubyしか無いから、何が何でもRubyのコピーだと言い張ってて鬱陶しいんだけど。

2019/08/22(木) 23:17:51.79

WEB+DB vol.111 は、Ruby on Rails 6, Julia 特集だけど、
Python から、Julia へ流れそう

Julia は、do ～ end が使えて、Ruby風に改良されてる！
Jupyter Notebook(JN)でも使える

Windows で、RubyをJNで使っている人は、日本語でバグらないの？
irb では、バグるけど

RubyをVSCode で使っているけど、JNでも日本語でバグらないかどうか、知りたい

2019/08/23(金) 01:33:05.16

ocraやgolangのgo buildみたいにRubyスクリプトとその要求ファイルを
単一の実行ファイルに固める仕掛けのLinux/FreeBSD向けってありませんか？
利用側でのセットアップを簡単にするために探しています

2019/08/23(金) 02:21:20.94

Bundler は？

Node.js のnpm, yarn と同様の、パッケージマネージャー

2019/08/23(金) 07:21:08.15

Bundler というより、gem だね
gem を作れば1ファイルにできる

2019/08/25(日) 21:34:28.24

>>640
JuliaとPythonじゃ目指してる方向が違うから、PythonがまるまるJuliaに移行するということはないよ。
numpyでゴリゴリ計算してるようなものはJuliaに移行するだろうけど、
Cなどで書かれた外部ライブラリを呼び出しまくっているようなものが移行するとは思えない。

2019/08/25(日) 22:57:02.68

結局、Perl5はシステム、RubyはWebバックエンド、Pythonは機械学習と、確立した用途で落ち着いてしまいそうだよなあ。

2019/08/25(日) 23:37:44.87

Rubyは良く出来た言語だが、困るのはバイナリ処理したいとき
バイナリを扱うことはできるらしいが、かなり面倒そうで結局やらない
rubyにCのインタプリタを内蔵してはどうなのだろう
AIなど一挙に使える範囲が広がる

2019/08/26(月) 00:06:00.18

もうCでよくない？

2019/08/26(月) 00:08:19.86

でもたいていのところではrubの方がでいいわけですし

2019/08/26(月) 03:42:42.45

>>646
バイナリ処理は、目的とやりようによっては、C/C++よりもPerl5/Rubyのほうが簡単なんだが。
pack/unpackが意外と使いやすいからな。

2019/08/26(月) 03:47:15.63

バイナリはバイナリのまま処理すればいいと思うんだが、
なんでいちいちpack/unpackなんかするんだ？

2019/08/26(月) 10:06:15.99

perlからの流れであり深い意味は無い
それが好ましいと言う奴だけがrubyを使ってる
だから宗教だ

「わたくしはそれを気にいっている」宗教ではコレ以外の理由は必要無い

2019/08/26(月) 13:12:19.64

>>650
スクリプト言語は原則として、メモリに直接アクセスするようにはできていない。

念のために言っておくと、C/C++のキャストと比較しているのならそもそも大間違い。
また、あれはあれで問題だらけ。

2019/08/26(月) 13:36:12.79

例えば？

2019/08/26(月) 13:43:52.88

バイナリのまま処理すればっていってるだけで
メモリに直接アクセスしろなんて言ってないんだが

2019/08/26(月) 14:43:00.63

>rubyにCのインタプリタ

ffiとかwin32apiとかじゃだめなんか

2019/08/26(月) 17:33:50.52

>>655
win32apiはちょっとできることが違うように思います
ffiというのは知らなかったので調べてみます

RubyGemパッケージrest-client、バックドアを含むバージョンが立て続けに公開される
https://security.srad.jp/story/19/08/25/0620202/
不正に公開されたのはバージョン1.6.10/1.6.11/1.6.12/1.6.13の4バージョン
1.6.13は1,061回ダウンロードされていたそうだ

2019/08/26(月) 19:08:01.58

質問です。
配列64個分packしたいんですけど、どうすればpackできますか？
よろしくお願いしますm(_ _)m
a=[0]*64
a.pack("i*")

2019/08/26(月) 19:29:23.21

a[5]=800
のようにデータを入れてから送りたいです

2019/08/26(月) 19:39:44.11

出来ました。
失礼しました

2019/08/26(月) 20:06:48.18

>>653,654
聞かなきゃわからんヤツ、自分が何を言ってるかわからんヤツは、「バイナリ」に手を出さんほうがええで。
どうせ自分の面倒を見られへんやろからな。

2019/08/26(月) 20:18:12.71

>>660
あぁ、えとなぁ、お前、Javaはバイナリを直接扱えるが
メモリに直接アクセスってお前は何を言いたいのか
ちゃんと言えるか？って聞いてんだよ。

2019/08/26(月) 20:46:55.19

いいぞ
もっとやれ

2019/08/27(火) 01:27:52.33

これほど自信満々なところを見ると俺らが知ってるバイナリと
>>660の頭の中のバイナリは違うものなんやろな

2019/08/27(火) 07:36:50.86

bit演算を使えば一度に計算できることを
ループと何重にもネストしたif文でやってる
プログラムを何度も見たことがある

2019/08/30(金) 02:31:29.55

RubyはPythonにはもちろんだけどPHPにも喰われ出してるね
何故こうなってしまったんだろうか
文法というか記法が独特だからなのかな

2019/08/30(金) 09:52:23.42

元々大した事なかったからな
Railsみたいなモルヒネで延命してるうちに手遅れになった

2019/08/30(金) 14:40:23.42

>>650
自分でTCP/IPパケットの解析をするときに、「バイナリはバイナリのまま処理すれば」十分なの？
バイナリをバイナリのまま処理できるのなんてコピーぐらいの単純なIOしか思いつかないのだが。

バイナリって文字列じゃないだけであって区切りを持った意味のあるバイト列だからね。

2019/08/30(金) 14:48:49.55

>>667
何が言いたいのかさっぱりわからん。pack/unpackなんか使わずに
特定の型の構造体として扱えばいいって言ってるだけなんだが？

2019/08/31(土) 05:20:39.23

unionみたいなのあったっけ？