C++相談室 part146

**デフォルトの名無しさん** · 2019/11/07(木) 11:35:36.76

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

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

このスレもよろしくね。
【初心者歓迎】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/ (日本語)

**デフォルトの名無しさん** · 2019/12/02(月) 15:39:04.52

>>481
配列の場合、delete するとメモリー上に大きな空き領域が出来ますが、
それより大きなサイズの配列を new しようとすると、そこが再利用できません。
なぜなら、配列の場合、連続したメモリ領域が固まって必要になるため、
要素の個数が N だとすると、N 個全てが一度にまとまって入りきる領域を探す
必要になるためです。

ところが、リンクリストの場合、要素数 N が大きくなっても、バラバラな
領域に分散して格納することが出来ます。すると、とても高い確率で、
分断化された空きメモリが再利用されることになります。

**デフォルトの名無しさん** · 2019/12/02(月) 15:50:07.84

>>481
「2回に1回」と書きましたが、実際にはもっと確率は高いです。
リンクリストを使っている場合、要素を全部 delete したような場合は、開放された
空きブロックは、余り断片化せずに、比較的高い確率で結合され、大きな空きブロックに
なるためです。空きメモリは、元の要素のサイズの複数個分以上になっている確率が
高くなります（複雑ですが、管理領域のサイズもこれに加わります。）。
この性質があるため、現実には、小さいサイズのオブジェクトを要素とする集合
が多種類有った場合、それを好きに new, delete した場合、50% よりずっと高い確率で
断片化空きメモリーは再利用されます。

**デフォルトの名無しさん** · 2019/12/02(月) 16:10:33.93

>>483
誤解無きように細くしておくと、「50% より大きい」というのは、
「断片化された空き領域が再利用される確率」
のことで、「断片化率」ではありません、。断片化率はもっと
小さな値になり、条件によりますが、例えば、数%～10%程度
が目安になります。最悪のケースだともっと大きいのですが、
ケースバイケースで適切なデータ構造（集合アルゴリズム）を
使っているとこの程度に収まります。また、適切なデータ構造を
選択することはそんなに難しいわけではありません、。

**デフォルトの名無しさん** · 2019/12/02(月) 16:15:53.26

>>475
既に、Windows95くらいの時期のメモリ容量で、C/C++のメモリ断片化は
問題が無い程度になっていました。実際には、MS-DOSの時代でも既に
問題なかったのですが。

とにかく、今の若い人の目線で言えば、古代ともいえるくらい古い時代に
既に C/C++ のメモリー断片化問題は問題が無い程度にハードウェアが
発達済みなのです。PC-8801 の 8BIT 時代には問題があったので、
N88-BASIC を筆頭に、GarbageCollection 方式をとっていましたが、
それは、若い人には「超古代文明」時代でしょう。

**デフォルトの名無しさん** · 2019/12/02(月) 16:34:28.08

>>485
また誤解が入りそうなので細くしておきます。
N88-BASIC などが GarbageCollection を使っていたのは、本当に
マシンのメモリが少ないのでデータをぎゅーぎゅー詰めに隙間無く
入れることが重要だったためです。
一方、JavaやC#がGarbageCollection を使っているのは、どちらかと
いうと、「メモリー開放の自動化」のためです。参照カウンタだけで
は、循環参照問題が生じるため、時々、広い範囲のメモリブロックを
巡回して、循環参照していても本当に使って無い場合を厳密に見つけ出して、
徹底的に開放することを行います。
そのため、メモリーの断片化問題とはまた違う意味で、メモリー開放の
自動化には、GarbageCollection が必要となっています。

N88-BASIC 時代と、現在の Java, C# とでは、同じ GarbageCollection
でも主な役割が違うと考えられます。もちろん、断片化を防ぐ役割も同時に
果たしてくれますが。

**デフォルトの名無しさん** · 2019/12/02(月) 16:40:43.00

>>486
誤字訂正：細く ---> 補足

・BASIC言語にはポインタが無かったので、循環参照問題は有りませんでした。
・BASIC言語における GarbageCollection は、主に文字列領域の開放のためです。
　A$="HELLO WORLD" と入れた後、A$="" とした時、元の文字列に使っていた
　領域は、しばらく経った後に GarbageCollection で開放される仕組みでした。
　ですので、文字列を余り使わなければ GarbageCollection も余りおきませんでした。
　なお、DIM A(100) のように確保した配列は、余り開放することは有りませんでしたが、
　開放した場合も、しばらく後に GarbageCollection の対象になっていたと思われます。

