【結構迷う】C vs. C++ 2行目【どっちで行こうか】

このエントリーをはてなブックマークに追加
1 ：デフォルトの名無しさん：
1 名前：デフォルトの名無しさん [sage]： 2008/04/06(日) 03:17:49
一般的には「C/C++」とひとまとめにされることの多い両言語ですが、
どちら一方をどっぷりと使っている人にとっては、かなり大きな
壁を感じると思います。

そこで、「C/C++」な人でも「C派」「C++派」に分かれて、それぞれの
観点からどちらの言語がより良いか、議論してみましょう。
主観的、客観的意見なんでも構いません。ただし建設的な議論に
なるよう、理由も添えてお願いします。

ルール
1．Java、C#などの「C/C++」以外は論外。これらについて言及している
レスは無視してください。

2．速い、遅いなどの議論は極力説得力のある根拠、ソース（情報源）
などを提示してください。

3．特定のOS、開発環境を理由に挙げたり、叩いたりしないでください。
たとえば、「Linuxの人は…」や「VC++ってやつは…」などは禁止。

4．標準、準標準のライブラリに関しては、その言語を使う場合常に
ついてまわるので言及をOKとします。

5．どちらか一方しか使ったことのない人は、その旨を述べた上で
意見をお願いします。

6．その他、明らかな煽りや無意味な書き込みも無視でお願いします。

前スレ
【結構迷う】C vs. C++【どっちで行こうか】
http://hibari.2ch.net/test/read.cgi/tech/1207419469/
2 ：デフォルトの名無しさん：2011/04/12(火) 15:15:50.85
関連サイト

C++はなぜ人気がないのか
ttp://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050215/156201/

もう C++ なんて好きでもないし使いもしない理由。
ttp://www.hyuki.com/yukiwiki/wiki.cgi?WhyINoLongerLikeOrUseCPlusPlus

Why not using C++?
ttp://xinehq.de/index.php/hackersguide#AEN405


Boost
http://www.boost.org/

GLib
http://library.gnome.org/devel/glib/2.8/
3 ：デフォルトの名無しさん：2011/04/12(火) 15:43:47.47
Linus TorvaldsがC++をメッタ斬り。
ttp://lwn.net/Articles/249460/
4 ：デフォルトの名無しさん：2011/04/12(火) 17:02:36.55
他人の書いたC++とPerlのコードは読み難くて嫌だ。
use strict がある分Perlの方がマシなくらい。

Cのコードは冗長だが読みやすい。Pythonのように。
5 ：デフォルトの名無しさん：2011/04/12(火) 17:18:09.12
C の汚ないコードも最悪だけどな。
C++ のまともなコードなら問題ないが。
6 ：デフォルトの名無しさん：2011/04/12(火) 18:58:21.44
主観的な読みやすさの順序

Cのきれいなコード > C++のきれいなコード > C++の汚いコード > Cの汚いコード
7 ：デフォルトの名無しさん：2011/04/12(火) 20:02:56.73
Cのきれいなコード > C++のきれいなコード > C++の汚いコード > Cの汚いコード > C++のBoostのコード
8 ：デフォルトの名無しさん：2011/04/12(火) 21:27:12.41
Cを推してる人は、CでもC++でもキレイなコードが書けるから
より可読性の高いCを好む。
9 ：デフォルトの名無しさん：2011/04/12(火) 22:31:38.12
C++の膨大なSTLをうまく使ってコードを書くのは実は結構難しい
Effective STLなどを読んでも落とし穴に引っかかりにくくなるだけで、
書けるようになるには別の訓練が必要
10 ：デフォルトの名無しさん：2011/04/12(火) 23:13:27.93
C++でまともなコード書けるプログラマなら、Cでもまともなコード書いてくれると期待できるが
逆は成立しない。
11 ：デフォルトの名無しさん：2011/04/12(火) 23:15:23.95
C++ を知っていれば C を知っているはずというのは幻想
C++ の知識や経験を増やしても C 的なコードが書ける様になる訳ではない
12 ：デフォルトの名無しさん：2011/04/13(水) 02:42:01.65
C的なコードってなんだ？
13 ：デフォルトの名無しさん：2011/04/13(水) 02:50:32.25
>>3
http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html
14 ：デフォルトの名無しさん：2011/04/13(水) 03:04:09.04
http://www2.research.att.com/~bs/bs_faq.html#compare
"... Language comparisons are rarely meaningful and even less often fair. ..."
15 ：デフォルトの名無しさん：2011/04/13(水) 07:57:36.97
>>14
C++は本当にひどい言語だと思うが、作者に突撃するのは違うと思うわ。
16 ：デフォルトの名無しさん：2011/04/13(水) 09:58:57.65
>>12
gets を使わないとか、マクロは大文字にするとか、C の常識を踏まえたコード
// コメントを使えたり、変数は必要な時に宣言出来るという、C の常識を踏まえたコード
17 ：デフォルトの名無しさん：2011/04/13(水) 15:23:41.86
C++はCのほぼ上位互換なわけだから好きな機能だけ選んで使えば
Cより悪くなることは事実上ない
ただスキルの低い人の書いたコードを扱わなければならない場合には
選択権がないのであまり快適ではない
まあ巨大プロジェクトならCの方が勝ることもあるだろうけれど
小規模ならSTLとBOOST使いまくってC++でやるのが早いよね
18 ：デフォルトの名無しさん：2011/04/13(水) 16:07:48.01
>>12
struct foo_t;

foo_t *foo_new(void);
void foo_method(foo_t *, ...);
void foo_delete(foo_t *);

みたいなのだろう
・ファイルスコープ、不完全型、union、void*、関数ポインタを駆使する
・templateやインライン関数はないのでマクロを使う
・名前空間が無いのでLispっぽく長い名前を使う
19 ：デフォルトの名無しさん：2011/04/13(水) 16:48:12.09
Cは完璧ニダ
C++は滅べ
ということ
20 ：デフォルトの名無しさん：2011/04/13(水) 17:32:08.27
>>17
今は若干乖離してるけどな、CとC++
まあ、その差もC++がそのうち取り込むんだけど
21 ：デフォルトの名無しさん：2011/04/13(水) 18:57:06.47
>>18
Cにもインライン関数はあるよ。知らないの？
22 ：22：2011/04/13(水) 19:01:19.40
それにCじゃstructは省略できないんだよ。
23 ：デフォルトの名無しさん：2011/04/13(水) 19:19:19.58
ああC99でinline出来たんだっけか
C99コードを書こうと思ったことはないし多分今後も無いから
忘れとったわｗ
typedefもしてないのにstruct省略したのは確かに俺のミスだ
24 ：デフォルトの名無しさん：2011/04/13(水) 19:29:16.68
名前空間はあれば当然使うけど、無くてもどうにでもなるっていうか。
http::request の代わりに http_request でも困らないよね。
25 ：デフォルトの名無しさん：2011/04/13(水) 19:41:08.32
>>24
名前空間の場合は補完が効くし、usingで省略したければ省略できる
それと、クラスも一種の名前の空間
C++ならメンバ関数にmethod()とつけるかもしれないが
Cならclass_methodのような形にせざるを得ない
名前空間まで入れると
namespace_class_method()
だな
困る困らないで言えばタイプが長くなるだけだけど、そりゃあったほうが楽だ
26 ：デフォルトの名無しさん：2011/04/13(水) 19:56:08.58
長くなるとtypoも増えるしなぁ
27 ：デフォルトの名無しさん：2011/04/13(水) 20:02:24.28
クラス含めて、名前空間ゼロってのはディレクトリの無いファイルシステムと同じ
ファイル全部同じ場所に並ぶ
仕方ないから、衝突を避けるために
FLAC__StreamDecoderSeekStatus()
みたいに長ったらしい名前をつけることになる
勿論関数だけじゃなくenum定数だのstructの名前だの、全部が全部だ
28 ：デフォルトの名無しさん：2011/04/13(水) 20:03:06.03
>>25
prefixでも補完は効くよね？こっちが何か勘違いしてるのかな。

それに自分の場合、基本的にファイルスコープの外に出る関数しか
namespaceに相当するprefixは付けないので、
意外とmethod()かtype_method()で済んじゃうし。

そりゃあ在れば便利なのが名前空間だけど、
C/C++だとABI不在のデメリットと引き換えだから。
29 ：デフォルトの名無しさん：2011/04/13(水) 20:05:12.41
もうアセンブラでいいよ
30 ：デフォルトの名無しさん：2011/04/13(水) 20:11:16.57
>>28
補完は確かにprefixでも効くね

2段目は作りによるわな
static関数ポインタを特定の構造体に突っ込んで、構造体だけエクスポートする系の
方法だと、確かに長い名前は比較的少なくて済む
あくまで「比較的」だけど

C++のABIの問題は確かにその通りだわな
ファイルスコープによるデータ抽象よりprivateはABI面で脆弱なので
結局手でpimplする必要があるが、それでも根本的なコンパイラ間互換性の問題がある
WindowsならCOM化という手もあるが面倒だ
31 ：デフォルトの名無しさん：2011/04/13(水) 20:14:04.06
>>27
Lisp-1とかLisp-2とかいう意味での名前空間としては、
Cにはラベル、struct/union/enumのタグ名、struct/enumのメンバ、
その他通常の識別子（変数/関数など）の４つの名前空間がある（マクロも入れれば５つか）。
だから

>> 勿論関数だけじゃなくenum定数だのstructの名前だの、全部が全部だ

は間違いだよ。
32 ：デフォルトの名無しさん：2011/04/13(水) 20:15:53.57
>>31
いや、その文は全部が全部同じ名前空間に属するという主張ではなく
全部が全部、長ったらしい名前をつけることになるという意味だよ
分かると思うけど

まあCが厳密に単一名前空間ではないというのは確かにその通りだけど
33 ：31：2011/04/13(水) 20:17:37.52
意図を読み間違えていたことに気づいた。
>>27よ、ごめん。
34 ：デフォルトの名無しさん：2011/04/13(水) 20:18:54.04
はっきり言ってCでは動的メモリ管理が面倒くさすぎる
木や文字列の処理などやる気にもならないレベル
35 ：デフォルトの名無しさん：2011/04/13(水) 20:22:45.28
>>34
> 木や文字列の処理などやる気にもならないレベル

100%同意するが、C++でもやる気にならないのですよ。
36 ：デフォルトの名無しさん：2011/04/13(水) 20:23:06.38
確かにGC欲しいよなｗ
37 ：デフォルトの名無しさん：2011/04/13(水) 20:32:04.28
C/C++で使えるGCと言えば、Boehm GCとかCRubyとかあるけど（CRubyはCだけかも？）、
使い心地はどうなのかね？
自分じゃ使ったことないからコメント出来ない。
38 ：デフォルトの名無しさん：2011/04/13(水) 20:36:51.53
C++と一緒に使う気にはならないな
Cとの組み合わせでは結構使われてるみたいだけど
保守的GCなので、ゴミをゴミと認識しないで残してしまうことがあるのが弱点

C++のスマートポインタも一種のGCでしょう、リファレンスカウントGC
勿論こちらも循環参照をゴミ掃除できないという弱点がある
39 ：デフォルトの名無しさん：2011/04/13(水) 20:40:19.19
GCが使えるシチュエーションなら、GC付きの言語でいい。
システムプログラミングだと、Linusに苛められるからCでいい。
40 ：デフォルトの名無しさん：2011/04/13(水) 20:44:03.89
>>38
C++だと、デストラクタで問題あるから最初から循環参照させないように組むし、
問題なく使えるよねスマートポインタ。
C++は嫌いだが、便利なのは否定できない。
41 ：デフォルトの名無しさん：2011/04/14(木) 00:15:48.76
クラスも一種の名前空間という話が出てたけど、
その意味ではメンバは一種のグローバル変数なんだよね。
42 ：デフォルトの名無しさん：2011/04/14(木) 01:17:25.20
GCが必要なところだけ、C++/CLIのgcnewでいいじゃないか。自分は嫌だけど。
43 ：デフォルトの名無しさん：2011/04/14(木) 01:23:17.84
>>35
動的メモリ管理の問題は std::string とか RAII に沿ったクラスを使うことで片付くと思うんだけど、
まだ何か問題あるの？
44 ：デフォルトの名無しさん：2011/04/14(木) 09:04:44.76
>>28
名前空間使っても extern "C" で口を開ければ C と同程度に ABI の問題は解決できると思うんだ。
45 ：デフォルトの名無しさん：2011/04/14(木) 11:11:04.98
C的な関数≒恣意的な関数
46 ：デフォルトの名無しさん：2011/04/14(木) 12:04:46.51
>>44
Cの関数をC++に取り込むのはゼロコスト（少々の非互換性があるが）だけど、
C++関数を extern "C" で公開するのは、多少手を加える必要があるから。

例えば、namespaceに属する関数やメンバ関数、オーバーロード使った関数の場合、
それ相応のprefix付けた関数を用意してラッパー書く必要があるし。
ちょっとした手間だけど面倒だよ。
47 ：デフォルトの名無しさん：2011/04/14(木) 12:06:18.13
>>43
動的メモリの問題というより、ライブラリの充実度かな。
文字列はPとかRで始まる言語が楽すぎて、もうC++でやる気は起きないよ（当然Cでも）
48 ：デフォルトの名無しさん：2011/04/14(木) 12:43:54.98
>>46
CにC++のクラスを取り込みたい状況というのが分からない。
C++にCなら良くあるが。
49 ：デフォルトの名無しさん：2011/04/14(木) 13:07:29.00
CのsoやDLLのABIはシンプルだから大抵の言語からリンクして利用できる
（再利用性が高い）けど、C++の場合、extern "C"でC ABIを適用しなければ
そうはならない（C++からしか使えない上に、コンパイラが違うだけで使えない）
という話では
Cから使いたいかどうかというより、ライブラリの再利用性の問題だな

まあC ABIが素晴らしいものかというと、別にそういうわけでもないんだがな
.NETやJavaやLLなら、関数の引数や戻り値にリストや木、辞書みたいなものを
使うのはごく普通のことだ
C++でもstd::map<>の参照を引数で渡したりするかもしれない
そんな「当たり前」の用途をC ABIに変換してごらん？
全く非本質的なことに馬鹿馬鹿しい労力が必要で、鬱陶しすぎてやってられないぜ
50 ：デフォルトの名無しさん：2011/04/14(木) 15:03:31.92
そらstd::mapはC++くらいでしか構築できないんだから
std::mapを引数に取る関数はC++以外で呼べる必要あんまないよね

同様にMYLIB_tree*を引数に持つ関数をC/C++以外から
NULL以外を引数にして呼ぶことなんてできないわけだし、
>>49て何なんだろうね。
51 ：デフォルトの名無しさん：2011/04/14(木) 15:24:18.21
>>50
>そらstd::mapはC++くらいでしか構築できないんだから
>std::mapを引数に取る関数はC++以外で呼べる必要あんまないよね

んな当たり前の話をしてるんじゃなくて、
意味・機能的にC ABIに移植することを考えれって話だよ
アホｋ？

>同様にMYLIB_tree*を引数に持つ関数をC/C++以外から
>NULL以外を引数にして呼ぶことなんてできないわけだし、

そんなことは無いよ
PODやそのポインタの範疇なら、普通にC/C++以外でも利用できる
C#でもpythonのctypesでもいいが、その手のffiを触ったこと
一度も無いだろお前
52 ：デフォルトの名無しさん：2011/04/14(木) 15:40:23.79
std::mapをDLLで使うとかどこの話だよ
__stdcallか__cdeclだけを置けよ
53 ：デフォルトの名無しさん：2011/04/14(木) 15:57:05.21
>>51
……C ABIに拘泥するあたり新しいものを勉強するのが嫌いなのか？
54 ：デフォルトの名無しさん：2011/04/14(木) 16:08:10.05
>>53
そうじゃなくてC++をDLLに置くと同じコンパイラを使う必要に迫られるだろ
個人的にはそういう縛りが嫌いなんで
55 ：デフォルトの名無しさん：2011/04/14(木) 16:35:44.85
名前修飾の問題ならdefファイル書けばいいんでない
56 ：デフォルトの名無しさん：2011/04/14(木) 16:51:54.96
defファイル書いたことないけど、コンパイラが違ったら
リンクできても例外等の仕様が違って実行時に落ちそうだが。
57 ：デフォルトの名無しさん：2011/04/14(木) 17:13:53.79
そんな事よりコンパイラが違うと単純にSTLのデータ構造が異なると思うが
58 ：デフォルトの名無しさん：2011/04/14(木) 17:18:05.00
STLとかinline化するためにあるようなものを遅延バインドさせるなって気が
59 ：デフォルトの名無しさん：2011/04/14(木) 17:35:05.97
まとめると extern "C" はめんどくせぇ
60 ：デフォルトの名無しさん：2011/04/14(木) 20:04:07.36
>>53
ffiも知らなかったくせに上から目線www
典型的なC++ PGですねw
61 ：デフォルトの名無しさん：2011/04/14(木) 20:40:32.00
STLのクラスとかは実装モロ出しでABIが脆弱な上に、アロケーションが
DLL境界またぐ可能性があるからな

