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

◆QZaw55cn4c (ﾜｯﾁｮｲ ba60-Mp6C) · 2018/04/24(火) 19:42:04.62

>>289
私は書き始めは std::vector を専ら使っており、後で他のコンテナに換えています

2018/04/24(火) 19:46:25.46

>>293
コード読めないの？

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdba-gnn3) · 2018/04/24(火) 19:51:37.43

>>296
普通の人間なら、文脈を読み取れるけど、俺はコンピューターに近いんだ。

2018/04/24(火) 20:04:19.79

>>289
実用上の問題が無いことがわかっている範囲内であれば、
深く考えずに vector だけで乗り切るのも悪い選択じゃないと思うよ。

ただ、使い分けることで意図を表現しやすい。

たとえば list を使っていれば要素の挿入や削除が頻繁なデータなんだなって思うし、
array が使われていれば要素の個数が固定なんだなって思う。
速度的に影響がない程度の規模であっても、
それが適しているような操作をこれからするのだという意思表明は人間がプログラムを読むときのヒントになる。

そして、そういうヒントは書いている途中にこそ必要なものなので、 >>295 のように後から整理していくスタイルは個人的には好きじゃないな。

◆QZaw55cn4c (ﾜｯﾁｮｲ ba60-Mp6C) · 2018/04/24(火) 20:22:55.46

>>298
＞それが適しているような操作をこれからするのだ

うーむ、いろいろと考えさせられます
std::vector でなら使えても、std::list では使えない、というのはあるから、最初からそれを考慮しておくのは…よくありますねえ

2018/04/24(火) 20:43:20.11

vector は list に比べた場合、

データがメモリ上隣接して並んでいるので
→そういう引数を要する各種 API にそのまま渡せる
→メモリアクセスが局所的にできてキャッシュが効く

予約領域を拡張する場合にのみアロケータが呼ばれるので追加時のアロケータによるオーバーヘッドが低い

とかの良い特性もあるので要素のコピーが軽くて個数が小さいものはvectorにして損することは少ない

2018/04/24(火) 21:34:54.87

BidirectionalIteratorとRandomAccessIteratorだろ
規格用語で言えば短く済む

2018/04/24(火) 22:35:44.34

std::listはメモリ局所性がないので今どきのマシンだとクソ遅い
積極的に使う理由は基本的にない

2018/04/24(火) 23:33:49.11

積極的にって...
使いどころで使うための物だよ

2018/04/24(火) 23:51:07.95

メリットとデメリットを見極められないとコンテナを使いこなすのは難しい
昔から配列を弄り倒している古参にとってはこんなに便利な物はないと思うがね
90年初頭辺りにタイムスリップして実際に構造を真似てフルスクラッチでテンプレートなんぞなかった世界で組んでみればコンテナの挙動は自ずと理解できると思うが時代がわるかったな
今は何も苦労しなくても容易になんでも手に入る世界だからな
修業が足らんよ青二才

2018/04/24(火) 23:55:55.63

>>303
その使い所がよほど特殊な状況以外にないんだよ

2018/04/24(火) 23:58:59.30

大規模C++ソフトウェアデザインという本を読んでいます。

冗長インクルードガードが紹介されているのですが、効果あるんですかね。

古めの本なのですが、最近のコンパイラだと意味ないですかね

**>>306** (ﾜｯﾁｮｲ e3b3-9jjH) · 2018/04/25(水) 00:13:26.67

http://ir9.jp/prog/ayu/datlog/tech_cpp/1149427282/1149427282_04.html

ここの967以降に同じ質問がありました。質問撤回します。

2018/04/25(水) 00:14:20.28

#pragma once　って規格化されたんだっけ？

2018/04/25(水) 01:03:31.17

されてない
しようしようと20年言われ続けて技術的な問題でできずにいる

2018/04/25(水) 02:07:21.83

243です。
アドバイスを頂き検討したのですが、メモリが散らかっているのが原因と判断しました。
都合により細々とした実装の話は割愛しますが、付き合ってくれた皆さんありがとうございました。

