C++相談室 part133

2017/11/24(金) 16:52:50.43

次スレを立てる時は本文の1行目に以下を追加して下さい
!extend:on:vvvvv:1000:512

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part132
http://mevius.5ch.net/test/read.cgi/tech/1507561894/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.102【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1509780815/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

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

2017/12/31(日) 01:33:30.83

>>763
作ろうとしているインタプリタってc++の？
それなら、自分で入力のc++のソースを解析する際に問題のクラスがdeleteされたりスタック上に生成されたりするのは検知すれば良いのでは。

2017/12/31(日) 01:34:01.16

>>773
それは嫌です
既存の処理系がcで書かれている以上なんとかなるはずです
これは好みの問題かもしれませんが

2017/12/31(日) 01:57:19.48

>>781
C で書かれてても完全に C の仕様の範囲内で書いてるとは限らんのだぞ。
アーキテクチャ依存の部分を適当に #ifdef で分岐して configure でなんとかしたりする (できる) のが C/C++

2017/12/31(日) 02:23:20.14

>>780
いいえ
c++の文法は自分の手におえません

2017/12/31(日) 07:16:38.47

>>779
コンストラクターが呼べない？
GC管理の範囲の切り分けができてないんじゃないの？
何から何までGCで管理する必要は無いはず。
Boehm GCの使い方を勉強しい。

2017/12/31(日) 07:28:36.53

もう言ってることもちぐはぐだしレス古事記としか思えない
スルー推奨

2017/12/31(日) 07:32:05.37

インタプリタで扱う、GC管理するクラスの基底クラスObjectBaseを定義して、そこでBoehm GCを使ってoperator new/deleteを定義する。
インタプリタ側でObjectBaseの派生クラスを必要に応じてnew/deleteすればGC管理ができる。

2017/12/31(日) 09:17:47.39

まだ自分では難しいですね
一旦中断して勉強し直します
ありがとうございました

2017/12/31(日) 10:57:38.40

>>781
そういう意味ではない。

>>787
まあ、根本的に分かってないというのは同意する。
今の君では無理だ。

君は「既存のインタプリタにGC機能を付け加えようとしている」、ここまではいいか？

インタプリタの場合、両端の柱は2つで、
A. evalラッパ
B. フルエミュ
で、結局の所これらの折衷案となる。どのポイントを目指すかは君が決めればいい。
ただし、君はここまですら到達できていない。

君はGCを自前で実装することにこだわっている。
これはGCをフルエミュすることを意味しているが、
この場合、delete等は常に自前パーサを逐一通すことになるので、その段階で弾けばいいだけだ。
君が言っているように「禁止する」必要は全くない。（ここが矛盾している。
GC管理変数をdeleteしようとしているかは、当然分かるし、分からないようではフルエミュできない)

だから俺たちはevalラッパ実装だという前提で話をしている。
こちらの場合は、システム側が持っている機能を使って相乗りになる。
混ざらないようにさえ出来ればとりあえずは動く。

コードを書く以前に、まず、仕様を固めないと駄目だ。君はここが出来ていない。
もっと上位の、エミュレーション戦略を固めないと話にならない。

2017/12/31(日) 12:02:46.05

＞この場合、delete等は常に自前パーサを逐一通すことになるので、その段階で弾けばいいだけだ
というのはインタプリタからは直接deleteが見えないことをさしていると思いますが（合っていますか？
>君が言っているように「禁止する」必要は全くない。
の理由がわかりません。
インタプリタ上のオブジェクトもC＋＋上ではただのポインタであり
delete hogehoge //このhogehogeはGCの管理下
することは文法上は可能なはずです。
これを禁止することは処理系の保守性／安全性のために必要だと考えています（というのが初めの質問につながります

そしてevalラッパというのはやらないです。
今回はメモリ管理まで実装することでその"Java"や"C#"での管理の仕組みを実装レベルで学ぶことが目的の一つだからです。
動けばいいとうわけではありません。当然出荷するわけでもありませんので大丈夫です。

＞コードを書く以前に、まず、仕様を固めないと駄目だ。君はここが出来ていない。
＞もっと上位の、エミュレーション戦略を固めないと話にならない。
ええ全くその通りでした。楽観的すぎたか単に実力不足です。