**デフォルトの名無しさん** · 2019/12/02(月) 17:06:01.34

リンクリストってシーケンシャルアクセスで毎回キャッシュミスするから、
配列の代わりに全面的に使ったりしたら断片化とか最早どうでもいいレベルでパフォーマンス低下するぞ

**デフォルトの名無しさん** · 2019/12/02(月) 17:15:40.51

>>488
リンクリストでシーケンシャルアクセスする場合、キャッシュ以前に
ポインタをたどるようにアクセスしないといけないのですが、
最近、配列と同じような通し番号方式でアクセスしようとする人が
多くなっています。ライブラリなどは、以前にアクセスした番号が
k の場合、そのポインタを覚えておいて、プログラマが k + 1 の番号
をアクセスしようとした場合、後続のノードへのポインタをたどる
ことで高速化している場合があるので、特に問題が無い場合がありますが、
それを深く理解せずに、本当に先頭のノードからたどってしまった場合、
本来なら O(N)で済むところが、O(N^2) になってしまいます。

**デフォルトの名無しさん** · 2019/12/02(月) 17:16:14.80

>>487
ヌルポ。

**デフォルトの名無しさん** · 2019/12/02(月) 17:18:32.46

>>489
C/C++ でのリンクリストは、場所を覚えるのは通し番号ではなく、ポインタ
で行うことが基本です。ところが、最近、通し番号で覚えてしまうプログラムを
書く人が増えているように感じます。それは、キャッシュのために遅くなっているの
ではなく、計算オーダーが完全に違ってくるために遅くなるため、ただごとではない
遅さを招きます。

**デフォルトの名無しさん** · 2019/12/02(月) 20:46:52.56

ネトウヨ東大特任准教授、謝罪するも言い訳「AIの過学習によるもの」
https://medaka.5ch.net/test/read.cgi/jsaloon/1575275488/

**デフォルトの名無しさん** · 2019/12/02(月) 20:59:09.09

>>487
循環参照問題の有無はポインタ(アドレス)とは関係ないでしょ。

**デフォルトの名無しさん** · 2019/12/02(月) 21:16:13.89

TIOBEってなんて読めばいいの？
ちおべ？

**デフォルトの名無しさん** · 2019/12/02(月) 22:59:36.28

ハッシュテーブルで要素Xが既存要素Yと衝突した場合でもXを格納したい場合は
リハッシュかリストになる
ｷﾓｽ

リハッシュで容量をちゃんと使い切るには相当にハッシュ関数を考えねばならない上に
衝突データを取り出すのに何回リハッシュしたかを見ながら要素をたどっていく必要があり、
ハッシュの検索性を帳消しにしてしまいかねない

よってリストのが圧倒的に簡単で速い

**デフォルトの名無しさん** · 2019/12/02(月) 23:15:49.08

>>493
ある
ガベージコレクト対象データでもって他のガベージコレクト対象データを指し示すような
再帰構造が表現不可能なら循環参照は当然起きない
N88-BASICの文字列はキャラクターの集まりであって他の文字列を指し示したりできないから、
相当の無能か悪意を伴って設計しない限り、文字列メモリのガベージコレクションで
循環参照は起こしようが無い（やるべきことは素のmalloc/freeに他ならない

**デフォルトの名無しさん** · 2019/12/02(月) 23:29:11.52

>>496
>>487で自分で書いているように配列がガーベジコレクションの対象になっているなら、循環参照は起こり得るんでないの？

**デフォルトの名無しさん** · 2019/12/02(月) 23:30:20.73

すまん>>497はまちがい

**デフォルトの名無しさん** · 2019/12/03(火) 04:41:05.52

まだやってたのか
うんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんち
うんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんち
うんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんち
うんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんち
うんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんち
うんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんちうんち

**デフォルトの名無しさん** · 2019/12/03(火) 06:45:35.36

C++20あたりになるともうついていけそうにないな。

**デフォルトの名無しさん** · 2019/12/03(火) 07:20:16.39