2018/04/25(水) 02:33:10.54

どおりで未だに警告でるわけだ

2018/04/25(水) 06:26:59.61

>>305
その特殊な状況の為にlistが存在する

私の場合は特殊なプログラムを書くことが多いので
使いどころは多いのかもしれない

また、普通の組み込みC言語でも簡易な片方向リストとかを使ったりする (C++じゃないのでlistは無い)

2018/04/25(水) 07:15:49.01

>>309
技術的な問題ってなに？
既に実装してる環境の方が多くね？

2018/04/25(水) 07:30:39.44

今はモジュールの方を標準化しようとしてるんじゃ

2018/04/25(水) 08:47:25.49

偉い人が考えてることはわからん

2018/04/25(水) 11:24:32.26

>>313
プリプロセッサは C++ じゃないからね
C++ 以外の言語と共有しているツールなので
それらと歩調を合わせる必要があるし
プリプロセッサだけ独立の規格にするなら
C++ を含め、諸言語の規格も
プリプロセッサのバージョンとどう付き合うのか
策定せにゃならん

2018/04/25(水) 12:23:57.05

>>316
意味わからん
C/C++の規格にプリプロセッサの仕様もあることを知らんのか？
そもそも他の言語と共有してる環境なんて見たことないし

2018/04/25(水) 15:37:25.53

