【初心者歓迎】C/C++室 Ver.104【環境依存OK】 ->画像>3枚

エスケープシーケンスやWin32APIなどの環境依存なものもOK
そのような質問は必ず環境を書きましょう
半角空白やタブでのインデントはスレに貼ると無くなります

コードを貼れる所
http://codepad.org/
https://ideone.com/

前スレ
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
http://2chb.net/r/tech/1530384293/

c++builder10.3 community
IID_PPV_ARGSを使わない場合どうしたら良いか教えてください
何を入れたら良いのかわからないです
#include <windows.h>
#include <tchar.h>
#include <shlobj.h>
#include <shellapi.h>
#include <commoncontrols.h>
void __fastcall TForm1::Button1Click(TObject *Sender) {
IImageList *piml;

SHGetImageList(SHIL_JUMBO, IID_IImageList, (void**)&piml);// pimlがNULLになる

SHGetImageList(SHIL_JUMBO, IID_PPV_ARGS(&piml));// 成功
}

わけのわからん言語をこねくり回して、つまらんことしてちゃ、つまらん。

O2

つまんね

>>997
UTF-8 は char * に入れるもの
char32_t * ならぎりぎりセーフ

wchar_t * は wcs 用
UTF-32 を wchar_t * に入れる

utf8は漢字仮名に3バイト使ってることわかってんのか
処理を簡単にするためいったんwchar_t使うのは普通のこと
でなければ文字数のカウントすら文字コードを調べる羽目になる

その用途ならchar32_t*ってことじゃね

調べる羽目になるっていうけど、たったそれだけのことでしかない
当然、パフォーマンス的に最適な方法は場合による

>>8
c++17は調べてないが、
char32_tだと文字列処理のライブラリも正規表現も使えないだろ。
既存のライブラリ使うためにまた変換するのか？

>>9
たったそれだけて、文字列処理なんか主たる作業じゃないC/C++プログラマにとっては、
utf8の文字コード常に思い浮かべながらコーディングするなんてのは不快極まるだろ。
*x == 'あ'
これが書けないことがたったそれだけかよ

endian でドツボですねわかります

そもそもchar32_tてutf32用だろwwww

判ってないなお前

このなかで一番美人なのって真ん中だよね？深キョンレベルだと思うのだが
ちなみに向かって右は目も鼻も整形してるって本人が公言してるけどそれ抜きにして誰が一番美人だと思う？
http://bigsta.net/media/1933567086757747003_3564907098

VSだとwchar_tは16ビットだろ。
だから3バイト以上/文字あるutf8だとおいしくもなんともないが、
unixは32ビットなんで、シェル出力をfgetwsでwchar_tで受け手、時にwstringで処理すると、
fgets->charより格段に楽に処理できる場合がある。
環境依存であんまり人に推奨できないだろうけど、unix, gcc限定なら正しく処理できる
もちろんwslでも使える

次から次へと嘘を並べるのがウリナラ

密漁船を捜索中だった→密漁船は既に発見し救出中(実際は瀬取り中？)だった
レーダーは水平以下へ照射していた→上空へレーダー飛んだのはなぜ
機体は真上を飛んでいた→実際は1km以上遠方だった
カメラを向けただけで照射はしていない→レーダーも回転して対面していた

selectしてないから

>>18
selectは「複数ソケットのとき」という先入観があったのですが、
1ソケットのときでも使うんですね。
ありがとうございました！

gccでしか確認してないが、warningは出るんだが
前にu8をつけない'あ' は int (4バイト)展開されるんだな
u8つけてしまうと下位1バイトしか処理されないんで正しく処理されない。

wchar_t buf[0x100];
としとくと
buf[i] == L'あ'
ではwarningすらでない.

文字リテラルにu8プレフィックスは使用できない。

【ＴＯＫＩＯがまた被曝を応援】　「不勉強」「操られている」のはローラではなく、安倍と食事した奴
http://2chb.net/r/liveplus/1546137382/l50

https://cpplover.blogspot.com/2012/02/blog-post_16.html

>>21
いったいいつの時代の話してるんだ古すぎるんだよ情弱
C++17から問題なく使用できる

情弱がねごとほざくからそのたんびにイラン労力強いられることとなる
ちったぁ情報収集してこいよダニ

どうせだったら、utf8専用のchar8_t型も用意しといてくれたら良かったのに。
ascii文字圏の連中にはどうでもいいことなんだろうけどw

教えてください。
C++のvectorについてです。
あるvectorの要素を自分自身に追加したいとき、どうすればよいのでしょうか。
例えば、v.push_back(v[2]);のようなことをしたいのです。

それでいいんじゃね？

>>27
それ以外の何を望むの?
特定場所への挿入v.insertぐらいしかないじゃん

27です。レスありがとうございます。v.insertでうまく行きました。
v.push_back(v[i])だとなぜか空の要素が追加されてしまい、困っていました。

>>27
https://stackoverflow.com/questions/18788780/is-it-safe-to-push-back-an-element-from-the-same-vector

>>30
まともなpush_backの実装なら対策されているので問題ないはず。
無対策でも明示的にコピーコンストラクタを呼べばうまくいかくも。(要素の型をTとする)
v.push_back(T(v[2]));

あ〜そういうことか
俺もハマりそうだなそれ
でもそれはvectorの実装側の責任になるか

>>27
意図しないエレメントが追加されてしまうC++は何？バージョンも併せて教えてよ

環境書くのを忘れてました。すみません。
Win7、Visual Studio 2008です。

>>32
まともでない実装ってのはどのテンプレート？つかコンパイラ？

>>35
thx
なるほど10年前のコンパイラならstlにバグ残ってる可能性あるわな
2011、2014、2017でずいぶん新しくなってるよ
仕事で2008指定されてるとかじゃなければ2017入れて損することあんまないと思うけど

さすがにvectorではまともでない実装にお目にかかったことはない。
VisualStudio2010のMFC独自コンテナCArrayで同じ問題ではまったことがあっただけ。

マジかよ MFC 最低だな！
失望しました。WPF 使うの止めます

vsに2011ってのもあったのか、いやあ勉強になるなぁ

C++の規格と混同しているっぽい。

C++の規格の話

つまり江添亮の話

>>31
参考になりました。ありがとうございます。

元日記念カキコ

gnuのobstackってざっくり理解するなら普通にデータ構造としてのstackのいち実装って認識であってますか？

うん

はっキネン

Privateにメンバ関数を置くのって別にいいですか？

いいんじゃね？
そのクラスの中のみでよく使われる関数とかprivateにする

zen2 5GHz が来た！
https://wccftech.com/amd-ryzen-3000-zen-2-cpus-ryzen-9-3900x-ryzen-7-ryzen-5-listed-online/

誤爆しました

デバッガってどう動いたら正常なんでしょうか
vscodeでハロワしてみてブレークポイントで止まる→これでいいんだよな？となりまして

リクツを語ると
デバッガにデバッガを適用するとバグかどうかを検出できない

Win32APIなんですが、
ウィンドウクラスにアイコンハンドルを設定してWS_OVERLAPPEDWINDOWスタイルで
CreateWindow()すると問題なくタイトルバーにアイコンが表示されるのですが、
WS_POPUPスタイルでCreateWindow()した後にSetWindowLong()でWS_OVERLAPPEDWINDOWスタイルに変更すると、
タイトルバーにアイコンが表示されません。
WM_SETICONをSendMessage()しても変わりませんでした。
どうすれば表示されるようになるでしょうか？

>>55
つ Win32API質問箱

>>56
そちらはスレが盛んでないので、こちらでお聞きしました･･･

じゃあ自力で頑張って下さい

>>55
http://eternalwindows.jp/control/controlbase/controlbase06.html
http://chokuto.ifdef.jp/urawaza/api/SetWindowLong.html
SetWindowLong 関数で変更されたそのデータは SetWindowPos 関数が呼び出されるまで反映されません 👀
Rock54: Caution(BBR-MD5:79b7e0206b0fd5ffcfddd514fa488d36)

>>59
SetWindowLong()後にSetWindowPos()はコールしていたのですが、
WM_SETICONをSendMessage()するときのアイコンハンドル取得方法がまずかっただけでした（汗）
（LoadIcon()のHINSTANCE引数が正しくなかった）
今は問題なくアイコンが表示できています。
お騒がせしました！

>>60
https://g.co/kgs/ZEZu9X 👀
Rock54: Caution(BBR-MD5:36abcc1a7fb24404caf692865ab3af18)

>>57
盛んでないなら先ず盛んにしろよ
欲しい者は先ず自ら与えると言うぞ

難癖つけ太郎

ﾂｹﾀﾛｻｧﾝ

C++て3年周期で新規格リリースされるんだなC++20が来年発表て、
えーかげんもうついていけんわ
家電のモデルチェンジじゃあるまいし。言語の追っかけなんかやってられん。

C言語の需要はそういうところじゃねえの
もうこれ以上進歩しないが大抵のことはできる
適度に難しいところもある

>>65
もしそうしたければ古い版の規格で書いてもええんやで。
C++20 が出ても C++11 が消滅するというわけでなし。
まあ主要なコンパイラがサポートしなくなったらしょうがないけど……

C++11が神過ぎる。
それまでとは雲泥の差。
これだけでずっと戦える。

>>67
言語って自分だけで済まんだろ
キャッチアップしていかんと人の書いたコードが読めなくなる
こんな短期間でアップデート繰り返すんじゃなくもっと精査した上で規格変更しろといいたい
アップデート繰り返す度にユーザ減少してるだろ

>>66
new/delete無造作に使ったコードを組込なんかで書くと、
メモリフラグメント作りまくるだけだからな。
ハードウェアの一部としてRTOS上で安定動作させるためには、
ポインタ使いまくりのbetter Cとして書くしかない。
4kB メモリのRL78でコード書いてみろと

>>69
C++の良かったのは仕様が枯れてることだったのにな
今は逆を逝っててどんどん人が離れて逝ってる

utf-8の文字コードが格納されてるchar配列から、デコードされた文字をstd::string型に入れる方法を教えてください
以下のような変換を実装したいです

char ai[] = {0xe3, 0x81, 0x82, 0xe3, 0x81, 0x84}; // "あい"のutf-8コード
std::string str = ??
std::cout << str << "\n"; // prints "あい"

>>72
aiの最後にnull文字は入れないの？
入れないなら
srd::string str { ai, sizeof(ai)/sizeof(ai[0]) };

>>72
wstringに入れろ

>>69
時間を掛けたら扱う項目 (提案) も増えるからどっちでも同じだよ。
一度の変更が大量になるよりは小さな変更を頻繁にした方が良いというポリシー。
その方が実際の運用で出た問題をフィードバックしやすいという利点もあるしな。

>>73
配列の大きさを知るには std::size か std::extent を使えよ。

C++ には C 以来伝統の sizeof / sizeof 以外に
配列の要素数を知る方法があったはず…と思ったが std::size だったか。
でも標準で使えるのは C++17 以降だよね。

「C++ならテンプレート使えばできますよ」的な情報は色々あるけど、
結局、移植性を考えると古典的な sizeof 割り算が便利だったり。

