Linus「C++プログラマはウンコ。寄ってくるな」

> Git のソースコードを最初に見たとき、ヘンだと思ったこと:
> 1. C++ じゃなくてただの C を使ってる。理由は謎。移植性が
> どうとか言わないで、
> そんなのウソに決まってるから。

*あんた* のほうこそ大ウソつきだ。

C++ はひどい言語だ。これは、多くの平均以下のプログラマーが
使ってるためにさらに輪をかけてゲロゲロになっていて、どうし
ようもないゴミが簡単に生産されるようになってる。正直いって、
C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だっ
たとしても、それ自体、C を使う強力な理由になりうる。

Linus Torvalds

http://tabesugi.net/memo/2009/1a.html#152154

マでやれよカス

C++ができたら、ほかの言語はなんでもできるみたいな自信家多いな　> C++PG

いまだにC++がオブジェクト指向言語だと思ってるやつもいるしな

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

Gitのソースを見てみたら、素直な書き方なんで心が洗われるような気がした。
C++好きのやつは、初心者のころの素直な気持ちを思い出して欲しい。

仕事してると Linus の言う事はある程度分かってくる。
C++ 使いこなせる奴自体が少ないというのが C++ の大きな問題だということに。

悪いけどLinusってフレーマーっていうイメージしかないから
いまいち発言に説得力はないんだよね。論理的でもないし。

Linus氏はポインタで優越感を感じテンプレートに劣等感を感じているのです。
Ubuntuです。
思いやりです。

>>4
C++はオブジェクト指向言語だが？

Linusが言ったということだけで2chの厨房レベルの発言でも
感化される権威に弱い日本人って…
せいぜい現場の親方どまりのLinusが
Bjarneに劣等感いだきまくりなのが見え見えでなんとも…

ちなみに俺はLinusがFedora使いだと知った時点であんまり信用できんな、と思いはじめた。

Linusが良いことを言った!

クラスベースのオブジェクト指向言語なんて、オブジェクト指向
じゃないし。言語仕様がコロコロ変わり過ぎる。しかも互換性無し。
C++はゲロゲロのウンコ。C++マは、ウンコにたかる蝿に過ぎない。

>>10
うんうん。そうだね。

Linus は時代に適応できない過去の人だな。

>>10
まだ居るんだこういう人・・・

C++ はマルチパラダイム言語だよ

まあ、実際、マルチパラダイム言語なんて百害あって一利なし、というのは確かだが。

オブジェクト恥垢

雑魚プログラマには使えんだろうな。

いいこと言ってるな、とは思うが、cで書いてるとC++のSTLとかメンバ変数とかを使いたくなる
こともあるんだよなあ。いちおう、便利なところは便利だわC++。
世の中の「cわかります」と「C++わかります」って言ってる奴のほとんどがわかってない、
というのは同意。

メンバ変数じゃなくてメンバ関数だよ。メンバ変数ならcにもあるっての。

型チェックを強化してくれ。
あとやっぱりテンプレートも欲しい。
そしたら C でもいい。

あとやっぱ無名 union も欲しい。
C++ に無いけど関数ない関数もくれ(0xのラムダは却下)。
STL 相当のも欲しいけど、Boost みたいな何かができることを期待する。

ところでみんなはC++分かってると豪語できる？

cならすっかりわかっていると言い切れるが、C++はよくわからん。

　C++が最強だと言っていたときがあったが、いまではC言語を使っている。
複数人で開発するときに理解度が違いすぎて使えない。
とはいっても、ネームスペースとテンプレートが欲しい。
しょうがないから、いろいろな方法で同じようなことしているけどね。

複数人で開発するときにはCよりC++だろ。
常識で考えても非常識で考えても。

C++は、フールプルーフが無いからな。
成果物の質はプロジェクトのメンバーの最底辺に揃えられる。

なんだかんだでJava6が最強だ

どうも、C++をオブジェクト指向ではないということが「カッコいい」と勘違いしてる奴がいるな。

C++は間違いなくオブジェクト指向言語だよ。

寒々しい休日の午後にふさわしい実のない流れだな。

おいお前ら、
Linusが何千人もの（自称含めた）開発者を相手にしていることを忘れるなよ・・・

>>29
> 「カッコいい」と勘違いしてる奴がいるな。

あー、中二病っていうんですかね。

>>29
＞「カッコいい」と勘違いしてる奴がいるな
俺がお前に抱いた感想そのもの

Firefox
Google Chrome
OpenOffice

これらはLinusのいう「ひどい言語」で作られています。ゲロゲロです。

>>33
Firefox以外はゲロゲロではあるが。

>>27
ちょっと待ってくれよ。
C と比べての話だろ？
C++ の方がコンパイル時エラー検出に役立つ仕様が多いだろ？

試しに例を挙げてくれよ。

言語と人は別だと思うんだが
その辺、整理したほうがよくない？

C++使いは普通Cも出来るからバイリンガルなわけで
用途に合せて使いわければいいでは？

>>36
まあそうだな。
Ｃだと走らせてみないとわからないようなバグが、Ｃ＋＋だとコンパイル時にわかったりする。
Ｃ＋＋の方が便利なのは確かだろう。後発だし。
ただし、ここでは、「便利なのを使うと素人がたかって来るからやむを得ず避ける」という話だから、
言語と人とを分けて考えるのがちと難しい。

言語仕様を人間フィルタ代わりに使うって、
実際的かもしれんが非生産的というかかっこわるいな。
C++が幅広すぎてノウハウ統一がしにくいなら
規約体系作ったりすればいいのに。
Linusってやっぱりギーク的ネガティブ思考なのかな。
こう、イメージとは違って
フロンティア精神みたいなものとはかけ離れてるな。
まあ実際、Linus製ソフトってGitとかLinuxとか
基本的にカイゼンモデルで開拓系といよりは職人系なんだけど。

>>34
Firefoxもかなりゲロい
GNOMEもコンポーネント化できずにwebkitへ行った

>>33
確かにゲロゲロだわ。Chromeは知らんが、
FirefoxもOOoも全てソースから、ちとマイナー環境で
buildしようと試みるとウンコ踏みまくりだった。
コンパイラやライブラリの些細なバージョン違いに
まで依存し過ぎ。

FFはビルドしたことないけど、
OOoはビルドにディスク空き10GB以上必要なんだよね…なにそれ？ｗ

リーナスが口が悪いのは今更だろ？
「Minixはゴミ」
「OSXはウンコ」
「Gccはどんどんゴミになっていく」
「GNOMEはナチス」
「SVNは信じられないゴミ」
これにC++が加わっただけ。

美味しそうな食材集めて至高の料理を、と思ったら
出来上がったのがゲロだったと、そういう事ですか？

firefoxって、結構ガチガチに規約で固めてあると思ったけど
それでもゲロゲロなんか
linuxががゲロゲロだと困るからね

C++使う奴はよって来るな！もいきー！

45をコンパイルすると
もいきー！→もんきー！→猿→西遊記→ドラゴンボール→悟空→最強

45 名前：デフォルトの名無しさん ：2009/01/24(土) 17:17:02
C++使う奴はよって来るな！最強！

46 名前：デフォルトの名無しさん ：2009/01/24(土) 17:17:02
ありがとう。

よく読んでみなよ。
C++とC++の言語仕様が糞なのじゃなくて、

１．これを大して理解してない奴
２．そいつがこしらえた糞コード

がウンコっていってんでないか？

シリアルポートたたいたり、デバイスドライバ作ったり、割り込み考えたりするなら、C++はイラン。

そういやLokiとかいうオナニーライブラリはいまいずこ。

>>46
手抜きしないで時間も少し変えろよｗ
コピペ修正ミスのバグだなｗ


C++ が具合悪いことは認めるが、型チェックが強力なだけで C よりマシ。
C++ コンパイラでエラーが出たソースを却下するとか、
C++ コンパイラでコンパイルするけど class, template, using, :: が検出されたら却下するとか、
妥協が欲しいところだ。

つーかトランスレータでいいから、Linus 自身がマトモだと思う言語を作ったらいい。

>>49
言語が悪いんじゃないって言ってんのに話きかない奴だなおまえは

Loki懐しいな…

正直、C++ではSTLとboost以外使うコードなんか見つけた日にゃ
rm -rfした挙句、HDD取り出してそれが記録されてた推定位置を
アイスピックでガリガリにして再起不能にし
それを落としたサイトのドメインでパケットフィルタでブロックして
全ブックマークからそのサイトにリンクしてるサイトを削除。
そこまでしないと気がおさまらない。

boostのキモさは世界一。

リナスはシステムが得意なプログラマーで、コンパイラとか処理系が得意なわけじゃない。

というか、コンパイラのエラーとか型チェックとかの文句言うなら素直にJavaかC#つかえ。
速度差も結局はJITあるからC++とまったく差はない。
というか、動的にコードの置き換えが起きたりする可変（アスペクト）の研究が進んでるから、
C++で書いたコードと最適化コンパイラが作ったネイティブのコードより逆に速い。

でもboostが無いとC++ではまともに汎用的なコード書けないからなあ…
整数型のサイズ指定とか、C99仕様頼りになるのもなんか気持ち悪いし。

命名センスが？？？なのが多すぎるけど。
boost::filesystemなんてなんで再定義強要するような命名するのかわからん…

>>53
嘘はダメ

Linuxユーザーが気持ち悪いのも、リーナスの影響なんだな

>>50
何言ってんだ。
ナマの C はヤダって言ってんだ。

リーナスって色白で体温低そう

2chねらー気質なのは確か

配列のサイズを取得するマクロすら標準で用意されていない C/C++ は両方ともうんこ

>>60
Cで書けばこういう奴が寄ってこなくなる訳か
こりゃ>>1に賛成せざるを得ないな

コメントが書きやすくなったC、ぐらいの人が多いよ実際。
で、クラスとはそれを専門にしてる誰かが書いてくれる物で自分では書けない、と。

>>61
毎回 sizeof / sizeof してるコードを見たら
お前もそう思うようになるよ。

//スタイルのコメントは今はCにも取り入れられたぞ

むしろ B に存在していた // を
C で削除したのが問題だったのだ。

>>47
いや、最初にひどい言語だって言ってるじゃん。

配列のサイズ取得って、Cなら普通終端データで渡すもんじゃないの？
うざいぐらいsizeof/sizeof使うとか、頭悪いの？

だから、sizeof/sizeofのマクロすら標準で無いからウンコだと言ってるんだろ

だからそんなもん必要になる場面が多い時はコードを見なおせと言ってるんだろ

69の言う通りだな。

sizeofってことは静的配列だろう。たかが静的配列のアクセスで
あちこちでsizeof/sizeofしてるってことは明らかにダメなコードだな。
後で動的配列に切り換えたとたん全部書き直しになるし。

動的配列のサイズを取得するマクロすら標準で用意されていない C/C++ は両方ともうんこ

>>70
いや、普通先頭アドレスとサイズを渡すだろw

普通、配列のサイズは変数で持ち回るだろ
mallocはsizeof(要素の型) * 要素の数
でやって、あとは先頭と要素の数を持ち回る。

sizeof(配列)/sizeof(要素の型)で配列の要素数なんて、
学生の書くコードだよ。
プロがやったらちょっとそれはw
って感じ
あと//のコメントもCでやると素人臭いな。
VCSにコミットするまでに//のコメは消しとけよって感じ

>>72
CはともかくC++の場合マクロで用意されてたら怒るけど。つvector

プロ
プロ
プロ

VCS
VCS
VCS

あれ？このスレにはちょっとレベル高かった？VCS

相変わらず、レベル高けーな

70>>
>>73
sizeof/sizeofで固定長の配列の要素数を得るコードをいっぱい書くなと言いたかったんだけどなぁ。

>>74
sizeof(配列の識別子)/sizeof(配列の識別子[0])の方がいいと思う。
古い人間だからかもしれないけど//は使わないなぁ。/* */と#if 0 #endif使っている。

#if 0
/*
//の方が便利じゃん。
*/
#endif

/* */ はともかく #if 0 #endif は頭が固すぎるな

>>81
＞#if 0 #endif は頭が固すぎるな
イマドキはどう書くんだい？

>>82
/* */ しか使わん。今時コメントバイナリに埋め込む馬鹿コンパイラなんて使わんし。

>>82
/// <summary>
/// いまどき
/// </summary>
/// <param name="val"></param>
/// <returns></returns>
public int func(int val)
{
}

>>83
いまどきの人はコメントを含むコードもコメントで囲むのかね？

いまどきの人はコメントがあるごとに区切ってコードだけをコメントアウトするんじゃないかね？

>>85
なんか困る？

>>87
どこが困るのかわからん奴はVBで遊んでろ
Cに近づくな

なんだ説明できないのか。

説明のヒントならとっくに出てるよ
おまえのスキルが低すぎて気づかないだけだ

で、自分では説明できないんでしょ？

>>75
お前は全ての配列を vector で動的に確保するというのか

　どいつもこいつもバカばっか。
実力のある人だけが、C言語でプログラミングして、実力のない人は、さっさと他の言語にいってくれよ。
そうしないと、じじいの目からビームがでるよ。

　ネストコメントだと思うけど、いまだに入らないんだ。
自作言語で/+ +/をネスト可コメントにしたこともあった。
//(スラリコメントと名前つけている)は、C99からだからC89でもコンパイルが通るように使わないことにしている。

ネストコメントなんてコメントアウトでしか使わないんだから #if 0 〜 #endif で良い

>>93から異臭が漂ってるな

>>92
＞動的配列のサイズを取得する

2chで段落の先頭にスペース入れてる人3年ぶりぐらいに見た。

>>93
あんたと同類みたいな人も居るみたいなのに「どいつもこいつもバカ」とは適当すぎやしないか？

>>96
動的配列に対しては配列数を取得するマクロなんて何ら意味が無いだろw

いや、だからそういってるんだけど。

いってねーよｗ

なんだ、>>72 へのレスだったのか。
そりゃねーわ。

文盲たん？

とりあえず、リーヌスが腕のいい釣り師ってことはわかります。

教祖様がPHP叩いてた時を思い出した

C++ でまともなコードを書けない奴は
C でもまともなコードは書けない

Cで芸術的で官能的なコードが書ける人は、C++でも書ける。

>>106
ということは、C++ではまともなコードが書けない
といっているリーヌスはCでもまともなコードを書いてないと。

リーヌス涙目ｗ

C++ でまともなコードが書けない人＝あまり勉強をしない人。
こういう奴は言語を問わずまともなコードは書けない。

C++のクラスがCの構造体より優れてる所って何かある？

機能がいっぱい付いてるのは知ってる
その全てが複雑な動作と無駄なオーバーヘッドと不可解なバグの発生に貢献してるのも知ってる

コンストラクタとデストラクタがあるだけで天と地の差がある。

クラスのインスタンスはレジスタ渡しされる実装が多いから
Cの構造体を関数に渡して処理させるより速いぞ。
仮想関数だって結局関数ポインタなりswitchなりに変更しても
オーバーヘッドは極端に変わらん。

デストラクタは、まあ確かに役に立つかな
C++プログラマがリソースの管理が出来ないのはデストラクタに頼りすぎだからだろうし

コンストラクタは罠の塊だろ
死んだ方がいい

そんなだからCプログラマは変数の初期化忘ればっかするんだよ

メンバ関数は時々便利かな。
演算子オーバーロードは絶対使っちゃダメだな。
継承？仮想関数？そういうのも無視、無視。

>>110
C++には糞のような機能もすばらしい機能も山ほど付いているから、それらを取捨選択する能力が必要

継承は純粋な悪であって、利点は存在しない

そのことにC++コミュニティもようやく気付き始めてコンポジション（笑）を推奨し始めてる
結局Cで遙か昔からやってきたことに戻ってきた

>>113
C++は例外があるから
デストラクタなしにはまともにリソース管理できないんだよ。