DLL側とEXE側で可視なデータ構造が異なったりするのはABI不一致で当然だめだし
片方でアロケートしたリソースを片方で開放したりする場合、両者が用いている
アロケータが完全に一致しない限りNG
(malloc()/free()だとしても、同じコンパイラなだけではダメ）
ディスクリプタのようなランタイムオブジェクトを境界をまたいで渡すのも
問題を起こすことが多い

この辺はCでも同様だからC ABIなだけではダメなのだが
C++はname manglingの問題だけでなくこれらの問題にひっかかりやすい
脆弱な実装になっているので、C++ ABIなDLLを作るとピッキーすぎて使い物にならない

で、>>44の言うようにC ABIにすればよくね？という話がどうかというと、
C ABIは単純・貧弱すぎて、単にextern "C"つけりゃいいだけの問題じゃない
ただの文字列や数以上に複雑なオブジェクトをやりとりするコードに
いちいちCラッパー書いてたら面倒くさすぎて発狂するぞ
上の例で言うと、std::map<>のプロキシを構造体とポインタで書き、C用の
要素のアクセスコードを書き、プロキシとstd::map<>の変換コードも書く必要がある
62 ：デフォルトの名無しさん：2011/04/14(木) 21:28:13.18
>>54
DLLなんて使わずに、ソースからビルドすればいいんじゃね？
63 ：デフォルトの名無しさん：2011/04/14(木) 21:33:04.16
std::mapを外に出すのは設計がおかしいんじゃねえの
何のためのDLLか、何のための複数言語による開発か
というところから見直すべきだろう
64 ：デフォルトの名無しさん：2011/04/14(木) 21:35:08.81
特にテンプレート多用されるようになってから、C++におけるコードの再利用は
ソース（ヘッダ）レベルで行われる率が高くなってるな
テンプレートならどのみちそうせざるを得ないし、ABIがダメだから

「コード再利用」という意味では間違いなく退化だし
コンパイル時間の長大化の原因の一つだ

LLとか.NETとか関数型とか、今時の言語と比べるとあらゆる意味で面倒過ぎ
どーしてもC/C++じゃなきゃいけない場面以外では避けたい
65 ：デフォルトの名無しさん：2011/04/14(木) 21:42:16.58
>>63
少なくともこれがJavaや.NETやLLのようなモダンな言語なら、MapだのListだのと
いった基本的で水や空気のように使われるデータ構造をライブラリの
インタフェースとして外に出すのはごく普通で当たり前の設計

それが出来ない、すくなくともやりにくいのは
設計云々じゃなくて結局CやC++の言語使用やABIに問題がありすぎるからだよ
66 ：デフォルトの名無しさん：2011/04/14(木) 22:00:57.75
>>65
Cで書かれたMapやListなら外に出せるよ。
それを必要とする言語が存在しないだけで。
67 ：デフォルトの名無しさん：2011/04/14(木) 22:09:23.26
確かにCは出せるが、低水準すぎるCはそういう高水準なデータ抽象を
標準で何も持っていないから、常に手書きする必要があるし、それゆえ
汎用的なバインディングを作りようもない
68 ：デフォルトの名無しさん：2011/04/14(木) 22:15:43.04
>>65
std::mapの関数を一つ一つ
引数をC/C++が受け取れる形に直して
C/C++の関数を呼び出す環境を用意して
当然inlineはできずcallし
元の環境に戻し
返り値を呼び出し側の言語が使えるようにする
という手順踏む意味あるんかい。STLの利点死ぬやん。
組み込みの連想配列なりunsortedなkeyとvalueのpairの配列なり
IUnknownなりあるんだから設計の間違いやろ。

統一されていないコーディング規約は害悪でしかない。
開発言語の統一をしないのならば、そのしない理由に沿った使い方しろよと。
69 ：デフォルトの名無しさん：2011/04/14(木) 22:40:03.01
>>68
設計を実装に即してだけ考えすぎ
抽象度の高いレベルで考えると、辞書をインタフェースにすることは
「設計」として特に問題はないし自然な発想だろ
それがC++の世界で閉じているなら、実装レベルでさえそれは問題はない

いざABI界面にそれを出そうとした場合に実装において問題になるわけだから
勿論現実には設計を（必要なら）実装に即して「捻じ曲げる」必要があるが
自然な設計を捻じ曲げなければならない時点で、それはその実装系がpoorだから
という話だ

勘違いしてもらっちゃこまるが、俺はstd::mapに対して実際にそういう具合に
Cのproxyを作れといっているんじゃない
そういう実装段階での設計の捻じ曲げが必要になること事態が問題だといってるんだよ
70 ：デフォルトの名無しさん：2011/04/14(木) 22:54:20.16
>>65
JavaのMapやListを.NETで使うのって大変じゃね？
71 ：デフォルトの名無しさん：2011/04/14(木) 22:56:46.36
>>69
いわゆるABIでやりとりしようとするのが間違いで
XMLあたりで表現してやりとりすればいいはなし。
72 ：デフォルトの名無しさん：2011/04/14(木) 23:02:33.80
>>71
そうすることは可能だけど、お互いに同じデータ構造を毎回
シリアライズ・デシリアライズして、パースするような非効率な設計／実装を
わざわざC/C++で選択するか？
まあ受け渡し手段がIPCならそれは妥当だけれども……
効率度外視してるのにC/C++なんか選ぶ意味って何？
73 ：デフォルトの名無しさん：2011/04/14(木) 23:13:16.53
>>71
ABIの方が速いから。
ABIでもマーシャリングのコストはあるけど、
C/C++側で重い処理を走らせられればペイするからなー
74 ：デフォルトの名無しさん：2011/04/14(木) 23:18:22.30
三行目は確かにその通りだね
APIが疎結合で、マーシャリングの頻度が十分少なければたいした問題にはならんだろう
75 ：デフォルトの名無しさん：2011/04/14(木) 23:38:23.37
>>69
ABIの不在という問題はいろんな著名人があちこちで言ってるんで皆知ってるし
そういう他人の受け売りでdisるだけなら他所でやれって思うが。
一応ここ、C vs C++スレなんだから、"どっちもダメ"論を展開されても困る。
76 ：デフォルトの名無しさん：2011/04/14(木) 23:45:21.82
std::mapの内容をシリアライズして共有メモリかパイプで送った方が速いような
無理ならファイルでもいい
77 ：デフォルトの名無しさん：2011/04/14(木) 23:49:13.95
>>69
LL側の連想配列でも、std::mapとint[string]のマーシャリングでもなくて、
std::mapをインターフェイスに使うのが自然だと考えた理由は何よ。
実装を見据えない設計が潰れただけじゃないの。
LL側にconstなくて第三次だのABI以外に考えるものは多いよ。
78 ：デフォルトの名無しさん：2011/04/14(木) 23:52:43.61
>>77
いやLLつってるのは、単にあれだぞ？
LL用に書くCの拡張／組み込みコードの話じゃなくて、LLによる実装コードの話だ
だからもちろんstd::map<>じゃなくてただのLLの組み込み辞書型だ

なんかどうも意図が通じないってか、意図的に枝葉末節にこだわって
自転車場の議論に持ち込もうとしてない？
俺の言ってる意図ってそんなに分かりにくいか？
79 ：デフォルトの名無しさん：2011/04/14(木) 23:55:46.80
>>75
そこまで言うんなら誰も見たこともないような斬新で高尚な意見を
自分から述べてくれよ
心にも無いことを言う気にはなれんしな

80 ：デフォルトの名無しさん：2011/04/15(金) 00:14:45.02
>>78
へえ、どれが誰のレスだかわかりますか

とりあえず「STLコンテナはバイナリ境界をまたげますよ」で終わるのかねえ
81 ：デフォルトの名無しさん：2011/04/15(金) 00:18:35.91
またげるが、コンパイラのバージョンやランタイムのデバッグ変種、
SECURE_SCL関連のコンパイルフラグなどがexeとdll等が違うだけで
問題を引き起こす（つまり非常に脆弱）ってことだろ

要は独立性や再利用性が非常に弱いわけで、それぐらいならそもそもdllに
分離する必要があるのかという疑いすら出てくる
82 ：デフォルトの名無しさん：2011/04/15(金) 11:53:06.15
コアライブラリはCで書いて、それを他言語（C++含む）から呼び出すのが
現実解ということでよろしいか
83 ：デフォルトの名無しさん：2011/04/15(金) 11:59:24.42
>>82
何の現実解だよ？
問題が定義されていないところで解について同意を得られるわけがないだろう。
84 ：デフォルトの名無しさん：2011/04/15(金) 12:30:18.92
問題：高性能なアプリケーションを少ない労力で開発したい
解答：LLやVM言語で抽象プログラミングし、遅い部分をCで書く
85 ：デフォルトの名無しさん：2011/04/15(金) 13:12:37.64
>>84
「～遅い部分を」まではベストプラクティスと言ってしまってもいいだろうけど、
このスレは最後の「Cで書く」について C と C++ とのどっちでいくかを考えるスレ。
その点を問題にしないのならスレ違い。
86 ：デフォルトの名無しさん：2011/04/15(金) 13:22:38.85
>>85
このスレの流れ読んでないの？
直前まで、C++よりCの方がLLとリンクしやすいって話だったと思うけど。
extern "C" するためにSTLコンテナをPODに変換するくらいなら
最初から全部Cの方がマシだよ。遅い部分だけC/C++で書いて
抽象プログラミングは別の言語でするんだし。
87 ：デフォルトの名無しさん：2011/04/15(金) 13:39:49.83
>>86
C or C++ に要求する処理の中で「文字列→文字列」のマッピングが使いたいとする。
処理のインターフェースは C 向けに定義されたものがあるとする。

C: 文字列・マップのメモリ管理を自前で書く必要があるが、インターフェースの
加工は不要。

C++: std::map<std::string, std::string> を使えるが、インターフェースの
宣言を extern "C" { ... } で囲う必要がある。

つまり「文字列・マップのメモリ管理を自前で書く」労力と
「extern "C" { ... } で囲う」労力との選択になると思うんだけど、
これらの比較はされていない。
88 ：デフォルトの名無しさん：2011/04/15(金) 13:42:54.66
>>87
ちょ、ちょっと待て
単に

extern "C"
void f(std::map<std::string, std::string> &dict);

とかすりゃいいとでも思ってるのか？
Cリンケージ指定しといてインタフェースで非POD型使うなんて既知外もいいところだぞ
89 ：デフォルトの名無しさん：2011/04/15(金) 13:46:53.72
>>88
「インターフェースは C 向けに定義されたものがあるとする」って書いただろ。
↓こんなのが先に決まってるとしての話。
void foo(char const* keys[], char const* values[], int n);
90 ：デフォルトの名無しさん：2011/04/15(金) 13:49:12.12
まあどうせC++うんこでダメなんだから最初からCで書けば楽かと言えば
全然そういうわけではない

libfoo_dict_t * dic = libfoo_dict_new();
libfoo_dict_set_value(dic, "foo", "bar");
libfoo_do_something_with_dict(dic);
libfoo_dict_iterator_t *diciter = libfoo_dict_iterator(dic);
while (libfoo_dict_iter_next(diciter)) {
　const char *key = libfoo_dict_get_key(diciter);
}

みたいなコードになるんだろう
ちっとも楽じゃない上に鬱陶しいことこの上ない
91 ：デフォルトの名無しさん：2011/04/15(金) 13:49:57.97
>>89
なるほど、ｽﾏｿ
92 ：デフォルトの名無しさん：2011/04/15(金) 14:04:57.19
ループ構造と計算式だけで作れるものはC
それ以外はC++って感じかな
RGBをYMCA形式（？）とかってやつに変換するくらいならC++固有の技術使うような機会はないだろうけど
オセロのCPUならクラスを使った方が拡張や改良するときにやりやすいはず
93 ：デフォルトの名無しさん：2011/04/15(金) 14:10:58.92
>>87
STLで用意されてるような操作は、LLやらVM言語でも組み込みで持ってないか？
それらは内部でC/C++で実装されてるんだろうし、そんな処理を速度的な問題で
C/C++に要求することって実際あるの？
94 ：デフォルトの名無しさん：2011/04/15(金) 14:14:07.99
>>93
いやリストだの辞書使ってそういうどこにでもあるジェネリックな仕事をしたいだけなら
いちいちCのコード書く必要は確かにないだろうけど

ここでのリストとかは単にデータをインタフェースにわたすための道具で、
そのデータを使ってなんか特殊で性能を要する仕事をしたいからCとかで書きたい
そういう場合の話をしてるんでしょ
95 ：デフォルトの名無しさん：2011/04/15(金) 14:21:44.58
どのみちCでもstring相当の独自バッファとか使ったら、
C++での外部インターフェース相当を書くわけだろ？
内部実装書かないで済むだけ、やっぱりC++の方がちょっと楽できるんじゃないの？
96 ：デフォルトの名無しさん：2011/04/15(金) 14:31:52.54
多分楽はできるけど
多分むなしい度が高い

Cだともともと低レベルでなんにも無いからどのみち書かなければいけないコードだが
C++の場合はそうじゃないから
97 ：デフォルトの名無しさん：2011/04/15(金) 14:34:42.32
あー確かにむなしさはあったｗ
98 ：93：2011/04/15(金) 14:45:52.88
STLがあれば内部実装の大部分を省略できるような処理をC/C++に投げる？
皆がどういう状況を想定して言ってるのか分からん。
たぶん自分が少数派なんだと思う。

ちなみに、自分は数値計算ライブラリをCで書いてる。
hashMapとかも内部で使ってるけど、ライブラリを書く作業全体と比べれば
一から全部自前で実装しても面倒さは誤差の範囲だ。書くのもテストも簡単だし。
もちろん、作業の大部分はコードの正当性の検証（とアルゴリズムを導出するところ）。
99 ：デフォルトの名無しさん：2011/04/15(金) 18:16:47.05
>>95>>96
むなしさだと？デバッグに費やす時間の間に感じる自虐感と比べてどちらがいいんだ？
よく考えてみ
100 ：デフォルトの名無しさん：2011/04/15(金) 20:43:50.64
それを「むなしい」って感じる奴って後ろ向きすぎ
101 ：デフォルトの名無しさん：2011/04/16(土) 01:44:10.15
>>96
車輪の再発明やテストにたっぷり時間をかけることで得られる充実感（？）がCのメリット
というわけですね？
102 ：デフォルトの名無しさん：2011/04/16(土) 02:53:03.53
Cにも glibc とか APR とか Glib とかのサポートライブラリはあるので、
車輪の再発名は必要ないよ
103 ：デフォルトの名無しさん：2011/04/16(土) 03:58:16.77
>>102
あ、そう。

>>96
じゃぁ >>90 みたいな冗長なタイピングを繰り返すことで得られる充実感（？）がCのメリット
というわけですね？
104 ：デフォルトの名無しさん：2011/04/16(土) 09:21:49.58
>>103
for (std::vector<RecordTypeFoo>::const_iterator iter = dic.begin(); iter != dic.end(); ++iter) {
...
}
みたいなのは冗長なタイピングじゃないんだよね？わかるわかる
105 ：デフォルトの名無しさん：2011/04/16(土) 09:36:34.97
タイピングが冗長とか言ってる低能は素のviやメモ帳で書いてるの？
補完とか使えないの？
106 ：デフォルトの名無しさん：2011/04/16(土) 10:21:43.88
タイプ数とか言ってるアホはPerlでも使ってろ
107 ：デフォルトの名無しさん：2011/04/16(土) 12:53:13.95
>>104
何でauto使わないの？
108 ：デフォルトの名無しさん：2011/04/16(土) 13:03:30.78
>>107
つまりC++0x以前のC++は冗長でクソでしたってこと？
109 ：デフォルトの名無しさん：2011/04/16(土) 13:04:37.02
>>104,108
C++2003 でも BOOST_FOREACH() ってもんがあってな。
110 ：デフォルトの名無しさん：2011/04/16(土) 13:15:09.46
>>109
C1Xでも BOOST_FOREACH 相当が実装できそうだが
111 ：デフォルトの名無しさん：2011/04/16(土) 13:38:04.25
>>110
そうなの？
C_ARRAY_FOREACH とか LIBFOO_DICT_FOREACH とか、
対象のコンテナごとに別になっちゃうんじゃない？
112 ：デフォルトの名無しさん：2011/04/16(土) 13:45:50.99
>>111
C1Xには _Generic キーワードが入って type-generic が出来るようになった。
template の代わりになるようなもんじゃないし、ビックリするほど醜くなるが
できると思う。
113 ：デフォルトの名無しさん：2011/04/16(土) 13:58:14.46
>>108
そりゃautoが導入されたのは冗長だって認識されたからでしょ。
でも、それだけで以前のC++をクソ呼ばわりするなら、Cなんて
最初から最後までクソの固まりってことになってしまうよ。
114 ：デフォルトの名無しさん：2011/04/16(土) 14:16:25.11
>>113
冗長さなんてどうでも良いと思ってるから、それが理由でC++がクソだとは思ってないよ

なお、C++0xでautoが導入された一番の理由は、
C++では型を正確に知るのや書くのが難しい場合があるからだってさ
http://www2.research.att.com/~bs/C++0xFAQ.html#auto
115 ：114：2011/04/16(土) 14:18:23.47
ここでいう冗長さっていうのは、型名や関数名が長いってことね
116 ：デフォルトの名無しさん：2011/04/16(土) 14:27:57.02
>>104
タイピングは補完すればいいから大した手間じゃないけど、
読むのが面倒くさいな。
FullHDのディスプレイいっぱいに使ってまだ入りきらないのとかあるし。
117 ：デフォルトの名無しさん：2011/04/17(日) 10:27:07.93
>>104
for_each ( dic.begin(), dic.end(), some_struct() );
118 ：デフォルトの名無しさん：2011/04/17(日) 10:58:53.59
SchemeでCコードを生成してる俺からすれば
C++の抽象化などウンコ
119 ：デフォルトの名無しさん：2011/04/17(日) 12:48:11.02
>>90
Cでもこんなふうにすれば関数名は短くなる

典型的なCの関数の例
void std_foo_func(std_foo_t, int)
void std_bar_func(std_bar_t, int)

(1)namespaceもどきを実装
#ifdef USING_NAMESPACE_STD
#define foo_func(...) std_foo_func(__VA_ARGS__)
#define bar_func(...) std_bar_func(__VA_ARGS__)
#endif

(2)_Genericを使用(C1Xから)
#define func(self,...) _Generic((self), std_foo_t: foo_func, std_bar_t: bar_func)(self,__VA_ARGS__)

これで以下のように呼べる。キメエwww
int n;
std_foo_t x;
std_bar_t y;
func(x, n) // std_foo_func(x, n)
func(y, n) // std_bar_func(y, n)
120 ：デフォルトの名無しさん：2011/04/17(日) 21:53:40.57
>>113
autoは（ユーザ定義型の）暗黙型変換と組み合わさることで
恐ろしくデバッグ困難なコードができそう
121 ：デフォルトの名無しさん：2011/04/18(月) 07:20:58.78
えーと、つまりSTLコンテナのような便利ライブラリは
Cにも準標準で存在するし、コードは読みやすく書けるし、ABIはあるし、
C++の人気はゆっくりと下降してるから将来性が（メンテナンス面で）不安だし、
やはり>>84ならCを使うのが最適ですな
122 ：デフォルトの名無しさん：2011/04/18(月) 07:27:44.01
Cを使うとC++使いを排除できるのが魅力だ。

C++使いはC++におけるイディオムを覚えてるだけで
正確に言語仕様を把握してるわけじゃないから
イディオムが異なるCは書けないんだよねwww
123 ：デフォルトの名無しさん：2011/04/18(月) 10:23:33.22
えーと、つまりSTLコンテナのような便利ライブラリが
C++には標準で存在するし、コードは読みやすく書けるし、ABIはあるし、
Cの人気はゆっくりと下降してるから将来性が（メンテナンス面で）不安だし、
やはり>>84ならC++を使うのが最適ですな
124 ：デフォルトの名無しさん：2011/04/18(月) 10:41:56.75
メンテナンス面の不安という意味では
C++の膨大な言語仕様は足枷になると思う
単純に習得が困難だから、人気が落ちると新人の確保が難しそう
125 ：デフォルトの名無しさん：2011/04/18(月) 10:45:15.33
>>121
> えーと、つまりSTLコンテナのような便利ライブラリはCにも準標準で存在するし
これ何のことを言ってるんだろう…
RAIIによるメモリ管理、テンプレートによるジェネリシティ＋型安全性＋効率性
言語標準であることによる普及度

比べるのが失礼なレベルのものしか思いつかないのだが
126 ：デフォルトの名無しさん：2011/04/18(月) 10:51:30.53
>>124
日本だとパッケージはほぼ死滅してるから
ビジネスでのC++の主な用途は組み込みやゲームといったあたりだろう
限られた範囲の要員ぐらいはいるんじゃねーのかな

今時ゲームをC++やC#やフラッシュで書く奴はいてもCで書くやつはいないから
127 ：デフォルトの名無しさん：2011/04/18(月) 10:53:42.03
今の所C++で実用レベルで生き残ってるライブラリはQtぐらいじゃね？
後は科学技術演算ライブラリ程度か
128 ：デフォルトの名無しさん：2011/04/18(月) 10:59:05.35
>>125
効率性以外は概ね同意。でも、そういうのはLLとかVM言語でやれば？と思うが。
どんだけC/C++でコード書くつもりなんだよと（>>84の問題設定理解してる？）
もうC/C++なんて可能な限り書きたくない、という前提を忘れてる。
129 ：デフォルトの名無しさん：2011/04/18(月) 11:04:16.21
>>126
CUDAとかOpenCLとかのマルチコアCPUやGPUを扱うフレームワークが
Cで提供されてるので、高パフォーマンスを必要とするときは
まだまだCは現役
130 ：デフォルトの名無しさん：2011/04/18(月) 11:08:16.59
>>128
そっちこそスレタイ読んだほうがいいんじゃないの
CかC++を使うべき・使わざるをいけない時にどっちで行こうかってスレだろここ

それに「そういうの」って意味がよくわからんぜよ
CかC++が出てくるような場所にはベクトルやリストの処理は出てこないとでも？
kernelだろうがデバイスドライバだろうがエンコーダだろうが
必ず使うだろその種のデータ構造……
（実際にC++とSTLを使うかどうかは別だ）
131 ：デフォルトの名無しさん：2011/04/18(月) 11:09:18.30
>>129
いや当たり前だけど、それはC++で叩けるから……
まあ敢えてCで書いてるってんなら何も言わないけど
132 ：デフォルトの名無しさん：2011/04/18(月) 11:11:46.42
>>125
STL遅えwww効率性wwwww
ttp://d.hatena.ne.jp/fd0/20080419/p1
133 ：デフォルトの名無しさん：2011/04/18(月) 11:13:20.05
>>131
マジか……以前CUDA使ったときはC++が通らなくて俺涙目だったのに
134 ：デフォルトの名無しさん：2011/04/18(月) 11:13:56.10
>>132
ああSTLの非オーダードマップはおせえ。特にじんかむうぇあは

ただアルゴリズム系は大抵手書きするのと効率が変わらんし
std::sort()は関数ポインタ渡しになるqsort()より高速なことで知られてる
135 ：デフォルトの名無しさん：2011/04/18(月) 11:16:58.39
>>130
Linuxカーネルでもリストは使ってるぜ
container_ofマクロを使った変態コードだがな
136 ：デフォルトの名無しさん：2011/04/18(月) 11:18:03.39
>>133
nvccでC++は一応使えるんだけどまだバグが多いという感じみたいだな

まあ多くの商用ベンダのC++コンパイラが標準準拠またはそれに近い状態になるまで
どんだけ時間がかかったか考えてみればさもありなん
137 ：デフォルトの名無しさん：2011/04/18(月) 11:18:44.05
>>135
BSDだとqueue.hとかだな
勿論マクロ多用
NTにも似たようなヘッダがある
138 ：デフォルトの名無しさん：2011/04/18(月) 12:02:26.27
>>130
「そういうの」の意味は、効率が一番の目的のような場合(>>84)に
>>125のような利点は重要なのか？ってこと。
Cにも抽象コンテナ実装はあるし、それらの実装は安全性以外は劣らんだろう。
もちろん安全かつ効率的なのが一番だけど、C++はコードサイズひとつとっても
Cより肥大化傾向だから。extern "C"するならそのインターフェースの分もな。
139 ：デフォルトの名無しさん：2011/04/18(月) 12:09:27.42
ここの速度差などどうでもいい。
完成品のボトルネックが問題。
それがSTLだったら書き換える、違えばそれを書き換える。
140 ：デフォルトの名無しさん：2011/04/18(月) 12:33:30.48
C++はコンパイラのバグが腹立たしすぎる。ありえん。
141 ：デフォルトの名無しさん：2011/04/18(月) 12:38:22.72
特にWindowsの場合、どのみちAPIの都合などで言語の選択の余地がないケースはある
（COMまたは準COMの形でインタフェースが規定されている場合など）
UIツールキットもGTK+を除いてほとんどC++だし
フォトショやブラウザみたいにある程度複雑で大規模なネイティブGUIアプリは結局
大半がC++で作られている
プログラマなら適材適所で使い分けるだけの話じゃないのか
なんか現実が見えてない発言としか見えないものが多いな
142 ：デフォルトの名無しさん：2011/04/18(月) 12:58:14.81
現実という意味ではC++はオワコン
143 ：デフォルトの名無しさん：2011/04/18(月) 13:01:02.60
第2のCOBOLはJavaかと思ったらC++だった
144 ：デフォルトの名無しさん：2011/04/18(月) 15:43:51.72
iPhone/iPadもAndoroidも脱JAVAしてC使わせてまで
速度を稼ぐ方向に行ってるので、どうだろうかな。
145 ：デフォルトの名無しさん：2011/04/18(月) 19:50:12.48
第2のCOBOLはVisual Basicだろ
146 ：デフォルトの名無しさん：2011/04/18(月) 19:56:23.60
じゃあC++は第2のPerl
147 ：デフォルトの名無しさん：2011/04/19(火) 01:02:49.13
WindowsでもmingwのおかげでC99が使えるから
C++なんて全く使わなくなったわ
148 ：デフォルトの名無しさん：2011/04/19(火) 09:21:53.16
皆で共有する再利用性の高いコードはC
自分一人で使うやっつけ仕事用のコードはC++
プログラマなら適材適所で使い分けるべき
149 ：デフォルトの名無しさん：2011/04/19(火) 11:45:57.29
> 理由の無い断定のみ
150 ：デフォルトの名無しさん：2011/04/19(火) 13:50:45.26
>>149
可読性が低いとか罠だらけの文法とか、C++には色々言いたいことがあるが。
もっと客観的なデータとして、C++のトレンドは低下している。

http://www.tiobe.com/index.php/content/paperinfo/tpci/
http://journal.mycom.co.jp/news/2011/04/19/016/index.html

なんで再利用性の高いモジュールを、より人気が低く下落傾向にあり
ポータビリティでさえ劣る言語で書かなきゃならんのよ？
>>141の言うように選択の余地が無いならともかく、沈み行く船に
進んで乗っかるのはアホのすることだ。
151 ：デフォルトの名無しさん：2011/04/19(火) 14:00:10.05
>>150
人気が重要ならCのほうがいいだろうってことね。
別にそれはそれでいいけど、そうじゃない場合もあるでしょ。
インターフェースをCに固定してC++で実装することもできる。
152 ：デフォルトの名無しさん：2011/04/19(火) 14:12:03.33
>>150
型エラーやリソース破棄漏れの防止が人気やポータビリティよりも重要なら
C++で書いたほうがいいんじゃないの？
153 ：デフォルトの名無しさん：2011/04/19(火) 14:22:22.68
型エラーは警告でつぶせるし、
リソース破棄漏れはRAIIなら大丈夫とか言ってるC++のコードの方が酷い。
ろくにリソース破棄時のエラーをチェックしてないからな。
きちんとエラー拾ったらJavaのtry/finallyだらけのコードみたいになるし（C++にはfinallyすらないが）。
それに extern "C" するならちゃんと全部の例外拾っとけよ？
154 ：デフォルトの名無しさん：2011/04/19(火) 14:32:26.20
断定を避けるため、とりあえずCとC++の共通部分を利用するべき。
共通じゃない部分はC++でもGLibでもLLでも良いので、断定してはいけない。

C++を使うということは、断定するということ。
155 ：デフォルトの名無しさん：2011/04/19(火) 14:38:54.50
むしろC++は下手に extern "C" とか考えるより
STL と boost を使いまくり、例外も演算子オーバーロードも使いまくり、
とにかくC++のあらゆる言語機能を使い倒した方が書いてて楽しい。
どうせ言語機能の一部を自粛したって、それを簡潔に明示する方法がない以上
(Perl の use strict; 的なやつ)可読性はたいして上がらないし、
だったら自由にやった方が精神衛生上もいいよ。
better C とか Embedded C++ とか誰得。
156 ：デフォルトの名無しさん：2011/04/19(火) 15:09:43.76
extern "C"は価値はある。
関数内は一番手間がかからない方法で実装。
ボトルネックをC言語やアセンブラにする。
157 ：デフォルトの名無しさん：2011/04/20(水) 00:49:26.85
>>153
型エラーについてはCだと警告だけどC++ではエラーになる。
エラーのほうが望ましい理由はわかるよね？

リソース破棄時のエラーについて、C++で酷いコードになるケースが
あるのはわかるけど、同じケースに対してはCでも同じことになるでしょ。
そして、メモリやそのほか破棄処理がエラーを起こさない多くの
リソースについてC++の利点は生きる。
どちらかといえばC++のほうがいいのは明らかじゃない？

extern "C" から例外もらさないように注意するのは当然な。
catch (...) しとけば済む。
158 ：デフォルトの名無しさん：2011/04/20(水) 00:53:49.86
>>157
>エラーのほうが望ましい理由はわかるよね？

プログラマの意図に合わせて柔軟に対応出来る方が望ましいよ。
159 ：デフォルトの名無しさん：2011/04/20(水) 00:56:26.12
何も考えずに -Werror 付けるバカを思い出した。
160 ：デフォルトの名無しさん：2011/04/20(水) 01:00:25.55
>>158
警告で済まされていたほうが柔軟に対応できて望ましいような型エラーって、どんなの？

特別な意図があって許して欲しいときはコメント付きでキャスト入れてもらったほうがいい
場合しか思い当たらなかった。警告だと何も書かずに無視されちゃう。
161 ：デフォルトの名無しさん：2011/04/20(水) 01:01:07.01
無視するなよw
162 ：デフォルトの名無しさん：2011/04/20(水) 01:03:32.14
手早くプロトタイプを作る時なんか、コンパイルを通すだけの為のキャストなんてしてられんわ・・・
163 ：デフォルトの名無しさん：2011/04/20(水) 01:06:02.18

C++ PG : 「何か警告出てましたけど、無視してやったっス

C PG : 「お前・・・
164 ：デフォルトの名無しさん：2011/04/20(水) 01:43:36.47
Cの人は相変わらずだなぁ。
165 ：デフォルトの名無しさん：2011/04/20(水) 01:44:16.52
C++の人は期待通りだなあ。
166 ：デフォルトの名無しさん：2011/04/20(水) 02:25:34.27
んなこたーどうでもいいから議論を進めろよカスども。
167 ：デフォルトの名無しさん：2011/04/20(水) 04:57:21.94
警告無視しました。その結果バグりました。
自分を含め、コードを利用する全ての人が警告&バグに気づきませんでした。
みたいな状況をまじめに議論するの？勘弁してよ。

>>157
メモリと排他制御のロックくらいだけどね。リソース破棄時にエラー返さないのって。
168 ：デフォルトの名無しさん：2011/04/20(水) 12:18:34.44
>>157
> extern "C" から例外もらさないように注意するのは当然な。
> catch (...) しとけば済む。

お前のプログラムからは Unknown error ばっかり飛んできそうだwww
169 ：デフォルトの名無しさん：2011/04/20(水) 12:21:55.06
>>167
> 自分を含め、コードを利用する全ての人が警告&バグに気づきませんでした。
> みたいな状況をまじめに議論するの？勘弁してよ。

そんな議論はしなくていいから、 >>160 の質問に答えてみろ。

> メモリと排他制御のロックくらいだけどね。リソース破棄時にエラー返さないのって。

そう思うんならそれでいいが、 >>157 の主張に量は関係ない。


話題をそらすな。見苦しい。
170 ：デフォルトの名無しさん：2011/04/20(水) 12:31:45.79
>>169
俺は「警告で済まされていたほうが柔軟に対応できて望ましい」と書いた人間では無いが。
少なくとも、再利用性の高いモジュールのようなプログラムを書くときに
何も書かずに警告は無視しない。だからコンパイルエラーでも警告でも関係ない。

それ意外の、ちょっとしたプログラムを書くときは>>162なんじゃないか？

171 ：デフォルトの名無しさん：2011/04/20(水) 12:41:14.73
>>169
> そう思うんならそれでいいが、 >>157 の主張に量は関係ない。

なんで？>>157は
> そして、メモリやそのほか破棄処理がエラーを起こさない多くの
> リソースについてC++の利点は生きる。

って書いてるんだから、量は関係あるだろ。
172 ：デフォルトの名無しさん：2011/04/20(水) 12:51:58.54
>>171
CとC++との比較については「多くの」を飛ばして読んでも同じ事だろ。

「破棄処理がエラーを起こさない」場合が >>157 にとっては多くて、
>>167 にとっては少ないんだろう。そこの違いは作ってるものによる
だろうから、どっちが正しいかを話してもしょうがない。
173 ：デフォルトの名無しさん：2011/04/20(水) 13:02:58.19
>>172
他者が重要と思ってないところを利点として挙げられても、誰も同意できないわけよ。
別に独り言を書き込んでるわけじゃないだろ？
まあ、メモリ管理の単純化は重要だと思うけどね。
174 ：デフォルトの名無しさん：2011/04/20(水) 13:05:08.36
メモリ管理について言えば、C++の参照カウントは便利だけど
Cでもメモリプールを使えば十分すぎるレベルで簡単になる。
メモリプールの実装としてはAPRが有名で誰でも使える。
メモリプールは参照カウントよりも大抵は高速だぞ。循環参照もありだし。
175 ：デフォルトの名無しさん：2011/04/20(水) 13:07:14.50
メモリ管理を自動化せず、プログラム内で自前で管理するのが最速。
メモリの使い回し。
176 ：デフォルトの名無しさん：2011/04/20(水) 13:20:22.78
>>173-175
アプリケーションにとってapr_pool_tが都合がいいならC++でもそれ使えばいいね。
デストラクタで処理できるところがあればさらに楽できるところが増えるよ。


で、 >>153 ってもう居ないの？
177 ：デフォルトの名無しさん：2011/04/20(水) 14:28:54.48
>>176
なんでAPR使ってんのにポータビリティ下げてまでC++？

デストラクタで処理できるところがあればって、
Cのモジュールから抜けるときに apr_pool_destroy() 一回呼ぶだけなんですけど。
# もちろん、場合によってはもっと詳細な制御が出来る。
下手すりゃデストラクタ呼ぶためにapr_pool_tをクラスでラップするほうが手間じゃね？
178 ：デフォルトの名無しさん：2011/04/20(水) 14:34:03.14
C++ プログラマのプロファイル（最新版！）

C のコードを書かせたら、

・性能要求がきつい箇所で strlen() をループの判定部分に入れる
・あれだけ使うなと言われているのに、未だに gets() を使い続ける
・平気で realloc() でメモリをリークさせる
・副作用がある事を意識して使うべきマクロに関数と間違う様な名前を付ける
・厳密な型検査があれば通過しない様なコードを無意識に書く
・警告は無視する（NEW!!)
179 ：デフォルトの名無しさん：2011/04/20(水) 14:35:23.49
枝葉を広げて論点をはぐらかすの飽きた。
180 ：デフォルトの名無しさん：2011/04/20(水) 17:49:38.02
Cで出来ることはC++でも出来る、ただその一点のみでC++を推してるやつは
当然Objective-C++を使ってるんだよな？
お前等の理屈なら、CもC++もObjective-Cも全部出来るObjective-C++を
選ばない理由は無いもんな？
お前等の言ってることはそういうことだぞ？
181 ：デフォルトの名無しさん：2011/04/20(水) 19:59:25.61
>>153 「型エラーは警告でつぶせる」
>>160 「警告は無視される」


会話が成立してねーだろwww
182 ：デフォルトの名無しさん：2011/04/20(水) 20:36:28.74
Cを使ってるとこうなるってことだ
183 ：デフォルトの名無しさん：2011/04/20(水) 21:33:42.45
C++を使ってると物凄い事になるっぽいね
184 ：デフォルトの名無しさん：2011/04/21(木) 01:20:24.38
>153 の人ﾏﾀﾞｰ?
185 ：デフォルトの名無しさん：2011/04/21(木) 01:28:36.57
WARNING!

DO NOT IGNORE THIS MESSAGE!!

DO NOT...

HEY!

HEY, YOU!!

WATCH OUT!!!

PLEASE?
186 ：デフォルトの名無しさん：2011/04/21(木) 01:41:56.82
> 1．Java、C#などの「C/C++」以外は論外。これらについて言及している
> レスは無視してください。

> 6．その他、明らかな煽りや無意味な書き込みも無視でお願いします。
187 ：デフォルトの名無しさん：2011/04/21(木) 01:57:34.58
>>177
> なんでAPR使ってんのにポータビリティ下げてまでC++？
>>152

> ラップするほうが手間じゃね？
そんなときは当然ラップしない。
188 ：187：2011/04/21(木) 01:59:22.36
あー別に >>152 のやつだけじゃなくてもテンプレートでも例外でも、いろいろC++使う理由はあるな。
189 ：デフォルトの名無しさん：2011/04/21(木) 02:02:52.97
C++を使う理由って、警告を無視するプログラマにもキャストを強制出来るとか？
190 ：デフォルトの名無しさん：2011/04/21(木) 02:10:19.53
人のコードで警告が出てるのを見てツッコミを入れるような手間が省けるんなら十分
C++を使う理由になるな。周りのレベルによるんだろうけど。
191 ：デフォルトの名無しさん：2011/04/21(木) 02:12:55.68
子供の集いじゃあるまいし、そんな理由で言語を選びたくないわな。
つか、ホントにそんな状況なんてあるんだろうか。。。
192 ：デフォルトの名無しさん：2011/04/21(木) 04:13:21.44
まず決定権のある立場につかないと
193 ：153：2011/04/21(木) 07:07:53.23
>>184
別に名乗る必要があるとは思えんが、一応>>170>>171>>173>>174>>177は俺だが？

>>187
C++の機能を使わないならC++にする理由が無い。
もし、それでもC++が良いというなら、つまりは>>180ということか？

警告を当然のように無視する腐れプログラマを排除する、
ただそれだけの理由でもCを採用する強力な理由になるな。
それは俺にとってはテンプレートよりもメリットだ>>188。
もちろんテンプレートは便利（コンパイルクソ遅くなるけど）だから、
C++使うならテンプレートも使うけど。
194 ：デフォルトの名無しさん：2011/04/21(木) 11:00:55.59
>>193　(>>153)
>>158 の↓について何も言ってくれてないんだけど、どうなの？
> リソース破棄時のエラーについて、C++で酷いコードになるケースが
> あるのはわかるけど、同じケースに対してはCでも同じことになるでしょ。

あと、Cを使ったからって警告を無視するプログラマを排除するような
効果は無いよね？
195 ：デフォルトの名無しさん：2011/04/21(木) 11:19:05.03
>>193
> 警告を当然のように無視する腐れプログラマを排除する、
> ただそれだけの理由でもCを採用する強力な理由になるな。
Linusは偉大なハッカーだとは思うけど
よりによってこういう非論理的な言説をLinusからパクる必要ないのに…
プログラマの優劣と使用言語は関係ないでしょ

googleはトップクラスのプログラマを大量に雇ってるけど
googleが使ってるのはC++であってCではないよね
まああなたがgoogleのプログラマ達よりずっと優秀だと自負してるんなら
まあご自由に
196 ：194：2011/04/21(木) 11:27:56.65
あ、ごめん。引用したの 158 じゃなくて >>157 だった。
197 ：デフォルトの名無しさん：2011/04/21(木) 12:00:33.62
>>194
try/catchまみれのプログラムは
Cのように戻り値でエラー処理してるプログラムより下手すりゃ読みにくい。
特にfinallyが無いC++の例外処理はな。

それに extern "C" する関数ではエラーを整数や構造体で
表現して返すわけで、それならモジュール内外で
エラーの表現方法をそろえるのも、読み手にはメリットがある。

ああ、もちろんC++でも戻り値でエラー処理できるよ？
でも、エラーは戻り値で処理してると決め撃ちできるのと、
ひょっとしたら例外も飛んでくるかもって思いながら読むのとでは
読みやすさが違うんだ。
198 ：デフォルトの名無しさん：2011/04/21(木) 12:00:48.07
>>194
> あと、Cを使ったからって警告を無視するプログラマを排除するような
> 効果は無いよね？

それ以前にさ、再利用性の高いモジュールを、C/C++のような危険な言語で書くときに
警告を無視するようなプログラマなんか存在しないと言いたいわけよ。
非実在プログラマを排除したっていいだろ？>>195

# >>160は、ちょっと口がすべったんだろう。そう思わせてくれ。
199 ：デフォルトの名無しさん：2011/04/21(木) 12:33:04.36
>>197
> ひょっとしたら例外も飛んでくるかもって思いながら読むのとでは
> 読みやすさが違うんだ。

なるほどね。

PythonなりRubyなりでいつも例外と隣り合わせな俺はもうそこらへん
平気だから気にしないことにする。
200 ：デフォルトの名無しさん：2011/04/21(木) 12:36:10.99
>>198
つまり言語の性質みたいに言っちゃった>>193は間違いなんだね。
これもちょっと口がすべったんだろう。もうそれでいいよ。
201 ：デフォルトの名無しさん：2011/04/21(木) 12:39:52.36
>>199
平気なつもりでバグだらけのコード書いてるんだよねwww
警告無視するしねwww
202 ：デフォルトの名無しさん：2011/04/21(木) 12:41:29.45
C++ PG(>>178)を排除できるなんてCメリットありすぎwwww

