C++の将来

716 ：デフォルトの名無しさん：04/08/01 08:39

C++はでかいけど、もっと肥大化して欲しいと思う。

・クラスの実装を簡単に隠せるように前方宣言を強化する
・サブクラスにvirtual継承を義務づける機能
(デフォルト実装を提供できるinterfaceのつもりで)
・virtualでない関数のオーバーライドを防止できるように
・Dのtypedefに相当するアレ
・typeofとか本物のtype_traitsとかtypedefテンプレートとか
・int (void::*)(const char *)みたいなもの
(これが無いせいでsignal/slotの実装が酷いことに・・・)
・finally

言語機能だけでもこのくらい欲しい。標準ライブラリも、
イベントディスパッチャ、スレッド、ネットワークあたりは、
オプションでなら入れてもいいと思う。

717 ：デフォルトの名無しさん：04/08/01 11:04

propertyも欲しいね
あとdelegateも

718 ：デフォルトの名無しさん：04/08/01 11:50

>>716
>virtualでない関数のオーバーライドを防止できるように
MPのことを考えるとそういう方向の制約はどうだろう？
危険なのはわかるが。

>int (void::*)(const char *)みたいなもの
boost::signalじゃダメって事？

>type_traitsとか
boost::type_traitsをって意味なら同意。
boost::concept checkあたりも言語で取り込んで欲しい

>>717
propertyは欲しいけどdelegateはびみょー

ちなみに俺が欲しいのは
・翻訳単位初期化順番の指定
・template周りの強化
・template関数の部分的特殊化可能に
・関数ローカルなクラスもtemplate引数にしたい
また、組込みのことを考えると、inline展開を強制する等
コード展開のされかたを縛れたら便利かなーと

719 ：デフォルトの名無しさん：04/08/01 12:09

取り敢えずboostをstd::に入れろやーぼけぇー

720 ：デフォルトの名無しさん：04/08/01 12:11

全部入れるのは勘弁

721 ：デフォルトの名無しさん：04/08/01 12:44

機能追加する前に iostream の作り直しを
とりあえず単純な入出力だけを担当する部分と
書式付き書き出しを担当する部分に分割してﾎｽｨ

722 ：デフォルトの名無しさん：04/08/01 12:49

何故?

723 ：デフォルトの名無しさん：04/08/01 14:29

>>717
propertyは無理じゃね？ポインタ、参照の考え方が
根本的に変わってきちゃうから。
>>718
> >virtualでない関数のオーバーライドを防止できるように
> MPのことを考えるとそういう方向の制約はどうだろう？
> 危険なのはわかるが。
あ、防止したいときにキーワード1つ書く程度の手間で
防止できるように、というつもりだった。
あと継承不可とか欲しいよね。
> boost::signalじゃダメって事？
あれを実現するために恐るべき手間がかかるのが嫌。
boostに依存させるまでもないから必要なだけ自分で実装
しちゃうって場合に困る。
>>721
streambufでは駄目？

724 ：デフォルトの名無しさん：04/08/01 14:50

>>723
>propertyは無理じゃね？ポインタ、参照の考え方が
>根本的に変わってきちゃうから。
propertyはメンバ変数のラッパーではなく、setter/getterのラッパー・構文糖に過ぎないから
別に今すぐ導入したって問題は発生しないよ。
単にpropertyの参照・アドレスの取得を禁じればいいだけ。
RTTIが絡むと別の意味合いも帯びてくるけど。

725 ：デフォルトの名無しさん：04/08/01 15:23

>>723
> streambufでは駄目？
微妙。必要なときはstreambuf弄るけど。

726 ：デフォルトの名無しさん：04/08/03 13:54

そういうのは、iostreamじたいを弄るんじゃなくて、アダプタやデコレーションで用意すればいいんでね？
てか必要ならさほどの苦労も無く作れそうだな。

727 ：デフォルトの名無しさん：04/08/04 11:00

istream とか ostream をインターフェイスとして使いたい場合は？

728 ：デフォルトの名無しさん：04/08/04 12:29

>>726
Java / C# 風の StreamReader とか StreamWriter の類？

729 ：デフォルトの名無しさん：04/08/05 01:11

>>728
Java/C#風っつー意味ではInputStream/OutputStreamとかStreamなんでは？
iostreamはそれ自体がゴテゴテし過ぎてるからデコレーションには向かんと思う。

730 ：デフォルトの名無しさん：04/08/30 02:42

関数テンプレートの部分特殊化ってなんで導入してないんですか？
この理由についての議論どこかに落ちてないですか？

731 ：デフォルトの名無しさん：04/08/30 07:28

>>730
ほれ。
ttp://www.gotw.ca/publications/mill17.htm
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1295.asc

732 ：730：04/08/30 12:07

>731
ありがとうございます．GotW漁ってなかったのは不覚でした．

733 ：731：04/08/31 00:30

>>732
ふつうにgoogle使っただけだぞ。
ttp://www.google.co.jp/search?q=%2Bwhy+%22function+template%22+%22partial+specialization%22

734 ：730：04/08/31 00:44

>733
自分もググっていたのですが徹夜続きで少々ボケ気味だったようです．
日本語サイトの検索結果をweb全体の結果だと早とちりしてました・・・orz
ともかくありがとうございました．

735 ：デフォルトの名無しさん：04/10/01 16:03:49

boost使って書いても大丈夫？
将来無くなることとかないの？

736 ：デフォルトの名無しさん：04/10/01 16:16:35

>>735
無くなる事はあっても
使用が禁止されることはないだろう。

737 ：デフォルトの名無しさん：04/10/01 22:47:02

そこでC++/CLIですよ。

738 ：デフォルトの名無しさん：04/10/02 01:20:50

CLI 使うなら素直に C# に移行したほうが幸せになれそうな予感

739 ：デフォルトの名無しさん：04/10/08 15:20:17

C++とC#で速度比べたら、100倍近く速度が違ったあたり、まだまだC++はいけるなと思った…。

forでくるくる回してa++;しまくるプログラムでね。

740 ：デフォルトの名無しさん：04/10/08 16:28:09

forでくるくる回してa++しまくるプログラムに実用性は無い

741 ：デフォルトの名無しさん：04/10/08 18:09:26

ただの足し算で100倍も速度に違いがでる時点で、C#は糞

742 ：デフォルトの名無しさん：04/10/10 13:49:36

>>741
一方でたかが財務計算のコーディングとデバッグに手間をかける言語も
同じくクソなんだから、一概にどっちが悪いとも言えん。

VC++でクラスライブラリを作って、そのテストクライアントの開発言語という
前提ならやっぱりC#がラク。
いまのWin32基本のシステムで速さを求めるならそういう作り方しかないっしょ。
C#が真価を発揮するのは、Win32が単なるお荷物に成り下がる未来のお話。

743 ：デフォルトの名無しさん：04/10/10 14:42:39

>>742
　　　　　　　　　　　　/ 　ヽ　　　　 / 　ヽ
　　＿＿＿＿＿＿ / 　　ヽ＿＿/　　　ヽ
　　|　＿＿＿＿　／　U　　　　　　::::::U:::::＼
　　| |　　　　　　 /／　　　　　　　＼　　:::::::::::::::|
　　| |　　　　　　 |　 ●　　　　　● 　　 ::::::U::::|　　　何この文章…
　　| |　　　　　 .|　　　　　　　　　　　U　:::::::::::::| 　　
　　| |　　　　　　 |　　（__人__丿　.....:::::::::::::::::::/　　
　　| |＿＿＿＿　ヽ　　　　　　.....:::::::::::::::::::::::<　
　 └＿＿＿／￣￣　　　　　　　:::::::::::::::::::::::::|
　　|＼　　　 |　　　　　　　　　　　　:::::::::::::::::::::::|
　　＼＼　　＼＿＿＿　　　　　　 ::::::::::::::::::::::::|

744 ：デフォルトの名無しさん：04/10/11 01:12:00

>>743
それって、C++ と C# の言語の違いじゃなく、C#は、.net 環境しかないから、ネイティブコードを作れないという違いじゃないの？

745 ：デフォルトの名無しさん：04/10/11 02:28:27

>>744
ネイティブコードを作れない、というのはひとつの言語だけを使うという前提の欠点であって、
C++と併用する分には問題ではない、ということ。
これまでだってVC++プログラマはVBを覚える必要（つーか義務)があったんだけど、
それに比べたらラクになったと思う。

WinFXがWin32に取って代わると、C++のネイティブコードによるAPI呼び出しは、C#からの
呼び出しよりもオーバーヘッドが増える（ように設計される）ので、少なくともAPI呼び出しに
関してはメリットがなくなる。
それでも、実行速度を求められる部分にはC++の利用価値は十分にあるわけだが、
単なる計算にしかメリットがないなら、C++の手腕はほとんど意味がない。
むしろデバッグの煩雑さが仇となって、案件が減る。おまんこの食い上げだ。

別にJ#でもVB.NETでもいいけど、最低限のツールとして.NET専用言語は覚えておくべきだ、
という話。

746 ：デフォルトの名無しさん：04/10/13 00:43:05

つまり、Winプログラマは、つべこべ言わずにC#に移行しろってことですね。

747 ：デフォルトの名無しさん：04/10/26 23:11:47

つべ

748 ：デフォルトの名無しさん：04/10/26 23:54:57

こべ

749 ：デフォルトの名無しさん：04/10/26 23:55:27

って、>>747、お前STLスレから来ただろ！

750 ：デフォルトの名無しさん：04/11/29 18:42:46

.net では、 C++/CLI よりも C#をマイクロソフトは推奨してるみたいですね。
C++は、既存のコードを使えるように残した感じ。

でも、C#ってVBっぽいって声も聞くし、MSオンリーな感じだし。どっちを使うべきなんだろうか。

751 ：デフォルトの名無しさん：04/11/29 18:43:42

Ｒｕｂｙｄｅｓｕ