[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 05/09 08:49 / Filesize : 163 KB / Number-of Response : 776
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

C++ってなんであんなに肥大化しちゃったの?



1 名前:デフォルトの名無しさん [2008/08/28(木) 14:48:15 ]
仕様が大きすぎるくせに、
実用的なライブラリが未整備。

なんかいらいらしない?
こんなこともできないくせに、
なんでこんな仕様ばっかり作るんだよって。
C++ってなんであんなに肥大化しちゃったの?
名前: 仕様書無しさん
E-mail:
内容:
仕様が大きすぎるくせに、
実用的なライブラリが未整備。

なんかいらいらしない?
こんなこともできないくせに、
なんでこんな仕様ばっかり作るんだよって。

C++はなんでもできます。でもなんにもできてないので
つくってね。的な。

331 名前:デフォルトの名無しさん [2008/10/01(水) 10:37:52 ]
カスタム・ヴィークル・オペレーション

332 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 10:48:31 ]
>>322
広いレンジって言っても文字が文字コード想定してないってだめでしょ。
JavaもC#もStringとかStreamはちゃんと変換できるようになってるからみんな
おとなしく使ってるでしょ。

333 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 11:39:18 ]
文字コード変換ってでっかいテーブルが必要だったりするから
組み込みでは難しかったりするんだろう
ライブラリに任せるというのは比較的真っ当なやり方だと思うがね

そもそもC/C++標準ではファイルシステムの存在すら仮定してないし
そういったシステムに依存するような仕様を緩くして
実装可能な範囲を広げようというスタンスなんだろう

334 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 11:47:29 ]
標準にlocaleがあるしcodecvtファセットがエンコード変換することになってるよ

まあ糞だけど

335 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 17:39:52 ]
間違った所を緩めてどうでもいい所を締めるから
COAP(笑)だのvector<bool>(爆)だのみたいな悲劇が生まれるんだよ

336 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 17:46:37 ]
どう考えてもMFCやVCLが実用的

337 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 17:50:15 ]
>> 336
組み込みでMFCやVCLは動きません 役割が違うのに批判されても困るわ

338 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 17:50:47 ]
何度ループしても糞であるという結論にしか至らないC++(笑)

339 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 17:57:34 ]
アホですね(笑)



340 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 17:58:35 ]
組み込みでSTLなんてそれこそ使えるか

341 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 17:59:14 ]
言語の標準ライブラリが特殊環境を想定する必要はない

342 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:00:08 ]
いまどきの組み込みはJavaや.NETが普通に動く世界なんだろ

343 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:01:08 ]
そんなのはハイエンドか産業用だけです

344 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:08:44 ]
Lispで動く炊飯器を見たい

345 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:12:53 ]
STLは、単品で使うには粗末だし。
メーカーのライブラリの基盤に採用するには癖が強すぎる。
何より標準ライブラリを名乗っている割に後発なのが痛い。

346 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:14:44 ]
もはや組み込み専用マイナー言語に落ち果てているのに
仕様的には肥大化しきってる

ぶっちゃけCでいいじゃん
人生をかけてC++を学んだ様な奴は認められないんだろうけど(笑)

347 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:17:22 ]
>>346
主な需要は組み込み、ゲーム、パッケージソフト
てなとこか
でも組み込みはどっちかっつうとCのがまだメインなんじゃないか?
他ではほとんど死んでるな

パッケージも、本当はC++である必要が無い気がするな
.NETやJavaまでいかんでも、リッチなOSを前提にできるんなら
GCぐらいはあってもいいし、ギチギチのzero overhead ruleなんて必要ない

348 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:30:51 ]
結論としては、CとC++の中間くらいが一番良さそうだな。
つまり、基本Cみたいな使い方でゴテゴテしたC++の機能は使わなかった俺が正解か。

349 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:35:08 ]
C++の素晴らしいところは本物のデストラクタを持ってることだ
リソースの完全な管理という点では今でも右に出る言語はないと思っている



350 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:38:23 ]
>>349
そっすねw
自己管理がんばってくださいww

351 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:42:36 ]
うんw
実際自己管理を頑張らなきゃならない場合ってのはあって
そういう時だけはC++は本当に役に立つし、なくてはならないんだよ
そういう時だけはな

352 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:50:23 ]
Pythonみたいに参照カウントとマーク&スイープ併用してる言語もあるよ

