C++相談室 part147
レス数が1000を超えています。これ以上書き込みはできません。
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part146
https://mevius.5ch.net/test/read.cgi/tech/1573094136/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/
■長いソースを貼るときはここへ。■
http://codepad.org/
https://ideone.com/
[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
↑え？だってお前、普通ダイナミックリンクするだろ？
"ダイナミックリンク"す・れ・ば、ファイルサイズ**増えないです** 藻前らにクリスマスプレゼント貼る、
ttps://cpprefjp.github.io/international-standard.html
もっともっと争いにはげむと良い このままいくとそのうち C++20 → C++40 → C++80 ...
などとなり、そのうち C++98 とどっちが古いかわからなくなる
時がやってくるわけだが、その点をちゃんと考えているのか
標準化委員会に問い詰めたい こんなだからC++敬遠されるんだよ
組み込みエンジニアとしては嘆かわしい限り >>6 前スレッドの「あれっ？」は、俺の環境だと1000番だったよ。
>>8 「こんなだから」はどこを指してる？
「そんなことも忖度できないから…」かも知れんけど。 は！const付けると書き込めないから
コンパイラが最適化してくれるんじゃないだろか！！ 一つのクラスの単体テストって何個くらい作りますか？ ■ windows.hのmin/maxマクロ回避策４パターン
ttps://yohhoy.h a t e n a d i a r y.jp/entry/20120115/p1
↑
こんな具合に記号定数マクロ展開を抑止する方法って無いですかね… 単に展開を抑止するだけなら#undefで良いんですが
#include <Windows.h>
namespace w32w {
const w32wMOVEFILE_REPLACE_EXISTING = MOVEFILE_REPLACE_EXISTING;
#undef MOVEFILE_REPLACE_EXISTING;
const MOVEFILE_REPLACE_EXISTING = w32wMOVEFILE_REPLACE_EXISTING;
/*...*/
} // namespace w2w
みたいなのをもっと簡単にやれないものか… ちょっと何言ってるかわかりませんね
FOOという定義済みマクロとnamespace barがあるとして、
const int bar::FOO
を定義済みマクロFOOの値で初期化したい
とゆーことです＼(＾o＾)／ >>23
手で書けるなら頃せる
今気づいたが定義済みマクロWINVERって<Windows.h>をインクルードしなくても
定義されてるのねん… windows.hのsmallに引っ掛かって30分悩んだ >>22
マクロにFOOとかを渡して、トークン連結演算子でどうにかできるのでは？
#undef使って切り替えるより簡単だと思う
何がやりたいのかいまいちわかってないので違ってたらスルーしてくれｗ >>24
頃せる？
できるって意味か？
手でやるのは馬鹿げてる作業だと思うぞ
でツールでやるなら別に簡単に書ける必要もなし
正直そんなとこがんばってもと言う気はするけどね
小文字のマクロだけは滅んでほしい namespace w32w {
#include <Windows.h>
} // namespace w2w
const MOVEFILE_REPLACE_EXISTING = w32w::MOVEFILE_REPLACE_EXISTING; constはスレッドセーフじゃないとダメなんだな。 キャッシュやメモ化してるだけのメンバはconst付けたいところだけど、ミューテックス使うとマイクロ秒の単位で時間がかかるとなると、付けないほうが良いのかな。 そういえばマクロって使う必要なくなったよね。
なんでだろ。 c++11以降の目的の一つがマクロつぶしだからな。 >>39
boostはまだ言語仕様で標準化されていない機能を標準化された機能で実現しようとしている部分が多いから、自然とマクロでどうにかしなきゃならない箇所が多いんだろう >>40
捨てるためにゴテゴテとよけいな機能をつけなくても、
スコープ内だけで有効なローカルマクロ的なものを導入すればそれで良かったような気がしなくもないが、
#includeが絡むとやっぱだめかなw 今さらEmscripten使ってwasm化してみたけどそこそこ使えそう マクロというかプリプロセスの一部を言語規格内に取り込まないと無理なんだろ マクロの進化を考えてみた
マクロは型に対応していないのが問題なので、まず型を導入する
しかし完全に常に型を必要としてしまうと普通の関数や変数と違いがなくなるので
コンパイル時に決定できる場合に限り、ジェネリックに何でも受けいれるようにする
・・あ、そうだ同じ名前で複数の宣言を可にして、それのうち一つでもコンパイルエラーで
ないなら他は無視して、コンパイルできるもののみ有効とかにすると色々つかえるかもしれないな
たとえばある構造体に特定のメンバがあるかどうかでコンパイル時に処理を分岐するとか マクロと言えばマクロアセンブラ
C/C++のマクロより高機能なので見てみると良い C++コードをプリプロセスする専用の新規言語を発明すれば！ >>57
それはcfrontといって世界最古のC++だ >>59
mocはまだ生きてるんだな
無くなったと思ってた >>60
そうか、C++11 or later を食らうをプリプロセッサーがウけるのか… rustのようなマッチングでやるとか
他にはASTのAPI提供するとか
あとはlispみたいにやるとか
c/c++よりまともなやり方はあるけど正直どれもややこしいし上に
めんどくさいんだよね メタプログラミングにおいてあえてチューリング不完全にしちゃうってのは
悪くないデザインチョイスだと思うんだよね
すがすがしい てかその手の糞みたいな発想はlispでやりつくされてる。
バカが知らないだけで。 includeでテキストファイルを文字列literalとして読み込んだり、CSVファイルを行毎に指定の変換で読み込んだりしたい
外部プログラムで変換するのがめんどい なんとかいうプログラミングの偉いひとがいってたんだけど
「凡人が斬新な発想と思っている事の5割は既に誰かがやっており
残り5割は斬新ではなくそもそも機能しない」らしい c++ natureを極めるためにはc++公案で鍛えるしかない 主要コンパイラはすべてサポートしているにも関わらずいまだに#pragma onceを使わない人が少なくないのはなぜ？ >>74
#if defined() / #ifdef で十分ですから
#progma once が規格に取り込まれでもしないかぎり状況はかわらないでしょうね
#progma once の優位性はなんでしょうか 一行で済む
万が一のdefineの衝突が起こらない 3.4.xのどこかで対応してるからもう10年以上前の話 VSについてくるclang-clはpragma once普通に使えてる。 いまcl、clang-cl、gccでチェックしてるけど、pragma onceは使えてる。 #pragma once
と書いておけばperlで#if defined() / #ifdefに直せる 標準化してくれれば良いのに
pragmaで出来ることの範疇越えている気はするけど 他のもろもろと合わせてモジュールに移行することで済ませるつもりなんでしょ。 そういやまだモジュールサポートしてるコンパイラないな C#だとis演算子を利用してキャスト可能か判定していますが、
C++でdynamic_castでキャスト可能かってどう判断すればよいのでしょうか？
後、static_castできるかどうかの判定はどうすればよいのでしょうか？ dynamic_castがnullptrを返すかどうかで判断
if (auto dp = dynamic_cast<Derived*>(bp)) {
(dpを使った処理)
} >>87
static_castは静的に決まるから、コンパイルエラーにならなければできるということだぞ。
それが意図した通りの変換になるかは規格を正しく理解すればいい。 >>91
まずは日本語の基礎を身に付けてください。
それと、最近python関連のスレでテトリスの質問をしまくっていたキッズなら、テトリスはあきらめて愚直に入門書から始めてください。 江添の最近出した本、このスレ的にはどういう評価なの？ 江添亮のC++入門、2019/9
こんな本を出していたのかw
関係ないけど、漏れは、下の本を読んでる。
短くまとめられていて良い
[改訂第3版]C++ポケットリファレンス、高橋 晶 ほか、2018 >>96
＞C++ポケットリファレンス、高橋 晶
たぶん最初に出たC++11和書ですね、すごく勇気がいったと思います、私も読ませてもらっています 江添亮、επιστημη［エピステーメー］、高橋晶とか、
日本のC＋＋標準化委員会のメンバーは、伝道師みたいな香具師が多い
本をよく書く まあ、猫でもなんとかとか、スッキリわかるとか、柴田よりはましだろw >>98
エピさん、監訳ポジなら問題ないんですけどエピさん単著だったら、ちょっと考えますね
エピさんの本は出来の波が激しすぎるのです エピはサンプルコードの題材が全部タイマーのイメージ >>98
その3人全員委員会のメンバーなの？江添だけだと思ってたが sizeof(void)がビルドが通らないorz
void型を渡すときのテンプレートの特殊化ってどう書けば良いんじゃ… >>102
Ｃ＋＋テンプレートテクニック―簡潔で再利用しやすいコードのためのＣ＋＋活用術、2009
著者の紹介文に、こう書いてある
επιστημη［エピステーメー］
Ｃ＋＋標準化委員会会員
高橋晶
１９８５年生まれ。２００８年０５月からＣ＋＋標準化委員会にエキスパートとして参加
（本データは、この書籍が刊行された当時に掲載されていたものです） まじかよ
正直ソフト開発してないライターがやたら参加してんのはどうかと思うけどなぁ まぁ規格の解説とかはそういうのに関わってる人にしてもらうのが一番いいんじゃない？ まぁ解説とかはそうだし有難いんだけどね
ちょっと日本のライター(に限らないのかもしれんけど)は自分でがっつり使い込んでもないテクニックを
「もしかしたら役に立たないかもしれない」との疑い全く無しに押し付けてることがあるしたまに宗教じみてるから
そういう人ばかりだと今後が不安だなぁと
それだけw 技術書籍は著者の思想に染まらなくても
そこに書いてあるアイディアを欲しいとこだけつまみ食いが
デフォな読み方だろ いや、どれもこれも役に立つよ
てか新機能は大概実際に使っているやつらの発案で始まっているのだから当たり前
まあ、だからこそいろんな分野での要望がまぜこぜになって、ある分野では誰も興味を持たないみたいな言語機能も出てくるのだが >>114
いや言語機能は大抵役に立つよそりゃ
役に立たないかも、ってのは彼らが主にブログとかで紹介してるようなテクニックのこと
完全型か不完全型かを判定するテクニック思いついたよ！(ODRに違反するので要件チェックでエラーにする為にしか使えないが、それは書いてない)とか
C++/CLI風のプロパティをテンプレートで作ってみたよ使ってね！とかな
実際に開発してて使ってたらそんな都合よくはいかんやん？開発に使ってる人間とはちょっと感覚がズレてるんだよな >>115
それは開発やってる人間が考えたってある前提では上手くいくが別の前提では使えないということもあるし、巷に溢れてる初心者でも書ける記事よりは価値があると思うよ。
参考になるところだけ拾って自分の役に立つときに取り出せればいいんでない？ まぁそれはそうやね
なんだかんだ世話にはなってるし std::vector<std::string> で、登録済みのstringのc_str()が変化しないことを保証する方法ってないかな？
このままでも基本的にはムーブされることが期待できるけど、コピーが発生する可能性は否定できないよね？ restrictがないからconst&から取得したc_strでも失効してることがあるよな >>118
そのvectorに対してiteratorが無効になる操作をしないこと、およびその要素stringに対してc_strが無効になる操作をしないこと、ではいけないの？ vectorで書き換えられたくなければvector<string_view>にすれば コピーを作って、参照ではなく元々constなオブジェクトにするしかねえべ ありがとう、そのままじゃ無理みたいだね。
std::vector<std::unique_ptr<std::string>>> にするわ。 vcとgccでは通るんだけどclangだけ引っかかる
const test obj;
return static_cast<test const&&>(obj); //ok
return move(obj); // warning: moving a local object in a return statement prevents copy elision [-Wpessimizing-move]
copy elisionを後押ししちゃダメってこと？ そのまま読むと、「ムーブすると」コピー省略の妨げになるとしか書かれてない気がするけど 現代的なコンパイラならわざわざムーブする必要ないからね
最適化の邪魔になる可能性あるよって親切に教えてくれてるんでしょ 118からの流れで122を書いたんだけど
const付きで何かした結果をmoveでなら無理なくconst外し
できるのかって発想で実験してたんだ >>123
そんなことするくらいだったらstd::dequeの方がよくね？ std::list は大丈夫かもしれないけど std::deque は vector と同じような。 まぁ、std:dequeはチャンク単位でメモリ確保するから、頭とお尻の操作であればの再配置が行われないけど、途中要素だと再配置入るから保証は無理か。 ああなるほど、dequeの尻に追加する分には既存の要素の再配置は起こらないのか。ありがとう。 詳しくは知らないけど、std::dequeにはreserveがないから、ちゃんと規定されているのではないかと思う。 C++とか多重定義があるから関数名が内部で修飾されて違う名前にするの、英語でなんか呼び名があったと思うのですが
なんというのですか？
C++と多重定義に限らず、実際の名前と違うのを作ることを言うのかも知れなかったけど 昔から思ってるけど、マングリングっていう単語
ちょっと口にするのに抵抗ある感 うちの会社は開発島のとなりに総務島があってマングリングを誤解するだろうお姉さま方がたくさんいるから、とても言えない。
わざと聞こえるように言って反応を見てみたい気もするが怖くて出来ない。 そんな事をいちいち気にしなきゃいけないとか大変だな
置換とか正規表現とかも言うなよ string GetAnswer(string mode, string text) {
std::string ques, ans;
if (mode == "Read") {
std::ifstream ifs("xxxx.txt", std::ios::in);
ques = text;
}
else if (mode == "Write") {
std::ifstream ifs("xxxx.txt");
ques = split(text, ":")[0];
}
std::string str;
ans = "not_found";
std::vector<std::string> line;
while (getline(ifs, str))
{
・・・・・・・・・
}
l・・・・・・・・
この状態でgetlineを読み込まないのはなぜですか。 std::ifstream ifs("xxxx.txt");
if (mode == "Read") {
// std::ifstream ifs("xxxx.txt", std::ios::in) //コメントで外す; もしくは削除
ques = text;
}
else if (mode == "Write") {
// std::ifstream ifs("xxxx.txt"); //コメントで外す、もしくは削除
ques = split(text, ":")[0];
}
こうすれば、まともに動くのですが、前記の状態で動かないのはなぜですか。
modeは"Read"と""Write"しかないのですが。 グローバルスコープにあるならオープンされてなさそうだね 質問ですが以下のコードのように、enum Barが
クラスFooの中でprivateなサブタイプとして定義されているときに、
enum Barで定義されている定数TAG1やTAG2を
ラムダ式の定義の中からクラス名修飾無しで使うにはどうしたらいいんですかね…
class Foo {
private:
enum Bar { TAG1, TAG2, TAG3 };
public:
enum Bar some_method();
enum Bar launch(std::function<enum Bar(int)> func);
};
Foo::Bar Foo::some_method() {
// メソッドの地の文
printf("TAG1=%d\n", TAG1); // これはクラス名修飾無しでもOK
// ラムダ式の定義
auto lambdaFunc = [=](int x)->enum Bar{
if (x == 1) {
return Foo::TAG1; // これはクラス名修飾しないとコンパイルエラー
} else {
return Foo::TAG2; // これもクラス名修飾しないとコンパイルエラー
}
};
// ラムダ式を使う
return launch(lambdaFunc);
} >>151
レス㌧クス、だいたい動いたのですがMSVC 2010だと1点変更が必要でしたorz
↓17行目
https://ideone.com/PYoVfL
some_method()の定義をクラスFooの定義外に持っていっても同じ。
ラムダ式の中でFoo::TAG1とせねばならないというのは誤認だった模様ｻｰｾﾝ、
しかし上のような新たな闇に行き当たってしまった、、、 なお、>>152の17行目のthisをコメントアウトして（つまりオリジナルの>>151のコードに戻して）
その上でラムダ式Lmの中でFoo::T1と書くともっと訳のわからないエラーを吐かれる↓↓↓
1>ideone_38OeRz.cpp(19): error C2065: '__this' : 定義されていない識別子です。
1>ideone_38OeRz.cpp(19): error C2227: '->T1' : 左側がクラス、構造体、共用体、ジェネリック型へのポインターではありません。
21世紀も半ばにさしかかろうというのにこんなことになるとわ…！ 遅いけど、私はなかなか c++11 に移行できていない労咳だと心底自覚するようになりました… https://ideone.com/b6s1Oi
>>152 病みすぎて良くわからん。
>>153 Ideonでは動いているので、環境が古すぎるとしか言いようがないな。
2010ってそろそろ10年前といっても差し支えない程度に古いぞ。 そういえば、ドラフトのIO2Dってどうなったんすか？ 頓挫したんじゃない？
一時期どんなものかと資料調べてだけどまとまってなかったよ。今どうなんだろうね？ >>146
ReadかWriteのどちらかを抜けてからgetlineで読み込みますね。
デバッグで確認しています。
>>147
ビルドの段階で全くエラーが出ません。
警告にもなっていません。>>149
>>149
グローバルスコープと言うより全体が__declspec(dllexport)で
出力された関数です。 >>162
VS使ってんでしょ？
> while (getline(ifs, str))
このifsを右クリックして定義がどこか探しなはれ >>162
ここまで頓珍漢なレスは久々に観た
釣りなら大したもんだ 初心者なんてそんなもんだろ
>>145
if/else文の中で宣言されたifsはブロック{}で囲まれてしまっているから、ブロックの外からアクセスできない。
だからgetlineに渡してるifsはどこか別の場所にあるifsを参照してしまっている。
std::fstream fs; //< 読み書き両用にするなら"fstream"にすること
if (mode == "Read") {
. fs.open("xxxx.txt", std::ios::in);
. ques = text;
}
else if (mode == "Write") {
. fs.open("xxxx.txt");
. ques = split(text, ":")[0];
}
...
getline(fs, str) >>165
おっしゃる通りです。お恥ずかしい。
for文とかにだけ当てはまると思っていました。
後はローカルかグローバル変数かぐらいしか。
ありがとうございました。 vector<vector<vector<char>>> data(10, vector<vector<char>>(3, vector<char>(3)));
だと,、char[10][3][3]になると思うのですが
[10]の部分だけ動的にするにはどうすればいいのでしょうか。 >>168
vector<array<array<char, 3>, 3>> data(10); 構造体もvectorに入れられるのですね。
ありがとうございます。 ちなみに class と struct はデフォルトが public か private か、という違いしかない
事実上同じもの C++のclassとstructはデフォのアクセス指定以外全く同じものだとちゃんと教えない教材がちらほらあるのが悪い
そもそもclassより先にstructをCの構造体の感覚で教えるやつは教える側がちゃんと理解してない可能性すらある そこまで言うなら
struct の方をさっさと deprecated - obsoleted すれば良かったんよ
20年位前にやっとけば良かった というかclassが要らん
private: 一行書けばいいだけだろ
まあ最近ではGoやRustによってstructが復権してるけど、
当時はオブジェクト指向の用語に対して変なコンプレックスがあったんだろうな >>178
そうそう
|
| 彡⌒ミ
＼ (´･ω･`)デフォルトのアクセス指定子を定義したことは，十中八九，間違いであった．
(| |)::::
(γ /:::::::
し ＼:::
＼ 指定子書き忘れにデフォがprivateならコンパイルエラーでわかるがpublicならわからん
デフォはprivateの方がいい 禁止がデフォで許可が明示な
constも本当はそうなっていて欲しい
ラムダ式の[=]だけデフォconstになっててmutableで外すんだけどね 全部コンパイルオプションで対応できそうなのに
っていうかRustいらなくならなくね >>181
最適化禁止のvolatileがデフォはウザすぎる volatileの有用な機能のみを残し、効果が疑わしい、または壊れている機能を非推奨化する
完全に消える分けでは無いらしい
詳細は知らん >>176
まじですか、C++のstructも構造体だと思っていたけど。
知らなかった。
プロパティだけならstructの中の変数とclassの中の変数
って、あまり変わらない気がするけど、classの方はメンバ
とか言われる実質は関数を含むことができるじゃない。
あと、親から継承したりとか。
なんとなく同じものという感じがしない。 structもメンバ関数を持つし、継承もするし、classをstructが継承することもその逆もできる
デフォがpublicかprivateかの違いだけで機能はclassと全く同じ >>188
知らなかった。長い間,、Cの構造体と同じことしか
できないと思ってた。 なんかboostスレ死んでるからここで教えてください。
boost使ってクラサバ作ってて、クライアントが接続されるたびに、サーバ側で比較的重い処理があり、
処理止めたく無いからio_serviceに溜まったキューの数見てスレッドを動的に調整したい。
けど、自分の拙い検索能力ではio_serviceに溜まってるキューの数を調べる方法が無さそうなんですが、取得することは可能ですか？
よろしくお願いします。 許容されるスレッド数で常にフルスロットルじゃいかんのけ？
処理がないスレッドは勝手に止まってるし、なんならセマフォで動作数も調節もできるだろうし スレッド増やしたところで本質的な解決にならん問題な気がする。 キューの前にガバナー、調速機を付ければいい
キューに入れた個数と出てきた個数をカウントすりゃいいんだろ
スプールでも作ればいいんじゃないの 質問ですがstd::function<T>型のオブジェクトにNULLって代入していいの？ >>194
大丈夫
nullptrの代入は何も関数を保持していない状態にする C++11の知識でC++書いてるけど、特に不便ないな
最新のC++だと何ができるの？ お前がC++11で十分と思っていても他人はお前に遠慮なんかせずC++20の記法で書く
お前がヘッダーをよこせと言ってもモジュールしか提供されない なにを怒ってるんだよ
イージーになろうぜ、イージー 俺は久しぶりにC++を書いて機嫌がいいんだ
あまり怒らせるなよ 標準ライブラリにはまだモジュール使われないんだろ？
20の次あたりでモジュール版も出てくるかどうかだろ またテンプレートの分割コンパイルを誰かが1年ぐらいかけて実装して、
できたころには陳腐化しているという歴史の繰り返し
永遠に枯れない gcc10入れた！
-std=c++2aでモジュールって使えるの？ なんだ-std=c++2aでは使えないみたいだな
概念的にはGoのpackageに近いのかな？ なんでだよー＞＜
相手してくれよー＞＜
うわわわわん まだ実装してるコンパイラが無いっぽいから誰も使い勝手なんかわからんわな
>>205
持てる 1) mkl_blas.h がシステムに存在したらそれをインクルードし、行列行列積ルーチンとして (C++で実装された) dgemmを使う。
2) mkl_blas.hが存在しなければFortranルーチンのdgemm_を使う。
というのを実現したいとします。
mkl_blas.h もないし Fortranルーチンもないという状況は考えません。
関数名の末尾のアンダースコアの有無がややこしくて困っています。
#if __has_include(<mkl_blas.h>)
#include<mkl_blas.h>
#define dgemm_ dgemm
#else
extern "C" void dgemm_(省略);
#endif
としておいて、プログラム中の行列行列積ルーチンは全てdgemm_と書くことでお茶を濁しているのですが、もっとスマートな方法はありますか。
#define dgemm_ dgemm
という部分がいかにも場当たり的で気に入らないです。 俺ならソースにdgemm_みたいなのがあるのは嫌だから
#if __has_include(<mkl_blas.h>)
#include<mkl_blas.h>
#else
#define dgemm dgemm_
extern "C" void dgemm_(省略);
#endif
ってやると思う マクロが嫌ならinline関数にすればいいんじゃね C++で次々に追加される無駄機能は
Cをしっかり理解していれば同等の機能を実装するのは造作もないものが多い #define my_static_assert(cond, msg) typedef char my_static_assert_failed[(cond) ? 1 : -1] Cはマクロの使い方次第で出来ることが深まるんだよな
ただC++はマクロ使わない方向で進化してるからな >>212
下手なことするよりその書き方のが良い。個人的には214の方のが好きだが大して変わらん。 いざというときも最悪Cならコンパイラを自作できるがC++はちょっと… おとなしく頭の良い奴に従っとけ
自分が優秀だと思い込んでいる精神異常者の諸君 増えていく機能が軒並み
プログラミング始めたてのやつが持つ不満を具現化したようなものばかりだ
慣れていくとCがそうである理由がわかってきて、いらなくなっていく
おおかた頭のいい奴が新規で入ってきて、慣れてないくせに良かれと思って追加してるんだろう >>216 >>228
具体例早くしてくれ
抽象論では話にならん C++コンパイラとC++のライブラリはC言語でも書けるから
当たらずしも遠からずだと思う >>228
C++は大人数で開発するための言語なんだからてめー個人がいるかいらないかなんて関係ねーんだわ チームでの開発を安全に進めるための機能なんて熟練者が書く分にはそりゃいらんだろ
で？ まあアセンブラさえあれば他に必要ないし
でもそこそこ規模大きいプロジェクトはc++多いよね
反例にlinuxはあるけど windowsでさえc++なんか使わなけりゃよかったいうとるぞ。
つまり低レイヤー触るのに向いてるようでそうでもないってのがc++なんだよ。 >>233
Sun/OracleのJavaのコンパイラ javac は Java 自身で書かれている。
IBM製のJavaコンパイラ ecj も同じく。 皆さんが使用されているエディタを教えてください....🙇♀ あ、すみません僕は今はatomを使っています
自作のエディタを使ってらっしゃる方なんているんですね。。。 ↓のコードはコンパイルが通るのですが、func(1)ではなく、func<int32_t>(1)のようにしなければいけないと思っていたんですが、そうではないんですか？
これはコンパイラが勝手にTの型を推測してくれているのでしょうか？
#include <iostream>
template<class T>
void
func(T value) {
std::cout << value << std::endl;
}
int main() {
func(1);
return 0;
} 俺は自ら望んでなったC++使いだが
リーナスの主張には何ら文句はない
俺も好かんところがいくつかあって我慢しているが
他の人がキレるのを否定はしない >>249
intに推論されてるね。
関数は推論してくれる。 >>251
そうなんですか
ありがとうございました C++17からはクラスも推定するようになったから気をつけろな >>249
>>251
もう少し正確に言うと関数の引数の型については推論してくれる。
戻り値については推論してくれないから<>で型を指定する必要がある。
template<typename T>
T func(double v){
return static_cast<T>(v);
}
int main(){
// int pi = func(3.14); // エラー
int pi = func<int>(3.14);
return 0;
} >>253,255
なるほど！
ありがとうございます C#使ってきたわい、C++入門するにあたって何から手を付けたらいいか分からない
江添の入門本読んだらええの？ +を重ね合わせないでずらして書くと#じゃなくて++になるやろ
つまりそういうことや あんなカス本読むならビャーネの本とeffective系統を何冊か読んだ方がよっぽど為になる。 俺も自分の経験からは禿の本をオススメすることになる C++でウィンドウ関係の処理を組もうと思っているのですが、
最近だとMFCではなく.Net Framework を利用するのでしょうか？ >>265
MFC抜きでWin32APIだけでコード書くことがあるけど正直無駄な苦痛を感じるよ
MFCもダサいとこあるけどMFCでできることと同じ内容のコードを書いてると泣けてくる オブジェクトを明示的に破棄する方法ってある？
自分で new したなら delete すれば良いと思うが、STL コンテナ等の場合はどうすれば良いかという質問です。
例えば巨大な vector を作って何らかの作業をした後、もうその vector は用無しでメモリがもったいないからスコープを抜けるのを待たずに破棄したいみたいな状況を想定してます。 >>271
純粋仮想関数であることを示すための専用の構文らしい。pure-specifierという。 >>275
場当たり的な対処に思えますが、そういうのが嫌ならマメにスコープを切れということでしょうか。 >>276
じゃあvectorをnewしたらいいじゃん
頭使えよ >>265
tcl/tk
wxWidgets
Qt MS製にこだわって頑なにMFCみたいな化石使ってる奴いるけど普通にサードパーティのツールキット使うのが主流 他人のところの事情も知らんくせにシッタカこくと
聞こえたやつ全員からそれぞれ色んな理由でアホにされるぞ >>281
選択肢に.NETが出てくるあたり何の制約もない状況でサードパーティが使えない理由とは？ スレ違いでしょ。続きはWin32APIスレに移動してどうぞ。 vectorをnewする？
ゴミみたいなこと言うな > 自分で new したなら delete すれば良いと思うが
良いと思ってるならvectorもnew/deleteで良いでしょ vector newでいけない理由を先に説明してくれないと > スコープを抜けるのを待たずに
> 破棄したいみたいな状況を想定してます。
破棄するタイミングはコンパイラには分からんのだろ
人が判断するしかないなら「場当たり的」にやるしか無いのでは vector::clear()、vector::shrink_to_fit() の連続実行で十分なのでは？ shrink_to_fit
capacity()をsize()に縮小させるというリクエストを行う。
実装依存の最適化を許可するために、縮小するという動作は仕様上強制されない。
縮小されないかもしれない、らしい たいていは逆にスコープを破棄のタイミングに合わせるような書き方すればいいだろ。
分岐の激しい破棄条件書くくらいならそっちのが楽なことは多い。 途中で投稿してしまい失礼。
do {
} while(0);
で括って、処理が続行できない場合はbreakして、doループを抜けたすぐ下でで資源解放する古典的な記述でいいのでは。 gotoを避けるためにgotoよりクソなコードを書くのがいいわけねえだろ ま、資源解放のコーディングが楽になるなら正義でしょ。 >>298
確認するが、ここがC++スレということは忘れてないよな？ メモリがもったいない言うけど、ホントにカツカツなのだろうか
環境的に余裕であれば妙なコーディングする意味がない どんくらいスキマと余裕があるのかを常時監視するソフトウェアはかんたんに作れる
なんせわたくしはC++を極めましたからな >>297
gotoより糞な訳無いだろ
こんな単純で頻出する制御構造が文法上ループにせざるを得ないのが悪いだけ
まあtry catchと同型だが、これだと遅くなるしね >>302
doでない単純な複合文とgotoで済む話だ
アホｗバカｗｗｗ すまねーよ。他の例外で飛ばされたらどうすんだ馬鹿。 >>304
do(0) なんて持ち出すアホが RAII かよｗ まあ最近は
[&]{
...
}();
で書くことが多いが do{}while(0);の問題は知らない奴が混乱するって一点のみだろ 「知ってるやつ」の言い訳を、ここで開陳してもらおうか
最近、笑う健康法ができてないんで、よろしく頼むわ芸人さん その前にgotoより糞ってのが既に成立してないじゃん
どこが糞なのか具体的に ははは、話を逸らすしかねえよな
「do{}while(0);の問題」てのが他の問題によって
成り立つのか成り立たねえのか影響されると
自ら自白してやがる（核爆
助けてやらねえよ、自分でなんとかしなアホｗバカｗｗｗ >>312
逃がさねえぞ
「知ってるやつ」の言い訳を、ここで開陳してもらおうか
最近、笑う健康法ができてないんで、よろしく頼むわ芸人さん やりたいことはスタックにあるvectorの早期解放なんだから
gotoもdo{}while(0)もラムダ式もいらない
単に{}で囲うだけでいい ↓do { } while(0)でこれできたっけ？
if (cond) { goto label1; }
do {
処理A
label1:
処理B
} while (0);
YES! gotoならできる!!
if (cond) { goto label1; }
label2:
処理A
label1:
処理B
goto label2; つか
do {
処理A;
if (cond) { break; }
処理B;
std::unique_ptr p(new Foo());
処理C; // pを使用
} while (0);
みたいな腐り切った腐敗臭しかしないコードを書くぐらいなら
std::unique_ptr p;
{
処理A;
if (cond) { goto last; }
処理B;
p = std::unique_ptr(new Foo());
処理C; // pを使用
}
last:
;
と書くわ
Perl風に >>314
そんなことはお前ともう1名ほど除いて皆わかってる
そうじゃなくて特定の条件で早期に開放したい場合にどうするかだよ
>>315
味方が現れてウレションかよw >>318
auto v = std::make_unique<std::vector<Hoge>>(...);
...
if(特定条件){
v.reset();
}
これだけの話では？ goto過敏症のアホどもが少しでも目を醒ましてくれるといいな >>273
から読み直して
空moveが確実だけど質問者がそれを場当たり的と生意気言ったことから話が盛り上がるw >>323
この場合gotoは何の解にもなっていないことにそろそろ気づいた方がいいよ RAII対応してないから無理矢理goto出来るようにした糞コード上げられてもああ糞ですねと言うしかないんだが。
内部が複雑になってきたらその度にブロック外に変数追加して、変数の内容の初期化は必要に応じてって書き方を続けるつもりなんかね >>325
gotoが何かの解になったらいいの？ｗｗｗｗｗｗｗｗ やっぱこういうコードは一度書いてみたいよな
try {
label:
何かの処理;
} catch (Exception ex) {
goto label;
} gotoを使うと糞、と言う香具師は多いが
goto以外の構文も大概なことがある
↓これとか
EnterCriticalSection(&csec);
{
if (エラー条件成立) {
LeaveCriticalSection(&csec);
throw "*** ERR ***";
}
何かの処理;
}
LeaveCriticalSection(&csec);
一体どうすれば…orz いやまあテストラクトされるときにLeaveCriticalSection()するような
AutoLockオブジェクトを使えば済むっていやー済むが
裏返せばgoto以外の構文も糞製造機であることにはかわりわない！ それは構文が糞なんじゃなくてリソース管理が糞なだけ auto lockなんてむしろ使ってなかったらPRでリジェクトされる gotoの何が悪いのかを端的に表すたった一言が出てこない教条主義は物笑いの種 誰にも迷惑がかからないgotoの例：
for (a = 0; a < 2; a++) {
for (b = 0; b < 2; b++) {
for (c = 0; c < 2; c++) {
....
for (zaaa = 0; zaaa < 2; zaaa++) {
処理A
if (何かの条件) { goto last; }
処理B
}
...
}
}
}
last:
; >>334
たまたまLeaveCriticalSection()はエラーを返さないが
エラーを生じるﾌﾞﾂだったらどうすんじゃ
まあエラー通知先があれば良いのでやりようはあるが
加速度的に手が込んだコードが必要になって全体が糞化していくんじゃ！ そもそもそのgotoを書きたくなるくらい深くネストしている時点でよくない説 >>338
対象とするデータによっては単純に多重ループで処理するのがもっとも自然でシンプルなケースもあるだろう。
無条件に｢ネストしたループ(・A・)ｲｸﾅｲ!!｣と言うのも教条主義じゃね？ gotoにせよthrowにせよ、goto/throwの発生元が分からないのが受身になる側として辛い。
この点は、スタック情報へのアクセスが言語仕様として認められているJava/C#/Perl/Pythonに優位がある。 throwの発生元は例外オブジェクトに情報を持たせれば良いじゃん？
gotoのジャンプ元は変数に情報を持たせれば良いじゃん？？ >>343
goto/throw発生元がバイナリで配布されている場合は、コードを書き換えられない。
クラス設計でやたらとメンバ変数をprivateにされると、クラスを利用する側はメンバ変数を古典的プリントデバッグできなくて難儀する。 C++のprivate属性は厳しすぎ。readonlyアクセスできる属性があってもいいと思うんだ。 >>344
バイナリ配布のﾌﾞﾂの例外発生元を何でコードで知りたいのかがわからん…
アドレスがわかったところでソースが無いわけやし……
何事かを言わんとするための想定に無理が有るのでは… タイミング依存の不具合を追跡する必要に迫られると、当然ながら対話デバッグはできない。
C++のprivate変数が不具合に関与しているとわかってもランタイムで値を見れないのは辛い。
他人様の作ったC++クラスヘッダーを一時的に書き換えてコンパイルする羽目に。 >>346
例外が吐かれた後にできることなんてほとんどなくてもスタックをダンプできるだけでかなり助かる。
特に自分が作ったわけではないレイヤーでthrowされた時には、スタック情報が役立つ。 公式がデバッグシンボルを配布するご時世なのに、C++のスタック仕様はそれについていけていない。
デバッガを介することなくスタックをダンプできる手段が制約されすぎ。 gotoはRAIIと相性が悪いってのが端的だろ
これはgotoが悪いと言うよりc++の言語仕様上のgotoの扱いが悪いって話
constexprで使えないとか規格が新しくなる度に不都合が増えていくよ 文字列パーサー内とかでの状態遷移に使うは推奨する
その他でのgotoは代替手段があるし、そっちの方が言語サポート良いからgoto使うのはバカのやること まあ不遇な原因はgotoが自由すぎて前にも後ろにも飛べるせいだろうね
変数のデストラクタを呼ぶべきかどうかフラグ管理でもしないとコンパイラが判断できなくなる。
goto使うならその自由さが必要な場面でこそ使うべきなんだよ >>354
プログラミング言語の世界では、前や後ろという表現は直観的にわかりにくい。
前や後ろは相対的なものであり、バックしているイテレータにとっては前はバックなのだ。
上と下なら直観的にわかるだろう。 gotoの使い方を知らない初心者がこのスレにいるってのが不思議 [コラム] 正規表現の先読み/後読みは、どう考えても名前が悪いので、呼称禁止令を出してルックと気軽に呼んでみませんか。 - Qiita
https://qiita.com/mochizukikotaro/items/84f3ab2740b8efbe0dc6 >>357
誤魔化さない説明がちゃんとできるやつがずいぶん少ないという、残念な状況が今の日本だ わざわざ複雑にしてまでgotoを避ける
って宗教だよな
使いどころで使う
それだけ 別にgoto使っても使わなくても馬鹿が書けば複雑なコードになるだろ。
そういう問題じゃない。
そもそもc++の標準ライブラリが例外投げる時点でgotoとの相性は最悪だよ。
一番末端の関数で、副作用もないようなもの以外使えんわ。 gotoおじさんはたぶん例外安全性という概念をわかってない >>363
例外安全の定義が難しいのですが、gotoを使っても例外安全を保障することはできると思うのですが、いかがでしょうか。 >>364
c++の標準ライブラリに関して例外安全とは何かは定義されてる
できるできないで言えばgotoかつ例外安全はそりゃできるでしょうよ
まずgoto関係なしに例外安全が相当大変であることを理解してから出直してくれ
そうじゃなきゃRAII、autoなんとかmakeなんとかの有難みも理解できてないのよ >>366
話題を勘違いしてるのはお前だよ
お前は単にbreakでスコープの脱出することに対してgotoの方が簡潔と言ってるんだろう
そういう場合があるのは同意するけど今回の話題はそれじゃない
スコープの脱出になってるのはRAIIでリソースを安全に開放する前提だからだ
だからお前が言うべきはスコープをなくしてgotoを使うというなら
合わせてリソースをどのように安全に開放するかを説明しないといけない
場当たり的でない方法でね
そこをまったく説明できない以上お前はgotoおじさんと呼ばれ続ける >スコープをなくしてgotoを使う
なんか言ってることが変だと思ったらこんな条件付けてたのか。ブロックスコープ使えばいいじゃん。 スコープを無くしてgotoで解放？
なんじゃそりゃ？
スコープを抜けないと解放されないぞ 断わっておくけど
>>295 に対してgotoおじさんが >>297 と言ったのが発端
後出しはしていない
ちなみに295を書いたのはおれではない どんな劣悪な環境でも動く do{ } while(0); こそ絶対正義。 >>295は
do ループを抜けたすぐ下で資源を解放
って書いてあるように見えるけど >>372
ああ確かに >>295 に対してってのは語弊があったかな
ID:cLOUBKze の発言を追ってみて
>>303
とかね
gotoおじさんかと思ったら別人なのね >>365
本来の「例外安全」の定義はもっと広い意味なのですが、あなたは、throwやcatchなどの「例外」が起きたときでもnewされたオブジェクトの削除などを行うという定義を採用されているようです。
break文を用いずにgoto文でブロックを脱出した場合でもオブジェクトは自動解放されるのをご存知ですか？ >>375
自分は理解しているって言いたいわけね
じゃあさ >>273 のお題に対してgotoを使ったエレガントな方法を書いて
おれは思いつかないね
よろしく そもそも一番のカスはこいつ >>276 >>286 >>370
>>295に対して>>303が
{
goto label;
}
label:
でいいんじゃないかってことかと。
逆にどう解釈してRAIIとか例外安全とか持ち出したのか気になる。 >>378
それだとdo-whileと変わんないだろ
gotoおじさんの論点てそれか？
人の事クソバカ言ってるわりに何の優位性があるのかわからんな そうだよ、変わんないよ
複合文だけでできることになんでわざわざdoなんて面倒くせえもん使わなきゃいけねえんだよ まさかとは思うがブレースを開くのにdoだかforだか何らかのキーワードが必要とでも思ってたか？ 俺は何の実績もないおまえの言うことより、あわしろいくや氏を信じるけどな。 >>378
噂のgotoおじさまもさすがにこのコードがいいなんて言わないでしょ >>384
ブレースを開くのにキーワードが必要か否かに実績は関係ない
他人のネームバリューにすがるしかなくなったか？ >>386
ネームバリューは関係ないんだよ。
あわしろいくや氏は信用できる。
おまえは信用できない。 >>387
俺はお前のあわしろいくや氏は信用できるという言葉が信用できない >>388
俺のことは信用しなくていい。
あわしろいくや氏を信じろ。 まさか do while 構文が論点だと思ってたんかな？
まあ本当はgotoを推す正当性が全くなくてごまかしてるんだろうけれど。
てかgotoと例外安全性はかなり綿密に絡んだ話だろ。誤魔化しすぎだわ。 >>387
ヒゲ生やした教祖様のために死刑になった信者と同じだなｗ >>380
そのくらいしか思いつかなかったが、>>297はその程度の主張だったんじゃないの？
じゃあどういう主張しているとID:PgEzQeWdは解釈していたのかな。そっちが気になる。 > かなり綿密に絡んだ話だろ
誤魔化しすぎというブーメランが脳天に突き刺さってるぞｗ gotoと例外安全性がどう絡むのかわからんﾎﾞｽｹﾃ； 話しても無駄以前に、結局gotoと例外安全がどう関係するのか一言も出てこなかったな。 そらgotoでリソース開放ルーチンに飛ぶようなCスタイルのプログラム書くと
例外飛んできたときに死ぬって話でしょ
(いくらC++にfinallyが無いからってgotoでリソース開放ルーチンに飛ぶのはダメ)
ただし元々の質問には関係ない話なんだがな
ところでC++にfinallyが無いのはちょっと良くないよね
今となってはラムダで自作できるようになったからいいけど >>398
その「混ぜる」って具体的にはどういうことを言ってるんだろう。 基本的に break や return も生き先の決まった goto なので
余ほど変な使い方をしない限りRAIIと goto を混ぜれないって事はないよなぁ
むしろ RAII を使わないで goto でC系のリソース開放をしていた場合にハマるって話では
まぁでもこれは
do{
if( error ) break;
}while(0);
//開放処理
return;
でも同じことだし、元の質問には関係ないんだが do {
if(...) break;
} while (0);
よりは
{
if (...) goto label;
}
label:
の方が良い
という意見に賛成
>>303ではないけど {
{
if (...) goto label;
}
}
label:
これはbreakじゃ無理 {
switch (...)
{
case ...: goto label;
}
}
label:
これも無理 while(0)とか意味不明なコードよりgotoでスコープ抜ける方がはるかにシンプルだわな 一応 do while(0) の使い方も覚えておいた方が良い
他人のコードを見たりマクロで使ったり
する事もあるだろうから 普段のdo whileもwhile(0)って書くなど弊害が出るのでやめた方がいい ループするつもりもないのにループの構文使うのは悪手だと思う そこはまぁ、ループではあるけれども同時にbreakが使えるブロックでもあるわけで、
実際do-whileなんてほとんどがそういう使い方しかされていないわけだし。
ループできる構文でループしないのはbreakできる構文でbreakを使わないのと
同じようなものかと。 >>411
do whileしてるのになぜか1回しか実行してないのに気付くのに時間がかかる
習慣で書くのでwhile(0)に気づけない こんなささいな違いは個人の好みでいいと思う派
do-while使わない派の言い分もわからなくもないが、
ソースを読む場合gotoだってgoto先を確認しないと意図が理解できないだろ
label名を考える必要があるのもちょっとめんどい
なのでこんなのどっちでもいい
ちなみにrust方式もブロックの先頭にラベル付いてるのは若干違和感覚える どっちのやり方でも構わないけど、リソース◯◯を自動解放するためのブロックだとか意図を示すコメントを付けておいてくれればそれでいい。 ↑だからその方法だと例外安全が・・・
C++だとリソース開放は RAII か finally かしか幸せになれない >>417
誤解させたかもしれないから補足すると、どっちのやり方もと言ったのはただのブロックかdo whileかという話のことで、どちらにせよスコープを抜けて破棄されることを想定していた。
解放ルーチンにとばすことは端から考えてなかったよ。 解放ルーチンにとばすくらいしかgotoの有用な使い方なんてねーだろ。
だからRAII、例外安全の話になってるわけだが
もう意地になって意味もわからずgotoにこだわってる馬鹿がいる。 finally相当のデストラクタをラムダ式で渡すクラスのインスタンスを作ればいいじゃない、
で済まされてしまいそうだがやはりfinallyはあったほうがいい。 「解放ルーチンにとばすくらいしかgotoの有用な使い方なんてねーだろ。」
って思えるぐらい、Cではこの技法が多用された
なぜなら真実は逆で
「gotoでとばすぐらいしか開放ルーチンをまとめる方法なんてねーだろ」
だったから多用された
A→Bでなくて、実はB→Aだったって話
なんだけど、あまりにもB→Aが多用されたから
数の暴力で逆のA→Bも成り立つと感覚的に思ってしまう
だが本当にそうだろうか、gotoに開放ルーチンに飛ばす以外の利用法は無いのだろうか
模索してみよう、というのがスレの流れ
スレがその流れになるのは自明で
何故ならC++においては「gotoで開放ルーチン」は例外安全の意味で完全な悪手になったから
初めから勘定に入らないし、考える意味もないし、議論の余地もない
他の利用方法を前提に話すのは当たり前で既定路線 スレの流れはvectorの動的な解放手段についてです >>410
ほんこれ
メインフレーム時代から「なぜ０を足すんだろう」なんてあったけど
そういう謎コード書いて俺スゲーってやる厨二病は痛いよな つまりgotoと例外安全がどうとか言っていた人はこんなC時代の技法を念頭に置いていたわけか。
if (fail) goto FINAL;
FINAL:
後始末
gotoとRAIIの相性が悪い、混ぜられないという話はまた別なのだろうか。 >>426が例外安全かどうかとgotoは関係ないんじゃない？
>>273と>>426のコードも関係ない
ただ例外安全て言いたかっただけと思う >>273
vector<usigned char> huge;
//do something
huge.clear();
gotoは全く関係ない >>428
vector自体が確保したメモリが解放される保証がないのでNG
とっくに答えは書かれているのだから今からどやるのやめろ >>275
これで解決済みだよなぁ
std::vector<...>{}.swap(v) >>292 で実装依存の最適化について言及がある。
あるサイズを超えるまではヒープではなくスタックを使うことで高速実行を期待する実装はあり得ると思う。
vectorの具体例は知らないが、EASTL::basic_stringはそうやってる。 >>433
だから、どこに書いてあったのかと聞いているんだが >>431の言う空の一時オブジェクトとswapという常套手段で解決するのに質問者のクズは場当たり的などと難癖をつけ、
さらにじゃあnew/deleteしろよというまっとうな意見にバカを言うななどとほざいた結果がこのくだらねえ流れだよ >>435
c++の規格書は有料だけど持ってんの？
ぐぐればstack overflowとかいくらでもひっかかるけど調べた？
これは割りと知られた仕様だと思うけどね
実際g++とかでやってみればわかるけどclearしてもcapacity変わんないから 少なくともVC2019はclearでデストラクタが呼ばれてる >>438
それはvectorに格納した要素ごとのデストラクタの話であって、それらを格納するためにvector自身が確保した領域が解放されるわけではないだろ >>437
情報持ってるのに出してくれないのはわかったよ、無理にとは言わん
g++の挙動については情報ありがとう むしろclearで解放せず、capacityが減らないことを保証してほしいよね
capacity減らす手段は用意されているのだから 結局何を保証して欲しがってるのかさっぱりわからんが
言語仕様はvectorの何やらはもちろん、deleteだってfreeだって、OSにメモリ領域を確実にお返しになる事なんか保証してない事は覚えておこうな >>441
> capacity減らす手段は用意されているのだから
いや>>432はそれが確実じゃないって話だろ
まあそんな実装は見たことないけど >>444
空とswapは場当たり的に見えて却下と質問者様がおっしゃったからこの論争になったんだぞ >>442
OSに返すかどうかの問題じゃねえだろ
allocatorが管理するサブプールに還元でもいいわけで 概出鴨試練蛾
do{...}while(0); と
{...} の違いって決定的なのは何かって
break; を入れられるかどうかだと思うんだけど
ループじゃないものに do{...}while(0); を使うのは可笑しいって派の人らは
後者に break; 入れられるようにしておけば良かっただけなんだよな ループする気もないのにループ構文を使うのは誤解の元
同様のことは他にもいくつも手段はあるのにループを使う必要がない
モダンな書き方だと[&](){...}(); 違うだろ
while使わないよ派はgotoで充分だろ
ブロックを抜けるbreakが欲しいのは現状while使うよ派だろ once{};
みたいな構文で良いんじゃね
マクロとか書けば マクロ（）
ベターCとか03で脳みそ止まってんだろうなｗ C++スレだからlambdaでも許されるけどCだと使えないやん? ほぉ、じゃあお前はCで使える文法のみでC++を書いてんだな
ボケてんのか？ >>447
GOTO文有害説で言われる無条件分岐のスペルがbreakであろうとgotoであろうと同じことだ
同じ意味合いのことを書くために、ループでないものをループという嘘をつくことに俺は反対だ { から } までを１命令と読めるようにするのにgotoは無用と言っているに過ぎない
そのようにまとめようとしていないときやgotoを使っても１命令と読める場合にまで
GOTO有害説に囚われ強弁するのは何も分かってないやつのすることということだ >>448
今だとdo-whileでループする方が誤解の元になりそうな。 #define BLOCK(stmt) do { stmt; } while(0);
BLOCK(
if (error) break;
); do{}while(0)とか初めて見たけど
ダサすぎてそりゃ思いつかねーわｗｗｗ 結局goto有害説に流されないオレカッケーが言いたいだけだろ？
それでもgotoが有効な場面なんかないけどな。禁止にしても問題なんかない。 GOTO有害説に流されるのがオレカッケーと思っているようだな
アホｗバカｗｗｗ
禁止にしたら問題あるからlongjmpやthrowができてきたんだよ つまり、使わないほうが良いのですね。
なんとなくですがわかりました。 Javaから帰ってこなくていいからな
永久にバイバイ >>462
今時、例外の問題も把握してないでlongjumpとかthrowとか言ってんのか。。
馬鹿にもほどがあるわ。
負け確定だから泥仕合にしようってのはわかるがそろそろ引っ込めよ。 >>459
while(0)の後ろにセミコロン付けちゃダメ >>465
GOTO有害説に流されているという指摘は否定しないんだな？ｗ >>459
定義部 { stmt; } のセミコロンも不要かな。
プリプロセッサを通した変換結果を見て気付いた。
って言うか、関数形式マクロの実引数に
空白とかカッコとかを含めることができるのね。 >>468
確かカンマも使えないはずだし、>>459のマクロは使い勝手は悪く制御構造も隠蔽する有害な使い方だろう。 gotoを使わないことが目的になって
余計分かりにくくしてるアホな例 goto論争はくだらない
一方でラムダ使ったループ脱出は議論の余地がある
これがエレガントに見えるのか
パズルに見えるのか
自分の場合どちらかといえば後者
ラムダ自体は多用するけど 盲目的にgoto＝悪と信じて、かえって読みずらいコード書く奴ってほんとアホだよなあ gotoの何が悪いのかわかってないやつをもう少しいたぶってやろうと思ってたけど
途中で可哀想になってきて答え書いてやってるのになあ。。。 >>460
do { } while(0)
は自分は見たことがある。
忘れてしまったが、確か、#define マクロの定義部分で使われていて、目的は、
マクロ全体が一つの分の用に実行されて欲しいことであったようだった。
#define マクロ名() do {\
・・・\
・・・\
} while(0)
のような感じだったと思う。
これなしで裸で書くより安全になる場合があった気がする。 >>475
忘れてしまったが、おぼろげながら何か以下の様なことに関連していたような記憶がある。
C/C++では、if 文の直後は {}がなくても書くことが出来てしまう。
それで、
if (条件式)
マクロ関数名();
のように書いた場合、マクロの定義部を単なる {} で書くより安全な場合があったような
気がする。
忘れた。 >>476
あ、その場合だね、多分。
#define aaa() {・・・}
と定義してしまった場合、
if (...) aaa();
else ...
と書くと、
if (...) {};
else ...
と展開されてしまい、else の部分がエラーになってしまう。ところが、
#define aaa() do {・・・} while(0)
と定義していると、
if (...)
do {} while(0);
else ...
と定義されて、正しく動作する。 それは11年前のネタだからそうなってるけど現代C++ならラムダ式で書くべき内容 ていうかなぜラムダ式？
考える順は以下じゃない？
関数
インライン関数
テンプレート関数
マクロ >>483
そこで回答されている
#define FOO(x) do { foo(x); bar(x); } while (0)
は
#define FOO(x) [&] { foo(x); bar(x); } ()
と簡潔に書ける
そのQAの内容は今のC++におけるdo-while(0)の有用性を示す内容ではない ああ、そういうことか
do while に対するメリットがないと
互換性から do while を選ぶことになりそう ラムダ式はc++11からか
使えない環境は結構あるんだろうな
近付きたくない >>484
最適化前提にしないと代替とは言えないね >>484
JavaScriptだとそうかいても速度差がないかもしれないけど、C++だと、
そう書いた場合は、関数を定義してから、マシン語の call 文でその関数が
呼び出されるので結構なオーバーヘッドとなる。
JavaScriptの場合は、どう書いてもオーバーヘッドがあるからそのくらいの
オーバーヘッドは体感速度に登ってこないのでどっちでも良いだけ。 >>492
ラムダ式はインライン展開されるからオーバーヘッドにはならない error: no member named 'emplace_back' in 'std::__1::vector<int,
std::__1::allocator<int> >'; did you mean '__emplace_back'?
v.emplace_back(d);
^~~~~~~~~~~~
__emplace_back
/Library/Developer/CommandLineTools/usr/include/c++/v1/vector:696:10: note:
'__emplace_back' declared here
void __emplace_back(const value_type& __x) { push_back(__x); }
^
1 error generated.
push_backは普通に使えるんですけどemplace_backは何故か上記のようなエラーが出てしまいます
一応コンパイラに言われた通りに__emplace_backに変えれば動きはするんですが、普通にアンダーバーなしで
動かすにはどうしたらいいんでしょうか。環境はmacの10.14です。 >>493
それ保証されてる？
最適化オフでは関数オブジェクトのままじゃないの？
最近のc++はデバッグビルドが使い物にならないことが多くてマジ困る >>496
最適化するかしないか自分で選べるんだから、言語のせいじゃないと思うんだ。 最近というか昔からだなデバッグまわりがクソなのは
ほんと標準化プロセスは現実のプロダクト開発に関わったことのない言語オタクの遊び場に見えるわ
デバッグをないがしろにするなと
>>497
端的にテンプレートが原因だから言語のせい
というか誰のせいかどうでもいいから解を提供しろと >>498
最適化設定を変えることが解になると思って言ったんだけど、そうはいかないことがあるの？
デバッグまわりがクソだと言うなら、相手はまずコンパイラ＆デバッガのベンダであって、言語の標準化は
あんまり関係なくね？ インライン展開するかどうか含めて
最適化はコンパイラ依存
パフォーマンス測定やチューニングは
実際の環境でやらないと
可能性で言えばマクロが一番インライン展開の可能性が高い
(コンパイラが賢すぎて同一コードを共有するとかない限り) マクロはソースの字面を読み替えるだけ
機械語の命令シーケンスを開いたサブルーチンにするインライン展開とは全く別な話 >>500
マクロは、C言語の時代から「前処理(preprocess)」として処理され、
コンパイル作業が入る前にその場にトークンとして展開されるだけと
仕様で決まっています。勝手に関数になる可能性はほぼ0です。 挙動が仕様通りになるならコンパイラは何やってもいいんだよ（と仕様で決まってる）
マクロだったものに関数呼び出しを仕込むのもコンパイラの自由だ
実際同じ処理の塊があっちこっちに出てきたらまとめて関数（みたいなもの）にするコードサイズ最適化は普通にやる可能性がある >>501
オーバーヘッドを語ってるんだから
どういう手順でバイナリになるかは関係ない
バイナリになった状態が全て
>>502
>>500にそう書いてるけど >>504
マクロ展開は最適化が始まる前の話だつってんだよ、わかんねーやつだな
#define a(b,c) b * 2 + c * 2
a(x, y) //これは
x * 2 + y * 2 //こうしろというだけの指示で
(x + y) * 2 //このような変形は意味していないし
してはならない
a(x, y) * z //こういうとき困るだろうが インライン展開されるかどうかは、そのコード片がマクロの展開結果かどうかには関係ないってことだぞ
こんなこと、いちいち言わなきゃわからんようだから付け足しておく >>505
最適化をいつ始めるかなんてそれこそコンパイラ次第なんだけど つまりマクロはインライン展開されやすいという主張は引っ込めるわけだな 都合悪くなると
どうせいつもの手で逃げるだろうけどな
尻尾巻いたやり取りは残るぜ >>505
#define a(B,C) ((B) * 2 + (C) * 2)
>>498
>ほんと標準化プロセスは現実のプロダクト開発に関わったことのない言語オタクの遊び場に見えるわ
ほんそれ >>510
それはおまえさんの勝手な思い込みだよ
x * 2 + y * 2 * z
という結果を意図して使うこともできるのは
マクロに特有の機能で今さら変更できなくなっている 意図して出来るのは知ってるが
敢えてやらないんだよ >>499
デバッグのために最適化切ると激遅になる問題が散見されるという問題にたいして
最適化設定を変えるという解がナンセンス
そりゃpragma駆使して手で細かく切り替えりゃ可能だろうがそんなことやってられない >>512
おまえが510で持ち出したような括弧が自動的に付くような規格改定が行われない理由を考えたことがあるか？ >>505
多分比較してる内容が噛み合ってない
マクロを展開した結果と直接記述と
が同じなのは当然
プリプロセッサなわけだから
そうじゃなくて
マクロ、インライン関数、通常の関数の比較の話
当然最適化の期待度は
マクロ(直接記述)＞インライン関数＞通常の関数 >>505
そもそも最適化ですらない話を持ち出してるのか
話の流れと全く関係ないですね >>499
ベンダの責任っていうのは一見もっともでそれがまさにc++標準化メンバーのスタンスだ
でも例えばお前はSFINAE関連のデバッグどうやってるよ？
いくつかツールはあるが導入が難しいか頼りないものばかりだ
そんな状況がずっと続いている
このあたりが改善するには言語コアを設計する時点からどんなデバッグ機能が必要か考えるべきってのがおれの主張
作業フローを理解しない人が無邪気にこれが入ればさらにソースコード短く書けまっせレベルの議論で機能追加を考えるべきでない 機能を使うかどうかはお前の判断でお前の責任
勝手に機能使っておいて八つ当たりすんな ＞ほんと標準化プロセスは現実のプロダクト開発に関わったことのない言語オタクの遊び場に見えるわ
+1 江添みたいなのしかいない日本と違って、普通の国の委員は企業の代表として参加しているのでその指摘は的外れ >>503
関数になっているものを inline 展開する処理系は多数ありますが、
プログラマがせっかく展開して書いてあるものをわざわざ関数に戻す処理系
はめったにないのです。
また、そのような最適化は人間には簡単に思えるものですが、機械にやらせようと
するととても大変です。マクロ展開される前のマクロ関数の状態ならまだ
できるのですが、コンパイラの中で最適化層と前処理層がかけ離れた位置に
あるので、もしやりたければ最適化層だけでそれをやることになり処理がとても重くなります。
まず、コンパイル後に出来上がった中間コードのなかから同一のパターンを見出すのが
ものすごく時間が掛かります。それから全く同じではない場合への対処が機会は苦手です。 >>516
最後の２行とそれ以前が論理的に繋がってないぞ >>517
506で牽制しておいたはずなんだが
言わなきゃわからんのではなく、
言ってもわからんやつのようだな >>516
> 当然最適化の期待度は
> マクロ(直接記述)＞インライン関数＞通常の関数
現代のコンパイラの最適化機構はかなり複雑で、どのように最適化が効くか予想するのは無理。
素朴な処理系ならなんらかの傾向がある場合もあると思うけど、一般化できるような話ではないよ。
普通の関数はインライン関数より呼び出しのコストは確かに大きいけど、
全体のコードサイズが大きくなるとキャッシュメモリからあふれやすいといった話もあって、
トレードオフになってる要素がある。
それに、主要なコンパイラは inline キーワードで修飾してもしなくてもインライン化が効果的ならインライン化するし、
効果的でないならしないよ。
inline 関数として定義すれば各コンパイル単位の中に必ず定義もあるわけだから、
LTO が有効ではない状況では結果的にインライン化しやすい条件がととのっているとは言えるんだけど、
逆に言えば LTO を有効に出来るならどうでもよくなるわけだし。
いずれにしても、そんな微々たる速度が気になるような場合ってそんなにあるか？
速度が問題になってから実測しろよ。
状況によってどうとでもなるんだから、具体的な状況を示さずにどれが速いとか言ったってかみ合うわけないだろ。 >>525
一般的な期待度の話
当然例外はある
コンパイル単位が別で
関数を定数パラメーターでコールした場合
なんかが差が大きくなる
レジスタ退避やスタックポインタのアラインメント調整、スタック拡張、AVXの準備関数コール
もそれなりにオーバーヘッドとなる
同じコンパイル単位であれば
今のコンパイラではそれほど差は出ないが
組み込みのチープなコンパイラもまだまだ使われている >>501
お前さんは LISP のマクロを知らないのか？ 関数とマクロの違いがlispだとわかりやすいから。
わかってないやつをあぶりだすのにはちょうどいい。 >>518
よくわかんないので、SFINAEなりConceptなりconstexprなりをデバッグに配慮して設計していたら
どう問題を改善できていたと思うのか、教えて。 （CMakeスレがないっぽいので）
target_link_libraries(a.exe PRIVATE ${MPI_CXX_LIBRARIES})
↑${MPI_CXX_LIBRARIES}が定義されていなくても合法で、その場合何ともリンクしないということを期待してもＯＫ？
それとも
if(MPI_FOUND) target_link_libraries(...) endif()
とすべき？
公式を見てもよく分からない >>534
デバッグに配慮してたらそんな糞機能入れないだろうね。 >>534
まず現在の問題の構造を考えて欲しい
c++はtemplateを使ってメタプログラミングを行うのはご存知の通り
でtemplateはチューリング完全だ
それだけの複雑さを持っている
それに対して一般人がやるデバッグはコンパイルが通って期待通り動くかエラーメッセージを見るかぐらいだろ？
これは原始的なprintfデバッグを行っているのと同じレベル
なのでまずストレートに考えると
メタプログラミングの結果が取得できること
コンパイラにデバッガ接続可能にしてメタプログラミングの実行がトレースできること
が必要
これがベストなのかはさておき、メタでないプログラミングでは当たり前なんだから
SFINAEをどうするかみたいな話の前にまずこういうところを整備すべきだった
ハードウェア依存じゃないのだから標準モデルを定めるのは可能だ gotoを受け入れるとクリーンでわかりやすい実装が開ける。
・・・かもしれない。 >>539
> メタプログラミングの結果が取得できること
> コンパイラにデバッガ接続可能にしてメタプログラミングの実行がトレースできること
> が必要
あったらいいなとは思うけど、必要（＝可能になるまで機能を使わせるべきではない）とは思わないなぁ。
実行時プログラムについて言語規格側でデバッグのための特別な「標準モデル」が定められたりいてないけど、
現状でわりと使えるデバッガができてるし、コンパイラはあるけどデバッガは無いという環境や時代はあったし。
メタプログラミングだからといって機能追加に先立って特別な定めが要るという理屈はよくわからない。 >>540
470, 472も言っているが
gotoを使わないこと自体が目的化してはいけない
そういうアホがbreakは平気で使ったりする constexpr関数内でgoto使えないのだから、gotoを避けることを目的とせざるを得ない場面はある。 breakとgotoを同一視するのも問題なのでは。 >>544
同一視ってGOTO有害説の中では完全に同じだよ goto有害説ではbreakとgotoは違うもの扱いしているよ
breakで出来ないことがgotoで出来ること自体を問題視しているのだから gotoは使わないけどbreakは使うってのがgoto有害説じゃないの？
完全に別の扱いしているってことだろ >>546 も >>539 も同じタイプの馬鹿
選択の幅は広い方がいい
機能の存在を否定するのではなく、単にお前が使わなければいいだけ break でも goto でもそれを使わなかったときにもっと複雑になるのなら使っていいよ。
クソみてぇなフラグを立ててループから抜けるよりは break の方がマシだろ？
使わなくても十分に良いなら使わない方がいいに決まってるけど、要るときに使わないのは馬鹿げた話。
現実にはクソな道具が役に立つクソな状況があるんだよ。 do{...}while(0);
とかにしたくないとき
while(1){
...;
...;
break;
}
もたまに意図的に使う >>556
breakしなかった場合の動作が違うじゃねえかよ >>556
switch(1){
default:
} forやwhileもgotoのシンタックスシュガーだから使うなみたいな gotoって自由すぎて対応するlabelの場所によって意味が変わるから、自由に飛びたいとき以外に使うと分かりづらくなる。
breakやcontinueなら一連の処理の一部を飛ばすって意図がそれだけでわかるのだから、do{}while(0)だとgoto使うのと何を分かりやすくするかでトレードオフになる do{} から以後が、それまでの話と繋がってねえぞ
それから break と continue のGOTO有害説における違いもわかってねえな do while(0)+breakを使う->loopだと誤解する可能性がある
gotoを使う->labelの飛び先見ないと意図がわからない
ってどちらの分かりづらさを大きな問題とするかで、どちらが良いかの好みが別れる
これがトレードオフ まあdo while(0)と組み合わせるならcontinueの方が良い気もする
やっぱりretryしようと思ったときのために >>562
C++自体自由過ぎるから使わない方が良いぞ 自由だから使い所はその自由度が必要なときってだけなのだが。
forのかわりにgotoでループさせる奴は正気じゃない 関数もどこに飛ぶかわからないから
使いどころは必要な時だけだな
ポインタも同じ >>588
後者のbreakはifが付いてないので絶対breakするというなら一緒だが
しかし途中のどこかでcontinueが掛かれていると動作が変わる なぜか変なところへ安価が・・・
>>558
後者のbreakはifが付いてないので絶対breakするというなら一緒だが
しかし途中のどこかでcontinueが掛かれていると動作が変わる goto駆使してcoroutineというパターンは。 ループする気がないのにcontinueが入る可能性があるのか？
やっぱループ構文をループ以外の目的で使う奴はアホだわ >>564
どうでもいいが
do{}while(0);+continue;でもっと難読化するかも知れない >>552が答えを書かないのだが。
もしかして答えなんて持っていないのでは。 function();
何をするかわからないから関数は使うべきじゃない
pointer;
何を指し示すかわからないからポインタは使うべきじゃない >>577
あとで、しまったと思ったんだが
もう答えを書いてしまっていた
今んとこ、まだ伏せておきたいので
どこなのかは書かないから
自分で探せ >>553
とかいいつつ古い仕様の範囲で実用してる人をバカにして
マウント取って憂さ晴らしするんですねわかります >>564
どうせdo-whileなんて本来のループとして使うことはまずないんだから、あとは
ローカルルールとしてwhile(0)以外禁止とかにすれば十分かと。 gotoは高級の中にいきなり低級なことぶちこむから違和感あるんだろ
場当たり的で美しくないね まえにSQLパーサを書いたときはgotoがすごく便利だった。
文法をそのままソースに反映できる感じ。
goto嫌いな人たちはどうやって書くのか見てみたい。 そういえば、まだ構造化されてない昔のBASICは、構造化された今のBASICより人気があったのではないかと思うけど、行番号と goto 文の組み合わせはラベル名を考えなくて済むので便利であった。
そして、BASIC言語は分かり易くて易しい言語と言われていたのだから、goto文自体はそんなに理解や扱いが難しいものではない。
ただし、フローチャートを書いてから組まないと分かりにくいことがあったかも知れない。
逆に、今フローチャートを書く必要がある場面は少なくなったのはgoto分を使わずに書けるようになったからかも知れない。 ここまで無理やりな擁護してまで使うほどの機能じゃねーだろバカか。 gotoとかマクロとか話題に加齢臭漂ってるぞ
もうちょっと食いつく話題選べよ main関数が呼び出される前にグローバル変数が初期化されますが、
これの初期化順を変更することは可能なのでしょうか？ A、B、Cと言う順序で実行されるべき処理が
A、B、Cと言う順序で実行されれば良いのであって
それが上からA、B、Cの順で書いてあろうが
B, A, Cと書いてあるのをgotoでA、B、Cの実行順にしようが
スレッド1、2、3が同期をとりあってそれぞれA、B、Cの順で実行しようが
相違なるコールバック1、2、3がこの順で呼ばれるように仕組まれた上でそれぞれA、B、Cを実行しようが
B、Cの実行がラムダ式で書かれていてその定義がAより上にあってAの実行後に呼び出されようが
ぜんぜん問題ではない 一方gotoなど使わなくとももっと酷い糞はいくらでも作れるのだから
gotoが駄目だと言い張る奴は精神が弱って
いるな！ >>590
同じ翻訳単位にあれば上から
異なる翻訳単位のグローバル変数の初期化順序は未定義 >>590
やり方としては >>594 のとおり。
「同じ翻訳単位」とは要するに1個のソースファイルってことね。
でも一般的には「グローバル変数の初期化順序に依存すべきではない」
はずだけど、初期化順序を制御したい事情に興味があるわ。
もっと一般的には「グローバル変数を使うべきでない」だけど、それは別のお話。 初期化順序を制御したい事情なんていくらでもあるだろ
そういう事情があるにも関わらず
明示的な初期化処理で初期化しないのが問題なのであって >>585
SQLってBNFで書けるから普通にswitchで書けると思うけど >>589
ツール使ってテーブルを生成させるならありだと思う。
そうでないなら、文法拡張のためにテーブルに手を入れるとか考えるだけでも嫌にならない？
あと、メンテナ交代のためにつくるドキュメントとかも。
>>598
それな >>598
いや、わざわざgotoなんて使う必要ないって話な
C言語の時はエラー処理でgoto使う機会もあったけどC++なら例外で対処できるし
パーサーとか書いたことないとわからんかも知れんが >>599
ツール使うならコードまで生成させるだろ breakやらgotoやら、普通に関数作ってreturnすらば済む話なのになんでここまで盛り上がるかねぇ >>601
わざわざgotoってのが意味不明
使用リソースや所要時間は非常に少ない
ただのジャンプ命令だから
少なくとも
わざわざ関数に分けるとか
わざわざ変数を使うとか
に比べればはるかに軽い
breakに比べれば
記述量が多いので
｢わざわざ｣という表現を使うことはあるだろう >>604
そんなエラーをgoto文で書いてる様なc++ソース読むのやだわw throwと同様の構文でgotoと同じコード生成する機能があれば良いのに >>604
タイプ量が少ないソースがいいソースとか思ってそうw
いつの時代の人なんだよ わざわざ例外使わんでもgotoで十分なときも普通にある
gotoだから絶対ダメとか思ってそう
頭かたすぎ >>609
逆にわざわざgoto使う例外って何よ？
そんな個別情報も渡せない上にわざわざラベル名前まで考えて、goto文使う方がめんどくさいだろ
あーあれか、throwよりgotoの方が打つ文字少ないから楽とかかw throw って、入れる catch を RTTI を使って探すという
結構なコストのかかることをするが goto や longjmp にはそれがない 情報処理の教育を受けていると、大抵のものはステートマシンに見えるので、goto使いたくなるのかもしれない。
教育の有無で思考過程が違うので、使い道が理解できない人は使うことを禁じたほうが良い。
セキュリティにもかかわるので公安委員会直轄でgoto免許試験場を創設するべき。 >>615
一番上のリンクだけ見ましたが、これはミスリードじゃないだろか。 >>616
二番目のリンクも見ましたが、これはgoto代わりに例外を使うべきではないというお話ですよね。
例外の代わりにgoto使えという話ではないと思うんですよ。
「あれ？ifの代わりに例外使えるんじゃね？」とはならない。
同様に「あれ？gotoの代わりに例外使えるんじゃね？」ともなりません。 どれもしょぼいな。
本物のgoto使いはラベルを100個使うんですよ。 C++歴20年でこれか。。。例外が悲しいほどわかってない あーお前らなっちゃいねえ。
gotoの使い方わかっちゃいねえ。 gotoも例外も恐れなく使えと私は言いたい。
ただし、資格は必要でしょう。 以下は 良い goto 文の使い方だと聞いたことがある。
・二重以上のブロックを抜けるために goto 文を使うこと。
・エラー処理。 <--- こう言われていたのは throw がなかった時代からだが、
今でも throw, catch を使うより効率が良いので使っても良い
と思われる。 >>622
はいはい、そういう人には、状態遷移図を書く癖をつけることをお勧めしていますよ。 ラムダ万能説
>>615 の1つ目の2など途中で打ち切りたいときはラムダさえあればgotoも例外もいらないことがわかる
if( [?]{
...
if(//エラー発生時){
return false;
}
...
return true;
}()
&&
...
&& [?]{
...
if(//エラー発生時){
return false;
}
...
return true;
}() ){
//正常終了
}
else{
//異常終了
} >>613
だから例外処理にまで速度にこだわる意味は何だよ
if文と勘違いしてんじゃね
そんな特殊な状況を一般化するんじゃねぇよ if goto
if throw
となるわけでifと例外を比べるのはおかしい
>>626
「こだわる」とか「特殊」とかバイアス満載で話にならんな そもそも有名どころのコンパイラがだいたい例外禁止オプション持ってるのがどういう意味か考えてみろよ goto使わないで2重ループを抜けるのってどうするの？ >>628
throwが速いのは呼び出した関数がthrowする場合と戻り値で成否を返す場合の呼び出し元コード側の話だろ
余分な条件分岐命令が出力されない
代わりに例外発生時にスタック解析して例外処理用コード探すから物凄い時間がかかるが goto 賛成派の意見
「例外使え」←「ネストが増えるから嫌」
「break使え」←「深い所から出るのに無駄なフラグ増やしたくない」 ちげーよ
「例外使え」←言われなくても使ってるよ、gotoを禁止する理由になってねえ goto禁止派はgotoの使い方を知らないだけ
知ってたら禁止しない gotoと例外のどちらかを禁止するなら例外を禁止したい Windowsの64bit環境って例外めちゃくちゃ遅いんだよね
例外が発生しない時はオーバーヘッド無いんだけど
32bitだと関数コールの度にオーバーヘッドが発生する
だから例外処理OFF機能がある 確かに現状のC++例外はちょっと好かんところがある
いっそnested_exceptionとdynamic_castだけに統一したらどうだと思ったりする おまえら全員間違ってる。
gotoは免許制にするべきで、一律に禁止するものでも許可するものでもない。
試験に合格した者だけ使うべき。 「もういいよ。オレがインデックス張ってやるから、まあ見てから言えよ。な？」 まだしょうもないこと言い続けてんのかよ。
こういう糞議論を排除するってだけでもgotoを禁止する価値はあるな。 goto使いたいものが100万人いれば、更新費用1万円として100億になる。
gotoで事故を起こした場合、行政処分がある。
取り締まるためにgoto警察も必要。 gotoじゃなくおまえらを排除すれば
問題の本質がわからんやつによる不毛な喧嘩≠議論はなくなる
化学調味料の永久ループと寸分違わねえ なんでプログラマってこんな糞みたいな話題で延々と盛り上がるんだろうね
って、実は知ってるくせにってか >>614
ステートマシンでgotoって次のステートに直接飛ぶとか言ってるのか？ ダイクストラの時代にとっくに決着した話をまだダラダラやってんのか 煽り9割マジ1割
ここはそうゆうインターネットです 絶対禁止と思っているやつは全員不合格
つーより事前審査で門前払い 絶対禁止と本気で思ってるヤツはいないだろ
gotoが無ければ2重ループも抜けられない gotoおじさん達いい加減にこの話終わりにしてくれない？
久しぶりに自分が参加できる話題だからってはりきりすぎでしょ Open Jane がDelphiで書かれたように
5ちゃんねるブラウザがC++で書かれたら
嬉しいんだけどね >>657
今は他に話題ないし
話題がないと数日レス止まるようなスレじゃけえ 江添亮の本でstd::cout<<""にs付けろって書いてたんだけどsつけたらエラーになる >>657
久しぶりに笑う健康法ができてありがたかったんだよ
おーい芸人さんたち、アンコール！ アンコール！ >>664
#include <string>
using namespace std::literals::string_literals; とまあこのように、江添先生の本は、すべて理解してる人にしか理解できません。 幼稚園児が大学の図書館へ行っても読める本ないのと同じだな
無理しないで「ぐりとぐら」くらいから始めとけ 残念、俺は江添じゃない
興味のツボは奴と似てるとこあるけどね 普通の文字列リテラルが char 型の配列であるというのは (初心者には) 分かり難いので、
いっそ一貫して std::string 型で扱うというのは悪くない方針だと思う。
だけどユーザー定義リテラルという枠組みもそれはそれでだいぶんアレな仕様なんで、どちらにしてもクソだよな。 こんばんは、後藤です。
ところで ""s だけでは片手落ちな気がする
ちゃんと u""s みたいに文字コード指定しなかったら
string_literalsを使う意味ないような気がするんだけど
わしだけか >>656
関数で切り出してreturnしろカスが。 uがなかった時代でもなんとかなってたんだから意味なくはないだろ 江添本は初心者向けと謳っていながらこのくらいわからん奴は帰れみたいな意思を感じる 初心者に内容を理解してほしいんじゃなくて俺すげーってことだけ理解しろってスタンスだからな。
むしろ理解されると大したことやってないのがバレると思ってるくらいだろ。 C++はしたことがないが数学博士号のやつと高校卒業を一緒くたにするのが問題だろう
それぞれの学力で開始すべき章を設定するべきだ
できないとしたら著者の無能なので落胆することはない 初心者がC++に入り込まないよう防御壁として江添先生が存在するのではないか。 C++の道を行きたいなら、俺を倒してから行け。
ってことでは。 張り合ったら明らかにプログラム書けなくなるだろ。。誤誘導すぎるわ。 C++の前に立ちはだかる屈強な門番。
俺を倒せるものでなければ入門を認めぬ。 グダグダな C++ をグダグダじゃなく説明するのは無理だろ。
どの本を見たって少なからずグダグダか物足りないかどっちか。 まぁ、実際の現場だと、c++なんてちょっと便利なC言語としてしか使われてないよ
未だにcharポインタやmalloc乱立してるし参照型すら使われてない。
クラスなんて関数まとめるnamespace代わりだし ひと昔前にstaticおじさんの話がバズったことあるけど、
たぶん現実にはけっこういるんだろうな。 ちゅうか、C++ 使うなら charポインタは必須だ。
使いたくないなら 別の言語を使ったほうがいい。 Cのライブラリを使わない限り文字情報はすべてstringで済む
モダンC++の仕様はそういう範囲内での使用も許容している c++ではchar*は文字列とは関係ない場面でよく使う >>684
＞クラスなんて関数まとめるnamespace代わりだし
さすがにそれはダメだと思うが・・
そういう現場確かにあるが
>>688
とか言いながらstringは途中からnull終端を保証したりして、
結局Cの資産を無視できなかったという もともとc_strはnull終端されてた
それに合法的にnull文字を含むことが出来る時点でnull終端ではない >>684
私のことですね…
new をグローバルオーバーロードしたら、その中では malloc() するしかないですからね… >>693
> >>684
> 私のことですね…
> new をグローバルオーバーロードしたら、その中では malloc() するしかないですからね…
するしかない？
mallocはどうやって実装されてると思う？ >>693
おまえさ、何のために new をグローバルオーバーロードしてるの？
malloc でいいんなら、そんな必要ねえだろ
おまえアホか まぁデバッグの手法としてなくはない
ただその手のものは既存のものが腐るほどあるからそれ使った方がいい >>694
＞するしかない？
ええ、するしかないと思いますよ
>>695
＞何のために new をグローバルオーバーロードしてるの？
無論 delete と対になっているかどうかをチェックするためですよ、こういうのは自分では出来ていると思っていても時々お漏らししてしまいますからね
まあ、C++11 以降は手抜きして make_shared することを覚えてしまってずいぶんと時間が経ちましたが、それでも生ポを使うときは new/delete をオーバーロードしますね
https://mevius.5ch.net/test/read.cgi/tech/1434079972/51 line.143～150 >>696
昔の borland c++ にはまさしくそのための、なんていうんだったんでしたっけ、そういうコンパイルスイッチがあって便利に使っていましたが、
今評価版を入手すると、それは clang ベースに変更されて、その機能がなくなってしまったんですよね… >>698
思い出した、bcc32 CodeGuard でしたっけ >>697
それなりにプログラマ経験あるんだと思ってたけどmallocの中身知らないとはね
別にメモリ確保のsyscall直接使ってもいいんだぞ
むしろnewをリプレースしたい場合ってページ単位で処理したいときとかでしょ
ちなみにこれはデバッグで使うのも有用だぞ
unmapしてるところにアクセスしたらその時点で例外で止まるから原因特定が容易
まぁそんなの自前でやる前にValgrindでも使えって話だけど >>697
アプリケーションの層ではアロケータを書く機会はまずないから
やったことないのは別にいいけど、
さすがに new の本質はメモリの割り当てだってのはわかってて欲しいわ。 >>700
＞それなりにプログラマ経験あるんだと思ってたけどmallocの中身知らないとはね
専ら win32api でやっているので、：：HeapAlloc(：：GetProcessHeap(), ...) とか ：：HeapFree(：：GetProcessHeap(), ...) だとは考えていましたし、数年前はそう置き換えていたこともありました。
＞unmapしてるところにアクセスしたらその時点で例外で止まるから原因特定が容易
これは初耳です。よろしければ、もう少しキーワードだけでいいので羅列していただけませんか 関数で切り出すのは入出力がはっきりするというメリットはあるが
ループの内と外の依存性が高い場合に内を無理矢理関数分けすると
シグネチャに入力引数と出力引数（参照渡し）がぞろぞろ並ぶことになって
それはそれでお勧めしない
（関数の意味も不明確になりがちやし… >>702
そうだよwindowsならそのあたりだよ
あとVirtualAllocね
> ＞unmapしてるところにアクセスしたらその時点で例外で止まるから原因特定が容易
> これは初耳です。よろしければ、もう少しキーワードだけでいいので羅列していただけませんか
new/deleteのたびにページ単位で確保・解放するんだよ
それこそVirtualAllocで
だから重いよ
そうするとdangling pointerでヒープ壊される問題があった場合、
壊しにいったら即セグフォルで止まるからデバッガつなげれば犯人特定できる >>686
そんな職場は大変だぞ
構造体だからって、triviallycopyableを満たさないクラスをわざわざvoidポインタに格納して、memcpyしたり
クラスをわざわざmallocしてコンストラクタ、デストラクタ飛ばしたり
const属性をキャストでわざわざ消して値変えられたり ベターCなどとほざく連中がいかに馬鹿で愚かで有害かがよくわかる まあそんなやつは C もまともに使えてなかったりするんだけどな。 中途半端にc++を持ち込んで現場を荒らすやつもいるからね
>>706 の状況はそういうところで見たことある
別にc++が書けるのがえらいわけじゃない
質の良いプロダクトをきっちり仕上げられる奴がえらい
まわりがc++わからないメンバーならcで書くか、
c++が必要というなら十分にチームでトレーニング行ってからだ C から段階的に学んでいける (業務を止めずに) って D&E には書いてあるけど、
今の C++ じゃもう無理だと思うわ。 C++ は C++ としてそこそこの訓練はいるよな。 はちみつ餃子がでてくると、どうもこんな時間に腹が減ってきていかん >>706
それは問題。
でも、STLべったりのC++は Cとの書き方の乖離が激しすぎて、もはやCの冠を被ってほしくない。 >>714
関数切り出しできないと大変だね。(特に周りの人たちが。) >>716
CはCらしく、C++はC++らしく使えばよろしい
CをPascalっぽく使うやつとかすげー迷惑なのと同じ テンプレートメタプログラミングはC++らしいとも思うけど全然別の言語になっている気がしないでもない >>705
情報ありがとうございます
::VirtualAlloc() 系は書いてあることが難しい上に、ばっちゃの遺言「::HeapAlloc() を使え」もあって敬遠していましたが、ここで教えてもらったのもなにかの縁だからデバッグ用に試行してみようと思います
win32api の criticalsection と signal でやっていた（何かがまずくてstarvationに悩まされていました）のも
C++11 になって pthread が大幅に規格に取り込まれた以上、
C++11 の上からの mutex・cond 派に切り替えようか、とか、C++11 になってスタイル変更を考え中です >>717
ループを抜ける為に関数を分けるようなアホと一緒に組むと大変だ 確かに大変だね
if breakしてる複合文を関数にするときにreturnとか言い出すやつは
longjmpだろうがって >>720
実際、別言語だと思う。
C++はtemplateや演算子のオーバーライドを使えば、ほぼ別言語をみなせるようなものを上に載せられる設計になっているので。
STLを使いまくるプログラミングの書き方だと、もはやCとは何の関連性もなくなってしまっている。 >>723
ループ抜け出すぐらいでそんな苦労するようなコードになってるなら
関数で抜け出すのが当然だろカスが。
いくら脳みそ足らなくてもgoto擁護のために無理筋言ってるってことにそろそろ気づけ。 ネストするなら別のプログラムに切り分けましょう。
シェルから呼び出せばいいのです。 >>725
もともとCってマクロで何でもやりたい放題の言語だぞ
http://www.pro.or.jp/~fuji/computerbooks/c/c.modula2.html >>727
｢gotoダメ！絶対！教｣の戒律を破ることじゃないかな。きっと身を裂かれるほどの苦しみなんだろうw いったん収まったと思ったら
また goto の話開始してて草
アスペ特融の拘りと言われても仕方がないな gotoの話で叩きのめされたやつが話題を変えたいのはわかったよ(ﾆﾔﾆﾔ >>729
たしかにCもマクロを使えば結構何でも出来る。
だが、マクロを多用すると分かりにくくなるとも言われていたし、使い方によっては、ソースコードが全く別言語のようになってしまうことも知られていた。
それと同様の現象がSTLにおいては起きる事態になってしまっている。 >>734
なってねえよ
おまえさんにはSTLがIOCCCに見えるのか
慣れの問題と言いたいがおまえさんは極端すぎ
一種の病気だ >>736
STLの作者は、自分では分かり易くしようとしているようでいて実際には逆に分かりにくくしてしまっている。 STLは神がかってるけどな。
あの時代によく設計できたな。 >>735
自分で好きなようにプリプロセッサを実装すればいいんじゃね？ >>737
その分かりにくいの主語は、世間一般ではなくお前個人なんだろ。 >>738
だよな
Cではmemsetやqsortにvoid*というリスキーなことをせざるを得なかったのを
関数テンプレートで型情報をきちんと面倒見るようにできたし
リニアサーチがない等のCライブラリの不備も解消した
そこに気付かないやつはプログラマとしての資質を問われる >>738, >>742
あのな、STLは設計構想から含めると十年から数十年かかってんだよ
それだけよく考え抜かれたものが優れてないわけがない
これ何回も書いたんだけどな
「最新仕様追ってる俺スゲー」したいだけの奴の希望的観測はもうこりごりだわ 最新仕様とか書いたらSTLが最新？とか言われそうなんで先に言っとくけど
マクロ(プリプロセス時メタプログラミング)を貶してテンプレートは持て囃すのはダブスタってことなんで誤解なきよう ただ俺としては右辺値参照の発見にノーベル賞を授与するべきだと思うんだよな。
これ人類史上でも大きな発見じゃないかと思うんだよな。 >>743
742だが、おまえさんは俺が何がわかっていないと言いたいんだ？
どっかの馬の骨が何回書いたかなんて興味ねえが
当たり前のことをドヤられる意味がわからんぞ STLにノーベル文学賞なんてオサレだと思わないか。 >>746
同感
そもそも左辺値参照にconstをつけたら右辺値を指せるなんて
珍妙なルールが招いた禍根を何とかする苦肉の策が右辺値参照だかんな
今ふり返って見るとconstなしの左辺値参照でもテンポラリを束縛できて
それを禁止したい場合のキーワードがあればよかったんだと思う >>745
互換性を失わない形で性能にも寄与するのはすごい思い付きだと私も思った。
スマートポインタが充実する方向で良くなると思っていたので、
まさか参照を区別する形でコピーを避けるとは思いもよらなかった。
だけどなぁ……。 結局は後付けなんだよね。
互換性を捨てられないという制約の中ではこれ以上ない発明ではあっても、色々と不満はあるよ。
ムーブ自体は言語のコアに組み込まれた機能ではないから
ムーブ後の抜け殻をうっかりいじってもコンパイラは黙って通しちゃうし。
ムーブできるようにしようとすると実質としてはポインタの入れ替えになるから、
各クラス向けにカスタマイズしたスマートポインタを書いてるみたいなもんだ。
本来ならそんなのコンパイラの最適化で頑張ってなんとかすべきことだろ。
言語処理系の敗北の証にすら見える。
いや、良いとは思ってるんだよ。
間違いなく rvalue 参照は素晴らしい発明で、 C++ をより良くした。
でもまあいいことばかりでもないよねっていうちょっとした愚痴。 構造体/クラスを戻り値にするっていう発想が無かった時代からのつぎはぎ拡張だから そもそも構造体を=でコピー出来るのが始まりだからな
配列は=でコピーできないのにな
その辺一貫性なかった>C言語 >>754
配列は (その先頭要素を指す) ポインタに型変換されるルールを入れてしまったので
それと辻褄の合う形には出来なかったんだと思う。 もしCが
構造体を参照するとポインタ相当になります
引数で渡すときも&つけなくても勝手にポインタになります
コピーするときはmemcpyしてください
って仕様だったらC++はどうなってたんだろうな
色々まずいことになるのは確か ↑ただ、モダンな言語はむしろそういう仕様なんだよな
その代わりGCがあるが
しかし、それはそれで不便なのであった >>744
おまえさんは
#define STR char* //と、
typedef char* STR; //の違いが
わかってなさそうに見えてしまうが
違うよな？
コンパイラでないものによる字面の読み替えと
コンパイラによる意味の読み替えを
区別するのはダブスタか？ >>758
そういうのじゃなくて、>>734に対して>>736書いたよな？
慣れ、ってのはわからんでもないがSTLの成功にはっちゃけて何でもテンプレートでどうにかする
今の風潮は俺もどうかと思うので。
もちろんマクロでメタプログラミングするよりは遥かに楽だけど、方向性としては同じようなもんだろ というかVCだとプリプロセスだけ済ませたソース見れるから、
時にテンプレートよりデバッグ楽かもしれない >>759
質問に答えてないな
字面の読み替えは評判悪く
意味の読み替えが広く受け入れられているのは
ダブスタか？ マクロを殺すためにどんだけ苦労してきたと思ってんだよ。 >>761
それをダブスタとは思わないし言ってもないんだが
>>762
だったら尚のこと歴史に学べよ >>766
アンカーぐらいちゃんと付けろよボケ
＞そこに気付かないやつはプログラマとしての資質を問われる
これは>>734に対する発言だよな？
俺じゃなくてお前が相手の発言を矮小化してバカにしてると気付け >>767
734と俺の問題は
おまえさんと俺の問題とは別だ
話を逸らすな
744の発言をおまえさんは貫くのか撤回するのか
立場を明らかにせよ どんな脳味噌と見て貰っても結構だ
744のダブスタ発言をおまえさんは貫くのか撤回するのか
立場を明らかにせよ Cと違うことを理由にC++を否定する奴たまにいるけど何なん？
なんでCを使わないんだ？ お前の都合のいい解釈(プリプロセス時ではなく型の文脈の問題までマクロでどうにかしていたのをtypedefやテンプレートに置き換える)を
そもそもダブスタとは言ってないんで貫くと取ってもらっていいが
それより>>759-760に対する回答はまだなの？ >>771
メタプログラミングとして見るとやってることは一緒なんだが
言語としての出来不出来は別として(個人的には>>735に同意 C言語にこそ、UnifideCallSyntax必要だと思うのだけど、入らないかねー。
関数オーバーロードと一緒に入ったらクラスなんかいらねっ。 c++の専門家の皆さんに質問ですが
using F = int(int)
のように 戻りの型(引数の型) の形式で関数型を書けるようになったのってどのc++からなの？
あとこれを書ける場所ってusingとtemplate以外にある？ >>773
> プリプロセス時ではなく型の文脈の問題までマクロでどうにかしていた
プリプロセス以外でマクロでどうにかするって意味がわからない
よって「ダブスタとは言ってない」の意味も俺には（おそらく、ここの誰にも）通じてない
744のダブスタ発言をおまえさんは貫くのか撤回するのか
立場を明らかにせよ 相手に嫌な思いをさせたいだけの議論は辞めろ気持ち悪い
プリプロセス時の問題に遭遇したことが無いのならお前の方が資質に欠けるし経験も足りてない
>>734の言うことも俺の言う事もそら理解出来んだろう
話にならんよ c++11以降において「マクロをリッチにする」ってことの代替が
テンプレート、constexpr をリッチにするって方向だろう。
正しい方向だとは思わんが、方向性なり答えはうちだしてはいる。 それはそれとしてプリプロセス時プログラミングもやりやすくして欲しいってだけのことだよ
(現実的に叶うとは思ってないが) c++の専門家の皆さま教えて下さい
auto a = +[](int b) { return b;};
このaの型は何ですか？
困っているので秒速でお願いします >>778
間違いを認めることができない未熟者には
嫌な思いからも学ぶべき教訓があるんだよ
やめてくれえ、気持ち悪いいい、それで？
命令口調では許してやらんぞ >>783 int型。
---
君たちひまそうだね。暇だったら、こっちのソースでも見てくれないか？
https://github.com/katahiromz/ImagePocke/blob/master/ImagePocke.cpp
C++/Win32で書いてるんだけど。
ここからドロップした画像ファイルを表示可能にする予定。
画像読み込みにGDI+を使う予定。 静かになったなw
>>789
関数ポインタ
ttps://wandbox.org/permlink/zLH8pFOt3tLJhujk ラムダに+をつけると関数ポインタになるなんてcppreferenceにもないけど常識なの？ そうなんだよね
この仕様がどこで決められてるものかがよくわからない
ぐぐったら
ttps://stackoverflow.com/questions/18889028/a-positive-lambda-what-sorcery-is-this
というのが見つかってなんか built-in overload らしいんだけど
結局のところ関数オブジェクトに対する仕様がどこに書かれているのかよくわからない
でもわりとよく使ってる >>791
・ キャプチャしている変数がないクロージャは関数ポインタに変換可能であり、関数ポインタが必要なところでは暗黙に型変換される
・ クロージャに単項 + を適用することはできない (ので関数ポインタに型変換してから解釈される)
という合わせ技によって関数ポインタになる。
(キャプチャしてる変数があるときは変換できないよ) 関数オブジェクトには関数ポインタへの暗黙の変換が存在して
operator+(T*)がそれ自身を返すからということね まじで？
たまたまできるってことなのか
なんか今後使うのためらうわw >>795
専用の、クロージャをポインタに変換する機能というわけではないという意味ではたまたまだけど、
ちゃんと保証された動作なのでためらわなくていいと思うなぁ。 >>796
もし今後関数オブジェクトに他の暗黙変換が追加されたらって考えると気が引ける
まぁ使うんだけどさ >>776
実験してないので間違ってるかもしれないが、
(型名)ptr で関数ポインタへキャストする場合、
( int(*)(int) )ptr
と書いても良いが、
( int(int) )ptr
と書いても良かったかも知れない。というのは、
typedef int (*FUNC)(int);
と書いても良いし、
typedef int FUNC(int);
と書いてもよかったり、関数型のポインタ pFunc に対して、
(*pFunc)(123);
と書いても良いし、
pFunc(123);
と書いても良い、とか。 >>776
C89 から関数型の表記としては解釈されるかと。
コンパイルが通る文脈は C++ まで無かったかもしれんけど。
C++ でも今のところ using とテンプレート引数以外では使えなさそう。 >>799
一部、コンパイラが故意にエラーにする可能性は有るが、
int(*ptr)(int);
は、関数へのポインタ型の変数ptrの宣言。
int(*)(int)
は「関数へのポインタ型」そのもの。
int func(int);
は、関数のプロトタイプ宣言だが、内部処理的には関数型の変数 func を定義しているような
解釈がされた後、関数型の場合の特別な処理として変数ではなくプロトタイプ宣言に特別
処理がされる。そして、
int(int)
は「関数型」そのもの、という解釈になる。
よく見るとこれらに対抗関係が有ることが分かる。
なお、最後のint(int)はコンパイラの内部処理的には関数型そのものだという解釈になるが、
コンパイラがその場合に特別にエラーを出す処理系と出さない処理系があるかもしれない。 >>801
何が言いたかったというと、戻り値(引数型) を解釈する新しい仕様が追加された
というより、数学の数式のようにみたときに一貫した規則に従っていることが
わかるということ。言葉で言えば、
「定義文に置いて、名前を除去すると型名になる」
という規則。
int func(int);
という定義文に置いて、名前であるのは func。だから、funcを除去した、
int(int)
は、funcの型名になる。名前funcの型は、「関数型」だから、これは関数型
という型名そのものとなる。
int a;
の場合、名前であるのは a で、aの型は、int型。だから、この定義文から
名前を除去した int は、int型ということになる。
int (*pFunc)(int);
の場合も、pFuncという変数の定義文であるが、この定義文における名前とは
pFuncであるので、pFuncを除去したところの
int (*)(int);
は、pFuncの型であるところの、「関数へのポインタ型」となる。
つまり、同じ法則にしたがっている。 関数型が暗黙に関数ポインタ型に型変換されるルールで引っ掛かってるってことかな？
関数型そのものは C++ が出現した最初から存在すると思うよ。 C にもあるもの。
こういう特殊な変換ルールを強制するために std::decay がある。 >>776
typeid で使ってもコンパイル通った。 RustってどれくらいC++に取って代わるんろうか
互換性以外でC++使う意味ない、みたいな時代はくる？ C++のライブラリはC++からしか使えないから最高なんです
何故ならヘッダという古臭い仕組みを採用しているからww
なおCOMは >>798
そりゃauto使いたいからじゃない
その理屈ならそもそもlambda使わずに普通の関数書けばいいってなる >>783
[](int b) { return b;}; だけなら明らかにラムダ式の関数ポインタだけど
それをオーバーロードか何かの+で虚無と足し算してんの？
*[](int b) { return b;};
これは掛け算でもするの？ 関数ポインタではない
スマートオブジェクトへのポインタだ
ただの関数ポインタならファンクタとして機能しない ラムダはデリゲートじゃねー。一個しか保持できんわな。
と遅レス。 ステートレスラムダって用語が出てこないんだね
stateless lambda >>804
template <typename F>
void test(F&&) { cout << 1; }
void test(int(*)()) { cout << 2; }
int func() { return 0; }
int main()
{
test(func); //2
test([]{ return 0; }); //1
}
ステートレスラムダを関数ポインタに渡すのはconversionで
関数を関数ポインタに渡すときのlvalue translationとは違う lvalue transformationだ、これは失礼 g++だと、これ通るｗ
auto closure = []{ return 0; };
using funcp = int(*)();
test(closure.operator funcp()); >>814
ワイはどちらかというとはちみつより餃子の方にアイデンティティがあるので…・… >>812
×スマートオブジェクトへのポインタだ
○スマートオブジェクトだ しょうもないシンタックスシュガーの話が好きな奴多いね。 >>827
踊るポンポコリンの｢インチキおじさん登場｣を思い出した。あんまり間違ってないだろう。 物事は適切に伝えろ
それが出来ないなら口を開けるなカスども ラムダが関数ポインタとかほざいてるカスが居てびっくりしたわ 個人的にはテンプレートなのに糞のSTLよりも
マクロωのQtの方がうまくやれてる実用的だと思う まあ個人的な感想は個人的な感想だからなぁ。
俺は Qt に対してなんやこのクソはとしか思わんが、
広く使われている現実がある以上は実用性は高いんだろう。 たぶん。 >>835
ああ、usingを使うべきだったな
typedefなんてダセーもんもういらねえって
頭ではわかってるんだが長年の癖でぽろっと出ちまう マクロを名前空間に閉じ込められるようになれば、マクロの害悪の何割かは減らせるはず。 ということは名前空間をプリプロセッサが処理せにゃあかんな
translation phaseを根本的にぶっ壊さないと無理だと思うが typedefが駄目で、usingが好まれる理由を教えてください。 否定的な視点から散々な言われ方をされがちなC/C++のマクロだけど、
Java/C#/Python/Pwel/Rubyに似たテキスト変換がないことに物足りなさを感じることが多いのも事実。 >>841
私が思いつくのは
・ using は名前を導入するという一巻した意味規則がわかりやすいから
・ using はテンプレートに出来るから
・ typedef だと複雑な型定義をするときに肝心の新しい名前が中の方にあって見づらい typo。PwelじゃなくてPerl。Perlはめっきり影が薄くなった。
PerlはGit for Windowsにバンドルされているので世の中の大部分のプログラマーがすぐに使える環境にあるのだが、
Git本体はPerl依存を減らす方向に進んでいるらしい。 >>842
Cプリプロセッサを Java やら Python やらにつこうてもええんやで。
そういえば cpp を使うことを (習慣的に) 想定してる言語って C/C++ を除けばHaskell (GHC) くらい？
汎用プリプロセッサとして使うなら M4 あたりの方が賢いしなぁ……。 >>841
たとえばこういう場合
#define STR char*
STR a, b; //これ、どうなる？
もしこうなっていたら
using STR = char*;
STR a, b; //これはどうだ？
おまえさんの好みに合うのはどっちだ？
そこに答えがある >>841
あ、すまんtypedefか
typedef 内容ごちゃごちゃ 名前;
using 名前 = 内容ごちゃごちゃ;
体裁が揃えやすいのはどっちだと思う？ typedef も using もエイリアスという点では
char * と STR の区別が出来ないから後で困る 関数ポインタの別名を作るときなんぞ
typedef int (*funcp)(); //内容ごちゃ名前ごちゃ
using funcp = int(*)(); //名前 = 内容ごちゃごちゃ
という違いが出る でもまあヘッダファイルを C と C++ の両方で (マクロで少し切り分けて) 使いたいってことはあるから、
そういうときは typedef にしといた方が共用できる部分が多くて楽ってことはある。 >>849
そこだけだと構文糖衣以上のメリットはないよね >>849
ポインタまわりはテンプレートの記法で書けば統一的でわかりやすい気がするが、
たぶん他の名前とかぶらないようにするためか長めの名前なのがちょっとなぁ……。
using funcp = std::add_pointer_t<int(void)>; >>842
PL/1はいいぞ
制御構文としてif程度しか使えないしょぼいC/C++マクロと違ってプリプロセッサでDOループやGOTOとかも使えるしサブルーチンの定義すらできるぞw
https://en.m.wikipedia.org/wiki/PL/I_preprocessor そういえば最近Boost.Preprocessorを使った楽しい黒魔術の話題を聞かない気がする
あれってまだ開発継続してるの？ >>849
typedefの方が簡単じゃん
コピペして＊付けて（）付けるだけ >>852
おまえさ、usingはテンプレートにできること、まさか知らないの？ CPPってもうメンテされていないようで怖い
#define FOO 123 // comment
とはとうてい恐ろしくてどうしても書けず、
#define FOO 123 /* comment */
と書いてしまうま N4713
5.2 Phases of translation
3
Each comment is replaced by one space character. New-line characters are retained. >>860
そこだけって書いてあるのに脳内で読み飛ばずのは
国語の成績悪かったやつの特徴 >>864
おい852本人、「構文糖衣以上のメリットはない」という自分の言葉から逃げるのに
そういう言い訳は見苦しいぞ
今さら吐いた唾を飲むなよ 俺は争いは好まないが、
平和的な話し方をしないやつには
場合にもよるが嫌悪感を露にすることもある 平和を愛するという点で共感が得られず
こちらが下手に出ることのベネフィットがない相手には容赦は無用ということだ 戦士と戦士が巡り合ってしまうと、バトル・フィールドが形成されるシステムってことか。 >>870=ID:VrR0aqw1
マウント取りたいだけの初心者だから相手しない方がいい >>867
多くのC++民が喧嘩腰なのでなく、一部の喧嘩好きの戦闘民族のレスが目立ってるだけじゃね。このスレから相手に勝つことだけが目的の無意味なレスの応酬を取り除いたら、1/10も残らないと思うぞ。 いや最近のC++に対するちょっと否定的な意見が出ただけで
過剰反応する住民のせいでもあると思うぞ
で、そういう奴に限って間違いを素直に認めたりなどしないからな(代理戦争で議論するやつ特有のパターン >>872
正直に言えよ、「gotoの何が悪いのか詰問されると困るから」相手しないと
マウント取られそうでヤバいんだろｗ 俺ID:loc7kxiYだからgotoの話はしてないよ
で、前にも聞いたけど反論まだ？ ああ、そのIDのときはSTLの話だったな
そこでマクロの話も出てきていたが
隠すべきものと隠してはならないものの区別がつかない点で
gotoの何が悪いのかわかってないやつとプロファイリングが一致するんだよ
俺の正直な気持ちを教えといてやる
マウント取りたいんじゃなく、頭からアホにしてんだよ
こんなやつをマウントできたからって偉くも何ともねえ いやSTLじゃなくてテンプレートを持て囃しすぎって話だったんだが
まぁいいや なんかおかしなのがいるよね
圧倒的にこっちが勝っている状態で意味不明な反論？してきて意味不明だから返せないと逃げたとか言う奴 明日早いから失礼するとは言ったが
それを謎変換せにゃならん切羽詰まったやつがいるのかｗ gotoは初期化を飛び越えることが出来ないと聞きました。 初期化を飛び越えることができるバーストモードgotoないでしょうか。 465のlongj【u】mp野郎まだいたのかｗｗｗ バカほど多くの機能を使いたがるってのがプログラマーが解決しなければならん問題だな。 使いどころが悪いって指摘ならまだしも、ある機能を使い所で使うなとか言うのは結局俺が分からんからってだけだよね 使いどころが本当に正しいか頭使って考えてりゃね。
バカは流行りだから、なんかカッケーから以上に何も考えてないから
レガシー化するわけだ。
んでまた新しいものに飛びついていく。 仕事ならそのコードがメンテできる人が他にどれだけいるかで考える メンテできるやつが「オレ」以外の全員でもか？ アホｗバカｗｗｗ C++03しか知らないんだけど
C++17まで修めるにはつるピカ先生の御本を読めばいいですか？ つるぴか先生の本は聖典だ
お守りのようなものなので読まなくても買って横においときなさい cppreferenceは循環参照みたいになってて使い辛い 実際にお互いに連携するからそう綺麗に木構造にはならんのやで。 １つの情報源しか見てないとサイトから脳へバグが伝染るぞ cppreferenceは調べるためのサイトじゃなくて
忘れてたことを思い出すためのサイトって意味なら
まあまあ同意 ネットじゃなく、ローカルに俺メモを作るのは基本だね 作らなくてもcppreferenceをcloneすればいいじゃないか 脳内の理解を、きちんと清書してみると
自分の言ってることがおかしいのに気付くことがよくあるんだよ 最近の俺はそう言われても仕方ないアホなことをよくやらかすが
まだ若く元気だった頃から、俺メモでセルフチェックはやってるよ 女子社員のメモを集めたら最強マニュアルができたなんてエピソード昔聞いたことある ビャーネ・ストラウストラップ の第四版は、C++11までですよね？ そら当たり前でんがな
承知の上で読む分には何も問題ないけどな 質問者は、C++17まで収めたいと思っているようですが。 C++11 までわかってればあとは cpprefjp で差分を見れば充分でしょ。 03→11の乖離は大きいが14、17はそれほどでもない
20、23でまた大きく変わるが しかしメジャー２連くるかねえ
段階的変更という大人の配慮を忘れたら
C++終わると思うが コンセプトとモジュールの導入は C++er の悲願だと思っていたがそうでもないの？
クソみたいなマクロを殺すのがだいぶん上手くいったから次はクソみたいな SFINAE を殺そうという動きだと理解してる。 > ポインタライクなオブジェクトからアドレスを取得する std::to_address() 関数 (P0653R2)
> ポインタライクなオブジェクトを引数にとり、それが表すのと同じアドレスを生ポインタで返す関数
> std::to_address(p) が追加されます。オブジェクトがポインタ型の場合はその値を返し、それ以外の場合、
> std::pointer_traits<Ptr>::to_address(p) の特殊化が定義されていて使えればその戻り値を、
> そうでない場合は std::to_address(p.operator->()) の戻り値を返します。
ついにポインタのことをアドレスって言っても良くなったんだな
俺の学生時代にはポインタの事をアドレスと言って良く怒られたものだ
懐かしい思い出 変数は実は二つの値から出来ている
一つは変数の中に入っている値
もう一つは変数のアドレスの値
この二つだ
変数の二重性がC言語の理解を無駄に難しくしてる
アドレスの値が入ってるのは機械語から言えば当然だが
変数なる計算機科学の概念がそこに中途半端にドッキングすると複雑になる
ポインタで躓くヤツが多いのは機械語と高水準言語、その中間に位置するC言語の変数がもつ二重性のせいだ ID:Z7o7STkD
このスレはこういう精神病みたいなやつ多くない？ 皆さん情報ありがとう
ひとまず先生のWeb版「C++入門」をやってみることにしました operatorの暗黒面を知れという実習問題
ここでみんなでやってみないか？ 単純なキーワード検索できないことぐらいでしょ。暗黒面。 operatorは自明な場合しか使わない
構造体代入のように見えて変数の逐次代入してあって、
後で追加された変数が処理されていなかったりして気づかないとかこわい 演算子の多重定義とテンプレートの組み合わせはﾁｮｰ便利
gotoと同じで手放せない便利さ…！ 同じといや同じだし違うといやぁちがう
普通の脳味噌のやつには適当に「こまけぇことはいいから同じようなもんだ」と
いっとけば通じるが、このスレにウヨウヨいるような偏執狂タイプの連中に
うかつに「同じ」なんていうとポインタをアドレスと同じように整数を足すと
そのぶんアドレス値が進むと思いこむやつがでてくるからうかつに言えないだけ >std::to_address()
^^^^^^^
>それが表すのと同じ「アドレス」を「生ポインタ」で返す関数
となってるので公式で
ポインタ=アドレス >>941
アドレスの値を生ポインタの型として返す、ということだから、
この文脈では明確に別の意味だろ いや、to_address() という名前の関数が生ポインタを返すから
ポインタ=アドレスで問題ない
そうじゃないんなら、to_pointer() っていう関数名にするだろ、普通
そこが to_address() となってる オプションだし。
アドレスを返せないファンシーポインタもあるということでは。 俺は古いタイプの人間だから俺の感覚で言うと
to_address() って言えば、生のアドレス値が整数型で帰ってくるという低レベルなイメージ
それが生ポインタが帰ってくるというなら to_pointer() としたいところ
ところが生ポインタが帰ってくるのに to_address() となってるわけだから
ああなるほど、時代は変わったなぁ、と
その辺 C++ の人たちはうるさいと思っていたんだがねぇ
もう公式で ポインタ = アドレス なのね pointer指すもの
address指す先
じゃね ファンシーポインタからポインタをとるときに使うもののような気がする。
それが不可能なこともあるからオプションなのでは。 ポインタ→ポインタあるいはファンシーポインタ・・・pointer_to。
ポインタあるいはファンシーポインタ→ポインタ・・・to_address。
ってことで、ポインタの意味は変わっていないんじゃないのかな。 簡単に考えれば、生ポインタとスマートポインタetcを区別するために
生ポインタの事をアドレスと言ってるわけだよ
スマートポインタetc -> ポインタ
生ポインタ -> アドレス
っていう格上か格下げか知らんが、一つずらした呼び名になってるんだ
俺みたいな古い人間には受け入れがたいものもあるが
「生ポインタなんか使わねーよスマポこそがポインタであり生ポなんかアドレスとでも呼べばよい」
という今の時代に合わせた考え方なんだろう
スマポetc(ポインタ)から生ポ(アドレス)に変換するから to_address()
ちょうど Java のオブジェクトを指す変数は C++ 的には参照だが
Java の人たちはオブジェクトと言うし、そう考えてる、ってのに似てる javaの変数はポインタだろ
代入したら指す先が変わるし
null持てるし
まあ演算できない劣化版だが 常識なんかどんどん変るからな、とくにC/C++みたいな歴史が長い世界は
ピュアCの時代にはそもそもポインタといえばたしかにその値がアドレス(位置情報)
として機能する値と一致していたがファンシーポインタがある現代では
"ポインタ"の実体とそれが保持したい情報(アドレス情報)は一致すると思わない事が常識になる
"ポインタ"は情報としては何かの位置を差す値を保持はしているがそのオブジェクト
自体は保持しているアドレス情報とはまったく無関係のメモリ空間にある何かである
現代の感覚でいうともし std::to_pointer というネーミングにすると
"は？ポインタをポインタに変換するってどういう意味だよ？？？？"とむしろ混乱の元になるってわけだ なんか長々書いたが
今の時代、スマポこそがポインタであって、もはや生ポインタはアドレスなんだよ！
人間も父が爺になって子が父に繰り上がっていくものだから
時代と共に名実ともに出世していくのは普通の事なのかもしれない ただどうしても言いたいのは
生ポインタは address じゃなくても
別に raw_pointer とか native_pointer で良くね？
address って言ったら、ただの数値のイメージがあるわ アドレスに無料で型情報をつけるアイデアをひらめいたときは、俺って天才かも？って思ったんだろな。 >>951
我々の感覚からすると実際その通りなんだが、Java脳の人々にとってはそうではない
彼等はスタックという感覚も非常にうすい
なぜならオブジェクトはスタックにはとれず、常に new (ヒープ)しかないから
我々はクラスのインスタンスがスタックにあるのかヒープにあるのかは無意識に常に
判断する事に慣れているが、これをjava脳の人に説明するのはしばしば困難なときがある >>929
宣言をヘッダファイルに分割する方式は C++ の意味不明さの根源のひとつじゃない？
それで宣言と定義を分ける運用がキッチリできるのならそれはそれでよかったけど、
テンプレートとインラインの活用でヘッダファイルに書く分量がだいぶん多くなってヘッダファイルってなんだっけって気持ちになる。
このあたりの仕組みは再編すべきでしょ。 モジュールは要るって。
コンセプトもなぁ、型に制約を付けるって普通にやりたいことじゃん？
ちょっとした制約を付けるためにまわりくどいメタプログラミングなんてやりたくないよ。
現代的な静的型付け言語ならあって然るべき機能が順当に入るってだけのこと……
と思ってたら延び延びになっちゃったから待たされてる感じが強い。 javaはヌルポ出すくせにポインタじゃないのか
ポはなんの略なんだろう >>941
公式は "A value of a pointer type ... represents the address of the first byte ..."
「ポインタ型の値はアドレスを表す」となってる。
https://timsong-cpp.github.io/cppwp/n4659/basic.compound#3
アドレスに加えて他の情報を持つ可能性は否定されないので、いろんな人が言ってるように
厳密にはイコールではないね。 >>958
要らんなどと一言も言ってないぞ
言い回しがそれっぽいってだけ
だいたいモジュールはまだ20では標準ライブラリには使われないし
「コンセプトはよ来い」とか上級者ぶりたい初心者がよく言うけど、その中に「自分で実際にコンセプトを定義する奴」などほぼ居ないだろ
個人的にはこれまでSFINAEでどうにかしてたメタプログラミング用の要件チェックのコードを
全部コンセプトに直すのクソだるい(便利になるだろうけどエラーメッセージ以外で実感するのはまだまだ先)
だいたい来るのはわかってんだからもう一喜一憂するような話でもない 今も昔もアドレスとポインタの意味は変わってないんでないの？
｢アドレス｣=メモリ上のオブジェクトの位置を表す番地(具体的には整数値)
｢ポインタ｣=
(1)何らかのアドレスを格納したT*型の変数(オブジェクト)。生ポインタ。
(2)｢アドレス｣と同じ意味で用いる
昔からポインタ(2)の用法でアドレスとポインタを同一視して使われるだけで、ポインタ(1)の用法で｢アドレス｣とは言わんでしょ。
to_addressの件も、引数として受けとるオブジェクトに対する｢アドレス｣の値を返すのだからto addressと言う命名で適切だろう。ここでto pointerとしたら直感的に｢ポインタ｣(1)の意味で解釈されかねず、下手な命名だと思う。 言葉遊びというか言葉の意味の違いでかみあってないだけじゃろ
こうした文脈でのアドレスという言葉を
アドレス＝機械語コードで使うのと同じ表現で指定されてるメモリアドレス
の意味に無自覚に限定してるのか
アドレス＝なんらかの形で指定されてるメモリアドレス
のゆるい意味で使っているかの話じゃ
ポインタはアドレスではない、は前者の意味のアドレスに対する話で
今回の話も含めたC/C++の規格レベルでのアドレスは一貫して後者の意味じゃて アドレスはオブジェクトの番地
ポインタはアドレスを格納する変数 しかしアドレスを返すと言いながら
ポインタで返し、型情報が付いてきているわけだが 緩い意味でのどこかを指し示す意味でのアドレスと言っているなら
スマポもアドレスになるから、to_addressの意味がさらにもう何が何だか ポインタというよりvoid*だね
void以外のポインタは実体の型により訳が変わる点が
単なるアドレスと違うところで いやでも、to_address() の戻り値の型は
void* ではなくて、ちゃんとした型情報を持った普通のポインタ型だよ
void* にはならないよ >>966
返されるのはあくまでアドレス(番地)の値だろう。型情報としてT*型を持つが、それはC/C++ではすべての式や値が型を持つから当たり前の話であって、型を持つからアドレスとは呼ばないというのはおかしな話だと思う。 >型を持つからアドレスとは呼ばないというのはおかしな話だと思う。
つまりは ポインタ=アドレス って事ね ポインタってのは変数のことでその中身はアドレスって第3版の時点ではっきり書かれてるぞ
型を持ってるのもあくまで変数の方だ それは当たり前
そういう話ではなく
う～ん、どういえばいいか
例えば、年齢を得る関数 int get_age() ってのがあったとして
俺は別にこれに疑問を持たんし、何とも思わない
to_address
それは int に対して age の方が高度で抽象的な概念になってるから
ところが pointer to_address() の場合はこれが逆になってて
pointer の方が address より高度で抽象的な概念になってる
だからこう、本質的に気持ち悪いというか
先の例で言えば
まぁ適切な例かは分からないが
age_t get_int()
ってなってたらキモイだろう なんか途中で送信してしまった
それは当たり前
そういう話ではなく
う～ん、どういえばいいか
例えば、年齢を得る関数 int get_age() ってのがあったとして
俺は別にこれに疑問を持たんし、何とも思わない
to_address() と何が違うか
それは int に対して age の方が高度で抽象的な概念になってるから
ところが pointer to_address() の場合はこれが逆になってて
pointer の方が address より高度で抽象的な概念になってる
だからこう、本質的に気持ち悪いというか
先の例で言えば、まぁ適切な例かは分からないが
age_t get_int()
ってなってたらキモイだろう なんか勝手に幻想抱いてるけどポインタに入れるものは常にアドレスだから
何もおかしくない でさ、
age_t get_int() ってのを見たとき
「age_t の中身は int だし
int を get してそれが age_t に入っているのだから
解釈としては問題ない」
って感じのことを言ってるレスが結構あったけど
俺はなんか違うような気がするって言ってるわけ 具体的には >>977 とかね
age_t の中身は常に int だから～的な
だとしても age_t get_int() とは書かんだろう、というのが俺の主張だから アドレスとポインタってのは
ageとage_tの関係 じゃあint *p = &a;の&もアドレスを取る演算子じゃなくて
ポインタを取る演算子に名前変えてもらうようにお願いしたら？ アドレスはデコーダに入力するビット列 （ハードウエアの概念）
ポインタはアドレスを扱うことを目的とするデータ型 （プログラム言語の概念）
IEEE754とdoubleのような関係だ 通常はポインタが数値であることなんてのは意識せんわな。
リングバッファなんかを取り扱うなら嫌でも意識することになるが。 ポインタが数値がどうか意識しないと
リングバッファも作れないようなのが
C++を使うのか >>976
その例は逆
アドレスとポインタは本質(イデア)とその表現の関係にある
(イデア <-> 表現)
年齢 <-> 整数
色 <-> RGB値
アドレス <-> ポインタ
この関係に照らせば、年齢を取得する場合は
int get_age();
だし、色を取得する場合は
RGB get_color();
だし、アドレスを取得する場合は
T* get_address();
になる >>986
分岐？
それも普通は不要
アドレスを意識するのはDMAなど
ハードウェアでリングバッファを使う時くらい ハードウェアとのDMAならポインタにいれるアドレス自体は気にしないだろ
特定の物理メモリを適当な仮想アドレスにマップして使うのだし じゃないのもあったりするのか？
チープなマイコンのDMAしか直接扱ったことがなくて 仮想アドレスってことはページフォールトがあるってことだろ
OSによってページインされるまで待つことになるが
そこまでペリフェラルで面倒見る必要あるか考えてみそ >>993
フォルトならエラーで止めときゃいいんでない？
そこまでハードで面倒見る必要は無い >>993
おいおいそんなわけないだろ
デバイスがさわるメモリはページアウトしない
でも物理アドレスを使わない理由は何でしょう？
あスレ違いだな >>996
ペリフェラルって何だと思う？
>>998
循環論法だな このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 44日 2時間 57分 54秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