conceptの仕上がり次第だろうな
Cのrestrictもそうであるように
うるさすぎると嫌気がさすやつが続出する

**デフォルトの名無しさん** · 2019/12/03(火) 14:10:18.28

実際にコードを書いてないやつほど仕様を知っててアホみたいなこだわりを見せる
ってことが常態化してる。
そろそろロクでもない結末を迎える。

**デフォルトの名無しさん** · 2019/12/03(火) 14:24:39.60

並列処理じゃないですかねこれからは
マルチなコアをもりもり使えないと

**デフォルトの名無しさん** · 2019/12/03(火) 14:38:06.74

>>502
仕様を知ってるのは良いけど
コードを書いてない人は気にするところがズレてる

**デフォルトの名無しさん** · 2019/12/03(火) 15:33:28.77

コンパイラやパーサーを作っているか、本を書こうとしている人だとすれば
隅々まで仕様を知る必要があるから、単なる自己満足の言語ヲタクとは
限らない。

**デフォルトの名無しさん** · 2019/12/03(火) 15:40:53.19

コンパイラやパーサを作ってる人よりも
本やブログを書くだけの馬鹿のが変な仕様にこだわってるのが問題。
後者は単なる自己満足の言語ヲタクと変わらん。
端的にカスでいなくなった方がいい存在と思う。

**デフォルトの名無しさん** · 2019/12/03(火) 15:46:11.44

>>506
自慢するために言語ヲタクになっている人は困るけど、本やブログを書く人は
貴重なので、情報収集のため5chでもなんでも使ってもいいと思うんだよ。

**デフォルトの名無しさん** · 2019/12/03(火) 16:08:25.07

現場でガリガリ書いてる奴らが本を書かないのが悪いんだろ
えっ、ブラック労働環境で疲弊してて書く余裕がないって？ｗ

**デフォルトの名無しさん** · 2019/12/03(火) 16:50:33.73

ブログはともかく5chの情報を元に本を書くとか
勘弁してくれ

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

>>508
解説本みたいなのは読まんな

規格書、データシート、仕様書、リファレンスマニュアル
こんなのは5chを参考にするはずがない

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

>>509
全く知識が足りて無い場合、知ってる人に聞くと大幅な時間短縮になる事がある。

**デフォルトの名無しさん** · 2019/12/03(火) 17:42:58.95

>>508
現場でガリガリって、コンパイラ開発してるとこのか？
そうでなければ普通言語の仕様なんか気にしてねーんだよ
むしろ仕様というか規格に詳しくないと使えない言語とか実用性無いわ

**デフォルトの名無しさん** · 2019/12/03(火) 17:45:16.73

>>508
あとお前が知らんだけで、各分野の経験豊富な人がいくらでもその分野のコードを書くための本出してる
言語オタクには気付かんだろうけど

**デフォルトの名無しさん** · 2019/12/03(火) 17:50:23.07

>>911
全く知識が無い人が本を書く？？？？
何の本？
アンカーミス？

**デフォルトの名無しさん** · 2019/12/03(火) 18:43:45.39

未来へのアンカー

**デフォルトの名無しさん** · 2019/12/03(火) 19:20:43.49

>>514
考えてみれば、本を書く人はここでは聞かないかも。

**デフォルトの名無しさん** · 2019/12/03(火) 19:21:46.86

Stroustrap の本とか高いし、cpprefemceは分かりにくいし、誰かに
聞いてみたくなる気持ちは分かるがな。

**デフォルトの名無しさん** · 2019/12/03(火) 19:22:03.63

>>513
C++のコンパイラ分野でいいので２~３冊あげてみ

**デフォルトの名無しさん** · 2019/12/03(火) 19:22:10.56

けっ言語についていけねえうえに
ろくな業績も出せてねえ真性ゴミクズが
書いたコードの量が多いんだと
精一杯のブラフで自我を保とうと必死こく
究極にくだらねえ茶番だろうが

**デフォルトの名無しさん** · 2019/12/03(火) 19:25:02.10

コードを書けないのがコンプレックス？

**デフォルトの名無しさん** · 2019/12/03(火) 19:26:01.05

禿4はわかりやすかったけど、もう少し突っ込んだ話が読みたかったな。