ちょっと知ったかは、よくよく初心者を馬鹿にする。
自分も、初めは、初心者だったくせに。

スタティックおじさんにならないように戒めなければ

ヒカキンの年収が10億超え!?明石家さんま・坂上忍も驚愕の総資産とは??
https://logtube.jp/variety/28439
【衝撃】ヒカキンの年収・月収を暴露！広告収入が15億円超え！？
https://nicotubers.com/yutuber/hikakin-nensyu-gessyu/
HIKAKIN(ヒカキン)の年収が14億円！？トップYouTuberになるまでの道のりは？
https://youtuberhyouron.com/hikakinnensyu/
ヒカキンの月収は１億円！読唇術でダウンタウンなうの坂上忍を検証！
https://mitarashi-highland.com/blog/fun/hikakin
なぜか観てしまう！！サバイバル系youtuberまとめ
http://tokyohitori.hatenablog.com/entry/2016/10/01/102830
あのPewDiePieがついに、初心YouTuber向けに「視聴回数」「チャンネル登録者数」を増やすコツを公開！
http://naototube.com/2017/08/14/for-new-youtubers/
27歳で年収8億円　女性ユーチューバー「リリー・シン」の生き方
https://headlines.yahoo.co.jp/article?a=20170802-00017174-forbes-bus_all
1年で何十億円も稼ぐ高収入ユーチューバー世界ランキングトップ10
https://gigazine.net/news/20151016-highest-paid-youtuber-2015/
おもちゃのレビューで年間12億円！ 今、話題のYouTuberは6歳の男の子
https://www.businessinsider.jp/post-108355
彼女はいかにして750万人のファンがいるYouTubeスターとなったのか？
https://www.businessinsider.jp/post-242
1億円稼ぐ9歳のYouTuberがすごすぎる……アメリカで話題のEvanTubeHD
https://weekly.ascii.jp/elem/000/000/305/305548/
世界で最も稼ぐユーチューバー、2連覇の首位は年収17億円
https://forbesjapan.com/articles/detail/14474

std::sizeが使えなかったとしても(主要なゲーム機の環境の1つはC++14止まりだし)、テンプレートで取得するのはC++の移植性には影響しなくないか？

ていうかGUIとかマングリングの統一とかvtblが最初に来ることとか
テンプレート周りばっかりじゃなくて解決して欲しい問題いっぱいあるんだけどなぁ
あと個人的にはプロパティとかも欲しい

配列の要素数を取得するだけのものを自分で書くならこんな感じかな。

template<class T, size_t N>
std::size_t size(T (&)[N]) {
return N;
}

実装自体には sizeof を使ったって害はあまりない (あえてする意味もないけど)。

template<class T, size_t N>
std::size_t size(T (&a)[N]) {
return sizeof a/sizeof a[0];
}

sizeof でのやり方を「そのまま」書く、またはマクロで覆うのは、
型チェックの支援を受けられないから変なミスをしやすい。

変数 a が (配列ではなく) ポインタのときに
sizeof(a)/sizeof(a[0]) という式がコンパイルは通っちゃったりするし。
変数名を二回書かなきゃならないのも、
何かの修正のときにうっかり片方だけ書き換えたりとか有りがち。

プログラミングをそれなりに長くやってると、
馬鹿みたいなつまらないミスをした経験のひとつやふたつやみっつや二百くらいはあるでしょ。
型システムはそういうのを多少なりとも事前に検出してくれるありがたい仕組みなんだから、
積極的に活用したいところ。

C++標準じゃないけどVC++の_countofが重宝してる

>>75
>時間を掛けたら扱う項目 (提案) も増えるからどっちでも同じだよ。

同じ訳ないだろが、
仕様変更、追加したものの、さんざん使ったあげくそんなもん使うなってのはいくらでもあるだろ。
auto_ptrはどーした。
だから3年なんて製品のモデルチェンジ並の仕様変更じゃなく、言語オタク共がもっと時間をかけて精査して、
10年に一度ぐらいの変更にしとけってこった。
そもそもCのプリプロセスだったわけで、
Cとの整合性は確保した上で双方同時に仕様変更しろといいたい。
だいたいどっち見て仕様変更してんの？言語オタクのセンズリか？wwww

3年ごとなのはいいと思うけど、クラステンプレートの引数推定なんか
関数テンプレートみたいに推論できないテンプレート引数が残る形に出来ない上に
エイリアステンプレートには使えないしクラステンプレートの参照にも使えないし
デフォルトテンプレート引数では省略できないしで・・

便利だけど、あまりにも片手落ちじゃね？と思うことはある

>>84
> 同じ訳ないだろが、
> 仕様変更、追加したものの、さんざん使ったあげくそんなもん使うなってのはいくらでもあるだろ。

同じだよ。
散々使ったからようやくわかったことで、ただの言語オタクどもがどんだけ理屈をこねた
ところで現実的なプロダクトの実際なんかわかりゃしない。
精査をしっかりすれば事前にどうにか出来てたと本当に思うのか？

> auto_ptrはどーした。

これはまあ……アレだ……
これ自体は擁護しようがないほどアレだけど、
一番アレなのを抜き出して言うのもちょっとどうかなって。

強いて言えば、当時としてはスマートポインタという概念を提示出来たという
成果といえなくもないんじゃないかな……。

> 10年に一度ぐらいの変更にしとけってこった。



> だいたいどっち見て仕様変更してんの？言語オタクのセンズリか？

そうならないために言語オタクにゆだねない (実際の運用で見極める) という選択なのに、
お前はもっと言語オタクに活躍しろって言ってんだぞ。
おかしいだろ。

仕様変更が止まってる言語はともかくとして仕様策定のない言語に比べればC++の更新スパンは割と長い方という認識がある

これより長いのメジャーどころだとC11(1,20年)/Fortran2008(5年)/Ada2005(10年)/Haskell(5年前後)くらい？
Haskellなんかは処理系拡張ゴリゴリだしアテにならないし他はもう古めかしさを感じるなぁ

これ以上Dをdisるのはやめて

まぁ、TypeScriptは年6回updateしてるけど次が待ち遠しいな。

426名無しでいいとも！＠放送中は実況板で2019/01/10(木) 18:17:49.03ID:b7PfIJnh0

新しい物好きな人は、よく、古いもの馬鹿にする。
古いものに、大切なものがあることが、
よくあることを、知らない人が多い。

古いという感覚を持つと話をしただけで古いものが悪いとは一言も言っていないが……？
一方でもしその良さが「新しい仕様を頻繁に覚えなくて良い」なら、言語に対して掛けるコストが減る事と、自身が怠惰である事の2面性を常に持つかもね

プログラマなんて怠惰でナンボだけど覚える事に怠惰か書く事に怠惰か人それぞれよね

個人的には草案で嬉しそうな機能を追加します！って言いながら実際の仕様では無限に延期される方が嫌

これな
youtube
qqwgldvnNlk
#t=41m41s

>>82
配列の参照のsizeofは配列のサイズじゃないから害はあるな()

>>84 は面白いよな、散々使うことで問題が見付かるって自分で初っ端から言ってるのに「だからスパンを長くしろ」つまり散々使うことが出来ないようにしろって言ってる
そして最後には言語オタクのセンズリかって、言ってる事が弾けまくってるな。

言語オタクのセンズリになってるのが不味いから、積極的に一定毎に更新するようにしていってるんだがな

何が言いたいのか分らん

箇条書きでよろ

おれは >>84 に同意だな
数年で更新ってそれがどれだけワークしてるのさ
だいたいどれだけ認知されてるのかようわからん小さい機能追加が山盛りな一方で
大規模なconstexprとかひかえめにいって大クソじゃん？
理論もなければ、現実のワークフローなにも考慮にはいってない
結局オナニーでしょ、何オタクかはしらんが

1.仕様が確定してからでなければ実務には使われない
2.実務で使われないと良し悪しは分からない

3-1.仕様確定のスパンが短いと、仕様に提案されてから試されるまでが短い（もし悪ければ次で撤回も可能）
3-2.仕様確定のスパンが長いと、提案されてから実務で試されるまでが長い（撤回されないと言えば聞こえは良いが、当然悪いものが残り続ける）

んで仕様策定を言語オタクのオナニーって言ってるのに、実務で試されない、策定の期間だけ伸ばして言語オタクなんとかしろって言ってるように聞こえるからよく分からんわけだ
だって君たち仕様確定してからじゃないとそうそう草案の機能なんて使わないでしょ？追わないでしょ？私だってそうだ

期間が長ければその間に普及する概念も多くなるし（少なくともc++はそれを取り込む方針の言語なので）あんまり長くすると大変だと思うよ

>>97
c++14のconstexprは条件分岐とかループにも対応してるから、そこそこ使えるよ。
文字列リテラルの長さを取得する関数とかも定数化できるし。
テンプレートの非型引数をあれこれする関数を定数化したりとか。

機能追加したい人が、ブランチして機能追加して実務で実証して、
それから正式に仕様を提案すりゃいいじゃん
なんで仕方なく業務でC++使ってるだけなのにベータテストみたいな
仕様更新に巻きこまれなきゃならないのさ

そんなことよりrvoを強制してほしい…

仕様を確定させないと各コンパイラでの実装と互換性チェックとか出来ないし、
既存のコードが動かなくなるわけでもなし、
10年くらい経って十分枯れた機能を使ってれば良いだけでは？

>>99
その程度の最適化はコンパイラが勝手にやればよくね？
もっと大規模なことしたいからわざわざconstexprなんてキーワード追加して
かつ人間様がわざわざそれを指定するんだろ？
で大規模なことをできる仕様か？あれが？
どうせみんなデバッグするときにconstexprをはずしてんだろ？
アホと思わないか？

>>103
Visual Studioでしか試してないけど、わざわざ外さなくてもデバッグビルドでは定数化されないのが普通じゃないの？

constexpr相当を勝手にやられたら、参照してるほうがリコンパイルが必要か判断できなくなるんじゃないの？

constexpr指定を使わずに同じような定数化を自動でやるとなると、
一度全ての関数を定数化可能か調べるためのプレビルドみたいなことをしないと無理だよね。

定数畳み込みなんて古典的な最適化手法だし、
gccはstrlenの最適化やるだろ
だからもっと大規模なことをやるためのconstexprだろと言ってる

その最適化をコンパイラ依存でなく標準規格化したことに意味があると思うんだけど。
gccで出来ればあとは何でも良いの？

珍説どうも
その程度の最適化技術を持たないコンパイラベンダなんてどうでもいいな
clangのバックエンド自分で作った方が早い

constexpr 相当のことはコンパイラが最適化で頑張るのが筋だというのは
まったく正当な意見だと思うんだが、本当に速度が必要な個所のチューニング
をしたいとき、つまりコンパイラの最適化以上のことがしたいときに
打てる手段が無かったりだとか処理系の拡張構文を使わなければならないというよりは、
不格好でも constexpr の方がマシ。

C++ は現実的に使えることを指向した言語で、現実はクソなんで、
クソを少しマシに書けるようにするってのは妥当な選択肢。
コンパイラが十分に賢いだとかいうような
理想的な世界で生きてる人は別に constexpr を使わなくてもいいよ。

