[過去ﾛｸﾞ] C++相談室 part165 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
6(1): デフォルトの名無しさん (ｱｳｱｳｳｰ Sad5-U1R4) [sage] 2023/10/31(火) 16:49:04.12 ID:Xd7Dooyma(1) AAS
>>3ヘッダーの最後の行の #endif みたいなものだよ
117: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 823e-OTTg) [sage] 2024/01/01(月) 05:30:52.12 ID:hmX3WjmM0(3/4) AAS
>>116116(1): デフォルトの名無しさん (ﾜｯﾁｮｲ d24b-WshQ) [] 2024/01/01(月) 04:55:26.71 ID:e5pnn2Xx0(1) AAS
アライメントは基本型のどれかと同じアライメント制約に合わせれば良いいということなら
使おうとしているうちで最も厳しいアライメント制約に一致する基本型を含むunionで解決するというのがC言語における伝統的な手法という印象、
C++でunionにしたら（それが可能なメンバのみなら） memcpyは安全とかにはならない？
コンストラクタや代入演算子がトリビアルであることなどの制約を守れば共用体も trivially copyable になりうる。
(C++ の共用体はコンストラクタやメンバ関数を定義できるがそこらが制限されることになる。)
124(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 9901-r6/T) [sage] 2024/01/04(木) 09:11:56.12 ID:/FDyuY0i0(2/3) AAS
A::base_に以下を足してA::derived_で実装し
Aのコピーコンストラクタから呼べば?
virtual base_ *clone (void *p) = 0;
288: デフォルトの名無しさん (ﾜｯﾁｮｲ cfcf-sYtR) [sage] 2024/02/18(日) 09:41:50.12 ID:WHoJTRhT0(1/2) AAS
>>285>例外の種類しか頭にないのか
>>283283(5): デフォルトの名無しさん (ﾜｯﾁｮｲ 1e85-XyAm) [] 2024/02/17(土) 23:18:00.46 ID:v62CV0mD0(1) AAS
>>278
> そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
> どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに
それは幻想
c++の例外安全の達成がどれだけ難しいか理解していないね
簡単にリークするし、オブジェクトが想定外の状態を持ったりする
動作保証ができない
だから仕様に明示されていない例外が来たら基本は終了だよ
そのまま継続してそれが原因でその後別の場所で落ちられたら無駄な調査の手間が増えるだけ
が仕様に明示されていない例外を話題にしているからだが。
>任意の場所での例外発生に対応するなん現実的にできないということ
これはどういう意味なんだろうな。
着目するのは自分が呼び出している処理から上がってくる例外に対して例外安全かどうかであって
それは基本的に局所的に判断できるもの。
下層の、例外が通過してきた処理が例外安全な実装になっているかどうかってのはそっちの責務。
390: デフォルトの名無しさん (ﾜｯﾁｮｲ a94a-ImVy) [] 2024/08/04(日) 14:50:32.12 ID:ao1w9dwD0(1) AAS
それはラムダ式を使う理由とズレてるな
A側で判定が必要なものならラムダ式の引数もしくはfuncAの引数で渡すべき
A側は受け取るものを「intをひとつ受け取ってvoidを出力する関数」として抽象化してるんだから、それ以外のことは知れないし、知るべきではない
Aは渡された関数が何であろうとintを一つ渡すだけで、その詳細 (関数がどのような値や参照をキャプチャしてるのか、渡した引数がどのように使われるのか) には触れられない
ラムダ式を使うのはこのような抽象化が目的のはずだから、キャプチャした値を知りたいというのは用途から外れるかと思う
458: デフォルトの名無しさん (ﾜｯﾁｮｲ 1ede-2PHd) [] 2024/09/11(水) 12:14:54.12 ID:n6/LwjNL0(1/3) AAS
(*this)
↑
自己参照
464: デフォルトの名無しさん (ｱｳｱｳｴｰ Sadf-N1Zj) [sage] 2024/09/17(火) 12:59:42.12 ID:TMGdiCOOa(1) AAS
それならオブジェクトを保持するためのオブジェクトと
moveためだけのインデックスを分けるかな
815(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 4202-rYal) [!donguri] 2025/03/27(木) 14:55:01.12 ID:OeqyroTj0(1) AAS
>>812過疎ってきてるし
C++とmakeは連動すること多いから
話題はあってもいいんじゃねーかと
書き込んでみるテスト
960: 青木康善 (ﾜｯﾁｮｲ 8a72-0ulL) [sage] 2025/04/23(水) 17:25:43.12 ID:4FkXeR/00(1) AAS
アドバイスありがとうございます。駿台電子のネットワークの先生が昔、あらゆるプログラミング言語の中で一番、処理が早いのはC++だと言っていたので、頑張ります。
996: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ b732-jewZ) [sage] 2025/04/27(日) 17:44:14.12 ID:0aN/b0Iq0(1) AAS
ダイクストラが言う構造化プログラミングはモジュールとか抽象データ型とかも含む広範で抽象的な概念として説明されている。
連接・分岐・反復で構成しようという話はそれより前に発表されたものだが、この時代は構造化もクソもないプログラムがまかり通っていたという前提がある。
まずはその三要素を基礎に据えて構成したらわかりやすくね？ という提案 (というか感想？) に過ぎず、それで全て事足りるみたいな主張ではない。
(理論上は連接・分岐・反復で全て表現可能であるという証明はされている。)
構造化プログラミングの考え方のキモは構造は人間の認知の中にあるということ。
人間が思考しているときの構造を書き表すためにどんな言語機能 (またはデザインパターン) があればよいの？ ってのが構造化プログラミングの議論なんだよ。
書いた人が思ってる構造が表現されているなら構造化プログラミングだし、構造化プログラミングのために用意された機能を使っていても構造が表れていなければ構造化プログラミングではない。
まあついでに言えば書き表されたものについて (コンパイラも人間も) 検証しやすいことも大事だ。
機械的に goto を除去したらむしろ構造が失われるという例をクヌースが出したりもしていて、結局のところはどんな機能も正しく使えば正しいし、悪い使い方をすれば駄目になるというシンプルな話。
そんなわけで break が構造化を崩すか崩さないかは使い方による。
ただ、常識的に考えて break は goto より構造を破綻させにくいだろうってだけ。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.038s