C++相談室 part135

2018/03/31(土) 20:20:06.25

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

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

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

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

2018/05/09(水) 10:29:31.98

数十バイトだとスタック領域ももパンクしそう、厳しいのではないか？

2018/05/09(水) 10:34:17.87

流石に盛り過ぎ

2018/05/09(水) 10:54:36.47

知らないで盛ってると言うのはどうかと
昔6ピンpicでｃ使ってたけどRAMは16バイトだった気がする

2018/05/09(水) 11:01:43.78

調べたら勘違いで自分の持ってたのはSRAM64バイトのpicだった

2018/05/09(水) 11:58:05.29

ＰＩＣ１２Ｆ６０９とかでもプログラム領域は1Kwあるけど
数十バイトしかない奴の型番教えてくれくれ

2018/05/09(水) 12:00:11.72

PIC10F200はRAMが16バイトですね
制約は当然ありますがC言語で開発出来ます

2018/05/09(水) 12:00:58.98

C++どころかCすらやってはいけないレベルだな
恥ずかしいやつ

2018/05/09(水) 12:02:35.51

>>562
ROMとRAMの区別がつかない人がなんでこのスレにいるのか？

2018/05/09(水) 12:04:25.14

ハーバードアーキテクチャのデータメモリサイズだけ書くの
卑怯だと思うの。プログラムメモリは２５６ワードあるじゃん

2018/05/09(水) 12:07:19.83

>>557を受けての話だから
そのチープなマイコンで開発にCが使えてる

2018/05/09(水) 12:09:43.50

だから盛り過ぎでしょ

2018/05/09(水) 12:10:13.60

>>568
じゃあできないというのか？

2018/05/09(水) 12:45:08.73

>>551
競技プログラミングとかunity覚えるの面倒とか？

2018/05/09(水) 13:09:28.13

>>566
RAMってしっかり書いてるじゃん
チープなマイコンだとROM/RAMに別れてるのが普通だよアーキテクチャー関係無しに

2018/05/09(水) 18:42:26.74

スタックの話だよね
スタックはRAMであることが絶対条件なので
ROMがどんだけあろうが関係ない

2018/05/09(水) 18:49:54.96

C# と C++ は世の中でどちらのほうが使われているのでしょうか？

いま、 C++ の本（ロベール）を読んでいますが、無駄ですか？
柴田望洋訳の分厚い本も買ってしまいました。

**デフォルトの名無しさん** · 2018/05/09(水) 18:54:28.74

C++は無駄とは言い切れないがロベールは無駄

2018/05/09(水) 18:59:28.28

>>574

ありがとうございます。

結局、どのプログラミング言語を習得するのがおすすめでしょうか？

Python のような言語は除いて。

2018/05/09(水) 19:01:30.85

何をやりたいと考えているか次第

2018/05/09(水) 19:05:22.21

>>576

趣味でアルゴリズムとデータ構造を勉強しています。
プログラミングコンテストの問題(Aizu Online Judge)を解いたりもしています。

もし、プログラマーになるとした場合、もっとも必要とされる言語を使って、
アルゴリズムとデータ構造の勉強をすれば効率的かなと考えています。

セジウィックとウエインの本や講義動画を読んだり見たりするときには、
Javaの入門書を見たりしています。

2018/05/09(水) 19:07:11.19

>>576
コンピューターサイエンスを広く学ぶ上で一番適した言語がいいかなとも考えています。

2018/05/09(水) 19:16:40.18

C++のスレで言うのもどうかとは思うが、
初心者が覚えるのに相応しい言語はJavaじゃないかなと思う
アルゴリズムだけを学びたいなら、C言語が良いかもしれない
他の人の意見も聞いてね

◆QZaw55cn4c (ﾜｯﾁｮｲ aa60-pRpi) · 2018/05/09(水) 19:47:49.06

>>577
そういうのがやりたくて、しかも今 C で片言がしゃべれるのなら、そのまま進めるのが一番いい

2018/05/09(水) 20:02:47.70

>>579
>>580

参考になりました。
ありがとうございました。

2018/05/09(水) 21:19:28.33

>>578
アセンブラかVerilog/VHDLあたりじゃね？
今の伝統的言語はユニプロセッサに源流があって
直列一辺倒の弱点が浮き彫りになっている昨今
【広く】学ぶうえでは却って足かせになるぞ

