C++相談室 part149

**デフォルトの名無しさん** · 2020/02/18(火) 06:19:41.54

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

前スレ
C++相談室 part148
https://mevius.5ch.net/test/read.cgi/tech/1580471646/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/

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

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

**デフォルトの名無しさん** · 2020/03/03(火) 12:52:22.33

>>489
それはgccのバグに思える。

**デフォルトの名無しさん** · 2020/03/03(火) 12:59:47.46

バグじゃないぞ
これがバグだったら最適化にかなりの制限がかかってしまう
strict aliasing ruleでググれ

**デフォルトの名無しさん** · 2020/03/03(火) 13:01:57.30

>>503
最適化しない場合とした場合とで結果が変わってくるのは駄目な最適化。

**デフォルトの名無しさん** · 2020/03/03(火) 13:04:15.59

だからググれって
鬼の首を取ったかのように叩く奴が出てくる前に教えてやってんのにw

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 13:05:53.55

>>499
肝心なことが漏れてた。すまぬ。

C++17 だと 4.4 の脚注に

> The number of bits in a byte is reported by the macro CHAR_BIT in the header <climits>

とあって、バイトとは char の大きさのことだというのが C++ での考え方だと思っていい。

C11 だと 5.2.4.2.1 の CHAR_BIT の説明のところに

> Their implementation-defined values shall be equal or greater in agnitude
> (absolute value) to those shown, with the same sign.
>
> - number of bits for smallest object that is not a bit-field (byte)
> CHAR_BIT 8

という言い回しがあって、 CHAR_BIT は 8 以上であればいい (8 キッカリとは限らない) と解釈できる。
それと、ポインタを持てる単位がバイトだということが示唆されているとも言える。

**デフォルトの名無しさん** · 2020/03/03(火) 13:08:55.41

>>491
charのbit数は決まってないが、バイトはコンピュータ用語として8バイトと決まっているはず。

**デフォルトの名無しさん** · 2020/03/03(火) 13:10:50.46

>>506
多分、
「The number of bits in a byte is reported by the macro CHAR_BIT in the header <climits>」
は、書き間違いで、正しくは、
The number of bits in a char is reported by the macro CHAR_BIT in the header <climits>
だと思われる。

**デフォルトの名無しさん** · 2020/03/03(火) 13:17:56.62

>>507
そうか、歴史的には、byteが7bitだったこともあったんだね。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 13:32:49.23

>>507
これな。
https://ja.wikipedia.org/wiki/IEC_80000-13
C++ が参照規格として示してないので採用してないんでしょ。

まあそんなこと言ったら英単語の意味だってどうとでもとりようがあったりするからアレだけど、
あらためて C++ の規格の中でバイトについて書いてある以上は C++ 世界では
「コンピュータ用語としてのバイト」を採用してないと解釈するのが自然。

将来的には変更されることもあるかもしれんけども。

>>508
C++20 のドラフトでもそのままなので本気で間違ってると思うなら指摘してあげればいいんじゃね？

>>509
9bit のマシンもあったらしいよ。
https://ja.wikipedia.org/wiki/ACOS-6

**デフォルトの名無しさん** · 2020/03/03(火) 13:48:53.72

>>501
概念消えるとは言ってないけど
今回文言消す理由ってなんなの？
何も知らずに口挟むとは思えないから質問させてくれ

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 14:19:12.58

>>511
もう POD という区分が適切な場面はあんまりないから、という意味のことが書いてあるっぽい。
https://botondballo.wordpress.com/2017/11/20/trip-report-c-standards-meeting-in-albuquerque-november-2017/

**デフォルトの名無しさん** · 2020/03/03(火) 14:41:53.95

trivialは生成解体の話で、standard-layoutはデータ配置の話だから
PODってのはレイヤーの違う性質が混ざってて規格に使う用語としては筋悪なんですわ

**デフォルトの名無しさん** · 2020/03/03(火) 16:26:35.30