pythonやmatlabみたいに配列やvectorを:とかでスライス抽出できないんですか？

技術スキンだけ高い奴が、できる奴と思い込んでるチキン。

>>111
それをアセンブラで書いてみてくれ

++20のfilterでスライスみたいな事ができるようになる
しばし待たれよ

>>110
constexpr指定はコンパイラにはわからない関数呼び出し先で
定数化できる計算であるとコンパイラに教えられるので
指定できるならした方がいいだろうけど

＞本当に速度が必要な個所のチューニング
そういう個所がコンパイル時にわかってる定数だけで構成されてる例なんて
まず滅多にないんだけどね

>>115
>> 本当に速度が必要な個所のチューニング
> そういう個所がコンパイル時にわかってる定数だけで構成されてる例なんて
> まず滅多にないんだけどね

constexpr はコンパイラに対するヒントであるだけでなく、プログラマにとっての制約でもある。
「そういう (速度が必要な) 箇所」であるにもかかわらず実行時の値に依存しているということを
プログラマが気づくことが出来る (ので分離するなどの工夫をする機会があるかもしれない)
というのは十分に便利だよ。

わかってないな
本当に解決しなきゃいけないボトルネックが、たかだか定数の畳み込みだけで
解決出来ることなどまず無いと言ってんの

ただの数回、数十回の普通の演算はそのままやっても十分速いんだよ
むしろ定数化できるとこを全部定数化したせいで、(即値にならないような構造体の場合)定数を読みに行くコストの方が大幅に高くなる可能性もある
constexprというか言語の機能を盲信しすぎ

あと、
＞「そういう (速度が必要な) 箇所」であるにもかかわらず実行時の値に依存しているということを
ファイルから読んだ内容、mainに渡された引数、ネットワークから受け取ったデータ
そういうの(および一度でもそれらと関わった変数)全て実行時の値だってわかってる？

オフラインで複雑な計算して、結果をバイナリで埋め込んでおくことはよくやる
ゲームなら当たり前にやるワークフローだよな
しかしそういう典型的な用途にconstexprは向いてないという間抜け具合
C++でなんでもやるというのが目的になってんだよね
こういうのをオナニーって言う

>>117-118
やりたいときに出来る方法があるというのは無いより「マシ」と私は >>110 で述べたが、
それが君にとっての妄信なのかい？
要するに、 constexpr の成果は限定的すぎると言いたいんだろ？
ほとんどの機能は個別に見ればどうでもいいような些細なものなのは普通のことだ。

何度も言ってきたが、負けを認めたら死ぬ病気なのか？君は

ついでに言えば、俺は「指定できるならした方がいい」と書いた
俺が成果を限定的だと貶してるんじゃなくて、
君が過信してるの

>>122
じゃあ何が問題なんだい？
指定できるならした方がよくて、指定できるようになってるのは指定できないより良いというのなら意見は一致してるじゃないか。

＞本当に速度が必要な個所のチューニング
＞をしたいとき、つまりコンパイラの最適化以上のことがしたいときに
＞打てる手段が無かったりだとか処理系の拡張構文を使わなければならないというよりは、
＞不格好でも constexpr の方がマシ。

(途中送信してしまった)
本当に"速度"が必要なときに速度より移植性やC++標準への準拠を優先してconstexprマンセーする
これを過信と言わずして何と言う

>>125
速度が必要な個所が「なるべく」移植性が高い形で表現できればそれに越したことは無いし、
更にそれ以上が欲しいなら移植性を犠牲にすることも出来るんだから、
constexpr の導入に何の問題もないだろ？

何でC++スレはプログラム板で勢いあるんですか？

C++で有名人になりたいです
どうすればいいでしょうか？

>>128
c++ のコンパイラを c で記述すれば、それだけで有名になれると思います
gcc が c から c++ になったときは心底残念に思っていました

>>129
それって無理では‥

>>130
つ https://www.amazon.co.jp/dp/4797344369

>>94
はちみつなんとかもそーだけど、
おまえもほんま馬鹿やね。表面しか読めないんだな。
10年間、言語オタを隔離してしまえといってるのだよ間抜けちゃん。
世の中から隔離された世界でせんずりこいてろといってる。ザーメン臭でくさいやつは地上に出るな。

大体、大規模プログラミングはすでにC++には向かないことが露呈して久しく、
せいぜいbetter Cとして生き残るぐらいしか道はないのにどういう意図を持っての3年ごとの改訂なんだ。
ポリシーなき改訂ははた迷惑なだけ
これだけ頻繁に改訂されると、スペック以外の解説本では、すでにストラウストラップ本自体改訂をキャッチアップできてない。
その邦訳ともなればますます現行仕様から浦島太郎になるのは必至。せっかく覚えた頃に新スペックの登場か？
C++初心者はいったいどの本買ってるのさ？キチガイ言語オタ江添本でも買うのか？
結局、ユーザー減少させてるだけだろうが

他人をけなす人には、なりたくないな
http://2chb.net/r/pav/1534982458/

なるな人間になるな

もしかして、最初の「なる」はNULLと掛かってる？
中身のない人間、アクセスしちゃダメな奴、みたいな意味で。

ちなみに自分は「ヌル」派。
だってNULLを「ナル」と読んだら「ぬるぽ」と言えなくなるもの。

>>131
一応買ってみました
でもどうせコンパイラ作るならC++でClangとかの実装を勉強したい

C++好きな人って、C‡‡、Java嫌いな人が多いのって偏見ですか？
関数型言語かRustの話しかしてない気がします

>>135
回文

>>132
C++ の言語としてのポリシーはこのように提示されている。
Stroustrup 自身がその著書に書いたもの。
委員会の公式な文書にするとかどうとかいう議論はあったけど、
結局どうなったのかは知らない。

・C++ の進化は現実の問題をその動因とする
・完全主義にはこだわらない
・C++ は今現在役に立つ言語でなければならない
・人に何かを強制しない
・静的タイプシステムに対する暗黙の違反が無い
・同じ機能なら人に教えやすい方を選ぶ
・C のプリプロセッサは使わないように
・C との正当でない非互換性が無い
・C++ 以外に他の低レベル言語を必要としない (アセンブラは除く)
・使わない機能はコストを発生させない

これらの考え方に基づいて今要求されているものが (不完全でも) より素早く反映しやすくする
リリース体制として ship train model が導入された。
多くの人が関わるので妥協はあるだろうが、一環したポリシーの下で改定されている。

そのポリシーを気に入らないでいる自由はあるし、それはどんどん主張して良いが、
ポリシーが無いというのは事実誤認だし、自分にとって妥当ではないからといって
必要としている人を侮辱するべきではないよ。

俺が以前「D&E読んでないのか」、って言ったせいではちみつはD&Eの受け売りするようになったな・・・

http://i-saint.hatenablog.com/entry/20101012/1286822888
「あるプログラム言語を使うためにその言語の弁護人になるべきではない。」
そういうただの弁護人になってるバカは大抵C++を実用レベルで使ってない人間ばっかりだ

そやな

>>140
？
このスレで言われたから読んだということは無いはずだが、どの発言のこと？
正確に覚えてないけど
私が持ってるやつは (日本語版の) 初版だからたぶん 2006〜2007 年頃には読んでるはず。

現実的な問題があるならそれは解決されなければならない問題であって、
改定を先延ばしにすることを要求するのはおかしな話じゃない？

ドキュメントが追い付いていないのは、これは確かにあるけど、
翻訳とかに時間がかかるのが分かっているから
早め早めに改定がリリースされるのはむしろありがたいことでしょ。
デカい改定が一気にくるよりは。

constexpr が限定的に過ぎるとかいうのはわかってる話で、
だから制限を緩くしたり consteval を検証したりしてるんだろ。
それでも必要だと判断したから入れたんだから、
そこに文句付けたって今更な話で擁護もクソもない。
駄目な部分があるのは知ってるっつーの。 それでも要るんだよ！

>>138 回文には気づかなかった。
「なるな」「人間に」がそれぞれ反転同一で、
それらフレーズを反転同一になるように並べて作成した回文か。
「人間になるな人間に」でも構造的には同じね。

いくらかPPAPな感じがしないでもない。
あと、正規表現のパズルっぽくもある。

酢にピリッとした風味を足すのに使えます

＿人人人人人人＿
＞　スピリタス　＜
￣Y^Y^Y^Y^Y^Y￣

>>145
すまん。 誤爆した。

はちみつと関係ないと思ったけど、餃子の方には関係ありそう。

しかし、C++スレッドでの真摯な態度と裏腹に、
他所ではどういうキャラクタなんだろ、と思わせる投稿ね。

真摯かねぇ・・・・希望的観測で詳しくないことに首突っ込んだり
自分の間違いや認識の誤りは絶対に認めないクソコテなのに

まぁそれも俺の主観だから他の人がどう思うかは知らんけど。

>>145
風味って鼻から空気が出る時に感じる食べ物の香りかと思ってたわ

c++が対象にしてる現実問題って何だ？
c++使う大規模プロジェクトってゲームがまずあると思うけど
例外禁止未だに普通だし標準ライブラリも限定的にしか使わないよ

c++で書かれたc++のコンパイラのことだろ
ここが0.001%早くなるだけで世界から年間１０００００時間くらいが節約できるんじゃねえの

じゃあLLVMのコーディングスタンダードこれな
https://llvm.org/docs/CodingStandards.html

例外、RTTI、iostream使わない
現実に使えるソフトってのはこういう制約で作るわけだ
C++の標準化やってる連中はメタプログラミングで遊んでるだけ
現実問題なんて何もわかってない

例外使わないとかないわー
初心者かよ

だから、ブラウザ、ロケット射的距離のシミュレーション、機械学習

>>153
初心者ってのはC++の例外のバイナリモデル説明できねーやつのことな

>>154
でC++がそれらに対してどんな問題解決してくれたんだ？

>>152
そこらへんはしゃーない。 便利な機能も害悪な場面は有るし、
ある時点では有用だったものが後には足を引っ張ることもある。
あるプロジェクトで縛りを設けるからといって
それが現実の全てというわけではない。

ただ、例外を使わない方向というのは大きなプロジェクトでは
そこそこあるかも？

>>153
例外が忌避されるのは他の言語と接続したときに、
呼出した側が例外を捕捉できないというのが致命的で、
つまりはそういった場面が想定されるようなライブラリでの一般的な規則。

外へ出る前に例外を全部キャッチしてしまうってのでも、
まあなんとかならんことはないが、
近頃では std::optional を活用した方がいいという雰囲気はある気がするね。

Go や Rust は最初からそういう方向だし。

このスレ、初心者を見下す者ばかりだし、

何が　【初心者歓迎】だよ。
【初心者歓迎】はずせ。

そう言うと、「何にもそんなことしてないよ」
とか、レスが来る。
子供スレ。

optionalはヒープ使わないだけでnullと大差ない
せっかく静的にnot nulが保証されてるとこを壊してしまう
ほとんどアンチパターン

業務でC++使ってない雑魚の意見なんて無視しろ

趣味でC++齧ってるやつと本気で仕事としてやってるやつじゃ格が違うんだよ

C++では好きなだけ効率を犠牲にして安全を手にすることができる
効率を犠牲にして安全を手にすることを余儀なくされている言語とは区別すべきだ

業務で使ってない素人は平気で例外禁則とか言って返り値チェックで死ぬほど汚いコード書くんだよな

まぁ業務と違って趣味は時間を無駄につぎ込めるから
人によっては素人の方がレベル高かったりするけどな

そういうのと比較するのはホントやめて欲しい

>>164
は？業務と趣味でやってる奴が一番最強

>>159
optionalの理解間違ってるよ

>>163
例外禁止されるのは業務の方だろ
一見汚くなるがそちらの方がバグが少なくメンテしやすいという判断で
トップダウンで強制される
趣味なら最新の機能ばんばん使って自由にやりゃいい

実際には例外を禁止するとバグが増えてメンテしにくくなるんだけどな

そのソフトが気に入らないなら、
そのソフトを使わなきゃ良いだけだし。
そんなことも、いい年になって、わからないのか。

このスレ卒業死体

スレばいいじゃない

setjmp 使えばよろし

遂に中級者になるのか……

>>173
なんでID消えてるの？

浪人で消してるんでっしゃろ

単なるエラーを返すのに例外機構みたいな大域脱出って牛刀感あるよな。

エラーコードの取り間違いやチェック漏れがないように書くにはすごい集中力が必要で神経をすり減らす作業
スローすれば僅かな労力で安全に済むところをわざわざ戻り値にするのは事を大げさにするだけ

つ errno

なあに、例外のcatch漏れや例外安全を欠いていないか注意するのと比べたら
たいてい局所的に判断できるから大したことない。

>エラーコードの取り間違いやチェック漏れがないように書くにはすごい集中力が必要で神経をすり減らす作業

検査例外じゃない例外機構でそれを保証するのも簡単じゃないと思うがな。
まぁ、一人開発で投げるのもcatchするのも全部把握しているという前提ならわからんでもないが。

>>179
そのへんはチェックするツールとかあったりしない？
知らんけど。

実はキャッチ漏れは戻り値処理漏れよりはるかに少ない
戻り値処理はその場でエラー処理したくない場合にも一度変数に受け取って分岐を入れて呼び元に返すということを繰り返さなければならない
なので処理漏れを起こしうる確率が呼び出し箇所の数に比例して増えていくことになる
そして本当のエラー処理をしたい場所が隠れてしまいコードの可読性が低下する
可読性が低下すればミスがさらに増える
例外なら処理したくない場合は何も書かなくていいので間違えようがないので安心
またエラー処理をしたいまさにその箇所だけに処理を書けばいいのでコードの見通しが非常に良くなりミスも激減する

エラーコード戻し安全なコードを書くことは実は非常に難しい
エラーコードチェックのせいで無駄な変数と分岐が大増殖するので正確にシステムの状態を追うことが困難になりミスが増える
例外を使えばフローが非常に単調で綺麗になるので安全なコードを書くのも簡単になる

同じ理由で、忌み嫌われてるgoto文も、実はけっこう便利だと思う

正しく使えば何だって便利だし、
駄目な使い方をすれば何だって駄目だっていう
すごく当たり前すぎる話

>>183
>>180
プログラミング辞めてツールでチェックしてもらえば？

>>180
それが検査例外じゃないかな。
いろいろ批判もあるけど、例外の内容に応じてそれぞれ異なるリカバリを確実に行うことを
保証する手段としては今のところそれ以外無いかなと思う。
まぁ、erlang/swiftあるいはgoのpanicのように、エラーの種類なんて気にせず「この下の
処理が失敗した」とだけ捉えるのが例外の扱いとして妥当なところかも。

>>181
使い捨てでないまともなプログラムはいたるところにエラーリカバリー処理が入る
つまり例外だといたるところにtry catchかつ外に投げる例外は誰がcatchするのか仕様が複雑
仕事で大規模なプロジェクトに関わったことない人はこういうのが理解できていない

例外押しのやつはどうせほとんどcatchせずにそのままexitさせてるだろ
exitするぐらいなら異常が発生した場所でabortする方がはるかにいい
確実にスタックダンプが残せる

例外が有用なのってネットワークとストレージのioぐらいという認識
それ以外で必要性を感じない
配列外アクセスとかで例外とばすなと思う

>>188
そういうバグが原因の例外はcatchしなければいいんでは？

>>189
だから現実的にそういうのに例外をなげる仕様にありがたみがないでしょ

>>190
なんで？SEGVも起こさずに潜在的なバグとして残り続けるよりよくない？

>>191
自分でcatchするならtry catchがうざい
バグ扱いでcatchしないならそもそも例外投げずにpanicされた方が調査が楽
また下手にどこかでcatchされたらバグに気づかない危険性がある

以上の理由により

gotoなんか品質チェックに問答無用で引っ掛かる

お間抜けな品質チェックだこと

ID:cHsPUmRi ってcatchで全ての例外がキャッチされると思ってるのか？

例外が発生しました

「このPCの電源が入っていません」

例外機構は誰がキャッチするのか別の問題を作った
問題先送りで日本人らしい
結局本質的には何の解決ももたらさなかった
例外機構はオカルトだったんだ。占いの類

例外なくしてOS作れるか？

>>197
エラーを返却値で返すことにしたところでそれは同じでしょ。
どこまで上に (返却値によって) 伝播すべきかってのは
どこでキャッチすべきかと問題は同じだよ。

ダウソファイルのファイル名置換する簡単なプログラムをC++とC#で書いてみた(C++で作って、それ見ながらC#に変換した)
もともとシェルスクリプトでもいいようなプログラムなんで実行速度とかどーでもいい
コンパイル時間長が
C# <<< 超えられない壁 <<< C++
C++のコンパイル時間と比べるとC#は一瞬で完了する。これは、快適性がだんちだな。

if文使うな。
ということか？

リターンコードスタイルにすると


無駄な変数が増える
無駄な分岐が増える
エラーコード追加時に全ての呼び出し元を精査しなければならない
エラーに付随する情報を伝達する標準的な規則が存在しない
全ての正常系の処理にコードチェックのオーバーヘッドが追加される
ライブラリ内部で発生する例外への対処が困難(例外を基本としていれば容易に対処可能)
参照透過性が壊滅する

デメリットだらけ

>エラーコード追加時に全ての呼び出し元を精査しなければならない
>参照透過性が壊滅する

例外ならそれが解決すると考えているならちょっとやばい。

>>203
返り値でエラー通知するようなセピア色の世界にいるとわからんかもしれんが普通に解決するぞ

参照透過性ってそういう意味だっけ？w
最近例外ない言語増えてる事実はどう考える？

>>203
リターンコード方式や例外と参照透過性になんの関係があるんだろう…

>>205
> 最近例外ない言語増えてる事実はどう考える？
Go以外にあったっけ？

まぁ、実際関係ないね。
同じ入力に対して常に同じエラーコードを返すなら参照透過性があると言えるし、
入力によらず場合によって例外を返すことがあるなら参照透過じゃない。

「呼び出し元を精査」とかプログラム内のデバッグに例外使ってるような書き方やね
例外処理は外部的要因（ハード、通信等）のエラーのように自分の責任外のエラーを積極的に通知するために使うべきだと思うけどな

戻り値形式ではそもそも式として書けないから参照透過性もクソもないということをまずは理解しろ

int h(P const & p, Q const & q, Z & out_z) {
X x;
Int ret_f = f(p, x); // out ref x
if (is_error(ret_f)) return ret_f;
Y y;
int ret_g = g(q, y); // out ref y
if (is_error(ret_g)) return ret_g;
z = x * y;
return RET_OK;
}

↑例外を使わない下品すぎるコード
↓例外を使ったスーパーエレガントなコード

Z h(P const & p, Q const & q) { return f(p) * g(q); }

Real Programmers Don't Use Exception.

>>206
rust
swiftは最初なくて後で追加
積極的に使うスタンスでない

>>209
そこに丹念なエラー処理を追加していくと、あら不思議どっちもあまりかわらない

>>211
それってやっぱりいるじゃん
ってことだよね w

>>212
え？
何言ってるの？
エラー処理ってなんのこと？
具体的に書いてみて

>>213
エラー処理って言ったらまぎらわしかった
異常系の対応ってこと

何にでも丹念なエラー処理が必要になることはないし
丹念なエラー処理も例外の方がやりやすい

>>214
エラー処理でも異常系の対応でもいいから具体的に書いてくれよ
>>209程度ならたいしたことないだろ

案の定、参照透過性は関係ない話だった。

>>216
具体的にするには前提がいるでしょ

f、gは外部から与えられてる関数で中身を書き換えることはできない
かつ至る所で使われている
p、qは誤りを含んでいる可能性があって、異常(エラー/例外)が起こりうる
異常の場合は何かおかしかったの後で調査できるようにログに残す、
または人間にフィードバックしてリトライさせる必要がある

製品レベルのソフトウェアならいたって普通の前提と要件
これを実現するとどうなるかは想像つくでしょ？

おれは例外否定派ではないよ
役に立つところは限定的と言う主張
>>188 がおれだから
まぁ確かにどちらかで言えばなくてもいいとは思ってる
ただ現状C++の標準ライブラリは例外ありきの設計に突き進んでいるから
エラーコードで突き進むのは筋が悪いのは確か

>>218
> p、qは誤りを含んでいる可能性があって、異常(エラー/例外)が起こりうる
意味わからん

コード書けないならそう言えば？
長文で言い訳してないでさ

普通は馬鹿に割く時間がもったいないからコード書けません

そう言ういいわけ要らんし

信者ですらわずかなサンプルコードを書くのをためらうほどには戻り値スタイルは厄介な代物ということがわかったね
くだらない言い訳で長文を書く労力よりも高くつくということがはっきりした

普通signalで実装するよね〜

天狗だ天狗が出たぞぉ

やっぱり例外機構はオカルトだった。皆が長い間この迷信に惑わされ疲弊した

疲弊してるのは君みたいだけど w

>>227
少し休め
人生は長いぞ

>>225
例外の使い方知らないのか

具体的に書いてくれよ

ほらな言った通りになった

戻り値スタイルはただ異常処理を上位に委ねるだけでも多量のコードを書かなければならない
だから本当に処理すべき異常や正常系の処理が異常伝達に埋もれてしまいコードの可読性が著しく低下してしまう
>>225が>>209のサンプルコードの意図を誤解した理由がこれだ
>>225が間違えたのは予想された事だったんだ

>>225が例外スタイルでは必要ない障害伝達を書いてしまった理由も根は同じ
戻り値スタイルを書き続ける事によって関数コールの周りに障害伝達を書くのは当たり前の事なんだと頭の中に刷り込まれて思考停止してしまった
結果として例外スタイルを書く際にもいつもの癖で不要な障害伝達を書いてしまった

そして戻り値スタイル派の人々は自分達が戻り値スタイルの常識にしたがって書いた例外スタイルの酷いコードを見てこう言うのだ
「ほらやっぱり例外はダメじゃないか」
とね

ちなみに言った通りのレスは>>181のことな

>>232
> > だとより複雑になる
> なんてことはない