現行では、 #include ディレクティブは「対象ファイルの内容がそこに書かれているかのようにふるまう」という規則なので、
ヘッダファイル内のプラグマ (#pragma once) の解釈が始まるのはインクルードされた後になる。
もちろん対象範囲がコンパイル単位全体に及んでしまっては #pragma once の意味がないが、
現状の仕様に辻褄を合わせるとそうなる。

実装した処理系がもうあるんだから実装に沿うように規定しなおすってことはできなくは無いんだろうが、
#pragma once を仕様に入れるのに #pragma once の項目を追加すれば済むわけではないってことは理解してくれ。

それと、プリプロセッサの仕様は C/C++ の一部なのは確かだが、
挙動を規定しきれていないのじゃないかということは指摘されている。
https://qiita.com/ruiu/items/4d471216b71ab48d8b74#3%E6%9C%8817%E6%97%A5
うやむやでやってきてるところを整理する必要は有ると思う。

>>317
Haskell (GHC) は C プリプロセッサを使うよ。
汎用的に使いたいなら M4 とかの方がいいとは思うけど、
Cプリプロセッサに慣れている人は多いから……。

2018/04/25(水) 16:38:46.53

また別な話
#includeしようとしているファイルが
過去に#includeしたファイルと同一かどうか
という判定も意外に厄介だね
ハードリンクできるファイルシステムと
そうでないファイルシステムがあったりするし
ハッシュが一致しても衝突かどうかの問題もある

2018/04/25(水) 18:09:25.23

ハードリンク、シンボリックリンクが無いファイルシステムだったとしても、サーチパスの問題も思いつくな。

たとえばカレントディレクトリと、カレントディレクトリ直下の foo ディレクトリからヘッダファイルを探すようになっているとき、

#include "bar.h"

と

#include "foo/bar.h"

は同じファイルを指しているが、表現が異なる。
同一のファイルとして除去すべきだろうか？

2018/04/25(水) 19:34:37.54

#if ****
#pragma once
#endif

とかどうなるの？
複数回のインクルードで条件がちがっていたら？

2018/04/25(水) 20:33:35.69

>>318
> 実装した処理系がもうあるんだから実装に沿うように規定しなおすってことはできなくは無いんだろうが、
規定すればいいだけだろ？
どこに技術的な問題があるんだ？
政治的な問題だと言うならまだしも
>>319-320みたいな話は処理系定義ですむ話
>>321は少し悩ましいがそもそも途中まで読んでから#pragma onceとか言われても面倒だから書くならファイルの最初に書けとかの制限をつければいい

> 挙動を規定しきれていないのじゃないかということは指摘されている。
いやいや、その子ちゃんと規格読めてないだけでしょ w

> Haskell (GHC) は C プリプロセッサを使うよ。
仕様を流用してるだけでしょ？
何かのコンパイラと共有してるわけじゃないと思うが

2018/04/25(水) 20:43:06.43

君よりよっぽど賢い人達が20年間悩み続けて未だに出来てないことを舐めない方がいい

2018/04/25(水) 21:22:23.29

>>323
別に悩み続けてなんていないでしょ w
#pragma onceで事足りてるからわざわざ政治的なことに足突っ込みたくないだけ

2018/04/25(水) 21:47:31.85

新規格の季節になると毎回のように標準化委員会の議題に上がってるんだが？

2018/04/25(水) 22:20:34.77

モジュール方式になったらヘッダファイルが要らなくなる？

2018/04/25(水) 22:28:42.99

>>322
> 処理系定義ですむ話

それはおかしいでしょ
ハードリンクできる処理系からできない処理系に移植したtarボールの
#includeの挙動が未規定なら結局インクルードガードを自前で書くことになる

2018/04/25(水) 22:48:43.95

>>325
でも誰も進めようとしないんだろ w
よくある話

>>327
C/C++ ってそういう言語だしそもそも環境変える予定があるならそんなものに依存したファイル構成にしないでしょ

2018/04/25(水) 22:55:12.61

#pragma once なんて
once upon a time だぜ
今はもうだれも気に留めてやしねぇ

2018/04/25(水) 23:31:56.94

アホの相手は疲れたわ
もう寝る

2018/04/25(水) 23:46:14.09

>>322
トピックとして大きすぎるので面倒くせえってだけの話。

2018/04/25(水) 23:50:29.61

#pragma once
ぐらいPerlでインクルードガードに自動変換できる、
ていうか無くてもできるから自前で書くとかありえん…

2018/04/25(水) 23:51:29.73

むしろプリコンパイルヘッダーが規格化されないの方のが悩ましい…

2018/04/25(水) 23:58:40.94

>>330
逃げるなら黙って逃げろよ w

2018/04/26(木) 00:10:34.39

ていうか#pragma onceとか#ifdef～#endifによるインクル～ドガ～ドのシノニム以外の何者でもないと思うが
一方#ifdef～#endifによるインクル～ドガ～ドは
「対象ファイルの内容がそこに書かれているかのようにふるまう」
という規則の下で立派に機能していると思うし、

>>321のように等価な#ifdef～#endifによるインクル～ドガ～ドが存在し得ない場合はエラーにしたら良いと思うし、

ハードリンクできる処理系かどうかに関係なく#ifdef～#endifによるインクル～ドガ～ドは機能していると思うし
（だいたい1バイナリのビルド中にハードリンクの中身が変わるみたいな想定をする方がおかしい＝ハードリンクはそうでないファイルと区別がつかないとみなせるﾊｽﾞ

だったら#pragma onceも問題なく規格化が可能なのでは…
少なくとも技術的な問題とかとうていナッシング？

2018/04/26(木) 00:21:25.86

ちょっとはググれよ。
お前みたいなやつを「殆し」って言うんだぜ

2018/04/26(木) 00:41:00.06

↑ググってもボンクラが書いたような駄文が見つかるだけなので却下。

1. #pragma onceは#ifdef～#endifによるインクル～ドガ～ドのシノニムである

2. #ifdef～#endifによるインクル～ドガ～ドは世の中で立派に機能を果たしている

にもかかわらず、

3. #pragma onceの規格化の有効な解が存在しない

という驚くべき結論がなぜ導かれるのやろうか…

2018/04/26(木) 06:29:49.76

インクルードガードを自前で書くたびに
毎度毎度ワンパターンでタイプ数だけは結構多い不毛な作業は
機械化できないかと考えるのは至極当然
むしろ何の疑問も持たないやつは適性に疑問符がつく

インクルードガード用のフラグマクロの命名則にも不安がつきまとい
無名namespaceのように衝突しない保証があったらなあと思ったりもする

2018/04/26(木) 07:22:21.59

要するに同じファイルであるかをどうやって判定するかの問題
インクルードガードは利用者（プログラマー）に識別子を決めさせる（押し付けたとも言う）ことで実現してる
なので押し付けられたプログラマーには
> インクルードガード用のフラグマクロの命名則にも不安がつきまとい
みたいなことが発生する
#pragma onceはこの判定を処理系側でやるんだが例えばファイルの絶対パスで判断するとかファイルをインクルードする前にmd5とかのハッシュを求めて判断するとかすればいいだけ
ハードリンクとかで違う名前つけて#pragma onceがうまく動かないとか言うアホとかは無視すればいいし、ハッシュの衝突が心配と言うなら衝突した時に比較するようにすればいい
どういう仕様がいいのかで揉めるのはあるけど技術的な問題とか言ってる奴はちょっと知能が足りなさすぎ

2018/04/26(木) 07:42:18.98

>>338 #ifndef 形式のインクルードガードを自前で書くとタイプ数が多いし
識別名を打ち間違える危険もあるから .h のファイルを新規作成したときに
自動的に入力されるようにエディタのマクロにしたよ。
まぁ、識別名をファイル名から作ってるから、ファイル名の変更でアレだけど。

昔(フロッピーでやってた時代?)は #ifndef 形式でガードすると
どのみちヘッダファイルをまるごと読み込まなきゃならないから、
#pragma once の方がコンパイル時間において優れてる、などと言ったけど、
ハッシュを計算して同一か検証するとか手間が増えるなら
時間の面での優位性はなくなったのかな。

2018/04/26(木) 09:45:48.32

「技術的な」というときの技術は「プログラミング技術」の意味じゃないこともあるんだよ。
前置きが無い限り広すぎてあんまり意味ない。
実装がいくつもあるのに、仕様策定にあたっての言葉で出てくる「技術的な」なんだから文脈でわかれよ。
仕様に落とし込む難しさが元々の論点。

ハードリンクの話題は「同一のファイルとは何か」を定義する難しさの一例で、実装のことなんか言ってない。

このスレで既に上がっている選択肢だけでも

　・内容が同じ
　・絶対パスが同じ
　・ #include ディレクティブ中の表現が同じ
　・ inode が同じ (ハードリンクは同一とみなす)

があり、内容の一致を選択する場合以外は言語の外の世界の環境に関する記述が必要になる。
世の中にある色んな環境のことを考慮して文面にする難しさってのはわかるだろ？

そんなわけで、個人的には内容の一致だけで判定するのが (仕様として定義するにあたって) 一番簡単だと思う。
ODR に関するルールの中にも同じトークン列を要求するものがあるし。

それに加えて >>318 で取り上げた展開手順の規則をなんとかする必要はあるが、 >>321 に解を与えるような上手い簡単な規則は思いつかないな。
既に多く書かれてしまっているコードの現状との互換性を考えると >>322 のいうような、
#pragma once を書ける場所を制限するような規則は選択できないと思う。
結局は複雑なものにならざるを得ない。

そんなのほっといてモジュールの導入に邁進しようぜっていうのは妥当な方針だろ。

2018/04/26(木) 11:12:45.83

>>339みたいに独善的なやつは標準化委員に向かないタイプだね
提起された問題を個人的に考えるのがイヤだから却下とかやってたら
みんなやる気なくすし

2018/04/26(木) 11:13:52.62

会社にもいるよね今の野党みたいなアイディアキラー

2018/04/26(木) 11:26:33.21

この板の別スレにも跳梁跋扈してるな

2018/04/26(木) 12:36:39.87

>>341
> 「技術的な」というときの技術は「プログラミング技術」の意味じゃないこともあるんだよ。
そういう人がいるからわざわざ「政治的」って言う言葉を入れてあるんだが理解できなかったのか？
で、あんたの言う技術的な問題ってなに？
具体的に書いてくれ

>>342
> >>339みたいに独善的なやつは標準化委員に向かないタイプだね
> 提起された問題を個人的に考えるのがイヤだから却下とかやってたら
意味わからん
俺が提示した内容がダメだと言うならもっといい案を提示すればいいだけ
こんなスレで独善的とか頭大丈夫？

2018/04/26(木) 13:01:09.90

提示してねえだろ、おまえは無視つったんだよ
嘘つくんじゃねえ

2018/04/26(木) 13:58:41.43

>>345
私はこの件について、技術的な問題があるとは述べてない。
その箇所の後に技術的という言葉は広範すぎて (言い換えれば、具体性がないので) 意味ないという意味のことを書いてるつもりなんだが。

それとは別に、私の考える問題を端的に言うと仕様の文面に落とし込むのは難しいねっていう、そんだけのこと。

2018/04/26(木) 14:09:35.01

相談スレであって要望スレじゃない

2018/04/26(木) 14:10:26.12

中身のないガキの言い合いは他で

◆QZaw55cn4c (ﾜｯﾁｮｲ 5360-c97c) · 2018/04/26(木) 17:50:46.60

>>348
現時点での問題点をはっきりさせることに意味はあると思いますよ…

2018/04/26(木) 17:56:28.00

>>346
理解できないなら絡んでくるなよ w
「アホな利用者は相手にしない（=無視する）」って言う仕様を「提示」してるって話だ、ボケ

2018/04/26(木) 18:15:04.17

>>350
スレチ
意味があると思うなら他にスレ立ててやれ

2018/04/26(木) 18:20:39.64

>>351
科学技術的な議論にアホなんて用語を使うあたりお里が知れるな
形容詞には比較基準や単位をつけろボケ

2018/04/26(木) 19:18:47.48

ガキの喧嘩は他でやれ

2018/04/26(木) 19:29:11.00

俺は>>339が正しいと思うぜ。
というか>>341は明確に間違ってるだろ。色々と。

「ハードリンクガー」なんてのは論外。規格で定めるべき事項ではない。
規格で定めるべきなのは、

・全く同一の中身だが実体が異なる場合でも #pragma once は有効か？
(cp A.h B.h　の場合にも B を読み込むか？)

だ。そしてこれは当然現行のインクルードガードと同じ方向に揃えるべきであり、

・読み込んではいけない

という仕様になるのも自明だ。
絶対パスやinodeやハードリンクというのは、

・通常のファイルシステムであれば、絶対パスが同一なら同じファイルを参照する
（＝同じ中身であることが保証される）
・inodeでファイルシステムが実装されているのなら、
同じinodeを指すファイル（＝ハードリンク）の場合には、同じ実体を参照する
（＝同じ中身であることが保証される）

であって、これらは「全く同一の中身」であることを確認する手段でしかない。
これらが有効な環境では間引くのに用いればいいだけ。勿論ハッシュを使ってもいい。
これらが別物に見えるのなら、それは抽象思考が出来ない馬鹿だからだよ。
ファイルシステム毎にC++の規格をいちいち決め直す必要があるなんて、おかしいだろ。
今後新しいファイルシステムが考案される毎に、毎回C++の規格を刷新するつもりか？
例えばWindowsでは同一ドライブに複数のドライブレターを割り当てることが出来るが、
それでどうなるかをC++の規格に定めるべきだと？マジで馬鹿だろ。

2018/04/26(木) 19:29:59.32

最終的に規格に定めるのはつまり、

・全く同一の中身の場合には #pragma once は有効
（＝現行のincludeガードと同様)