203 ：デフォルトの名無しさん：2011/04/21(木) 12:42:31.64
お前等C++ PGはObjective-C++使っとけよwww
204 ：デフォルトの名無しさん：2011/04/21(木) 12:42:37.16
> 理由の無い断定のみ
205 ：デフォルトの名無しさん：2011/04/21(木) 12:52:24.11
発狂中？
206 ：デフォルトの名無しさん：2011/04/21(木) 13:01:46.51
>>150-203 で１ループ終了となります。次の暴論をお待ちください。
207 ：デフォルトの名無しさん：2011/04/21(木) 13:19:11.33
>>199
読みやすさは主観や慣れもあるからな。
俺もPythonは不思議と読みやすいし（何故かRubyはイマイチ……）。
だから、そういう意見もあると思ってくれ。
208 ：デフォルトの名無しさん：2011/04/21(木) 13:22:01.43
>>204
根拠もくそも>>178はお前らC++ PGの発言集だっつのwww
209 ：デフォルトの名無しさん：2011/04/21(木) 13:38:53.13
>>195
Linusの主張(>>3)で唯一根拠が無いのが
「C++は多くの平均以下のプログラマが使ってる」
って点だが、それすら >>160 の反論の
あまりのヘボさによって例示されてしまってる。
210 ：デフォルトの名無しさん：2011/04/21(木) 13:52:11.16
そんなにCとC++の両方に精通した人って少ないのか知らん
211 ：デフォルトの名無しさん：2011/04/21(木) 14:09:30.31
C++のクラスは強力。
スパゲッティコードが、隠された構造をクラス化することで見通しよくなる。
STLなどは初心者には特におすすめ。
212 ：デフォルトの名無しさん：2011/04/21(木) 14:10:56.49
どんな分野も、最初は野心家が切り開き、
優秀な人間が発展させ、ヘボなのも優秀なのも巻き込んで大きくなり、
やがて衰退期に入ると優秀な人間は去っていく。
残るのは新しいものへ適応できない老人かヘボだけだ。

そして今C++は衰退期に入っている。あとは判るな？
213 ：デフォルトの名無しさん：2011/04/21(木) 14:19:59.31
ttp://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
ここ見てもCとC++は2位と3位だし
前年比ではCのほうがC++より低下率高い
これで衰退期とか言われてもなあ
214 ：デフォルトの名無しさん：2011/04/21(木) 14:26:01.42
>>212
具体的な話が出来ず、例え話しかできないってことですか。
215 ：デフォルトの名無しさん：2011/04/21(木) 14:27:29.05
「C++PGは己の馬鹿さも分からない馬鹿である以上C++はC++をできない者の手によってのみ批判されるのだ。」
216 ：デフォルトの名無しさん：2011/04/21(木) 14:28:35.83
長期的な傾向に決まってんだろ？
2001年頃からのグラフを見ろよ
217 ：デフォルトの名無しさん：2011/04/21(木) 14:31:43.50
C++ PGがCをろくに知らないのは読み取れたが
いつC PGがC++を知らないことになったんだ？
218 ：デフォルトの名無しさん：2011/04/21(木) 14:35:37.81
>>214
いつC++ PGが具体的な話したっけ？
あ、警告は無視しちゃうからC++がいいんですよねwww
219 ：デフォルトの名無しさん：2011/04/21(木) 15:25:17.86
>>215
まさに至言

>>195
> プログラマの優劣と使用言語は関係ないでしょ

C PGはOOPが出来ない等の（根拠の無い）定番の煽りが昔からあるけど
いざ自分たちの劣等さを指摘されたら手のひら返しwww
220 ：デフォルトの名無しさん：2011/04/21(木) 15:40:45.00
>>219
大学の教授を小学生が批判出来るとでも？
221 ：デフォルトの名無しさん：2011/04/21(木) 15:44:08.30
C vs. C++ が
C PG vs. C++ PG になってる
222 ：デフォルトの名無しさん：2011/04/21(木) 15:56:40.45
>>220
根拠も無ければ(>>204)具体的でもない(>>214)けど
それがC++ PGの反論なの？
223 ：デフォルトの名無しさん：2011/04/21(木) 16:36:15.89
>>221
C PG vs. C++ PG なんてやりたくないんだ・・・
まさか C++ PG がこんなに低脳揃いだなんて
スレ覗くまで思いもしなかったんだ・・・

でも一度知ってしまったら、もう低脳 C++ PG を
切り捨てるために C を使うのもありだと思えるんだ・・・
224 ：デフォルトの名無しさん：2011/04/21(木) 18:03:43.57
>>185
めっちゃワロタwww
225 ：デフォルトの名無しさん：2011/04/21(木) 18:25:15.53
真っ昼間から論争激しいね
226 ：デフォルトの名無しさん：2011/04/21(木) 21:10:58.61
>>195
現Google開発者のSteve Yeggeによるエッセイ（の日本語訳）
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
227 ：デフォルトの名無しさん：2011/04/21(木) 21:35:13.70
>>226
うわOOP手法を知らない馬鹿が書いてる
5000万行のソースを軽々と扱えるようにするためにクラスがあるのに、それで苦労しているようでは
OOPを理解してないとしか言いようがない
228 ：デフォルトの名無しさん：2011/04/21(木) 22:01:52.13
>>227
>>195にとってはGoogleプログラマは優秀ってことになってるのに
そんなこと言ったら>>195が可哀想だろ？

あとSteve YeggeはRuby on Railsが好きでJVM上で動くRhino on Railsを開発したり、
JavaとPythonでWyvern書いたりしてる、どっちかと言えばOOPが好きなプログラマ。
229 ：デフォルトの名無しさん：2011/04/21(木) 22:08:29.32
OOPを理解していれば5000万行のソースを軽々と扱える
>>227のご高説を賜るスレになりました

では、>>227にすばらしいOOP手法を解説してもらいましょうw
えーと、まずコンパイラの警告は無視するんでしたっけwww
230 ：デフォルトの名無しさん：2011/04/21(木) 22:20:35.72
>>229
本買って自分で勉強しろカス
231 ：デフォルトの名無しさん：2011/04/21(木) 22:56:31.51
OOPに動的型が必須とかC++で例外に行番号載せないとかいう人はなあ。
まあ一人がAならgoogle全体がAと考える人にとってはどうでもいいことか。
232 ：デフォルトの名無しさん：2011/04/21(木) 23:05:45.14
>>231
> まあ一人がAならgoogle全体がAと考える人にとってはどうでもいいことか。

そういうこと言うときは、せめて一人くらいBと考えてる人を示したら？
233 ：デフォルトの名無しさん：2011/04/21(木) 23:12:54.92
>>232
boostだのC++0xだのすら調べない人には何言っても無駄なので負けでいいです。
234 ：デフォルトの名無しさん：2011/04/21(木) 23:20:02.89
>>230
いやいや、そんなこと書いてる本見たことねーんだわwww
お前がアホすぎて自分じゃ解説できないなら、せめて本か論文の名前くらい示せよwww
235 ：デフォルトの名無しさん：2011/04/22(金) 00:46:06.31
>>208
ちがうよ。

>>178は、前スレやこのスレで挙げられたC++によって解消または軽減できる問題の例を
捻じ曲げて寄せ集めて自分でもバカにできるC++プログラマ像に仕立てあげたものだよ。

問題点として挙げてる人が自分でそんなコードを平気で書くわけないし、ましてや複数人が
バラバラに挙げた問題点すべてをすべてのC++プログラマが抱えてるわけでもないって、
普通にちょっと考えればわかるのに。
236 ：デフォルトの名無しさん：2011/04/22(金) 00:51:09.59
ということにしたいのね
237 ：デフォルトの名無しさん：2011/04/22(金) 00:53:53.80
これが Java や C# なら >>178 みたいなリストは最初から作られないんだがな
C++...
238 ：デフォルトの名無しさん：2011/04/22(金) 01:22:42.75
そんなにC++ PGにいじめられたの?
239 ：デフォルトの名無しさん：2011/04/22(金) 01:26:40.70
>>234
どんな本でもいいんだよ
お前がOOP手法を全く理解してない事は良く分かったから
240 ：デフォルトの名無しさん：2011/04/22(金) 01:34:52.57
C++ PG が自己証明したいと望むのは分かる。言語の落ち目だからな。同情するよ。
でも周りからしたらそんなのはどうでも良い事な訳で、イチイチ噛み付いても仕方が無いぜ。
241 ：デフォルトの名無しさん：2011/04/22(金) 07:34:53.25
>>235
> >>178は、前スレやこのスレで挙げられたC++によって解消または軽減できる問題の例を
> 捻じ曲げて寄せ集めて自分でもバカにできるC++プログラマ像に仕立てあげたものだよ。

そんなコードを書かない人間にとっては、そもそも問題にすらならない。
実際Cプログラマはどうでも良い問題だと思ってる。

でもC++プログラマにとっては、解消または軽減すべき問題ってことだろ？
それってC++プログラマがそういうコードを書くってことじゃん。
誰もそんなコードを書かないというなら、何が問題だっていうの？
242 ：デフォルトの名無しさん：2011/04/22(金) 07:37:45.63
>>178のリストの恐ろしいところは、どれか一つ該当するだけでもヤバいところだ
243 ：デフォルトの名無しさん：2011/04/22(金) 08:26:10.60
装備、道具を落とす事。順に難易度が上がる。
アセンブラや、C言語が簡単なやつは無理してC++を使うことはない。
より上級なプログラマといえるだろう。



STL、ブースト(C++ライブラリ)除去
⇒　C++除去(クラスやテンプレートなどの基本構造除去)　
⇒　C:言語除去
⇒　アセンブラ除去
⇒　機械語
244 ：デフォルトの名無しさん：2011/04/22(金) 08:43:14.60
C/C++ : ハードウェアに対してポータブル
アセンブラ/機械語 : レジスタなどを直接弄れる

上と下は明確に守備範囲が違う。
これはプログラマの工夫とかでは埋められない差。

一方、CとC++の差は、シンプルさとか手間とか、そういう
プログラマで埋めることが可能な差。
だから好みが出てくる。
245 ：デフォルトの名無しさん：2011/04/22(金) 08:47:59.16
まだ、昔の手法でやってるのかよ
246 ：デフォルトの名無しさん：2011/04/22(金) 08:58:03.16
C++で開発するのが時代遅れ
LLやVM言語があまりにも遅く>>84の手法が通じなかったころの昔の手法
247 ：デフォルトの名無しさん：2011/04/22(金) 09:02:08.27
そっち方面は堕落しそうだから好きじゃない
248 ：デフォルトの名無しさん：2011/04/22(金) 09:24:21.29
PHPかJavascriptを主流にして、
C言語などに翻訳できると良い。
249 ：デフォルトの名無しさん：2011/04/22(金) 09:38:49.95
C#っぽいシンタックスでCを生成するValaならある
250 ：デフォルトの名無しさん：2011/04/22(金) 10:39:22.41
>>241
>>178 にあるような各種問題のあるコードを書いてしまうプログラマは、
それらの問題について気付いていないプログラマであって、それがCを使うか
C++を使うかで変わったりはしない、そんなプログラマに黙ってCを強制した
だけで問題が回避されることは無い、ってのはさすがにわかるよね？

で、CとC++とで違うのは何かというと、問題に気付きやすいかどうか、
気付いたときに代案となるコードがどういったものになるか、といった点だろう。
251 ：デフォルトの名無しさん：2011/04/22(金) 10:42:36.69
変わんねえよ
252 ：デフォルトの名無しさん：2011/04/22(金) 11:02:19.09
C++の罠は避けられるから大丈夫と言った同じ口で、
>>178は避けられないプログラマがいるというのか
253 ：デフォルトの名無しさん：2011/04/22(金) 11:22:21.02
「C++の罠は避けられるから大丈夫」って何のことだ？
同じ口で「>>178は避けられないプログラマがいる」と言うと矛盾するのか？
254 ：デフォルトの名無しさん：2011/04/22(金) 11:33:20.30
ああ、前スレ読んでるとは限らないか。
前スレでは、C++の文法の罠を指摘すると「自分は慣れてるから」とか
「多少の罠があるくらいは不問」とか言ってスルーしてたんだよ。

仮に同じ口で言ったとした場合、
そうやってC++の罠は避けられるから問題じゃないと言ってきたのに
Cの罠（罠と呼ぶのも馬鹿馬鹿しい）は避けられるから問題じゃない
というのを否定する>>250は、まさにダブルスタンダードじゃないかね？
255 ：デフォルトの名無しさん：2011/04/22(金) 11:47:19.91
>>250
Cの罠はCを使うかC++を使うかで変わらないが
C++の罠はCを使えば絶対にハマらない
256 ：デフォルトの名無しさん：2011/04/22(金) 12:18:57.97
Cが使いこなせて生産性がいいならCだけでいい。
多くの人はCでは効率が悪いのでC++を使う。
上級者はCとアセンブラだけでプログラム。
257 ：デフォルトの名無しさん：2011/04/22(金) 12:21:40.38
>>254
「自分は罠に慣れてる」っていうのと「罠を避けられない（他の）人がいる」っていうのは
矛盾しない気がするな。「C++の文法の罠」ってのが具体的に何なのかもよくわからん。

後で読むから該当レス番もらえるとありがたい。
http://unkar.org/r/tech/1207419469

とりあえず、>>178も「C++の文法の罠」も、どっちも「罠と呼ぶのも馬鹿馬鹿しい」程度の話
なんじゃねーの、って思ってる。
258 ：デフォルトの名無しさん：2011/04/22(金) 13:32:28.34
>>257
罠、で検索してその前後を読んでみた。
例えば >>222>>231>>237>>243>>806 とか？

あと秀逸なのが>>372
259 ：デフォルトの名無しさん：2011/04/22(金) 13:42:25.17
>>257
> 「自分は罠に慣れてる」っていうのと「罠を避けられない（他の）人がいる」っていうのは
> 矛盾しない気がするな。

・自分は罠に慣れている、だから（罠を避けられない人はいるけど）C++の罠は問題にするな
・罠を避けられない人がいる、だから（自分は慣れていても）Cの罠は問題だ

分かるだろ？ダブルスタンダードなのが
260 ：デフォルトの名無しさん：2011/04/22(金) 13:48:12.23
どー考えても>>178とC++の罠を一緒にするのは無理があるwww
>>178なんてプログラマ失格レベルだろうがw
261 ：デフォルトの名無しさん：2011/04/22(金) 14:35:52.41
つーか5000万行のソースって何々だろうなｗ
262 ：デフォルトの名無しさん：2011/04/22(金) 14:38:12.23
＞C++は自分自身のことがわからない。イントロスペクティブでないのだ。
＞Cも同様だが、Cは別に「オブジェクト指向」なわけではない。そして
＞オブジェクト指向であるということの小さからぬ部分は、プログラムが
＞自分自身のことをわかるということなのだ。

これは分かるわー
boost conceptとかで一生懸命何とかしようとしてるのが涙ぐましい
263 ：デフォルトの名無しさん：2011/04/22(金) 15:12:45.30
何故か、しきりにC PGはCとアセンブラだけ使ってる的な書き込みがあるが、
全然そんなことないから。本当は>>84で、いらない子はC++だけだから。
264 ：デフォルトの名無しさん：2011/04/22(金) 15:25:14.51
>>263
×いらない子はC++だけだから。
○C++を使えないプログラマが未だに多すぎるから、ひがみです。
265 ：デフォルトの名無しさん：2011/04/22(金) 16:42:53.71
クラスとか要らないの?
266 ：デフォルトの名無しさん：2011/04/22(金) 16:51:51.74
>>265
まず自分からC++のクラスが必要な理由を書けよ

当然、LLやVM言語でOOPして遅いとこだけCで書くのと比べて
C++でOOPするメリットもな

ちゃんと説明できたら納得してやるから
267 ：デフォルトの名無しさん：2011/04/22(金) 17:12:42.32
CUDAやDirectXなんかと無縁な人を説得する人は無理でしょうよ。
268 ：デフォルトの名無しさん：2011/04/22(金) 17:28:40.64
>>267
そういうのは説明じゃねーんだよ
じゃあCUDAやDirectXでいーや、それ使うときのメリット言えよ
別に無縁じゃねーから心配すんな
269 ：デフォルトの名無しさん：2011/04/22(金) 17:31:28.61
やったことあるなら自明でしょう
270 ：デフォルトの名無しさん：2011/04/22(金) 17:34:25.36
いちからか？
いちからいわなきゃだめか？
271 ：デフォルトの名無しさん：2011/04/22(金) 17:44:38.84
CUDAなんて、基本的にはGPU側にメモリ確保して、
メインメモリの内容転送して、カーネル関数側でglobal/sharedメモリに転送されたデータをコピーして、
並列度の高い(四則)演算して、計算結果のデータをメインメモリに転送して、
メインメモリ側でデータを読み取る、たったこれだけだぞ？
どこにOOPの余地があるんだよ。知ったかぶるなよアホか？
272 ：デフォルトの名無しさん：2011/04/22(金) 18:17:31.35
そうだね、生ポインタを直で持ったり、forループをせこせこ書いたり、
配列もサイズもその変数の役割も全て無視してdouble*で扱うのが好きな人はC++に全く魅力を感じないだろうね。
273 ：デフォルトの名無しさん：2011/04/22(金) 18:25:17.08
>>271
お前にOOPの知識が皆無だという事はよく分かった
274 ：デフォルトの名無しさん：2011/04/22(金) 18:30:06.93
C++はほとんどCのプログラムを書く事も出来れば、Better Cとして書く事も出来れば、
C++そのもののプログラムも書くことが出来るマルチパラダイム言語。

言いたい事は分かるよな？懐が広いんだよC++は。
275 ：デフォルトの名無しさん：2011/04/22(金) 19:20:33.65
GCと動的型付けをやりたい
マルチパラダイムなら出来るよな？
276 ：デフォルトの名無しさん：2011/04/22(金) 19:22:22.73
前スレからC PGに病的な子が居るのはなんとかならんか
C++ PGがわざとやってるのか？
277 ：デフォルトの名無しさん：2011/04/22(金) 20:19:50.63
>>272
CUDAは基本float
そんなことも知らないお前はCUDAの知識ゼロ

>>273
根拠も無ければ(>>204)具体的でもない(>>214)な
どうしてそう言えるのか説明してみろよ
278 ：デフォルトの名無しさん：2011/04/22(金) 20:22:59.44
>>273
OOPの知識があれば5000万行のコードを軽々扱えるんだよなwww
279 ：デフォルトの名無しさん：2011/04/22(金) 21:01:04.92
>>274
Objective-C++はほとんどCのプログラムを書く事も出来れば、Objective-Cとして書く事も出来れば、
C++そのもののプログラムも書くことが出来るマルチパラダイム言語。

言いたい事は分かるよな？頭が悪いんだよC++ PGは。
280 ：デフォルトの名無しさん：2011/04/22(金) 21:05:06.86
>>266に答えられるやつ誰もおらんの？
281 ：デフォルトの名無しさん：2011/04/22(金) 21:07:16.35
>>279
その理屈で行くとObjective-C++ PGも頭が悪い事になるな
自己紹介乙
282 ：デフォルトの名無しさん：2011/04/22(金) 21:15:32.82
>>281
>>180のように>>274を皮肉ってんだろ
283 ：デフォルトの名無しさん：2011/04/22(金) 22:06:22.61
マジで>>266に答えられるやつ一人もいないの？
284 ：デフォルトの名無しさん：2011/04/22(金) 22:07:01.22
>>280
266はC++のクラスがOOP用だって言う変な前提があるからな。
個人的には記述が短くなるのでPODの構造体よりはクラスの方が好きではあるけれど
継承は最小限しか行わないで委譲でまかなうべきだと思ってる。

関数のオーバーロードやテンプレート等のC++にあってCにはない機能もOOPとは直接関係ないし
266のようにC++をOOPでしか語れない人っていうのは頭悪そうだよな。

LLだけれど、動的な型を用いるせいで大きなプログラムを書くとバグが発生しやすい
とか遅いとかリソース食うとか色んな欠点があるわけでC++の方がマシなケースもあるよね。
パフォーマンスが必要な部分が全体に及んでることもあるのになぜ一部だと断定できるんだろう。
数年前にtwitterの人がRubyからScalaに置き換えるとかいってたのもそういうことでしょう。
285 ：デフォルトの名無しさん：2011/04/22(金) 22:08:38.27
酢豚はトンカツとして食べる事が出来る、
と言いながらパイナップルを食わそうとする
286 ：266：2011/04/22(金) 22:26:20.16
>>284

そういう話を聞きたかった
別にC++をOOP専用だと思ってるわけじゃない。個人的には
テンプレート使った静的ポリモーフィズムは嫌いじゃないし

> 数年前にtwitterの人がRubyからScalaに置き換えるとかいってたのもそういうことでしょう。

RORは動的なのが大事なフレームワークなので、単純に遅いところをCで書き直すという
手法が通じなかったんだろう。そういうこともある
置き換え対象もまたVM言語なのはあれだが
287 ：266：2011/04/22(金) 22:43:25.03
> パフォーマンスが必要な部分が全体に及んでることもあるのになぜ一部だと断定できるんだろう。

あとさ、>>84のアプローチに対してCとC++のどちらが向いてるか、そういう話をしてたんだろ？
問題の前提をいきなり覆すのってどうなんだ。まあいいけどよ
288 ：デフォルトの名無しさん：2011/04/22(金) 22:46:50.67
一人芝居？
289 ：266：2011/04/22(金) 22:48:59.44
あり得ない仮定を置いたり、問題設定をころころ変更したり
論争に勝つのが目的じゃあるまいし、もっと誠実に議論しようぜ
290 ：デフォルトの名無しさん：2011/04/22(金) 22:50:01.64
>そういう話を聞きたかった
キリッ

>論争に勝つのが目的じゃあるまいし、もっと誠実に議論しようぜ
キリリッ

そこまでいうなら266はトリ付けてよ
291 ：デフォルトの名無しさん：2011/04/22(金) 22:54:25.54
5000万行のコードを軽々扱えちゃうとか、恥ずかしげもなく言えちゃうんだよ？
このスレの C++ PG なんてアホばっかりなんだから
誠実な議論なんてできるわけないじゃんね
292 ：デフォルトの名無しさん：2011/04/22(金) 22:58:24.11
>>284
こいつ全然C++のメリットについて具体的なこと言ってないからな。
C++固有の機能については名前を挙げてるだけだし、
LL批判にいたっては、型チェックとかリソース不足とかって
それ全部Cでも改善できることだろ。

293 ：デフォルトの名無しさん：2011/04/22(金) 23:00:53.84
>>291
顔真っ赤ですよ
余程悔しかったのかな？
294 ：デフォルトの名無しさん：2011/04/22(金) 23:08:42.31
>>284
>>数年前にtwitterの人がRubyからScalaに置き換えるとかいってたのもそういうことでしょう。

Rubyが遅いだけの話をLL全体の批判に転嫁すんなって
295 ：デフォルトの名無しさん：2011/04/22(金) 23:08:47.81
百の説明より一のコーディングだからなあ。
C++やってライブラリ一通り使ってみてその結論に達したんでしょ、
なら掲示板で話して意味のあることはないねえ。

まあ、例えばCのコードとC++のコード出して比べてC++のここがダメだとか言ってくれれば、
それに対して色々コメントは出来るけどね。
296 ：デフォルトの名無しさん：2011/04/22(金) 23:19:08.81
Cにはシンプルな構文、高い人気(>>150)、ポータビリティ、
STLより高性能な準標準ライブラリ(>>132)というメリットが示されてる。

C++がCへの優位性を示したければ、CではダメなコードがC++だと改善される、というのを具体的に示すべき。
そうじゃなければ人気でもポータビリティでも劣るC++を選ぶ理由が無いから。　
297 ：デフォルトの名無しさん：2011/04/22(金) 23:23:24.75
CのほうがObjective-Cから呼びやすいから好き
C++はObjective-Cと混ぜるの面倒くさい
298 ：デフォルトの名無しさん：2011/04/22(金) 23:27:35.28
>>296は芸風がつまらん
もう少し盛り上げてよ
299 ：デフォルトの名無しさん：2011/04/22(金) 23:30:48.45
そーだそーだ
>>160>>227を見習え
300 ：デフォルトの名無しさん：2011/04/23(土) 00:04:30.73
そうそう、とてつもないギャグを言うスレだここはｗ
301 ：デフォルトの名無しさん：2011/04/23(土) 00:25:13.29
>>295
短いコードでC++の特徴示すの難しいよ。

#include "iostream"

class X {
public:
X & operator= (const X &x) { return *this; }
operator bool() { return true; }
};

X operator *(const X &x, const X &y) { return y; }

int main()
{
X a, b, c;
if (a * b = c) {
std::cout << "True\n";
} else {
std::cout << "False\n";
}
return 0;
}

さて、True か False かどっち？
302 ：デフォルトの名無しさん：2011/04/23(土) 00:41:51.89
>>301