C++でshared_ptr使って参照カウントは出来るが、フツーのGCより効率悪いよね
便利機能一切使わない覚悟でないとC++のコードは速くならないっつか
確実にCより遅くなる
スレッドのことは勿論なにも考えてないからマルチコア時代では先が見えてるしな

353 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:51:00 ]
デストラクタならJAVAのほうがマシな実装だと思うぞ

354 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:54:28 ]
>>353
廃棄のタイミングを厳密に制御したいんでしょ

Pythonはブロック抜けで参照カウント0になれば廃棄されるし
(当たり前だがデストラクタは定義できるし実行される)
巡回参照でも大丈夫だよ

355 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:56:04 ]
>>348
D言語ですね、

でも、現在迷走中。

356 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:57:16 ]
Dは最初の狙いは悪くなかったと思うけど
開発者の独りよがりな趣味で終わりそうだね

357 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 19:01:03 ]
>>353
Javaのはデストラクタじゃなくてファイナライザ
ファイナライザは全然役に立たない

358 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 19:07:32 ]
C++/CLI最強説

359 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 19:24:17 ]
>>358
割と本気でそう思ってるんだが誰も同意してくれない



360 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 19:39:17 ]
>>358
C#の方が好きだ。

361 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 19:45:55 ]
C#もデストラクタないんだよな…

362 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 19:47:53 ]
IDisposable

363 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 19:50:47 ]
それデストラクタじゃなくてdelete

364 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 19:52:01 ]
using(Hoge hoge = new Hoge())
{
 //なになに
}

365 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 19:53:40 ]
確かにマルチスレッドとかマルチプロセスに特化した言語は欲しいな。

366 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 19:54:54 ]
うお、そんな書き方出来るのか初めて知った

C#いいな!

367 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 19:58:04 ]
でもC#にはローカル変数とかのfinal宣言子がない…
あればいいのに あれば…

368 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 19:59:38 ]
>>364
同じキーワードをあっちこっちの用途で流用するところはC++譲りみたいだな

369 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:00:52 ]
>>364
それ使いたいオブジェクトの数が増えると構文が悲惨よw



370 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:01:01 ]
もしかしてJavaもできるの?
C++はdeleteし忘れるからGC最高とか言ってる奴らが
結局finally節にdispose()とかclose()とかunlock()とかチマチマ書いてるのが
とっても滑稽だと思って以来いい印象ないんだけど
出来るなら認識改めないと

371 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:05:30 ]
スマポでええヤン

372 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:08:51 ]
コンテナに入らないふざけた奴か

373 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:10:56 ]
スマポが悪いんじゃないんです
auto_ptrがアホの子なだけなんです
COAPとか使いたがる奴らが悪いんです
許してあげて下さい

374 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:17:30 ]
まさに 「痒い所に手が届かない」

375 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:18:10 ]
tr1まで標準にリファレンスカウントなスマポ入れなかったってのは、
そもそも標準にスレッドセーフという概念が無いからか?
どっちみちSTLがスレッド?何それ?状態だから関係ねーけどな

ヨボヨボすぎて、もうモダンなOSの主要言語の座はとっくに引退していい仕様だろ
お爺ちゃんをいつまでも無理して使いすぎなんだよ

376 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:21:27 ]
0xでようやくスレッドの概念が入って
スレッドローカル変数とかが定義できるようになるらしいけどな

マトモになるのはいつになるやら

377 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:26:31 ]
iostreamとか、仕様練る時に変だろこれと誰一人思わなかったのかな。

378 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:26:44 ]
え?マトモにする予定なんてあるの?

