C++相談室 part138
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part137
http://mevius.5ch.net/test/read.cgi/tech/1531558382/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1530384293/
■長いソースを貼るときはここへ。■
http://codepad.org/
https://ideone.com/
[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured >>148
https://code.woboq.org/llvm/libcxx/include/chrono.html
↑によれば、以下の様になっており、time_point は、一般的な
template の time_point<・・・>とsystem_clock::time_pointは
厳密には「別」で、後者は前者を特殊化したものを typedef宣言
している。そのため、 std::chrono::system_clock::to_time_t()の
(メンバ)関数宣言の
static time_t to_time_t(const time_point& t) noexcept;
のtime_pointは、chrono::time_point<system_clock>という
system_clock専用になっている。それが原因で>>147は
エラーを出すらしい。
class system_clock {
public:
・・・
typedef chrono::time_point<system_clock> time_point;
・・・
} そう思ってtime_point_castしてみたんだが、それすら通らない。。。 >>150
time_point_cast() は根本的な「Clock」の部分は変換前後で共通の場合のみが
実装されているようです。なのでどこまでの細かい時間を表現できるかの
「時間精度」は変更できても、表現の違いのようなものまでは対応できないのかも
知れません：
namespace std {
namespace chrono {
template <class ToDuration, class Clock, class Duration>
time_point<Clock, ToDuration>
time_point_cast(const time_point<Clock, Duration>& t); // C++11
template <class ToDuration, class Clock, class Duration>
constexpr time_point<Clock, ToDuration>
time_point_cast(const time_point<Clock, Duration>& t); // C++14
}} テンプレートとマクロのメリットデメリットって他にありますか？
またテンプレートとマクロの使い分けで悩んでいます
マクロのメリット
・一括置換ができる
・文字列も使用できる
・定数式にも使える（配列の要素数）
マクロのデメリット
・数式が複雑なときにミスをしやすい（＋＋を渡してはいけない、演算優先順位がミスしやすい）
・型の識別ができない
・一行記述なので大規模なのには不向き
テンプレートのメリット
・名前空間を定義できるので影響範囲をとどめやすい
・型の識別ができる
・関数なので大規模なのも書ける
テンプレートのデメリット
・定数式にしようできない
・ユーザー定義と標準定義が混ざったときのエラーを判別しにくい
こんなメリットデメリットだと思っています。
他にありますか？？
これを踏まえた上で使い分けとしては、
マクロは文字列などの簡単な定義に向いていて、テンプレートは処理（演算）を含むものと考えているのですが、
他に観点あるでしょうか マクロのデメリット
・スコープに従わない ←致命傷
・デバッガとの相性が極悪 >>152
「他にありますか？」の答えにはならないんだけど・・・
> テンプレートのデメリット
> ・定数式にしようできない
そんなことなくね？
> ・ユーザー定義と標準定義が混ざったときのエラーを判別しにくい
どういう状況のこと言ってるのかよくわからないけど、マクロにすればわかりやすくなる状況なのか
怪しい気がする。
ってことで、使い分けとしてはマクロでしかできないこと（トークン連結・文字列化）以外は
テンプレート使うとしたほうが簡単だと思うし、よく聞く話。 マクロはコンパイラが展開後のコードを見せてくれるけどテンプレートは見せてくれない 展開じゃないからな
typename Tに何が来ているかなんてのはcout << typeid(T).name()で監視できるんで
iocccなみに解読困難なプリプロセッサ出力がないからって困りゃせん その監視というか確認の煩雑さは、マクロの方が面倒だろに。 >>152
マクロは、テンプレートのメタ側に位置する機能なので、テンプレートに出来ない事や、テンプレート自体のコードに変更を入れる場合につかうと良い。
まあ、リテラルレベルの置換と、プリプロセッサの入力に使えるってくらいかな。
よく使うのは、コンパイルスイッチくらいじゃないかな。
極稀にリテラルを文字列化したり、リテラルレベルでトークン連結処理したりするくらいかな。
定数はぶっちゃけどっちでも良いけど、式を含むならconstexpr を使うのが c++11の流儀。 >>159
こんなクソみたいな記述入れて一旦ビルドして確かめるとか正気の沙汰じゃねーわ。
cout << typeid(T).name()
マクロもたいがいダメだろうがこれをやらせるって歪んでるとしか思えん。 一旦ビルドしてって、テンプレートはコンパイルしないと何が来るかなんて分からんだろ
＞マクロもたいがいダメだろうが
とか雑な切り捨てしてる辺りからしても、めっちゃ初心者とみた >>161
何がどうクソなんだ？
おまえさんのルールの何条に違反しているんだ？ >一旦ビルドしてって、テンプレートはコンパイルしないと何が来るかなんて分からんだろ
だからこれがしょうもないってことを言ってるんだが。
静的にコード見て判断しずらい仕組みをなぜ疑問なく使えるのか、そっちのがよっぽど素人感丸出しだよ。 へー、判断しづらいのかｗ
おまえさ、C++に向いてないよ
もうやめたら？ 横からすまんが
cout << typeid(T).name()
はくそださいと思う 宣言だけのテンプレートを使ってエラー吐かせてクラス名確認するのはわりとやる ダサいと言っているその姿がダサいことにくらい気がつけよ
技術板で客観性を全く欠いた戯れ言ぬかしやがって >>164
＞静的にコード見て判断しずらい仕組みをなぜ疑問なく使えるのか
これにはテンプレートも含むってこと？
それならまぁ言いたいことはわかる >>161
言ってることは当たってる。C++は、というか、正確に言うと、C++のスレは歪んでる。
C++ってのは結局のところ、何でも出来るように設計されている。
だから、ユーザーがその機能を使うか使わないか、よくよく考えないと逆に色々面倒なことになる。
マクロもテンプレートも上手く使えば素晴らしいが、濫用すると余計に酷くなる。
○○を使えばいい、とか、逆に、○○は禁止、とか、（本来は）単純に切り分けられるものでもない。
この辺は他LL言語やJava/C#等は最初から使える範囲が決まっており、
C++から見ればかなり制限されているから、濫用は出来ない。
結果、「C++の酷いコード」よりは「C#の酷いコード」の方が数段ましなものにはなる。
逆に言えば、C++はプロ仕様で、
自身でコーディングルールをそれなりに決められる人じゃないと適切には使いこなせない。
実際の職場では大概はがんじがらめのルールが決められているはずで、
C++でコーディングルール無しのところなんてないのではないかと思う。
ところがC++のスレは勘違いした素人が多いのか、
C++の新しい文法や小手先テクニックを使って書くことが目的になっている奴が多い。
そして「長期的な保守」を全く考慮してないレスも散見される。
だからここではそういう雑音もきちんと峻別する能力が求められてしまう。
といってもそれもC++の範疇で、つまり「自分で判断しろ」でしかない。
無理ならC#等そういう「馬鹿が使ったらどうしようもなくなる機能」が最初から用意されてない言語を使え、でしかない。
ここで素人相手にマウント合戦なんて意味無いから止めとけ。
> 静的にコード見て判断しずらい仕組みをなぜ疑問なく使えるのか (>>164)
この基準は正しい。
テンプレートに問題があると認識されているのは昔からだ。
ただ、テンプレート以外に上手く同等のコードを得る方法がないから、それでもテンプレートは使われている。
いずれにしても、その機能をどこまで使うかは君が判定するしかない。
実際に動かさないと何が当たっているか分からないテンプレートなんて事実として糞だが、
それでもその方がましならそういう書き方をするときもあるだろう。
全体を見ず、個々の末端の事例でグダグダ言い争っても意味はない。 上っ面しか見てねえやつだな
長期的な保守性という要求から色んな仕様が発明されているのに
ついていけねえ低脳が被害者面しやがる おまえらもういいから、ずーっとC++98使い続けてろよ
それで食っていける仕事があるなら俺たち別に非難しねえ
非難てのも変だけどな >>172
お前最低限メタプログラミングは出来てて言ってるんだよな？
stlとか新機能使ってるだけとか自分で人様に使われるライブラリ書いたことない、とかじゃないよな？ >>175
stlが新機能って・・・・おまえいつから更新停止してんだ？ >>171
だいたい納得。
別にstl使うなとかそこまで無茶は言わんよ。
unique_ptr なんかも使っていくのは良いと思うし。
ただおれおれ糞テンプレートライブラリは使いたくねーわという話。 アンチテンプレート厨はenable_ifになぜ_tがあるのかとかわからんだろ そこだけ泥縄で調べて何かぬかすんだろうけど
言ってることの全体的な薄っぺらさはどうにもならねえぜ >>157, >>181は別人だと思ってたんだが違うのか
＞enable_ifになぜ_tがあるのか
別にアンチじゃないけどそれはある程度基礎が出来てる人には常識だとおも >>180
まあそうなんだが、unique_ptrとstlで大体いけるならPython/Ruby/Java/C#で全く問題ないし、
それらを使う方が断然生産性が高い。
だから逆に、C++を使うのならそれなりの理由が必要で、
通常それは速度、つまりゴリゴリに手動チューニングしてでも最速を得たい、ということなのだが、
C++のスレは「ナマポは撲滅されるべき、今時スマポ使わないなんて話にならない」だから終わってる。
ナマポを混在させられることがC++のメリットだし、それを使わなければC++使う意味ないと思うが。
あと、C++が導入したのは「オブジェクト指向」と「テンプレート」だが、
オブジェクト指向の方はほぼ全部のメジャー言語に採用されたのに対し、
テンプレートの採用は皆無だろ。出来も推して知るべし。
生産性を追求するC#、安全性を追求するJavaからは要らない子扱いされてるのが現実だ。
個人的に思うのは、超最速を目指さない限りC++で全部組むのはナンセンスで、
GUI部分とかはPython等で楽に組んで、演算部分だけCのDLLを呼ぶのがいいと思う。
Cは大規模コードを組む為の仕組みがないので次第に大きくなってくるとなかなか厳しくなるが、
この方法だと各DLLは1k行程度で済むのでCでも問題になることはない。
なお手動チューニングするならCの方が楽だ。
C++はコンパイラが最適化する前提でテンプレートを重ねがけする事が常態化しており、
ソースコードからどんなオブジェクトコードが生成されるかが読みづらい。
といってもこれはCはあんまり最適化しないからであって、
糞コードであっても速いオブジェクトが出る可能性のあるC++の方が断然いいのも事実だが。
（Cは糞コードなら糞オブジェクトしか出ないが、C++はコンパイラでの最適化がかなり期待できる局面もある）
なお今から学ぶならRustもありだと思うぞ。
unique_ptr基本で組むようにデザインされている。（らしい）
問題はRustは本当に立ち上がるか微妙なことだが。
C++が悪い点は多々あるが、それらって結局、そういう書き方をしなければいいだけでしかなく、
結局のところこれがCもC++も(Rustが立ち上がったとしても）死にきらない理由でもある。 >enable_ifになぜ_tがあるのか
こういうのを知ってウキウキするのはよくわかるよw
https://www.fluentcpp.com/2018/05/18/make-sfinae-pretty-2-hidden-beauty-sfinae/
でもいらん機能を無理やり現場に持ち込んで他人に迷惑かけるのは筋違いだから。 はいはい
テンプレート(もちろん自作の)バリバリのコード書いて
それがどれだけ開発効率に影響与えたか、コスト掛けた価値がどれだけあったか
客観的に言えるようになってからほざいてね 本末転倒もいいとこだな
いいか、最も肝心なことは何を実現したかと成果物の質だ
開発効率だのコストだのはその次に考えることで
そこに振り回されて本分を投げちゃいけねえ 都合のいい抜き出し方をするな
その成果物の質のために、どれだけの時間と労力を掛けて
それが質の向上に見合ったものかを客観的に見れるようになってから言えといってんの 別にテンプレート使うなって言ってんじゃないよ
使ってごちゃごちゃ作るからにはそれが本当に後々まで使える便利なもので、
ゆくゆくは長い開発期間を償却できるレベルなのかどうか、そこまで考えると、普通は判断は難しい
テンプレート使う奴が実力あるやつで、やめとけと言うのは老害とかそんなアホな話は有り得ない 経営者目線ならこっちは自営で
ニートのご高説は無用だ ははは、自らの主張を引っ込めたな
そうなるしかないんだけどな ?俺>>184だよ
テンプレートバリバリ使ってコストのバランスに毎日悩んどるわ
ちな俺も自営、元は会社でチームでやってたが >>189
アウトプットを最大化するために効率をあげるんだが そういって腐ったテンプレートを残していった老害を何人も見てるからな。
下の世代がまた同じことを繰り返そうとしてたらそりゃ文句の一つも言っとかなきゃあかんだろ。 今ここで為されている議論ももう何回目だ？だし、積極的に続ける意味はないと思うが。
そんなに気になるなら他人のコーディングルールを確認してみればいい。
例えばgoogleのテンプレートについての記述は以下。
https://ttsuki.github.io/styleguide/cppguide.ja.html#Template_metaprogramming
まあそうだよね、程度だが。
個人的にはリファクタの障害になるのが致命的だと感じる。
max_fやmax_iなんてやるのは馬鹿みたいではあるが、
しかし検索は簡単で、変更時の影響範囲も明確に分かる。
これはLinusも同じ事を言っている。
C++は若干コードに執着しすぎている。
泥臭くも書けるところを無理矢理綺麗にしようとして、余計に複雑になっている。
具体的に言うと、記述を１ヶ所に絞る為にテンプレートを3回重ねがけ、なんてのは割とある話で、
それなら数ヶ所ならベタで書いてしまって「同じ記述が○○にもあるから変更するときは注意しろ」と
コメントに書いてしまうというドベタな解決策も採れるわけだが、C++はこれをよしとしない。
(Cの場合はこの場合はマクロにしてしまって１ヶ所に纏めたりする。
これはこれで問題はあるが、それ以前に意識高い系C++erではマクロは禁止だし）
ただ現実的には、C++は上記「コメントで対応」「マクロで対応」「テンプレートで対応」のどれも出来る。
だからユーザーが適切に選べばいいだけであって、
より本質的な問題は、「こう書くべき、じゃないと認めない！」
みたいな意識高い系馬鹿がC++にも進出してきたことではある。
色々な書き方が無駄に出来てしまうC++は彼等にとってはそれなりに居心地がいいのかもしれない。
だからそういう馬鹿に流されず、「俺流のC++はこう」みたいなのが出来るのならそれでいいと思うが。
同じ話はconstや例外にもあって、それらも結局煮え切らない議論になってるだろ。
googleはconstは推奨、例外は禁止、のようであるが。
https://ttsuki.github.io/styleguide/cppguide.ja.html#Use_of_const
https://ttsuki.github.io/styleguide/cppguide.ja.html#Exceptions googleの例外禁止は古いコードが例外対応していないため、改修が辛いと言う消極的理由だけどね >>199
しかし例外が素性が悪いのも事実だろ。
そして現在のソフトウェア工学はこれに対する解をまだ提供できてない。
オブジェクト指向は各オブジェクトを基底側のクラスで抽象化して統一的に扱えるからいいのであって、
例外は基本的に派生クラスでの対処が必要だから全く馴染まない。
そしてこれがJavaで繰り返されてる
「例外でコケるの止めてくれない？」「えっと？握りつぶせばいいですか？」
の根元だろ。
かといってC流のエラー番号＆毎回いちいちチェック方式がいいというわけではないが。
C++流のオブジェクト指向はほぼ全てのメジャー言語に広まった。これは出来がいいからだ。
同様に、ラムダも出来がいいから最近採用されまくってる。
C++が当初これを持ってなかったのは結果的には単にC++が馬鹿だったからでしかない。
テンプレートも同様で、広まらないのは出来が悪いからでしかない。
例外がイマイチなのは、そもそも出来が悪いからだ。
そして本質的に、例外方式では非同期/ベクタ(SIMD)には対応できない。
同期で済むところを非同期で書かされるJavaScriptも相当ウザイが、
今後のプログラミングのトレンドが
マルチスレッドによる非同期やGPU活用の為のベクタライズ(SIMD)に進むとしたら、
今現在の『旧式』の例外をコードに含まないようにしておくことはかなり意味がある。
googleが過去にこだわっているだけだと見るのは勘違いだと思うよ。
まあいずれにしろ、C++は今後とも「全部入り、使うかどうかはおまえら次第」を目指すようではあるし、
そういう言語が一つくらいあってもいい。
だからこそ、各自でその機能をどこまで使うべきか考えないといけないし、
それを適切に出来ない人は、
誰かのコーディングルールに乗っかるか、C++を使うのを止めるかした方がいいと思うが。 >>194
おまえさ、そんなすぐ目先の損得に頭を占領されてんの？
同じ「コスト」って言葉を使ってるけど、なんか全然意味違いそうだな
５年１０年単位の長い波長を持つ金の津波をどう起こすかって話と
ずいぶんズレて聞こえるんだが >>202
俺が言ってんのは開発期間(見積もり含め)とかの話な
お前多分だいぶ規模小さいだろ
だから無条件にテンプレート崇拝できるんだろうな >>197
別にお前に言ってないけど図星突いちゃったか 規模が大きいって、template使わないから規模が無駄に大きくなっているだけだろ
コピペ改変繰り返したような糞コードの山みたいな >>203
ああ、やっぱりそうか
５年１０年つってんのに規模がどうたらとか
マジその日暮らしなんだな
同情はできるぜ、俺だって死にそうに苦しい時あったからな うちの会社にもなんでもかんでもテンプレートで定義する奴いるけど、
ほとんどのテンプレートが実際には１つの型でしか使ってなかったりするｗ は？
まぁ自営歴はそっちのが長いかもしれんが
>>186に対して>>187を書ける根拠が知りたいね
くだらないことでマウントかましてきたからやり返すけど、お前チーム開発の経験はあるんだろうな？
自分が開発したライブラリ(もちろんテンプレート使った)を人様に使わせたこともあって言ってるんだろうな？ あ、あと>>204は読み間違いだったわ、すまんorz >５年１０年単位の長い波長を持つ金の津波をどう起こすかって話と
名言ｋｔｋｒｗｗｗ
金の津波ｗｗｗ
それを考える奴がC++のソース書くのは時間が勿体ないよｗｗｗ なんでも良いだろ。
デバドラ書いてる俺はいまだにCだよ。 理解してないバカがいるかぎりは何度でも言う。
てか google c++ の規約くらい読めばいいと思うよ。
実際、ためになるし、この手の文書にしては相当簡素で物量で圧倒されるようなもんでもないし。 ちょっと悪意ある実例かもしれんけど、
仮にメモリリソースを標準ヒープ限定にしないよう、任意のアロケータを使ったstring, vectorを
受け取る関数を書いたとして（いずれのデータも結構大きい可能性がある）、
https://wandbox.org/permlink/wGxcWDrAvb93ptzD
↑のようにテンプレート化した途端に、簡単なリテラルや初期化子リストからは受け取れなくなる
（もちろんstd::string(), std::vector<hoge, allocator<hoge>>{うんたらかんたら}とすれば通るが）
むやみにテンプレートマンセーして、ちょっと否定的な意見（しかも経験豊富な人からの）を見ただけで火傷起こしてるバカどもは
この程度の（自分でテンプレート使って汎用性求めればすぐわかる）デメリットにすら気付いたことがないんだろう
（こんなんだったらポインタで受け取った方がマシ、この場合は。） ちなみに、こういう任意のリソースを受け取るということについていちいちテンプレート化しなきゃいけなかったという
STL周りの不便さを改善すべく、新しいリソース管理クラスが導入されたけど
Alex Stepanovや標準化委員会も、allocator周りは失敗だったと思ってるんだろうな
あと、>>187も含めテンプレートマンセーしてる初心者は知らんだろうけど
STLは構想から含めて十年以上かけて作られた代物だからな、ある意味優れてて当たり前
そんなライブラリでも改善すべき点は見つかるんであって、ろくにテンプレートライブラリ書いたことも無いやつが権威を笠に着るなと言いたい
その上で「お前らその開発期間を償却できるほどの設計センスと経験、責任感があるんか」と問いたい
>>212
自営業といっても全然関係ない業種の趣味グラマだったりして それ目的に対してテンプレートの書き方が悪いだけじゃね？ StringTとかArrayTとかもっと雑に受け取れってことやろ？
わかるけど、その先で全部統一した一つの関数テンプレートで処理をまとめられるとは限らない
結局泥臭いコンパイル時分岐を書かなきゃいけなくなることもある >>215
ちょっと趣旨から脱線して申し訳ないが、
そういえば独自アロケータを与えられるのもC++の特長ではあったか。
となると、C++をどうしても使わなければならない局面は、
・ナマポとスマポの混在
・独自アロケータの使用
とかかな？
ただまあ、責める気はないが、
独自アロケータについては他言語は対応してないと思うので、
この場合はstlやテンプレートがどんだけ糞であろうが頑張ってC++で書くしかない。
勿論、色々改善する余地はあるとしても、
他言語がいわゆるシステムレベルプログラミング（≒OSそのものを作る）に
対応していないのだから選択の余地はない。
まあLinusに言わせればC++もシステムレベルプログラミングには使い物にならない、とのことだが。 >>218
雑というかSFINAEで制限しろという
まあ、conceptくるまで汚くて面倒なのは仕方ない 大体1の方しかなかったら、無駄にヒープ使われるだけで、それこそ望む挙動にならないような SFINAEで対応とか、c++のオーバーロード、ならびにrvalue周りの仕様を
全部読み、かつ現実のソースをすべて読むのにどれだけの物量かかるか少しも想像してないんだろう。 >>219
いや、悪意ある例と書いたけど
どう確保したかに関数側が興味ないのであれば＆特殊な用途でなければ素直にポインタでいいし
>>216で挙げたPolymorphic Resource使えばテンプレートにする必要すら無いんだけどね（実際めっちゃ便利）
標準ヒープを前提にした設計＆サンプルコードなんかの綺麗な例のようなSTLの使い方しか
したことない初心者には全くそういう問題が想像つかないんだろうなと言いたかった
テンプレート使って設計するのはめっちゃ時間かかるし、そこまでする価値があるのかどうかというのは
今どきのC++でのコーディングには避けられない重要な判断だと思う
（そういう判断放棄して古臭い書き方してる職場が多いのは、決しておかしな話ではない）
>>220
＞SFINAEで制限
まぁその方が理想的なんだろうね（ある程度差異を吸収する関数はあるし） 仕様全てとは言わんが、書くなら関連する仕様くらい押さえておけってだけだろう。
書けない人材でも、そのライブラリを使うのには支障無いだろ string_view的なもので実装書いて、他のは適当に切り分けてtemplateも必要に応じて使いつつoverloadで変換して実装呼ぶみたいなのはよくやる
そう言うのが多過ぎて面倒なら、パラメーター受け用のクラス作って受けたい元クラスから作るコンストラクタで変換するってのもあるし >>224
c++の場合、まともにオーバーロードの仕様を抑えてる奴などおらん。
てかコンパイラ作る方も理解が薄いんじゃないかと思うレベルでバグ入れ込む話だぞ。
実際に仕様読むと増築につぐ増築でまともな仕様とは思わなくなる。
簡単だと主張する輩というのは仕様を読んでないか、もしくは江添みたく仕事の関係で後に引けないやつかしかおらんってことだ。 ADL含めたらややこし過ぎるが
そんなの普通は使わんだろ
名前空間指定してその中のオーバーロード使わせるのがまともなやり方 ID:9yJw5XoJ0は逃げたんだろうか・・・・ﾂﾏﾝﾈ >>200
「全部入り」と言いつつcodecvtを入れた香具師は死刑 実引数依存の名前探索 （じつひきすういぞんのなまえたんさく、ADL）とは、
C++において関数呼出時に与えられた引数の型に依存して、
呼び出す関数を探索 (lookup)する仕組みのことである
英語ではKoenig lookup、argument dependent lookup (ADL)、argument dependent name lookupなどと呼ばれる。
なお、Koenig lookupとは、この仕組みをAndrew Koenigが提案したことにちなむ
Koenigは、C Traps and Pitfalls(Ｃプログラミングの落とし穴)を、1989年に書いてる。
ADLは、Koenigが発明したのではないけど、標準委員会を説得したのは彼らしい
たぶん、ここまで詳しいのは、江添の本にしか書いてないだろう Cは使い続ける意味はあるが
C++には未来はないよ
そういう使い方したい人は
Dを使えば良いんじゃないかな >>227
それなら関数名なりを変えてるのと変わらんだろ。
オーバーロードなんて無理に使う必要ない。
てかそこまでうまくモジュール分割できないやつに限って使おうとする機能だから
問題なんだよ。 >>233
namespaceのalias作れるから
単純に関数名の接頭付けるのとは
使い勝手が段違い
namespace内でのoverloadは普通に有効だし >>234
だからネームスペースで区切った時点で話は終わってんだよ。
オーバーロードなんて余計な機能使うのは混乱を生むだけ。
無駄に検索にも弱くなるし。 overloadは使うだろ？
overloadはする側が管理するため空間分けるってのは至極当然な話では？ >>236
関数のoverloadはgrep検索が上手く出来なくなるからなるべく使わないほうが
いいと思ってるよ。ちなみに間違いやすいけど override のほうじゃないよ。 推奨しない理由がgrepっておかしくね？
ちゃんと参照を解析できるIDE使えばいいやん
本質からずれてる まあ使うも使わないも自由だが、あまり文法的なことばかりにこだわらない方がいい。
言い方を変えれば、「プログラミングの達人」と「C++言語の達人」は別なことを認識した方がいい。
「C++言語特有の機能」を使いこなせれば「C++言語の達人」ではあるだろう。
しかし、それは「プログラミングの達人」ではない。
「プログラミングの達人」なら当然「他言語を使っても達人」であり、
それは「言語非依存部分での圧倒的な巧さ」によるものだ。
単純に言えば、「ああ、こうすればこんなに簡単に実装できるのか」を繰り返してる。
C++特有の機能、つまりテンプレートやオーバーロードをいくら使いこなしてもここには到達できない。
それらは無ければ無いで何とかなる程度のものでしかなく、所詮はソースコードの整形でしかない。
それらをどれだけ使いこなしても本質的な構造の改善には繋がらない。
休日に5chに来てプログラミング談義に参加するような奴は、
モチベーションはあり、これは素晴らしい。上達も(本来は)するだろう。
ただ、最近は脱線している奴を多く見かける。
そして、無駄にやる気だけはあるから、おかしな議論で永久ループしてしまっている。
「言語非依存部分での腕前の差」を認識できないうちは、文法的なことにばかりこだわらない方がいい。
「C++言語の達人」ではなく「プログラミングの達人」を目指すなら、それは完全に空回りでしかない。
俺が見る限り、どの言語で始めてもどうやらそれなりにくだらない議論をやってる。
Javaの初学者は必要もないところでクラスを作って継承をこねくり回してる。
JavaScriptの初学者はセミコロンを打つか打たないかで議論してる。
C++の初学者はC++の無駄に複雑な言語仕様、特にテンプレート周りに惹かれるようだ。
ただ、これらを使いこなしても「プログラミング」そのものの上達はしない。
本来の「プログラミング」、つまり「言語非依存部分」での上達にフォーカスした方がいい。
そうであれば、C++が死んだら死んだで、あっそう、でしかない。
（俺はRustではC++を殺しきれないと見ているが） 途中まで、何かもっともらしく聞こえるが
結局、C++の特定の機能を否定したいだけな下心が隠せてないな そりゃ無駄なことで労力使うことになる機能なんてなくなりゃいいと思うわ。
バカは他の人間が苦労してるのがうれしいのだろうが。 C++から入れば他言語で当たり前に使われてるRTTIやリフレクションがおかしなものか分かる >>241
君がどこを目指すかは君の自由だが、「プログラミングの達人」のつもりなら、
君らが馬鹿にする「C限定」「C++98限定」縛りでも他の凡人とは明確に差を付けられなければいけない。
それが出来ないのなら、君は「プログラミングの達人」ではない。
ただ、新しい記述は古い記述の問題点を修正したものであるのは事実なので、
その問題に直面しているのに新しい記述を拒絶するのは、老害だと馬鹿にしていい。
といっても、当然だが基本/必要不可欠な部分から整備するので、
最近のC++に入っている仕様はかなり屋上屋を架す状態になっているのも事実だろ。
googleのルールがC++11を基本としているのもこれが遠因にある。
C++のスレが歪んでいるのは、住人がこの辺の「ちょっと考えれば分かること」を認めないからだ。
はちみつ餃子（コテ名）なんて、リアルの友人に職業マ（ゲーム）が居て色々聞いてみて、
「プロでも最近の仕様には疎いんだよなー」とか愚痴ってたろ。
そこでアマチュアであるはちみつ餃子が正しくプロが間違っている、と認識する点が狂ってる。
そしてこのタイプの人間がC++スレには割と多い。
C++が一番使われているのはゲーム業界だと思うが、これは単純に速度が速いからだ。
そしてゲーム業界が直面している問題は（ちと古いが）例えば以下であり、要するにOOPの限界とかだ。
OOPはコードを綺麗にまとめる手段ではあるが、速度は大概遅くなる方向だからだ。
https://sites.google.com/site/shunichisnote/translations/data-oriented-design
そして当たり前だがC++の新機能なんてこれに対する解を提供するものでは全くない。
結果、C++のゲームプログラマはC++の新機能なんて知る意味がないから、無視または受動的となる。
これもちょっと考えれば分かることだと思うんだがな。
プログラマ＝料理人に対して、包丁職人＝C++の達人も必要であり、
それを目指すなら、新機能を使えること＝上達だと考えるのは正しい。
でもそうでない場合、早い段階でこの認識は改めた方がいい。 ある機能を使わない理由が知らないからで、結果無駄な労力かけている
知らない理由を正当化しようと、知る前から役に立たないとか抽象的な理屈で断定するのは逃げでしかないんだよね
まあ言語仕様なんてアセンブラがあればなんでもできる
色々な言語があって、それぞれ独自に進化しているのは、結局みんな楽をしたいからなんだよ
手を動かす方で楽をするためには知識と知恵が必要で、知識を得るためには勉強が必要
まあ知識だけ入れても使いこなす知恵がないと無意味なのだけど >>243
リフレクションは動的→静的変換には必要ではある。
ただし動は動で組む、というのがC流ではある。(リフレクションがない世界だったから当然ではあるが)
といってもリフレクションありならだいぶ楽に書けるのも事実で、
.NET(WPF)はこの部分だけはフレームワークが自動的にリフレクションしてくれることになっている。
RTTIはgoogleは「必要になるのは設計ミスだ」という見解であり、確かにこれは事実だが、
https://ttsuki.github.io/styleguide/cppguide.ja.html#Run-Time_Type_Information__RTTI_
RTTIを使っていいのなら手抜きなパッチをサクッと当てられるのもまた事実だ。
(RTTIありなら1行で済むのが、無しでvirtualで対応なら新規クラス追加になってしまう）
ここら辺は結局のところ、どのコード品質まで許容するか、であり、
当然体面は「常に今現在の仕様で最高のコードにしておけ」な訳だが、
現実的に「そんなん出来るかバカヤロー」である程度デタラメなパッチも許容するのなら話は変わってくる。
だからこの辺は「無くても実装は出来るし、困らない」のを認識した上で、
どこまで手抜きを許容するか、だと思う。
>>245
それは俺に向けたものではないと思うから補足になるが、
俺はそれに関してはC++ではなく他言語をやった方がいいと思ってる。
現状、手抜きに関してはLL言語の方が数段上で、C++は完全に周回遅れだ。
クロージャ採用も今更だし、リフレクション等も他言語で普通に学べる。
（それを使うかどうかはまた別として）
今現在、C++でしか学べない事って、
C++固有案件(テンプレートをこねくり回すこと等)以外にはないよね？
C++が先頭切って導入しようとしている事ってあったっけ？ ■ このスレッドは過去ログ倉庫に格納されています
