C++相談室 part140
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の1行目に以下を追加して下さい。 !extend:on:vvvvv:1000:512 C++に関する質問やら話題やらはこちらへどうぞ。 ただし質問の前にはFAQに一通り目を通してください。 IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。 前スレ C++相談室 part137 (正しくはpart138) http://mevius.5ch.net/test/read.cgi/tech/1535353320/ C++相談室 part139 https://mevius.5ch.net/test/read.cgi/tech/1538755188/ このスレもよろしくね。 【初心者歓迎】C/C++室 Ver.103【環境依存OK】 https://mevius.5ch.net/test/read.cgi/tech/1530384293/ ■長いソースを貼るときはここへ。■ 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 C#で書かれたC#以外のコンパイラとかあるんだっけ >>675 その解析ツールはC++11対応してるの? その程度静的解析持ち出すまでもなく コンパイラのwarningにできるでしょ え、静的解析でauto禁止にするって話だったの? 静的解析というよりどっかのしょうもないガイドライン準拠か調べるオマケレベルの機能だろそれ 1LLとlong long型の1と明示されている変数に対して警告出すのおかしくない? 世の中にはauto使うと読みにくくなるから使わないで、って言う人が本当に居るから・・・ 読みにくくなる場合があるから「全部」禁止な って言う老害 std::vector<std::pair<…>> 読みやすくするためとテンプレートのためにautoを使うんじゃないの autoで読みにくくなる所って大体変数名をちゃんとすれば良い それで足りないなら仕方ないから型を書く 静的解析ツールの挙動を好意的に解釈すれば、 「暗黙の処理」に対して「それって本当にプログラマの意図した通り?」 ってのが機械的には読み取り難いことだから厳しい側に倒してるんじゃない? 仮にそうだとしたら、 機械で「わからない」箇所を人間が検証してねっていう話なわけで、 よくない作法だからやめてねというわけではないのでは。 ただ、テスト駆動開発で最初からテストしやすいプログラム構成をするように、 静的解析ツールを開発に活用する前提で静的解析しやすりプログラムを書くというポリシーも それはそれでひとつの選択ではあるだろ。 今使っている静的解析ツールはIPAのこのルール↓↓↓への適応をチェックするやつ ttps://www.ipa.go.jp/sec/publish/tn16-007.html (ツール自体はIPAとは無関係なサードパーティー製 autoはそれ自体は別に何とも言われなかったと思う 一方、>>670 の下の方 long i = 1; とすると、R2.4.1あたりの指摘を食らっていたと思う ひょっとしたらR2.5.1かもしれん… 最終的に指摘を出なくするので記憶モード、 なんかクソとクソを組み合わせてるな clang一つあれば全部解決だろうに >>687 こういうバカが当時は最新だったが今はレガシーなコードを残していくという負の連鎖。 >>673 int の 1 を long long に変換したらそれは 1LL じゃないの? >>696 そうだよ もちろん結果は同じになるけど生成コードが違うかもって話 まぁ書いてる通りほぼあり得ないと思うけど 構造体や複数の変数の中から必要な変数を扱うときに auto & var1 = ってエイリアス的なノリで使ってるけどこれはありだよな? C++が束縛ってイキッた数学用語使うのなんかいらっとくるんだよね 理論もへったくれもない建て増し温泉旅館のクソ言語のくせに C++20でいろいろな武装がついて、ますます訳が分からなくなってきた。 ついにコンセプト入るんやろ? やることが増えただけとも言えるが クラステンプレートの引数推論は改良されないのかな・・ コンストラクト時にしか省略できない&パラメータが残る形で省略できないのは不便 <=>、契約、range... 結構盛りだくさんだよね 大学で2年CをやったんだけどC++を学習するのかなり楽になる? 大学次第かなぁ CができればC++の学習はそら楽になるよ、相対的には >>711 C++はC言語のほとんどの部分を内包したようなものだから、先にC固有の部分を理解した上でC++に入るのはかなりやり易いとは思う。 あと、Cでは当たり前のやり方がC++では推奨されないやり方になる部分もあるので、考え方の切り替えは必要になる。推奨されないといっても深い理解のためにはけして無駄になるわけではない。 まあそれでも十分大変だが。 >>714 >Cでは当たり前のやり方がC++では推奨されないやり方 なんかありましたっけ? mallocとかsetjmp/longjmpとか 変数は関数の頭じゃなくて使う直前に宣言するとか ファイラ作る場合c+とc#どちらがいいのですか? いずれ3dもやりたいです ご本尊のハゲ先生は「Cを知らなくてもC++を使える」と書いてるな。 一方『独習C++』でシルトさんは「Cを知らなきゃC++は難しい」と書いてる。 C以外のプログラミング言語を知ってるかどうかに依存するのか知れんし、 「この本ではCと共通する部分は説明しないよ」程度の意味かも知れんけど。 malloc/freeだとコンストラクタ・デストラクタが呼ばれないからね。 placement newと組み合わせて、余計なmallocを減らして高速化をねらう使い方もあるにはあるけど、そういのはコンテナクラスでまとめちゃうだろうし。 >>718 まあ難しいけど使えるという状態はあるからその2つは矛盾してるわけじゃない >>719 malloc() の戻り値は「void *」で、C だとどんな型のポインタ変数に代入しても エラーや警告が出なかったが、C++ だとエラーが出る。 C++ は型を非常に大切にしていて、 TYPE *ptr = new TYPE; や TYPE *ptr = new TYPE[N]; のように書くのが標準。理由は、必ずコンストラクタを呼ぶようにするためと、 型の異なるポインタには cast しない限りは絶対に代入できないようにするため だと思われる。というのは、delete ptr とした場合に、ptr の型によってどの class の デストラクタが呼ばれるかが変わったり、ptr->func() とした場合に、func が、 どの class のメンバ関数であるかをコンパイラが知るため。わずかでも違っていれば 結果が変わってきてしまう。これが C++ が大きなプログラム開発に向いている 所以でもあって、わずかな間違いでもコンパイラが見つけてくれる確率が高くなっている。 C++ で malloc() をエラーを起こさずに使うには、コンストラクタが(絶対に)存在しない ところのBYTE 配列の場合ですら、 BYTE *ptr = (BYTE *)malloc(N); のように書かなくてははならない。 これは面倒なので(←嘘です)、 BYTE *ptr = new BYTE[N]; と書く習慣になっている。 >>723 TYPE *ptr = new TYPE; の場合は、delete ptr; で、 TYPE *ptr = new TYPE[N]; の場合は、delete [] ptr; と書くのが C++ の原定義。ここが、C++ のちょっと怖い気がするところ。 間違えてても、コンパイル段階ではエラーになってくれない。 deleteにカッコつけるのってちょっと配列を特別視してて嫌だわ。 配列を実現するにしても、[]表記を捨ててもいいんじゃないの。 その辺は禿先生も失敗だったと認めてるけど今更変えられないんだよ new[]は一切使わず、配列をnewするときはstd::arrayを使うのが今時の推奨スタイルです 今時はstd::unique_ptrを使えという人もいるかも知れん。 newとdeleteでいいと思うが念のため。 たしかオブジェクトは、それと同じ型を要素とする大きさが 1 の配列と同じレイアウトだっていう保証は どっかに書いてなかったっけ? (C++ じゃなくて C だっけ? うろ覚えですまん。) それを前提とすると delete と delete[] の区別を導入してしまったのは不用意だよな。 malloc / free では区別なしに出来てたわけだし。 >>730 ヘッダ部分を除いたデータ部分としては完全に同じといっても過言ではないんだけど、 ptr = new TYPE; とした場合は、C++ の仕様上は メモリブロックの先頭に「配列の場合には埋め込まれるところの要素数」をコンパイラは 必ずしも埋め込まなくても良いという事になっていて、その場合、delete 命令から見ると、 要素数1の配列とは同じではない。ただし、VC++ の場合には、危険を避けるため、 delete と delete [] は、どちらを書いても問題なく動作するようになっている という文書を読んだ事が有る。 (C++元々の)仕様は、なるべくメモリ使用量も検査量も少なくして効率を上げる、 という哲学から来るものなんだけど、型検査をがちがちにして安全性を高めている一方で、 非常に危険な仕様になっていると言えなくもない。ただし、TYPE が小さなオブジェクトの 場合、new TYPE において、メモリブロックのヘッダ部分を配列と同じ構造にしてしまうの は、結構、メモリの無駄使いにはなる。ただし、それもC#なんかの無駄と比べれば すずめの涙程度の全然問題ない程度のものではある。しかし、それだけ、C++が効率が 良いはずではある。 >>732 new はランタイムの処理だ。 同じメモリプールから切り出してくるならどちらにせよ大きさの管理は必要で、 コンパイル時に型が (すなわち必要なバイトサイズが) わかっているからといって、 それで効率的にはなる余地はあんまりあるとは思えんな。 >>733 要素数が正確にわからないと、デストラクタを呼び出す回数が分からない。 >>735 生のメモリブロックも、大きさは管理されているといえばされているんだけど、 理由は分からないけど、サイズを取得するための _msize(ptr) が存在しない ライブラリがある。あと、TYPE が小さい場合、アラインの問題もあって、 MBのサイズがTYPE が2個以上入ってしまうようになってしまう場合も有り得て、 要素数を計算する再にその場合の処理を適切にしないといけない。 恐らく出来ないわけではないはずなんだけど、そういう変な事情も 考慮して元祖の C++ は設計されたんじゃないかな。 日本で最も使いやすい無料レンタルサーバーといえば、xrea だろう。 しかし、bit defender traffic light は、「黄色ランプ」になる。 これも、日本人に対するいじめの一環と考えられよう。 一応の理由としては、xrea で設置されていたバナー広告が過去に マルウェア感染していた事があるかららしい。 いずれも日本で最も使いやすかったり普及していたり、日本人にとっては 最も重要なものばかりだ。 スマートポインタを返す関数?について質問です Smp<Foo> f = foo(); // こういうのがあるとき if (foo()->bar) {} // こういうのとか handle h = foo()->handle; // こういうのは安全なんですか? または、スマポのデストラクタが動く瞬間はいつですか? >>740 uniequ_ptr/shared_ptrはチェックしない ただ、operator bool()を持ってるから取得してすぐチェックしてやれば以降は安全 デストラクタが呼ばれるのは寿命が尽きるとき 1番上の例はfのスコープの終わり、下2つはその行の終わり operator bool()について勉強になりました if (f = foo() && f->bar) {} こういう書き方にすればnull関係のチェックとなるというわけですね > 下2つはその行の終わり なるほどですね、実はそれを恐れていましたw あほっぽいですが->barする直前にもしやデストラクタ動く?と怯えました ありがとうございます >>743 ifの場合はその後に続く{}の終わりまで延長する、一応 >>743 最新の C++ (C++17) なら if(auto f=foo(); f && f->bar) {} というように初期化と条件式をセミコロンで区切った書き方もできる。 ここで宣言した変数は if 文全体の終わりがスコープの終わりになるので、 範囲が限定的、かつ、スコープの終わりがわかりやすいので、 積極的に活用したいところ。 >>716 変数を使う直前に宣言するのは、 今では C でも望ましいスタイルだと思う。 今までは構文の都合でconstであるべき変数もconstにできないことがあったが↓↓↓、 char c; while ((c = *(p++), (c != '\0' && isprint(c))) { /*...*/ } // 以下変数cを使わないコード これからはconstにできる↓↓↓やたー! while (const char c = *(p++); (c != '\0' && isprint(c))) { /*...*/ } もうfor文とかも見境無し! for (int i = 0; const char c = str[i]; c != '\0'; i++) { /*...*/ } すばらしい…! shared_ptrじゃなくてunique_ptrじゃないとだめなときってあるの? 基本sharedでいいけどリソース節約したいところではuniqueって感じ? shared_future, shaed_mutex を使い分けるポイントって何でしょうか? 基本uniqueで、いろんな所に取り回したいのがsharedかな 所有者がはっきりしてればunique、パタパタ受け渡したり色んなので共有するならsharedが自分の基準 c++のデスクトップアプリケーションをVS2017で作ろうと思うのですが、フォームデザイナーはないのでしょうか? ボタンの位置などは全部コードで作る感じでしょうか? >>757 リソースエディタ、ダイアログエディタがそれに該当する。Win32のリソース参照。 リソースエディタでダイアログを作って、DialogBoxまたはCreateDialog系の関数でダイアログを作成できる。 ↑mfcというのは今はあまり使われないそうですが、c++でインターフェースを作る場合、 今どきは何が使われるんでしょうか? ある程度いい見た目にするのなら、自作しなければいけない感じですか? >>761 wxWidgetとGTK3がオススメ。キャリアがほしけりゃ、Win32なんか窓から捨ててしまえ。 >>761 Visual studioでは標準的 ただマイクロソフトから見切られているので今後の発展は無い 最近ならQtが人気 初心者には取っつきづらいのと日本語情報がほとんど無いのとライセンスがちょっと厳しいのとVSで完結させることはできないが移植性が高くガンガン更新されているから将来性は一番ある 今時なデザインにしたいならQt内で独自言語のQMLを使ってつくるかWebEngineをつかってhtmlとjavascriptと連携させて作る必要がある どちらも簡単にはできないけど Qt5なんてダウンロードに数十分かかるアホなビッグシステム。 使いもしないオプションを付けて時間がかかるとか言ってる人がいるってマジ? >>756 htmlやcssはできるので調べてみます もしかしてc++って個人で使うようなものではなかったりしますか? >>773 目的によるだろうね 個人でC++を使ってる人の大半はC++を使うこと自体が半ば目的化していると思う 自尊心と中二心をくすぐる言語だから 間違いなく C++ に出来ることは多いのだが、 要はそこまで必要な場合ってそんなに多くないでしょって話。 画像処理とか仮想通貨マイニングみたいな性能のチューニングがギリギリまで必要ってのなら C++ を使う甲斐があるけど、 GUI を記述するのに C++ を使うのはそれほど強い必然性はない。 本来の処理をする部分が C++ で書かれているなら、 あえて GUI だけ別言語にする必要もないなっていう程度のことだと思う。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる