◎正当な理由による書き込みの削除について： 生島英之とみられる方へ:
C++相談室 part152 ->画像>3枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1594528940/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part151
http://2chb.net/r/tech/1589424805/ このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://2chb.net/r/tech/1556142878/ ■長いソースを貼るときはここへ。■
http://codepad.org/ https://ideone.com/ [C++ FAQ]
https://isocpp.org/wiki/faq/ http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
テンプレここまで
STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？
#include <stdafx.h>
後死ね。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
-Wl,--start-groupって-Wl,--end-groupで閉じなくてもいいの？
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします！
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします！
ある整数nが他の整数の4乗数であることも確かめられない奴らが常駐してるC++スレに何の意味があるのだろうか、、、
素直にsqrtなりpowなり使えば良いのに無意味に二分探索とか言い出す奴まで現れる始末
#include <stdafx.h> が入ってると消したくなる
>>7 流れ観てて思ったけど
整数の2乗数じゃないと判った時点で整数の4乗数でないことは明らかで打ち切りっていうレスが無かった気がする
それ5ちゃんは2ちゃんじゃない5ちゃんだってのと同じ匂いがする
>>9 前スレッドで
http://2chb.net/r/tech/1589424805/998 は、そのつもりで書いたんだけど、上手く伝わらなかったみたいね。
4乗数は例えばmod5で必ず0か1なので234だったら弾ける
他にもいろんなmod使ってアーリーリジェクトするのが速い
まあそれだけで判定はできないから最後は真面目に確かめるんだけど
整数の4乗だろ？
どのレンジの値までサポートする必要があるのか
この辺に意識行かないやつは初級者
template <class R>
R hoge(std::function<R(int)> func, int val) {
return func(val);
}
みたいな、std::functionの戻り値の型がテンプレートな関数があったときに、第一引数のfuncに渡す引数を
「std::function<int(int)> f = [](auto a) {return 10 * a; }」
と明示的に「std::function」にすると、Rも型推論が効いて「hoge(f, 10)」と呼べますが
ラムダ式を直接渡すと、Rの型推論が働かず「hoge<int>([](auto a){...}, 10);」と
テンプレートの型を明示しない限り、MSVC2019(std:c++latest)ではコンパイルエラーになります。
こういう場合にラムダ式から型を推論できる関数を作る方法ってないですかね？
ラムダ式がいければ、std::functionは渡せなくなってもいいのですが。
難しく考えすぎ
template <class F>
auto hoge(F func, int val) { return func(val); }
[](auto a) -> int {return 10 * a; }
[](auto a) -> std::common_type_t<int, decltype(a)> {return 10 * a; }
>>17-19 ありがとうございます。やりたかったことができました。
ラムダだからって変にstd::functionとか入れずに、関数まるごとテンプレートに委ねればよかったんですね。
どうも関数を特別視してしまっていたようです。
std::list<int> l = {0, 1, 2};
auto it = l.begin();
// auto x = move(*it);
l.erase(it);
// この後 x にムーブしてればいいけど it を参照するのは未定義動作？
// pop が削除した要素を返してくれればいいのに
コマンドライン引数でブーリアン渡したいときってどうするん
コマンドライン引数は文字列
boolとかintとか渡せない
「"1000"を1000と解釈してintを渡せる」って言うなら、
同様に"true","false"を解釈すればいい
オプション文字列を渡す作法のような話なら
-f1, -f0 や --flag, --no-flag の形で渡すかな。
簡易的には -f と指定すれば有効、指定しなければ無効、って感じ。
ある変数に対してプロセスAからは書き込みしかしないで別プロセスBは読み込みしかしない場合
この変数に対してstd::atomic<>する必要ありますか？
>>30 プロセスとスレッドの違いは理解している？
「プロセス」は「スレッド」と読み替えるとして
自前で排他してもいいし
「ある変数」が例えばintで今のPCのCPUなら元々アトミック
そういう意味では「std::atomic<>する必要」はないよ
すstd::atomic<>なら型に応じた特殊化がなされていることが気体できるのでは知らんけど
ていうかTによらずアクセスの度に馬鹿正直にcritical sectionに出入りされる実装だったら嫌すぐる、、、
アーキテクチャーに応じて確実に作動するDouble-Checked LockingとかTripple-Checked Lockingとかになって
最適なパフォーマンスが出るコードにしていただける処理系であってﾎｽｲ
>>30 別途排他制御をしていないなら、コンパイル時や実行時に勝手に実行順序並び替えて誤動作する可能性があるから、atomicにしておいたほうがええよ
>>36 未定義動作の結果はそれだけでは済まないかもしれない。
プロセスならOS提供の共有メモリ使うから、未定義動作の範疇外じゃね
>>30 結論は必要がある(もちろん環境依存しないのが前提として)
>>33は間違い
たとえCPUがload/storeのatomic性を保証していたとしても
コンパイラが代入を1 instructionにする保証がない
なのでLinux kernelでは(C言語だけど)WRITE_ONCEみたいな一見意味不明なマクロが用意されていたりする
マルチプロセスでlock-freeを自作するのは勉強になるけど、たぶんミスるから
製品とかでは使わないのをお勧めする
>>40 CPUがstoreのatomic性を保証しているのに
コンパイラが代入を2 instructionにできるの？？
俺には意味不明だ
>>41 できるできないならできるだろ
例えば32bit整数を16bit毎に書き込むようにすればいいだけだし
そんな意味のないことをするコンパイラがあるかどうかは知らんけど
コンパイラが独自仕様で明示的に保証してるなら別にいいよ
特に何も書いてないなら保証されてないと思うべき
>>42 x86だと即値の場合16bit x2のコードが吐かれる場合があるらしいよ
forで少しの（２５５以下）ループ回すときにint i=0;i<10;++iとかするけどなんで
２バイトのintでとって１バイトのunsigned charじゃあまり取らないんだろ？
（typedefで宣言すればタイプ数少なくできるし・・・）
unsigned char でループしても良いけど
結局 int にされるでしょ
それより int が 2byte っていつの話よ
>>47 すいません
＞結局 int にされるでしょ
ってとこ解説お願いします
マイコンでc使うときにメモリ節約しようと思って
そもそも組み込み系のスレで質問しろって話ですが・・・
>>48 charは算術式の中ではintに拡張されるって話だ
char a, b;
printf("%u", sizeof(a)); //1, これは左辺値で算術式ではない
printf("%u", sizeof(a - b)); //2, 減算の算術式
printf("%u", sizeof(+a)); //2, 単項プラスの算術式
>>49 なるほど
ちなみにこれで最後の質問ですが
forループは自分が間違えてましたしint使ったほうがいいと理解しました
それでビット演算でのみ使う場合においては
intにされることはないという認識でいいでしょうか？
（ビット演算で使いたいと思って調べてたらふと
>>46みたいな疑問が湧いたので）
>>46 charの拡張はcpu内部のレジスタで行われるだけで
メモリにはその痕跡が残らない
だからintをunsigned charにすればメモリを節約する効果は
期待できる（ただし保証はされない）
俺も実はforの制御変数は[0, 256)の範囲内でもintを使うが
正直に本音を言うと長い長いtypedef unsigned charをタイプせずに
短くintで済むからだ
普段建前ではintは自然なサイズの整数だからとか言い訳してるけどね
>>51 なるほど
丁寧に解説してもらい助かりました
スッキリしました、ありがとうございます
あとメモリの節約には効果ありそうなのは目論見通りなのでよかったです
>>50 されるよ
たとえば、こういう場合
char c = 0;
c = c | 1;
部分式 c | 1 は ((int)c) | 1 で計算され結果はint
c = (char)結果; という具合にcharに戻して書き込む
c は00000000
c | 1 は0000000000000001
=は00000001にしてからを書き込む
一旦intにされたものをcharに戻して書き込んでいるが
普段はこのことを忘れていても正しいコードが書けてしまう
おっと、ここC++スレやん
Cスレのつもりだったｗ
C++の場合はここ気をつけて
void func(char); //#1
void func(int); //#2
char c = 0;
func(c | 1); //#2
>>53 >>54 ありがとうございます
されるんですね・・・
う〜ん、やっぱ大人しくint使います（メモリ切り詰めるほどでないなら）
>>55 丁寧にどうもです
いや、自分が悪いっす
そもそもここで聞くなよという話なので
（ここが一番はやく回答してくれるので申し訳無さ半分で質問してます・・・）
>>51-52 「メモリを節約する効果は期待できる（ただし保証はされない）」っていうより
「メモリを節約する効果は期待できない（ただし可能性はゼロではない）」でしょ。
ほんとうにメモリ節約のためにやるなら実測のうえ結果をコメントで添えてたのむ。
>>58 sizeof(int) == 2な環境を使ってる質問者だぜ？
おまえさんターゲットをエスパーできるのか？
できたとして同じコンパイラ持ってるか？
>>56 char使ってメモリ節約ってのは基本的にクラス・構造体のメンバとか配列、かつそれらが多用される場合ね
単発の一時変数をcharにしたところでそれがスタックに置かれたとしてもアライメントで何も節約できてないどころか
整数拡張のオーバヘッドで逆に非効率になる
引数にchar使うのも性能上は意味がない
組み込みマイコンなら特に逆アセは読めるようになった方がいいよ
ちょっと追加で調べて納得したのはcharを扱うメリットとしては
int ポインタ型に +1 した際、何バイト進むのかは処理系に依存するけど
char ポインタ型なら必ず１バイトだけ進むから
その場合においてメリットがあるからchar使えってことですかね？
>>61 別に逆汗しなくても汗吐かせればええやん
けっこう懇切丁寧にコメント入れてくれたりするぞ
デバッガでトレースしながら読むから逆アセだな
アセンブラ吐かせるってそれ用にビルド設定用意するのか？
泥縄で設定変えるのイヤだから
端っからアセンブラ経由にしてる
C++でUnicodeを扱いたいんですがライブラリを探したほうが良いですか？
なにか定番のライブラリありませんか？
>>68 返信遅くなってすみません
ICU把握しました、ありがとうございます
学術の巨大掲示板群 - アルファ・ラボ
http://x0000.net 数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など
simulationライブラリで純粋な関数式プログラミングをする
UIライブラリ (C#, 2D) を作ったよ
連続と離散を統一した！
4Dエンジン
matrixのライブラリ
ある強力なFor関数
SQLライブラリ
☆ VM + ASM を書いた (C#, DX) * x86 ではない!
http://up.x0000.net/files/TSimulang.zip ☆ malloc / free を実装してみた (C#)
http://up.x0000.net/files/TMallocTest.zip UDPで、メッセージをブロードキャストすると該当するコンピューターがユニキャストで応答するんですが、
このとき、シングルスレッドで、ブロッキングでsendでブロードキャストしてすぐにrecvで受信待ちするのは素敵ではないですよね?
UDP でもともとreliableでないですがsendとrecvの間にネットワークスタックが受信したりすると、recvで受信できない?
UDPはじめてなんですが、受信を先に立ち上げてから、sendすべきでしょうか?
○○で××で△△な□□ってオタクが好む文語でしょｗｗ
std::unordered_mapのキーをstd::stringにして
findで検索する時にstd::string_viewを使って検索したいんだけど、
error C2664 : 'std::string_view' から 'const _Kty &' へ変換できません。
と出てしまいます。
std::unordered_mapの場合ではどうすればいいでしょうか？(´・ω・`)
以下仮コード
std::unordered_map<std::string, int> a;
a.insert_or_assign("AAA", 10);
std::string_view b = "AAA";
std::unordered_map<std::string, int>::iterator it = a.find(b);
>>80 a.find(std::string(b));
>>81 あ・・・・・・(´・ω・`)
できました。ありがとうございます。
ついでに聞きたいのですが、
std::stringに変換することなくfind関数を使用するにはどうすればいいんでしょうか？
std::mapであれば、std::less<>を用いることでfind関数を使用した時std::string_viewでも検索できるようになりますが、
std::unordered_mapの場合はどのようにすればいいんでしょうか？
>>83 これは・・・・・・
C++20から使えるかも？ってことですかね？(´・ω・`)
std::unordered_map<const std::string, int> a;
今年学生でコロナ下でオンラインばかりなので合間を縫って独学に勤しんでます。
優しいc++を読み終えました
現在atcoderのabcやオライリーから出てるmodern c++ チャレンジ等をやっていますが、何をもってプログラミングが出来ると言うのでしょうか？
テトリス等もサイトを参考に書いたりしてみました。
自分はlinux上で動作する音楽プレイヤーソフトを作成したいと思うのですが、文法等はある程度理解していてもいざ自分で一から作れと言われると出来ません。c/c++で書かれているgithubのソースコード等は読めるんです
読めると言うのは、知らない文法やライブラリ等検索出来るためなんとなく実装内容がわかるって意味です
しかし自分で一からとなると何から始めればいいのか…
皆さんはこの壁をどう超えましたか？それとも壁に出会いませんでしたか？もしそれなりの規模の開発をする際止まった経験があるならばアドバイスを欲しいです
長文すみません
初心者は、Ruby on Rails で、web アプリのポートフォリオを作る
むしろ、コーディング・テストよりも、
アプリの設計・構築運用など、Linux の勉強の方が多い
文法・コーディングだけだと、ちょっとしたコマンドぐらいしか作れない
Rails みたいなフレームワークを使わないと、
データベースを含んだ、webアプリなどは作れない
>>87 linuxの統合開発環境がどんなのか知らんけど、とりあえず空のプロジェクトから作るのは出来るんでしょ？
そっから必要なものを一つずつ実装してくだけだよ
千里の道もうんたらで
>>87 > 何をもってプログラミングが出来ると言うのでしょうか？
何かを作るぞ！ と頑張って、目標を達成できること
「何か」はゲームでもいいしドローンの自動運転でもいいから
自分の好みで勝手に決めればいい
87は音楽プレイヤーだろ？
いきなり市販のプレイヤーに匹敵しなくてもいい
こんなことできないかな〜とアイディア先行で実験してみて
うまくいったら見栄えも気にして仕上げにかかる
てなことを小刻みに繰り返すとアジャイルっぽくなる
第二不完全性定理の制約を受けず、
停止性問題を解けること、
って無理ｹﾞｰじゃん？！？
なんで人間ってプログラミングできるの？！！？！
ユニバーサル文法があるから
その辺りは余り深く考えても意味が無い
出来るから出来る
出来ない奴は出来ない
ユニバーサル文法を操るメンタルオーガンが実在したとしても
そいつがたんなる機械なら解決にならないんじゃ…
>>87 まず作りたいものの機能をもった最も簡単なプログラム作ったら？
例えば音楽プレーヤーがお題なら音声ファイル名を与えると再生するだけのコマンド
あとは機能を付け足してく
>>87 強いて言えば
「バグ取りを自分で出来ること」
>>87 アプリ作り上げるのに言語の詳しい知識って実はあんまり要らないんだよね
c++だとtemplateにはまって一日つぶすとかざらにあるんだけど、
これってただの自己満だよな〜って思う
愚直なコードでとりあえず解決しておいて、その分
アプリとして作り込むのに時間かけた方がよかったんだろなーと
まぁそれはさておき、音楽プレーヤなら
- GUIフレームワーク
- CODECライブラリ
- linuxシステムコール、libc
あたりの知識がないと進められないでしょう
GUIフレームのお作法の理解とか、
CODECもフォーマット特有の制約が上位まで波及したりするから結構知識いるよね
まず何を使うかの選定からでしょう
あと、たぶんお前さんの作りたいものは既に世の中にごまんとあるはず
それを承知で勉強と割り切って作るのはいいんだけど、
あんまり大きいものは最初の目標にしないように
すぐに情熱失ってやめてしまうのがオチ
87のものです 皆さん有難うございます
再生させる機能やタグの取得等の割りかし簡単そうなものから実装していき
あわよくばイコライザーやスペクトラム等の機能も追加していこうと思います
あと、linuxだとuiや機能が優れた音楽プレイヤーって実は少ないんですよね…GitHub等でも探したのですが…foobar2000とかしかなくて正直ダサくて…
ないから自分で勉強がてら書いてみたいなと思った次第でした
>>87 〉何をもってプログラミングが出来ると言うのでしょうか？
他の人も似たようなこと言ってるけど、「ソフトを完成させる段取りを知っていること」が一つの目安。
実現機能を明確化して、実装する機能に分解して、必要なリソース・ライブラリを集めて、全部の機能を実装して、誤動作しないようにバグ取りをする。
これができれば言えるんじゃない？
少なくとも「プログラムするためには何が必要か」がわかるようになる。
>>96 ダウト
「こうしたい」と、せっかく閃いたアイディアを
表現力が足りないばかりに諦めたり
誰かさんみたいにtemplateがロクに使えなくて一日つぶすとかってのは
言語の詳しい知識が足りないことに他ならない
それを何やかんやと言い訳考えることこそ自己満以外の何物でもない
言語の基本をしっかり固めるのを軽視するとこうなるという典型だ
progress_displayいつになったら規格に取り込まれるんだ
＞誰かさんみたいにtemplateがロクに使えなくて一日つぶす
そんなこと一言も言ってなかったと思うが(俺96じゃないよ)
いつものアホが沸いたのかな？
というか他人が思ったことに対してダウト〜っていうセンスに痺れるわ
strcmp的なやつって笑える表現だな
a="templateにはまって一日つぶす";
b="templateがロクに使えなくて一日つぶす";
ここでstrcmp(a,b)が偽になる以上どういう意図のなのか説明が必要だろ
＞言語の基本をしっかり固める
とはまったく逆の事をしてることに気づけ
へーえ、おまえさんとこではstrcmp(a, b)がint(0)を返すのか
ユーザーがあまりにも馬鹿過ぎると標準ライブラリまでバグるとは知らんかったわ
strcmpてのは三値を返すんだから0が真で非０が偽
>>107 普通は零が偽、非零であればなんでも真、なんですけど
>>107 無茶苦茶言わないで、そこは「strcmp(a,b)==0が偽」の書き間違いだと認めるぐらいしようぜ。
strcmp を定義するのは言語仕様なんやから
あえて言語仕様と異なる用語を使うんなら
その適用範囲 (プロジェクト単位？) と共に定義を明文化するのは最低限の要求やろ。
当事者が合意した範囲内でなら一見して変な用語でも使うのは好きにすりゃええ。
たとえばハードウェアに近い部分なら負論理がソースコード上に露骨に現れることだって無いとは言いきれん。
ただそれは特殊な例を総合的に見てあえて奇妙な用語を使った方が良くなる場合にとる選択肢であって、
「三値を返すんだから」というようわからん理屈では正当化でけへんし、
言語のスレとしては許容でけへんわ。
個人的には整数のサイズにこだわるときは
#include <cstdint>
してint8_tとか使ってるなぁ
そもそも3値な時点でbooleanの真偽かどうか議論すること自体無意味
真偽値じゃないものを真偽値扱いしてもエラーとして検出されない、根が深い問題なんだよな。
型が無いB言語に末代まで祟られているとも。
整数の暗黙の型変換はそれなりに上手くいってると思うけど
bool が整数型扱いってのがいきすぎた一般化だったのかもな。
学術の巨大掲示板群 - アルファ・ラボ
http://x0000.net 数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など
VM + ASM を書いた (C#, DX) * x86 ではない!
simulationライブラリで純粋な関数式プログラミングをする
UIライブラリ (C#, 2D) を作ったよ
連続と離散を統一した！
4Dエンジン
matrixのライブラリ
ある強力なFor関数
SQLライブラリ
VM + ASM のダウンロード
http://up.x0000.net/files/TSimulang.zip 45歳こどおじ高卒無職歴約10年
10年以上前にIT系業界にいたが主にPC保守やユーザサポートをトータルしても10年くらい
コード開発の実務は30代の頃VB約3ヶ月でばっくれ
30代の頃エクセルVBA約3ヶ月でばっくれ
両方超ブラックだった
なんか疲れて実家帰ったらいつの間にか10年経ってた
暇なんで趣味で勉強してみた
2年前くらいに3ヶ月ほどjavaとpythonとc++
各言語のpaizaでC問題全部回答B問題10問くらい解けたからもうやってない
ガチで就職探したけど当然無くて諦めて勉強もやめてた
んでまた競プロサイトで練習始めたんだけど結局アルゴリズム意味不明で詰んだ感じ
暇なんで暇つぶしの惰性で練習してる感じ
こんなレベルで就職あるかな？
無職10年は適当にバイトしてたとかでごまかすコミュ力はあると自負してるつもり
こんな新人来られてもやっぱ迷惑だよね
てか俺が採用担当だったら絶対に採用しない
死んだほうが良いかな？
転生してやりなおしたい
if (!strcmp(a, b)) goto hell;
例えば、
x<1 || y>3
と書いた場合、人間なら、この < や > は、大小比較をする比較演算子だと
思うでしょうが、コンパイラにとっては、1 || y を実引数とするところの
template展開だと勘違いする可能性があります。
どうやってこれを区別しているのでしょうか？
どちらかというと
< <>, <> >
みたいなときに
<<>, <>>
って書くと期待通りに動かないのが面倒だと思う
x がtemplate名であるかどうかを検査するのでしょうか？
pure C で、構文ツリーを作りたいとき、出現してきた名前トークンがどう宣言されて
いるかを知らなくても、構文ツリーを作れてしまいます。
ところが、もし、xがtemplateの名前として宣言されているかどうかを知らなければ、
< が、比較演算なのが、template引き数の始まりを示す括弧なのかの区別が
付かないのであれば、そうはいかなくなります。
pure C の場合:
構文ツリーを作る ---> ツリーの中にある中の名前の宣言を調べ、種類を見る。
で済んだところが、C++の場合、下手すれば、
構文ツリーを作る際に、出現した名前の宣言も逐次、調べる。
ということになります。
その場合、トークンとしての'<'が比較演算子なのかテンプレートの括弧なのかは区別しないで
構文解釈の結果として文脈によって決定するのが常套手段だろうね。
https://github.com/antlr/grammars-v4/blob/master/cpp/CPP14.g4 >ところが、もし、xがtemplateの名前として宣言されているかどうかを知らなければ、
>< が、比較演算なのが、template引き数の始まりを示す括弧なのかの区別が
>付かないのであれば、そうはいかなくなります。
そうならない仕様にはしているはず。
どうしても区別がつかない部分は前にtemplateキーワードを置く必要があるとか。
>>126 >その場合、トークンとしての'<'が比較演算子なのかテンプレートの括弧なのかは区別しないで
>構文解釈の結果として文脈によって決定するのが常套手段だろうね。
ここは、x<・・・> の x がtemplate名かどうかを区別できるところの
意味解析の段階ではなく、本当に構文解析の段階ですか？
xがtemplate名かどうかは識別子の辞書を見たらﾜｶﾙ
辞書の中身はその時点までのソースコードの内容と
言語規格上の定義（形式言語ではなく、自然言語で書かれた仕様）に依存するから
言語の「意味」に依存するところがあるからこれを意味解析に含めるかどうかは議論の余地があるが、
普通のコンパイラ屋のマインドとしては
識別子の辞書を見てxが（例えば）template名であると判明したら
xがtemplate名xという「字句」であるという前提の下に字句解析した結果を文法パーサに入力するので
構文解析の範疇だと思われ
>>128 昔読んだコンパイラの本には、これまでに行われた宣言の情報を参照するのは、
意味解析だ、とあったと記憶しています。
逆に、それが意味解析でないのなら、何が意味解析になるのでしょうか。
「解析」ですから、コード生成では有りませんし。
それよか
std::vector<std::string>> x("Hello");
と書いたら
std::vector<std::string> > x("Hello");
とコンパイラに解釈させるという方がよっぽど凶悪
これこそ構文の意味を知らねば「>>」という単一の字句なのか、「>」という字句2個なのか
定まらないという意味で字句解析→文法解析の流れをぶち壊しにしてくれる
>>129 構文解析、でええやん？
>>130みたいな凶悪なケースと違って
辞書の参照、というただ1点のチートだけやれば、
BNFで形式的に完全に表せる世界に持ち込める
訂正orz
誤：
>>130みたいな凶悪なケース
正：
>>129みたいな凶悪なケース
訂正2、。n_
>>130 正：
std::vector<std::vector<std::string>> x("Hello");
と書いたら
std::vector<std::vector<std::string> > x("Hello");
とコンパイラに解釈させる方がよっぽど凶悪
>>131 C++の場合、辞書の参照も簡単では有りません。
namespaceや、クラススコープの名前などが複雑に絡み、
スコープ演算子を使った、修飾名などがあり、
Q1::Q2::Q3::name<xxx>
のような場合がありますが、
ややこしいのは、実際に template を展開してみないことには、nameがどういう識別子
なのかも分からない事があることです。例えば、
aaa<xxx>::bbb<yyyy>::name < 5, 5 > y
と有った場合、name が変数名なのか、template 名なのかによって、
< が template 引き数の始まりなのか、比較演算子なのかが決まる可能性があります。
ただ、この場合、> の後に名前トークン y が来ていますが、template展開だと
すると、この並びは恐らく、必ず間違いであるはずで、比較演算子でしか
合法にはならないと思います。
>>127 どのテンプレートが使われるかの判断は意味解析だろうけど、テンプレートの使用か
比較式かの区別は構文解析段階で確定するはずだがね。
で、両方に解釈できるケースは基本的に非templateとみなすことになっていて、そこで
テンプレートを使用したいならばtenplateキーワードを追加する。
>>136 >両方に解釈できるケースは基本的に非templateとみなすことになっていて、
それだと構文解析時のBNFの当てはめ時点でバックトラックしているように読めてしまうま、
そのような方式は、テンプレート定義が入れ子になったときバックトラック回数が指数関数的になりかねないから近畿
実際はそんなことはせずに、「name」というテンプレートの定義が辞書にあれば、「name」とかかれたソースコードの部分が
<テンプレート名>という字句として文法パーサに入力される、という方式で実現しており、
字句解析→文法解析、の一本道が保たれているはず（つまりは
>>128のやり方
>>134 辞書の参照が難しい、と仰せなのですが
識別子のスコープを辞書の階層化で表現するのは常套手段であってコンパイラの教科書にも書いてある
（と思う）のでそんなに難しい話とはみなすことはできない（希ガス
C++の文法は複雑すぎて構文解析と意味解析を分離できないのは有名な話
例によってBoostさんがそれを最大限に悪用してるのも有名な話
https://dechimal.hatenadiary.com/entry/20090216/1234793122 構造体へのファイル読み込みについて、悩んでいます。
今まで#pragma pack(x)を使用して、構造体にパディングが入らないようにしていたのですが、これ以外にパディングが入らないようにする方法はあるのでしょうか？
移植性の面からpragma禁止、かつ暗黙アラインメント禁止(自分でパディングを入れる)という指示がありました。
メンバ１つずつ個別に入出力
C++はそれがしやすい
エンディアン問題は１バイトずつ入出力することで解決できる
自分でパディングを入れる方が、明確。
解釈の余地がなくなるから
構造体へのファイル読み込みって、
構造体には、文字列のポインターがあるだけだろ
可変サイズの文字列の実メモリは、構造体内には確保しないだろ
そもそもの話の流れの趣旨とは無関係
struct hoge {
char mojiretsu[0];
} hage;
で malloc するときに
struct hoge *p = (struct hoge *)malloc(sizeof(struct hoge) + length + 1);
>>142 バイト単位で読み込んで自分でメンバーに格納
てか移植性云々なら入出力部分を切り出しとけよと思うが…
C++的には構造体の中の物理的な配置に依存しない設計をするのが本筋
ostream& operator << (ostream&, your_struct const&);
istream& operator >> (istream&, your_struct&);
ありがとうございます。とても参考になります。
パッと見て理解できないこともありますが、一つ一つ勉強します。
「入出力部分を切り出し」については、知識不足でイメージもできない状態なのですが、入社したらそうなっているのかも？と心構えというか、理解しておきたいと思います。
>>142 自分でパディングいれろ、という指示なんだから自分パディング入れればいいんでしょ？
方法は明確じゃん
まぁお前の質問の仕方が悪いってことね
まずやることはコンパイラのパディングのルールを確認してどういう条件で暗黙パディングが入るか理解すること
理解できたら自分でダミーのメンバ追加して暗黙パディングが入らないようにする
gcc/clangだったら-wpaddedで暗黙パディングが検出できるはず
念のためstatic_assertとoffsetofを使ってすべてのメンバーで期待通りのオフセットであること保証しておくといい
おまけでstatic_assertとsizeofで期待通りの構造体のサイズであることも
こういうのが多数あるんだったら、別途ツール使って構造体のソースは自動生成するようにすべき
あとpragma packは(レイアウトによって)実行時にオーバーヘッドが生じるってことも勉強しとくといい
すみません。質問を正しく説明できるように気をつけます。
私が質問したかったのは、「パディングの入れ方」ではなく、「そもそもパディングが入らないようにする方法はないだろうか」ということでした。
パディングの入れ方については既に理解しているのですが、入るとやや都合が悪い状況です。
「暗黙アラインメント禁止(自分でパディングを入れる)」と書いてしまったことで質問内容がブレてしまい、良くなかったと反省しております。
また、詳しくアドバイスをしていただきありがとうございます。
>>151 「そもそもパディングが入らない方法」がpragma packであって、それが禁止されてんでしょ？
言われた通りに明示的にパディング入れな
何か方法があったとしてもチーム開発しているときに、妙な小細工は嫌われる
「#pragmaは禁止」とあったので、そうだと判断しています。
もしこれが必ずしも#pragma pack(1)も禁止というわけではないなら、一度担当者に確認してみようと思います。
>>153 ありがとうございます。
そのようにしようと思います。
様々なアドバイスをいただき、私の考え方や疑問に思う部分が誤っていたと感じました。
これからはもっと広い視野で考えられるように頑張ります。
環境依存しない方法なんてないよ
int, short, longのバイト数すら環境依存なんだから
環境依存が嫌ならC++使うこと自体が間違い
#include <cstdint>知らなさそうだね
明示的にパディング入れる方がかえって小細工になったりして…
パディング前：
struct Foo {
int16_t m_someWord;
// ここに明示的にパディングを入れる
int32_t m_someDoubleWord;
int16_t GetSomeWord() const { return m_someWord; }
};
明示的パディング後(1)：
struct Foo {
int32_t m_someWordＩｎDWord; // 32 bit境界に隙間無くパディング入ったやたー！
int32_t m_someDoubleWord;
int16_t GetSomeWord() const { return (m_someWordInDoubleWord >> 16); } // OOPS! 欲しい16 bitの位置がホストのエンディアン次第で変わるorz
};
明示的パディング後(2)：
struct Foo {
uint8_t m_someWordＩｎBytes[4]; // 32 bit境界に隙間無くパディング入ったやたー！今度はしくじらないのですよ
int32_t m_someDoubleWord;
int16_t GetSomeWord() const { return ((uint16_t)m_someWordInBytes[1] << 16) | (uint16_t)m_someWordInBytes[0]; } // |||ＯＴＬ
};
逆だな。
C言語を使うといくらでも環境依存のものを作れそうな気持ちにさせる
環境非依存て聞こえはいいけど色んな機種の機能の積集合でできることだかんな
Unix文化とWindows文化の違いがあって、
Unixでは、OSよりもC言語によって、ハードウェアの違いを吸収する思想だった。
この思想では、バイナリ互換ではなく、ソース互換を目指し、
異なるOSやCPUに対しても、Cのソースを再コンパイルして対応しようとした。
一方、Windows文化では、最初から互換性のあるCPUを使うことが前提であり、
OSがCPU以外のハードウェアの違いを吸収することで、バイナリレベルで互換性を
維持する思想であった。
この思想では、異なるOSやCPUをターゲットにすることは想定されていない変わりに、
ハードウェアの違いは、互換性のある(単一の)OSをハードウェアに乗せることに
よって吸収しようとした。
なので、GNUやgccなど、Unix文化からきたプログラムでは、徹底的に#ifなどで
場合分けして互換性を維持しようとしているのに対し、Windowsから来たプログラム
ではそのような場合分けはしていない。
また、Unix文化でも、#if によってソースを場合分けすることで対応していることが
ほとんどで、何の場合分けも無いソースで対応できている訳ではない。
C++を検索するときの技で上手い方法ありますか？
ググる、アマゾン、図書館での検索など
勉強しようとしても検索できないです
コンパイラーのエラー文で投げたら大抵その言語で釣れると思うけどなぁ
ぐぐるときは
hoge -ruby -java -javascript -php -sejuku -techacademy -teratail
>>166 検索して出てきた情報を理解するための基礎的な力が無いんじゃね？
ググれば何でも即解決できるわけではないよ
愚直にC++の入門書を買って順を追って系統立てて、C++の基本的な概念や用語を理解していく必要がありそう
もしかすると、C++より前に他の言語でそれをやってプログラミングの基本的なところから土台を踏み固めておかないとダメかも
「勉強」がどのレベルなのか分からないとなんとも言えない
直感で言うとC++の入門書なんでもいいから一冊買ってやりなさい
>>166 俺も
>>170 に同意だわ。
基礎的な考え方が身に付いてないと個別の説明を見ても意味わからん。
検索するにしたって検索に適当な語句を選択するだけの知識は要るしな。
用語は大事。
概念を分割して定義を積み重ねるのが体系化だし、
定義は用語の定義として現れることが多い。
用語がわかると色々わかる。
「C++」で検索ができないんだが
PCの設定がダメなのかな
これから情報を得るために検索くらいしたいんだけど
本買いたくても出てこない
図書館へは行ったけどC++は貸出中で予約も数件入ってるらしい
+のフォントが変なのか？
>>173 俺の手元だと、グーグルでもアマゾンでも C++ で検索できてるがなぁ……。
ダブルクォートで囲って "C++" にしたらより確実に C++ が含まれるページが検索される。
twitter は、C++ や C# を検索できない。"C++" や "C#" としても駄目。
なので、cpp OR cplusplus とすると良いと言われているが、
個人的には、これは、twitter を作った人の C++ や C# を弱まらせるための策略
だと思っている。
アメリカはそういう国で、
彼らは、自分のためなら何をやっても文句は言わせない的な心持でいる。
>>176 ありがと
cplusplusで検索できました
何故かyahooでリアルタイム検索ではC++で検索できる
シープラプラとか
チンチンブラブラみたいな名前付けやがって
たぬき砲でいいよなもう
Cよりもちょっと背伸びした意識高い系狙ってみましたみたいなキモいネーミングセンス
>>183 ちょっとどころじゃねーよ馬鹿
お前みたいな低能にはC++は無理
CRTP(奇妙に再帰したテンプレートパターン)ってどんなときに使うの？
template <class Derived>
struct Base {
static void interface() {
...
Derived::static_interface();
...
}
};
struct Hoge : Base<Hoge> {
static void static_interface() { ... }
};
通常の継承とは依存関係が逆になってるというのはわかるけど
具体的にどんなケースで便利なのかいまいちピンとこない．．．
速度重視のときじゃないかな。
ATL/WTLがCRTP使ってると思ったけど。
メリットとデメリットを比べるとデメリットが上回ってるような気がするな。
ぼくは構文解析器の合成にCRTPを使いましたが、合成の頻度が非常に少ないので、使った感じです。
仮想関数の代わりにCRTPを使うと呼び出しコストが無くなる・・・的な使い方で、便利にはならないと思う。
というより、めんどくさくなるだけ。
なるほどどうしてもパフォーマンスが気になるときに使うものって感じですかね
というより、動的な多態は不要だが静的な多態が必要で、
かつ派生クラスの型情報がどうしても必要なときに使うもんだと思う
クラステンプレートであれこれやってるうちに必要な場面が出てくるかと
学術の巨大掲示板群 - アルファ・ラボ
http://x0000.net 数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など
VM + ASM を書いた (C#, DX) * x86 ではない!
simulationライブラリで純粋な関数式プログラミングをする
UIライブラリ (C#, 2D) を作ったよ
連続と離散を統一した！
4Dエンジン
matrixのライブラリ
ある強力なFor関数
SQLライブラリ
VM + ASM のダウンロード
http://up.x0000.net/files/TSimulang.zip 派生クラスの型情報を静的に使うというのはstatic_castでのダウンキャストだな
Derivedを引数にとる比較演算子を生成するみたいなことは継承だと無理そう。
基底と言いつつテンプレートでガッツリ派生型の名前が入ってるわけで
他の派生型を持つ基底を一括してコンテナに入れるとかできないしあまり意味を感じないな
そもそもポリモ目的でやるもんじゃないでしょ
基底クラスは結局全部別モンになるわけだし
ボイラープレートコードをまとめたクラスをミックスインするときに使うもの
>>195 basic_iosとios_baseみたいにテンプレート化する必要のある部分と不要な部分に分けるとか
関数へのポインタが、メンバ変数に有る場合、例えば、
class CXxx {
public:
void (*pfn)(int a);
void (*pfn)(float b);
};
の様な場合、
pXxx->pfn(5);
pXxx->pfn(10.0f);
とした場合に、関数呼び出しに使われる関数ポインタが自動的に選択されるでしょうか？
つまり、関数ポインタについても、関数と同様な「オーバーロード解決」が行われますか？
そもそも、上の様なクラスは、定義時にエラーになるでしょうか？
同じ名前のデータメンバーをふたつ定義してるからアウト
ここに質問するより少ない手数で試せるだろうに何やってんだろうね
>>198 関数は多重定義できるが
関数へのポインタは多重定義できない
ちかっとエスパーすると
class CXxx_base {
public:
virtual void fn(int) = 0;
virtual void fn(float) = 0;
};
class CXxx : public CXxx_base {
public:
void fn(int) override { }
void fn(float) override { }
};
pXxx->fn(5);
pXxx->fn(1.0.f);
これでおまえさんの考えてることはできるんじゃないか？
>>198 机上の空論持ってくるな
きちんと検証してから持ってこい
関数へのポインタって関数じゃなくてただのメンバ変数だからな
>>196 >ボイラープレートコードをまとめたクラスをミックスインするときに使うもの
ちょっとかっこいい(型情報ある)マクロみたいな感じか
構造体を使った配列の記憶にて
配列に順に入力しても出力が上手くいきません助けて偉い人
void dataInput(Student& st){
string ans;
for(int i=1, i<=n;i++){
cin>>st.id;
pN[i]=st.id;
cin>>st.ans;
pA[i]=st.ans;
}
};
void showData(Student& st);
int main(){
cin>>n;
pN = new int[n];
pA = new int[n];
Student st;
dataInput(st);
showData(st);
return 0;
}
void showData(Student& st){
for(int j=0; j<=n; j++){
cout << pN[j] << pA[j] << "\n";
}
}
定義はファイル別にしてある
正直すまんかった
hファイルの方
struct Student{
int id;
char ans;
};
int n;
int* pN;
char* pA;
cppファイル冒頭
#include <iostream>
#include <string>
#include "funk.h"
using namespace std;
デバッグしたけど問題は見つかりませんでしたと出た。出力に問題があるっぽい
自己解決しました！iとjの初期値を1から0にしたら解決できました。
自己解決しました！iとjの初期値を1から0にしたら解決できました。
きちんと検証しろ
ソレができないなら初心者スレか日記帳にでも書いとけ
githubなりに落ちてるc++で書かれたアプリなりを読んで勉強しているんだけど、
include無限ループに陥って萎えてしまうのですが、どうしてますか？
mainのinclude沢山→その指定先にもinclude沢山→stlなりのライブラリ(ここは読まずネットでドキュメント読む)
で相当時間食ってしまうまのですけど、コツとかありますか？
ていうかなぜ初学者なのにいきなりそんな重厚長大なアプリからチャレンジしようとするのか
自分の力量を過大評価しているのではないか
まずヘローワールドとかそういう簡単なとこからはじめなさい
コンパイル時にg++とかなら-Eオプションつければ
実際のプリプロセッサの処理の結果が確認できる
読まなきゃいいじゃん
何のために全部読もうとしているのか自問自答したら？
>>223 身の丈に合わない巨大なプロジェクトを読もうとしてるか、または愚直に頭から全部読もうとしてないか？
お前さん自身がコンパイラじゃないんだから、頭からすべて把握して読んでいく必要はないぞ。
まともなソースならオブジェクト指向で書かれてるのだから、上位層で大筋を把握しながら必要に応じて深いところに入っていって、有用そうな所や興味があるところだけ詳しく読めば？
ヘッダファイルは使ってるライブラリとかの当たりをつける程度でざっと読み飛ばして、定義を調べたくなったときにIDEの機能で見に行けばいいだろう。
吊りかも知れないが勉強中とのことなので
マジレスすると
#include の行を一つづつ消してみて(mainに近い方だけ)
消したらどんなコンパイルエラー出るかを観察する
>>228 sshのソース読んでも全くオブジェクト指向じゃないぞ。
あらゆるところで参照したいヘッダファイル↓があるとして
./include/common/hoge.hpp
詳細な実装（深い階層にいるやつ）
./include/hage/chibi/debu/unko.hpp
からそれを読み込むときって
#include "../../../../common/hoge.hpp"
みたいにしてしまっているのですが、もっとまともなやり方はありますか？
なぜSTLは
#include <vector>
などで読み込めるのでしょうか
不思議ですねぇ
./include/common
をインクルードパスに含めるのは思いついた上で微妙な気がしたから
聞いてます
./include/hage/chibi/
配下ではどこからでも見れるようにするとかしたいときはそこの
CMakeLists.txtにインクルードパス指定する
とかしかないんですかね
インクルードガード標準搭載の言語多いのに
ほんと無駄な時間使わせてる言語なんだなって再確認できて辛い
>>237 マクロによるインクルードガードなんて決まりきった定型文だし、正直 #pragma に載せる必要もないかと…
まあね、GUIDなら衝突の確率340澗分の１だかんな
それすらも衝突したらどうすんだと・・・ほとんど病気だねｗ
>まとも〜とか微妙〜とか
なんとも思わねえよばあか
そっか君プログラマ向いてないね
知らなくて驚くかもしれないけどコンピュータには感覚じゃなくて理屈しか通じないんだよ
>>237 C++20 にはモジュールが入ったから……。
誰がプログラマって言ったよ？
理屈しか通じないんだろ？
頭悪そう
is_integralみたいな型判定をメタ関数に渡すとこを書いてて思ったんだが
変数テンプレートをテンプレート・テンプレートパラメータとして渡せるようにはなってないんだよなぁ
ということは、と思ってコンセプトの予定されてる内容調べたら、コンセプトも同様なんだな・・残念
C++でもNPMみたいなパッケージマネージャ使いたい
ヘッダと実装別で書かなきゃいけないのも無駄
このへん解決したAlterC++みたいなの作って
>>246 ヘッダファイルを実装とは別に用意する仕組みは効率よく差分ビルドするための仕組みとして機能していたんだけど、
テンプレートが登場してからは足を引っ張るようになってるとは思う。
まあ単純に面倒くさいってのもわかる。
パッケージマネージャはディストリビューションに乗ってるものを使いたまえよ。
実行環境の管理と開発環境の管理は要求されるものが本来は違うのだけど、
C/C++ は特権階級的な立場だから実行環境を開発環境として使えるようになってることが多い。
あえて分離したいなら CONAN が有名かなぁ……。 使ったことないけど。
https://conan.io/ >実行環境を開発環境として使えるようになってることが多い
これは古い慣習でそうなってるだけで実は分けたほうが便利な気がする
システム汚さないし、依存関係の解決も楽
そもそも実行環境に不要なはずのものがいることがおかしい
ConanもC++20のModuleも良さそうだけど結局バベルの塔だからなぁ
>>249 俺も同意見
開発環境、それとテスト環境もVMwareのゲストにしてる
おっかない実験もするし
>>249-250 それは重々承知なんだけど C/C++ では分ける体制になってないから
無理して分けるとそれはそれで変になるって話。
>>252 ＞それは重々承知なんだけど C/C++ では分ける体制になってないから
そうか？
はちみつはそういう経験無いだけだろ
VCでだってクロスプラットフォームは可能だぞ
C/C++はコンパイラメーカーがローダーを用意していない。
これに尽きる。
最近は何でもdockerに突っ込んでいる。
vscode + remote containerで開発環境の構築も楽になったし。
C++ moduleってテンプレート使ったクラスをモジュール化したとき
プリコンパイルヘッダと原理的に同じで機械語じゃなくて中間表現に
変換されるらしいんだけど、これってコンパイル速度が大幅に改善することはない
ってことだよね？
よく考えたインクルードでpch併用してるプロジェクトなら、普段のビルド大して変わらんかもだけど
pchが依存するヘッダを書き換えた場合のフルビルドみたいなのは避けやすくなるぽい？？
プリコンパイルヘッダを試しに生成するのと
普通にコンパイルするのと試したら２割程度しか時間短縮できなかった
>>260 二割はでかいやろ。
>>258 従来からもたとえば gcc で LTO を有効にしたときは中間表現で持っておいて
リンク時に最適化とコード生成をやったりはする。
それと同程度のコンパイル速度だろうと考えると
モジュールの導入は速度にはそれほど寄与しないと思う。
うーん まぁチリツモと考えるとでかいか
夢見過ぎだったか
>>262 ジョジョ、それは高速化しようとするからだよ。
逆に考えるんだ、『もう十分に速い』と考えるんだ。
質問ですが
double x = 0.3333;
printf("x=%f\n", x); // 期待する表示: x=0.3333
みたいなBCD風表記→IEEE 754→再びBCD風表記
としたときに、元の表記と結果の表記が一致することは
保証されてますん？
>>264 保証されない。
0.3333 は浮動小数点で正確に表現することは出来ないので誤差は生じる。
誤差があるところから再び十進数の表現にするんだから
元と同じ表現になることは期待できない。
ちょっソ───スコ───ドに0.3333と書いたのに
0.33331とかに解釈になったらスゲーまずくね？？
さすがにもう少し精度が高くて、doubleなら
0.3333000000000001 くらいの誤差じゃない？(適当)
何がしたいのかというと実行時計算ができる有理数クラスを書いたんじゃが
ソース値がソースコードに浮動小数点で書かれていた場合は当たり障りのない有理数にしたいわけで、
たとえば
Rational x = 0.11;
と書けば済むところはそのまんま
x.m_num == 11LL // 分子
x.m_den == 100LL // 分母
とかになってﾎｽｲ
（必ずいちいちRational x = Rational(11, 100);と書かなければならないことはユーザー（≒漏れ自身）に強制したくない
つかソースコードに書かれた浮動小数点数を文字列化して元に戻せることの重要性を
書いたコンパイラの教科書はマイナーかもしれんが実在したで（記憶モード
そのやり方こそ今思い出すべきなのだが手元に無いから質問すた、
>>274 やだ
数値的にやるとしたらここ↓のalmost_equal<T>()でも使ってゴニョれば良いんかのう…
https://en.cppreference.com/w/cpp/types/numeric_limits/epsilon しかし件の本にはこれと似たような演算を書いてあったような気がしないOTL
>>273 浮動小数ならやり方ははっきりしてんだよ
お前の場合BCDなんだろ？
>>276 そのRationalクラスが多倍長とかだったら無理だね
64bit/64bitでも無理だろ、たぶん
>>278 しらそん
桁の十分不十分は応用にもよるし
足りないとわかったらRationalの方を多数桁対応させるは
とにかくRationalは見かけをdouble型と同様に扱えるように仕上げ鯛、
なぜなら真に走らせたいアルゴリズムはdoubleをtypedefして作ってあって、
それをRationalに差し替えるだけ！と思ってたら
単体テストが10億行ぐらい浮動小数点で書いてあったので…
それはわかったけど
>>264 は必要？
別にいらんと思うけど
char配列に変換して8バイト読み書きするだけのこと
文字列に変換することは忘れろ
そもそも0と0.0を区別する方法がないのにどこまで意味のある事なのか
> （必ずいちいちRational x = Rational(11, 100);と書かなければならないことはユーザー（≒漏れ自身）に強制したくない
無理だろ
Rational x = 0.1;
こんなの、どうすんだよ？
double型の0.1は1/10じゃねえぞ
denが必ず10のべき、みたいなことにして
誤差が最小になるように頑張るならともかく
>>272 Rational x = "0.11"; を許せばいい
>>279 仮にテストコードに 0.333333333333333 って書いてあったとしても
それは 0.3333333333333329818 のことだから、
0.333333333333333として受け取ってしまうと逆にテストに失敗するのでは？
10億行ぐらい既存テストコードがあるとのことなので文字列とか全面書き換えになる案はNGなんでしょう
でもいい案はなさげ
一旦浮動小数になったら元のリテラルの復元はできないだろうな
>文字列とか全面書き換え
Rational にする書き換えはOKなんだろ
そりゃクラスの差し替えは局所的な置き換えで済むんじゃないの
浮動小数のリテラルを全部文字列に置き換えることに比べたら楽でしょ
まぁ本人が答えるべきだが状況はなんとなく推測できる
そのくらい正規表現で置換すればいいだろ。
だいたい10億行のテストコードが仮に本当なら100%手書きじゃないから一つずつ確認しながら置換するなんてアホなことはしない。
有理数クラスなんて普通は枯れたライブラリ拾って来るけどな
だからさ、そこは本人の希望なんだからあれこれ言ってもしかたないじゃん
正規表現で機械的に置き換えたらまずいものもあるかもしれないし
浮動小数と有理数で切り替えたいって言ってるからそのメンテコストもあるだろ
ユーザー定義リテラルとか使ってboost::rationalでも生成したら？
やったことないからできるか知らんが。
何にせよdoubleになった時点でリテラル表記の情報は失われるんだから、何がしかの書き換えをするしかない
それがイヤだ絶対やらんと言うなら、じゃあ不可能だよという答えにしかならない
Rational に double の数値が直代入されてるところだけ文字列代入にするための
プリプロセッサ描けば良い話
結論から言うと、
IEEE 754の値x → 10進数文字列 s→ IEEE 754の値x'
という変換を行った場合、x == x'となるかどうかはx次第であって一般に保証されないが、
10進数文字列s → IEEE 754の値x → 10進数文字列s'
という変換は、sが非正規化数だったりIEEE 754の仮数部で表現可能な桁数を超えない限り -- (1)
s == s'を保証可能
なぜなら、(1)の条件を満たすsとそのIEEE 754への変換結果xの食い違う条件は
sを2進数に変換したとき循環小数になる場合に限られるが（もとの10進数のsはもちろん循環小数ではない
この食い違いは±DBL_MINを超えないから以下略
（結局x→s'変換はalmost_equal<T>()的な処理が必要にはなるが、適切にやれば
sの整数部の文字列化 ==> x -= (xの整数部) ==> x *= 10、
の反復を何時やめればよいか確定する
>>294 やだという理由は
>>279の後半部で言い尽くされとる
sagemathで
a=0.11
QQ(a)
とすると
11/100
が得られる
aの実体はMPFRのオブジェクト
まーsagemathのソースでも見とけば
>>297 その前にリテラル表現→double値（お前が言うところのIEEE754の値）
という変換が入って、それが不可逆だから書き換えなしじゃ無理だっつってんだよ
Hoge(0.0)とHoge(0.00)に表現に応じた別の処理させるのはC++の範囲では不可能だ
ああ、#で文字列化できるからこの場合はできるのか忘れてた
まあ対象の浮動小数を全部マクロで括らないといけないからどっちみち書き換えは発生するけどな
ん？シンボルを文字列化する#演算子はプリプロセッサディレクティブの一つだぞ
何か間違ってるか？
絡んでくるだけで具体的な問題を指摘できないカスは置いといて
プリプロセッサフェーズの後で0.0と0.00を区別する方法はないから279君の望みは叶わないでFA
プリプロでもdouble x = 0.00;とかを自動で書き換えるの無理でしょ
>>299 有理数の分母が10の冪という前提ならある程度の精度で出来そうだな。
分母仮定せずに普通にディオファントス近似した方が誤差小さくなると思うんだけど
10進リテラルで渡す前提なら分母が10の冪になってしまったら逆に誤差が大きいことになると思うが。
＃約分とかは別として。
まぁ、1.0/3.0みたいなものも渡せるようにということなら確かにそうかも。
とりあえずここまではできた；；
x=0.1: rt=1/10
x=0.11: rt=11/100
x=0.111: rt=111/1000
x=0.1111: rt=1111/10000
x=0.9: rt=9/10
x=0.99: rt=99/100
x=0.999: rt=999/1000
x=0.9999: rt=9999/10000
x=0.33333: rt=33333/100000
x=123.34567: rt=1233456699999999/10000000000000 // NG
x=123.345678: rt=123345678/1000000
x=123.3456789: rt=1233456788999999/10000000000000 // NG
x=12.34567: rt=1234567/100000
x=12: rt=12/1
x=123E-5: rt=123/100000
わかったことは、
10進数文字列s → IEEE 754の値x → 10進数文字列s'
において、s→xのところで仮数部最小桁で丸めがおきたのかどうかの情報が無いと
xからsの復元が難しいケースがあるというこっちゃorz
コンパイラならs→xをやるのは自分自身なので、x→s'を行うライブラリと手を握ってうまいことやれる可能性があるが
xを与えられるだけのユーザープログラムではこれは対処が難しい
Ad-hocに.999999 = 1とみなす系のAd-hocな処置が必要かも試練、
だからさ
例えばそれでrt=1233456699999999/10000000000000になったとして
どうやって元の表現が123.34567だったって判断するのさ
本当に123.345699999999って書かれてた場合と区別できるわけないんだけどどうするの？
123.34567を123.345699999999に間違えるのはダメだけど逆は許されるの？どうして？どういう仮定置いてるの？
その辺を何一つハッキリさせないまま勝手にやられても
何がしたいのか全くわからない
まぁそんな追い込まんでも
自分で手を動かしてダメっぽいことい気づいたのは立派だよ
>>314 そのことを言ってるんだろ、
>>313の丸め情報が必要ってのは
>>314 >本当に123.345699999999って書かれてた場合と区別できるわけない
思い込みが激しいお人じゃ…
123.345699999999はギリ仮数部で表現可能な桁数に収まっているから
これは123.34569とは明確に区別可能
ていうか実際のところできたわ；；
x=0.1: rt=1/10
x=0.11: rt=11/100
x=0.111: rt=111/1000
x=0.1111: rt=1111/10000
x=0.9: rt=9/10
x=0.99: rt=99/100
x=0.999: rt=999/1000
x=0.9999: rt=9999/10000
x=0.33333: rt=33333/100000
x=123.34567: rt=12334567/100000
x=123.345678: rt=123345678/1000000
x=123.3456789: rt=1233456789/10000000
x=123.345699999999: rt=123345699999999/1000000000000
x=12.34567: rt=1234567/100000
x=12: rt=12/1
x=123E-5: rt=123/100000
そりゃ0.00002も差があれば区別できるに決まってるわな
いやまあ自分が書き間違えたのが悪いんだけど結局何が問題だか全く理解してないのね
>>318 何が問題なのかではkwsk
ｗｗｗｗｗｗｗｗｗｗｗ
0.500000000000000166533453693773481063544750213623046875
これできる？
別のリテラル表現が同じdouble値(IEEE754の値)を示す時に何をもって正しいとするかという
お前の勝手な俺様基準を何も説明しないまま公衆の面前でガチャガチャやってることが問題なんだよ
わかれ
>>321 >>272を嫁、
気体動作は明確はなず
これを読んでもわからず妥当な反論ができもしないというのであれば
読み手のセンスの問題と判断せざるおえない
>>320 >>297を嫁、
提示されたテストケースは(1)を満たしていないから範囲外
いやいやそれでどやられてもw
> 10進数文字列s → IEEE 754の値x → 10進数文字列s'
> という変換は、sが非正規化数だったりIEEE 754の仮数部で表現可能な桁数を超えない限り -- (1)
> s == s'を保証可能
仮数部で表現可能かどうかってどうやって判定するわけ？
うれしげにコード貼る、
https://ideone.com/EKHKWG 実行結果は
>>317と同じ
>>313の問題があるから
0.999999（9の循環小数）を1.0と見なす処置を入れた結果、考えていたテストケースは全部通った。
結局、
10進数文字列s → IEEE 754の値x → 10進数文字列s'
でs'が厳密なsの復元にならないケースがあるはずだがまだ見つかっていない。
ま、あったとしても有理数として解釈する上では数値としての大差は無いので問題ないはず、、、
>>323 入力となる浮動小数点数を文字列として書いた時点でﾜｶﾙ
52 bitでまったく表現しきれない桁数なら(1)を満たさない
そうでなく、かつ（xE+s表記で与えたとして）指数sが極端に小さくなければ（xの桁数+sが-1022以上なら）(1)を満たす
>>325 なんだ、仮数部で表現可能かのチェックのために結局20億行テストコードを文字列として解析する必要があるわけね
じゃあその時に文字列として扱うようにコード直せよ
どうせそういうスクリプトが必要なんだからついでにやればいいね、よかったこれで解決だ
あほくさ
>>325 は？書く？
10億行のテストコードあんだろ？
それが(1)を満たすかどうか確認する必要があるんだろ？
だいたい仮数におさまってたら大丈夫ってそりゃそうだろよ
誤差が問題なのにそれを考えなくていいケースなんだもの
>>326 >なんだ、仮数部で表現可能かのチェックのために結局20億行テストコードを文字列として解析する必要があるわけね
なんでそうなる必要があるのかkwsk、
10億行のテストコードは手入力なので52 bitで表現できないような桁数の数値は無いし、
とまれそこまで認識が進んだのであれば、あと何か言いたければ
>>324のバグ探しでもしてちょんまげ
看板に偽りありを示すテストケースを指摘してくれたら大金星と言える
>ま、あったとしても有理数として解釈する上では数値としての大差は無いので問題ないはず、、、
ならRationalなんていらないね(´・ω・｀)
>>328 はあ？なんだそれ？
全部お前に都合がいいリテラルしか書いてない前提なんだったら、お前がさっきから書き散らかしてる落書きなんも必要ねえじゃん
話にならんわ下らねえ
>>330 単体テストというのは真に走らせたいアルゴリズム（
>>279）の単体テストのことであって、
別段IEEE 754から有理数への変換のエッジケースを書く必要は無いんである。
問題の所在自体を（よく読みもせずに）つついても無駄じゃよ
それよか何か言いたいのであれば
>>324をデバッグ汁、
あっはいどうでもいいです
(仮数部)/2^52に一番近い10^nを分母とする分数を探す簡単なさんすうの問題を解くだけの話だったんですね
がんばって
手入力だから大丈夫ってのはお前しか判断できないよね？
成り立たない数字あげてもそれは手入力しないと言われるわけでしょ？
おれもあほくさくなった
俺ぐらいの達人になると、もう初期段階で
「あ、これさわったらアカン人や・・」って雰囲気でわかるようになる
10億行手入力したとか言い放つキチガイ相手にするの馬鹿らしくない？
1行/秒でも1700人月よ
浮動小数点型としてメモリに載せた時点でアウト
文字列とかでやるしかなくね
単に誤差最小のものを選ぶだけだと
>>314みたいになるから、1ULPか2ULPの誤差範囲内で
冪数が最小になるものを選ぶのがいいかな。
連分数展開でディオファントス近似する方法なんてその辺にいくらでも転がってるのに
./hello > hello.txt
ってやったときhelloのprintfが無限ループだったら無限にhello.txtを上書きし続けますか？
>>340 上書きなんてしないよ
どんどんprintfの出力内容を追加していくだけ
./hello < hello.txt > hello.txt
Pythonで書いたGUIアプリをC++で書き直す日々が始まるお(*´ω｀*)
イテレータを i 個分進める (戻す) のって i 回インクリメント (デクリメント) するしかないの？
一気に進める方法があったら教えて下さい
ああvectorならできてsetなら無理ってことか
ググったらわかりました
すみませんでした
>>340 わざとやってみたことあるけど
途中で飽きてきてCtrl+C
うすらでかいファイルができていた
ずーっと放置するとHDDの空き容量がなくなって
stdoutへの書き込みが失敗するようになるはず
それがOSのファイルにも使うドライブだとシステムダウンして
親ガメこけたら皆こけただね
>>346 つstd::next
自分で増分するのに比べて早くはならないと思う
typedef struct HOGE
{
int x;
int y;
HOGE(int x, int y)
{
this->x = x;
this->y = y;
}
} hoge_t;
class TEST {
hoge_t h(1, 2); // expected identifier before numeric constant
}
で、// のとおりエラーが出てしまいます。
typedef struct と class の違いが理解できていないのが悪いのですが
メンバ変数として利用するとき初期化は出来ないのでしょうか。
>>351 丸括弧じゃなくブレースだよ
それとTESTの最後にセミコロンがない
>>351 初歩の初歩でつまづいとるな
クラスの直下にプロセスを書けるとでも思っているところとか初心者スレ逝けばやさしいひとたちが教えてくれるぞこわっぱ
ブーメラン投げてんなよ
C++11からokになったの知らねえとか
勉強不足にも程があるだろうが
あっそっか
コレ、メンバの初期化してんのか
てっきり文かいてんのかとおもたわ
スマンスマン
>>351 それは、恐らく昔のC++では動かなかったような非常にきわどい書き方をしている。
1. まず、クラス名をtypedef宣言しても、それをどの場所でもクラス名の変わりに
使えるかどうかは、微妙。余り行われていないことで、よく調べてみないと分からない。
特に、この例の様なコンストラクタによる初期化を伴う変数の宣言の場合には、
当たり前のように出来るように見えて、コンパイラ作者目線では解析に負担がかかること。
2. static以外のメンバ変数(インスタンス変数)を、クラス宣言の中で直接初期化する
書き方は、あるバージョン以降のC++でのみできるようになってきたはずで、
その書き方に対応していないコンパイラだとエラーになる。
>>357 1に関して。
まず、typedef宣言自体が、ポインタや配列や関数型などが複雑に絡んだ
「組み立て型」を簡単に表すためと、
C言語では、構造体型をそのまま型名として使うことができず、typedefを
使わなければ、「struct タグ名」とstructを省略できなかったので、
typedefが好んで使われた。
ところが、C++では、structやclassキーワードを書かなくても、いきなり
タグ名を書いても型名として扱われる。だから、class名/struct名を敢えて
typedef宣言する人は非常に少なくなった。なので、そのような書き方に
滅多に遭遇しないので、テスト不十分でコンパイラにバグが残っている可能性がある。
>>358 メンバ関数を含まない struct (つまりは POD) なら、
C のヘッダファイルとしても使えるように書く場合は珍しくもないと思うよ。
コンパイラのバグを心配し始めたらなんもできなくない？
主要なコンパイラでよほど長く改善できてないバグだったり、
(特殊な開発環境などで) 実際に使わざるを得ない特定のバージョンにバグがある
ことが分かっているときなら配慮もするけど、
普段の習慣として気にするほどのことじゃないでしょ。
hoge_t h = {1, 2};
で普通にコンパイル通るんだが
class TEST のインスタンスが造られる度に実行されるのか
それともあるインスタンスで変更されたら
次に造られるインスタンスは後者の値になるのか
>>360 TEST 型のオブジェクトが生成されるたびに h も生成されるよ。
TEST のコンストラクタで初期化するのと機能はなんも変わらん。
実は、
z x(a,b);
の形式は、コンパイラが関数xのプロトタイプ宣言と、引数付きのコンストラクタ
呼び出しによる変数xの初期化の区別を付けるのが難しい例として知られている。
その区別は、基本的にはaの部分が型名なのか、型名でないのかで区別される。
それに加えて、zの部分にtypedef名を書くと、コンパイラはいろいろなことを配慮
しなくてはならなくなる。
関数のプロトタイプ宣言と、メンバ変数の定義では、コンパイルの流れが大きく変わるので、
なるべく早い段階でそれらを区別しなければならない。
余り深く解析しすぎてはコンパイル時間が増大してしまう。
だから、適度にヒューリスティックな方法で判別していることがある。
ヒューリスティックな方法なので、滅多に書かない特殊な書き方をした場合、間違えてしまう可能性があるかもしれない。
なんでここってそんな殺伐と喧嘩腰みたいなやつ多いの？
もっと柔らかくさ切磋琢磨してこうよ
class TEST {
hoge_t h;
TEST() : h{1, 2} {}
};
のほうがわかりやすくね
class TEST {
hoge_t h;
TEST() : h{1, 2} {}
};
のほうがわかりやすくね
うおダブルクリックしちゃった
てかJavaScriptで防止しとけよｗ
コードを書くとききは、最低限簡単なテストコードで
コンパイルが通るかどうか確認してから書きなさい
技術系ブログですらそのルール守ってない事があり
そういうブログはたいてい読むに値しない
>>351 #include <iostream>
using namespace std;
struct Hoge{
int x;
int y;
Hoge(int x, int y){
this->x = x;
this->y = y;
}
};
int main() {
Hoge h(1, 2);
cout << h.x << endl;
return 0;
}
GVkKul - Online C++0x Compiler & Debugging Tool - Ideone.com
https://ideone.com/GVkKul 余り深く考えないならこんなんでいいんじゃなかろうか
explicit Hoge(int x, int y)
にしろと言う派もいそう
こうですか？
わかりません＞＜；
■ 小数を含む10進数の表記の再現に関する定理
有限桁の10進数で表記された非負の数x0をIEEE 754形式（2進数版）に変換して
xを得たとして、x0の最小の桁が10^mの位、xの仮数部のLSBが2^pの位ならば、
m > p * log10(2)
を満たす限り、xからx0の最小の桁まで正確に再現できる。
■ 証明
x0の最小の桁が10^mの位（10^mより小さい位が無い）ということは、
x0は周期10^mの格子点上にある。（kを適当な整数として、x0=k*10^mと表すことができる。）
一方、x0をxに変換する際、仮数部のLSBが丸めで繰り上がらなかったとすると、
x ≦ x0 ≦ x + 2^(p-1)
が成り立ち、仮数部のLSBが丸めで繰り上がった場合は
x - 2^(p-1) ≦ x0 ≦ x
が成り立つ。（全ての不等号が等号付きなのは、偶数丸めの可能性を考慮している。）
合わせると、どっちにせよ以下の式が成り立つ：
x - 2^(p-1) ≦ x0 ≦ x + 2^(p-1) -- (1)
x0が周期10^mの格子点上であることから、式(1)より
(2^(p-1) - (- 2^(p-1))) ＜ 10^m ∴ m > 2 * log10(2)
であれば、xから式(1)を満たすx0が一意に定まり、
周期10^mの格子点上に位置する他の数と区別できる。
□
>>364 それはどうだろう。 慣れという面は大きいと思うよ。
普通のローカル変数は変数の宣言と初期化は一体なわけだし、
その記法と一致させた方がよくない？ ってのは有るでしょ。
でも初期化のタイミングが (ある程度は) 見かけ通りになって欲しいという感覚からは
コンストラクタの方で初期化した方が自然だよなってのも有る。
そういう感覚的な部分は置いてちょっと便利な使い方としては、
コンストラクタが複数あってそれぞれが初期化したい対象が違う場合に
共通する部分は宣言と同時に初期化するように書くという方法。
こんな感じね。
struct foo {
int mem_i = 1;
double mem_d = 2;
char mem_c = 3;
foo(int i) : mem_i(i) {}
foo(double d) : mem_d(d) {}
foo(char c) : mem_c(c) {}
};
以下のように書くよりはマシでしょ。
struct foo {
int mem_i;
double mem_d;
char mem_c;
foo(int i) : mem_i(i), mem_d(2), mem_c(3) {}
foo(double d) : mem_i(1), mem_d(d), mem_c(3) {}
foo(char c) : mem_i(1), mem_d(2), mem_c(c) {}
};
宣言と同時の初期化が書かれていてコンストラクタでも初期化が書かれているときは
コンストラクタでの初期化のみが有効になる。
今まで全部下の方法で書いてたわ
そしてやめる気もない
ただ、
>>375 にも良くない面はあって、
ヘッダファイルでクラス定義をして
コンストラクタの実装は .c に書いた場合、
// foo.h
struct foo {
int mem_i = 1;
double mem_d = 2;
char mem_c = 3;
foo(int i);
foo(double d);
foo(char c);
};
// foo.c
foo::foo(int i) : mem_i(i) {}
foo::foo(double d) : mem_d(d) {}
foo::foo(char c) : mem_c(c) {}
ヘッダファイルからは 1, 2, 3 で初期化するかのように見えて実際にはそう初期化しないことがある
ってのは混乱の元になるかもしれないと思う。
ワイとしてはどう運用 (使い分け) すればいいのかはっきりした見解を確立できてない。
どうすればいいんやろね？
struct foo {
int mem_i = 1;
double mem_d = 2;
char mem_c = 3;
foo(int i);
foo(double d);
foo(char c);
};
こういうことするとfooは文脈依存で意味が違う紛らわしい存在になる
このfoo自体存在しないでほしい
class foo {
foo(int i);
foo(double d);
foo(char c);
private:
int mem_i = 1;
double mem_d = 2;
char mem_c = 3;
};
これなら別にいいでしょ
全データメンバー丸出しの単純structに中途半端なコンストラクタ付けてるのが問題の本質に見える
>>363 予想だけど実社会で蔑まれてる弱者で
こういうとこで憂さ晴らしをしてるんだろう
>>363 誰に対していってるのか知らないけど、
>>362は普通に書いただけだよ。
>>364 C++03にしがみついてるだけじゃん
>>377 初期化子にデフォルトがあるってだけだろ
関数引数のデフォルトで混乱するやついないのと同じ
>>375 >>377 みたいな初期化してるとき
どんな getter が定義されるのか興味ある
というわけで自己解決しますた！
https://ideone.com/Zz21oH 仕様としては15桁以内の10進数で、IEEE 754で表せる範囲で、
なおかつ最小桁の位が10^0以下だったら何でもおk
（原理上は最小桁の位は10^0より上でも逝けるやつは作れるが今回はパス
まぁ証明自体はいいと思うよ
あってるか知らんけど
あとはがんばって
>>279 の10億行の手入力のテストデータが確実に
15桁以内の10進数であるか確認しないとな
そこをスクリプトにするぐらいなら最初から書き換え案でよかったよな
色々とありがとうございました。
class TEST {
hoge_t h(1, 2); // expected identifier before numeric constant
};
の部分を
class TEST {
HOGE h(1, 2);
};
にしたら大丈夫になりました。（hoge_t を使わないで HOGE のほうを）
ここで疑問が出ました。
typedef struct HOGE
{
...
} hoge_t;
の HOGE と hoge_t の違いはなんでしょうか。
片方がなくても動くようですが、先ほどの話のように HOGE を使ったほうが間違いがないような気がします。
そこで、
typedef struct HOGE
{
...
};
という風にしてしまいつつあるのですが、どういう副作用があるのでしょうか。
>>391 そこに書かれた範囲だと HOGE と hoge_t とは同じものを指すことになるから、
そこを置き換えて大丈夫になるなんてことは無いはず。
たぶん書いてないところに問題があったんだろうと思う。
それはそれとして、その typedef には意味がないので単に struct HOGE で済ませておけばいい
という結論は問題ないと思うよ。
C で struct 省略のための typedef を変に覚えただけでしょ。
HOGE が型名で、hoge_t が変数名、という認識は合ってますか？
「struct HOGE ・・・」 を hoge_t 型 と定義する、みたいなやつですか。
C++ 使ってる限り、忘れていい過去の遺物と思っていいんですね。
struct Hoge{...};とtypedef stuct Hoge hoge_t;をまとめて書いてるだけ
古のCマスター様のイキリ構文だから忘れなさい
>>395 C++ のことだけを考えるなら typedef を使う理由はもう無くなった。
少なくとも C++11 以降は型の別名を付けるにしても using で全ての状況をまかなえる。
C では構造体タグと型名は別物として管理されていたけど
C++ ではそうではないのでわざわざふたつの名前付ける必要もあまりない。
>>397 なんか誤解招く説明じゃね？
ミスリード狙ってんの？
気に入らなければお前が説明しなおせばいいんじゃない？
Cでもタグ名とtypedef識別子は衝突しないんだから
typedef hoge_t HOGE;なんてしなくていい
C++14みたいに_tと_vにするなら意味あるけどね
>>400 まるでC++11で初めてタグが不要になったかのように思わせかねない
C++11以降の利点を推したいんだろうがごっちゃにしたらいかんと思うよ
>>407 using の説明のつもりだったが、
その部分も C++11 の話に見える？
まあ見えるかもしれんな。
>>408 そもそもusingの話(前半2行)いるか？ってことな
>>409 お前文章問題苦手だろ
>>411 むしろ using を使えという方が俺の言いたかったことなんだ。
しいて言えば typedef は「構造体の宣言と同時に」別名の定義もできるという点が
using ではできないけどそうする意味が失われている (ので特に優位性ではない) という意味で後半の補足を入れた。
あー、まぁ実質typedefは忘れた方がいい、というのは同意するけどね(初心者に教えるという意味では
C++ではstructをtypedefする必要は無くなった
ただ、typedef（やusing）は
typedef vector<Coord> Path;
typedef vector<Path> Pathes;
みたいな時に使っている
しかし、typedefに不満が無い人に対して、書き方が違っているだけのusingを
推進しようとするC++勢の姿勢は嫌い。
Cが好きで延長線上で使っていたのに、いつのまにかCとはまるっきり別言語に
強制されていっている。
>>416 typedefは文法的に非合理的なところがあるんだけど気付いてる？
typedef std::basic_string<char, std::type_traits<char>, std::allocator<char>> string;
typedef std::mersenne_twister_engine<std::uint_fast32_t, 32, 624, 397, 31, 0x9908b0df, 11, 0xffffffff, 7, 0x9d2c5680, 15, 0xefc60000, 18, 1812433253> mt19937;
↓
using string = std::basic_string<char, std::type_traits<char>, std::allocator<char>>;
using mt19937 = std::mersenne_twister_engine<std::uint_fast32_t, 32, 624, 397, 31, 0x9908b0df, 11, 0xffffffff, 7, 0x9d2c5680, 15, 0xefc60000, 18, 1812433253>;
using使うとtemplateも使える
template <class T>
using vec = std::vector<T>;
vec<int> vi;
usingはこういうのが嬉しいと思う。
// C++11
using func = void(*)(int);
// C++03 equivalent:
// typedef void (*func)(int);
>>417 文法的に非合理的？
C/C++みたいな低レイヤーの言語を触る時代はいつまで続くのかね
10年後でも100年後でも一番下のところは必ず存在する
アーキテクチャが変わってもC言語のような低水準言語は必ず出てくる
つまり世の中から『一番下』が無くなるとは思えない
AIによる最適化技術がコンパイラに積まれたら
C/C++みたいなのは不要になる気がする
アーキテクチャの一番下のアセンブラとかは残るとしてもね
>>423 AIによる最適化技術って具体的になぁに？
>>425 現行のLLVMとかによる最適化なら知ってるけど、まだ実現されてないAIによる最適化ってなにかなぁと思って。
typedefがわかりにくいのではなくてC言語以来のポインタ定義構文がおかしいんである
これは聖典『プログラミング言語C』でも「批判を浴びることがある」みたいに書かれている
これはどうせCベースの言語なら乗り越えねばならない関門なのでノーカンとして、
単に型のエイリアスが欲しいときはtypedefで十分やし、
定義型をテンプレートにしたいとか別の型にしたいときはクラスにしたら宜しい
かと
普通に考えて
機械語を入力としてそれと等価で高速に動作する機械語を出力する
作業をAIに任せるってことなんじゃないの（たぶん）
同じことをするのにいくつも書き方があるようだと
C++はますますプログラミング言語界のPerlになってしまうま、
AIによる最適化はそもそも最適な最適化が何なのかは計算不能（コルモゴロフ複雑性
というのはどうすんじゃ………
>>428 ごめんね、喧嘩売ってるつもりじゃないんだ。
コンパイル最適化技術は興味あるんだけど俺の知識が数年前で止まってるので新しい知識として取り入れたかっただけ。
>機械語を入力としてそれと等価で高速に動作する機械語を出力する
それってAIと関係なく何十年も前からあるなんの変哲もない最適化だと思うの。
>>423 最適化の為だけにC/C++使ってるわけじゃない
ハードを直接触る必要があるから使うというのもあるし
まあAdaとかでもいいんだけどさすがに使える人が少なすぎる
>>428 AIなら何でも解決するとか思ってそうw
>AIによる最適化はそもそも最適な最適化が何なのかは計算不能
AIって解析的に解くわけじゃないから計算不能でもいい感じに動いてくれるんじゃないの
>それってAIと関係なく何十年も前からあるなんの変哲もない最適化だと思うの。
最適化技術は素人だから知らないけど現状が割と決まった最適化ルールに当てはめてる
だけだとしたら改善の余地はあるんじゃないのかな
想像だけど
もちろん、LLVMのようにJITの結果をAOTしてくれるような俺の脳味噌で考えられる最大限の最適化より、もっと進んだ技術が将来的に出てくるとは思うんだよ。
最近そういう技術から離れてたので、俺の知らないうちに新しいブレークスルーがあったのかと思って純粋な興味で質問しました。
>>419 それを言うならこっちでしょ
template <typename T>
auto func(T&&) -> enable_if_t<is_integral_v<T>, void> {}
これとどっちが合理的だと思う？
template <typename T>
enable_if_t<is_integral_v<T>, void> func(T&&) {}
typedefとusingの話ではないけど
合理性という論点では同じことだよ
>>418 そう、だからtypedefはもういじるのやめてtemplate化はできないまま放置されてるんだよな
>>435 ああなるほど、納得したわ
君の思うように進めばイイねw
深層学習、機械学習のことをざっくりAIと呼ぶ人は
まぁおおよそ技術わかってない人だろうね
プログラミングを知らない人が「こんぴゅーたって何でも出来るんでしょ」って言ってるのと似てる
>>441 そう聞こえちまう発言を見かける頻度が高すぎてやだよな
>>437 「それを言うならこっちでしょ」の意味も
「合理性という論点では同じ」の意味も
「文法的に非合理的」の意味も全て分かりませんでした
>>443 では言い方を変えようか
関数識別子でも型識別子でもそれを一覧しやすいところに集めやすいことを合理性と言っている
概要と詳細はどっちを先に書くべきかってことだよ
typedefは右端に宣言対象の識別子
usingは左端から７文字目という決まった位置に宣言対象の識別子
trailing-return-typeも５文字目という決まった位置に宣言対象の識別子がある
可読性という観点からどう思う？
typedefは変数宣言を流用した手抜きだからこんな糞みたいなのも書けてしまう
typedef int are, kore, sore, dore, *hare, **yore, (*more)(float, long), (*ore)[42];
typedef int (*more)(float, long); //この書き方に抵抗は全くないが
using more = int (*)(float, long); //それでも俺はこっちが好き
>>445 その点については統一感あってむしろ美しいと思うけどｗ
typedef int are, kore, sore, dore, *hare, **yore, (*more)(float, long), (*ore)[42];
sore g(float, long) {}
int main() {
are a = (int)0;
kore b = a;
hare c = &b;
yore d = &c;
dore e[42];
more f = g;
ore h = &e;
return 0;
}
int are, kore;
変数のareとkoreが本質的に同じ型であることが重要なときに統一できるのはいいけどね
intの同義語をそんなに量産してどうするんだと
usingとtypedefでいうと関数ポインタ、配列の扱い違うよね
あのあたりよくわかってない
誰か解説して
>>440 まるでさも自分がわかってるみたいな言い方
別のスレでちょっと書いたことがあるが……。
人工知能 (AI) ってのは人間の知能を代行するものという意味合いで私は考えてる。
昔はコンパイラそのものが人工知能の枠内で扱われていたこともある。
それ以前にルールベース、つまり if 文の羅列のようなものまで人工知能の一種だった。
でもそれらが分野として確立されたら人工知能とは呼ばれなくなっていた。
機械でやるのが当たり前のものになったから。
普通の道具になったから「知能」ではなくなったんだ。
人工知能を実用化するってのは人工知能を人工知能でなくすること。
逆に言えば人工知能と呼ばれている間は曖昧模糊としてよくわからんのが当たり前なんだと思う。
これはいろんな使い方をされる「人工知能」という言葉について私なりの解釈であって
正しさを主張するつもりはないが、それなりに実態に合った解釈ではあると思う。
そんなこねくり回した理解いる？
たんなる学術分野を指すだけの言葉じゃん
意味が広いだけ
>>452 ワイン。 一杯目の終わりの方。
でもまあ前に別スレでも書いた内容だから酔って考えてるというわけでもない。
と思ったけど前に考えてたときも酔ってたかもしれん。
最適化方面へのAIの適用というと、
高度なルールベース（80年代のAI）までいったん後退したものに
収束が必ずしも保障されない最適化処理（有限ステップで終わる保証がないからもはやアルゴリズムと呼ぶのは抵抗があるがGAとか
を組み合わせたものになりそうなﾖｶﾝ
FPGAの論理合成エンジンみたいなやつを考えたら宜しいかと、
もはや冪等性は気体できない
ビルドをやるたびに結果が変わるorz
>>418 >>438 それを知らずに議論するやつが居ると思ってるのか・・・
文字列の内容を1行毎に配列に入れたいのですが
以下のプログラムだと一部の文字しか抽出できていませんでした
完全が必要な点を教えてください
for (unsigned int i = 0; ; i++) {
for (unsigned int j = 0; ; j++) {
if (*str == '\0')
return;
if (*str == '\n')
break;
datalist[j][i] = *str;
str++;
}
str++;
}
datalistに行ごとに抽出するならiとj逆のような気もするけど
とりあえずdatalistの方にも、各行の終わりに\0(文字列の終端)が必要じゃね？
ゼロ終端文字列として扱わないとか、最初にmemsetしてるなら別だけど
>>457 逆にいなかったと思ってるなら日本語の
勉強からやり直してくださいｗ
>>443 で、意味通じたのかな？
君の見解が聞きたいんだが
>>459 このレベルで人に聞いてるようでは使い物にならんな
>>417 それのどこが非合理なのか全く分からない。
ちなみに、俺は数学が好きで、学生時代、ほぼ満点だった。
>>467 >444 を読むと、言いたかったことはわかる。
> 関数識別子でも型識別子でもそれを一覧しやすいところに集めやすいことを合理性と言っている
言葉のチョイスはおかしいと思うけどね。単に「読みやすさ」「読みにくさ」とか言えばよかったところ。
>>459 vector<string_view> dim;
string_view sv = str;
string_view::size_type f;
while ((f = sv.find('\n')) != string_view::npos)
{
dim.emplace_back(sv.begin(), f);
sv = sv.substr(f + 1);
}
dim.push_back(sv);
>>468 個人的に数学記号のようなもの解読する値から強い方だからかも知れないが、
usingがtypedfよりも特に読みやすいとさえ思わない。
ただし、
#define 名前 定義内容
と
using 名前 = 定義内容;
で順序に対応関係が有ることはある。
しかしながら、C/C++では、
型名 変数名; // (100)
の順序な分けで、LL言語に多い、
var 変数名 : 型名;
の順序ではないので、統一と言う点では、typdefは(100)と美しく統一されている。
typedef int (*funcA)(float, long), (*funcB)(float, long), (*funcC)(float, long);
↑
の代わりに
typedef int (*(funcA, funcB, funcC))(float, long);
とか描けないよな
>>464 通じませんでした
しかしこれ以上興味も維持できませんので
この話はここで閉じさせてください
レスしてもらったのに申し訳ないです
見解は元の
>>416さんにでも尋ねてみてください
>>470 > しかしながら、C/C++では、
> 型名 変数名; // (100)
> の順序な分けで
「型名 変数名;」ではなく「型指定子 宣言子;」な。
(実際には宣言子は複数書けるがそれはわきに置く。)
順序はある程度は好みだろうとは思うが、
変数を宣言するにあたって「型名を与えているわけではない」んだ。
たとえばポインタ型の変数だと
int* a;
みたいに宣言できるが、
このとき int という型指定子と *a という宣言子から成る。
a の型名は int* であるが、
宣言のときには int は型指定子の側について * は宣言子の側についてるわけ。
typedef は変数宣言の文法と一致させているという意味では一貫していることに合意するが、
そもそも型名を途中で分断するかのような変数宣言の文法がイケてないので、
そっちで統一するのが本当にうれしいのかね？ という点で疑問を提示する。
いや、それでうれしいというのならそれでもいいんだが、
前提がそれほど一貫してないのに一貫性をもちだしても仕方なくね？
>>475 すまんが、個人的には、
int *ptr;
を
int* ptr;
と書く人は頭が悪いのかな、と思っていつも見ている。
int* a;
int* b;
int c;
//int[42] d;
↑こう書きたいという勢力と…
int *a, *b, c, d[42];
↑こう書きたいという勢力があるんやろね
好みというかその人のバックグラウンドというか
>>476 * は (文法的には) 宣言子の側についてるからそちらにくっつくもんなんだろうが、
型名としては int* だから int* と書く方が好ましいと考えている。
文法的な解釈はともかく「型名 変数名;」に近い書き方の方がわかりやすいという考え方だ。
あと、 C++ の設計者自身が * を左に寄せる書き方をしてるから私はそれに巻かれている。
C として書くときは * は変数名の側にくっつけて書くようにしてる。 (K&R ではそういう書き方になってるので。)
* の両側に空白を入れる流儀も存在するようだ。
>>478 >あと、 C++ の設計者自身が * を左に寄せる書き方をしてるから私はそれに巻かれている。
>C として書くときは * は変数名の側にくっつけて書くようにしてる。 (K&R ではそういう書き方になってるので。)
Cの設計者は数学的、C++の設計者は凡才的。
>>476 +1
ほんそれ
stroustrupは頭が●照る
>>478 int* a, *b, *c;
あほやろ
わしは自身がハゲてきてビヨヨーン先生を師と仰ぐようになったから左寄せ派
俺も左寄せ派だわ。
*は明らかに型の一部なのに変数宣言のときだけ型でないふりしてるのがいただけない
int *aを
int* aと書きたい人は
int (*f)()を
int(* f)()と書けば満足するのだろうかという不思議はある
そういうときこそtypedefですよ、ってことなんだろうか
>>484 int*を返す関数じゃないんだから不思議はないと思うが
>>486 なるほど
int*p // 左に*寄せる
int (*f)() // 寄せない
int (*a)[42] // 寄せない
int* (*f)() // 戻り値側だけ左に寄せる
こういう感じでやっていくのかな
いつも老害呼ばわりされてる俺が
今日ほどこいつら老害と思ったことはない
Is int* p; right or is int *p; right?
https://isocpp.org/wiki/faq/style-and-techniques#whitespace > The choice between int* p; and int *p; is not about right and wrong,
> but about style and emphasis. C emphasized expressions; declarations
> were often considered little more than a necessary evil.
> C++, on the other hand, has a heavy emphasis on types.
boost::format() が標準にとりこまれるのって、c++20 からでしたっけ？
>>484 元からイケてない変数宣言の文法を部分的にどうにかすっきり見せる
って程度の話なんで、複雑な事例を更に複雑にするような変なルール
にしたいわけではない。
C++ 的な方向に振るなら int (*f)(); は
std::add_pointer_t<int()> f;
か
std::decay_t<int()> f;
かなぁ……。
冗長だけど変に入り組んだ感じがなくなるので type_traits はそれなりに取り入れてもいいと思うよ。
>>492 std::format は boost::format とはだいぶん違うように見えるが。
でもまあ std::format が出来たのは C++20 からではあるよ。
>>495 ありがとうございます
今回は sprintf() で妥協します…
sprintf_s()と_countof()をセットで標準にしてﾎｽｲ
>>497 C だと _countof に相当するものは欲しいなと思うが、
C++ 的には std::size か std::extent を使いたまえ。
>>493 >元からイケてない変数宣言の文法を部分的にどうにかすっきり見せる
一般的なポインタを表現するためには、どうしても、宣言子の中にも型の一部を
書くべきだったので、文法がそのように選択され、
int* a;
ではなく、
int *a;
と書く方がその記法と統一感がある。
数学者や物理学者は一般性や統一性がある方が美しいと感じる人が多いと
言われており、通常、数物の世界で「美しい」というのは、統一性のある
書き方。
なので、C/C++の型でも、後者の方が美しく感じるのが数物系の才能がある
人の感覚。
>>496 どんな判断だよ
libfmt使えばいいじゃん
>>499
ポインタだけでなく、配列も、
int a[3];
の様に書く。これも、人気言語であったBASIC言語の
DIM a(3)
と似た感覚となっている。
配列はもちろん型の一部ではあるが、これを
int[3] a;
と書いて分かり易いとは限らない。というのは、
配列を使う場合には、BASICの場合ではa(i)、Cの場合では、a[i]のように書くので、
これも、宣言に置いても、BASICやCの書き方の方が分かり易いと思うのも自然。
それに
int *ptr_s[3]; // (100)
のような場合に、分かり易く型を全て左に書くのは難しい。
書くとすれば、
int*[3] ptr_s;
となるが、これが果たして分かり易いかと言えばNoだろう。
使う場合には、ptr_s[i] が int へのポインタになるのだから、
(100)の記法は至って分かり易い。 >>499 > どうしても、宣言子の中にも型の一部を書くべき
それを前提とするならそれと一貫させることを俺は否定してない。
でも前提とできないよねという話をしてるんだから
なんで「べき」なのかを説明しないとなんの主張にもなってないよ。
>>501 さらにいえば二次元配列の場合、宣言は、
int a[3][2]; //C。使う場合は a[i][j]
DIM a(3,2); //BASIC。使う場合は、a(i,j)
となるが、もしCで型を全て左に書くとすれば、
int[3][2] a;
となると思うかもしれないが、これは、数学的な統一性からすれば
間違いで、正しくは、
int[2][3] a;
となり、前後を逆に書くのが「正しい」。
これが即座に理解できる人が数学的才能が有る人で、
教えてもらわないと分からない人才能が無い。
>>502 Cの記法は、物理学で言うところの「組立単位」に相当する「組み立て型」を
一般的に表現するためには、かなり美しく正しい選択をしている。
int *a[10]; // (1)
int (*a)[10]; // (2)
と
は、物理学のように言えば、int-ptr-array-aとint-array-ptr-aの違いを
表しているが、Cの表現はとても理にかなっており非常に分かり易い。
これらの型を全てまとめて左に書こうとすれば、書くことは出来て、
int*[10] a; // int-ptr-array-a, (10)
int[10]* a; // int-array-ptr-a, (11)
となるが、果たしてこれが分かり易いかどうかと言う問題となる。
それぞれを使う際の a[i] や、*a の表記と(1), (2)に上手く対応しているので、
(10),(11)よりも統一が取れており、数学的には「美しい」状態となっている。
>>502 それは、
>>503 や
>>504 のようなことがあるから。
>>502 C言語のように「書くべき」ことが分かる一番分かり易い例は、Cで
int a[1][2][3][4];
と書くものが、全部左に型を書く記法だと
int[4][3][2][1] a;
と書かないと、組み立て型(物理学における「組立単位」に相当)における
一般性を失うが、それだと、使う際の a[i1][i2][i3][i4]と要素数の指定とが
直感的に逆さまになってしまう問題が起きる。
もし、
int[1][2][3][4] a;
のように書くと、一般性を失い、組み立て型としては破綻しまい、その場しのぎの
記法となってしまう。
もしこれが理解できないのなら、悪いけど、数学的才能や、コンパイラを設計する才能が無い。
じじいはこういう語りつくされた古い話題しか話せないからな
大工が金槌はこうでなくてはならない（家を作ったことない）
クソみたいなマウント合戦を繰り広げる老害であることを自覚しろ
>>504 数学的・物理的な美しさを (仮に (あくまでも仮に) その主張が妥当だとしても) C++ スレで根拠にするのが不思議。
そんな美しさなんてどうでもいいもの。
こちらの主張は
宣言の文法が型名とは別にある
→ その時点で一貫性なんてないよ
→ どちらを軸にすることもありうる
→ でもまあ C++ の発展の様子からすると型名を軸にしたさが見えるね
って話で、現時点で無い文法を導入したいとか思っているわけでもないし、
存在する文法を絶対に駄目だというわけでもない。
とはいえ (話の大元に戻るが) 現在の C++ が typedef を冷遇しているので、
なるべく using を使ったほうがいいよねってだけ。
わしのFormatterは
int* a;
int *a, *b, c;
のように整形しよる。これが落とし所として妥当であろう
>>500 https://github.com/fmtlib/fmt でしょうか？github になれてなくて、これを使う方法もよくわからないし…
20年使っている sprintf() でもういいや…って妥協してしまいました
手元のコンパイラは g++17, 職場のは g++11 だけれども、セキュリティが堅くて「無断で」cygwin をアップデートさせてもらえない…
必要に迫られて徹夜して間に合わせたけれども、プログラミングへの集中力はずいぶんと落ちてしまいました…
コメントありがとうございました
>>506 auto signal(int, void(*fp)(int)) -> decltype(fp); //こう書かれたら「破綻」で読めなくなるのか？ おまえさんは
それこそC++11のグラマーが読めない、つまり数学的才能に乏しいことになるぞ
>>512 あいつ結局Cの文法と設計思想を説明してるだけだよな
それをC++11の文法と設計思想を否定する根拠にしようとしているようだが
筋違いというか脈絡がない
ぼくはusing使いたくないんだーtypedef使うのを邪魔すんなー
僕はものすごく数学と物理に詳しいんだーセンスないやつうるせー
数学や物理学は、2000年以上も続く巨大なエコシステムを持っており、
それ以上簡潔にならないくらいな表現方法を発明済み。
それとは別の表現をしてもそれらを超えることはまず不可能で、文系の人達の
自己満足に過ぎない。
思っクソ関係ない
話せば面白そうな気がしたがそっちへ行くのね
あーあ残念
最近の「モダン」言語は、既存のものを知らずに新しいものを作ろうとする傾向が目立つ。
彼らは、今までの理論などそのメリットが理解出来ておらず、効率の悪い、
分かりにくい、整合性の無い、その場しのぎで、一般性が無い記法を導入する。
>>503 えっ？
そもそも
int a[2][3]; //C。使う場合は a[j][i]
DIM a(3,2); //BASIC。使う場合は、a(i,j)
じゃないのかな
>>499 は支持する
>>506 ここもおかしい
元々
int a[4][3][2][1];
と書くべき
分かりにくい文法で自爆ってダサすぎるなw
そもそもC++なのに素の多重配列使うって
センスなさすぎだし
>俺は数学が好きで、学生時代、ほぼ満点だった。
数物系が得意な人が、こんな馬鹿っぽくて曖昧な書き方するのかね？
この情報でどうやってお前の能力を推し量れと
>>493 なんでもテンプレートに書き直せばいいってもんでもない
CでもそうだけどC++を使うからにはC++らしく使いたいね
C訛りのたどたどしいC++からは早く脱したい
Cで憶えたことがとりあえず使えるのがC++に用意された入りやすい門ではあるけどね
そこは振り出しでしかないんだよ
>>493みたいなのをC++らしい、と思ってるならだいぶアレだけどな
仕事で使うならBetter Cで留めるのが正しいC++の使い方。
>>493 > std::add_pointer_t<int()> f;
> std::decay_t<int()> f;
（´･∀･`）ﾍｰ
そんなんあるんですね
勉強になりました
>>529 凄くC++らしいと思うけどｗ
意地でもテンプレートで何とかしようというのは
>>524 確かに、数物系に「特異」な人のコメントにしては貧弱だなあと、私も思いました
たとえばガロア理論、とか、相対性理論、超弦理論、とか、を熱っぽく語って欲しいです
個人的にはエルゴート理論について薀蓄を知りたいですね
>>527 でも iostream は失敗作という気がふつふつと…（略）
c++らしいって言っても時代によってかなり変わるし無意味な言い回しだわ。
時代によってかなり変わるの？
C++98以降しか知らないけど
C++らしさ＝テンプレート
と断言していいほどの一点張りだと思うけど（個人の感想です）
ここまで喧喧諤諤の多くの意見が飛びかっておるが
iostream は要らん子、というのは一致しておるな
とくに operator << >> 系のやつ
coutで出力するよりstd::stringに一旦文字列化してからprintf()で出した方が速いという時点で以下略
個人的には iostream をそこそこ好きなんだが、
今だったらこんな設計はしないだろうなというのはとてもよくわかる。
>>535 互換性を捨てられない以上は汚い部分も捨てられないんだよね。
だからどうやって抽象化層をかぶせるか、もっと直接に言えば
汚い部分をどう隠すかというのが C++ らしさじゃないかな。
そして型 (または型の表記) に関して汚い部分を隠す道具としては
テンプレートは特に有用なもののひとつだとは思う。
ただ、一点張りは言い過ぎで、取れる手段、手数の多さも C++ らしさだというのが私の感想。
組み合わせよう。
printfで%dとか%zとか指定するのめんどいやん
printfはバッファオーバーフローの脆弱性を産みやすい
>>531 ＞意地でもテンプレートで何とかしよう
"自分でテンプレート書いて"色々どうにかしてる人が言うならまだ説得力もあるけどね
add_pointer_tとかdecayは基本的に標準ライブラリの実装(のためのメタプログラミング)の上での副産物だろ
テンプレートの文脈(=受け取った型に、場合により変換を施す必要がある)でもないとこでそんなん使って
「C++らしい」とか、だいぶ痛々しい
まぁ別に使用を禁止されてるわけでもないから使いたきゃ好きにすればいいけどね・・・
>>533 まあね、俺も禿１からの付き合いだけど
未だによくわからんところはある
iostreamに限ったことじゃなく古株のクラスライブラリって
だいたい今作るならこうはしないってところが何かあるね
大きな実害なければ我慢するし
困る場合はそれこそ腕が鳴るチャンス
>>535 たとえばだけど、二次元配列がいるならクラス化するとかね
人によるだろうけどvector<vector<int>>は俺あんまりやりたくない
用意されているものを使っただけだろ
意地でもとかバイアスが入るのはコンプレックスの顕れだからこそ
ギャンギャン強弁してくるわけだ
>>542 printfでバッファオーバーフロー？
お前器用なやつだな
decayに_t付けるの忘れてた
>>548 それ誰に向けて言ってるの？
なんか口調でわかるわ、いつものアホか・・・
「＞」これが付いてるのは引用箇所だからな、覚えとくといいよw
printf, scanf系はtypedef型の正体を知っておかねばならないとかクラス型を基本型と同等に扱えないとかモロモロあるのに
いつまでもマンセーしててもしゃーないで
>>549 いや普通にありえるからググってわかる程度のこと聞くなよ
>>555 typedefの正体を意識してprintf/scanfを使うのは
privateでデータメンバを隠す話と真っ向逆だね
最終出力がわかりにくいとかロケール対応しにくいとかあるわけだけど
引数順にしか出力できない時点でprintfもロケール対応のやりにくさは変わらん
ググりかたから教えなきゃならんの？
相手にしてられんわ
>>558 そんなあなたにput_money, put_time
>>561 ロケールと書いたのが悪かったな
多言語化だな
語順を変えるとかやりにくい
Pythonのようにフォーマット文に引数の順番をかければ
言語による語順の違いもフォーマット文の差し替えだけで済む
>>556 ググれー
で逃げる気マンマンでワロタ
おとなしくsprintfでした、ごめんなさい
って言ってりゃいいのにw
>>547 boost::numeric::ublasとか使えばいい。
>>562 ああ確かに語順の変え方はprintfと変わらんな
auto time_v = time(nullptr);
cout << put_time(localtime(&time_v), "%m/%d/%y %H.%M'%S");
>コールスタック上のリターンアドレスを書き換えて不正なコードを実行させる
自分の過ちを認めろと言う割に自分は謝らず図々しく更に無駄な質問を重ねるとは
>>570 バッファオーバーフローさせるだけではコールスタック上のリターンアドレスは狙えないぜ
同じ記憶域期間を持つ他のオブジェクトを破壊する可能性があるというだけだ
コールスタック上のリターンアドレスを狙うなら配列でないオブジェクトのアドレスにオフセットかけるだけでもできるしな
逆に自動変数のアドレスを確実に得る技術が必要になる
printf/scanfといえばバッファオーバーフローという固定観念に囚われているから
そういう読みになっちまうんだよ
まともに日本語の文章も読めないようじゃプログラムは君には難しいよ
メモリ位置にあるデータを確認できると書いてあることすら読めてない
おとなしく、日本語もググるのも難しくてひとつずつ教えてもらわなきゃできません
ごめんなさいって言ってりゃいいのにｗ
>>575 俺、自動変数のアドレスを確実に得る技術って言ったけど
おまえさんは、これが何のことかわかってる？
printf/scanf関係ないんだがｗ
Wikipediaまで引用してあげたのにまだごねるのか
本当にわがままだな
> printfはバッファオーバーフローの脆弱性を産みやすい
重箱の隅な記事では、最後の「やすい」という主張の裏付けにはならないってことだ
粗暴な罵倒語も裏付けになるわけがないな
そんなにprintf好きなら勝手に使えばいいんじゃない？
おまいら printf の戻り値は毎回チェックしろよ
printfの書式にユーザ入力を使うことなんてあるか？
SQLインジェクションとはワケが違うぞ
バッファ使ってるsprintfと
バッファ使ってないprintfの
違いもわからんのか
確かにprintfの書式文字列に関するメモリ破壊の脆弱性が示されてるが、これを｢バッファオーバーフロー｣と呼ぶのは違和感があるな
>バッファ使ってるsprintfと
それ勝手に持ち出したのお前だからなｗ
結局のところ、
>>542が恥ずかしい奴だったという結論でok?
>>591 お前みたいな頭悪いやつが多くて
何も有益な話にならないから解散
という結論
cout << ...
がダサいだのprintfが早いだの
程度が低いんだよ
>>592 ん？
バッファーオーバーフローとメモリー破壊の区別もつかないアホがドヤって撃沈だろ？
ダサすぎるw
適当に脳内で読み替えとけや無能
こっちはprintfなんてそもそも使わんから詳しいことに興味はない
だからググれって最初に伝えたんだわ
>>594 じゃあメモリ破壊とバッファオーバーフロー
でリターンアドレスの書き換え方が
どう違うのか説明してみ
>>595 詳しいこと知らんのに
>>542で参戦してくるの？
振られたネタならともかく自分で振っといてwwww
printfに脆弱性ある
というのが重要な点なのにあくまでも上げ足取りをするのか
本当にごみしかいないな
こういうのに反応してくるのは雑魚と相場が決まってるからなｗ
>>596 それがprintfのバッファーオーバーフローと何か関係あるのか？
ごまかすならもう少しうまくやれよw
いや関係ないけど
どうせこいつもわかってないくせに人のこと煽ってるんだろうから
聞いてみたらやっぱ逃げた
printfはバッファオーバーフローの脆弱性を産みやすい
printfはバッファオーバーフローの脆弱性を産みやすい
printfはバッファオーバーフローの脆弱性を産みやすい
煽りモードに入るならボコボコにしてやんよ
>>610 どうぞご自由に
せいぜい頑張れよ無能なりに
>>542 今日日のIDEなら書式文字列とパラメータの型の不一致を指摘してくれる
Visual Studioなら2015からそうなっているので安心、
>>611 で、どこのバッファーがオーバーフローするのかな？w
黙ってりゃいいのにバカは無駄に吠えるしか能がないから無理だろうな
sprintf()なら有り得る、
希ガス
個人的にはsprintf_s()しか使わないから無用の心配だが
自分でバッファオーバーフロー言い出しといてなんやねん
std::ostringstreamは未来
そんなふうに考えていた時期が漏れにもありました、
しかしなんでスタックって高位側から低位側に伸びる実装なんだろうな
逆にしたらそれだけで外部入力依存のバッファオーバーフローでexploitされる危険性を半減できるはず…
バイナリエディタ見てみろよ。アドレス高いほうが下だろ。
スタックはちゃんと下から積んでるんだよ。
安全なライブラリ=チェックが多く遅いライブラリ
C使う意味なくね？
>>619 それは昔々、CPUが今よりずっと低能力で、malloc()などをする余力もない時代、
メモリー領域を、普通の変数のワークエリアと、call命令での戻り値アドレスの
記憶のためと、レジスタの保存、復帰(push,pop)用のためのエリアを逆方向
から使うことは、画期的なアイデアだったから。
データ領域は、アドレスの小さい方から、大きいほうへ伸ばして使っていくが、
そうやってるさいにも、call,push,pop命令は使いたいから、そのようにする
以外には当時の非力なCPUには非効率すぎて選択肢が無かった。
今なら、リンクリストや高速なmalloc()などを駆使すれば、別の方法も取れるかも
知れない。
>>624 [捕捉]
今は、マルチスレッドプログラミングをする際、各スレッドに、それぞれ
別のスタック領域を割り当てるが、その領域の容量は固定サイズ。
固定サイズでも何とかなるのは、メインメモリーが非常に大きくなったためで、
大部分は無駄になっていても、なんとかなってしまうから。
たとえば、関数呼び出しの回数と、ローカルスタック変数の容量を
掛け算したような値を見積もってみれば、とても無駄なスタック領域の
割り当てをしているだろうが、メモリーがふんだんに余る位になっているので
それでも特に問題がなくなってしまった。
ところが、かつてはメモリーが足りなくてどうしようもなかった。
しかも、当然当時はシングルスレッドだった。
なので、データ領域は上から、スタック領域は下から伸ばしていけば、
お互いが衝突するまで使える。これは、ギリギリ限界まで無駄なく
メモリーが使えることを意味する。
>>624 どこらへんが画期的で効率的なのかkwsk、
普通の変数のワークエリアと逆方向からスタックを伸ばしたところで
使えるメモリが増えるわけでなし…
（スレッドが2本以上あればスタック領域は結局スレッド毎に固定サイズで割り当てるしかない
百歩譲って一つながりのメモリを上と下の両方から使っていったらすばらしいと思えたとしても、
なんでスタックを0番地から上に伸ばしてsbrkが最大アドレスから下に伸びる設計にしなかったのかの
説明にならない
>>625 [もっと捕捉]
今は、MMUを使っており、実際に使ってない仮想メモリー空間には、物理メモリー
を割り当てない。だから、使うまでは物理メモリーは無駄にはならない。
もう一つは、(仮想)アドレス空間自体が飛躍的に大きく取れるようになったことで、
搭載している物理メモリー以上に大きなアドレス空間が使えて、各スレッド
のスタック用に大きめにアドレス空間を確保(commit)しておけるように
なった。
32BIT時代ですら、4GBの仮想アドレス空間が使えたから、アドレス空間自体の
不足は余りおきなくなった。積んでいる物理メモリーよりも大きな空の領域を
各スレッドのスタックに割り当てても、特に問題が無い。
今や64BIT時代。同時に実行するスレッドの個数も増えつつあるが、各スタック
領域の仮想アドレス空間上のサイズを大きくとってもどうってことは無い時代になった。
しかし、かつてはそうではなく、スタックは下から上に伸ばして行き、データ領域
と衝突するまで使うのが良い方法だった。
>>627 picの変態仕様見れば分かる。汎用機もそうだけどスタック制限あるアーキテクチャが普通だった時代。
しかも0番地から伸ばすとかCPUの仕組みすら知らんレベルだな。割り込みベクタがあったり、プログラムのROMがあったり、
0番地にフリーのRAMなどたいていない。つまり空いてるRAMの下限は開発が終了するまで確定しないこともしばしば。
じゃあいつSP設定値いつ決まるのって話。決まらないんだから一番うしろにして前に進めるのが頭使わずに済む。
ちなみに8086はスタックセグメントあるから。便利だろw
>>622 ものによるんだろうが、たとえば配列へのアクセスがバッファーオーバーフローに
ならないかのチェック程度ならほどんど実行時のペナルティはないというデータはどこかで見たことがあるな。
正しいプログラムなら分岐予測がほぼ成功するから。
まあ結局のところは程度問題というか、許容可能な程度ならチェックしたっていいだろうし、
実際問題として全く異常系がないプログラムというものもそれはそれでありえないわけで。
>>629 よく8086のセグメントレジスタを糞呼ばわりするやついるけど
あれはあれで意外と合理性あったんだよな・・
>>622 ライブラリによってはデバッグ版とリリース版を持ってたりする
チェックを端折ることができるって言うのが売り
>>629 > なんかデタラメがいろいろ混じってるぞ。
お前が言うなよ…
> 0番地にフリーのRAMなどたいていない。
6800はダイレクトアドレッシングモード持ってるから0x0000〜0x00ffはRAM前提
6502も0x0000〜0x00ffがRAMでないと使い物にならないしスタック領域がハード的に決まってるにも関わらず後ろから使う設計だったりする
> じゃあいつSP設定値いつ決まるのって話
開発中にRAMの下限が変わったらSPの初期値の設定変えるだけだろ
>>631 想定している範囲内で使う分には効率いいし優れたアーキテクチャだと思う
想定している範囲がすぐに時代遅れになってしまったけど…
>>627 スタックポインタというものができた、8008から8080に進化した時の話なのよ
>一つながりのメモリを上と下の両方から使っていったらすばらしい
うん、それだけの話
若い番地にはプログラムを置くのよ、後ろからスタック、そんだけ
mallocまで行かなくてもRAMが少ないからこそヒープからの固定長メモリブロックを使って省メモリしてたし、ヒープとスタックは別方向に取ったほうが最大限利用できた。
運が悪いとオーバーラップして誤動作するけど。
キャッシュ効率を上げるためにコーディング上でなにかできることある？
あるよ
まずキャッシュ効率というのをどうやって計測しようとしているか書いてみ
>>629 ふふふ 皆その程度のことなどわかった上で
たわむれておるのだがn（ry
>>635 >若い番地にはプログラムを置くのよ、後ろからスタック、
プログラムがROM上なら別段RAMの先頭からスタック、で良いのでは…
プログラムをRAM上に転送してから実行するとしても、プログラムの末尾からスタック、で良いのでは…
ハンドアセンブルするときにプログラム末尾のアドレスが最後まで確定しないというのは却下
（ワークメモリをプログラムの末尾に配置するほうが数が
プログラムの末尾アドレス確定後に決めなければならない定数が増えて大変なはず…
>>639 じゃあ最適化ガイドのドキュメントあるでしょ？
がんばれ
メモリアクセスが狭い範囲に集中するように工夫する
可能な限りスレッド数を少なくタイムスライスを長くする
>>637 対象CPUのキャッシュアーキテクチャは何？
>>635 > スタックポインタというものができた、8008から8080に進化した時の話なのよ
知ったか乙
PDP-11にすでにスタックポインタはあるぞ
>>642 ざっくりした内容で1行書き込めば
懇切丁寧に教えてもらえると思った？
>>646 PDP-11の時代からスタックは高位番地から使うようになってる
8080は（他のプロセッサも含めて）それに倣っただけ
>>649 何で俺がそんな説明されるのかよくわからん
>>650 >>635の話じゃないと言うならいちいち横から絡んでこないでね、ウザいだけだし
CSとSSが物理的に分けられるようになって意味が無くなった
>>633 6502のアーキテクチャぐらい知ってるがな。だからたいていと言ってるだろ。
> SPの初期値の設定変えるだけだろ
当時の開発環境は紙の上とかが普通。ハンドアセンブル上等でみんなOPコード暗記してた。
ROM位置ズレました〜なんて言われたらちゃぶ台返しレベルの仕様変更。
8086のような相対値アドレスで比較的リロケータブルな環境は後になってから。
設定値を変えるだけだろとか簡単に言われても困る。
> PDP-11の時代からスタックは高位番地から使うようになってる
だったら当時はなぜそうなったか説明してくれないとな。
>>651 646が絡んだことになってるのか
被害妄想の強い人だな
>>653 > 設定値を変えるだけだろとか簡単に言われても困る。
スタックへのアクセスってよほどトリッキーなことをしない限りSP相対だぞ
スタック領域変わったからと言ってSPの初期値以外に一体何を書き換えるんだよw
> だったら当時はなぜそうなったか説明してくれないとな。
それはPDP-11のアーキテクトに聞いてくれ
俺の指摘は8080ガーと言うのが的外れって言う話だから
>>654 いちいち絡んでくるなよ、気持ち悪いわ
被害妄想というよりボキャ貧かｗ
なるほどな、今さらなことをドヤってるのも頭の更新が止まっている症状か
納得
>>652 でも、アセンブラならcall,push,pop,[ebp+xxx],[esp+xxx]はss:をしていなくても
勝手に stack segment相対になるから良いが、Cの引数にバッファのアドレスを
渡すような場合、ds:なのか、ss:なのかが分からないから、farアドレスにする
しかなくなってしまう。なので、ss=dsの状態にした方がCだと効率が良かった。
64ビットになったらセグメントなんてどうでもよくなったな
対立してないのにどうやって反論するんだよ
それと何がどうだったという証言は論じゃないからな
>>661 お前はどうでもいいから無駄に絡んでくるな
>> 設定値を変えるだけだろとか簡単に言われても困る。
> スタックへのアクセスってよほどトリッキーなことをしない限りSP相対だぞ
> スタック領域変わったからと言ってSPの初期値以外に一体何を書き換えるんだよw
に対する答えが欲しいだけ
>>662 おまえさんこそ俺が言ったことに反駁できてないな
喧嘩腰で来たのそっちだぜ
許して欲しいならちゃんとそう言えよ
まあ逃げても追わねえでやるけど
それこそ論点がないのにどう反駁しろと？
バカが横から絡んできて勝手にスッ転びました、どうしましょうか？
⇒ 放置しかないわなw
>>655 >SP相対
なんだよこれ。非力なチップでスタックフレームの実装でも始める気か？
8086のようなスタックフレーム考慮した楽ちんアドレッシングとかおまえの指摘は時代錯誤が多い。
当時のデバイスもROMやテープが当たり前だし設定値変えるだけとかほんと簡単に言ってくれる。
だいたい先頭にスタック置いて、今度はどうやってワークエリアの位置を確定する気だよ。
結局確定しないから後ろからってなるだけだ。
>>665 また意味不明なことを言い出した
まあ低能にありがちな行動だけどw
>>666 push/popってSP相対だろ
> 当時のデバイスもROMやテープが当たり前だし設定値変えるだけとかほんと簡単に言ってくれる。
どうせ変更するのにSPの初期値を変えるのが面倒とか意味わからん
ちなみに俺は8bit時代からの組込み屋でテープもEP-ROMも使ってたから当時の話とかでごまかそうとしても無駄だよ
> だいたい先頭にスタック置いて、今度はどうやってワークエリアの位置を確定する気だよ。
後ろから取ればいいだけだろ
ただなんとなく気持ち悪いから前からワークエリア、後ろからスタックってなっただけだと思うよ
否定しないなあｗ
スタックへのアクセスはpush/popだけとか
自動変数にポインタ経由でアクセスするのがトリッキーとか
何だろこの人ｗ
> EP-ROMも使って【た】
過去形だね
C++でファームウエア書いてないってことか
>>667 なぜSPは後ろからという議論なんだから結論を先に言えよ。先に言ってりゃおまえとは議論しないんだよ。
> ただなんとなく気持ち悪いから
>>668 > 自動変数にポインタ経由でアクセスするのがトリッキーとか
それSP相対になるだろ
とりあえず
> スタック領域変わったからと言ってSPの初期値以外に一体何を書き換えるんだよw
の答えを考えてからレスしろよ…
>>669 えっ、まだEP-ROM使ってるの？
紫外線イレーザーが現役とかすげーなw
>>670 結論じゃねーよ、俺の勝手な想像だ
日本語も理解できてないアホはこれだから…
>>671 ならねえよ
void func(int* p)
{
*p = 1; //代入先が自動変数か否かはわからんだろ
}
おまえさん、左辺値pから右辺値をpopで取り出すとか思ってそうだな
EEPROM知らねえらしいな
マジ頭の更新止まってやんのｗ
>>673 呼ばれた側は自動変数かどうかなんて意識する必要ないだろ…
それ自動変数へのポインタを引数にして呼ぶ側のコード考えたらわかると思うけど
>>674 ん？
EEPROM知らないとかどこから出てきたんだ？
EP-ROMでバカにされて発狂の図？w
>>675 自動変数かどうかわからんものへのアクセスをSP相対にできるのかって話だよ
重箱の隅ではないごく一般的なケースだぞ
ここC++スレだぜ？ this->すげー多用するんだが
UV-EPROMのまま更新が止まった頭じゃ思い至らんかったか
>>676 > 自動変数かどうかわからんものへのアクセスをSP相対にできるのかって話だよ
だから自動変数へのポインタを求めるのは呼び出し側でSP相対で計算してるだろ
呼ばれた側は単なるアドレスになってるから関係ない
C/C++の基礎だぞ、まじでわかってないのか？
EP-ROMとか言う前にちょっとは考えろよw
>>667 > 8bit時代からの組込み屋でテープもEP-ROMも使ってた
このスレ凄い人おるんやな
素直に感心したわ
>>678 ごめんなホレリスカード使ってたわ
それと2500feetのオープンリールとかね
>>678 別に凄くはないよ
そういう時代に仕事してたってだけの話
もうすぐ定年だけど正直仕事としては当時の方が面白かったな
まあ時代が上り坂だったせいもあるけど
>>677 this->がどう翻訳されているのか覗いてみたことがないから
スタックへのアクセスはほとんどがSP相対だなんて大きく出たんだろ
おまえマジC++でROM焼きしてねえだろ
>>681 > this->がどう翻訳されているのか覗いてみたことがないから
C++はスタティックとかヒープとかにインスタンス置けるから一概には言えんけど自動変数としてインスタンスを生成したらthisポインタはSP相対になるだろ
ならない例があるとでも言うのか？
> おまえマジC++でROM焼きしてねえだろ
まあC++のROM焼は確かにあまりないな
ROM焼きするのは8bitはほぼアセンブラだし、16bitでもC言語だったし
ただC言語でもスタック上に生成した構造体へのポインタはC++のthisポインタと同じだしな
アセンブルリスト見たらすぐわかる話
>>679 褒めて欲しいん？
>>680 謙遜しなさんな(｀･ω･´)ゞ
俺も含めてオッサンしかいないスレw
オッサン同士仲良くしようぜ。
>>682 C++でROM焼きしてねえんだな？
このスレではゴミだぜ、クズだぜ
そこ弁えろな、ゴミクズ
thisがSPとか寝言ぬかしてんじゃねえ
スタックに必要なサイズを求めるのはとても面倒だった。
だから、予め決まった領域を割り当てるのは不可能に近かったので、
データ領域とは逆さまに、データ領域が最後まで使わない部分をスタック
領域とし、暴走しない限りはスタックが足りていると判断する(笑)と言う
当時としては合理的な方法が採用された。
この方式だと、スタックサイズが見積もれなくても、問題が無い。
本等はスタックが足りているかどうかは、暴走したかどうかではなく、
機械語モニタなどで、スタック付近をダンプしてみて、00h以外の値が
ある部分がスタックが使用されている領域とみなすことが出来た。
>>682 もちろん、その関数の中ではsp相対になる。
しかし、C言語では、ローカル変数のアドレスを他の関数に渡す。
一方、グローバル変数のアドレスも同じ方式で他の関数に渡す。
で、どちらからきたアドレス化を区別する方法が基本的には無い。
区別するためには、far pointer といって、普通のアドレス以外にセグメントアドレス
を合わせた長いポインタを渡す必要があった。
しかし、それは何かと効率が悪かった。
そこで、Windowsは32BIT化したときに、far pointerを使わずに済ますため、
(大体で言えば)セグメントを全て共通のベースアドレスとサイズを持つようにし、
「Full Flat」方式を採用した。
これで、ポインタ渡したり記録したりするための領域が短くて済み、
効率が上がった。
>>685 で、SP相対にならない例はあるんか？
>>679見る限り汎用機のオペレーターさんみたいだからあまり無理すんなw
>>689 だからthisな
どっから値もらってきたかは関係ねえの
わかったか？ ゴミクズ
>>688 sp 相対アドレッシングって 6809 以外にはなにがあるのですか？
>>691 x86系は、[esp+xxx]が使える。
[ebp+xxx]も、ebpを関数の先頭でespを記録するから、同じこと。
>>688 申し訳ないけどfarポインタの話は頓珍漢だしややこしくなるだけだよ
セグメントレジスタはSSとDSだけじゃなくてCSやESもあるし、そもそもローカル変数とグローバル変数を区別するためのもんじゃないし
>>690 >>663w
けんかをやめて 二人をとめて私のために 争わないで もうこれ以上
thisの話は何をモメてるかよくわからないが、単順にブート時のSP初期化値の変更で
後ろのスタックをアクセスするコードを修正する必要があるかないかという話。
彼はSP相対(←この表現がおかしい？)だから変更する必要がないと言ってる。
まぁ、基本手はにはそうだが、処理系によってはバンク切り替えでスタックエリアが裏に回る可能性も否定できない。
そして今時のカーネル開発のようにコンテキスト保持のために同期てんこ盛りになるわけだ。
>>691 6800とかでもTSX命令でSPをインデックスレジスタにコピーして相対アクセスできる
8080ならSPHLでSPをHLレジスタにコピーできる、オフセットの処理は自前でやるしかないけど
まあ6809や8086に比べたらかなり効率悪いコードになるけどね
x86のC言語では、スタックに積み込まれた自動変数のデータは、SPが変更されてもスタックフレームを復元すれば、変更前と変わらずアクセスできる。SPの値もプッシュ・ポップできる訳であって。
>>698 > 処理系によってはバンク切り替えでスタックエリアが裏に回る可能性も否定できない。
そんな特殊な例を出されても…
一般的な日本の8bitPCで64KB空間しかないのにROMだけでもあれこれと数百キロバイト積んでるし、
VRAMもでかい。基本、z80も6502もフラットを要求するCとの相性はよくない。
6800てｗ
ワイが学生時代演習で使ったのが68000だったなぁ
今となっては何一つ覚えてないけど
>>693 おまえさんが使う空疎な罵倒語とは違うぞ
なぜゴミクズなのかきちんと説明したうえで言っているからな
>>705 > スタック領域変わったからと言ってSPの初期値以外に一体何を書き換えるんだよw
の答えはまだかな？
> 許して欲しいならちゃんとそう言えよ
> まあ逃げても追わねえでやるけど
そのまま返してやるからさw
>>706 答えはまだかなって、そもそも俺は聞かれてないんだが？
レスの流れをもっぺん追ってみな
>>707 お前が誰か知らんがなw
関係ないならいちいち絡んでくるなよ、気持ち悪いわ
>>708 では「答えはまだかな」は引っ込めるんだな？
しがみついてた梯子を外されて可哀想にｗ
>>709 馬鹿なの？
お前に対しては聞かないというだけの話
>>653が早く答えればいいだけ
まあ無理だからゴミクズとか言い出してるんろうけどw
>>710 おまえさんがゴミクズなのはC++でROM焼きしてないからだ
それをすり替えようったってそうはさせねえよ
わかったか？ ゴミクズ
何だこいつ？
いきなり絡んできて意味不明なこと言い出すとか通り魔かよw
ここはC++スレだ
ゆえにC++でコード書いてないやつは価値ゼロだ
もう一度言う
おまえさんがゴミクズなのはC++でROM焼きしてないからだ
8080であろうが6809であろうが関係ない
C++でコード書いて得た知見を言え
それ以外の戯れ言はいらん
>>713 ROM焼きしてないだけでC++はガンガン使ってるけど？
thisポインタなんてstructへのポインタを自動生成してるだけ
初期のC++処理系でC言語に変換したコードとか見たことないのか？
>>714 おまえさん6800だの8080だの持ち出してドヤってたろ
6800でC++書いてんのかよ？ え、おい
>>715 6800とか8080の話は
>>691からの流れな
話の流れも読めないバカは黙ってなよw
スタック上にある構造体を指すポインタはスタック領域を指すっていう
それだけの話で100レス以上も盛り上がれるなんて楽しそうで羨ましい
上から目線で頓珍漢な結論を開陳してる君の方が幸せそうだがw
話の流れも読めないバカがなんか言ってるなw
惨めにならないんだろうか？
上から目線で頓珍漢な結論を開陳
上から目線で頓珍漢な結論を開陳
上から目線で頓珍漢な結論を開陳
>>716 633とかの黒歴史はなかったことにしたいんだろｗ
C++使ったことない環境の話でドヤるなと牽制されて
なあID:cdg8K9Zmよ
>>722 ん？
633のどこがおかしいの？
結局、
>> 設定値を変えるだけだろとか簡単に言われても困る。
> スタックへのアクセスってよほどトリッキーなことをしない限りSP相対だぞ
> スタック領域変わったからと言ってSPの初期値以外に一体何を書き換えるんだよw
の回答もないんだけど、君が答えてくれるのかな？w
当初は技術論をぶつけあってるようで興味深く読ませてもらってた
難しくて理解できないことも多かったけど
いまはもうただの罵倒合戦になっちゃったね残念です
>>723 説明したとおり、昔の処理系は移動した先のスタックエリアがそこに常にあるとは保証されないからその対応は必要。
今はユーザーモードならOSがスレッドコンテキストを保証してるから頭使わないだけ。
>>725 > 説明したとおり、昔の処理系は移動した先のスタックエリアがそこに常にあるとは保証されないからその対応は必要。
申し訳ないけど全然状況が想像できん、具体例で説明してくれ
スレッドセーフだったAPIがスレッドセーフじゃなくなりました!!
って言われて、はぁ？と言いながらソースを修正する、みたいな。こんな具体例でいいですか？
ワイはそこまで昔のことは知らんし、組み込み系の話もわからんけど、
MS-DOS (16bit) 時代のプログラミングの知識だと
データの位置はスタックポインタからの相対というだけではなく
セグメントレジスタの内容も加算される。
スタックセグメントレジスタとデータセグメントレジスタが一致するときは
単純なのだが、そうでないときはセグメントの値とセグメント内のオフセットを組にして
ポインタとして扱わなければならない。
(いわゆる far pointer のこと。
Windows SDK のヘッダファイルの中に near と far がマクロ定義されているのはたぶんそのなごり。)
C のプログラムとして書く分にはメモリモデル (セグメントの扱い) を決め打ちして、
コンパイラはそれに従って整合性を取ってくれるから素直な C プログラムなら問題にならないが、
凝ったメモリ管理をしようとするとそう単純にはいかないことはあったかもしれん。
>>727 ごめん、全然わからん
そもそもスレッドとかがある時代の話なの？
>>728 あなたも書いてる通りfarポインタでも
> コンパイラはそれに従って整合性を取ってくれるから素直な C プログラムなら問題にならない
のが普通
よほどトリッキーなことをすれば駄目なケースがあるのかも知れんが俺には思いつかん
>>730 スタック領域にメモリーコンパクション？
昔の処理系の割にスレッドとかメモリーコンパクションとかなかなか凝ったシステムやねw
メモリーコンパクションて昔の処理系でしょ
今の処理系でやるやつあんの？ｗ
昔といえば昔かな、
>>725はもっと昔の話かと思ってたけど
で、メモリーコンパクションがどう関係するって？
これだけ説明して何も分からないならそれまででしょう。
OSに感謝してC++富豪プログラミングを謳歌してください。
説明できずに遁走
と言うことでいいかなw
まあそうだろうとは思ってたけど
もちろんだ。それでキミの自尊心が傷つかないで済むならそれでいい。
>>729 ひとつのプログラムの中では整合性は維持されるけど、
別のタスクとやりとりするときにメモリモデルが違うと
near pointer と far pointer を明示的に使い分けないといけないことがある。
わかってればとりたてて難しいことではないのだけど、
言語仕様に沿ってれば後はコンパイラにお任せというわけにはいかない。
知ってる必要はあった。
話題の発端 (よりは少し後？) でスタックポインタとの相対番地は
呼出し側で計算するんだから……という話が出ていたので、
他の要素 (セグメント) が絡むアーキテクチャのことを思い出したなぁという余談。
>>739 理解しているだけでなく、far というキーワードを
char far *ptr;
のように書いたりしなくてはいけなくて、面倒だった。
far ポインタ、今ここで見なければたぶん一生わすれたままだったのに
ちなみにMS-DOS時代は全部のセグメントをひとつにまとめた .COM っていう実行形式あったな
いまでも動くのかしらんけど
>>741 Windows では今でも com 形式を実行できるよ。
環境変数 PATHEXT の Windows でのデフォルト設定を見ればわかるが、先頭に com が入ってる。
(同じ名前であれば exe より com が優先されるということ。)
C:\Windows\System32 の下にはいくつか com 形式の実行ファイルはあるし。
ただ (com 形式に限らず) 昔のプログラムは直接にデバイスを叩いていたりして、
さすがにサポートしきれていない場合もあるから、昔のプログラムが何もかもそのまま
動くというほどではない。
>>739 別に一つのプログラムの中でもnearとfarを混在できる
メモリーモデルはディフォルトのnear/farを決めてるだけだから異なるメモリーモデルのプログラムを混在させたなら相互に使用するデータやコードには個々にnear/farの指定をする必要があるのは当たり前
それを含めて言語仕様だし
>>740 char near * far f();
とか書き方がややこしいのは認める
>>743 たとえばC:\Windows\System32\format.comなんかあるけど
dumpbin /headers format.comとやると中身はexeだと出てくるぞ
masmに付いてたexe2binで出力した本当のtinyモデルのやつは
x86までで、x64のwindowsでは実行できんぞ
>>745 えっ、そうなんや！？ それは知らんかった。
じゃあ拡張子が com なのはなんかの互換性とかの都合なのかな。
format.comはdosの時代からずっと拡張子.comのままだね
int 21h, ah=4bhで指定するファイル名が変わると困るから
ちなx64で16bitプログラムが実行できないのはm$の恣意的な制限で
ホストx64、ゲストx86のvmアンダーなら.com形式のプログラムも実行できる
Windows 95 の command.com ですら exe 形式
ライブラリ含むと64KB制限は結構きつい
確か、int 21hのDOS Function Callは、今のWindowsではサポートされなく
なったと聞いた様な。
じじいは昔話しだすと止まらなくなる
ボケてないんだったら自覚して自重しろ
.comはCPMの名残だけど
全セグメントを一つにまとめたってのは
ちょっと違くないか？
別に違うセグメントにアクセスしても問題無く動いてたろ？
>>754 今でいうセクションみたいなことを言おうとしたんでしょ。
実行環境の話ではなくあくまでもファイルフォーマット。
>>754 たぶん *.com と *.exe の違いはMS-DOS のイメージローダの都合、というものじゃないでしょうか？
*.exe はテキストの前に、セグメントアロケーション情報を持っていて、実行ファイルをロードする歳に、関係するセグメントオフセットを実セグメントに変更します
*.com にはそれがなく、生のテキストがメモリ上に配置されるだけ
*.com であってもプログラマが自分でオフセット・セグメントを把握したり、スタックポインタ・スタックセグメントを設定しているのだったら、それはそれで問題なく動くでしょう
簡単な実験
echo ﾃ>test.com
test.com
PC9801の頃に、漢字 2字? のファイルを comで保存して、IPLん走らせるみたいのあったな
たしかその 4バイトは 0番地に分岐する命令だったような
How many files (0-15) ?
NEC N88-BASIC Version 2.1
Copyright (C) 1981 by Microsoft
56548 bytes free
Ok
_DEBUG で区切っているコードがあり、
releaseモードで実行したのに
_DEBUGで切っているコードを実行されてしまいます。
プロジェクトプロパティにて宣言していないのは確認しています。
なにか解決になるヒントだけでもいただけないでしょうか？
>>763 大ヒント:
それはC++の機能じゃない。Visual Studioのスレで聞け。
あとビルド構成
Releaseモードにしたとき自動で入るのはNDEBUGだろ
その昔、ソースコードの中で#undefしてる大タコなやつがいた
間接話法による自己紹介とはなんと慎み深いお方なんだ
ここ見てるとC++使いは性格悪いのが多いって感じがする
昔はこのスレももっとまともな人が多かったと思うけど、いつの間にか一部のガラの悪い奴らの下らない罵り合いばかり見せられて人が去っていったのかなと思う。
ここで聞くより調べたほうが大抵早いし
なんでこんなところに来るのかわかんない
入り組んだ仕様の組み合わせで起こることならともかく、
簡単に調べられることだと回答も仕様 (またはどっかの解説)
をコピペするか URL を貼るだけになるからつまらんのだよなー。
そのワンステップ必要？ という気持ちにはなる。
本物の初心者がそれすらできないことがあるのも知ってるから、
あまり無碍にはしないようにしてるけど、
つまらんなーという気持ちは残る。
別に質問しに来てるわけじゃないからな
質問する人がどういう経路で来るのか気になる
まじでc++ユーザー煽り合いしか出来ねーな
普通に教えられないのか？
そのくせTwitterでは、新人への対応がーとか云々社内のこと愚痴る癖に人の振り見て我が振り直せって感じ
コード書かないC++委員会の言語オタクどもが仕様拡張病を患ってるから
仕様を知ってる知らないレベルでマウンティング合戦になるんだよな。
>>776 >C++委員会の言語オタクどもが仕様拡張病
ああ判るわ
コード描くか描かないかに関わらず目的が可笑しい
知らなかった情報が拾えるのはいいことだし
質問する者にとって回答してくれる者がいるのもいいことだ
問題はしょーもないクイズで人を小馬鹿にするやつと
無知を正当化しようとする弁舌だけ達者なボーガスだ
質問して答えられなかったら自分の勝ちというのは昔から馬鹿左翼の論法。
国会でカップラーメンの値段聞いたりほんと馬鹿である。答えを知ってるなら説明するだけでいい。
いや気が短い人には、テンプレート絡みのエラーメッセージなんか読めるはずがない
組織で開発してるのにおれおれテンプレートなんか使われたらもはや他人が読めるものではない。
キレて当然。
出たな
無知を正当化しようとする弁舌だけ達者なボーガス
>>770 >>771 でも検索するより、知ってる人に聞いたほうが早いことが多い。
それに複雑な事柄を検索しても、回答を見つけるのは難しいことが多い。
問題はしょーもないクイズで人を小馬鹿にするやつと
無知を正当化しようとする弁舌だけ達者なボーガス
↑
ゴミクズ同士、共食いで滅びて欲しい
ID:oZeTafce ←こういうのが一人でもいると他人が読めないコードを大量生産してデスマーチになるからちゃんと監視しなきゃならない。みんな無知過ぎ、他人の読めないコード書くおれーすげー、みたいな。
>>776 最近日本人の有名なC++ライターが
「グラフィクスとかオーディオのライブラリ標準化にはゲーム業界も参加しないとやばいよ、という目的もあった」
とかtwitterで言ってたんだが(なんかの講演に関して)
この上から目線は最近？昔から？
ゲーム業界はC++標準に興味など無いことに、いつになったら気付くのか・・・(特にグラフィックスはC++標準に新機能が採用されるのを、何年も待つはずが無い)
>>788 全然、凄くない
当たり前のことをしているだけだ
法には周知義務があるのを忘れるな
まあ江添みたいな馬鹿はあと数年も持たず路頭に迷うだろ。
職質拒否して裁判もボロ負けしたC++イキリおじさんだっけ
本当に、職務質問を拒否しただけで逮捕されるのか？
日本は民主国家か？
これ、中国と同じだろw
いかにも怪しいやつを人権・自由を盾に野放しにする社会とどっちがいい？
自分がその「いかにも怪しいやつ」に仕立て上げられてと構えられることの想像力が働かないんですね
別にIOCCCみたいにわざと意地悪してるんじゃなく
整合性を大事に書くときに有り難い機能が追加されたら使うってだけ
新しい機能を使うなってやつは何を基準に言ってるんだ？
たとえばcfront 1.0が基準ならテンプレートどころかprotectedすらないんだが
堀江貴文と一緒でルールハックドヤかましたかっただけだろうがマジで連行されたっていう頭の悪いオチだろ。
他国の有罪率は、50%。
日本だけが、100%
だから、半分は冤罪。
ほとんど証拠がないけど、有罪になってる
酒酔い運転の検問でも、息を吹きかけて、検査機のランプが点かないと、
警官がちょっと待ってと言って、くるっと後ろを向くと、ランプが点く
何のことはない。
警官が酒を飲んでいて、息を吹きかけているw
警官の犯罪率は、異常に高いと思う
>>804 rubyガイジは真正の馬鹿だな。
脳みそ足りなすぎて日常生活に支障が出てるんじゃないか？
日本の起訴率は51.5%
よって有罪率は0.515 * 0.998 = 約51%
技術書なんてなんぼ売れてもカスみたいな収入にしかならんよ。
技術書は高めなので1冊の執筆料1000円入ってきたとして、1000部売れても100万円かぁ。
小遣い稼ぎならともかく、事業として考えたらペイはしないわな。
印税なんて5%〜10%程度よ？
しかも最初の1000部は印税なしとか大学生だったときに教授から聞いた
具体的な部分は契約によるらしいが、
表紙デザインを除いては Github に公開してしもうとるし、
それで儲ける気はないんやろ。
でもまあ C++ 界でそこそこ知名度のある本にはなったし、
実績として十分だわな。
本と言えば思い切ってプログラミング言語C++を買ってしまいました
これで僕もハッカーになれますか？
ユーチューバーは、100万視聴で1000万近くになるらしいですよ。
YouTubeで受けるためには道化師になる必要があると思われる。
芸人と呼ばれる人は、ピエロや道化師のように、下から下から
やっていかなくてはならず、人に馬鹿にされることによって
食っていく立場となる。
それが出川であり、アンガールズ田中だ。
ランタイム速度最強で、高機能は最新バージョンでなんでも無理やり入れるところかな。
その代わり、一貫性、ビルド速度あたりが犠牲になるが。
汚かろうがなんだろうが問題解決のために使用可能だということが C++ の強さだと思う。
程度はともかくとりあえず C++ を使えるという人材を確保するのはなんら難しいことではないし、
資料もたくさんある。
言語機能がどれだけよくできていたところで使い手がいないだとか
まともな処理系がないとかだったら話にならんわけで。
特に産業的な分野では。
C++ は教育体制や処理系の充実と足並みを揃えてその大前提を満たし続けてきた。
----
ところでどうでもいい話なんだけど「きたなかろうが」を変換したら「北中朗が」と出てきた。
> C++ は教育体制や処理系の充実と足並みを揃えてその大前提を満たし続けてきた。
釣り針デカすぎだろw
conceptをC++11では一旦引っ込めたのも
足並みを揃えるってことの1つだな
>>824 教育体制って言うか資料は豊富にあって勉強するには事欠かないし処理系はかなり充実してるとおもうぞ
c++よりrustのほうが良くなーい？と思っていてrustを本格入門している
さようならc++ perlみたくなるんじゃねーぞ
python は 10-20年程度で perl を駆逐出来たけど
perl や python は 20年以上経っても C/C++ を駆逐出来ていない
俺も rust はかなり気に入ってるけど、
だからといって C/C++ から全く離れようという気持ちにはならんな。
プログラミング言語なんて所詮は道具よ
ノコギリとハサミの間に優劣なんてないから
まあRustがC/C++の代わりになるのは無理だね。
へー、なんで？
最近Rust手つけようかなと思ってた
やりたければやれば良いだけ
なんで他人に確認求めるんだ？
>>834 ハード屋からすればアセンブラは基礎だが、その基礎と対応が明確なのはC。
対応関係が明確で闇が少ない。
もともとシステム言語としてはC++よりCが好まれているが、C++はCの延長線上に
あるのでなんとか使える。
しかし、C++もどうコンパイルされるのか分からことがあるという意味で「闇がある」と言われている。
ところが、Rustのsafeモードはアセンブラと対応関係が不明確だし、
仕様も非公開や曖昧なところがあるのでC++以上に「闇がある」ので
アセンブラの代わりに使うのは分かりにくいし危険だし、効率も良く無い可能性
が高い。ベンチマークは、Rustに都合の良いものが選べれていることが多いので
実際とは異なる。
linux kernel開発にrustが試験的に導入されつつあるが
c++は依然シカト状態
linusのこの判断が妥当と思うか不当と思うかでエンジニアとしてのタイプが大きく分かれる
カーネルモジュールの話なら、昔からC++で開発できるじゃん。
ところがrustはそうでなかった。APIの一部は直接呼び出せなかったり、呼び出すのが煩雑だったりした。だから対応方法検討してみようかってだけ。
検証結果が取り込まれて初めてc++に追いつくんだよ
C++利用者の層がクズだからKernel開発に使わないという理由は割とマジでがちだろうな
>>838 linux kernelだよ？
c++で開発されてるモジュールって何？
ランタイムどうしてんの？
>>840 最低限のライブラリのみをスタティックリンクしてるんでしょ
組み込みの開発したことないの？
>>841 linux kernelのモジュール開発したことあんの？
ないならすっこんでいてほしい
あるならそのc++で開発した事例を教えてくれ
>>844 そんな個人がなんとかハックしたおもちゃドライバでできると言われてもね
linux kernel のrustサポートと同列じゃないよ
どこがハックなんだろう…
まあ具体的に何がまずいのかも書けない時点で顔真っ赤なんだろうなw
そのブログにすんなりc++で作れましたよ〜って書いてあるようには全く読めないな
まぁそこを争うつもりはないので以後スルーで
STLのvectorのソース見てみたけど、解読がとても難しい。
listも難しかった。
一部のc++機能をcで無理やり実装しましたよ〜っていう馬鹿がよくやる種類の話だね。
>>847 争うつもりがないなら黙ってりゃいいのにw
>>849 お前バカ？
怒らせてしまった。やっぱ本当のこと言うのは良くないね。
C++でカーネルを書くとして
レイヤー的にSTLとか一切禁止になるんじゃ…
するともはやCに対するアドバンテージはクラスや仮想関数が使えることぐらい
だがそれあってもカーネル書くのに言うほどうれしいかどうか、、、
アプリケーション開発なら問題領域と解決領域をスムーズにつなぐのにクラスや多態性が役に立つが
OSのカーネルとなると信頼性と効率性が追求目標なのでアプリの設計とは様相がだいぶ異なるﾖｶﾝ
アルゴリズムとデータ構造の世界で今日日のアーキテクチャーの複雑なメモリモデルの
要請を満たしつつﾒﾁｬ枯れた書き方を要求されるしそれ以外の書き方をしたらリーナスに頃される
ﾊｽﾞ
>>854 テンプレート自体は使える
ただ、new/deleteや例外を使ってるやつも多いから使えるのはかなり限定されるとは思う
>>852 ダッサw
>>854 カーネルで糞重い仮想関数使うな、馬鹿。
おいおい
linux kernelの中はいたるところ仮想関数だらけですがな実質的には
vptrは使わないけど
そうだっけvptrって構造体に書かれているvptrでvtblを参照してさらにそのvtblに収容されているポインタを参照するわけだが
そんなことをするぐらいなら構造体メンバとしてポインタを持ったほうがなんぼかﾏｼ
※ 個人の感想です
なんでこんなC++を目の仇にしてるようなオッサンがわざわざスレみにきてるのかが謎だ
その精力を別のことに割り振ればもっと生産的なのに・・
>>860 virtualキーワード導入にあたってvtable方式に対する反対意見としてそういうのがあったらしいね
多態はクラスの特性かオブジェクトの特性かという分かれ道で
Smalltalkerあたりが言い出しそうなことだ
Smalltalker
昔あった東京や大阪の街情報誌みたいだなw
>>862 ちゅうか、お湯に入れたカエルは飛び出るので死なないが、
水から茹でたカエルはそのまま死んでしまうのと同じで、
昔のC++が好きで使っていたらいつのまにか全然違う言語になってしまって
嫌いになっているから。
私は C++ が ISO で標準化される前から使っているが今の方がずっと良くなってると思うんだがなぁ……。
まあ私はアマチュアだから業務での事情とかも知らんし、何か思うところがある人もいるのかもしれん。
保守性無視のアホ拡張ばかりでもはや業務では使えん。
多くのOSSのC++プロジェクトが担当してたPGがいなくなれば保守されず放置されるのは至極当然。
昔のObjective-C、C++、Java、Javascript、C#がそうであったように、オナニー拡張するなら改名して別言語にすべし。
テンプレートメタプログラミングのトンチ臭さがなんとも
ライブラリを使うだけの立場なら使いやすくなったと思うけど
テンプレート絡んだライブラリ作る側はしんどすぎる
デバッグつらい
確かに色々としんどい機能は多いのかもしれんけど、
それらの機能が必要なときに使わずに書くともっとしんどいでしょ。
全面的にメリットがないときなら使わないという選択もできるわけだし。
頓珍漢甚だしい。その拡張された機能が必要だったのは標準化される10年も20年も前だろう。
必要なときに用意しないで今更使ってくれと迷惑極まりない。C++標準化委員会のやってることは時代錯誤甚だしい。
過去のコード資産を全否定するような拡張するなら別言語にしろと言ってんだ。
てか、はちみつはマジで煽り抜きで
数万行以上のソフトをモダン(と、C++オタが信じてる)な書き方で作ってみたらいいよ
当然メタプログラミングにも挑戦して、だ
業務どうこうじゃなくて、ソフトを作る道具としての今のC++がどうなのかわかるから
>>875 新しい機能を (必要だと考えるまで) 使わないでいい自由があるということを
私は言ってるのにその返しはなんかおかしくない？
>>880 >新しい機能を (必要だと考えるまで) 使わないでいい自由がある
全部publicなのが問題
んまー低水準開発だと見えてほしくないものが見えてしまっている
レイヤーAとBの初期化が終わらなければレイヤーCの機能を呼んではいけないのに、
という状況は言語によらず普通に発生するから程度なのかもしれんが
C++はその手の罠が大杉問題、
最新のC++規格について行けている（ｷﾘ
と自称されている方々は、
単にOSが起動完了した状態での使い方に習熟しているだけではないのかどうなのか、
くだらねえ言いがかりだな
まあそんなことしか言うことねえのはわかるぜ
最大級に軽蔑する
このスレ観てたら C#++ とか産まれそう
と思った
>>881 プロジェクトのコーティング規約に従えよ。
プロジェクトのコーティング規約をしっかり定めさえすれば
空も飛べるはず、
>>870 まあ、配列が TYPE a[N][M]; ではなく、
vector<vector<TYPE>> a; // ???
が推奨された時点でもう、おかしいから。
しかも、このスレにはvectorと略さずに必ずstd::vectorと書け、とまで言う人までいる。
vector< vector <TYPE> > a;
はそもそも
TYPE a[N][M];
じゃなくて
TYPE *a[N];
だからなー
>>888 プロジェクトのコーディング規約に従えよ；；
iteratorの書き方も煩雑すぎ、長すぎ。
linked listの場合に効率悪すぎ。
ポインタも生ポインタ費推奨で uniqure_ptr, shared_ptrなどが推奨されているのも
既に言語として破綻してる。
ポインタはCの「命」なのに、unique_ptrなどと書くのは長すぎるので。
アメリカの学生は9割がポインタが理解できないので、
多数決で言語仕様を決定していくと、ポインタを徹底的に排除してしまう。
角度の Radian 法が理解できない人が、Degreeを推奨し続けたりしているようなもの。
AndroidのSDKは、それになっている。
馬鹿じゃないかと思う。
>>891 std::unique_ptr便利やん？
機能を使えるところまで持っていくのが面倒なだけで、
頭が悪い人は、ポインタの表記の優先順位を頭の中で「ほどけない」ので、
優先順位が馬鹿でも分かる
unique_ptr<unique_ptr<T>> p;
という書き方の方が分かり易く感じるのだと思う。
頭の良い人にとっては、ただ書くのが長くなっただけに過ぎないのに。
>>892 便利でも書くのが長くなった時点で駄目。
頭の悪い人は、長くても考える量が少なくなる方を好むから、
9割がベギナー止まりであるところのプログラミングの世界で多数決で
良し悪しを決めると長くても考える量が少なくなる方が人気を呼ぶことになる。
しかし、頭の良い人は頭のAIがすぐれているので、考えなくても瞬時に分かって
しまうので、読み解いたり自分で書くときに全く時間が掛からないので、
短くかけるほうが好まれる。
>>894 違うな。
実世界では天才と呼ばれているから。
>>895 長くなったことの問題はわかるけど
じゃあc++はどうすればよかったか代案だせんの？
余は真に驚くべき代案を思いついたが
匿名掲示板に書くには余白が狭すぎる、
>>896 ネットを除いたお前さんの実世界って、話す相手が自分自身かお母さんくらいしかいないんじゃないの？
>>891 生ポインタは言語仕様上、現在でも有効だし、合理的理由があればナマポを使うことを否定されるわけでもないのに、何が不満なのか分からんな。
>>882 グローバル変数やスタティック変数のコンストラクタに依存姓のある処理を記述して失敗しているのを目撃することはよくある。
でもそれはロード時に自動実行する機能のある言語では同様に起こりうることだと思うよ。
だいたいシングルトン多用するやつの仕業。
使うと恥ずかしくて死んでしまうようなパターン名ならよかったのに
std::vector ←イキってるだけのアホ
::std::vector ←こう書かなきゃ意味ねえだろ
メモ帳でコード書いてんの？
普通のエディタは補完が効くよ
>>896 そういうのならその証拠をみせてください
あなたのものの言い方は、どちらかというと反対側の人の言い方ですね
この板で一番馬鹿っぽいのに自分は賢いと思っているのが QZだ。
恐らく女。
女の中では賢いのかもしれないが、男の中では普通。
>>903 アドレスサニタイザー入れたらシンプルトン関連で例外だらけになった
やっぱ未定義動作なのね
>>909 ＞恐らく女。
面白い意見ですね、どのような推論からこの結論が導き出されたのか興味があります
>>896 ＞実世界では天才と呼ばれているから。
というのなら、その証拠を投稿内容で証明してみせてほしいですよね
>>909 を見る限り、私には馬鹿の同類項にしかみえないですね……
C++で食ってるフリーランスいる？
いくつでどういう技能を持ってていくら貰ってるか教えてくれよ
>>911 >＞恐らく女。
>面白い意見ですね、どのような推論からこの結論が導き出されたのか興味があります
普段から、馬鹿な応答が多かったし、
「自分でコンテナクラス(リストなど)を作れるから天才」
だとか、男だったら基本中の基本の出来て当たり前の事が出来るだけで天才と言っている
辺り、如何に周りのレベルが低いかが分かったから。
>>904 > ::std::vector ←こう書かなきゃ意味ねえだろ
えーキモいからやだ
:: が増えると tanasinn な感じになるな。
>>916 絶対パスのつもりらしいが絶対パスになってねえだろ
相対パスならusingしろ
絶対パスの面倒臭さと相対パスの曖昧さのデメリット両取りする間抜けな書き方すんじゃねえって話
stdが被る可能性はないに等しいのでセーフという合理性
あのなあ、ここ技術板だぜ？
合理性っておかしいだろ
>>920 技術板だからこそ、教条主義的な完全性より現実的な条件での合理的な判断があってしかるべきだと思うぞ。
プログラミングはサイエンスの部分もなくはないがエンジニアリング (またはテクノロジ) 寄りの話だろ。
一部の隙もない論理を構築したいわけじゃなくて問題を解決したいんだ。
で、 std のかわりに ::std と書くことで解決される問題が
このスレの誰かの前に出現したことがただの一度でもあると思うのかね？
トップレベル以外の名前空間に std が現れるのは仕様で禁止されていないっぽいから、
そりゃあ可能性だけで言えば絶対にないとは言えんだろうが、
現実にはこの二者がいたらどちらがよりクソだと思う？
・ 変なところに std という名前空間を作るやつ
・ ::std と書かずに std と書くやつ
前者があまりにもクソすぎるのでそういうやつはおらんだろということで
だいたい上手く運用できておるのや。
自己弁護にしか聞こえねえな
"今までそうやってきたから正しいことにしたい"
批判的な相手がそれで納得するとでも思っているのか
いっそstdをキーワードにすればって話ならまだわかるぜ
おまえらの論法で言うところの関数名やオブジェクト名をstdにはしねえんだから
下線で始まらないoperator""をstd以外には作らせないこともできるね
>>923 そうだよ。
std という名前を作らないか ::std を使うかのどちらかが達成されていればよく、
std という名前を作らないという習慣で今までやってきるのをあえて乱したいのはなんで？
っていう話だよ。
::stdってしてたら逆に何こいつイキってんの？って思うけどなｗ
>>923 どちらかが正しいと言ってるんじゃなくて、一貫させることが正しいと言ってるんだよ。
移行コストを支払って得られる何かがあるなら検討はするよ。
何かいいことあるの？
>>923 世の中には話の通じない相手がいるのは分かってるし、そんな相手を納得させることに無駄なエネルギーを費やす価値はない。お前さんが納得しなくも他の誰も困らないからどうでもいい。
というのも合理性だなw
「合理性」を咎められたのが余程効いたようだな
意味をここでだけ変更したくてそんなに必死になるのは
そういう手合いはstdの意味をここだけ変更もしかねねえな
>>928 どちらが正しいかって論点では分が悪いもんなｗ
::stdって自己満でしかない
リターンがない
特に困ってない問題を解決したところで人生の無駄遣い
そこがんばったところでアホなマクロがひとつ混ざれば破綻する可能性はあるわけで
ある程度の良識や常識に依存するのは仕方ない
可能性のスケール感を考えられるかどうかとも言える
まぁやめろとは言ってないんだから好きにすればいいじゃん、ひとりで書いてる限りは
実害が出る前に予防的措置ということはあるぞ
それから俺は既存のコードを書き直せなんて言ってない
そんなのはてめーらの勝手だ
アカデミックな目線でおかしいと思うところを批判しているだけだ
代替案も出してる（採用されるか否かはともかく）
>>935 もっと広範囲に std という名前を禁止する提案はもう出てるよ。
言語仕様として良くなかったというのは言わなくても皆がわかってるので、
そんなに強くいわなくてもいいよ。
C++ の仕様がグダグダなんていうのは今更のことじゃん。
その上で、 std という名前を定義しないという運用上の習慣は確立してるって話。
そもそもstd名前空間(::stdじゃなくて)の拡張は未定義じゃね？
(17.6.4.2.1 Namespace std)
何のためにstd名前空間を定義するの？
茨木が
いばらき
なのか
いばらぎ
なのか
くらいどうでもいい
例えばstd::swapで自分のクラスの交換を定義したい、ってケースが考えられる。
>>939 その std は ::std のことやで。
その std を拡張することは禁止されているが、
別の名前空間の下に std という名前空間を作るのは禁止されていない。
using namespace で std を含む名前空間を取り込んだ上だと ::std でなく std という表現をすると
標準ライブラリの std でないものを指す可能性があるというのが今の話題。
でも禁止されてないからといって std という名前を付けるやつはおらんから気にするだけあほらしいでというのが反論。
>>935が言ってる採用されるか、てのは「相手が」だと思うが
C++標準の話ではないやろ
>>941 std (::std) に定義を追加することは禁じられているが特殊化を追加することは禁じられていなかった。
しかし C++20 からはこれも禁止になる。
カスタマイズポイントという仕組みが用意されたのでこれを使うのが (今後は) 望ましい。
>>942 C++標準にnamespace std を ::stdとする定義ってあったっけ？
『standard libraryの名前xは ::std::xとして定義しろ（20.5.1.1.3）』
というのはあるけど、namespace std = ::std という定義じゃないよね？
最近は標準を読んでないから見落としあるかもしれんが、
ざっと見た範囲では無さそうだった。
>>945 そう。
using namespace std; の std が ::std でないものを指す可能性があるが、
拡張を禁じている std というのは ::std のことなので、
大元の議論は ::std を拡張するなんていう話はしてないという指摘をしてる。
ID:FCbCRYtX さんはグローバル以外で自分のコードから見えるスコープに誰かが
std という名前を宣言している可能性も考慮して万全の策を取っているんですね。すごいなぁ。
ということは当然、誰かが #define std ... している可能性も考慮して
::std を使う行の前には必ず #undef std も書くのでしょうね。すごいなぁ。
「::」って打つのは超々々多大なコストですもんね。すごいですよね。
>>946 16.5.4.2.1 Namespace std
Unless otherwise specified, the behavior of a program is undefined if it adds declarations or definitions
to namespace std or to a namespace within namespace std.
で、::stdの規定があるのは
16.5.1.1 Library contents
Whenever a name x defined in the standard library is mentioned, the name x is assumed to be fully qualified
as ::std::x, unless explicitly described otherwise. For example, if the Effects: element for library function F
is described as calling library function G, the function ::std::G is meant.
だけだから、拡張を禁じているのが::stdだけというのは言いすぎじゃね？
標準化の経過を追っているわけじゃないからこの解釈が妥当か知らんが。
>>942 反論なら論で来いよ
あほららしいなんて感情ではなく
>>943 「相手が」stdをキーワードにできると思うのか？
>>950 >>939でほぼ確定だろ。
namespace std == ::std
なら話は別だが、それは無さそうだし。
>>952 俺だけでなく
>>946もそうは見ていないようだぞ
C++14の時点では考え落とされているから言及がないだけだろ
それとも、どこかに議論された形跡でもあったのか？
>>953 反論なら論で来いよ。
標準で議論されていないなら標準の文言が全てだろ。
>>949の通り、標準の文言だと明らかに
namespace std != ::std
として扱われているんだから、反論するならそれを否定する
namespace std == ::std
の証拠を持ってこいや。
>>954 標準ライブラリのxは::std::xだと書いてあるやん
>>955 16.5.4.2.1で拡張を禁止されているのはstdと名前の付いた名前空間で、::stdに限定しないだろ。
と言っているんだが。
反論するなら、標準で
namespace std==::std
としている定義を持ってきてくれ。
話が噛み合ってないな
考え落としで言及がないだけだろと言ったはず
あくまで推測だけどね、考え落としていないとわかるものがあるなら拝見したい
>>958 標準化委員じゃないんだから、議論したかどうかなんてクソどうでもいい。
「::stdじゃないと意味ない」とかいう話をしているんだから、まずは標準でどうなっているかだろ。
標準で「namespace stdを拡張すると未定義」となっているなら、::stdに限らず未定義としか言えんわ。
反証するなら
namespace std==::std
とする証拠を出せよ。
話の流れとはずれますが、C++の仕様の確認のための質問をします。
namespace AAA {
void func() {
std::vector<TYPE> v;
}
}
と書いた場合、コンパイラはstdをAAAの中に最初に探し、AAAの中に見つからなければ
「グローバルな名前空間」から探すので、AAAの中にstdが見つからない場合でも、
::std と書かなくてもエラーにはならないんですよね？
>>959 いやいや、自然言語で書かれている以上は文脈・意図を全く考慮せずに読み解くことは出来んよ。
そんなこと言ったら add という言葉の意味が仕様書内で定義されてるか？
とかいう話にもなりかねんわけで。
仕様書という性質上、なるべく解釈の幅がないように書くべきではあるが、
不確かな場合はどうしたってあるし、経緯に遡って解釈することだってあるよ。
>>961 [捕捉]
ファイルのパス名の場合、/std と書くとルートから探し、stdと書くと
カレントディレクトリから探すだけでルートは探しませんが、
C++の場合、stdと書いても最初は「カレント名前空間」から探し、
見つからなければ、見つかるまで「親の名前空間」を連鎖的に探して
行くのですよね。
この違いは気を付けなければなりません。パス名との類推から、
ややもすればうっかり混同してしまいそうです。
>>962 今回の件と関係するのかね？
極端な例で反論したつもりになられても議論できんわ。
文脈の話をするならば、標準の記載では入れ子になったnamespace Nもnamespace N表記なんだから、特に記載の無い限り入れ子になったnamespace stdもnamespace std表記だろ。
namespace stdを
::stdに限定するなんて、標準の文脈からすればなおさらありえん。
UBIとかEAのような大規模ゲームってどんなコードで作られてるの？
きっとmain関数の中にスレッドループがあったりはしないんだろうな
タイトル画面ですら複雑な処理してそう
メインループは回すよ
回さなかったら終了するじゃん
まぁspawnしてjoin待ち見たいなのもよくあるけど
>>927 そんなコード見たら虐めちゃうけどな
なんかイラッとするわ
>>974 俺のみたところ餃子はだいたいまともな事を言っている
ただし lisp シンパなのはまったく理解できない
C++の知識はちゃんとしたものではあるが、それ以外の事は必ずしも
正しくはない。
>>977 ワイは Lisp 全体に対してはそんなに関心ないわ。
Scheme を好きで使ってるから結果的に周辺の情報に少し触れることもあるって程度。
>>981 そうは思わない。
少なくとも、日本には役立っていると思う。
lispは数学的には美しいけど実用の道具としてはカス
このスレの主要なコンテンツ
・不毛な議論
・０７２/マウントみたいなレス
・昔話
質問に答えているのはマウントではなく、国の衰退を防ぐためとか、
プログラミング産業を盛り立てるためとかもある。
そんな崇高な理念を持ってる奴いねーよ
ただマウント取りたいだけ
はちみつ爺さんは世界平和のために書き込んでるんだぞ
>>988 普通にいるぞ。
崇高と言うのとはまた違う。
なぜなら国の衰退や、産業の衰退は、必ず自分にもマイナスになって帰ってくるから。
この板が荒れれば、日本も衰退し、やがて自分の将来も暗くなることは
予想できる。
たとえば、プログラミング学校、プログラミングの支援ツール、
ゲーム作製ツール、プログラミング言語の解説本、プログラミング処理系
などを仕事にしたり作製したりしている人にとっては、プログラミング
している人を支援することはプログラミングが好きな人を増やし
やがて自分も潤うと考えられる。
だからこのようなスレや板で質問に答えれば彼にとっては得になる。
>>990 数学者の藤原正彦氏のようなことをいってますね‥‥
>>992 あの人は、実は人の気持ちが分からない人。
京大生に昼休みの始まりに小学生レベルの分数をさせて、時間がもったいないから
無回答で出て行った人が多かったのに対し、「小学生レベルの分数の問題が解けない」
と本に書いた。
， ，:‘. 。 + ，..
’‘ + ，.. . ..; '， ，:‘
. .; : ’ ' ，:‘.
あ あ ，:‘. +
.. ' ，:‘. . ...:: ’‘
’‘ .; こ ん な に お 断 り し た い
。
. 。 気 持 ち に な っ た の は ，:‘. 。
'+。
初 め て で す .. ' ，:‘.
:: . .. .. ' ，:‘.
ﾊ,,ﾊ
( ﾟωﾟ )
>>991 英会話教室関係者と似たような構図にしか思えない
>>993 それは多分別の人だと思いますよ
藤原氏は「アメリカの学生は分数がわかっていない」と昔のエッセーに書いていたのは記憶していますが、
一般の日本人の「数学力」を腐す論調ではなかったと思います
彼のいうことは唯一つ、なんでもいいから「本を読め」、「本を読め」、「本を読め」、「本を読め」、「本を読め」、「本を読め」、「本を読め」、「本を読め」、「本を読め」、「本を読め」、「本を読め」
lud20241205155809caこのスレへの固定リンク： http://5chb.net/r/tech/1594528940/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「C++相談室 part152 ->画像>3枚 」を見た人も見ています：
・C++相談室 part137
・C++相談室 part126
・C++相談室 part142
・C++相談室 part143
・C++相談室 part135
・C++相談室 part138
・C++相談室 part144
・C++相談室 part147
・C++相談室 part136
・C++相談室 part154
・C++相談室 part159
・C++相談室 part151
・C++相談室 part158
・C++相談室 part150
・C++相談室 part153
・C++相談室 part162
・C++相談室 part156
・C++相談室 part163
・C++相談室 part149
・C++相談室 part124
・C++相談室 part161
・C++相談室 part148
・C++相談室 part160
・C++相談室 part133
・C++相談室 part131
・C++相談室 part140
・C++相談室 part137
・C++相談室 part130
・C++相談室 part117
・C++相談室 part134
・C++相談室 part146
・C++相談室 part145
・C++相談室 part132
・C++相談室 part141
・C++相談室 part139
・0からの、超初心者C++相談室
・C++Builder相談室 Part21
・Cygwin + MinGW + GCC 相談室 Part 8
・Cygwin + MinGW + GCC 相談室 Part 3
・C♯相談室 Part20
・C#, C♯, C＃相談室 Part93
・C言語相談室(上級者専用）
・自営業 悩みごと相談室 40
・自営業 悩みごと相談室 47
・ライダーマンのお悩み相談室
・C#, C♯, C＃相談室 Part91
・C#, C♯, C＃相談室 Part97
・C#, C♯, C＃相談室 Part94
・[特設]サマータイム対応相談室
・C#, C♯, C＃相談室 Part79
・C#, C♯, C＃相談室 Part75
・自営業 悩みごと相談室 43_
・C#, C♯, C＃相談室 Part90
・0からの、超初心者C#相談室
・C#, C♯, C＃相談室 Part96
・C#, C♯, C＃相談室 Part95
・C#, C♯, C＃相談室 Part95
・C#, C♯, C＃相談室 Part94
・【不倫.浮気】お悩み相談室
・【スキー】初級者アイテム相談室４【板靴何でも】 [無断転載禁止]
・アパートマンション経営なんでも相談室【154号室】
・♪♯☆ IRCnet相談室 part2 ♪♯☆
・アパートマンション経営なんでも相談室【146号室】
12:54:28 up 11 days, 13:58, 2 users, load average: 10.77, 9.90, 10.10
in 0.079171895980835 sec
@0.079171895980835@0b7 on 012502
|
ブックマークへ