24/06/09 22:18:48.29 RJYm8+UN0.net
んー
clangちょっと調べたかったんで
Visual Studioにclangインスコして調べますわ
できるならwslでやるのが手っ取り早いんですが
Q9550とQ9550sしか持ってないもんで
以来CPUの爆値上がりと最近の円の爆下がりで新しく組めてないんですわ
ダイサイズ変わらないのにCPU 3万ー> 10万とか購買意欲が萎える
358:デフォルトの名無しさん
24/06/10 18:15:47.68 bkv2YMA2M.net
>>355
github のwslのissueを漁れば出て来るかと。
結論がWSL2使えだったかと
359:350
24/06/10 21:38:00.71 gvR5xwnw0.net
自己レスです
その後 Visual Studioのインストールオプションでclangを選択し
正しく動作することは確認したのですが...
今や誰でもロハで使えるインテルコンパイラがとっくの昔にllvm化されてたんですね
clangに拘りがなければ x86/x64のwin/linux/wsl は素直にopenAPI使っとくのが幸せかも.
ちなみにwsl 1にlinux版をインストールしましたが
コンパイラicxもデバッガgdb-opwnapiも何の問題もなく動いてます(今のところは)
なので
Visual Studio はインストールオプションのclang は外してもとに戻し
wsl は
>apt remove clang clang-15
>apt remove lldb lldb-15
しときました
360:350
24/06/11 06:20:17.73 Ip4/j3Hv0.net
☓ openAPI
◯ oneAPI
361:デフォルトの名無しさん (ﾜｯﾁｮｲ 3bb1-hWAc)
24/06/21 22:07:24.38 sN/1ehEs0.net
今だけです
URLﾘﾝｸ(i.imgur.com)
362:デフォルトの名無しさん
24/06/22 13:52:54.53 5xyD4PGd0.net
今だけです
URLﾘﾝｸ(i.imgur.com)
363:デフォルトの名無しさん (ﾜｯﾁｮｲ 43d7-pk1M)
24/07/13 19:06:26.39 Dtkl2SPB0.net
若者のBoost離れ
364:デフォルトの名無しさん (ﾜｯﾁｮｲ 0501-twcF)
24/07/13 19:56:34.01 vwgbCsGD0.net
と言いますと?
365:デフォルトの名無しさん (ﾜｯﾁｮｲ f5f9-pk1M)
24/07/13 21:42:42.00 Rh1MnFN10.net
VS17.10.xでBoostがビルドできなくなってるのに
誰も触れない
366:デフォルトの名無しさん (ﾜｯﾁｮｲ f5f9-pk1M)
24/07/13 21:47:29.39 Rh1MnFN10.net
MSVC143から144に変わったせいでビルドできないらしいですよ
367:デフォルトの名無しさん (ﾜｯﾁｮｲ e91c-hIhh)
24/07/16 12:22:56.57 gS8T2k/f0.net
>>342
CMakeとNinjaはC++の話題なのでOKです
368:デフォルトの名無しさん (ﾜｯﾁｮｲ 4901-V77j)
24/07/27 17:57:44.53 KDd62vAV0.net
C++、
型の指定が、めんどい
速いぐらいしか、利点ないよな
369:デフォルトの名無しさん (ﾜｯﾁｮｲ 7b95-4q6c)
24/07/27 20:53:02.50 eNksZtKQ0.net
顧客目線に立てない三流の感想
370:デフォルトの名無しさん (ﾜｯﾁｮｲ 4901-7phL)
24/07/27 21:03:15.66 zOSUCWw50.net
>>368
auto使えば?
371:デフォルトの名無しさん (ﾜｯﾁｮｲ 1379-xel+)
24/07/27 23:40:34.69 iHlVB6Tw0.net
ランタイムに依存しない(し難い)のが最大の利点だろうに
さらに大抵のアーキテクチャには用意されてるからクロスプラットフォームの観点でもなんだかんだ最強なんだよ
むしろ最近はChatGPTが他の言語で書いたやつまで適当に書き直してくれるのもあって最強度がより高まってきてると感じるね
372:デフォルトの名無しさん (ﾜｯﾁｮｲ 8e95-N8l3)
24/07/28 00:00:39.51 ePI6t8jD0.net
全く同意できんな
むしろ環境依存上等で使うのがC/C++だろ
パッケージシステムも標準がないしビルド環境もばらばら
どこが最強やねん
標準ライブラリで完結するようなしょぼいプログラムなら他の言語使ったほうが楽
373:デフォルトの名無しさん (ﾜｯﾁｮｲ bdf0-+IYp)
24/07/28 00:11:55.23 4HqkcgMt0.net
型の指定のサンプル
GetProcAddressに変換をかけるマクロ
#define ENTRY_INTERFACE(api) api = (decltype(api)) GetProcAddress(hInst,"_INTERFACE_"#api)
ね？簡単でしょ？
374:デフォルトの名無しさん (ﾜｯﾁｮｲ 5d01-viEi)
24/07/28 12:00:20.72 x9q80Pnt0.net
>>370
auto
オートね
(いいこと聞いた
375:デフォルトの名無しさん (ﾜｯﾁｮｲ aa3e-cE1m)
24/07/28 17:36:32.24 9wLF96CX0.net
>>374
あとテンプレートを使ったダックタイプとかも便利。
376:デフォルトの名無しさん (ｵｯﾍﾟｹ Sr05-viEi)
24/07/28 21:14:24.07 roXukc4Cr.net
>>375
ふむ
実践的な(アプリを作るとか)、c++、書籍かなんか、おすすめ、ありますか？
cmake、とかの、関門もあるのだが
(githubにあがってるやつを、きっちり理解したい)
377:デフォルトの名無しさん (ﾜｯﾁｮｲ 4132-nuT0)
24/07/29 08:53:31.23 cQQT2a1I0.net
実践に入る前に言語の入門は読んだほうが良いと思う。
基礎を積まずに実践しようとするのは無謀。
378:デフォルトの名無しさん (ﾜｯﾁｮｲ 9a05-pVLH)
24/07/29 15:25:34.30 heyNGOtI0.net
なんでも、まずは改造から入るんだぜ
こうですか、うんたぶんこう
379:デフォルトの名無しさん (ﾜｯﾁｮｲ 4132-nuT0)
24/07/29 19:25:02.89 cQQT2a1I0.net
C++ には未規定がやたらたくさんあるんだ。
実際の挙動から仕様を想像しようとすると意味不明でグダグダやねん。
380:デフォルトの名無しさん (ﾌﾞｰｲﾓ MM9a-N8l3)
24/07/29 20:07:37.15 Nl7D5VelM.net
ネットでいくらでも勉強できるだろ
書籍なんかいらん
381:デフォルトの名無しさん (ﾜｯﾁｮｲ aa3e-cE1m)
24/07/29 20:36:26.35 9/o4+28+0.net
結局ライブラリが重要だから、作りたいアプリで流行っているライブラリの入門をやるのがいい。
作りたいアプリそのものじゃなくても、類似アプリを作るのはやる気に繋がる。
382:デフォルトの名無しさん (ｵｯﾍﾟｹ Sr05-viEi)
24/07/29 22:02:41.02 8hMQwTW/r.net
>>377
github にあがってるやつを、理解しようとして、助けになる本は、結局ない希ガス
実際、実践的なものがないので、文法理解で終わってしまうという
URLﾘﾝｸ(github.com)
これ、再利用して、アプリを作りたいのだが
383:デフォルトの名無しさん (ﾜｯﾁｮｲ 4132-nuT0)
24/07/29 22:18:19.65 cQQT2a1I0.net
>>382
言いたいことがわからん。
auto すら知らんかったということは文法もまだ十分に理解してないってことだろ？
文法が分かったら読めばいいだけなんだから何の本が必要なんだ？
384:デフォルトの名無しさん (ﾜｯﾁｮｲ 0168-qw7+)
24/07/29 23:36:56.61 7XbSB18u0.net
>>382
立直麻雀のシミュレーターなら mjx の方がいいんじゃないかな?
マイクロソフトで麻雀 AI Suphx の開発に携わってた人が作ったシミュレーターで
動作検証も天鳳の牌譜で実施したらしい
URLﾘﾝｸ(github.com)
他のシミュレーターだと
- libriichi (Rust製 麻雀 AI Mortal に付属 天鳳ルール準拠 AGPL)
URLﾘﾝｸ(github.com)
- kanachan.simulation (C++製 麻雀AI kanachan に付属 雀魂ルール準拠 MITL)
URLﾘﾝｸ(github.com)
とかも参考になると思う
作りたいアプリの内容がわからないけど
ネット麻雀を作りたいなら cmajiang の元ネタの電脳麻将
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(kobalab.net)
AI 用の対戦シミュレーターなら mjai.app
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(mjai.app)
が参考になりそう
385:デフォルトの名無しさん (ﾜｯﾁｮｲ 0168-qw7+)
24/07/29 23:43:38.11 7XbSB18u0.net
>>382
書くのを忘れてた
cmajiang の元ネタ majiang-core は作者が解説本を出してる
実際買ってみたけど、やっぱりソースコードだけ読むより分かりやすい
URLﾘﾝｸ(www.shuwasystem.co.jp)
ブログでも解説されてるけど、お目当ての記事を探すのが大変だし本の方が見やすいと思った
URLﾘﾝｸ(blog.kobalab.net)
386:デフォルトの名無しさん (ﾜｯﾁｮｲ bdf0-+IYp)
24/07/30 12:23:26.36 8UDCP+we0.net
>>379
未規定というか、C++11よりも古い規格のは、古参でないと扱いが難しいからね
そういう古い規格のものが仕事で入ってい来たりすると新人は頭悩ますかもしれんね
03~11まで結構間に空いてるしね
387:デフォルトの名無しさん (ﾜｯﾁｮｲ 5d01-viEi)
24/07/30 23:52:38.43 KT8SFJ0h0.net
>>385
はい、
すべて、既読です
make,
pybind11
とか入ってて、
デバッグビルド、わかりませんorz
388:デフォルトの名無しさん (ﾜｯﾁｮｲ 1bef-BWtz)
24/08/04 06:24:46.59 WlfSsbJh0.net
ラムダ式が渡された側って、キャプチャの内容をチェックしたりできないのでしょうか。
例えば以下の例で、funcA()の中でfの中のthisをチェックして挙動を変えたりとか?
そういうことをしたいなら、ラムダの引数で渡したりすべきでしょうか?
#include <iostream>
class A {
public:
void funcA(const std::function<void(int)>& f, int a) {
f(a); // can I check 'this' (B class) in f?
};
};
class B {
public:
void print(int b) {
A objA;
objA.funcA([this](int i) { std::cout << "val = " << i << "\n"; }, b);
}
};
int main(void) {
B objB;
objB.print(2);
}
389:はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ a932-NesV)
24/08/04 10:12:57.69 w7HjtqNP0.net
>>388
キャプチャした変数はラムダ式の中で使う以外の方法ではアクセスできない。
どのような方法で解決すべきかはそれをしようとする意図によるのでなんとも言えない。
390:デフォルトの名無しさん (ﾜｯﾁｮｲ a94a-ImVy)
24/08/04 14:50:32.12 ao1w9dwD0.net
それはラムダ式を使う理由とズレてるな
A側で判定が必要なものならラムダ式の引数もしくはfuncAの引数で渡すべき
A側は受け取るものを「intをひとつ受け取ってvoidを出力する関数」として抽象化してるんだから、それ以外のことは知れないし、知るべきではない
Aは渡された関数が何であろうとintを一つ渡すだけで、その詳細 (関数がどのような値や参照をキャプチャしてるのか、渡した引数がどのように使われるのか) には触れられない
ラムダ式を使うのはこのような抽象化が目的のはずだから、キャプチャした値を知りたいというのは用途から外れるかと思う
391:デフォルトの名無しさん (ﾜｯﾁｮｲ 9b72-3sGu)
24/08/04 18:55:04.35 knGBcNlu0.net
なんか最近自分でで適切なインターフェースを定義して使うって発想がなくなってる気がする
ひたすらありものを繋ぐだけで作り切るみたいな
392:デフォルトの名無しさん (ﾜｯﾁｮｲ c1f0-3TXu)
24/08/04 19:21:38.37 oxQURbTu0.net
仕組みを追求することをせずにどっかから完成した㌬をﾄﾞｯｷﾝｸﾞするだけの作業は情報収集力さえあれば組み込み系の作業員でもできるし己のﾁｶﾗにはならんのよな
で、いろんなもの付け合わせていった結果、とんでもない容量のものが出来上がる上におまえそれﾒﾝﾃとかどうするんだよって方向に走ってって…あとは想像のとおりに
393:デフォルトの名無しさん (ﾌﾞｰｲﾓ MM8b-3sGu)
24/08/04 19:54:18.08 wSg2UiB1M.net
オブジェクト指向オワコン論からの風潮
394:デフォルトの名無しさん (ﾜｯﾁｮｲ 1320-cRFB)
24/08/04 21:00:47.00 YVKn/U480.net
なんでオワコンなの？
395:デフォルトの名無しさん
24/08/06 01:29:43.68 DDRjgUjC0.net
全然関係ないよな
取って貼っ付ける行為とオブジェクト指向は
全体の概要設計を把握してﾒﾝﾃ出来ていれば何の問題もない
396:青木康善
24/08/07 04:36:25.01 S6qXQ6lv0.net
素晴らしいなあみなさん。早すぎる！C plus plusは！
397:デフォルトの名無しさん
24/08/07 09:54:05.95 +pgWMXtY0.net
JavaはCの20倍速いを知らん人か
398:デフォルトの名無しさん
24/08/07 17:07:58.21 RPpAsXPKa.net
>>391-392
チェンジニアをチェンジ
>>395
オブジェクト指向でもクラスライブラリを造る側とただ使う側では理解度に雲泥の差がある
399:青木康善
24/08/08 00:15:58.93 Qfze0mfg0.net
マジっすか？Cの20倍？しかし、専門学校の先生に、青木！バカもん！プログラミング言語Cが一冊で事足りる、と言われても、高校数学でつまづいて大鬱病になったんで、問題が解けない。。。有隣堂本店さんで、リッチーの本置いているから、いつか買います！
400:デフォルトの名無しさん
24/08/08 04:05:43.03 G3QDAupS0.net
今のANSI対応版は易しくなってると思うけどな。
不安ならアンサーブックとセットで買えば良いベ
401:デフォルトの名無しさん
24/08/08 16:07:46.41 fgfi2g+JM.net
VMのオーバーヘッドがあるのに20倍って?
あるいは20倍時間が掛かる?
402:青木康善
24/08/09 13:02:28.92 FZEpuz0a0.net
いや、プログミング言語は、駿台電子は、国語の倒置法なんです。夜間の一年で、javaからで、二年でCなんです。いや、アンサーブックは、池袋ジュンク堂本店さんには、置いてなかったような。。。。。ありがたいというか、ビックリ。。。。マジか。。。機械語を仕事でプログラミングしていた先生が、喫煙所で、青木、お前、一つのことを本当に深く考えたことがあるか？と質問してくれた恩師なんです。
403:デフォルトの名無しさん
24/08/10 12:16:45.89 xFKQiXk00.net
スカイネットの誕生日
404:デフォルトの名無しさん
24/08/10 23:52:09.93 oQf4NdPPd.net
御巣鷹山ノボレ
405:デフォルトの名無しさん
24/08/24 08:35:54.88 yYuYqoCz0.net
すみません。教えて下さい。
template<class T, class U>void (T& x, const U& y)
{
x=y;
...
}
double ←complex<double> の代入がコンパイルエラーとなるconceptの書き方あるんでしょうか？
complex<double> ← doubleの代入ではエラーが出てほしくないです。
406:デフォルトの名無しさん
24/08/24 09:05:25.59 yYuYqoCz0.net
あ、上では関数名fが抜けてましたね．concept使わずとも
template<class T> void f(complex<T>& x, const T& y)とすればいいでしょうけど、
y=xのときはどうかとか、あるいは complex<double>←float の代入はokにしたいとか、
いろいろ考えているとテンプレート関数なのに関数のオーバーロードが増えてしまって面倒だなと思ったものですから。
407:デフォルトの名無しさん (ﾜｯﾁｮｲ 7f78-/FHh)
24/08/24 09:23:02.26 yYuYqoCz0.net
y=xのときは忘れてください。(ｆ(complex<T>& y, const T& ｘ)とすればいいだけ)。どういう状況のためにconceptが必要なのか要点がまとまっていませんね。失礼しました。
408:デフォルトの名無しさん
24/08/24 09:53:34.49 PPcTgFGr0.net
conceptで無理やりくくるよりか、static_assertのほうが楽そう
template<class T, class U>void f(T& x, const U& y)
{
static_assert(std::is_same<double,T>::value&&std::is_same<complex<T>,U>::value,"絶対にゆるさない！絶対ﾆﾀﾞ!!");
x=y;
...
}
409:デフォルトの名無しさん
24/08/24 11:11:32.60 yYuYqoCz0.net
&& は右辺値参照ではなくてandの意味なんですね。std::is_same<double,T>はdouble型とT型が一致するかどうかを調べるヘルパー変数テンプレート、::value は trueかfalseのいずれかの値をとる定数ですか。static_assertは自分でエラーメッセージを作れるのがいいですね。完全にわかっていないですが、勉強します。ヒントありがとうございました。
410:デフォルトの名無しさん
24/08/24 11:44:22.45 6PXbzil00.net
最近、初心者にいきなり右辺値参照とかテンプレート教える風潮は良くないと思うんだよなぁ・・・論理andとごっちゃになってるやんけ
ともあれis_same自体は構造体で、中にあるvalueは定数値やで
変数テンプレートはis_same_vの方。利便性(::value書くのがめんどい)のために用意されてるだけ
static_assertの第一引数(bool)に条件式を与えてるんだが、間違ってる
static_assert(!(std::is_same<double,T>::value&&std::is_same<complex<T>,U>::value),"絶対にゆるさない！絶対ﾆﾀﾞ!!");
411:デフォルトの名無しさん
24/08/24 12:20:38.61 PPcTgFGr0.net
！抜けてたわ
ｽﾏｿ
412:デフォルトの名無しさん
24/08/24 12:40:45.95 PPcTgFGr0.net
// こういう書き方もある
if const_expr ( std::is_same<double,T>::value && std::is_same<complex<T>,U>::value ) {
//許されない処理
static_assert(false,"許さんぞ!!");
}else {
//正常処理
}
413:デフォルトの名無しさん
24/08/24 12:43:11.34 PPcTgFGr0.net
また間違えたw
× const_expr
● constexpr
414:デフォルトの名無しさん
24/08/24 14:40:14.03 yYuYqoCz0.net
いろいろとありがとうございます。参考になりました。
template<class T, class U> void f(T& x, U& y)
{
if constexpr ( !(std::is_same<T,double>::value &&
std::is_same<U, std::complex<T>>::value) ) static_assert(false,"ワシャ許さんぞ!!");
y=x;
}
template <class T, class U> void g(T& x, U& y)
{
static_assert( (std::is_same<T,double>::value && std::is_same<U, std::complex<T>>::v
alue),"ワシャ許さんぞ!!" );
y=x;
}
int main()
{
using namespace std;
double x=3.14159265358979;
complex<double> z;
f(x,z);
g(z,x); // 順番変えたり、ｘをfloatにするとエラー
cout<<z<<endl;
しかし、コンパイル時にifがつかえるんですねえ。凄いな、constexpr
415:デフォルトの名無しさん
24/08/24 15:09:12.28 yYuYqoCz0.net
std::is_same<T,double>::valueの代わりにstd::same_as<T,double>でも良いみたいですね．
416:デフォルトの名無しさん
24/08/24 16:42:04.52 6x2BzwZB0.net
#ifdef NDEBUG
/*pass*/
#else
class dbg_complex {
std::complex<double> m_complex;
public:
// std::complex<double> のメソッドのうち使うやつ同じシグネチャのメソッドを書き並べ、m_complexに移譲
...
private:
dbg_complex(doble); // 禁止
};
#define complex dbg_compled
#endif
※ 個人の感想です。
417:デフォルトの名無しさん
24/08/24 16:48:40.66 6x2BzwZB0.net
いちいち移譲せねばならないのはstd::complex<T>の継承が禁止されているためorz
実際デストラクタが十中八九virtualではないし、
>>416の最後の
#define complex dbg_complex
みたいな穴だらけの置換手段が嫌ならもうstd::complex<double> を普段からcomplexdbl という別名にすると決めてまう
すると
#ifdef NDEBUG
using complexdbl = std::complex<double>;
#else
using complexdbl = dbg_complex;
#endif
で済む
418:デフォルトの名無しさん
24/08/24 18:35:31.16 BJpt+Mj00.net
>>412
これかなり新しめのコンパイラじゃないと動かないので注意
419:デフォルトの名無しさん
24/08/24 19:16:42.78 6PXbzil00.net
行うべき解放処理が無い上ポリモーフィズムも不要なら、別にデストラクタがvirtualである必要は無いぞ
このケースで継承すべきかどうかはまた別として
420:デフォルトの名無しさん
24/08/24 23:53:59.32 4DIR6G6I0.net
>>412
constexpr if が使える (= C++17以上) なら std::is_same<T, U>::value よりも std::is_same_v<T, U> を使う方がシンプルだと思う
421:デフォルトの名無しさん
24/08/25 00:16:13.89 LfSHCV3h0.net
ま、お好きなの使えいいんじゃないんすか～
こちとら例文示しているだけで極めているﾜｹじゃないからぬ
422:はちみつ餃子
24/08/25 01:15:32.96 zZ+WMAII0.net
>>414
テンプレート型引数に require 節などで制約を付けた場合に制約に合致しなければオーバーロード解決候補から除外されるが、 static_assert や if constexpr での判定は解決が終わってテンプレートが実体化されるときに判定される。
つまり、より優先順位の低い候補に当てはめたいかもしれない場合は static_assert や if constexpr での判定をすべきではない。
状況によって使い分けがある。
それと >>418 が注意しているのは、テンプレートはテンプレート引数に依存しない部分は実体化されなくても検証されるルールだから。
(Two phase name lookup について調べてみて。)
つまり static_assert(false, ほにゃらら) と書いてあったらそのテンプレートが使われるかどうかに関係なく問答無用でエラーとして報告されていた。
新しい仕様では static_assert は実体化のときまで検証しないように挙動が改められたのだが、これは欠陥報告の形で問題提起されて過去の仕様に遡って修正されるので C++11 からこの仕様だったことになった。
新しいコンパイラでは C++11 を指定したときでも新しい挙動になる。
423:デフォルトの名無しさん
24/08/25 01:34:45.73 GxcwnqZY0.net
まあ、そんな小難しいこと言われても。C++が嫌われる理由だわ
424:デフォルトの名無しさん
24/08/25 02:05:31.18 LfSHCV3h0.net
実体化ってどっちみちコンパイルするときにエラー発生するんだから結果かわらねぇだろﾊﾞｶがよう
425:デフォルトの名無しさん
24/08/25 06:41:14.01 n8ainESh0.net
static_assert(false, "")は何かしらダミーの値入れて回避してたけど修正されてたんだ、知らんかった
426:デフォルトの名無しさん
24/08/26 00:27:52.82 JWWBXqLI0.net
false効かないﾊﾞｶｺﾝﾊﾟｲﾗはどうしようもないからどうにもならんか
//requires を使った方法
template<class T, class U>
requires(!(std::is_same_v<double,T>&&std::is_same_v<complex<T>,U>))
void f(T& x, const U& y)
{
x=y;
...
}
427:デフォルトの名無しさん (ﾜｯﾁｮｲ 2963-G6Q9)
24/08/27 07:16:06.25 NdPbjHCm0.net
特定の引数型についてテンプレート展開を阻止したいんなら
特殊化してその中にstatic_assert(false, "*** ERR ***")書いても昔は駄目だったんか恐ろしい……
428:デフォルトの名無しさん
24/08/27 07:35:09.57 NdPbjHCm0.net
しかしまあ特殊化してテンプレート引数の型Tについて
態と存在しないメソッドを呼ぶように書いたらその特殊化ケースについて展開を阻止できうる（適当
クラス内でint型定数が欲しかったら古き良き enum { ONE, TWO, THREE } で十分やし
同じことをやる手段を増やせば良いってもんじゃないぞPerlじゃあるまいし……
429:デフォルトの名無しさん
24/08/27 14:55:30.59 oHcafaf7a.net
perlの面白仕様
430:デフォルトの名無しさん
24/08/27 17:14:33.06 K2iTXH930.net
まぁ普通にSFINAEなり=delete指定なりコンセプトなりでオーバーロード候補から外す方が利用者視点でいえば自然だな
431:デフォルトの名無しさん
24/08/27 17:33:30.75 K7dNHCWQ0.net
#include <iostream>
#include <complex>
template <class T> decltype(auto) f(T x)
{
decltype(abs(std::declval<T>())) w;
w=abs(x);
return w;
}
int main()
{
using namespace std;
cout<<f(-1) << endl;
cout<<f(2.f)<< endl;
complex<double> z=complex<double>(1.0,1.0);
cout<<f(z)<<endl;
cin.get();
return 0;
}
いちかばちかでやったら、通りました。abs！ Who are you？ sizeof演算子と同じくコンパイル時に評価されるんですか？ というか、地味だけど declval が凄い。
432:はちみつ餃子
24/08/27 18:27:19.33 WfqXHPCU0.net
>>431
sizeof や decltype のオペランドは評価されないということになってる。
だからその文脈で関数を使う場合でもその関数が定義されている必要はない。 (宣言だけあればよい。)
評価されないけど実体化は起こるのでそのへんの理屈は複雑でよくわからん。
433:
24/08/30 02:40:03.60 qLymVnYK0.net
decval使ったコード始めてみたかも
434:デフォルトの名無しさん
24/08/30 05:15:18.21 ZIPlhev80.net
相互参照わっかんねぇ
435:デフォルトの名無しさん
24/09/02 12:36:59.33 bqeYsc0k0.net
相互参照は必要ない
最近はウェブプログラマのほうが賢くなった
すそ野が広がると質が良くなるらしい
436:デフォルトの名無しさん
24/09/02 13:00:06.45 Rco2Fp/20.net
必要ない理由ぐらい言ったら？
437:はちみつ餃子
24/09/02 14:42:22.37 o+5p2SR60.net
プログラムの文法要素が相互参照になっている状況という意味？
たとえば前方宣言が必要な場合とか。
それとも (実行時の) データ構造が相互参照ということ？
たとえば循環構造の後始末のやり方がわからんとか。
438:デフォルトの名無しさん (ﾜｯﾁｮｲ 0701-+rOo)
24/09/02 19:52:42.06 cn5uZ01w0.net
>>435
その「相互参照」って何?
439:デフォルトの名無しさん
24/09/05 00:06:16.92 /oUqYYg3a.net
相互参照も自己参照も一緒
自己参照なんて参照してるのは自己ではない
ホントの意味での自己参照は循環参照
440:デフォルトの名無しさん
24/09/05 18:17:57.29 xTcyjaky0.net
shared_ptrを使いたくなったら設計を見直すべき
441:デフォルトの名無しさん
24/09/06 07:27:10.33 Qb4sTpDj0.net
>>440
それは無理があるんじゃないのかね。
データ共有とかインターフェイス共有とか本質的に所有者が複数存在するオブジェクトはsharedptr使うべきかと。
設計ではモジュール間の疎結合・インターフェイスの汎用化を重視すべきで、そのためにはデータの共有方法が重要になる。
442:デフォルトの名無しさん
24/09/06 11:54:45.03 onD85wsiM.net
>>440
マルチスレッドセーフ考えたら使わざるを得ない場合は多々ある
言ってる意味がわからないならお前は経験不足
443:デフォルトの名無しさん
24/09/06 22:35:55.77 0hxwMUxG0.net
recurcive_mutexが欲しくなったら設計を見直したい、なら分かる気もする
444:デフォルトの名無しさん
24/09/07 11:45:08.02 Zy1zUumM0.net
C++11あたりから「生ポは使うな」みたいな極論で分かった気になってる思い上がった初心者が増えたからなぁ
445:デフォルトの名無しさん
24/09/07 11:58:09.00 UFsx2JaR0.net
>>444
生ポ使うよりかスマートポインタの参照を使った方がマシだったりするからなぁ。スマートポインタがスタックフレームにあるなら安全だし。
スタック変数専用仮引数とかあればもっと安全になるのになぁ。
仮引数の種類はもっとあっていいと思う。
446:デフォルトの名無しさん
24/09/07 16:26:14.57 lSV8lU690.net
>>445
考え方にもよるだろうけど、確保も解放も所有もしない関数でスマポ受け取る必要あるか？
特定の用途で管理されている特定のポインタしか許容しない、という意図ならスマポの参照でもいいだろうけど、汎用性は無いよね
生ポ受け取る場合暗黙のキャストも効かないし
447:デフォルトの名無しさん
24/09/07 20:17:38.39 Ci+xhqlU0.net
>>442
むしろshared_ptr<T>でスレッド間共有オブジェクトを保持するのは
生ポに対するshared_ptr<T>のメリットが無い……
可能な限りスレッド間共有なんてことはやめてconstオブジェクトのコピーにするのが正義……
>>439
自己参照ではないが前方宣言が必須の例、
class TreeNode;
class TreeNode {
std::shared_ptr<TreeNode> m_pLeft;
std::shared_ptr<TreeNode> m_pRight;
public:
TreeNode();
...
};
448:デフォルトの名無しさん
24/09/07 20:21:44.33 Ci+xhqlU0.net
んまー前方宣言が必須というのは言い杉やったかもしれんorz
TreeNodeみたいなクラスはノード毎にヒープを確保するなんてことはやめて専用のアロケーターを設けて
専用の領域をまとめて確保して、
木全体がいらなくなったら木をトラバースすることなく一気に解放するのが本当やが
その場合m_pLeftやm_pRightにあたるのはポインタではなくて専用の領域（配列）のindexとかにすれば
前方宣言は不要、
449:デフォルトの名無しさん
24/09/07 21:38:34.24 lSV8lU690.net
>>442
使わざるを得ないは言い過ぎじゃね
同期取るのにshared_ptrのアトミック保証に依存するしか方法が無いの？
競技プログラマか何かか？
450:デフォルトの名無しさん
24/09/08 00:33:39.65 vgBqrjWA0.net
shared_ptrの内部的な参照カウンタとかはともかく
保持しているオブジェクト自体はアトミックでもなんでもないでしょ
ってなんか勘違いしてる?
451:デフォルトの名無しさん
24/09/08 01:27:17.93 6Lpw1aoe0.net
持ってるポインタの指す先のオブジェクトがアトミックになるとか言ってると思ってんの？アホかw
452:デフォルトの名無しさん
24/09/08 01:32:50.82 TMvzCbR60.net
そこでRustですよ！
453:デフォルトの名無しさん
24/09/08 12:52:42.06 Lw7YNDXG0.net
でたｗ
布教ﾏｿw
454:デフォルトの名無しさん
24/09/10 11:29:59.05 v6KS9t6sM.net
>>447
お前の理解はshared_ptrの一面だけだな
ようするにunique_ptrの延長でしか見てない
shared_ptrがどうしても欲しくなるのは
オブジェクトのリリースタイミングが非決定的であるとき
これは一般的にマルチスレッド環境
お前のTreeNodeの例はそれこそ生ポで実装しても対して苦労しないが
例えば動的可変multi producerなqueueの場合確実に安全なqueueの解放タイミングを知るにはリファレンスカウントのような制御が必要となる
当然この場合コピーすれば安全なんて寝ぼけたことにはならない
455:デフォルトの名無しさん
24/09/10 13:20:49.36 KGjTz1X0a.net
x 対して
456:デフォルトの名無しさん
24/09/10 15:36:50.97 +l9ylb2n0.net
それで自己参照ってのは結局何のことを指して言っていたんだい
457:デフォルトの名無しさん
24/09/10 15:39:03.70 +l9ylb2n0.net
あ、相互参照が先か
>>436の言うところの
458:デフォルトの名無しさん
24/09/11 12:14:54.12 n6/LwjNL0.net
(*this)
↑
自己参照
459:デフォルトの名無しさん
24/09/11 12:19:01.05 n6/LwjNL0.net
木のノードはstd::vector<>で確保する
と言われて、だよねってなる人はnewもほとんど必要ない
460:デフォルトの名無しさん
24/09/11 12:22:29.60 n6/LwjNL0.net
木の巡回は、巡回方向別にアダプタとしてイテレータを用意することが出来る
良くある行きがかり順のイテレータはスタックを使って作る
461:デフォルトの名無しさん
24/09/11 15:12:04.16 1n/VD1trM.net
でvectorの拡張で破綻すんだろ？
462:デフォルトの名無しさん
24/09/13 16:29:50.66 bblj+c3pa.net
move禁止
463:デフォルトの名無しさん
24/09/13 19:59:43.80 2C9M8qgO0.net
move禁止したらvector使えないし
464:デフォルトの名無しさん
24/09/17 12:59:42.12 TMGdiCOOa.net
それならオブジェクトを保持するためのオブジェクトと
moveためだけのインデックスを分けるかな
465:デフォルトの名無しさん
24/09/17 16:24:30.60 DN+X/Cyr0.net
何がしたい
あほでしょ
466:447
24/09/21 20:05:42.93 FUSKAHoo0.net
何やら集中砲火を浴びている>>442 やが
マルチスレッド状況でshared_ptr<T>を超有効活用できる手が一つあったわ；；；
スレッド間の共有オブジェクトをポインタpで保持する際の問題点は、
そのポインタを知っている複数スレッドの間でpが指すオブジェクト*pへのアクセスを悉く排他制御せなばならない点やが
逆にpを知っているスレッドが任意の時刻につき1つだけなら、オブジェクトのアクセスに対して排他の必要が無い
それでいてスレッドへのデータの受け渡しに関してコピーの手間は減らせる
例:
なんちゃらWorkerスレッドオブジェクトをshared_ptr<Worker>のキューで保持しておく
スレッドfooが使うときWorker1をshared_ptr<Worker>としてpopする（←これは排他が要る
スレッドbarが使うときWorker2をshared_ptr<Worker>としてpopする（←これは排他が要る
...
（スレッドfooやbarはWorker1、2をそれぞれ独占的に使用できる） ←重要
...
スレッドfooが使い終わったWorker1をキューにpushする（←これは排他が要る
スレッドbarが使い終わったWorker2をキューにpushする（←これは排他が要る
467:447
24/09/21 20:13:25.63 FUSKAHoo0.net
ていうか2週間ぐらい前から作っていたやつが今さっき完動すた、
468:デフォルトの名無しさん
24/09/21 20:35:47.52 FUSKAHoo0.net
std::vector<TreeNode> nodes;
ならnodesを拡張したとき破綻するかもしれんが（nodeをnodesのindexで管理するならその限りではない
std::vector<std::shared_ptr<TreeNode> > apNodes;
ならapNodesを拡張しても破綻しないYO!（要素の実アドレスは保たれる
469:デフォルトの名無しさん
24/09/22 08:21:05.99 e5FZYjui0.net
それ何のためのshared_ptrなの？unique_ptrでいいというか横からコピーされないようにそうすべきでは
470:デフォルトの名無しさん
24/09/25 13:57:54.93 N5yN4IuU0.net
>>466
>>442 を書いたのおれだけど、なんでおれが集中砲火浴びてることになってんだよ
生ポとか意味不明なこといってる>>447は一見してわかるクソレスだろ
おまえはそれ以上のクソレスにクソコード
でもお前の勝ちだ
クソコードに2週間かけた情熱に免じて親切におしえてやるわ
shared_ptrはpに誰かがアクセスしている可能性がある間は決してdeleteされないことを保証できるのが肝
(pの先の排他ではこれは実現できない)
もちろんこれも正しく使わないと保証できない
よくあるミスは知ったかぶって参照カウントを操作しないようにshared_ptrを参照渡しとかにするやつな
その間に絶対deleteされない保証がないならやってはいけない
471:デフォルトの名無しさん
24/09/26 03:21:09.01 5BtHXQaO0.net
あーなるほど、一貫してshared_ptrの実体を渡してればそういう保証も出来るのか
自分の場合自前で排他処理や生存保証作ってたけど確かに大きなメリットだね
(オブジェクト内部の排他は別に必要だとしても)
472:デフォルトの名無しさん
24/09/26 10:52:52.31 R5lWYvWFa.net
そんなあなたにRust
473:デフォルトの名無しさん
24/09/26 11:26:35.22 r0pzUHiv0.net
>>472
c++コードと混在できるようになってからの話だな。
既存c++を捨てなきゃならんのなら要らん。
474:デフォルトの名無しさん
24/09/26 11:37:49.48 R5lWYvWFa.net
もちろんRustをやるにはC++を捨てる覚悟が必要
C++コード(特にテンプレやclass)とは相性最悪
475:デフォルトの名無しさん
24/09/26 11:38:22.04 R5lWYvWFa.net
>c++コードと混在できるようになって
Rustについて言うなら
おそらくそんな未来は永久に来ない
476:デフォルトの名無しさん
24/09/26 11:39:08.38 R5lWYvWFa.net
誤解の無いように言っておくと
(一部機能に限れば今でも混在出来るけど)
基本的にはC++とは相いれない
477:デフォルトの名無しさん
24/09/26 18:22:32.63 sl+cfKHN0.net
ならc++にRustの機能が取り込まれるのを待つ。
Rustが大人気になったら、さすがに標準委員の連中も初心者・コーダー向けの"Safe c++"をやる気になるだろ。
478:はちみつ餃子
24/09/26 18:52:53.17 B+Au+yIB0.net
>>477
もう Rust を使えばよくない……？
479:デフォルトの名無しさん
24/09/26 19:43:24.82 sl+cfKHN0.net
>>478
>>473だっつうの。
Kotlinみたいなのが欲しいのであって、Clojureみたいなのは要らん。
480:はちみつ餃子
24/09/26 20:25:47.69 B+Au+yIB0.net
>>165
C++ のコードを Rust から呼び出したりするくらいのことは簡単に出来るよ。
たぶん (Java に対する) Kotlin みたいなこととして思い浮かべているようなことは出来る。
Rust がやってるような安全性の保障を自動では受けられない。
当然だが安全ではない (安全性が検証されていない) C++ のコードが Rust から呼び出すことで安全になったりはしない。
大抵の場合に Rust の都合に合わせてラッパーを書くことになる。
481:デフォルトの名無しさん
24/09/27 10:23:27.00 n6BA5joS0.net
>>480
KotlinとJavaみたいにソースコードを混在できるレベルの相互運用性てあったっけ？
Rustとc++では無理だと思うけど。
482:デフォルトの名無しさん
24/09/27 10:44:00.51 02Aq/BhWM.net
cxxとかあるけど個人的には中途半端だから使わない
普通に共有ライブラリにして呼び出す方が素直で汎用的で良い
483:デフォルトの名無しさん
24/09/27 12:33:43.81 6/1p1gGO0.net
スマートポインターを使うように強制できる機能とかなら必要ないなあ
484:デフォルトの名無しさん
24/09/27 16:51:52.33 pgg/4VuRa.net
>>473 のような未来は永遠に来ない
485:デフォルトの名無しさん
24/09/27 16:54:13.57 pgg/4VuRa.net
>>482
結局Cが正解なんよ
C++のスレで言うのもなんだけど
486:デフォルトの名無しさん
24/09/27 16:54:31.95 pgg/4VuRa.net
>>481
同意
487:デフォルトの名無しさん
24/09/27 16:54:58.40 pgg/4VuRa.net
>>480
嘘つくな
出鱈目言うな
488:デフォルトの名無しさん
24/09/27 17:14:28.28 n6BA5joS0.net
>>483
コーダー向けので考えるなら、スマポ強制は最優先だろ。
生ポインタを(コーダーが)保存できなくするだけでも随分安全になる。あと生ポインタdelete禁止とか。
489:デフォルトの名無しさん (ﾜｯﾁｮｲ 728c-rNKn)
24/09/27 18:24:18.27 dg7IL8lg0.net
極限のパフォーマンスは別に要らないから安全にしたいという要件なら GC が既に解決しているし
今更生ポインタを禁止したところで C# や Java と同じ方向性のナニカにしかならんじゃろ
490:デフォルトの名無しさん
24/09/27 18:46:28.46 EoeiRCVP0.net
gcがあったらメモリリークしないなんて幻想未だに信じてるとはね
491:デフォルトの名無しさん
24/09/27 18:59:34.32 RwmUzOsi0.net
リークの話なの？
492:デフォルトの名無しさん
24/09/27 19:07:06.62 n6BA5joS0.net
>>489
ライブラリとかフレームワークを使う側のコーダーと作る側のライブラリアンは性能要件が全然別。
コーダーに対してライブラリアンが「コーダーのコードに極限のパフォーマンスは別に要らないから安全に「させたい」」というのはあるだろ。
493:デフォルトの名無しさん
24/09/27 23:12:04.55 cfj6fT7K0.net
>>492
それならライブラリ側でメモリ周りを隠蔽するような作り方も出来ると思うけど
ユーザー(コーダー)にはインスタンス使わせるけど内部では参照カウントなりスマポなり使ってるみたいな
それですら問題が起きるようならユーザーがクソ
494:デフォルトの名無しさん
24/09/28 10:42:06.28 swed/tX60.net
C++はどんな安全策敷いてもユーザー側がその気になればいくらでもぶち壊せるからね
ライブラリがあんまりそこ頑張っても仕方ない
495:デフォルトの名無しさん (ｱｳｱｳｴｰ Saaa-rNKn)
24/09/28 12:39:39.83 gf2/NL3ha.net
Rustなら壊れないみたいな言い草だな
496:デフォルトの名無しさん (ﾜｯﾁｮｲ 77ba-vp5J)
24/09/28 13:06:22.71 ZP4SxDa50.net
C++で書かれたChrome V8エンジンをRustから扱えるRusty V8というライブラリがリリースされたというニュースを見た
メモリ安全性を確保して呼び出しオーバーヘッドもゼロなんだって
ほんとかな？
ただのラッパーじゃないの？
C++側でメモリアクセス違反があれば落ちそうだけど
497:デフォルトの名無しさん
24/09/28 14:26:57.72 yW35cSECM.net
その手の話はMICROSOFTの新機能ぐらいい思っておけば
腹も立たない
498:はちみつ餃子
24/09/30 22:26:30.09 JxqgGnHQ0.net
>>496
Rust の標準ライブラリだって内部は unsafe だらけだぞ。
unsafe は Rust のメモリ安全性検査の例外とする指定で、検査はされないが安全であることはプログラマが保証しないといけない。
ただ、 unsafe な部分を慎重に押し込めて (押し込めるのが正しく出来ていれば) あとは Rust のメモリ安全性検査に頼ることが出来る。
ずっと気を付けなきゃならない C++ よりは面倒ごとを基盤に押し込めたら後は機械が検査してくれるほうがマシという程度の話。
押し込めた中に問題があればそりゃ当然駄目だよ。
499:デフォルトの名無しさん
24/10/01 02:05:59.60 J7GPtKrz0.net
V8エンジンてCVE脆弱性で毎月アップデートの口実にされる迷惑なやつだからさっさとRustで書き直せよ
500:デフォルトの名無しさん
24/10/01 15:19:57.32 KXGxeTHwM.net
>>498
>押し込めた中に問題があればそりゃ当然駄目だよ。
当然分かっているだろうが、unsafeの中だけでなく、
それが外側に及ぼす影響にも問題が生じないように作らなければなら
ないが、それにはunsafeとRustの両方に対する深い理解が
必要となるだろうな。
501:デフォルトの名無しさん
24/10/01 18:36:21.46 al1nAqGBM.net
>>500
unsafeの中を通過する時には問題ないが、
戻り値などや、連携する他のメソッドなどが
関係した結果、どこかで分かりにくいメモリーエラー
になるようなことも避ける必要が有るが、
それにはかなりRustの内部構造(?)に対する深い知識
と理解が必要となりそうだ。
502:デフォルトの名無しさん (ﾜｯﾁｮｲ 1fb1-/QnX)
24/10/17 11:01:19.65 P7X9/HPx0.net
>>422
これ、static_assertだけ修正してもしょうがない気がするんだけどなぁ
他にも実体化しないはずの分岐でチェックされてエラーにされることあるし
まぁ条件式に無理矢理テンプレート入れて回避は出来るけど
503:デフォルトの名無しさん
24/10/19 17:30:35.94 vb3IsOJN0.net
>>491
Rustのオブジェクトの所有権管理の強制はコンパイラに従う限りリークしない
（病的な反例があるかどうかは知らん
からリークの話ではないが、GC付き言語で解決という香具師が現れたから
504:デフォルトの名無しさん
24/10/19 17:31:10.99 vb3IsOJN0.net
>>490な発言になったんじゃないの
知らんけど
505:デフォルトの名無しさん
24/10/21 07:19:50.64 ThoL8xQh0.net
>>503
RustはRcの循環参照解決できたの？
公式ソースある？
506:デフォルトの名無しさん
24/10/21 14:54:46.51 WHCxApN50.net
C++派だが、Rustをもってしても、相互参照みたいなものは、人類には早いらしい
(設計段階で)無理しないこったな。。
507:デフォルトの名無しさん
24/10/21 15:57:11.21 Hhc6wfX80.net
そもそも静的解析で解決できる問題か？
508:はちみつ餃子
24/10/21 16:03:29.88 6JU3cZPt0.net
循環参照をしたいときに出来ないのも困るしな。
なるべくやらないに越したことはないが、やるなら後始末は人が考えないと仕方ないわ。
509:デフォルトの名無しさん
24/10/21 22:48:14.20 XvJERuqr0.net
食事する哲学者の問題……
Rustだと循環参照するコードを書きにくくなっているから
循環参照によるリークとか病的な反例のうちなんじゃないの
知らんけど
ノードNode同士が論理的には循環参照し得るんだけど
その所有権をスーパーバイザ的な配列superArray: Node[]が持っていて、
510:デフォルトの名無しさん
24/10/21 22:53:33.76 XvJERuqr0.net
Node間の参照はsuperArrayのindexで済ませるというのもRustではすんなり通してくれな
いんだっけどうだっけ……
Node& node1 = superArray[0];
Node& node2 = superArray[1];
node1.next = 1;
superArray[node1.next].value = 123; // node2.valueに書く
node1.nextがsuperArray[]の添え字範囲内であることを機械的に保証するためにRustはどんな魔法を使ってくれる
のか
511:はちみつ餃子
24/10/22 11:28:00.82 UXnTPhGj0.net
>>510
Rust では実行時にチェックされて範囲から外れていたら panic (C/C++ で言うところの abort みたいなもの) する。
URLﾘﾝｸ(doc.rust-lang.org)
C/C++ のように配列がポインタになるということはなく、スライス (C++ で言うところの span みたいなもの) が基本型として組み込まれているので範囲チェック出来る。
コンパイル時に範囲内であることがわかる状況なら最適化で消えることもあるみたいだけど
実行時に外部から入ってくる値に依存することもあるので実行時にチェックしないとどうしようもない。
512:デフォルトの名無しさん
24/10/28 13:44:32.71 A9ortPvu0.net
enum、
文字列への変換、
大変すぎて、ビックリした
513:デフォルトの名無しさん
24/10/28 14:06:10.17 /lht/Ba/0.net
俺はenumの機能を拡張するクラスを自分で定義してるな
それで文字列変換も文字列からの変換も出来る
514:デフォルトの名無しさん
24/10/28 15:41:01.09 xcgYWtNU0.net
autogenerated.txt.c みたいなの使うのも手だぞ 急がば回れ
そしてCよりはうまく書ける
515:デフォルトの名無しさん
24/10/29 08:22:28.04 XRXAB2XQ0.net
>>514
うーん、どんなもの？それ
516:デフォルトの名無しさん
24/10/29 13:58:12.41 WYOK+g300.net
好きなように書いて、好きなように変換して、途中でincludeする
簡単に書くもよし、ガッチガチにチェックするもよし
517:デフォルトの名無しさん
24/10/30 23:11:10.17 x0G86HEF0.net
HAGE(CAUWA1)
HAGE(CAUWA2)
HAGE(CAUWA3)
：
みたいなテキスト作っといて
手コキストを#includeする手前でHAGEの意味を変えてやるとうまいこと一元化できる
518:
24/10/31 00:43:29.18 ET2RcGMR0.net
ｶｳﾜ?
519:デフォルトの名無しさん
24/10/31 01:08:33.55 gisW4Gdb0.net
magic_enum教えてやれや
じじいは感度低いから知らんか
520:デフォルトの名無しさん
24/10/31 05:43:35.79 J4xtBqBy0.net
みてきた それが人気の実装か
やりたいこと次第だが、オーバスペック感はある
ちょうどほしかったんなら止めないけどね
521:デフォルトの名無しさん
24/10/31 10:56:16.92 ++2hP8JV0.net
横からなるほどー！
__PRETTY_FUNCTION__ / __FUNCSIG__
522:デフォルトの名無しさん
24/10/31 15:32:14.58 IcW65SaY0.net
あのー、アメリカグーグルで、検索すれば、良いのがでてきた
日本は、でてこない
これは、やっぱり、レベルなんだろうね
523:デフォルトの名無しさん
24/11/01 19:53:27.66 TgBKHsuNa.net
>>518
あさひ奈央
524:デフォルトの名無しさん
24/11/02 09:17:27.71 KpOoS8wa0.net
>>522
アメリカグーグルって言い方からして頭悪そう
525:デフォルトの名無しさん (ﾜｯﾁｮｲ 5910-fVPo)
24/11/05 08:04:39.53 //VVBUiD0.net
magic_enumは個数制限がきついんだよな・・256くらいが限度じゃなかったっけ
526:青木康善
24/11/06 17:05:23.05 vfgxFq1Ya.net
c plus plusとjava、電子音楽作成にどっちが向いてるかな？早いのは無論c plus plusだろうけど。
527:デフォルトの名無しさん
24/11/06 17:09:08.31 jrSvpMvx0.net
作成というが、記述したいのか、波形合成したいのか、はたまた生成(AI等)したいのか。。
528:デフォルトの名無しさん
24/11/06 17:14:36.09 P7rcAaD30.net
なんでjava？
529:デフォルトの名無しさん
24/11/06 20:06:37.45 TrFjb6KE0.net
>>526
C++ね
記号の入れ方知らないのかな
530:青木康善
24/11/06 20:56:51.96 XG1hV+N8a.net
C soundというのはかつてありましたが。javaでやろうかな。C++は自分にはハードル高すぎます。
531:はちみつ餃子
24/11/06 21:37:08.81 O6Mhx+Gj0.net
相談スレなんだから相談しなさいよ。
独り言を書きたいなら X で。
532:デフォルトの名無しさん
24/11/06 22:48:47.88 tlKINjNQr.net
５ちゃん初めてなんでしょ。浮いてるのはほっとこう、じきに慣れてくれる
コンパイラがCらしいね。でもjavaからも操作できる実績があるって
こういうときは、「やってみて脳汁が出そうなほう」でいいとおもう
結局モチベなんで
533:はちみつ餃子
24/11/07 03:05:44.48 LEgJ6Wm00.net
Csound は公式に Python や Java 用のラッパーは用意してるみたいだから得意なのでやればよさそう。
ところで固有名詞は正確に表記してくれないと探しにくいやで。
534:デフォルトの名無しさん
24/11/08 17:26:41.87 k0cYSKPq0.net
g++とclang++が混ざった環境なのですが、g++でコンパイルしたバイナリはstd::stringとか
名前に__cx11というプレフィックスが付き、一方clang++の方は__1というものが付くようです
とりあえず、clang++の方で__cx11が付くようなバイナリを生成するにはどうしたら
いいでしょうか?
535:デフォルトの名無しさん
24/11/08 17:28:48.87 k0cYSKPq0.net
すみません、__cx11じゃなくて__cxx11でした
536:はちみつ餃子
24/11/08 17:41:34.61 Me1tPYCI0.net
名前だけ合わせても具体的な実装方法が違えばどうせクラッシュするから意図的にマングルルールを違えている。
URLﾘﾝｸ(gcc.gnu.org)
537:デフォルトの名無しさん
24/11/08 17:52:36.03 k0cYSKPq0.net
>>536
なるほど、要は「C++コンパイラ、混ぜるな危険」ということでしょうか?
538:デフォルトの名無しさん
24/11/08 18:12:15.75 6Qfff3nN0.net
例外とか互換性があるんかいな?
539:デフォルトの名無しさん
24/11/08 18:14:37.25 6Qfff3nN0.net
C++コンパイラでコンパイルするにしても
ソースコードをCの範囲に留めて
関数プロトタイプを
extern "C"
すれば大丈夫だよ
540:デフォルトの名無しさん
24/11/08 18:18:53.42 k0cYSKPq0.net
>>539
なるほど、例えばこんな感じなら大丈夫なんですかね?
g++でコンパイルされたバイナリのグループAとclang++でコンパイルされたバイナリの
グループBがあったとき、AからB（またはその逆）を呼ぶときは必ずCリンケージの関数
経由にする、とか....
541:はちみつ餃子
24/11/08 18:25:46.25 Evz7xgHe0.net
>>540
OK。
C インターフェイスの範囲ではどちらも同じ ABI (Application Binary Interface) に従ってるはず。
542:デフォルトの名無しさん
24/11/08 18:35:59.90 k0cYSKPq0.net
>>541
なるほど
皆さんどうもありがとうございます
543:デフォルトの名無しさん
24/11/09 19:08:22.86 djyKk80a0.net
昔std::vector<T>とかstd::stringを前のコンパイラでビルドしたDLLに渡したら以下略
やっぱコンパイラを混ぜるときはextern "C" な関数にプリミティブな型のみを渡すインターフェース設計にするﾊﾟﾃｨｰﾝが安牌
文字列とか渡したかったらあくまでchar[]にすべき……
544:デフォルトの名無しさん
24/11/10 16:10:22.46 ck6aMoNGM.net
>>536
この場合は別々に標準ライブラリがリンクされる、つまり2つ動くのかな？
545:デフォルトの名無しさん
24/11/10 17:48:03.99 cLh8//6O0.net
単にリンクするだけではどっちかのライブラリのスタートアップしか呼ばれないから
呼ばれてない方のライブラリの初期化がされなくてまともに動作しない問題が残ると思う
546:はちみつ餃子
24/11/10 18:18:05.60 R/A45v0+0.net
仮にどうにか辻褄合わせが出来てちゃんと動いたとしても将来の開発環境・実行環境でどうなるか予想しづらいというのもある。
547:デフォルトの名無しさん
24/11/10 18:55:50.75 g8WH2rn90.net
こういう感じの実装を見かけたんだけど、ptrって解放済みの領域を指してないよね？
int *ptr = NULL;
std::map<char, int> m;
m.insert(std::make_pair('a', 30));
{
std::map<char, int>::iterator itr = m.find('a');
if (itr != m.end()) ptr = &(itr->second);
// ここでitrは解放される
}
if (ptr) printf("*ptr = %d\n", *ptr); // 大丈夫？
548:はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ cd32-bar5)
24/11/10 19:59:53.20 a6nPaG4v0.net
>>547
itr が指してる先は m の一部なのでまだ生きてる。
問題ない。
549:デフォルトの名無しさん
24/11/10 20:31:11.60 g8WH2rn90.net
>>548
あざっす！なるほど、よかった～
550:デフォルトの名無しさん
24/11/11 00:36:44.76 6qsu0cnY0.net
>>545
ﾔｳﾞｧｲやん>>539しても全然OKじゃないやん……
551:デフォルトの名無しさん
24/11/11 00:38:49.39 6qsu0cnY0.net
ただしウィンドーズのDLLの呼び出し場合は>>539に従っていれば問題無いはず……
ランタイムの初期化エントリはDLL毎に_DllMainCRTStartup が用意されてDLL初期化時に呼ばれる
552:デフォルトの名無しさん (ﾜｯﾁｮｲ 759b-NX7e)
24/11/11 16:46:00.51 XlNa4SSE0.net
URLﾘﾝｸ(www.openwork.jp)
553:青木康善
24/11/12 22:22:32.82 svwbS+Oga.net
独習C++を図書館で借りました。よく、こんな、難しく、エグい言語が出来ますねみなさん。
554:デフォルトの名無しさん (ﾜｯﾁｮｲ 1d1f-hYHe)
24/11/12 22:26:44.98 r67kfyB40.net
他に選択肢がなかったんや😭
あと最近はobjective-cとかいう悪魔合体に比べたらなんでもマシな言語に思えてきてる
555:デフォルトの名無しさん
24/11/13 01:53:29.63 CoujH3FQ0.net
Objective-C++もよろしく
556:はちみつ餃子
24/11/13 02:14:12.02 Gj2zjD3b0.net
>>553
汚いが、必要なものはある。
綺麗に整理されてても必要なものがないよりは良い。
557:デフォルトの名無しさん
24/11/13 03:47:19.43 rKuXlBFV0.net
そーだそーだ
C++は難しいからObject Pascalやろうぜ！
558:デフォルトの名無しさん
24/11/14 07:49:57.71 z8CYzrjO0.net
C++女学院の人々ってまだ読める所ある？
大好きだったんだけど。
559:デフォルトの名無しさん (ﾜｯﾁｮｲ a501-3n/g)
24/11/14 12:23:07.88 DkukOutW0.net
>>554
C++と悪魔合体してObjective-C++とかなってるけど自分は実用的に感じた
全部それで書こうとは思わんけど、C++との共存のレベルが高くて鼻血出そうになったわ
OSやその他Apple系APIとのやり取りはObjC++、それ以外のソースはC++のみ、とかも簡単だし
560:デフォルトの名無しさん (ｱｳｱｳｴｰ Sa13-vkNS)
24/11/14 14:52:24.21 a5xmyjQfa.net
>>553
若い人がCからC++の増築増築で可笑しくなって行った歴史をなぞるのは無意味ではない
>>554-555
Objective-C や Objective-C++ の方がまし
やる気は無いけどObjectPASCALはDelphiだっけ
561:デフォルトの名無しさん
24/11/19 11:41:41.34 1x1cv+pZH.net
演算子のオーバーロードない言語はダメだ
562:デフォルトの名無しさん
24/11/19 11:53:31.53 5+FMYvHmM.net
演算子オーバーロードがもたらす言語仕様の複雑性を理解してたら軽々しくそういうことは言えない
563:デフォルトの名無しさん
24/12/08 01:45:50.04 EhZF4lXKz
5chの管理人がRustマンセー野郎でRustの悪口言ったらBBS規制になっちまった。
それでこっちに書いときます。eigenという行列演算、線形代数ライブラリが
ありますが、これ列主順なんですね。なので、[]演算子のオーバーロードでは
行列Aのi行j列の要素にアクセスするときにA[j][i]という奇妙な順番でないと
いけない。それでeigenでは行列に対してA[i][j]みたいなサポートはしていない。
だから[]ではなく[][]演算子みたいな拡張がほしいと思いました。
564:デフォルトの名無しさん
24/12/08 02:15:01.21 EhZF4lXKz
マトリックスクラスを宣言すると
matrix_<double> a[3][3];
で何の対策もせずに、a[0][1][2][3]=１; みたいなアクセスは問題なくできるんですよ。
サイズ宣言時にa[3][3](3,3);というダサい形に。でもこれはstdsize(3,3);とでもして
おけば解決します。でも、列主順のときにはa[j][i]がネックに。()演算子なら列主順
だろが行主順だろが問題なくオーバーロードで解決できるんですが、A(i,j)の添字が0
から始まるのはfortran使っていた自分には違和感があります。
それでA[i,j]？ C言語のA[i][j]の伝統を捨てるんですか？ 感性の問題ですけど。
565:デフォルトの名無しさん
24/12/08 17:15:54.70 EhZF4lXKz
なるほど。C#に引っ張られたわけですね。a[i][j]の ][ を , に置き換えるプログラム
を作成すれば大きな影響もなく変換できそうですね。
でも、a[i][j]は残すんですよね？残さないと、ブーイングもしくはC++23もういいわ
になりそう。