**デフォルトの名無しさん** · 2019/12/03(火) 19:26:43.98

禿4はキンドルのセールに出ることあるよ。

**デフォルトの名無しさん** · 2019/12/03(火) 19:43:50.04

禿4は量が少ないわけではないがｃ＋＋を今からやるとしたら最低限ああなるだろ。
あれ以下に減らすのは実際無理。

**デフォルトの名無しさん** · 2019/12/03(火) 19:55:41.70

>>518
そういう意味で言ったんじゃないんだが

>>519
＞けっ言語についていけねえうえに
＞ろくな業績も出せてねえ
こういう前提はどっから来てんのかね
>>502,506 ,512みたいなことを言われるとそういう過剰反応するやつよく見かけるけど
>精一杯のブラフで自我を保とうと必死こく
>究極にくだらねえ茶番だろうが
鏡見た方がいいよ

**デフォルトの名無しさん** · 2019/12/03(火) 21:01:44.02

>>524
違うんなら証拠出してみろよ
言ってることが薄っぺらくてゴミクズにしか見えねえが
そういう俺にお見それしましたと言わしめる内容がおまえにあるか？

身バレするようなことでなくて結構だ
話している内容に深みを感じるかどうかだ
もう一度言う、おまえの言葉にはそれがまるでない

**デフォルトの名無しさん** · 2019/12/03(火) 21:24:21.32

>>524
> そういう意味で言ったんじゃないんだが
意味わからん
本を出してるって言うなら具体的に挙げられるよね？

**デフォルトの名無しさん** · 2019/12/03(火) 21:26:06.12

おまいらスレタイ

**デフォルトの名無しさん** · 2019/12/03(火) 21:30:25.58

実にC++erらしいこのスレにぴったりの会話だな

**デフォルトの名無しさん** · 2019/12/03(火) 21:58:21.97

>>525
お前も感情的に攻撃的に相手を罵ってるだけで、中身空っぽに見えるぞ。
お前の自己評価はもっと高いのかもしれないけど端から見たらただのバカだよ。

**デフォルトの名無しさん** · 2019/12/03(火) 22:13:59.08

>>529
おまえ誰？

**デフォルトの名無しさん** · 2019/12/03(火) 22:43:52.58

「現場でガリガリ」って可愛い表現だなｗ
アマチュア精神がにじみ出てる

**デフォルトの名無しさん** · 2019/12/03(火) 23:17:48.08

禿禿言うなよ
気にしてるらしいぞ

**デフォルトの名無しさん** · 2019/12/03(火) 23:39:54.64

お前らがC++高等テクニックｗｗ持ってるのは分かったから
まずまともな設計上げてこいやｗｗ

**デフォルトの名無しさん** · 2019/12/03(火) 23:42:10.99

経験マウント vs 知識マウント

実に人格障害のC++erらしいスレだ

**デフォルトの名無しさん** · 2019/12/04(水) 01:05:50.07

知識も経験も豊富な奴おらんのか？

**デフォルトの名無しさん** · 2019/12/04(水) 01:18:20.24

>>535
多分、C++の仕様が異常なほど膨れ上がってること、JavaScriptやWebGL、
AjaxやC#なども勉強しなくてはならない事が多くなったことなどもあって、
プログラムを沢山しながら仕様にも詳しい人は壊滅状態であることは想像に難くない。

**デフォルトの名無しさん** · 2019/12/04(水) 01:23:07.75

>>536
というか、普通にプログラムしていても、HTML、CSS、HTTP などの仕様はもちろん
のこと、Androidやるなら、Java、Kotlin、NDK、iOSやるならSwift、
それに加えて、C#なら、WinFoms、WPFなどもあり、さらに、WSL、
PowerShellにbashやApacheの設定方法、ライセンス各種の勉強などなど、
やることが多くなってきている。本当は、React、Blazor、Vue.js、node.js
Electron、flutter、wxWidget、Qt、GTK。別に全部やる必要はないが、
予備知識として知ってないと技術資料も理解しにくいことが多くなってきた。

**デフォルトの名無しさん** · 2019/12/04(水) 01:25:21.34

自分の得意分野以外は浅く予習しておいて使うときになって覚えて使わなくなったら忘れてる

**デフォルトの名無しさん** · 2019/12/04(水) 01:26:04.91

>>537
Python、Rust、Lua、curl、ant、gradle、git、github、wget なども知ってない
と話が理解できないことも多くなっている。

**デフォルトの名無しさん** · 2019/12/04(水) 01:31:31.51

今時コードだけでプログラミングするもんでもあるまい
C++使いならフロントはばっさり切り捨ててAWSとGCPにスキルを振ったほうが一貫性があり無駄の少ないスキルセットになる

**デフォルトの名無しさん** · 2019/12/04(水) 01:36:36.01

std::cout での出力フォーマット指定に関して教えてください。

cout.flag( ios::uppercase | ios::hex ) やら cout << setfill('0') とか
cout << scientific << setprecision(10) とかとか
大半の指定が１回数値を出力した後もその状態が保持されたままなのに
cout << setw(24) による出力幅指定はその都度指定しないと忘れてしまう挙動になっています。

その都度指定する必要は他にもあるのか。それと、
http://www.cplusplus.com/reference/iomanip/setw/
みたいな仕様を見て、どう読み取ればそれが正しい挙動であると分かるのか教えてほしいです。
ある個人ブログには setfill も毎回出力する度に指定する必要があるのだと書かれていましたが、
自分の環境では setfill は状態が保持されました。

**デフォルトの名無しさん** · 2019/12/04(水) 01:41:33.70

フロントエンドは本当に時間の無駄
ましてC++プログラマならほとんど領域が被らないから単なる二足のわらじ状態で非効率なだけ

**デフォルトの名無しさん** · 2019/12/04(水) 04:32:29.80

>>529
読解力が無いのか>>508と同じく言語オタクだから気づかないのかわからんが
>>508と
>>512-513読み直してくれる？
C++の言語仕様を詳しく解説する本を、コンパイラ”以外の開発に携わってる”人間が書いてくれると
思ってる方がおかしいんだよ
>>508の目には純粋にC++関連の本しか映ってないんだろう
C++を前提としてるがC++そのものでなくその分野の専門的な知識を教えてる技術書がどれだけあると思ってんだ

**デフォルトの名無しさん** · 2019/12/04(水) 04:32:49.61

>>525
＞えっ、ブラック労働環境で疲弊してて書く余裕がないって？ｗ
こんな腐りきった発言する思い上がったゴミアマチュアに教えてやることなど何もない
お前が使ってるその箱で動いてるソフトは誰が書いてくれてると思ってんだ

**543** · 2019/12/04(水) 06:39:12.18

安価ミス
Ｘ　>>529
○ >>526

**デフォルトの名無しさん** · 2019/12/04(水) 07:09:58.31

>>536
うん、想像なら只だもんな

**デフォルトの名無しさん** · 2019/12/04(水) 07:33:04.63

そもそも現場の奴らは、現場のやり方しか身につける必要ないだろw

**デフォルトの名無しさん** · 2019/12/04(水) 07:54:48.53

>>545
各分野にコンパイラ開発は入らんのか？
まあお前の好きな分野でいいから具体的な本の名前挙げてくれ

**デフォルトの名無しさん** · 2019/12/04(水) 08:05:44.23

>>548
挙げたらどうなんの？お前には興味ない内容だと思うけど
「ド素人が言ってんだろ」と思ってるんだろうけど、お前の誤解を晴らすためになんで自分の分野晒さなきゃいけないの？
本の名前挙げたら謝るの？

**デフォルトの名無しさん** · 2019/12/04(水) 08:06:15.64

>>546
実際そうだと思うよ
>>512にも書いたけど、仕事でやってる人もフリーソフト開発者も
規格読んだことある人なんか皆無だと思うよ
他に勉強しなきゃいけないこと山ほどあるし、仕様（新しいのも含め）は必要なときにググって確認するだけ（>>538も言ってるけど）、むしろそうであるべき

それを「言語についていけない」なんて貶せるやつの神経がわからん
>>519とか、ソフト開発もメタプログラミングも出来ないレベルのド素人だろ？
何調子乗ってんの？自分はついていけてんの？ｗ

開発力も無いし言語を活かせてもないのに、実際にC++を実用してる人を貶すとか
頭おかしい真似してるから言語オタクって言われるんだよ
（C++専門のライターも最近そういう傾向あるけど）