>>117
C++は静的型があるから
継承なしにはまともにポリモーフィズムできないんだよ。

本当にLinusが言いたかったことはひとつ

ＲＵＢＹ最高

これマジ

それはないわ

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　
　そんなことよりyahooきっず「どんな''ジャンボ''が食べたい？」に投票しようぜｗｗｗｗｗｗｗｗｗ
　ジャンボピーマンを一位にして餓鬼共を泣かせようｗｗｗｗｗｗｗｗｗｗ
　現在1位　yahooの工作開始までに2位のたこ焼きを突き放す

　http://kids.yahoo.co.jp/　　　　　　　　　＿人人人人人＿
　　　　　　　　　　　　　　　　　　　　　　　　＞鶴職人募集中＜
　　　　　　　　　　　　　　　　　　　　　　　　￣　Ｙ^Ｙ^^Ｙ^Ｙ^￣

　↓本スレ
　http://takeshima.2ch.net/test/read.cgi/news4vip/1232801214/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CStringのない環境で文字列扱えないっすよwww

std::string 使えよ

昔触ってた時は文字列クラスすらなかったな。
RTTI周りはちょっとは強化されたんだろうか。

1行目と2行目って関係あるの？

正直、STLとboostとQtがあれば出来ないことはないな…
コンソールからCGIからGUIまで汎用性＆実用性最高水準で書ける言語なんてこれぐらい。

>>127
若干、器用貧乏な気もする。

>>117
相変わらず継承を推しまくるJavaなんかよりはましだ。

Linusは実は2chネラー、間違いない!

>>129
あながち、OS論争の時もnetnewsでやってたし、2chの技術系板のさきがけみたいな
気はしないでもないな。

>>117
継承が悪なら、基本ライブラリはなんで継承使いまくってるの？

>>131
標準ライブラリを作っていた頃はよく分かっていなかった。
localeまわりのグダグダとかauto_ptrとかもそのせい。

>>132
いや、Javaやsmalltalk、LL言語でも継承使いまくってるじゃん
それに最近出来てるライブラリも継承使いまくってるじゃん？こういうのも悪なの？

底辺プログラマってさ、グラビアアイドルが騙されるのと同じだよな。
芸能事務所解雇と同時に事務所所有のマンションを追い出されたりして。
いつ自分もそうなるかわからないし、そうなったらかわいそうだよな。

Linusの煽りの激しさと釣りテクニックの巧妙さを考えれば2CHで修業を
積んだと考えたほうが合理的だろうな。

なんて情熱的な煽りをする奴なんだ！クレイジーだぜ！
などと思ったものだが、写メ見て幻滅した記憶がある。
ただのヲタじゃん。

こいつってマイクロカーネルも批判してたよね。

誰このLinusとかいうコテハンは?

>>47
C++&COMでドライバ作るわけだが

>>137
実際マイクロカーネルはクソだったじゃん

ゲームをコマ落ち無しでしたいアホが多すぎるからだろ

このスレには >>135 や >>136 など、高いユーモアのセンスを持った
人間が沢山いるな。

デバイスドライバ作っても給料は安いままだよな・・・
何の技術も持ってない奴よりも俺の年収の方が低いなんて・・情けないよな・・・

>>143
ヒント： 需要と供給

>>143
何の能力も無いまま広告代理店だの株屋だのに勤めてる奴らは俺らより年収高いぞ。
歴史に残る天才が貧乏だったケースは無数にある。
年収＝能力じゃないんだよ。
俺らはポインタも配列も怖くない、メモリリークなんていうバカなバグは出さない、
そこらの駆け出しプログラマとは格段にレベルが違う、その矜持だけでいいじゃないか。

確かにヘボな奴がメインでC++で組む位ならCでやらせるな
C以上の罠てんこもり言語だし

linusの言いたい事は解る。
自分の理解してる機能だけ使えばいいのにな。

>>143
日本のプログラマは給料安くてやってられね。
使える友人増やして、会社起こすしかないよ。

どうでもいいけどマ板でやって欲しいな

どうでもいいことなら黙ってろよ

>>143
金を得るという技術が無いだけでしょ？

金が欲しいならそっちの技術も磨けばいいじゃん。

Dだろ

C++とWinに手を出したら人間駄目になるよ。
麻薬だよ本当。

Objective-C & Mac OS X だよな。

Objective-Cなんてドうんこだろ

>>154
どこの部分が悪いか言える？

>>150
そっちの技術に興味がないけど金は欲しい

…ってのが大半なんだよな。エンジニアって…

どうでもよくないのでマ板でやって欲しいな

>>155
構文が汚い

C言語って、stlとかboostとか使えんの？

つかえないよ

識別子としてなら使えるよ

#include <stdio.h>

int main(void) {
　int stl = 0;
　int boost = 0;
　printf("%d, %d\n", stl, boost);
　return 0;
}

クリティカルなところはC
普通はLL言語つかってほうがいいわ。

全然関係ない個人的な主観の話でいうと、LL言語という表記がキモい。
見てると頭痛が痛くなってくる。

病院行けよ

例えも理解できないのかわかってて返してるのか

理解を分かってるよ。
LLかLW言語と言えってことだろ。

そういうくだらない所にこだわって
いちいち突っ込み入れて話を中断させる奴って小物ばっかりなんだよな。

よしじゃぁウォーニングとワーニングについて議論

しなくていいな

じゃあ、「C言語」で。

そのまえに「リナックス」と「ライナックス」と「リーヌクス」をハッキリさせようぜ。

>>168
それはお前が大物と話す機会のある立場に居なくて、
且つしょっちゅう言葉を間違えて突っ込まれる人生送ってるだけだろ。

大物（笑）

>>173
脊髄反射乙

>>160
Boost.Preprocessorは使えると思う。

待て待て、charはチャーなのかキャラなのかシャーなのかで

シャーだろjk

シャアの方がかっこいい

gitのすばらしいコードってどこでみれるかな

ちゃー・アズナブル

でも以下の事実は認めざるを得ないな。

・Linuxは世界で唯一成功したといえる非商用OS
・gitはRCSのなかで一番快適
・C++製アプリは規模だけでかくて質の悪いものが多い
　（採用実績はあっても成果実績が伴なっていない）

>>181
> ・gitはRCSのなかで一番快適
ほんとかね？
試してみようかね。

> ・C++製アプリは規模だけでかくて質の悪いものが多い
てめこの、ゲーム屋なめんな。

MercurialなんかPythonだし、バージョン管理システムなんて、diffとか一部の思い処理意外は
LLで書いても十分って気もするけど。

>・C++製アプリは規模だけでかくて質の悪いものが多い

>>33

確かに

確かに。
そもそもC++で書いてると、無駄に規模が大きく成ってしまう
気がする。言語版Multicsの再失敗だな。

COOLとかPP使えば
C++もCも大して変わらない。

結局、
作法が統一されてるC++で書いたほうが楽でスマート。

http://www.sage-p.com/process/cool.htm

COOLがC++かわらないって、それはないだろ。

this をうっかり使うと C++ から使えないので
self にした方が良い

いや、一人で全部完成させて一生一人でメンテするならC++でも何でもいいって。

ここで大胆ながらも核心をついた発言をしてしまうと
HSP最強、ということになりかねない流れだな。

そもそも技術者育てる力も無いのに
初心者歓迎！なんてやってる会社が多いのが問題。
そう言う所で育ったPGはひどいことになる。

その初心者にC++チーム組ませて地獄をみたプロジェクトならぬディスジェクトが山のように…

XtとかMotifとかを生で触った事があって、Cでオブジェクト指向GUIプログラミングを
をやると、どんだけ酷い目に遭わされるか知ってると、C++への感慨も
変わってくると思う。

http://twitter.com/cpp_akira

>>194
status/1148031371

なんかウンコ漏らしちゃったよ(´ω｀)

ウンコはウンコしない

>>191-192
あるある!!!

C++でGUIアプリの開発は悲惨の一言だな。
言語仕様が硬直的でまともにイベントディスパッチできねぇし。

ゲーム開発以外はもう全部Cでいいよ。

ゲームこそCで十分だろ。アセンブラでも良いぞ。

>>193
ﾉｼ
「こんないーもんあるじゃねーか！C++使わせろよ！」
と思った。

マフィアなどが横行する裏の世界では、発見されるとまずい遺体を硫酸プールに
沈めて溶かし、証拠を消すなどという噂話がありますが、実際に科学薬品で遺体を
処理したことがあるという人が警察に捕まったそうです。

詳細は以下から。


BBC NEWS | Americas | Mexico man 'dissolved 300 bodies'

メキシコ警察に逮捕された男・Santiago Mezaは通称「シチュー・メーカー」。Mezaは
薬を扱うギャングのために、対立するギャングの遺体を週600ドル(約5万円)の
賃金で苛性ソーダを使って処理したとのこと。処理した遺体は300人にもなるそうです。

10年以上遺体処理を続け「何の感情もなかった」と話すMeza


Mezaは犠牲者の遺族と話す機会があるならば「謝罪したい」と述べています。
アメリカとの境界に位置する都市ティフアナでは、ドラッグを巡る争いで700人以上の
死者が出ており、メキシコ軍はMezaの言っている話は真実であると考えているそうです。

ブラック・ラグーンに出てくる始末屋ソーヤーのような人物ですね……。

http://gigazine.net/index.php?/news/comments/20090126_dissolve_300_bodies/

>>203
>科学薬品
・・・

http://twitter.com/finalfusion/status/1148899157
http://twitter.com/finalfusion/status/1148902866
http://twitter.com/cpp_akira/status/1148906759
http://twitter.com/finalfusion/status/1148913004
http://twitter.com/cpp_akira/status/1148916130
http://twitter.com/wraith13/status/1148916782
http://twitter.com/cpp_akira/status/1148921926
http://twitter.com/wraith13/status/1148931187
http://twitter.com/wraith13/status/1148932048

>>205
自分らは陰口を書くのはOKってスタンスなんだから、同じ土俵にたてとか、2chどうこう言うなって感じだよなぁ。
しかも>>194とか、ほぼスルーされてるのに。
まあ、どうでもいいけど。

>>206
かまってちゃんを相手にするなよ・・・

LinuxにはHSPのような登竜門的な言語がないから
いつまでたってもフリーソフターが育たずにWinに遅れをとるんだよ…

>> フリーソフター
GNUの概念と真っ向から反するからそりゃね

>>208
HSPってwww

>>207
「どうでもいい」ことを一々嫌みったらしく書き残していく>>206もかまってちゃんだから、
相手にしないほうがいいよ。

cは金にならないからしかたない

なるよ
もっと視野を広げろよ

その点C++はトラブルが出つづけるので
ずっと金になるというのはあるな
まぁ誰かは損してるわけだが

バージョン決め打ちできるところは良いなあ

フリーソフターって初めて聞く用語だけど、一般的なの？

略してフリーターってよく言うじゃん。

>>206
はてな村やtw村での生活が長いと
ああいう勘違いしちゃうのかねえ

回り見えてないねえ

>>208
perl(のようなもの)とか、shスクプリトとか。

>>193
XtとかMotif触ったことないけど、kernelのファイルシステムや
ネットワークプロトコルスタック程度の使い方なら、Cのオブジェクト指向
っぽいプログラミングで十分だと思う。

逆にC++みたいなレイヤを一つはさむと、逆アセンブルしたコードが
Cに比べるとわけわかめなんで、panicしたとき調査しずらい。

>>199
それは、入力受け付けるのにコールバック関数を必要とするOSに、
薄いフレームワークをかぶせてるからであって、言語のせいではないと思われ。

>>206
自分でスレをtwに晒しておいて、自分のtwの発言が2chに晒されると「同じ土俵に立て」とか頭おかしいな。

>>219
なに、バールのようなものだと？

>>220
XmToggleButtonGadgetGetState()なんて関数名見たら、それだけでC++使いたくならない?w

むしろメソッドもネームスペースも無いからC使う。
一目ですべて分かる。

それじゃC以外使えないよ。

>>224
しかも Gadget と Widget で関数名違うしな。
で、なんかの派生クラス作ろうとしたら
vtable 自分で管理しなきゃいけなくて、益々C++ が欲しくなる。

ん、なんかごっちゃになってる。
× vtable
○ クラス構造体の関数ポインタ

Cはアセンブリ言語の違いを吸収するが、

C++はオブジェクトシステムの違いを吸収できない、と

>>221
C++ってdelegateはどうやって実現してるの？

燃料投下
ttp://hp.vector.co.jp/authors/VA000092/jokes/strup.html

化石燃料ですね、わかります。

Союз Советских Социалистических Республик

>>230
C#的なdelegateなら、適当なオブジェクトを受け渡し、
そのオブジェクトの特定のメンバ関数（典型的にはoperator ()という名前の関数）を呼ぶという取り決めでやり取りする。
ようするにダックタイピングが最近の流れ。

昔からある奴だと、仮想関数使ったりマクロで振り分けたりというのが根強い。

関数ポインタとマップ

>>235
Windowsだとコールバック関数にこちらから1つ値を渡せるから、
そこにオブジェクトへのポインタを仕込めるのでマップの出番は無いんだけど、ほかはそうでもない？

>234,230
オブジェクトへのポインタと、メンバ関数へのポインタでもできるかと。

ちなみにメンバ関数ポインタと言うのはこーいうの。

// メンバ関数ポインタ
void (CHoge::*pFunc)() = CHoge::func;
// .* 演算子でのアクセス
(obj.*pFunc)();

// ->* 演算子でのアクセス
(pObj->*pFunc)();

.* と ->* は . や -> と別の演算子として扱われ、
個別にオーバーライド可能ってのもポイント。

普通はBoost/TR1のbindとfunctionでラップして使うけどな。
そういやBoostにはSignalsなんてのもある。

>>238
>>1でそのboostもstlも一緒に馬鹿されてる

boostもstlもパラノイアを感じる
どうしてそこまでしてC++を使おうとするのか分からない

case insensitive な人が何か喚いている。

STLは素晴らしく便利だと思うが。
ていうかSTLを使わないC++はかなりウンコ。それならCでキレイに書いたほうがいい。

C++のiostreamを考えた奴は、アホだと思う。

後発の言語で、iostreamをパクったのって有るのか？

Cは言語機能がちょっと貧弱すぎるせいで、ぐじゃぐじゃなマクロで
取り繕おうとしてしまうケースがしばしば見られる気がする

マクロはウンコ

>>240
Cは貧弱で、
プロジェクトで作ったライブラリは顧客の所有物となれば、次のプロジェクトで流用できない。
別々のプロジェクトから集まったチームのためにvectorやらなんやら設計しなおすのもバカらしい。

C++をjavaとかC#と比べる奴はIT土方。
みんながみんな開発効率重視の使い捨てPGじゃない。
とりあえずC++の設計と進化くらいは流し読みしとけ。

>>243
あれは酷い。

C++はいわゆる「C++スタイル」で書くことに結構こだわる俺でも
iostream系だけは使ってない。

iostreamは、技術デモとしては面白いよね、あはは　ってレベル。
標準ライブラリとして紛れ込んでるのは、たぶん、事務処理ミス。

genericなライブラリもdelegateも言語仕様として素直にサポートすりゃいいのに
何でもかんでもtemplateで無理やりやろうとするところがバカっぽい。

ATLで十分

古いC++の本読むとクラスこそC++の光、継承こそC++の真髄みたいに書かれているのに
ちょっと前に出版されたC++ Cording Standardsには
なるべく継承はヤメれ、friendもほどほどにねみたいに書かれてる。

friend なんかいらないだろ。

というか、そこまで継承を使う必要に迫られたことがない。
オブシコの真髄はコンポジットにこそある、
とC++触りはじめて3日ぐらいで気付いたっけなあ。
これぐらいのセンスがないとC++はむずかしいね。