具体的にコードで書けよw
要件は >>218 な
h()が異常処理の責任を持つ前提でな
上に例外伝搬させてるだけでは問題は何も解決しねーから

あと
>>225
で例外投げなおしてるのは本質じゃない
単にそこでなにかしら異常系の対応をするという意味合い

人間にリトライさせることを考えると h()を呼び出したのがUIのフレームワークで
呼び出し側が "arg p is invalid" というメッセージでどっちの間違いが判定するなど
(現実には文字列で判定させる実装にしないだろうが、例な)

そこをそのまま exception_invalid_arg_f を上に伝搬させればいいだろと思うのはど素人
h() から外部ライブラリの exception_invalid_arg_f、exception_invalid_arg_g がそのまま
あがってくるというのは一般的にソフトウェアのレイヤー構造を崩してる
もちろん自分が担当している範囲ならありだが、
h() を外部に公開するような場合は仕様の責任をもつために自分で定義した例外で
投げなおすのは当たり前

とりあえず戻り値スタイルでコード書いてくれよ
例外版に直してあげるからさ

>>235
ほら何もわかってない
エラー発生箇所でなんでも解決しなきゃならないと洗脳されてんだね
何もなくてもエラー処理コードを書かなければならない戻り値スタイルの書きすぎで感覚がおかしくなってる

printfの戻り値もチェックしろよ

>>236
戻り値スタイルに慣れるとレイヤー境界がどこかも定義せずに例外変換をしてしまうようになっちゃうのかな
そして本当に変換が必要な例外は何かということも考えなくなってしまう
必要かどうかわからないけど何かしなきゃって強迫観念に苛まれてるのだろうね
戻り値スタイルだと伝達処理が必須だから例外スタイルになると不安になるのだろうな

戻り値って何？

戻り値を使う例

printf("%d\n",printf("1+2+3="));

配列・ポインタ・構造体・クラス→「プログラミング楽勝ンゴｗｗｗｗｗｗ」

スレッド・コルーチン・テンプレート→「あばばばば・・・」

はい誰もコード書かないw
お前らちっさいコードとか異常系の甘いコードしか書いたことないから例外マンセーなんだよ

やっぱり例外機構はオカルトだった。皆が長い間この銀の弾丸を装った迷信に惑わされ疲弊した

>>244
だから後出し条件出されると困るから戻り値スタイルでコード書いてくれ
って書いてあるだろ
例外とあまり変わらないんだから書けるよね？

>>244
>>209

あのなぁ、俺は他の機能についての話で何度か書いてるけど、
適切な場面で適切に使えってだけの話で、
どんな機能だってそんなに万能だと思ってるやつなんていねぇよ。

どうせ回復できない異常ならちまちまと返却値をとりまわして
上まで運ぶのはクソ面倒くせぇし、
その場で対処する必要があるようなものは
try/catch よりも if で書いた方が短くて簡単だし取りこぼしにくいってのはわかる。

どちらにするべきか判断を付けるコストの方がデカいわっていう場面なら
各プロジェクトのポリシーで一方に決めつけたって別にかまわん。

当たり前すぎて主張するのがアホくさいんだけど、
そんなことは場合によるとしか言いようが無いだろ。

異常系の処理がシビアになればなるほど例外が有利になる
リターンコードスタイルは複雑化した分岐と大量の変数のせいでミスを誘発しまくる
例外ならば必要な時に必要なだけ異常系の処理を書けばいいので混乱することはない
例外スタイルにはまったく過不足がない
やりたいことをジャストそのまま書けばよろしい

>>248
中身のない長文は要らんよ

例外はその機構が重いから極端な異常系にしか使わないようにしてるのも今は昔の考え方なのかな

>>250
ここ数10レスほど続いていた中身のない不毛なやり取りより>>248の1レスの方が有意義だと思うぞ

>>252
お前もな〜

>>251
そもそも正常系では例外の方が速い

>戻り値スタイルに慣れるとレイヤー境界がどこかも定義せずに例外変換をしてしまうようになっちゃうのかな

レイヤーの境界やエラーの粒度の違いに頓着しないのは、どっちかというと安直に例外投げれば良いと
考えている方のような気がするがな。
この一連の発言見ても、投げた例外が誤ってレイヤー境界を越えてしまわないようどう保証するかなんて
言及してた人いないでしょ。

>>251
例外にもいくつかの方式があって、SJLJ ってやつは例外を投げないときもやたら遅いが、
他のほとんどの方式は例外を投げないときはゼロに近いコストのはず。

ただ、 SJLJ 以外の方法というのはデバッグ情報を使うためにツールチェインとの連携が必須だとか、
ハードウェアの機能を使うとかいった制約があって移植性に難があったりもするので、 SJLJ も滅びずに残ってる。

要するに例外の処理速度は場合によるが、
普通のデスクトップコンピュータで SJLJ を使わざるを得ないようなみみっちいツールチェイン、ハードウェアって
ことはあんまりなかろうと思う。 (ある？)

>>255
リターンコードスタイルはレイヤ境界どころか体系的にエラー処理を考えるということをしないからなぁ
例外スタイルの人はじゃあどこで処理すんのということもちゃんと考えてる

例外でイベント発生させて、イベントハンドラで受けるのはど？

>>255
> この一連の発言見ても、投げた例外が誤ってレイヤー境界を越えてしまわないようどう保証するかなんて
> 言及してた人いないでしょ。
保証は言語側でやってくれるから言及する必要がないだけのこと
そもそも例外は>>249の言う通りその場所で必要なものをキャッチして処理をすればいいだけ

swith caseで分岐する場合もあれば、
関数へのポインタテーブル作って、ジャンプさせる場合もあるわけで、
例外も戻り値分岐も両方普通に使わないか？

C++てイベントとかイベントハンドラは環境とかboost任せで、言語仕様としては未だに確定してないのか？
C++11でようやくマルチスレッドや排他制御が仕様に盛り込まれたり、
テンプレートの仕様いじくるよりこっちの方がよっぽど大事なんじゃないのか？

>保証は言語側でやってくれるから言及する必要がないだけのこと

保証なんてしないよね？catch忘れたらそのまま上まですっ飛んでいくだけ。
Javaのような検査例外ならそこに差異があることを意識されられるかもしれないけど。

>そもそも例外は>>249の言う通りその場所で必要なものをキャッチして処理をすればいいだけ

そこでプログラマが考える「必要なもの」から漏れた例外は上位へ渡されてしまう。
それを防ぐためには呼び出し先から送られる可能性のあるすべての例外を把握する必要があるが、
検査例外がないなら動的型付言語のように投げる側と受け取る側とで平仄を合わせてやるしかない。

大前提が間違ってる
例外なんか最終的にはフレームワークが最上位で纏めてキャッチすりゃいいんだよ
途中でキャッチして処理するのはあくまでベターなオプションであり、それを必須とするような作りにしてはいけない

>>261
> catch忘れたらそのまま上まですっ飛んでいくだけ。
闇雲にキャッチしたいならcatch(...)ってやればいいだけ w
> そこでプログラマが考える「必要なもの」から漏れた例外は上位へ渡されてしまう。
本来キャッチが必要な例外を漏らしているならそれはバグ
それは戻り値スタイルでも同じ話
違うのは例外はキャッチする必要の無い例外についてはそこで考慮する必要はない、自動的に上位に渡されるから上位の然るべき場所で考慮すればいいから
それが>>249の言う
> 例外ならば必要な時に必要なだけ異常系の処理を書けばいいので混乱することはない
ってこと

>>262
半分同意。
結局のところエラーの種類に応じてきっちり対処するなら検査例外的な仕組みが必要になるが
そうでなければエラーの内容など見ずにlet it crash的に対処するしかない。
どっちつかずが一番ダメなやつ。

(検査例外とかいうJava自身も認める失敗作は論外として、)例外機構は正しく使えばエラー処理に対する関心の分離に有効なんだよ。
ところがC++では例外を煩わしいノイズと見做す人が多い。これは即ち関心の分離ができてないわけだ。
その一番の原因は、例外型がロクに標準化されてないことだろうね。
最上位での集約処理を実現するには、下位の全てのコードが制御下になければならない。
これは膨大な既存資産と貧弱な標準ライブラリを持つC++においては非現実的な前提である。

すべての例外を把握する必要はない
回復可能かつ回復が要件に含まれるなら個別に処理すべき
それ以外はアスペクトで処理すればいい

>>247
だからさ、比較できるように例外スタイルで一度きちっと異常系対応して
かつスーパーエレガントなのを書いてくれよって言ってんの
お前のは体よく異常系の処理全無視してるだけじゃん

catchしたい人が必要なところでcatchすればとか言うんだろうけど
例外発生場所から遠くなればなるだけ何が原因で例外が発生して、
その回避はどうすればいいかが不明瞭になっていくってのは
散々語られてる例外の欠点

リターンコードは泥臭いが下層からくるエラーをどう処理してるかはコード見れば一目瞭然
エラーを上位に伝搬させるか、リカバリーするか、その場でクラッシュさせるか
ローカルに記述が完結できてる
APIとして外部に公開するときもインタフェースの仕様にきっちり責任持たせることができる
ちなみにプルリクでレビューする文化があればエラー無視してるような雑はコードは突き返されるだろう
見ればすぐわかるんだから
大規模な開発を経験したことない人はこういう観点でソフトウェア開発を
考えられないんだよ

最後にもう一度言っておくけどおれは例外を完全否定してるわけじゃねーから
使える場所は限られるって意見ね

>>262
> 大前提が間違ってる
> 例外なんか最終的にはフレームワークが最上位で纏めてキャッチすりゃいいんだよ

これがど素人の意見
ソフトウェアの品質について考えたことがない

「不正な入力です」
「ネットワークでエラーが発生しました」
「書き込みに失敗しました」

こういう情けないダイアログが表示させて終わりのアプリを作るやつね

>>269
それでも正常に回復できてるならそれでいいケースは多い
例外の最大の利点は例外安全さえ死守できていればアドホックな例外処理が必須でなくなることで、
より丁寧な処理が必要になれば後から追加すればよい
まあ組み込みとかやってる人には馴染まない考え方だろうね

まあC++開発者が未処理例外=クラッシュと短絡的に考えてしまう気持ちはよく分かるよ
呼び出し階層の途中に一つでも if (hoge() != SUCCESS) errorhandle(); があれば例外安全は破綻するわけで、あまりにも非現実的

>>267
仕様は>>218が決めるんだから>>218がコードを提示すべき
>>236みたいに後出しの条件出されても困るからな

>>267
> 例外発生場所から遠くなればなるだけ何が原因で例外が発生して、
> その回避はどうすればいいかが不明瞭になっていくってのは
> 散々語られてる例外の欠点
それ戻り値スタイルでも同じだろ

> リターンコードは泥臭いが下層からくるエラーをどう処理してるかはコード見れば一目瞭然
だからそれはすぐ上位で処理することが前提になってるだろ
上位に何度も伝搬したら例外と同じになる上に伝搬するコードをそこら中に書く羽目になる

> ちなみにプルリクでレビューする文化があればエラー無視してるような雑はコードは突き返されるだろう
例外処理を書かないことはエラーを無視するんじゃなくてそのまま上位に伝搬してるだけ
書かないと無視してると取るのは例外をきちんと理解してないってこと