2017/12/31(日) 13:30:39.82

>>789
君が想定しているのは明らかにフルエミュ寄りだから、それで話をすると、
A *a = new A(); でまず、
自前の変数管理用ハッシュ内に valuesHash["a"] = {type: A*, value: ptr};　することになるだろ。
そして delete a; が来ると、
if (valuesHash["a"].type.canDelete) delete valuesHash["a"].value;
で対応することになる。だから、

> することは文法上は可能なはずです。
> これを禁止することは処理系の保守性／安全性のために必要だと考えています
ということ自体が間違いなんだよ。
文法的に禁止とか、全く意味が無くて、
実行時に自然に弾けるし、弾けないようなフルエミュは実装不能だから。

君はインタプリタ自体がどう動いているのか理解できていない。
インタプリタの場合は、生きている変数を全て自分で把握してないと話にならないんだよ。
俺たちはこれは「常識」として、その先の ptr の配置先をどうするか、の話をしていた。
だから完全に空回りすることになる。

> 楽観的すぎたか単に実力不足です。
どっちもだ。
君は車を作ろうとしているが、車にエンジンとタイヤが必要なことすら理解できてない。
このレベルの馬鹿だ。自覚してくれ。

2017/12/31(日) 21:01:51.54

>>790
ありがとうございます
全く甘々でしたよ。。勉強してきます!

2017/12/31(日) 21:05:22.85

まぁ机上の空論の段階で質問してる感じはするね
まず実装してみて詰まってから質問したほうが絶対早い

2017/12/31(日) 21:10:48.47

これのやり方真似るだけじゃねえの
C++にこだわる理由とかあるのか

GitHub - python/cpython: The Python programming language
https://github.com/python/cpython

GitHub - ruby/ruby: The Ruby Programming Language
https://github.com/ruby/ruby

2017/12/31(日) 23:28:57.22

C++ということならV8もどうぞ。

V8 JavaScript Engine
https://github.com/v8/v8

つか、知らんかったけどCのインタプリタもあるのな。
https://root.cern.ch/root/Cint2006.html
https://stackoverflow.com/questions/69539/have-you-used-any-of-the-c-interpreters-not-compilers

2018/01/01(月) 15:09:24.40

特定のプログラムの音(ゲームの音やブラウザの音など)のみを録音する方法ってありますか？
ステレオミキサー経由の録音はできたのですがそれだとPC全体の音が入ってしまいます

2018/01/01(月) 15:29:07.61

全くもってスレ違い

2018/01/01(月) 16:20:46.04

C++で実装してるのですが

2018/01/01(月) 18:43:32.24

>>795
どういう環境かにもよる。

2018/01/01(月) 19:08:55.81

>>798
win10でマザボから音出してます

2018/01/01(月) 22:50:45.26

>>795
ステレオミキサーで必要な音以外をミュートにしておくのではダメなの？

2018/01/01(月) 23:04:49.88

>>800
ステレオミキサーで拾う音を選択することができるのですか？
録音デバイスのプロパティからはできないですがどうやるのでしょうか

2018/01/01(月) 23:29:57.50

めんどくさ。
DLL インジェクションでサウンド関連の API 呼出しを横取りして記憶するとかどうよ

2018/01/01(月) 23:48:05.00

まずOBSとかAfterburnerなんかの録画アプリで出来るか確かめてみれや
それでできるなら出来るだろうし出来ないなら出来ないってこった

2018/01/02(火) 00:08:23.37

>>797
録音を実現する機能はc++という言語の範疇ではないから、適切なスレで聞いてきた方がいいよ。
具体的に使うAPIなりライブラリなりが分かってやりたい処理があって、それをc++で記述する上で疑問が出てきたならこのスレでいいと思うけど。

2018/01/02(火) 02:09:46.75

>>801
Windows7だと画面右下のタスクバー上のスピーカーアイコンを右クリックして
音量ミキサーを起動すると、ミュートする音を選べるようになるよ
（各音源の一番下の青いスピーカーの部分をクリックすればいい）

2018/01/03(水) 00:50:02.27

みんなストイックに-Weverythingなの？

2018/01/03(水) 18:02:54.72

We very thing

