C++相談室 part133
レス数が1000を超えています。これ以上書き込みはできません。
次スレを立てる時は本文の1行目に以下を追加して下さい
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part132
http://mevius.5ch.net/test/read.cgi/tech/1507561894/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.102【環境依存OK】
http://mevius.5ch.net/test/read.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
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？
#include <stdafx.h>
後死ね。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
---- テンプレ ここまで ---- >関数内で作ったベクターやマップは関数を抜けたらメモリ解放されると考えてよかです？
だって今回の話はmove関係ないし
質問とは関係ない余計なことを言って知識をひけらかしたかっただけの人でしょ
今回の話であれば
「自動変数であればスコープを抜けるときにデストラクタが走って解放される」
というだけの話
それ以上の話はまた別の話
>うん、信じていい
>XXから抜けるときにムーブコンストラクタでtmpへ移動され
>createmapから抜けるときに解放される
>このときoperator deleteが呼び出されるが
>operator deleteがどのようなタイミングで解放しているかには依存すべきでない
>我々が関心を持つべきはoperator deleteが呼び出されるタイミングで実装の詳細ではない
↑依存すべきでは無い、と言っておいて、関心を持つべき、と言ってみたり
実装の詳細に関心を持つべきでない、と言っておいて、vectorの実装詳細を語ったり
言ってることやってることが支離滅裂で、意味不明だろう
ついでにバージョンによってRVOどうのこうのも、質問には関係が無い余談だし
そもそもバージョンの話するんなら昔のC++はmoveセマンティクス無いし
しかし、どうであれ、どのみち質問には関係が無い >>3
おまえも何を言っているんだ？
operator deleteが呼び出されるタイミングを
vectorの詳細とでも言っているなら病院へ行ったほうがいい 前スレのおバカさんか
>このときoperator deleteが呼び出されるが
>operator deleteがどのようなタイミングで解放しているかには依存すべきでない
>我々が関心を持つべきはoperator deleteが呼び出されるタイミングで実装の詳細ではない
↑これの説明してみ？
好意的に解釈することもできるが、どのみち意味不明すぎる >>8
そっちこそ何言ってるんだ？
今は RVO の話だろ？ まぁ、>>10の意味不明な文章の解釈などどっちでも良いんだが
質問者はvectorな自動変数の寿命に関して、RAIIが正しく行われるか
不安だから聞いているだけなのに、moveがどうとかドヤッた挙句
RVOが働いたらmoveされないんじゃね？ってのはお粗末すぎる
return vec;で、RVOが働くか、ムーブコンストラクタになるか、コピーコンストラクタになるか、は
コンパイラの銘柄とバージョンと最適化のオプションによるだろうし
もしかしたら、コンパイラの気分で変わるかもしれないし
なんだったら、関数がインライン展開されたらまた前提が変わってくるだろうよ
なんで、こんなことは考えるだけ無意味であるし
というか、考えなくてよいように作ってあるし
むしろ、考えてはダメというか、依存させてはいけないという意味で
余計なこと(悪いこと)は考えないほうが良いし
結局、質問者には
vectorな自動変数はスコープを抜けると寿命が尽きてデストラクタが呼ばれて解放される
というC++の根底のDNAである、RAIIのルールだけ言えばよいわけで vectorな自動変数 という表現はちょっとアレだったかもしれん
まぁ、vector型として宣言された自動変数 のこと・・ 「コンパイラの銘柄とバージョンと最適化のオプションによる」
少なくとも991の置いたC++17の前提ではムーブコンストラクターやコピーコンストラクターは有り得ないのだが、
ひょっとして前提をすり替えられたのだろうか それは>>991が言ってるだけで
質問者はC++17とは言ってない
質問者に対して、もしC++17の場合は必ずRVOになるので～～という説明をしたとして
これもあまり意味が無いというか、関係が無い
質問者はvectorがRAIIを徹底していのるか心配になったから聞いているだけ
その意味ではRVOだろうがムーブだろうがコピーだろうが、関係が無い 991がC++17のことを言っているのはちょっと脱線しただけであって、
話の前提でもないし質問の意図に沿ったものでもないよな const参照を返す関数があるのだけど、autoで効率よく戻り値を受け取るには
const auto&とか書かなきゃいけないの？
それともdecltype(auto)とかするの？ ↑嘔吐するから漏れには関係ない
それよか想定上はconstメソッドなのだが実際のところ実装がどうされるかわからない抽象仮想関数にconstをつけて良いものかどうか
いつも悩む autoで受けて余計なコピーを発生させちゃう困ったちゃん >>20
考えたこともなかった困ったちゃん参上！
正直スマンかった以後気をつけるわ 最近勉強始めたばかりで100までの範囲の数字を入力したらそれが1～10,11～20,・・・91～100のどの範囲にあるか判定したいけどif文10個用意する方法より綺麗にするにはどうしたらいい？ >>23
pair<int, int>の配列を用意してループする
https://ideone.com/0pYJWk Win32とかだとフラグ管理でビット演算利用してるけど、今どきのc++17だとどのようにするのがベスト？ C++入門書でよく勉強したはずなのにautoとかconstexprとか知らんもんが一杯… 変わらず std::bitset 使い続けてる ベストかは自信ないけど不便もないので >>32
やさしいC++第3版
大体9年前に買ったのを寝かしといて最近になって勉強し始めたが、そんなに仕様変更ないと思ってたが間違いだったようだ CはそれほどでもないけどC++は11以降どんどん変わるようになったね Effective Modern C++を俺は使ってる
でもC++17が出たらまた新刊出るね
これC++11/14対応版だしすぐに古くなる Effective Modern C++17出たら買ってみるわ もうC++を本で勉強するのは無理なのではないだろうか C++を始めようと思うんですがおすすめの参考書知りたいです。Cの知識はありませんがPythonでプログラミングは経験したのでプログラミング初学者ではないです。 >>41
accelarated c++
c++11 以前の古い本だが、C を経由せずに C++ をある程度マスターできることを評価したい 今は規格から追ってった方がいいと思う
規格書そのものの通読は大変だろうから、cpprefjpとか眺めてわからなくなったら規格に当たってコード書いて試してが一番早いよ
プログラミング完全初心者はそうも行かないだろうけどPython知ってるなら大丈夫だろ >>42
英語の本ではなく日本語の本で何かありませんかね？
英弱なもので^^; >>44訂正
日本語版もありますね
すいません(^^;; C++ の定本は、ロベールだけど、ものすごい分厚い
これは、ちょっと古めの本だけど、
ドワンゴ江添などの新しい規格の本は、古い規格を知っていないと読めない
猫でもわかるC++プログラミング 第2版
数言語知っているなら、簡略なこの手の本で、お茶を濁す
とにかく、C++は言語の最高峰だから、
スッキリJava で、オブジェクト指向をマスターしていないと、取得できない。
理解できるまでに数年以上掛かる
まずこの本で、オブジェクト指向を学ぶ
スッキリわかる Java入門 第2版、2014
その後、この2冊をこの順に読む
たのしいRuby 第5版、2016
みんなのPython 第4版、2017 >>47
＞とにかく、C++は言語の最高峰だから、
いや、関数型の諸言語の方が、わけわからなくてすごい、と思うときもあるのでした。最古参の lisp とか… 関数型は、コンセプトが難しいだけだが、
Elixir みたいに分かりやすい言語もある
一方、C++ はポインタとか、実装が難しい。
実装に直面させられるから
Rust では、実装の詳細をどう回避しようとしてるのか、よくわかる >>48
うーん、 Scheme スレ住人の私からすると、 LISP はＳ式表現の考え方で引っかかってる人の方が多い印象があるな。
関数型たって、副作用にややこしい手順が必要なのは Haskell くらいで、 LISP に「関数型」であるが故の難しさはそんなにない。 >>47
なんでc++の勉強するのになんでrubyやpythonの本を読まなきゃいけないんだよ？ >>52
必須ではないにせよ様々なパラダイムについて見識を持つのは無駄にはならないと思う。
ただ、入門者が色々手を出すと混乱する可能性も大きいんじゃないか。 C++ は、エベレストみたいなもの。
まず、色々な山で練習しろってこと
スクエニなんて、社員が何千人もいるのに、C++ を募集してるだろ。
社員の平均勤続年数は、7年だけど誰もできない
最近では、言語の募集をしても、全然できない。
言語を知っていても、何もできない
コンピューターリテラシー、つまり環境・OS を含めて、
すべてを知ってる人でないと、無理
C++ では、Ruby などの関数型とか、勉強できない。
ビジネスロジックの話ができない。
メモリとか、余計なものが付きまとってくるから
C++ で勉強していると、ものすごい時間が掛かって、非効率 >>53
pythonスレでもrubyの宣伝しててうるさいからつい。
無駄にはならないけどc++への理解は遠ざかるんじゃないかな？ >>54
足切り点がちょっと高めで、落ちるやつは容赦なく落ちるというだけ
いつぞや足切り点を低くしようというCOBOLとかいう試みがあったが
結果は周知のとおり
落ちたやつにはエベレストに見えるのかｗ >>54
うーん Ruby/Python/Java で実装した例を読むと、即座に C++ に直す、というか、どうしてもそうしたくなってしまうんだよ
薄い本なのにぜんぜんはかどらない OS 周りの事は、Python よりも、Ruby の方が楽。
Vagrant, Chef で、仮想OS もできるし
Python は、AI とか数値計算用。
次世代は、Elixir, Rust の2択
社員数何千人の大企業が、C++ を募集すること自体が、そもそもおかしいだろ。
何千人もいて、できる奴が、1人も見つからないなんて
そもそも、そんなに簡単だったら、皆、こんなに挫折しないって。
こんなに本屋に、難しい本が並ばないから
何十年も、C で手続き型をやってる老害どもが皆、
C++ のオブジェクト指向で、討ち死にしてる >>58
いやいや 言語自体の話ではなくて、応用例の話で
いまはまっているのは https://www.amazon.co.jp/dp/4627847610 で、こういうのを読むと c/c++ で書いてみたくなるという… Go は老害が作っているから、結局、手続き型から言語から、抜け出せなかった。
C から、C++ へ移行できない、老害と同じ
一方、Elixir, Rust とかを見れば、どの概念を抽象化したのか、よくわかる C++, Rust を比較すれば良い。
どの概念を抽象化したのか、よくわかる
ニコ生も今、Rust で作り直してる最中 C++を勉強したいという人にrubyやpython,javaの本をすすめるなんて
遠回りな事言うんだなと思ったら>>59だもんな・・・ 難しい難しいと言って「ポインタとか」という例が出てくるところで察し 素人がエベレストを目指しても、ダメ。
レベル5 の冒険者が、レベル50 のモンスターを倒せない。
小学生が大学数学を解けない
実際に大企業では、プログラマーが何十人来ても、即日サヨナラが続いてる
漏れは、C++ のプロジェクトに採用された事があるけど、
派遣から来ても、ほとんどが即日サヨナラ
何十年も、C をやってる老害でも、C++ は全くできないし できるとかできないとかどのくらいのレベルのことを言っているのか気になる >>65
どのくらいの C++ スキルが必要とされるの？ >>66
> 小学生が大学数学を解けない
ちゃんとこう言ってるじゃないかｗ >>68
例えが分かりにくいのでC++で例えてほしい 最近の大企業では、言語の募集をしても、全然できない人が来る。
言語を知っていても、何もできない
だから、コンピューターリテラシー、
つまり環境・OS・アルゴリズムなど、すべてを含めて必須
OS のコマンドを知らないとか、アルゴリズムを知らないとか、
仮想OS を構築できないとか、Vagrant, Chef, Docker を知らないとか、
LLVM, MFC を知らないとか
C++ なんて、ほぼすべてが必須だろ。
だから求人票には、コンピューターリテラシー必須って書いてある
言語の知識ぐらいでは、何もできないから、派遣から来ても、即日サヨナラとなる
Emacs を使えない人は、お断りっていう会社もあるほどw
プロなら、自分が使うツールにも、こだわりがあるはずだから >>70
チンパンジーに因数分解みたいな話に例えもへったくれもねえだろ >>69
この場合はstd::inializer_listになるよ ◯std::initilizer_list
だからstd::beginとかstd::endが使える >>71
趣味でやってるから企業の事などさっぱりだがそれはc++以外だと不要なのか？ 最近の大企業では、言語の募集をしても、全然できない人が来る。
言語を知っていても、何もできない
だから、コンピューターリテラシー、
つまり環境・OS・アルゴリズムなど、すべてを含めて必須
だから募集要件が、コンピューターリテラシーがある人になる
確かに、何の言語でも、そうなる >>60
あ、すまん、それは薄い本 (同人誌のことをいうスラング) に反応してしもうたというジョークなので気にしないで。 >>77
C言語できますって言って2進数知らない人とか来るもんね まあ簡潔に言えば、C++ を学びたい場合、直接C++ を学ぼうとしても無理。
文法だけを学んでも、全く何もできない
周辺知識(コンピューターリテラシー)から埋めていかないと、どうにもならない
高山列車が直接、真上に進めないのと同じ。
切り返ししながら、徐々に上がっていく感じ
何十年も、手続き型言語のC をやってる老害が、
オブジェクト指向に移行できないのも、そう
平山尚のセガ本もあるけど、文法を学んでも、オブジェクト指向が理解できない。
やっぱり「スッキリJava」から始める必要がある Javaみたいなオペレータもテンプレートも使えない糞言語薦めるな ヒエラルキーのトップC++にはなにもかも無駄な知識
Javaもrubyもpythonも C++を使うのにオブジェクト指向に対する理解が必要、という意見にはある程度賛成できる。
しかしながら、そのために先にJavaの本を読め、てのはどうなんだろ。
C++の入門書でオブジェクト指向の解説までカバーした本、てのは存在しないのかな。
C++の本を書くような人はオブジェクト指向の説明をするのは沽券に関わると思っているのか、
あるいは「C++の専門家」にはオブジェクト指向を教える能力がないのか。 オブジェクト指向をわかりやすく説明した本は、世界中にない。
だから「スッキリJava」が出た 2011年は、オブジェクト指向にとって、エポックの年
この本以降、C++ を学ぶのに「スッキリJava」から始めるという道筋ができた。
この道筋で学べるのは、日本だけ
他国では、もっと苦労してるはず。
まあ、漏れの勝手な意見だけど Javaみたいなゴミ薦めるな。ソフィーの世界の方がマシ いろんな言語のおいしいとこだけ使って個々の言語に深入りしないのが得策
おいしいところを繋ぎ合わせる能力のほうが大事 イカンことはないと思うが、C の環境に行った時に困るぞ。
まあ最近の C には大体取り込まれてるみたいだけど。 例の約一名入ってることがおかしくて
まず初心者というか入門で、C++の文法などを覚えたいという話なのに
コンピュータリテラシーが無いと現場では使えない、とか
今それ関係ないし 他の言語の本は無しとしてオススメの本ある？
c++11以前だったら独習C++が良かった。 c++ プライマー第5版くらいしかないと思う。
c++の基本的な文法から解説してあってc++11対応。他の言語を学んでいるなら読めると思う。 C++11 が成立するより前だと「詳説 C++ 第2版」が良かったと思う。
http://amzn.asia/4C6Q7x9 >>95
説明が悪かったけど、プログラミングの全くの初心者が読むにはちょっと難しいかもってこと。 >>83
> 入門書でオブジェクト指向の解説
ここがそもそも間違っている。
オブジェクト指向は肥大化(10k行以上）するソフトウェアを整理して記述するための方法論であって、
肥大化してない（1k以下）ものすら書けない初心者（入門書を読む層）には不要だからだ。
だから、ない。要らないから、無いんだよ。
少し考えれば分かるはずだが、世界中の誰も出来ないと思うかい？そんなわけないだろ。
ただし、日本のシステムでは必要なんだよ。
日本では大量の馬鹿（新入社員）でもプロジェクトの足しにする方向だから、
せいぜい100行しか組めないド新人にもオブジェクト指向を強いる。それが日本のJavaだ。
既に稼働中の大規模システムに組み込むコードは、
それが新人が書いたものであっても、正しくオブジェクト指向してないと困るから。
言い換えれば、大量の馬鹿が少しずつ組み上げることに日本は特化している。
これは平均的ド素人の最低レベルが保証される社会だから出来る方式でもある。
逆に海外はおそらくそんな馬鹿が大規模システムに組み込むコードを書く前提にしてない。
熟練し、正しくオブジェクト指向できる奴だけでメンテする前提であり、馬鹿は死ね、だ。
これはITドカタの給与の平均値からも分かる。だいたい海外は日本の2倍だ。
だから初心者にオブジェクト指向を教える意味がないんだよ。
オブジェクト指向自体は別段難しいものではなく、また、手続き型(Cスタイル）と（実は）地続きだから、
十分に熟練すれば自然と理解できるし、「手続き型だ」と言い張ったところでどうしても中身は似てくる。
Java鹿は、オブジェクト指向と手続き型が別物だと勘違いしている。
ド新人に「オブジェクト指向(ｷﾘｯ」と洗脳し、その意味すら理解できない馬鹿が教える側に回って、悪循環してる。
普通に考えれば、C++の仕様でstructとclassがほぼ同じことからも、
また、未だにインスタンスメソッドとクラスメソッドの区別が文法以外にほぼ無いことからもこれは分かる。
(instance.method()とstaticMethod(instance)の実行時の違いがほぼ無い、
或いは、結局はレシーバをどう記述するかだけの話だ、と言った方が分かりやすいか。
Goに至ってはこの点、どっちでもいいです、という仕様にしてしまっているし） Cで大規模なシステムを組むと、どうしてもstruct*を多用することになる。
これ自体がオブジェクト指向そのものだ。
ただしCにはこれをサポートするための文法が無く、全部自分でやらないといけない。
だからちと辛いし、class構文欲しい、というのは自然な流れだ。
おそらくLinusがC++erを毛嫌いしているのはこの辺で、（彼が嫌っているのはC++ではなくC++erね、念のため）
Cにはサポート構文がないだけであって、
自前でやる気なら正しくオブジェクト指向できるし、
それが昨今の「継承イラネ、全面委譲で」なら実は大して手間は変わらない。
この場合、「C文法で組め」と言われても、「ああ、これならまあ」程度でしかない。
これについてグダグダ言う奴は理解できてない馬鹿だからイラネ、ってのは当たってる。
そもそも、入門者の言う「オグジェクト指向が難しい」の理由は、
「オブジェクト指向で組めない」ではなく、
「オブジェクト指向の利点が分からない」「なぜこんな記述方式にする必要があるのか？」だろ。
元々大規模のコードを整理するための手法なんだから、
大規模なコードが書けない新人には理解できないのは当たり前。
それを理解しろ、という日本方式に無理があるんだよ。
あと、Javaの問題は、かなり制限された言語だから、
他言語だとすごく単純に記述できることを
デザインパターン(ｷﾘｯをこねくり回して意味不明な構造にしないといけないことが多いこと。
だからC++入門者にJavaを勧めるというのはやっぱりキチガイだよ。
そしてこの意味で老害が一番多いのはJavaだと思うよ。
と言うか、ちょっと逝っちまっていることを言う奴はたいていJava鹿だ。>>86もそうだろ。
例のスタティックおじさんの話もJavaだし。（あれは双方の言い分も分かるが） C++の問題は、「何でも出来る最強言語」を目指しているのか、本当に何でもありすぎる点だ。
だから新人が戸惑ってしまうのも分かるし、無駄に覚えることも多すぎる。
例えば、継承した場合に隠蔽できるが、あれなんてマジで要らないだろ。
(virtualでないメソッドをoverride（とは言わないが）して隠蔽、って奴ね）
この辺、バランスが取れているのはC#だ。そもそもそこが狙いのようだし。
Cに関しては、老害ではなく、「老」が多い。これは古い言語だから。
ただしC++への移行はいつでも出来たし、既に書いたがオブジェクト指向とは地続きだから、
文法的にオブジェクト指向してないだけで中身はオブジェクト指向そのもの、ってのはよくある話だ。
そしてCは元々関数ポインタを扱えた。これはものすごく大きい。
Javaが糞なのは、全く関数ポインタを扱えず、
その結果デザインパターン(ｷﾘｯする糞言語になっている点だ。
ただしあの頃はまだ「関数ポインタの有用性」がさほど理解されておらず、致し方なかった面もある。
C#もこの辺、記述方式が二転三転しているし、C++もやっとラムダを取り入れたばかりだ。
K&Rも「関数ポインタも使えるよ」としか書いて無い。あれはもっと力説されて然るべきだった。
でも、今新しい言語を作るとして、関数ポインタが使えないのはマジで糞だろ。
そしてこの点、文法的にではなく、
「社内ルールで」関数ポインタの使用を制限する「老害」が多いのは圧倒的にJavaに決まっている。
Cは元々使えたし、C++は(読みやすくはないが)ファンクタを使えたので、有用性は「老」でも理解している。
Javaにはそもそも関数ポインタの使い方を理解している「老」がいない。
Java8で文法的には取り入れられたものの、おそらく大半の職場では相当期間制限されるはず。 海外の連中の話だと、「プログラミング自体」を学ぶのに一番早いのはPythonだと言われてる。
(俺はPythonを使ったことがないから分からんが)
例えば、入門者のよくある質問、
「元データがこういう配列で、このうち○○を含むものだけを抜き出したい」等、
どうプログラミングするか、という所から学ぶケースだ。
この辺の本当の初心者に対しては、
C++の、よし、ここはスマポだ、とか、
Javaの、そこはオブジェクト指向で云々、とかは邪魔なんだよ。
本当にフォーカスすべき案件に集中できない。
この意味ではC++は最初の言語には向いていない。
だからド初心者用の入門書の良書は少なく（需要がない）、逆にeffective系が多いのだと思う。
ただしPython自体も古くてゴミな部分もあるから、（ラムダに制限がある）
基礎を組めるようになったら早く卒業し、
C/C++やJavaScript等の「無制限な」言語で色々やったほうが上達するとは思うが。
この意味ではJavaやPythonは制限されすぎていて駄目で、
C#は適切に制限されているから、現実解としてはかなりありで、
C/C++やJavaScriptは自由すぎて(上達はするが)大規模システムを組むには怖く、
だからこそJavaが現代版COBOLとしてのさばっている、という構図だが。
だから、C++erが大規模システムの為に安全なJava言語を選ぶ、というのはありなのだが、
Javaしか出来ないJava鹿が知ったような口を利くからおかしなことになる。
Javaがどれほど制限されているのか理解していればそんなことは言えない筈なんだがな。
この辺、新しく出てきたGoは色々整理されているはずだと期待したんだが、
かなり糞だったので逆に驚いた。あれではC+GCでしかない。
今更Generic出来ないとかマジで糞過ぎる。
逆に言えば、今でもC文法そのままでよく、GCだけ欲しい人にはGoは向いているが。 >>102
Go はさっぱりあかん言語だというのには同意するが、
現実にはその程度で良かったという話なんだよ…… 全くの初心者なら、まずはC言語の勉強をしてから>>94のc++ プライマー第5版などを読むのがいいかもしれないね
俺の知っているC言語の本で一番分かりやすかったのは、アスキーラーニングシステムの「入門C言語 新装版」と「実習C言語 新装版」だけど、さすがに古いかな？
同じ著者の本で2008年に出ている「Cプログラミング講座」というのもあるけど、これは読んだことがないな
というか、こっちもすでに絶版になっているっぽいな．．． ゲームプログラマになる前に覚えておきたい技術、平山 尚、2008
この本は賞を取ってるけど、セガの平山は、
1冊で、C++ の文法と、ゲームプログラミングの2つを、
同時に習得できる本を目指したけど、無理だった
結局、C++の文法だけで、2007年のロベールの分厚さが必要。
人間の読める限界を超えている。
それでも、日本にはロベールがあるだけマシ。
外人は、やさしい本が無いから、もっと苦労してる
結局、1冊でJava の文法と、オブジェクト指向の2つを説明したのが、
2011年の「スッキリJava」
ここまで、待たなければならなかった。
外人は、スッキリも無いから、もっと苦労してる
外人の場合、専門書しかないから、偏差値70未満は、単純に振るい落とされるだけ。
日本のように、学ぶことはできない >>103
あれは言っちゃあ悪いがC++のオブジェクト指向が暴走した反動だよ。
C++が無駄に複雑化しなければ全くのゴミだったはず。
それ以前にC++はGC嫌いが宗教じみてる。
無駄にスマポで頑張るのではなく、VC++/CLIのgcnewを導入した方がましだったと思うよ。
Goは全く新しい機能がなくてびっくりした。
ただ、C++が複雑化しすぎてWeb系（というかバックグラウンドがない初心者）に厳しいのは事実。
そしてゆとり版C++＝Goってのも分からなくもない展開だ。
ただ、持ち上げている連中の非力感は否めない。
あれは関数型()と同様に大騒ぎしてポシャる可能性もあると思う。 >>93
独習c++ いいね、ハーバード・シルトは要点を押さえてさえている、独習Java がダメダメだったのとは一線を隔しているね
演習問題に std::string を再実装する、という山場があるが、それを乗り越えると c++ の初級者になれると思う >>70
明確な強い理由がない限り言語なんて大概何でもいいだろ
どこの現場でも出来る奴ってのは、モジュール設計のセンスとネーミングセンスのある奴じゃなかろうか >>99
Java のいいところは、一文字一文字丁寧に読んでいければだれでもわかるように書けるところにあるのでは？
それは一つの到達点だと思う
BigInteger.ONE とか、ちょっと嫌だな、と思う書き方はあるが、仕方がない
（gmp なら 普通に 1 と書けば文脈を読んで BigInteger(1) というコンストラクタが働くのだが、昔の Java はそもそもオートボクシングがなかったくらいだし）
C/C++ ならスタックにデータを置けても規模が大きくなると、new/delete する方向になるのを見込んで、Java が最初からクラスをスタックに置かないことに徹したのも、
定石どおりでいい感じ、Java は尖がったところがないので好感をもっている
昔はアルゴリズムの教科書といえば pascal で記述されたものだが、最近は Java で記述されているものもよくみかける
私は Java を非難したくはないな… unique_ptrとshared_ptrのことちゃんと解説してる日本語本ってないだろ(C++1xのマニア向け本除く)
レガシーコードのメンテするんでもない限り生ポインタで一生懸命あーだこーだしてる古い本なんて役に立たないしむしろ有害だよ
規格書読んだほうがまし >>107
じゃあ、おまえの主張どおりC++にGCを実装するなら
どんな実装になっていたんだ？
俺はベアメタルのROM屋だが
今でさえ例外だのRTTIだのでさえ殺意を覚えているんだが マニア向けも何もunique_ptrもshared_ptrも1x以降に実装されたんだから当たり前やろ unique_ptr, shared_ptr などは、たぶん、Boost の本に載ってるかな？
C++ は、Rust, Elixir へ移行している
C++ では、多重継承も難しいから、Java, C# では単一継承だけになった >>112
だから書いたろ。gcnewだよ。
https://msdn.microsoft.com/ja-jp/library/te3ecsc8.aspx
動きとしては、C#やJavaのnewと同じ。
ただしnewだと予約語で被るのでgcnewになってる。
C++はランタイムが無いから、std::GCを作って、
gcnewを1回でも呼んでいるようならそれをリンクしてやればいいだけ。
まあ今からでもできる拡張だからやってくれ、とも思うが。
ただ、GCは絶対に入れない宗教なんだろC++は。 リソースを全部GCで管理してくれるならいいんだけど
自分で解放しないといけないリソースもあってなんだそりゃっていつも思う GCなんて負の遺産だろ
崇高なC++にそんなもん混ぜんな >>117
ほんこれ
んで結局usingだのwithだのって、ええ…って感じ >>110
Java自体はオブジェクト指向の完成形になるはずだったのは認める。
問題は、Javaに関数ポインタがなく、それが致命的だったことだよ。
というかあの頃のC++/C#/Javaの連中は誰も関数ポインタの有効性に気づいてない。
だからC++でも匿名関数をサポートしてなかった。
関数ポインタ＝オブジェクト指向（多態）を手動でやるときに必要＝クラス構文でサポートしたからイラネ
という判断だったのだろう。C#のdelegateもまずクラス(thisの受け皿）ありき、だからね。
あとはcallback出来ればいいや、位か。
関数型のように関数ポインタを常用する事になるとは思ってもいなかったはず。
ところがLisp-Erlang-Haskellの連中は匿名関数の有効性に気づいていて、
おそらくJavaScriptでそこに日が当たってしまった。
そして匿名関数のサポートがないのは間違いだったと気づき、C++/C#/Javaの全てはこれを導入した。
(後は関数がfirstClassObjectになるかどうかだが、
今のC++の雰囲気なら、じきに何らかのサポートを入れると思う)
ここで問題なのは、C++/C#は以前から関数ポインタを（見やすくはないが）使えたから、
ユーザも使えるし、コードも必要ならそう記述してあること。
一方、Javaはユーザ側にその知識がないし、
関数ポインタが無い為に継承等で無理に実装してあるコードが既に大量にあること。
Javaユーザが勉強熱心だとはお世辞にも思わないし、何周も他言語ユーザから遅れてしまっている。
そして大量に居るJava鹿の為、すぐにJava8を導入できるとも思えない。
ただしC#は進化し続けた＝ユーザーに勉強を強い（時間を奪い）、
また環境にも負荷をかけ続けた（いちいち新しいコンパイラ等を整備する必要がある）為、
結果的にエコシステムの構築が遅れ、
下位互換でしかないJavaに対してかなり出遅れている感じは否めない。
ここら辺は結果論でしかないが、分からん物だね。
単純にいい言語が繁栄するわけでもないし。 古典的な同期プログラムなど、いまどき何で書いても同じ
問題になるのは
非同期処理やら
例外安全(処理の巻き戻し)やら
マルチスレッドでデッドロックしない云々やら
いわゆるトランザクションのようなものをどう実現するかやら
そのへん
超高級言語で、いわゆるスクリプトなどなど
高級なくせに上記のサポートが何もないのが真の糞言語で
無駄に重たいだけで、「今まで何やってたの？」状態
動的型なんか何も意味無かったし、本当に何やってたんだろうな >>115
おまえアンカーミスったか？
俺の問いに対して一言も答えていないんだが new自体ほぼ使わないのにgcnewを導入しろとかアホか 一連の投稿(同一ワッチョイによる)を一通り読んだけど、
マトモに議論(賛成にしろ反論にしろ)できるほど理解できなかったわ。
自分の読解力というか、多くのプログラミング言語を比較評価できるだけの
知識の欠如が原因で、投稿者を批判するわけじゃないんだが。
ただ一応は読んだ、という証拠を示す意味で一言。
>>102 にある「Javaしか出来ないJava鹿」って言い回しは気に入った。
意識して書いたか分からないけど、ウマくかかってる。 他の言語のスレに行ってJAVAを薦める「Javaデモ」はいらん。
デモもピケもお断り pairを戻り値とする関数内でmake_pairを返そうとしてる
pair<string, string>( vector<string> vec)
{
return make_pair<string,string>(vec[0],vec[1])
}
要素数が2より小さいときにペアが作れないから他のものを返したいのだけど
こういう場合は何を返せば良いのだろうか？
受けてる先では
map<string,string>にinsertをしてる >>137
見直して意味わからんかったので直しました
pair<string, string> XXX( vector<string> vec)
{
return make_pair<string,string>(vec[0],vec[1])
}
int main()
{
map<string,string> map:
map.insert(XXX(vector))
} >>137
C++17の std::optional を使うところかな
戻り値をstd::optional<std::pair<string, string>>にして
意味論的に不正な場合は std::nullopt を返す
C++17以前なら boost::optional もあり あぁスマンmapに入れるのか
でも１つしか無かった場合もmapに入れたいのかエラーにしたいのか？？
あとmake_pairは関数だからテンプレート引数は省略できるよ >>127
キチガイ死ね
韓国人死ね
>>128
それはCへの回帰だぞ。お前は多分理解して無いと思うが。 >>137
nullobjectパターンかね
mapで絶対検索されないキーを突っ込んでおくとか >>137
何を返しても嘘になるので、返してはダメ
if (vec.size() < 2) throw logic_error{"runt vector"}; もしくはassert(vec.size() >= 2); name=valueみたいなのを分割してmapに入れる感じ？
俺も例外投げて止めてしまった方がいいねと思うね だが待ってほしい。
例外を投げるということは誰かに責任を押し付けることではないだろうか。 >>129
C++より簡単でお気軽な言語が大量にある今、C++で全くの初心者用の環境を要求すること自体が間違い。
それはトレーラやユンボでド初心者を教習するのに近い。
そうではなく、まず普免を取ってからこれらの特殊車両だろ。
お前は「俺はトレーラー乗りになりたいから、最初からトレーラーでやってくれ」とゴネている教習生なんだよ。
C++のオブジェクト指向でいい本が「世界中に」ない＝C++やるような奴にはそんなもの需要がない
でしかない。お前はそれすら理解出来ない馬鹿なのに、
> C++の本を書くような人はオブジェクト指向の説明をするのは沽券に関わると思っているのか、
> あるいは「C++の専門家」にはオブジェクト指向を教える能力がないのか。
ってのは自意識過剰すぎる。世界はお前を中心に回っているわけではない。
C++を使う必要がある局面でC++を使う人たちには、今更オブジェクト指向なんて教える必要がないんだよ。
それは自明だから。
そして本を書いている奴らも別段崇高な精神を持って布教しようとしているわけでもない。
いや、そういう奴もいるかもしれないが、当然「売れるから書く」という下俗な奴も世界には必ず居るはずであり、
そういう奴らすらいない＝売れない＝需要がない＝みんな既に知っているから、でしかない。
だいたい、オブジェクト指向ってのはプログラミング手法であり、
言語とは別の軸なのだから、「『C++の専門家には』オブジェクト指向を」ってのも論理的におかしい。 そもそもオブジェクト指向がさも特別で崇高な存在だ、なんてのはJava教団がそうしたがっているだけで、
実際のところは、Cで大規模コードを扱うと、最初はstruct*、次に関数ポインタの嵐になり、
これらをどうにかしてコンパイラに自動的にやらせよう、として生まれたのがC++のオブジェクト指向だ。
だから既に言ったがC→オブジェクト指向は完全に地続きなんだよ。
これは出自からしても当然で、
Cの典型的な問題点を新たな言語サポートにより解決することを目指したものがC++だから。
逆に言えば、C++98で搭載されている機能はほぼ全てCの問題点の克服であり、
Cを使いこなしていた連中にとっては当たり前に「その気持ちは分かる」ものでしかない。（なお同意するかは別)
そしてオブジェクト指向もこの中に入っている。
だから当初からオブジェクト指向の有効性をわざわざC++で語る意味はなかったし、
他お手軽系言語が乱立している現在、さらに輪をかけてその必要性がなくなっている。 それでも初心者が「オブジェクト指向自体を学びたい」ときにはどうすればいいかと言えば、
俺個人は「まず3k行程度なら平気で書けるようになってからでいい。そうすればおのずと分かる」という立場だ。
しかしそれでもHellowWorld直後のド初心者に教えようってのならJava教団みたいに洗脳していくしかない。
どう見ても実行に直接関係ない記述の嵐であり、ド初心者にとっては「無駄じゃね？」としか見えないだろうし。
だからこの意味ではJava教に入信しろ、というのもありではあるのだが、
問題はJava教団はJava教の不備は絶対に認めないというか、気づいてないことだ。
関数ポインタさえあれば非常に単純に実装できることを、無理に継承を導入したおかしな構造で対応し、
しかもそれをデザインパターン(ｷﾘｯと公式化しようとしている所が滑稽だ。
しかし、Java教信者は関数ポインタの存在を知らないから、この教義がおかしいとも気づけない。
また、Javaのオブジェクト指向は今既に邪道で、オブジェクト指向するのが目的化してきてる。
例えばprivateにすること、イテレータを実装することが目的になってるだろ。
だから実際に前スレ896みたいな事も平気でやる。本当に全く意味が無い。
(これについてはLinusはC++erも同様だと言っているが)
だからJava教でオブジェクト指向を学ぶのは、邪教というか、
邪オブジェクト指向を学ばされる可能性がかなり高いのでオススメしない。 結局、オブジェクト指向は｢学ぶ｣物ではなく、本来は｢悟る｣物なんだよ。
そしてそれは涅槃の境地で解脱しろ、みたいな崇高なものではまったくなく、
「この交差点、信号無いと危なくね？」位の、普通に運転してりゃ分かるだろ、程度の物でしかない。
だからわざわざ解説するほどのことでもないんだが、結果的に、
｢オブジェクト指向しろ｣と言われる割には解説本がなく、初心者にとってはなんだかよく分からん状況になっている。
そしてお前みたいな馬鹿は｢幼稚園で『どこに信号を立てるべきか』きっちり教えるべきだ！
俺は教わっていないから分からない！教えられる先生もいないのか！」
と主張するわけだが、完全にモンペ通り越してキチガイだろ。
オブジェクト指向は幼稚園で教えるべき内容ではないし、教えなくとも自然と理解できる物だし、C++は幼稚園ではないし。
そして脱線すると、「結局オブジェクト指向はよく分からんね｣というゆとりが逃げ出した結果が関数型祭りだ。
いや結果的にはC++/C#/Javaの全てがラムダを導入したのだから、一定の成功を得た、と評すべきかもしれんが。
しかしErlangみたいに「オブジェクト指向での限界を突破する」為の明確な方策がなく、
単に馬鹿な連中がより簡単な関数型に逃げ出しただけであり、そこで何か新しい境地が拓けるものではなかった。
そしてGoも俺はこれに似た匂いを感じてる。C++出来ないゆとりが集まっただけじゃんこれ、みたいな。
ただし、確かにC++は無駄に複雑化しているのも事実だが。
> Java鹿
それ、読み方は「Ja馬鹿」ね。ただ表記上分かりやすいので「Java鹿」にしてるが。 まあ俺はゆとりは死ねとしか思って無いからな。
つか、この程度の文も読めないのなら、お前ら仕様書や本も読めないだろ。
向いて無いからプログラマ辞めろよ。 >>148
そこはまぁその関数の仕様として、呼び出す側が確実にcatchする責任があるわけだな。
それを忘れると例外が呼び出し階層を突き抜けていっちゃう。
そういう事態を防ぐために考えられたのが検査例外だけど、これはこれで使いづらい面があるんで
Java以外にはあまり採用されなかった。
そんなことを考えてみると>>137程度の目的で例外などという暴力的な仕組みを使うのがそもそも
適切なのかどうか。Goの選択もそういうことなんだろう。 ttp://nekko1119.hatenablog.com/entry/20120625/1340602468
main関数の最後にあるstringへのキャストでエラーがでるのですがなぜですか。
エラー C2440 '型キャスト': 'Any' から 'std::string' に変換できません。
コンパイラはvc++2017です。 >>158
> Goの選択もそういうことなんだろう。
Goのって「自分でthrowしないといけない例外｣だろあれ。
あれなら普通の例外のほうがよかったんじゃ…と思ったけどね俺は。 >>159
(string)をany_cast<std::string>にすれば通りそうだが >>161
通す方法ではなくてなぜ通らないのかが聞きたいのですが
template<Type>
operator Type()
で暗黙の型変換のオーバーロードを定義しており、
int型やHoge型に対して代入する際にそれが使われているのに
std::stringに対してだけうまくいかない理由はなぜかが知りたいです。 >>162
intのとこもHogeのとこもキャストは使われてないように見えるが…
でもまぁ確かに呼ばれてほしい気もするね
static_castでもだめ？ すいません。勘違いしてる部分がありました。
std;;stringだけじゃなくて他の型でもダメみたいですね。
質問取り下げます。もう一度自分で考えてみます。
>>161
失礼しました。 >>162
gcc 7.1.0とclang 6.0.0では通った
ただしstd::type_infoと書くべきところをただtype_infoと書いてる個所があるので、それは直したけど。
それより下のコンパイラバージョンだとエラーになった。(ambiguous conversion)
そして
(string)val
の代わりに
(const string&)val
と書いたらclang 4.0.1でも通った。 (int)valはいけますけど
(Hoge)val, (std;;string)valはダメのようですね。
で、ご指摘のとおり
(Hoge&)val, (std::string&)valは通りました。
前者と後者の違いは分からないですが。 & の意味が分からないなら、プログラミングできない
(int)val
普通、こういうキャストの書き方は、しない
static_cast など数種類あるキャストの書き方の中から、
キャストの種類を指定してキャストする
君は、入門書を読んでいないだろ >>143
newの代わりにmalloc使ってるとか思ってるアホ？
今時new使うやつは以下のどれか
* Javaから来たC++初心者
* 化石コンパイラ使わさせられてる可哀想なやつ
* 自身が化石な可哀想なやつ
* パフォーマンスのために用意されてない構造の実装が必要なライブラリ設計者
お前は1番目と3番目の複合型だろうね。 template<class Type> Any::operator Type() const
上をやめて、下の２つを定義したらmain関数の記述そのままでうまくいきました。
template<class Type> Any::operator Type&() const
template<class Type> Any::operator const Type&() const
理由は分からないです。分かる方がいたら教えてください。 & の意味が分からないなら、プログラミングなんて出来ない。
初歩の初歩なのに
まず、入門書を読むこと >>144
>>139
>>145
基本的には2以下は存在しないから例外処理組み込もうと思ったけどnullobjectってのがあるのね
おそらく俺の理想的にはこいつが適してそうだからこいつを調べてみるよ
>>145の言うとおりに絶対に呼ばれないキーをいれておくのも検討違いな気はしてる >>147
まさにそれをしようとしてる
そこのロジック的には空文字入れる予定だから必ず2以上になるのだけど
関数分割していて関数としては何が返ってくるか不明なため
問題が起きたときのコードを記載しようとしてる
vectorのsizeが0や1の時にアクセス違反になってしまうからどうやれば回避できるのかなぁと悩んでる
例としてはこんなん
=value
key=value
key=
==value >>171
確かにそうだね
それにclangの最新だと通ることから、それなりにややこしい話かと思う >>173
> key=value
これは正常ケースだよね
> key=
仕様によるけどvalueに空文字入れときゃいいんじゃね？
> =value
> ==value
エラーでしょ？
例外発生させるなり、ログ採ってnullptr返すなりしなよ
そんなものを無理矢理 map に突っ込もうとするのがおかしいと思うぞ ＞vectorのsizeが0や1の時にアクセス違反になってしまうからどうやれば回避できるのかなぁと悩んでる
vectorの要素数が不確定の場合はatで取り出せばいいよ、なんかあったらout_of_rangeが飛んでくるから >>175
空文字入れるのはできてる
ただベクターの生成は別関数が行うから引数に渡されるベクターにいくつ値が入っているか不明
だからマップ作成側で個数を意識する対策する必要あるよね？って話
ベクターの生成に関しては実際問題ない
>>176
try catchするしかないのかな
nullopt返そうとしたけど実装無理だったわ... 例外投げるかなにかしとけばよいって
ロジック的に要素数2未満はあり得ないし想定してないんでしょ？
余計なことする必要ないって、以降の処理が余計ややこしくなるだけだから
エラー処理が適切 あってはいけないことなら assert で止めてしまえよ assertは良いがリリースビルドで消えてなくなるから
それがあってるかどうかだな
よほど条件に自信があればassert >>178
おいおい、例外をエラー処理以外に何に使うってんだよ >>182
だから、エラー処理が適切だから
例外投げてエラー処理でもしとけば？と書いてあるはずだが・・・
ただこの手合い、例外投げて、それを受け取ったからと言って
リカバリーしてプログラムを再開できるかはわからないよなぁ
プログラム本体の状態を一切汚さずに(書き込まずに)
新規領域のみで何か処理をして
例外が飛んで来たら全てを無かったことにする・・・とか
例外でやる場合は例外安全を確保するのが結構面倒なんで
プログラムの末端から例外投げるのは最後の手段にしたい
だから「実際に実行してみないとエラーが出るかわからない」系のエラーが無いのであれば
早期の段階で入力データにエラーがあるかどうか精査して、エラーがあればその旨返して
以降はエラーが発生しない前提で処理する(ので巻き戻すことは考えない)
もし不慮のエラーが発生したら、バグであるからログ吐いて異常終了
可能なかぎり、なるべくこちらで行きたいわけで >>177
optionalを挙げたものだけど 惑わせたようで申し訳ない
insert 前にチェックして不正ならそもそもinsertしない設計を考えてました
結局 optionalを返す insert / find を自前実装することになるから
そんな面倒な事せずに 素直にXXXで例外投げても全く構わないと思う
一応詫び代わりに書いてみたけど 鵜呑みにはしないでください
C++17 例外なし 読みやすさのためにautoなし
https://wandbox.org/permlink/rag4d7YPqwPKQpNq 検査可能な事前条件はそりゃ呼び出し側の責務にしたいわな >>177
> ただベクターの生成は別関数が行うから引数に渡されるベクターにいくつ値が入っているか不明
.size で取ればいいだけだろ
そもそも name=value のパース結果をベクターで渡してくると言うの設計もどうかと思うが
> だからマップ作成側で個数を意識する対策する必要あるよね？って話
そうだよ、その対策を>>175にかいたつもりだが...
もしかして
name=
と
=value
の両方とも vec[0] にしか入れてこないとかなってるんじゃないよね？
だとしたら生成部分を直さないとどうしようもないけど 色々とありがとう
最終的には呼び出しもとでtrycatchすることにしました
>>188
両方とも0 1の要素に値いれてるね
もう一個別件なのだけど
ファイルの存在チェックとファイルのオープンエラーについて教えてほしい
ある設定値は特定の設定ファイルが存在するにも関わらず読み込めなかったときに有効になるものとしたい
且つ設定ファイルが存在しないときもある
(設定する値が二つある。ひとつはkey=valueの形のvalue、もう１つは正常にファイルから値がとれたか否か)
ファイルが存在しないときはvalueの値をデフォルトで扱う必要があるので、
単純にファイルオープン処理を用いて一度で処理できなかった
(ファイルがなくて開けないのか、あって壊れていて開けないのか判断できないので)
そのため
statでファイル存在有無チェック→ファイルオープンとしたのだけど
タイミングが一致してないので刹那のタイミングでのファイル焼失を担保できないと言われている
どうすればファイルがなくて開けないのか、ファイルが壊れていて開けないのかを判断できますか ファイルオープンの開けませんでした例外をキャッチしたらええやろ keyにデフォルト値が存在するなら、最初にデフォルト値のmapを持つ。
ファイルを読み込んで存在したキーだけ上書き更新する。
だけでいいだろ。ファイル読み込まれなければ全部デフォルト値のままだ。 例外見ろよ
std::ifstreamならstd::ios_base::failureだからcode()の戻り値見ろ
何のために投げてると思ってるんだ >>168
ゆとり死ね
お前は何も分かってないし、学ぶ知能もない
>>190
> 刹那のタイミングでのファイル焼失を担保できないと言われている
てかそいつに聞けよ。
課題として与えられてるのなら、そいつは「考えさせることに意味がある」と思っているのだから、
こんな糞上司に付き合ってられるか、と思ってないのなら自分で考えろよ。
ここで聞いているのは宿題の答えだけ写しているようなもので、全く上達しないぞ。 ファイル存在チェック→オープンがアンチパターンなのは常識だろ何言ってんだお前 相変わらず持論展開ウザ杉るの自覚してないな
アスペウンチ君 割とタイムリーな話題というか、ここ一週間ぐらい、実行時エラーやら例外やらが発生したとき
どうやったらプログラムを安全に再開するか考えてた
で、至った考えは、ひとまとまりの一連の処理を二つに分割して
まず前半はread onlyセクションで、プログラム本体の状態を書き換えてはならないが
そのかわり例外が発生したら、無かったことに出来る(なのでread onlyにしておく)
後半はwritableセクションで結果をプログラム本体に反映させるが、その代わり例外(失敗)は許さない
bool func(){
hoge_type result;
try{ result = sub1(); sub2(); }catch(...){ /*リカバリ可能*/ return false; }
try{ hoge = result; }catch(...){ /*リカバリ不可*/ abort(); } return true;
}
ただこれでもあまりうまくいかなくて、sub1()とsub2()が上記ルールに従ってたとしても
sub1()は成功してsub2()は失敗した場合に困る
全体としては失敗だけどsub1()は既に成功していて結果も反映されているので
sub1()の実行を無かったことにして巻き戻すのは難しい
sub1()をsub1_read_only()とsub1_writable()に分解するという方法もあるかもしれないが
データの受け渡しで苦労するし、可読性が落ちるうえ、複雑なことはしにくくなる
もう一つの別の要求もあって、重たい処理は別スレッドで実行して即座にGUIスレッドに制御を返したい
ということはユーザーは重い処理のキャンセルが出来るだろうが
処理のキャンセルは例外からのリカバリと本質的には全く同じこと
また、先ほどのread onlyセクションはプログラム本体の状態を書き換えない前提なので
別スレッドで実行したり非同期に同時並行で実行したりが出来る
(ただし、誰かがwritableセクションを実行したら、そいつ以外の処理結果は無効になる
古いデータに基づいて処理した結果ということになるので・・) 上記のようなことを総合的にまとめると
void func(){
// read only セクション
barrier();
// writable セクション
}
という結論に至った
ただし、func()はコルーチンから呼び出す
read only セクションでは、必要であれば処理を別スレッドで処理を実行することが出来、自身はyield_returnする
投げた処理が終わるとメインスレッドにて続きから再開してもらう
read only セクションでは、新たなコルーチンを作成することが出来、作成元のコルーチンと親子関係を構築する
親子関係を持つコルーチンの全てがbarrier()に到達するか終了してからでないとbarrier()以降は実行されない
親子関係を持ついずれかのコルーチンがread only セクションにて補足されない例外を発生するか
もしくは外からキャンセルされると、無かったこと扱いになって
全ての親子関係を持つコルーチンにおいてbarrier()以降は実行されない
(親子関係の有る複数のコルーチンの処理が一端barrier()で止まって、全てが成功したのを確認してからbarrier()以降が再開される)
コルーチンにはグループNoを設定することが出来る
違ったグループNoを持つコルーチンを同時に実行することはできない(終わるまで待つ)
同じグループNoを持つコルーチンは同時に実行できるが
いずれかのコルーチンがyield_returnした段階で、それと親子関係のあるコルーチン以外はすべてキャンセル扱いになる
たとえばボタンAを押して処理Aが始まったが処理Aが終わる前にボタンBが押されたら
処理Aはキャンセル扱いになって処理Bが反映される
キャンセルされると困るような処理は別のグループNoにしておく
というような感じでひとまず落ち着いた
グループNo周りはかなり暫定的な感じだが・・・
以上日記 32 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 07eb-5mWG)[sage] 投稿日：2017/11/26(日) 17:30:11.12 ID:DaGrByo80 [1/4]
C++入門書でよく勉強したはずなのにautoとかconstexprとか知らんもんが一杯…
35 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 07eb-5mWG)[sage] 投稿日：2017/11/26(日) 17:38:44.74 ID:DaGrByo80 [2/4]
>>32
やさしいC++第3版
大体9年前に買ったのを寝かしといて最近になって勉強し始めたが、そんなに仕様変更ないと思ってたが間違いだったようだ
36 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 07eb-5mWG)[sage] 投稿日：2017/11/26(日) 17:39:04.93 ID:DaGrByo80 [3/4]
>>33だった
39 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 07eb-5mWG)[sage] 投稿日：2017/11/26(日) 17:52:39.37 ID:DaGrByo80 [4/4]
Effective Modern C++17出たら買ってみるわ
95 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 07eb-5mWG)[sage] 投稿日：2017/11/27(月) 12:49:42.23 ID:vi7VqSly0 [1/2]
遠回しに他の言語の本読めって言っとるようなもんだ
98 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 07eb-5mWG)[sage] 投稿日：2017/11/27(月) 13:23:45.26 ID:vi7VqSly0 [2/2]
>>97
ああそういうことね
132 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 07eb-5mWG)[sage] 投稿日：2017/11/28(火) 12:26:15.71 ID:+ODnZXKO0 [1/2]
Java原人がいるようだね
156 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 07eb-5mWG)[sage] 投稿日：2017/11/28(火) 23:59:58.99 ID:+ODnZXKO0 [2/2]
ワッチョイって神だわ
199 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 07eb-5mWG)[sage] 投稿日：2017/11/29(水) 21:47:36.72 ID:ZCDC/+v90
実際にスレ汚しとるのはお前だけどな
さすがゆとり、これらが役立つ投稿のつもりらしい。 バックアップの、3-2-1 ルール
同じデータをコピーして、3つ持つ。
2つの媒体に保存する。
1つは、離れた場所に持つ >>200
SQLite3使ってみろ。
>>201
C++はyeildも入れたのか？と思ったがstd::yieldはただのsleep(0)か。
まああまり凝ったことしても、とも思うし、そもそもGUIはC++で無理に組む意味無いぞ。
それも含めて自由にやればいいとも思うが。
>>125
君は何が言いたかったのだ？
分かると思うが俺がゆとり死ねと言っている奴だ。
見る限り、君は話す気はあるようだ。
125は唐突過ぎてスルーしたが、相手してもいいぞ。
ただし125はバラけ過ぎているからテーマを絞れ、と言いたいところだったが、
その日記を読む限り上段落の話は一連のテーマか？
だったらWeb系の連中ならそこは「DBを使う」って事になっている。
C++は自前で何でもできるから、無意味なほど精神論で速度を追求するわけだが、
そこらへんをサクッと割り切るあいつらのやり方にも学ぶ物はあるぞ。
そもそも自前でトランザクションを実装するとか、検証の手間まで含めたらありえんだろ。
精神論でゴリゴリではなく、上手く手抜きするコツも覚えるべきだ。 実際問題、メモリやデータだけを復元の対象とするとしたら
DBなど使わなくとも原本を保存しておけば何があっても元に戻せるのだが
そういう話ではないし
どのみち非同期処理にC#よろしくコルーチンが使いたいわけで
ただしそのままでは並行して細切れに処理が走って危険なので
書き込む前にbarrierを設けようというアイデアがまずあって
そうすることでついでに例外安全性も確保できるし
ならばキャンセル処理もできますわなぁという巡り合わさった面白い話 >>194
確かにそうだね
ありがとう
自分なりに調べて回答も出たのでそれでいくことにします >>206
> 巡り合わさった面白い話
まあ俺は単に張り切りすぎだと思うけど、
そういうところを含めて無駄に熱いのがC++erのいいところでもあるとは思う。
Web系の奴らは上手くこなすことだけを考えていて、自分で考えることを止めてしまってる。
あれでは上達しないのも分かる。
>>200
一応捕捉しておくと、SQLite3はDBだが鯖形式ではなくCのライブラリ(DLL)だからC++から直接呼べる。（はず）
ソースはパブリックドメインだからDLできるし、もちろんincludeしても使える。
(https://www.sqlite.org/quickstart.html // サンプルが extern "C" ではなく include かよ！）
DBはメモリ上にも置け、当然爆速だ。自前でトランザクション/ロールバックの仕組みを作るよりだいぶ楽。
公式に素晴らしいドキュメントがあるから詳しくはそこを読みまくったほうがいい。
C++erなら問題はSQL位だが、どうせいつかLINQもC++に導入されるだろうし、予習だと思ってやっとけ。 例外投げるってのは自分の責任の範囲外の事象が起きたときじゃないのかね
有効無効の意味合いならブール値返したほうがいいと思う 一応いまのところこんな感じで書けるようになってる
やってることが非同期処理なので多少ややこしいのは本質的に仕方がない
int func_async( int n ){
if( n == 0 ){ return 0; }
a_wait() << [&]{ sleep( 10*1000 ); };
//↑非同期で何か重たい処理
//↑別スレッドに投げたのちyield_return;
int resunt;
a_sync() << [&]{ //コルーチン作成
resunt = func_async( n - 1 ); //再起呼び出し
};
//throw nanika;
//↑仮に誰かが例外を投げれば親子関係のあるすべてのコルーチンの処理が
//↑キャンセルされて、どのコルーチンもbarrier以降は実行しない
//barrier前なのでresultの値は不定
barrier();
//barrier後なのでresultの値が決まる
return n + result;
}
int main(){
a_sync() << [&]{ //コルーチン作成
int result;
a_sync() << [&]{ result = func_async( 10 ); }; //コルーチン作成
barrier();
printf( "%d\n", result );
}
message_loop();
return 0;
} C++の名前空間と呼ばれるのがあまり理解出来ないんだが
Javaでいうパッケージ的なやつ？
それともそれを使うためのパスワード的なやつですか？ >>212
複雑っていうけど、元から非同期処理なんか、どう書いたって複雑だろ
>>211はお遊びでワザとコルーチン作りまくってるだけだし
あの程度の事なら本当はこれでいけるわけで
int func_async( int n ){
if( n == 0 ){ return 0; }
a_wait() << [&]{ sleep( 10*1000 ); }; //非同期処理
return n + func_async( n - 1 );
}
int main(){
a_sync() << [&]{ printf( "%d\n", func_async( 10 ) ); };
message_loop();
return 0;
}
別に複雑と言うほどでもないし
非同期処理を同期処理みたいにかけるというだけ
あとはキャンセルと例外安全のためにbarrierの機能を追加しただけ >>214
まず、君が書いているんだから君が好きなようにやるべきだし、
実験的な意味合いも含めて色々やること自体はいいと思うが、、、
非同期にしてるのは何故？GUIからの呼び出しでC#のasync Taskと同じ状況か？
それなら確かにどうしようもないが、しかし今見てみるとC#のasyncもだいぶ筋が悪いとは感じるね。
そのケースなら、普通にマルチスレッドした方がすっきり書けるはず。
あと、コルーチンからのthrowって、君の意図しているようにドミノ倒し的に回収できるものなのか？
これは俺が仕様を知らないだけではあるが、普通はコルーチンってそういう使い方しないと思うし。 >>あと、コルーチンからのthrowって、君の意図しているようにドミノ倒し的に回収できるものなのか？
そういう風にコルーチンを実装した
具体的にはコルーチンのメンバにキャンセルフラグを持たせておいて
コルーチンを外部からキャンセルしたいときはそのフラグを立てる・・・だけ
コルーチンがyieldから再開したら真っ先にそのフラグを読みに行って
もし立ってたら自発的に例外を投げてスレッドを巻き戻す
>そのケースなら、普通にマルチスレッドした方がすっきり書けるはず。
あくまでこれは例だからなぁ
上で書いた内容もそうだけど、ひとつコルーチンがシングルスレッドというのがミソになってて
マルチスレッドだと排他処理が非常に面倒なことになる場面でも
コルーチンはシングルスレッドだから問題にならない
ただ、yieldの前と後ろで時間的につながりが無いことが問題になるので
誰かが何かを書き換える前にbarrier()を設けるルールを作って、他のコルーチンを無効にする
非同期処理なんかまともにやったら頭がおかしくなるに違いないので
横断的に静的に管理したいなぁと
今までコルーチンは全然使わなかったし、完全にマルチスレッド脳だったんだが
コルーチンはかなり脳の負担が少なくてよい
自分が動いているときは必ず他人は止まっているという性質が良い
yieldの前後だけ気を付ければ後は完全にシングルスレッドのノリで排他処理が要らない
ただ逆に同期オブジェクトをLockしたままyieldしたら終わるという
>C#のasyncもだいぶ筋が悪いとは感じるね。
正直、あれの使いどころは俺もよくわからないんよなぁ
複数のコルーチンが同時並行で走ったら危ないから結局画面をロックせざるを得ないんじゃないかとか
キャンセルを受け付けられるようにするためには例外安全についても考えないとダメなんじゃないかとか
色々思うところは有るが、実はよく知らん >>216
async/awaitのしくみはawaitするタスクの完了時に呼ばれるべきコールバック関数登録の糖衣構文にすぎないとかそんな感じ、
ttps://qiita.com/ryosukes/items/db8b45c8ea42f924f02f
（まんまC#の関数で説明したページもあったはずだがどっかいったのでJavaScriptの例↑
で、ネイティブスレッドX上でasync/await呼び出しをいくつ書いても上記コールバック関数は単一スレッドで実行されるので
Xに対して同期的なデータへのアクセスはロック不要
ウィンドーズホンのGUIをぬるぬる動かすのがほぼ唯一の存在意義 つまり同一スレッド内であればasync/awaitをいっぱい書いても複数のコルーチンが順不同でresumeされる感じにはなるが真に同時並行で実行されることにはならない なお順不同なresumeというｼﾁｭは、関数A内でawaitされるasyncタスクB内でタスクCをawaitする…とかいったケースで容易に生じる
この場合A内のawaitに引き続くのコードと、B内のawaitに引き続くコードのは順不同でどっちが先にresumeされるかわからん
しかし真に同時並行ではなく、同期的 ttps://stackoverflow.com/questions/1724036/splitting-templated-c-classes-into-hpp-cpp-files-is-it-possible
Your template classes must represent only data structures not the algorithms.
This enables you to hide more valuable implementation details in separate non-templatized class libraries,
the classes inside which would work on the template classes or just use them to hold data.
この回答の具体的な例を教えて頂けないでしょうか。
std::vector（データ）とstd::algorithm（アルゴリズム）と思ったのですが、
std;;algorithmはnon-templatized classではないですよね。。。 >>217
> あくまでこれは例だからなぁ
もしかしてコルーチンを自動的にマルチスレッド展開して加速させる為のラッパを用意してるってことか？
それならまあそのコードの感じになるのかもしれん。
ちなみに言っておくと、俺が普通に実装したら>>215と同じようなものになる。
単純に、「ディスパッチして、joinを待って、commitする」としか読めないコードにする。
ただこれは君ももちろん分かっていて、あのコードなのだとは思う。
なお俺はC#のasyncは設計ミス、
・UIコンポーネントがUIスレッドからでしか触れないこと
の対策だと思っている。あれが無いと毎回invokeするとか、ちょっと回りくどい書き方をするしかない。
実際、Thread->backgroundWorker->Task->async Task だったっけ？何度も変更されていて、
こういう場合は通常、
・修正している奴が馬鹿だから修正のたびに新たなバグを仕込んでしまい、収拾がつかない
わけだが、ヘルズバーグとMSがそこまで馬鹿なはずも無く、もう一つのケース、
・根本の問題を修正せずに表面的に対策をしているから、収拾がつかない
のだと思っている。そして、根本の問題は、最初に書いたUIガー、って奴。
これについて「根本のUIスレッドの問題直せやボケエ」ってをずいぶん前にC#スレで議論した覚えはあるが、
UIをマルチスレッドにして悲惨だった歴史が既にあるらしく、
「オメーがラップすりゃいいだけだろボケエ」と返され、あ、確かにそうだな、と思って終わった。
ま、とにかく、UI関係のコードをスッキリさせる為の物だから、気になってないのなら放置でいいと思う。
> yieldの前後だけ気を付ければ後は完全にシングルスレッドのノリで排他処理が要らない
コルーチンの方がいいケースについてか。
うーん、どうなんだろうなあ？俺もコルーチンはほぼ使ってきてないが、
マルチスレッドする場合にはほぼ干渉しない場合に限っていたから、
逆に言えば、コルーチンを使えばもっと並列化できるということか？ Eigenで透視投影変換行列を作るのは次の書き方でいいんでしょうか？
なんか結果をみても微妙にずれているのですが．．．
Eigen::Matrix4f perspectiveMatrix(float left, float right,
float bottom, float top,
float near, float far)
{
Eigen::Matrix4f m;
m << 2.0f*nearZ/(right-left), 0.0f, (right+left)/(right-left), 0.0f,
0.0f, 2.0f*near/(top-bottom), (top+bottom)/(top-bottom), 0.0f,
0.0f, 0.0f, -(far+near)/(far-near), -2.0f*far*near/(far-near),
0.0f, 0.0f, -1.0f, 0.0f;
return m;
} await/asyncのコルーチンは並列化じゃなくて非同期処理を同期処理っぽく書くための物だとおもうよ
「これを実行して、終わったらこれを実行してね」
っていうときに、スタックの内容がそのまま残ってるからデータの受け渡しが楽というだけだろう
ただ>>220が言ってるように順不同のresumeが起こったらアブナイので
何か書き込む前にbarrierを張って自分に関係が無い実行中のコルーチンを全部キャンセルして始末してしまおうという
(実際にはbarrierだけじゃなくawaitのタイミングでも始末するようにしているが)
ただキャンセルするために例外安全性とかも重要になってきて
ここでもbarrierとコルーチンの仕組みがそのまま活躍するのが、なんか不思議な感じなんだが
読み込みオンリーだけどキャンセルできるセクションと、書き込みできるがキャンセルできないセクションに
処理を分けるというアイデアはなかなか汎用性が有るんじゃないかと
で、二つのセクションは別関数にせずにコルーチンでつないで一つの関数に収めbarrier前/後とし
barrier前ならawaitも使える、と、2,3のことが同時にかたづいて気持ちが悪い exec execve などいくつかあるけど
こいつらの違いを理解できない
ここの人たちはmanページを読んで理解できるもんなの？ >>227
解決しました。あれで合ってました。
間違ってのはモデル変換行列の方でした。 >>224
最終的に何をしたいんだ？
俺にはそこが見えない。
一つずつ詰めると、頭三行
> await/asyncのコルーチンは並列化じゃなくて非同期処理を同期処理っぽく書くための物だとおもうよ
> 「これを実行して、終わったらこれを実行してね」
> っていうときに、スタックの内容がそのまま残ってるからデータの受け渡しが楽というだけだろう
については同意する。これは>>218-220含めて3人の共通理解でいい。
(ただし俺には逆に、君自身は「並列化の為に」async/awaitを使おうとしているように見える)
> ただ>>220が言ってるように順不同のresumeが起こったらアブナイので
これについては、一般的には逆だ。順序が逆になったら危ないような物を非同期にしてはいけない。
違う言い方をすると、非同期の結果をbarrierを張ってキャンセルするのではなく、
barrier後に非同期にして、結果は必ずcommit出来る構造にする。
ちなみにJavaScriptの連中はここら辺が分かっていなくて、
(というより連中は制御構造云々を議論できるレベルではないのでこれ以前なのだが）
同期前提の制御構造で非同期を扱おうとするからおかしなことになる。
JavaScriptには非同期しかないんだから、選択の余地もないんだが。
C#のasyncはこれとはちょっと違って、イベントで起動するから必ずUIスレになるんだが、
それにジョブをやらせるとUIがカクつくから他スレッドを起動しろ、
しかしそれだと結果を画面に表示できないからそこだけUIスレッドを呼び戻せ、
ただこれだとソースが汚いから、asyncというキーワードをつけ、あたかも全てUIスレッドが処理しているように見せる、
みたいな、なんだかなあ、という状況になっている。
つまり処理順と処理スレッドを入れ替える為の糖衣構文のようなものであって、
本来のasync/awaitのように、非同期を同期的に書くための物自体ではない。ただしそうとも使えるから流用してるが。
それで話を戻すと、君は非同期部分に一般とは逆の「非同期の結果を普通にキャンセルできる構造」を作ろうとしているようだが、
これは何故？或いは何のメリットがあると考えている？ Java厨はハードの基本がわかってないニワカなんちゃってPGが殆どだからな 予告犯でホリエモンもどきがシンブンシにそんな事言っていたな コルーチンをキャンセルとか意味わかんない事言ってるから途中から読んですらない。 >>226
引数が違うだけで、内部的には、どれも同じだろ。
つまり、ラッパー関数
OS をすべて知っている奴は、いない
だから皆、神の書と呼ばれる、この本を枕にして寝ている。
著者は、man ページの作者。
この本が翻訳されているのは、日本だけ
Linux プログラミング・インタフェース、2012 >この本が翻訳されているのは、日本だけ
もうだめだこの国 Linux 資格の、LPIC 取得者も、半分以上は日本人だろ
日本は、Linux 大国 Linuxは日本に入ってきたのが早かったし、最初期に一気に広まった。
日本がLinux王国というのは間違いではない。
しかし、それを生かせなかった。
なんでだろ。 >>240
PC98 のリソースが freebsd に注がれ、linux への移植が遅れたため 当時書店でBoWとか売ってたけど、そのせいで遅れたような感じはしなかったけどなあ。
むしろLinuxでX11動かすのに四苦八苦してた頃、すでにコンソールで日本語が使えてたのは、
UNIXの人たちのおかげのような気がする。 検索してみるとコンパックショックが1994年なんだな。
DOS/V機自作したのが1993年だからもうちょっと前かと思ってたけど。
正規流通前にショップが輸入して売ってたんだろか。 その当時、漏れは、Windows 3.1 で、UNIX プログラミングやってた。
テキストエディタ MIFES を使っていた
Oracle で、銀行とか、新幹線とか >>245
＞銀行とか、新幹線とか
暗号方式はなにを使っていましたか？ NECは当時経営陣が自社の社員が開発したソフトを押し退けてＭＳのソフトをごり押ししてたからな
終わっているよな 派生クラスのデストラクタでなにもしないなら、
基底クラスのデストラクタを仮想にしなくてもいいですか？ >>250
自由にクラスを設計すればいいよ。
デストラクタを仮想クラスを必ず定義しておかなければならないとか、そんな義務はない。
あらかじめ定義しておくと、仕様変更があった時などで、派生クラスで、デストラクタを使いたい時に、基底クラスをいじらずに定義できるだけだよ。
仮に、複数人で、アプリを作ってるなら、基底クラス担当がいたとして、わざわざ基底クラスをいじりますよーとか連絡しないでいいという利点はあるかもな。
もし、基底クラス担当で、他人に基底クラスを触らせたくないなら定義しておいたほうがいい。
基底クラスをいじられて、変なバグとか追加されても困るｗ >>250
規格は知らんが問題が発生するコンパイラは存在しないと思う。が、デストラクタで何もしないというのはデータメンバーも含まれるからね。
派生クラスにstd::stringのメンバーが居るだけでアウト
そんな事を気にするより素直にvirtual付けるか基底クラスでdeleteされないようにする方が有意義に時間を使えると思うよ。 >>254
>派生クラスにstd::stringのメンバーが居るだけでアウト
それだけでアウトなのではない
DerivedがBaseの派生だとして、実体はDerivedなのにコンパイラからはBaseにしか見えないケースで問題になるだけ
DerivedをDerivedとして宣言したらスコープを抜けたらちゃんとDerivedのデストラは呼ばる
問題なやつの例：
Derived g_d;
void foo() {
Base* p = (Base*)&g_d;
/*...*/
delete p; // Base::~Base()は呼ばれるがDerived::~Derived()は呼ばれない
} ごめ、一点抜けた
誤： 実体はDerivedなのにコンパイラからはBaseにしか見えないケース
正： 実体はDerivedなのにコンパイラからはBaseにしか見えない状態で当該オブジェクトが破棄されるケース
なお、（規格でどういう言葉使いをしているかわ知らんが、）
Derivedが多態性をきちんと実装してあるなら、Derivedは「コンパイラからはBaseにしか見えないケース」には該当しない ごめ、一点抜けた
誤： 実体はDerivedなのにコンパイラからはBaseにしか見えないケース
正： 実体はDerivedなのにコンパイラからはBaseにしか見えない状態で当該オブジェクトが破棄されるケース
なお、（規格でどういう言葉使いをしているかわ知らんが、）
Derivedが多態性をきちんと実装してあるなら、Derivedは「コンパイラからはBaseにしか見えないケース」には該当しない >>255
だから
「基底クラスでdeleteされないようにする方が」
って言ってんだろ 大事なことなので2回ry
まあ一般論として、>>255の問題なやつがプログラム内に存在しないことの確実で安価で
ウザく無い検出方法というものはこの世に存在しないので、
継承関係を使うならデストラクタを見たらvirtualにするパブロフの犬に徹するべきではある ＞delete p; // Base::~Base()は呼ばれるがDerived::~Derived()は呼ばれない
~Derived()が呼ばれないけど、
呼ばれたとして何も仕事をしないのであれば、呼ばれなくても不都合ないのでは？ なにも仕事をしないデストラクタという前提がおかしいのですか？ メイヤーズが言ってる
ポリモーフィズムを目的とした基底クラスはvirtualデストラクタにする
それ以外はしないってルールでいいだろ >>261
Yes
デストラクターの仕事はプロクラマーの書いたコードだけではない >>260
このあたりで話題になったことがある。
https://echo.5ch.net/test/read.cgi/tech/1478440682/651-
結論から言うと不都合は有る。
少なくとも言語仕様上は未定義に踏み込むのでクラッシュしても泣かない強い心を持ち合わせているのでなければやらない方が良い。 >>254
暗黙的なメンバー変数の破棄が呼ばれるべきってのはあるけど、何もアウトなことはないぞ？ >>259
その考えはどうかと思うけどな
vtblが邪魔になるような、メモリ上では純粋にデータしか持たないクラスとか作れなくなるぞ 継承関係を使う＝vtbl
と考えてしまうような無知な者には理解するのは難しい
他人の作ったものも構わずナマポをdeleteしておいて「virtualにしておけば安全」というのはマッチポンプと言えよう 正直何を言いたいのかはよくわからん w
まあ>>251みたいな頓珍漢野郎なんだろう... >>270
いや、この件に関してはお前の方が無知だぞ 結局のところ
何も仕事をしないデストラクタはあるが、（空のデストラクタかつメンバ変数なし）
基底クラスのデストラクタだけで派生クラスをdeleteすることが未定義だから
基底クラスのデストラクタは仮想にしないとダメという理解でよろしいでしょうか。 デストラクタは仮想にしておくことにより通常の仮想関数と違って継承元辿って全自動ですべて呼び出されるから基底はやることなくても以後継承で実装を変更することがあるのなら空の{}で括っておいたほうが良いよ もしかして本当に継承使ったPOD型に思い至ってないのか くそー>>254の簡潔すぐる日本語のせいで暗黒の日曜日になってしまったわ、
だいたい質問者の>>250も簡潔すぐる
初心者質問と思ったし、だいたい理解している上で確認の意味で質問しているのならそう書いてﾎｽｲ、 もうここ完全に初心者様質問無しにしろよ
上級者様もそれで満足だろ >>278
漏れのように語りたい初心者は一体どうすれば…orz これまでinlineを関数に適用するとインライン展開されるんじゃなかったでしたっけ？
c++17の説明を読むと翻訳単位で共通のアドレスになるって書いてあるのだけど仕様が変わった？ 何を言っているんだお前は
ISO/IEC 14882:1998 7.1.2/p4
An inline function with external linkage shall have the same address in all translation units 以前void f(A &a, int num)をa.f(num)みたいに呼べる機能が追加されるとかされないとかを見た気がするんだけど知ってる人いたらURLか機能名を教えてほしい ウニファイドコールシンタックスは死んだのだ。
よみがえれ！ accelerated c++ をやっている人いませんか？
今やりなおしているけれども、5年ほど前の自分の回答をなくしてしまった…
4章章末練習問題4-6の回答を、よろしければお見せいただけませんか？
この章、EOLine と EOFile を std::cin の eof フラグ 1 個でなんとかしようとしているのが非常にまずいと分かりましたが
逆に教科書掲載のプログラムでうまくいっているのが不思議です…取り組まれた方のコメントをお待ちしています…
普通 getline() をつかうんだろうけれども、なんでこんなに変てこな実装になっているのだろう？
教科書の内容 https://ideone.com/rdtZWG
>>44-45 悪書を薦めてしまいました、ごめんなさい >>289
メソッドチェインしたいだけなら拡張メソッドの方が筋がいいだろ。そっち応援してやれよ 拡張メソッドってデコレータパターンで充分なのに、なんで最近の言語には結構ついてんだろ。 >>292
>>44-45
結局のところ、std::stringstream を使うべきだという結論になりました。（std::stringstream は今回初めて知った）
教科書本文（64ページ、項4.2.3、70ページ、項4.5）
https://ideone.com/F761bo
73ページの練習問題4-5の方は
https://ideone.com/H9iE4j
このように >>42 は多大な努力を強いられる教科書ですので、お勧めです、強くなりたい人はどうぞ
私はもう強くなくてもいいから、この本はもういいです…
教科書をお持ちでない人には関係ない話ですみません >>285
別に驚くほどのことじゃないし…
関数のインライン展開と、同じ機能の非インライン関数の存在は両立する
>>284の規定は関数のアドレスをとられたときのため用 >>151
template の話もお願いしていいですか？
型安全を優先するあまりに instantiate（これいい訳がないね） してまで、という思考と void * を許してしまう思考の両方について、比較していただくとうれしいんですけれども >>168
std::make_shared はあっても unique 版はない、とかなんとか、そこらへんが徹底されていない、とか、確かあったような気が >>150-152
ファイルのopen/close とか、RAII ／デストラクタが Java にもあればなあ、と思っています。
あと、Java の syncronized って、結局、テキトーなダミー変数を mutex 代わりにしちゃう、とかありません？ >>115
古来ゆかしき Boehm GC を思い出しました。これ、C++11 later とかの対応はどうなんだろう？
http://www.hboehm.info/gc/ よくわからん… >>101
＞K&Rも「関数ポインタも使えるよ」としか書いて無い。あれはもっと力説されて然るべきだった。
これが本題かな？
いや、関数ポインタってそんなに特筆すべきものだったかな…むしろ setjmp()/longjmp() の方がインパクトが、ってこれはexception として広く採用されていましたっけね
いや、関数ポインタってコールバック(とvtable）は別として、何か使えるネタが他にあるかなって考えてました、今のところ思いつかないな… >>99
＞(instance.method()とstaticMethod(instance)の実行時の違いがほぼ無い、
うーん、Java で、これでもか、これでもか、と this が null でないことをチェックするのを読んだことがあります。
C++ だと(virtual でなければ）普通に this = 0 にして this->method() できちゃうんですが、この this の null チェックって、広く行われているのでしょうか？http://codepad.org/gtEBWFKR これでおしまい
try～catch はいいとして、finally って使いにくい、というか使い方がわからないんですが、finally って意味あるんでしょうか？ > RAII ／デストラクタが Java にもあればなあ、と思っています
RAIIは7年前にジャバに入った筈だが
何を言っているのだろうか >>305
C++ 的にはなるべくデストラクタで後始末がつくようにやれというスタンスっぽい >>304
C++ ではヌルポインタからメンバ関数を呼び出すのは未定義だよ。
メンバ関数内でデータメンバにアクセスする要素がなかったとしても未定義。 this->method()は(*this).method()と等価で、ぬるぽに*適用したらその時点で未定義だからアウト 未定義だけどvirtualじゃなきゃ大抵動く
だからNULLチェックも意味がある thisをNULLチェックするようになったらそれはもう終わってるコード >>305
catchの中で再スローしてもとにかくリソースを解放したいとか普通にあるでしょ >>315
RAIIを徹底すればそんな危なっかしいことは不要 >>309
自分にレスすんなよ
見てて恥ずかしいだろ >>300
std::make_uniqueがあるだろうが（C++14） 返答を期待しないでただ聞いて文句言ってもらいたんですけど
03以来久し振りにc++いじってます
17だか20の最新仕様も未だにclassでgetter/setter定義しなきゃいけない仕様なんですかね？
C#のpropertyがあれば便利と思うんですけど。今あるか知りませんが
どうなんでしょ？今後の仕様も導入予定なし？
おやすみなさい >>311
いや、俺は意図通りに動かない場合にガチで遭遇したことあるからこれはホントにお勧めしない。 >>320
そもそも、せったげったってそんなに重要か？ 一応 >>324 を解説しておくと、 this が真のときはもちろん真だし、
this が偽 (ヌル) のときは未定義なのでどういう挙動をしてもかまわないので真と解釈してもええやろという超推論で常に真として扱われる。 できないよ
thisは常にconst修飾されている
禿本1stではthisへの代入があったんだけどね >thisは常にconst修飾されている
それは規格のどこに書いてあるのですか >>329
ご指摘どうも
struct X
{
void f()
{
decltype(auto) that(this);
that = nullptr; //ok
}
void g()
{
X* const it(nullptr);
decltype(auto) that(it);
that = nullptr; //error
}
};
確かにそのようで void f() constのことを言っているなら見当違いだが *thisじゃなくてthisのことだよね？
何かで「const pointerである」って読んだことあるような気もするけど、
そもそもprvalueにしか思えない。 this = だの &this なんてことは考えもしないので気がつかなかった ＝０とかじゃなくてpureとかそのまま書ければいいのに
そもそもなんで０入れるんだ vtblの関数ポインタをNULLにセットするっていうK&R時代の発想で決まった文法 独自拡張で0の代わりに関数ポインタ代入できるようにした糞コンパイラと
それ使ってイベントハンドラかなんかの設定するようになってる糞システムが
なんかあったような気がするけど誰か覚えてない？ >>340
実際には存在し得ない抽象クラス単体オブジェクトが指すためのvtableな
bcc32のバグで存在し得たことはあるが =0、漏れはしゅき！！！！１！！！！！１１！
キーワードを増やさなくて済む
切り札は最後までとっておくべきものじゃ つかpureみたいな柔弱で恥ずかしい感じのキーワードを追加してくれなくて本当に良かった C++98だかでポインタ値にNULLじゃなくて0を使うのが推奨されていた頃の名残じゃないかな
の割にはnullptrを指定するとエラーになるけど 文脈依存キーワードを導入しちゃったからな。
pure も有りといえば有りな気はしないでもない。 pure関数って状態を持たない関数であって純粋仮想関数とは別物だぞ >>347
標準委員の人がそういう意味じゃないよ。適当に決められたんだよ。って言ってた。 >>349
この話の流れで virtual pure function でないと思ってるお前が不憫だよ... =0は最初ボーランドが勝手に実装した、とどこかで読んだが
じゃあ=0より前のC++には純粋仮想関数は無かったのやろうか… ていうか
class Foo {
public:
void someMethod() { }
};
と書くしかなかったものが
class Foo {
public:
void someMethod() = 0;
};
になったのだとしたら
文字数的にもバランスがとれた良い追加構文 >>353
そこは俺もそう思う
しかし=0;なのにvirtualが必須なのはイヤ
基底指定子にpublicがいちいち必要なのと同じくらいに >>351
pure virtualだろ？virtual pureってなんだよ >>357
すまん、そんなアホなところにまで突っ込まないとダメなほど必死だとは思わなかったよ w 必死なのはお前だろ
誰と同一人物だと思ったんだw
俺この話に参加したの初めてだぞ ていうか>>349は>>345宛てじゃねーの？
それを踏まえて文脈依存うんぬんだと思うが 質問があります。
コンパイラはMicrosoft(R) C/C++ Optimizing Compiler Version 19.12.25830.2 for x86
class A {
public:
explicit A( void ) {}
};
struct B {
A a;
};
int
main( int, char ** )
{
B b;
B b2( {} );
B b3 = {};
B b4{};
return 0;
}
上記のソースをオプション/std:c++latestを付けるとエラー、つけないとエラー無しになります。
対処だけだったらAのコンストラクタからexplicitを取れば良いのですが、
何故エラーになるのかがイマイチ理解できていません。
C++17の波括弧初期化の型推論の新規則あたりがそれっぽいですがその辺を読んでも理解できていません。
（そもそも引数無しのコンストラクタにexplicitを何故付けるのかって突っ込まれそう） 前にgetter/setterプロパティ書いた者だす
getter/setterは有効な回答得られず
03→17/20でも、例えば
int& Status() { return m_status; }
const int& Status() { return m_status; } const
の二重定義必要？
おやすみなさい そんな糞みたいなgetter書くくらいならpublic変数にしたほうがまし >>360
5chは初めてか？
ちょっと肩の力抜けよ hage.sizeof みたいな書き方があってもいいけど、別になくてもいいからな
話は上がっているんだろうけど、優先順位はかなり低いと思うね >>366
constバージョンだけでよくない？
何で内部状態を他人に書き換え許可するのさ。 >>367
>>366のgetter/setterの中身はあくまでサンプルなのでは…
>>373
いちいちメソッド呼び出しの度に状態を引数渡しするほうが内部状態の露出として醜悪かもしれん…
つかデータメンバの書き換えはデータメンバの書き換えだからNGというものではなくて、
内部状態の整合性が保たれれば何だって良いんじゃ…
データメンバ直書き換えでなくsetterなら整合性をチェックしたり与えたりするチャンスがある
（あるいは排他制御とかやることもある…まあ慎重に考えたらsetterでやるよりロック回数が少ない方法がたいてい見つかるが、 アンカーミスった、
誤： >>373
正： >>372 >>366 の実装はサンプルにしてもありえないだろう。
一度呼ばれて参照を保存されたら、変更を制御できなくなる。
int& status = a.Status();
status = 2; >>377
それな。
中身だけでなく外見(インターフェース)も糞。かつそのインターフェースなら例外なく中身も糞になる ここでgetter/setter言ってるのは例外なくどうしようもない低能だから無視してあげて下さい int mydata() const; // getter
void mydata(int data); // setter
こういう感じの下駄瀬田は道南？ >>366のgetterの&を見落としていたorz
m_dataへのmutableなポインタを返すのではm_dataのgetterとは言えぬ メンバ変数hogeにgetHoge,setHogeなんて名前の下駄雪駄を
機械的に作ろうとしてる事自体が間違いの可能性を考えろ
class Window
{
int width, height;
...
//まちがい
int getWidth() const;
int getHeight() const;
void setWidth(int w);
void setHeight(int h);
//せいかい
Size getCurrentFrameSize() const;
void resize(int width, int height);
}; >>382
>>320は、Ｃ＃の機能があると便利ですねー。セッター/ゲッターが毎回定義するの？っていうお題じゃねーの？
どっからWindowやら、Sizeが出てきた？ クラス内部状態の変更は意味のある操作単位として外部に公開すべきであって
むやみに内部の変数を下駄雪駄として露出すんなっていうつもりだったんだが難しかったかな？ >>384
そんな分かりきったことを議論することではないだろ。
C++の規格が新しくなってsetter/getterは従来道理なの？が質問。
set/getするときは、直の変数の読み書きの代用だけではななく、何かの処理をしたりして公開/制限付き公開するものじゃねーの？ >>383
だからプロパティ単体で読み書きするのが常に正しい訳じゃないでしょってこと
> どっからWindowやら、Sizeが出てきた？
一例だってことわからないの？ >>385
従来通りだよ。
何がしたいのかはっきりさせないからこうなるんだよ。
メンバーへの代入のような記述でメンバー関数呼び出ししたいということか？ 昔どっかで下駄雪駄をクラスにして公開する方法が書いてあったな。
面白そうだったけと使おうとした事はなかった。 単にデータメンバー指定したらgetter setter相当のメンバー関数を自動生成するような機能が欲しいというなら他のやつが言うように思考停止したバカしか欲しがらない機能
EなんとかとかいうIDEには付いてるらしいが 理想はわかるけど、ある程度の規模のコードを書けば何だかんだでsetter/getterはけっこう書くだろ .netのPropertyは実際のオブジェクトがバッキングフィールドってとこに完全隠蔽されることがメリット
C++では自動実装は不可能、同じ効果を得るならばpimplパターンでオブジェクトを隠蔽は可というのが答えではないだろうか >>390
getterはともかくsetterは書かない setter/getter批判論者は何を批判しているのかいまいちわからん…
class SomeWidget { // GUIのパーツか何か
Color m_FgColor; // 前景色
Color m_BgColor; // 背景色
...
};
とゆークラスがあったとして、
void SomeWidget::setFgColor(Color color) { m_FgColor = color; }
void SomeWidget::setBgColor(Color color) { m_BgColor = color; }
というのはsetterだからﾀﾞﾒで、意味的にまとまりのある
void SomeWidget::setColor(Color fgColor, Color bgColor) { m_FgColor = color; m_BgColor = color; }
とかにしないとﾀﾞﾒだとかそーいう主張？
ｽｹﾞｰいらんお世話な気が… setter/getter自体を批判してんじゃなくて
自動生成をC++に求めるのを間違いだと言ってるだけだと思うが >>393
> void SomeWidget::setColor(Color fgColor, Color bgColor) { m_FgColor = color; m_BgColor = color; }
> とかにしないとﾀﾞﾒ
それを意味的にまとまりがあると考えるお前がおかしい
だからそんな頓珍漢なレスになるんだよ クラスにメンバーがいっぱい→それぞれの下駄雪駄をいっぱい作らなきゃ！→楽な書き方ないの？
っていう発想から抜け出せてないんだろうけど
この最初の矢印がそもそも間違いだって言ってんだよ
まずはどんな操作をpublicで公開すべきなのかちゃんと設計しろ、話はそれからだ
結果的にただのgetterとsetterとして実装されるものはもちろんあるだろうし、それが悪いわけじゃないけど、
そんなのが自動生成しなきゃ追いつかないほど大量に出てくるようなら一回設計を疑うべきだ 内部のデータメンバーからインターフェースを作るのではなく、インターフェースから内部実装を書くという当たり前の事を言ってるだけ。 これC++に限った話じゃないからね。これが理解出来ないようだったら自分のソフトウェアの設計能力はとてつもなく低いと自覚した方がいい >>393
なんでコンストラクタで初期化しないの？ 正直聞きたい事はそういうことじゃねーのよ
簡単に記述する方法が導入された、される予定があるか知りたいだけ
C++にC#みたいなproperty要望無いの？
const地獄解は消されたのかな？
ってこれ！
具出すなは分かる>>377の言う通り例が悪かった
APIや世界に発信するライブライ作ってる訳じゃないけど
>>382これが普通なの？俺別にpublicゆーてないけど
protectedでもこんなまわりくどい事すんの？
そもそも設計が…言う前に”そんな方法は無い！”って言ってくれたら…
つーか言えっつーのお願いマイメロディー >>401
プロパティの言語サポートはない。
が、がんばればそれっぽいものをライブラリで作ることはできる。 >>401
VC++になら最初からpropertyはあるし使えるが。 >>400
mutableなオブジェクトとして書きたい（ときもある）から プロパティ厨しつこい
C#使ってろよ
public変数使う言い訳探してんじゃねえよ >>402
手間掛けたくないのであればなーって
自作出来ても汎用性無いでしょ。汎用性関係あるプログラムじゃないけど
>>403VC独自拡張？知らんかった
それが標準になりそうなら憶える価値あるだろうけど… 間違いが広がっては困るから一応言っておくけど
>>403が言っているのはC++とは全く互換性のないC++/CLIのことな >>409
ウィンドーズホン御用達言語のC++CXにもあるわ； >>408
覚えるも糞もあるかよ。C#のがそのままだよ。
というか、C#≒.NET≒VC++だから、C#の機能はVC++/CLIでは大概ほぼ使えるはずだが。
https://msdn.microsoft.com/ja-jp/library/2f1ec0b1.aspx
なお死ねには同意。
C#が良ければC#を使えばいいだけ、C#ライクなC++が欲しいならVC++/CLIを使えばいいだけ。 >>406
一時期流行ってたprivate厨さんちーす >>412
ウィンドーズホンでネイティブC++を呼び出すための唯一の手段なので死んではいないﾊｽﾞ…
ttps://docs.microsoft.com/ja-jp/windows/uwp/winrt-components/creating-windows-runtime-components-in-cpp C++/CLIのことをVC++っていうのやめろよ
それにC++風ですらないし >>418
なるほど君は知らないんだな。VC++/CLIは混ぜられるんだよ。
君が言っているのはmanagedで、俺が言っているのはunmanaged。
まあ、どうせ君は使わないのだろうし、深く知る必要はないが。 ID:Rt5tAWZZ0 こいつ話噛み合わなさすぎてやべえぞ >>401
protectedこそちゃんと設計しないとメタメタになるだろうが
publicもprotectedもコードの利用者が自由に使えることには変わらんから公開インターフェースには変わらんぞ
お前もしかして「protectedだしメンバ全部下駄雪駄付けて継承先に丸出しするおー(^q^)」ってやってんの？
誰がどんな派生クラス作ってどんなふうにいじくって親クラスのふりして混入させてくるかわからないのに？
世界に発信しないからどうでもいいって？同僚や1年後の自分はたまったもんじゃねえな >>423
ただ単にforeground colorまたはbackground colorを変更するだけのために
いちいちオブジェクトを破棄してGDIリソースを開放して再びGDIリソースを確保してオブジェクトを新規作成し直してどうぞ
>>423にとって不幸なことに、この惑星では現実のアーキテクチャーも現実の外部世界も移ろいゆくもの（mutable）なんじゃ >>424
変更をstateとしてカプセル化しろという示唆だボケ
外からガチャガチャいじんな >>425
setForgroundColor(Color color)がカプセル化の結論ではありえないとする根拠は？
だいたいstateにせよ（＝mutableな要素をオブジェクト内に受け入れる）というのは>>400から話が逸れているわけだが 背景色が暗かったら前景色を明るくして見やすくするとかそういう制御はしないのか？
最初はしないつもりでも後から必要になったりリクエストが来たりしたらどうするんだ？
前景背景以外の第3の色のパーツが増えたらどうする？
アルファチャンネルが増えて半透明時はその裏側の色にも合わせて制御する必要が出てきたらどうする？
インターフェースってのは中のデータメンバーの下駄と雪駄とかそんなレベルで決めるもんじゃないんだよ
お前の言ってることは次元が低すぎるんだよ >>426
前景色をいつでも外部から独立に変えて良いオブジェクトならそれで構わないけど
それをforeColorメンバ変数があってそのsetterだから～みたいな程度の低い議論で決めたんだとしたら
後で大変な苦労をすることになるだろうな
今のお前はしなくてもお前の同僚やユーザーや1年後のお前がな >>427
>背景色が暗かったら前景色を明るくして見やすくするとかそういう制御はしないのか？
>最初はしないつもりでも後から必要になったりリクエストが来たりしたらどうするんだ？
>前景背景以外の第3の色のパーツが増えたらどうする？
>アルファチャンネルが増えて半透明時はその裏側の色にも合わせて制御する必要が出てきたらどうする？
setForgroundColor()を備えた低水準なクラスを実現した上で、
ユーザーの好みや用途に合わせた高水準なクラスをかぶせる階層設計にする
なんでもかんでも詰め込んだクラス設計はアレくね？>>427の好みなのかもしれんが どういう設計にするかって話じゃなくて
設計を決めるのに最初からデータメンバーと下駄雪駄ありきで考えるのをやめろって言ってるんだが
何一つ伝わってないようで残念だ >>430
>設計を決めるのに最初からデータメンバーと下駄雪駄ありきで考えるのをやめろって言ってるんだが
はげどうで、それにたいするスレ内に書かれた情報を前提とする答えが階層設計(>>429
何一つ伝わってないようで残念だ
ていうか
>>427程度では可能性を列挙しているだけで何を作るべきなのか指定したことにならない
仕様提示も無しにクラスの詳細を設計せよとかどんだけ～ 427は例えば前景背景色を変えるインターフェースを作るときに考慮しなきゃならなそうな事のほんの一例を挙げただけで
詳細設計しろなんて誰も言ってないんだが
最初に考慮すべきことはそもそも何を実現するつもりなのか、そのためにどういう操作を受け付けなきゃならないかであって、
privateのデータメンバーにbgColorがあるとかはどうでもいいし、必要ならそんなもの後から変えたっていいんだよ
それをデータメンバーありきで脳死で下駄雪駄付けてたら、そのメンバーの存在が公開外部仕様になって簡単に変えられなくなるんだよ
お前さんの例で言うと、不用意にsetFgColor()とsetBgColor()を公開したら、ずっとその2つを外部から独立に自由に変えられるようにしなきゃならなくなるの
本当にそうするべきなのかは、それこそオブジェクトの本来の目的次第で判断することでしょ？
「とにかくデータメンバーにbgColorとfgColorがあるんだからひつようなんです(^q^)」とか抜かしてたらバカで無能だと思うだろ？
お前さんは今そう見られてるんだよ buttonならselectedとかdeselectとか、たぶんそんなインターフェース。
color露出とか正気の沙汰ではない。 setColor()なんてグラフィックコンテキストのIFならありがちだけどな。 世の中のたくさんの組織で使われたりするような汎用ライブラリならね >>435
そういうライブラリならあり得るんだろ？
要件もわからんのに頑なに否定する ID:dE7pgqu30 がアホと言う結論でよろしいか？ 別にset～Colorなんて普通にありだろ
変なふうに頭固いやついるね 正直GUI系は納期に晒されやすいということもあってコードが汚くなりがちではある
それが劣っているとか優れてるとかではなく気の毒ではある >>438
設計の話してるのにいきなり実態を語るとか話をそらそうと必死
って言うことでいい？ >>432
>最初に考慮すべきことはそもそも何を実現するつもりなのか、そのためにどういう操作を受け付けなきゃならないかであって、
いやまさしくおっしゃるとおりで、
グラフィック部品のforeground colorとbackground colorは通常の表示ハードウェアの元では独立に変えられるﾌﾞﾂなのだから
ハードウェア寄りなwrapperレベルの実装だとそれぞれ独立に露出するのが正しいという結論に…
（独立に弄っても内部状態の不整合は起きない。これがgetter/setterを公開してもよい基準である
>お前さんの例で言うと、不用意にsetFgColor()とsetBgColor()を公開したら、ずっとその2つを外部から独立に自由に変えられるようにしなきゃならなくなるの
ならない
階層設計の意味がわかっていない？
漏れのやり方で起きることは、Foreground colorとbackground colorの2つを公開したクラスXのインスタンスをいつでも作れるというだけで、
上位水準で要求される操作のみを受け付けるべくXを利用して実現するクラスYではsetFgColor()とsetBgColor()を隠蔽することができる。
（単にYが使うXのインスタンスをprivateにすれば良い
ていうか話を進める前にID:dE7pgqu30には>>426の2行目にお答えいただいてからにしていただきたいですのう…
（>>400の話が途中から変わっていることには目をつぶって差し上げても良いので そもそもセッターゲッター書きまくらなきゃいけなくなるんだけどどうすればいいの？っていう話では >>441
俺が発端だとしたら書きまくるなんて言ってない
楽に書く方法導入されたかな～って聞いただけ
されてないのは分かったからもういけど >>443
残念ながら標準C++には無いねー。
俺の周りでも結構欲しがる人多いんだけど、何が良いのかいまいちわからないなー。
使うときに、変数を扱うような記法で、関数コールが出来るってだけだよね…
一文字減るだけで何が嬉しいのか… >>444
それについては
to.setBackgroundColor(from.getTextColor());
より、
to.backgroundColor = from.textColor;
の方が読みやすいから俺は否定はしない >>447
後でカラーが変更されたときに処理を追加したくなったときに面倒 セッターとゲッターをいちいち作るのかという単純極まる話に流れもへったくれもあるか 欲しけりゃ作れというCいやBから続くハングリー精神を忘れた主張はいくら喚いても無駄だ そういうおまえさんも、ここ僅か数レスの流れから目を背けているだろうが 不変条件がある→カプセル化(class)
不変条件がない→露出(struct)
では駄目なの？ >>306
try-with-resources/java.lang.AutoCloseable, java.io.Closeable/Java7～ ですか >>448
お前は
>>444 と>>447を100回読み直して出直してこい >そういうおまえさんも、ここ僅か数レスの流れから目を背けているだろうが
何回読んでもこのレス最強すぎて草生える >>462
いいから読み返してこい。自分がどんなトンチンカンなレス返したのか自覚するまで帰ってくるな。 >>463
すまんマジでわからん
お手数ですが改めて解説して頂けますか？ >>464
プロパティっつーのは
> to.backgroundColor = from.textColor;
みたいなコードでも.backgroundColorが変更された時の処理が書ける
って話だから プロパティが常に左辺値として扱えるってなら面白いけど、ただのシンタックスシュガーなんでしょ？ getsetなんちゃらより視覚的にわかりやすくて見た目がスッキリして汚物感がない あえて無視してるとかじゃなくてガチでわからんのか…… to.backgroundColor.blue = 100;
みたいに書いても意図通りに動かないからクソ to.backgroundColor.blue(100);
でいいだろ。 あるデータメンバをpublicにしたほうが合理的と判断したならすればいい
そこでいちいち教条主義にとらわれて見えない不安と戦うアフォは
物事の分別がわかるようになるまでROMってろ また流れの読めない奴が来たのかよ...
しかもドヤ顔 w
> 物事の分別がわかるようになるまでROMってろ
お前がな >>470
コンパイルエラーになるなら問題ないやろ >>465
それをC++でどうするかって話でしょ…
そんなことで上から煽ってたんか
付き合う必要なかったな >>476
お前がレスしたコメントが
「それをC++でどうするかって話」に読めたならマジで救いようがないな。
何がどうなってお前の中ではそうなったのか知らんがそれを外に出してくんな。 >>476
> それをC++でどうするかって話でしょ…
そんな話しはしとらんし
引っ込みつかなくなってるのかマジで話の流れが読めないのかわからんけどしばらくROMっとけ どうにかする以前に現状の標準規格ではどうにもならない >>478
お前こそスレタイ見直した方が良いぞ
引っ込みつかなくなってんのはどっちだか 要するに俺様の個人的好みがああだから言語もそれに合わせるべきと言っているだけ
周りと全会一致状態ならともかく批判的な意見に攻撃的な態度をとるだけ
どっから見ても単なる厨二病の自己チュー まあ言論の自由なんだけどね
やってて恥ずかしおまへんか？ setの方はプロキシオブジェクト噛ませば無理矢理できなくもない（やる価値もない）
getはどうやっても無理 マジで引っ込みつかなくなってるんだな...
>>443 そろそろプロパティが導入されたかなぁ？
>>444 されないねぇ、何が嬉しいのかよくわからんけど
>>447 メソッドが読み書きするより読みやすいでしょ
>>448 変更時に処理を追加できないだろうが
一同 ファッ！？、ヤベーよ、こいつ w プロパティはmsvcだと普通に使えるし、実装できない訳じゃないでしょ
つーかclangもマイクロソフト独自のプロパティに対応してるらしいとの噂 C++と関係ない話題をふっておいて噛み合ってないとか 出来るけどテンプレート引数やautoと相性悪いからあまりオススメしない C++でC#みたいなプロパティがサポートされる日は永遠に来ないからもう駄々こねるな 頭いっちゃってる奴らがサイドショーでもやってんのか？ C#以外のメジャーな言語に採用されたら有用性を認めてやる >>498
JavaScriptにはあるよ。
便利だが、基本的にアジャイルで頻繁に変更する環境向けであり、
C++みたいにゴリゴリやりたいところに向くかは少し疑問。
とはいえ、俺は導入に賛成だが。 >>498
Python Kotlin Swift >>500
Swiftにはないよ。
Computedプロパティと.Netのプロパティを同じだと思ってるなら一から勉強し直したほうがいい。 >>501
Storedプロパティに限定した話だったの？
俺そっち要らない派だからどうでもいいんだけど。 >>495
>>486読んでまだそんなこと言ってるなら相当ヤベーぞ w C#のプロパティはカプセル化の範疇を超えた使い方する奴が出てきてからクソだと思い始めた >>504
可能であれば例よろしく。URLでいい。 いや、どんな機能もクソな使い方をする奴は少なからずいるよ。
そんなもんだよ。 C言語にバックポートしてほしい機能はテンプレート一択。
何を言っているのかわからないと思うが。。。 >>505
プロパティ便利すぎとか言ってる同僚が書いた200行を超えるゲッターや初回だけ挙動が違うセッターなど
publicな変数も混ざってる環境なため普通の変数だと思ってあっちこっちで参照していたら気づかないうちに激重になっていた
どこがボトルネックになっているのか探すのに時間がかかった 仮にもc++使いならばそんなアホみたいな事例を気にする必要はなかろう >>508
サンクス。
> どこがボトルネックになっているのか探すのに時間がかかった
多分これがC++がプロパティを入れない理由だと俺は思っているが、
今のC++の勢いならどうせいつか入れるのだろうとも思っている。
> 200行を超えるゲッター
これはあまり行儀はよくないが、
メソッドとフィールドの文法的区別をなくすのがgetteｒでもあるから、
正しいといえば正しい。
> 初回だけ挙動が違うセッター
これはコンストラクタでやるべきものをセッターに持って来たことが悪い。
つまり、セッターの問題ではない。
セッター文法がこれを誘発するかと言えば、関係ないと思うから、プログラマその人の問題だと思う。
で、C++は一応「プログラマは正しくプログラミングできる」という前提だから、
どうせプロパティもいつか入れるんでしょ、と思っている。
その時には、「getterには重い処理を入れない」等の掟が出来るのだと思う。 ＝での演算子のオーバーロードがsetterに相当する
その辺りを自動でやってほしい
他、＋＝やらの演算子も余りにも面倒なのでどうにかしてほしい
pythonではそういう軟弱な特殊メソッドがあるが軟弱なのでC++の感触には合わない
さらに困難で不可解な記述方法を編み出すべきだ C#についてはサッパリだけど、調べたらかなり便利そうな機能だね、処理を差し挟めるというか？
C++で「stringのように振る舞う値」を作ろうとするとまずその型から定義しなきゃならないし
継承でやっつけることも可能だけど、問題点もある
さらに「intのように振る舞う値」となると継承不可だし、各種演算子をいちいち定義しないといけない
型を定義したいわけじゃなく、ある型のインターフェースを持ちつつアクセス時の処理を入れたいだけ、ってのは
確かにC++にも欲しくなるね
大した例えじゃないと思うけど、いずれ似たようなことが出来るようになったらいいなぁ プロパティって要するに、セッターは1引数の関数って場合が多いような。ゲッターは引数無しの関数。
カッコつけないだけで可読性がそこまで上がるもんかと思う。 window.SetSize(display.GetSize() * 0.5);
よりは
window.size = display.size * 0.5;
の方が読みやすいとは思う なぜそんな使い方をするのかよくわからん。
参照でパクってくるのはできないの？ あー、あーるばりゅーに＆つけるのってダメなんだっけ？ >>500
Kotlinはなんか注目度高いらしいな
スマートニュースか何かで見た https://ideone.com/x4WLWF
これを見てくれ、こいつをどう思う？
大分前にここにも上げたやつ。
こういうこともできなくないけど、標準で持ってほしいのはわからんでもない。
まぁ、カッコ一個減ったくらいでそんなに変わるかどうかはビミョーなところ。 >>525
プロパティっぽいことは実現できてると思うんだけど、
いかんせん型が違うから、例えばstringのメンバ関数呼び出しは出来ないし
暗黙のキャストが効かない場面でエラーになるんじゃないかな
やっぱ言語でサポートしてくれないと限度がある
と思ったけどT.P + T.Pとかが通って吹いた リファレンサなんか大昔からみんなやってることじゃん
誰かがいみじくも言っていたようにカッコ１つ減らすためだけに
そんな馬鹿げた努力（言語の複雑化も含む）がしたいのか 努力はしたくないけど言語の複雑化は構わんなあ
もっと複雑な機能いっぱいあるし、プロパティなんてかわいいもんでしょ >>528
何を偉そうに言ってるのかわからんが、俺も似たようなことやってきた上で言ってる
カッコ１つ減らすためだけに、ってのはちょっと矮小化しすぎ
>>523がどのような意図でリンク貼ったのかはわからんけど、
最後の一文でプロパティ便利だなっつってる
本質はアクセス時に処理を差し挟めることだと思うんだが
クラステンプレートで仲介するのは、新しい型を定義することになるから
ものすごい遠回りになるし、どうしてもC++の型システムと相性が悪い
まぁ必須とは言わないけどあれば便利だなとは思う >>529
お前さんの理想は、お前さんが書くべきコードそのものが
コンパイラにビルトインで入っていることなんだろうな
すごい儲かりそうだね [][][] [][][] [] [][][][] [][] [][][][][] [][] [][] [] [][][][][]
[] [][][][ [][][][][] [][ [][] [] [][][] [] [][][] []
[][][][] [] [] [][][][][][ [] [][][] [][] [][] [] >>527
えー？stringのメンバ呼べない？const参照してるだけだから呼べない道理はないはずだけど。
まぁ、マズそうなら一回static_castかませないとダメなんだっけ？うーむ。
まぁ、難しいことは考えずサンプルとして見てくれ。 >>528
>>444へ戻る
バカはなぜか同じ話題を延々ループさせたがるんだよな w >>533
Test<std::string> T;
size_t a = T.P.size();
とかやった場合の話ね（もちろん明示・暗黙に関わらずキャストされたらいける
継承使えばメンバ関数もいけるだろうけど・・・・そうすると多分、スライシング等の問題が・・・・
そんなこんなでプロパティか、それに近い機能入ってもいんじゃね？と思っただけｗ >>535
推論してくれないのか。そこまで便利にはできてないか。
ちょっとアイディア無いのでこれまでだな。
色々教えてくれてありがと。 つかな、使ってもないのに使用感を予想で語るの止めい。
そりゃ話がループする。
他言語には普通にあるんだし、使ってる奴のレポートを待てばいいんだよ。
利点は、フィールド←→メソッドを変更するときに、記述変更が少なくて済むことだ。
場合によっては戻すこともあるから、その時も助かる。
従って、アジャイルで既に動いているコードを変更しまくるときには便利だが、
ウォーターフォールで基本書いて終わりなら大してメリットはない。()が付くだけだ。
これとは別に、JavaScriptの場合はフィールドとメソッドを区別してないので、オーバーヘッド無しの遅延評価にも使える。
（プロパティ《関数ポインタ、ここで遅延評価する》をフィールド《遅延評価の結果》で直接上書きできる）
C++でこれをやる場合、オーバーヘッドが生じるし、そもそもメソッドコールでいい。
結果、C++には記述上のメリットしかなく、
これはIDEが進歩してリファクタリング出来るようになれば解消する話でもある。
だからそれを待つ、という作戦もありだろうし、
それ以前にIDE側のプリプロセッサでpropertyをサポートしてしまえ、ってのもありだと思う。
まあ、あれば便利程度で、あまり本質的ではない機能なのも事実だ。 お前がそう思うならそうなんだろう
お前の頭の中ではな
貴様の意見も机上の空論でしかない そんなにつぶし合いしたいかね。
収集しようとしてるのに。 >>537
C++を他言語にしたがるやつはどこにでも湧くダニみたいなもんだ
#define begin {
#define end } >>537
なぜ爺は終わった話をクドクド繰り返すのか c++でIF公開するときはメソッドに統一する、でおしまいの話なのにな。 文句だらだらなら、GCCを自分で仕様を追加しちゃえよ！ 自分で仕様を追加したGCCとか>>540のマクロとたいして変わらんくない？
いや公式GCCにアクセプトされるなら話は別だけど 追加する仕様によるな
禿がCに「追加した」機能はマクロじゃ済まない そんなにプロパティ欲しいとは思わんが、単純な値操作ならメンバの参照返すメソッド作れば事足りるんじゃね？
それよりconst地獄ってホントにあるの？
const使いまくってて体感したことないんだけと。 メンバの参照を返したらprivateにしている意味が完全に失われるぞ >>547
上流が const を渡してきたら、下流は逆らえない、ってことでは？ 自作クラスのメンバ関数にconst全く付けてないタコが聞きかじりで中途半端に付け始めて
「メソッド呼べない！ムキー！このconstってやつ使えねー」ってパターンが大半だと思ってる const地獄になるってことはそのコードが間違ってるって事だからな
全部直せ >>547
本気で言ってるなら、それは経験が足りない 副作用の少ないきれいな設計ならconstだらけになるはずだが No.1
1 2 3 4 5
2 3 4 5 6
No.2
1 2 3 4 5
2 2 2 2 2
3 3 3 3 3
No.3
3 4 5 6 7
：
：
No.n
というtxtファイルがあり。No.〇の次の行に整数が記入されている（何行あるかわからない）
整数の左からx1[ i ][ k ]、y1[ i ][ k ]、x2[ i ][ k ]、y2[ i ][ k ]、A[ i ][ k ]の配列にそれぞれ書き込み
もし次の行整数があればi＋１をしまたそれぞれの配列に整数を書き込む
もし次の行に整数がなければ（No.の行）k+1を次の行にいき整数をそれぞれの配列に書き込む。
これをNo.nまで繰り返す。
このプログラムをfopenを使ってプログラムどなたかつくってくれませんかー？ ヒント。
いずあるふぁっていう関数どっかにあるから、先頭にアルファベットがあったらスキップや。
それと宿題スレって落ちたの？ const指定って下流が対応してないのに上流からやり始めるのは愚だよね プロパティよりも、deleteするとコンパイルエラーになるポインタが欲しい。 >>561
std::shared_ptr<int> a{std::make_shared<int>()};
delete a; //C2440 スマポも「ポインタ」とは言うけどさぁ
deleteの文脈で言っているんだから、オブジェクトは想定外だわ。 所有権のないスマポ（？）ならstd::observer_ptrがもうすぐ入るから待っとけ ところでスマポのコンストラクタの書き方ってどっちがいいの？
class Foo
{
std::shared_ptr<Bar> bar;
Foo(): bar(new Bar(42, 100.5, "xxx")){}
Foo(): bar(std::make_shared<Bar>(42, 100.5, "xxx")){}
};
下の書き方されてるのよく見るけどこれって
「newがあるのにdeleteがない！１１１」って発狂するアホコードチェッカを黙らせる以外にメリットなんかあるの？ あーなるほど
new隠しだけのための砂糖だと思ってましたありがとう
ということはunique_ptrの場合はメリットなしでいいんですかね 俺もmake_uniqueはいらねーよなぁって思ってたけど使った方が例外安全なんだとよ point cloud libraryというライブラリを読んでいます。
kdtreeクラスはsearchクラスをパブリック継承しており、
kdtreeクラスの冒頭で、searchクラスのデータメンバやメンバ関数の一部をusingしています。
これはどういう意味があってやっているのか教えて頂けないでしょうか。 IO2D楽しみだなー。
ウニファイドコールシンタックス復活しないかなぁ。 質問です。
#include "classB.h"
class A{
private:
B* b;
public:
void set(B* b){this->b=b;}
B* get(){return b;}
};
クラスAのメンバーにクラスBのポインタとアクセサがあります。
しかし、set()を使わずに、get()を使ってメンバーにアクセスできてしまいます。
例：a->get()=b;
ポインタではなく、複製したインスタンスを返すことも考えたのですが
クラスBのサイズが非常に大きいため、
可能であれば複製はしたくありません。
どうかご助力をお願い致します。 B* b = nullptr;
B* get(){ assert(b != nullptr); return b;}
こうでもしとけばいいよ >>576
const B* get() { return b; }
あとこうでは
*(a->get()) = b; エスパーだがポインタみたいな動作させたいなら operatorｰ>() を定義すりゃいいけど上の説明だとなにがやりたいのか具体的にわからないね >>577-582
ありがとうございます！
なるほどconst、普段しっかり使っていないツケが来ましたorz
ただ、そのままだと代入できなかったので、勉強してきます。
ありがとうございましたm( _ _)m
>>580
すみません、ご指摘の通りです。ありがとうございます！ Bがなんだかわからないけどsetがものすごくまずいように見える [][] [] [][][][] [][] [] [][][][][
[ ][] [ gtkmmググっても英語含めて１７ページしかないんだわ(´・ω・`) オブジェクトの内部データへの変更を許すフリーパスを外に与えるようなsetterやgetterはNG、
しかしあまり杓子定規にそれを言い立てるとファイルハンドルとかもgetterで返して良いかどうかﾋﾞﾐｮｰに…
ファイルはオブジェクトの内部データではないお客様という解釈で乗り切る？ いいわけないだろ
教条主義にとらわれていると
そういうことがわからなくなる フレンドクラスに見せるようにする方が例外扱いが明記される分だけマシ >>295 >>292
accelerated c++ をぼちぼちやっています。
>>295 にもバグがあり、正しくは
https://ideone.com/sK4aJ2
一行を最後まで読んでしまったのなら、即座にループを抜けないといけない
なんだか最近 while() の使い道がなくなってきたように思えるのです…いつも for(::) { break; } ばかり書くようになってしまった… 停止性を担保するのは良いことだと思うが。
結局無限ループからのブレークしか使ってないなら頭整理してWHILEに置き換えるようにするなぁ。 >>593
停止性の確認を行った後、余計なことを一切してはいけない、という制約が加わると
途中判定の break 脱出以外に手がない、と考えています
あまり思い出したくないんですが、DOS/Windows の findfirst/findnext なんかも似た類かと >>593
ああ、こういうのはアリでしたね
コメントありがとうございます。
https://ideone.com/9r8rZe アプリケーション上で確保されたヒープ領域を追跡したいです。
operator new/delete と allocator を弄ればできると思い調査していたころ
「プログラミング言語C＋＋ 第４版」P997 に
「標準ライブラリのすべてのコンテナは、newによってメモリを確保して、deleteによって解放するデフォルトアロケータを（デフォルトで）もっている」
と書かれていました。つまり、new をグローバルでオーバーロードすれば追跡可能です。
実際、手元のコンパイラでは std::vector のメモリ確保と解放を追跡できました。
ここまでの内容は規格で保証されている事柄ですか？
実際のアプリケーションに組込むことを考えています。 メモリの確保形式はさすがに実装依存でしょ。
最近リーヌスがブチ切れたらしいけど。
メモリーオーダーコンシウムとかの話は今やってるところ。 >>596
>アプリケーション上で確保されたヒープ領域を追跡したいです。
つgperftools >>596
std::allocator<T> (The default allocator) についての [allocator.members] で規定されてる。
> Remarks: the storage is obtained by calling ::operator new, but it is unspecified when or
> how often this function is called.
標準コンテナにアロケータを指定しなければ std::allocator が使われるから、それでいける。
「実際のアプリケーション」に変なものが混ざってなければね。 アロケータ自作してスパイアロケータとか作ればそれっぽいことはできるね。
標準コンテナに限っては。 >>576
ポインタを返さずに、ハンドルクラスを定義してそのオブジェクトを返す。 >>596
グローバルnew/deleteのオーバーロード自体は、規格で許されてるので合法。
ただ、注意深くやらないと吹っ飛ぶ。
とある処理系の標準ライブラリで、ユーザー回避不可能な不具合に当たったこともあった。 596です
規格での確認と該当箇所のコーディングを確認しました
ありがとうございました！ sleep_untilで「何秒後」ではなく「何時に」という絶対時刻を指定する方法なんだけどさ
mktimeとfrom_time_tを使う方法しかないかね？ なんかダサくてやなんだけど IDE：Visual Studio Express 2015 for Windows Desktop
浮動小数点モデル設定：Fast Math
コンパイルモード：Release
wWinMain関数内で
wchar_t str[ 16 ];
DirectX::XMMatrixOrthographicLH( 1.0f, 1.0f, 0.0f, 1.0f );
for( int i = 0;; i++ )
{
float f = i;
if( f > 0.0f ) break;
swprintf_s( str, L"%f", f );
}
と書くと、swprintf_sの結果が、期待される0.0ではなく、-0.0になります。
swprintf_sの行と上のif文の行を入れ替えると、0.0になります。
XMMatrixOrthographicLHがなかったり、Debugモードだったり、
Fast MathではなくデフォルトのPreciseだったりすると、
行の入れ替え関係なく0.0。
-0.0になるときは、何が始ま･･･起こってるんです？ コンパイラ固有のことなんか聞かれても誰も分からないと思うぞ >>607
floatの符号部が0だったり1だったりしてるのかと
最適化でswprintfだけが残って、fの値は+0.0f以下のゼロということで-0.0にしてくれてるのかなあ >>608
やっぱそれですよね（汗）
>>609
やはりそうですか･･･。
詳しい方なら、何が起こっているかだいたい読めたりしないかなと期待しましたｗ
>>610
たしかに、符号ビットがコロコロしてそうな感じですよね。
ちなみにif文で比較する定数は1.0fとか2.0fでも結果は同じになりますので、
swprintf_sだけが残るためではないですね。 Gtkmmは4.０も出たのに、詳しい解説ページは２．４のママ・・・(´・ω・`)
でも俺はAPI見ながら頑張るぜ！ 今だとC++でGUIやるならQtがデファクトだと思うからそっちの方がいいんじゃない？
GTK使えと命令されてる立場ならすまん Qtとかでかいしライセンスは高いし謎の独自拡張を使わされるわでかなり使いにくいんだが
そのくせ特別使いやすいわけではない でもネットや本の情報は多そうじゃない？
まあ用途も聞かずに頭ごなしに勧めるもんではなかったなすまんかった io2dまだかー。
ウニファイドコールシンタックス復活せよ～。 基本的な動作について知りたい
msgrcvは、msgsndされた瞬間にキューがたまるから、キューが追加されたと同時に待機状態をやめて動き出す
これであってる？？
あと、msgsndする先やmsgrcvで確認する先はmsggetで動的に確保された番号を知らないといけない
こうであってるかな？ システムコールの話ならLinux板にでも行け
なんかのライブラリの話なら知ったこっちゃないわ これ実行すると0と2が表示されるので一応は問題ないですか？汚いとは思うけど。
int main(void)
{
vector<int> vec;
vec.push_back(0);
vec.push_back(1);
vec.push_back(2);
for(vector<int>::iterator ite = vec.begin(); ite != vec.end();){
if(*ite == 1){
vec.erase(ite++);
printf("num: %d\n", *ite);
}else{
printf("num: %d\n", *ite);
++ite;
}
}
return 0;
} >>624
>vec.erase(ite++);
ite = vec.erase(ite); にすべし
あと、次の行のprintfは削除で おっと、質問は問題あるかどうかだった。
結論から言うと、問題はある。
0～2までではなく0～3までvectorに入れてから実行すれば、
まともに動作していないのは分かるはず。 >>626
やっぱこうしないとダメですね。
ite = vec.erase(ite);
どうもでした。 一応はこれでもいけるってことですかね？削除した時は次の要素になるという理解でいいですか？
for(vector<int>::iterator ite = vec.begin(); ite != vec.end();){
if(*ite == 1){
vec.erase(ite);
}else{
++ite;
}
} これlistとvectorでも違いました。
listだと++しないと正常に動作せず
for(list<int>::iterator ite = lst.begin(); ite != lst.end();){
lst.erase(ite++);
}
vectorだと++すると上手く動作しない
for(vector<int>::iterator ite = vec.begin(); ite != vec.end();){
vec.erase(ite);
}
でもeraseの戻り値取得するのが一番いいですね。 std::vector::eraseのリファレンスに、こう書いてある。
https://cpprefjp.github.io/reference/vector/erase.html
削除された要素またはそれ以降の要素を指すイテレータや参照は無効になる。
これによると、vec.erase(ite); 実行後にはiteが無効になることになる。
あなたの環境だと、たまたまiteが削除した次の要素になったのかもしれないが、
それがすべての環境で成り立つ保証はない。 >>631
基本的にはvectorは無効になるということですかね。 >>631
そのinvalidationは既に取得してるiteratorに起こるやつでは? >>631
なんか変な説明だね
vector<int> vec{0, 1, 2};
auto ite = vec.begin();
++ite;
vec.erase(ite);
--ite;
cout << *ite; //これでvec[0]にアクセスできそうに聞こえる
内容的にはこういうことなのに
vec.m_head = realloc(vec.m_head, 2 * sizeof(int)); listだとこれで動くと思っていいのかな
for(list<int>::iterator ite = lst.begin(); ite != lst.end();){
lst.erase(ite++);
} >>634
eraseした時点で削除された要素のitrも無効だから--できないと思うけど、
別途確保しておいたitrは有効であるかのように読めるから、確かにおかしいね
>>635
どうやら合法。 そもそもこれ何してんの？
表示とともに要素を消したいならFILOなコンテナ使いなよ
std::stackみたいな >>636
listはOKそうですか。
>>637
いやとくに意味はないです。ただvectorとlistで動きが違ったので気になりました。 アホか
eraseの戻り値が何のためにあると思ってるんだ >>639
eraseの戻り値使うのが一番いいのは分かったんですが
単にvectorとlistで動作が違うのが気になっただけです。 vector だと要素の再配置が必要になるけど list はそうじゃないって話 https://gabekore.org/vscode-c-windows
↑のサイトを見ながらCの開発環境を作っているのですが④の当たりから分からなくなってしまいました‥‥
説明のユーザー設定というものがそもそも無かったです‥‥ただの設定を開いたらこの画面になったのですが、この右に書いたのは合ってるのでしょうか‥‥？
このあとの⑤からはほんとによく分からなくなってしまいました‥‥この程度が出来ないなら、プログラミングなんて出来ないですよね‥‥(..;)
自分が不甲斐ないです‥‥-_-
https://i.imgur.com/VH9Yt5X.jpg >>642
MacでもLinuxでも使えるVisual Studio Code Part2 [無断転載禁止]©2ch.net
http://mevius.5ch.net/test/read.cgi/tech/1494638671/ 削除する場合とそうでない場合の処理を分ければＯＫ
forでもwhileでもＯＫ リストでもＯＫ
std::vector<int> vec{ 0, 1, 2 };
auto it = vec.begin();
while (it != vec.end()) { if (*it == 1) it = vec.erase(it); else it++; }
for (auto n : vec) { printf("vec %d\n", n); }
std::list<int> list{ 0, 1, 2 };
auto it2 = list.begin();
while (it2 != list.end()) { if (*it2 == 1) it2 = list.erase(it2); else it2++; }
for (auto n : list) { printf("list %d\n", n); } >>640
根本的に勘違いしていると思うけどな。
× > eraseの戻り値使うのが一番いいのは分かったんですが
○ eraseの戻り値を使わなければならない（そうしないと意味がない）
× > 単にvectorとlistで動作が違うのが気になっただけです。
○ 戻り値を使えば同じソースコードになるように設計されている
何の為にイテレータを使うか分かっておらず、
イテレータ使えば効率が上がると勘違いしているJava鹿程度の知能なんだろ。
Linusが文句言っているのもこういう連中に対してなんだが。 javaとかc#はイテレータで列挙してる最中に要素を削除できない
例外になる C++ 使っててもLinusに馬鹿にされてるぞ
C原理主義者（OSつくってるひとたち）はC++を馬鹿にして
C++信者はCを馬鹿にする
滑稽だな >>634
規格書の文言そのままの説明だと思う。
vec.erase(ite)の段階でiteは無効になるのでそれ以降は未定義だからvec[0]にアクセスできる保証はないという意味になる。
vector::eraseで領域の再確保は発生しないので削除する要素以前のiteratorは無効にならない。
vectorのiteratorをポインタで実装していれば次の要素をさしてそうなものだけど、そうでない実装、例えば削除した分だけ自動的にずらして同じ内容を指し続けてくれたり、例外を投げて間違いを知らせてくれるとかがありうる？ eraseの戻り値がなぜ必要かが分からないなら、vectorとiteratorの実装コード見て理解したらいいよ。 というか特定の値を消したかったらremove_if使おうぜ c++についての質問です。
call by reference あるいは call by value にて引数の受け渡しを行う関数を利用して、乱数発生ルーチンを評価し、評価得点法による最適次数n(<5)を求める場合どのようなプログラミングになるのでしょうか？
教えてください。よろしくお願いします。
ここまではできたんですが、このあとどうすればいいでしょうか？
https://i.imgur.com/XmuQ0Mw.jpg >>651
「乱数の評価得点表」「最適次数」とはどういう概念ですか？
適切な資料を教えてください。 >>646
まあその実装の方が初心者向けには妥当だな。
C#はそこら辺の「割とどうでもいいが無駄に複雑になる」部分を回避していていいと思う。
ただまあ、この方向（堅牢性、容易さ）のベストは実行時例外ではなくコンパイルエラーであり、
C#もまだそこまでは行けてない、ということだね。
なおJavaScriptはその辺保証してない。「出来るだけ止めない」方針だからね。
> もしプロパティがある反復で修正された後に訪問されたなら、ループにより公開される値は後の時点での値となります。
> 訪問される前に削除されたプロパティは、それから後には訪問されません。
> オブジェクトに対する反復が起きている中でそのオブジェクトに追加されたプロパティは、訪問されるかもしれませんし反復から省略されるかもしれません。
> https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/for...in
>>647
Linusが馬鹿にしているのは、意味もなく抽象化して喜んでいる馬鹿C++erだろ。
正しく抽象化している分には馬鹿にして無いと思うが。
とはいえ、OS組むならC++よりもCなのは事実だよ。 >>648
>>631を理解できない馬鹿共は放置として、君の理解にも多分間違いがある。
> ありうる？
多分無い。
× vec.erase(ite)の段階でiteは無効になるのでそれ以降は未定義だから
○ vec.erase(ite)後にiteが指すのは「次の要素」であり、
元々指していた「削除された要素」ではないことを「無効」と表現している。
そしてそれ以前に「削除された要素」以降を指していた物も全部ずれるので、
「削除された要素またはそれ以降の要素を指すイテレータや参照は無効になる。」という表現になる。
つまり、この文字数であればきわめて妥当な表現であり、ゆとりが馬鹿すぎて理解できないだけ。
> vectorはシーケンスコンテナの一種で、各要素は線形に、順序を保ったまま格納される。
> https://cpprefjp.github.io/reference/vector.html
つまり、ド頭から密に詰められていることを規定されているので、
削除すれば当然次の要素が入るに決まっているし、
（これは君は正しく理解しているが）reallocはなされないし、
vec[0]についてもアクセス時点での先頭要素が取得できるに決まっている。←多分君はここを勘違いしている ｃ原理主義者はそぎ落とされたロジックにしか興味ない
c++は彼らにとっては冗長なんだろう
GNUのツールセットのコードをみてると納得いく
しばらく見てると脳のワーキングメモリが不足しておかしくなりそうだ
が、残念なことにifとフラグとマクロ使いまくりの糞コードにも見える >>656
オススメのツール（ソース)ある？見てみるから。
ＵＲＬあれば助かる。 そこら辺は古すぎるので現在の常識とは異なる場合があると思うけど std::vector::erase - cppreference.com
http://en.cppreference.com/w/cpp/container/vector/erase
>Invalidates iterators and references at or after the point of the erase, including the end() iterator.
翻訳には肝心のモンが抜けてるんじゃあねえのか？
複数形のsとか >>659
サンクス。見てみているが、まずGNUはこのコーディングルールがな…
ちなみにこれ、今時ハイライト（色づけ）されないのは何とかならないのかね。
http://git.savannah.gnu.org/cgit/grep.git/tree/src/grep.c >>660
そう思うなら、今の常識に照らして書き直してあげたら？
パフォーマンスあがるならマージしてもらえるぞ Linusはプログラマの頂点ではないしGNUは最も優れたプロジェクトではない
既に手本にならない部分は多い >>655
>元々指していた「削除された要素」ではないことを「無効」と表現している。
そうなの？
規格ではclearとかresizeとかでも無効になる(invalidate)と書いてあるしeraseがそれと何か違うようにも見えないし、無効なiteratorをdereferenceするのは未定義だとも書いてあるように見えるけど。
>つまり、ド頭から密に詰められていることを規定されているので、
>削除すれば当然次の要素が入るに決まっているし、
>（これは君は正しく理解しているが）reallocはなされないし、
>vec[0]についてもアクセス時点での先頭要素が取得できるに決まっている。←多分君はここを勘違いしている
ポインタならそうだろうけどvectorのiteratorでも規格上保証されてるの？
ttps://stackoverflow.com/questions/45758659/does-stdvectorerase-really-invalidate-the-iterator-at-the-point-of-erase >>661
> including the end() iterator.
いや、これが抜けてる方が大問題だろ。
まあ広い意味では「それ以降の要素を指すイテレータ」に含まれるとも言えなくもないが、
これについては明記されるべきだね。
しかしこれだとイテレート中に削除していいのか？と心配になるが、
直ぐ下のサンプルコードで「偶数番目の要素を削除」してるからいけるんだろうね。
てか初心者なら、この辺のサンプルコードから出発した方がいいよ。いろんな意味で。
ちゃんと公式な使い方してあるし。(当然戻り値をイテレータに代入している)
> // Erase all even numbers (C++11 and later)
> for (auto it = c.begin(); it != c.end(); ) {
> if (*it % 2 == 0) {
> it = c.erase(it);
> } else {
> ++it;
> }
> }
> http://en.cppreference.com/w/cpp/container/vector/erase >>663
何で興味もないものに時間をかけてやらなきゃならない
ちゃんと動いていれば十分 std::vector の場合はこう、std::list の場合はこう、とかいう知識はあまり意味がないのではないか？
erace() したら、erace() したところおよびその後を指していたイテレータ（＝ポインタ）は使えなくなる、くらいで一括するのが妥当だと考える。 細かい場合分けするのはプログラミング的に悪だと思ってる。
統合的に丸っと処理できると気持ちいい。
なのでちょっと粒度を上げてSTLの作法というものを考えた方がイイ。 >>665
つか、君は何に文句を言っているのだ？そこにそのまま書いてあるだろ。
> When describing iterator invalidation,
> the C++ standard takes the simplifying assumption that iterators refer to elements,
> and a valid iterator value always refers to same element.
> Invalidating references, pointers or iterators to an element all follow the same rules. (The exception is the end iterator).
>
> Clearly references or pointers to the erased element are invalidated by a call to erase,
> thus under the standard's simple rules so are all iterators.
> It could have described what new element must be moved in place abd substituted what iterators refer to,
> but the writers of the standard chise not to go there. They instead simply dictated the iterator was invalid.
eraseでvecが移動しないことは保証されてるだろ。
当然vec[0]は削除後の先頭要素を指す。
ただしそもそも削除後にイテレータを再代入してないコートについては知るかボケだろ。
それについてもそこにモロに書いてあるし。
そのページは俺の言い分を全く書いてあるような物なんだが、何が言いたいんだ？ そもそもeraseするならvectorなんか使うな。よっぽど小さいvectorじゃない限り
eraseは縮小操作だからリアロケーションは起きないけどその時何が起こるのか理解してるのか？
理解できないならお前はC++を使えないやつ >>659
こんなもんじゃね？みたいな感じなんだが。
決して理解したわけではなく、雰囲気だけしか見てないが。
C特有のstructの嵐でもなく、
今ならIDEが警告出してくるほどのif文等のネストもなく、
意味不明なマ黒魔術使いまくりでもない。
グローバルが嵐になっているが、これはCUIツールだから大して問題ないし。
色が付いてないのとコーディングルールがアレなので詳しく読む気にならないが、
整形ツール通せば結構読めるコードのような気がする。 >>671
>eraseでvecが移動しないことは保証されてるだろ。
>当然vec[0]は削除後の先頭要素を指す。
誰もそんなことは問題にもしてないんだが大丈夫？
偉そうなことを言ってる割には全然読めてないんだなあ >>675
>>634から読み直してこい。俺も言葉を省略したが文脈上まさか読み間違う人がいるとは思わなかったんだ。 >>634
ite = vec.begin()
++ite;
ite = vec.erase(ite);
--ite;
であれば ite == vec.begin(); は保障できるが、
vec.erase(ite)
とした場合の ite の値は、コンテナ vec のどこかを指している保障はないのでは？
したがって、--ite もどこを指しているか保障がないのでは？
典拠を示してほしい イテレータを削除したときあり得る処置。
一個目。
メモリの再確保相当のことをして再構築する。
二個目。
尻尾の要素をムーブして詰めて最後の要素を開ける。
このどっちかだと思う。
2個目だとイテレータのロストはしないかもしれないが、
1個目だとアドレスが変わっちゃうのでイテレータが保持しているアドレスは無効。
両方あり得るのでeraseの戻り値はちゃんと受け取ろう。 >>680
お前もちゃんと読めよ
> 戻り値
> 削除された要素の次の要素を指すイテレータを返す。
> そのような要素が存在しない場合は、end()を返す。
> さらに、削除された要素以降の要素の数と同じ回数のTのムーブ代入演算子が呼ばれる。
> https://cpprefjp.github.io/reference/vector/erase.html
つかC++にはGCねえんだよ
Java鹿死ね 規格にきっちりかっちり書いてある挙動について
あり得る処置（ｷﾘｯ
とか抜かして適当な憶測垂れ流す奴がいるんだな なんか話が混ざってる気がするけど、eraseに渡した引数のイテレータの話じゃないの？ >>681
>○ vec.erase(ite)後にiteが指すのは「次の要素」であり、
>元々指していた「削除された要素」ではないことを「無効」と表現している。
とか書いちゃう人が言っても説得力ないけどねw >>681
GCどっから出てきた。韓国人といい。話が飛躍しすぎ。 昔のvectorは同一メモリ上にデータが配置されていることは保障されていなかったから昔の環境でなにか作る場合は注意したほうがいい。
そういう処理系が存在するのかどうか疑問だけど。 >>679
俺の論旨は保証ねえだろなんだが
だからreallocを持ち出した
典拠というのがあるなら631で
俺はそれを変だと言っている >>687
え？？
昔ってどのくらいのことを言っている？
そもそも連続領域でなければリストと同じ特性になってしまい
配列であることのメリットが完全に失われるだろ
ポインタの配列になっていて実体はばらばらでもよいということならわかるが >>649
横だが。
ソース見ろとよく言っている奴が居るので偶には、ってやってるんだが、
どこにあるかわかりにくい上に何だかなあ、なコードなんだが。
とりあえずこれでいいのか？
https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a01116_source.html
そしてiterator.cがどこにあるか分からないという、、、
同様の奴もいるが、あまりオススメはされてない。
https://stackoverflow.com/questions/4304783/c-vector-source-code
> 00402 iterator
> 00403 erase(iterator __position)
> 00404 {
> 00405 typename _Base::iterator __res = _Base::erase(__position.base());
> 00406 return iterator(__res, this);
> 00407 }
> 上側URL
__position.base()ってのは<T>だから致し方なしかもしれんが、
確かにこれだとC使いにとってはC++は冗長すぎる。
> ｃ原理主義者はそぎ落とされたロジックにしか興味ない
> c++は彼らにとっては冗長なんだろう (>>656)
は当たってる。 >>689
C++は厳密な定義を始めたのはここ最近の話で昔はほぼ実装に丸投げしてた。
これは、きゃするのように仮想コンピュータを定義しないでやってきたツケだな。
ぼんやりとコンピュータっていうものの抽象化イメージだけで進んできた。
あと、C++はわからないけど、Cはとあるコンピュータに依存するものは規格に入れない決まりになってたと思う。 >>691
韓国人2号も死ね
つかお前は>>682が>>680（お前）向けであることをまず理解しろ
日本語が不自由なら死ね この手のキチガイが湧いてくるまでになったか
このスレももう終わりだな 流れ読んでないけどvec[0]が無効になるって発言したやつがいるから荒れてるの？ 真に受けてソース読んでるしw というか読めてないしwww
実装見ても理由なんて分かるわけないだろ
質問者の使ってる実装は動いてしまう実装なんだから >>694
誰もそんなこと言ってないけどそう言ったと勘違いした人はいたみたいね
荒れてる原因はみんなが少しずつテキトーなことを言ってるからじゃないか？ >>692
俺が死んだら責任とってくれるんだよね？ 遺書を書いて死んだら>>692は事情聴取くらいはされるかもね このスレ頭おかしいのとプログラミングスキルでイキリ散らしたいのしかいねえな 俺は叩き合いが面倒だから理由つけてしゃべってるのに、問答無用で死ねはひどいよなぁ。
完璧超人じゃないから間違いの一つや二つくらいするよ。
なぁ。完璧超人。鏡見てみたらいいと思うよ。自分ぶっ殺したくなると思うよ。 > プログラミングスキルでイキリ散らしたい
ニヤニヤ 文献に書いてあることが全てだと真信してマニュアル通りに事を進めていくってまぁ受験とかならソレで良いかもしれないけどね。
物事の成り立ちを追っていくと決してその通りではないことも世の中にあるわけできちんとそういう所は汲み取っていかないとただ
の鉄砲玉みたいな一番扱いが厄介な｢無能な働き者｣になってしまうよ。
特にこの業界では型にはまってばかりの柔軟性のない>>692みたいな思想の違うものは徹底的に粛清しようとするワンマン堅物野郎は淘汰されるべきだと思うけどね。 >>694
日本語も英語も読めない不遜鮮人2人(>>674,>>686)が火病してるだけ。
話に脈略が無く、突然火病るのはいつものこと。
だから嫌われる。当然韓国人は排除されるべき。邪魔だから。
話が噛み合ってないのなら噛み合わせる努力をすればいいだけ。
それ以前に知りもしない奴がデタラメに回答する必要もない。
そして状況を知りたければ全部読めばいいだけ。
日本語が読めない馬鹿ゆとり>>694も邪魔なだけ。
つまり、結論は、
韓国人マジで死ね
ゆとりも死ね
お前らが居なければどれだけ2chから雑音が減るか、少しは考えてみろ。 初心者ですがGC付きの言語しかやったことないのでメモリ管理について質問させてください
例えば下記のようなコードでは、hoge関数で確保したvector用のメモリはGCがないためプログラムが終了するまで解放されないということでしょうか？
少なくともpiyo関数が終了するまでは残ってないと使えないですよね？
vector<string> hoge(){
vector<string> v = {"hoge", "piyo"};
return v;
}
string piyo(){
vector<string> v2 = hoge();
string s = v2[0] + v2[1];
return s;
}
int main(){
cout << piyo();
} まずはスタックとヒープをググって調べてみるといいかも。 >>711
ヒープってオブジェクトをインスタンス化したときに割り当てられるメモリ領域って認識なんですが合ってますか？
Cは関数内で宣言したローカル変数に配列を代入しても関数外に引き継げないのでまだわかるのですが、C++の考え方が掴めず混乱してます…… >>706
ヘタレか？
お前の喧嘩を買ってやると言っているのだから、
馬鹿パヨク韓国人なりの論理を展開してみろよ。
状況としては、2chは地域の公園のようなもので、
誰でも自由に入って楽しむことは出来るが、
飼い犬のウンコをまき散らして帰るような奴は二度と来るな、と当然思われる。
それを俺は、はっきり言ってやってるだけだ。
お前らは馬鹿すぎて理解できないようだから、直接的に言うしかない。
韓国人死ね
で、それで俺を嫌うのはお前らの自由だが、当然それでは何も解決しない。
お前らが迷惑行為を続け、他の連中に嫌われ続けるのも変わらないからだ。
何でも他人のせいにして被害者ぶるのはマジでムカつかれるから止めた方がいい。
嫌われる原因はお前ら自身にある。特に匿名掲示板ではそうだ。 一秒一秒大切に。 Please don't waste your time. vector<string> ←これはコピー
vector<string>& ←これは参照
戻り型を参照にしたらプログラムがあぼーんするけどね >>715
ということは、>>710でいうとpiyoが受け取ったvectorとhogeが返してるvectorは中身が同じだけの別物ということですかね？
いわゆるメモリリークはあくまでfree忘れやdelete忘れさえしなければそんなに心配しなくてもいいということでしょうか >>716
うん別物
で、hoge内のvectorはRAIIの仕組みによって自動的に開放されているから安心して >>717
なるほど…やっとモヤモヤが晴れてきました
ありがとうございます
RAIIについても調べてみます vector<string> hoge(){
vector<string> v = {"hoge", "piyo"};
return v;
}
vector<string> v2 = hoge();
関数スコープを抜けたら、関数内のオブジェクトは、自動的に消滅する。
return した瞬間に、代入演算子で、コンテナ内のデータをすべてコピーするのかも。
2重にデータを作るから、無駄
一方、参照型の言語では、primitive 以外は、すべてオブジェクトで、参照で扱う。
コンテナの参照(アドレス)をコピーするだけだから、オブジェクトは1つだけ
f(ref inout){ ～ }
C/C++ だけ、関数の引数に、更新用の参照を渡して、
関数内部で、そのオブジェクト・コンテナを更新することを、明確にした方が良いかも >>719
C++11 以降の vector ならそういう場合は最悪でもムーブするんちゃう？
NRVO が効くかもしれんし、全コピーは無いと思うが。 断っておくけど俺はc++は素人なので誰か訂正よろ
>>711
横からだけど
それはこの場合の答えには向いてない気がする
>>717
>>719
そのvectorは関数を出ても破棄されないしコピーされない
そのまま使われる
RVO（RETURN VALUE OPTIMIZATION）という仕組みがあって無駄なオブジェクトの生成が抑制される
c++はこういう所を死ぬほど気にする言語 Rust には、オブジェクトの所有権という概念がある
代入で、所有権がmove する。
オブジェクトはコピーされず、1つだけで、所有権が移動するだけ
こういう概念が、言語ルールにあるから明確 >>721
RVO は C++17 で必須化されたけど、 >>719 の事例はいわゆる NRVO で、やってもやらなくてもよい最適化のはず。
しかしムーブはコピーよりも優先されるので処理系が NRVO を最適化しなかったとしてもムーブが発動する。
故にコピーはしない。 弱いものを踏みつけて偉い事を誇示しないと生きていけないなんてかわいそう。
それだけがやり方だと思ってるんだったら先はない。 >>724
強者が言えば説得力があるが
強くなる努力・精進を惜しむ怠け者の言い訳は見苦しいだけだ >>691
実装を限定はしていなかったというだけの話か？
だとしたら興醒めだな
確かに昔のC++は実装と提供の分離が論点なので
vectorの実装がリストでも文句をぬかすな、だったが
じゃあ何でvectorの他にlistがあるのかって話 昔は規格書に書いてある通り実装されてないことがよくあったって話だが、これ書けばよかったな。
だから大半のことは実装依存だった。
今頃になってりーぬすに怒られたからメモリの構成の話してるんだぜ。
仮想コンピュータの仕様でも決まってりゃ今頃3D扱っててもおかしくない。
今頃2Dをやっと扱えるようにしようとか言ってるんだから。まぁ、ないよりいいから期待はしてるが。 あほ
vectorの要素アクセス速度が添え字に比例してたら
リーナスでなくてもキレるわ
それで誰も使わなくなったライブラリがあとで改訂なんかされるかよ
# リーナス？ ここC++スレだが メモリーオーダという話を最近始めた。
http://en.cppreference.com/w/cpp/atomic/memory_order
これだったかな？
valarrayさんが救済される日は来るのか。
ここ10年位で委員会の人が突っ込み入れるようになったけど、それ以前は忖度されてて誰も何も言わなかった。
だから、MSのコンパイラはタコだったんだよ。 ああ、最近こんな話を聞いたと自慢に来ていたのか
気の毒だがその話とvectorの実装はまるで無関係だ
悪いが俺はもう付き合ってらんねえ unordered_set<valarray>でひどい目に遭ったのは俺だけじゃないはずだ >>724
僕は韓国人です、ブーメランおいしい、まで読んだ
>>727
>>729
お前は何のためにここに来ているんだ？
全く脈略のない昔語りなんて、老害以外の何者でもない。
しかも内容は間違いだらけだし。
お前みたいな認知バイアス馬鹿には
> 問答無用で死ねはひどいよなぁ (703=お前)
と取れるようだから、俺がわざわざ分かりやすく、
お前が死ななければならい理由707,713を書いてやったんだ。
ちゃんと読んで死ね
> 鏡見てみたらいいと思うよ。自分ぶっ殺したくなると思うよ。 (703=お前）
むしろお前が680を書いていてまだ生きているのが不思議なんだが。
さすがゴキブリといったところか。
韓国人死ね >>732 時間の無駄だ。life timeを無駄にするな。 >>733
あなたがどう思おうがあなたの自由だが、俺は短期的視野で動いているわけではない。 >>727
仮想マシンどころか現在存在するメジャーなインタプリタ言語の仕様にすら3Dはおろか2Dすら無いんだが。 >>735
仮想マシンどころかってjavaとかc#とかのことさしてるの？ >>732
しょうがないなぁ。
じゃぁ、今死んだことにしてやるからあとの責任は取ってね。
じゃーねー。 class A {
//...
};
class B : public A {
};
A *a = new B();
delete a; // だめ
B *b = new B();
delete b; // だめ
というようにA, Bのdeleteを禁止することはできますか。
ただしこの制約はAでつくりたいです。 バカな考えはやめとけ
充分な知識と経験があるやつがバカな考えと知りつつあえてやるなら勝手だが
具体的なやりかたも分からないレベルのやつが思いつきでやろうとしても
あちこちぐちゃぐちゃになって自滅するだけだ A&& a{B()};
B&& b{B()};
じゃだめなん？ やりたいことを実現するだけならA::~A()をprivateにすればいい
数多の副作用をどうするかは自分で考えろ ベクトルの内積を取りたいのですがC++で実装する場合最も高速な方法はなんでしょうか 逆にどういう条件ならdeleteしても良い条件なのか？
コレでは一向にdelete出来ないではないか 罷り間違ってもdeleteできないインスタンスとなると
核開発か深海探査か宇宙船くらいしか思いつかない 最近の時事と照らし合わせると人工心肺の回収があったな
電源を切れないデザインの電子機器があるのかもしれない 逆ですね
つまりヒープにしか置きたくないです。
Aから派生したクラスのメモリサイクルを全てGCで管理します。 だとしたらGCからはdeleteできないと困るんでない？ たとえばprivateデストラクタを呼べる状態なら
friendにすればいいかと考えています。
それができなければ単に新しいvirtual del()メンバー関数を新設するつもりです。
領域自体はfree()で解放するのでデストラクタがなくてもクラス自体は削除できます。 newは既にオーバーロードされていて
ヘッダ取り付けmallocするようになっています。
問題はnewしてAのコンストラクタが動きGCの管理化であるにもかかわらず、
deleteされたりそもそもスタック上に造られてしまうことです。 いまのところの案は
A のdeleteをオーバーライドして
deleteされても領域は解放されないようにすることです。
しかしこれでもスタック上に配置することはできますが。
連投失礼しました。 GCしか使わせたくないのなら、普通にGC言語使った方がいいと思うが。
オレオレＧＣ実装とか、全くの無駄だし。
なおVC++/CLIでよければGC専用クラスを明示的に作ることは出来る。 おそらくid変わってます
インタプリタ作っているんです
でインタプリタでgcをサポートするためにc++でgcを書いています
ですのでなんとかc++で解決したいわけです それならnew/deleteでGCしようとするのが悪手 インタプリタの空間からは直接deleteにはアクセスできないんだろ？
だったらstd::shared_ptr使いなよ。 >>766
循環参照をインタプリタで考えたくないんです 某書籍の問題をC++で解いています。
格子状の道路を、同じ辺を通らずに（同じ格子点ではないです）
直進と左折のみで、左下から右上まで行く道は何通りあるか求めよ。
それに対して以下のコードを書きましたが、うまくいきません。
https://ideone.com/0JMvWz
MigiDame::CanGo関数の中での挙動が、こちらが期待しているようにならないのです。
＞全部trueが返る。
＞また、releaseとdebugで挙動が違う。
どなたかご助言をお願い致します。 >>767
論理的に矛盾している。GCは動的に確保・解放するが、C++のスマートポインターは基本的に静的にする。
それをインタプリタ側でしたくないのであれば、外部GCエンジンをインタプリタに接続するインターフェースが必要。 http://www.nminoru.jp/~nminoru/programming/boehm-gc3.html
こちらを参考に。 後はクラス内部のoperator new/deleteを定義する。 >>763
> でインタプリタでgcをサポートするためにc++でgcを書いています
意味不明。
例えば、JavaやC#でインタプリタ書けば全く問題ないだろ。
一般的にはシステムとユーザで別ヒープ空間にしてサンドボックス化したいけど、
GC言語って一般的にGCヒープが壊れるようなアクセス方法を提供してないから、
別空間に分けなくてもそんなに酷いことにはならないぞ。
オレオレインタプリタ程度なら問題ないはず。 ヒープにしか置けないオブジェクトというのは、
More Effective C++ の項目27にあったな。
>>746で既に触れられている方法だけど。 インタプリタのメモリー管理はインタプリタ側かGCエンジン側でしないといけない。
インタプリタでは自動的にデストラクタは呼ばれないので、インタプリタ側が引き金を引かないといけない。 Boehm GCというGCエンジンをそのまま使えばいいからさ。 >>768
255行目は「return false;」じゃないの? ありがとうございます。
仰る通りでした。
お恥ずかしい。 >>774
継承元のコンストラクタを呼べないのでそれはできないです >>763
作ろうとしているインタプリタってc++の？
それなら、自分で入力のc++のソースを解析する際に問題のクラスがdeleteされたりスタック上に生成されたりするのは検知すれば良いのでは。 >>773
それは嫌です
既存の処理系がcで書かれている以上なんとかなるはずです
これは好みの問題かもしれませんが >>781
C で書かれてても完全に C の仕様の範囲内で書いてるとは限らんのだぞ。
アーキテクチャ依存の部分を適当に #ifdef で分岐して configure でなんとかしたりする (できる) のが C/C++ >>780
いいえ
c++の文法は自分の手におえません >>779
コンストラクターが呼べない？
GC管理の範囲の切り分けができてないんじゃないの？
何から何までGCで管理する必要は無いはず。
Boehm GCの使い方を勉強しい。 もう言ってることもちぐはぐだしレス古事記としか思えない
スルー推奨 インタプリタで扱う、GC管理するクラスの基底クラスObjectBaseを定義して、そこでBoehm GCを使ってoperator new/deleteを定義する。
インタプリタ側でObjectBaseの派生クラスを必要に応じてnew/deleteすればGC管理ができる。 まだ自分では難しいですね
一旦中断して勉強し直します
ありがとうございました >>781
そういう意味ではない。
>>787
まあ、根本的に分かってないというのは同意する。
今の君では無理だ。
君は「既存のインタプリタにGC機能を付け加えようとしている」、ここまではいいか？
インタプリタの場合、両端の柱は2つで、
A. evalラッパ
B. フルエミュ
で、結局の所これらの折衷案となる。どのポイントを目指すかは君が決めればいい。
ただし、君はここまですら到達できていない。
君はGCを自前で実装することにこだわっている。
これはGCをフルエミュすることを意味しているが、
この場合、delete等は常に自前パーサを逐一通すことになるので、その段階で弾けばいいだけだ。
君が言っているように「禁止する」必要は全くない。（ここが矛盾している。
GC管理変数をdeleteしようとしているかは、当然分かるし、分からないようではフルエミュできない)
だから俺たちはevalラッパ実装だという前提で話をしている。
こちらの場合は、システム側が持っている機能を使って相乗りになる。
混ざらないようにさえ出来ればとりあえずは動く。
コードを書く以前に、まず、仕様を固めないと駄目だ。君はここが出来ていない。
もっと上位の、エミュレーション戦略を固めないと話にならない。 ＞この場合、delete等は常に自前パーサを逐一通すことになるので、その段階で弾けばいいだけだ
というのはインタプリタからは直接deleteが見えないことをさしていると思いますが（合っていますか？
>君が言っているように「禁止する」必要は全くない。
の理由がわかりません。
インタプリタ上のオブジェクトもC＋＋上ではただのポインタであり
delete hogehoge //このhogehogeはGCの管理下
することは文法上は可能なはずです。
これを禁止することは処理系の保守性／安全性のために必要だと考えています（というのが初めの質問につながります
そしてevalラッパというのはやらないです。
今回はメモリ管理まで実装することでその"Java"や"C#"での管理の仕組みを実装レベルで学ぶことが目的の一つだからです。
動けばいいとうわけではありません。当然出荷するわけでもありませんので大丈夫です。
＞コードを書く以前に、まず、仕様を固めないと駄目だ。君はここが出来ていない。
＞もっと上位の、エミュレーション戦略を固めないと話にならない。
ええ全くその通りでした。楽観的すぎたか単に実力不足です。 >>789
君が想定しているのは明らかにフルエミュ寄りだから、それで話をすると、
A *a = new A(); でまず、
自前の変数管理用ハッシュ内に valuesHash["a"] = {type: A*, value: ptr}; することになるだろ。
そして delete a; が来ると、
if (valuesHash["a"].type.canDelete) delete valuesHash["a"].value;
で対応することになる。だから、
> することは文法上は可能なはずです。
> これを禁止することは処理系の保守性／安全性のために必要だと考えています
ということ自体が間違いなんだよ。
文法的に禁止とか、全く意味が無くて、
実行時に自然に弾けるし、弾けないようなフルエミュは実装不能だから。
君はインタプリタ自体がどう動いているのか理解できていない。
インタプリタの場合は、生きている変数を全て自分で把握してないと話にならないんだよ。
俺たちはこれは「常識」として、その先の ptr の配置先をどうするか、の話をしていた。
だから完全に空回りすることになる。
> 楽観的すぎたか単に実力不足です。
どっちもだ。
君は車を作ろうとしているが、車にエンジンとタイヤが必要なことすら理解できてない。
このレベルの馬鹿だ。自覚してくれ。 >>790
ありがとうございます
全く甘々でしたよ。。勉強してきます! まぁ机上の空論の段階で質問してる感じはするね
まず実装してみて詰まってから質問したほうが絶対早い これのやり方真似るだけじゃねえの
C++にこだわる理由とかあるのか
GitHub - python/cpython: The Python programming language
https://github.com/python/cpython
GitHub - ruby/ruby: The Ruby Programming Language
https://github.com/ruby/ruby 特定のプログラムの音(ゲームの音やブラウザの音など)のみを録音する方法ってありますか？
ステレオミキサー経由の録音はできたのですがそれだとPC全体の音が入ってしまいます >>795
ステレオミキサーで必要な音以外をミュートにしておくのではダメなの？ >>800
ステレオミキサーで拾う音を選択することができるのですか？
録音デバイスのプロパティからはできないですがどうやるのでしょうか めんどくさ。
DLL インジェクションでサウンド関連の API 呼出しを横取りして記憶するとかどうよ まずOBSとかAfterburnerなんかの録画アプリで出来るか確かめてみれや
それでできるなら出来るだろうし出来ないなら出来ないってこった >>797
録音を実現する機能はc++という言語の範疇ではないから、適切なスレで聞いてきた方がいいよ。
具体的に使うAPIなりライブラリなりが分かってやりたい処理があって、それをc++で記述する上で疑問が出てきたならこのスレでいいと思うけど。 >>801
Windows7だと画面右下のタスクバー上のスピーカーアイコンを右クリックして
音量ミキサーを起動すると、ミュートする音を選べるようになるよ
（各音源の一番下の青いスピーカーの部分をクリックすればいい） 「GCが欲しければObjectBaseを継承しなければならない
「さあObjectBaseを継承したまえ、GCが欲しいだろう
↑
という押しつけがましさ switch(c) {
case '{':
aho();
break;
//...
} https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
＞that Intel's CPUs speculatively execute code potentially without performing security checks.
...
＞That would allow ring-3-level user code to read ring-0-level kernel data.
投機的実行が仇になったようだね、リング3 コードがリング0 カーネルデータを読み込める、というのは最悪だねえ‥ intelのCPUに重大なバグ。修正により性能30%ダウンは確実。 もちろんcoffeeも対象 [589351131]
https://leia.5ch.net/test/read.cgi/poverty/1514960738/
＞インテルのCEOが関連性は不明だが2017年11月にCEOを最低維持できる25万株残して株式を売却している
ヤバいで なんか>>811にめちゃめちゃ書いてあるらしく実際そんなヤバないらしいよ やってみろよ
ム板でそういう発言恥ずかしくないのか システムコール呼び出すたびにアドレス空間を切り替えるパッチを当てるみたいだから、
io叩きまくるコンパイル作業はモロに影響うけるかもね。
arm64版にもパッチを当てるみたいだけど、禿大丈夫か… c++で例外は使ってますか？
また使う場合std::exceptionを継承しますか？ 最後の門番がstd::exceptionなんで継承して使う ] ][][[[ [][] [[["][ [ ]]]["04" >>821
標準コンテナとか含めて new 使ったら bad_alloc 受けることになるんだから
ほとんどの場合に使ってると言えそうなんだけど「継承しますか？」って話に繋がってるってことは
「使う」＝自分で例外クラスを定義して使うって話なのかな？ >>825
TeX で英数字からなる語の前後に空白を入れないと単語境界がうまく認識されないという問題があったので、この習慣は広く定着してる。
ただ、 pTeX などでは自動で境界を認識して適切な幅を取るようになっているのでむしろ空白文字を入れるとダメってのもある。
どっちでも上手いこと処理するのもあるし、そのへんごちゃごちゃしてややこしいんだわ。
ウェブブラウザでも物によって幅の取り方が違う。
まあ個人的には、バッドノウハウだという自覚はあるが、 html やプレーンテキストでは英単語の前後には空白を入れた方が見やすいと思う。 >>824
そうです。c++の本など見ても標準の例外を説明して終わりな事が多いし、しまいにはnoexceptなるキーワードまで出来てるし実際使ってるのかなと。 標準の例外はexception&で捕獲できる
ただそれだけのこと
独自定義の例外を標準の例外とは区別したいのなら
exceptionを継承しないという手も当然ある
教条主義にとらわれるやつ＝自分の頭で考えないやつは
こういう判断が極度に苦手だ 標準のライブラリがやってることっていうのはだいたいその言語における「普通」なので、
原則としてはそれに合わせるというのは良い方法だよ。
あえて原則に逆らいたいとき、逆らった方が便利なときというのももちろんあるけれど、
たいして強い動機もないのに独自の設計を選択するのは混乱の元。
つまり、例外クラスは std::exception を継承するのが好ましい。
その上でそのデザインが問題を起こす場合があるなら見直せばいい。 動的例外がまだ廃止されていない頃に設計されたものが
今のC++に対して本当に「普通」なのか考えたことがあるか？
（別にここで答えなくてよいが）
誤った前提のうえに立つ主張はただの戯れ言で
そうなっていないことは確認してからぬかせ std::exceptionを継承しないメリットって何かある？ std::exceptionを継承しないデメリットもようわからん…
std::exceptionは一体何をやっているのや？
std::exceptionを継承しなくとも
throw 1; --> catch (int)で捕捉
throw "Hello World!"; --> catch (const char*)で捕捉
とかやれるようになったのって比較的最近？ >>834
ないよ
std::exceptionを継承しても独自例外は区別できるし、>>830は反例になってない
std::exceptionを継承しないのは、普通にアンチパターンだからやめたほうがいい クラス以外を投げるのはdeprecatedになってたような…(自信なし)
とはいえstd::exceptionを継承しなければならない強い理由もあんまりないような気がする
JavaのThrowableやらPythonのExceptionやらはGCの都合だし
あくまでstd内の例外を組織化するための基本クラスでしょstd::exceptionって >>838
テスティングフレームワークとか、ロギングフレームワークとか魔改造したくないでしょ
おとなしくstd::exception継承しとけ、デメリットが多すぎる std::exceptionおよびその派生クラスを受け取る標準のロギングフレームワークってありましたっけ…
STLはなんか例外を投げる側しかサポートしていない印象
そもそも例外の捕捉のしくみは「知ってる例外のみ捕捉して処理する/知らない例外はさらに呼び出し元に送る」戦略なので、
受け取る側に既存のフレームワークが無いんなら、投げる側の例外が高度に統一されている必要は実はそんなには無いｷﾓｽ
せいぜいコピーしたときリークするようなクラスではあってほしくないという願いがあるぐらいで実は何だって良いのでは… >>840
「フレームワーク」にあたるかどうかはわかんないけど、
catch(std::exception& e) で e.what() を拾うっていうよくあるエラー処理のパターンがあるんだよ。
https://github.com/search?utf8=%E2%9C%93&;q=%22catch+std%3A%3Aexception%22+what&type=Code
だから、 std::exception 派生にしといてもらわないとまともなエラーメッセージが出なかったりして困る。 アホか
e.what() を誰に対して表示するんだよ
一般消費者にbad_allocとか言っても通じねえ
せいぜい「何たらファイルを保守員に渡せ」くらいだろ e.what()なんてどうでもいい
どのソースファイルの何行目でそいつがthrowされてきたかだ >>842
実際広く使われてるものを一人で一生懸命否定してもな・・・ そこら辺が例外としてカスタマーに出す情報として欠けている
巷で言うところのアスペクト機構というやつか 十進数計算をするためには一般的にはBCDをDPDを使用しますが
二進数のままで十進数の丸め処理をすることはできますか？ >>844
自分の頭で考えることを放棄しているやつとでは議論にならない >>847
そんなに独自路線を走りたいなら家で大人しく引きこもってろ >>841眺めてるけど
全ての例外オブジェクトはstd::exception派生でなければならないなんてポリシーで書かれてるコードそんなにないぞ
当たり前だけどだいたいcatch(...)も後続させてるし、std::exception派生じゃない独自クラスのcatchを前に続けてるコードも普通にある
というか「catch(std::exception& e) で e.what() を拾うっていうよくあるエラー処理のパターン」って何？
それは単にstd::exceptionを拾ってるだけで、std::exceptionを拾ったらそりゃwhat()使うに決まってんだろ当たり前の話 (´・∀・`)ﾍｪー
あ、ちなみに俺はC++経験ないけど暇つぶしに横から煽ってるだけだから気にしないでね^^ > std::exception 派生にしといてもらわないとまともなエラーメッセージが出なかったりして困る。
まともなエラーメッセージって
cout << runtime_error{"aho"}.what(); //aho
これのことか？ｗｗｗ
おまえさんもしかしてsystem_errorが理解できなくて使ってないとかか？ >>849
後続の catch(...) で拾っても何が起こったのがわかんなくて困ることがあるって話。 >>847
カスが考えるより、 C++ の (ライブラリ) 設計を真似た方がマシやで おまえが考えるより真似た方がマシなのは言われんでもわかってる バカの考え休むに似たりなる諺の発祥を追うような展開 ファイルコピーをしたいんだけど改善点あるかな？
引数にはコピー元とコピー先のファイルパスを受けとる予定
もっと簡単な記法があると助かる...
int copy(const char* old, const char* new)
{
FILE *fi, *fo;
int ch;
if(NULL==old||NULL==new){
return -1;
}
if ((fi = fopen(old, "r")) == NULL) {
return -1;
}
if ((fo = fopen(argv[2], "w")) == NULL) {
fclose(fi);
return -1;
}
while((ch = fgetc(fi)) != EOF){
fputc(ch, fo);
}
fclose(fi);
fclose(fo);
return 0;
} 関数仮引数を動的検査している
終了ステートが負論理
system_errorを使っていない
C++なのにfopen fpucとfgetcの繰り返しは短いファイルなら良いけど長いファイルだとCPU時間やたら食うだけのクソになるな >>860
改善点以前にコンパイルできるコードを持ってこいよ...
> if ((fo = fopen(argv[2], "w")) == NULL) {
あと文字単位のコピーは非効率だからせめて fread/fwrite にすべき
また使える環境ならstd::filesystem::copyとかを使った方がいい
http://en.cppreference.com/w/cpp/filesystem/copy >>863
おお...気付かんかった
C++なのにCで書いてあるからそもそもだめだったか...
fread/fwriteでまず考えてみます
FileCopyみたいなの欲しい freadを考えてみたけどファイルサイズ不明な場合一度に読み込むバッファサイズとかどうなるん？ 各マシンでの最適なバッファサイズを逐一計算して求めるのがC++ >>865
環境わからんからなんとも言えんが10KB程度とっときゃいいんじゃね？ >>861
＞関数仮引数を動的検査している
解説お願いします
＞終了ステートが負論理
ダメですか？
＞system_errorを使っていない
ダメですか？
＞C++なのにfopen
ダメですか？ >>860
fopen の引数は “rb” “wb” にしておくのが一般的
もし実用品として使うならなるべく大きな単位、
最低でも1Mバイト程度はまとめて読み書きすると良いよ。100Mでもいい。
細かい単位で読んで書いてを行うとHDDで大きなファイルを処理する場合とてつもなく遅くなる。
あとそういう書き方をしたいならそれは c++ ではなく
c のスレ(あるのか知らんが)で聞く内容だと思う >>868
不勉強を恥じろボケ
#include <filesystem>
#include <iostream>
auto copy(char const* src, char const* dst)
{
try
{
return std::filesystem::copy_file(src, dst);
}
catch(std::exception& err)
{
std::cerr << err.what();
}
return false;
} filesystem がまだ使えない環境もあるかもしれんので小ネタを披露しておくと、
rdbuf を使う方法があるんや。
ifstream in(src);
ostream out(dst);
out << in.rdbuf();
みたいな要領な。 エラー処理は適宜うまいことやってくれ。 パフォーマンス厨だが
もし実用するなら setvbuf の rdbuf 版みたいなのがあるからそれも呼ぶべきと一言 system("cp -f a.txt b.txt") でいいよね(´・ω・｀) パフォーマンス厨なら
リードとライトは別スレッドにするとか
読み書きサイズをクラスタサイズの倍数にするとか 物理的に別のデバイスならリード/ライトは別スレッドで回したほうが速いだろうが、同じデバイスだとシングルスレッドでも大差ないだろうな
あとはバッファサイズをできるだけ大きく取って、IOの発行数を抑えるのが王道かな >>860
fgetc、fputc？笑っちゃうくらいのダメダメ
俺の部下が万が一こんなコード書いてたらもう二度とそいつには仕事回さない プログラミングなんてどっかからコード引っ張って書けば一切手を汚すことなくできるのに何偉そうに言ってんだか...
英語読めないからって海外の文献を参考にせず自分で作ろうとする日本人の無駄な努力には呆れるよ
アメリカ「アホだから」
韓国「レベル低いな」
インド「アジアの恥さらし」って思われてそう 必死こいてコード書いてるやつ見ると情けない
世界65億人130カ国！
お前の書いてるコードがまさか地球上にないものだと思ってんの？
プログラマーの端くれが、そりゃトップで活躍するプログラマーなら常に新しいものを求めてるから生き残るけど...
それ未満は10年後にはAI、またはコード共有化が進んで消えた職業になっているだろうね
悲しいけど現実見てくれ 構ってちゃんが必死で連投してるな
著作権だの互換性だのと縁のない幸せ者だな >>876
バカにするなら模範コードぐらい書いてやれよ。 テストしてないけど
const size_t BUF_SZ=8192;
char buf[BUF_SZ];
while(!feof(fi)){
size_t n=fread(buf,sizeof char,BUF_SZ,fi);
if(n&&n!=fwrite(buf,sizeof char,n,fo)) {perror("ディスクエラー");return -1;}
}
>>873
WindowsならSHFileOperationかな？
windowsでsystem叩くのは文字数制限とか""のくくり方とか微妙に怪しくてなんか嫌なんよね お題：http://mevius.2ch.net/test/read.cgi/tech/1480579110/981
回答
http://mevius.2ch.net/test/read.cgi/tech/1480579110/997
http://mevius.2ch.net/test/read.cgi/tech/1434079972/30
https://ideone.com/LV4UdE
while (bytesDataNum > 0) {
int n;
fin.read((char *)&buffer, std::min(N, bytesDataNum));
if (fin.fail())
return 0;
n = fin.gcount();
fout.write((char *)&buffer, n);
if (fout.fail())
return 0;
bytesDataNum -= n;
}
return 1;
}
C++fstream/read/write を使うのだったらこんなところか
>>881 の n = fread() が BUF_SZ に満たなくてもエラーが立ってしまうのが思案のしどころだね、あらかじめ読み込みバイト数を知っておかなければならない‥ せやね。エラーチェックは難しいのう。
const size_t BUF_SZ=8192;
char buf[BUF_SZ];
while(!feof(fi)){
size_t n=fread(buf,sizeof char,BUF_SZ,fi);
if(!n) {perror("ディスク読み込みエラー");return -1;}
if(n!=fwrite(buf,sizeof char,n,fo)) {perror("ディスク書き込みエラー");return -1;}
} >>880
さてそんなこと言われてもプラットフォームすら指定されていないし
例えばWindowsなら↓一発で済む話だよな
https://msdn.microsoft.com/ja-jp/library/cc429185.aspx
ファイルコピーごときに自前でコードなんか書いてられるかよ ISO/IEC14882の現行規格を差し置いて何を今さら。。。
Windowsなら純正コンパイラが対応しているだろうが >>886
お前の境遇はよく分かったから勝手に笑っとけ >>885 >>884
C++17はともかく、boost::filesystemあたりが妥当だろうな。 とりあえずだ、fcloseの戻り値判定してないのも誰かつっこんでやれよ。。。
普段気にするところじゃないけど、わりと重要だよな？書き込み系のclose処理 バッファサイズ8kだと少し大きなファイルコピーすると結構遅くなるよ
書き込み側はOSのキャッシュが効くからそうはならんだろうけど
メモリはいっぱいあるんだし動的確保でもして一気に128Mくらい行くべし
>>889
簡単な処理はあまり外部依存しないコードにしたいよね 関数のconst参照引数って
コピーが重い方だと意味あるけど
intとかsize_tとかだと全く意味ないの? >>894
どっちが軽いか考えてみればいいじゃん
(1) 常に8バイトの数値(アドレス)を引数として渡すためにコピーして、呼び出された関数側でそのアドレスから値をコピーして、処理に使う
(2) 1～8バイトの数値を引数として渡すためにコピーして、呼び出された関数側でその値を処理に使う >>895
あーなるほど
どこかの入門サイトで参照は変数の名前の置き換えって見たから
コンパイル時に置き換わるもんだと思ってた
中身はアドレスなのね >>896
内実としては参照はデリファレンスが自動化されたポインタと思ってもさしつかえないと思う。
ABI レベルで見ればポインタと互換性が有りさえするアーキテクチャも有る。 (言語仕様で保証しているわけではない。) はちみつ餃子はc++とscheme以外に何が使えるの？ メンバがint2つくらいだとコピー渡しにするか参照渡しにするかちょっと悩む
int4つくらいまでならキャッシュの関係でコピーのほうが早いとか聞いたことあるけど本当なのかね FF15ではベクトルクラスはコピーにしたら劇的に早くなったと言っていた ゲーム機は尖ったアーキテクチャだったりするから……。
やってみないとわからん。 いやゲーム屋なら当たり前の話だよ
IntelのCPUだってSSEあるし、__m128は出来るだけ値渡しした方がいいはず
(もちろんインライン展開された場合は除く インライン展開されたら値渡しだろうが参照渡しだろうが（あんま）関係無いんじゃ…
※ 参照と不十分なインライン展開が重なったときmemory aliasingによる最適化の阻害の危険性がちょっと増すぐらい クラスの継承について質問です。
スーパークラス(Super)を継承したサブクラス(Sub)内にて
スーパークラスの関数func()をoverrideしています。
このサブクラスのfunc()の中で、
スーパークラスのfunc()をそのまま呼び出したいときは、
このようにする方法がありますよね。
void Sub::func(){
____Super::func();
____/*その他の処理*/
}
しかし、これはサブクラス側の自由であり、
スーパークラスのfuncを実行しないこともできます。
そこで、サブクラスのすべてのfunc()で
スーパークラスのfunc()が必ず処理されるように強制したいです。
これは可能でしょうか？
文字通りではなく、擬似的な手段で構いません。
よろしくお願いします。 ↑誤字修正致します。
☓そこで、サブクラスのすべてのfunc()で
○そこで、すべてのサブクラスのfunc()で
申し訳ございません。 スーパークラスとかサブクラスとか言ってるやつにイラッとするのが C++er メソッドチェーンというものを自作すればコントロール可能だが、ややこしい上にオーバーヘッドがある。 ごめん、間違った。
メソッドチェーンじゃなくてC#デリゲート。 >>914
親と子の方が一般的ですか…？
>>915
ありがとうございます！
メソッドチェーン自体は知っていましたが、
それを活用するという考えはありませんでした。
これをヒントに色々試してみます。 >>916
入れ違いになってしまった。
デリゲートでしたか！ >>917
スーパーというのはある集合を内包する、より大きな集合。 サブというのはある集合の一部の集合。
このとき、オブジェクト指向におけるクラスというのはインスタンスの集合とみなして、
サブクラスはスーパークラスの一部の集合とする考え方によってスーパー/サブと言ってる。
しかし、あるクラスをクラスが持つ機能 (メソッド) の集合と考えるとスーパー/サブが逆転する。
これはわかり難くて混乱の元。
という教訓に基づき基底クラス (base class) と派生クラス (derived class) という用語を C++ では採用した。
ちなみに C++ にはサブオブジェクトという用語はあって、
これはあるオブジェクトのデータメンバや基底のオブジェクトのこと。 >>921
> ちなみに C++ にはサブオブジェクトという用語はあって、
> これはあるオブジェクトのデータメンバや基底のオブジェクトのこと。
へー、スーパークラス＝基底クラスで、基底のオブジェクト＝サブオブジェクトなのか
これがスーパー/サブの逆転ってやつか
確かにわかりづらいね VC++だと派生クラスBarから基底クラスFooのメソッドfuncを
__super::func()
という風に
__super
キ──ワ──ドが使えるんじゃ！ privateなvirtual funcImpl()をカスタマイズポイントとして派生クラスに自由にオーバーライドさせて
基底クラスのpublicなfunc()で>>912で言うところのSuper::func()相当の処理してからfuncImpl()を呼ぶ
(func()自体はnon-virtual)
ってのがまあ常套手段だと思うけどそれだと困る？ >>922
多分ちげーんだろーな
C++のサブオブジェクトはサブリミナルとかのサブだろ
オブジェクトに潜んでる何かだろ
つい最近にもあった潜性／顕性の潜性の方だろ
無理に対義語作るならジス(this)・オブジェクトかメイン・オブジェクトじゃねえの サブセットのサブだろ
あるオブジェクトの一部分がサブオブジェクト
対義語はやっぱりスーパーだよ 部分オブジェクトの反対語をスーパーオブジェクトとは言わん subset, subhuman などに使われる前置詞 sub だろ
語義は「不完全な」だ 集合は要素の重複を認めないのでスーパーオブジェクトとかサブオブジェクトとか言う方が異端なのでは… 英語圏の方々の言語感覚は正直ﾜｶﾗﾝこともあるが
「具体的な」（Concrete）と「完全な」（Complete）は多分使い分けられれているのではないか >>926
クラスcがクラスaの単一継承なら
{ クラスcに属するオブジェクト } ⊂ { クラスaに属するオブジェクト } ・・・ (1)
なのでa::func()はcから見て__super::func()で正しいが、
クラスcがクラスaとbの間の子なら、(1)および
{ クラスcに属するオブジェクト } ⊂ { クラスbに属するオブジェクト } ・・・ (2)
はどっちも成立しないから__superキーワードが使えないのはある意味当然で整合的と言える、 ｽﾏﾝ訂正
クラスcがクラスaとbの間の子（で公開継承）なら、(1)と(2)が両方成立するんだったorz
（cのインスタンスはaのインスタンスとしてもbのインスタンスとしても扱える
ついでに補足で、>>933は「包含関係の意味でスーパーとかサブとか言うなら」異端という意味 std::set にて std::set<int> に特化して実装しようとしていますが、
ここで private メンバーである iterator positionToInsert(int n) を記述しようとして、はまっています
iterator posisionToInsert(int n) ：
n を挿入するべき内部テーブルの位置（イテレータ）を返す
n がすでに set にあったら nullptr を返す
としたかったんですが
・nullptr を iterator に代入できない
・そもそも コンテナ.end() が nullptr だ（無理にキャストしてみて分かった）…①
返り値を複数にするしかないのかな…
std:set.insert() も pair を返すみたいですし
①は規格で決まっているのでしょうか？処理系依存でしょうか？
https://teratail.com/questions/25576 変なメンバ関数つくるよりfind使っておけよトーシロー
理解できないなら余計な機能追加はするな
余計にわからなくしてプログラムを目茶苦茶にするな findじゃないなlower_boundで位置は把握できるだろこのハゲー std::setは挿入する位置を気にしないはずだが。設計思想が間違っている。 >>940
これから作るその find() の内部で iterator を返す private な関数を作ろうとしているのです
二分探索で find() するのも、二分探索で挿入先を探すのも、やることは一緒ですよね
lower_bound() も、これから記述するのです
>>942
std::set は挿入する要素が互いに比較できることを必要としています
挿入先の位置を求めるメンバ関数は、あくまでも private としています >>944
まずは iterator じゃないものを iterator で返すという発想をやめて
pair でも参照型引数でもいいから結果と成否は別に返すのが良いと思う >>938
> end()がnullptr
たんに指し示した先のデータが0だったってだけじゃないの？
双方向イテレータとして使用可能なのでnullptrだと上手くいかないと思うよ。 class Foo{
void function(){
hoge.exe();
}
private:
Hoge hoge;
}
と
class Foo{
void function(Hoge& hoge){
hoge.exe();
}
}
どっちが最適化かかりやすい? ほぼ変わらないと思うけど
スタックに積まない分前者かなと思う >>948
情報処理における罪の多くは最適化の名のもとでなされる。
そこはメンテナンス性の高い方を選ぶべき。
これから何千行のコードを書こうとしてるのか知らないけど、いちいちそんなことに頭使ってたら禿げるよ。 データメンバへのアクセスはthis経由なので
ポインタにオフセットを書けて逆参照という動作になる
左辺値参照の場合はオフセットなしで逆参照
いずれにせよ仮引数を受け取るという点は同じ動作だ
最適化という観点からはデータメンバはrestrictが付いているようなもので
若干有利ではないかな
ただしデータメンバの場合は全ての非静的メンバ関数が関与する可能性があり
仮引数の場合は当該関数のみというアクセス範囲の違いがあるので
最適化する以前の、基本的な設計で選ぶべきだろう できるけど、モーダルでもモードレスでもかなりうぜえぞ
template <typename T>
void display(T const& variable)
{
stringstream ss;
ss << variable;
MessageBox(NULL, ss.str().data(), typeid(variable).name(), MB_OK);
} 質問させてください。VS2008で仮想継承使っていたら以下の警告が出たんですが、警告が出ないようにするにはどうすればいいでしょうか？
warning C4250: 'CHoge' : 2 つ以上のメンバが同じ名前を持っています。'CTest1::CTest1::Draw' から継承します。
----------------------
class ITest1 {
public: virtual void Draw() = 0;
};
class CTest1 : virtual public ITest1 {
public: virtual void Draw() { printf("Draw\n"); }
};
class ITest2 : virtual public ITest1 {
public: virtual void Func() = 0;
};
class CHoge : public ITest2, public CTest1 {
public: virtual void Func() {}
}; VS2017ではデフォでは何も言ってこず
/W4にするとC4250が出る
warningだろ？ errorは直すしかないが
warningは内容を読んで理解したうえでどうするかを判断するものだ
必ず消そうと思うな、キリねえぞ
意味を理解しないからdisられたと思っちまうんだよ どうしても「消すこと」が絶対ならこれやっとけ
#pragma warning(disable : 4250) >>955
なんでITest2を仮想継承してないの？ この場合どっちを継承するとかの問題もないし
普通にこっちにも virtual つければいいだけだと思うが vc だと違うのか？
>>955
＞class CHoge : public ITest2, public CTest1 {
＞public: virtual void Func() {}
＞};
こう
class CHoge : virtual public ITest2, virtual public CTest1 {
public: virtual void Func() {}
}; おまえら質問者に教えて貰うあべこべになりそうだなｗ iTest2のDraw()が零でCTest1のDraw()が定義されているからそりゃ衝突する罠 >>956
VS2017では警告出ないのですか。試して頂いてありがとうございます。
自分なりに意味を考えたところ、
無視して大丈夫そうという結論に至りました。
#pragma で消す事にします。
>>958
１つにしたいのはITest1::Drawだけなので、
ITest1のみ仮想継承しました。
>>959
試してみましたが、同じ警告が出てしまいました。
>>961
衝突した結果、有効な方が選択されるので特に問題なさそうな気がしますね。 boost::spirit::qiで
boost::spirit::qi::rule<std::string::iterator, std::string()> hogehoge;
としてとき std::string() のようにかっこ付でテンプレート引数に与えていますが
このかっこ付で型名をあたえる方法はどのように活用できますか？（一般論として それは特別な方法ではなく普通の『引数をとらずstringを返す関数型』の指定でしかないから
一般論として普通はテンプレートで関数の型を明示的に指定したいときに活用する ありがとうございます。
引数のシグネチャに戻り値を加えたものってことでいいんですかね？
これで関数の入出力の型をテンプレートが知ることができるということですか 質問お願いします。
装置制御のプログラムを組みたいと思っているのですが、最適な言語はC++でいいのか迷っています。
内容としては、イベントを開く際に、一軒家の室内灯のオンオフ制御や、スイッチの信号受信、信号を送信しての仕掛の動作などです。
現在理解している言語はVBAのみです。
どの言語を学習するにしろ、ほぼ一からの学習になると思うので、最適な言語は何なのか調べているところです。
最適なものはC++なのか、それとも他にあるのか教えて頂けたら幸いです。 対象は全く問題ないがＣ言語を理解したあとでないといきなりC++を学うのは危険です。 >>970
>>973
ハードは管理用に新調する予定なので、装置制御に最適なものを合わせて教えて頂けますか？ どうやって照明をオンオフするの？
元からコンピュータによる照明制御の仕組みが備わってる建物か照明自体に無線通信機能のついてるやつじゃないと無理じゃね？ それか物理的にスイッチを押す装置を取り付けるか... >>975
元から付いている室内灯の制御は無理ということでしょうか？
それであればLEDを後付けして、擬似的な室内灯として制御したいです。 LEDを後付けとは？照明用のLED並みに明るいLEDを部屋に置くということ？
照明をリモコン化する商品はたくさんあるようだからそれらを使って既存の照明を無線化することもできるが。 >>978
ただオンオフするだけではなく、少し点滅させるような演出も入れたいんです。
無線の照明だとそのような演出は難しいですよね？ 無線のでもオンオフを繰り返せばいいはず。
後付けの照明って室内灯レベルには照らせなさそうだがそれでも問題ない？ >>980
>>981
ホラー映画でよくあるような、蛍光灯がジジジ・・・ジジ・・・ジとする点滅をさせたいです
明るさとしては通常の室内灯レベルは求めませんが、出来る限り明るくしたいです いい照明装置が見つかったとして、こういうSSRとArduinoを使ってAC電源を制御するとか。Arduinoなら言語は必然的にC言語。
http://akizukidenshi.com/catalog/g/gI-08620/ なるほど、明るさをじわーっと変化させたりじゃないのね
で、C++の話に戻るけど
C++を使うならC++コンパイラがあるCPUを選ぶ必要があるぞ
たとえばg++を使うならARMはいいけどPIC16F84なんかは無理 >>983-985
Arduinoという物を使うと良いんですね。
ありがとうございます。
Arduinoについて調べてみます。 Wifi対応のLED電球をスマホで制御ならやったことある
この程度でいいなら制御側はなんでもいい気がする std::vectorの[]演算子って引数の型がstd::size_tで定義されてるけどint型とかshort型で渡すと暗黙の型変換がかかって遅くなる? 大抵の石では拡大型変換は多くても1命令でできるので、遅くなるっちゃ遅くなるけどそこまで気にするほどでもない
更に言うと、コンパイラの最適化次第では型変換を省略して0命令になるかもしれない
よほど変態的な型変換を挟むとか、組み込み等で1命令でも削減したいとかでなければ、あまり深く考えても… その前にさ
size_tでないならじゃあ何型であるべきだと思っているんだ？
displacement(base + index)というアドレス計算のindexに当たるところだが >>994
質問者は「遅くなるか」と聞いているんだぜ
何と比べてだ？ というのが993の論旨 遅くなる可能性はある
遅くなったとしても微妙
というのが回答 [ ] のコストが問題で高速化したいなら
data() で生ポで扱うとか
アセンブラを使うとか
ループアンロールとか
複数ループの結合とか
まあ色々とテクニックはある
マルチスレッド化、GPU利用、アルゴリズム改善...
など、もっと大きなレベルの最適化も [ ] のコストが問題になるのは非常に小さなループだろうから
型くらいはコンパイラが勝手に最適化するのが普通 実際に問題になっている事が確かめられて無いのなら
最適化しないで普通にコードを書いた方が良い
見やすさ、変更のしやすさ、移植性、バグの出にくさ、...
などの理由で このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 56日 16時間 0分 49秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