> 見ればすぐわかるんだから
お前の能力がな w

>>267
例外を使いこなせていないね

例外の型とパラメータをみれば何が起こったかはっきりわかる
おそらく君は例外の種類を使い分ける習慣がないだろ？
あったとしてもせいぜい標準ライブラリの例外をなんとなくふり分ける程度だろうね
でないとこんな発言はしないから
まずは例外を定義するところから初めてごらん

それと大規模開発をしたことがないのはそちらだろう
関数コールするたびにずらずらと変数や分岐を書かれたらあっという間に管理不能になる
大規模だからこそ標準的なコード、必要十分なコードというのが大切になる

リターンコードスタイルをレビューに出すと袋叩きにされるぞ

・ノイズが多すぎて正常系のレビューが不可能
・同じくどのエラーが上位伝達、エラー変換、共通対応、個別対応なのか見てすぐにわからない
・同じく要件漏れを見落としやすい
・正常系、異常系、判断、伝達などあらゆる要素が密集して強く結合しているため仕様変更があった場合の影響が大きすぎてレビューしきれない

>>275
考え方自体には同意するけど、>>271で示したように例外安全が破綻しているケースについてどう考える?
エラーコードを前提にクリーンアップ処理が記述されているコードが混入しているような場合ね
あくまでC++に限った話だけど、大規模開発で完全な例外安全を維持するのは極めて困難だか実際には絵に書いた餅と思ってる

>>276
訂正
極めて困難で、実際には絵に描いた餅

レビュアーの経験値不足って感が否めない

>>276-277
必要なら直せばいいだけ
非常に稀な事象についてまで例外安全を遵守する必要はないでしょ
そもそもそういう変なコードが混入してる体質の組織で何を言ってるんだよ？ って話だと思うけど

>>279
文化と素養の問題だよ
例外の是非でこれだけ荒れる現状を見てれば、例外のスルーなんて怖くてできねえよ
そりゃあんたが全てのコードをレビューしてマサカリ投げまくってくれるなら別だけどねえ

>>280
ごめん、言ってることがよくわからん
そもそも
if (hoge() != SUCCESS) errorhandle();
なんてコードがあったら戻り値スタイルでもどうしようもない
例外は魔法の杖じゃないんだから何でもかんでも例外使えば解決するわけじゃなくて戻り値スタイルより楽にできるというだけの事だよ
プログラムがデカくなるほどその差は開くけど

>>281
result = hogehoge();
if (failure(result)) エラー処理();
リソース解放();
これhogehogeが例外起こしたらリークするだろ

>>282
スマートポインタ使うなりcatchしてリソース解放して例外再送出するなりいくらでもやりようはあるだろ…
ちょっとレベル低くね？

>>283
だからそれが例外安全だよ
勉強になったね

流石に恥ずかしくね？ w

>>283
基本的にデストラクタやリソース開放系は例外投げられると大変なことになる
catchしてなんて簡単にいってるけどもcatch(...)をそこに入れることになるのはわかるかね

で、そんな当たり前のことを言って何が言いたいの？
聞きかじりの知識を披露してるとしか思えないんだが… w

例外機構は宗教
多くの人が正しいと盲信しているに過ぎない

戻り値でイベント投げるという選択肢がない言語使用自体くそじゃね？

Cにそんな機能あったっけ？
それとも別の言語の信者が折伏に来ているの？

>>265
そう、検査例外を正しく使うのはしばしば困難で批判も多いな。ただ、呼び出す処理がどのような
例外を返すか、静的な型検査による保証を与えてくれる仕組みとしては他に無いのも事実。

検査例外を否定するのであれば例外型に頼らない(>>264の後者)か、プログラマの努力で
整合をとってやる(>>261の最後)カウボーイ的プログラミングになる。
>>265はあくまでも例外に型を期待しているようだからカウボーイの方なんだろう。

>>291
＞プログラマの努力で整合をとってやる(>>261の最後)カウボーイ的プログラミングになる。

…
…
これって「カウボーイ的」と形容されるべきものだったんですか？

catch の引数は値ではなくて、「型」だから、
テキトーな super class ERROR の下に個別エラー用派生クラスを列挙しておき、
臨機応変に catch (ERROR &e) を噛ましています…

>>256
一応例外を投げておくけれども、まじめにサポートする気はさらさらなく、
そもそもやる気は皆無・全くゼロであることを、ただ、それだけを全心全霊で表現するためだけに

throw 13;

例外の処理速度については、こういう提案もある。

https://ezoeryou.github.io/blog/article/2018-07-10-static-exception.html

要するに、投げるオブジェクトが条件を満たすときは、
暗黙の返却値のような形で例外を伝播する仕組み。
バイナリレベルの取り扱いも ABI を決めさえすれば済むだろうし、
互換性も確保しやすそうに思う。

どう見ても例外否定派の方が宗教がかってる…

環境の方の質問NGなら完全スルーでお願いします

Windows8.1 64bit のうえで Windows98SE でも動く C のバイナリを作ろうと思ってるのですが
LSI C 試食版以外に何か良い方法がないかなあと…


Windows98SE の方に Visual C++ 6.0 & SP6 をインストールしても良いのかも知れませんが
DLL の整合性とか不安
VC++ 2005 は iso 持ってるだけ…Windows98SE で動くバイナリが生成できるとか何とか

業務で使った経験は一切ないです
使い捨てレベルのものを書くのが目的です

TEST::TEST()
{
　うんたら
}

ってコンストラスタがあって、このクラスにパラメータ付のコンストラスタを追加したいとき
C# だったら
TEST::TEST(int param) : this()
{
　増やす機能
}
みたいに書きますが C++ の場合はどうやって書きますか

TEST::TEST(int param) : クラスのパラメータ(param)
{
　増やす機能
}

>>297
委譲コンストラクタでググると出てくると思う。
たしかC++11で追加された機能。

>>295-296
LSI-C試食版 って Windows 用どころか MS-DOS (16bit) の、しかもスモールモデルしか作れないじゃん。
使い捨ての、いいかげんな富豪的プログラミングしたらすぐメモリ足りなくなるぞ。

ワイとしては Open Watcom C++ を推すやで。

>>295
https://bellard.org/tcc/
https://en.wikipedia.org/wiki/Tiny_C_Compiler
https://dyama.org/2012/11/tiny-c-compiler/
https://github.com/TinyCC/tinycc

LSI-Cとかなっつｗ
昔の勉強用コンパイラといったらこれだったな

LS愛ちゃん

>>302
Cマガの付録CDに常に収録されてたよな！

LatticeCとかBDS-Cとか使ってたわ

>>298-299

TEST::TEST(int param) : TEST()
{
　増やす機能
}

で出来ました。ありがとうございました。

bcc32c でコンパイルしたバイナリが Win98SE 上で動くことを確認…
Win98SE 上だと Turbo C が動くことを確認…

Open Watcom C++ というのは存じませんでした
確認してみます

森公一郎さん、4年前に亡くなってる

>>295
> VC++ 2005 は iso 持ってるだけ…Windows98SE で動くバイナリが生成できるとか何とか
なんで試さんの？

DLL hell に躊躇

LSI-C試食版ｗｗｗ
懐かしいなあ
あの頃はものすごくCPU遅かったよね
486にして感激したからな
もうC言語でプログラムはしたくない
C++だ・・・

コメントに//が使えない時点でもうダメだな俺はw

古いOSでも動作させたいけど、ソースは新しい規格で書きたい、
と言うのは要望としてはありうるな。

>>295 はLSI-C試食版(C89相当だっけ?)を使ってるようだから、
そのクチではないのかも知れんけど。

>>310
今時なら仮想マシンでやればいいだけだろ

>>312
コメント前に // つけるより
/*
コメント
*/

あるいは

#if 0
コメント
#endif

のほうがすっきりしないか？

コメントが複数行にわたる前提ね

だから何？
それに同意しようがしまいが単一行コメントのときに面倒なのは変わらないよね
個人的にはエディタがコメントの一括付け外しに対応してるなら複数行でも//の方が見やすいと思ってるけど

C言語の a=b;　って
アセンブラで言うと、メモリ→レジスタ→メモリって移し替えてるのと同じ？
メモリ→メモリにデータコピーする時って、必ずレジスタを経由しないとだめなのかな？
アセンブラ勉強初めたばっかで何言ってんだこいつ的な感じだったらごめん。

>>318
CPU の種類による。

アセンブラはアセンブラという言語の規格があるわけではなくて、
各コンピュータの機械語の単語を便宜的に読みやすい書式に置き換えた
ものの総称なので、使える命令は各アーキテクチャのデザインに従うし、
書式のバリエーションもある。 いくつかの伝統的な習慣はあるけれど。

データの移送にレジスタを経由しなければならないようなデザインの CPU もあるし、
そうでないものもある。
メモリアクセスをする命令とその他演算の命令を明確に分離するようなデザインの
アーキテクチャを特に Load?store architecture と呼んでる。

https://en.wikipedia.org/wiki/Load%E2%80%93store_architecture

コンピュータの設計の根本を左右する方針の違いなので、
理解があやふやとはいえ、ここに引っかかりを感じたというのは才能を感じる。

>>319
自分が勉強してたCPUがたまたまレジスタ必要とするものだったということですね。ありがとうございます。

あと、intelとryzenは、どちらのCPUであっても殆どのソフトは動作しますが
この2つのCPUのアーキテクチャオペランドは同じということでしょうか？
ゲームなんかは高速化の部分でアセンブラ使う場所も頻繁にあるんじゃないかなと思うのですが。

すみません自己解決。
x64ですね。

>>317
wwww
逆に、だから何？
エディタが/* 入力と同時に
*/ を自動挿入してくれるなら全く変わらないだろ
それともおまえのエディタは / 入力で
もひとつ/ を自動挿入するように設定でもしてるのか？
ゆとりもここまで来るとどーしよーもねーな。

>>318
>>319
状況によるが、
a = b;
はメモリを介せず、できるだけレジスタ間コピーになるように最適化される。

んでメモリ to メモリを許すのはCISCと相場が決まってる
RISCはメモリ to メモリは命令にない 。命令セットを減らしてるからこそ reduce
このおかげで回路が簡単になり、所用クロック数をほぼ等しくして、クロック(Hz)をあげることができた。
このタイプはメモリ→レジスタ→メモリとせざるを得ない

今は、パイプラインを深くして、CISCでもクロックをあげられるようになったのでRISC/CISCはあんまり関係なくなった。
CICSの代表はx86なのでメモリ→メモリ命令セット調べてみ。
CISCの歴史的な経緯がわかるのは、これもCISC代表のx68kやH8は、命令セットごとに大幅に所用クロック数が違う。
それに対してx86の流れをくむ最新設計のRL78だとほとんどの命令セットが1クロックとなって。RISCと変わらない上に、
メモリ to メモリが可能となってる。それでも メモリ to レジスタに比べて1クロック増えてる。
メモリ to メモリ とレジスタ to メモリを同クロック数で実行しようとするなら、 バスラインがもう一組(例えば32bit)必要になった上に、
2ポートメモリが必要になってしまうwwww