であって、揉めるとしたら、

・意味的には同一だがバイナリ比較では異なる場合
(例：最終行に空白や改行が追加された場合や、コメントのみの変更の場合)
（＝現行のincludeガードでは読み込まれないが、単純な方法では同一性の確認が難しい場合)

だが、これも方向としては現行のインクルードガードと合わせる方向、つまり、

・読み込んではいけない

とされるべきであり、これもまた自明だ。
（とはいえここは実装的に揉めるかもしれんが）

そもそも「同一性の確認」をファイルシステムに依存する考え方自体がおかしい。
もうじき #include 対象を url 指定するような時代にもなるだろうし。
(善し悪しはさておき、PHPではこれが出来る)
そうしたら、「同一かどうかは中身で判断する」という選択肢以外はなくなる。
こんな当たり前の話が分からないのは完全に老害化してる。

2018/04/26(木) 19:30:31.24

そしてやる気がないのは今更意味がないからだろ。ほぼ全ての環境で実装済みだ。
> Cray C and C++ 以外では全て実装済み
> https://en.wikipedia.org/wiki/Pragma_once

勿論糞長いパスとかにしたらはまることもあるが、これもよくある話でしかないし、ユーザ責任でいい。
規格に「パスは○○文字まで」と決めるわけにも行かんし。
> 途中でバッサリとパスが切られて、まったく同じシンボル名になって、
> 初めてincludeしたファイルなのにスキップされるという、
> なかなか原因解明が困難な不具合に襲われる……といったケースがあるかもしれません。
> ……はい、体験談です。
> http://cpp.aquariuscode.com/include_guard