>>547
それはそれでどうかと思うけど

**デフォルトの名無しさん** · 2019/12/04(水) 08:07:22.17

>>541 直接的な回答でない上に長々しい文章で気が引けるけど…。

『プログラミング言語C++』第4版の38章「入出力ストリーム」で
「width(n)の呼出しは、その直後に行われる<<による出力だけに影響を与える」
と書いてあるね(p. 1094)。
setw() は「次の出力のフィールド幅をn文字とする」(p. 1096 の下の表)
表の説明で“次の出力の”と限定されてるのはsetw()だけ。

で、一般的に書式指定やマニピュレータのうち、
どれが「一度指定したら別の指定をするまで有効」で、
どれが「指定された次の出力だけ有効、その後デフォルト状態に戻る」なのか、
N3337 の 27.5.3.2 周辺を見ても分からなかった。
基本的には ttp://www.cplusplus.com/reference/iomanip/setw/ よりも
少ない記述内容だし、「この指定は直後の一回の出力に限り有効」みたいな
補足の説明も見当たらない。

ISOやJISの規格に詳しい人が「素人め、ここに載ってるんだよ」と
ズバリ指摘してくれるのを期待して、調べた限りを投稿してみた。

**デフォルトの名無しさん** · 2019/12/04(水) 08:21:05.72

>>549
他の分野の人にどういう説明してるのかを知りたかっただけなんだけどね
まあ>>525が言うように薄っぺらな知ったかが吠えてるだけってわかったからもういいやw

**デフォルトの名無しさん** · 2019/12/04(水) 08:24:57.77

>>541
setfill() じゃなくて setw() の話だけど、古い本に
「setw()の幅指定は、永続的に有効な実装と、直後の出力1回だけ有効な実装との
両方が存在するので、移植性を考えれば毎回指定する方が安全」とか載ってた。
もしかすると過去には「setfill() は1回だけ有効」な実装が存在したのかも知れん。

その後、規格で挙動が厳密に定められたのか、
今でも実装によって動作が違っても構わない(規格に明記されていない)のか、
肝心なその点は分からん。

**549** · 2019/12/04(水) 08:41:52.15

>>552
言ってる意味がわからんが
煽れば何か教えてもらえると思ってるアホだろ
今までお前に何度も言ったと思うが、邪魔だから出てってくれ

**デフォルトの名無しさん** · 2019/12/04(水) 08:46:18.46

>>550
他に勉強しなきゃいけないことって具体的に何だ？
インターフェースだの通信規約だの法務だのを
規格を避けて勉強なんかできるのか？
そういうおまえ自身は本当に勉強してるのか？

**デフォルトの名無しさん** · 2019/12/04(水) 08:48:00.43

>>555
一連の流れ読んでから言えよ
C++の規格や仕様の話だボケ

**デフォルトの名無しさん** · 2019/12/04(水) 09:05:20.91

>>556
おまえこそどーに目ぇつけとんのやあんだら
C++以外の規格なら読むんだって話じゃねえだろうがよ

**デフォルトの名無しさん** · 2019/12/04(水) 09:08:12.84

>>557
＞C++以外の規格なら読む
誰がそんなこと言った？
他に勉強しなきゃいけないこと、に含まれてるだろうが
自分の勘違い棚に上げるなよ

**デフォルトの名無しさん** · 2019/12/04(水) 09:15:53.35

>>557
550は規格を読んだことがあるやつは皆無と言ったんだよ
それがC++だけにせよ規格全てにせよ
おかしい主張であることに変わりはない

自分の発言を読み返してみな
俺がわざわざ頓珍漢とか言ってやることもない

**デフォルトの名無しさん** · 2019/12/04(水) 09:16:34.99

安価ミスった
558な

**554=556=558** · 2019/12/04(水) 09:32:28.38

お前はC++の標準ライブラリ等の仕様の確認に毎回規格書読んでんの？

**デフォルトの名無しさん** · 2019/12/04(水) 09:53:35.71

>>551, >>553 ありがとうございます。
今「C++ポケットリファレンス」を見たら

ほかのマニピュレータと異なり、std:setw()は例外的に効果が持続しません。
一度std::setw を指定した出力が行われると効果は解除されます
(std::setw(0)を呼び出した状態になります)。