379 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:31:52 ]
>>377
sprintfひとつですむことを
だらだら << 繰り返して書くのが楽しい。┐(´∇`)┌



380 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:33:38 ]
>>370
GCが便利なのはいっちいっちコピー先バッファとか
頭の悪いもの引数に用意しなくて済むからだよ。

381 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:40:32 ]
shared_ptrとか使って、ただのポインタアクセスをいちいち高価なものに
置き換えたりする必要も無いしな

382 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:44:10 ]
GCはshared_ptrなんぞよりよっぽど高価ですが

383 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:49:05 ]
>>377
iostreamの凄いところは、初期の仕様を捨ててわざわざ新しくしたのにそれでも糞であるというとこだね。
iostream絡みの昔のコードはどのみち通らないんだから、それなら思い切って捨ててしまえば良かったのに。

384 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:54:12 ]
マネージだからメモリリークしないと思っている人。
確かに、プログラムが終了するときにはリークしないでしょう。
けれど例えば、ある操作を繰り返すたびにメモリが解放されずに残ってしまう
ということは有り得ます。Javaでも同様です。
たとえば、ArrayListにStringを追加し続けているようなものです。

385 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 21:01:53 ]
GCは普通に使う分には便利だが
ゲームのオブジェクト管理とかやろうと思うとウザくなる

386 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 21:02:09 ]
>>384
unmanagedでもプログラム終了したらリークはしないでしょう。
何か特別なことしない限り。

387 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 21:07:02 ]
>>358
C++/CLIもコレクションに入れるとデストラクタが無力化する


388 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 21:08:36 ]
まあ、そんなに参照されるのがいやならソフトリファレンスでも使えや

389 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 21:50:39 ]
>>387
msclr::auto_handleは?



390 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 21:53:43 ]
そもそもauto_handle自身のデストラクタが働かないから_

391 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 22:35:54 ]
やっぱりmallocが最高だな。

392 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 23:54:57 ]
aro

393 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 00:39:29 ]
C++0x みたいな継ぎ接ぎはもういいから、新しいプログラミング言語の作成しろ。

394 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 01:43:49 ]
STL を組み込みで使えないという意見があったが、
処理系のデフォルトの operator new とか std::allocator
とかを使わないというだけで、<algorithm> も使うし
自前アロケータでコンテナも使うよ。

395 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 09:16:30 ]
C言語を完全に駆逐するためには
pc11.2ch.net/test/read.cgi/tech/1210158702/

396 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 10:58:03 ]
unixの設計のためにCを作ったように、
新しいOSのために、全く新しい言語が生み出されるであろう。

397 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 11:29:35 ]
んなこたぁー、ない。

398 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 18:09:47 ]
Be…

399 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 18:30:28 ]
並列プログラミングが重要視される時代なのでやっぱり新しい言語が必要。



400 名前:デフォルトの名無しさん [2008/10/02(木) 18:33:23 ]
ConcurrentC

401 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 18:41:36 ]
Nextだろ

402 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:07:59 ]
素朴な疑問なんだが
C++がCより開発効率が良いって主張あるよな?
ひとによっては暗黙の了解になってるぽいんだが
それって誰がいつどうやって比べたの?
ソースはあるの?

403 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:32:14 ]
鉛筆を一本ずつ数えるのとダースで数える程度の違い
ヘッダファイルの仕様化度が高いともいえるけど
所詮はマクロアセンブラを構文化しただけの言語
いくらでも非効率にも効率的にもできる

404 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:34:08 ]
↑に付いては知らんけど、COBOLの方がJavaよりも開発効率がいいなんて言い出すCOBOL脳には成るなよ。

405 名前:404 mailto:sage [2008/10/02(木) 23:36:10 ]
>>402

406 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:40:42 ]
>>402
高級言語の中で比較するんならどっちみちC++の生産性は低い
それ以上に再利用のしにくさが致命的
ABIが糞でコンパイル時計算への依存度が高いからな

407 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:41:06 ]
一応COBOLは開発効率を重視した言語だ
ただし、プログラマー向けじゃないけどね

408 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 23:46:15 ]
ソースは?脳内?

409 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 00:01:41 ]
個人的には、高級言語の皮を被った低級言語って感じでいいんだけどな。
基本Cでいいんだけど、少しだけ楽したいみたいな。



410 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 00:12:25 ]
ソースもなにも両方でプログラム作れば感覚でわかるだろ。

411 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 01:42:23 ]
CがC++よりいいって・・どうやってWindow表示すんの?MFCとかATLとか使わんの?クラスも使わんの?
CreateWindow(........)とかばっかしてがんばるの?なんなの?ばかなの?

412 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 01:50:29 ]
いい加減、開発の目的や背景を理解できるようになってくれ

413 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 02:06:05 ]
>>411
酷い馬鹿を見た
>>1から1000回読み直せ

414 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 02:17:32 ]
適切な設計をすればCよりは保守性も効率も上がると思うんだけど。
なんか極端なアンチが沸いてるが(俺ももちろんC++が楽だとは言わんが)、
必死に叩いてる奴って、クラスやテンプレートの使い方のセンスが無いor
理解できてない馬鹿ばっかりじゃないの?
単純に考えてC++はCに機能が増えただけなんだからCより悪くなるのは
機能の使い方が悪い以外に考えられん。

415 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 02:28:59 ]
> 単純に考えてC++はCに機能が増えただけなんだからCより悪くなるのは
> 機能の使い方が悪い以外に考えられん。

「キッチンシンク」という言葉は知ってるか?
なぜMultixが失敗してUnixが生まれたかを知っていれば
「大きいことはいいことだ」という単純素朴な発想は出てこないはずだ

C++みたいな半端な言語で何でもやろうとするのではなく、もっと高級で
ずっと生産性の高い言語とCを組み合わせるという選択も普通にあるんだが、
それも見えていないようだね

416 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 02:39:29 ]
まぁ、実際を考えると、マルチプラットフォームで使えるちゃんとしたコンパイラがあるかどうかってのもあるなw

417 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 02:49:20 ]
>>414
なるほど、C++の標準の策定者は「理解できてない馬鹿」で「機能の使い方が悪い」
からiostreamとか作っちゃうわけだな

418 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 02:59:05 ]
実用性は無くても、オブジェクト指向言語の可能性を立派にアピールしたよ

419 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 03:01:58 ]
C++をOOの代表であるかのごとくに言ったらOO信者の猛反発喰らうぞw



420 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 03:14:54 ]
C++はOOのOOらしさを極限までそぎ落とし、効率に振り向けた言語だからな

421 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 03:55:47 ]
オブジェクト指向言語の可能性←大間違い
オブジェクト指向の可能性←ギリギリおk

422 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 04:01:16 ]
SimulaとSmalltalkに失礼だな

423 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 04:07:21 ]
実用性皆無の実験言語が一般にアピールはないだろ
影響領域が違いすぎで失礼とかないわ

424 名前:414 mailto:sage [2008/10/03(金) 04:21:43 ]
>もっと高級でずっと生産性の高い言語とCを組み合わせるという
>選択も普通にあるんだが、それも見えていないようだね
なんか偉そうに言ってるけど、C++は実行効率最優先の言語なんですが。
生産効率が良くて、速度やメモリ効率を犠牲にしてでも高級な機能を持つ言語が欲しいのなら
最初からC/C++は選択肢に入らないだろ。見えてないのはお前の方だ。

425 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 04:34:31 ]
その低劣な生産効率を補えるほどに速くすらないのが問題なんだろ

vtbl持たなきゃならないのはオブジェクト指向言語の本質的な非効率性だから
C++でも他でも一緒だしな

426 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 04:39:32 ]
他の言語は知らないが、GNUとMSのコンパイラは
純仮想関数を使わない限りVTBLは使われないよ

427 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 04:54:09 ]
そりゃ使わない物は使わないし、まともなコンパイラなら省くに決まってる

でも継承を有効利用するにはvtblはないわけにはいかない
継承と多態性はオブジェクト指向の根幹だ

428 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 05:03:58 ]
だから、継承とプリモにはVTBLは必要ないぞ
COMとか使ったこと無いか?アレだ

429 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 05:07:31 ]
インスタンスが自分が何者かを知らずにどうやってポリモやるんだ?



430 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 05:11:22 ]
オブジェクト指向がどうこうってより、同じような設計をしようと思ったら
Cでやっても同じようなコード(vtblと同じ、関数アドレスを介した呼び出し)になるわけで。
原理的に無理なものをどうこう言っても仕方無いだろ。

ただ、D&Eに「多重継承をサポートする為に、vtblを”単一継承なら使える最も速い方法”で
実装しなかった(加算1つと代入1つ増えた)。ここだけは唯一ゼロオーバヘッドルールに
違反することになった」って書いてあったけども。

それすら気になるほど速度を重視するのならそもそも仮想関数を使わないor
vtblが必要になるような仮想関数の書き方をしなければいい。
そんな滅茶苦茶ギリギリで設計の自由度も無い状況で仮想関数使うような
多態性を用いる設計を使おうとする方がおかしい。

>>428
あまり詳しくないがCOMはvtbl使ってるはずだよ。

431 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 05:14:35 ]
>>430
そうそう
だから効率が重要な場合はあらゆるOO言語は使えないってこと
それはC++だろうとなんだろうと一緒な訳で






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<163KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef