18/04/28 16:51:34.89 ueAKslGb0.net
ああすまん、何となく1行目の意味は分かった。
・クラスインスタンスをstatic変数に入れ、そのメソッドを呼んだ
事をそう表現したのかな？
だったらはっきり言ってstatic云々関係ない。
GCなんて無いから「statc変数に入れたら忘れてGCされてしまう」みたいなことはそもそも無い。
ヒープを壊しているのはユーザーです。つーか、ランタイムもないし。
ガチでコンパイラのバグだと思っているのなら、
どのみち再現コード（その場合は20行程度か）を作るしかない。
その過程で君のバグだと気づけるだろうさ。
ただこのように「下から」デバッグをするのは時間がかかるから、俺は嫌いだけど、
君がそう思うのならやるしかない。
C/C++は広く長く使われて来ている言語だから、
現在もバリバリに使われているコンパイラなら、この辺の基本的な部分にバグは無いと思うよ。
static変数に確保するのはマイナーかもしれないが、滅多にやらないってほどではないし、
そもそも上記の通り、コンパイラにとって危険のある（バグに命中する可能性のある）使い方でもない。
474:デフォルトの名無しさん
18/04/28 16:59:13.74 9z8isRDe0.net
>>460
破壊って何？
475:デフォルトの名無しさん
18/04/28 17:20:06.35 aIENMcPWd.net
ふつうに、
クラスのインスタンスがstatic宣言と読んだけだ
static MyClass a;
スコープローカルかファイルローカルかはわからん
476:デフォルトの名無しさん
18/04/28 17:29:35.84 ueAKslGb0.net
>>450
>>464
日本語でおｋ
お前は半島に帰れ
>>452
それでお前は何パスだと思うのさ？
予言してやる。お前は言えない。
なぜならお前は馬鹿であり、それがばれるのが怖いから。
477:デフォルトの名無しさん
18/04/28 17:46:24.07 aIENMcPWd.net
おれは数学の専門家だぞ
わからないわけがない
478:デフォルトの名無しさん
18/04/28 17:46:53.04 aIENMcPWd.net
なぜ問題を出したのか考えてみ
479:デフォルトの名無しさん
18/04/28 18:39:11.84 ueAKslGb0.net
ひとまず俺の一つ目の予言は的中だな。
次に行こう。
>>467
ID:aIENMcPWd
お前の日本語の間違いをすべて訂正してみろ。
2つ目の予言をする。お前は言えない。
なぜならお前はゴキブリ韓国人であり、間違いを認識できていないから。
480:デフォルトの名無しさん
18/04/29 02:23:46.17 UY96NiMha.net
C++でプラットフォームに依存しない音楽再生ライブラリってある？特にlinuxで使いたいんだけど。
mpg123とかいうのもみてみたんだけどプログラムに組み込むやり方が分からない
481:デフォルトの名無しさん
18/04/29 02:25:23.22 kTR2ZRC/0.net
MIDAS
482:デフォルトの名無しさん
18/04/29 07:28:51.71 riHNUW7H0.net
Gstreamer
483:デフォルトの名無しさん
18/04/29 10:01:20.67 4Txko8z40.net
質問ですが
Q1.
浮動小数点型について表現しえる最小の値（負の値のうちの絶対値が最大のやつ）を取得する
環境非依存なやり方はどうすれば良いの？
-std::numeric_limits<double>::max()とか
-DBL_MAX
でおk？
Q2.
テンプレートを型引数が整数型と浮動小数点型で分けたいんですが
同じ名前のテンプレート名のまま、テンプレートの特殊化的な簡単に済ませる方法は無い？
484:デフォルトの名無しさん
18/04/29 10:55:07.91 6B047Ccs0.net
>Q2
template <typename T, bool = std::is_floating_point<T>::value>
struct hoge {};
template <typename T>
struct hoge<T, true> {};
485:デフォルトの名無しさん
18/04/29 11:05:23.85 iHQcqnOH0.net
>>472
>Q2.
こういう事？
URLﾘﾝｸ(ideone.com)
486:デフォルトの名無しさん
18/04/29 13:22:08.35 WuAwAiPA0.net
>>472
std::numeric_limits<double>::lowest()
487:デフォルトの名無しさん
18/04/29 13:56:48.76 4Txko8z40.net
まりがとうございます
>>473
>>475
すばらっし
>>474
言葉足らずでｽﾏﾝｶｯﾀorz
具体的型名で特殊化する普通の特殊化ではfloatとdoubleのそれぞれについて特殊化した定義を与えねばならないので
>>473みたいなやつを求めていたのです！ヽ(＞∀＜)ﾉ！！！１１１！１！
488:デフォルトの名無しさん
18/04/29 15:24:36.24 AQKaesvCd.net
たまにはlong doubleも思い出してあげてください
489:デフォルトの名無しさん
18/04/30 23:11:41.90 xhvNrk1GM.net
Boost.Optionalを使う際に、
対象クラスが自分自身の有効無効を変更できるようにしようとしてみたところ、
宣言時に宣言対象を引数にとって初期化できることに気づきました。
変数の引数に変数自身を使うのは仕様的にありなのでしょうか？
URLﾘﾝｸ(wandbox.org)
490:デフォルトの名無しさん
18/04/30 23:32:18.45 9aMn2TSu0.net
ポインタか参照なら問題ない
中身は使えない
491:デフォルトの名無しさん
18/05/01 23:40:40.03 dOOCYV+Z0.net
CObject obj;
for(i=0; i<N; i++)
{
obj = new CObject();
・・・（処理)・・・
}
↑みたいにdeleteせずにnew演算子でクラスオブジェクトを割り振り続けるプログラムってお行儀悪い？
CObject obj;
for(i=0; i<N; i++)
{
obj = new CObject();
・・・（処理)・・・
delete(obj);
}
↑こういうふうにすべき？ 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)
492:デフォルトの名無しさん
18/05/01 23:49:10.85 +P0DkpYu0.net
unique_ptr使うべき
493:デフォルトの名無しさん
18/05/01 23:54:52.50 2ADD+YWD0.net
今時newなんかを自分で書いてることに疑問を持ったほうがいい
494:デフォルトの名無しさん
18/05/01 23:55:37.66 b3AAvo5J0.net
>>480
お行儀の次元の話じゃない
495:デフォルトの名無しさん
18/05/02 00:01:31.48 LLl+2Gg10.net
手っ取り早く動かしたいその場限りのコードならそういうことをやることもある
くらいかな
496:デフォルトの名無しさん
18/05/02 00:09:49.83 HN9ze8O60.net
ビンラディン並みのテロリストだな
497:デフォルトの名無しさん
18/05/02 00:09:55.64 MK7npuGj0.net
そんなにお行儀悪いんでつか(´；ω；｀)・・・
498:デフォルトの名無しさん
18/05/02 00:43:03.85 Ve
499:qNn1690.net
500:デフォルトの名無しさん
18/05/02 01:21:31.16 9riosu0F0.net
ポインタじゃないものにnewしたもの格納できるとでも思っているのかジャバグラマ上がりのトーシロー
501:デフォルトの名無しさん
18/05/02 01:32:41.73 G9KSYPOz0.net
なんでdeleteしなくていいと思ったんや
502:デフォルトの名無しさん
18/05/02 01:39:46.98 HN9ze8O60.net
釣りだと思う
503:デフォルトの名無しさん
18/05/02 03:44:38.96 MK7npuGj0.net
deleteしてからnewすることにします・・・
>>488
こうでしたorz
CObject* obj;
504:デフォルトの名無しさん
18/05/02 06:00:07.99 3K4Hzh4Z0.net
>>480
C++的には
for(i=0; i<N; i++)
{
CObject obj;
・・・（処理)・・・
}
でいいんじゃね
505:デフォルトの名無しさん
18/05/02 10:02:54.88 EfCiDMro0.net
大規模なコードで大量にオブジェクト生成するならアリだと思うけど
その場合もnewしたものをdeleteするための仕組みは必須だしね
追跡できなくなる、もしくは自分で自分を破棄する仕組みも無いようではダメ
506:デフォルトの名無しさん
18/05/02 11:01:41.50 lsKTgXIy0.net
ライブラリに分ける利点ってなんですかね
507:デフォルトの名無しさん
18/05/02 14:44:29.23 MK7npuGj0.net
>>482
クラスのメンバ変数に他のクラスインスタンスを召喚するときとか
コンストラクタでnewしてやらないといけないと思うの
508:デフォルトの名無しさん
18/05/02 14:47:38.93 G9KSYPOz0.net
>>494
複数のプロジェクトで使いまわせる
>>495
スマポ(かコンテナ)で大体のnewは回避できる
そのケースも回避できる
509:デフォルトの名無しさん
18/05/02 15:02:47.22 .net
>>495
別にnewしなくてもよくね？
なんかサンプル出してみ？
new無くしてやっから
510:デフォルトの名無しさん
18/05/02 16:18:42.29 MK7npuGj0.net
>>497
class CTest
{
CFoo cfoo;
void CTest()
{
cfoo = new CFoo();
}
};
こんなんとかどうでしょう
511:デフォルトの名無しさん
18/05/02 16:23:28.41 BwUG32HZa.net
>>498
class CTest
{
CFoo cfoo;
void CTest(): cfoo()
{
}
};
メンバ初期化子知らんのか
512:デフォルトの名無しさん
18/05/02 16:28:43.53 hqQx66t6a.net
山口メンバーも初期化できたらいいのに
513:デフォルトの名無しさん
18/05/02 16:29:15.41 9riosu0F0.net
ヤバいなジャバ上がりｗ
514:デフォルトの名無しさん
18/05/02 16:36:00.09 BwUG32HZa.net
ちなみに非PODならメンバ初期化子に書かなくてもデフォルトコンストラクタで初期化子される
515:デフォルトの名無しさん
18/05/02 16:36:35.49 .net
そもそも>>498の例なら初期化子自体いらんしｗ
516:デフォルトの名無しさん
18/05/02 17:10:02.19 MK7npuGj0.net
>>499
そ、そうやって初期化したcfooはdeleteしなくてもいいんでつか？
517:デフォルトの名無しさん
18/05/02 17:15:22.77 2RgXx2xAF.net
>>504
変数の寿命を理解してないのか？
C/C++で変数の寿命を理解せずコード書くとメモリリークだらけになるから止めるか横着せず勉強するかしてくれ
518:デフォルトの名無しさん
18/05/02 17:19:29.16 9riosu0F0.net
>>504
何言ってんだお前は
そもそもdelete出来んだろ
519:デフォルトの名無しさん
18/05/02 17:35:57.58 EH+UkdGd0.net
教えてください
やりたい事は ↓
URLﾘﾝｸ(stackoverflow.com)
ここに出てるようなPropertyGridで、数値配列の値を16進で表示したい
[0] 0x0001
[1] 0x0002
[2] 0x0003
....
例えば↑とか、単にこれだけ
そうとう調べまくったんだが、配列の例はみつけられなかった
配列でなければ、実装例は結構見つかるんだが・・・
一見簡単そうなんだけど、俺のレベルでは不可能
520:デフォルトの名無しさん
18/05/02 18:09:52.99 2RgXx2xAF.net
>>507
それC++の質問なの？
.NETのライブラリ(=>C++/CLI)じゃなくて？
521:デフォルトの名無しさん
18/05/02 18:25:45.38 EH+UkdGd0.net
いや、c# です
522:片山博文MZ
18/05/02 18:26:58.58 fs6y
523:NkAId.net
524:デフォルトの名無しさん
18/05/02 18:29:31.79 EH+UkdGd0.net
ごめん間違えた、ここ C++のスレだった
隣で聞きます。
525:
18/05/02 18:52:21.12 R3g8E+PO0.net
>>504
delete しなくてもいいのです
526:デフォルトの名無しさん
18/05/02 19:04:04.70 MK7npuGj0.net
>>505
>>506
>>512
み、みんな、親切にありがとう・・・
527:デフォルトの名無しさん
18/05/02 19:06:49.69 U7aQES8cr.net
>>494
一度に作る分量が減るので間違えにくい
別々の人間が手分けして作れる
528:デフォルトの名無しさん
18/05/02 20:14:18.27 sTDjib3HM.net
>>503
そもそも>>498はコンパイルエラー（もしくは警告）になるだろ...
class CTest
{
CFoo* cfoo;
CTest(int x){
cfoo = new CFoo(x);
}
~CTest(){
delete cfoo;
}
void ReNew(int x){
delete cfoo;
cfoo = new CFoo(x);
}
};
みたいな奴を想定してたのかも知らんけどこれでもunique_ptr使えば良いだけだしね
529:デフォルトの名無しさん
18/05/02 23:29:42.51 .net
どうせ>>498の
CFoo cfoo;
はこれまた
CFoo *cfoo;
のつもりだったんだろう
とりあえず>>499の形にすればnewはなくせる
ポインタを保持したい場合も生ポインタはやめたほうがいいね
530:はちみつ餃子
18/05/02 23:41:46.06 g0SlpjdS0.net
可能な限りスマートポインタを使え、そしてスマートポインタで駄目な場合はほとんどないってのはその通りなんだけど、
初心者が生ポインタをちゃんと理解したことのないままスマートポインタを使いこなせるとも思えぬ。
そこらへんはちゃんと分けて、今回の場合はまずは生ポインタを理解するという方向性で説明する場面じゃろ。
531:デフォルトの名無しさん
18/05/02 23:47:44.17 MK7npuGj0.net
>>516
>>499を仰ぎますm(_ _)m
532:デフォルトの名無しさん
18/05/03 00:10:52.91 XlBZHwDZ0.net
もうスマポはスマポとして理解させたほうがいいような気がするけどな
下手な生ポの知識は初心者に有害だ
533:デフォルトの名無しさん
18/05/03 01:53:27.71 OyWVOyw+0.net
ていうかコンストラクタだから返却値型いらんやん
534:デフォルトの名無しさん
18/05/03 02:06:40.03 jt77zXjA0.net
ポインターをdeleteせずに扱う猛者がいると聞いて駆け付けてきた
535:はちみつ餃子
18/05/03 02:41:54.13 HFudy7bE0.net
delete をしない戦略ってのは無くはないよ。
アプリケーションの起動時直後にガッと大量のメモリを必要として、
終了直前に全部解放するってパターンなら、
どうせプロセスの終了と一緒にリソースは回収されるのでわざわざメモリ解放の処理を入れる必要はない。
(C++ だとデストラクタは必ずしもメモリを解放するだけではないので注意が必要だが)
だけどそういう戦略をとれるのはちゃんと理解した上で問題にならないことを確信できるだけの知識があってこそだわな。
というか、それ以上に、確保したのを解放しないのは「気持ち悪い」と感じる心が C/C++er にはある。
536:デフォルトの名無しさん
18/05/03 05:19:48.86 qNLpdLzsd.net
組み込みだとそもそも終了なんてものがなかったりする
537:デフォルトの名無しさん
18/05/03 20:37:30.17 giVWGYEy0.net
解放しないメモリをnewとか頭湧いてんのか
538:はちみつ餃子
18/05/03 20:40:51.26 HFudy7bE0.net
あたまがあったまってるんだ。
539:デフォルトの名無しさん
18/05/03 21:00:46.14 Nqnp2049M.net
確保済みメモリに対してのnewってあるよ
540:
18/05/03 21:15:35.38 hvfEvXXP0.net
>>526
placement new の意味が今でもよくわかりません…どんなときに使うのかなあ…
541:片山博文MZ
18/05/03 21:18:01.47 RMsmDfZSd.net
char buf[MAX_BUF];
new(buf) MY_STRUCT(1, 2
542:, 3);
543:片山博文MZ
18/05/03 21:18:51.15 RMsmDfZSd.net
char buf[sizeof(MY_STRUCT)];
new(buf) MY_STRUCT(1, 2, 3);
544:はちみつ餃子
18/05/03 21:19:45.60 HFudy7bE0.net
>>527
VRAM みたいな特殊なメモリを C++ のオブジェクトに見せかけたい場合とか
545:片山博文MZ
18/05/03 21:20:25.98 RMsmDfZSd.net
すでに確保したメモリーブロック上でコンストラクターを発動させる。
546:デフォルトの名無しさん
18/05/03 21:23:27.91 IMqmw2mT0.net
組み込みとかゲーム機のような、最初に一気に確保する環境で使うんじゃないかね
といっても確保済みのメモリに対して断片化しないように管理する仕組み作ったら、必然的にnew演算子もオーバーロードするだろうから結局placement new使わんかもしれんけど
547:デフォルトの名無しさん
18/05/04 04:49:56.51 JszYn0L4M.net
クラスを丸ごとDLL化するときにはnew系をオーバーロード
しておかないと解放時にエラーになるべ。
ヒープはDLL単位にあるので集めておきたい場合はplacement使う
548:デフォルトの名無しさん
18/05/04 11:44:28.56 8Ch7v1Nca.net
unique_ptrの配列版でメモリの再確保を行いたい場合どのように行うのがベターですか？
549:デフォルトの名無しさん
18/05/04 11:50:52.58 Z8Fitafid.net
何に対してベター？
550:デフォルトの名無しさん
18/05/04 12:02:46.79 uwR6wCpjM.net
>>534
unique_ptr::reset( ) じゃねーの？
551:デフォルトの名無しさん
18/05/04 15:25:56.64 xM/0IOG70.net
スマポ使うときは最初にnewするもんなんじゃ…
552:デフォルトの名無しさん
18/05/04 15:29:55.09 YqO5U4DS0.net
make_unique使ってね
553:デフォルトの名無しさん
18/05/04 15:47:45.28 kp+zcI/10.net
配列伸ばしたいなら素直にvector使え
554:デフォルトの名無しさん
18/05/04 22:00:12.15 VI6126jwa.net
いろんな意味にとれるから質問の答えは未定義
555:デフォルトの名無しさん
18/05/05 18:32:19.19 sJdk0i7H0.net
[][][] [[[ ] X_[[[ [] ][ [] ][][[[]
556:デフォルトの名無しさん
18/05/06 13:23:46.73 z9ZCOpRGM.net
以下のように、派生クラスのメンバ関数で基底クラスのメンバ関数を呼ぶように
基底クラスが派生クラスに強制する方法はないでしょうか？
URLﾘﾝｸ(wandbox.org)
557:デフォルトの名無しさん
18/05/06 14:01:54.85 f5coeozT0.net
FAQやな
インターフェースとカスタマイズポイントを分けろ
struct base {
void f() { //非仮想
cout << "base" << endl;
this->f_custom();
}
private:
virtual void f_custom(){}
};
struct child : base {
void f_custom() override {
cout << "child" << endl;
}
};
558:デフォルトの名無しさん
18/05/06 14:08:44.77 1ubTl4pj0.net
>>542
NVIじゃね？
URLﾘﾝｸ(wandbox.org)
559:542
18/05/06 14:59:52.15 z9ZCOpRGM.net
レスありがとうございます。
NVIというのがあるのですね。
（大昔に勉強したような…しかし思い出せず）
560:デフォルトの名無しさん
18/05/06 15:57:13.38 Amh1VkyH0.net
大昔とかの問題じゃなくて基本だぞ
561:デフォルトの名無しさん
18/05/06 19:15:44.52 5lNukHv1M.net
>>544
pure virtualなのに関数定義することなんてできたのか…
f()とbase::f()は同じ関数なんだよね？
562:デフォルトの名無しさん
18/05/06 19:32:29.01 9CUhRDV/0.net
}]] [[《_["[[]]" 〈[]》》 [][][]0,1》》〈〉 [] } } "B,V,0%%%,*1BVLO,SASA1`}}//%\\0,1\"VL"\
563:デフォルトの名無しさん
18/05/06 19:37:26.47 hMxfhnzD0.net
>>547
俺も知らんかった...
規格上も正しいみたい
URLﾘﾝｸ(cpplover.blogspot.jp)
564:デフォルトの名無しさん
18/05/07 05:32:12.66 WYJ+W2Mc0.net
>>547
12行目のbase::f()はvirtualを抑止してpure virtualを呼び出す
13行目のf();は動的結合でchi
565:d::f()を呼び出す baseは抽象クラスでnew base{}できないので 13行目の動的結合がbase::f()を呼び出すということは起こりえない だからif(typeid(*this) != typeid(base))のようなチェックをしていない
566:デフォルトの名無しさん
18/05/07 22:52:31.63 JZ0Er0Nn0.net
ちょっと根本的な質問を。
C#が既に普及しているなかあえてC++に固執する理由ってある？
567:デフォルトの名無しさん
18/05/07 23:34:15.98 Xl7KiTHE0.net
MSのOSしか使わないなんちゃてPGならC#で十分じゃないの
568:デフォルトの名無しさん
18/05/08 09:42:55.49 JvzvEXdEd.net
mono/Xamarinはしんどいと言う事を知らない世界の内はいいんじゃない？
大体Win限定だとしても高速化するのにC++で書いたのをdllimportするだろう
569:デフォルトの名無しさん
18/05/08 10:29:13.38 EjLESs2X0.net
ざまりんが苦しい人は信仰が足りないのです
僕は信仰の自由を主張しますけどね
570:
18/05/08 17:04:15.75 6aMWII0O0.net
>>551
余計な依存関係をかかえないのが嬉しいです
571:デフォルトの名無しさん
18/05/09 03:49:30.68 .net
Boostとか使ってると余計な依存関係をかかえてしまうけどな
C言語が一番
572:デフォルトの名無しさん
18/05/09 10:07:16.66 Ajqxpjd7d.net
一番多くの環境で使えるのはC言語
RAMが数十バイトしかないような非常にチープな8bitマイコンでも使える
573:デフォルトの名無しさん
18/05/09 10:29:31.98 ZxmL37bf0.net
数十バイトだとスタック領域ももパンクしそう、厳しいのではないか？
574:デフォルトの名無しさん
18/05/09 10:34:17.87 3kbM/2hPM.net
流石に盛り過ぎ
575:デフォルトの名無しさん
18/05/09 10:54:36.47 7azCP7HQa.net
知らないで盛ってると言うのはどうかと
昔6ピンpicでｃ使ってたけどRAMは16バイトだった気がする
576:デフォルトの名無しさん
18/05/09 11:01:43.78 7azCP7HQa.net
調べたら勘違いで自分の持ってたのはSRAM64バイトのpicだった
577:デフォルトの名無しさん
18/05/09 11:58:05.29 3kbM/2hPM.net
ＰＩＣ１２Ｆ６０９とかでもプログラム領域は1Kwあるけど
数十バイトしかない奴の型番教えてくれくれ
578:デフォルトの名無しさん
18/05/09 12:00:11.72 jousW3+sd.net
PIC10F200はRAMが16バイトですね
制約は当然ありますがC言語で開発出来ます
579:デフォルトの名無しさん
18/05/09 12:00:58.98 1NFscAG5a.net
C++どころかCすらやってはいけないレベルだな
恥ずかしいやつ
580:デフォルトの名無しさん
18/05/09 12:02:35.51 1NFscAG5a.net
>>562
ROMとRAMの区別がつかない人がなんでこのスレにいるのか？
581:デフォルトの名無しさん
18/05/09 12:04:25.14 3kbM/2hPM.net
ハーバードアーキテクチャのデータメモリサイズだけ書くの
卑怯だと思うの。プログラムメモリは２５６ワードあるじゃん
582:デフォルトの名無しさん
18/05/09 12:07:19.83 1NFscAG5a.net
>>557を受けての話だから
そのチープなマイコンで開発にCが使えてる
583:デフォルトの名無しさん
18/05/09 12:09:43.50 3kbM/2hPM.net
だから盛り過ぎでしょ
584:デフォルトの名無しさん
18/05/09 12:10:13.60 1NFscAG5a.net
>>568
じゃあできないというのか？
585:デフォルトの名無しさん
18/05/09 12:45:08.73 e8iSV/lBM.net
>>551
競技プログラミングとかunity覚えるの面倒とか？
586:デフォルトの名無しさん
18/05/09 13:09:28.13 J0gm0Ysvd.net
>>566
RAMってしっかり書いてるじゃん
チープなマイコンだとROM/RAMに別れてるのが普通だよアーキテクチャー関係無しに
587:デフォルトの名無しさん
18/05/09 18:42:26.74 X9SFPyiC0.net
スタックの話だよね
スタックはRAMであることが絶対条件なので
ROMがどんだけあろうが関係ない
588:デフォルトの名無しさん
18/05/09 18:49:54.96 bhGLBTeZa.net
C# と C++ は世の中でどちらのほうが使われているのでしょうか？
いま、 C++ の本（ロベール）を読んでいますが、無駄ですか？
柴田望洋訳の分厚い本も買
589:ってしまいました。
590:デフォルトの名無しさん
18/05/09 18:54:28.74 .net
C++は無駄とは言い切れないがロベールは無駄
591:デフォルトの名無しさん
18/05/09 18:59:28.28 bhGLBTeZa.net
>>574
ありがとうございます。
結局、どのプログラミング言語を習得するのがおすすめでしょうか？
Python のような言語は除いて。
592:デフォルトの名無しさん
18/05/09 19:01:30.85 ZxmL37bf0.net
何をやりたいと考えているか次第
593:デフォルトの名無しさん
18/05/09 19:05:22.21 bhGLBTeZa.net
>>576
趣味でアルゴリズムとデータ構造を勉強しています。
プログラミングコンテストの問題(Aizu Online Judge)を解いたりもしています。
もし、プログラマーになるとした場合、もっとも必要とされる言語を使って、
アルゴリズムとデータ構造の勉強をすれば効率的かなと考えています。
セジウィックとウエインの本や講義動画を読んだり見たりするときには、
Javaの入門書を見たりしています。
594:デフォルトの名無しさん
18/05/09 19:07:11.19 bhGLBTeZa.net
>>576
コンピューターサイエンスを広く学ぶ上で一番適した言語がいいかなとも考えています。
595:デフォルトの名無しさん
18/05/09 19:16:40.18 ZxmL37bf0.net
C++のスレで言うのもどうかとは思うが、
初心者が覚えるのに相応しい言語はJavaじゃないかなと思う
アルゴリズムだけを学びたいなら、C言語が良いかもしれない
他の人の意見も聞いてね
596:
18/05/09 19:47:49.06 dHqNIKDN0.net
>>577
そういうのがやりたくて、しかも今 C で片言がしゃべれるのなら、そのまま進めるのが一番いい
597:デフォルトの名無しさん
18/05/09 20:02:47.70 bhGLBTeZa.net
>>579
>>580
参考になりました。
ありがとうございました。
598:デフォルトの名無しさん
18/05/09 21:19:28.33 X9SFPyiC0.net
>>578
アセンブラかVerilog/VHDLあたりじゃね？
今の伝統的言語はユニプロセッサに源流があって
直列一辺倒の弱点が浮き彫りになっている昨今
【広く】学ぶうえでは却って足かせになるぞ
599:デフォルトの名無しさん
18/05/10 12:15:01.11 yXMj8vMdM.net
>>578
Occam2 とか XCが最凶かもな
600:デフォルトの名無しさん
18/05/10 12:20:40.60 YLAKf1v1a.net
Cはアルゴリズム勉強にはあまり向いてないと思う
以前各言語向けのアルゴリズム辞典みたいのを見比べてみたけど
Cのだけ異質な感じ
forのカウントいじってあったりして勉強しにくい
少なくともオブジェクト指向入れた言語じゃないと後で生かしにくい
601:はちみつ餃子
18/05/10 15:18:57.11 RiSXhiCD0.net
オブジェクト指向が導入されているべきかどうかというよりも、単純に C は抽象化の能力が低いんだよ。
下層レイヤを上手く隠せないから段階的に積み上げていくというのがやり難い。
学習段階では上から下まで見えているって方が分かりやすいということはあるかもしれないので、
どちらが良いかというのは考え方とか好みにもよるので一概には言えないと思う。
602:デフォルトの名無しさん
18/05/10 15:24:31.29 bWcYs//f0.net
アルゴリズムの仕組みが言語の内部に隠されると理解を妨げるだろう
オブジェクト指向については、別の機会に学べば良い
603:はちみつ餃子
18/05/10 15:59:00.64 RiSXhiCD0.net
そうとも言えない。
複雑なものを理解するには「分解する」は基本的なアプローチのひとつで、レイヤを切り分けるのは有用だよ。
それが >>585 に書いた「段階的に積み上げていく」の意図ね。
かといってそれで全体像
604:が見通しにくくなってもそれはそれでアレだし、何がベストかなんて言えないよ。 やりやすいと思った方でやるしかしょうがないんじゃね。
605:デフォルトの名無しさん
18/05/10 16:46:33.01 bWcYs//f0.net
C言語で書かれたアルゴリズムが読み解けるようでないと
後で困るだろう
606:デフォルトの名無しさん
18/05/10 17:51:59.26 Ulb5C2sT0.net
C以外だとリストのシャッフルはshuffleだけで済ませられる
Cだとshuffleの中身を書かないといけない
C以外だと「Combination()を使おう」
Cだと「Combination()を実装しよう」
くらいの差がある
アルゴリズムがどこまで指すのか分らないが、楽しいことから先にやればいいんじゃねえの、ということで、C以外から
607:デフォルトの名無しさん
18/05/10 18:15:07.55 bWcYs//f0.net
アルゴリズムを学習するって、その実装の中身を理解することだろう
608:デフォルトの名無しさん
18/05/10 18:39:39.67 k0RUZ23fa.net
個人的には、各種ソートや基本的なデータ構造の操作を自前で書くようなシンプルなところから入った方が分かりやすいかと思うけど、まあ人それぞれかなと。
609:デフォルトの名無しさん
18/05/10 18:45:52.70 yjf1B9Q5a.net
みなさん、ありがとうございます。
セジウィックとウエインのアルゴリズムの本に載っているのは、おそらく
ジェネリクスを使っているので一般性もあって、かつ効率もいいプログラム
だと思います。
ライブラリのようなクオリティーでプログラムを作るというのが理想です。
610:デフォルトの名無しさん
18/05/10 18:51:57.46 yjf1B9Q5a.net
アルゴリズムの本というと C 言語でプログラムが書かれた本が多いですが、
やっと C++ で書かれた日本語の本が最近出版されましたね。
セジウィックとウエインの本よりももっと初歩的な本のようですが。
データ構造とアルゴリズム (電子情報通信レクチャーシリーズ B-8) 単行本 ? 2018/2/1
岩沼 宏治 (著), 美濃 英俊 (著), 鍋島 英知 (著),
611:デフォルトの名無しさん
18/05/10 19:17:25.91 4Q48RAuxd.net
アルゴリズムの抽象的な部分(オーダーとか適用するデータ構造の再帰性や対応関係)を学ぶならCよりML系の方が向いてるは向いてると思う
ただ環境構築なんかの障壁もあるだろうし最終的にCは触るだろうけどアルゴリズム以外の所で詰まりにくいという意味でC#を推してみる
612:デフォルトの名無しさん
18/05/10 19:18:39.74 4Q48RAuxd.net
>>594
勿論F#でもいいし理想はそうだが好みというかネットの情報量の多さ的にC#を挙げた
613:デフォルトの名無しさん
18/05/10 19:24:56.01 faWxDCCY0.net
C#はLinqが便利すぎてお勉強用としてはどうなんだろうなぁ
何やるかによるけど
614:デフォルトの名無しさん
18/05/10 20:05:12.45 4Q48RAuxd.net
ああ勘違いしていた
アルゴリズムを勉強したいのではなく
>>もし、プログラマーになるとした場合、もっとも必要とされる言語を使って、
>>アルゴリズムとデータ構造の勉強をすれば効率的かなと考えています。
なのね
であれば >>573 氏が現役バリバリな時の主流の言語なんて今からじゃ予想つかないだろうし、実務なら最も適した言語が使われるだけだからC++をそのままやり続ければいいと思う
コンピュータサイエンス自体死ぬほど広範囲な学問で、実務のプログラミングとの間にもやっぱり開きがあって万能な言語なんて無いよ
敢えて言うなら物理と数学、これだけは裏切らない
615:デフォルトの名無しさん
18/05/10 21:40:19.82 n6BTi4dIM.net
>>597
あと英語な
616:デフォルトの名無しさん
18/05/10 21:41:29.95 tcNeLXMy0.net
>>585
そこがいいんだよ
隠蔽されたことを忘れたフリをし
本当は忘れていないということの練習に向いている
忘れたフリが綺麗なコードの練習
本当は忘れていないことが性能評価につながる
両立した技能の練習に向いているということだ
617:デフォルトの名無しさん
18/05/11 12:08:47.61 CPfY1M+aM.net
>>571
>>572
そもそもROMの反語はRAMじゃねぇし(SAMってのもある)
SH
618:ARCだとDMのサイズは0でも、PMさえあれば動く で、PMの事隠してマウンティングすればお前らは受け入れるのか？
619:デフォルトの名無しさん
18/05/11 12:33:06.03 Asz7DXCua.net
今はどうか知らないけどcは標準でvectorやlistやmapがないから
そこから始めないといけないのでめんどくさい
アルゴリズム辞典見たら配列をdefineされたNやMで確保してた
ライブラリとして使う気ゼロ
620:デフォルトの名無しさん
18/05/11 13:01:20.12 Mluu9Rs0d.net
>>600
世の中のほとんどのチープなワンチップマイコンはROM/RAM構成なんだよ
世の中を知ってたら>>557に対して>>566なんて考えは出ないはずだ
621:デフォルトの名無しさん
18/05/11 13:03:39.86 Mluu9Rs0d.net
>>601
Cはチープな環境やOS関連で使われるくらいだからなあ
コストのデカイlistやmapなんて無くて当然
必要になったら必要最低限の機能で自力で作る世界
622:デフォルトの名無しさん
18/05/11 13:59:40.72 lM6VzEPtM.net
>>602
あーハイハイそうですね～
623:デフォルトの名無しさん
18/05/11 15:05:19.79 KxM4SNOx0.net
>>603
コスト云々よりジェネリクスが無いから汎用コンテナを作るのが難しい
624:デフォルトの名無しさん
18/05/11 15:52:32.74 MTbwW/C5M.net
作るのが難しい人は拾ってくればいいだけ
625:デフォルトの名無しさん
18/05/11 18:24:24.95 biwWi4aJ0.net
数十バイトしかないなら、普通アセンブラで書くだろう
626:デフォルトの名無しさん
18/05/11 18:50:06.30 Mluu9Rs0d.net
そうでもない
普通にCが使えるので
627:デフォルトの名無しさん
18/05/11 18:55:57.64 Mluu9Rs0d.net
>>605
別に難しくない
標準化されてないから広まってないだけで
作ってる人はいっぱいいる
628:デフォルトの名無しさん
18/05/11 19:49:06.46 l0MSXuwV0.net
>>600
だから何？
いいよ、じゃあSAMもありにしようや
で、スタックの量がCに適するのか適さないのか
おまえさんなりの考えを言ってみな
629:デフォルトの名無しさん
18/05/11 19:59:50.91 KxM4SNOx0.net
>>609
静的型の恩恵が受けられなくなるだろ？
630:デフォルトの名無しさん
18/05/11 20:34:03.62 Mluu9Rs0d.net
で？
631:デフォルトの名無しさん
18/05/11 20:40:41.03 x5BQ9FS4M.net
>>611
普通にvoidポインタに置き換えるだけだが。
何が難しいの？
632:はちみつ餃子
18/05/11 20:56:19.66 e+Ei11A70.net
初期の JAVA もコンテナを使うときにキャストが必須ってアレな仕様だったよな。
633:デフォルトの名無しさん
18/05/11 21:04:30.87 2EGPeEG9a.net
昔は仕様がダメで段々改良されていくということがありますが、
それはなぜなのでしょうか？
その当時はハードウェアの性能上そういう仕様にせざるを得なかったというような
理由があるのでしょうか？
それとも単に思慮が足りなかったというだけでしょうか？
634:デフォルトの名無しさん
18/05/11 21:16:49.77 Mluu9Rs0d.net
理由はいろいろ
635:はちみつ餃子
18/05/11 21:20:43.57 e+Ei11A70.net
>>615
知見が足りなかったというのが最大の理由だと思うけど、
せざるを得なかった場面よりもその程度で充分だったという方が多いと思う。
636:デフォルトの名無しさん
18/05/11 21:23:11.17 biwWi4aJ0.net
仕様が固まらないうちに作る時は、それなりの暫定仕様か何らかの制限事項を設けて開発したな
637:デフォルトの名無しさん
18/05/11 21:36:00.99 Mluu9Rs0d.net
知見が足りなかったなんてのは少数派と思う
シンプルな仕様からだんだんと機能追加で肥大化の方向
ってのがほとんど
638:
18/05/11 21:43:16.90 /s88DeTW0.net
>>619
C89 からの「関数の引数として構造体が（実体渡しとして)OK」というのは、私には堕落以外のなにものでもないと
639:デフォルトの名無しさん
18/05/11 21:53:49.41 HARszYd10.net
昔のC++にあった（今もある）糞の山は、今のモダンな他言語たちへの反面教師として大いに役立った
640:デフォルトの名無しさん
18/05/11 21:55:02.56 Mluu9Rs0d.net
例えばどの仕様が糞？
641:デフォルトの名無しさん
18/05/11 22:06:17.59 KxM4SNOx0.net
>>613
メモリぶっ壊しやすくなるのは十分問題だと思うが
ライブラリ利用者側の責任で何とかしろってのはリソースの条件が厳しけりゃしょうがないがさもなくば正当化しかねる
642:デフォルトの名無しさん
18/05/11 23:57:53.51 MowAKA7Xa.net
独習C++は一通り読んだんだが次に読む本ある？問題集みたいなのとか
643:
18/05/12 00:13:37.95 HeMwMf3D0.net
>>624
私がお勧めしているのは
URLﾘﾝｸ(www.amazon.co.jp)
URLﾘﾝｸ(www.amazon.co.jp)
前者は実は難があって、変てこな実装をしている部分もありますが、それを自分で調べて解決すれば、強くなれると思います
後者は STL の解説本です
いずれも C++11 以前で今となっては古いのですが、代わりになるような本がない…
両方とも私は読んでいますので、普通の質問には答えることができます
644:デフォルトの名無しさん
18/05/12 00:24:10.29 TkoJoFTb0.net
最初に読む本は禿4版一択ですよ。
645:デフォルトの名無しさん
18/05/12 01:17:09.76 hwxaPbIq0.net
どの言語でも、入門書の次は、Effective 何々
646:デフォルトの名無しさん
18/05/12 05:59:18.81 D96wT16B0.net
>>625
「なぜ」そうするのか
「なぜ」そうなっているのか
他にどんな選択があったのか
という思考回路の俺には合わない本だ
647:デフォルトの名無しさん
18/05/12 06:50:27.10 QiJLTR+Nd.net
>>623
それは低級言語に求める物じゃない
C/C++は低級言語として数十年間圧倒的なシェアであり続けている
これってすごいことだと思う
648:デフォルトの名無しさん
18/05/12 07:33:39.79 eFTG6CfX0.net
>>623
データ構造の要素が静的に型が決まろうがそうでなかろうが、必要な要素数のメモリを確保する作業に違いはない。
せいぜい型のサイズを余計に掛け算するくらいだ。
確保するサイズが間違っていれば静的に型が決まろうがメモリ破壊は起きる。
もう少し具体的に示してくれないか？
649:デフォルトの名無しさん
18/05/12 07:37:30.31 D96wT16B0.net
静的な型の恩恵がどうたらって
mallocがvoid*を返すのと同じだろ
問題ちゃ問題だがそんなもん怖がるやつぁC使いに向かない
650:デフォルトの名無しさん
18/05/12 08:45:19.55 vhGL8v7ea.net
>>629
静的なら実行時パフォーマンスには影響しない
>>630
「既に壊しうるのだからちょっとくらい壊せる場所増やしてもいいでしょ」には無条件では同意しかねる
>>631
向いていようがいまいがCの案件はあるわけで, 可能な限り安全にコーディングしたいと思うのは可笑しいか？
で話を戻すと, 汎用コンテナのCでの実装には, 大きく分けてもdefine使った型安全な実装とvoid *を使ったオーバーヘッドあり型安全なし実装が考えられるわけで, まずそれだけでこうして対立し得る
実装上でもいずれもpros/consがあるわけで, そりゃ規格がまとまる道理がないよね, って主張
別に必要最小限の機能で自分で実装することを否定するわけじゃないし, 型安全が絶対だという気もない
651:デフォルトの名無しさん
18/05/12 08:57:39.01 QiJLTR+Nd.net
高速コンパクトと安全性利便性は相反するものだ
諦めろ
652:
18/05/12 09:08:53.09 HeMwMf3D0.net
>>627
独習の次に Effective C++/Effective Modern C++ は飛躍しすぎではないかな？
ついてこれるのか
653:デフォルトの名無しさん
18/05/12 09:12:02.44 vhGL8v7ea.net
>>634
必読書ですしおすし
654:デフォルトの名無しさん
18/05/12 09:13:51.54 PbE4ojLD0.net
>>632
> void *を使ったオーバーヘッドあり
とは何？サイズ管理＋アドレスの計算のこと？
だったらC++の汎用コンテナでも同じ事を内部でやっているし、オーバーヘッドはないが。
見た目でしか分からない人はCに向いていないぞ。
というか、型安全が欲しければC++を、
そんなん要らんから小さくて早いコードを、というのならCを、ってだけだろ。
その分自分で管理する項目が増えるだけの話で。
選択肢はユーザー側に与えられているのだから、それ以上は要らんだろ。
655:デフォルトの名無しさん
18/05/12 09:15:07.55 D96wT16B0.net
>>632
できねえこと言ったってしゃーないだろ
Cにはテンプレートがない
諦めるしかない
656:デフォルトの名無しさん
18/05/12 09:18:40.30 kx3qluwG0.net
とりあえずスクリプト言語やC#で書く→速くしたい所をC++で書く→もっと速くしたい所をCやasmで書く
これが正解
どれかにこだわって対立させて排他するのはアホ
657:デフォルトの名無しさん
18/05/12 09:26:19.92 PbE4ojLD0.net
>>638
同意。
若い奴が統一言語「○○だけ勉強すれば全ておｋ」を求めるのは自然だが、
そうなっていないのは理由があって、つまりは手抜きと実行効率（速度）の兼ね合いだ。
一時期Cが統一言語だったが、それは他言語がゴミだったから（対抗馬がLisp)であって、
C++で再統一されることはないよ。特に今のC++では。
658:デフォルトの名無しさん
18/05/12 09:31:37.48 vhGL8v7ea.net
オーバーヘッドについては撤回
>>636-639
だから基本的にそういう役割分担について否定しているわけじゃない
Cで汎用コンテナが標準化されることはないだろうっていうのが元々の主張
659:デフォルトの名無しさん
18/05/12 09:56:03.80 QiJLTR+Nd.net
>>638
Cで書けることは基本C++で書ける
C++で最適化出来ない所はCでも無理
アセンブラしかない
660:デフォルトの名無しさん
18/05/12 10:05:55.31 QiJLTR+Nd.net
>>636
CやC++に関わらず専用なコードは汎用に比べて高速コンパクトに出来る事がある
つまり、
void*で作って全てのコンテナサイズ(型)同一コードよりも型ごとにコードを作る方が速いことがある
C++のコンテナは全て専用コードなので
コードの肥大化と引き換えに微妙に速いかもしれない
コードの肥大化によってキャッシュミスして遅い可能性もあるけど
661:デフォルトの名無しさん
18/05/12 11:33:41.32 VFvkGYoW0.net
>>638
> 速くしたい所をC++で書く→もっと速くしたい所をCやasmで書く
asmはいいとしてC++→Cでもっと速くなるケースなんてあるのか？
662:デフォルトの名無しさん
18/05/12 11:35:17.48 tcCubJZ8M.net
>>632
>すでに壊してるのだから
一体どこからそんな主張を読み取ったんだ？
勝手に人の主張を捏造せずに、ちゃんと質問に答えてくれないか？
あと、void*使わなくても、生成時に型サイズを受け取る方法もある。
汎用コンテナ作るのにdefineで型定義なんてするわけないだろう。
663:デフォルトの名無しさん
18/05/12 11:39:23.77 D96wT16B0.net
>>642
qsortやbsearchとかそうだよな
C++のsortやbinary_searchには絶対に敵わない
664:デフォルトの名無しさん
18/05/12 11:44:45.24 .net
>>644
FF外から失礼します
「すでに壊してるのだから」とはどこにも書いてないと思うのですが
なぜあなたこそ勝手に人の主張を捏造しているのでしょうか？
FF外から失礼しました
665:デフォルトの名無しさん
18/05/12 11:48:55.40 tcCubJZ8M.net
>>646
面倒なやつだな。
「既に壊しうるのだから」
これでいいか？
666:デフォルトの名無しさん
18/05/12 11:52:21.18 My8LWy2ka.net
ふぁいなるふぁんたじぃ？
667:デフォルトの名無しさん
18/05/12 11:59:59.40 FtdYwxfb0.net
前輪駆動車じゃない？
668:デフォルトの名無しさん
18/05/12 12:14:05.61 D96wT16B0.net
255
669:デフォルトの名無しさん
18/05/12 12:31:23.28 My8LWy2ka.net
-1
670:デフォルトの名無しさん
18/05/12 12:40:45.91 QiJLTR+Nd.net
汎用バイナリ < 汎用コード専用バイナリ < 専用コード
速度的にはこう
速度が非常に重要であれば
CだろうがC++だろうが専用コードを書くのが一番
671:デフォルトの名無しさん
18/05/12 12:42:10.49 PbE4ojLD0.net
>>643
間接参照を抜ける場合とかだろ。
逆にCよりもC++の方が速くなるコードの方があり得ないと思うが。
実際にC++はCより遅いってのは事実だし。
>>645
お前が値配列と参照配列の区別が付いてないだけだろ。
672:デフォルトの名無しさん
18/05/12 12:44:50.30 D96wT16B0.net
>>653
アンカーミスったか？
qsortとstd::sortはどちらも値であろうが参照（ポインタ）であろうが使えるぞ
673:デフォルトの名無しさん
18/05/12 12:49:50.14 QiJLTR+Nd.net
>>653
>>641
674:デフォルトの名無しさん
18/05/12 12:50:14.86 VFvkGYoW0.net
>>653
> 間接参照を抜ける場合とかだろ。
それC++のまま書き換えればいいだけ
> 逆にCよりもC++の方が速くなるコードの方があり得ないと思うが。
そんな主張はしてない
> 実際にC++はCより遅いってのは事実だし。
だからどんなケースなんだよ
STLとか使いまくって遅いとかなら使わないように書き換えればいいだけだろ
675:デフォルトの名無しさん
18/05/12 12:58:57.32 QiJLTR+Nd.net
厳密に言うと
C11の可変長配列はC++には無い
C++では例外処理を実現するために関数コールに微妙なオーバーヘッドがある場合がある
って感じでCの方が有利な事がある
どちらもガシガシに最適化した場合の話
676:デフォルトの名無しさん
18/05/12 13:05:00.64 QiJLTR+Nd.net
x86-32
例外処理を有効にすると
関数コールに微妙なオーバーヘッドが加わる
x86-64
例外処理の為のオーバーヘッドは無い
その代わり例外発生時の処理は非常に遅い
Cの可変長配列のような、スタックに可変長サイズを確保する手段はC++には無い
当然ダイナミックなメモリアロケートよりはスタックに確保した方が速い
ただし実際にはあまり使われていないと思われる
677:デフォルトの名無しさん
18/05/12 13:09:56.56 PbE4ojLD0.net
>>654
ミスってないぞ。
>>656
Cの場合は抽象化してくれないんだから、関数を直接呼ぶしかないんだよ。
だから動的解決をしている場合はC++の方が遅く、静的解決の場合は同速になる。
CのほうがC++より遅いケース出してみろ。ないから。
C++は機能的にはCをラップしてるんだよ。
例外とか、クラスの動的解決とか、スマポ（ｷﾘｯとか。その分管理が楽だが、速度は遅くなる。
Cの場合はC++のラッパ抜きで直接呼ぶことになるから、その分速い。それだけ。
678:デフォルトの名無しさん
18/05/12 13:11:52.26 PbE4ojLD0.net
>>658
> x86-64
> 例外処理の為のオーバーヘッドは無い
> その代わり例外発生時の処理は非常に遅い
これマジ？
煽りじゃなくて仕組みを知りたいから、キーワードかURLくれ。
こちらでググって確認する。
679:デフォルトの名無しさん
18/05/12 13:28:22.55 QiJLTR+Nd.net
自分でディスアセンブルしたり
バイナリ比較したり実測してわかったことで
仕組みがまとめて書いてあるような所は知らない
680:デフォルトの名無しさん
18/05/12 13:31:21.41 PbE4ojLD0.net
>>656
> だからどんなケースなんだよ
探してやったぞ。
> 実験によれば 6-13% の実行時間が単なる関数のディスパッチに用いられ、オーバーヘッドは場合によって 50% に達する[1]。
> URLﾘﾝｸ(ja.wikipedia.org)
C++は動的な型の変更はなしなので、コンパイル時に対象関数は確定するだろ。それが仮想関数であってもね。
だからvtblを用いた実装自体がコンパイラの単純さを採って、実行速度を捨ててる。
JavaScriptみたいに、実行時に型を変更してしまえる言語ではないのだから、
型毎にテーブルを持つこと自体が冗長で、
テンプレートみたいに、仮想関数が上書きされた毎時点で平面的に展開し、直接それを呼ぶ実装も出来るんだよ。
勿論オブジェクトコードは膨らむが。
Cの場合は、どちらでやるにしても「自前で」実装するしかない。だから当然、選べる。
C++の場合は、選べないでしょ。一般的にvtblの実装になる。（コンパイラの都合だが）
681:デフォルトの名無しさん
18/05/12 13:35:45.30 QiJLTR+Nd.net
C/C++で基本同じ結果となるコードが書ける
同じ結果となるコードを書けば結果は同じ
ってだけで
当然違う結果となるコードを比べれば違う結果になる
当たり前
682:デフォルトの名無しさん
18/05/12 13:36:37.92 PbE4ojLD0.net
>>66
683:1 ちなみに計測したときのOSは何？ なおその兆候が正しいなら、x64の場合はハードウェアで対応していることになる。
684:デフォルトの名無しさん
18/05/12 13:38:15.87 QiJLTR+Nd.net
クラス関数はthisを第一パラメータとして渡してるだけで、これは構造体でも同じことが出来る
virtual関数は関数ポインタテーブルへのポインタを持ってるだけ
同じことは当然Cの構造体でも出来る
テンプレートは型ごとにコードを書くのと同じ
685:デフォルトの名無しさん
18/05/12 13:39:04.83 PbE4ojLD0.net
>>663
だから、いわゆるC++の機能を使ったら、管理が楽になる分だけ遅くなる、というだけ。
C++の機能を全く使わないコードはCと言うんだよ。
だから、C++はCより常に遅い。それだけ。
686:デフォルトの名無しさん
18/05/12 13:41:20.71 QiJLTR+Nd.net
>>664
そういえば、
例外発生時のスタックにあるリターンアドレスを検索するとかどこかでみたような
どこかに仕組みが書いてあった気がしてきた
687:デフォルトの名無しさん
18/05/12 13:42:51.66 QiJLTR+Nd.net
>>666
君独自の定義とか持ち出さないでくれ
688:デフォルトの名無しさん
18/05/12 13:44:31.67 PbE4ojLD0.net
>>665
> virtual関数は関数ポインタテーブルへのポインタを持ってるだけ
> 同じことは当然Cの構造体でも出来る
Cでやる場合は、関数ポインタを引数で渡すことも出来るんだよ。
(勿論C++でも出来るが、クラスを使う意味が無くなるから普通はやらない）
この場合、間接参照が抜ける分だけ速くなる。
（実際はメモリアクセス1個よりはキャッシュを壊すことの影響の方が大きいとは思うが）
689:デフォルトの名無しさん
18/05/12 13:45:03.28 QiJLTR+Nd.net
C++独自の機能を使うとCより常に遅い？
それは嘘だな
690:デフォルトの名無しさん
18/05/12 13:47:32.05 QiJLTR+Nd.net
>>669
C++にだけ独自の縛りを設けてCのが速い？
強引に主張を通したいのはわかるが
そろそろ痛いぞおまえ
691:デフォルトの名無しさん
18/05/12 13:49:15.64 PbE4ojLD0.net
>>667
それはスタックウォークという、従来の例外実装方法だ。
君の場合なら、x86がそれになってる。
>>670
ならC++の機能を使って、Cよりも速くなるケースを挙げてみろ。
ないから。
692:デフォルトの名無しさん
18/05/12 13:51:18.48 QiJLTR+Nd.net
もとは>>638だ
C++で最適化に行き詰まった時に
わざわざコンパイラをCに変えて最適化する事なんてないから
Cっぽい記述とかアセンブラっぽい記述とかなら
そりゃいくらでも
693:デフォルトの名無しさん
18/05/12 13:53:21.45 QiJLTR+Nd.net
>>672 前半
自分で調べろ
>>672 後半
ええと、...
「C++独自の機能を使うとCより常に遅い」
の否定はわかるかな？
694:デフォルトの名無しさん
18/05/12 13:53:48.97 .net
>>658って単に32bitプログラムを64bit CPUで走らせてオーバーヘッドがーって言ってるんじゃね？
695:デフォルトの名無しさん
18/05/12 14:01:29.48 PbE4ojLD0.net
>>674
君は理解できてないようだから、定義を確認しておこう。
ただしこれは一般的な解釈であり、おそらくこのスレの住民は共有してる。
・テンプレート、クラス構文、スマポ等、
C++コンパイラではないと通らない機能を使ったコードを、C++のコードという。
・その他、関数ポインタ等、Cコンパイラでも通る機能のみで書かれたコードを、Cのコードという。
> 一般に、カーネルモジュールをC++で設計するやつは、以下のいずれかだ。
>
> (a) 好んで厄介事に巻き込まれたい者
> (b) 自分が書いているのは実はCだと気がついていないC++バカ
> (c) 授業でそういう課題を与えられた者
>
> (d)を付け加えるなら好きにしてくれ。
>
> Linus
> URLﾘﾝｸ(cpplover.blogspot.jp)
君は多分(b)だね。
今の話題はC++のコードとCのコードの速度比較ということでよろしく。
>>673
> C++で最適化に行き詰まった時に
> わざわざコンパイラをCに変えて最適化する事なんてないから
そんな話は誰もしてない。
勿論その場合はCのコードに変更し、C++コンパイラを使うに決まっている。
じゃないと他の部分が通らないだろ。
君の定義は、C++コンパイラを使っていればどういう書き方であってC++ということだったのか。
なら話は噛み合わないさ。
696:デフォルトの名無しさん
18/05/12 14:05:34.23 D96wT16B0.net
#
697:define SIZE 100000000 long long array[SIZE]; int comp(void const* lhs, void const* rhs) { if(*(long long*)lhs < *(long long*)rhs) return -1; if(*(long long*)lhs > *(long long*)rhs) return +1; return 0; } int main(void) { clock_t t0 = clock(); qsort(array, SIZE, sizeof(long long), comp); clock_t t1 = clock(); printf("%g[sec]\n", (double)(t1 - t0) / CLOCKS_PER_SEC); //2.288[sec] }
698:デフォルトの名無しさん
18/05/12 14:06:21.60 D96wT16B0.net
#define SIZE 100000000
long long array[SIZE];
int main(void)
{
clock_t t0 = clock();
std::sort(array, array + SIZE, std::less<long long>());
clock_t t1 = clock();
printf("%g[sec]\n", (double)(t1 - t0) / CLOCKS_PER_SEC); //8.245[sec] ・・・あれ？ 何だこりゃ
}
699:デフォルトの名無しさん
18/05/12 14:07:22.82 VFvkGYoW0.net
>>657-658
そういやスタックにとる可変長配列はC++にないんだな
まあメジャーな環境でalloca( )使えないものはないと思うが
例外は使わないようにすればいいだけかと
700:デフォルトの名無しさん
18/05/12 14:14:29.71 PbE4ojLD0.net
>>678
一応、基本的確認をするが…データは同じなんだよな？
俺の予測では同速。多分そちらの期待も同じだと思うが。
701:デフォルトの名無しさん
18/05/12 14:14:45.58 VFvkGYoW0.net
>>676
> ・その他、関数ポインタ等、Cコンパイラでも通る機能のみで書かれたコードを、Cのコードという。
可変長配列とか使ってないならC++のコードでもある
つまりC++の範疇で書き直してるだけ
って言うのが大方の人の解釈だと思うが
702:デフォルトの名無しさん
18/05/12 14:18:31.88 D96wT16B0.net
>>680
うん
だってグローバルだからオール０
703:デフォルトの名無しさん
18/05/12 14:20:49.93 QiJLTR+Nd.net
>>676
それは単なる君の定義
100歩譲っても5chで一般的なだけ
普通C言語, C++と言えば、
その規格や規格に準拠したコードを表す
704:デフォルトの名無しさん
18/05/12 14:22:26.74 PbE4ojLD0.net
>>681
それは君の勘違いだね。
その定義ならC/C++を区別する理由がないし、多分LinuxもC++になってしまうだろ。
705:デフォルトの名無しさん
18/05/12 14:26:21.88 D96wT16B0.net
>>676
たとえばヘッダファイルなんか、同一のファイルを
Cコンパイラに入力したり
C++コンパイラに入力したり
ってこともあるよな
内容には無関係で単に
Cコンパイラに入力したらCのコードで
C++コンパイラに入力したらC++のコードだろ
最適化の内容だってrestrictのように
CとC++で違ってくる可能性はあるしな
706:デフォルトの名無しさん
18/05/12 14:27:02.49 PbE4ojLD0.net
>>682
最適化の掛け忘れでは？
Cの方はほぼ最適コードだが、(メモリアクセス減らして一時変数に取れとかその程度）
C++の方は最適化無しだとトンデモコードが出てくるが、
最適化でそれを消すからおｋというノリだったと思ったぞ。
最適化無し同士の比較は意味がない。最大最適化同士の比較やってみそ。
707:デフォルトの名無しさん
18/05/12 14:27:22.97 QiJLTR+Nd.net
使うモジュールの差を言語で言うから話が紛れる
で、
君の定義であるごく一般的な記述を行った場合の話であれば
C++の方が速いこともあるしCの方が速いこともある
C++はテンプレートによって専用のコードをたくさん作る
当然汎用バイナリよりも専用バイナリの方が最適化がかかりやすいし、
変数よりも即値の方が速いことも多い
C++例外処理も有効で、
これによって処理が速くなる場合がある
708:デフォルトの名無しさん
18/05/12 14:27:42.28 D96wT16B0.net
>>686
gcc unko.c -O3でやってる
709:デフォルトの名無しさん
18/05/12 14:29:31.07 PbE4ojLD0.net
>>685
> 内容には無関係で単に
Linus全否定かよ。
710:デフォルトの名無しさん
18/05/12 14:30:30.03 QiJLTR+Nd.net
>>682
オールゼロでクイックソート？
それは...
711:デフォルトの名無しさん
18/05/12 14:35:18.35 PbE4ojLD0.net
>>687
> 君の定義であるごく一般的な記述を行った場合の話であれば
> C++の方が速いこともあるしCの方が速いこともある
ねーよ。
実例挙げてみ？
それって単なるコンパイラの適性であって、コード自体の速度ではないだろ。
C++とCの本質的な速度差ってのは絶対にひっくり返らないものであって、
例えば、スマポを使っている限り参照ポインタを管理する分だけ遅くなる、というもの。
コンパイラがどう進化しても、「０」「ADDまたはDEC命令」の差はひっくり返らないんだよ。
> C++例外処理も有効で、
> これによって処理が速くなる場合がある
ねーよ。C
712:は最初から全部noexceptだ。
713:デフォルトの名無しさん
18/05/12 14:35:49.71 QiJLTR+Nd.net
ソートって
メモリサイズ
比較コスト
コピーコスト
キャッシュサイズ
...
こんなんで結果(時間)が大きく異なるんだよね
クイックソートだと
データの並び順でもたまたま選んだピボット値でも変わる
1個の場合を比較してもあまり意味が無いぞ
714:デフォルトの名無しさん
18/05/12 14:36:05.87 D96wT16B0.net
clでやってみたら期待どおりの結果になった
>>677 1.789[sec]
>>678 0.623[sec]
最適化は/Ox
715:デフォルトの名無しさん
18/05/12 14:36:46.83 D96wT16B0.net
>>690
ああ、それは確かに
テストデータをまじめに作るか。。。
716:デフォルトの名無しさん
18/05/12 14:37:45.07 PbE4ojLD0.net
>>688
となるとアセンブラを確認するしかないね。
(いいサイトはあったはずだが、普段使わんから忘れた)
717:デフォルトの名無しさん
18/05/12 14:37:57.15 D96wT16B0.net
>>689
ん？ なんで？
718:デフォルトの名無しさん
18/05/12 14:44:25.97 PbE4ojLD0.net
>>693
それさ、以下の3条件でやってみ。
1) Cのコード(677)を、Cコンパイラ
2) Cのコード(677)を、C++コンパイラ ←追加
3) C++のコー(678)を、C++コンパイラ
Cコンパイラってポインタ周りは最適化をかけないから、多分、
速度差はコンパイラ起因であって、コード起因では無いと思う。
719:デフォルトの名無しさん
18/05/12 14:45:53.71 PbE4ojLD0.net
>>696
> (b) 自分が書いているのは実はCだと気がついていないC++バカ
> URLﾘﾝｸ(cpplover.blogspot.jp)
君の定義が正しければ、上記(b)の定義が出来なくなるだろ。
720:デフォルトの名無しさん
18/05/12 14:46:34.72 QiJLTR+Nd.net
>>691
C++が遅くなる例だけあげてC++が遅いって言ってもねえ
C++が速い例
double p = 1.;
int n;
for (n = 1 ; ; n++){
p *= n;
}
C++だと例外処理をつかって、いつオーバーフローするかわかるんだけど
例外を使わないとどういうコードになるかねえ？
---
Cで普通に汎用vectorを作るとすると
普通は汎用バイナリで作ることになるんで
関数ポインタを経由する事になっちゃうけど
C++のテンプレートだとだとそれぞれ専用なんで
関数コールが速いよね
アドレス計算も即値の乗算だから色々なテクニックが使える
721:デフォルトの名無しさん
18/05/12 14:47:13.55 D96wT16B0.net
わりい、ちょっと離席する
722:デフォルトの名無しさん
18/05/12 14:49:16.03 PbE4ojLD0.net
>>699
> C++が速い例
Java出身か？死ね
723:デフォルトの名無しさん
18/05/12 14:51:30.31 QiJLTR+Nd.net
C++だとコンテナを使ってまともなソートを簡単に書けるけど
Cだと面倒だからバカソート
ってのも普通にある
要素数が少なければ意図的にやったりもする
一般的なコードではCの方が速い事の方が多い
ってくらいの主張にしとけば良いものを
強い主張をしちゃうから
724:デフォルトの名無しさん
18/05/12 14:53:13.25 QiJLTR+Nd.net
>>701
ん？
良くわからんが負け宣言てことでいいのかな？
725:デフォルトの名無しさん
18/05/12 14:55:06.52 VFvkGYoW0.net
>>684
何を言ってるのか意味不明すぎる
よほど感覚が独自なんだろうな w
726:デフォルトの名無しさん
18/05/12 14:56:22.02 PbE4ojLD0.net
>>699
おっとすまん、ポインタアクセスでのメモリオーバーフローと勘違いしてた。
doubleの無限大の例外って事？
俺はそっちには詳しくないが、浮動小数点例外をソフトウェアで検出するのなら同じだし、
ハードウェアでの検出なら割り込みがかかるだけで、速度的にはこれまた同じだが。
vectorについては完全に君の勘違いだぞ。
Cではそれぞれ専用の物を作るのが基本であり、それを一つにかけるようにしたのがテンプレートだ。
多分、理解の仕方が逆だ。
727:デフォルトの名無しさん
18/05/12 14:57:30.76 VFvkGYoW0.net
>>699
> Cで普通に汎用vectorを作るとすると
> 普通は汎用バイナリで作ることになるんで
速度云々議論してるところでそんなことする奴はバカって言われてもしょうがないと思う
728:デフォルトの名無しさん
18/05/12 15:04:23.09 VFvkGYoW0.net
>>705
> ハードウェアでの検出なら割り込みがかかるだけで、速度的にはこれまた同じだが。
Cだと言語の範疇ではその割り込みを処理できない
なのでif文とかでオーバーフローするのを検出するとかが必要
って話だろ
729:デフォルトの名無しさん
18/05/12 15:07:59.44 PbE4ojLD0.net
>>707
> if文とかでオーバーフローするのを検出するとかが必要
ほう。ならその
730:コードを書いてみ。 そしたらそのコードの中でオーバーフローするから無限ループだね。 そんな言語が実用だったとでも？
731:デフォルトの名無しさん
18/05/12 15:15:00.22 sI+Q43v80.net
>>705
例外については「お前は頭が悪すぎて会話にならん」とだけ
コンテナは
「C++の方が遅い例だけ扱って、速い例は自分の想定と違う」
という主張を続けるならお前と会話しても無意味だ
732:デフォルトの名無しさん
18/05/12 15:16:02.69 sI+Q43v80.net
IDが変わってしまった
まあそんな事はどうでもいいか
733:デフォルトの名無しさん
18/05/12 15:18:43.30 PbE4ojLD0.net
ちなみに速度比較についてはいろんな人が様々やってるけど、
俺的にまあ公平だと思えるのはこれだね。俺の体感ともだいたい一致する。
おれはC++は1.1-1.3位かと思っているけど。
> C 1.00
> C++ 1.56
> Java 1.89
> C# 3.14
> URLﾘﾝｸ(jaxenter.com)
> URLﾘﾝｸ(jaxenter.com)
C++の機能をバリバリに使ったら、そりゃJavaと大して変わらんだろ、ということになるし。
スマポってのは良くできたGCとコストはほぼ同じだし。（GCは全自動なだけ）
Javaは以前は3程度だったが、ゴリゴリチューニングしてきているらしい。
734:デフォルトの名無しさん
18/05/12 15:19:13.36 sI+Q43v80.net
>>706
速度優先のコード前提ってことなら
保護されまくった高機能汎用コンテナを使うこと自体アホってことになるねえ
さらに条件を加えちゃってもう
735:デフォルトの名無しさん
18/05/12 15:19:20.53 PbE4ojLD0.net
>>709
僕は知りません、まで読んだ。
736:デフォルトの名無しさん
18/05/12 15:20:34.21 .net
>>708
なんで喧嘩腰なのかがよくわからないけど、
C言語では「n <= DBL_MAX」というif文が必要ってことだろ？
double p = 1.;
int n;
for (n = 1 ; n < DBL_MAX; n++){
p *= n;
}
737:デフォルトの名無しさん
18/05/12 15:23:37.01 PbE4ojLD0.net
>>714
いやオーバーフローするのは p だろ。
と思ったが、もしかして n の方なのか？
738:デフォルトの名無しさん
18/05/12 15:33:27.39 .net
>>715
なんでもない、忘れて＞＜
739:デフォルトの名無しさん
18/05/12 15:48:51.69 PbE4ojLD0.net
>>716
通じたようで何より。
だからオーバーフローの検出はソフトウェアでは辛くて、通常はハードウェアのはずだ。
そしてその場合は割り込みとなり、Cの場合は割り込みハンドラにコードを書くことになる。
C++の場合は『そこから例外処理ルーチンまで引っ張ってきてくれるコード』をコンパイラが用意し、
ユーザーのcatchコードを実行する。つまり、上記『』内コードでラップされてる分だけ遅い。
（実際にはラップだけではなくスタックウォークも行うから相当遅いはずだが）
なんだが、実際俺はゼロ割例外しか見てないからオーバーフローについてはよくは知らん。
ハードウェア的には上記の動作になる。
一般的にはオーバーフロー例外は出ない環境（無限大に貼り付けるだけ）で使うのではないかと。
Cではアホみたいにゼロ割チェックやってるよ。
これはC++でも同じだと思うが、C++erはやらないのが作法なのか？
とはいえ、ゼロ割はCMP+Brachであり、通常は分岐しないから、x86ではほぼゼロコストだ。
割り込みは関数呼び出し自体が遅くなるから、結局これもCの方が速いはずだが。
740:デフォルトの名無しさん
18/05/12 16:03:54.80 68o7JYmcM.net
>>712
お前話の流れが読めてないだろ w
>>638から読み直せ、バカ
741:デフォルトの名無しさん
18/05/12 16:11:14.40 eFTG6CfX0.net
overflowてexception吐くんだっけか
742:デフォルトの名無しさん
18/05/12 16:35:26.68 68o7JYmcM.net
>>708
バカはこれだから w
isfinite( ) マクロとかも知らんのかよ
743:
18/05/12 16:40:25.40 HeMwMf3D0.net
>>717
オー�
744:oーフローで例外や割り込みが起動することはないのでは？ 普通、無符号ならキャリー、符号有りならオーバーフローのどっちかのフラグで判定するかと
745:デフォルトの名無しさん
18/05/12 17:14:24.19 D96wT16B0.net
unsigned long long array[100000000];
↑
ここに同じファイルから乱数を読み込んで比較してみた
clのオプションは /Ox /arch:AVX
gccのオプションは -O3 -mtune=sandybridge
qsort
cl 27.171[sec]
gcc 26.139[sec]
std::sort
746:デフォルトの名無しさん
18/05/12 17:16:00.99 D96wT16B0.net
途中で書き込まれてしまった
unsigned long long array[100000000];
↑
ここに同じファイルから乱数を読み込んで比較してみた
clのオプションは /Ox /arch:AVX
gccのオプションは -O3 -mtune=sandybridge
qsort
cl 27.171[sec]
gcc 26.139[sec]
std::sort
cl 13.456[sec]
gcc 9.103[sec]
おまけ
std::sortにstd::execution::parを指定してみた
cl 3.288[sec]
gcc 未実装
747:デフォルトの名無しさん
18/05/12 17:16:40.49 D96wT16B0.net
>>690が正解だったね
748:デフォルトの名無しさん
18/05/12 17:49:15.49 D96wT16B0.net
>>698
そこの２通目に箇条書きしてある部分は
1992年当時に俺が思っていたことに近い
・例外がクソ
うん、マジクソだ
C++11以後マシになったが下痢が治ったという程度
・newいらねー
演算子newを初めて聞いた瞬間、
mallocの設計理念が大声でわめき立てた
C++11以後ブーイングが更にエスカレートした
・キーワードclassいらねー
禿自身が認めやがった
・・・しかし、それがなぜ>>685への反駁に引用されるのかがわからん
749:デフォルトの名無しさん
18/05/12 18:15:21.20 VFvkGYoW0.net
>>721
大抵のプロセッサの浮動小数点ユニットにはオーバーフローしたら例外を発生させる機能がある
それを有効にしてるかどうかは環境による
あとC言語の話で割込ハンドラーとか言ってる>>717は単なる知ったかなのでスルーした方がいい
750:
18/05/12 18:29:10.59 HeMwMf3D0.net
>>726
＞大抵のプロセッサの浮動小数点ユニットには
「浮動小数点ユニット」なんですね、ここで確認しておきます。
＞オーバーフローしたら例外を発生させる
演算結果が ±inf になることを「オーバーフロー」と言うのですか？ちょっと耳慣れないですね
>>726
＞C言語の話で割込ハンドラー
lsi-c ver3, MS-C ver6 あたりでは、そういうのもあったと記憶してます、 matherr() ですね
だから >>717 はあながち間違いとはいいきれない面もあります
751:デフォルトの名無しさん
18/05/12 18:40:33.53 PbE4ojLD0.net
>>725
世間では「どちらのコンパイラを使うか」ではなく、
「どちらのスタイルで書いているか」でCとC++を区別してるんだよ。
752:デフォルトの名無しさん
18/05/12 18:42:16.14 VFvkGYoW0.net
>>727
> 演算結果が ±inf になることを「オーバーフロー」と言うのですか？ちょっと耳慣れないですね
それ反対、オーバーフローしたら結果をinfにしてるだけ
753:
18/05/12 18:49:16.74 HeMwMf3D0.net
>>729
inf も NaN も浮動小数点表現の中にあるので「オーバーフロー」と呼びにくい、と思っています、まあ人それぞれ
754:デフォルトの名無しさん
18/05/12 19:04:56.38 VFvkGYoW0.net
>>730
だから誰もinfがオーバーフローとは言ってないだろ
オーバーフローしたらそれっぽい値としてinfを入れてるだけ
755:デフォルトの名無しさん
18/05/12 19:24:22.69 yANyZ1HYd.net
>>728
それなら
Cスタイル、C++スタイル
と言えば良い
CかC++かは当然コンパイラで決まる
C++は元々上位互換を目標に作られた物だ
756:デフォルトの名無しさん
18/05/12 19:29:38.17 VFvkGYoW0.net
>>728
お前の変な世間はどうでもいい
757:デフォルトの名無しさん
18/05/12 19:48:04.17 PbE4ojLD0.net
>>732
> C++は元々上位互換を目標に作られた物だ
そうだ。そしてだからこそ、スタイルで区別されるんだよ。
元々C++はCの完全上位互換だった。
だから君らの定義なら、C++が登場したときから全てのCは消滅し、C++になっているはずだろ。
実際はそうじゃない。
「○○のコードはCで書かれています」
「○○のコードはC++で書かれています」というのは、
世間では俺の言った定義(>>676)で使われてる。
その後、CとC++が仕様的に分離してしまったから、
今現
758:在はCコンパイラで通るコードがC++コンパイラで通らないケースが存在する。 だから今は明確に「どちらのコンパイラを使うか」を想定しておく必要があるが、 それもコーナーケースで、 大半の「Cのコード」はC++コンパイラでもそのまま通る。 お前らがC++信者でC++の範囲を広く取りたいのは分かるが、世間はそうじゃない。 C++がCの仕様を全て取り込んだら、 お前らにとってはCは消滅、全てはC++になり、お前らは幸せになれるだろうさ。 ただ、その後も世間はCとC++を引き続き区別するだろうよ。
759:デフォルトの名無しさん
18/05/12 20:09:12.78 sI+Q43v80.net
お前用語の定義の説明とかどうでもいい
スタイルの意味ならスタイルと書け
760:デフォルトの名無しさん
18/05/12 20:09:24.63 D4Rf+0xLd.net
>>734
それは嘘だなぁ
extern "C"が無いとCライクに見えるオブジェクトを吐かない事が常となっているC++(コンパイラ)について、いくらpure Cライクなコードを書いてもpure Cでないextern "C"を書かないとCライクに見えるオブジェクトは吐けないってそれはもうC++でしょう
他の内容にも誤りがあって君の世間ではCライクなコードであればCで書いたと宣言していいらしいけど、少しでも世間のOSSのコードを見て回れば良いよ
Cで書かれているのはCだから
761:デフォルトの名無しさん
18/05/12 20:30:38.36 PbE4ojLD0.net
お前らが誤解したままでいるのはお前らの自由だが、
お前らの定義だと、CとObjective-Cを区別できないだろ。
あれはCの完全上位互換で、Cコードそのまま食えるらしいからね。
お前らも少し考えれば自分で矛盾に気づけるはずだが。
762:デフォルトの名無しさん
18/05/12 20:58:42.38 cTj25fOrM.net
>>734
それは言い過ぎでしょ。
流石にそれは、世間を知らなすぎ、と言われても仕方ない意見にみえてきたなあ。。。
763:デフォルトの名無しさん
18/05/12 21:57:33.16 PbE4ojLD0.net
ならもうちょっと分かりやすい説明をしてやる。
>>677-678について、お前らの定義では『コード』について議論できないだろ。
俺の定義では、677は「Ｃのコード」で、678は「C++のコード」だ。コンパイラに依らない。
お前らの定義では、678は明確に「C++のコード」だが、677については、
「Cコンパイラを通した場合、677はCのコード」
「C++コンパイラを通した場合、677はC++のコード」
になってしまうだろ。
それだと、CとC++の『コード』の速度比較自体が定義できないだろ。
677をCコンパイラを通した場合とC++コンパイラを通した場合の速度差は、
「コードの差」ではなく、「コンパイラの差」なんだよ。
当たり前だろ。
というか、C++erもここまでレベルが落ちたのか。世も末だな。
764:デフォルトの名無しさん
18/05/12 22:16:57.78 DXsEIRbfM.net
std::filesystemで片方のスレッドでファイルを出力し
もう片方のスレッドでファイルが存在していたら読み込むというプログラムを書いた場合
出力中に存在すると判定されて読み込んでしまいそうですが、
そんなことないでしょうか？
もし読み込んでしまう場合、自力でフラグ管理かMutexを使うなどして
判定する以外の方法はあるでしょうか？
765:デフォルトの名無しさん
18/05/12 23:29:24.63 sI+Q43v80.net
>>739
お前が考えた定義とかどうでも良いって言ってるの
766:デフォルトの名無しさん
18/05/12 23:53:40.44 PbE4ojLD0.net
というか何でお前らそんなに必死なんだ？
俺の言ってる定義が世間一般の定義だよ。
そうじゃなきゃ『コード』の善し悪しの議論が出来ないだろ。自明だと思うが。
繰り返すが、C++がCよりも遅いのは事実で、それもググレばいくらでも出てくるだろ。
ただこれはC++そのものよりもオブジェクト指向の弊害だが。
URLﾘﾝｸ(chrismdp.com)
URLﾘﾝｸ(www.quora.com)
逆に言えば、C++の機能をふんだんに使ったとして、Javaに対する速度優位がどれだけあると思ってるの？
C++で世界が再統一されることは、今のC++の仕様/方向
767:性ではあり得ない。C++ではCを殺しきれない。 だからRustが生まれた。 >>711の表を信じるなら、RustはCの代替としてはC++以上に上手く行ってる。
768:デフォルトの名無しさん
18/05/12 23:56:27.27 sI+Q43v80.net
お前の定義じゃないと議論が出来ないのは
おまえがアホだから
769:デフォルトの名無しさん
18/05/13 00:02:56.89 VV8A9gRv0.net
定義の布教なんかより技術的な会話をしろよ
770:デフォルトの名無しさん
18/05/13 00:03:10.09 C4Q8t1mmM.net
必死なのはどちらなんだろう…
771:デフォルトの名無しさん
18/05/13 00:20:47.86 OjngaL1la.net
C++スレらしい流れだと思うよ
772:
18/05/13 00:59:58.71 eWw2CnRZ0.net
面白くていいじゃないですかぁ…
ここで linus メールをコピペ（省略）
773:
18/05/13 01:17:46.49 eWw2CnRZ0.net
>>742
面白い表ですね
つい C# とか lisp の立ち位置を確認してしまった…
774:デフォルトの名無しさん
18/05/13 08:12:09.87 pAG2qz7m0.net
>>739
だからお前のオレオレ定義なんてどうでもいい
そもそも>>638みたいな話でC++→Cで全面書き換えなんてする奴はいないだろ
まともなプログラマーならボトルネックを見つけてその部分を書き換える
例えば１つのファイルに関数f1()とf2()があってf2()がボトルネックだからC++からCの範囲で動くようなコードに書き換えたとする
お前はそのファイルの記述言語は何て言うんだよ？
関数毎に記述言語が違うとか言い出すのかよ w
775:デフォルトの名無しさん
18/05/13 08:18:26.86 pAG2qz7m0.net
>>740
> 出力中に存在すると判定されて読み込んでしまいそうですが、
> そんなことないでしょうか？
そりゃ普通にそんなことあるだろ
> もし読み込んでしまう場合、自力でフラグ管理かMutexを使うなどして
> 判定する以外の方法はあるでしょうか？
そもそも何をしたいのよ？
出力完了してから読みたいだけなら出力完了してから読み込む側のスレッド起動するとかする方法もあるだろうし
776:デフォルトの名無しさん
18/05/13 09:30:39.74 tSRcUD9w0.net
>>749
お前がIDコロコロしてまでも定義にこだわる理由が分からん。
お前の定義なら、仮に全面インラインアセンブラで記述してあっても、
Cコンパイラを通したらそれは「Cのコード」であり、
C++コンパイラを通したらそれは「C++のコード」になり、
Objective-Cコンパイラを通したらそれは「Objective-Cのコード」と言うんだろ。
そんな定義の奴はいない。それは「アセンブラ」と言うんだよ。
ただこの定義はもういい。
君は間違いを認めないようだし、仮に俺が間違っていたとしても、
お互いの認識のズレは確認できたのだからそれでいいだろ。
そして>>638は最初からそう言っているだけだ。
お前は「コンパイル単位」でしか言語を規定できないからおかしな事になっている。
世間は「コード単位」でも言語を規定する。だから、お前が
> f2()がボトルネックだからC++からCの範囲で動くようなコードに書き換え
と言うのを、世間では「f2()をCコードに書き換え」と言うんだよ。
仮にお前の定義が正しくても、これを日常的にやるようなら、じきに略されて
俺（世間）の言い方に落ち着くのも分かるだろ。
だから>>638は最初から、お前の言葉で言う、
> f2()がボトルネックだからC++からCの範囲で動くようなコードに書き換える
「f2()がボトルネックだからC++からアセンブラの範囲で動くようなコードに書き換える」事を
> もっと速くしたい所をCやasmで書く
と表現している。元々「コンパイル」単位ではなく、「コード」単位なんだよ。
その「コード」について議論するのに、「コンパイル」単位を持ち出すのはおかしいだろ。
「速くしたい『所』」ってのは一部限定って事を明示してるだろ。
お前はどうしても認めないようだが。
お前は根本的に考え方がおかしい。それではまともな議論が成立しないだろ。
議論している粒度に合わせた言葉を使え。
777:デフォルトの名無しさん
18/05/13 09:51:06.22 pAG2qz7m0.net
>>751
> ただこの定義はもういい。
> 君は間違いを認めないようだし、仮に俺が間違っていたとしても、
> お互いの認識のズレは確認できたのだからそれでいいだろ。
いきなり弱気になってて笑うわ w
778:740
18/05/13 10:01:51.37 ntCzq/+YF.net
自己解決しました。
仮の名前でファイルを書き出してからリネームすれば書き込み中か書き込み済みか
判定する処理をなくせるみたいでした。
779:デフォルトの名無しさん
18/05/13 11:07:48.71 Q3HZm9Uhd.net
>>751
コンパイラが変わらない単なる最適化で
C++からCにする
なんて言わないから普通
少なくともエンジニアの会話では無い
簡単にいう場合は「最適化」「チューニング」だし
詳しくいう場合は中身を具体的に言う
頭の悪い文系を騙すのには使えるのかもしれないけど
780:デフォルトの名無しさん
18/05/13 11:09:34.85 Q3HZm9Uhd.net
C言語風なコード
と
C言語のコード
全く意味が違う
781:638
18/05/13 11:24:15.00 YEhpfoS10.net
「C++で書く」→カジュアルにSTLとか使って読みやすく書く
「Cやasmで書く」→キャッシュやSIMDとか低級に考慮してガリガリ最適化する
くらいの軽い気持ちで書いただけなのに紛糾しすぎててワイ将困惑
782:デフォルトの名無しさん
18/05/13 12:17:41.91 oMdj20B0d.net
話が長い上にどうでもよすぎる
783:デフォルトの名無しさん
18/05/13 12:26:54.36 yds9udeH0.net
またいつものキチガイか
784:デフォルトの名無しさん
18/05/13 12:43:30.13 AL0mRZz+0.net
>>756
おまえさんの頭がC++03のまま更新が止まってしまっていることはわかった
785:
18/05/13 12:46:19.41 eWw2CnRZ0.net
>>759
そう判断した理由は？
786:デフォルトの名無しさん
18/05/13 12:51:49.36 AL0mRZz+0.net
C++11以後の「低級」を知らんだろ
787:デフォルトの名無しさん
18/05/13 13:01:15.34 DrlMjc+O0.net
C++xx
この末尾のへんなナンバリングが施されるようになったのっていつ頃から？
788:デフォルトの名無しさん
18/05/13 14:22:28.62 pAG2qz7m0.net
>>762
元々はC++09を狙ってたらしいから2008年頃じゃね？
789:
18/05/13 14:53:37.16 eWw2CnRZ0.net
>>761
具体的に
790:デフォルトの名無しさん
18/05/13 15:27:50.96 AL0mRZz+0.net
>>764
人に聞くのは知らないからだな
791:デフォルトの名無しさん
18/05/13 15:47:31.87 CI2jyTw+0.net
>>759
STLが03から入ったと思ってんのか
あと
＞Cコンパイラってポインタ周りは最適化をかけないから、多分、
＞速度差はコンパイラ起因であって
こんなこと言ってる時点でID:PbE4ojLD0の話は聞くに値しない
792:デフォルトの名無しさん
18/05/13 16:22:20.14 AL0mRZz+0.net
>>766
あの流れからどうやってSTLが03からという話になったんだ？
793:デフォルトの名無しさん
18/05/13 17:44:42.77 tSRcUD9w0.net
>>756
馬鹿につき合ってすまんかった。
少なくとも俺とLinusは君と同じ定義で使ってるよ。俺の認識では世間もそう。
俺はこれでこれまで話が通じなかったことはないから。
おそらくはCをやらずにC++だけやってる世代と、
必ずCをやったうえでC++に進んだ世代の違いだ。
ゆとりだけで閉じてる世界では、彼らの主張する定義なのかもしれん。
ただまあ、話を聞いてる限り、こいつらは色々と無知だし、無知なことに無自覚だね。
まあもういいが。
自分が知らないだけのことをすべて間違いだと断定しているようでは上達しない。
C++erもここまでゆとり化が進んだのは残念だ。
794:デフォルトの名無しさん
18/05/13 19:37:46.91 5h/P5YlNM.net
本当に通じていたのかな？
いわゆるフツーの人達は、めんどくさいから適当に話し合わせてテキトーに打ち切るものだが…
795:デフォルトの名無しさん
18/05/13 20:05:09.29 tSRcUD9w0.net
ついでだからもう少し書いておいてやるよ。
ゆとりC++erが「C++は速い」ということにしたがるのは、C++「言語」以下の解像度がないからだ。
「C++コンパイラさえ使えばおｋ」になってくれてないと困るからこそ、そこに異常にこだわる。
(他言語でも同様に、低位実装を直感的に推測できない馬鹿はこの傾向がある）
お前らは>>722-723の結果、同じデータ構造で同じアルゴリズムを適用した物に対し、
速度差が出た場合にそれを「言語の差」と言い張るようだが、
それは明確な間違いだ。ただの不勉強でしかない。
実際、それだとそれ以上の最適化は
796:出来ないだろ。 C出身者なら、必要ならasm書いてチューニングすることも出来る。 現在C++は失敗しつつある。 それはRustを見ても明らかだ。以下ページを見てみろ。 https://imoz.jp/note/rust-functions.html スマポ(ｷﾘｯな連中にとってはC++よりもRustの方が明らかにいい言語だろ。（後発なので当たり前だが） C++だけにすがるのは止めとけ。 もうそういう時代じゃないし、C++はそれを満たせる言語ではない。
797:デフォルトの名無しさん
18/05/13 20:17:51.87 CI2jyTw+0.net
別にC++とCの宗教論争に加わるつもりはないが、
お前qsortがstd::sortより遅くなりがちな理由わかってないだろ
アセンブラ使わんでも自分で書きゃCでも同等の速度は出る
（というかVCの最適化にハンドアセンブルで本当に勝てるんか？こいつ）
＞CよりもC++の方が速くなるコードの方があり得ないと思うが。
＞CのほうがC++より遅いケース出してみろ。ないから。
調べもせずにこんな決めつけを書く低レベルさ以前に
これをC++のスレで書くお前はどう見てもただの荒らしだから。
798:デフォルトの名無しさん
18/05/13 20:53:01.09 tSRcUD9w0.net
>>771
お前は根本的に勘違いしている。
出発点は自前のコードでもいいが、逆アセンブル結果でもいいんだから、
改善できなくとも、遅くなることはあり得ない。
アセンブラを読めない君らでは、これは無理だ。
そして、遅くなる可能性の方が高いからやらないってのは、
馬鹿な君らなりの対処法としては正しい。
まあ、C++スレではC++マンセーしないと荒らしだ、ってのは理解した。
C++erがそこまで落ちぶれたのは残念だが、俺は去るよ。
799:デフォルトの名無しさん
18/05/13 20:57:13.19 HhTyaKjTd.net
それぞれの言語の良くある使い方であれば
Cの方が速いコードもC++の方が速いコードも
どちらも存在する
同じ処理を同じように書けば普通は同じ速度
(ただし、一部細かい例外あり)
800:デフォルトの名無しさん
18/05/13 20:59:07.22 HhTyaKjTd.net
一般的な使い方では
C++の方が開発効率が高く
Cの方がバイナリの性能が高い事が多い
(もちろん逆になる要素もある)
801:デフォルトの名無しさん
18/05/13 21:06:47.71 CI2jyTw+0.net
>>772
以前ここに書いたこともあるけど、最近ET＋simd（SSE、NEONのイントリンシック）で
ゲーム用の自前の線形代数ライブラリとか作ったんで
＞アセンブラを読めない君ら
残念ながらこれは当てはまらないよｗ
どれだけ逆アセ読んで比較したか・・・・
＞C++マンセーしないと
お前が”正しい批判をしてれば”荒れてないんだよ
ついでに言えば、
＞「C++で書く」→カジュアルにSTLとか
STLをカジュアルとか呼ぶ辺り、最近のC++界隈は
「流行に流されて自分で考えることを放棄する」という、かつてJavaの流行に荒らされた時代と
同じ愚を犯してるな、とは思うけどねぇ
C++er憎し、では色々と話がおかしくなるよ
802:デフォルトの名無しさん
18/05/13 21:07:47.84 HhTyaKjTd.net
同じ処理を同じ動作で記述出来ない例
Cの可変長配列
C++の例外処理
803:デフォルトの名無しさん
18/05/13 21:09:03.49 pAG2qz7m0.net
もうアホらしくなって途中離脱したけど
例えば関数内のループで使ってるstd::unique_ptr が遅いからその部分だけ生ポインタに書き換えたら ID:tSRcUD9w0 は何言語で書いたって言うんだろ？
って言うのはちょっと気にはなる
まあまた明後日の長文書くだけだと思うけど w
804:デフォルトの名無しさん
18/05/13 21:32:59.83 Q+Wg2L410.net
禿は神。
禿4はバイブル。
805:デフォルトの名無しさん
18/05/13 21:41:37.55 AL0mRZz+0.net
禿５マダー？(tntn
806:デフォルトの名無しさん
18/05/13 22:13:01.62 tSRcUD9w0.net
>>775
> どれだけ逆アセ読んで比較したか・・・・
ならコンパイラ出力コードが手書きアセンブラと比べてどれだけ糞かも知ってるはずだ。
それでその言い方には矛盾を感じるけどね。
> STLをカジュアルとか呼ぶ辺り、最近のC++界隈は
その発言は俺ではないが、
基本的には抽象度を上げるのは簡単にプログラミングする為であって、
「カジュアル」という表現は妥当だ。
Cみたいに全部手でゴリゴリ書く意味なんて無い。
速度が問題ない部分は出来るだけ手抜きすべきだ。STLがそれに適しているのなら使えばいい。
ただ、「STL使わなくてもどうとでもなる奴が手抜きでSTLを使う」のと、
「STLを使わないと何も出来ない連中がSTLを使う」のは全然意味が違う。
とはいえ、俺は後者が前者になるべきだとは思ってない。
ただ、後者ならC++ではなくJavaやC#を使った方が妥当だとは思うが。
君が見落としているのは、STLをカジュアルと呼ぶ連中は、
基本的に、STLを使わずに最速な実装が出来るものの、面倒なので、
「手抜き」を「カジュアル」と言い換えてごまかしているだけだということだ。
連中は君みたいにSTLが無いと何も出来ない馬鹿ではないんだよ。
> C++er憎し、では色々と話がおかしくなるよ
これは違うぞ。俺は無知なくせにデタラメを言い張るゆとりは死ねと思っているだけだ。
ただし、お前が無知のままで死ぬ権利は尊重するので、
有用な情報は書かないようにするが。
807:デフォルトの名無しさん
18/05/13 22:14:29.75 VV8A9gRv0.net
キチガイにさわるな
808:デフォルトの名無しさん
18/05/13 22:15:45.94 AL0mRZz+0.net
密度が低い
809:デフォルトの名無しさん
18/05/13 22:19:54.88 .net
>>772
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
810:デフォルトの名無しさん
18/05/13 22:28:00.02 AL0mRZz+0.net
吐いた唾は呑ませんぞ
811:デフォルトの名無しさん
18/05/13 23:48:52.64 d5CbxlL9M.net
>>780
> ならコンパイラ出力コードが手書きアセンブラと比べてどれだけ糞かも知ってるはずだ。
爺いは早めに滅びればいいのに
812:デフォルトの名無しさん
18/05/14 00:21:52.22 BWBgd2BN0.net
constexpr+UCS=ニューパラダイムのはずだったんだがなぁ。
コンパイルタイムは夢がある。
813:デフォルトの名無しさん
18/05/14 02:44:09.99 xNObD1oN0.net
昔はライブラリもそんなに充実してなかったしアルゴリズム事典とか読み漁りながら色々自作してやってたけどね
しかしまぁ便利な時代になったもんだ
Ｃ言語だと型が変わるだけで使い物にならなくなっていたものが大半だったけど
型に囚われないSTLライブラリは本当に有能だよ
型に囚われない部分は全部インラインになっちゃうけどね
814:デフォルトの名無しさん
18/05/14 13:39:06.22 0aBfdvZZ0.net
オンラインになるんか！
815:デフォルトの名無しさん
18/05/14 13:40:44.68 0aBfdvZZ0.net
実行可能形式はC++、スクリプトはPython。
これができる大人の選択。
816:デフォルトの名無しさん
18/05/14 13:48:17.86 mA8jyKTp0.net
バッチは？
817:デフォルトの名無しさん
18/05/14 13:56:29.91 0aBfdvZZ0.net
バッチは他人からパクるので贅沢は言いませぬ。
818:デフォルトの名無しさん
18/05/15 20:21:01.90 L6tD5feN0.net
スタイルについての質問なんですけど、Cの文法で書けるならできるだけCで書いたほうがいいのでしょうか
上司のC++のコードがもうほんとゴリゴリのCって感じで、C++でcharの配列も無かろうよと思ったりするんですよ
確かにその方が分かる人は多くなるかもしれないですけど
819:デフォルトの名無しさん
18/05/15 20:32:27.71 tHLzTn7F0.net
>>792
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:
- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)
- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。
言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
820:デフォルトの名無しさん
18/05/15 20:34:21.22 joZeDATc0.net
いや別に
C++で問題ない
上司の意図は知らんが
パフォーマンスを考えたコードとか
互換性を考えたコードとか
そういう可能性も
5chの一般的な価値観とは違って
C++っぽいのが良いコードって訳じゃない
821:デフォルトの名無しさん
18/05/15 20:36:35.58 joZeDATc0.net
逆に若者はコストも考えずに安易に汎用コンテナを使ったりと思うことがある
822:デフォルトの名無しさん
18/05/15 21:03:22.33 5psId9wb0.net
ものによるのじゃん？
メモリイメージを意識するならCスタイルの方がきれいにおさまる。
823:デフォルトの名無しさん
18/05/15 21:09:12.04 .net
バグを生む可能性が一切ないならCスタイルのほうがいいに決まってる
824:デフォルトの名無しさん
18/05/15 21:41:08.24 h7VmA7z3a.net
c言語って移植性あるの？まともなの？
825:片山博文MZ
18/05/15 21:41:08.58 NlOsi0K3d.net
最近のC++は、std::vectorが配列に最適化されるのか？ 遅いだろ
826:片山博文MZ
18/05/15 22:23:39.58 NlOsi0K3d.net
C++11以降ならstd::array使うけど、覚えることがともかく多い
827:片山博文MZ
18/05/15 22:26:59.43 NlOsi0K3d.net
区間チェックしてくれる配列を簡単に指定できると嬉しいの†
828:片山博文MZ
18/05/15 22:31:58.98 NlOsi0K3d.net
例えば、[ ]を二重に書くと添字チェックしてくれるとか。どうかな。
int a[[10]];
829:デフォルトの名無しさん
18/05/15 22:42:37.30 PNM8l+laM.net
atじゃだめなんか？
830:デフォルトの名無しさん
18/05/15 22:43:36.39 sqV4cudU0.net
例外投げるインデクサと投げないインデクサ両方ありますから。
831:デフォルトの名無しさん
18/05/15 22:46:39.90 IhUmYIjB0.net
プロパティONにするとチェック有効で
832:デフォルトの名無しさん
18/05/15 22:46:50.65 IPNyvhtL0.net
>>802
オブジェトCを彷彿させるので嫌です
833:デフォルトの名無しさん
18/05/16 03:32:46.81 gRCAgj/W0.net
>>802
attributes構文と紛らわしい。
834:デフォルトの名無しさん
18/05/16 23:25:18.23 cmH84vOv0.net
arrayはなんで［］でチェックしてくれないの
835:はちみつ餃子
18/05/16 23:28:49.70 axtQyUCZ0.net
ゼロコストの原則
836:デフォルトの名無しさん
18/05/17 02:43:52.94 vEqyw0xg0.net
C++のコストの大部分は例外に起因するらしい。
Cでコンパイルできるコードであっても、C++としてコンパイルするとバイナリが肥大化する。
その原因は例外。
837:デフォルトの名無しさん
18/05/17 07:10:31.59 AhjFsLsi0.net
x86-64だとゼロコストだよ
838:デフォルトの名無しさん
18/05/17 08:34:28.77 FVFi5bM10.net
どこにコストが消えたんだろ
サボってるの？
839:デフォルトの名無しさん
18/05/17 09:12:53.49 UhXGat7x0.net
>>810 要出典。
840:デフォルトの名無しさん
18/05/17 14:51:21.43 T9EnGAyld.net
x86-32だと割り込み発生時に対応出来るように
関数コールの度にスタックに情報を埋め込む
x86-64はこれが不要
割り込み処理がなければコストはかからない
841:デフォルトの名無しさん
18/05/17 18:56:39.80 vEqyw0xg0.net
>>813
組み込み開発の株式会社○○みたいなサイトで読んだんだけどな。
なかなかためになる内容だったしブックマークしとくんだった。
見つけたらリンクくれ。
842:デフォルトの名無しさん
18/05/17 18:58:28.25 vEqyw0xg0.net
俺の見解では、例外にコストが割かれるなら、それは必要なコストだと思うんだよな。
843:デフォルトの名無しさん
18/05/17 19:43:22.14 WDNJ9RfY0.net
元記事消えてるっぽいからアーカイブだけど
URLﾘﾝｸ(bytepointer.com)
Windowsの例外機構がx64ではスタックベースからテーブルベースの通過するだけならゼロコストなものに変わった
ただしバイナリサイズは増える
844:はちみつ餃子
18/05/17 19:46:45.63 oI1zc+Au0.net
>>816
例外を使うならコストがかかるのは当然なんだが、
例外が通過しないかもしれないのにそこかしこで情報を積まないといけないのは良くないってことなんよ。
そんでまあ例外を投げたときだけにコストが生じる方式がいいよねっていう話。