2018/05/10(木) 12:15:01.11

>>578
Occam2 とか XCが最凶かもな

2018/05/10(木) 12:20:40.60

Cはアルゴリズム勉強にはあまり向いてないと思う
以前各言語向けのアルゴリズム辞典みたいのを見比べてみたけど
Cのだけ異質な感じ
forのカウントいじってあったりして勉強しにくい

少なくともオブジェクト指向入れた言語じゃないと後で生かしにくい

2018/05/10(木) 15:18:57.11

オブジェクト指向が導入されているべきかどうかというよりも、単純に C は抽象化の能力が低いんだよ。
下層レイヤを上手く隠せないから段階的に積み上げていくというのがやり難い。

学習段階では上から下まで見えているって方が分かりやすいということはあるかもしれないので、
どちらが良いかというのは考え方とか好みにもよるので一概には言えないと思う。

2018/05/10(木) 15:24:31.29

アルゴリズムの仕組みが言語の内部に隠されると理解を妨げるだろう
オブジェクト指向については、別の機会に学べば良い

2018/05/10(木) 15:59:00.64

そうとも言えない。
複雑なものを理解するには「分解する」は基本的なアプローチのひとつで、レイヤを切り分けるのは有用だよ。
それが >>585 に書いた「段階的に積み上げていく」の意図ね。

かといってそれで全体像が見通しにくくなってもそれはそれでアレだし、何がベストかなんて言えないよ。
やりやすいと思った方でやるしかしょうがないんじゃね。

2018/05/10(木) 16:46:33.01

C言語で書かれたアルゴリズムが読み解けるようでないと
後で困るだろう

2018/05/10(木) 17:51:59.26

C以外だとリストのシャッフルはshuffleだけで済ませられる
Cだとshuffleの中身を書かないといけない

C以外だと「Combination()を使おう」
Cだと「Combination()を実装しよう」
くらいの差がある

アルゴリズムがどこまで指すのか分らないが、楽しいことから先にやればいいんじゃねえの、ということで、C以外から

2018/05/10(木) 18:15:07.55

アルゴリズムを学習するって、その実装の中身を理解することだろう

2018/05/10(木) 18:39:39.67

個人的には、各種ソートや基本的なデータ構造の操作を自前で書くようなシンプルなところから入った方が分かりやすいかと思うけど、まあ人それぞれかなと。

2018/05/10(木) 18:45:52.70

みなさん、ありがとうございます。

セジウィックとウエインのアルゴリズムの本に載っているのは、おそらく
ジェネリクスを使っているので一般性もあって、かつ効率もいいプログラム
だと思います。

ライブラリのようなクオリティーでプログラムを作るというのが理想です。

2018/05/10(木) 18:51:57.46

アルゴリズムの本というと C 言語でプログラムが書かれた本が多いですが、
やっと C++ で書かれた日本語の本が最近出版されましたね。

セジウィックとウエインの本よりももっと初歩的な本のようですが。

データ構造とアルゴリズム (電子情報通信レクチャーシリーズ B-8) 単行本 ? 2018/2/1
岩沼宏治 (著), 美濃英俊 (著), 鍋島英知 (著),

2018/05/10(木) 19:17:25.91

アルゴリズムの抽象的な部分(オーダーとか適用するデータ構造の再帰性や対応関係)を学ぶならCよりML系の方が向いてるは向いてると思う
ただ環境構築なんかの障壁もあるだろうし最終的にCは触るだろうけどアルゴリズム以外の所で詰まりにくいという意味でC#を推してみる

2018/05/10(木) 19:18:39.74

>>594
勿論F#でもいいし理想はそうだが好みというかネットの情報量の多さ的にC#を挙げた

2018/05/10(木) 19:24:56.01

C#はLinqが便利すぎてお勉強用としてはどうなんだろうなぁ
何やるかによるけど

2018/05/10(木) 20:05:12.45

ああ勘違いしていた
アルゴリズムを勉強したいのではなく
>>もし、プログラマーになるとした場合、もっとも必要とされる言語を使って、
>>アルゴリズムとデータ構造の勉強をすれば効率的かなと考えています。
なのね

であれば >>573 氏が現役バリバリな時の主流の言語なんて今からじゃ予想つかないだろうし、実務なら最も適した言語が使われるだけだからC++をそのままやり続ければいいと思う