2018/01/03(水) 18:06:12.23

「GCが欲しければObjectBaseを継承しなければならない
「さあObjectBaseを継承したまえ、GCが欲しいだろう
↑
という押しつけがましさ

2018/01/03(水) 18:08:47.07

ブランケットアンクローズドシンタックスエラー

2018/01/03(水) 19:20:51.86

switch(c) {
case '{':
aho();
break;
//...
}

◆QZaw55cn4c (ﾜｯﾁｮｲ ea60-rhJv) · 2018/01/03(水) 22:18:43.34

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

＞that Intel's CPUs speculatively execute code potentially without performing security checks.
...
＞That would allow ring-3-level user code to read ring-0-level kernel data.

投機的実行が仇になったようだね、リング3 コードがリング0 カーネルデータを読み込める、というのは最悪だねえ‥

2018/01/03(水) 23:20:34.97

intelのCPUに重大なバグ。修正により性能30%ダウンは確実。もちろんcoffeeも対象 [589351131]
https://leia.5ch.net/test/read.cgi/poverty/1514960738/

＞インテルのCEOが関連性は不明だが2017年11月にCEOを最低維持できる25万株残して株式を売却している

ヤバいで

2018/01/04(木) 00:19:22.89

>>812
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table

2018/01/04(木) 00:25:51.35

>>813
https://www.theguardian.com/technology/2018/jan/03/major-security-flaw-found-intel-processors-computers-windows-mac-os-linux

2018/01/04(木) 00:34:08.27

関連記事がまとまっていた
https://news.google.com/news/story/dxTQx3jGZ4VUkpMLaUSX33-gnbA8M?hl=en-GB&;ned=uk&gl=GB

2018/01/04(木) 00:45:09.37

えっやばくねこれ

2018/01/04(木) 02:42:39.95

なんか>>811にめちゃめちゃ書いてあるらしく実際そんなヤバないらしいよ

2018/01/04(木) 06:34:15.00

やってみろよ
ム板でそういう発言恥ずかしくないのか

2018/01/04(木) 08:34:28.43

システムコール呼び出すたびにアドレス空間を切り替えるパッチを当てるみたいだから、
io叩きまくるコンパイル作業はモロに影響うけるかもね。
arm64版にもパッチを当てるみたいだけど、禿大丈夫か…

2018/01/04(木) 18:57:44.39

intel抜けてる
intel割れてる

2018/01/05(金) 22:53:49.25

c++で例外は使ってますか？
また使う場合std::exceptionを継承しますか？

2018/01/05(金) 23:16:55.81

最後の門番がstd::exceptionなんで継承して使う