>>510
>C++20 のドラフトでもそのままなので本気で間違ってると思うなら指摘してあげればいいんじゃね？
annotated C++ reference manual, 3.2.1c Integral Limits には、
CHAR_BIT　　　8　　maximum bits in a byte
とあった。

**デフォルトの名無しさん** · 2020/03/03(火) 16:39:36.38

>>514
ANSI/ISO, Standard C プログラマーズリファレンス
P.J. Plauger / Jim Brodie, 日本語訳, ASCII

第一部第一章基本整数型には、
--------------------------------------------------------
表記,　　　　最小範囲,　表現における制限
--------------------------------------------------------
char,　　　　 [0,128),　　signed char か unsigned char のどちらかと等しい。
signed char,　(-128,128), 少なくとも 8bit 精度の符号付整数
unsigned char, [0, 256),　signed charと同じサイズ。負の数は無い。
--------------------------------------------------------

第二部第二章標準ヘッダ <limit.h> には、
--------------------------------------------------------
CHAR_BIT
#define CHAR_BIT <#if 式 ≧ 8>
このマクロは、char 型のデータオブジェクトを表現するのに使われているビット数の最大値と置き換わる。
--------------------------------------------------------
とある。

後半は >>514 とは異なり、byte ではなく、char となっている。

**デフォルトの名無しさん** · 2020/03/03(火) 16:46:23.12

type punning について、このスレで議論されていた union の場合は、「適合コード」の例とされている：

https://www.jpcert.or.jp/m/sc-rules/c-exp39-c.html

適合コード
以下のコード例では、オブジェクトの有効な型と互換性のある型を持つ union 型を使用している。

union {
short a[2];
int i;
} u;

u.a[0]=0x1111;
u.a[1]=0x1111;

u.i = 0x22222222;

printf("%x %x\n", u.a[0], u.a[1]);
このコード例では確実に "2222 2222" と出力される。

**デフォルトの名無しさん** · 2020/03/03(火) 16:56:05.32

union による type punning は、C99やC11では大丈夫になったのではないか。
最後に代入したメンバ以外のメンバからの読み出しは、合法になったようだが。
よく読んでないので分からん:

https://stackoverflow.com/questions/11639947/is-type-punning-through-a-union-unspecified-in-c99-and-has-it-become-specified

**デフォルトの名無しさん** · 2020/03/03(火) 16:58:14.25

>>517
Finally, one of the changes from C90 to C99 was to remove any restriction on accessing one member of a union when the last store was to a different one.
The rationale was that the behaviour would then depend on the representations of the values.
Since this point is often misunderstood, it might well be worth making it clear in the Standard.

[...]

To address the issue about "type punning", attach a new footnote 78a to the words "named member" in 6.5.2.3#3: 78a
If the member used to access the contents of a union object is not the same as the member last used to store a value in the object,
the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning").
This might be a trap representation.

**デフォルトの名無しさん** · 2020/03/03(火) 20:10:58.79

>>515
日本語訳が間違ってる可能性もあるな

**デフォルトの名無しさん** · 2020/03/03(火) 21:25:40.77

>>514
頑なに仕様書読まないのはなぜなのか

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 22:12:33.33

>>520
仕様書が間違ってると思ってる (>>508) からじゃね。

**デフォルトの名無しさん** · 2020/03/04(水) 00:45:53.15

C++は間違っているからな
間違いで間違いを正すことはできな
い

**デフォルトの名無しさん** · 2020/03/04(水) 01:36:12.37

>>515 も仕様書だと思うのだが。

**デフォルトの名無しさん** · 2020/03/04(水) 08:18:37.27

それに基づいて作られた製品があればの話だな

**デフォルトの名無しさん** · 2020/03/04(水) 09:01:59.59

まあc++の仕様を完全に守ってる実装なんて一つもないしな。
それ確かめるのに工数かかるってどうなん？とは思う。

**デフォルトの名無しさん** · 2020/03/04(水) 09:56:46.98

>>523
それは解説書

**デフォルトの名無しさん** · 2020/03/04(水) 10:55:23.42

