[過去ﾛｸﾞ] C++相談室 part154 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
399: 2021/01/31(日)20:39 ID:/1NNOLNs(4/4) AAS
pairはSTLのアルゴリズムの恩恵を得るための物。
自宅の郵便受けを豪華にしたところで、郵便事業には何の関係もない。ただの趣味の世界。
400(1): 2021/01/31(日)21:08 ID:vFnk+kXo(2/2) AAS
set< pear<int, int> > で、ある数を含む pear を高速に検索する方法ってある？
401: 2021/01/31(日)21:47 ID:jyYnHelr(1) AAS
set<int, vector<pair<int,int>*>>
元の集合に１億個程度のペアが入ってるとすると、住所録めいたものをあらかじめ生成しておく
配列でやっても速そう
list[m].empty()
こういうリストで空っぽかどうかわかればいいわけだ
vector<vector<pair<int,int>*>>>;
それならドでかい二次元配列に入れた方がラクかもしれない
連想配列でも出来る
map<int ,vector<pair<int,int>*>>>
静的な話だったが動的つまり追加と検索が交互に起こるとおそらく話は違ってくる
全部試して早かったモンが高速である、程度の他愛ない結論に落ち着く
402: 2021/01/31(日)22:01 ID:gvpDZJRs(1) AAS
構造体にしろよバカども
読みにくいだろ
403: ◆QZaw55cn4c 2021/01/31(日)22:54 ID:wKQ2AmTw(1) AAS
>>333
>>339
では _x ではなく x_ にしようっかな‥‥
404: 2021/01/31(日)23:01 ID:eyFvwlDf(1) AAS
googleスタイルガイドはそちらを推してるな
405(1): 2021/02/01(月)01:17 ID:FSry25xS(1/3) AAS
>>391
int _x=_y;
int _y=_x;
ここの二行目の右辺の_xは、b(_y,_x)の第二引数の_xではなく、一行目
で宣言した_xになっているので、b(_y,_x)の第一引数の_yになる。つまり、
int _x=引数の_y;
int _y=引数の_y;
となるので、{}の中の_x, _yは、どちらも引数の_yの値に等しくなってしまう。
これではマクロ作者が意図したことではなくなってしまう。
406(2): 2021/02/01(月)01:19 ID:FSry25xS(2/3) AAS
>>394
まあ、それはもっともな指摘なのだが、アプリ本体では使用禁止で、
マクロでは使用可能と勝手に解釈してしまうのが一つの流儀。
407(1): 2021/02/01(月)01:22 ID:FSry25xS(3/3) AAS
>>389
そうではなくて、ローカルスコープで使うことそのものが、file scope
で使ってないことに当たるので、規約違反と言うことになると解釈できる
気がするんだ。
なぜそんなルールにしたのかは分からんがな。
408(1): 2021/02/01(月)03:22 ID:fw9rYrIy(1) AAS
>>405
残念だったね。インライン関数使おうね。
>>406
あなたの流儀を規格の定めであるかのように話すのは迷惑なのでやめてくださいね。
>>407
file scope で予約されてる名前を file scope で使ってないなら問題ないね。
規約違反などという解釈にはならない。気のせい。そんなルールになってない。ってことで終われよ。
409: 2021/02/01(月)07:01 ID:v6ebtUL1(1/2) AAS
>>400
unordered_map<int, int>
410: 2021/02/01(月)07:30 ID:LhepLs74(1/3) AAS
>>406
マクロ定義内の仮引数名は当のマクロ定義外の何者とも関係しないのでは…
いわゆる束縛変数
411: 2021/02/01(月)07:38 ID:LhepLs74(2/3) AAS
として安全に取り扱われる
一方>>346の_xはa(x)が展開された結果が他のプリプロセッサ定義で再置換され得るなら危険
これが起きるかはプリプロセッサの仕様（規格）を見たら白黒付くが
個人的には君子なので危うきには近づかないことに死体、
412: 2021/02/01(月)08:09 ID:v6ebtUL1(2/2) AAS
うちの若いのがあんなアホマクロ書いてたら張っ倒す
まあ、やらかしそうなのはいないけど
413: 2021/02/01(月)09:26 ID:5yr9aQzL(1) AAS
>>346
そもそもそのマクロで生成される変数はファイルスコープでないから、そもそも問題外では？
仮にファイルスコープな変数を宣言するようなマクロでも、ユーザが意図せず
414(2): 2021/02/01(月)11:43 ID:xFB8fPis(1) AAS
仕事に情熱が持てなくなった
415: 2021/02/01(月)11:43 ID:VhfMLcQM(1) AAS
>>346
アホだ
416(1): 2021/02/01(月)12:06 ID:ZelzH3+k(1/7) AAS
>>414
コロナの影響だろな。
福島大爆発の影響も計り知れない。
「原爆ぶらぶら病」で検索してください。
417(3): 2021/02/01(月)12:30 ID:jyRtFT93(1/4) AAS
>>408
>file scope で予約されてる名前を file scope で使ってないなら問題ないね。
そうじゃない。
英語原文を読めば、file scopeで予約されているのではなく、file scopeで
使用するために予約されているのだ。
だから、file scope以外で使用することが禁止されている。
418: 2021/02/01(月)12:32 ID:jyRtFT93(2/4) AAS
>>417
日本語で言うなら、「file scope 専用」。
419: 2021/02/01(月)12:46 ID:/T40sBmV(1) AAS
>>414
ちゃんと飯を食え。
週末はちゃんち休め。
年10日は連続した休暇をとれ
420: 2021/02/01(月)12:55 ID:ioMwojjO(1) AAS
>>417
その一文ばっかりやたらこだわるけど
これが属しているセクションの名前って「17.4.3.1.2 Global names」なんだわ
グローバル名前空間の名前以外については言及してないの
ドラフトならインターネットで無料で見られるんだからこの辺の全容見てきな？
421: 2021/02/01(月)13:14 ID:Z79JHlVc(1/2) AAS
>>417
あらゆる場所で使ってはいけないのなら、7.1.3でわざわざ1つ目と対比させるように使用用途を限定して記載した理由を説明してよ。
普通はコンパイラ実装者のために予約されている、だけで十分でしょ
422: 2021/02/01(月)13:45 ID:fos4FOVO(1/4) AAS
仕事に情熱が持てなくなった
423(1): 2021/02/01(月)13:50 ID:jyRtFT93(3/4) AAS
外部ﾘﾝｸ:www.learncpp.com
Second, you should avoid naming your identifiers starting with an underscore, as these names are typically reserved for OS, library, and/or compiler use.
424(1): 2021/02/01(月)14:08 ID:fos4FOVO(2/4) AAS
>>373
obj& operator [] (int i) {return elem[i];}
もちろんelem[]の定義はobj elem[];
obj.shape() も実装すると便利
425: 2021/02/01(月)14:13 ID:fos4FOVO(3/4) AAS
>>416
「コロナでゴロゴロ病」
426(1): 2021/02/01(月)15:47 ID:Z79JHlVc(2/2) AAS
>>423
そのサイトを紹介して何の証明になるの？
427: 2021/02/01(月)16:16 ID:ZelzH3+k(2/7) AAS
>>426
外部ﾘﾝｸ:isocpp.org
428: 2021/02/01(月)16:22 ID:ZelzH3+k(3/7) AAS
C++ is the only real language for expert developers.
429: 2021/02/01(月)16:55 ID:fos4FOVO(4/4) AAS
C/C++は好きだし比較的最強の部類だと思うけど
夢未過ぎは判断を誤るから色んな言語を適材適所に使えるようになるのが理想
430: 2021/02/01(月)17:40 ID:LhepLs74(3/3) AAS
システム記述言語はアセンブラを除けばこの世にCとC++とRustしか、
431: 2021/02/01(月)17:46 ID:ZelzH3+k(4/7) AAS
中国人のありがたいお言葉ですぞ。
432: 2021/02/01(月)18:02 ID:jyRtFT93(4/4) AAS
大体、この板には中国人や韓国人はほとんど来ず、来ているのはアメリカ人
やヨーロッパやアフリカが多いらしい。
433: 2021/02/01(月)18:44 ID:+21BJdPm(1) AAS
いやrustが最強でしょww
434(1): 2021/02/01(月)18:47 ID:CDWd/LQ7(1) AAS
Goは駄目なん？
435(1): 2021/02/01(月)18:57 ID:0s4gr52A(1) AAS
自作の構造体をsetに入れたいときって operator < さえ定義しとけば良いの？
eraseとかは全部のメンバが同じものを見つけて消してくれると思って良い？
436: 2021/02/01(月)21:08 ID:ZelzH3+k(5/7) AAS
検索するとひろみをお勧めしてくる時点で無理だった。
437: 2021/02/01(月)21:34 ID:ZelzH3+k(6/7) AAS
しかもチップも取るんかーい！
438: 2021/02/01(月)22:43 ID:CtNYZU7D(1/2) AAS
>>435
erase含め、同値性は!(a<b)&&!(b<a)で判定される
全メンバ一致で同値とみなしたいなら辞書順比較する比較関数を定義すればよし
439: 2021/02/01(月)22:46 ID:FbSt8IWH(1) AAS
演算子オーバーロードは地雷度高い。
440: 2021/02/01(月)22:53 ID:CtNYZU7D(2/2) AAS
まあ、setに入れるためだけなら演算子オーバーロードするより関数オブジェクト使う方がいいかね
441: 2021/02/01(月)23:03 ID:f9q1oLiO(1/2) AAS
C++の質問じゃないとは思うんですが、上位数ビットを0で埋めたいといった場合は
「0埋めしたいビットを0、他を1にしたもので&演算する」
であってますか？
442(1): 2021/02/01(月)23:11 ID:ZelzH3+k(7/7) AAS
合ってます。
443(2): 2021/02/01(月)23:17 ID:f9q1oLiO(2/2) AAS
>>442
ありがとうございます
今までは例えばQWORDの上位3バイトを0埋めしたいってとき(value << 3*8) >> 3*8って言う2命令使う馬鹿な方法でやっていました・・・
444: 2021/02/02(火)02:08 ID:DmcXRB7X(1/2) AAS
へ椅子ブックが少し綺麗になってます。
445: 2021/02/02(火)02:10 ID:DmcXRB7X(2/2) AAS
RedditのC++コミュは17万人、オンラインが500人以上。
凄いね。
446(1): 2021/02/02(火)10:17 ID:uFATDe77(1) AAS
ビット演算の中で最速なのってシフトじゃなかったっけ？
だから下手したら>>443の方がフェムト秒レベルでは微妙に早いんじゃない？
447: 2021/02/02(火)10:29 ID:kGc73xZq(1) AAS
命令語長がマスク分だけでもQWORDに対して、シフトなら1バイト程度か
448: 2021/02/02(火)12:37 ID:vWAdhQ36(1) AAS
>>446
CPUの世代やアーキテクチャによって違うが、
Latencyが、Shiftの方がandより少し遅いことがある。
449: はちみつ餃子 ◆8X2XSCHEME 2021/02/02(火)12:49 ID:+MtixY9O(1) AAS
>>434
Go は GC が前提にあるから少し制約が強いけども、
OS のカーネルを書くのでもない限り思ったより足かせにならないという評価はあるみたいだね。
450: 2021/02/02(火)13:08 ID:aIAA0dxH(1) AAS
Goはクソすぎるから駄目だ
何が駄目といってまず名前が駄目
451: 2021/02/02(火)13:45 ID:8HFbTrXI(1/2) AAS
GoはPC初心者用
昔でいういわばBASIC
452: 2021/02/02(火)18:03 ID:FSwj4KRK(1) AAS
バレルシフタと単純ゲート
レイテンシも糞もねえだろ
453: 2021/02/02(火)18:11 ID:8HFbTrXI(2/2) AAS
でもその縛りプレイが大好きな変人も居る
454: 2021/02/02(火)22:23 ID:likaPPB8(1/3) AAS
operator ==も定義しておくとなお良い
==のために<が2回呼ばれるのもアホらしいと感じるはず…
結局std::rel_opsを使って全部定義するという結論に落ち着く
455: 2021/02/02(火)22:25 ID:likaPPB8(2/3) AAS
インテルのやつはバレルシフタじゃない気配がする…
シフト結果をテーブル化した方が速かったことｇ
456: 2021/02/02(火)22:28 ID:likaPPB8(3/3) AAS
あるいは最大限バレルシフタにしようとしているがパイプライン1段に収まっていないだけかもしれん…
457: はちみつ餃子 ◆8X2XSCHEME 2021/02/03(水)00:25 ID:p0NvFN6a(1/2) AAS
>>443
gcc, clang, msvc で最適化最大で試してみたら and をとるように最適化されたぞ。
主要コンパイラがそのように最適化するということは (前後の状況によるかもしれないけど)
たぶん and のほうが効率的ってことなんだろう。
458(2): 2021/02/03(水)00:38 ID:53EFMpkm(1/4) AAS
ビットシフトは64bit整数でのコンパイラ解釈が信用できないからAND演算子使うのが確実だと思うけどどうかな。
459: 2021/02/03(水)00:51 ID:5b6XJ+8s(1) AAS
>>458
落ち着いてよく考えてみよう
お前がC++で作った成果物のうち、お前自身が書いたコードの割合なんてごくごく僅かに過ぎない
仮にそんなレベルで互換性が当てにならないような環境があったとして、お前が直接書いていない他の99%のコードがまともに動くと本気で思うか？
460(2): はちみつ餃子 ◆8X2XSCHEME 2021/02/03(水)00:54 ID:p0NvFN6a(2/2) AAS
0xffffffffff とか書いてたら桁数を正しく書けてるか不安になる……
今の C++ だと桁区切りも入れられるけど、
どう入れたら意図がわかりやすいかようわからんし、
シフトで表現するのもありな選択だと思う。
461: 2021/02/03(水)01:01 ID:+m9V7fCu(1/2) AAS
>>458
具体例をお願いできますか？
462(1): 2021/02/03(水)01:20 ID:53EFMpkm(2/4) AAS
コンパイラがちゃんと32bit整数への丸め警告を出してくれるならいいが、しれっとコンパイルされたらお手上げ。
463: 2021/02/03(水)02:47 ID:+m9V7fCu(2/2) AAS
>>462
丸めって暗黙の型変換のことですか？
シフト演算は特に関係しないと思いますが……
464: 2021/02/03(水)06:01 ID:QcjMAifW(1) AAS
>>460
0x0000'ffffull
465(3): 2021/02/03(水)06:29 ID:y3dS6mbz(1/2) AAS
unsigned long long x = (0x1ULL << 32) - 1ULL;
ならちゃんと動く（と思う）が
unsigned long long x = (0x1 << 32) - 1;
とかだとｲﾏｲﾁ不安が…
466: 2021/02/03(水)06:38 ID:Nl+WsQpo(1) AAS
>>465
下の方はイコールの右辺にintしか出てこないのだから、intが32bitの環境なら32bitでしか計算されないだろう
467: 2021/02/03(水)10:23 ID:q8Ed7guF(1) AAS
丸めと暗黙の型変換は違うものでは？
468: 2021/02/03(水)11:47 ID:HtH84Poo(1) AAS
丸めや打ち切りは浮動小数点数の概念やね
469: 2021/02/03(水)13:02 ID:53EFMpkm(3/4) AAS
ビットシフト記述は自然すぎてソースコードに埋もれてしまう。
64ビットマスクのAND記述は見た目がどぎついので、かえって人間の注意を引くことができる。
470: 2021/02/03(水)14:45 ID:J722wycU(1) AAS
なにいってんだこいつ
471(1): 2021/02/03(水)15:50 ID:pE1foWCw(1) AAS
>>465
やっぱり、32BITの時が一番プログラミングし易かったな。
64BITになると、64BITと32BITを区別して書く必要が出てきて、
書くのが面倒になった。
472: 2021/02/03(水)19:12 ID:XaYGR0Wv(1) AAS
そう？ポインタサイズくらいしか違いなくない？
473(2): 2021/02/03(水)21:29 ID:53EFMpkm(4/4) AAS
まじめにC/C++標準型size_tを使っている人には32bitと64bitの処理切り分けが地味に辛い。
474: 2021/02/03(水)22:36 ID:y3dS6mbz(2/2) AAS
>>465の下の方のやつは符号拡張されたりする気がするorz
475(1): 2021/02/03(水)22:40 ID:Ea4RwHR/(1) AAS
>>424
> obj& operator [] (int i) {return elem[i];}
> もちろんelem[]の定義はobj elem[];
objは行列クラスで、elemはobjのメンバで行列要素を格納する一次元配列、で合ってますよね？
class obj{
array<int, ?> elem;
public:
obj& operator [] (int i) {return elem[i];}
};
ということですか？
476: 2021/02/04(木)03:22 ID:R0EDVzG0(1/2) AAS
>>473
size_t は、型名が長いし _ も含んでいるし、打つのが辛い。
それにコードに締める長さも長くなるので画面が狭くなるし。
477: 2021/02/04(木)04:17 ID:SkZt7jTc(1) AAS
>>473
まじめに、て別にsize_t使ってたら偉いわけじゃない
サイズを表したいけどいちいち考えたくない場合の選択肢だぞ
478: 2021/02/04(木)11:32 ID:sIhIIpMX(1/2) AAS
size_t型はSTLを使う人なら避けて通れない。
479(1): 2021/02/04(木)11:40 ID:ZzRKCYY/(1/2) AAS
>>471
それ本来そこにあった問題に気付いていないだけだったと思うぞ
480(1): 2021/02/04(木)11:44 ID:ZzRKCYY/(2/2) AAS
>>475
class obj{
array<obj, ?> elem;
public:
obj& operator [] (int i) {return elem[i];}
};
481(1): 2021/02/04(木)12:06 ID:DWE1XJjK(1/2) AAS
>>480
それってarrayのarrayとかvectorのvectorとか配列の配列として行列を作るのと同じですよね？
一次元配列に要素を格納しておいて[][]でアクセスするのは不可能なんでしょうか
row majorやcolumn majorを自由にできる、等の理由でそちらの方が好ましいのですが
482(2): 2021/02/04(木)12:29 ID:waKgX41w(1) AAS
一次元配列を内包しているクラスのoperator[](int y)が、下記のようなクラスを返すようにすればできる。
class Row {
vector<int>& 一次元配列への参照
int 列数
int y
int& operator[](int x){ return 一次元配列への参照[列数*y+x]; }
};
でも自分ならoperator[]は使わずもとのクラスにindex(x, y)みたいな関数を用意して対処すると思う。
483(1): 2021/02/04(木)13:10 ID:g2cSm/y9(1) AAS
malloc とか new で確保したメモリ領域を使うように
vector ( または array ) をインスタンス化するにはどうすればよいですか？
484(1): はちみつ餃子 ◆8X2XSCHEME 2021/02/04(木)13:13 ID:ttCVH4wp(1/2) AAS
>>481
こういう雰囲気で他のクラスをひとつ間に入れることでなんとかなる。
外部ﾘﾝｸ:wandbox.org
だけど俺も >>482 の言う通り operator[] にこだわらずに適当なメンバ関数でやる方法を推すわ。
実態として二引数なのだし、記法のためだけに余計な定義をするの馬鹿らしいと思う。
提案としては hoge[i, j] みたいな感じで二引数のインデックスを受け取れるようにする案は出てるんだが、
現状ではこのときのカンマは普通にカンマ演算子として解釈される。
前準備として、 C++20 からはブラケット内でのカンマは非推奨にするという変更が入っている。
外部ﾘﾝｸ:timsong-cpp.github.io
485: はちみつ餃子 ◆8X2XSCHEME 2021/02/04(木)13:20 ID:ttCVH4wp(2/2) AAS
>>483
ある時点で確保済みのメモリの上にオブジェクトを構築するには
std::uninitialized_default_construct を使う。
でも std::vector 自体を適当なメモリの上に構築できても
std::vector 内で使うメモリは std::allocator で確保しようとするから、
必要ならアロケータを定義する必要がある。
486(1): 2021/02/04(木)15:40 ID:R0EDVzG0(2/2) AAS
>>479
いや、全て32BITは、それに全て統一することで速度とメモリ効率と実用性の
バランスが取れていた。
ところが64BITだと実用上、表せる値の範囲はオーバースペックで
変数のメモリに占めるバイト数が8バイトと余りにも効率が悪い。
なので、多くの数値は32BITとし、必要な部分だけ64BITにするという
面倒な選択を強いられる様になった。
アドレスが64BITなので、それを整数型に入れるためには32BITの整数では
不足するので引きつられて整数も64BITを必要としがちになり、大混乱
が生じている。
(また、メモリーもアドレスを32BITより多くを必要とするアプリは非常に稀。)
487(1): 2021/02/04(木)16:48 ID:DWE1XJjK(2/2) AAS
>>482
ありがとうございます
ストラウストラップの「プログラミング言語C++」に「行列クラスの設計」なるセクションがあったのを覚えてるので、そちらではどうしていたかも見てみます
488(2): 2021/02/04(木)17:07 ID:dB2jWvbu(1) AAS
unique_ptr<Hoge[]> p(new Hoge[4]{a, b, c, d});
みたいな定義と同時に代入は出来るのですが
(各要素毎に Hoge(a), Hoge(b), Hoge(c), Hoge(d) になりました)
unique_ptr<Hoge[]> p = make_unique<Hoge[]>(4);
だと引数無しのデフォルトコンストラクタが無いといけないし
(そもそも引数無しのデフォルトコンストラクタ作りたくない)
unique_ptr<Hoge[]> p = make_unique<Hoge[]>({a, b, c, d});
とか
unique_ptr<Hoge[]> p = make_unique<Hoge[]>(4){a, b, c, d};
とかはコンパイル出来ませんでした
引数無しのデフォルトコンストラクタがあれば
unique_ptr<Hoge[]> p = make_unique<Hoge[]>(4);
p.reset(new Hoge[4]{a, b, c, d});
だとうまく逝きますが効率が悪い気がします
make_unique は使ってはいけないのでしょうか？
489: 2021/02/04(木)17:51 ID:b9gCdorg(1/3) AAS
>>487
485も見てねー
490: 2021/02/04(木)17:52 ID:b9gCdorg(2/3) AAS
まちがえた。484
491: 2021/02/04(木)20:56 ID:ZyzsEROR(1) AAS
配列のunique_ptrは色々と中途半端で使いづらいからオススメしない
492: 2021/02/04(木)22:14 ID:b9gCdorg(3/3) AAS
>>488
unique_ptr<Hoge[]> p;
p.reset(new Hoge[4]{a, b, c, d});
でよいのでは？
493(1): 2021/02/04(木)22:20 ID:un3OWVjy(1) AAS
>>486
32bitアプリでも今どきなら64bit整数を使える処理系は多いだろ
そもそもアドレスを整数型に入れるっていつの時代の人よw
494: 2021/02/04(木)22:47 ID:/RiZUiBF(1) AAS
>>493
アドレスを整数に入れるのは過去の話じゃないぞ
495: 2021/02/04(木)22:51 ID:sIhIIpMX(2/2) AAS
intptr_t整数型を使ってたのっていつの時代？
496: 2021/02/04(木)23:24 ID:hMfhfQWp(1) AAS
uintptr_tならいつもお世話になっております
497: 2021/02/05(金)00:01 ID:NIkVqohR(1/2) AAS
この手合いのボケを量産するのはC++の害だな
498: 2021/02/05(金)01:35 ID:EB7VAtvO(1/2) AAS
むしろCの害
499: 2021/02/05(金)01:52 ID:xbM9VFWh(1) AAS
Rubyって結局勉強しないままPythonの時代になってしまったな
500: 2021/02/05(金)04:42 ID:ZuGfyZDY(1) AAS
同様にC++を勉強しないままRustの時代になる
501: 2021/02/05(金)09:51 ID:U76qOqQA(1) AAS
>>488
外部ﾘﾝｸ:www.it-swarm.jp.net演算子よりもstd-makeuniqueを使用する利点/826350881/amp/
外部ﾘﾝｸ:ja.stackoverflow.comの利点
502: 2021/02/05(金)13:28 ID:ou/gU5gH(1/3) AAS
c++やらずにrustとか馬鹿量産するだけにしか思えんな。
503(1): 2021/02/05(金)14:10 ID:Xzu/prlh(1) AAS
それ言ったらノーコードがどうたら言ってる奴らはもっとやばそう
504(1): 2021/02/05(金)14:17 ID:M7C1cdPI(1) AAS
ノーコードていってノードツリーみたいなのでフロー管理するやつ
よくゲーム系ツールにありがちだけど、サンプルみたいな単純な処理ならともかく
こみいったフローになってくるとノード間の接続線がものすごいことになって
とても管理しようという気になれない、まさに見た目どおりのスパゲティプログラムに
505(1): 2021/02/05(金)14:18 ID:ou/gU5gH(2/3) AAS
>>503
それはもう50年くらいずっとそうだろ。
ノーコードとか逆に俺様言語作ってるのとほぼ変わらん状態にしかならんという
しょーもない展開しか見たことない。
506: 2021/02/05(金)15:14 ID:zImWQG8r(1/4) AAS
VCPKGのupdate、upgradeが常に失敗するんだけど、使えてる人いますか？
小まめにupdateしないからだろか？
507: 2021/02/05(金)15:14 ID:zImWQG8r(2/4) AAS
Goは標準ライブラリが圧倒してる。
508: 2021/02/05(金)15:18 ID:zImWQG8r(3/4) AAS
半年に一度フルビルドみたいになってしまう。
509(1): 2021/02/05(金)16:12 ID:A9cGRDK5(1) AAS
Goは何がクソといってまず名前がクソ
510: 2021/02/05(金)16:36 ID:zImWQG8r(4/4) AAS
C++は基本だから、義務教育で習得するべき。
511: 2021/02/05(金)16:50 ID:/MNAnFTn(1) AAS
言語仕様がでかすぎるからC言語で精一杯
オマケで紹介される程度かな
512(1): 2021/02/05(金)18:21 ID:7P5D6x+s(1) AAS
>>505
昔はアセンブラすら触れない奴がC言語とか笑わせるなとか真顔で言う人がいたんだぜ。
別に仕事ができるのならRustでもPythonでも何でもいいと思うぞ。
513: 2021/02/05(金)19:09 ID:AjJLCZml(1) AAS
仕事ができるのならw
514: 2021/02/05(金)20:48 ID:ou/gU5gH(3/3) AAS
>>512
仕事ができるならなw
できないカスがクソみたいなもん押し付けてくるから文句が出るんだよ。
rustでもpythonでもまともなコード書いてりゃ文句はないわ。
まともじゃないから文句が出る。
515: 2021/02/05(金)21:49 ID:a81hUa+F(1/2) AAS
というか、プログラマとしてrust(鉄さび、腐食)になるというダブルミーニングを狙ったんだと思うけど。
516: 2021/02/05(金)21:59 ID:kFtfKVND(1) AAS
お前らってド素人のくせになんでいっちょまえの口利くん？
それって不思議だわ
517: 2021/02/05(金)22:34 ID:EB7VAtvO(2/2) AAS
Rustの名前は金属の錆じゃなくてサビ菌が由来
518: 2021/02/05(金)22:36 ID:NIkVqohR(2/2) AAS
Rottenでいい
519: 2021/02/05(金)22:48 ID:a81hUa+F(2/2) AAS
Perl6はRakuになってしまったし、Rustもいずれ「わびさび」の境地でSabiに改名されるでしょ。
520(1): 2021/02/06(土)03:04 ID:kQVOjfvp(1) AAS
「まともなコードが書けるなら」じゃなくて、まともなコードを強制するのがRustという言語の方針だと思うが
521: 2021/02/06(土)04:45 ID:oQfB5lBJ(1/2) AAS
>>284
昔からのプログラミング/電気界隈の慣習だから仕方ないけど、2要素のミニマルなブール代数しか扱わないにも関わらずboolean型を称するのがそもそもキモい
プログラミングで使うような半順序関係は、9割booleanで書くのが一番スッキリする
一般のbool型をプリミティブにして、そこからt/fやら三要素やらに派生するのが合理的に思う
522: 2021/02/06(土)04:50 ID:GfZyzG1j(1/4) AAS
ブーリアン革命。
523(1): 2021/02/06(土)05:13 ID:oQfB5lBJ(2/2) AAS
革命というか、クラスシステムでブール代数をエミュレートしてるのが現状のOOPじゃないかと
まあ言語によって可補性はマチマチだけど、全てについてスーパークラス/サブクラスなクラスを設けるのは、メインストリームの言語では大体そうだろ
524(1): 2021/02/06(土)07:27 ID:S9Y30hRK(1/7) AAS
>>520
だとしたら胡散臭さ200%のカルトだな
525(1): 2021/02/06(土)09:31 ID:rZdEmaWa(1/5) AAS
>>524
Java、Kotlin、Scala、C#、Ruby、Python、PHP
あたりのどれかを触ってみれば、危険な記述を言語仕様レベルで封印することのありがたさが分かる
他言語も触ってみることをオススメする
上下前次1-新書関写板覧索設栞歴
あと 477 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.034s