2018/04/26(木) 19:39:23.16

二重にインクルードすることを想定しているヘッダーファイルって、存在するものなの？
pragmaとか書かなくても、勝手にやってくれたら問題あるの？

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdb3-L0fA) · 2018/04/26(木) 19:43:43.54

>>358
<pshpack?.h>
<poppack.h>

◆QZaw55cn4c (ﾜｯﾁｮｲ 5360-c97c) · 2018/04/26(木) 19:56:21.41

>>355
要旨が混乱していますね

＞例えばWindowsでは同一ドライブに複数のドライブレターを割り当てることが出来る

つまり、今読み込んでいるヘッダファイルがかつて読んだファイルと同じ実体かどうか、を決める方法は**基本的にない**と主張しているのですよね
そう主張するのなら、

＞・読み込んではいけない
＞という仕様になるのも自明だ。

「読み込んでいいかどうか」を決める方法がないのに「読み込んではいけない」と決めていいのですか？
条件を満たすかどうかチェックする手段がないのに、その条件を仕様とするのは無意味ではないですか？

2018/04/26(木) 19:59:02.73

>>358
たくさん存在する。
インクルードする前後のマクロ定義によって挙動を切り替えて使うようなものもある。
基本としては宣言というか、別のコンパイル単位にある関数などのインターフェイスを取り込むために使うものなんだけど、
アクロバティックな使い方をしてるものはそれなりに多いよ。