仕様を説明していても仕様書かどうかとは別な話だな

**デフォルトの名無しさん** · 2020/03/04(水) 12:41:56.62

>>526
実際には、あれは普通の解説書ではなく、コンパイラを実装する人が重宝するようなバッカス記法や決定性オートマトンなどを使って仕様がかなり厳密に書かれた特殊な本。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/04(水) 13:50:02.87

>>515
古い C では違ったのかもしれないと思って
念のために C89 も確認してみたけどそのときから >>506 と同じ文言になってるぞ。
C (の公式な仕様) では最初からバイトとは char の大きさのことと結論していい。

K&R 第二版の日本語訳の付録Bだとバイトとは書いていない。
あくまでも要約だから省略したのかもしれないし、
前書きには「予備版 (ドラフトのこと？) が出ていたので早く出せた」という意味のことが書いてあるので、
仕様の決定稿が出る前の一時期にはバイトとは記述してなかった (それを元に本にした) 可能性はあるのかもね。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/04(水) 13:54:01.41

C/C++ の仕様が信用ならんなと思うのは欠陥報告 (Defect Report) の存在だな。
仕様書に書いてないことの確認がとれていても仕様にないとは言い切れない。
把握できるわけないだろ！

**デフォルトの名無しさん** · 2020/03/04(水) 14:10:16.09

公文書だかんな
はい発表しましたよ、周知義務よろしく
↑
こういう体質なのは今さら驚いても始まらん

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/04(水) 14:57:19.24

公文書なら著作権法による保護が及ばないのでそれはそれで利点があるんだけどな。

実際には ISO は民間組織だし、正式な規格票はクソ高価すぎる。
私はドラフトと cpprefjp しか見てないんだけど、買った人いる？

**デフォルトの名無しさん** · 2020/03/04(水) 16:25:27.01

VS2019 の limits.h のコメントはこうなっている :
#define CHAR_BIT 8 // number of bits in a char

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/04(水) 16:43:02.53

そうか。

**デフォルトの名無しさん** · 2020/03/04(水) 16:43:03.91

VSの想定環境では正しいし何の問題もないな

**デフォルトの名無しさん** · 2020/03/04(水) 16:58:40.94

CHAR_BIT なのに本当に「number of bits in a byte」が厳密定義なら、何らかの説明が欲しい所ではある。

ただ、C言語では、charは言語が扱える整数の「最小単位(?)」などと書かれている文書を見たことがある。
だとすれば、Cに高級アセンブラの地位を期待する需要が有る以上、charのbit数がbyteと一致する必要は必ずあるとは思う。
総合的に考えれば、C言語においては、char=byte でなくてはならず、もはやbyteも絶対に8BITでなければならないので
char、byteがいずれも8bit
であることは事実上、必須である。

**デフォルトの名無しさん** · 2020/03/04(水) 17:05:12.53

Wikipediaの「整数型」のところで、C言語では、何があろうとsizeof(char)は必ず1になると決められており、たとえ16BITワード単位のアーキテクチャでも、CHAR_BIT は 16になるが、sizeof(char)は必ず1になるのだそうだ。
一方、sizeof(X)は、Xの「バイト数」だとされているわけだけど、はっきりいってこんな状況では総合的に考えて、charを8BIT以外には出来ない。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/04(水) 17:14:44.63

>>536
Rationale の 6.5.3.4 に記述がある。
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf

sizeof(char) は 1 を返す。
たとえこの単位が 36bit 幅であっても。
C 用語の「バイト」はストレージの最小単位であることを意味する。

**デフォルトの名無しさん** · 2020/03/04(水) 17:16:32.37

>>536
>C言語では、charは言語が扱える整数の「最小単位(?)」
は、>>506 の以下の部分にも書いてあるようだ。
CHAR_BIT とは、
「bit-field以外で最小のオブジェクトのbit数(byte)」
だと：

>C11 だと 5.2.4.2.1 の CHAR_BIT の説明のところに
>> - number of bits for smallest object that is not a bit-field (byte)

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/04(水) 17:18:06.36

ポインタを作れる単位を最小単位にするのは理に適ってるんじゃないの。

**デフォルトの名無しさん** · 2020/03/04(水) 17:20:06.24

「bit-field以外のオブジェクトの最小単位」
なわけだから、ポインタが指しうるアドレスの最小単位でもあるわけだ。
言葉が変かも知れないが。

**デフォルトの名無しさん** · 2020/03/04(水) 17:35:08.28

気にするような環境にない奴に限ってこういうこと気にするのな。

**デフォルトの名無しさん** · 2020/03/04(水) 17:39:54.09

個人的には、ソース配布してダウンロードした人が各自勝手にコンパイルするようにするようなプログラムを書いたことが無い。
必ずバイナリレベルでテストして十分デバッグ済みだと思ってからバイナリを配布してきたから。
ソース配布文化は別世界。

**デフォルトの名無しさん** · 2020/03/04(水) 18:59:40.00

だから何だ
結局何が言いたいんだ
規格が間違ってるって言うならISOのWGに意見書出せよ
情報は歓迎だぞ

**デフォルトの名無しさん** · 2020/03/04(水) 20:23:54.51

>>537
byteは16bitになる可能性を自分で示しているじゃないか。
一体何と矛盾してるんだ？

**デフォルトの名無しさん** · 2020/03/04(水) 20:40:21.43

まず一生触ることのない環境のことはどうでもいい

**デフォルトの名無しさん** · 2020/03/04(水) 20:47:19.33

お、江添きたか

**デフォルトの名無しさん** · 2020/03/04(水) 21:36:25.82

>>536
C,C++ はそれぞれずっと前から "byte" を独自定義していて、 2008 年発行の IEC 80000-13 の定義は関係ないんだよ。
（・・・って >507 に書いてあったわ。なんでまだこんなこと言ってるのこの人？）

**デフォルトの名無しさん** · 2020/03/04(水) 22:55:14.08

byteが何者かわからんから、オクテットとか言う呼び方があるのだろう

**デフォルトの名無しさん** · 2020/03/04(水) 22:56:33.25

nibble != 4bits ということはあるのかね

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/04(水) 23:02:36.78

>>550
どこかに正式な定義があるかはわからんけど、
Byte の語源は Bite (噛みつく) らしいし、
それよりは控えめってニュアンスは感じるよね。

**デフォルトの名無しさん** · 2020/03/05(木) 08:23:20.57

c++初心者です
実際現場でよく使われる関数はどんなものがありますか？

**デフォルトの名無しさん** · 2020/03/05(木) 08:31:27.44

begin, end, operator ++, operator !=

**デフォルトの名無しさん** · 2020/03/05(木) 08:48:57.01

>>553はSTLしか使ったことないアマチュアの発言

**デフォルトの名無しさん** · 2020/03/05(木) 09:32:08.09

STLだと？　俺はrange-based-forを想定して書いたんだが、気が付かなかったのか？

**デフォルトの名無しさん** · 2020/03/05(木) 09:35:26.73

一緒だよ

**デフォルトの名無しさん** · 2020/03/05(木) 09:44:32.03

c++11でregexの正規表現で\sと\Sがエラーになるけど、
全部自分で記述で[ \t\r\n]とかしないといけないですかね？

**デフォルトの名無しさん** · 2020/03/05(木) 10:06:12.56

>>552
関数セットとしては、やはり伝統的なCのものを使うことが多いんではなかろうか。
ソートや乱数、最大最小値計算、正規表現なんかはC++風のものが好まれる傾向が出始めてるかもしれない。
文字列の一致テストなども、個人的にはCのstrcmp()、_strcmpi()、strncmp()、memcmp() なども結構使ってるけど、若い人の間では std::string の比較機能が好まれているかもしれない。
というかC++から勉強した場合、それしか知らないだけかも知れないが。
文字列表示は、ネットではなぜか cout 系で、cout << "Hello"; のようなものを良くかけるが、
表示する際の16進数と10進数の区別や、表示桁数の指定、float/double値の有効数字桁数の指定、先頭に0を付けるかどうかなどを指定し易いので、古いと言われようが個人的には昔ながらのprintf()が好きだ。

