C++相談室 part150
■ このスレッドは過去ログ倉庫に格納されています
sort(
vecVisibilityPolygonPoints.begin(),
vecVisibilityPolygonPoints.end(),
[&](const tuple<float, float, float> &t1, const tuple<float, float, float> &t2)
{
return get<0>(t1) < get<0>(t2);
});
はt1の最初に設定されたfloatとt2の最初に設定されたfloatを比較して昇順に並べているのでしょうか？
[&]の意味はよく分からなくて教えて頂けると幸いです。 そうですね。
&に何の意味があるのか僕にもわかりません。 >>223
>t1の最初に設定されたfloatとt2の最初に設定されたfloatを比較して昇順に並べているのでしょうか？
その通りです。get<0>(t)でタプルの最初の要素を取り出して大小比較してます。
ちなみにget<0>を使わずに直接 t1 < t2 と比較すればタプルの左の要素から順に辞書順でsortされます。リンク先の(3)参照。
https://ja.cppreference.com/w/cpp/utility/tuple/operator_cmp
[&]はラムダ式の中で使われる外部の変数を参照で持ってくるものです。リンク先のラムダキャプチャを参照。
ただ上の例ではそもそも外部の変数を使っていないので[&]ではなく単に[]で問題ないです。
https://ja.cppreference.com/w/cpp/language/lambda >>217
当たり前はそうなんだが言語機能や標準ライブラリでそういうのを守りやすくしようぜって
流れは感じるけどね。 >>226
お前さんがそこで流れと言っているものは別に最近できた流れでもなく、昔からあったし随時拡充されてきているものだぞ。 僕も流れを感じますね。
このフォースを感じ取れないものもいるんですね。
少し驚きました。 get<0> とか get<1> とか観るとげんなりする
なんで動的にアクセスできないんだ そりゃ0番目と1番目の型が違うかもしれないからだよ >>230
タプルはそれぞれの要素の型が違う可能性があるから仕方がないし、
array とかなら get を使わない選択肢があるんだから問題なくね？ 格納する値の型を知っているのに相称型でしかアクセスできないのは不便ではないかというご提案として、受け付けました。
進捗状況は、ご提案番号1として随時ご確認できます。
格納する値が実行時にしか確定しない以上、コンパイラが値の型にアクセスすることも出来ないんだよな。
std::variantのoperator==は荒業でアクセスしてるよね。 あらかじめインデックス渡した関数テンプレートを実体化して
boost::anyみたいなものを返すという力技でどうにか出来なくもないだろうけど
上の方で何でもコンパイル時にやるのが良い事みたいに思ってるアホがいたけど
この辺の問題全く分かってないんだろうなぁ
(tupleを否定してるわけじゃないので変な噛み付き方しないように 学術巨大掲示板群: アルファ・ラボ
ttp://x0000.net
物理学 化学 数学 生物学 天文学 地理地学
IT 電子 工学 国語 方言 言語学 など int要素が1個だけならget<int>でアクセスできなかったっけ 出来る限りコンパイル時に解決したほうが良いと思います。 constexpr ifで実行時の条件分岐数を減らす。
これがいま話題の都会的プログラミング。 >>230
楽してコストを減らす工夫だよ
見た目がイヤなら横着しないで
ちゃんと意味がわかる名前を付けなさい template < typename > union vector3 {
struct {
T x;
T y;
T z;
};
T[3];
T&operator[](int n);
const T& operator [](int n) const;
}; >>238
規模の小さな小さなプログラムでしか効果が無いようなことが都会的かあ >>242
何も知らない田舎者が漠然と憧れてイメージする都会ってことだろう 都会が優れていると思っている人を見ると、馬鹿なのかな、と思ってしまう。 タプルの分解は構造化束縛でだいぶ楽になったけど使わない変数を読み棄てる機能も欲しい
int main(){
const std::tuple<std::string_view, int> person("nanashi", 35);
const auto [name, age] = person;
std::cout << "name:" << name << ", age:" << age << std::endl;
return 0;
} タプルなんて小規模のちょこっとしたプロトタイプコードのときは
楽だなんておもうけど、きちっとした巨大なコードに仕立て上げていく経過で
結局ふつうにちゃんと構造体なりを定義してそれ返すようにしないと後々
混乱しかないのが見えて結局こんなのイラネーな、ってなる 都会つってもアーバンライフが理想だったりするんだよね
最先端とは言わなくても整った街並み統一された景観
中心部は新旧入り混じったごみ溜めみたいなもん
流行に飛びついてつまみ食いするだけのが最悪 タプルは雑多な多値を返したいときが本来の目的
メタプログラミングでも活躍するけど 使い方のわからない初心者が要らないというが、必要ないなら標準に入るわけがない。 >>225
ありがとうございます。
リンクと丁寧な説明、大変助かりました。 タプルはどっちかというと無名クラスそのものな印象
なので>>249に1票を入れたい
さらに言うとC++ではラムダ式の引数にもポインタを渡せるし、
[&]で呼び出し元変数の書き換えもできるしで
ラムダ式との絡みでもタプルという機構はそこはかとなく重畳な印象
、 ゼロコストのための手段の品揃えが良いのはいかにもC++だが
JavascriptやPythonに似せる方向性の努力はC++的では無い
ｷﾓｽ なんじゃそりゃC++はプログラミング言語界のPerlでも目指しとるんか、 というのは半分は冗談で、
スレッド安全のために関数からはオブジェクトのコピーを返したいのだが
オブジェクトのクラスをいちいち定義したくない、と言う場合には多少便利 時代はjavascriptとPythonだからねー
キミたちより意識高いし「デキる」人多いよ ランタイム速度落とさずに高級なことできるならなんでもやるがc++だろ >>261
最近多いんだよねー
JavaScriptやPythonとかちょっとかじった程度で
「俺プログラマーやってます」って顔する子
最初の入り口が動的型付け言語なんだよね最近の子って
そんなもんじゃ使いものにならねっての いつの時代にもいるもんだよ
CでPascalっぽいコード書くような手合いは でも、constexprの使い道もわからないようじゃC++の意味ないのでは。
豚に真珠。 CひいてはC++の需要が無駄に高まってきてるのは、一つは競技プログラミングのため、もう一つはpythonのためだ >>267
＞constexprの使い道もわからない
誰と戦ってるんだ 学術の巨大掲示板群 - アルファ・ラボ
ttp://x0000.net
数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など RTTIをプログラムの一部で使用した場合
使用していない部分でもRTTIを有効にしたデメリット(実行速度など)の影響を受けますか？ RTTIって何だっけ要るときになったら確保とかいうやつだっけ dynamic_castとtypeidを使う時に必要な機能 >>274
実行速度は実際に使うところにしか影響ないと思う。
バイナリサイズの面でのデメリットはRTTIを有効にしてコンパイルしてたら使わなくても発生すると思う。 C++の設計思想としては
Cで同じコードを書けば同じ速度、リソースで実行出来るのを目指している
で基本的には思想通りに仕上がってる 関数形式のキャストってあるじゃん
int(a)みたいの
これのlong long版ってあるの？
スペースを含んでいるのだが(笑) >>282
実は、コンパイラからすれば、それは、旧来のC形式の
(型名)値
の形式のキャストとみなされている。 >>283
(TYPE)x // 原初的なCから存在していた旧来のキャスト形式
TYPE(x) // C++ で追加された関数形式のキャスト >>281
typedef long long long_long_type;
using alias_ll = long long;
てな感じに別名をつけたらどうだろ。 関数形式のキャストって、キャスト演算子をオーバーロードするとき
間接的にしかお世話になってない希ガス、
旧来のキャスト形式に対して他になんかメリットあんの？ コンストラクタによる変換と一貫してて見やすい（個人差があります >>289
コンストラクタとの一貫性を持たせることでtemplateを書くときに何か都合がいいとどこかで読んだ気がするが、うろ覚えなので間違ってたらスマン printfで標準出力に一行づつ出力するのが面倒なので、複数行をビアドキュメントで出力したいのですが、何か方法はありますか？ >>292
printf(
"hhhh"
"jjjj"
"kkkk"
"llll"
); >>292
printf(
R"(hhhh
jjjj
kkkk
llll)"); >>293,294
どちらも出来ました！
ありがとうございます。 複数行ってそういう意味か？ω
出力は改行せんでええんか？ωωω 絶対に大丈夫なやり方は、こう :
printf(
"xxxx\n"
"xxxx\n"
); https://ideone.com/rhcxbJ
g++とclで結果が違う
ideoneではエラー
どれが正しい？ >>300-301
スコープ無し列挙定数は全ての列挙子の値を表せる整数型が基底になる。
ただし、全ての列挙子の値が int か unsigned int に収まるならば int より大きくなることはない。
この場合は int で表せないのでもっと大きい型にしたいけど最大の整数型である long でも
表せないのでお手上げって言ってる。
codepad は gcc 4.1.2 を使ってる。
つまりその時点での最新仕様は C++03 で、C++03 には long long なんていう型はない。
long 型が最大の整数。
(実際には処理系の拡張として __int64_t という名前で 64bit 整数も使えたりはするんだけど、
enum 関連で使用されるようにはなってないっぽい。) >>303
レスthx
clはデフォC++14なのでlong longがあるはずなのに
何でtest2がlong止まりなのって話
std::cout << typeid(test2).name() << std::endl;
とやってみても
enum `int __cdecl main(void)'::`2'::<unnamed-enum-test2>
となるだけでlongかどうかは確認できない
さらに
void func(int) { std::cout << "int" << std::endl; }
void func(long) { std::cout << "long" << std::endl; }
これだと出力がintになる >>304
> clはデフォC++14なので
cl っていうと Common Lisp を連想してまう……というのは余談として、
それは動作環境を用意できてないからこっちで実行できへんのや。
結果が違うってのはどうなるの？
実行結果も示してくれへん？
あと 64bit 版か 32bit 版かも明示してや。
> longかどうかは確認できない
列挙型はあくまでも個別の列挙型であって整数ではないので、
基底型が何かというのは std::underlying_type で調べる必要がある。 godbolt で確認しようとしたら
LINK : fatal error LNK1104: cannot open file 'libcpmt.lib'
と出るんやが…… >>305
Visual Studioと言えば通じる？
underlying_typeか、こいつは情報ごっつぁん
std::cout << typeid(typename std::underlying_type<decltype(test2)>::type).name() << std::endl;
これの出力もintだった >>307
> Visual Studioと言えば通じる？
コマンドが cl というのは知ってはいるんだけど、コンパイラの名前として cl っていうのは伝わり難いと思う。
マイクロソフトのドキュメントでは Microsoft C++ か MSVC という書き方をしていることが多いようなので、
たぶんそれが公式な呼び方なんじゃないかな。
> これの出力もintだった
値は何になってる？ 値はもうあんまり興味なかったが
一応試したらやっぱり0だった >>310
よくこんなの見つけたな
指摘からもう１年経つのにまだ放置か 300で言ってたclは2019だよ
もち更新ちゃんとやってるやつ >>315
最新のコメントに `_MSC_FULL_VER` が `192328105` の環境で再現すると書いてある。
これは Visual Studio 2019 version 16.3.2 のことだそうな。
https://cpprefjp.github.io/implementation.html#visual_cpp_ver あーすまん、ちゃんと見てなかった
2019でも起きるのに一年放置は長いな
型指定使えば済むやろ、で後回しにされてるのかも？ だいたい出尽くした？
餃子さん情報２つもありがとう
リアルならバーでおごるところだ 本当は、64bit型が追加されたことはコンパイラ作者泣かせなんだ。
C++コンパイラはとても複雑になってしまっている上に新しい仕様が入ったことで組み合わせ爆発が起きて細かなバグが入り易い。 型の「昇格」や、2項演算子における型の「統一」も、64bit型が入ったことで複雑さが増した。
普段当たり前すぎて気にしないことだが、
unsigned char ch = 1;
と書いた場合でも、右辺は最初 int 型整数と解釈されるが、型にうるさいC++においても、それよりバイト数の少ない ch に警告も無く代入できてしまう。
他にも、
ch += 2;
とした場合、2は、最初int型と解釈されるのに、それよりバイト数の小さい ch に何の警告も無く足せてしまう。
これらで警告が出たらコーディングの手間がかかり過ぎるためそうなっているとは分かるが、型安全なC++においては背後にどういう仕組みがあるのかと思ってしまう。 >>321
unsigned char ch = 1 + 2;
と書いたとする。
右辺は、C言語の使用によれば、1も2もint型だとみなされてから計算され、
結果の3もint型である。普通、int i; に対して、
ch = i;
とすると当然エラーか警告が出るのに、
この場合には何もメッセージが出ずにコンパイラが通るはずだ。
これも背後にどの仕様が働いているのだろうか？ ■ このスレッドは過去ログ倉庫に格納されています