2018/04/26(木) 20:06:45.74

プリプロでループを実現するには再帰includeは欠かせないからな

2018/04/26(木) 20:08:29.05

>>361
むしろそっちのほうに、
二重インクルード可能みたいな宣言を用意してほしいわ

2018/04/26(木) 20:24:45.91

>>360
マジで言ってるんなら死ね。
俺の意見は、

・#pragma once は現行のインクルードガードと同じ方向に仕様化すべき

であって、実際これで文句が出ることはないし、妥当だろ。
つかお前、>>340を理解してるか？

2018/04/26(木) 20:34:58.75

int lengthOfLcs_r(const char x[], const char y[], int ix, int iy, int xsize, int ysize) {
static int **lengthTable = new int*[xsize];
for (int i = 0; i < xsize; ++i) {
lengthTable[i] = new int[ysize];
}

if (ix == xsize || iy == ysize) {
return 0;
}
if (x[ix] == y[iy]) {
return lengthOfLcs_r(x, y, ix + 1, iy + 1, xsize, ysize) + 1;
}
return max(lengthOfLcs_r(x, y, ix, iy + 1, xsize, ysize), lengthOfLcs_r(x, y, ix + 1, iy, xsize, ysize));
}

2018/04/26(木) 20:36:08.64

#include "/dev/tty" も知らない雑魚はもう黙ってろよ