**デフォルトの名無しさん** · 2020/03/05(木) 10:22:38.04

マニピュレータを作ることが出来るのでストリームを使ってるだけでは。

**デフォルトの名無しさん** · 2020/03/05(木) 10:23:41.63

若い子は馬鹿なのでストリームを好むｷﾘｯって風に見えるのだろか。

**デフォルトの名無しさん** · 2020/03/05(木) 10:59:35.38

C++の文字列比較で比較開始位置や最大長さを指定したい場合、
if ( str1.compare(0, 5, "abcdefghijklmn") == 0 )
のように書く必要があるが、Cのstrncmp()だと
if ( strncmp(pszText1, pszText2, 5) == 0 )
と書ける。
後者の方が、比較する2つの文字列1, 文字列2の間にみごとな「対称性」があってとても美しい。
さらに、
C :
if ( strcmp(pszText1, pszText2) == 0 )　　// 長さ指定なしの全体比較
if ( strncmp(pszText1, pszText2, 5) == 0 ) // 最大長さ指定有り。
C++のstd::string :
if ( str1 == str2 )　　　　　　　　　　　　// 長さ指定なしの全体比較
if ( str1.compare(0, 5, str2) == 0 )　　　 // 最大長さ指定有り。
のように、長さ指定が無い場合と有る場合の「対称性」もCの方が高い。

さらに、開始位置と長さを指定する引数の位置が、コンストラクタに置いては
std::string str2("Hello World");
std::string str1(str2, 長さ);
std::string str1(str2, 開始位置, 長さ);
なのに、比較においては
str1.compare(開始位置, 長さ, str2)
のように前後が逆転していて、ここでもまた、STLの文字列操作には「対称性」が無い。

なお、MFCのCStringの場合は、
CString str1, str2;
に対し、以下のように strcmp(), strncmp() に簡単に指定できる :
if ( str1 == str2 )　　　　　　　　// 長さ指定なしの全体比較
if ( strcmp(str1, str2) == 0 )　　 // 長さ指定なしの全体比較
if ( strncmp(str1, str2, 5) == 0 ) // 最大長さ指定有り。
一方、std::string の場合、const char* 型への暗黙変換が出来ず、str.c_str() のように書かないといけないという困った問題がある「かも」知れない。
今のC++でどうなったかは知らない。

**デフォルトの名無しさん** · 2020/03/05(木) 11:41:02.48

>>552
人による。
そして上のやり取りでもわかる通り玄人ぶったバカが変な思想を押し付けてくるが
気にしなくてもよい。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/05(木) 12:19:38.92

>>561
そんなん好きなようにラッパー関数を書けばええがな。

**デフォルトの名無しさん** · 2020/03/05(木) 13:09:53.92

>>563
ラッパー関数とは関係ない話。

**デフォルトの名無しさん** · 2020/03/05(木) 13:22:25.57

>>558
ストリームよりprintfがましってのは同意だがprintfよりfmt使え
C++20から標準になる

**デフォルトの名無しさん** · 2020/03/05(木) 13:31:47.82

>>565
気になるので言っておく。
stream 入出力とは、古くから FILE, fopen, fclose, fgetc, fread などに対して使われていた言葉で、cout/cin 系専用の言葉ではない。
なんでもそうだが、言葉は有名なところで先に使っていた方が優先されるべきだ。

**デフォルトの名無しさん** · 2020/03/05(木) 13:35:39.19

>>566
1. Cのstdin, stdout, FILE, fopen, fclose, fgetc, fread 系の関数群のことは、
非常に古くから「Stream I/O」と呼ばれていた。
2. C++ では、「iostream」というような名称で cout/cin 系のクラスが定義された。
後者の事を単に「ストリーム」と言っても1とは区別が付かないのでやめて欲しい。