2018/01/05(金) 23:33:54.58

] ][][[[ [][] [[["][ [ ]]]["04"

2018/01/06(土) 01:45:54.07

>>821
標準コンテナとか含めて new 使ったら bad_alloc 受けることになるんだから
ほとんどの場合に使ってると言えそうなんだけど「継承しますか？」って話に繋がってるってことは
「使う」＝自分で例外クラスを定義して使うって話なのかな？

2018/01/06(土) 02:11:45.78

英単語の前後にスペースを挿入するのはこだわり？

2018/01/06(土) 02:48:37.95

>>825
TeX で英数字からなる語の前後に空白を入れないと単語境界がうまく認識されないという問題があったので、この習慣は広く定着してる。
ただ、 pTeX などでは自動で境界を認識して適切な幅を取るようになっているのでむしろ空白文字を入れるとダメってのもある。
どっちでも上手いこと処理するのもあるし、そのへんごちゃごちゃしてややこしいんだわ。

ウェブブラウザでも物によって幅の取り方が違う。

まあ個人的には、バッドノウハウだという自覚はあるが、 html やプレーンテキストでは英単語の前後には空白を入れた方が見やすいと思う。

2018/01/06(土) 02:53:16.08

たしかに

2018/01/06(土) 02:59:22.25

>>825 https://www.google.com/search?q=%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%89%8D%E5%BE%8C%E3%81%AB%E3%82%B9%E3%83%9A%E3%83%BC%E3%82%B9

2018/01/06(土) 09:05:07.05

>>824
そうです。c++の本など見ても標準の例外を説明して終わりな事が多いし、しまいにはnoexceptなるキーワードまで出来てるし実際使ってるのかなと。

2018/01/07(日) 19:05:16.44

標準の例外はexception&で捕獲できる
ただそれだけのこと

独自定義の例外を標準の例外とは区別したいのなら
exceptionを継承しないという手も当然ある
教条主義にとらわれるやつ＝自分の頭で考えないやつは
こういう判断が極度に苦手だ

**デフォルトの名無しさん** · 2018/01/07(日) 23:12:25.29

>>825
Linux の日本語ドキュメントの読み書きに慣れてると自然と空白空けちゃうね。
http://linuxjf.osdn.jp/JFdocs/jf-styleguide.html#s2

2018/01/08(月) 02:30:58.74

標準のライブラリがやってることっていうのはだいたいその言語における「普通」なので、
原則としてはそれに合わせるというのは良い方法だよ。

あえて原則に逆らいたいとき、逆らった方が便利なときというのももちろんあるけれど、
たいして強い動機もないのに独自の設計を選択するのは混乱の元。
つまり、例外クラスは std::exception を継承するのが好ましい。
その上でそのデザインが問題を起こす場合があるなら見直せばいい。

2018/01/08(月) 03:33:16.23

動的例外がまだ廃止されていない頃に設計されたものが
今のC++に対して本当に「普通」なのか考えたことがあるか？
（別にここで答えなくてよいが）
誤った前提のうえに立つ主張はただの戯れ言で
そうなっていないことは確認してからぬかせ

2018/01/08(月) 04:19:16.37

std::exceptionを継承しないメリットって何かある？

2018/01/08(月) 05:20:35.84

僅か数レスの流れくらい読め

2018/01/08(月) 06:27:14.93

std::exceptionを継承しないデメリットもようわからん…
std::exceptionは一体何をやっているのや？

std::exceptionを継承しなくとも
　throw 1; --> catch (int)で捕捉
　throw "Hello World!"; --> catch (const char*)で捕捉
とかやれるようになったのって比較的最近？

2018/01/08(月) 06:38:24.96

>>834
ないよ
std::exceptionを継承しても独自例外は区別できるし、>>830は反例になってない
std::exceptionを継承しないのは、普通にアンチパターンだからやめたほうがいい

2018/01/08(月) 09:47:56.66

クラス以外を投げるのはdeprecatedになってたような…(自信なし)

とはいえstd::exceptionを継承しなければならない強い理由もあんまりないような気がする
JavaのThrowableやらPythonのExceptionやらはGCの都合だし
あくまでstd内の例外を組織化するための基本クラスでしょstd::exceptionって

2018/01/08(月) 09:53:10.93

>>838
テスティングフレームワークとか、ロギングフレームワークとか魔改造したくないでしょ
おとなしくstd::exception継承しとけ、デメリットが多すぎる

2018/01/08(月) 10:38:49.41

std::exceptionおよびその派生クラスを受け取る標準のロギングフレームワークってありましたっけ…
STLはなんか例外を投げる側しかサポートしていない印象

そもそも例外の捕捉のしくみは「知ってる例外のみ捕捉して処理する/知らない例外はさらに呼び出し元に送る」戦略なので、
受け取る側に既存のフレームワークが無いんなら、投げる側の例外が高度に統一されている必要は実はそんなには無いｷﾓｽ

せいぜいコピーしたときリークするようなクラスではあってほしくないという願いがあるぐらいで実は何だって良いのでは…

2018/01/08(月) 11:10:23.18

>>840
「フレームワーク」にあたるかどうかはわかんないけど、
catch(std::exception& e) で e.what() を拾うっていうよくあるエラー処理のパターンがあるんだよ。
https://github.com/search?utf8=%E2%9C%93&;q=%22catch+std%3A%3Aexception%22+what&type=Code

だから、 std::exception 派生にしといてもらわないとまともなエラーメッセージが出なかったりして困る。

2018/01/08(月) 14:35:51.13

アホか
e.what() を誰に対して表示するんだよ
一般消費者にbad_allocとか言っても通じねえ
せいぜい「何たらファイルを保守員に渡せ」くらいだろ

2018/01/08(月) 14:44:37.01

e.what()なんてどうでもいい
どのソースファイルの何行目でそいつがthrowされてきたかだ

**デフォルトの名無しさん** · 2018/01/08(月) 14:46:08.42

>>842
実際広く使われてるものを一人で一生懸命否定してもな・・・

2018/01/08(月) 14:48:45.77

そこら辺が例外としてカスタマーに出す情報として欠けている
巷で言うところのアスペクト機構というやつか

2018/01/08(月) 15:10:05.58

十進数計算をするためには一般的にはBCDをDPDを使用しますが
二進数のままで十進数の丸め処理をすることはできますか？

2018/01/08(月) 15:46:10.84

>>844
自分の頭で考えることを放棄しているやつとでは議論にならない

**デフォルトの名無しさん** · 2018/01/08(月) 16:18:21.05

>>847
そんなに独自路線を走りたいなら家で大人しく引きこもってろ

2018/01/08(月) 16:30:52.97

>>841眺めてるけど
全ての例外オブジェクトはstd::exception派生でなければならないなんてポリシーで書かれてるコードそんなにないぞ
当たり前だけどだいたいcatch(...)も後続させてるし、std::exception派生じゃない独自クラスのcatchを前に続けてるコードも普通にある

というか「catch(std::exception& e) で e.what() を拾うっていうよくあるエラー処理のパターン」って何？
それは単にstd::exceptionを拾ってるだけで、std::exceptionを拾ったらそりゃwhat()使うに決まってんだろ当たり前の話

**デフォルトの名無しさん** · 2018/01/08(月) 16:41:29.24

(´・∀・`)ﾍｪー

あ、ちなみに俺はC++経験ないけど暇つぶしに横から煽ってるだけだから気にしないでね^^

2018/01/08(月) 16:47:22.54

誰もおまえを相手にしてない定期

2018/01/08(月) 17:58:52.06

> std::exception 派生にしといてもらわないとまともなエラーメッセージが出なかったりして困る。

まともなエラーメッセージって
cout << runtime_error{"aho"}.what(); //aho
これのことか？ｗｗｗ

おまえさんもしかしてsystem_errorが理解できなくて使ってないとかか？

2018/01/08(月) 20:02:51.13

shamu_game？

2018/01/08(月) 22:00:33.29

>>846
固定小数点でやればいい

2018/01/09(火) 02:11:08.05

>>849
後続の catch(...) で拾っても何が起こったのがわかんなくて困ることがあるって話。

2018/01/09(火) 02:22:46.70

>>847
カスが考えるより、 C++ の (ライブラリ) 設計を真似た方がマシやで

2018/01/09(火) 10:16:09.54

おまえが考えるより真似た方がマシなのは言われんでもわかってる

2018/01/09(火) 10:43:54.73

バカの考え休むに似たりなる諺の発祥を追うような展開

2018/01/10(水) 23:37:28.15

>>857
せやろ。だから真似るんや。

2018/01/11(木) 06:31:56.64

ファイルコピーをしたいんだけど改善点あるかな？
引数にはコピー元とコピー先のファイルパスを受けとる予定
もっと簡単な記法があると助かる...

int copy(const char* old, const char* new)
{
FILE *fi, *fo;
int ch;

if(NULL==old||NULL==new){
return -1;
}
if ((fi = fopen(old, "r")) == NULL) {
return -1;
}
if ((fo = fopen(argv[2], "w")) == NULL) {
fclose(fi);
return -1;
}
while((ch = fgetc(fi)) != EOF){
fputc(ch, fo);
}
fclose(fi);
fclose(fo);
return 0;
}

2018/01/11(木) 06:46:10.27

関数仮引数を動的検査している
終了ステートが負論理
system_errorを使っていない
C++なのにfopen

2018/01/11(木) 06:55:18.88

fpucとfgetcの繰り返しは短いファイルなら良いけど長いファイルだとCPU時間やたら食うだけのクソになるな

2018/01/11(木) 07:06:36.75

>>860
改善点以前にコンパイルできるコードを持ってこいよ...
> if ((fo = fopen(argv[2], "w")) == NULL) {

あと文字単位のコピーは非効率だからせめて fread/fwrite にすべき

また使える環境ならstd::filesystem::copyとかを使った方がいい
http://en.cppreference.com/w/cpp/filesystem/copy

2018/01/11(木) 07:23:14.65

>>863
おお...気付かんかった
C++なのにCで書いてあるからそもそもだめだったか...
fread/fwriteでまず考えてみます
FileCopyみたいなの欲しい

2018/01/11(木) 07:33:45.62

freadを考えてみたけどファイルサイズ不明な場合一度に読み込むバッファサイズとかどうなるん？

2018/01/11(木) 08:03:11.10

各マシンでの最適なバッファサイズを逐一計算して求めるのがC++

2018/01/11(木) 08:10:51.08

>>865
環境わからんからなんとも言えんが10KB程度とっときゃいいんじゃね？

2018/01/11(木) 09:08:45.65

>>861
＞関数仮引数を動的検査している
解説お願いします
＞終了ステートが負論理
ダメですか？
＞system_errorを使っていない
ダメですか？
＞C++なのにfopen
ダメですか？

2018/01/11(木) 09:58:35.85

>>860
fopen の引数は “rb” “wb” にしておくのが一般的
もし実用品として使うならなるべく大きな単位、
最低でも1Mバイト程度はまとめて読み書きすると良いよ。100Mでもいい。
細かい単位で読んで書いてを行うとHDDで大きなファイルを処理する場合とてつもなく遅くなる。

あとそういう書き方をしたいならそれは c++ ではなく
c のスレ(あるのか知らんが)で聞く内容だと思う

2018/01/11(木) 10:03:28.58

>>868
不勉強を恥じろボケ

#include <filesystem>
#include <iostream>

auto copy(char const* src, char const* dst)
{
try
{
return std::filesystem::copy_file(src, dst);
}
catch(std::exception& err)
{
std::cerr << err.what();
}
return false;
}

2018/01/11(木) 10:19:39.83

filesystem がまだ使えない環境もあるかもしれんので小ネタを披露しておくと、
rdbuf を使う方法があるんや。

ifstream in(src);
ostream out(dst);
out << in.rdbuf();

みたいな要領な。エラー処理は適宜うまいことやってくれ。

2018/01/11(木) 11:19:16.78

パフォーマンス厨だが
もし実用するなら setvbuf の rdbuf 版みたいなのがあるからそれも呼ぶべきと一言

**デフォルトの名無しさん** · 2018/01/11(木) 12:15:07.96

system("cp -f a.txt b.txt") でいいよね(´・ω・｀)

2018/01/11(木) 13:09:33.65

パフォーマンス厨なら
リードとライトは別スレッドにするとか
読み書きサイズをクラスタサイズの倍数にするとか

2018/01/11(木) 13:20:11.53

物理的に別のデバイスならリード/ライトは別スレッドで回したほうが速いだろうが、同じデバイスだとシングルスレッドでも大差ないだろうな
あとはバッファサイズをできるだけ大きく取って、IOの発行数を抑えるのが王道かな

2018/01/11(木) 14:07:04.69

>>860
fgetc、fputc？笑っちゃうくらいのダメダメ
俺の部下が万が一こんなコード書いてたらもう二度とそいつには仕事回さない

2018/01/11(木) 14:43:56.63

プログラミングなんてどっかからコード引っ張って書けば一切手を汚すことなくできるのに何偉そうに言ってんだか...
英語読めないからって海外の文献を参考にせず自分で作ろうとする日本人の無駄な努力には呆れるよ
アメリカ「アホだから」
韓国「レベル低いな」
インド「アジアの恥さらし」って思われてそう

2018/01/11(木) 14:48:19.11

必死こいてコード書いてるやつ見ると情けない
世界65億人130カ国！
お前の書いてるコードがまさか地球上にないものだと思ってんの？
プログラマーの端くれが、そりゃトップで活躍するプログラマーなら常に新しいものを求めてるから生き残るけど...
それ未満は10年後にはAI、またはコード共有化が進んで消えた職業になっているだろうね
悲しいけど現実見てくれ

2018/01/11(木) 15:17:43.47

構ってちゃんが必死で連投してるな
著作権だの互換性だのと縁のない幸せ者だな

2018/01/11(木) 15:32:14.08

>>876
バカにするなら模範コードぐらい書いてやれよ。