アンカー違い
× >>319
○ >>320

>>322
自分で複数行が前提だと言っときながら何言ってんの君

>>325
*/の自動補完は複数行だろうが単一行だろうが関係ないだろが。
おまえがエディタ支援による入力補助を持ち出したから応じてやっただけだろゆとり
入力の手間はむしろ/* */の方が楽なんだよお馬鹿さん

>>325
それとさ俺が複数行限定といってるのに
>>317
>単一行コメントのときに面倒なのは変わらないよね

また単一行の話をしてるのはそっちだろーが。
おまえは朝鮮人か？それともボケてんのか？

まあ例えばインテルアーキテクチャでも、
機械語の命令列を内部で μop に分解して最適化してから実行したりするので、
機械語のレベルなんてまだまだ高級な層。

内側では RISC 的なデザインとも融合していて
正直言って、そこで何が起きているのか正確に理解するのは無理。
(結果に影響しない範囲で) 命令を並べ替えることすらあり、
しかし、マルチスレッドと絡むとわけわかんなくなりがち。

Z80 の牧歌的な世界を知ってると隔世の感がある。
実際、演算能力で言えば何百倍とか何千倍とかいう規模で違うもんな……

Z80Aで、おおむね4Mhzだったような
無印Z80は知らない

日本人だとZ80AよりμPD870Cの方が普及？？？

>>329
μPD780C-1な。870だと電卓チップになってしまう。

詰めが甘いな :-P

>>328
自分もこの結論に達した

初心者です
関数の引数の1つとして3種類の構造体を受け入れたいという場合オーバーライドで3つ書くのよりスマートなやり方ありますか？

オーバーロードで3つ書く方がスマートですよ

関数テンプレートというものが一応存在する。

tempate<class T> void func(T arg)
{
...
}

このように記述すると、型に応じたオーバーライドをコンパイラが自動で作成してくれるという機能。
ただ、実際に呼び出すコードを書かないと（型が確定してないから）コンパイル対象にならなず限定的なエラーチェックしか行われない、
エラーが出た時に問題が関数内なのか呼び出し元なのかが分かりづらい、エラーメッセージもわけわからない、という欠点があるので、
あまり初心者向きとは言えない。すごく便利なんだけどね。

>>333-334
ありがとうございます
オーバーロードでしたね＾＾；

>>335
Variantが使えるならVariant
対照的にunionはおすすめしない

結局中で分岐だろ

>>336
variant勉強します
ありがとうございます

投機実行がセキュリティホールになるなんて
当時の技術者は予見できたのだろうか

いやー
論文ネタに困った情報系の役にたたん学者がひねり出したネタだろ
投機実行を攻撃に使った実例なんてあるのか？

煽ってたら論文ネタに困った情報系の役にたたん学者が投機実行を攻撃に使った実用法をひねり出したらどうすんだ

>>340
手元にようやく SandyBridge(IvyBridge) を確保しましたのでいろいろ試してみようと思っています

Googleだったっけ、見つけたのは？
役に立たない暇な部門があったんだ

C++って未だにasync,awaitがないんだな？
江添とかtemplate使えないC++プログラマはポインタを使えないCプログラマと同じゴミとかいってるんだが、
templateは確かに面白いし頭の体操になるけど、templateはひな形があれば、泥臭くエディタちょい編集して使い回したり、
yacc/lex使うとか、ループのアンロールはスクリプトで展開するとかいくらでも手段はあるので、
どう考えてもasync,awaitあたりの実装の方が重要だと思うけどな。

futureでいいんじゃね。C#のawaitもFutureパターンの実装でしょ。

>>345
.net動いてるのとそれが前提でないC++では全く同じにはいかんのだろな
教えてくれてありがと

コルーチン拡張は提案段階なんだっけ？
MS界隈ならC++/WinRTで使用例があるけど

>>346
いや別に
C#のasync/awaitって単なるステートマシンジェネレータだし
標準化は至難だろうけど技術的にはC++でできない理由はない

>>344
再帰includeとdefineの組み合わせでも大抵はなんとかなったりするなw

templateは型に縛られてるから安全な反面、不便なこともあるよね。
sjisとutf8が区別できないし。なぜchar8_tを作らなかった…(´･ω･｀)

テンプレートよりObjective-Cのやり方の方が好き

江添なんて最新仕様知ってる俺スゲーやりたいだけの奴だからな。
まともに使えるプログラムを書いてるわけじゃない。

でもプログラム書くなんて誰でも出来るじゃん

おまえのgithubさらせよ

>>353
お前が先に晒せ

きっとはぶられる

>>353
そろそろ github に移行しようか…
http://2chb.net/r/tech/1434079972/

http://hibari.2ch.net/test/read.cgi/tech/1289715349/
http://hibari.2ch.net/test/read.cgi/tech/1295273862/
http://hibari.2ch.net/test/read.cgi/tech/1309527259/
http://peace.2ch.net/test/read.cgi/tech/1313183984/

>>351
江添とか書いてることみてるとムカっ腹立たないか？
何様だこいつ。しかもやってることキチガイだろ

>>357
は？お前じゃあ江添より仕様に詳しくてC++のコンパイラを実装出来るような能力なのかね？ええ？

工学部生よりましやろ

例え世界一の物知りでもそんな口の効き方をする人とは
付き合いたくないな
RMSにはEMACSやgccといった作品があるから許される

この3冊は、日本人が作った神の書。
皆、基地外。基地外しか、こんな本を書けない

Linux プログラミング・インタフェース、Michael Kerrisk、2012

この本は、神の書と言われていて、翻訳本は日本しか出ていない。
著者は10年、man-pagesを書いてきた人で、翻訳者・アドバイスの千住治郎も、技術者

C++11/14 コア言語、江添 亮、2015

組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006

ドワンゴ江添は需要があれば、テンプレートの本を出そうか、なんて言ってるけど、既にこの本がある

C++テンプレートテクニック 第2版、
επιστημη(えぴすてーめー)・高橋 晶、2014

ステマ宣伝乙
5ちゃんでは禁止

Linuxの黎明期にman page 書いていたのは janneさん事、中谷千絵さんだよ
エピスメーテーさんは昔っから雑誌に記事を書いていたな
The Basicだった？

真ん中の人は知らないけどどんな貢献をしたの？

>>363
ざべは読んだことないけど、Cマガでεπιστημηの名前はよく見たな。
今では Teratail で C++ の質問をするとたまに回答者として出現するよ。

>>364
そうでしたか、CUJJとかは買っていたけど...CMAGは
時々だったので

>>361
えぴすてーめーと高橋のC++テンプレ本は神だわ。
なんというか、読者に理解させてあげたいという熱意が伝わってくる
江添とは大違い
江添にお布施するつもりは毛頭ない。死ねばいいのに

>>358
本人様のご登場wwww

>361 の3冊は、単なる規格の文章ではなく、それをソースコードの実例にした所がすごい！
だから、プログラマーは皆、Kerrisk の本を枕にして寝ろって、言われている

たぶん、江添やMISRA‐C の本も、外国で発売されていれば、大絶賛されるはず！

エピスや高橋ageて江添sageってのもよくわからんな
立ち位置違うし江添は委員会の人間だから
仕様や提案について素晴らしいとかクソとか言う権利や責務がある
それをsageるってことは「現行仕様マンセー、標準規格に欠点など無い！」みたいなことか？

>>361
エピさん単著は買わないですね、エピさんの文章は今の言葉で表現するとすれば「ポエマー」が近い

同じくポエマーに分類される私がいうことではないのですけど…

元々は、Kerrisk も、江添やMISRA‐C のメンバーも、
規格をソースコードの実例で、表示してやろうという、とんでもない企画！

よく規格厨みたいな香具師がいて、企画書を読めって言うけど、
文章で書かれてもわからないし、全く出来るようにならないから、業を煮やして書き始めた

こんな面倒くさいことを、何年も掛けて書くかね？

こういうのは、忍耐力がある日本人が得意なんだろう。
外人は、まずやらない

MISRA はBOSCH を引き込み損なった時点で絵に描いた餅でしょうね
デンソーが勝利すれば勝ちの目も出て来るかもしれないが

>>371
>規格をソースコードの実例で、表示してやろうという、とんでもない企画
いや言語の解説本は規格をわかりやすく、ソースコードを例示して解説するでしょ。
それがなければ、規格だけでいいわけで、解説にならない。

わかりやすく書こうとしてるけど、そこの熱意の持ち方と、おつむのレベルでほんとにわかりやすいかどうかが問題なんだろ。

そら商業目的の本だったらわかりやすく書くの当たり前だろ
江添の本は読んだことないから分からんけど
売られてる本とブログで比較してないか？

>>371
>こういうのは、忍耐力がある日本人が得意なんだろう。
>外人は、まずやらない

K&R も Stroustrapも規格になるまえからやってますがな
ソース示してこつこつと。

何もプログラム言語だけじゃないわ。人に説くこと、伝道師のようなwriterは日本人よりむしろ、英米人に多い。
クヌースの The Art of Computer Programmingあたり読んでみ。

>>374
反響見て、読んだやつにバグだしさせてたあとブログ印刷物なり、ebook販売するんだから
金取ろうが、無償でやるかはどーでもいい話
日本語のコンピュータ書籍なんて販売数からしてとてもとてもメシ食えないから
ほぼ実益のないめんどくさいだけの作業
ブログでわかりにくければ本になってもわかりにくいことは保証する

クヌースの4-1巻目は、かなりの分量をZDD/BDDの説明に割いていて
このアルゴリズムは北海道大学で日本人が考えた物だね

で、その江添さんという方はどの様な技術貢献をしたの？

>>377
警察に喧嘩売って訴訟おこしたこと以外知りませんがな
きちがいの所業なんざ

まぁC++テンプレートテクニックがわかりやすい良書なのは同意するけど
高橋晶ってたまにテクニックのメリットを語るときに
デメリットに気づいてない(またはスルーしてる)ことがあるんだよな
わかりやすくても鵜呑みには出来ない

ま、江添が好きならどーぞご勝手に俺は願い下げってだけ

好きとは言ってないよ
結局役に立つ&正確な情報を書いてるかどうかが全てだ

というか江添のブログでも「あれ？おかしくね？」みたいなことあったから
どっちがどうとも言えないけど

だいたい

ドマンコ

とかいう社名が下品すぎる

>>364
毎月題材がカウンタークラスの人…

https://qiita.com/dc1394/items/d2b8de600a304664cdb5
実に参考になった

型指定するのが嫌だから最初にautoを使うc++入門書籍を書こうとしてたり、
まともにプログラム開発してたら最新の仕様を追えないので開発しないとか言い出す奴とか
普通の精神してりゃ信用せんわな。
根本的にありゃ馬鹿だよ。

>まともにプログラム開発してたら最新の仕様を追えないので開発しないとか言い出す奴とか
江添みたいに標準化委員会に属してたら正しいと思うけどね
何もコミュニティに貢献しない趣味グラマだったりライターでもない奴が言ってたらアホだが

趣味グラマにドワンゴが給料払ってるんだろwww