コンピュータサイエンス自体死ぬほど広範囲な学問で、実務のプログラミングとの間にもやっぱり開きがあって万能な言語なんて無いよ
敢えて言うなら物理と数学、これだけは裏切らない

2018/05/10(木) 21:40:19.82

>>597
あと英語な

2018/05/10(木) 21:41:29.95

>>585
そこがいいんだよ
隠蔽されたことを忘れたフリをし
本当は忘れていないということの練習に向いている

忘れたフリが綺麗なコードの練習
本当は忘れていないことが性能評価につながる
両立した技能の練習に向いているということだ

2018/05/11(金) 12:08:47.61

>>571
>>572
そもそもROMの反語はRAMじゃねぇし(SAMってのもある)
SHARCだとDMのサイズは0でも、PMさえあれば動く
で、PMの事隠してマウンティングすればお前らは受け入れるのか？

2018/05/11(金) 12:33:06.03

今はどうか知らないけどcは標準でvectorやlistやmapがないから
そこから始めないといけないのでめんどくさい
アルゴリズム辞典見たら配列をdefineされたNやMで確保してた
ライブラリとして使う気ゼロ

2018/05/11(金) 13:01:20.12

>>600
世の中のほとんどのチープなワンチップマイコンはROM/RAM構成なんだよ

世の中を知ってたら>>557に対して>>566なんて考えは出ないはずだ

2018/05/11(金) 13:03:39.86

>>601
Cはチープな環境やOS関連で使われるくらいだからなあ
コストのデカイlistやmapなんて無くて当然
必要になったら必要最低限の機能で自力で作る世界

2018/05/11(金) 13:59:40.72

>>602
あーハイハイそうですね～

2018/05/11(金) 15:05:19.79

>>603
コスト云々よりジェネリクスが無いから汎用コンテナを作るのが難しい

2018/05/11(金) 15:52:32.74

作るのが難しい人は拾ってくればいいだけ

2018/05/11(金) 18:24:24.95

数十バイトしかないなら、普通アセンブラで書くだろう

2018/05/11(金) 18:50:06.30

そうでもない
普通にCが使えるので

2018/05/11(金) 18:55:57.64

>>605
別に難しくない
標準化されてないから広まってないだけで
作ってる人はいっぱいいる

2018/05/11(金) 19:49:06.46

>>600
だから何？
いいよ、じゃあSAMもありにしようや
で、スタックの量がCに適するのか適さないのか
おまえさんなりの考えを言ってみな

2018/05/11(金) 19:59:50.91

>>609
静的型の恩恵が受けられなくなるだろ？

2018/05/11(金) 20:34:03.62

で？

2018/05/11(金) 20:40:41.03

>>611
普通にvoidポインタに置き換えるだけだが。
何が難しいの？

2018/05/11(金) 20:56:19.66

初期の JAVA もコンテナを使うときにキャストが必須ってアレな仕様だったよな。

2018/05/11(金) 21:04:30.87

昔は仕様がダメで段々改良されていくということがありますが、
それはなぜなのでしょうか？

その当時はハードウェアの性能上そういう仕様にせざるを得なかったというような
理由があるのでしょうか？

それとも単に思慮が足りなかったというだけでしょうか？

2018/05/11(金) 21:16:49.77

理由はいろいろ

2018/05/11(金) 21:20:43.57

>>615
知見が足りなかったというのが最大の理由だと思うけど、
せざるを得なかった場面よりもその程度で充分だったという方が多いと思う。

2018/05/11(金) 21:23:11.17

仕様が固まらないうちに作る時は、それなりの暫定仕様か何らかの制限事項を設けて開発したな

2018/05/11(金) 21:36:00.99

知見が足りなかったなんてのは少数派と思う

シンプルな仕様からだんだんと機能追加で肥大化の方向
ってのがほとんど

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-bFqk) · 2018/05/11(金) 21:43:16.90

>>619
C89 からの「関数の引数として構造体が（実体渡しとして)OK」というのは、私には堕落以外のなにものでもないと

2018/05/11(金) 21:53:49.41

昔のC++にあった（今もある）糞の山は、今のモダンな他言語たちへの反面教師として大いに役立った

2018/05/11(金) 21:55:02.56

例えばどの仕様が糞？

2018/05/11(金) 22:06:17.59

>>613
メモリぶっ壊しやすくなるのは十分問題だと思うが
ライブラリ利用者側の責任で何とかしろってのはリソースの条件が厳しけりゃしょうがないがさもなくば正当化しかねる