もしかして
　if (a * b = c) {
は
　if (a * b == c) {
って事？

でも False になるような事はなさそうな。。。
303 ：デフォルトの名無しさん：2011/04/23(土) 00:44:02.12
ゲーム制作メンバーを募集しています。

http://yuzuru.2ch.net/test/read.cgi/ff/1298538064/l50
http://www31.atwiki.jp/fftsukurou/

・最近のFFが嫌い
・昔のFFが好き

どちらかに当てはまれば誰でも結構です。
昔ながらのFFをみんなで作りましょう。
304 ：デフォルトの名無しさん：2011/04/23(土) 01:04:44.72
>>302
いや、もとのコードでOK。

こんな短いコードでも a * b = c みたいな式が書けてしまう、それがC++。
305 ：デフォルトの名無しさん：2011/04/23(土) 01:12:42.14
ああ、operator bool() { return false; }
にするつもりだったのに、間違えた。orz
a * b = c と a * b == c で結果変えたかったのに。

306 ：デフォルトの名無しさん：2011/04/23(土) 02:28:25.80
>>301
そんなcopyと言う名前でjoinする関数書くようなやつは土に埋めてしまえ。
307 ：デフォルトの名無しさん：2011/04/23(土) 02:49:04.58
>>306
> そんなcopyと言う名前でjoinする関数書くようなやつは土に埋めてしまえ。

全然ポイント外してる。理解できてない
308 ：デフォルトの名無しさん：2011/04/23(土) 03:09:50.12
この流れで>>301をC++の特徴と申すか
309 ：デフォルトの名無しさん：2011/04/23(土) 03:12:06.13
IOC++CCが開催できるからダメなんだと
310 ：デフォルトの名無しさん：2011/04/23(土) 03:31:33.85
しかし、確かにCは空気も読まずに
>>301みたいなのを書いちゃう
馬鹿避けにはなるのか
311 ：デフォルトの名無しさん：2011/04/23(土) 03:41:34.59
>>301は何の難読化テクニックも施してない普通のC++コードだが、
それでもキモい式が書けてしまうのはC++が必要以上に複雑だから。

そして、ぱっと見て挙動が理解できないC++ PGは全員ろくに
言語仕様も理解せずにC++書いてる低能だから反省しろ。
312 ：デフォルトの名無しさん：2011/04/23(土) 03:49:13.94
積の戻り値の一時オブジェクトに代入してる時点ですでに普通のC++コードではない。
これで意味のあるコードならば、積を積として使っていないか、代入を代入として使っていないか、或いはその両方だろう。
313 ：デフォルトの名無しさん：2011/04/23(土) 03:56:02.39
>>312
> 積の戻り値の一時オブジェクトに代入してる時点ですでに普通のC++コードではない

普通にC++のクラスを定義しただけで、そんな普通じゃない式がコンパイルエラーにも
警告にもならないってのを問題にしてるんだが、理解できないかね？
314 ：デフォルトの名無しさん：2011/04/23(土) 04:00:04.85
「何の難読化テクニックも施してない普通のC++コード」じゃなかったん。
315 ：デフォルトの名無しさん：2011/04/23(土) 04:01:43.09
そうだよ？実際 a * b = c の式以外で不自然な点はあるか？
316 ：デフォルトの名無しさん：2011/04/23(土) 04:43:54.75
んー、ぱっと見て難読化テクニックを施したか単なるtypoかどちらかだとすぐに分かるコードをぱっと見て
C++PGが挙動を理解出来ないことに憤る>>311は不自然だあね。
317 ：デフォルトの名無しさん：2011/04/23(土) 08:34:18.79
operatorオーバーライドを使わなきゃいい話
318 ：デフォルトの名無しさん：2011/04/23(土) 12:46:04.07
C++も悪いけど書き手が馬鹿なだけじゃねえの？
319 ：デフォルトの名無しさん：2011/04/23(土) 12:49:56.45
>>318
お前が馬鹿なんだろ
320 ：デフォルトの名無しさん：2011/04/23(土) 12:51:05.74
ほらね
321 ：デフォルトの名無しさん：2011/04/23(土) 13:02:46.49
C言語→JavaへいったからC++はほとんどわからん。
C++ってJavaと比べてどうなの？
322 ：デフォルトの名無しさん：2011/04/23(土) 13:08:47.00
>>321
Java はオブジェクト指向に沿ってコーディングする感じだけど、
C++ はオブジェクト指向は使っても良いかなって感じ（マルチパラダイム）

Java は分かり易さとか明確さを重視するけど、
C++ はそういうのを気にしてない感じ

Java の言語仕様はコンパイラに優しいけど、
C++ はパーサが苦労して頑張ってる感じ
323 ：デフォルトの名無しさん：2011/04/23(土) 13:18:42.02
>>322
やっぱり作る側も相当技術必要っぽいね。
CとJavaは結構やってるけど、C++も始めようかなあ。
仕事では出番ないんだけどね
324 ：デフォルトの名無しさん：2011/04/23(土) 13:48:28.41
>>320
悔しそうですね
325 ：デフォルトの名無しさん：2011/04/23(土) 14:24:07.36
ろくに言語仕様も理解できない低能と一緒に仕事？まったく冗談じゃないよ
やはりC++ PGを排除するためにCはありだな。いまどき進んでC++やってるのはカス過ぎる
326 ：デフォルトの名無しさん：2011/04/23(土) 14:28:41.43
>>325
と、単にC++を理解出来ないだけのカスが申しております
327 ：デフォルトの名無しさん：2011/04/23(土) 14:30:58.64
>>317
C++で演算子オーバーロードを極力使わないのは同意だが
何やってるのか理解できないのは問題だろ
それじゃSTLすら読めないじゃん
え、まさか自分が利用するライブラリのコードすら読めなくていいと思ってんの？
328 ：デフォルトの名無しさん：2011/04/23(土) 14:48:11.61
>>327
C++標準委員会の人が一般プログラマは
ライブラリのソースを読む必要が無いとか言ってたぞ。
329 ：デフォルトの名無しさん：2011/04/23(土) 15:30:59.81
で、クラスとか要らないの?
330 ：デフォルトの名無しさん：2011/04/23(土) 16:01:23.54
>>328
標準委員会にライブラリ読まなくていいとか言われちゃう時点で
C++のヤバさに気付け
ていうか、他人にコード読まなくていいって言われたら素直に従うのかよ
さすが仕様もコードも読まないC++ PGだな
331 ：デフォルトの名無しさん：2011/04/23(土) 16:19:29.63
>>329
クラスを使ったコードはC++ PGには読めなかったようだけど？
332 ：デフォルトの名無しさん：2011/04/23(土) 16:30:11.35
なんで話題を C++ PG vs C PG 側に持っていくの？
プログラマの能力が言語の選択でどうにかなるわけないだろ。
言語を比較しろよ。
333 ：デフォルトの名無しさん：2011/04/23(土) 16:36:10.85
C++のメリットが分からないのはプログラマが理解できないからだ、とか
すぐプログラマの能力の問題に持ってくのはC++ PG側だけどね
実際はC PGより全然理解できてないわけだけどwww
334 ：デフォルトの名無しさん：2011/04/23(土) 17:20:49.53
よっぽどC++ PGに苛められたんだなあ
335 ：デフォルトの名無しさん：2011/04/23(土) 17:34:06.26
C++についてすらC++ PGより詳しいのに
どうやったら苛められるんだろう？
336 ：デフォルトの名無しさん：2011/04/23(土) 17:40:11.14
>>335
どうして詳しいって分かるんだろう？
自画自賛ですか？
ずいぶんナルシストですね
337 ：デフォルトの名無しさん：2011/04/23(土) 17:41:57.00
C++ PGは言語仕様すら把握してないからじゃね？
>>301を見てIOC++CCとか言ってる馬鹿がいて笑ったよ
338 ：デフォルトの名無しさん：2011/04/23(土) 19:25:14.65
うわあリアルで不幸そう
339 ：デフォルトの名無しさん：2011/04/24(日) 02:06:17.60
>>330
ライブラリのソースを読まないといけないのかw
はげるぞ。
340 ：デフォルトの名無しさん：2011/04/24(日) 03:14:42.94
>>330
>ていうか、他人にコード読まなくていいって言われたら素直に従うのかよ
もろちん。
>さすが仕様もコードも読まないC++ PGだな
仕様書に基づいて呼び出しのコードを書くのが筋。
ライブラリのソースを見て呼び出しプログラムを書くCプログラマーは
仕様に従うという文化を持たないバカ共。
341 ：デフォルトの名無しさん：2011/04/24(日) 03:35:24.94
必要な情報が全て仕様書に記述されていて、それがひとつのバグも無く実装されていて、
何の副作用も無く使えると信じきれるなんて、C++ PG は幸せなんだあ
342 ：デフォルトの名無しさん：2011/04/24(日) 03:50:08.28
>>341
車輪の再生産に無限の価値を未だに信じている時代遅れの馬鹿発見
343 ：デフォルトの名無しさん：2011/04/24(日) 03:55:32.06
え、駄輪？
344 ：デフォルトの名無しさん：2011/04/24(日) 04:02:54.27
>>342
？

車輪の生産とは一切関係無いんだが
345 ：デフォルトの名無しさん：2011/04/24(日) 04:28:40.14
C++ PG は debug する時にライブラリのバグは疑わないの?
仕様書にそう書いてあるから問題無いんだ（ｷﾘｯ　ってな感じ?
346 ：デフォルトの名無しさん：2011/04/24(日) 04:32:14.26
人の所為にしたいから、そんなの気にしてないのでは？
347 ：デフォルトの名無しさん：2011/04/24(日) 04:32:23.68
341とか345は使用者が副作用まで考えて
使わなきゃいけないライブラリを書くのか。
とりあえず仕事では間に合わんから使えんな。

>>344
ググれ。
348 ：デフォルトの名無しさん：2011/04/24(日) 04:37:22.61
>>347
ググるとかじゃなくて、基礎部品の再実装とは関係無い話だと言っているのだが。

所詮は他人が作った部品を、心の底から信じきれる C++ PG は幸せなんだろうな。
349 ：デフォルトの名無しさん：2011/04/24(日) 05:18:30.60
>>348
347じゃないけれどSTLなどの標準ライブラリのバグなら経験上ググると高確率で見つかるよね
もともとSTLのソースの話だったのに、勝手に基礎部品と言い換えて話を拡大して
反論するのはおかしいですよ、日本語読めないんですか？
350 ：デフォルトの名無しさん：2011/04/24(日) 05:19:13.19
>>348
君はシステムコールとかAPIをいちいち逆アセンブルしてるのか
351 ：デフォルトの名無しさん：2011/04/24(日) 05:30:02.58
>>349
車輪の話だ。

>>350
気になったらソースコードを読んでますよ。
OS は Mac も Linux も *BSD も Solaris もソースコードが公開されています。
公開されていない物に関しては、残念ですが仕方が無いですね。
352 ：デフォルトの名無しさん：2011/04/24(日) 05:47:03.79
C++ PG ってホントにライブラリのソースコードは一切読まないの?
それはそれで凄いねw
353 ：デフォルトの名無しさん：2011/04/24(日) 09:20:17.62
>>340
> 仕様書に基づいて呼び出しのコードを書くのが筋

そう思うなら、せめて使う言語の仕様くらいちゃんと把握してろwww
354 ：デフォルトの名無しさん：2011/04/24(日) 10:16:01.78
だからoperatorなんて使わないんだよ
355 ：デフォルトの名無しさん：2011/04/24(日) 10:19:41.67
万が一使うときはそのときグローバルとメンバのどっちが優先されるか
試せば良いだろ？
君はあれか？TVの仕組みとかケータイの内部規格とか、そういうの
も予め使う前に(作る前ではない)知らべちゃうのか？
356 ：デフォルトの名無しさん：2011/04/24(日) 10:24:23.91
言語仕様もライブラリも読まずバグったときはググるwwww
357 ：デフォルトの名無しさん：2011/04/24(日) 11:51:18.03
実装が一つじゃない場合に仕様を統一してそれに従うのであって
再実装を否定するなら仕様書もいらないよ
マニュアルを書くなら、下手に形式ばらない方が読みやすい
358 ：デフォルトの名無しさん：2011/04/24(日) 14:36:22.06
ここのC PGは狭い自分の世界が
世の中の標準だと思ってるな
359 ：デフォルトの名無しさん：2011/04/24(日) 14:43:51.00
一人でしょ。暴れてるのは。
360 ：デフォルトの名無しさん：2011/04/24(日) 14:47:24.10
ここの C++ PG の世界は、全ての仕様は完全完璧で、それが厳重厳格に守られており、
全ての実装は無瑕無疵を誇っているらしいから、とっても羨ましいや・・・
361 ：デフォルトの名無しさん：2011/04/24(日) 14:49:04.53

C++ Committee : 「お前らソースなんて読むなよ」

C++ PG : 「はーい！　読みませんとも！」
362 ：デフォルトの名無しさん：2011/04/24(日) 15:07:46.04
いつからプログラマがソースコード読まないのが
世の中の標準になったんだよw
363 ：デフォルトの名無しさん：2011/04/24(日) 15:19:54.34
書いて終わりの人が増えてるから
364 ：デフォルトの名無しさん：2011/04/24(日) 15:34:14.09
まぁ、俺も C++ のコードなんて読みたくないしな
365 ：デフォルトの名無しさん：2011/04/24(日) 15:36:25.22
デバッグって言葉は死語？
366 ：デフォルトの名無しさん：2011/04/24(日) 16:53:43.14
>>362
ライブラリにバグがあるよりも自分のコードにバグがある確率の方が圧倒的に多い
だいたいライブラリなんか読んでいたら時間が足りない
367 ：デフォルトの名無しさん：2011/04/24(日) 16:55:58.43
デバッグは　確率だけじゃ　進まない
368 ：デフォルトの名無しさん：2011/04/24(日) 17:24:22.76
>>367
自分の書いたコードをデバッグするんだよ？
意味分かってないだろ？
369 ：デフォルトの名無しさん：2011/04/24(日) 17:29:32.82
>>366
> だいたいライブラリなんか読んでいたら時間が足りない

そういう台詞はライブラリを読めるようになってから言えよw
370 ：デフォルトの名無しさん：2011/04/24(日) 17:29:36.83
>>368
君、>>367 の意味が分かってないでしょ。
371 ：デフォルトの名無しさん：2011/04/24(日) 17:29:53.08
暴れてる子コテハン付けてくれないかなあ
372 ：デフォルトの名無しさん：2011/04/24(日) 17:30:54.41
名乗らなくても直ぐ分かるから良い
仕様もコードも読まない子
373 ：デフォルトの名無しさん：2011/04/24(日) 17:38:30.64
仕様読むとかコード読むとか、 C も C++ もまるで関係ない話にしか思えんのだが、
なんでこんなに長々とここで言い争ってるの？
374 ：デフォルトの名無しさん：2011/04/24(日) 17:42:07.93
>>373
仕様読んだりコード読んだりするのは、言語に関係無く当たり前の話だよな。
375 ：デフォルトの名無しさん：2011/04/24(日) 17:53:52.75
>>373
仕事してないニート暇人ばかりだから
376 ：デフォルトの名無しさん：2011/04/24(日) 17:59:39.79
C PG : 「言語仕様がシンプルとか、ソースコードがシンプルとか大事だよね？」

C++ PG : 「それは C PG がヘボだから。クラス、オーバーロード、テンプレート必要！」

C PG : 「じゃあ簡単なコード(>>301)読んでみてよ」

C++ PG : 「は？そんなの読めるわけないだろ！IOC++CC かよ！」

C PG : 「これ読めなきゃ STL とかのライブラリ読めないよね？」

C++ PG : 「ライブラリなんて読まなくていい！標準委員会も読まなくていいと言ってる！仕様書が読めればいい！」

C PG : 「でも言語仕様書は読んでないよね？」

C++ PG : 「言語仕様書も読まなくていい！困ったらググるから！」 << いまここ
377 ：デフォルトの名無しさん：2011/04/24(日) 18:08:40.28
C PG : 「でも俺たち仕事してないもんな！ただの趣味でガヤガヤ言ってるだけだし」

C++ PR : 「そうだよな俺たちがいくらこのスレでわめいても全く説得力ないもんな」
378 ：デフォルトの名無しさん：2011/04/24(日) 18:20:05.96
>>375>>377
悔しいの？顔真っ赤だよ？
379 ：デフォルトの名無しさん：2011/04/24(日) 18:22:09.36
>>378
自己紹介乙
380 ：デフォルトの名無しさん：2011/04/24(日) 18:26:28.38
そろそろこのスレにもようかんマンが必要だな
381 ：デフォルトの名無しさん：2011/04/24(日) 18:36:11.17
>>345
バグを疑わないといけないようなライブラリしか無いのはかわいそうだな。
自分のバグなのに「ライブラリのバグだ！」って騒ぐ人もいるけど。。
382 ：デフォルトの名無しさん：2011/04/24(日) 18:49:54.00
>>356
大抵誰かが同じ問題にぶち当たってるからなー。
既にパッチが出てるのに自分で解析するのは無駄じゃね？
383 ：デフォルトの名無しさん：2011/04/24(日) 18:57:28.14
>>381
ライブラリのバグに遭遇した事が無い人は幸せだなあ。
384 ：デフォルトの名無しさん：2011/04/24(日) 19:02:32.06
>>382
スタックをダンプして、問題発生箇所でソースコードを grep した方が早い場合も多いよ
使うのは有名ライブラリばかりじゃないからね
385 ：デフォルトの名無しさん：2011/04/24(日) 19:12:11.70
>>1
俺だったらバグだらけの無名ライブラリしか使えないようなものは選ばないな。
選択権が無い場合は仕方ないが。。
386 ：デフォルトの名無しさん：2011/04/24(日) 19:29:34.15
ライブラリにバグが無い事を仮定して仕事が出来るなんて羨ましいですね
387 ：デフォルトの名無しさん：2011/04/24(日) 19:31:33.44
仮定できないようなライブラリは仕事では使えないわ。
388 ：デフォルトの名無しさん：2011/04/24(日) 19:33:42.44
デバッグもテストも何の為にするんだろうな。
389 ：デフォルトの名無しさん：2011/04/24(日) 19:53:29.58
俺の使うライブラリにバグなど無い、バグなど無いわあ！
390 ：デフォルトの名無しさん：2011/04/24(日) 21:40:17.40
ライブラリにバグが無いとは思わないけど、
Cプログラマーはライブラリのソース追わないとライブラリの
バグなのかどうか判断つかないの？
ライブラリの挙動が仕様に従っていなくて暇だったらライブラリの
ソースを追うけど、最初からソース追う気満々なのは嫌だ
391 ：デフォルトの名無しさん：2011/04/24(日) 21:52:27.87
そんな話は誰もしてないけど?
392 ：デフォルトの名無しさん：2011/04/24(日) 21:59:25.09
ソースコードを読むのが嫌で嫌で仕方が無い人間がプログラムを書く物かね・・・
393 ：デフォルトの名無しさん：2011/04/24(日) 22:01:17.46
あのdinkumwareのヘッダファイルはツールで整形してあるらしく
改行が変な場所にあって読みにくいったらありゃしない
394 ：デフォルトの名無しさん：2011/04/24(日) 22:23:47.15
>>392
もっと他に読むコードがあるものでね。
395 ：デフォルトの名無しさん：2011/04/24(日) 22:30:49.10
仕様書の無いソースは読む気にならんな。価値ゼロのゴミ。
そのプログラムが何をするものなのか、どうなれば正しいのか
定義も不明なまま処理を追うのは苦痛以外の何物でもない。
396 ：デフォルトの名無しさん：2011/04/24(日) 23:06:50.89
何でそんな事してるの?
397 ：デフォルトの名無しさん：2011/04/24(日) 23:15:06.65
>>392
時間は無限じゃないんだよ？
ライブラリのソースコードなんて解析してたら10年ほど掛かるんじゃね？
398 ：デフォルトの名無しさん：2011/04/24(日) 23:18:50.14
>>397
何で無目的に全てのライブラリを読もうとしてるの?
399 ：デフォルトの名無しさん：2011/04/24(日) 23:21:29.86
>>386のような事を言う馬鹿がいるもんでさ
400 ：デフォルトの名無しさん：2011/04/24(日) 23:22:43.48
それは普通に考えて、バグがあったら該当のソースコードを読むという話じゃないの?
何で全部のソースコードを読む必要があるの?
401 ：デフォルトの名無しさん：2011/04/24(日) 23:24:29.29
>>394
普段はどんなコードを読んでいるの?
402 ：デフォルトの名無しさん：2011/04/24(日) 23:29:23.47
>>400
俺がいつ「全部のソースコードを読む必要がある」と言った？
403 ：デフォルトの名無しさん：2011/04/24(日) 23:31:28.33
ソースコード貼ると盛り上がるねw
オペレータは自分では定義しないし、使ったソースは読まないと言われたので、今度はそれを使わない例。

#include <iostream>

namespace X
{
template <typename T>
void print(T) { std::cout << "X\n"; }

template <typename T>
void print_2(T x) { print(x); print(x); }
}

namespace Y
{
struct D {};
void print(D) { std::cout << "Y\n"; }
}

int main()
{
Y::D a;
X::print_2(a);
return 0;
}

何て出力されるかな？
404 ：デフォルトの名無しさん：2011/04/24(日) 23:33:20.70
>>402
常識的に考えて、全部のソースコードを読むんでなければ10年も掛からないから
405 ：デフォルトの名無しさん：2011/04/24(日) 23:35:04.37
>>404
つまりは貴方の勝手な解釈なわけですね
常識とは貴方だけに通用する常識である事をお忘れなく
406 ：デフォルトの名無しさん：2011/04/24(日) 23:35:27.70
マクロでもやれよｗ
407 ：デフォルトの名無しさん：2011/04/24(日) 23:36:32.02
>>405
それでは、10年間も何のソースコードを読むつもりだったの?
答えは貴方の常識の範疇で良いよ
408 ：デフォルトの名無しさん：2011/04/24(日) 23:40:52.63
>>407
貴方に答える義理はありません
409 ：デフォルトの名無しさん：2011/04/24(日) 23:43:06.05
>>408
じゃあそれで良いよ。

常識的に言って、ライブラリのソースコードを一切読まないプログラマなんて居ないよねえ。
410 ：デフォルトの名無しさん：2011/04/24(日) 23:50:33.04
お好きなように解釈なさってください。寝ます。
411 ：デフォルトの名無しさん：2011/04/25(月) 00:01:16.62
>>406
C/C++のマクロって見た目汚くなるだけで、意外と非直感的な結果って出せないんだよね。
所詮やってることは文字列置換だから。
412 ：デフォルトの名無しさん：2011/04/25(月) 00:06:29.78
>>403
Y
Y
で合ってる？
413 ：デフォルトの名無しさん：2011/04/25(月) 00:16:47.74
>>412
合ってる。
>>403は個人的にC++で嫌いな振る舞いのひとつ。
名前空間とはなんだったのか。
414 ：デフォルトの名無しさん：2011/04/25(月) 00:24:33.15
テンプレートなんか使うから悪いんだよ
415 ：デフォルトの名無しさん：2011/04/25(月) 00:37:45.58
ADLを真面目に考えると頭がおかしくなる
416 ：デフォルトの名無しさん：2011/04/25(月) 02:54:14.96
>>413
テンプレートをマクロと同様のものだと思ってるなら不用意に省略とかしないので
void print_2(T x) { X::print(x); X::print(x); }
と書くと思う。要するにただのバグだから嫌いな振る舞いするのは当たり前。
417 ：デフォルトの名無しさん：2011/04/25(月) 03:04:55.24
>>416 ADL による名前空間汚染は問題として確かにある。さすがに「当たり前」は無理だ。
418 ：デフォルトの名無しさん：2011/04/25(月) 03:20:58.67
void print(T) { std::cout << "X\n"; }　と'std::'で修飾してる直ぐ下の関数で
void print_2(T x) { print(x); print(x); } と'X::'つけないでprint呼んでるんだから
頭おかしい人が書いたようにしか見えない。動作考えるとか以前に第一印象がバグ。
419 ：デフォルトの名無しさん：2011/04/25(月) 03:26:03.20
>>418 print 使う前に print の宣言があるだろ。そいつが呼び出したいと読めてしまうのはしょうがない。
420 ：デフォルトの名無しさん：2011/04/25(月) 06:53:26.04
>>416>>418
名前空間は一種のスコープであり、かつ同一の名前空間の中では
X::というスコープ演算子を省略できるというルールがある以上、
同じ名前空間にあるほうの print が呼ばれると思うのが自然。

あとマクロと一緒にするのは間違い。マクロは名前空間とは違う
「名前空間」（ああややこしい）に属するから。実際マクロには
X::のようなスコープ演算子を付けることは出来ない。
421 ：デフォルトの名無しさん：2011/04/25(月) 07:29:55.11
Koeningのlookupだっけ。
仕様がおかしいと主張するC使いにたいして
仕様通りだと答えるコミュニケーション能力の無いC++使い。
422 ：デフォルトの名無しさん：2011/04/25(月) 07:40:46.06
>>418
std::cout は外側の名前空間にアクセスしてるんだから'std::'が付いて当たり前
付けなきゃエラーだ
423 ：デフォルトの名無しさん：2011/04/25(月) 07:46:18.88
また増税？ふざけんな谷ガキ！
まず、防衛費ゼロ、
防衛省や自衛隊組織解散、
高給公務員の所得規制
からだろ
424 ：デフォルトの名無しさん：2011/04/25(月) 08:35:05.60
>>418
C++やってると頭おかしくなるんだね
こいつアホすぎ
425 ：デフォルトの名無しさん：2011/04/25(月) 12:20:07.35
ADLはC++ PGの脳を破壊するのか・・・
426 ：デフォルトの名無しさん：2011/04/25(月) 13:27:11.46
>>301のときはライブラリのソース読まないって面白発言が
飛び出したけど、今回はどんなギャグを披露してくれるかな？
427 ：デフォルトの名無しさん：2011/04/25(月) 14:10:12.86
ライブラリのソースが公開されてない場合は？
428 ：デフォルトの名無しさん：2011/04/25(月) 14:21:47.21
スレ違いだ。やめろ。
429 ：デフォルトの名無しさん：2011/04/25(月) 14:43:17.70
>>418
同じ名前空間でも一切修飾を省略しないつもりかよ。
それじゃCみたいにprefix付けて区別するのと変わらないだろ。
むしろ付け忘れたらコンパイルエラーになる分Cの方がマシだわ。
430 ：デフォルトの名無しさん：2011/04/25(月) 17:06:22.11
オカシナ例しか挙がらんな、ツマラン。
431 ：デフォルトの名無しさん：2011/04/25(月) 17:58:34.34
都合の悪い例は全部オカシイということにしたいんですね、わかります
432 ：デフォルトの名無しさん：2011/04/25(月) 19:13:45.23
C++から都合の悪い機能を取り除くより
都合の良い機能だけCに付け加える方がいい
433 ：デフォルトの名無しさん：2011/04/25(月) 19:28:28.73
>>432
それがC99でありDなわけだが
流行ったかどうかはご存じの通り
434 ：デフォルトの名無しさん：2011/04/25(月) 19:53:01.57
DirectXとかでCOMは流行ったな
435 ：デフォルトの名無しさん：2011/04/25(月) 19:59:52.94
>>433
徐々にC99も使われだしてきてる
K&RスタイルからANSIスタイルへ移り変わるのにも時間がかかったし
こういうのは移行期間が長くかかるというだけ

あとDさんをdisるのはスレ違い
436 ：デフォルトの名無しさん：2011/04/25(月) 20:11:18.20
Dはどっちかというと奇麗なC++を目指してたと思う
Cを置き換えられるのはやっぱりC(99,1X)だけだな
437 ：デフォルトの名無しさん：2011/04/25(月) 20:40:20.97
Google Code Search で Makefile 内のコンパイラオプションを調べてみた

ANSI(-ansi)
http://www.google.com/codesearch?hl=ja&lr=&q=%22+-ansi%22+file%3AMakefile

C89(-std=c89 or -std=gnu89)
http://www.google.com/codesearch?hl=ja&lr=&q=%22+-std%3Dc89%22+file%3AMakefile
http://www.google.com/codesearch?hl=ja&lr=&q=%22+-std%3Dgnu89%22+file%3AMakefile

C99(-std=c99 or -std=gnu99)
http://www.google.com/codesearch?hl=ja&lr=&q=%22+-std%3Dc99%22+file%3AMakefile
http://www.google.com/codesearch?hl=ja&lr=&q=%22+-std%3Dgnu99%22+file%3AMakefile

今の時点では約4割がC99だね
不人気と言われ続けてるC99だけど、意外に使われている
438 ：デフォルトの名無しさん：2011/04/25(月) 20:44:57.36
>>435
C99に完全準拠したコンパイラはありますかね？
Intel C++もgccもライブラリで完全準拠してないし、今のCをC99で置き換えるほどの
メリットが感じられない

むしろ今元気があるのはObjective-C

http://journal.mycom.co.jp/news/2011/04/19/016/index.html

C99なんて文字列はどこにも見当たりませんが( ´ー｀)y-~~
439 ：デフォルトの名無しさん：2011/04/25(月) 20:46:38.16
>>437
こんな状態じゃC99とは言えませんって
ほとんどgcc独自拡張と考えられている

http://gcc.gnu.org/c99status.html
440 ：デフォルトの名無しさん：2011/04/25(月) 20:50:30.02
鶏が先か卵が先か
って感じでしょ
441 ：デフォルトの名無しさん：2011/04/25(月) 20:52:43.92
>>439
C99で欲しい機能はほぼ実装されてるんだけど、そのリストの中で未実装で困る機能ある？

あと、言語仕様に完全準拠したコンパイラが必要条件とするなら
C++なんて全然使えないだろ。
442 ：デフォルトの名無しさん：2011/04/25(月) 20:55:38.05
>>441
あっそ
じゃせいぜいC99を使ってて下さい
うちの会社じゃのけ者にされるだけなんで
443 ：デフォルトの名無しさん：2011/04/25(月) 20:56:55.54
規格通りじゃないから、使えないと言いたいとか？
444 ：デフォルトの名無しさん：2011/04/25(月) 21:01:39.09
>>438
> C99なんて文字列はどこにも見当たりませんが( ´ー｀)y-~~

その手のリストでCをC89とC99に分類して表示するわけないだろ。
PythonだってRubyだってバージョン毎に分かれてない。
ばかじゃねーの？
445 ：デフォルトの名無しさん：2011/04/25(月) 21:01:44.81
お前頭悪いだろ
大きなプロジェクトは複数人でプログラムするだろ
一人だけC99使っててみろ
どうなるか位わかるだろ
446 ：デフォルトの名無しさん：2011/04/25(月) 21:08:04.32
うわぁ、すごい馬鹿が来た。
複数人が参加するプロジェクトで自分勝手に言語選ぶわけないだろ。
C99を使うかどうかは協議して決めるにきまってる。
コンパイラがあるなら移行自体に技術的障壁は無い。
447 ：デフォルトの名無しさん：2011/04/25(月) 21:11:09.37
>C99を使うかどうかは協議して決めるにきまってる。

はい、協議の結果C99は却下間違いありません
448 ：デフォルトの名無しさん：2011/04/25(月) 21:25:10.43
プロジェクトで C99 を使う事が決まると、自動的に >>442 の会社は除外される訳か
449 ：デフォルトの名無しさん：2011/04/25(月) 21:50:46.13
なんだただの屁理屈屋か
放置しよ
450 ：デフォルトの名無しさん：2011/04/25(月) 22:23:13.68
２０世紀末に
//
でコメント出来るのを知らなかったところがあったな
規格とかうるさくなかった時代だけど、
妙に昔の実装に固執してたような感じっだ、
いわんや、中身が...
451 ：デフォルトの名無しさん：2011/04/25(月) 22:29:05.22
>>437
C99 は全く流行ってないから C++ を better C として使うべき
っていうのが C++ 派の心の拠り所だったのに・・・
452 ：デフォルトの名無しさん：2011/04/25(月) 23:14:52.84
で、クラスくらい使うだろ。
453 ：デフォルトの名無しさん：2011/04/25(月) 23:29:03.75
窓s系はclassベースだから、知らないうちに使ってるんじゃないの？
454 ：デフォルトの名無しさん：2011/04/25(月) 23:47:47.23
C99はクラスないから大規模開発の時に地獄見るよ
455 ：デフォルトの名無しさん：2011/04/25(月) 23:48:57.84
腕があれば、言語選ばんだろうに
456 ：デフォルトの名無しさん：2011/04/25(月) 23:50:15.53
と、腕無し脳無しが申しております
457 ：デフォルトの名無しさん：2011/04/25(月) 23:53:30.61
書き方に隠蔽された処理が読みにくいのでC++はあんまり好きじゃないな
慣れれば、読めるんだろうけど
458 ：デフォルトの名無しさん：2011/04/26(火) 06:37:39.89
>>452>>454
再利用性という観点からは、データ構造とアルゴリズムは分離したほうが良いのは自明で、
実際C++もtemplateでそっち方面に進んでいるが
なんで昔はクラスでデータ構造とアルゴリズムを結合するのが流行ったのかね？
データとアルゴリズムが強く結びついてる所為で
クラスライブラリAとクラスライブラリBを混ぜてつかうとか、本当に難しくなったのだが
459 ：デフォルトの名無しさん：2011/04/26(火) 07:18:35.53
そのレスどっかで見たな・・・
460 ：デフォルトの名無しさん：2011/04/26(火) 09:17:07.56
メインループAとメインループBを混ぜてつかうのが難しいのは
結合のせいじゃなくて内部イテレータのせいだ
461 ：デフォルトの名無しさん：2011/04/26(火) 11:44:51.49
クラスはバカなPGにバカなことをさせないための檻であり鎖
囚人は自分を縛る鎖の出来を自慢する
462 ：デフォルトの名無しさん：2011/04/26(火) 11:53:19.57
>>461
えらい皮肉だな
463 ：デフォルトの名無しさん：2011/04/26(火) 12:47:29.00
>>458
アルゴリズムが再利用可能であるためには、データはアイテレータなどの共通インタフェースを持つ必要がある。
データを保持するクラスが持つべきはアルゴリズムじゃない。インタフェースだよ。
464 ：デフォルトの名無しさん：2011/04/26(火) 13:00:46.85
>>463
STL以前の初期のオブジェクト指向だとそういう分離が考えられてなかったよね
って話じゃないの。
465 ：デフォルトの名無しさん：2011/04/26(火) 13:07:43.96
>>463
その目的だとしても、総称型のほうがクラスより向いてるという話でしょう。継承しなくていいから。
インターフェースを呼び出す構文としても、obj.f() と f(obj) で本質的に変わらない。
いや、むしろメソッドは第一引数に bind される分だけ
複数の引数を取るインターフェースが自然に書けない。
466 ：デフォルトの名無しさん：2011/04/26(火) 13:21:39.40
STLはオブジェクト指向とはかなり異なるアプローチだな

但しコンテナを作るためにバリバリにクラスを使いまくっているけど
templateもSTLを作るために入れられたって話だし

templateの存在がC++を著しく理解困難にしているのは確かだが
これにより得られた物も極めて多い
467 ：デフォルトの名無しさん：2011/04/26(火) 14:03:37.72
STL作者の A. Stepanov はOOPが嫌い

http://www.stlport.org/resources/StepanovUSA.html
468 ：デフォルトの名無しさん：2011/04/26(火) 15:03:27.57
良くも悪くもクラスって何にでも使えるよね
469 ：デフォルトの名無しさん：2011/04/26(火) 17:02:26.72
クラスは劣化名前空間、劣化クロージャ、劣化総称型として使えるからな
470 ：デフォルトの名無しさん：2011/04/26(火) 17:35:39.33
>>469
何だよその劣化って
どうしてもクラスをけなしたいのか
471 ：デフォルトの名無しさん：2011/04/26(火) 18:03:19.38
>>470
事実だから
472 ：デフォルトの名無しさん：2011/04/26(火) 18:13:30.90
>>471
お前の中ではな
お前の中「だけ」ではな
473 ：デフォルトの名無しさん：2011/04/26(火) 18:35:07.49
名前空間：スコープの制御が柔軟にできる
クロージャ：環境のcapture機能あり
総称型：ルートオブジェクトを継承したりする必要なし

こんな感じか？
クラスはクラス、専用構文には流石に敵わんよ
474 ：デフォルトの名無しさん：2011/04/26(火) 18:38:31.72
全く存在目的が異なる物を比較してどうなると言うのか
それは劣化と言えるのか
475 ：デフォルトの名無しさん：2011/04/26(火) 19:08:50.05
>>466
＞templateもSTLを作るために入れられたって話だし
どこで聞いたんだ、そんなデマ。。。
歴史的におかしいぞ。
476 ：デフォルトの名無しさん：2011/04/26(火) 19:10:42.53
>>469
クロージャがあればクラスが要らないというのはよくある勘違い。

クロージャをクラスに見立てようとすると、メソッドディスパッチを自前で実装しなくてはいけない。
一生懸命実装したとしても、コンパイラの支援を受けられないから当然遅くなる。
シンタックスも冗長になるし、何も良い事無い。
477 ：デフォルトの名無しさん：2011/04/26(火) 19:18:34.10
>>469
名前空間は引数にして渡したり、メッセージを受け取ったり出来ないじゃん。
部分的にクラスの代用になるというだけだから、名前空間自体が劣化クラスという見方もできちゃうよ?
478 ：デフォルトの名無しさん：2011/04/26(火) 19:25:01.41
>>475
D&E位読めカス
479 ：デフォルトの名無しさん：2011/04/26(火) 20:58:27.31
このようにC++信者はクラスの存在意義一つ取ってもコンセンサスが形成できない酷い有様です。
480 ：デフォルトの名無しさん：2011/04/26(火) 21:04:03.67
クラスで他の構文を模倣しようとしてもその構文に敵わないし、
逆に他の構文でクラスを模倣しようとしてもクラスに敵わない。
それはその通り。

問題は、クラスの機能は模倣する価値があるのかってこと。
例えばクロージャと高階関数があるのに単一メソッドディスパッチなんて必要か？とか。
481 ：デフォルトの名無しさん：2011/04/26(火) 21:18:20.64
class も closure も higher order function もある Smalltalk がこの世を統べるべき

つまり、そう言いたい訳だな?
482 ：デフォルトの名無しさん：2011/04/26(火) 21:43:59.28
>>479
と、クラスの意味を全く知らないC信者が吠えております
483 ：デフォルトの名無しさん：2011/04/26(火) 21:54:52.14
>>482
クラスの意味は知ってるよ？>>461でしょ？
囚人の境遇に慣れすぎると、鎖に繋がれていない自由人を嘲笑さえするらしいね？
484 ：デフォルトの名無しさん：2011/04/26(火) 21:57:15.06
暴れてるC信者は何がしたいの？
485 ：デフォルトの名無しさん：2011/04/26(火) 22:18:56.02
>>484
仲間に入りたいならいつでもこっちに来いよ
486 ：デフォルトの名無しさん：2011/04/26(火) 22:21:08.27
クラスは欲しいけど継承は微妙
487 ：デフォルトの名無しさん：2011/04/26(火) 22:33:56.87
>>483
馬鹿だなあ・・・・
488 ：デフォルトの名無しさん：2011/04/26(火) 22:34:51.07
継承がないと仮想関数の存在理由がなくなるっしょ
それとも禁断のif文の羅列にする？
489 ：デフォルトの名無しさん：2011/04/26(火) 22:37:47.40
継承しないなら構造体でいいよ
490 ：デフォルトの名無しさん：2011/04/26(火) 22:42:34.23
構造体だと self が参照出来ないからクラスが欲しい・・・・
491 ：デフォルトの名無しさん：2011/04/26(火) 23:01:21.29
>>488
インターフェイスだけあれば良い
492 ：デフォルトの名無しさん：2011/04/26(火) 23:24:20.44
インタフェースとしても使えるんだから問題ないじゃん。
493 ：デフォルトの名無しさん：2011/04/26(火) 23:27:32.39
C++を知らない癖に偉そうにC++を知ったかぶりでしたり顔で語ってるアホが多いな
494 ：デフォルトの名無しさん：2011/04/26(火) 23:29:57.57
恐れ多くも C++ を知ってるなんて言えるお方は、世界広しと言えども、あのお方、ただ一人だけ

かの君を差し置いて、自分が C++ を知ってる等と思ってる奴は不届き千万
495 ：デフォルトの名無しさん：2011/04/26(火) 23:30:28.23
C++を批判する人々は全てC++を知らないことにしたいんですね、わかります
496 ：デフォルトの名無しさん：2011/04/26(火) 23:35:26.75
C++ を知らない奴が批判しているという事にしてしまえば、傷口が浅い様に見えるからな
497 ：デフォルトの名無しさん：2011/04/26(火) 23:37:55.11
なんだやっぱり図星か
顔を真っ赤にしてファビョってる様子が目に見えるようですよ
498 ：デフォルトの名無しさん：2011/04/26(火) 23:40:21.47
おい、図星らしいぞ
499 ：デフォルトの名無しさん：2011/04/26(火) 23:51:34.03
おいおい、>>301で C++ PG が言語仕様を把握してないのバレたばっかりだろ。
しかもSTL含むC++ライブラリ一切読まないとか恥ずかしい主張してたろ。
それで自分はC++知ってますとか、恥ずかしくないの？
500 ：デフォルトの名無しさん：2011/04/26(火) 23:55:34.46
君はC++使うバカがひとりいたからC++使う人はみんなバカであると言うのかい？
501 ：デフォルトの名無しさん：2011/04/27(水) 00:00:02.69
何でバカとか言うん?

わざわざそういう言葉を選ぶ理由が分からん・・・
502 ：デフォルトの名無しさん：2011/04/27(水) 00:21:18.18
前スレから荒して楽しんでるだけじゃん
503 ：デフォルトの名無しさん：2011/04/27(水) 00:24:57.96
C++を批判するコメントは全部荒らしなんですね、わかります
504 ：デフォルトの名無しさん：2011/04/27(水) 00:29:51.61
団子と同じ臭いがして気持ち悪い
505 ：デフォルトの名無しさん：2011/04/27(水) 00:37:23.02
ただの構ってちゃん荒らしだから相手をしなければコメ止まるよ
506 ：デフォルトの名無しさん：2011/04/27(水) 01:10:27.26
しかしC++を擁護するまともな発言が無いからなぁ
大規模開発にはC++が必要だ！みたいな決め付けばかりで
507 ：デフォルトの名無しさん：2011/04/27(水) 01:12:09.73
C99へのFUDとかね
508 ：デフォルトの名無しさん：2011/04/27(水) 01:46:27.49
C++覚えたのは10年以上前だが今でも全部はわからないよ。言語仕様を細かく把握するとか時間の無駄。
http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms 程度が理解できれば十分使える。

大規模開発には>>506は不要!
509 ：デフォルトの名無しさん：2011/04/27(水) 02:03:41.64
バグ取りにどれだけの時間の差が生じるのか実際に経験した事がないのか
お前本職じゃないだろ
510 ：デフォルトの名無しさん：2011/04/27(水) 02:16:04.31
C/C++のメリットを語れという流れなのに、罵倒のみを返す>>508が怖い
511 ：デフォルトの名無しさん：2011/04/27(水) 07:13:16.10
C++でプラグインを追加できるアプリケーションを書くとき、STLを引数に渡すなといわれるけど、
C++ Coding Standards―101のルールとかには、
組込み型でも期待するサイズを明記することって書いてあった。

これって、Cで本体とプラグインを同じシステム上でコンパイルしても、コンパイラやオプションが
違うだけで、例えばlongのサイズが変わるってこと?
512 ：デフォルトの名無しさん：2011/04/27(水) 07:15:20.11
これだと、結局CでもABIは不在で、プラグイン作成者にコンパイラとコンパイルオプションを
教えなくてはいけないの? たとえ、本体が商用アプリケーションでも。
513 ：デフォルトの名無しさん：2011/04/27(水) 09:03:02.37
同じコンパイラで 32bit と 64bit の実行ファイルを作ったときに
long やポインタのサイズが変わるけど、そういうことがいいたいの？
そりゃ当たり前でしょう
514 ：デフォルトの名無しさん：2011/04/27(水) 09:19:54.30
>>506
作るものによってはC++の機能がないとツライってのは確かにあるでしょ。
前スレでも出てたけど。
http://warp.povusers.org/programming/cplusplus_superior_to_c.html
515 ：デフォルトの名無しさん：2011/04/27(水) 09:33:31.84
>>512
ABIは存在するけどABIには型がない
問題はABIの有無ではなく、型がないというのを許容できるかどうか
516 ：511：2011/04/27(水) 09:35:27.14
>>513
例えば、同じ64bit OS上でもコンパイラやコンパイルオプションで型のサイズが
変わるなら(大小関係は規格で決まっていても)、アプリケーションとプラグインで
データの受渡し時に不具合が出るのはないかと心配しています。

Cでもこういうことが起こるならCにはABIがあるって言えるのかと疑問に感じました。
517 ：デフォルトの名無しさん：2011/04/27(水) 09:35:49.31
>>515 そこまでいくとこのスレで問題にする話じゃないだろう。
518 ：デフォルトの名無しさん：2011/04/27(水) 09:38:04.18
>>516 http://ja.wikipedia.org/wiki/Application_Binary_Interface
519 ：511：2011/04/27(水) 09:41:15.54
あ、かぶった。

>>515
なるほど。ABIは型(およびそのサイズ)とは関係ないということですね。
そうすると、やはりプラグインシステムは本体のコンパイル環境(コンパイラやそのバージョン、コンパイルオプション)と
常に同じにしなくてはならないということですね。
520 ：デフォルトの名無しさん：2011/04/27(水) 10:25:29.32
>>519
どんな環境を想定してるか分からないから答えようが無いよ
環境を完全に限定しないなら>>515
WindowsやLinuxなら 32bit/64bit をそろえたらOK
521 ：デフォルトの名無しさん：2011/04/27(水) 12:18:10.58
>>514
「C++が必要なんだよ、わかるだろ？」的な仄めかしはもう良いよ
522 ：デフォルトの名無しさん：2011/04/27(水) 12:30:22.45
>>521
仄めかしじゃなくてそのとおりのことを言っているんだけど、わかんないの？
>>514のリンク先の例でCとC++が選択肢にあるときに、Cを選ぶ合理的な理由を挙げられるのか？
523 ：デフォルトの名無しさん：2011/04/27(水) 12:43:07.79
>>522
平明で読みやすいが記述が冗長なCと、簡潔に記述できるが可読性に難があるC++

プログラムは書くより読む方が難しく、また読む時間の方が長いという性質がある以上
Cを選ぶことだってある
524 ：デフォルトの名無しさん：2011/04/27(水) 12:45:52.31
前スレより

> 753:デフォルトの名無しさん [ sage ] 2011/03/22(火) 08:18:09.61
> >>752
> エラーの処理については、C++例外を使った方が可読性が低い、とこのスレで議論されてる。
>
> 初期化と解放については、そんなものが本当にプログラミングにおいて重要な問題なのか疑問だ。
> C++では例外がある上にfinallyが無いから解放はややこしい問題たりえるが、Cでは全然難しくない。
>
> 標準で便利なコンテナが提供されていないのはCの欠点だ、というのは認めざるを得ないね。
> GLibとかの実装があるし、リストくらいなら自分で簡単に実装できるから不便は感じないけど、標準であるのは便利だ。

> 最後に、全体的な主張である（と思われる）Cで書くと冗長であるという点については、
> その代わりがC++の漏れのある抽象化というならごめん被る。
525 ：デフォルトの名無しさん：2011/04/27(水) 12:54:05.48
C++よりもCを選ぶ理由は、PerlよりもPythonを選ぶ理由に似ている
Perlならこんなに短く書けるよ！CPANもあるし！とか言われても
ふーんとしか思わずPython使い続ける感覚
526 ：「初心者なのにエラそうだな]」(笑)劣等種憤死wwwwwww：2011/04/27(水) 13:03:16.68
http://hibari.2ch.net/test/read.cgi/win/1298974733/420
http://hibari.2ch.net/test/read.cgi/win/1298974733/420
http://hibari.2ch.net/test/read.cgi/win/1298974733/420

↑負け組・初心者に固執してたホモ精神障害者ってコイツぐらいだろｗｗｗｗ自爆乙ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ



IＰ変えててもバレバレのマヌケ乙ｗｗｗｗおいおい中途半端に自治気取ってんぞｗｗｗｗ
荒らしもしてねえのにバレる馬鹿ってコイツぐらいのもんだろｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
上級者自慢とかｗｗｗｗｗ情けねぇデブだなｗｗｗｗリアルでもやってそうｗｗｗｗｗ必死チェッカー見ながらニヤつくキモヲタｗｗｗ
頭悪すぎて勝手にファビョってることにしちゃってんだろうなｗ思考停止の典型ｗｗｗｗｗ
だから必死こいて顔面沸騰させてレスストップｗｗｗｸｯｿﾜﾛﾀｗｗｗｗ
知能低いから出る発言は突っ込み所しかない朝鮮人ぶりｗｗｗｗおもしれーーーｗｗｗｗ
知障レスもわざわざ読んでやる俺に感謝しろよ知的障害者ｗｗｗｗｗｗｗｗｗ
残念なのは顔だけにしとけよホモｗｗｗｗｗＦｉｒｅｆｏｘと初心者に劣等感抱いてる基地外ｗｗｗｗｗｗｗｗｗ
「「「エラそう」」」なんて言葉をすぐに口にする時点でコンプバレバレの自己紹介だなｗｗｗｗｗｗｗｗｗ
普通わかんねえなら黙ってるもんなんだがなｗ白痴のプライド()に突き動かされてんだろなｗｗｗｗ「「「勘違い自称上級者」」」の社交性コンプででちゃった哀れな雑魚ｗｗｗｗｗｗ

527 ：デフォルトの名無しさん：2011/04/27(水) 18:10:34.84
C++にABIが無いからABI自体あっても無駄って
暴れてたのがいたのか

>>523
読みやすさに価値を見出すのはソースコード読むPGだけ
528 ：デフォルトの名無しさん：2011/04/27(水) 20:11:47.47
>>514
C++ は Fortran の置き換えでも狙ってるの?
行列演算なんてニッチな分野で比較されてもなあ

科学技術計算を超高速化したいんじゃなきゃ Java で良い訳だし、
実際ウェブの世界ではそうなってる
529 ：デフォルトの名無しさん：2011/04/27(水) 20:30:02.00
>>519
そりゃそうでしょ。
実際のことを考えたら、ABIだけではなく、
ランタイムライブラリもあわせる必要が
あるんだから。
530 ：デフォルトの名無しさん：2011/04/27(水) 20:39:44.19
>>528
高速性や省リソースなどが必要な
要件はまだまだ存在する。
ただ、規模や管理の面で、Cは機能
不足だという状況もある。

Webの世界がどうあろうと、関係がない。
要するに、別世界だから。
531 ：デフォルトの名無しさん：2011/04/27(水) 20:47:20.29
>>530
そういうのは科学技術計算と金融計算くらいじゃないの
もちろんそういう案件がゼロでは無いと思うけど、わざわざ取り上げる程の物かねえ
532 ：デフォルトの名無しさん：2011/04/27(水) 21:04:03.80
ゲームもCじゃきついな
533 ：デフォルトの名無しさん：2011/04/27(水) 21:26:15.96
コンソールゲームと PC 用のゲームは C/C++ だろうけど、それ以外は・・・
534 ：デフォルトの名無しさん：2011/04/27(水) 22:23:19.22
>>531
そんなこと言ってたら、
Cの出番って、コンパイラが整備されてないマイコンくらいになっちゃうし。
535 ：デフォルトの名無しさん：2011/04/27(水) 22:24:26.27
そんなことないよ?
536 ：デフォルトの名無しさん：2011/04/27(水) 22:30:23.15
若いころはweb-cgiをCで開発するとかバカなことをやってたなぁ。
537 ：デフォルトの名無しさん：2011/04/27(水) 23:26:13.46
>>530
科学技術計算？Fortranじゃないならrestrictで最適化が効くC99一択だけど。
もちろん最適化効かさない部分をC++で書く人もいるけど、そこはC++である必要は無くて、
実際にPython(numpy)とかRからC関数呼ぶ形式で使ってる人が多い。
538 ：デフォルトの名無しさん：2011/04/27(水) 23:31:31.50
VS2010には__restrictがあるので抜け目はなかった

しかし最大の問題はFortranと行と列が逆な事だろ
どうやってMATLAB呼ぶの？
539 ：デフォルトの名無しさん：2011/04/27(水) 23:38:47.94
LAPACKは行と列がどちらの並び優先でも使えるインターフェースがある。
CLAPACKはf2cでFortranをCへ変換してる所為か、CでFortran形式の行列を作って
渡した方が遅かった。
MATLABからはC/Fortranを呼べるけど、何か問題が？
540 ：デフォルトの名無しさん：2011/04/27(水) 23:40:05.29
BOOSTが何とかしてるんじゃないの
541 ：デフォルトの名無しさん：2011/04/27(水) 23:48:18.64
C/C++から使うのならGSLが良さそうだな
BoostのuBLASも出来映えはいまいちだし
542 ：デフォルトの名無しさん：2011/04/27(水) 23:54:15.11
GSLみたいなライブラリはCで書かれてる
543 ：デフォルトの名無しさん：2011/04/28(木) 01:16:33.25
>>523
Cが「平明で読みやすい」っていうけどさ、Cの「冗長さ」の中には
関数の呼び出し深度に比例して増えるエラーチェックの if や
関数脱出パスの数に比例して増えるリソース解放処理（への正しい分岐）
なんかが含まれるわけよ。

明示的に記述されたそういったコードが間違っている可能性もあるわけで、
そんなコードをたくさん読まされることを考えると、一概にCなら可読性が高いとか
一概にC++の機能（例外やデストラクタ）が可読性を損ねているとか言い切れる
ものじゃないと思うんだ。

どう思う？

例えばデストラクタなんか使わずに明示的に破棄処理を書くべきだというのなら、
同じ理由でCの自動変数についてもスタックの上げ下げを明示的に書くべき
なんてことも言い出しそうな気がするんだけど、そんなソースでスタックの上げ下げが
正しく行われているかおびえながらソース読む、なんて考えられないでしょ。
544 ：デフォルトの名無しさん：2011/04/28(木) 01:22:50.08
>>543
>関数の呼び出し深度に比例して増えるエラーチェックの if や

エラーチェックは関数の呼び出しと同じレベルでネストするから、
調査する範囲は局地的で、問題になり様が無いんだけど。

具体的にどういうコードを想定してるの?
545 ：デフォルトの名無しさん：2011/04/28(木) 01:23:49.75
スタックの上げ下げは失敗しないから
546 ：デフォルトの名無しさん：2011/04/28(木) 01:29:42.85
>>544 こんなの、とか？
int source_of_error(...);

int foo(...)
{
// ...
int e = source_of_error()
if (e != 0) return e;
// ...
}

int bar(...)
{
// ...
if (foo() == 0) return -1;
// ...
}

int baz(...)
{
// ...
if (bar()) return BAZ_ERROR_A;
// ...
}

int error_handler()
{
// ...
if (baz() != BAZ_OK)
// ...
// ...
}
547 ：デフォルトの名無しさん：2011/04/28(木) 01:39:35.19
>>546
それ、各ネストレベルできちんと意味のあるエラーを返していれば問題無いよね?

関数の返り値なんてデバッガでも簡単に追えるし。
548 ：デフォルトの名無しさん：2011/04/28(木) 01:51:12.32
>>547
こういう場合（もちろんもっとネストが深い場合含めて）のエラー通知に例外を使えば
if 文（の間違いの可能性）が減るし、デストラクタがあれば途中 return での
リソース漏れ（の心配）もなくなって、それらによって可読性が上がるとも言えるでしょ、
って話。

コードに問題が有るとか無いとかいう話じゃないし、デバッガで追うとかいう話でもない。
549 ：デフォルトの名無しさん：2011/04/28(木) 01:52:34.43
>>546
ふつうに読みやすいと思った
550 ：デフォルトの名無しさん：2011/04/28(木) 01:54:43.79
>>549 bar() がバグってるのには気付いたかい？
551 ：デフォルトの名無しさん：2011/04/28(木) 02:01:05.91
もちろん。バグってるかどうか局所的に判断できるし読みやすい
552 ：デフォルトの名無しさん：2011/04/28(木) 02:17:23.99
ネストが深い所で起きた例外って、結局は無視するか、適当なエラーメッセージを出して
異常終了するかのどちらかな気が・・・
553 ：デフォルトの名無しさん：2011/04/28(木) 02:20:32.89
>>552
同じ問題を示すエラーの通知方法が例外かそうじゃないかで処理方法が変わるとでもいうのかい？
554 ：デフォルトの名無しさん：2011/04/28(木) 02:25:35.08
>>553
それが変わらないから、『ネストが深くなった時』という問題設定自体がおかしいと思うんだよね。
そもそも何でそんなにネストするんだって話。
555 ：デフォルトの名無しさん：2011/04/28(木) 02:30:34.49
またまた、ご冗談を。
556 ：デフォルトの名無しさん：2011/04/28(木) 02:35:16.10
君に冗談を言う義理は無いよ
557 ：デフォルトの名無しさん：2011/04/28(木) 02:36:06.60
おやすみ～
558 ：デフォルトの名無しさん：2011/04/28(木) 02:36:08.87
Cでifを使う場合と比較するなら、C++版でもcatchするべき
C++版がcatchしないなら、C版はexitを使っていい
559 ：デフォルトの名無しさん：2011/04/28(木) 03:04:39.10
せめてlongjmpしてくれよ。
560 ：デフォルトの名無しさん：2011/04/28(木) 03:18:59.11
>>546からは source_of_error() のエラー/例外は致命的で
あらゆる処理を中断して error_handler() で対処するって仕様が見て取れるけど、
そういう「コンテクストに一切依存しない source_of_error() のエラー処理」は
source_of_error() 関数内でやるのが一番読みやすいよ
もしプログラム毎にエラー処理を差し替えたいなら extern な関数でも内部で呼べば良い
561 ：デフォルトの名無しさん：2011/04/28(木) 03:25:09.83
次に、>>546のような深いネストがどうしても必要な場合
仮に例外で処理するなら error_handler() で catch するだろう
そうすると途中の関数は例外処理がいらないから(デストラクタで処理できるリソースだけ使ってる場合は)簡単になるけど
error_handler() を読むのが凄く難しくなる
深いネストを潜って source_of_error() まで到達する必要があるからね
562 ：デフォルトの名無しさん：2011/04/28(木) 04:02:44.08
例外は綺麗なgotoと呼ばれることもあるが
関数/メソッドのスコープを超える大域ジャンプなことには変わりないぜ
563 ：デフォルトの名無しさん：2011/04/28(木) 04:19:39.52
>>561
> error_handler() を読むのが凄く難しくなる
> 深いネストを潜って source_of_error() まで到達する必要があるからね

何のためにそんなことする必要があるの？
564 ：デフォルトの名無しさん：2011/04/28(木) 04:34:28.47
>>563
ソースコードのどこで（つまりどんな状況で）エラーが起こったのか知らずにエラー処理できるの？

別の言い方をすれば、いつ・どこでエラーが起こったかによらずエラー処理できる場合に
>>560のようにしてはダメな理由は？
565 ：デフォルトの名無しさん：2011/04/28(木) 04:46:08.38
>>564
例外使ったこと無いの？
もともと >>560 のような動作も含めて柔軟にエラー処理ができるように
考えられた言語機能が例外なんだよ。

必要な情報は例外オブジェクトに詰めて投げればいいんだ。

それに、その理由で source_of_error() まで見に行くって言うことだと、
戻り値でも同じことする必要があるんじゃないの？
566 ：デフォルトの名無しさん：2011/04/28(木) 04:50:30.05
> 必要な情報は例外オブジェクトに詰めて投げればいいんだ。

source_of_error() の中で必要な情報が詰められるなら、
>>560のように処理してダメな理由は？
567 ：デフォルトの名無しさん：2011/04/28(木) 05:05:37.08
>>566
マ板で散々議論した結果をみれば？
568 ：デフォルトの名無しさん：2011/04/28(木) 05:18:02.81
>>567
見てきたよ。むこうでも揉めて結論出てなかった
少なくとも>>566の疑問には答えてなかったよ
569 ：デフォルトの名無しさん：2011/04/28(木) 05:53:47.48
>>565
> それに、その理由で source_of_error() まで見に行くって言うことだと、
> 戻り値でも同じことする必要があるんじゃないの？

戻り値は return 探してさかのぼれば良いから読みやすいよ
570 ：デフォルトの名無しさん：2011/04/28(木) 09:20:40.77
デバッガでスタック遡れば良いだけとも言えるのでは？
571 ：デフォルトの名無しさん：2011/04/28(木) 09:50:50.18
>>566
へ？ >>560 に書いてあるのは「コンテクストに一切依存しない～エラー処理」でしょ。
場所によって処理が違えば当然無理なんじゃないの？

それに exit() や extern 関数はライブラリに切り出しできなくなるからね。
572 ：デフォルトの名無しさん：2011/04/28(木) 10:03:55.69
>>569
ごく単純な >>546 で考えればそうかもしれないけど、 baz() 以下で
source_of_error() や他の失敗する可能性のある処理が１回ずつしか呼ばれて
いないとは限らない。

他にも baz() 以下のソースがあるとも限らないだろうし、 baz() 以下の
コードが未来永劫そのまま保たれるとも限らない。

例えば fopen() の失敗を処理している関数を読むときに「 fopen() のソースが
無い。困った。」なんてことにはならないでしょ。
573 ：デフォルトの名無しさん：2011/04/28(木) 10:16:41.74
>>572
ソースが無い場合は考えてもしょうがないと思う

例外だろうと戻り値だろうと辿って辿れないことはないと思う
ただ、戻り値の場合エラー処理してる関数だけ辿ればいいけど
例外の場合全ての関数を辿る必要あるよね（全部はちょっと言い過ぎだけど）
574 ：デフォルトの名無しさん：2011/04/28(木) 10:37:34.77
>>573
意味がわからないよ。

ソースが無い場合には不可能な行為を >>561 では「必要がある」と言っている。
これは明らかにおかしい。

>>564 で「ソースコードのどこで（つまりどんな状況で）エラーが起こったのか」が
エラー処理をする際に必要になると言っているようだが、 return を辿るなどしないと
得られない情報をどうやってエラー処理に使うというのか、わからない。

この状況でエラー発生位置まで辿ることを前提に話されても困る。そんな行為が
無意味に終わる理由はソースが無い場合のほかにも >>572 で挙げられている。
575 ：デフォルトの名無しさん：2011/04/28(木) 10:44:57.60
>>574
意味がわからないのはこっちだよ
ソースが無い場合なんて言い出したのは>>572が初でしょうに
それ以外のひとはソースがある前提で話てたと思う
だってソースの可読性の話をしてるのに、ソースが無い場合とか意味不明でしょ？
576 ：デフォルトの名無しさん：2011/04/28(木) 10:57:35.28
C++ PGは型が同じ例外なら、それがどこで発生しても
同じ処理でいいと思ってるのさ。
普段から「std::bad_allocだ。exitしよ」みたいなウンコプログラムを
書いてるんだろうね。
今だって、なるべくコードを読まない理屈を並べようとしてるし
ほんとコード読めないんだね。
577 ：デフォルトの名無しさん：2011/04/28(木) 10:59:09.75
コードの可読性の議論だったのに「コードがあるとは限らない」ワロスwww
578 ：デフォルトの名無しさん：2011/04/28(木) 11:00:46.73
>>575
ソースが無い場合の可読性なんてのを問題にしているわけではないよ。

例外を使った場合に可読性が下がる理由として、エラー処理しているコードを読むときには
エラー発生箇所を特定する必要があるからだ、と >>561,564 が言った。

そんな必要は無いという根拠のひとつとして挙げられているのが、ソースが無い場合。
根拠はそれ以外にもある >>572


今はこの「エラー発生箇所を特定する必要がある」の真偽を話している。その結果によって
「例外を使った場合に可読性が下がる」という主張の妥当性が変わる。
579 ：デフォルトの名無しさん：2011/04/28(木) 11:02:22.95
こっちでやれ。

例外を正しく使えないプログラマ多いね。 その6
http://hibari.2ch.net/test/read.cgi/prog/1298059471/
580 ：デフォルトの名無しさん：2011/04/28(木) 11:15:43.59
このスレでの結論としては、例外やデストラクタによって可読性が上がることもあり下がることもある、
つまり一概に言えない、ということかね。
581 ：デフォルトの名無しさん：2011/04/28(木) 11:22:24.06
>>578
error_handler() が全ての必要なエラーを補足できてるか知るためには
関数を遡って調べるしか無いでしょう？
もし漏れてたらバグかもしれないし、または catch(...)で捕まえても
何のエラーか分からなきゃ碌な処理はできない
戻り値ならエラーのハンドリングはそれぞれの関数でやってるから
責任が局所化されてるわけ

まあスレ違いと言われちゃったので最後にしておきます
582 ：デフォルトの名無しさん：2011/04/28(木) 11:45:37.74
まぁあれだ、Cの大き目のプロジェクトだとしばしば「エラーコード表」なるものが作られて、
どの関数からも一律にそのエラーコード表に則ったエラーコードなる数値を返すことになる。
その場合、エラーコード表の更新はしばしば現場の開発よりも遅れがちだから、
結局のところ自分の知らないエラーコードが下位関数から上がってきたらそのまま
上に上げるしかなくなる。
このことはつまり、C++の例外と同様の仕掛けを人力で再現していることに他ならないよね。
583 ：デフォルトの名無しさん：2011/04/28(木) 11:52:30.97
>>582
結局荒しの言い分って、クラスにしろ例外にしろ、その他もろもろ
手作業で似たようなことできるからそれで充分ってことなんだよね。
電卓なんか使わなくても算盤で良いよってのと同じ思考。
584 ：デフォルトの名無しさん：2011/04/28(木) 11:55:19.98
>>571>>582
エラー処理関数を格納するポインタテーブルを作って
エラーが発生したらその種類に応じて特定の関数ポインタを呼ぶという方法があるよ
関数ポインタテーブルなので、後から関数を入れ替え可能
その場で処理するから上にあげる必要もなし
585 ：デフォルトの名無しさん：2011/04/28(木) 12:06:53.69
C++ PGの習性として「コードにバグがあるのではないか？」
という想像力の欠如がある。
ライブラリにバグがないことを信じるのも
エラー処理にバグがないことを信じるのも
同じ精神から来ている。

C vs. C++の全てはこの精神性の差に由来する。
586 ：デフォルトの名無しさん：2011/04/28(木) 12:16:01.65
それはあるかもね。
古い体質の環境に晒され続けているCプログラマと、新しい開発環境を享受できるC++プログラマの差かもしれない。
587 ：デフォルトの名無しさん：2011/04/28(木) 12:20:21.01
> 理由の無い断定のみ
588 ：デフォルトの名無しさん：2011/04/28(木) 12:45:35.25
>>585
コードを書けばバグが発生する可能性があるから、デストラクタや例外を使って
その可能性を減らすってのは間違いじゃないよね。
589 ：デフォルトの名無しさん：2011/04/28(木) 13:02:33.28
もしバグがあったら、その部分を書き直せばいいだけだが
C++には書き直しを許さない空気があるね

Cが再発明に寛容すぎるから、その反動だと思う
590 ：デフォルトの名無しさん：2011/04/28(木) 13:21:46.13
>>584
Linuxカーネル方式か
591 ：デフォルトの名無しさん：2011/04/28(木) 14:01:42.37
バグが見つかったときの反応

C PG : 「直します」
C++ PG : 「仕様です」
592 ：デフォルトの名無しさん：2011/04/28(木) 14:14:30.23
そもそも

C: コーディングに匹敵する時間を掛けてテスト仕様を作り、クリティカルなバグは見逃す。
C++: クラス・モジュール単位でバグが出ないように作っているからとろくなテスト仕様を作らない。

で、>591

更に、

C: 「バグの原因調査に費用が発生します」
C++: 「仕様変更なので費用が発生します」

どっち途、金にはならんのだけどねw
593 ：デフォルトの名無しさん：2011/04/28(木) 15:04:57.68
荒らしが居なけりゃ悪くない流れなのになあ
594 ：デフォルトの名無しさん：2011/04/28(木) 16:36:09.89
コード読みたくないでござるwww
絶対にコード読みたくないでござるwww
595 ：デフォルトの名無しさん：2011/04/28(木) 20:07:34.01
荒しなんていたっけ？
596 ：デフォルトの名無しさん：2011/04/28(木) 20:49:58.50
C++を批判すると荒らし認定されます
597 ：デフォルトの名無しさん：2011/04/29(金) 00:21:56.98
>>589,591,592 理由の無い断定のみ
598 ：デフォルトの名無しさん：2011/04/29(金) 05:02:32.05
いずれにしても、Cではライブラリにバグがあったり
エラー処理にバグがあったりするのが当たり前って言うんなら
そんなもん使いたくないな。
599 ：デフォルトの名無しさん：2011/04/29(金) 05:37:00.56
警告無視したりコード読まなかったり
言語仕様を把握してなかったりするC++ PGの
コードのほうがバグが少ないとか、冗談だよね？www
600 ：デフォルトの名無しさん：2011/04/29(金) 06:03:34.62
>>598
その線で頑張っても無意味だと思うが・・・
自分でも分かってるだろ
601 ：デフォルトの名無しさん：2011/04/29(金) 06:13:56.82
C vs. C++ スレで C PG vs. C++ PG の話をすると荒らし認定されます。
602 ：デフォルトの名無しさん：2011/04/29(金) 06:20:08.16
道具（言語）を実際の運用（プログラマ or プログラム）と切り離して語っても身のある話にならない
603 ：デフォルトの名無しさん：2011/04/29(金) 06:31:39.00
実際の運用にまで踏み込むとC++フルボッコだからね
つまり本当に言いたいことは >>596
604 ：デフォルトの名無しさん：2011/04/29(金) 06:38:02.23
言語の差異から生じる運用の差異について話してくれるぶんにはいいんだが、
>>585,586,589,591,592,599 みたいな、単なるプログラマの能力を決め付けての
書き込みは意味が無いだろ。

スレのルール的には無視しろってことになってるが。 >>1
> 6．その他、明らかな煽りや無意味な書き込みも無視でお願いします。
605 ：デフォルトの名無しさん：2011/04/29(金) 06:41:04.18
C vs. C++ でなく、Java vs. C++ や C# vs. C++ でもフルボッコだろうな。
iOS が市場シェアを取っている間は、ObjC vs. C++ でも C++ に勝ち目があるとも思えない。

結論 : C++ は vs. しちゃダメ。他の言語に挑むのは止めようぜ。
606 ：デフォルトの名無しさん：2011/04/29(金) 06:41:13.06
s/プログラマの能力/プログラマの能力や性格/
607 ：デフォルトの名無しさん：2011/04/29(金) 06:44:34.79
>>604
>言語の差異

C++ は仕様が大きくて複雑すぎる

>から生じる運用の差異

言語仕様の把握や他人が書いたライブラリの読み込みが軽視される

って事だな、きっと
608 ：デフォルトの名無しさん：2011/04/29(金) 07:18:37.66
>>607
うん。こんな感じにしてくれるといいね。
しかし結論が飛躍しすぎているようで、よくわからん。

「言語仕様の把握」に大きさが関係するとなると暗記するってことなのかと思うんだけど、
それを「軽視」したり重視したりするというのは具体的に何をする（あるいはしない）ことなの？

ライブラリの読み込みは、ちょっと前に出てたライブラリのソースを読むかどうかって話かな？
これも、読むかどうかはライブラリの信頼性によるところが大きいと思うんで、言語仕様の
大きさとどう繋がるという話なのか、よくわからない。
609 ：デフォルトの名無しさん：2011/04/29(金) 07:26:41.05
ここはお前さんが理解出来るまで皆で教えてあげるスレじゃないんだがな・・・

雑談とか馴れ合いがしたいなら他のスレがあるだろ
610 ：デフォルトの名無しさん：2011/04/29(金) 07:53:20.47
>>600
趣味で使うなら言語仕様にいくら拘ってもいいけど、
仕事なら安定してる方を選ぶよ。
611 ：デフォルトの名無しさん：2011/04/29(金) 07:56:07.10
ソース読まないと信用できないようなライブラリしか
提供されないんじゃ仕方ないけどね。
612 ：デフォルトの名無しさん：2011/04/29(金) 08:46:42.46
>>611
じゃあどうするんだ
まさか「ソースの無い宣言のみ」で信用するやつはいないよな
613 ：デフォルトの名無しさん：2011/04/29(金) 09:08:01.52
>>607
>C++ は仕様が大きくて複雑すぎる
>言語仕様の把握や他人が書いたライブラリの読み込みが軽視される

って明らかに自分がC++を理解する能力や素養の無さから目を背けたがっているよな
本当は駄目な自分が悪いのにそれをC++に責任転嫁しようとしている。

>>608
>「言語仕様の把握」に大きさが関係するとなると暗記するってことなのかと思うんだけど、
>それを「軽視」したり重視したりするというのは具体的に何をする（あるいはしない）ことなの？

>ライブラリの読み込みは、ちょっと前に出てたライブラリのソースを読むかどうかって話かな？
>これも、読むかどうかはライブラリの信頼性によるところが大きいと思うんで、言語仕様の
>大きさとどう繋がるという話なのか、よくわからない。

自分の能力の無さを「合理化」してるだけだからそのままでは理解出来ない。
屁理屈とはそういう物。言葉通り捉えずに、そいつの本当の問題を見抜く力を養うのも
デバッグ能力を高めるのに役立つよ。
614 ：デフォルトの名無しさん：2011/04/29(金) 09:27:13.52
という事にすると楽で良いよな。

一般的に C++ が理解し易い言語なら、これだけ駆逐される事も無かっただろう。
615 ：デフォルトの名無しさん：2011/04/29(金) 09:35:04.74
ライブラリの件は、発端は単純な話だったんだよ

C PG : C++の仕様は理解困難だよね。ほら、この構文とか難しいよ
C++ PG: そんな構文は使わないから理解できてなくていい
C PG : でも理解できてなきゃライブラリ読めないよ？
C++ PG: じゃあライブラリなんて読まない

たったこれだけ
自分一人で全てのコードを書くわけじゃない以上
言語仕様の一部だけ理解できてれば良いなんて戯れ言だと指摘されて、
C++ PGはムキになってコード読まないとキレてるわけだ
616 ：デフォルトの名無しさん：2011/04/29(金) 09:51:58.64
>>614
いや、どう考えても「自分の能力の無さを言語のせいにする方」が楽だろう
何もしなくて文句だけ言ってりゃいいんだから
617 ：デフォルトの名無しさん：2011/04/29(金) 10:10:24.72
>>616
比較にならない物を比較しても意味ないだろ。
「方」という言葉を使う時は、自分が何と何を比較しているか気を付けた「方」が良い
618 ：デフォルトの名無しさん：2011/04/29(金) 10:23:02.35
能力がないと使えない言語では組織戦で生き残れない
619 ：デフォルトの名無しさん：2011/04/29(金) 10:23:54.04
>>617
その話の持って行き方は意味がない
また屁理屈かと思われるだけだぞ
主要なアプリがまだまだC++ + Qtで書かれている現実を見ろよ
620 ：デフォルトの名無しさん：2011/04/29(金) 10:27:06.70
非現実的な突っ込みを入れて来るから、意味のある議論にしようとするのが無理。

Qt はどうなるんだろうね。Nokia は MS とガッチリ手を組んじゃったみたいだし。
621 ：デフォルトの名無しさん：2011/04/29(金) 10:46:17.98
ところで、主要なアプリが Qt で書かれているとはどういう事だろう?

Firefox も LibreOffice も独自 GUI だし、Chrome もかな。
Inkscape も Gtk+ だし。

中には C++ や Qt を使っているアプリもあるだろうが、だから何?
622 ：デフォルトの名無しさん：2011/04/29(金) 10:49:55.81
InkscapeやLibreOfficeが主要アプリとか言っちゃう人って
623 ：デフォルトの名無しさん：2011/04/29(金) 10:50:36.54
何が主要か自分の意見を言えない人って
624 ：デフォルトの名無しさん：2011/04/29(金) 10:56:37.39
Google Earth は Qt と違うん？

>>620
非現実ではなくて要するに能力の無さから逃げてないか？って話
これは比較ではなくて自覚
625 ：デフォルトの名無しさん：2011/04/29(金) 10:59:15.92
>>624
お前さんが逃げていようとどうでもいいんだわ。
他の人も逃げている様に見えるなら、自意識過剰過ぎなんじゃないの。
626 ：デフォルトの名無しさん：2011/04/29(金) 11:03:33.18
つか、これって、いつもの C++ PG の鎖自慢だよな。。。
627 ：デフォルトの名無しさん：2011/04/29(金) 11:05:14.26
>>625
( ﾟДﾟ)ﾊｧ?いつ俺が逃げていると言った？
>>614が逃げているように見えるので指摘したら逆ギレですか？( ´ー｀)y-~~
人格障害じゃねーのお前
628 ：デフォルトの名無しさん：2011/04/29(金) 11:07:41.66
>>627
他に逃げてる人が見当たらなかったから、お前さんの事かと思ったわw

人格攻撃ありがとう。
629 ：デフォルトの名無しさん：2011/04/29(金) 11:08:29.84
>>624
>Google Earth は Qt と違うん？

Google Earth は主要なアプリなん?
ウェブブラウザやオフィススイートと肩を並べるくらいなん?

よしんば主要なアプリだとして、Qt を使ったアプリが一個あったら何なん?
630 ：デフォルトの名無しさん：2011/04/29(金) 11:12:32.61
何じゃこいつらは
議論をわざと成り立たなくするために文句を言う事に終始し始めたか
無視しよ
631 ：デフォルトの名無しさん：2011/04/29(金) 11:14:22.05

C++ PG : 「C++ が複雑だと言うのは理解する能力が無い証拠！」

C PG : 「いつまで鎖自慢してるんだよ・・・」
632 ：デフォルトの名無しさん：2011/04/29(金) 11:23:39.48
>>623
C++は、書き間違いを防ぐために何も書かない言語なんだよ。

コンストラクタもデストラクタも例外も「何も書かない」ための仕組み。
何も書かないから、例外がどこから飛んできたのかわからない。
633 ：デフォルトの名無しさん：2011/04/29(金) 11:42:51.58
鎖自慢ってＣのほうじゃねーの？
例外なんてウザイ機能が無いから安心。
それが俺のジャスティス！
ってことだろ？
634 ：デフォルトの名無しさん：2011/04/29(金) 12:09:12.24
良くも悪くもC++で拡張された非Cの部分に踊らされる毎日
635 ：デフォルトの名無しさん：2011/04/29(金) 12:22:36.40
setjmp/longjmp があるから例外なんて要らねえ！




とか言ってる奴がいたら鎖自慢かもしれんが、そんな奴はいない
俺も Java を書く時は例外使ってるし
636 ：デフォルトの名無しさん：2011/04/29(金) 12:59:28.64
>>635
例外が無いほうが秩序が保たれるんだろ？
好き放題にできない方が、鎖で縛られてると思うんだけど。
637 ：デフォルトの名無しさん：2011/04/29(金) 13:01:46.09
>>635
文字列操作程度で自前でメモリ管理しないといけないのに
鎖ではないと。
638 ：デフォルトの名無しさん：2011/04/29(金) 13:11:55.75
焦る気持ちは分かるが、質問はもうすこし整理して書いてくれ。
俺はお前等のお母さんじゃないんだから、分かり易く頼むわ。
お前らの脳内の世界までは見透かせないからな。

↓じゃ、ひとつ目の質問ドゾ。
639 ：デフォルトの名無しさん：2011/04/29(金) 13:28:52.57
>>638
例外が無いほうが秩序が保たれるんだろ？
好き放題にできない方が、鎖で縛られてると思うんだけど。
640 ：デフォルトの名無しさん：2011/04/29(金) 13:29:07.01
>>638
文字列操作程度で自前でメモリ管理しないといけないのに
鎖ではないと。
641 ：デフォルトの名無しさん：2011/04/29(金) 13:29:43.34
つまらん
642 ：デフォルトの名無しさん：2011/04/29(金) 13:31:40.78
もしかして setjmp/longjmp を知らないから、話の流れを無視した
質問をぶつけてくるのかな?

それとも会話の流れを読む事をお婆ちゃんに禁止されてるとか?
643 ：デフォルトの名無しさん：2011/04/29(金) 13:37:03.17
>>642
いや、例外を使うor使わないという選択の自由があるのに、
使わない一択なCの方が自由だという表現は変じゃないかなと。
644 ：デフォルトの名無しさん：2011/04/29(金) 13:43:24.25
選択肢は多すぎるとかえって不自由になる
645 ：デフォルトの名無しさん：2011/04/29(金) 13:44:29.79
>>643
それは俺が言った訳じゃないから、文脈がよく分からないんだが、
何で俺に聞いてるの?

一般論として言うなら、例外を使うか使わないかは、言語の標準
ライブラリも含めて統一されていた方がソースコードの見通しが
良くなる。
646 ：デフォルトの名無しさん：2011/04/29(金) 14:06:49.65
>>644
マーケティングではバカ向けに選択肢を絞ってやることが大切なんだよね。
647 ：デフォルトの名無しさん：2011/04/29(金) 14:47:22.08
>>646
選択肢の絞られたCはバカ向けであると？
648 ：デフォルトの名無しさん：2011/04/29(金) 15:06:17.21
選ばれし天才のみにしか扱えない言語なんてイラネ
649 ：デフォルトの名無しさん：2011/04/29(金) 15:11:23.49
Cにしてみればテンプレートもクラスも例外もライブラリによる拡張で補えるわけで、
CとC++でできることに違いがあるわけじゃない。
表記が気に入らないなら#defineでもなんでもすればいい。
650 ：デフォルトの名無しさん：2011/04/29(金) 15:35:49.56
>>649
宗教的な理由があるわけでもないのに、そこまでしてCを使う気になれないw
651 ：デフォルトの名無しさん：2011/04/29(金) 15:54:13.86
http://www.nicemice.net/cexcept/
652 ：デフォルトの名無しさん：2011/04/29(金) 15:59:48.60
http://code.google.com/p/exceptions4c/
653 ：デフォルトの名無しさん：2011/04/29(金) 17:21:09.22
テンプレートも例外も、他人が用意したのを使う分には良いけど、自分で書きたくはないな。
コンパイルが遅くなったり文法要素が増えるのも嫌だ。

クラスは欲しいね。とすると、やっぱり ObjC かな。
654 ：デフォルトの名無しさん：2011/04/30(土) 17:39:21.86
C++ PGの言語自慢を聞いてると、
メーカ製PCに山ほど付いてくる下らないプリインストールアプリを指して
「色々機能があるよ！使わない自由もあるし！」って言われてるみたいで
何だか微笑ましくなる。君が有り難がってる機能はゴミだよwww
655 ：デフォルトの名無しさん：2011/04/30(土) 18:07:59.02
>>654
知らない場所で無駄な常駐が動きまくってて挙句の果てには
「遅くなってきたらもっと速いPCを買えばいんだｗ」となる。
656 ：デフォルトの名無しさん：2011/04/30(土) 18:10:24.11
>>654-655
「無駄な常駐」が具体的に C++ の何にあたるのか言ってもらわないと例え話として成り立たないよ。
657 ：デフォルトの名無しさん：2011/04/30(土) 18:17:13.51
C vs. C++ スレなんだから、Cに追加されたC++の機能だろう
ユーザが使わないつもりでも構文自体は常に有効なところも常駐って感じ
658 ：デフォルトの名無しさん：2011/04/30(土) 18:18:29.31
クラスはゴミ?
659 ：デフォルトの名無しさん：2011/04/30(土) 18:42:53.85
フリーソフトでできる仕事をそのアプリでさっと片付け次の仕事に取り掛かるのがＣ＋＋プログラマ
こんなソフトは遅すぎてだめだとアプリ開発から手を付けてどうだ俺のアプリのが5％速いぜまいったかと鼻息荒くするのがＣプログラマ
660 ：デフォルトの名無しさん：2011/04/30(土) 18:46:27.74
誰か >>659 の解説キボンヌ
俺には難し過ぎて理解出来なかった
661 ：デフォルトの名無しさん：2011/04/30(土) 18:48:06.48
Ｃ使いは開発効率のわるいグズってことだろ。言わせんな恥ずかしい
662 ：デフォルトの名無しさん：2011/04/30(土) 18:51:19.44
いや全然分からないんだけど、どこをどう読んだらそうなるの?
663 ：デフォルトの名無しさん：2011/04/30(土) 18:54:35.54
つまり、使い捨てスクリプトはC++
再利用性の高いプログラムはC、ってことだな
664 ：デフォルトの名無しさん：2011/04/30(土) 18:55:39.97
なるほど
665 ：デフォルトの名無しさん：2011/04/30(土) 19:38:43.73
まぁ世にあるライブラリでよく使うものはＣのだわな
666 ：デフォルトの名無しさん：2011/04/30(土) 19:40:58.29
思うにＣとＣ++って比べるものじゃないだろ。
万年筆とワープロを比べるよう物。
667 ：デフォルトの名無しさん：2011/04/30(土) 19:44:36.88
しかし、Cをいまだに使っているのは
日本ぐらいだとおもうが・・・
海外のコミュニティでCを使ってるなんて言ったら
時代遅れだと思われて終わりだろ。
てか、CベースのC++なんだからおんなじようなものだ。
あとは開発環境とかの問題だろ？
668 ：デフォルトの名無しさん：2011/04/30(土) 19:45:16.44
C++ はワープロか・・・
確かにそうかも
669 ：デフォルトの名無しさん：2011/04/30(土) 19:47:08.48
>>667
そうだったら良かったね・・・

C がベースなんだから C++ でも同じな筈っ
きっと同じっ！

実際は・・・
670 ：デフォルトの名無しさん：2011/04/30(土) 19:49:46.34
CはエディタでC++はワープロ
なるほど言い得ている
671 ：デフォルトの名無しさん：2011/04/30(土) 20:39:14.90
>こんなソフトは遅すぎてだめだとアプリ開発から手を付けてどうだ俺のアプリのが5％速いぜまいったかと鼻息荒くするのがＣプログラマ
とある処理が5%速くなったけれど、それはI/O待ち時間の数千分の一程度だったというのが普通。
672 ：デフォルトの名無しさん：2011/04/30(土) 20:52:18.60
Cつかう理由のほとんどはC++がわからないからでしょ
673 ：デフォルトの名無しさん：2011/04/30(土) 20:54:12.10
という事にしたいんだな・・・
674 ：デフォルトの名無しさん：2011/04/30(土) 20:55:09.55
ちがう。Cで十分だから。余計なものは要らない。
「不必要なものを入れない」ってのはC++に無い重要な考え
675 ：デフォルトの名無しさん：2011/04/30(土) 20:59:04.57
C++ は色んな機能を節操無く詰め込んだけど、代わりに ABI と
初心者向けの学習クラスでも使えるシンプルさを永遠に失ったよな。

C の学習者数は今後も変わらないけど、今から C++ を学ぶ理由は無いね。
676 ：デフォルトの名無しさん：2011/04/30(土) 21:09:46.48
自分のまわりはCで十分だから
他もC++を必要としないはずだ
677 ：デフォルトの名無しさん：2011/04/30(土) 21:11:48.40
自分はC++を必要だと錯覚してるから
他人もC++を必要とするはずだ
678 ：デフォルトの名無しさん：2011/04/30(土) 21:17:28.40
C++にも存在意義はある

Cは人気言語なので、「こんな機能/構文を足してくれ」という要求が数多く寄せられる
でもC++が存在したから「そんなのはC++でやれ」と簡単に棄却できた
おかげでC++自体は巨大でグロテスクになったが、Cはシンプルでいられた
もしC++が存在しなかったら、Cはいまほどシンプルでは無かったかもしれない
679 ：デフォルトの名無しさん：2011/04/30(土) 21:19:33.84
>>677
それは誰も主張して無いと思う。

自分はC++を必要だから使うよ。何か文句ある？
せいぜいこの程度。
680 ：デフォルトの名無しさん：2011/04/30(土) 21:20:03.52
Cはプログラミングの基本を学ぶってイメージやわ。
C++はアプリケーション作りに最適な言語だと思ってる。
681 ：デフォルトの名無しさん：2011/04/30(土) 21:23:01.11
>>678
それはあるかも。捨て石になってくれたんだね。。。
682 ：デフォルトの名無しさん：2011/04/30(土) 21:26:30.44
今は携帯アプリもウェブサービスも Java だよね
DB まで Java だったりするし

C で基本を学んだら Java へ進むのが順当
いきなり Java でも良いけど

とすると、C++ の守備範囲がよく分からない
683 ：デフォルトの名無しさん：2011/04/30(土) 21:28:41.77
デスクトップは C#, ObjC, Vala があるしなあ
684 ：デフォルトの名無しさん：2011/04/30(土) 21:29:05.75
Javaだと遅すぎるとかメモリ使いすぎるとか細かいことに煩いとこよう
685 ：デフォルトの名無しさん：2011/04/30(土) 21:30:43.04
ところが、それが携帯でも動く時代なんだよね
686 ：デフォルトの名無しさん：2011/04/30(土) 21:30:45.08
>>678
その結果がC1xとか？
687 ：デフォルトの名無しさん：2011/04/30(土) 21:32:12.95
C1x はスレッドが標準装備になったのが嬉しいね
C++ PG が大好きな gets() は無くなるけど
688 ：デフォルトの名無しさん：2011/04/30(土) 21:35:14.75
>>685
動くのと快適とは大きな隔たりが
689 ：デフォルトの名無しさん：2011/04/30(土) 21:40:05.20
快適じゃないならこんな各社から出てないでしょう
簡単な話
690 ：デフォルトの名無しさん：2011/04/30(土) 21:46:18.19
AndroidはJavaは遅すぎて使い物にならんよ
まともなアプリはC++で書かれてる
691 ：デフォルトの名無しさん：2011/04/30(土) 21:55:40.13
実体の無い「まともなアプリ」の話をされてもな。
NDK を一生懸命駆使しても結局 Java 経由のサービスを使うんだぜ。
692 ：デフォルトの名無しさん：2011/04/30(土) 22:02:32.44
Java経由のサービスを利用するからといって
なんで自分のコードまで糞なJavaを使うことになるんだ？
693 ：デフォルトの名無しさん：2011/04/30(土) 22:05:53.60
書いてみれば分かるよ
694 ：デフォルトの名無しさん：2011/04/30(土) 23:33:02.86
692 名前：デフォルトの名無しさん [sage]： 2011/04/30(土) 22:02:32.44
Java経由のサービスを利用するからといって
なんで自分のコードまで糞なJavaを使うことになるんだ？
695 ：デフォルトの名無しさん：2011/05/01(日) 12:53:11.51
Javaは糞だけどC++よりはましだよね
どうしてもオブジェクト指向（笑）で作れと強要されたらJavaを選ぶわ
もちろんそんな拘束条件がなければ相手にしないけど
696 ：デフォルトの名無しさん：2011/05/01(日) 13:09:12.53
Java Client VMは最初は、というかほんの2～3年ほど前までは
馬鹿正直にエミュレート実行していたらしくて本当に遅かった
これは糞と言える

でも最近JITコンパイラを積極的に取り入れるようになってServer
バージョン並みに速くなった

これでC#の追従を振り切るつもり
697 ：デフォルトの名無しさん：2011/05/01(日) 13:58:01.67
いつの間にかJava叩きが始まっていたでござる
個人的にはC→Javaが良いように思える。
ポインタやっておけばJavaで参照に戸惑うこともないだろうし、クラスもC++よりはややこしくないので嫌になることはないと思う。
GUI作りたくなったらswingやC#いけばいいし。
698 ：デフォルトの名無しさん：2011/05/01(日) 14:30:56.80
Cで十分だからブラウザも余計なもの！
699 ：デフォルトの名無しさん：2011/05/01(日) 14:51:15.13
Java やっておけばスマートフォンでもタブレットでもサーバサイドでも
潰しがきくから C++ やるよりは断然良いな
700 ：デフォルトの名無しさん：2011/05/01(日) 14:57:09.66
実装継承（差分プログラミング）が衰退して更にまた一段とややこしくなった
原子力にたとえると高速増殖炉が使えなくなったみたいな感じ
701 ：デフォルトの名無しさん：2011/05/01(日) 15:13:16.27
>>699
でも給料安いよ
Javaがこれだけ普及したのは人件費が極めて安いという事にも原因がある
なんせプログラマの大半がバイトのオバチャンだもんな
702 ：デフォルトの名無しさん：2011/05/01(日) 15:14:35.45
もう無理すんなよ・・・
703 ：デフォルトの名無しさん：2011/05/01(日) 15:16:32.01
>>696
JavaのJITのC並みっていうのは、GCCの-O並みの速度でしかない
GCCの-O3並みではないし、VCのPGOやICCでビルドしたものには全く歯が立たない
無論インラインアセンブラ使えばJavaをぶっちぎるのは容易
オラクルの宣伝なんて信じるなよ
704 ：デフォルトの名無しさん：2011/05/01(日) 15:21:58.55
CPU のクロック上がったなあ・・・
メモリも沢山積めるし・・・
705 ：デフォルトの名無しさん：2011/05/01(日) 15:57:16.91
窓際C PG vs 薄給J PG vs ニートC++PG
706 ：デフォルトの名無しさん：2011/05/01(日) 16:11:11.64
ひでえw
707 ：デフォルトの名無しさん：2011/05/01(日) 22:00:39.29
>>703
それは百も承知さ
C#なんてJITコンパイルしたアセンブリのあちこちに間接CALLを埋め込んで
パイプラインCPUの良さを殺してるし
まあ仕方ないが
CでもC++でもライブラリにDLLを使えば同じ事だ

いずれにせよJavaでC#並みの速度が出るようになったんだからそれはそれで
いいじゃないか
銀行も今全国でシステムの入れ替えをしてるだろ？
通信との連携が困難なCOBOLをやめてどんどんJavaにしている
みずほと郵貯で続けざまに事故を起こしたのが良くなかったな
航空券の予約はとうの昔にJavaに置き換わってしまったしな
708 ：デフォルトの名無しさん：2011/05/01(日) 23:01:55.37
Ｃプラプラはたまに入り組んだ言語仕様のせいで謎のコンパイルエラーに悩むのが困る
解けたときにアハ体験で脳が活性化する
709 ：デフォルトの名無しさん：2011/05/02(月) 11:09:15.76
Cめんどくせ → C++快適！ → C++糞文法うぜぇ → CかわいいよC → 最初に戻る
710 ：デフォルトの名無しさん：2011/05/02(月) 12:45:14.20
Cやっててある程度文法覚えてオブジェクト指向に手を出したくなったときにC++やるって感じだわ。
711 ：デフォルトの名無しさん：2011/05/02(月) 12:48:31.74
今時は C++ より Java や C# に行くでしょ
712 ：デフォルトの名無しさん：2011/05/02(月) 14:08:10.05
C++はオワコンなの？
713 ：デフォルトの名無しさん：2011/05/02(月) 14:15:18.26
>>712
ここらへん参考になるんじゃないかな？
http://www.tiobe.com/index.php/content/paperinfo/tpci/
714 ：デフォルトの名無しさん：2011/05/02(月) 14:17:36.67
>>712
ここらへん参考になるんじゃないかな？
https://github.com/languages
715 ：デフォルトの名無しさん：2011/05/02(月) 14:26:44.67
>>712
ここらへん参考になるんじゃないかな？
http://sourceforge.net/search/
716 ：デフォルトの名無しさん：2011/05/02(月) 14:35:24.78
>>712
ここらへん参考になるんじゃないかな？
http://www.ohloh.net/languages/compare?l0=c&l1=cpp
717 ：デフォルトの名無しさん：2011/05/02(月) 15:51:24.55
まだC#よりずっと多いな。
というか業界第3位じゃないかい。
718 ：デフォルトの名無しさん：2011/05/02(月) 16:39:07.50
>>711
JAVAもアプリ開発のためにやってる。
C++はCの延長だと思ってやってる。
C#はVS入れるの面倒やしやってない
719 ：デフォルトの名無しさん：2011/05/02(月) 18:23:21.13
C++はやっつけ仕事をこなすのに使ってる
720 ：デフォルトの名無しさん：2011/05/02(月) 18:47:06.59
やっつけ仕事にＣプラプラわろた
721 ：デフォルトの名無しさん：2011/05/03(火) 12:56:38.77
C++はまだまだ終わりませんよ
90年代から2000年代初頭にかけて乱造されたC++プログラムを
メンテする仕事が残ってるからね
722 ：デフォルトの名無しさん：2011/05/03(火) 13:05:38.40
コンピュータの性能が大幅アップしたしJITコンパイラ技術もどんどん成熟しているから
今後はJava、C#というGCを備えたメモリリークの心配のない、しかもGUI開発の楽な
言語が主流になるだろうね

開発期間というのはモロに人件費に反映してくるので馬鹿にできない

C/C++は組み込みあるいはゲーム/OSなどのスピードを必要とする分野で生き残るだろう
723 ：デフォルトの名無しさん：2011/05/03(火) 13:23:26.01
QtがLGPLでも使えるようになったから
デスクトップの分野でJavaとかC#は用済み
724 ：デフォルトの名無しさん：2011/05/03(火) 13:23:35.92
あんまり簡単にしすぎると仕事が減るから開発者がわざとめんどくさくする方向にすすむと思うよ
725 ：デフォルトの名無しさん：2011/05/03(火) 13:32:15.67
>>723
Qt が LGPL になってから既に 2 年以上経つんだが・・・
その後のニュースって携帯向けの主要プラットフォーム争いから脱落した事くらいじゃない?
726 ：デフォルトの名無しさん：2011/05/03(火) 13:57:35.63
>>724
お前・・・・それは言っちゃだめだろｗ
727 ：デフォルトの名無しさん：2011/05/03(火) 14:13:24.16
もうだれも争わなくなった時にしか主要は存在しない
主要争いってなんだろう
728 ：デフォルトの名無しさん：2011/05/03(火) 14:28:06.70
自分で勝手に定義を作り出して
それに対して疑問を抱くって

器用だなw
729 ：デフォルトの名無しさん：2011/05/03(火) 20:34:41.67
>>727
主要なプラットフォームってことだろ？
ばかなの？
730 ：デフォルトの名無しさん：2011/05/04(水) 06:01:08.47
13年前くらいからCとC++の関係に変わりないからなあ・・
そして10年後もなにも変わらずこんなスレが立ってんだろうな。
731 ：デフォルトの名無しさん：2011/05/04(水) 08:36:46.08
10年後はC++は死滅してるかも
732 ：デフォルトの名無しさん：2011/05/04(水) 09:54:16.05
D言語にシェア奪われて駆逐されるよ
733 ：デフォルトの名無しさん：2011/05/04(水) 11:23:17.26
>>732
それはない
734 ：デフォルトの名無しさん：2011/05/04(水) 12:54:24.42
>>733
ない
735 ：デフォルトの名無しさん：2011/05/04(水) 13:22:51.49
でも、もしかして、ひょっとしたら、ってことも……
736 ：デフォルトの名無しさん：2011/05/04(水) 14:03:27.90
仕事があるとしても、メンテ中心じゃね？
737 ：デフォルトの名無しさん：2011/05/04(水) 17:36:03.60
いい加減。CまたはC++と、一緒に求人されてる事実を受け入れろよ。
738 ：デフォルトの名無しさん：2011/05/04(水) 23:15:35.36
Dってｗ


yaneuraoはどうなった
739 ：デフォルトの名無しさん：2011/05/05(木) 09:20:39.04
昔はC/C++と一緒に求人されてたら、C++使いが
「一緒にするな！Cが使えてもC++が使えるとは限らないだろ！」って
鼻息荒く怒っていたものだが、時代は変わったものだね……
740 ：デフォルトの名無しさん：2011/05/05(木) 12:08:21.92
今でもC++とPerlを一緒にする人いるけど
Perlの人は昔から、言語全体を知らなくても言語は使えるって言ってた
741 ：デフォルトの名無しさん：2011/05/05(木) 18:32:40.32
C++は一部分を知ってるだけじゃ
安全なプログラムは書けないけどね
742 ：デフォルトの名無しさん：2011/05/05(木) 18:42:29.79
Better Cとして使っても十分に効果はある
例外安全は超難しい
デザパタも難しい
743 ：デフォルトの名無しさん：2011/05/05(木) 20:23:18.03
Better C なら C99 や C1X でいいよ
744 ：デフォルトの名無しさん：2011/05/05(木) 20:43:48.15
std::regexも使いたい。
745 ：デフォルトの名無しさん：2011/05/05(木) 20:50:46.09
C99よりC++の方がBetter Cとしては良い
なぜかというとそのままC++に入れるから

一度C99で書いてしまうと変な癖がついて抜けなくなりgcc以外で
コンパイルエラーを何回も目にするはめに・・・
746 ：デフォルトの名無しさん：2011/05/05(木) 20:53:41.94
POSIX の regex.h や鬼車でいいよ
747 ：デフォルトの名無しさん：2011/05/05(木) 20:55:54.50
Objective-C にそのまま入るから C99 でいいや
gcc だけじゃなくて icc や clang でも使えるし
748 ：デフォルトの名無しさん：2011/05/05(木) 20:57:31.73
>>741
CだってPerlだって同じようなものだが。

人が母国語を使うにあたって、文法や
語彙を完全に知る必要はないし、
そもそも無理だ。
言い間違いもするし勘違いもあるし、
誤用だってするだろう。

コンピュータ言語だって、そういう感じで
いいじゃないか。
749 ：デフォルトの名無しさん：2011/05/05(木) 21:24:18.06
>>748
仏のような寛容さ・・・！
でもプログラムの仕事は任せたくない、不思議！
750 ：デフォルトの名無しさん：2011/05/05(木) 21:26:46.61
>>745
VC以外でC99に対応してないって理由のエラー見たことねーや
VC縛りがあるならC++でいーんじゃないの？
751 ：デフォルトの名無しさん：2011/05/05(木) 21:29:15.87
むしろC99の機能を積極的に使う理由がわからん
可変長ローカル配列ならalloca()でいいし
C++はstd::complex持ってるし
752 ：デフォルトの名無しさん：2011/05/05(木) 21:30:29.58
http://seclan.dll.jp/c99d/

この中で一番よく使うC99の機能って何よ？それからはっきりさせよう
753 ：デフォルトの名無しさん：2011/05/05(木) 21:44:41.19
>>752
一番だと コメント// か ブロックの途中で変数宣言 のどちらかになっちゃうよ
754 ：デフォルトの名無しさん：2011/05/05(木) 21:48:23.38
・コメント//
・ブロックの途中で変数宣言
・マクロ（__func__、__VA_ARGS__）
・最適化（inline、restrict）
・移植性（stdint.h、inttypes.h）
・指示付きの初期化子と複合リテラル

C99ならこれらは使うね
755 ：デフォルトの名無しさん：2011/05/05(木) 21:55:41.31
クラスがほしい
756 ：デフォルトの名無しさん：2011/05/05(木) 21:59:29.61
>>754

・Cでも大抵使えるという理由でしばしば見掛ける。勿論c++なら使える。
・Cでどうしても必要ならさらにブロック化してしまえばなんとかなる。勿論C++(ry
・inlineは事実上不要。restrictはiccならc++でも使える。
・なければ自分で用意すれば何とか。
・そう言えば自分では使わないな。
757 ：デフォルトの名無しさん：2011/05/05(木) 22:00:19.04
>>754
VC++には__restrictがある
758 ：デフォルトの名無しさん：2011/05/05(木) 22:01:31.69
なあんだC99使いたいとか言ってる奴大した機能じゃないじゃん
何をこだわってんだか
ここまで来たらただの意地張りだけだろ？
759 ：デフォルトの名無しさん：2011/05/05(木) 22:04:53.19
だってC99が使えるのに使わない理由がないもん
実際C++とだってヘッダ共有は大抵できるから、リンクするだけなら問題ない
760 ：デフォルトの名無しさん：2011/05/05(木) 22:06:28.63
>>756
inline展開はコンパイラに任せたがいい方が多くなってきてるからな。
マクロくらいにしか使ってないや。
761 ：デフォルトの名無しさん：2011/05/05(木) 22:09:42.32
>>760
C99 の inline は C++ のそれとは違って本当にインライン展開されるとは限らない
実際コンパイラ任せの方が速いからね
コンパイラへのヒント（速さ優先）でしかない
762 ：デフォルトの名無しさん：2011/05/05(木) 22:12:00.79
C とも Objective-C とも C++ とも簡単に混ぜて使えるから
Better C なら C99 でいいや
763 ：デフォルトの名無しさん：2011/05/05(木) 22:39:24.32
C1x も控えてるしな
C はゆっくり着実に進化している
764 ：デフォルトの名無しさん：2011/05/05(木) 23:25:37.45
C99はD化してるのに何をこだわってるんだ
765 ：デフォルトの名無しさん：2011/05/05(木) 23:26:41.95
そうだったら良いのにな
766 ：デフォルトの名無しさん：2011/05/05(木) 23:28:54.91
そうなんですけど？
767 ：デフォルトの名無しさん：2011/05/05(木) 23:29:14.39
そんな世界を夢見てた
768 ：デフォルトの名無しさん：2011/05/05(木) 23:29:42.43
OOPできないC99は欠陥言語
C++1Xが出たら消える
769 ：デフォルトの名無しさん：2011/05/05(木) 23:30:18.96
C++ が消えるの?
770 ：デフォルトの名無しさん：2011/05/05(木) 23:39:22.59
C++ PG の C99 への憎しみは異常
お得意の Better C ってフレーズで
C++ に誘い込むのが出来なくなるから
771 ：デフォルトの名無しさん：2011/05/06(金) 00:37:39.78
>>768
C++1X が出る頃には C++ は消滅してるだろうな
772 ：デフォルトの名無しさん：2011/05/06(金) 00:52:59.02
C99PG の　C++ への憎しみは異常
D言語化しているというのに
773 ：デフォルトの名無しさん：2011/05/06(金) 00:54:24.86
>>761
C++ でもいっしょじゃね？
違うのはリンケージ周りぐらいでしょ。
774 ：デフォルトの名無しさん：2011/05/06(金) 02:56:26.46
>>761 痛っ
775 ：デフォルトの名無しさん：2011/05/06(金) 03:36:25.97
Cが消えない以上、C++が消滅とかは絶対にないんだよ。10年以上前からそんな感じ
776 ：デフォルトの名無しさん：2011/05/06(金) 07:18:08.22
>>773
C++のはインライン展開されるか、無視されるかのどちらか
Cのは"Making a function an inline function suggests that calls to the function be as fast as possible"
言語仕様くらい把握しとけよ
777 ：デフォルトの名無しさん：2011/05/06(金) 07:37:08.51
>>772
C99 は C++ とも仲良くやれるから、憎む理由が無い
C++0x で C99 との互換性も高まったし
ところで、D言語化してると繰り返し言ってるけど根拠となるデータはあるの？
778 ：デフォルトの名無しさん：2011/05/06(金) 07:51:45.64
>>776
文面が違うのはわかるけどさ、インライン展開以外の最適化が禁止される
ことなんてないんだから、やっぱりいっしょじゃないの？

違うというのなら、C99のinline関数にできてC++のinline関数にできない最適化
ってどんなのがあるの？
779 ：デフォルトの名無しさん：2011/05/06(金) 08:16:37.80
>>777
>>756>>757
780 ：デフォルトの名無しさん：2011/05/06(金) 11:49:01.79
>>778
gccでアセンブラ出力してみると違いが分かる
C99 で extern 指定子を付ければ外部定義も生成しつつ
関数定義がある翻訳単位ではインライン展開してくれる
C++はそういうことはしてくれないね
781 ：デフォルトの名無しさん：2011/05/06(金) 11:51:56.01
逆にC++だとASMもインライン展開できるが、C+ASMだと
外部コールになるのでインライン展開できない。
782 ：デフォルトの名無しさん：2011/05/06(金) 12:06:02.61
>>780
inline int f(int x, int y) { return (x * y + 100) / 10; }
int g(int x, int y) { return f(x, y); }

gcc -S -o - -O3 -x c++ -std=c++98
gcc -S -o - -O3 -x c -std=c99

シンボル名以外まったく同じでしたよ。 gcc 4.3.4 (Cygwin)


> C99 で extern 指定子を付ければ外部定義も生成しつつ

上のコードで extern int f(... にすると f() の定義が生成されるけど、そういうこと？
これは何がうれしいの？
783 ：デフォルトの名無しさん：2011/05/06(金) 12:06:05.11
>>781
はぁ？何言ってんの？
784 ：デフォルトの名無しさん：2011/05/06(金) 12:13:50.83
>>782
何回も呼び出されるところだけインライン化して、他は普通の関数呼び出しにすることで
悪戯にコードサイズが膨れ上がるのを防げる
インライン関数もLLなど他言語から呼べる
785 ：デフォルトの名無しさん：2011/05/06(金) 12:21:18.75
>>784
C++のインライン関数ではそれができないってことでいいのかな？
できないと思う理由は？

あと、アセンブリ出力してみれば分かったはずの違いはどこに行ったの？
786 ：デフォルトの名無しさん：2011/05/06(金) 12:34:05.41
>>785
C++ では extern 付けても外部定義が生成されないのは
アセンブラ見て分かっただろ？
どうも言語仕様を見ない主義らしいから、代わりにアセンブラ見ろって言ったわけ

C++の言語仕様には、インライン関数は翻訳単位毎に「同じ」関数定義を
繰り返すことが必要だと明記してある
787 ：デフォルトの名無しさん：2011/05/06(金) 12:57:15.63
>>779
これはひどいwww
どこが根拠となるデータなんだよ
せめて>>437みたいなのにしてくれよ
788 ：デフォルトの名無しさん：2011/05/06(金) 13:07:34.61
>>786
要らない（使ってない）外部定義が出力されないのに何か問題あるの。
C++でも関数ポインタ取るとか、必要になれば外部定義が出るよ。

逆にC99の規格がアセンブリ上に外部シンボルの出力を強制してる
わけでもない。

下２行も何を言いたいのかわからない。

結局、C99のinline関数にできてC++のinline関数にできない最適化なんて
ないんじゃないの？
789 ：デフォルトの名無しさん：2011/05/06(金) 13:42:37.94
>>787
だってgccじゃ商売に使えないもん
GPLに汚染されているから金がもらえない
>>437は証拠にも糞にもならない
せめてIntel C++のC99モードにしろよ
790 ：デフォルトの名無しさん：2011/05/06(金) 13:48:21.09
>>788
C99 の場合 extern 付けたら外部定義が生成されるのは
仕様で決まってる

> 下２行も何を言いたいのかわからない。

C++ では各翻訳単位で定義を持つんだから、それぞれで外部定義を作ったら
One Definition Rule 違反になるだろ？
だから C99 と同じように外部定義を作ることは出来ないの
791 ：デフォルトの名無しさん：2011/05/06(金) 13:58:26.54
>>790
規格の話はわかってるから、繰り返さなくていいよ。

「extern 付けたら外部定義が生成される」ってのが
「C99のinline関数にできてC++のinline関数にできない最適化」だと
言いたいわけじゃないんでしょ？

何がうれしいのか説明してくれないと。

念のため言っとくと>>784はC++でも同じだからね。繰り返さなくていいよ。
792 ：デフォルトの名無しさん：2011/05/06(金) 14:05:34.19
>>791
分かってないから繰り返し書いてんだよ
単純に >>784 は C++ ではできない
出来るというなら方法を示してくれ
793 ：デフォルトの名無しさん：2011/05/06(金) 14:18:41.53
>>792
>>784にある２つのうち、

前者はinline指定しないことも含めてコンパイラに任せればいい。
必要ならコンパイラ依存の細かな指定を加える。
C99の規格でもプログラマが呼び出し毎に細かくインライン展開を
制御できるようには定められていない。

後者もコンパイラが提供する機能を使うことになる。
gcc なら __attribute__((externally_visible)) とか。
C99の規格で言う「外部定義」の存在はアセンブリ出力を含めて
コンパイラ出力中への実体の存在とは直接関係しない。
使われる可能性の無い関数の実体はコンパイル時に出力されなく
なってもいいしリンク時に出力されなくなってもいい。
これはC99でもC++でもいっしょで、inline指定も関係ない。
794 ：デフォルトの名無しさん：2011/05/06(金) 14:31:23.02
>>793
そっちが >>776 という全然違う定義の文面を見て、
定義は違っても実際は同じように最適化されるんじゃないか？というから
実際も違うってことを示したのに、今度は規格で定まってない？

規格の話をしてるのか具体的なコンパイラの話してんのか
どっちなんだよ
795 ：デフォルトの名無しさん：2011/05/06(金) 14:52:55.62
C++ の inline がコードサイズが膨れるわりに速くならない可能性があって、
結果として全部コンパイラ任せの方がマシなものだとしても、
C99 の inline は「関数の呼び出しを可能な限り高速にすることを示唆する」
なんだから、そんなデメリットは無いわけよ
一緒にされては困る
796 ：デフォルトの名無しさん：2011/05/06(金) 15:10:50.45
>>783
こういうこと

inline void func() {
_asm {
~
}
}

func(); //アセンブラで書いた関数をインラインで使用できる
797 ：デフォルトの名無しさん：2011/05/06(金) 15:11:26.93
こっちでやれ。

C、C++の最適化について語るスレ 3
http://hibari.2ch.net/test/read.cgi/tech/1215242849
798 ：デフォルトの名無しさん：2011/05/06(金) 15:13:12.92
>>794
必要ない定義が出力されるっていう違いが最適化の例だとは思って
なかったんだけど、そういうことなの？

> 規格の話をしてるのか具体的なコンパイラの話してんのか

どちらかというと規格の話をしている。
でもC99でのみ可能な最適化の例を見せるのに使えるというなら、
具体的なコンパイラの話をするのもかまわない。

いいかげん、C99のinline関数にできてC++のinline関数にできない
最適化ってのを示してくれないか？グダグダ言ってないで、スパっとさ。
あるいはそんなものは無いと認めるか。
799 ：デフォルトの名無しさん：2011/05/06(金) 15:25:16.43
>>795
C++のinlineも「速くならないようなら展開しない」っていう扱いにしても
かまわない（というか現存のC++コンパイラはほとんどそうする）わけだが、
それは知ってて言ってるの？
800 ：798-799：2011/05/06(金) 15:38:35.49
>>797
スマンカッタ。
>>794-795 レスは 797 のスレにしてね。
801 ：デフォルトの名無しさん：2011/05/06(金) 15:46:15.75
> いいかげん、C99のinline関数にできてC++のinline関数にできない
> 最適化ってのを示してくれないか？グダグダ言ってないで、スパっとさ。

C99 の定義なら
何回も関数を呼ぶ箇所があったら、その箇所とインライン関数定義を
同じ翻訳単位にしてインライン展開し、他の場所は普通に外部定義を
呼ぶとかできるわけ
こうすることで、コードサイズの増加を押さえながらインライン展開できる
C++ ではできないし、少なくとも一度もできる方法は示されてない
802 ：デフォルトの名無しさん：2011/05/06(金) 15:53:21.62
>>796
言語仕様にはそんなこと書いてないし、
gcc じゃ C99 でもインライン展開されるよ？
803 ：デフォルトの名無しさん：2011/05/06(金) 16:00:04.92
別のスレでやれっていってるだろ。
見苦しいんだよ。
804 ：デフォルトの名無しさん：2011/05/06(金) 18:52:05.14
>>789
gccの生成物（実行ファイル）にGPLは適用されません
805 ：デフォルトの名無しさん：2011/05/06(金) 18:54:10.75
gccはGPL3になっちゃたからもう使えないよ
806 ：デフォルトの名無しさん：2011/05/06(金) 19:20:25.29
codepadも普通にC99が通るね
807 ：デフォルトの名無しさん：2011/05/06(金) 19:22:19.09
gccがGPL3になっても>>804
808 ：デフォルトの名無しさん：2011/05/06(金) 19:33:53.82
gccはオワコン
gccいじるくらいなら一から書いたほうがいいって
clangの人も言ってた
809 ：デフォルトの名無しさん：2011/05/06(金) 19:42:43.50
もし本当にオワコンなら必死になって否定する必要も無い訳で
つまり・・・
810 ：デフォルトの名無しさん：2011/05/06(金) 20:00:23.35
>>809
啓蒙活動だよ
811 ：デフォルトの名無しさん：2011/05/06(金) 20:03:50.14
活動家には興味無い
使える物が偉い
812 ：デフォルトの名無しさん：2011/05/06(金) 20:10:54.41
clang はデフォルトで gnu99 が使われててワロタwww

http://clang.llvm.org/docs/UsersManual.html
813 ：デフォルトの名無しさん：2011/05/06(金) 20:57:04.99
>>806
codepadはgccだもん
814 ：デフォルトの名無しさん：2011/05/06(金) 21:38:57.38
>>813
オプションに -std=c99 または -std=gnu99 付けてるってことだね
815 ：デフォルトの名無しさん：2011/05/06(金) 21:58:25.76
>>814
付けなくても通る
816 ：デフォルトの名無しさん：2011/05/06(金) 23:40:50.79
gccはGPL3でダメらしいからBSDライセンスのclangにするわ
C99使えるし
817 ：デフォルトの名無しさん：2011/05/06(金) 23:46:19.16
誰がどのコンパイラを使おうと正直どうでも良いんだが、
GPL v3 だと GCC が使えないというのは理解不能。
818 ：デフォルトの名無しさん：2011/05/06(金) 23:49:11.61
>>817
表出ろやコラ
819 ：デフォルトの名無しさん：2011/05/06(金) 23:50:38.36
>>818
意味分からんwww何でキレてんだよwww
820 ：デフォルトの名無しさん：2011/05/06(金) 23:50:52.12
寒いからヤダ
821 ：デフォルトの名無しさん：2011/05/07(土) 00:04:12.73
C99のメリット何なのさ？って感じだけど
822 ：デフォルトの名無しさん：2011/05/07(土) 00:06:06.99
便利さ
823 ：デフォルトの名無しさん：2011/05/07(土) 01:28:38.64
C++も便利だろｗ
何を意味不明な事を
824 ：デフォルトの名無しさん：2011/05/07(土) 01:34:59.64
C++は要らない
825 ：デフォルトの名無しさん：2011/05/07(土) 01:57:59.97
C99はもっといらない
826 ：デフォルトの名無しさん：2011/05/07(土) 02:02:11.44
> C99 の inline は「関数の呼び出しを可能な限り高速にすることを示唆する」
> なんだから、そんなデメリットは無いわけよ
関数の呼び出しを高速化するだけだな。
デメリットがあるかどうかは関係ない。
827 ：デフォルトの名無しさん：2011/05/07(土) 02:07:41.14
gccは昔からやってるな
828 ：デフォルトの名無しさん：2011/05/07(土) 02:22:13.68
>>825
残念でした
829 ：デフォルトの名無しさん：2011/05/07(土) 10:44:14.25
C++の圧倒的なクソ文法はCとの互換性を重要視したからって理由もあるからなぁ
だから互換性が無いC99に怒りを覚えるのは理解できるよ
830 ：デフォルトの名無しさん：2011/05/07(土) 10:48:46.74
C の文法と互換性があるという事で芽が出た言語なんだから、自業自得
ObjC も C と互換性がある訳だし、他人を恨んじゃダメよ
831 ：デフォルトの名無しさん：2011/05/07(土) 11:03:16.77
インラインCにすれば良かったんや
832 ：デフォルトの名無しさん：2011/05/07(土) 11:36:43.46
互換性が欲しけりゃ勝手にC99を取り込めばいいのに
それをせず代りにFUDをばらまくんだから困ったもんだよ
833 ：デフォルトの名無しさん：2011/05/07(土) 11:41:45.23
>>828
悔し涙が出てるよ

>>829
だよなあ
C99はとっくの昔に業界から見捨てられた存在なのに
妙に入れ込んでるアホがいる
Intel C++もgccもC99を捨てればいいのに
834 ：デフォルトの名無しさん：2011/05/07(土) 11:42:29.66
という事にしたいんですね
もう休んでいいんですよ・・・
835 ：デフォルトの名無しさん：2011/05/07(土) 11:51:23.36
という事実ですよ
ほら涙を拭いて
836 ：デフォルトの名無しさん：2011/05/07(土) 12:02:14.06
そんな夢を見ていました
837 ：デフォルトの名無しさん：2011/05/07(土) 12:15:14.65
better C のポジションは C99 や C1x に奪われ
アプリケーションプログラミングは他の高級言語に取って代わられ
順調に業界から見捨てられつつあるのは C++
838 ：デフォルトの名無しさん：2011/05/07(土) 12:15:52.81
年内には次の規格が決まるかもしれないってのに、
今更 C99 の反対キャンペーンをしてももう遅いんだよなあ

10 年くらい遅れてる
839 ：デフォルトの名無しさん：2011/05/07(土) 12:24:55.53
C99ってどこで使われてるの？
参考書すら出てないでしょ
840 ：デフォルトの名無しさん：2011/05/07(土) 12:33:03.78
C99の規格？を知らないうちに使ってるだけですよ
841 ：デフォルトの名無しさん：2011/05/07(土) 12:38:31.67
言語仕様書は読まなくても参考書は読むの？
842 ：デフォルトの名無しさん：2011/05/07(土) 12:38:52.36
知らないのをどうやって使うんだ？
843 ：デフォルトの名無しさん：2011/05/07(土) 12:40:50.76
それはこのスレのC++ PGならご存知でしょ
ろくに言語仕様も把握せずにC++書いてるじゃん
844 ：デフォルトの名無しさん：2011/05/07(土) 12:43:52.19
規格よりコンパイラの動作で作りこむけど
845 ：デフォルトの名無しさん：2011/05/07(土) 12:58:47.98
C99厨必死
もう消えそうな言語を擁護して何の得が？
846 ：デフォルトの名無しさん：2011/05/07(土) 13:01:43.39
頑張っても無駄だぜ
847 ：デフォルトの名無しさん：2011/05/07(土) 13:57:56.75
えっ、クラス使えないの
848 ：デフォルトの名無しさん：2011/05/07(土) 13:59:28.05
無駄
849 ：デフォルトの名無しさん：2011/05/07(土) 14:27:22.28
えっ、演算子のオーバーロードも使えないの？
850 ：デフォルトの名無しさん：2011/05/07(土) 14:32:13.94
あっ、それは要らないや・・・
C++ さん、どうぞ
851 ：デフォルトの名無しさん：2011/05/07(土) 14:38:26.17
いらない？デバッグ大変そう・・・・ご愁傷様
852 ：デフォルトの名無しさん：2011/05/07(土) 14:43:33.97
普通に要らないだろw
もしかして C++ が良い物だと思ってないか?
853 ：デフォルトの名無しさん：2011/05/07(土) 14:48:55.50
お前の頭がまともな確率より
C++が良い物である確率の方が高いわな
854 ：デフォルトの名無しさん：2011/05/07(土) 14:50:15.02
可哀相に
人格否定始めちゃったよ・・・
855 ：デフォルトの名無しさん：2011/05/07(土) 14:50:46.46
僕にとっては良いものです。
一般的にも、ISOで標準化されたりいくつかのオープンソースプロジェクトで
採用される程度には有用なもののようですが、酷いものだと言う人もいます。
酷いものだという人の論調は決めつけが主であり、僕はそういう人が嫌いです。
856 ：デフォルトの名無しさん：2011/05/07(土) 14:51:19.16
名前空間とか、当たり障り無いのを出しておけば良いのに、
よりによって演算子のオーバーロードw
857 ：デフォルトの名無しさん：2011/05/07(土) 14:56:42.87
C言語使っている人間って
裸で洞窟に暮らしているイメージ
858 ：デフォルトの名無しさん：2011/05/07(土) 14:57:38.59
創作ポエムのスレかよ・・・
859 ：デフォルトの名無しさん：2011/05/07(土) 18:03:16.86
>>852
>もしかして C++ が良い物だと思ってないか?

C++を触った経験もないのになんでこんな上から目線の発言が出来るの？頭おかしいの？
860 ：デフォルトの名無しさん：2011/05/07(土) 18:05:18.74
定期巡回乙
861 ：デフォルトの名無しさん：2011/05/07(土) 18:09:34.60
>>859
だからお前等C++ PGの圧倒的低能さとC++自体への無知が
余すところ無く示されたこのスレで何の冗談だよw
862 ：デフォルトの名無しさん：2011/05/07(土) 18:10:08.95
C99って演算子のオーバロードできないんだっけ？
863 ：デフォルトの名無しさん：2011/05/07(土) 18:12:48.15
C++にとってはCの存在は重要だろうが
CにとってはC++は数多在る相互運用できる言語のひとつにすぎない
しかもその他大勢の中でも出来の悪い部類
864 ：デフォルトの名無しさん：2011/05/07(土) 18:17:30.50
>>852
いらない世界といる世界があるんだよね。
865 ：デフォルトの名無しさん：2011/05/07(土) 18:17:52.27
ま、全部アセンブラで書けばCもいらないんだけど。
866 ：デフォルトの名無しさん：2011/05/07(土) 18:18:09.65
最近はJavaもいいな。
867 ：デフォルトの名無しさん：2011/05/07(土) 18:19:00.33
このスレは何を書いてもレスが貰えるから楽しいな。
868 ：デフォルトの名無しさん：2011/05/07(土) 18:37:09.08
>>867
みんなやさしいもんね。
869 ：デフォルトの名無しさん：2011/05/07(土) 18:44:30.84
>>868
やさしいんじゃなくて粘着キチガイだらけ
870 ：デフォルトの名無しさん：2011/05/07(土) 19:08:11.60
レスもらえてよかったな。
871 ：デフォルトの名無しさん：2011/05/07(土) 19:13:50.99
>>871
今日の粘着
872 ：デフォルトの名無しさん：2011/05/07(土) 19:56:02.81
>>862
できない。
自分の場合は複素数を扱うので演算子オーバロードができるという理由だけで
C++を使っていたがC99は複素数がそのまま扱えるのでC++とは縁が切れた。
もちろんC++の機能はそこ以外使っていない。
873 ：デフォルトの名無しさん：2011/05/07(土) 22:58:09.72
>>871
自己紹介乙としか言いようがないな自分に安価付けてるし

>>872
でも四元数を扱おうとするとクラスが欲しくなるでしょ
結局オーバーロードは必要なんだよ
874 ：デフォルトの名無しさん：2011/05/07(土) 22:59:23.70
行列演算で演算子のオーバーロードなんてカオスw
875 ：デフォルトの名無しさん：2011/05/07(土) 23:02:17.25
自分は quaternion はこれと同じ様な感じでやってるわ
取り立てて不便は無い

http://marina.sys.wakayama-u.ac.jp/~tokoi/?date=20040321
876 ：デフォルトの名無しさん：2011/05/07(土) 23:03:37.90
この二つに共通することはやさしいCもやさしいC++もあんま役に立たないということ
877 ：デフォルトの名無しさん：2011/05/07(土) 23:36:12.39
>>874
つ boost::numeric::ublas

そんなにカオスでもないと思う
878 ：デフォルトの名無しさん：2011/05/07(土) 23:39:39.29

そんなに必要でもないと思う
879 ：デフォルトの名無しさん：2011/05/07(土) 23:43:41.16
>>875
むやみにタイプ量を増やすのが趣味なんですね
タイプ量に比例してバグ発生箇所も増えて行くのに
クラスがあればクラスを直せばすぐ終わる

>>878
必死ｗ
880 ：デフォルトの名無しさん：2011/05/07(土) 23:52:18.70
必死なのはイチイチ全レスを付けて回ってる人だと思うわ・・・
下らん
881 ：デフォルトの名無しさん：2011/05/08(日) 00:05:29.70
>>880
自己紹介乙
882 ：デフォルトの名無しさん：2011/05/08(日) 00:24:39.47
関数は関数である様に見せるのが C の基本的なスタイルだからな
標準ライブラリでは幾つか例外もあるけど、ユーザ定義関数はそういうお作法

真面目な話をしても無駄っぽいけど、一応
883 ：デフォルトの名無しさん：2011/05/08(日) 00:34:47.71
抽象化に慣れる事もしないで時代遅れもいい所だな
884 ：デフォルトの名無しさん：2011/05/08(日) 02:13:17.66
やっぱり無駄だったか・・・
885 ：デフォルトの名無しさん：2011/05/08(日) 06:27:39.62
>>873
> でも四元数を扱おうとするとクラスが欲しくなるでしょ
> 結局オーバーロードは必要なんだよ

四元数は知らなかった。これからも扱うことはないのでおれにとって
オーバロードは無用の長物。
886 ：デフォルトの名無しさん：2011/05/08(日) 06:34:59.16
>>885
DirectXを使うとすぐに三次元物体の回転に四元数(クオータニオン)が
出てくるんだが

もしかして3Dゲーム組んだ事ない？すぐバレるよ
887 ：デフォルトの名無しさん：2011/05/08(日) 06:44:42.70
そんな厨臭いレスしなくても。
888 ：デフォルトの名無しさん：2011/05/08(日) 06:59:05.20
>>887
図星でしたか
顔真っ赤ですよ？
889 ：デフォルトの名無しさん：2011/05/08(日) 07:28:35.32
>>886
> もしかして3Dゲーム組んだ事ない？すぐバレるよ

ね～よ。3Dゲーム組んだこともないしこれからも組むことはない。
それが顔真っ赤にするようなことか？　想像力がすごいな。
ついでに>>887はおれじゃない。
890 ：デフォルトの名無しさん：2011/05/08(日) 08:41:09.91
IDが出ないから何とでも言えるわな
四元数に限らずあらゆるデータ型を新規に作り出せるし演算子の
オーバーロードも出来るC++に比べるとC99はCに比べて大して代わり映えしない
891 ：デフォルトの名無しさん：2011/05/08(日) 08:47:05.58
ゲーム置いといても3Dに興味無い、一生やら無いって点だけで、どれだけロートルか
知れるわな。スマフォやそれ以下のガラケーですら3D対応がデフォなのに。
892 ：デフォルトの名無しさん：2011/05/08(日) 08:52:54.23
だよな
C99に妙なこだわりを見せてる奴はロートルと思って間違いない

C++が全然分からないけどC99なら何とか分かるので使ってみて
わずかな優越感に浸りたいだけだという感じがよく伝わってくる
893 ：デフォルトの名無しさん：2011/05/08(日) 09:02:36.77
その手の3Dってもう最先端じゃないよね。
陳腐化したから携帯端末にまで載せられるようになったとも言えるけど。
894 ：デフォルトの名無しさん：2011/05/08(日) 09:07:56.69
屁理屈を使うのはロートルの証拠
895 ：デフォルトの名無しさん：2011/05/08(日) 09:12:22.28
というか、最近じゃその手のはCUDAとかOpenCLとかになるわけで、
C vs C++って話じゃないよね(Cベースではあるけど)。
896 ：デフォルトの名無しさん：2011/05/08(日) 09:14:16.25
ほらまた屁理屈でしょ
演算はCPUでやる事はいくらでもある
いちいちDirectXを呼び出していたら遅くて仕方が無い

そういう場合はプログラム側で演算する必要があるが
Cだとバグりやすい
897 ：デフォルトの名無しさん：2011/05/08(日) 09:27:41.63
>>893
そう、陳腐化した技術すら使いこなせない。理解もできない。オ㍗ル。
898 ：デフォルトの名無しさん：2011/05/08(日) 09:33:07.41
そうだな。コンパイラも書けないようじゃプログラマとして終わってるな。
899 ：デフォルトの名無しさん：2011/05/08(日) 09:38:24.08
ここは終わったプログラマの溜まり場。俺も仲間に入れてくれ。
900 ：デフォルトの名無しさん：2011/05/08(日) 10:08:36.87
ここでは複素数を使った数値計算をやるPG（研究者？）を
3Dゲームを組む薄給PGが煽るスレですね
901 ：デフォルトの名無しさん：2011/05/08(日) 10:22:46.39
で、ここで演算子オーバーロードを素晴らしい機能だと
吹聴してる輩は >>301 は理解できるようになった？
以前は理解できなくて、苦し紛れに「理解できなくても良い、ライブラリも読まないし」
って言ってたけど。
902 ：デフォルトの名無しさん：2011/05/08(日) 10:44:16.94
合理化 - 酸っぱいブドウの機制

http://shirokumaice.sakura.ne.jp/wp/archives/131

>“酸っぱい葡萄”に手が届かない現実と、執着のギャップが大きいほど
>当人自身が葛藤に対して脆弱であれば脆弱であるほど
>"酸っぱい葡萄”に手を伸ばすことが、傷つきのリスクをもたらしやすく、耐えることが困難であるほど
　
>“酸っぱい葡萄”は強烈で堅固なものになる。

「自分がC++を理解出来ない」という現実を認めたくないので、代わりに
「俺にはC++なんか必要ない、C99で十分さ」と「合理化」する

そして、このスレに粘着しているロートルはただのロートルではなく、葛藤に対して脆弱、
つまり精神的に弱い、打たれ弱いダメなロートルであるから、管理職にも就けない

本当に精神的に強い人間ならば素直に「C++はわかりません」と認められるものだ
PG35才定年説を考えても終㍗ル
903 ：デフォルトの名無しさん：2011/05/08(日) 10:47:42.85
>>902
で、>>301は理解できたの？
警告を無視し、5000万行のコードを軽々と扱え、
演算子オーバーロードは理解できないから使用せず、
ライブラリは一切読まないC++ PGさん？
904 ：デフォルトの名無しさん：2011/05/08(日) 10:53:04.21
そんなやつぁーおれへんやろー
905 ：デフォルトの名無しさん：2011/05/08(日) 11:02:50.45
>>903
また屁理屈か
そんな超人みたいな奴いるかいアホ
906 ：デフォルトの名無しさん：2011/05/08(日) 11:13:01.58
超人じゃなくて、根拠無く5000万行うんぬん妄言を吐くアホPG
907 ：デフォルトの名無しさん：2011/05/08(日) 11:38:42.80
ある時はCと同じ、ある時はロートルとは違う
超人5000万行
908 ：デフォルトの名無しさん：2011/05/08(日) 11:42:27.40
>>903
つーか理解どころか一度も使ったこと無くても、試せばすぐ分かる
のに誰もレスしないって事がどうゆう事なのかも分からないの？ｗ
909 ：デフォルトの名無しさん：2011/05/08(日) 12:13:57.17
>>906>>907
だから誰がそんな事をいつ言ったんだよ？そいつは多分PGじゃないよ
ちょっと考えれば無理な事ぐらい誰でも分かるだろ

共同開発した場合話は違ってくるだろうが一人でそんな多大なコードを
保守出来るわけがない
910 ：デフォルトの名無しさん：2011/05/08(日) 13:33:57.43
>>908
結構レス付いてたよ？
難読化するなとかIOC++CCとかコメントされてたwww
全然難読化なんてされてないのに。
で、理解できたの？
911 ：デフォルトの名無しさん：2011/05/08(日) 13:36:38.53
>>301のようなIOCCCのC++版みたいな糞コードは理解しなくてよろしい
というか仕事で>>301のようなコードをあちこちに書いてデバッグをしにくくしたら
クビが飛ぶぞ
912 ：デフォルトの名無しさん：2011/05/08(日) 13:39:53.11
糞コードというからには、何故／どこが糞コードなのか理解できなければいけない。
理解できないのにどうやって避けることが出来る？
演算子オーバーロードを完全に使うのを止めれば避けられるが、使うんだろ？
913 ：デフォルトの名無しさん：2011/05/08(日) 13:58:31.39
>>912
完全な仕様書があれば>>301も糞コードにならずに済んだかもしれない
しかしC++の文法をほとんど理解している俺でも>>301のコードの実行結果は
目を疑うような物だったぞ
そういうのを糞コードと言うんだ

C++を使うのなら、クラスや演算子のオーバーロードを使うのなら、それによって
「見やすい、保守しやすい」コードを書くべきだ

見にくいコードを書く位ならC++なぞ使うな
914 ：デフォルトの名無しさん：2011/05/08(日) 14:00:47.17
>>886-891
こういうの見ると何だかな・・・

ゲームなんて作ってるのは業界の中でも一握りじゃないの。
自分の知ってる世界が全てという感覚で突撃されたら、
コミュニケーションなんて成立しないだろ・・・
915 ：デフォルトの名無しさん：2011/05/08(日) 14:04:41.80
>>914
自分の知っている事しか言えないと思うが？
自分の知らない事を無理に言おうとすると間違った事を言ってしまう危険性があるぞ
それより自分の領分を正しく発言する方が余程マシだと思う
916 ：デフォルトの名無しさん：2011/05/08(日) 14:06:13.72
普通は知らない世界もある事を前提に入れるんだよ
そうじゃないと知らない人とのコミュニケーションは成立しないから
917 ：デフォルトの名無しさん：2011/05/08(日) 14:11:57.92
あっそ
じゃせいぜいデタラメな議論でも続けてくれよ
918 ：デフォルトの名無しさん：2011/05/08(日) 14:22:59.73
文法を殆ど理解していても目を疑うような実行結果を
簡単に出せてしまう言語は糞言語なのでは？
>>301と「見やすい、保守しやすい」コードの違いも説明されてないしね
919 ：デフォルトの名無しさん：2011/05/08(日) 14:26:54.58
>>918
糞言語？見事な話のすり替えと言いたい所だがすり替えさせないよ
糞コードの話をしているのにいつの間に糞言語に？

それを言うならC言語もIOCCCを見れば分かるが読めないコードは
いくらでも掛けるからあんたの言い分ではCも糞言語なんですが？
920 ：デフォルトの名無しさん：2011/05/08(日) 14:33:34.44
>>301,305
class Xはメンバ変数を持たないし
operator=もoperator*もどちらもその演算子が本来持ってるであろう代入も乗算もしてない
operator bool()が呼ばれたら必ず同じ値を返す

a * b = cだったらoperator bool()が返す結果が全てになる
a * b == cだったらtrue右辺も左辺も等しいのでtrueになる

あんまり頭ひねるような事でもないと思うんだけど
921 ：デフォルトの名無しさん：2011/05/08(日) 14:33:37.34
Cでも簡単に難読化できるけど、それを避ける方法は簡単に説明できるでしょ？
だから邪悪なコードは避けることができる
一方C++では、パッと見で普通にクラスと演算子オーバーロードを使ってるだけに見える>>301と
邪悪ではないコードとの差を説明できない。説明できないのにどうやって避ける？
邪悪なコードを簡単に避けられない言語は糞言語では？
922 ：デフォルトの名無しさん：2011/05/08(日) 14:51:00.48
>>301はオーバーロードされた演算子が普通じゃない

証明終
923 ：デフォルトの名無しさん：2011/05/08(日) 14:51:53.55
>>920
メンバ変数の有る無しも、operator=とoperator*の内部が殆ど空なのも
式 a * b = c が書けるのとは関係ないけどね
924 ：デフォルトの名無しさん：2011/05/08(日) 14:53:58.90
>>922
operator= と operator* とoperator bool のどれを禁止する？www
925 ：デフォルトの名無しさん：2011/05/08(日) 14:54:47.11
どれも禁止しなくてよくね？
926 ：デフォルトの名無しさん：2011/05/08(日) 14:55:19.38
レビューして「分かりにくい。書き直し」で終わり。
927 ：デフォルトの名無しさん：2011/05/08(日) 15:02:39.64
>>926
どこが分かりにくいかも説明できないくせにwww
928 ：デフォルトの名無しさん：2011/05/08(日) 15:02:43.78
>>921
変換演算子がある時点で既に難読なんだよ
お前本当にC++知らないんだな
929 ：デフォルトの名無しさん：2011/05/08(日) 15:02:57.80
オーバーロードってなんですか？
930 ：デフォルトの名無しさん：2011/05/08(日) 15:07:10.58
>>928
全然>>301を理解できてないことが分かった
931 ：デフォルトの名無しさん：2011/05/08(日) 15:22:56.55
なんかoperator-に加算の実装がされてても
邪悪だけどどこが異常か説明不可能な普通のオーバーロードだとか
それが可能なんだからクソって言いそうだな
932 ：デフォルトの名無しさん：2011/05/08(日) 15:24:50.25
>>931
いや、それの邪悪さは説明できるwww
933 ：デフォルトの名無しさん：2011/05/08(日) 15:29:24.59
>>930
だから=と==の事だろ？でもそれはCにも言える事だろ
今は>>301がC++で難読である理由を聞かれてるんだから変換演算子があると
答えたのになんか文句あんの？
934 ：デフォルトの名無しさん：2011/05/08(日) 15:34:24.40
>>927
掲示板では細かい議論に付き合ってくれる人がいるけど、
仕事じゃそんな親切な人がいるとは限らないぜ。
935 ：デフォルトの名無しさん：2011/05/08(日) 15:37:01.69
一時オブジェクトへの代入が叱責物で
if文の条件式での代入がコーディング規約や使うライブラリ上仕方ないこともあるがあまりC++的ではない
operator bool()を使うのは大抵邪悪なコード。ただFalse型など邪悪でない使い方はある
まあconst関数じゃない時点で難読化にでも使うのかという感じだけど
で、C++固有の話では無いが使う人のことを考えない設計をする奴は首にしたいな。
936 ：デフォルトの名無しさん：2011/05/08(日) 15:41:31.12
>>933
じゃあoperator=をコメントアウトしてもいーよ
それともoperator=を禁止する？

>>935
operator bool を消しても a * b = c が 真偽値を持たなくなるだけで
この式自体は書けるからね
理解できないからって無関係なとこばっかコメントするなよwww
937 ：デフォルトの名無しさん：2011/05/08(日) 15:42:38.46
つーか、あきらかに病気だからあんまり構うなよ
938 ：デフォルトの名無しさん：2011/05/08(日) 15:48:04.29
あれん？「C++ではCと違ってパッと見で健全なコードと邪悪なコードを見分けられない」>>921から
「C++は邪悪なコードを書くことが出来る」>>936にえらい後退したな
939 ：デフォルトの名無しさん：2011/05/08(日) 15:53:19.41
>>936
>じゃあoperator=をコメントアウトしてもいーよ
>それともoperator=を禁止する？

変換演算子って代入演算子じゃないんだがなあ・・・・
恥ずかしいからお前もう書くなよ
940 ：デフォルトの名無しさん：2011/05/08(日) 15:54:16.25
>>938
だからさ、そんな邪悪なコードをどうやったら禁止できるか
まったく説明できないだろ？
a * b = c なんて式は動的言語でさえシンタックスエラー返すぜ
941 ：デフォルトの名無しさん：2011/05/08(日) 15:56:05.70
bool消すと普通にコンパイルできないが
どんな処理系使ってんの？
942 ：デフォルトの名無しさん：2011/05/08(日) 15:56:40.81
>>939
だからさ、operator bool なんて禁止しても
式が書けるかどうかとは関係ないわけ
禁止する意味あるのは operator= と operator* だけ
恥ずかしいなぁ
943 ：デフォルトの名無しさん：2011/05/08(日) 15:57:16.17
>>941
if () の中に入れられなくなるだけで a * b = c は書ける
944 ：デフォルトの名無しさん：2011/05/08(日) 16:00:58.38
>>943
いや、、書けてどうするんだ？
945 ：デフォルトの名無しさん：2011/05/08(日) 16:02:32.86
>>944
そんなアホな式が書けるC++を馬鹿にしてるんだけど？
946 ：デフォルトの名無しさん：2011/05/08(日) 16:04:01.54
なにそれ。>>301には一時オブジェクトへの代入以外に邪悪なところは無いと考えているのかよ
947 ：デフォルトの名無しさん：2011/05/08(日) 16:10:00.88
>>945
一見アホな式でも書けるけど、それをどう使うかはプログラマに任されてるのがC++。
だからアホが使えば問題になるのは、そういう思想の言語だから仕方ないわな。
948 ：デフォルトの名無しさん：2011/05/08(日) 16:11:49.75
a * b = c はbが帰ってくるように実装されてる
>>301はただそれだけの話だろ
949 ：デフォルトの名無しさん：2011/05/08(日) 16:13:42.31
>>948
全然違うwww
950 ：デフォルトの名無しさん：2011/05/08(日) 16:19:56.51
>>942
また話のすり替えか
C++で難読になる理由を変換演算子と答えたのに
いつの間にoperatorの話になってんの？マジ頭悪いなお前
951 ：デフォルトの名無しさん：2011/05/08(日) 16:24:02.04
どうしてもa * b = cが書けるので心配だという人は書かなければいいのではないか
952 ：デフォルトの名無しさん：2011/05/08(日) 16:33:25.54
ってかそんなのより&&あたりのオーバーロードをした時の方が悲惨だろうが
953 ：デフォルトの名無しさん：2011/05/08(日) 16:37:53.32
そもそも
a*b=c
で何がしたいのかがわからんしな。
めったに見ないコードだが、目的に対して手段が妥当ならそれでいいと思う。
954 ：デフォルトの名無しさん：2011/05/08(日) 16:39:47.09
C++に穴があるのは確かだけど
だからCだけで十分ニダってのはおかしいだろ
955 ：デフォルトの名無しさん：2011/05/08(日) 16:44:12.98
>>952
More Effective C++に書いてあるね
956 ：デフォルトの名無しさん：2011/05/08(日) 16:47:04.36
C++ Cording Standardsにもあるぞ
957 ：デフォルトの名無しさん：2011/05/08(日) 16:50:38.97
Cording?
958 ：デフォルトの名無しさん：2011/05/08(日) 16:51:37.35
お前みたいな優秀なのがいるからtypoできるんだよ
959 ：デフォルトの名無しさん：2011/05/08(日) 16:51:57.81
>>940
動的言語だからじゃなくて、ポインタがないから右辺値から左辺値を作る演算子を見つけづらいてことやろ
http://ideone.com/pTGKu
その言語をよく知っていれば変なことは大抵の言語でできる
960 ：デフォルトの名無しさん：2011/05/08(日) 17:44:19.47
>>950
話のすりかえじゃなくて、独りピント外れなこと言ってるから。
お前が>>301で理解できたのはそこだけだもんね？
もう今じゃお前だけじゃね？理解できてないの。
961 ：デフォルトの名無しさん：2011/05/08(日) 17:52:52.08
>>959
Ruby なら変なことしなくても a + b = c は書けてしまう
http://codepad.org/xvV9nvk5
962 ：デフォルトの名無しさん：2011/05/08(日) 17:54:03.60
おら、C++しか知らんのだが
CからC++の関数呼び出して
例外飛んできたらどうなるの？
963 ：デフォルトの名無しさん：2011/05/08(日) 17:54:20.18
>>960は誰と闘ってるの?
お薬足りないの?
964 ：デフォルトの名無しさん：2011/05/08(日) 17:57:00.07
>>960
馬鹿ですねえ
もう分かってるけど難読な理由を変換演算子だと書いただけですよ
そりゃ演算子のオーバーロードを他の目的に使えば読みにくいですよ
例えばoperator+を-の意味に使っちゃうとか

ストリームに<<をオーバーロードしたのはなかなかいいセンスだと思う
965 ：デフォルトの名無しさん：2011/05/08(日) 17:57:45.04
>>963
多分そうでしょう
>>960には見えない物が見えて聞こえない物が聞こえるようです
早めに精神科に行って薬をもらって飲むべきでしょう
966 ：デフォルトの名無しさん：2011/05/08(日) 17:58:41.81
C PGが演算子オーバーロードは必要無いと言ったら
理解できないロートル呼ばわりして煽ったのに
いざ自分たちが理解できてないことを指摘されたら怒るのは
どうかと思う
967 ：デフォルトの名無しさん：2011/05/08(日) 17:59:43.33
>>964
> そりゃ演算子のオーバーロードを他の目的に使えば読みにくいですよ
> 例えばoperator+を-の意味に使っちゃうとか

今だに>>301が理解できてないことが分かった
968 ：デフォルトの名無しさん：2011/05/08(日) 18:01:13.82
>>967
いつまでも言っててください
はい次の患者さんどうぞ
969 ：デフォルトの名無しさん：2011/05/08(日) 18:01:41.49
よし、じゃあこの話題終了。
>>960は二度と書き込むな。
970 ：デフォルトの名無しさん：2011/05/08(日) 18:08:29.75
>>962
>CからC++の関数呼び出して
>例外飛んできたらどうなるの？

C++ で catch してないのと同じ動作、つまりそのまま更に上位の関数に
例外が伝播するだけ。
971 ：デフォルトの名無しさん：2011/05/08(日) 18:14:28.22
>>970
ん？catch句がないと

>もし、規定以外の型の例外を返した場合は異常終了します
>許可のない型の例外が発生した場合、unexpected() を呼び出します

じゃないの？

それにCとC++の処理系が違うとさらに妙な事が起きる可能性がある
972 ：デフォルトの名無しさん：2011/05/08(日) 18:22:53.84
>>962
どうなるかわからんからやっちゃいけない。多くの場合 catch (...) が必要になる。
973 ：デフォルトの名無しさん：2011/05/08(日) 19:27:10.30
このスレを読むだけで>>3の

> C++ is a horrible language. It's made more horrible by the fact that a lot
> of substandard programmers use it, to the point where it's much much
> easier to generate total and utter crap with it. Quite frankly, even if
> the choice of C were to do *nothing* but keep the C++ programmers out,
> that in itself would be a huge reason to use C.

は的を射てると解る。Linusは賢人だな。
974 ：デフォルトの名無しさん：2011/05/08(日) 19:46:30.91
このスレを読むだけで>>13の

> The typical C-hacker will fail to give any rational and logical argument about
> why C++ is a bad language and why C is better.

は的を射てると解る。
975 ：デフォルトの名無しさん：2011/05/08(日) 20:05:03.66
自分の言葉で語れ
976 ：デフォルトの名無しさん：2011/05/08(日) 20:08:08.91
いやいや、止めといた方が良いよ？
C++ PGは語れば語るほど低能さを露呈するからね？
977 ：デフォルトの名無しさん：2011/05/08(日) 20:26:33.04
どんだけC++ PGに酷い目にあわされたんだよw
ちょっとお兄さんに聞かせてごらん?
978 ：デフォルトの名無しさん：2011/05/08(日) 20:43:38.56
お前さん達ホント仲が良いよな
日曜日に何時間チャットしてるんだよw
979 ：デフォルトの名無しさん：2011/05/08(日) 20:59:14.31
c++はcにオブジェクト指向を追加していくっていう方向でよかったんじゃないかな
980 ：デフォルトの名無しさん：2011/05/08(日) 21:08:51.56
いまさら何をおっしゃってるので
981 ：デフォルトの名無しさん：2011/05/08(日) 21:10:21.68
C with Class 路線を堅持していれば、もっと多くの人を惹き付けられてたかもね
今更遅いけど
982 ：デフォルトの名無しさん：2011/05/08(日) 21:10:26.21
言い負かされとこを忘れて欲しいんでしょう
983 ：デフォルトの名無しさん：2011/05/08(日) 21:18:42.66
なあCしか能がないロートルPGども
悔しかったらC++覚えてみ
984 ：デフォルトの名無しさん：2011/05/08(日) 21:22:07.33
煽りが下手
985 ：デフォルトの名無しさん：2011/05/08(日) 21:23:37.42
レスして欲しいのが透けて見えてる様な煽りはダメな煽りだよな
986 ：デフォルトの名無しさん：2011/05/08(日) 21:25:14.95
悔しそうでつね
顔が真っ赤ですよ？
987 ：デフォルトの名無しさん：2011/05/08(日) 21:27:39.94
次スレやるなら、ほんとに迷ってる人が具体的な事例を挙げて、
それについて議論する流れになってくれたらいいな。

・・・ならないんだろうけどな。それならもう次スレも要らん気がするな。
988 ：デフォルトの名無しさん：2011/05/08(日) 21:28:26.99
>>983
コンパイラ作ってちょ
989 ：デフォルトの名無しさん：2011/05/08(日) 21:28:52.90
>>988
コンパイラ買う金もないのか
無職か？
990 ：デフォルトの名無しさん：2011/05/08(日) 21:29:46.48
c99のせいでc++との互換性が完全に絶たれっちゃったよね
991 ：デフォルトの名無しさん：2011/05/08(日) 21:31:05.40
>>989
作ってちょ
992 ：デフォルトの名無しさん：2011/05/08(日) 21:44:22.06
gccのビルドぐらいできんと...
993 ：デフォルトの名無しさん：2011/05/08(日) 21:47:24.99
>>991
金払え
高いぞ
gccでも使ってろ無職は
994 ：デフォルトの名無しさん：2011/05/08(日) 21:52:21.06
>>993
100万ぐらい？
995 ：デフォルトの名無しさん：2011/05/08(日) 21:59:22.26
>>995
アホ抜かすな5000万円だ
996 ：デフォルトの名無しさん：2011/05/08(日) 22:20:26.83
で、いつ出来るの？生きてる内？
997 ：デフォルトの名無しさん：2011/05/08(日) 23:07:03.19
c++が嫌だからってcもすててdに走った人は今度どうなるんでしょうか？
998 ：デフォルトの名無しさん：2011/05/08(日) 23:08:06.20
d++が嫌になってdも捨ててfに走る
999 ：デフォルトの名無しさん：2011/05/08(日) 23:09:02.34
>>998
eを飛ばすな
小学生か？
1000 ：デフォルトの名無しさん：2011/05/08(日) 23:20:24.60
>>993
規格を完全に準拠したコンパイラってもう出来ているの？おしえて
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。