とありました (p.250)。
それと...
$ man std::setw
～
The width property of the stream will be reset to zero (meaning "unspecified") if ～

ちゃんと書いてますね。何より先に man を見るべきでした。
とはいえ setw は "例外的" なのだとちゃんと教えてくれる本は助かるなあと思いました。

**デフォルトの名無しさん** · 2019/12/04(水) 10:10:41.87

それから man の最後には http://cppreference.com へのリンクがありました。
あまり www.cplusplus.com との違いを意識した事はなかったのですが、
公式仕様として参照するべきなのはそっちのようですね。

同じ内容の日本語版は
https://ja.cppreference.com/w/cpp/io/manip/setw
で見れました。

**デフォルトの名無しさん** · 2019/12/04(水) 10:52:51.16

規格確認部とかあるんじゃないの。
知らんけど。

**デフォルトの名無しさん** · 2019/12/04(水) 10:57:38.20

>>561
え？・・・そうだけど？
規格票というか、正確にはドラフトな
何かおかしいか？

**デフォルトの名無しさん** · 2019/12/04(水) 11:17:13.05

それ無駄に時間かかってるんじゃないの
よくクビにならないな

**デフォルトの名無しさん** · 2019/12/04(水) 11:19:22.93

1.禿でも判るC++入門
2.判ると禿げるC++入門
3.禿専用C++

**デフォルトの名無しさん** · 2019/12/04(水) 12:23:43.29

>>554
煽る以前に>>513からはペラッペラの内容しかでてこないことはわかったからお前が出てけよw

**デフォルトの名無しさん** · 2019/12/04(水) 12:29:09.42

>>561
必要なら読むだろ
流石に毎回じゃないけど
そもそもお前は規格も読まないでテキトーにコード書いてるのか？

**デフォルトの名無しさん** · 2019/12/04(水) 12:36:02.75

>>569
＞流石に毎回じゃないけど
なら黙ってろ

規格の原文読まない＝テキトーにコード書く、なのかお前の中では
思い上がりすぎだろ

**デフォルトの名無しさん** · 2019/12/04(水) 12:48:55.97

いや、きちんと仕事したくて
伝聞に頼らず一次ソースを確認するんだよ

**デフォルトの名無しさん** · 2019/12/04(水) 12:53:29.05

実用コード書くより机上の空仕様書描くのが好きな人なんやろな

**デフォルトの名無しさん** · 2019/12/04(水) 13:03:10.48

>>570
> 規格読んだことある人なんか皆無だと思うよ
とか言うバカに言われてもなぁ
知識がペラッペラすぎるw

**デフォルトの名無しさん** · 2019/12/04(水) 13:09:39.95

おまいらスレタイ

**デフォルトの名無しさん** · 2019/12/04(水) 13:17:06.83

みんな私のために争って！

**デフォルトの名無しさん** · 2019/12/04(水) 13:19:26.79

「きちんと仕事したくて伝聞に頼らず一次ソースを確認」
なんか胡散臭くなってきたな・・・・
「仕事でやってる人もフリーソフト開発者も」のどちらにも当てはまらないのに噛み付いてきたんだろうな
エアプログラマの相手してスレ無駄遣いした、すまんかった

**デフォルトの名無しさん** · 2019/12/04(水) 13:20:38.21

ソフトエンジニアでC++の規格書を読む人なんてほとんどいないよ
そんなのを読んでも良い設計にはつながらない

**デフォルトの名無しさん** · 2019/12/04(水) 13:23:39.63

規格書で確認しないと書けない/読めないようなコードは
基本的には悪いコード

**デフォルトの名無しさん** · 2019/12/04(水) 13:26:15.79

ゴールポスト移動中ですね判ります

**デフォルトの名無しさん** · 2019/12/04(水) 13:27:52.48

規格書ではなく規格票な
つまらん齟齬を避けたいのも
規格票を読む目的の１つだ

**デフォルトの名無しさん** · 2019/12/04(水) 13:42:20.48

>>578
でも最近、特に海外の方で自分が知っている素朴な C++ とは全く違う
書き方をしている C++ コードを良く見かけるようになったので、
新しい仕様を学ばないと理解できなくなってきた。
STLを深く使うと C++ とは思えないようなコードになるので。