2018/05/11(金) 23:57:53.51

独習C++は一通り読んだんだが次に読む本ある？問題集みたいなのとか

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-bFqk) · 2018/05/12(土) 00:13:37.95

>>624
私がお勧めしているのは
https://www.amazon.co.jp/dp/4894714221/
https://www.amazon.co.jp/dp/4881357786/

前者は実は難があって、変てこな実装をしている部分もありますが、それを自分で調べて解決すれば、強くなれると思います
後者は STL の解説本です

いずれも C++11 以前で今となっては古いのですが、代わりになるような本がない…
両方とも私は読んでいますので、普通の質問には答えることができます

2018/05/12(土) 00:24:10.29

最初に読む本は禿4版一択ですよ。

2018/05/12(土) 01:17:09.76

どの言語でも、入門書の次は、Effective 何々

2018/05/12(土) 05:59:18.81

>>625
「なぜ」そうするのか
「なぜ」そうなっているのか
他にどんな選択があったのか
という思考回路の俺には合わない本だ

2018/05/12(土) 06:50:27.10

>>623
それは低級言語に求める物じゃない

C/C++は低級言語として数十年間圧倒的なシェアであり続けている
これってすごいことだと思う

2018/05/12(土) 07:33:39.79

>>623
データ構造の要素が静的に型が決まろうがそうでなかろうが、必要な要素数のメモリを確保する作業に違いはない。
せいぜい型のサイズを余計に掛け算するくらいだ。
確保するサイズが間違っていれば静的に型が決まろうがメモリ破壊は起きる。
もう少し具体的に示してくれないか？

2018/05/12(土) 07:37:30.31

静的な型の恩恵がどうたらって
mallocがvoid*を返すのと同じだろ
問題ちゃ問題だがそんなもん怖がるやつぁC使いに向かない

2018/05/12(土) 08:45:19.55

>>629
静的なら実行時パフォーマンスには影響しない

>>630
「既に壊しうるのだからちょっとくらい壊せる場所増やしてもいいでしょ」には無条件では同意しかねる

>>631
向いていようがいまいがCの案件はあるわけで, 可能な限り安全にコーディングしたいと思うのは可笑しいか？

で話を戻すと, 汎用コンテナのCでの実装には, 大きく分けてもdefine使った型安全な実装とvoid *を使ったオーバーヘッドあり型安全なし実装が考えられるわけで, まずそれだけでこうして対立し得る
実装上でもいずれもpros/consがあるわけで, そりゃ規格がまとまる道理がないよね, って主張

別に必要最小限の機能で自分で実装することを否定するわけじゃないし, 型安全が絶対だという気もない

2018/05/12(土) 08:57:39.01

高速コンパクトと安全性利便性は相反するものだ
諦めろ

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-bFqk) · 2018/05/12(土) 09:08:53.09

>>627
独習の次に Effective C++/Effective Modern C++ は飛躍しすぎではないかな？
ついてこれるのか

2018/05/12(土) 09:12:02.44

>>634
必読書ですしおすし

2018/05/12(土) 09:13:51.54

>>632
> void *を使ったオーバーヘッドあり
とは何？サイズ管理＋アドレスの計算のこと？
だったらC++の汎用コンテナでも同じ事を内部でやっているし、オーバーヘッドはないが。
見た目でしか分からない人はCに向いていないぞ。

というか、型安全が欲しければC++を、
そんなん要らんから小さくて早いコードを、というのならCを、ってだけだろ。
その分自分で管理する項目が増えるだけの話で。
選択肢はユーザー側に与えられているのだから、それ以上は要らんだろ。

2018/05/12(土) 09:15:07.55

>>632
できねえこと言ったってしゃーないだろ
Cにはテンプレートがない
諦めるしかない

2018/05/12(土) 09:18:40.30

とりあえずスクリプト言語やC#で書く→速くしたい所をC++で書く→もっと速くしたい所をCやasmで書く
これが正解
どれかにこだわって対立させて排他するのはアホ

2018/05/12(土) 09:26:19.92

>>638
同意。

若い奴が統一言語「○○だけ勉強すれば全ておｋ」を求めるのは自然だが、
そうなっていないのは理由があって、つまりは手抜きと実行効率（速度）の兼ね合いだ。
一時期Cが統一言語だったが、それは他言語がゴミだったから（対抗馬がLisp)であって、
C++で再統一されることはないよ。特に今のC++では。