2018/04/26(木) 20:37:18.41

>>365

の関数は、再帰的な関数です。

その再帰的な関数内で static な配列を利用したいのですが、動的に確保した
領域を解放するにはどうすればいいのでしょうか？

再帰的な関数なので単純に関数の最後で解放するというわけにはいかないので
困っています。

2018/04/26(木) 20:39:18.48

>>365

動的計画法で配列に計算結果を記録しておき利用したいんです。
なので static にしています。

◆QZaw55cn4c (ﾜｯﾁｮｲ 5360-c97c) · 2018/04/26(木) 20:39:31.36

>>364
わけて考えてみますね
インクルードガードはプリプロセッサ名前空間内の一つのプリプロ識別子を犠牲にして、機能させようとしているわけですよね
#progma once が犠牲にする**べき**ものは何でしょうか？

2018/04/26(木) 20:40:15.50

>>365

の関数はまだ書きかけなので、計算結果を記録した配列の値はまだ利用していません。

2018/04/26(木) 20:43:55.37

>>>365
lengthTableのポインタ値をなんとかしてグローバル変数に持ち出してatexitに登録するか
最初からそのグローバル変数でnewするか
どうせプログラム終了時にヒープ丸ごと消えるんだから放置するか
一から書き直すかの4択

2018/04/26(木) 20:45:16.69

>>365

あ、すみません。

なんかおかしなことを書いてしまいました。

2018/04/26(木) 20:53:11.22

>>371

ありがとうございました。

すみません。質問がちょっとおかしかったので、質問を代えさせていただきます。

ある特定の関数内でしか見えないグローバル変数のような変数というのはC++にありますか？

考えているのは、関数 func でそのグローバル変数のような変数 a を宣言する。
func 内で呼び出している再帰関数 rec_func 内でのみそのグローバル変数のような
変数 a を利用したい。グローバル変数のような変数なので、 rec_func の引数として
a を渡す必要はない。

2018/04/26(木) 20:57:03.80

何度も呼び出される再帰関数に引数として同じ変数を渡し続けるのはなんか
無駄なことをしているように思われたので質問しました。

本を読むとグローバル変数は使うなと書いてあるので質問しました。

2018/04/26(木) 21:01:32.17

>>373
でいう変数 a の代わりに、クラスを作って、メンバ変数を利用すればいいですかね？

rec_func はメンバ関数にすればいいですかね？

2018/04/26(木) 21:03:04.18

でも、そのためだけにクラスを作るというのもなんだかな―という感じがします。

2018/04/26(木) 21:06:11.37

>>360
一応添削しておくと、

> 今読み込んでいるヘッダファイルがかつて読んだファイルと同じ実体かどうか、を決める方法は**基本的にない**
× 同じ実体かどうか、を決める方法は
○ 同じ実体かどうか、をパス等で決める方法は

ただし俺はそもそも「中身」を見て確認すべきで、同じ実体だったら云々、という話はしてない。
cp A.h B.h の場合にインクルードガードでBを弾くとして、
当然Bは「ファイルとしては」「読み込まれ」、「コンパイル対象としては」「読み込まれない」だろ。
#pragma once はインクルードガードの自動版なんだから、インクルードガードと同じ仕様でいいんだよ。
そして逆に、実体が異なっていてもこの場合はインクルードガードは利くのだから、#pragma once も利くべきなんだよ。
ファイルパスでの識別ではこれは実現不可能だろ。

>>369
意味不明。何も犠牲にするべき物は無いと思うが。
というかな、規格化するなら方向は自明で、

・#pragma once はインクルードガードの代わりに使われているのだから、
現行のインクルードガードを機械的に #pragma once に置き換えして問題ないように仕様化すべき

でしかないだろ。これで誰も文句ないと思うが。

2018/04/26(木) 21:07:21.99

