-
プログラム
-
C++相談室 part136
-
UPLIFTで広告なしで体験しましょう！快適な閲覧ライフをお約束します！
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part135
https://mevius.5ch.n...cgi/tech/1522495206/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.102【環境依存OK】
http://mevius.5ch.ne...cgi/tech/1509780815/
■長いソースを貼るときはここへ。■
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 - コメントを投稿する
-
2get
-
STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？
#include <stdafx.h>
後死ね。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
---- テンプレ ここまで ---- -
C++解ると豪語していた人が後日茂みで戉だらけの死体で発見される例が後を絶ちません
C++解るは何か宗教的禁忌の呪詛なのだと思います -
青い鳥に「C++を完全に理解した」と語りかけると
もれなく狂人が群がってきて引き裂かれます -
構文、ライブラリ、パラダイム毎のテクニック、イディオムの一部を覚えて解った気になるなはどの言語でも同じね
-
>>3
このテンプレ貼り付けるの面白いんか -
C++を完全に理解するには40年の下積みが必要
-
C++77をやっと理解しました
-
c++11とか14とか17って何ですか？
-
ggrks
-
C++完全に理解したわ。
-
C++完全理解ってすげー
入門本ですら辞書の様に分厚いのに -
覇王になれます
-
コンパイラの中の人や
規格票の中の人なんかね -
C++界のラオウ
-
>>12の家に江添が向かうぞー！
-
12による攻略本を待てば良いのか？
-
最近は規格を完全に満たしたコンパイラって存在するの？
-
C++11は結構「満を持して」って感じだったけど、その後14だ17だとアップデートサイクルが
短くなるならCfrontに回帰してもらった方がハッピーな気がしてきた。
今のC++で技術的にどのくらいしんどいのかはわからないけど、TypeScriptやBabelなんかの
JS界隈でうまくいってるエコシステムがうらやましい。 -
ラムダとか型推論とか
やわらか言語のお遊びだと思ってたのにいまじゃこの有り様だよ -
コンパイラを駆動するためのプログラミングと、実行可能形式を駆動するためのプログラミングを一度にできる、一粒で二度おいしい言語がC++である。
つまり、ビールとワインを混ぜたらとてもまずかったというお話。 -
>>22
？
TypeScriptもBabelも普通に使ってるけど？
それがうまくいってるのを見てるからこそC++もそうできたらいいと思ったんだが。
まぁ、コンパイルに時間がかかるのとデバッグがちょっと隔靴掻痒気味ってのはある。 -
金箔貼っても糞は糞
-
C++がこっち方向→に糞だとすると、Javascriptは←あっち方向に糞。
-
歯糞耳糞を笑うというが、本物のウンコには誰も勝てなかったというお話。
-
>>26
結構印象が違うもんだね。
C++03が失敗気味でオワコン視された雰囲気はわかるけど、だからこそ次は失敗できない
C++11はそれなりの完成度になったと思うんだが。逆に14や17は蛇足気味のような。 -
しかしJavascriptとC++を完全に理解した俺が最強ってことだろうな。
-
同じ糞なら書かなきゃソンソン
-
>>33
いや14は重要なバグ直しでautoが安心して使えるようになったし
17はfilesystemやstring_viewにexecution（これすげー）が入って名実共にメジャー
やっぱC++03からの沈黙が異常すぎたんだよ -
>>36
常に最新を使えとまでは思わんが、さすがに C++11 は人権だと思うぞ。
C++14 や C++17 はユーザ視点では重要なものも含まれるとは思うが、
C++11 に間に合わなかったりミスがあったりしたのを補った、
マイナーアップデートという印象は有るな。 -
>>38
スマートポインタの恩恵は享受しようと思いますが、右辺値参照はよく理解できません… -
キーワードclassは結局いらなかった
newは忌み子だった
禿がどういう方面で過ちを犯したか
何となく察することができるだろう -
newで帰ってくるのがunique_ptrにならねえかなあ
-
>>39
えっ、それって重要な機能のひとつじゃね？
ライブラリは標準になくてもなんとかなるけど、
基礎的な機能で大事なトピックがてんこ盛りなのが C++11 でしょ。
最低でも
auto
decltype
constexpr
可変長引数テンプレート
あたりは無いとつらすぎるんですけど！ -
C++17はDoxygenを凄いことにする。
ひどい奴だ。 -
std::unique_ptrはユニポと読むんだよな？
-
>>44
> ちなみに他言語を使わない理由は何だ？
Scheme スレが私の巣だと思ってるくらいには Scheme 派なんだけど、
話題が少なくて暇だからこっちに出てきてる感じ。
> おそらく君はインラインアセンブラとか全く使わない人だろ？
使わないに越したことは無いというのが基本姿勢ではあるけど、使う必要があるので使うよ。
どういう意図で言ってんのかよくわかんないんだけど、
C++11 以降に加わった機能がスゲー大事という気持ちとこれらが何か関係あるの？ -
人は皆生まれながらにC++が好きだけど、その気持ちに気づくかどうかに違いが出るんだよね。
-
がしゃーん
がしゃーん
△ ￥ ▲
( Ｃ ＋＋ Ｃ )
( )
／│ 肉 │＼
＜ ＼＿＿＿／ ＞
┃ ┃
＝ ＝
C++17だよ
自動で Doxygenを凄いことにしてくれる
ひどいやつだよ -
よく知らないのだけど、いったいC++17でDoxygenに何が起こるんだ・・・
-
>>47
俺はC++を使う利点は
・高位から低位まで同一言語でカバー出来る点
だと思っていて、逆に言えば、
高位でしか組まないのなら他高位言語を使った方がいいと思ってるんだよ。
だからC++の利点を生かす為には、
・高位の機能と低位の機能を混ぜて使う
＝スマポもラムダもナマポもインラインアセンブラも 『同時に』 使う
事が必要で、逆に、このスレに巣くっているナマポ禁止な連中には若干懐疑的なんだよ。
それなら他言語の方が生産性が高いから。
必要ならその部分だけCのDLLにすれば済む話だし。
そして最近の新機能は高位向けの物が多いから、聞いてみたわけだ。
Schemeは知らんが、他高位言語を使っているのなら済まんかった。 -
>>51
高から低をカバーしてるのが良いというのは私もまったく同意見だよ。
だから、高から低をカバーと言っておきながら、高水準の部分は他言語に任せた方がいいというのはなんか矛盾してないか？
俺は「(現代の水準では) 足りてないからもっと (少なくとも C++11 で追加された分くらいは) 欲しいよな」って気持ちなわけ。 -
>>52
矛盾してない。
高水準の部分はC++は他言語に対して後れているから、
C++がそれを追加するのは妥当ではある。
ただ、俺なら他言語で組んで、CのDLLを呼ぶようにする。
それだと、他言語の進んでいる高水準機能を使えるから。
わざわざ遅れているC++に対して文句を言いながら使う意味がない。
例えば、C#がその作りになってるでしょ。
マーシャルがウザイか、C++の機能的周回遅れがウザイかってだけ。
勿論、インラインアセンブラを使いたいならC++しか解がない。
で、ナマポ禁止派はいったい何がしたいんだ？ってのが疑問で、
それだったら俺と同じでC#＋CのDLLで良いじゃん、と思うわけ。 -
C#やってるとテンプレート欲しくなるじゃん
-
ナマポが本当に必要な所では存分に使えばいいと思うよ
ただし普通は99.9%くらいはそうじゃないからスマポを使え -
99.9%がスマポなら、最初からスマポがデフォの言語を使った方が捗るでしょ。
Rustでもいいし、C#やJava等のGC言語でもいいし、PythonやRubyのようなスクリプト言語でもいい。
残り0.1%をマーシャルなりしてCのDLLで。 -
話をぶった切ってすんません。
複数のスレッドで
thread_local int* p;
p=new int [1000];
で確保したヒープ領域はやっぱりスレッドセーフ、じゃない、データ競合が
おきるんですか？ -
>>53
まー、生ポインタは一箇所たりとも許さんってほどの原理主義は過激だとは思うよ。
俺も生ポインタを使わないことはないし、 goto を使うことだってあるし。
ただ、「低レイヤから高レイヤまでをひとつの言語の中で扱える」というのは
「高レイヤな機能で低レイヤを隠蔽可能だ」ということであって、
低レイヤを低レイヤのままで扱うスタイルを是とするものではない。
直接的な部分ではインラインアセンブラを使うことが有っても、
その上のレイヤに持ち上げるときには必ずスマートポインタを使えってくらいの主張なら真っ当だと思う。
C++ なんてそもそもがクソなんだから、
解決のために追加された機能は積極的に使わないとやっとれんわ。
(でも好き。) -
>>57
起きないです。 -
>>57
thread_local で宣言した変数は名前が同じだけでスレッドごとに違う存在だし、
それぞれのスレッドで new したならそれぞれのスレッドで配列が確保されてる。
別のスレッドの p (やそれが指す先の配列) にアクセスすれば競合が起こることは有りうるが、そうじゃないんだよね？ -
>>59
ありがとうございます。これが本当ならホッとします。
でも、これって規格書に明確に記述されているのか、コンパイラがそういう仕様の
アセンブラコードを吐き出しているだけなのかわかりません。
データ競合がおきたら修羅場ですｗ -
>>61
明確です。
newで確保される領域はダイナミックストレージに属します。
これは他のスレッドと同時に読み書きを行えば競合します。
thread_localで確保されたint* pはスレッドストレージに属します。
これは複数のスレッドで別のページに属します。
従って、pに対して読み書きしている分には競合しません。 -
>>58
> 低レイヤを低レイヤのままで扱うスタイルを是とするものではない。
そう。で、俺は、低位はDLLで切り出しても大して問題なく、
高位だけなら他言語を使った方が効率的、という見方。
> その上のレイヤに持ち上げるときには必ずスマートポインタを使えってくらいの主張なら真っ当だと思う。
ちなみにそもそも俺はスマポ自体に懐疑的で、
・スマポじゃないとやってられないのはシャローコピーを永続化させるときくらいで、
C++でこの使い方をすることはほぼない。
（部分的シャローコピーでオブジェクト毎の生存期間に差が出て、
さらにそれがデータ依存しており、プログラム側で確定させるのが面倒なとき。
(半分満たす)例：このスレのレス配列があったとして、
特定のIDのみ、ポップアップ用にシャローコピーで抜き出す場合。
ただしこの場合はポップアップ後も次のポップアップ用に全体配列を保持する為、
シャローコピーの永続化はせず、寿命管理は全体配列単位となり、スマポじゃなくても苦労しない。
というより、正直、該当ケースを思いつけない）
なんだな。
要は、オブジェクトの生存期間をコード上で静的に確定させられないときにはスマポは強力だが、
俺には該当ケースがないんだな。
というか、お前ら何に使ってるんだ？
面倒なだけなら、GC言語の方が楽だしいいと思うんだが。 -
で結局ユニポでいいんだよな？
-
俺には分からない日本語をみんなが喋ってる
-
そんな柔な理解力ではこのC++の壁に傷一つ残すことはできんわ！
-
>>64
所有権を移転*しない*ということを表現できるのもスマートポインタの使い方のひとつだよ。 -
ナマポでもpimplはできるが
毎度毎度わかりきったコードを書く
無駄な手間がちょっとイヤ -
pimplに限らないが、メンバーにunique_ptrを使ったときの空のデストラクタが悲しい。
-
JSはES6でｽｹﾞｰ良くなった希ガス
もはやC++やPerlみたいな工業用言語として十分逝ける -
URLから連想出来る署名は
IQ110のJS先輩と学ぶ関数型プログラミング14日間 -
工業用言語でperl w
-
何を以て「工業用」と言っているんだろう
-
>>71
生存期間がシンプルすぎるからunique_ptrが入らないっていうのは賛同できないわー。
将来デストラクタが複雑になって誰かがdeleteする経路をすっ飛ばしてreturnしてしまうかもしれんし、使えるところは使っておけばいいじゃない。
何を気にしてunique_ptrさけてるの？ -
>>70
それで何が嬉しいんだ？
ついでに質問しておこう。
君はCのような自前でリソース管理をしなければならない言語でリソース管理をしたことがあるか？
あと、これはC++er全般に対してだが、
shared_ptrが絶対に必要なケースってのは何だ？
unique_ptrで後述A,B以外の使い方Dがあるか？(なおCは予約語) -
Cでのリソース管理戦略は非常に単純で、おそらく以下の２つしかない。
A. 作成者が責任を持って破棄する。
B. 投げ捨て。基本的に所有権を渡し、末端（付近）で破棄する。
Aが基本パターンになる。
Bは例えば描画用の一時データ等の場合で、
この場合、使用するのは「描画ルーチン『だけ』」であり、それ以降は不要だと自明だから、
・「描画ルーチン」までの途中経路での使用は原則禁止
（厳密には、「描画ルーチン」呼び出し以降の使用は禁止で、
呼び出し以前は改変等を加えてもいい＝この例なら、描画スケールの改変等）
・「描画ルーチン」内で必ず破棄
となる。
ただしあまり気にしないのならBも使わず、Aだけで組んでも問題ない。(というか多分そっちが主流か？)
描画の例であれば、描画終了後は普通はかなり速やかに親関数まで帰ってくるので、
親関数側でfreeするA方式でも大差ないからだ。
対して、OOP的に実装した場合、例えばゲームの敵キャラの生成/消滅を管理するとして、
この場合は「描画ルーチン」のように
「静的に明示的に生成/消滅の両方を内包する親関数」が規定出来ないので、
A方式は事実上使えず、Bで対応するしかない。だから上記を書き直せば、以下となる。
A. 「作成/使用の両方を静的に管理下に持つ親関数」を規定出来る場合、（＝構造化プログラミング）
その親関数内で確保し、親関数のスコープ終了と共に破棄する。
B. 上記親関数を規定出来ず、「作成」「使用」場所が明示的な場合、（＝OOP）
「作成」後は基本的に所有権を譲渡し、「使用」後に破棄する。 -
既に言ったように、Cの戦略は多分この２つだ。というか、正確に言うと、これ以外での管理は無理だ。
そしてこれはC++では以下のようになる。
A. 自動変数上のunique_ptrに確保、関数呼び出しでは所有権の移転はしない
＝生成場所のスコープ終了と共に破棄、それ以外の破棄はない
B. unique_ptrに確保し、自関数を抜ける前に『必ず』誰かに所有権を移転する
自関数が対象関数（上記例なら描画関数）であれば、移転相手がいないので破棄する
だからはっきり言えば、Cのナマポは事実上C++のunique_ptrの使い方しか出来ないし、してない。
C++erがスマポ(ｷﾘｯなのは、上記C流のリソース管理を知らない＝無知だからでしかない。
繰り返すが、Cは最初からunique_ptrしかないのと等しい。
ここがC->C++の連中と、C++しか知らない馬鹿との違いだ。
これに対して、shared_ptrは上記制限を解除するものだ。
だからshared_ptrを使えば新しいプログラミングパラダイムを発見出来る可能性はある。
これは何だ？
俺にはこれがイマイチ思いつかない。
いわゆる構造化プログラミングで、関数を入れ子で呼んでいく場合、必ずAは適用可能だ。
これがCが今までのさばっている理由でもある。
OOP的に組む場合はBが基本戦略となり、必ず誰かが明示的に「生成」し、
同様に、必ず誰かが明示的に「破棄」するので、これまた問題ない。
だから今のところCで間に合っているのも事実だ。
リソース管理が「面倒だ」というのは分かるとしても、
「難しい」というのは根本的に組み方を間違っているからだ。
GC言語しか知らない馬鹿共が知らないのは当たり前だとしても。
shared_ptr等が必要なプログラミングパラダイムが発見され、
それに対応する方法がなければ、お前らの望み通り、Cも死ぬしかない。何かないのか？
或いは上記A,B以外のunique_ptrの使い方Dがあるか？(なおCは予約語) -
例外安全性の確保でウッカリさんするくらいなら使った方が良い。
-
>>68,79
そもそもpimpl自体が要らんだろ。
あれはC++のコンパイラが単純に仕様変更
・ヘッダにはprivate関数は書く必要がありません
すればいいだけの話で、そもそも「名前空間は開いていますが、クラスは閉じています(ｷﾘｯ」を、
「ヘッダのクラスは開いていますが、実装のクラスは閉じています(ｷﾘｯ」にすればいいだけ。
編集上の都合でソースが汚れるとか、全く馬鹿な話だろ。
気づけよ。 -
pimplに近いテクニックとしてC言語の頃から絶縁テクニックというものがあるが
それをやると大概静的解析ツールが横暴な量の警告メッセージを吐いてきやがるので却下
pimplも多分同じ結果に… -
Javascriptを使って感じるC++の有利な点は仕様の明確さだろう。
Javaは重いと言われユーザーに嫌われる言語のひとつだが、開発者はベンチマークを提示しC++の20倍速いと言う。
しかしユーザーは実際に重くて困っているだろう。
ブラウザも同じ問題を抱えていて、当然Javascriptも重いとユーザーは感じている。 -
Microsoft社はソフトウェアの使用状況を監視させてほしいとユーザーにお願いする。
IMEの誤変換データや、プログラムのクラッシュ時の情報などだ。
これらは、開発者とユーザーの間の意識の乖離を埋める可能性がある。
ユーザーの重いと開発者の軽いのような。
オープンソースに対するアドバンテージがここにあるのかもしれない。 -
>>90
慣れたらJQueryなど使わずとも複数プラットフォーム対応逝ける！ -
Visual StudioはCMakeに対応したし、Microsoft社はオープンソースとの付き合い方をやっと学んだようだ。
-
pimplを多用するライブラリの一つにQtがある。
C++はテンプレートによって拡張性を担保できる言語だ。
一方、拡張性はライブラリのユーザーにとってわかりやすさを損なう。
IDEとの結合において、pimplによる公開は一つのテクニックかもしれない。 -
ところでpimplってぽいんぷるって読むんだよな？
-
ピーいんぷるって呼んでた
-
RAIIは？
↑今すぐ読める無料コミック大量配信中！↑
