C++相談室 part135
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の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 >>505
>>506
>>512
み、みんな、親切にありがとう・・・ >>494
一度に作る分量が減るので間違えにくい
別々の人間が手分けして作れる >>503
そもそも>>498はコンパイルエラー(もしくは警告)になるだろ...
class CTest
{
CFoo* cfoo;
CTest(int x){
cfoo = new CFoo(x);
}
~CTest(){
delete cfoo;
}
void ReNew(int x){
delete cfoo;
cfoo = new CFoo(x);
}
};
みたいな奴を想定してたのかも知らんけどこれでもunique_ptr使えば良いだけだしね どうせ>>498の
CFoo cfoo;
はこれまた
CFoo *cfoo;
のつもりだったんだろう
とりあえず>>499の形にすればnewはなくせる
ポインタを保持したい場合も生ポインタはやめたほうがいいね 可能な限りスマートポインタを使え、そしてスマートポインタで駄目な場合はほとんどないってのはその通りなんだけど、
初心者が生ポインタをちゃんと理解したことのないままスマートポインタを使いこなせるとも思えぬ。
そこらへんはちゃんと分けて、今回の場合はまずは生ポインタを理解するという方向性で説明する場面じゃろ。 もうスマポはスマポとして理解させたほうがいいような気がするけどな
下手な生ポの知識は初心者に有害だ ポインターをdeleteせずに扱う猛者がいると聞いて駆け付けてきた delete をしない戦略ってのは無くはないよ。
アプリケーションの起動時直後にガッと大量のメモリを必要として、
終了直前に全部解放するってパターンなら、
どうせプロセスの終了と一緒にリソースは回収されるのでわざわざメモリ解放の処理を入れる必要はない。
(C++ だとデストラクタは必ずしもメモリを解放するだけではないので注意が必要だが)
だけどそういう戦略をとれるのはちゃんと理解した上で問題にならないことを確信できるだけの知識があってこそだわな。
というか、それ以上に、確保したのを解放しないのは「気持ち悪い」と感じる心が C/C++er にはある。 組み込みだとそもそも終了なんてものがなかったりする >>526
placement new の意味が今でもよくわかりません…どんなときに使うのかなあ… char buf[MAX_BUF];
new(buf) MY_STRUCT(1, 2, 3); char buf[sizeof(MY_STRUCT)];
new(buf) MY_STRUCT(1, 2, 3); >>527
VRAM みたいな特殊なメモリを C++ のオブジェクトに見せかけたい場合とか すでに確保したメモリーブロック上でコンストラクターを発動させる。 組み込みとかゲーム機のような、最初に一気に確保する環境で使うんじゃないかね
といっても確保済みのメモリに対して断片化しないように管理する仕組み作ったら、必然的にnew演算子もオーバーロードするだろうから結局placement new使わんかもしれんけど クラスを丸ごとDLL化するときにはnew系をオーバーロード
しておかないと解放時にエラーになるべ。
ヒープはDLL単位にあるので集めておきたい場合はplacement使う unique_ptrの配列版でメモリの再確保を行いたい場合どのように行うのがベターですか? >>534
unique_ptr::reset( ) じゃねーの? [][][] [[[ ] X_[[[ [] ][ [] ][][[[] 以下のように、派生クラスのメンバ関数で基底クラスのメンバ関数を呼ぶように
基底クラスが派生クラスに強制する方法はないでしょうか?
ttps://wandbox.org/permlink/K4IHMYwOsutPQz3i FAQやな
インターフェースとカスタマイズポイントを分けろ
struct base {
void f() { //非仮想
cout << "base" << endl;
this->f_custom();
}
private:
virtual void f_custom(){}
};
struct child : base {
void f_custom() override {
cout << "child" << endl;
}
}; レスありがとうございます。
NVIというのがあるのですね。
(大昔に勉強したような…しかし思い出せず) >>544
pure virtualなのに関数定義することなんてできたのか…
f()とbase::f()は同じ関数なんだよね? }]] [[《_["[[]]" 〈[]》》 [][][]0,1》》〈〉 [] } } "B,V,0%%%,*1BVLO,SASA1`}}//%\\0,1\"VL"\ >>547
12行目のbase::f()はvirtualを抑止してpure virtualを呼び出す
13行目のf();は動的結合でchid::f()を呼び出す
baseは抽象クラスでnew base{}できないので
13行目の動的結合がbase::f()を呼び出すということは起こりえない
だからif(typeid(*this) != typeid(base))のようなチェックをしていない ちょっと根本的な質問を。
C#が既に普及しているなかあえてC++に固執する理由ってある? MSのOSしか使わないなんちゃてPGならC#で十分じゃないの mono/Xamarinはしんどいと言う事を知らない世界の内はいいんじゃない?
大体Win限定だとしても高速化するのにC++で書いたのをdllimportするだろう ざまりんが苦しい人は信仰が足りないのです
僕は信仰の自由を主張しますけどね >>551
余計な依存関係をかかえないのが嬉しいです Boostとか使ってると余計な依存関係をかかえてしまうけどな
C言語が一番 一番多くの環境で使えるのはC言語
RAMが数十バイトしかないような非常にチープな8bitマイコンでも使える 数十バイトだとスタック領域ももパンクしそう、厳しいのではないか? 知らないで盛ってると言うのはどうかと
昔6ピンpicでc使ってたけどRAMは16バイトだった気がする 調べたら勘違いで自分の持ってたのはSRAM64バイトのpicだった PIC12F609とかでもプログラム領域は1Kwあるけど
数十バイトしかない奴の型番教えてくれくれ PIC10F200はRAMが16バイトですね
制約は当然ありますがC言語で開発出来ます C++どころかCすらやってはいけないレベルだな
恥ずかしいやつ >>562
ROMとRAMの区別がつかない人がなんでこのスレにいるのか? ハーバードアーキテクチャのデータメモリサイズだけ書くの
卑怯だと思うの。プログラムメモリは256ワードあるじゃん >>557を受けての話だから
そのチープなマイコンで開発にCが使えてる >>551
競技プログラミングとかunity覚えるの面倒とか? >>566
RAMってしっかり書いてるじゃん
チープなマイコンだとROM/RAMに別れてるのが普通だよアーキテクチャー関係無しに スタックの話だよね
スタックはRAMであることが絶対条件なので
ROMがどんだけあろうが関係ない C# と C++ は世の中でどちらのほうが使われているのでしょうか?
いま、 C++ の本(ロベール)を読んでいますが、無駄ですか?
柴田望洋訳の分厚い本も買ってしまいました。 >>574
ありがとうございます。
結局、どのプログラミング言語を習得するのがおすすめでしょうか?
Python のような言語は除いて。 >>576
趣味でアルゴリズムとデータ構造を勉強しています。
プログラミングコンテストの問題(Aizu Online Judge)を解いたりもしています。
もし、プログラマーになるとした場合、もっとも必要とされる言語を使って、
アルゴリズムとデータ構造の勉強をすれば効率的かなと考えています。
セジウィックとウエインの本や講義動画を読んだり見たりするときには、
Javaの入門書を見たりしています。 >>576
コンピューターサイエンスを広く学ぶ上で一番適した言語がいいかなとも考えています。 C++のスレで言うのもどうかとは思うが、
初心者が覚えるのに相応しい言語はJavaじゃないかなと思う
アルゴリズムだけを学びたいなら、C言語が良いかもしれない
他の人の意見も聞いてね >>577
そういうのがやりたくて、しかも今 C で片言がしゃべれるのなら、そのまま進めるのが一番いい >>579
>>580
参考になりました。
ありがとうございました。 >>578
アセンブラかVerilog/VHDLあたりじゃね?
今の伝統的言語はユニプロセッサに源流があって
直列一辺倒の弱点が浮き彫りになっている昨今
【広く】学ぶうえでは却って足かせになるぞ Cはアルゴリズム勉強にはあまり向いてないと思う
以前各言語向けのアルゴリズム辞典みたいのを見比べてみたけど
Cのだけ異質な感じ
forのカウントいじってあったりして勉強しにくい
少なくともオブジェクト指向入れた言語じゃないと後で生かしにくい オブジェクト指向が導入されているべきかどうかというよりも、単純に C は抽象化の能力が低いんだよ。
下層レイヤを上手く隠せないから段階的に積み上げていくというのがやり難い。
学習段階では上から下まで見えているって方が分かりやすいということはあるかもしれないので、
どちらが良いかというのは考え方とか好みにもよるので一概には言えないと思う。 アルゴリズムの仕組みが言語の内部に隠されると理解を妨げるだろう
オブジェクト指向については、別の機会に学べば良い そうとも言えない。
複雑なものを理解するには「分解する」は基本的なアプローチのひとつで、レイヤを切り分けるのは有用だよ。
それが >>585 に書いた「段階的に積み上げていく」の意図ね。
かといってそれで全体像が見通しにくくなってもそれはそれでアレだし、何がベストかなんて言えないよ。
やりやすいと思った方でやるしかしょうがないんじゃね。 C言語で書かれたアルゴリズムが読み解けるようでないと
後で困るだろう C以外だとリストのシャッフルはshuffleだけで済ませられる
Cだとshuffleの中身を書かないといけない
C以外だと「Combination()を使おう」
Cだと「Combination()を実装しよう」
くらいの差がある
アルゴリズムがどこまで指すのか分らないが、楽しいことから先にやればいいんじゃねえの、ということで、C以外から アルゴリズムを学習するって、その実装の中身を理解することだろう 個人的には、各種ソートや基本的なデータ構造の操作を自前で書くようなシンプルなところから入った方が分かりやすいかと思うけど、まあ人それぞれかなと。 みなさん、ありがとうございます。
セジウィックとウエインのアルゴリズムの本に載っているのは、おそらく
ジェネリクスを使っているので一般性もあって、かつ効率もいいプログラム
だと思います。
ライブラリのようなクオリティーでプログラムを作るというのが理想です。 アルゴリズムの本というと C 言語でプログラムが書かれた本が多いですが、
やっと C++ で書かれた日本語の本が最近出版されましたね。
セジウィックとウエインの本よりももっと初歩的な本のようですが。
データ構造とアルゴリズム (電子情報通信レクチャーシリーズ B-8) 単行本 ? 2018/2/1
岩沼 宏治 (著), 美濃 英俊 (著), 鍋島 英知 (著), アルゴリズムの抽象的な部分(オーダーとか適用するデータ構造の再帰性や対応関係)を学ぶならCよりML系の方が向いてるは向いてると思う
ただ環境構築なんかの障壁もあるだろうし最終的にCは触るだろうけどアルゴリズム以外の所で詰まりにくいという意味でC#を推してみる >>594
勿論F#でもいいし理想はそうだが好みというかネットの情報量の多さ的にC#を挙げた C#はLinqが便利すぎてお勉強用としてはどうなんだろうなぁ
何やるかによるけど ああ勘違いしていた
アルゴリズムを勉強したいのではなく
>>もし、プログラマーになるとした場合、もっとも必要とされる言語を使って、
>>アルゴリズムとデータ構造の勉強をすれば効率的かなと考えています。
なのね
であれば >>573 氏が現役バリバリな時の主流の言語なんて今からじゃ予想つかないだろうし、実務なら最も適した言語が使われるだけだからC++をそのままやり続ければいいと思う
コンピュータサイエンス自体死ぬほど広範囲な学問で、実務のプログラミングとの間にもやっぱり開きがあって万能な言語なんて無いよ
敢えて言うなら物理と数学、これだけは裏切らない >>585
そこがいいんだよ
隠蔽されたことを忘れたフリをし
本当は忘れていないということの練習に向いている
忘れたフリが綺麗なコードの練習
本当は忘れていないことが性能評価につながる
両立した技能の練習に向いているということだ >>571
>>572
そもそもROMの反語はRAMじゃねぇし(SAMってのもある)
SHARCだとDMのサイズは0でも、PMさえあれば動く
で、PMの事隠してマウンティングすればお前らは受け入れるのか? 今はどうか知らないけどcは標準でvectorやlistやmapがないから
そこから始めないといけないのでめんどくさい
アルゴリズム辞典見たら配列をdefineされたNやMで確保してた
ライブラリとして使う気ゼロ >>600
世の中のほとんどのチープなワンチップマイコンはROM/RAM構成なんだよ
世の中を知ってたら>>557に対して>>566なんて考えは出ないはずだ >>601
Cはチープな環境やOS関連で使われるくらいだからなあ
コストのデカイlistやmapなんて無くて当然
必要になったら必要最低限の機能で自力で作る世界 >>603
コスト云々よりジェネリクスが無いから汎用コンテナを作るのが難しい 数十バイトしかないなら、普通アセンブラで書くだろう >>605
別に難しくない
標準化されてないから広まってないだけで
作ってる人はいっぱいいる >>600
だから何?
いいよ、じゃあSAMもありにしようや
で、スタックの量がCに適するのか適さないのか
おまえさんなりの考えを言ってみな ■ このスレッドは過去ログ倉庫に格納されています