**デフォルトの名無しさん** · 2020/03/05(木) 13:38:39.89

>>556
おい554、range-based-forはコア言語だぞ、断じてSTLではない
そもそも規格票に一言も出てこない用語でイキッてんなよ
俺がアマチュアかどうかも証拠持ってるわけねえよな

寝言は寝て言えタコ助

**デフォルトの名無しさん** · 2020/03/05(木) 13:39:59.47

>>567
C++スレなので。
コンテキストで十分判別がつきます。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/05(木) 13:41:04.88

何を使ってもいいけど、レイヤは切り分けた方がいいと思う。
string を使ってるときは char の配列と混同させて使うべきではないし、
char 配列を使っているなら string のことは忘れた方がいい。
どこがレイヤの境界なのかはっきりさせて。

**デフォルトの名無しさん** · 2020/03/05(木) 13:41:08.45

>>565
初めて聞いたが、書式で{1}{2}など C#に似た使い方が出来るが、
逆に、{ や } の記号を簡単にはかけなくなり printf より使いにくくなってしまう。
しかも、{1}{2}が使い易いとは思わない。むしろ%sや%dより混乱する気がする。
しかも標準ライブラリではない。

**デフォルトの名無しさん** · 2020/03/05(木) 13:41:55.46

>>569
付かない。
C++はCを前提にしているのだから、両者を混在して使うのが普通だし。

**デフォルトの名無しさん** · 2020/03/05(木) 13:46:28.70

>>570
仕組みを深く理解していれば混在させても問題もない。
文字列程度でレイヤー訳が必要になるんなら、Cの上位互換の名を外すべきだ。
別の言語としてやり直せ。

**デフォルトの名無しさん** · 2020/03/05(木) 13:46:40.22

>>572
もうそんな時代じゃないので。
いまは、CがC++に依存する時代。
C++で書かれたAPIをCから呼び出す。
C++がスクリプト言語のような柔軟性を持ちつつ、しかしシステム言語として使われるのは、Cから呼び出せるからでは。

**デフォルトの名無しさん** · 2020/03/05(木) 13:52:08.63

c++がスクリプト言語のような柔軟性をもつ？何言ってんの？病気か？

**デフォルトの名無しさん** · 2020/03/05(木) 13:55:30.86

>>568
言い返すとこはそこでいいのか？w
ちなrange-based forはまだC++に慣れてない初心者に押し付けるほどのものではないし
ましてrange-basedに合わせるためにoperatorの実装を押し付けるのは論外
ドヤりたいだけの初心者は黙ってろマジ迷惑だから

**デフォルトの名無しさん** · 2020/03/05(木) 13:59:58.25

>>574
coutやstd::stringが使い易いなら誰もCでやろうとは思わないが、現実にはCの方が便利だから
あくまでも使いにくいそれらを使おうとするとのは、今のネットは新しい情報だけが上に来てしまうため、C++しか知らない人が多いためだ。

**デフォルトの名無しさん** · 2020/03/05(木) 14:00:13.40

>>571
好きにどうぞ
時代に取り残されないようにな

**デフォルトの名無しさん** · 2020/03/05(木) 14:00:44.50

>>577
一行目の「だから」の直後に「。」が抜けていた。

**デフォルトの名無しさん** · 2020/03/05(木) 14:01:43.36

>>578
古いものを知らないで勝手に変な仕様を入れてしまう人が増えているんだ。
C#やcppfmtのそれは、PerlやRubyよりも遥かに使いにくい。

**デフォルトの名無しさん** · 2020/03/05(木) 14:10:16.89

>>580
好きにどうぞ
時代に取り残されないようにな

**デフォルトの名無しさん** · 2020/03/05(木) 14:11:08.23

>>576
現場でよく使われる関数は何かと尋ねられて
すぐ思い当たるものを正直に述べたのが
初心者に押しつけたように見えるのは
おまえの目か頭のどちらかがおかしいからだ
いや両方か？

