C++相談室 part134
レス数が950を超えています。1000を超えると書き込みができなくなります。
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part133
http://mevius.5ch.net/test/read.cgi/tech/1511509970/
このスレもよろしくね。
【初心者歓迎】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 visualstudio2017 Win32アプリケーションでSQLiteを使いたいのですが
Nugetにそれらしきものが合ったのでインストールしようとしたのですが以下のエラーでインストールできません。
https://www.nuget.org/packages/SQLite/
パッケージ 'SQLite 3.13.0' をインストールできませんでした。このパッケージを 'native,Version=v0.0' を対象とするプロジェクトにインストールしようとしていますが、
そのフレームワークと互換性があるアセンブリ参照またはコンテンツ ファイルがパッケージに含まれていません。
どうすればよいのでしょうか。 CoAppのタイムスタンプ調べてみて。
NuGetは捨てろ。 代わりに何を使うか。
VCPKG。
ただし、MSは三年後にVCPKGも捨てているだろう。
逆に我々がVSを捨てる時期に来ている。 MSの方針としてC++を捨ててC#に移行させるというのがあって、C++ユーザーはあの手この手で改宗を迫られる。
もはやVSでC++は苦行。
というか、WindowsでC++が苦行。 C++を捨ててC#に移行するか、Windowsを捨ててOSXかLinuxに移行するか。
二択。
WindowsではC#が正解。
なぜならMSがそれを望んでいるから。 C++のチームも頑張って更新してるけどな
IDEとコンパイラは十分なのに
・パッケージマネージャーがクソ
・再起動しないとPATHが更新されない
・VSのプロジェクトが用意されていないとビルドが面倒
と環境が整備されてなさすぎる C# + C++/CLI + C++
という選択肢 我々が間違っている公算も高い。
我々はC++を使いこなせる。
だから、C++なら簡単にできるのになぜそうしない？と思ってしまうが、これから学ぶならC#のほうが簡単だろう。
MSがC#を推すのは正しいのかもしれない。 C#はビジネス用だから
より早く大量にコードを生産することを目的としているからC++とは用途が違う Android でも iPhone でも Windows でも使える共通部分のコードは c++ で、
ってのを C# に変えたいのかもしれんが
別段 c++ で不自由ないしなあ…
てか c# って .Net のイメージ強すぎて単体で使える気がまるでしない 未だにproperty実装出来ていないC++標準仕様が異常なんだぜ
そりゃMSも堪忍の尾が切れるってもんだぜ ら、ライブラリで実装できるから・・・。
ちなみに、プロパティっぽい提案は過去出てるが、全くテーブルに乗らない。 C#はいい言語だよ
Linq便利だし
ただC++とは用途が違うってだけ 何度聞いてもプロパティが欲しいという思いが沸かないんだが ウィンドーズホンでネイティブC++とC++/CXの間を取り持つwrapperを書くのに使う
Wrapperを書くのに便利 プロパティが使えたらMFCのような糞環境でUpdateDataを使わなくてよくなる
プロパティに代入で表示が変わり
プロパティからそのまま値が取り出せる しかしVisual Studioは何だってUTF-8で保存されるのをそんなに嫌うんだろうか。
あの手この手でUTF-8で保存するのを妨害してくるけど。 VSで開発してLinuxに移植されるのを嫌がってるんだろうかね。
その割にはgdbと接続できるようにしてるし。 >>869
ナイナイ
今だって setFoo() だの getFoo() だの実装すりゃできるけど初学者以外はやらないだろ？
実装するにも使うにも効率が悪いからね。 >>869
それはsetter/getterではできないことなんだな？ a.Hoge+=100;
みたいな事をできて便利だなと思うことはあるけど無けりゃないでいいわレベル プロパティはメソッドともフィールドとも区別できるメタデータとしての活用が唯一の動機なんだが
結局のところ実行時の型システムまで整備しないととただの構文糖だしなあ >>873
A.Width+=20;
と
A.setWidth(A.getWidth()+20);
どっちがいい？; a.value++とかif(a.Width==100)とか
普通に書けるものをわざわざgetter setter書きたいんだな
変ってる UI とのバインディングを失笑されたら
シンタックスシュガーでこんなに楽にかける！と主張し始めたよw
そりゃ楽にかけて便利だよな。
そのためのものだもの。そこは同意する GUIだけじゃなくて他にも使えるというか
他がメイン >>878
そういう風にお手軽にメンバを書き換えるのは事故のもとなのでやめましょうってことでめんどくさくしたのに
戦争を知らない世代みたいな
現状でもa.value()++とかif(a.Width()==100)でできるしな
これまでのコードとの一貫性を破壊してなおかつ年代物のコンパイラに更に複雑なパースをさせて得られるものがちょっと括弧を省略するだけとは プロパティのメリットは最初publicで適当に実装しといても後からgetter/setter付きのprivateに変えれる所じゃない？ 変数がない状態でもテストに通るように作るべきだからpublicで変数を持たせる機会が一瞬もない C++builderってプロパティなかったっけ。
たいそう便利だったような気がするのだが、思い違いだろか。 そもそも最近のGUIビルダってC++ビルダーの影響受けまくってるような感じがする。 トップダウンで理想から考えるのが早い
どういう風に書ければ満足するんだ >>881
パースが面倒になるとは思えない
変数と同じ使い方なんだから変数のようにパースするだけだと思うが…
それにお前はコンパイラつくらないじゃん c++0x（）以降の理念で仕様策定だけしたらいいじゃん
基本機能を妨げないように仕様追加
使うかどうかは本人次第
誰も強制しない 拡張forもautoも馬鹿みたいに文句言ってたけど今でも使うなって言う人はいるのかな >>887
これらを採択する人の中にGCCやMSVCの人がいないわけないじゃん
関数として扱うのか、変数として扱うのか決めなきゃいけない
そしてどうやってポインタをとるのかなど色々な問題がある
そしてさっきも言ったけど括弧を少し減らせるだけでできることが増えるわけじゃないというのが最大の問題 得意げにご高説を垂れ流してる最中に申し訳ありませんが
a.value++;
と
a.value()++;
は別物
あえてみんなスルーしてくれてるのに ん？
参照した値を変えるとGUIの表示とか更新してくれんの？
getterとsetterあったとして実行してくれんの？
a.width()とa.widthが同じgetter的な動作してくれるのはわかるけど a.value()++; が参照返しとかどんだけヘボいんだよｗ
リファレンサのprvalueだろjk プロパティ不要とは言うけどそもそものプロパティの仕組みと効果はわかってないんだね
こんな人ばかり 何スレか前にもプロパティの議論あったんだけどね・・
少なくともgetter/setterを自動生成する、みたいなクソな機能ではないぞ >>884
Builderだけtry-finallyセクション使えたり次元が違う希ガス >>876
A.extendWidth(20);
それを書くことが便利で必要なクラスだったらそういう操作を作るべきだな >>884
あったよ
>>904も含めて当時はネイティブコードを吐くC#みたいな感じだった
もう少し頑張れるかと思ったけど、Visual Studioの便利さに負けたと思ってる カーンを首にしてアプリ側に振ったのが敗因だったな
膨大なdbaseの資産も全く使えなかったのはNetaWareと
同じだった >>908
違うよ。
デフォルトでのゲッタ/セッタを提供したりすることはあるけども、 >>903 で言及している通り「変数に見せかける」機能。 そもそも変数に見せかけると言うプロパティ自体の話とgetter/setterの自動生成の話は全く別物で>>902で比較してる意味がわからん
たぶん本人もちゃんと理解できてないんだろうな... >>909
なんだそういうことか。それも含めて単なる自動生成だと認識してたよ。 そうやってソフトが重くなって行くわけだな
数値の += なんて軽いと思って何度も呼んだら
実は描画や保存も何度も呼ばれてしまうとか プロパティってそれ単体で取り出せるの？
それなら使えるな 呼ばれる側 : そんな何度も呼ばれるとは思わなかった
呼ぶ側 : 重いとは思わなかった 少なくともAdd()なら何かしらの関数を呼んでいることはわかる プロパティでもなんらかの関数が含んでいることはわかるが それがただの変数なのかプロパティなのかは調べるまでわからない 変数でも演算子がオーバーロードされてる場合もあるからな
結局調べないとダメ っていうか>>883いわく、publicな変数は有り得ないらしいし、そういう運用してるなら考えるまでもなくプロパティじゃん >>910
お前のレスの意味がわからん
実際C#もソースコード公開されてるソフトの改造程度にしか触ったことないんでちゃんと理解してないが
getter/setterの自動生成するだけのクソ機能と誤解してる人がこのスレでも前スレでも見られたから
>>902を書いただけなんだが
というか書き込む前の１〜２レスすら読めんのかお前は C++erが通常prvalueで返しているリファレンサを、データメンバにするってことなら
テンポラリを作らなくなる分、速度的なメリットはありそうだな
# でも、俺はイヤだな
# データメンバがドカドカ増えるのがなんか気持ち悪い
# 慣れの問題っちゃそうかも知れんが >>923
だからそんな誤解してるのはお前と同レベルのバカだけだろ w
言語仕様の話とIDEの機能の区別もつかないアホなんて放置でいい >>927
いや、なんか根本的に誤解されてる気がするが
C#とかだと、多分プロパティ作ると自動である程度書いてくれるんだろうけど
その話じゃなくて「C++におけるpublicなGetXX(), SetXX()が暗黙的に作られる（だけ）」、みたいな誤解
（C#やBuilder知らずに議論をぱっと見するとそういう誤解しがち、俺も以前はしてたが）
があるんだよな
説明不足だったかもしれんけどIDEの支援機能の話ではない
というか前スレのリンクにあったブログの
http://ufcpp.net/study/csharp/oo_property.html?key=property#property
これが個人的にはわかりやすかった Javaのイメージなのかな？
あれはJavaBeansとかいうゴミ規約のせいで本当にGetXX()とSetXX()を作るだけのゴミ機能がIDEに標準装備だったりする まあプロパティある言語触ったことないやつは勉強不足だから無視していいって言うのは一理ある >>930
現状のメンバへの代入や値取得が
暗黙的に作られるgetter/setter
プロパティが採用されてもこの辺はなんら変わらないかと お前らの書き込み見ると、プロパティがものすごい大発明なんじゃないかと錯覚するけど
変数のようにかける件を含めても糖衣構文以上のものじゃないだろ。
+=したけりゃそういうプロキシ書けばいい。 これ以上言語機能を増やさなくて良い
コンパイラが規格に追い付いてなくて互換性が崩れる クソ機能というわけではないが、ものすごく便利というわけでもない
あればあったで使うけど、ないならないで困らないし、言語設計として採用するしないの判断はどっちもあり
C++は採用しない判断をした
その程度の話 実体が関数なら漢らしく見た目も関数にしろよwww
見た目が変数なのに処理が走るとか、見た目が割り算なのに文字列連結するとか変態野郎は死にくされやwwwww その辺はC++のコンストラクタ・デストラクタに嫌悪感を示すCユーザーが昔よく言ってた台詞と似てるｗ
「裏で何が起きてるかわかりづらいから嫌だ」、とかね
別に本気でプロパティ推してるわけじゃないが、いざプロキシクラスで代用しようとするとめんどい
ETなんかを仲介するとテンプレートの実体化の数でコンパイラへの負担がデカいし、
メンバ関数の呼び出しをサポートしようとすると継承が必要になるし・・・それなりに問題点はある >>934
大発明じゃなくて、もはや常識。C++にはないって聞いて最初驚いたもん
いやまあたしかになくてもいいんだけど、演算子オーバロードはあるのにプロパティはないって変な言語だわ >>941
>>941はiostreamを擁護する気か ダイヤモンド継承使われてるんだっけ
あれ使ったことないな
いらない機能だと思うなら使わないってだけだしプロパティはあった方がらくだと思うけどね
独自拡張でつけてるのもあるし >>942
凄くないよ
>>943
すまん。適当書いたけどiostremは擁護出来ねえわ iostreamの<<チェーンが実は最近まで規格上未定義動作だった話は正直呆れた 採択されてもプロパティのアドレスをどうやって取るのかっていうことで標準化委員会で揉めて10年は停滞する >>947
サブオブジェクトがユニークアドレスを取れなくてもいいことを示す [[no_unique_address]] 属性が C++20 のドラフトに入った。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0840r1.html
オブジェクトがユニークなアドレスを持つ原則を捨てたわけ。
これを踏襲するなら、プロパティのアドレスは取れないってことにして解決するのが自然で、揉める余地はそんなにないと思う。
実際にアドレスは存在しないわけだし、存在しないものを返しようがないじゃん。 >>948
最初のプロパティの提案がいつかはしらないけど
実際にこれが決まったとして最短で2020年
そこから更に何年かかるのか 抽象クラス"Super"から派生した子クラス、"A", "B", "C"があったとします。
Super* obj1 = new A();
Super* obj2 = new B();
Super* obj3 = new C();
訳あって動的に作成したインスタンスobj1〜3を一度deleteしたのち
再び同じ子クラスでインスタンスを作成しようと思います。
obj2がクラスBのインスタンスであることが一目で分からない場合に
obj2がクラスBのインスタンスであることを突き止め、一度deleteし、
再度クラスBでインスタンスを作成する方法はあるでしょうか？
ちなみに必死に考えて考えついた方法ですが
クラスA, B, Cにそれぞれ「私はAクラスです」「私はBクラスです」みたいな
文字列を出力する共通メソッドをpublicで作成し、そのメソッドを実行して
帰ってきた文字列からそれがどのクラスのインスタンスか判別が付くのではないかなと思いました。
決してスマートな方法とは言えませんが・・・
もっとスマートな方法はありますか？ レス数が950を超えています。1000を超えると書き込みができなくなります。