>>374の心配があるんだったらクラスにしたって裏でthis渡すようになるだけだから一緒よ
ポインタ渡すコストが気になるならグローバル変数にするしかない

>>365のコードのままなら末尾再帰の最適化かかるだろうから問題にならんと思うけどな

2018/04/26(木) 21:07:30.49

クラスを作ってそのプライベートなメンバ変数を、
ある関数内でのみ利用できるグローバル変数の
ような変数として使うというのは邪道でしょうか？

2018/04/26(木) 21:08:37.69

>>378

ありがとうございました。

2018/04/26(木) 21:51:10.65

>>373
> ある特定の関数内でしか見えないグローバル変数のような変数というのはC++にありますか？
見た目だけの話ならラムダでキャプチャすればいい。(クロージャ）

ただ、今気づいたが、C++のラムダって名前付けられないから再帰できないね。
変数の直接呼び出しも試してみたが、以下は通らない。

auto f = [](int x) {return x? x+f(x-1) : x;};

なんでこんな糞仕様にしたんだ？
JavaScriptも当初はそうだったが、不便だったので名前が付けられるように変更した。
この変更を知ってて無視してるのなら頭おかしいし、
知らないのなら不勉強だし。（言語仕様に携わる奴は他言語の動向も見ておくべき）
名前を付けられて悪いことはないし、技術的に不可能って事も無いと思うが。

2018/04/26(木) 22:07:02.86

ID:4xU9Va0kM=ID:HtO+dzj70

#include "X:\sandbox\aho.h"
#include "Y:\sandbox\aho.h"
これでどうなるかをC++の規格に定めるべきだと言っているのはおまえだけ

//X:\sandbox\some_app.cpp
#include "aho.h"
#include "some_lib.h"

//Y:\sandbox\some_lib.h
#include "aho.h"

おまえq文字列の解釈をまさか知らんのか？

2018/04/26(木) 22:34:27.88

>>353
反論されてぐうの音もでないのかよ
５チャンは初めてか？ w

2018/04/26(木) 22:35:24.34

>>383
全文そのまま返すわ

2018/04/26(木) 22:41:09.16

同じファイル
同じ中身

大きく分けて2種類あり、
それぞれ、同じの定義の詳細は色々と考えられる

2018/04/26(木) 22:45:45.22

>>382
> ID:4xU9Va0kM=ID:HtO+dzj70
勝手にアホな認定するんじゃねーよ
そもそも俺はハードリンクとかのファイルシステム依存の話は処理系依存にした方がいいって思う

2018/04/26(木) 22:46:56.42

>>384
人を嘘つき呼ばわりして謝ることもできない奴がなに言ってるんだよ w

2018/04/26(木) 23:09:17.34

効いてる効いてるｗ
嘘つき呼ばわりじゃなく嘘つきという真実を指摘されてファビョーンかよ
おまえは考察自体を放棄した
この事実はどうにもならない

2018/04/26(木) 23:12:02.64

>>381
自己レス。
すいません出来ました。以下通ります。autoは無理のようです。

std::function<int (int)> f = [&f](int x) {return x? x+f(x-1) : x;};

>>373
見た目だけなら、上記のようにラムダで再帰すれば書ける。

2018/04/26(木) 23:58:27.23

またいつもの奴が暴れてるのか
相変わらず不毛な話してるな

2018/04/26(木) 23:59:44.22

それで結局#pragma onceが採用されてこなかった理由はなんなん？

2018/04/27(金) 00:09:03.41

所詮 pragma だから
この部分は処理系依存が強く出るので

2018/04/27(金) 00:18:29.43

>>388
>>351にまともな反論してから出直してこい w

2018/04/27(金) 00:25:32.85

https://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/YG76sfDJ4f8
http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0538r0.html

#pragma onceについて語りたい奴は必ず先に目を通すように
じゃないと上で騒いでる馬鹿みたいになっちゃうからな

**デフォルトの名無しさん** · 2018/04/27(金) 06:18:50.95

MSアレルギー