C++相談室 part153
■ このスレッドは過去ログ倉庫に格納されています
template <typename T>
using my_priority_queue = priority_queue<T, vector<T>, greater<T>>; gccの場合、未実装でもスタブだけ存在する場合があるんですよね。
つまり、コンパイル時やリンク時にはエラーにならない。
悪いことに実行時にもエラーにはならず、静かにスルーされる場合さえあるんです。
ここまでの流れでもお気づきでしょうが、gccの熱烈なファンは、gccが後れを取ることが許せないんですよ。
ですから、gccの熱烈なファンサイトより、GNUのマニュアルを見ることをお勧めします。
マニュアルを見れば、たいていは、きちんと書いてあります。 >>748
ここ以外に各コンパイラでの実装具合が上手い事まとまってるサイトとかあんの? コンパイラのサポート状況 (C++17) - cppreference.com
https://ja.cppreference.com/w/cpp/compiler_support/17
こっちでの表現は「初等文字列変換」になってんのか
分かるワケねーな >>746
N4713のpdfとかどこをどう漁れば出てくんだ?
全然見つからないんだけど >>755
N4713 c++で検索したらトップに出てきたぞ。
普段どんな検索しているんだよ。 https://github.com/cplusplus
ここで検索すればドラフトならみられますよ。
向こうも見てるだろうけど。 >>751
関係ないけれども、gcc って今は C++ で記述されているんですよね
長い間私はそれをとても残念に思っています
オプティマイズは苦手であってもいいから C で記述されている C++ 処理系って存在するのでしょうか? おーけーぐーぐるえぬよんなないちさん、と言いました。 行き着いた、ってのは>>746の彼がだよ
どういう経緯で彼が「これこそが勉強すべきドラフトである」と結論したんだ? 俺がN4713を見ていたことが、えらい気に入らない人がいるようだね
知らんがな
仮にwebページ見られなかったとして、どうやってN4713を落とせたのかとか
いちいち開陳せにゃならんの? >>722 >>725
差分プログラミングとかいう腐りきったプログラミングパラダイムでは
ハイディング上等なんだ、
そう思っていた時期が(ry こちらから見えるということは、向こうからも見えてるということです。
気を付けなされよ。 >>762
「ドラフトはこれを見ましょう」と大々的に紹介されてるわけでもなし、
落としたDLしたじゃなくて、どうしてそれを『選んだ』のかが不思議なんだよ
普通の経路じゃまず選べない c++ってやたうんちくばっか言う人多いよね
そんな人に限って仕事ができない
やたら得意げに説明してるけど、細かいことばっか気にしてて結局納期遅れwww
それなら、ある程度チャランポランでも納期通り出荷して、最悪現地デバッグの方がまだ救いようがある これの話の続きなのか
なら不思議は解消だ
謎は全部解けた
C++相談室 part151
https://mevius.5ch.net/test/read.cgi/tech/1589424805/20
20 名前:デフォルトの名無しさん[sage] 投稿日:2020/05/14(木) 18:32:35.87 ID:jF4/VTtK
>>17
ggrks
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf
あとcppreferenceはある意味ファンサイトみたいなものなので、何らかの標準化組織の公式サイトというわけじゃないよ >>766
こういうとこでの情報提供や議論はともかく、うんちくでマウント取りたがるのは自信の無さの裏返しだからねぇ うんちくがうっとおしくて、仕事なら自分が勝ってる!って思い込みたいだけなんじゃないの >>765
だから何?
俺がどのドラフトをDLするかを
いちいちあんたの承認とらにゃいかんの?
こっちゃ不思議がられても関係ないんで
いちいち申告してもらわなくていい 正式版は有料だがドラフトはタダで手に入るからヒジョーに得がたいが、
やっぱドラフトの内容は随時変わるから、
居丈高に相手を論破してなじり倒すにはやっぱ最新のドラフトでないとイマイチ、 よくわかりませんが、Chromeで実装されてるお試し機能がSafariで実装されてないからSafariはクソというのと似た話ですか? Chromeで実装されてるお試し機能がSafariで実装されてないからSafariはクソとなじったら
ドラフトの版が変わったらChromeの方がクソだった、みたいな ゴミみたいなやり合いだな
くだらな
建設的な議論ができんのか C++のプロジェクトに始めて関わって既存コード眺めてたんだけど、関数やメソッドを呼び出す時って、呼び出す側が結果を格納する箱となる変数とかポインタを渡して、
メソッドや関数は成功失敗のint値をreturnする書き方しているんだけど、
これってC++の書き方なの? >>786
まあその方がメモリ管理をミスを防ぎやすいからな
C++11以降だとまた世界が違うが >>788
スマートポインタが実用になったから、それでメモリ管理する方が文字通りスマートになった
だから、必要なら関数内部でメモリ確保する方法でもメモリ管理ミスが起こりにくい >>786
c++というかcの伝統だわな。
オブジェクトをヒープに置かなくていいという性能的なメリットもある。 Cだと不定長の配列やら文字列やら返す関数ひとつ作るだけで大事件だからなぁ
「いいですかー!この関数が返す配列はヒープ確保したものですよー!使い終わったらXXX__free()で解放してくださいよー!
解放忘れたらリークしますよー!!!絶対に最後に解放してくださいよー!忘れないでねー!絶っっっっっっ対に忘れないでねー!!!」
ってコメントやドキュメントやサンプルコードにしつこくしつこくしつこく書いて書いて書いて徹底的に注意喚起しないといけない
そして当然のように忘れられて「分かりにくい関数作りやがって」って叩かれる所までがお約束
vectorやstringをゴロッと返せば済む今はいい時代になったと思う 消費者が買い物袋用意するなんてレジ袋有料化みたいだな 質問@:
例えば…std::vectorで配列を確保したとします…push_backで追加した時に…アロケーター??が…
アドレスの再割当てをしたとします…この時…vectorは要素のアドレスは連続である事は保証されますが…
この時のアドレスの再割当てって…同期?非同期?どうなるの?
つまり…push_back時に同期で行うのか…非同期でロジック流れて行っちゃうか…って所…。
非同期だと怖いんだけど…。
質問A:
std::vector<char>とやった場合…data()でchar*を取れますが…std::vector<char>に'\0'の概念って
あります?どうなんでしょうねぇ…。'\0'のために+1多めに確保するなんて事はしないと思いますが…
どうなん?内部でどうなってるのかは…解りません…。 >>795
アロケータの内部実装がどうなっていようとも、push_back()から戻った時にはデータは追加されているので、問題ないのでは?
std::vectorは末尾に0を追加したりしません。 >>782
- 最新のドラフト
+ 正式版の規格票 確かにCだと必要メモリの問い合わせの為に二度呼び出したり面倒でしたわ… >>798
正式版の規格票は金かかるやんけヽ(`Д´)ノ >std::vectorは末尾に0を追加したりしません。
左様いまだにstd::string::c_str()が内部で何をやっているのかわからん… >>801
msys64/mingw64/include/c++/10.2.0/bits/basic_string.h
ここに書いてあるぞ >>799
でも「直接メモリいじってる」て感覚があって好みだったなぁ
まあ自己満足でしかないのだけれど 今どきのC++(C++11以降)だと基本的にスコープ抜けたら開放される方式で実装するものなの?
なるべくnewせずにスタック変数にする or ヒープ確保するにしてもスマートポインタ使う
とかで >>805
そうしたほうが簡単だから、C++11とか関係無くそうするだろ。 そうかな?
ライブラリとかでわざわざInitialize/Finalizeとか明示的に呼ばなきゃいけないの
結構ある気がするけど Finalizeが失敗する可能性があってエラーハンドリングしないといけない場合はあえてそうしているかもね というかスコープ内で完結しない、グローバルな状態を持つものならそうするやろ お前が挙げてたそういうライブラリがInitialize/Finalizeの中で何やってるか考えれば自ずと答えはでるだろ グローバルな初期化と後始末ならInitialize/Finalizeとか明示的に呼ぶ設計のが一番闇が少ない
ファクトリメソッドでオブジェクトを作ることにして、ファクトリ元オブジェクトの
コンストラクタとデストラクタでそれぞれInitializeとFinalizeでも良いが(呼び忘れ対策は完璧になるが
InitializeやFinalize自体のエラーハンドリングを考えるとやっぱビミョー 変数名で対象変数のポインタを取得してくる実装(リフレクション?)をしたいんですけど
対象変数をポインタテーブルとかに書き下すことなくコンパイル時に変数名リテラルと対応するポインタを自動生成することってできますか? 対象変数はstructかclassのメンバ変数を想定しています 直接には無理
目的次第だけど基本的にはプリプロ駆使して頑張るしかない 数値計算に興味がある方に聞きたいのですが、ベクトル演算はどのように実行していますか?
valarrayかeigenなのか、vectorでforを回すのか…C++の常識ではどうやるのか伺いたいです >>821
blasやlapackにルーチンがあるならそれを使う(ラッパーを作る)
要素の持ち方はvectorでもvalarrayでもその他クラスでも、一次元的にメモリに格納されるなら何でも良い
二次元以上の配列が行優先か列優先かさえ固定しておけば何でも良い SVDとかするなら自前実装なんか無駄だからeigen使う。それ以外なら>>822 の通りだな。 みなさんありがとうございます
主に多次元の常微分方程式を解く目的でFortranからc++へ移行しようと考えていたのですが、ベクトル和やスカラーベクトル積等の計算がFortranほど簡単ではなさそうに感じて質問しました
eigen等を活用しつつ頑張ってみます そりゃそうだろな
汎用機の時点で科学計算と銀行計算の両方ができる
だから科学専用に作られているFortranと汎用のC言語は根本的に用途が違う
そもそもFortranの後に作られたのがC言語だし、時期も近いし、
だからFortranで出来ることをわざわざC言語でやったりはしない、
用途での住み分けがそのころからある
後発の方が簡単に出来るというのは幻想 簡単なことは簡単に言え
既成のソフトを使い慣れているならそれを使え
不満があるときに自分の理想との違いを埋めるのに
打って出る手段の1つにプログラミングがある
それはC++に限らない
たまたまC++を選んだのなら自らの名誉に恥じぬ努力をせいや
これまたC++に限ったことではないがな
あれ使えばいいやー、これ使えばいいやー
自分なんか物事を考えるだけ無駄なんだー
↑
こういうスタンスのやつ、俺は反吐が出るほど大大大大大嫌い ヘッダファイルに
double hoge = 1.0/3.0;
みたいに書いてた場合、除算はどのタイミングで行われるんですか?初回呼び出し時のみですよね? 大昔(40年ぐらい前?)とかもんのすごい特殊な環境用のコンパイラはしらんが
今の普通のコンパイラではそれはコンパイル時に計算される すみません、830で回答されてましたね
畳み込み、とかで検索してみては >>826
Fortranでも基本的にblasとかlapackに投げるだけじゃないの?
しかもC/C++からFortranルーチン呼べるし
「FortranではやりやすかったがC/C++ではやりにくかったこと」って非常に興味あるから具体的にどういうものか教えてほしい blasとかlapackがfortanで記述されてるからね
中身いじるような人がどれほどいるかはわからんけど >>829
翻訳時
なぜなら1.0/3.0は定数式だからだ
これは昔とか今どきとか関係ない 翻訳(interpret)ですか?
C++はコンパイル言語ではないのですか? コンパイラと構文解析とオートマトンって大学の授業でやったなぁ constexprとか中身がどうなってるのかもうわけわからん >>834
中身いじるような人がいないからこそ、fortranで(blasやlapack)でできる線形代数計算はC/C++でもできるだろうと思うのだが constexprともなるとどこまでコンパイル時計算してくれるかは
処理系依存と聞く…!
関数が絡んだ場合だけかもしれんが >>842
constexpr にまつわるルールはコンパイル時計算してくれる最低ラインを定めるもの。
どこまでコンパイル時計算してくれるかが処理系依存なのは初期のC言語から変わりないよ。 constexpr指定したものはコンパイル計算でしょう? >>844
コンパイル時評価可能(コンパイル時に評価するとは言っていない) >>844
constexpr 指定が付いた関数は定数式が要求される文脈において
与えられる引数も定数 (定数式) である場合に限りその関数呼出しは
定数式という扱いになる。
定数式が要求される文脈で入力が定数でないならエラーになるし、
定数式が要求されていない文脈であれば実行時計算だよ。
実行時計算にはならない (実行時計算が必要な文脈だとエラーにする) 指定として consteval が導入されたのは、
constexpr の文脈依存な挙動が面倒だと思ったやつがいたからだと思うよ。 C++はまだ色々と足し続けてるのか
constexprはともかくconstinit, constevalて... 自動で呼び分けて欲しいと思うこともあれば
コンパイル時に限って欲しいことだってあるだろう。 ■ このスレッドは過去ログ倉庫に格納されています