なるほどねぇ、自分は本に書かれたままに受け取るしか出来ないからC++には向いてないかな。
でも、C++面白いんだよね、純粋に。

Cのコンパイラより
C++のコンパイラの方が
なんか速そうな感じがする。

C++は、要らん苦労を背負っときながら、でもこうするとちょっと楽だよね
っていう感じで、3歩下がって2歩進むことばかりに見える

ttp://www.hsjp.net/upload/src/up57929.jpg
販促チラシ

>>243
javaとc#でなんか同じような名前のがあったような。

いやいや、名前にStreamって付くクラスがあるだけ。
どっちも演算子で入出力なんてやらないよ。

i/ostringstreamはかなりイケてると思うんだがどうよ。

演算子を使ってるのはべつにいいけど、書式指定の使いにくさがどうにも。

printf 風の指定もできればいいのに
boost なしで

うん、俺もout系のstreamは、sprintfというのが用意してあったらかなり違ったと思うね。
scanf系のアドレス渡しとかフォーマットミスが嫌われた要因の一つだろうから
in系はともかくとしても。

あと、Cが文字列型を持たないのを引きずって、文字列の扱いが中途半端だったね。
もちろん、C++がAT&Tで生まれた直後から多数の「文字列class」が生まれてしまったのも原因だけど
「静的なstring」を用意することが出来ない。
だから、f(const string&)を呼び出すときにf("abc")とすると
毎回コンストラクタとデストラクタが呼ばれるってのもどうもね。
char*をやめて全部stringにしろといわれても、外部やAPIとのやりとりではそうも行かず。

普通イテレータ使うだろ。

ま、あのJavaでさえ、途中からとはいえprintf()様の軍門に下ったからな。

printfは神

printf っぽいものでも
型安全にする事は可能だからな。
ostream は今からでもそれをサポートすべき。

もう誰も新しい整形方式でprintfを倒そうという愚かな野望を抱かなくなったこと
結果としてprintfの優秀さが再認識されて今多くの言語でサポートされて使えること

これらがiostreamの惨めな失敗によるものなのだとしたら
あの糞ライブラリにも意味があるのかもしれない

>269
不遜なC#がprintf()様に微妙に反抗してます。

c#のあれは最初からprintfの軍門に下っている
iostreamのようにprintfへの挑戦者ではないだろう

printf対ostreamは天地の差だけど
scanf対istreamならどっこいどっこいだと思う

というか、上級のC++グラマでC++そのまんま使ってる奴なんているか？
そのクラスだと独自マクロ作ってC++なんかドライバ扱いなのが普通だと思ってたが。

つまり273は上級だと

>>273
http://www.gnu.org/fun/jokes/helloworld.html

>>275
Seasoned Hacker

% cc -o a.out ~/src/misc/hw/hw.c
% a.out
Hello, world.

ワロタw

Cコンパイラってなんであんなコンパイルが軽いの？
手抜きしてそう

企業に例えるとCは昔のGoogleでC++は今のGoogle

>>277
C++がLALRでないからじゃなかったっけ

構文解析の複雑さくらいじゃ、体感出来る程の違いは生まれないんじゃね？
テンプレートの実体化とかオブジェクト(vtable)のレイアウトを決定するのに時間がかかりそう

新人医者有受研修、教授被教尿道挿管。
医者挿入四苦八苦、多苦労後無事挿入。
然教授苦笑曰新人、「汝挿入場所相違也」。
医者赤面至急欲除、尿管微動不得取外。
医者必死謝罪患者、然患者喜々誤挿入。
教官不思議聞患者、曰「快感多旦那以上」。

>>278
なんか妙に納得。

昔のGoogleは素気ないがCoolだったな。
いまじゃすっかりチンドン屋になってしまったが。

>チンドン屋

ヤホーほどじゃない。

経済学的にはC++のほうが良い言語なのかなｗ

経済学的に考えると、
世の中の機器からチンドン屋になっちゃったんだから、
チンドン言語で書くのが効率的じゃね？

自然な思考で当たり前のプログラミングを〜Bjarne Stroustrup氏との対話〜
http://codezine.jp/article/detail/3370

http://123.writeboard.com/27c7a247acc07351e/login
pass:pgtwit

C++からCにいって気付いたこと。

デフォルト引数も関数の多態性もないせいで
ライブラリの関数とかで無駄な引数いっぱい…
不使用の引数でもわざわざダミー変数用意しなきゃならん。
Xlibとかめんどい。

欠点が明確なのは、欠点がなんだかよくわからないよりずっとましだ。

>>288
君はC++にも不適格だと思うぞ

なこたあないん。

C++プログラマって、どこまでも行っても下がいる
言語仕様がクズを生みやすいってことだと思う

それはCでも同じ

>>288
君は「C++の設計と進化」を読んだ方がいい

変数宣言は一番上だけってのがきもい

>>295
kwsk

まさか、ソースコードの一番上で宣言するような言語があるのか?

int func(a, b, c)
int a;
float b;
void* c;
{
　return a+(int)b+(int)*c;
}

>>295
ヒント： スコープ