すみません
n秒ごとに関数foo()を繰り返し実行するような、かつ「低負荷な」方法を教えてください。
n秒は、精度はだいたいでよくて、たぶんnは600(つまり10分)程度にしたいと思っています。

windows 10 で、gccで最新の標準C++ とboost C++ が使用可能です

よろしくお願いいたします

>>389
SetTimer API を使って WM_TIMER イベントの発生を待つのが妥当な方法だと思う。
イベントが発生するまでは何もせずに待つだけなので低負荷。

>>390
windows API をつかう方法で行ってみます
ありがとうございます。
標準C++ で導入された
thread とchrono を用いて、while (1 )を回すという方法がGoogle検索で 出てきますが、低負荷な方が良いので、windows API で行ってみます。
ありがとうございます。

whileは単なる無限ループじゃなく、スレッドが立ち上がるまで、sleep で CPU を眠らせてるんじゃないの？
whileだけだと、負荷かかるし、sleep一発だと、繰り返し待ちできないから

https://ja.cppreference.com/w/cpp/compiler_support
gccは並列STLまだ実装できてないんだな。がかーり
C++2xは後回しでいいから先に実装してもらいたいな
msvcがしらん間にgccを上回るC++17準拠状況になってるんだな
msがかなり頑張ってるのがかなり意外

趣味グラマーって本職が焼そば職人だっけ

MSが標準をわざと外して潰し合う戦略を取ってたのは遥か昔
今は協調してシェアを取り込んでから独占する戦略がメイン

>>394
ブロガーで良くね？

スパゲッティーでは？

>>396
つ https://cpplover.blogspot.com/2016/05/2016.html

>>394
Oishii Sru Paの話？

6
だまれ朝鮮人
失せろ

Class TA{
public:
TB B;
}
Class TB{
･･･
}
Class TA::TA(){ //コンストラクタ
B = new TB;
}

で、TAのデストラクタが走った時点でBも一緒に消えるんですかね。
それともTAのデストラクタで delete B が必要なんですかね。

>>401
new したのなら delete は必ず書かないといけない
https://ideone.com/z0IYgT

必ずというわけではないよ

>>403
理解はしますが薦める気にはならないのです…

>B = new TB;

エラーになるんじゃね？

>>405
それぐらいは忖度してやれよ

メンバ変数にクラスを持つときはポインタ型にしてコピーコンストラクタを作るべきですか？
それともクラスの実体を持たせても大差ありませんか？

クラスと用途による

実体で用が足りるならすべて実体でよい
効率云々はまず一通り動くものが出来上がった上でそこが問題になってから考えろ

わかりました
ありがとうございます

値型とエンティティを意識して作って下さい
エンティティはスマポで管理、値型は実体を持たせるべきでしょう

エンティエィって何？
定性的な定義を頼むわ

>>412
インスタンスがアイデンティティを持つならエンティティ

>>413
実数はエンティティですか？
符号付整数はエンティティですか？

あーやだやだ
こういう宗教じみた設計論語るやつ

>>414
値です

>>415
現実を見据えて追求すると自然と出てくる答えです

親クラスとライフサイクルが同じか数値型なら実体、そうでないならポインタでいいだろ。

動的確保よりコピーやmoveのほうがコストが低い場合とか検討の余地はあるけど、考えすぎると禿げる。

>>401
デストラクタは virtual に汁

どうせそこまで最適化も厳密なメモリ管理も必要なプログラムじゃないだろ。

>>417
ほらね、こういう精神論がでてくる

組み込み以外に使い道あるんですか？

OS作ったり、ブラウザ作ったり、3Dバリバリのゲームを作ったり、他の言語向けに機械学習や科技計算等のライブラリを作ったり、いろいろあるよ

RubyはC++が嫌いだからCで書かれている

>>423
天才達だけに許された言語なのでしょうか？
もっと身近なプロダクトはないんですか？

古い例だとニコニコ動画がC++
まあおかげで開発がスケールせずオワコン化したわけだが

the door is open

>>425
聞いてばっかりじゃなくてお前がどういうものを探しているか書いたら？

CADとか画像処理とかビット演算系アルゴリズム(cf.ZDD)なんかは
まだまだ他の言語には負けないね

>>426
＞開発がスケールせずオワコン化した
これってどういう意味ですか？

JavaからC++勉強中です
C++の場合、他のクラスのオブジェクトを複数持たせるときは、一般的にどうするんでしょうか

・コンテナにオブジェクトそのものを突っ込む（一番わかりやすいけど、ムーブの定義忘れとかでミスが出そう）
・コンテナにオブジェクトへのポインタを持たせる（コンテナ解放時に、クラスごとに同じようなメモリ解放処理書くのかしら）
・コンテナにポインタをスマートポインタで持たせる

辺りをネットで読ませてもらいましたが、こんな感じで良いんでしょうか？
不勉強な上、他のオブジェクト持つという基本的なことなので、なんかもっと簡単な方法を見落としてる気がしてしまいまして

>>431
時と場合によりますので一般的な答えはありません

>>431
Javaのオブジェクト参照はC++のポインタに該当する。
C++のオブジェクトは、型を持ったバイト列だと考えていい。
C++で自動変数を宣言すると、スタックにバイト列が割り当てられる。
newやスマポやコンテナを使うと、ポインタによりヒープでメモリーが割り当てられる。
ポインタも型を持ったバイト列。ポインタは配列のように周りのメモリーにアクセスできる。
C++のクラスは構造体に関数群を追加したもの。C++でクラスを継承すると、関数群とバイト列を引き継いだサブクラスになる。

>>431
大体、その3つの通りで、そこに述べられたものの上から優先的に選ぶ。
つまり、普通にメンバ変数にオブジェクトとして宣言するのがC++では
最も効率が良くて伝統的な書き方。それでは問題が生じる場合にオブジェクトの
ポインタとして持たせる。スマートポインタは後になって導入されたもので、
人気があるものではないので無視して良い。

二番目のポインタとして持たせるのは、例えば、今定義している最中の
クラス（自分自身）と同じ型のデータで、子どもや親にあたるデータへ
リンクを作りたいようなときか、または、ある基本クラスを継承した
色々なクラスのオブジェクトを持ちたい場合に用いる。

C/C++では、sizeofキーワードを使えば、簡単にvoid以外の型のサイズがコンパイル時に取得できる。Javaではオブジェクトのサイズを簡単に取得することはできない。
C/C++はよくオブジェクトのサイズやバイトの並びを意識してプログラミングする。

結局CのポインタってJavaとかの言語で表すなら何なんだ？

なぜなら、例えばスタックに巨大なデータを割り当てると、スタックオーバーフローというエラーが発生するし、
ヒープだって、巨大なデータの割り当ては失敗することがある。
また、構造体を変更すると、構造体のサイズやデータ構造が変化して、互換性の問題が発生することがある。

>>434氏他
丁度今、ウェブ上のC++で書かれたCompositeパターンのソースを読ませて頂いてました
正に2番目で実装されてましたが、都度メモリ解放処理書くくらい当たり前なんですね、流石C++です

独学なもんで、こうはっきり言ってもらえると本当にありがたいです、使い分けて行きたいと思います
他の皆様もありがとうございました、勉強になりました

>>436
Javaの動的配列はCのポインタに近いが、Javaの配列では危険なアクセスは制限されているし、参照カウントで管理されている点が異なる。
Javaのオブジェクト参照は、参照カウントで管理されており、C++の構造体／クラス型に対するstd::shared_ptrに該当する。

しかし、std::shared_ptrはヌルポを指定できるが、Javaはできない。

すごく古い書き方だ

>>441
ナマポの場合、代入したらまずいよ。例外安全にも問題があるし。

確かに、人に教えるレベルじゃないね

>>445
ダメだこりゃ。

良い子のみんなは>>441の危険性が理解できるまではスマートポインタを使ってね
おじさんとのお約束だよ

>>445のデストラクタでnullチェック必要？
nullポインタをdeleteしても問題ないはずだが
二重解放防止にはならんし意味わからん

>>448
超独自仕様の組み込み開発とか、メモリー管理がbuggyなプログラムでは意味があるらしい。
例えば解放したメモリーブロックをアクセスするような行儀の悪いプログラムでは意味がある。

初心者なので確認
コンストラクタの中に飛び込む前のメンバの初期化で例外発生したら m_pBuf は中途半端になるから
コンストラクタの中で代入するんじゃなく、メンバ初期化子で初期化しろ
という認識でいいのかしら

>>451
「C++ 例外安全」でググれ。ナマポを使わずに、素直に生配列、コンテナ、スマポのどれかを使えば済むこと。マネージされてないナマポは村八分にしろ。

ちょっち理解は大変だけど生ポはスマポにドンドン置き換えたい

スマポならコピーコンストラクター・代入のややこしさからも解放される。

まあまあ。
スマートポインタを活用しろというのはその通りだが、
ポインタ (や例外機構) を理解せずに
思考停止してスマートポインタを使うのはあかんやろ。

ここの元質問者はまだそこを理解しようとしている
ところなんだから、スマートポインタを使わなかった場合にどう書けば良いのか、
きちんと書くと面倒くさすぎるという体験も必要だろ。

所有権の管理は人類には早すぎる。
所有権が変動するときは、スマポでOK.

こんなときはナマポを使ってもよい:

処理の中で所有権が移動・消滅しない場合。
バイナリーデータやPODを生で扱う場合。
処理系がナマポやトークンやハンドルの入力を要求する場合。

生ポはスマポのオーバーヘッドすら許容できないときに使うものです
だから初心者は無理して生ポを使わなくていいです

>>434
スマポは後になって導入されたもので人気がない、なんて意見は一般的ではないので無視して良い

スマポをC#のusing感覚で使ってる

エアプwwwwwwwww今は参照カウントじゃねーよw残念だったなクソ蟻wwww

それで、Cの生ポってC/C++以外で表現するなら何なんだ？

>>463
native int

>>464
仮装アドレス的な意味で来るとは思ってなかったwでも本質はそうだよなあ

CALL -151

>>463 今の言語は極力「生のポインタ」が見えないようにしてるからなぁ。
オレの乏しい知識で無理矢理ヒネリ出すなら、
「古いBASICの peek, poke のアドレス指定に変数を使った場合」かのう。
型のない単なるアドレスって言うか数値だけど。

upvar

恥の上塗り

intptr_t とか、INTPTRとか。

eax

行儀よく バッファなんて 守れやしなかった
夜のサーバ　オーバフロー起こしてまわった
*印見て アナルといわれた 早く添え字になりたかった
信じられぬ カーニハンとの 争いの中で
許しあい いったい何 解りあえただろう
うんざりしながら それでも過ごした ひとつだけ解ってたこと
このポインタからの 卒業

まあstatic変数やglobal変数使ってリークしてないとか言い張るバカよりかは
ナマポ使えやとは思う。
それならまだコード修正効くからな。
初心者にスマポ使わせればリークしないコード書かせることができるって考えははっきりいって幻想だわ。

昔研究室の後輩でポインタがわからないから全部グローバル変数でプログラム作ってるって奴がいて、
それはそれである意味すごいなって思ったわ。
マルチメディア系ライブラリを触る必要がある研究室なのだが。
元々組込系が得意な奴だったってのもあると思うけど。