2018/05/12(土) 09:31:37.48

オーバーヘッドについては撤回

>>636-639
だから基本的にそういう役割分担について否定しているわけじゃない
Cで汎用コンテナが標準化されることはないだろうっていうのが元々の主張

2018/05/12(土) 09:56:03.80

>>638
Cで書けることは基本C++で書ける
C++で最適化出来ない所はCでも無理
アセンブラしかない

2018/05/12(土) 10:05:55.31

>>636
CやC++に関わらず専用なコードは汎用に比べて高速コンパクトに出来る事がある

つまり、
void*で作って全てのコンテナサイズ(型)同一コードよりも型ごとにコードを作る方が速いことがある

C++のコンテナは全て専用コードなので
コードの肥大化と引き換えに微妙に速いかもしれない
コードの肥大化によってキャッシュミスして遅い可能性もあるけど

2018/05/12(土) 11:33:41.32

>>638
> 速くしたい所をC++で書く→もっと速くしたい所をCやasmで書く
asmはいいとしてC++→Cでもっと速くなるケースなんてあるのか？

2018/05/12(土) 11:35:17.48

>>632
>すでに壊してるのだから
一体どこからそんな主張を読み取ったんだ？
勝手に人の主張を捏造せずに、ちゃんと質問に答えてくれないか？

あと、void*使わなくても、生成時に型サイズを受け取る方法もある。
汎用コンテナ作るのにdefineで型定義なんてするわけないだろう。

2018/05/12(土) 11:39:23.77

>>642
qsortやbsearchとかそうだよな
C++のsortやbinary_searchには絶対に敵わない

**デフォルトの名無しさん** · 2018/05/12(土) 11:44:45.24

>>644
FF外から失礼します
「すでに壊してるのだから」とはどこにも書いてないと思うのですが
なぜあなたこそ勝手に人の主張を捏造しているのでしょうか？
FF外から失礼しました

2018/05/12(土) 11:48:55.40

>>646
面倒なやつだな。
「既に壊しうるのだから」
これでいいか？

2018/05/12(土) 11:52:21.18

ふぁいなるふぁんたじぃ？

2018/05/12(土) 11:59:59.40

前輪駆動車じゃない？

2018/05/12(土) 12:14:05.61

255

2018/05/12(土) 12:31:23.28

2018/05/12(土) 12:40:45.91

汎用バイナリ < 汎用コード専用バイナリ < 専用コード

速度的にはこう

速度が非常に重要であれば
CだろうがC++だろうが専用コードを書くのが一番

2018/05/12(土) 12:42:10.49

>>643
間接参照を抜ける場合とかだろ。
逆にCよりもC++の方が速くなるコードの方があり得ないと思うが。
実際にC++はCより遅いってのは事実だし。

>>645
お前が値配列と参照配列の区別が付いてないだけだろ。

2018/05/12(土) 12:44:50.30

>>653
アンカーミスったか？
qsortとstd::sortはどちらも値であろうが参照（ポインタ）であろうが使えるぞ

2018/05/12(土) 12:49:50.14

>>653
>>641

2018/05/12(土) 12:50:14.86

>>653
> 間接参照を抜ける場合とかだろ。
それC++のまま書き換えればいいだけ

> 逆にCよりもC++の方が速くなるコードの方があり得ないと思うが。
そんな主張はしてない

> 実際にC++はCより遅いってのは事実だし。
だからどんなケースなんだよ
STLとか使いまくって遅いとかなら使わないように書き換えればいいだけだろ

2018/05/12(土) 12:58:57.32

厳密に言うと

C11の可変長配列はC++には無い
C++では例外処理を実現するために関数コールに微妙なオーバーヘッドがある場合がある

って感じでCの方が有利な事がある

どちらもガシガシに最適化した場合の話

2018/05/12(土) 13:05:00.64

x86-32
例外処理を有効にすると
関数コールに微妙なオーバーヘッドが加わる

x86-64
例外処理の為のオーバーヘッドは無い
その代わり例外発生時の処理は非常に遅い

Cの可変長配列のような、スタックに可変長サイズを確保する手段はC++には無い
当然ダイナミックなメモリアロケートよりはスタックに確保した方が速い
ただし実際にはあまり使われていないと思われる