>>297
なにこれ、釣り？
AT&Tでは、そんな書き方できたんだ、知らなかったなぁ。
>>void* c;
>>{
>>　return a+(int)b+(int)*c;
参考になりますた。C言語を使いこなせない人は、ここに立ち入り禁止ね。
C++を使う人も来ないでください。気持ちが悪いです。

>>299
お前が来なきゃいい。

「C++プログラマはウンコ。寄ってくるな」

それはLinusが言ってるだけで、このスレに来ることは問題ないから。

「C++プログラマは犯罪者。消えろ」

*(int*)c じゃないのか？

C++プログラマをいじめすぎ

それでいいよ。

追い詰められたC++はLispを取り込んで最終形態に・・・

C++ の作者にセンスがなかったと言わざるを得ない。
作者が元凶であった以上、C++ は元々消えていく運命にあったのだね。

Objective-Cの糞構文を見たら、C++の構文は神に見えるよ

>>294
そういう問題でもない。

>>268
＞printf っぽいものでも
＞型安全にする事は可能だからな。
どんなふうにすればいいの？

>>220
＞逆にC++みたいなレイヤを一つはさむと、逆アセンブルしたコードが
＞Cに比べるとわけわかめなんで、panicしたとき調査しずらい。
わざわざご自分の無能をおさらしにならなくとも
よろしいのに。

int i; float f; MyClass c;

printf("%(int) %(float) %(MyClass)\n", i, f, c);

それどこのオレオレコンパイラの仕様？

>>309
どっちも糞

HSP……
こうなってはもうHSPしかないのか……

printfの安全性は、コンパイラが賢くなる事で解決。

プログラマブルプログラマはCを使う。

C++じゃないけど、正規表現みたいにprintf書式もリテラルを作れればいいのに、と思う。

そもそも、printfとstd::coutって実質的に何が違うんだろ？
std::coutで特に記述が簡素化したとも思えないんだけど。
何を思ってこんなもん作ったんだ？

オペレーターオーバーロードをしたかっただけだろ。

>>320
long longが%I64dか%lldかで悩む必要なく、doubleに%lfを使うコードを見てうんざりする必要がなくなった。
ただ、それを実現したいだけなら、Javaみたいにprint(x)でいいわけなんだけど。

おーできない君が群がるスレですな
結構活気ありますねｗ

ですな

>>320
可変長引数を間違えるうんこを、救済したかったんだろ。
案の定あらゆる所で漏らしまくる、うんこ野郎が集まってきたとw
メモリの管理も出来ないゴミを前提にしてるし仕方ないさ

というかマ版用スレじゃんこれ

>>320
オブジェクト指向のデモ的な側面があったんだろうね

「ほら、オブジェクト側に処理を任せちゃえば、何も考えないですむんですよ」
「なるほど、楽ですね。でも出力幅とか書式指定したくならないですか？」
「実際のプログラミングではそうだろうね」
「そうすると結局手間は変わらない、むしろ面倒になるのでは？」
「ですよね。まあ、こんなことも出来ますよ、というデモですからねー」

>>323
出来たつもりになってるうんこ君を笑うスレです

俺はデキルスレになってるのが笑える

iostreamはいい加減に黒歴史化してほしい。
新しい入出力ライブラリ作ってさ。

C++って仕事でチーム開発で使うとCベースより問題が発生することがほとんどなんだが
これを言うとキャリアの浅いやつや責任持ったことのない奴ほど理解できないんだよな。
ここでこういうこというやつは、よっぽど教育がなされてる環境にでもいるのかな。

そりゃあんた、できないと思われることを嫌う連中は理解したがらないよ。
ここで言っている方は、挫折経験でもあるのだろうし。

できないと思われたくないならやさしいと思っているＣを提案されれば飛びつくだろ。
でもそうならない。

最先端の現場ではHaskell使っても統一とれるんだから
指揮能力の問題だろうな。

Cはやさしいかなぁ？
VBでいいって言われるならともかく。

さすがにそのレベルは除外

最先端の現場ってどこだよｗ

最戦端の現場

>>337
http://xmonad.org/

これが？

初心者から雇う癖に教育しないからそうなる

C++なんて教育するよりCでやったほうがコスト安い

それで現場でいきなりC++やって、訳分からんクラス作ったりするんだな

だからやらせないんだろ

つーかCよりC++の方が便利で楽じゃね。

つーかC++よりHSPの方が便利で楽じゃね。

何が便利で何がラクなのか。素人に抽象化の機能なんか使わせたら
コードも動作も抽象化されて修復不可能になるんだぞ。

初心者は何も抽象化しないよ

抽象化なんて全く必要ないね

このスレC++使いほとんどいないな

初心者というかオレ天才的初心者な。
入門書を曲解して謎のコードを大量生産。

ここまで「スクリプト言語使えよ」という意見ほとんどなし

>>352
誰も使うなとは言ってない。
問題は、C with スクリプト言語か、C++ with スクリプト言語かだ。

>>351
K&Rですね、わかります

抽象化なんてC++には不向き。
機能に溺れて逆にCのほうが抽象化しやすくなってる。

それはない。

抽象化がほとんど出来ないがために中身がよく見えるC
中途半端な抽象化のせいで中身ダダ漏れだけど肝心な所には触れないC++

黙って Haskell か Lisp 使っとけ

で、お前はHaskell使ったことあるわけ？

main = return "無いよ" >>= putStrLn

世の半分程度の人は抽象思考が苦手
その状態でプログラムに手を出す人がいるが、
プログラム向いてないよと言いたい

どうぞ言ってください

論理的思考のできない人多いよね

例えば？

ちょっと抽象的なコードを書いたら読めないとか言われたり

抽象的なコードもいいけど
むりやりC++で書いた関数プログラミング的なコードを読まされるのだけは勘弁

C++からオーバーロードを引くけば食いおわった魚の骨のごとくである。

その心は？

C++-<<

おあとがよろしいようで。

計算機を動かすコードに抽象的なんてことがあるだろうか？

屁理屈大魔王。

>>368
計算機を動かすコードには無いだろうね。
でも俺らが書いてるのは、計算機を動かすコードを生成させるコードだから。

>>368
計算機を動かすコードはすべて抽象的なもの。

抽象的なコードが具体的な電荷や電気信号に変換されて計算機を動かす。

C/C++で仕事してる俺から見るとJAVAorC#プログラマはC/C++に寄ってくるなと言いたい。
classの宣言と実体を全て.hファイルに記述されてるの見た時、
リアルで（'A｀）ｳﾍｪｰってなった。
3000行超えてるし…誰が管理するんだよ…

早めにそれはアカンと言えばいいだけだろw
放置する方が悪い

そもそも宣言と定義が分かれてるのがクソなわけで

>>373
> 早めにそれはアカンと言えばいいだけだろw
まぁ、初期段階では指摘するチャンスが無かったってこともあるだろう、いろんな事情で。

3000行って・・・大した事ないよね？

Java or C# プログラマが全部そんな人だと思わないで下さい・・・

大きなクラスなら.cppもそれくらい長くなることもあるだろ
メンバを一覧出来ないってことなら、現代的なIDEならそんなのは表示してくれるし

ファイル変更時のリコンパイル範囲が問題なんだよ

Ｃ＆viの時代からプログラムは組めているのに、IDEがないとまともにかけない言語ってどうなの？

>>379
Javaは動的解決だけどC++は静的解決って差もわからない奴がC++いじるともう・・・

全部ヘッダで3000行ならきついだろ。
例外はBoostの水準のテンプレートライブラリだが、そんなの自分では書かないしね。

なんだ、書かないんだ。

テンプレートはどうせ全部ヘッダで書かないといけないから
クラス内に全部記述したので問題ない。
（static メンバ変数の実体定義だけはクラス外に書く必要があるが）

>>372がテンプレート知らなかっただけってオチ？

また知ったかが便乗してる

いいや、Java/C#から来た人間がそんなもの書くわけないだろ。
家に帰ったらC++やりますって偽装でもない限り。

>>385
それは無いな。

>>372必死ｗ

知ったかが勘違いを押し切ろうとしている

>テンプレートはどうせ全部ヘッダで書かないといけないから

おまえはどんな糞コンパイラつかってんだよ…

>>391

export なんて都市伝説です
Comeau C++ なんて知りません＞＜

>>392

int 392(void){
return >>394;
}

ふう。再帰化完了。

export も知らない素人か・・・

(void) ってC臭がプンプンするな

主要コンパイラにないものを語って悦に入るって・・・

exportがサポートされていない→糞コンパイラ
って、まったくプログラム書かない言語ヲタか何かかな。

いるんだよね、Cの記述スタイル馬鹿にする奴
単純にCもまともに使えないだけなんだが

>>391の使っているコンパイラを紹介して貰いたいところ

export を知らなくて、ジョークも理解できなかったようだな

3000行越えてるからどうこう言ってる奴は
とりあえずLinusさんが開発してるカーネルのkernel/sched.cを見た方がいい

テンプレートに挑んでexportを知らない奴はいないだろう

c/cppファイルなら別に文句ないぞ。
>>372の場合、ヘッダに全部書いているのが悪いだけだ。

ああ、372は「C/C++で」宣言定義を全部.hに書いてるアホがいるって言ってたのか
そりゃクソだな
てっきり「Java/C#は宣言も定義も一つのファイルに書くから糞」って言ってるのかと思った

お前・・・
正直なのはいいことだよ・・・

>>403
まぁこうなったら「ジョークが理解されなかった」で押し通すしかないのはわかる。

宣言と定義が別ファイルに分かれてるだけでもう二度手間というか
いまどきありえねーって思う。エッチとCは一緒だろ

そうかなぁ
インターフェースと実装を分けるのって大事じゃない？

interface があればいいんだよ
interface が

>>410
そんなもん当然IDEが全自動でやってくれるだろjk。
……って言えるようになってほしいです。

>>381のいってることが現実に

どっかのえろい人はヘッダファイルを.cppから生成させてたな。

# hoge.h
--------------------------------------
template <class T> class Hoge{...};

#include "hoge.h.impl"
--------------------------------------
# hoge.h.impl
--------------------------------------
template < class T >
Hoge::Hoge(){...
--------------------------------------

という幹事で、ヘッダの最後にincludeいれて、実装ファイルを読み込ませる方法で
文理させるのが最近の俺の流行り。

素人質問で悪いんだけど、VC++2008の場合、templateは別として、
ヘッダファイルに関数の定義を書き込んじゃうと、多重定義エラーでない？
templateも特化すると多重定義エラーになるし。

#pragma once
か
インクルードガードやっとけ
#ifndef foo
#define foo

implementation

#endif /* foo */

#pragma onceの方はいいんだけど
2008の場合、通常のインクルードガードだと
コンパイル単位が違うとエラーが出るんだよね･･･なぜか。

リンクエラーじゃないのか？だとしたら、そんなの当たり前だ。
上のほうで.hに書く云々って話は、全て、メンバ関数をclass内に書く、という話だと捉えたよ。
少なくとも俺は。
そうすればinline扱いになるし。

まさか「2箇所に書くのが嫌」と言いながら.h内で実装を別途用意するなんて
(相互参照とうでなければ)ありえないしね。

>>417
リンケージについて勉強した方がいい

こういう人が「自分はC++を使っている」と言うから
「C++プログラマはウンコ」呼ばわりされる原因じゃないのか。

C++の入門書とかって能天気すぎなんだよ。
多重継承とか演算子オーバーロードとか副作用大きい機能とかを
知ってて使うことが上級者への道みたいに煽る。
いい迷惑だ。

入門書には分割コンパイルの原理とか書いてないことが多いからなあ。
グローバル変数の実体は１個しか定義できないとか、そういう基本的なことを知らないまま
「C++出来ます」とか言い切るウンコが増えてきているから邪魔なんだよな。

>>423
プログラミングの話をしているときに「副作用」をそういう意味で使うのは・・・

知っててもなお使うに値するケースかどうか判断する事は
上級者になるのに重要なことだと思うが

BK厨おつ

2ちゃんねる推奨のAccelerated C++には
コンパイル単位の話も出てきませんでしたよ^^

っていうか、この本のソースコード、
VC++2008じゃコンパイルできないし^^；；；

>>426
入門書だと、その判断するということを省いているのがまずいのでは？

>>424
そういうのってリンカの仕事だからな
C/C++の範囲外ということで入門書では避けられてる

そしてあらゆる言語の入門書がそうやって逃げ回る結果
解説してる本がどこにもないという

>>424
＞グローバル変数の実体は１個しか定義できないとか、そういう基本的なこと

C++ Coding Standardにも出てくるけど
そういうことは「一回コンパイルすればわかる」からねぇ。

>>426
> 上級者になるのに重要なことだと思うが

「入門書」の話ししてるんだけど。

C++やC#は演算子オーバーロードがあるだけで神
他の言語は設計者が数値計算とか3Dとかやらない文系なのがモロバレ

っ ほーとらん

>>431
gccだとオプション次第では分からないことも・・・

>>430
解説してる本は普通にあるよ

演算子オーバーロードが必要だと思うのがよくわからん。
自由に使わせたら可読性下がるだろあれ。

お前、可読性の意味分かってないだろ

おまえだよ。

型見て演算子の宣言見ないと何やってるかわかんないからな。
自分の中で閉じるなら問題ないかもしれないが自由に触らせるものではないでしょう。

定義だろ

いい加減、カプセル化に慣れようぜ

隠蔽化って隠蔽内容が完全でデザインに矛盾がなく直観的であることが前提だから
慣れるとか簡単なことじゃないぞ。

プログラムのセンスない奴は直観をどこまでも拡大解釈するしねｗ

数値型作る場合以外どうせ使わないし、
その場合は直感的になるから問題ないよ

お前が問題なくても自称できるやつが謎のオーバーロードし始めるんだよ。
C++はこういう問題がたくさんある。Javaでなくなったのにはそれなりの理由がある。

結局ジェネリック追加されたし
どうなるかは分からないよ

まぁその程度の低レベルな話は
C++ Coding Standard一冊で全部解決。

たった200頁の本だし（ぺらぺら）、
Effective C++やExceptional C++よりはるかに簡単な本だし、
もう必読書ってことで。

演算子オーバーロードが要らないと強弁する文系丸出しが続々登場！
みんなゲームとかつくらないの？ おもしろいよ。

ああゲームの末端で好きかってやってメインプログラマーに迷惑かける奴か。
つーかレス見る限り個人でしょぼいゲーム作ってる気になってるだけか。

おれはレベル高いからって言ってる奴はチーム仕事してねーだろ

プロジェクトの出来は、最もレベルの低いものに左右される

本読んどいてでみんなまともにプログラム組めてたらこの仕事天国だよ

>>452
それはリスク対策が出来ないプロマネがアホなんだろ

逆だろ
みんながまともにプログラム組めるなら、プログラミングなんてコンビニのバイト程度の価値しかなくなる
ほとんどの自称プログラマがカスだからまともなプログラマが食っていける

プログラムくらいアホでも組める

Linuxもアホでもかけるんだね。

Linuxはアホじゃなくてライナス
アホはAWK

Bjarne Stroustrup インタビュー (？)
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

10年くらい前のジョーク？みたいだけど根本的な解決を見た事ないな。
むしろ策略を追加してる印象。

まぁ、自分もカスだから人のこと言えないけど
そのカスである俺よりもひどい能力の人が上司だったりしたこともあるので
カスはカスで生きる方法があるんだと思う今日この頃。

まあカスの生きる道がないと世の中死屍累々だと思う

最上層と最下層の間の幅が一番小さいのはやっぱりHSPなのか？
一番大きいのはいうまでもなくC++だろうが。

HSPのきれいなソースを見ると才能の無駄遣いだと思うけどなｗ
>>463が想像するより人によってかなり差がある

>>463
いちいちそんなカス言語を引き合いに出してくれるなよ。

いや、C++の問題点を浮きあがらせるためには
その正反対のパラダイムをもつHSPを知ることが先決。

Σ (ﾟДﾟ;）ﾊｯ この流れもしやHSPオンリー？

>>466
正反対とは？

マルチパラダイムの正反対…なんだろ。意味不明。

てか、HSP使いなんていくら頑張ってもC++を
マスターすることなんてできないだろうから、
このスレで発言するいること自体間違ってる。

するいる

>>463
> 最上層と最下層の間の幅が一番小さいのはやっぱりHSPなのか？
> 一番大きいのはいうまでもなくC++だろうが。

人によってそんなに差がある言語は困るんだよ
ウンコプログラマーには分からんと思うけど

そもそもなんでHSPが出てくるのかわからないのだが…

>>472
誰と戦ってるんだお前

>>474
C++ と、じゃね？

TDNのHot Soup Processor

アツー！

C++: 複雑・高機能・マルチパラダイム・初心者には人気ない
HSP: 単純・低機能・パラダイムレス・初心者に大人気

>パラダイムレス
さあ困った。

なぜ世界的な現役最高峰プログラマーが世界的な言語について語っていてる
スレで、極東ローカルでゴミしかつかってない言語の話をするのか。

世界的な現役最高峰プログラマーが
このスレで語ってるわけではない。

HSPはダークホースだよな。
支持基盤が強いので化ければC++を駆逐できる可能性はあると思う。

>>482
馬鹿も休み休み言え。

春休みだからな。

素人だけど、Cをやっていてある程度理解しているつもりなんだが、
やればやるほど分からないことやきちんと理解していないことが
次から次へとどんどん出てくるんだよな。
なんか果てしない戦いが続いてる感じになってくる。
プログラム言語ってこういうもんなんだろうな。

C++も少しは勉強したんだが、C++プログラマになるとウンコになるのか。
やめとこうかなｗ

具体的に何が難しい？
ライブラリーを全部覚えるとかならともかく文法や作法はそれほど難しくないと思うけど。
演算子の優先順位とかなら暗記する必要もないし。

*pp[i]でsegvって(*pp)[i]なら平気でああそう言えばそうだったなあとか
*が増えると普段使ってないと割ときついね

>>487
それだとCからキツイのでは・・・？

C++ハジメル人は
STL、Boostを参考にコーディングし、
JAVA、C#、COOLを勉強するのばベストだね。

MFCから入ると変な癖つくからやめたほうがいいと思った。

MFCはSTLより長寿なんだぜ

先に相手が死んだ上での長寿なら誇れるけど、
どっちも生きてる上で「先に生まれたぶんだけ長寿」な場合、
設計の古さのアピールにしかならないかも。

>>490
それは、MFCは何時死んだ設定で計算してんの？

>>485
>プログラム言語ってこういうもんなんだろうな。
そういうもん。
まあ、やろうとしている事の複雑さによる。

>C++も少しは勉強したんだが、
テンプレートの魔力に取り込まれた人の一部は
一生闘い続けた挙句、boost という魑魅魍魎を召喚しました。

>489
Boostなんか超絶悪い癖が付くから、参考にしない方がいい。
悪癖を自覚しながら使うのはいいけど。

他人と協調してプログラミングを書くつもりなら
better C以外の使い方はするな。

Templateの変態度を味わいたいならBoostガンガン使え
でも檻から出てくるなよ

>>494
でも、その一部が次期C++に入りそうなんだろ。
楽しみ半分、不安も半分。

shared_ptrとかfunctionとかユーザとして使う分にはいいのもあるよ。
ソースコードは悪魔だけど。

>>486
>>485だけど、文字列を扱う際に配列で扱うのとポインタで扱うのでは
微妙に違うから、それがらみで混乱することがあるかな。
Cでの文字列の扱いは基本的に嫌い。
C++だとstringクラスあるから文字列の扱いは楽なんだろうなあ。

他人と協調してプログラミングを書くつもりなら
C++の基本機能 ぐらい理解しろ。

BetterCを味わいたいならEC++でも使ってろ
でも檻から出てくるなよ

>>499
これのこと？逆に、C++として何か欠けているの？
http://www.caravan.net/ec2plus/

>>500
主に例外とテンプレートと名前空間がない
あと多重継承とかRTTIとか新形式キャストとか

要するにアンチC++厨が嫌いなものを取っ払ったんだが
本当にただ取っ払っただけなので色々と使い物にならない
特に例外まわり

ここでLinusがC+Liなんてオシャレ言語を作ったら一生ついていくんだけどな。
CVSとサブバdisってGit作ったくらいだからやるんじゃないか？

Cという完璧な言語がある以上、その再発明はしない
とLinusは答えるだろう

Linusが言語のデザインなんてできるかよｗ
どう見ても一発屋だろ。

>>483,484
馬鹿が存分に休みながら言ってるってことかｗｗｗ

>>504
ということは、HSP開発者>Linusってことになるのか…

>>506
当たり前だろ。
何をいまさら。

少なくとも組み込み系ならEC以上の機能はいらない。
>>501が上げたものにメリットがほとんど感じられないうえ
デメリットが大きすぎる。

Google C++コーディング規約
例外

我々はC++例外を使用しません。

例外はモジュール内だけの閉じた世界で使われる分には問題ないけど、
それを飛び越えてグローバルな世界にしゃしゃり出てくると無限地獄の始まり。

門外漢だけど、名前空間と新キャストは実行時のオーバーヘッドもないから組込で使っても問題ないように思えるんだが。

>>503

Linusは、C++もCも糞だが、Cの方が圧倒的にマシだから
使ってるって書いてたよ。

Cを完璧な言語なんて思ってないと思うよ。

だったらRubyを使えばいいのに。

Ｃより安全で実用的な言語ってあるのかなぁ

>>514
COBOL

>>514
PASCAL・・・は、安全だけど、実用的じゃない・・・

Java
ただし、ごく一部の用途に限る

言語をもっとカスタマイズできる方向にならないのかな
EmbededC++よりももっと自由度高く。
多重継承禁止オプションとかテンプレート禁止オプションとか。

使わなければいいだけじゃん。

例外使わない主義の人たちはコンストラクタの失敗をどうやって検知してるんだろう
全てのクラスにerrno的なフラグ仕込んで作るたびにチェックしてるんだろうか
例外で通知するより凄く忘れやすそうだし、危険に感じるんだけど
例外アンチの人たちはその辺どうなの

ファクトリ関数作ったりコンストラクタと別に初期化関数設けたりするんでしょ、きっと。

ファクトリ関数だって最終的にはコンストラクタ呼ぶんだから
コンストラクタのエラーを拾うのがファクトリ関数になるだけで話は一緒だろ

初期化関数？いちいちデフォルトコンストラクトしてから値設定し直すの？
実行効率命の組み込みでそんなことしてていいの？

最適化すれば冗長なコードは消えるだろJK

いまさらぬるぽのキーワードができるとかものすごいうんこだと思う。
0で書いた既存のC++コードは置換すらできない。

0からぬるぽの意味が消えるわけじゃないけどな

>>523
初期化関数がインライン化できない程度に複雑だったら無理だろJK

>>519
チーム仕事したことないだろ・・・

>>514
Cのどこが安全なんだ
むしろ安全じゃないから専門家に使いやすいのに
安全を追うならVBでも使ってろ

Linusが本当にそれを言ったなら
アメリカ人らしくて本音をちゃんと名前を出してぶっちゃけてくれているから
アメリカつうか白人文化は良いな。

今度はこっちか

リーヌスがアメリカ人?

C++の深刻な問題点は、ソフトをグループで開発するときに現れる。
C++に精通したプログラマはついついC++の高度なテクニックを使って
しまう。ところが、ペイペイの新米プログラマはそのコードの意味を
真に理解しておらず、誤解からバグを組みこんでしまう。

直接的にバグを仕込んだ新米プログラマが怒られるのだろうが、
考えようによっては高度で難解なコードを書いたベテランC++
プログラマの方がバグを発生させる罠を仕掛けたようなもので、
もっと責任が重いと思う。

まぁ、C++はプログラマの習得レベルの差が露骨に表れるから
共同開発には不適で、一人のプログラマがシフト開発するとき
しか使えない言語ってことだ。

ルーシーの弟であるところの Linus はアメリカ人だろ一応。

>>532
どうだろ。無能は VB8 やらせても無能だしなあ。

>>532
「坊主憎けりゃ袈裟まで憎い」の典型的コメントだな
別にC++が悪いわけではない
無能プログラマが悪いだけだ

>>534
オレはCのエキスパートだが（この点について煽りたきゃ好きなだけ煽れｗ）、C++でオーバーロードやら
派生やらを駆使したプログラムを追うのは苦労するし、そんな書き方する奴はアホかと思うぞ。
C++の「美しい」書き方は解析やデバッグにはまるで向かないんだよ。沢山のクラスに「append()」が
あったとき、コード中にある「hoge.append()」が一体どこを指しているのやら、探し出すのは大変なことだ。
プログラミングで一番大変なのはデバッグなのに、それ以外の仕事で大変な思いをするのは
（しかも、みずから選んで）バカバカしいことだと思うね。

カプセル化に意義を見出せず、中で何やってるか気になって
追いかけないと気がすまないのが C のエキストラとやらですか。
まあ下手糞にクラス作らせると、そういうこともあるけどさ。

>>535
派生やオーバーロードを他人が追うことになっている時点でC++の使い方を間違えている。
ユニット化してブラックボックスで使うものだろ。

何を言ってるんだ？
デバッグ時や機能拡張時は追いかけざるを得ないだろう。
動いているものなら放っておくよ。

>>537
おまえも何を言ってるんだか。
ブラックボックス化したクラスは、本人しか触るべきでない？
そいつが辞めたら、死んだら、どうするんだ。
機能拡張のために、またしても派生クラスを作るのか。
元のクラスを見ないまま派生して、効率が悪い、遅い、だけならいいが、
見ないまま書いたコードがバグらない保証があるのか？

だいたい、「本人しか触れない」と宣言した時点で、糞コード確定だってことわかってるか？

>>538
他人がデバッグや機能拡張している時点でC++の使い方を間違えている

>>539
オブジェクト指向全般に対する批判だな、こりゃ。
クラスの仕様書が残っていないのが悪い。

>>541
どんなツモリ、と
どうデキテルはちがうだろ。

クラス図くらい書いた上での話なんだろうな。

Cプログラマって
IDE支援なしで組んでるの？

>>539
お前は立派な糞グラマだ

>>534

お前みたいなのがバグを引き起こすテロリストになるのだ。

腐れチンポが、死ね。

>>546
逆ギレすんなよウンコグラマ

>>541の
> オブジェクト指向全般に対する批判だな、こりゃ。
これに尽きる。Cのエクスタシー君の話は、「C++の話」ではない。

そうか、逃げ道が見つかってよかったな。
でもその逃げ道は、「C++で書かれたプログラムはデバッグも修正もおそろしく手間がかかる」という
命題を否定できないけど、いいのか？

誰々がいなくなれば解決すると主張する人間と、
継承とか例外がなくなれば解決する主張する人間では、どっちがマシだろうか。

>>549
で、クラス図くらいは書いた上での話なんだろうな。
>>539の言っているのは一つの関数を複数人でいじり倒すのと同じことなのだが

C++は１行楽にするため何十行も追加するような言語
share ptrとかくだらん小細工ばかり多すぎ

>>552
そんなこといってるから
例外出た時に
メモリリークしてても気づかないんだよ。

>>552
お前はC丼でも使ってろ

>>552
C++ はマルチパラダイムです。検討ﾊｽﾞﾚですね。

つか、なんで双方必死なの？
個人的には、構造化すら満足に出来ない連中に
「OOノススメ」なんて無茶だと思うんだが。

クラス図見てもメモリリークはどうにもならんからな・・・

「健闘」の誤変換に気付いて修正しておいて
「検討」とはなんたる失態。

>>554
C丼で思い出した。
小学生の時に、藤井と言う子がいたんだが、彼女が日直の時に黒板の井の字の中に点を打ったのは、僕です。
それ以来、彼女はみんなから、藤丼と呼ばれるようになりました。ごめんなさい。

>>556
いや、クラス図は単に characteristics な面しか記述できないんだから
当たり前。

結局誰も「C++はデバッグが極めて困難な言語だ」という命題には反論出来ないことはわかった

>>560
ちょっと待った
命題には前提があるだろ
「もし下手グラマがC++に糞コードをたくさん入れたら」という

俺自身C++グラマだけど、
IDEが使えないような状況なら「デバッグはきわめて困難」だと思うぞ。

結局>>539=>>549はフェードアウトか。

>>561
命題って言いたいだけだから、深く突っ込むとヒス起こすのでは。

>>562
でも自分はJavaでもC#でも同じことを感じると思う。

>>565
動的なディスパッチがある言語(C++, Java, C#)は
ソース見ただけだと、次にどこに行くのかわかんないからねえ。

だからまずデザパタを理解しろって
話はそれからだ

デザパタ万能論者か

なんで唐突にデザインパターンに話を逸らそうとするんだろう。

>>566
on the flyでswitch文に変換して表示してくれるエディタを開発すればいいのだ

>>562
gdbなめんな
慣れれば超便利だぞ

よく考えるとgdbは超便利ってほど便利でもないような気がしたが
まあ普通にデバッグでやりたいと思えることはちゃんとできる

この前、久しぶりにCでコードブレーカってゲーム作る機会があって、
がりがり書いてたんだけど、後で見直したらスパゲッティだった。

で、気が向いてC++に移植したんだけど、ずいぶん見通しが良くなってコードも短くなった。STL使ってるが。
コードを解くAIもクラスに分離できたし、いいことしかなかった。そんな趣味グラマ。

っていうかね、C++から離れられん体になってしまった。
クラスのいいところは、Length()とかSize()とかIsEmpty（）ってメソッドが直感的に使えること。回りくどくない。リードオンリーだし。
不満は参照が固定されることだなぁ。ポインタ見たく挿しかえれないのが最初戸惑った。

>>570
マジで頭いいな！
と一瞬思ったけど、すぐに、Cのコードをcppでマクロ展開したときの
苦い思い出が頭をよぎったよ。

なんか「最強の格闘技は何か？」って議論に似てるな。
結局使う人次第でしょ。

そういう時は、素直にポインタ渡しでいいじゃん

>>576
そうかもしれん。。。

どれが呼ばれるか、なんて、ステップ実行すればすぐ分かる事。
デバッガが無いなら typeid でも出力すればいい。

>>573
file.open("r")がopen(file,"r")より読みやすいとはどうしても思えない

メンバ関数って結局は仮想関数の都合で第一引数を特別扱いしてるだけだろ
そもそも読みやすくするための構文じゃないと思うんだけど

特定のオブジェクトに関する情報を、限られた範囲の関数でグローバルに扱うものです。

>>556
継承やオーバーロードが追えないとか言うからクラス図を書けといったのに、
今度はメモリリークですか。
やれやれ。
話を逸らさないと都合が悪いようだな。

>>579
そんな貴方にscheme

>>573
えーっと、何かを開くときは、コンストラクタで指定するのがほとんどなんで、そういう奇妙なことにはならんと思うよ。
std::ifstream ifs（Path）;
で開ける。開いたかどうかは、isf.is_open（）；で一発。読み取りはこれでok。
もちろんifs.open（Path）;ってこともできる。
ちなみに書き込みは、
std::ofstream ofs(Path);〜。
でOK。

俺の場合だけども、基本的にカウンタ以外の変数の使いまわしはしないなぁ。

>>579
操作の主体となるデータがはっきりするから
OOの方が分かりやすいと思うが。
というか、ファイル名はどこに指定するんだ？ それは。

>>584
ファイル名用の引数忘れてた…気にしないでくれ

それはそれとして、fileは操作の主体じゃないぞ
ファイルディスクリプタはファイルから中身を取り出すためのトンネルであって主体はあくまでファイルの実体
だからたとえばreadはfileを読むんじゃなくてトンネルに手を突っ込んで中身を取り出す操作なんだから
file.read()よりread(file)の方が間違いなく的を射てる

OOってその辺の混同を招くから気持ち悪いんだな、うん

>>583
カウンタも使い回すか？
その都度、forで宣言するだろ。

OO表記をdisりたいんなら
file.read()とかよりバイナリメソッドを例にとったほうがいいよ

"".equals(s)とかs.equals("")とかいうやつね

>>585
まあ、一口にOOといっても、Common LispのCLOSみたいなのならそういう気持ち悪さは無いが

>>585
ファイルディスクリプタの先にあるファイルそのものも
カプセル化により抽象化して内包してしまえるのだよ

>>587
バイナリメソッドは実はそんなに気にならないなぁ
"".equals(s)は「.equals」って演算子みたいに見えるから
二項演算は操作が真ん中にある方がしっくり来る

File1にFile2が出たら

C++なら
file1.read()
file2.read()
と書けるけど
Cなら
read_file1(file1)
read_file2(file2)
になる。
オーバーロードできないといちいち名前変えなきゃいけないから気持ち悪いんだな、うん

>>590
本来対等である2項演算子のoperandのどっちかを無理やり「receiver」に
見立てなきゃいけないのは不自然だと思わないの？

Lispなら常にoperatorが前置でoperandは平等かつ何個でも置けるね

>>589
それが嫌なんだよなぁ
オブジェクト指向ってそういう風に「同じようなものに関わってるけど、実は微妙に違うもの」ってすぐ隠蔽しちゃうじゃない
実はその微妙な違いが大事だったりするのにさ

下手に隠蔽するから、いざ区別が必要になった時に微妙に違うクラス作り直すことになって
同じような名前が付いてて同じような機能持ってて……ってありがちじゃん
元々別にしてりゃよかったのに

オブジェクト指向教信者に何を言っても無駄だよ。
こいつらは批判精神なんてとっくに失ってる。
何も考えずにオブジェクト指向を信仰してるだけなんだから。
出現からこれだけ時間が経って、これだけ成果を挙げていないものを
いつまでも信じるなんて信仰以外の何物でもないよ。

>>593
自分の無能さを言語のせいにしてると、いつまでたっても成長しないよ。

>>586
たまーに、必要になるときがあるんだわ。基本的にはそのつど宣言するのだけども。

>>593
C++の標準からしてそうじゃん…
stringとstringstreamとかさ
ただのchar[]に大げさな名前と機能付けて似たようなもの2つも作ってアホかと

vector<char>もあるぞｗ

>>598
それはバイナリ配列でしょ。

stringとstringstreamが同じようなものって、どういうこった。

C のようなバッファとサイズを渡して結果を入れてもらう関数を使うときは
vector<char> を使わざるを得ないんだよ、現状では。
そのうち string 使えるよう保証されるようになるけど。

stringstreamはsprintf相当のもので、std::stringはコンテナだよ。

>>601
奇妙な設計に見えるなぁ。
Cとの互換性のためって言うならそういうのもあるんだろうけどさ。やったことないや。

ガタガタぬかさずに使えや
C++に文句言ってる奴はC止まりの奴に決まってる

>>604
なぜかC++信者はCをよく理解してない分際で「C止まり」などと見下したことを抜かすんだよなあ

>>605
何を抜かすか
俺はC89の規格が決まった頃からずっとCを使っている
いわゆる両刀使いだ

>>603
現状の規格では string の内部バッファは連続領域とは限らない。
だから規格に厳密に従うなら、string をこの目的で使う事は出来ない。
昔は vector もそうだったが、2003年に改善された。
string も次期で改善される予定。
まあ、実際に string の内部バッファが連続領域でない実装なんて知らないけど。
data() や c_str() の実装の手間を考えると当然だろう。

>>607
なるほど。

>>590
そういえば、s.equals("")なら許せるけど、Javaとか（C++も？）
定数文字列を先に持ってくる奴が多いんだろう

C言語でも、if( 0 == p ) みたいにひっくり返す馬鹿がいるけど、
== を = と書いたことを検出できる、とか言い訳にもならない

>>609
javaのは、sがnullでもヌルポが発生しないってことらしい。
ダメテクニックだな。

ifがbool以外をとるのがダメなんだろうけどさ。
明示的にboolにキャストが必要とかすればp=0とかしようが間違えないわけで。

間違って=と書いた日の問題箇所特定の難しさを知らんとしたら、かなりの幸せ者だ

　　　　　　　　　 ＿
　　　　　　ミ　∠＿）
　　　　　　　　　/
　　　　　　　　 /　　　＼＼
　ｳｲｰﾝ　　Γ/了 　 　 |　|
　　ｳｲｰﾝ　 |.＠|　　　　|　|　ｶﾞｯｶﾞｯｶﾞｯ
　　　　　　　| / | . 　 　 人
　　　　　　　|/　|　　　 < 　>_Λ∩
　　　　　 ＿/　 | ／／. Ｖ｀Д´）/>>610
　 　 　　（＿フ彡 　 　 　 　 　 /

>>612
ふつー一発でわかります。

>>610
なるほど・・・

>>614
実務経験無い人は、無理にレスしなくていいよ

>>614
スーパーハッカーですね

=と==の間違えを見つけられないような人が実務やってるんですか。

コンパイラが指摘するだろう。
Java/C#ならエラーだし、C++だって警告くらい出すぞ。

>>619
そういえば、C#やjavaでも定数を左のおくスタイルの人っているけど、
ああいうのは、意味を分かってやってるのだろうか。

そういうまあ過去のテクニックというか文化はどこから新世代の言語に伝搬するんだろうな

まったくもってC++信者に説得力がない。
中規模クラス以上の開発で責任者やったこと奴いないの？
すくなくともデメリットくらい語れないと話にならない。

無能じゃんって罵ってればプロジェクトが収束するなら一日中罵るわｗ

警告を出さないようにコードを書くって、当たり前のことをやってない人が
実務に携わって、しかもけっこうな規模をやってるって事実のほうが怖い。

C++語っちゃうようなやつにもいるよね
そういう奴とは二度と一緒に仕事しないけど

定数を左に置くスタイルの人って、本を読んだり職場以外のコードを読んだりとかしないのかね?

意味わからなくてもエラーが出て安全だろ。

でも職場のコードよく読んでるやつのほうが一冊の本で頭よくなった気になれる奴よりまし。

参考になるコードなら良いけどな
俺の職場のコードは腐ってる
読めば読むほど何も考えてないことが伝わってくる
まさにウンコ

でも職場の代々受け継がれてるクセの濃いコードしか読んでないから、
定数を左に置くのがいいとか思っちゃうんでしょ?

いまえらcppファイル１０００個以上、合計１００万行以上のプログラムの実装・管理を
やった経験くらいはあって語ってるんだよな？

>>625
そんなんじゃ気が付いたら回りに誰もいなくて君一人だね

>>632
警告すらも理解できない奴ばかりなの？

>>633
現実を見ようよ
そんな立派なグラマばっかりいないから

こえ〜ｗ
さすがにこええ
警告をエラーにすればいいんじゃないの？
とんでもない回避されるけどｗ

それで、
誰かLinusの書いたC++のコードを見たのか？

>>631
スタイルの話題になると「俺は経験で」で言い出すやついるけど、
匿名でそれやっても、論拠にならないよ。

俺がみたいくつかの大規模で世間で評価されてるプロダクトのソースは
定数を左におくスタイルは採用してない。

見た程度のレベルの人がなに言ってもねｗ

経験も本人談だし。

LinuxカーネルやGCCだってコンパイルするとボロボロ警告出てくるぜ…

実績ある奴の経験談と本読んだ感想が同レベルだとでも？

実績ある人のコードを読んだら、定数を左に置くスタイルじゃなかったから。
自称実績のある人じゃなくて、本当に実績のある人の。

本人連れてきて書き込ませろよ。
本当に出来る奴ならどうでもいいって言うと思うぞ。

まあダメな奴はコーディングルールをいくら用意しようが無駄だからな

本当に出来る奴は面倒ごとを機械に任せられる奴
=を書き間違ってないかのチェックなんてコンパイラに任せればいいんだから左に定数を書くのが正しい
本当に出来るならそう言うはずだ

>>643
そんなことはない。
定数を左のスタイルの話題は昔からある話題で有名で知ってる人は多い。
で、そのスタイルが少数派ってことは、どうでもいいじゃなくて、知ってて採用してないってこと。

論理学から勉強しなおせ

でもどうしても気持ち悪いなら無理して左に書いて生産性を落とさなくてもよい
と付け加えるのが真のプロフェッショナル

ワーニングですらそんなものないのに何でかたくなに否定するかね

定数を右に置くのは可読性のためだろ
一通り書いてテストしてる間は左に定数置いて
リリースする時に==の両辺を入れ替えてるんだよ
grepで一発だし==なら入れ替えても意味が変わる心配はない
みんなそうしてると思うんだけど

動いてるソースを改変するなんてバカだろ

つリファクタリング

==の両辺の入れ替えに意味の変化は一切ないから改変じゃないよ
&&の入れ替えならダメだけど==は評価順不定だから

有名書籍とか有名プロダクツのソースとかで、定数を左におくスタイルのやつがあったら、
これって例をだしてみればいいのに。
名前の出せない「俺がやった大規模プロジェクト」以外にもあるんでしょ?

if( a(1) == a(2) ){}

int a(int v){ static float s = 100; s /= v; return s;}

俺どっちでもいいから気にしたことないけどいくらでもあるんじゃないか？
それ縛りのコードは少ないだろうが。

意味が変わるかどうかではなく、手を入れることがバカだと言っている

653涙目ｗ

>>656
こんどから注意してみてみたら?
すごい少数派だと思うよ。

>>655
不定だな
if( a(2) == a(1) )だとしても不定には変わりない
意味も動作も変わらない

>>660あきらめろ

戦争をワーとか言い出しそうな人が紛れ込んでるな

お前の思い込みなどどうでもいい

"".equals(s)とs.equals("")では意味も動作も違うと思うのだが

if(0 == 5 == 3 == 5) printf("== 5 == 3 == 5 ==\n"); /* == 5 == 3 == 5 == */

grep一発でどうやるの？

まさかとは思うけど
655のコードでif( a(1) == a(2) )なら偽でif( a(2) == a(1) )なら真になるとか
思ってる輩は紛れてないよな？

あまりいじめんなよ。
人とプログラム書いたことないんだから。

アホが涙目ｗ

>>666
まさかとは思うけど、お前はそうじゃないと思ってるの？？？
幼稚園からやり直せ

int a(int v){ static int s; int t; t = s; s = v; return t;}

if( a(1) == a(2) ){}
if( 1 == a(1) ){}

>>650
そんなアホな。
エンバグが趣味なんですか？

左定数厨はプログラムが上から順番に実行されることも知らんのか

釣り宣言まだぁ？

コーディングルールとかコーディングスタイルってのが流行った時期があるから
メジャーなスタイルで定数を左辺に置くのもあると思うんだが、ちょっとぐぐった程度じゃでてこないな。

バカにしてるやつは若いヤツなんだろうけど、コンパイラがウンコな時代には役に立ったものだよ。

>>670で結論出ただろ。

>>670のa(1)とa(2)はどっちが先に呼ばれるかわからないから不定だな
if( a(2) == a(1) )だとしてもa(2)とa(1)のどっちが先に呼ばれるかわからないから不定だ

不定って言えば逃げられるとでも思ってんのかｗ

お前のプログラムの動作が不定なんだろｗ

670でa(2)が先に呼ばれるわけないだろｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
もうやめとけってｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>676
不定ではあるが、「==のLHSとRHSの置換が常に等価なので置き換えても安全である」
という間抜けな主張への反証としては十分過ぎる例かと

コンパイラがウンコな時代とか時代背景があるならわかるんだが
今なお使っている奴はなんなんだという

左辺に定数置くとウォーニングでんのか？

左辺に定数を置いたらダメな理由が不明すぎ。

自分のスタイルと違って見づらいっていうならまだしも、かっこ悪いとか時代遅れとか？　死ねよ。

>>682
if (x = y) {..}
とか書くと今のコンパイラは大抵は警告を出す
が、別に比較式はif文だのwhile文だの中でしか使えないと決まっているわけではない

なんだ、本物のバカばっかりか
http://www.kouno.jp/home/c_faq/c3.html#4

>>680
a(1) == a(2)もa(2) == a(1)もどっちも「不定」という意味で等価
どっちで書いたとしてもどっちが先に呼ばれるかわからないんだから

つーか
"".equals(x)
と
x.equals("")
は意味が違うだろと

前者はreceiverがStringであることが確定している式で、xがnullでもよい
後者は確定していない(nullかもしれない）

本当は、二項演算をこのような形でしか書けないJavaがよくない

お客に「前から動作不定だったんですよ！」って言い訳するの？

馬鹿はお前。言い訳になってない。

>>687
入れ替えようと入れ替えまいと、コンパイラのご機嫌で評価順なんていくらでも変わるんだから
遅かれ速かれ言い訳することになるだろうね
あんなコード書いてたら

で、grep一発の件はどうなったの？

>>665は？

お客に「悪いのは僕じゃない！」って言い訳するの？

>>685
またひどいリンク見つけてきたな

＞f() + g() * h()
＞
＞掛け算は足し算の前に起こるということはわかっているけれど、3つの関数のうちどの関数が最初に呼ばれるかはわからない。

そんなわけねーだろｗｗｗ

動作不定がコンパイラの機嫌だと思ってるのかよ！！！

入れ替えてバグが出るようなコードは
たとえ入れ替えなくてもちょっとした弾みでバグが出るんだよ

だったら入れ替えても入れ替えなくても同じじゃないか、と言ってる

恥ずかしすぎる。

>>693
機嫌だよ
極端な話、コンパイルごとに評価順変えたっていい
それが不定（unspecified）の意味

Javaは左辺を先に評価すると決められてる
左辺から評価するのが普通だろ
わざわざ右辺から評価する変態コンパイラがあるわけがない

本の知識だけで本物のコンパイラを知らない子供が不定不定って騒いでるんだな

規格票に不定と書いてあるんなら規格票が最優先だばかものども

>>698
帰れよ

ついに反論も出来なくなったかｗ

これに懲りたらもう二度と勝手に左辺と右辺を交換するなよ
評価順が変わってみんなに迷惑かけるからな

>>692
さすがにランダムで順番決めるわけじゃないよ。
その文章は、コンパイラが違ったり、同じコンパイラでも最適化とかのオプション次第で変わるよと言う話。

>>692
激ワロタww

おまえら if (3 == a) の件で騒いでたのか。暇だなあｗ
これって誰かが「こう書けば間違って(3 = a)と書いた時検出できる」って提唱して広まったんだけど、
○"=="以外では意味が無い
○"=="でも定数相手以外では意味が無い
○直感的でなく読みにくい（人間は「aが3と等しければ」と思考する、逆はあまり得意ではない）
という理由から言うほど広まらなかったんだよな。
意外に、直感的でないというのは大きい理由で、流して読んでるときにこういう箇所で「ん？」って
止まっちゃうのって結構思考の邪魔になる。
今でも頑張って「3 == a」って書いてる奴はまあ、頑固というか論理的すぎるというか形式主義
というか、要するに「感覚」より「論理」の方が大事な奴なんだろうな。
コーディングやってると「感覚」を妨げることの方がよっぽど作業効率を落とすと思うんだけどね。

普通は = にしても警告出るから a == 3 で全く問題ない

わたしも昔は、定数左派だったが、いまではコンパイラが警告出してくれるので、どちらでもよくなった。
強いて言えば、読みやすい方(例えば右側)に書いている。
if ( foo >= 0 && foo < 256 ) よりも if ( 0 <= foo && foo < 256 ) の方が、読みやすいから、
こういうときは、左に書いている。まぁ、今回の話とは関係ないことだけど。

そろそろ、C++プログラマはウンコの話に戻せよ。

＞if ( foo >= 0 && foo < 256 ) よりも if ( 0 <= foo && foo < 256 ) の方が、読みやすいから、
こういう、数直線のイメージに拘ると称して意味不明な理屈を振り翳す奴ってよく居るよね。
前者なら「fooがゼロ以上で256未満」と素直に読めるのにね。

わかるなー
if ( 0 <= foo && foo < 256 ) がif ( foo >= 0 && foo < 256 ) より読みやすいとは一切思わないね
まあこっちはそこまで読みにくくもないけど、
これの否定をif ( foo < 0 || 256 <= foo ) とか書かれると最悪なんだよ
こっちに関してはif ( foo < 0 || foo >= 256 ) の方が圧倒的に読みやすいに決まってるのに
数直線にこだわる奴は数直線で思考止まってるんだよね

だからコーディングスタイルの話は他のスレでできるだろ。
ここはうんこのスレなんだからそれらしくだな

ほんと簡単な話題だとくいつきがいいよな
左定数なんておまえら何回同じ話してんだっつーの

自転車置場の議論ってやつだな。
ttp://0xcc.net/blog/archives/000135.html

C プログラマは下らない議論でしか盛り上がれないからな。

だな
C言語は文法が簡単なので雑談に流れやすい
C++になると言語仕様そのものが難解になるので雑談している暇がない

と言ったところか

C++の言語仕様が難解ってどんだけ馬鹿なんだよ。

C++の言語仕様が難解じゃないって言ってるってどんだけ馬鹿なんだよ

バカばっか

>>714
こういう奴にboostのソースを全部読み解けるかたずねてみたいものだ

boostが難解なのであってC++の言語仕様が難解なのではない

また言い訳始めよったか

boost自体のソースはきれいに出来てるじゃないか
むしろboostを使うと

言語仕様の話してんのに boost 持ち出すとか、どんだけ莫迦なんだろう。

>>713
えーと、難解だから偉い、と言っているんでしょうか？

>>707,708
Pythonで普段
if 256 <= a < 4096:
pass
って書いてたら、他の言語でも自然に 0 <= a && a < 256 って読み書きするし、普通に読みやすいよ。

brainf*ckやwhitespaceのコードを読めばわかるが
言語仕様が単純明快でも高可読性には必ずしもつながらない

>>708
否定するときは直感的に否定で書こうぜ。無理に or に書き直す必要は無い。
if ( !(0 <= foo && foo < 256))

それならまだ
　if (〜)
　　;
　else
の方が…つか、style ｽﾚでやれと。何度も。

>>725
Pythonは所詮スクリプト言語だし、効率なんてどうでもいい所で使うもんだからそれでもいいけどさ

if ( 0 <= foo && foo < 256 ) の書き方のもう一つの最悪な所として、柔軟性が全然ない
たとえばfooが負になることが滅多にないとすると、当然両辺の入れ替えを考えるわけだが
このまま入れ替えるとif ( foo < 256 && 0 <= foo ) という壮絶な式になってしまう
数直線にこだわるならif ( 256 > foo && foo >= 0 ) になるが、数直線としても向きが逆だし
ただ両辺を入れ替えるだけなのに全部書き直しだ

最初からif ( foo >= 0 && foo < 256 )ならそんなこと考える必要もないんだぜ

何が壮絶なのやら

>>727
>たとえばfooが負になることが滅多にないとすると、当然両辺の入れ替えを考えるわけだが
おれはそんなこと考えないから数直線で良いや。
いい加減、個人の感性の問題で、お前の感性に根拠なんて無いことを自覚しろ。

Cプログラマって本当に暇なんだな

C++って難解なんかい？

うわこれすげーおもすれー

>>729
おいおい…&&は偽になりやすい順に、||は真になりやすい順に並べるのが当たり前だろ
そんなことも考えずにC使うなよ

>>729
短絡評価(short circuit)って知ってる・・・よな？

比較回数減るから速くなるって言いたいんだろ、知ってるよそんなもん
だがそんなのはコンパイラが最適化の時に決めるもんであって人間様が気にすることじゃない
可読性の方が大事

>>734
コンパイラに期待しすぎ

if(0 <= a && a < 256)
のときに
0 <= a の方が
a < 256 よりも
先に評価されるのは仕様で決まっていますか？

>>734
ショートサーキットに反するから絶対にひっくり返してはくれないよ。

まあ、そもそもこんなところを手動最適化したところで
効果なんてたかが知れてる。
基本的に全部読みやすく書くべき。

>>736
それに依存した書き方がされているのが当然だから
バグ入れるなよ

>>734

バグニモマケズ
副作用ニモマケズ
標準ニ準拠シ
プログラマノ意図ヲ汲ンデ
空気ヲ読ンデ
適切ナ方ヲ最初ニオイテクレル
ソンナコンパイラニ　私ハナリタイ

無茶言うなよ(笑)

>>739
その「副作用」は意味合ってんの？

if ( foo >= 0 && foo < 256 ) のどこに副作用があるんだよアホか
（fooやifが変なマクロってのはなし）

>>741
ああ、そこは一般論の話。
変数なら副作用は無いけど、↓

「リソウノコンパイラ」なら
hoge()>piyo()&&foo()==bar()
とかにも対応しているんじゃね？
そのときはきっと
プログラマノ意図ヲ汲ンデ
副作用がおきないことを（リソウノコンパイラが）理解した上で
空気ヲ読ンデ
適切ナ方ヲ最初ニオイテクレル
ソンナコン…(ry

っていう意味。
説明不足すまそ

min < a && a < max みたいな上限と下限を指定する比較って
そもそもあまり書かなくない？

思い起こすと、C言語を覚えたばかりの頃はよく使っていて、
Pythonみたいな min < a < max があればいいのに、と思ったけど
今は全く使わない。

経験を積むと自然と使わなくなる書き方じゃないかなあ・・・多分

エラー処理とか全くやってないのか

入門者の頃と違って、エラー処理をちゃんと考え出すことも
そういう単純な範囲比較をしなくなる理由のひとつだろうね

もちろん単純に上限下限でくくって済むケースもあることは否定しないよ

>>741
bool operator&&(int a, int b){printf("バカ\n");return 0}

いや、沢山あるだろう・・・

もちろん単純に上限下限でくくって済むケースもあることは否定しないよｗ

プラスαがあっても上限下限でくくる部分はそう書くね

くだらないことをさも意味があるかのように話すからよってくるなって言われるんだろうな

>>746
それはさすがのC++でも許してない

>（fooやifが変なマクロってのはなし）
つ「演算子のオーバーロード」

DDR3は待たなくてもいいっぽいな。

ttp://www.age2.tv/rd05/src/up3543.jpg
ttp://www.age2.tv/rd05/src/up3542.jpg
ttp://www.age2.tv/rd05/src/up3541.jpg
ttp://www.age2.tv/rd05/src/up3540.jpg

guro

intとintの演算はオーバーロードできないぞ
それやるならこうしないといけない

Bar operator>=(Foo, int){/*...*/}
Bar operator<(Foo, int){/*...*/}
bool operator&&(Bar, Bar){/*...*/}

int が別の型に置換されるマクロかもしれないじゃないか

なるほどその発想はなかった

IsRangeとかテンプレートでつくれよこのウンコやろう

OrangeRange

Boostにintervalといううんこがあるよ

Boost Interval Arithmetic Library
http://www.boost.org/doc/libs/1_37_0/libs/numeric/interval/doc/interval.htm

#define int char
#define private public

C++の優れている点
◎bool型
◎文字定数がchar型 (Cだとint型)
◎namaspace
◎メンバ関数 (structスコープ内限定の関数を宣言できる)
◎inline関数
◎引数省略時の解釈。 int f( ); が int f( void ); と等しい。
　Cだと引数は任意の意。

○static_cast等の新形式のキャスト (もっと短くして欲しいが…)
○デフォルト引数
○structがスコープを持つ。
　Cだとstruct内にstruct等を書いてもグローバルスコープ。

△参照
△変数の宣言がブロック先頭に限定されていない

まとめると
「型・スコープがより厳密になった一方で、記述の柔軟性がUP」
ですかね。

for (;_;)//~~

while (T_T)//~~

ここでアセンブラ廚の俺が登場
素直にLisp使え

まずはLispでカーネルモジュールあたりを作ってから口出してもらおうか。

そういえば「出刃どらはC++で書きたい」というようなスレがLKMLであったような。

テレビの制御モジュールではダメかね？

デフォルト引数は手抜き野郎がチェックせずに関数仕様を変更する温床にしかなってない気がするんだが。

デフォルト引数より名前つき引数をサポートしてﾎｼｨ

>>768
これは同意
とはいえ、全ての関数呼び出しに名前付けろとか言われると
やりきれないけど

クロージャが匿名クラスなら
名前つき引数は匿名構造体か

最近のgccだと

　foo({.hoge = hogedata, .fuga = fugadata});

とかいけるんだっけ？

hoge、fugaの型は？

ほんとにできたよな、と試してみた。

#include <stdio.h>
struct hore { int hoge, fuga; };
void foo(struct hore *data) { printf("hoge=%d\n", data->hoge); }
int main(void) {
　foo(&(struct hore){.hoge = 1, .fuga = 2});
　return 0;
}

多相関数なんてないんだから、キャストなしでも警告程度で自動型判定して
くれてもいいんじゃないかとオモタ。

>>771,773
C99からできるようになったんだよ。
前は、GCCの拡張だった気がするけど。
まぁ、それ使い出すともうC言語じゃないと思っているから、いまだに実際に使ったことはない。
いまだに、C89でも通るように組んでいる。(というかむしろ-std=c89 -ansi -pedanticでコンパイルしている)
#if (__STDC_VERSION__ >= 199901L)で、inlineとかrestrictとか使うようにしている。
可変引数マクロを使いたいと何度思ったことか。全ては、C89で通るように。

それ、名前付き引数じゃなくて、複合リテラルだろ

ちなみに、C++0xだと初期化リストでfoo({hogedata, fugadata});と書けるようになるはず。

むしろ、C99,gccマンセー。

>>774
可変引数マクロは最低限２つ引数がないと使えないという糞仕様なので
使わなくていい。なんでgcc拡張をそのまま採用しなかったのが意味不明。
C89で通したいならMACRO(())で今後もやるしなかいな。

>>778
引数2つってどういうこと？
http://seclan.dll.jp/c99d/c99d02.htm#dt19990405
ここにはこういう例が載っているけど。
#define dbg(fmt, ...)　\
　printf("debug:" fmt, __VA_ARGS__)
#define adbg(...)　　　\　//(1)これもOK
　printf("debug:" __VA_ARGS__)

>>799
あれ？前試したときは

#define HOGE(FMT, ...)

みたいに一つは置石がないと ... を続けられなかった記憶があって
そう書いたんだけど、... 単品で通るね。

スマン、嘘情報でした _O_ （トンクス）

C最強だろｗ
C++とかコロコロ言語仕様変わるし
糞仕様のオンパレードｗ

と、C++に挫折したCプログラマが負け惜しみを呟いております

Cで数十万行のものとか扱ってるけど
その8割方はschemeのコードから自動生成したものだったりする
Cはこういう使い方も比較的楽できるからいいね、C++でやろうとしたら
数倍難しい

Cのコードを吐けるなら
C++のコードも吐けるだろ
ほぼ同じで動くんだから

Cが低レベルな言語だから高レベルな言語からの変換がしやすいだけでしょ。
コンパイルができるとCに変換できるはほぼ同義じゃねーかよ。
パラダイムの違う高水準言語同士で機能をフルに使った変換とか難しくて当然じゃねーかよと。

>>762
template もあるんじゃね

>>783
それなら全部schemeで扱って、コンパイルのときだけCにすればいいってことだね。
つまりscheme最高ってこと？

>>787
8割って書いてあるだろ。
それを無理矢理10割にしようとした結果が、C++のようなモンスター言語だ。

まぁ確かに最近のC++はメタプログラミングに力入れてるね

C++は糞言語
これだけはガチ

その糞を拭えば、コアはすばらしく良い言語なんだよ
Cの膨大なライブラリもそのまんま使えるし
糞の上塗りさえやめてくれればいいんだけど

糞は糞
C++はRubyよりも狂信者が多い
異端宗教者の集まりだしなｗ

根拠のないアンチC++も多いってことは分かった。

信者でもC++を他人に薦めるようなのは少数派だしね

いや糞がついたものは洗っても食わないだろう普通

都会の人間は堆肥を知らない

江戸は、糞の再利用にかけては今も昔も世界最先端都市だったのになあ
潔癖症は中国農薬野菜でも食ってろ

・メンバ関数
・アクセス修飾子
・new/delete演算子とこの２つだけの演算子オーバーロード
これだけでいいよ。継承は単一継承ならホントはあってもいいけど
継承を乱用する奴多いから要らないかな・・・

ベースはc99ね

テンプレートも入れといて。

テンプレートも乱用されるからね・・・

継承よりは副作用がないと思うんだ。

なんでそんな四則演算のオーバーロードをいやがるん。
ベクトルとか行列とかクォータニオンとか複素数とか扱ったことないわけ？

>>803
意味無いし生産性悪い書き方だから
排除すべきだろ

そんな特殊なケースのみを言語仕様に盛り込み
たがるアホがC++に多い影響でC++自体が邪教の
産物になってしまっただろ。
次期C++仕様もboostの製作陣から糞過ぎるって
痛烈に批判されてるしなｗ

宇治社中で学んだ口だがオーバーロードいらん

haskellみたいに関数を演算子として適用する明快な方法を提供していれば
また状況は違ったかもしれないが、

>>803-804
意味はあると思うけど、指針が無くて個々人の感性に任されるから、
乱用されて他人から見たら直感的でない、ってケースがありすぎる。

結果、いっそ排除した方が良いというハメに。

Prolog みたいに演算子を好きに定義できる言語もあるんだし
このくらいなんてことはないよ

Prologで大規模開発してから言ってくれ

演算子オーバーロードが無かったら…
stringとかvectorとか、めっさ使い勝手が悪くなると思うけど。

　record = name + "\t" + address + … ;

とか書けてたのが、↓になっちゃうんですが。

　record.assign( name ).append( "\t" ).append( address ) … ;

そんなのどうでもいいというか良く使う機能で慣れてるから違和感ないだけで
慣れてなければPerl並に可読性悪い。

演算子多重定義は要るよ派だけど、
C++のostringstreamとC#のStringBuilderでは後者のほうが使いやすいと思う。
そもそもiotreamの<<と>>が終わりの始まりだったな。

記号地獄はもういやです

CのDLL -> C++/CLIのDLL -> C丼のＧＵＩ
の構成でC++/CLIを使ってみた。
変態言語だと思った。

いや、C++は好きなんだけど…
スレ違いか・・・

文字列の連結は + で行う言語が主流ではあるけど
& で行う言語や . で行う言語もあるんだよな。

>>810
> 　record.assign( name ).append( "\t" ).append( address ) … ;

record = name + "\t" + address + … ;
⇔ (python)
'%s\t%s' % (name, address)
⇔ (python)
'%(name)s\t%(address)s' % locals()
⇔ (glib)
g_strdup_printf( "%s\t%s", name, address);

>>810
sprintfも知らない奴は発言するな

>812
iotreamがC++入門者への糞設計洗脳プログラムとして作用してる。

自分の頭が悪いだけなのに無意味な仕様って
テレビと同レベルだな

お前ってテレビ大好きだなｗ

>>812
その二つは用途が違うだろ。
C++のstringはイミュータブルじゃないからstringbuilder系のクラスいらないし。

文字列の連結に演算子が要らない言語もあるね。
他の言語がどうだってのは余り意味がないよ。

LinuxがC++不要言ってたんだし
2chのC++関連のスレ潰していこうぜ

半端なとういうか
わからないならおとなしくbetterCとして使ってればいいのに
ヘタに手を出してクソコードを生み出してる奴を叩いてるのであって

そりゃ、Linuxの開発にC++は邪魔だろうな。
Cはヘッダ共有しなくても、関数引数リストがわかっていれば他人の書いたソース・オブジェクトと連携できるが、
C++はヘッダ共有しないと話にならないし。
最初から統一された設計の下に作るならC++がいいが、大勢の思いつきの寄せ集め的開発手法にはあわんわな。

名前マングリング位統一しとけよハゲ

ということか

Linusは2ちゃんの味方。
彼はレベルが高いよ。

>>803
ないんだろうな。数学コードまったく書かない文系なんだろ。
「特殊なケース」とかアホすぎる。お前ゲーム一切やるなと

記号のオーバーロードがどんなに危険か想像つかない奴は幸せだよ
たいしたコード書いてないって自分で白状してるようなもんだ

ゲームの場合は計算量を抑えるために
演算子オーバーロードを敢えて使わないケースもあると思う。
a = b * c; とか、無駄なテンポラリオブジェクトを作って、
そこからの代入が発生してしまうので、
これが行列だったりしたら結構無駄が多くなる。
Matrix a = b * c; なら最適化効くからいいけど。

演算子オーバーロードはもっと計算量がシビアに効いてこないプログラムや値で
使った方がいいと思われ。
まあ、分数や複素数程度ならいいんじゃない？

つ Expression Template

もう好きにすればいいじゃないか。
C++が使いたい奴は、勝手に使ってもらって構いません。
わたしとあなたが出会わなければいいだけです。

C++の演算子オーバーロードは、抽象データ型を直感的に(原始データ型と同じように)扱うためにあるんだよ。
演算子オーバーロードをしないのであれば、別にC言語で十分同じようなことはできる。
TMPは、したいと思うけど、あれはコンパイラががんばっているだけだから、
何か取り決めを決めて、Perlを通して、C言語を吐かせた後にコンパイルすれば、どうにでもなる。

複雑な計算式になると、関数呼び出しだけじゃ訳分からんことになるので
演算子オーバーロードは貴重だぞ

>>833
計算はFORTRANだろ、常考

＞出会わなければいいだけ
まったくそのとおり。
勝手に演算子オーバーロードでも使って、見た目キレイに書いて、
バグが出た時には勝手に死んでくれてればいいんだが、
オレのコードにそんな不便なものを混入されたら迷惑なんだよな。

まぁぶっちゃけ演算子オーバーロードは
文字列と数学系以外使わないからどうでもいい

あとはboostが変態的な使い方してる位か

つうかC#にもあるんだがそれには文句ないのか

1 * 2は*(1,2)っていう関数適用の構文糖衣
ただその構文糖衣に「かけ算」っていう暗黙の解釈が存在するのが混乱の元になってるんだろうよ
オーバーロードなんて((Int,Int), *)と((MyT, MyT), *)っていう代数構造を示す組が同時に存在してるだけじゃん
それに伴う暗黙の変換は場合によっちゃ厄介だけどさ

>>835
数値クラスの場合は関数で書いた方がバグは多いと思うぞw

バグを減らすなら暗黙の型変換を一切禁止しちまえばいい

バグが出やすい出にくいの話なんてしてないよ。
バグった時にひどい目に逢うと言っている。
演算子オーバーロードだけじゃない、継承もそうだし、コンストラクタもそうだし、
カプセル化と称するインターフェイスの共通化もそうだ。
オブジェクト指向はなんだか宗教みたいになってるよ。たいした功績も無いまま、
キミ達のような信者が必死に信仰してる。
そういう信者が多い方がこっちとしては希少価値が上がって助かるけどなｗ

a * b - c * d

a.multiply(b).subtract(c.multiply(d))

論理記述より数式記述のほうが直感的というのもどうかと思うが

酷い目に逢うという思い込みで語られても

メンバ関数の呼び出しも構文糖衣なんだよな
thisもパラメータであることを考慮してみると
xの型をTとしてx.fって呼び出しはcall(x,T::*f)であると考えられる

ひどい目に合うって経験談だろ。

外部関数をメンバ関数であるかのように呼べる言語もあるね

>>845
具体例を挙げない体験談ほど胡散臭いものは無い

>>847
まあそうかも知らんがめんどいしこれだけのやつらが言うって言うのも何かあるとは思うだろ。
キミはどのくらいの規模のプロジェクトをどんな立場でどのくらいやってきたんだい？

構文糖衣かどうかより、シンプルな問題はシンプルに書きたい。
その辺り C言語はバランスよく出来てる。

その意味では、string の + はアリだと思うけど
一般のクラスに対しても + を overload できるのはやりすぎちゃったよね

何年も保守されてるプログラムでも
普通に文字列の + とか使われてるが、
何の問題も起きた事無いけどな。

>>849
やりすぎとはまったく思わない。
必要ないときは使わなければ良いだけ。

そもそも隠蔽化と継承・多態はセットである必要があるのか？
隠蔽化だけならモジュールプログラミングなんだっけ？

>>851
きみみたいなのがプロジェクトで深刻な問題を引き起こしてるんだよって話

だから具体例上げろよカス

一般化の利点は取捨選択ができること
stringの+とか一部だけ許すってのは、その一部のクラスを言語の仕様に組み込んでしまうということ
特殊化より一般化

まあプロジェクトリーダーになったらわかるよ。
なれないと思うけど。

ゴミを大量生産する一般化。

>>849
言語仕様としてはアリだと思うけど。
どう使うかは設計レベルだから、言語仕様ではなく実際の運用の話になるんではないか？

それは取捨選択ができない人間が使ってるだけかもしれない、それだけの根拠で言語を叩くのは間違い
ただ、使えない人間が沢山存在するような言語である点は褒められたものではない

>>859
それは個人で使うならいいけど大規模プロジェクトでは問題ありと結論できない？
C++は当初(今も？)大規模開発での有用性をうたってたけど

そんなことを言い始めたら、どの言語も程度の差あれ、全て問題ありだろ。

MSやgoogleは、とにかく優秀な人間を集めてさえいれば大丈夫、と結論付けたようだな
他にそんなことが出来るところがあるかどうかはともかく

程度の差が問題なんだろ

だな
全部アセンブラで書くかって話だ

そこまで言わなくてもCでいいじゃん

Cなんてメモリリークさせ放題の糞言語だろ

え？ｗ

「子供の手の届くところに置いてはいけません」ってのがふと浮かんだ。

速度があまり要求されないならJava、そうでないのならC
これで十分だけどそう結論がついちゃったら一部のコン猿達がおまんま食い上げだから
C++は凄いとかLLでコスト削減とか関数型がクる！とか色々

>>867
malloc使ってメモリリークしてないプログラムを見た事が無い
Cは糞言語

メモリーリークにおいてmalloc/newに違いがあるの？
スマートポインタ云々はまったく別問題だぞ

スマートポインタ云々を別問題にされると困るんだが

まあ、C++は良くも悪くも面白い言語ではあるよ。
。。。最初だけなw

>>870
たぶん、３つかそこらしか見たことが無いんだろうな
丁寧に書けばCでもアセンブラでもメモリリークなんて起こさないよ

>>870
>malloc使ってメモリリークしてないプログラムを見た事が無い
私がいるセカイはこんなに糞なんですよ、という告白ですか。

つまりC++上で派生した技術をC++の利点として挙げているわけですね。
それは必ずしも間違ってはいないけど
当初C++がCへのトランスレーターとして存在していたことをみても
C++のメリットとは言いがたいし、そもそも組み込み系のCとかだと違うアプローチで
メモリを扱うことによって回避している。

>>874
演算子オーバーロードはちゃんと使える人が少ないから糞で、
mallocはちゃんと管理できる人が少なくても丁寧に書けば大丈夫！か。
何というダブルスタンダード。

メモリの管理もできないような人は、プログラミングしないでください。
malloc()で、メモリリーク起こす人がいるから、C言語が糞言語だと言うのは、
演算子オーバーロードで、混乱を招く人がいるから、C++が糞言語と言うのと同じだ。
使う人が問題なだけであって、それ自体は問題ではない。

特にエラー時のメモリリーク管理が出来てないプログラムが多い。
あるいは、管理はできてるけど、ifの中に毎回大量のfree書いてるような糞コードとか。

いやいやスマートポインタがあるからなんでもOK！っていうデスマプロジェクトがあってねｗ
夢の技術を妄信しておれたち頭良すぎるから納期に間に合わずバグてんこ盛りで納品！
もうあほかとね。昔から自前で回避してた技術をすべて否定して夢の技術を妄信するってどうなんかと。

多分それ、newを生で使ってもリークし放題なプログラム書くだろうな。

俺組み込み系だからよくわからないんだがスマートポインタ使えば回避できる問題ってなんなの？
newもmallocも正しいタイミングで開放できなきゃ分断化でリークと変わらず問題がでるんだが

そもそもC++は例外があるからなあ。
自分で例外使わなくても、ライブラリが例外投げることもある。
ちゃんと毎回try-catchしてdeleteしてんのか？

原理がわからないまま便利な機能だけを使ってもロクなことにならないってことだな

COMの扱いが分からずCComPtr使わずリークさせてるのもあったな

スマートポインタの仕様を使ってコードが特定の状況において、
メモリリークを発生させないことが証明できない限りは安全とか言っちゃ駄目なんだね
コメントに証明を書かないとね
でもそこまでするならコードが仕様の証明になる言語が欲しいわ

つまりくれくれ君、かつスマートポインタ使ったんだから
このバグはスマートポインタのせいだから直しませんよってスタンスなんだね。わかります。

スマートポインタって、馬鹿のための機能って感じだよね。
RAII 程度に抑えておけばよかったのに、欲張ったあげく
ポインタを完全に置き換えられるわけでもないから
結局新しいバッドノウハウを生み出している。

スマートポインタ使う時に気を回す手間で、
まともに free やdelete が書けるよ。まともな人なら

そう主張する人に限って例外安全に書けてないんだよな

プロセス終了すれば開放されるから別にいいじゃん

まともな人が書いてまともじゃない人がメンテする時もあるからねぇ。
そもそも例外とかスマートポインタを使わないメモリ管理は、free/deleteの箇所が分散して、まともな人でも見落とす／見づらいコードになりやすい。

実行中にどんどんメモリ増えたら困るじゃんw

そらスマートポインタにしろなんにしろ制限があるからね
原則として特定の状況の元、リークしない事を保証するって仕様なんだから
必要条件が満たされない状況においてはリークしない保証ができないし
だから「スマートポインタのせいだから直しません」ってのはまず無理だと思うがね

あたりまえだろ

まあGCほどオバカ仕様じゃないからね。

ＦｉｒｅＦｏｘもＧＣ採用してからアホになった

毎日再起動すればいいじゃん
みんな無駄に求めすぎ

>>897
お前はGCよりオバカそうだな。

>>898
私は君みたいにおりこうさんじゃないからね
君たちがちゃんとやってくれればいいんだよ

かしこまりました。
その代わり給料上げてね。

>>831
残念ながら式テンプレートでも、排除しきれない例がある。
ttp://d.hatena.ne.jp/Cryolite/20040513
operator =とは別に、一時オブジェクトを生成しないassign関数を用意しているから使い分けろという形。

FireFoxでニコニコ見てるときガクガクするようになったのはGCしてたからなのか

flashで動画再生するとmplayerで再生するより2倍(athlon64 3000+でのcpu使用率比)重くなる

アセンブラから上は全部構文糖なんだよ。
あの構文糖は甘すぎて不健康とか飴玉なめながら言ってんじゃねーよ、とか
思いますです。

アセンブラも構文糖だろwww

構文糖衣を全否定するならbrainfackでＣやC++と同等の生産性をあげてくれ。
C++は構文糖衣が副作用を伴いすぎてることが問題。
なかには糖衣ですらないものも。

C/C++はbrainf*ckの構文糖ではないが・・・

>>906
oh,miss spell

構文糖衣つまり、Syntactic Sugarを勘違いしてないかな。
既にある構文と完全に同じ意味の構文として置き換えることのできる構文のことでしょ。
例えば、C言語で言うところの(*(p + i))とp[i]の関係や
char a[] = {'f', 'o', 'o', '\0'}とchar a[] = {"foo"}またはchar a[] = "foo"の関係など。

>>904,905
意味不明だな。これがC言語使いの発言なら、とても恥ずかしく思う。
ああ、C++使いの発言でありますように。

>>906
Fuck you

マシン語に構文がないと思ってるのだろうか？

fuch↑you↓

フーホヨウ？

芙蓉

楓

　　　　　　　　　　　　　　　　　　　,　　-――-　　_
　　　　　　　,　- _ ニﾆ = ｰ　' ´　　　　　　　　　　　｀ ヽ ､
　　　　,　',´ｨ ' ´　　　　　　　　　　　　　　　　　 　 　 　 　 ＼
　　 ／ '／　　　　　　　　　　　　　＿＿＿　 　 ､　　　　 ､　　ヽ　／/ヽ
.　/ '´, '　　　／　　　 ,　 ,...:.:.':.´:.:.:.:.:.:.:.:.:.:.:.:.:｀:.:.:.ヽ　　 　 ヽ　 冫:;ィ::::;'　 __
　'′/　　,／　　　　 /':.:.:.:.;:.　-―¬¬¬―-　､:.:ヽ　　 　 ヽ/:／,.l:::::l':´_ハ
　　/　.,.,''　　,　　　 /:,:　'´　　　　　　　　　　　　　｀ ',　　　　',/／;:l::::;'´ /:::/
　 ,'　//　　/　　　 ,'´　　 i　 　 l 　 !　.　 | 　 　 !　　 ,　 　 　 r '´ l::〈　/::::ﾉ
　i　/.,'　　/　　　　l 　 i　 l　__tﾊ l　!　.|　t T¬ ﾄ l､　! 　 　 　ト、 !:::l /:; '
　l./ .l　　,'!　 　 　 l　 ,レ'T´　ll! !.l, l　 li. |', ﾄ, ＿!_l　｀!　 　 　 lヾ':.l::::!l::::l
　l,'　l　　! !　 　 　 !　 l',　l ,ゝｪ ､',|',l',. ! !.l　>' ,r ､ ヽ,,'l　　　　 l::ヾ:!:::|.l::::!
　　　!　 l　!　 　 　 ', . l ' / /.ｎ.',｀　.'|',|　'!　　ｌ 0 l　 '' !　　　　.l;:::l::ｰ':;'::/
　　　',　 !. l　　　　　'., ',::''::.ヽﾆ.ﾉ, .:　　　　::... ﾐﾆ'r　　l.　　 !　 ll::::ﾄ:ヾｰ'
　　　 ',　!　!　　　　　 ヽ':;:::.｀￣　　 ..::.　　　　　　　　,'　.　 l.　 !l::::! ';::':,
　　　　', l　l　 　 　 　 　 ';｀::::.. 　 .::::::'　　　　　　 　 ,'　　　l 　 !.';:::', ':;:::':,
　　　　 '.,!　!　　　　 　 　 ';::::::::...:::::::::r--ｧ　　　　 ..;'　　.l　l!　 l　';:::', l';::::',
.　　　　　　 !　　　　　l　　 lヽ:::::::::::::::::ｰ.′　　 ..::;:;'　　 l　.l!　 !　 ';:::':!,';::::',
　 　 　 　　 ! l　 　 　 !.　　!　 ｀　､:::::::::::　 ...::;:::'::/　 　 !　,'!. /　　ヽ::::':,!::::!
　　　　　　　! l　　　　.l　　.l　 !　　 ｀ヽ:､:;::::':::::::/ 　 　 !　,','./ l　　　ヽ:::';:::l
　　　　　　　l l!　 　', . ﾄ、. ﾄ、',､　　　 !:::::::::::／　 　, / .///　ﾄ、､　.l! !:::ト'
　　　　　　　l ﾊ　.　 ',　',ヽ ', ヽ',＼　　 !::::／　　 ／/／>､ ､　! ヽ!', l.l,'';;';!

もう900越えてんのかw
みんな好きだなあ

真・スレッドストッパー。。。(￣ー￣)ﾆﾔﾘｯ

止まるの?

>>917
この景気だし暇なんだろ。

Linux is obsolate!
Linus is 釣り師!

>>916
誰だよw

>>914,915

糸電話だな

>>837
それは甘い
1+2+3
ではどうなると思う？
1+2の結果を一時オブジェクトにコピーして、その一時オブジェクトのメンバオペレータが呼び出されて+3の演算が行われて・・・となるよ。
(+ 1 2 3)
とかなら何度も一時オブジェクトが生成されない。

>>826
そうではない。
誰かがクラス定義をちょっといじると基本的に全部コンパイルしなおしとか。
クラスを使うだけなら、メンバ関数の仕様を固めておけばいいだけだが、
クラスの中をいじると、基本的にクラスメンバなんてメンバ関数にとってはグローバル変数同然なので影響はクラス全体に及ぶ。
統一した意思の下でクラスをいじるなら問題ないけど、勝手な思惑でクラスをいじられると影響する範囲が広すぎる。
それこそ、オーバーロードや派生がどうなっているかソースから追うとかいう自称Cエキスパート君のようになる。

ま、これはLinux風な開発をしている場合の話であって、業務で誰かが統括してれば本来起こるはずはない問題だと思うけどね。

>>926
バザールモデルで統一的な規約を強制しての開発はしにくい
ってことを言ってるのかな

>>826が言ってるのは、ABIがグダグダ＆ソース依存性が高い（例えば
テンプレートライブラリはC++からしか利用できない上に、
ほとんどの処理系ではソースレベルでの利用となる）等の理由により、
低レベルのシステムプログラミングやライブラリ開発には結局向かない
（それ向きの言語であると喧伝されているが）ってことだろう

それぞれ別の、独立した問題だな

>>927
前半のとおりです。
だから、Linusがウンコと言ったところで、開発手法が違えばウンコではないわけでね。
とはいえ、複数人でソース分けて作るのは面倒くさいなぁ。
ヘッダの他人が作る部分にプレースホルダ入れてても、最後にマージとか面倒だな。
.o作るだけでもヘッダの依存性が高すぎる。

>>926
構造体いじっても同じことじゃねえか？

>>926
ソースから追う以外の方法って何？
仕様書から？

そこでCOMです

腐った沼地にビルは建たんよ。

>>930
オーバーロードや派生なんてのはクラス設計の時点で決まっているものだから、設計図がきちんとしていればコードを追う必要はないでしょ。
設計図が各人の頭の中にバラバラにあればコードを追わないといけないが。

つまり、C++はアジャイルに向かないポンコツ言語って事

boostの設計の時点っていつかな

＞設計図がきちんとしていれば
果てしない理想主義だな
貴族というか大名というか
世の中の何割の連中がそんな環境でコーディングしてるんだか

設計も信用できない
コーディングも信用できない
プログラミング言語も信用できない
クライアントも信用できない
会社も信用できない

自分も信用できない

コンパイラも信用できない

937-939の中で一番信用できるのはコンパイラだな

いまの所信じるのはISO/IEC 14882:2003だけでいい…

>>933
そんなレベルまで設計でやってるのか。
効率わるー。

だいたい、バグった箇所を特定するためにはコード追うしかないじゃん
設計図眺めてバグ取れるのか？

設計そのものに問題があるとバグの数も増える
かといってその時点で設計見直しても後の祭

お前らほんとにC++プログラマ？

設計なんてコード書きながらやりゃええがね。
10年もコード書いてりゃ勘で何とかなるわ。

ExcelマクロとWSHとdebug.exe使ってるただの事務員ですよ^^

仕様レベルの設計なら必要だけど、クラスがどうとかオーバーロードがどうとかって
コーディングレベルは設計いらんだろ。

プログラミングは設計です
タイピングの段階でのことなら知りませんけどー

>>943
オーバーロードがどうなってるかとか、派生の関係がわからないとか、そういう次元のバグとりなのか？
それならコードを追わずにクラス図からやり直せ。

クラス図なんか描くところあるのかよって一瞬思ったけど、
今日読んだブログに、クラス一個つくるのに承認印が必要だけど、これって誰得って
文句書いてあったな。

>>951
どこ？

同じところを見てるかわからないけど、品質管理ってそういうもの

「ハンコがないとクラスも作れない」、というのは当たり前で、
気軽にクラスを作れるグダグダ開発がどこでも通じるってのがおかしい

>>952
http://www.kt.rim.or.jp/~kbk/zakkicho/09/zakkicho0902a.html#D20090206-4

きっとただのタプル構造体やRAIIクラスにまでハンコ要求してるんだろう

はんこを押せば品質が上がるとでも思ってるんだろうな...

悲しいけど信頼されてないってことだから、少しずつ信頼度を上げていくか、めんどくさいからプロジェクトから去るかのどっちか。

>>957
信頼度あげても、変わらないんじゃね?
ベテランだったり優秀ならハンコなしでもOKってシステムなら、信頼されてないってことになるけど。

もう、Class Main に全部入れればいいよ。

そのクラスにハンコは押せんな。

思いつきでチョロチョロとクラスを増やすからハンコが面倒くさいんだろ。
最初から一気にデザインしてからハンコもらえばいいだけのこと。
単に、オブジェクト指向は全体像を把握せずに端からコーディングしたら破綻するというだけのことで、C++がどうこうという話じゃないね。

最初から全部、使うクラスを洗い出すなんてムリ。
フレームワークにメソッドやメンバ変数をガシガシ追加して、自分じゃまったくクラス作らない
みたいなスタイルなら可能だけど。

pimplするとハンコ2ついるのかな

>>962
そのままコードに落としこめるくらいまで細かく設計すれば可能だけど、
そういうのってけっきょくコンパイラの機能に頼らずに頭の中で
コーディングしてるのと同じだしな。

全部は無理でも全体を見通せるぐらいの設計はしような。

全体見通すって何のためのカプセル化だよ

全部グローバル変数で作るのとなんもかわらんじゃないか。

プログラミングは製造じゃなくて設計だって何度言えば分かるんだ

>>968
プログラムは設計じゃなくて政治だって何度言えば分かるんだ

プログラマは経営者とかいう意見もあったな
分裂君の言うことだから9割ネタだろうけどさ

Linus は頭のいい人間なのに、成功しなかった理由がこれで解った。

世間には、優秀なプログラマと、おバカなプログラマがいる。
優秀なプログラマには力を存分に発揮してもらわなければならない。
おバカなプログラマにも、優秀なプログラマの足を引っ張らない
ようにしながら、それなりの仕事をしてもらわなければならない。
C++は、それを実現しやすい点でCよりも優れているのだよ。

>>971
ちょっと待てｗｗｗ
Linus以上に成功したプログラマが世界に何人もいると思ってるのか

>>971
> Linus は頭のいい人間なのに、成功しなかった理由がこれで解った。

完全に間違った事をここまで自信を持って言う奴がいたとは。

ビルゲイツはBASICだけで世界有数の長者になったからなあ。
Linusは技術に精通し全てをプログラミングにつぎこんでも
せいぜい日本人の上の下クラスの生活でしょ？

そういう意味では、世界にはLinus以上に上手くプログラムで成功した奴って何万人もいるんじゃねえの。

ライナスなんて未だに下働きの土方階級じゃん。

>>974
お前にとっては 「金 = 成功」 か？
ちっちゃな人間だなお前は。
可哀そうになってきた。

>>976
メアドも見てやれよ

>>975
だがLinusの作ったOSは世界中いたるところで使われており、その名前は歴史に残った
お前は2chで書き込んでるのが関の山

Altair-BASIC は Gates 一人で作ったわけじゃないし
Linux は Linus 一人で作ったわけじゃないし
Apple ][ は Jobs 一人で作ったわけじゃないし
そもそも、殆どは彼らよりも周りの人間が作ったと言えるけども
そんな事とは関係なく成功者なので

　　　奴らはマとして成功したわけじゃない

うん。やっぱ成功の秘訣は大言壮語かも試練。

>>978
ネタだと逝ってくれ。ツッコミどころありすぎ。

][

つttp://www.iknow.co.jp/lists/1244

Linusは俺が作った by 親父

他はともかくAppleはJobs一人で作ったようなもんだろ

>>983
一人で作ったような顔をしているだけだろ。

>>983 Appleはウォズがいなきゃ存在していない

ウォズ？だれそれ

ウォーズマン

違法コピーのソフトとか電話のただがけ装置作って売ってた人
林檎の教祖の片割れ

>>988
その利益を騙して独占したのがジョブズ

>>988
本気で言ってる？

もしかして、電話クラックしまくってた誰かと間違えてない？

ウォズって、 測定器しか作ってなかった頃の HP でバイトしてて,
Apple のプロトタイプ作った時に, HP から
「うちはそんなもん作らんから勝手にしろた」
って言われて、スティーブにそそのかされて Apple 立ち上げて
Apple I とか Apple II を設計した人なんだけど…

>>990
つttp://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%86%E3%82%A3%E3%83%BC%E3%83%96%E3%83%BB%E3%82%A6%E3%82%A9%E3%82%BA%E3%83%8B%E3%82%A2%E3%83%83%E3%82%AF

>>911
マシン語とニーモニックの区別もつかんのかお前は。

で、お前はマシン語に構文が無いと思ってるの？

まぁjobsとlinusとgatesの中では
jobsが一番モノ作ってないのは間違いない
元からエンジニアではないし

次スレ行こうぜ

C++ が糞なのは分かるけど、その代替が C ってのもなんだかな。

関係ないけど、cygwinにgit入ってんだな。
使ってみるか。

こんな感じかね：

　 jobs:技術６、評価眼９、魅力９、経営力９
　　　　（wozオプションで技術９にアップ）
　linus:技術８、評価眼７、魅力６、経営力NA
　　　　（OSSオプションで技術と評価能力９にアップ）
　gates:技術７、評価眼９、魅力７、経営力９
　　　　（allenオプションで能力同じでx2に分身可能に）

ちなみに一般人の限界は５くらいで。

ゲイツやジョブズと比べるとリーナスは技術50くらいだろ

ウンコ言うお前がウンコ

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。