C++11に付いていけず置いてかれ
C++03でドヤりたいだけなアウトカーストこそ
マトモな初心者に触るなアホが伝染るから

**デフォルトの名無しさん** · 2020/03/05(木) 14:12:52.64

マジでプロでもフリーソフト開発してるアマチュアでもいいから実際の開発に使ってる人(と初心者)専用の相談スレがあった方がいいかもな
開発全くしてない人間でも別に好きにすればいいが、ここはプロや経験長い人にマウント取りたいだけのクソバカが多過ぎる(しかもそれに初心者が騙されて右往左往する)

まぁその役割は初心者スレがすでにある程度担ってんだろうけど

**デフォルトの名無しさん** · 2020/03/05(木) 14:13:34.58

>>582
アマチュアで初心者でドヤりたいだけ、ってのは否定しないのかwwww

**デフォルトの名無しさん** · 2020/03/05(木) 14:16:27.96

乱数とかCライブラリでは辛すぎる。

**デフォルトの名無しさん** · 2020/03/05(木) 14:16:37.51

>>584
はあ？　俺がアマチュアという事実無根の誹謗中傷をしたことを否定しないのはおまえだろ

**デフォルトの名無しさん** · 2020/03/05(木) 14:17:44.84

嘘つき野郎と日本語で言っても非難の度合いが弱すぎるので英語でLIAR!!

**デフォルトの名無しさん** · 2020/03/05(木) 14:17:54.10

仕様に「任意の」とついたら、もうCでは拷問になる。
CIA真っ青級の。

**デフォルトの名無しさん** · 2020/03/05(木) 14:18:57.32

めんどくさいからそろそろ天才がどうたらいういつもの結論行って。

**デフォルトの名無しさん** · 2020/03/05(木) 14:20:20.54

Networking TSが入れば追いついてこれるものなど居ない。

**デフォルトの名無しさん** · 2020/03/05(木) 14:21:04.08

江添に影響されたバカが増えたよな。
ああいうまともにコード書いてないで知ったかするカス態度はほんと害悪だわ。

**デフォルトの名無しさん** · 2020/03/05(木) 14:23:28.86

生データからノイズを除去し有益な情報だけを抽出できないやつに江添の文面は無理

**デフォルトの名無しさん** · 2020/03/05(木) 14:26:52.95

まぁC++専門のライター自身がC++に変な幻想抱いてるしね
スクリプト言語の代わりになったって仕方ないのに
むしろC++にそのように振る舞わせるためにユーザーがアホほどコスト掛けなきゃいけなくなるという

**デフォルトの名無しさん** · 2020/03/05(木) 14:32:04.59

>>593
https://root.cern.ch/cint

**デフォルトの名無しさん** · 2020/03/05(木) 14:32:11.09

ただ新しい言語をなぜやるかの理由の一つとして
年上にマウントとるためってのは実際大きいんだろうなと思う。
これは他言語でもそうだし、昔からそう。
この点についてこの業界は50年以上全く解決されてない。

**デフォルトの名無しさん** · 2020/03/05(木) 14:33:02.32

C++でワンライナー書けるようになったら、初心者脱出。

**デフォルトの名無しさん** · 2020/03/05(木) 14:37:10.41

>>574
cがc++に依存するって何のこと言ってる？

**デフォルトの名無しさん** · 2020/03/05(木) 14:41:02.50

俺が6800のマシン語やり始めた頃
ジジイたちはPCなんてオモチャとバカにしてたから
マウント取りたきゃいつでも取れてたが
そんなパンピーが考えそうなくだらねえことには興味なかった

**デフォルトの名無しさん** · 2020/03/05(木) 14:45:43.10

C++を使いこなせないと老害の始まり。

**デフォルトの名無しさん** · 2020/03/05(木) 15:16:05.18

>>594
時代がどうこう言ってたのに03までやんけ（´･ω･`）

>>598
老g(ry

**デフォルトの名無しさん** · 2020/03/05(木) 15:17:50.50

URL見て気が付いてほしかったが。