Linus「C++プログラマ ..
[2ch|▼Menu]
751:デフォルトの名無しさん
09/02/06 23:59:10
>>746
それはさすがのC++でも許してない

752:デフォルトの名無しさん
09/02/07 00:26:04
>(fooやifが変なマクロってのはなし)
つ「演算子のオーバーロード」

753:デフォルトの名無しさん
09/02/07 00:43:58
DDR3は待たなくてもいいっぽいな。

URLリンク(www.age2.tv)
URLリンク(www.age2.tv)
URLリンク(www.age2.tv)
URLリンク(www.age2.tv)

754:デフォルトの名無しさん
09/02/07 00:45:01
guro

755:デフォルトの名無しさん
09/02/07 00:46:01
intとintの演算はオーバーロードできないぞ
それやるならこうしないといけない

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

756:デフォルトの名無しさん
09/02/07 00:47:34
int が別の型に置換されるマクロかもしれないじゃないか

757:デフォルトの名無しさん
09/02/07 00:49:29
なるほどその発想はなかった

758:デフォルトの名無しさん
09/02/07 01:11:40
IsRangeとかテンプレートでつくれよこのウンコやろう

759:デフォルトの名無しさん
09/02/07 01:23:29
OrangeRange

760:デフォルトの名無しさん
09/02/07 01:28:53
Boostにintervalといううんこがあるよ

Boost Interval Arithmetic Library
URLリンク(www.boost.org)

761:デフォルトの名無しさん
09/02/07 03:16:02
#define int char
#define private public

762:デフォルトの名無しさん
09/02/07 04:16:46
C++の優れている点
◎bool型
◎文字定数がchar型 (Cだとint型)
◎namaspace
◎メンバ関数 (structスコープ内限定の関数を宣言できる)
◎inline関数
◎引数省略時の解釈。 int f( ); が int f( void ); と等しい。
 Cだと引数は任意の意。

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

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

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

763:デフォルトの名無しさん
09/02/07 06:24:37
for (;_;)//~~

while (T_T)//~~

764:デフォルトの名無しさん
09/02/07 10:04:51
ここでアセンブラ廚の俺が登場
素直にLisp使え

765:デフォルトの名無しさん
09/02/07 10:22:05
まずはLispでカーネルモジュールあたりを作ってから口出してもらおうか。

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

766:デフォルトの名無しさん
09/02/07 11:17:06
テレビの制御モジュールではダメかね?

767:デフォルトの名無しさん
09/02/07 11:39:18
デフォルト引数は手抜き野郎がチェックせずに関数仕様を変更する温床にしかなってない気がするんだが。

768:デフォルトの名無しさん
09/02/07 12:18:23
デフォルト引数より名前つき引数をサポートしてホシィ

769:デフォルトの名無しさん
09/02/07 13:09:11
>>768
これは同意
とはいえ、全ての関数呼び出しに名前付けろとか言われると
やりきれないけど

770:デフォルトの名無しさん
09/02/07 13:23:54
クロージャが匿名クラスなら
名前つき引数は匿名構造体か

771:デフォルトの名無しさん
09/02/07 13:26:48
最近のgccだと

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

とかいけるんだっけ?

772:デフォルトの名無しさん
09/02/07 13:40:46
hoge、fugaの型は?

773:デフォルトの名無しさん
09/02/07 14:13:32
ほんとにできたよな、と試してみた。

#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;
}

多相関数なんてないんだから、キャストなしでも警告程度で自動型判定して
くれてもいいんじゃないかとオモタ。

774:デフォルトの名無しさん
09/02/07 14:44:13
>>771,773
C99からできるようになったんだよ。
前は、GCCの拡張だった気がするけど。
まぁ、それ使い出すともうC言語じゃないと思っているから、いまだに実際に使ったことはない。
いまだに、C89でも通るように組んでいる。(というかむしろ-std=c89 -ansi -pedanticでコンパイルしている)
#if (__STDC_VERSION__ >= 199901L)で、inlineとかrestrictとか使うようにしている。
可変引数マクロを使いたいと何度思ったことか。全ては、C89で通るように。

775:デフォルトの名無しさん
09/02/07 15:20:41
それ、名前付き引数じゃなくて、複合リテラルだろ

776:デフォルトの名無しさん
09/02/07 15:27:30
ちなみに、C++0xだと初期化リストでfoo({hogedata, fugadata});と書けるようになるはず。

777:デフォルトの名無しさん
09/02/07 15:33:53
むしろ、C99,gccマンセー。

778:デフォルトの名無しさん
09/02/07 15:35:27
>>774
可変引数マクロは最低限2つ引数がないと使えないという糞仕様なので
使わなくていい。なんでgcc拡張をそのまま採用しなかったのが意味不明。
C89で通したいならMACRO(())で今後もやるしなかいな。

779:デフォルトの名無しさん
09/02/07 16:00:50
>>778
引数2つってどういうこと?
URLリンク(seclan.dll.jp)
ここにはこういう例が載っているけど。
#define dbg(fmt, ...) \
 printf("debug:" fmt, __VA_ARGS__)
#define adbg(...)   \ //(1)これもOK
 printf("debug:" __VA_ARGS__)


780:デフォルトの名無しさん
09/02/07 16:10:11
>>799
あれ?前試したときは

#define HOGE(FMT, ...)

みたいに一つは置石がないと ... を続けられなかった記憶があって
そう書いたんだけど、... 単品で通るね。

スマン、嘘情報でした _O_ (トンクス)


781:デフォルトの名無しさん
09/02/07 19:59:11
C最強だろw
C++とかコロコロ言語仕様変わるし
糞仕様のオンパレードw


782:デフォルトの名無しさん
09/02/07 20:40:21
と、C++に挫折したCプログラマが負け惜しみを呟いております

783:デフォルトの名無しさん
09/02/07 20:41:47
Cで数十万行のものとか扱ってるけど
その8割方はschemeのコードから自動生成したものだったりする
Cはこういう使い方も比較的楽できるからいいね、C++でやろうとしたら
数倍難しい

784:デフォルトの名無しさん
09/02/07 20:45:01
Cのコードを吐けるなら
C++のコードも吐けるだろ
ほぼ同じで動くんだから

785:デフォルトの名無しさん
09/02/07 21:09:23
Cが低レベルな言語だから高レベルな言語からの変換がしやすいだけでしょ。
コンパイルができるとCに変換できるはほぼ同義じゃねーかよ。
パラダイムの違う高水準言語同士で機能をフルに使った変換とか難しくて当然じゃねーかよと。

786:デフォルトの名無しさん
09/02/07 21:38:45
>>762
template もあるんじゃね

787:デフォルトの名無しさん
09/02/07 21:42:34
>>783
それなら全部schemeで扱って、コンパイルのときだけCにすればいいってことだね。
つまりscheme最高ってこと?

788:デフォルトの名無しさん
09/02/07 22:17:25
>>787
8割って書いてあるだろ。
それを無理矢理10割にしようとした結果が、C++のようなモンスター言語だ。

789:デフォルトの名無しさん
09/02/07 22:22:50
まぁ確かに最近のC++はメタプログラミングに力入れてるね

790:デフォルトの名無しさん
09/02/07 22:37:59
C++は糞言語
これだけはガチ

791:デフォルトの名無しさん
09/02/07 22:43:23
その糞を拭えば、コアはすばらしく良い言語なんだよ
Cの膨大なライブラリもそのまんま使えるし
糞の上塗りさえやめてくれればいいんだけど

792:デフォルトの名無しさん
09/02/07 22:56:15
糞は糞
C++はRubyよりも狂信者が多い
異端宗教者の集まりだしなw

793:デフォルトの名無しさん
09/02/08 00:00:49
根拠のないアンチC++も多いってことは分かった。

794:デフォルトの名無しさん
09/02/08 00:08:54
信者でもC++を他人に薦めるようなのは少数派だしね


795:デフォルトの名無しさん
09/02/08 00:24:12
いや糞がついたものは洗っても食わないだろう普通

796:デフォルトの名無しさん
09/02/08 00:25:55
都会の人間は堆肥を知らない

797:デフォルトの名無しさん
09/02/08 00:31:09
江戸は、糞の再利用にかけては今も昔も世界最先端都市だったのになあ
潔癖症は中国農薬野菜でも食ってろ

798:デフォルトの名無しさん
09/02/08 00:38:34
・メンバ関数
・アクセス修飾子
・new/delete演算子とこの2つだけの演算子オーバーロード
これだけでいいよ。継承は単一継承ならホントはあってもいいけど
継承を乱用する奴多いから要らないかな・・・

799:デフォルトの名無しさん
09/02/08 00:39:39
ベースはc99ね

800:デフォルトの名無しさん
09/02/08 00:39:53
テンプレートも入れといて。

801:デフォルトの名無しさん
09/02/08 00:40:19
テンプレートも乱用されるからね・・・

802:デフォルトの名無しさん
09/02/08 00:47:28
継承よりは副作用がないと思うんだ。

803:デフォルトの名無しさん
09/02/08 01:29:13
なんでそんな四則演算のオーバーロードをいやがるん。
ベクトルとか行列とかクォータニオンとか複素数とか扱ったことないわけ?

804:デフォルトの名無しさん
09/02/08 01:36:46
>>803
意味無いし生産性悪い書き方だから
排除すべきだろ

そんな特殊なケースのみを言語仕様に盛り込み
たがるアホがC++に多い影響でC++自体が邪教の
産物になってしまっただろ。
次期C++仕様もboostの製作陣から糞過ぎるって
痛烈に批判されてるしなw

805:デフォルトの名無しさん
09/02/08 01:39:37
宇治社中で学んだ口だがオーバーロードいらん

806:デフォルトの名無しさん
09/02/08 01:42:04
haskellみたいに関数を演算子として適用する明快な方法を提供していれば
また状況は違ったかもしれないが、

807:デフォルトの名無しさん
09/02/08 01:47:03
>>803-804
意味はあると思うけど、指針が無くて個々人の感性に任されるから、
乱用されて他人から見たら直感的でない、ってケースがありすぎる。

結果、いっそ排除した方が良いというハメに。

808:デフォルトの名無しさん
09/02/08 02:07:07
Prolog みたいに演算子を好きに定義できる言語もあるんだし
このくらいなんてことはないよ

809:デフォルトの名無しさん
09/02/08 02:19:48
Prologで大規模開発してから言ってくれ

810:デフォルトの名無しさん
09/02/08 04:38:56
演算子オーバーロードが無かったら…
stringとかvectorとか、めっさ使い勝手が悪くなると思うけど。

 record = name + "\t" + address + … ;

とか書けてたのが、↓になっちゃうんですが。

 record.assign( name ).append( "\t" ).append( address ) … ;


811:デフォルトの名無しさん
09/02/08 05:00:46
そんなのどうでもいいというか良く使う機能で慣れてるから違和感ないだけで
慣れてなければPerl並に可読性悪い。

812:デフォルトの名無しさん
09/02/08 05:04:55
演算子多重定義は要るよ派だけど、
C++のostringstreamとC#のStringBuilderでは後者のほうが使いやすいと思う。
そもそもiotreamの<<と>>が終わりの始まりだったな。

813:デフォルトの名無しさん
09/02/08 05:41:31
記号地獄はもういやです

814:デフォルトの名無しさん
09/02/08 05:43:58
CのDLL -> C++/CLIのDLL -> C丼のGUI
の構成でC++/CLIを使ってみた。
変態言語だと思った。

いや、C++は好きなんだけど…
スレ違いか・・・

815:デフォルトの名無しさん
09/02/08 06:17:58
文字列の連結は + で行う言語が主流ではあるけど
& で行う言語や . で行う言語もあるんだよな。

816:デフォルトの名無しさん
09/02/08 07:35:23
>>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);


817:デフォルトの名無しさん
09/02/08 08:25:33
>>810
sprintfも知らない奴は発言するな

818:デフォルトの名無しさん
09/02/08 08:34:05
>812
iotreamがC++入門者への糞設計洗脳プログラムとして作用してる。

819:デフォルトの名無しさん
09/02/08 09:22:22
自分の頭が悪いだけなのに無意味な仕様って
テレビと同レベルだな

820:デフォルトの名無しさん
09/02/08 09:38:16
お前ってテレビ大好きだなw

821:デフォルトの名無しさん
09/02/08 09:38:33
>>812
その二つは用途が違うだろ。
C++のstringはイミュータブルじゃないからstringbuilder系のクラスいらないし。

822:デフォルトの名無しさん
09/02/08 09:50:21
文字列の連結に演算子が要らない言語もあるね。
他の言語がどうだってのは余り意味がないよ。

823:デフォルトの名無しさん
09/02/08 10:31:48
LinuxがC++不要言ってたんだし
2chのC++関連のスレ潰していこうぜ

824:デフォルトの名無しさん
09/02/08 10:38:56
半端なとういうか
わからないならおとなしくbetterCとして使ってればいいのに
ヘタに手を出してクソコードを生み出してる奴を叩いてるのであって

825:デフォルトの名無しさん
09/02/08 10:54:45
そりゃ、Linuxの開発にC++は邪魔だろうな。
Cはヘッダ共有しなくても、関数引数リストがわかっていれば他人の書いたソース・オブジェクトと連携できるが、
C++はヘッダ共有しないと話にならないし。
最初から統一された設計の下に作るならC++がいいが、大勢の思いつきの寄せ集め的開発手法にはあわんわな。

826:デフォルトの名無しさん
09/02/08 11:20:47
名前マングリング位統一しとけよハゲ

ということか

827:デフォルトの名無しさん
09/02/08 11:28:15
Linusは2ちゃんの味方。
彼はレベルが高いよ。

828:デフォルトの名無しさん
09/02/08 12:23:26
>>803
ないんだろうな。数学コードまったく書かない文系なんだろ。
「特殊なケース」とかアホすぎる。お前ゲーム一切やるなと

829:デフォルトの名無しさん
09/02/08 12:25:07
記号のオーバーロードがどんなに危険か想像つかない奴は幸せだよ
たいしたコード書いてないって自分で白状してるようなもんだ


830:デフォルトの名無しさん
09/02/08 12:33:28
ゲームの場合は計算量を抑えるために
演算子オーバーロードを敢えて使わないケースもあると思う。
a = b * c; とか、無駄なテンポラリオブジェクトを作って、
そこからの代入が発生してしまうので、
これが行列だったりしたら結構無駄が多くなる。
Matrix a = b * c; なら最適化効くからいいけど。

演算子オーバーロードはもっと計算量がシビアに効いてこないプログラムや値で
使った方がいいと思われ。
まあ、分数や複素数程度ならいいんじゃない?

831:デフォルトの名無しさん
09/02/08 12:38:42
つ Expression Template

832:デフォルトの名無しさん
09/02/08 12:43:01
もう好きにすればいいじゃないか。
C++が使いたい奴は、勝手に使ってもらって構いません。
わたしとあなたが出会わなければいいだけです。

C++の演算子オーバーロードは、抽象データ型を直感的に(原始データ型と同じように)扱うためにあるんだよ。
演算子オーバーロードをしないのであれば、別にC言語で十分同じようなことはできる。
TMPは、したいと思うけど、あれはコンパイラががんばっているだけだから、
何か取り決めを決めて、Perlを通して、C言語を吐かせた後にコンパイルすれば、どうにでもなる。

833:デフォルトの名無しさん
09/02/08 12:47:01
複雑な計算式になると、関数呼び出しだけじゃ訳分からんことになるので
演算子オーバーロードは貴重だぞ

834:デフォルトの名無しさん
09/02/08 12:54:29
>>833
計算はFORTRANだろ、常考

835:デフォルトの名無しさん
09/02/08 12:55:52
>出会わなければいいだけ
まったくそのとおり。
勝手に演算子オーバーロードでも使って、見た目キレイに書いて、
バグが出た時には勝手に死んでくれてればいいんだが、
オレのコードにそんな不便なものを混入されたら迷惑なんだよな。


836:デフォルトの名無しさん
09/02/08 12:58:37
まぁぶっちゃけ演算子オーバーロードは
文字列と数学系以外使わないからどうでもいい

あとはboostが変態的な使い方してる位か

つうかC#にもあるんだがそれには文句ないのか

837:デフォルトの名無しさん
09/02/08 12:59:06
1 * 2は*(1,2)っていう関数適用の構文糖衣
ただその構文糖衣に「かけ算」っていう暗黙の解釈が存在するのが混乱の元になってるんだろうよ
オーバーロードなんて((Int,Int), *)と((MyT, MyT), *)っていう代数構造を示す組が同時に存在してるだけじゃん
それに伴う暗黙の変換は場合によっちゃ厄介だけどさ

838:デフォルトの名無しさん
09/02/08 13:00:03
>>835
数値クラスの場合は関数で書いた方がバグは多いと思うぞw

839:デフォルトの名無しさん
09/02/08 13:03:36
バグを減らすなら暗黙の型変換を一切禁止しちまえばいい

840:835
09/02/08 13:21:03
バグが出やすい出にくいの話なんてしてないよ。
バグった時にひどい目に逢うと言っている。
演算子オーバーロードだけじゃない、継承もそうだし、コンストラクタもそうだし、
カプセル化と称するインターフェイスの共通化もそうだ。
オブジェクト指向はなんだか宗教みたいになってるよ。たいした功績も無いまま、
キミ達のような信者が必死に信仰してる。
そういう信者が多い方がこっちとしては希少価値が上がって助かるけどなw


841:デフォルトの名無しさん
09/02/08 13:21:47
a * b - c * d

a.multiply(b).subtract(c.multiply(d))


842:デフォルトの名無しさん
09/02/08 13:23:56
論理記述より数式記述のほうが直感的というのもどうかと思うが

843:デフォルトの名無しさん
09/02/08 13:26:39
酷い目に逢うという思い込みで語られても

844:デフォルトの名無しさん
09/02/08 13:26:54
メンバ関数の呼び出しも構文糖衣なんだよな
thisもパラメータであることを考慮してみると
xの型をTとしてx.fって呼び出しはcall(x,T::*f)であると考えられる

845:デフォルトの名無しさん
09/02/08 13:27:31
ひどい目に合うって経験談だろ。

846:デフォルトの名無しさん
09/02/08 13:27:34
外部関数をメンバ関数であるかのように呼べる言語もあるね

847:デフォルトの名無しさん
09/02/08 13:27:57
>>845
具体例を挙げない体験談ほど胡散臭いものは無い

848:デフォルトの名無しさん
09/02/08 13:30:00
>>847
まあそうかも知らんがめんどいしこれだけのやつらが言うって言うのも何かあるとは思うだろ。
キミはどのくらいの規模のプロジェクトをどんな立場でどのくらいやってきたんだい?

849:デフォルトの名無しさん
09/02/08 13:33:10
構文糖衣かどうかより、シンプルな問題はシンプルに書きたい。
その辺り C言語はバランスよく出来てる。

その意味では、string の + はアリだと思うけど
一般のクラスに対しても + を overload できるのはやりすぎちゃったよね

850:デフォルトの名無しさん
09/02/08 13:35:12
何年も保守されてるプログラムでも
普通に文字列の + とか使われてるが、
何の問題も起きた事無いけどな。

851:デフォルトの名無しさん
09/02/08 13:35:17
>>849
やりすぎとはまったく思わない。
必要ないときは使わなければ良いだけ。

852:デフォルトの名無しさん
09/02/08 13:35:38
そもそも隠蔽化と継承・多態はセットである必要があるのか?
隠蔽化だけならモジュールプログラミングなんだっけ?

853:デフォルトの名無しさん
09/02/08 13:36:18
>>851
きみみたいなのがプロジェクトで深刻な問題を引き起こしてるんだよって話

854:デフォルトの名無しさん
09/02/08 13:38:21
だから具体例上げろよカス

855:デフォルトの名無しさん
09/02/08 13:39:54
一般化の利点は取捨選択ができること
stringの+とか一部だけ許すってのは、その一部のクラスを言語の仕様に組み込んでしまうということ
特殊化より一般化

856:デフォルトの名無しさん
09/02/08 13:40:13
まあプロジェクトリーダーになったらわかるよ。
なれないと思うけど。

857:デフォルトの名無しさん
09/02/08 13:41:00
ゴミを大量生産する一般化。

858:デフォルトの名無しさん
09/02/08 13:42:47
>>849
言語仕様としてはアリだと思うけど。
どう使うかは設計レベルだから、言語仕様ではなく実際の運用の話になるんではないか?

859:デフォルトの名無しさん
09/02/08 13:43:40
それは取捨選択ができない人間が使ってるだけかもしれない、それだけの根拠で言語を叩くのは間違い
ただ、使えない人間が沢山存在するような言語である点は褒められたものではない

860:デフォルトの名無しさん
09/02/08 13:45:44
>>859
それは個人で使うならいいけど大規模プロジェクトでは問題ありと結論できない?
C++は当初(今も?)大規模開発での有用性をうたってたけど

861:デフォルトの名無しさん
09/02/08 13:47:49
そんなことを言い始めたら、どの言語も程度の差あれ、全て問題ありだろ。

862:デフォルトの名無しさん
09/02/08 13:47:59
MSやgoogleは、とにかく優秀な人間を集めてさえいれば大丈夫、と結論付けたようだな
他にそんなことが出来るところがあるかどうかはともかく

863:デフォルトの名無しさん
09/02/08 13:48:20
程度の差が問題なんだろ

864:デフォルトの名無しさん
09/02/08 13:50:13
だな
全部アセンブラで書くかって話だ

865:デフォルトの名無しさん
09/02/08 13:51:21
そこまで言わなくてもCでいいじゃん

866:デフォルトの名無しさん
09/02/08 13:52:34
Cなんてメモリリークさせ放題の糞言語だろ

867:デフォルトの名無しさん
09/02/08 13:53:56
え?w

868:デフォルトの名無しさん
09/02/08 13:54:02
「子供の手の届くところに置いてはいけません」ってのがふと浮かんだ。

869:デフォルトの名無しさん
09/02/08 13:54:14
速度があまり要求されないならJava、そうでないのならC
これで十分だけどそう結論がついちゃったら一部のコン猿達がおまんま食い上げだから
C++は凄いとかLLでコスト削減とか関数型がクる!とか色々

870:デフォルトの名無しさん
09/02/08 13:55:03
>>867
malloc使ってメモリリークしてないプログラムを見た事が無い
Cは糞言語

871:デフォルトの名無しさん
09/02/08 13:56:13
メモリーリークにおいてmalloc/newに違いがあるの?
スマートポインタ云々はまったく別問題だぞ

872:デフォルトの名無しさん
09/02/08 13:59:40
スマートポインタ云々を別問題にされると困るんだが

873:デフォルトの名無しさん
09/02/08 14:00:25
まあ、C++は良くも悪くも面白い言語ではあるよ。
。。。最初だけなw

874:デフォルトの名無しさん
09/02/08 14:00:40
>>870
たぶん、3つかそこらしか見たことが無いんだろうな
丁寧に書けばCでもアセンブラでもメモリリークなんて起こさないよ

875:デフォルトの名無しさん
09/02/08 14:02:48
>>870
>malloc使ってメモリリークしてないプログラムを見た事が無い
私がいるセカイはこんなに糞なんですよ、という告白ですか。

876:デフォルトの名無しさん
09/02/08 14:03:29
つまりC++上で派生した技術をC++の利点として挙げているわけですね。
それは必ずしも間違ってはいないけど
当初C++がCへのトランスレーターとして存在していたことをみても
C++のメリットとは言いがたいし、そもそも組み込み系のCとかだと違うアプローチで
メモリを扱うことによって回避している。

877:デフォルトの名無しさん
09/02/08 14:05:08
>>874
演算子オーバーロードはちゃんと使える人が少ないから糞で、
mallocはちゃんと管理できる人が少なくても丁寧に書けば大丈夫!か。
何というダブルスタンダード。

878:デフォルトの名無しさん
09/02/08 14:05:55
メモリの管理もできないような人は、プログラミングしないでください。
malloc()で、メモリリーク起こす人がいるから、C言語が糞言語だと言うのは、
演算子オーバーロードで、混乱を招く人がいるから、C++が糞言語と言うのと同じだ。
使う人が問題なだけであって、それ自体は問題ではない。

879:デフォルトの名無しさん
09/02/08 14:07:43
特にエラー時のメモリリーク管理が出来てないプログラムが多い。
あるいは、管理はできてるけど、ifの中に毎回大量のfree書いてるような糞コードとか。

880:デフォルトの名無しさん
09/02/08 14:08:29
いやいやスマートポインタがあるからなんでもOK!っていうデスマプロジェクトがあってねw
夢の技術を妄信しておれたち頭良すぎるから納期に間に合わずバグてんこ盛りで納品!
もうあほかとね。昔から自前で回避してた技術をすべて否定して夢の技術を妄信するってどうなんかと。

881:デフォルトの名無しさん
09/02/08 14:09:26
多分それ、newを生で使ってもリークし放題なプログラム書くだろうな。

882:デフォルトの名無しさん
09/02/08 14:11:21
俺組み込み系だからよくわからないんだがスマートポインタ使えば回避できる問題ってなんなの?
newもmallocも正しいタイミングで開放できなきゃ分断化でリークと変わらず問題がでるんだが

883:デフォルトの名無しさん
09/02/08 14:15:12
そもそもC++は例外があるからなあ。
自分で例外使わなくても、ライブラリが例外投げることもある。
ちゃんと毎回try-catchしてdeleteしてんのか?

884:デフォルトの名無しさん
09/02/08 14:15:33
原理がわからないまま便利な機能だけを使ってもロクなことにならないってことだな


885:デフォルトの名無しさん
09/02/08 14:18:30
COMの扱いが分からずCComPtr使わずリークさせてるのもあったな

886:デフォルトの名無しさん
09/02/08 14:22:46
スマートポインタの仕様を使ってコードが特定の状況において、
メモリリークを発生させないことが証明できない限りは安全とか言っちゃ駄目なんだね
コメントに証明を書かないとね
でもそこまでするならコードが仕様の証明になる言語が欲しいわ

887:デフォルトの名無しさん
09/02/08 14:25:10
つまりくれくれ君、かつスマートポインタ使ったんだから
このバグはスマートポインタのせいだから直しませんよってスタンスなんだね。わかります。

888:デフォルトの名無しさん
09/02/08 14:26:00
スマートポインタって、馬鹿のための機能って感じだよね。
RAII 程度に抑えておけばよかったのに、欲張ったあげく
ポインタを完全に置き換えられるわけでもないから
結局新しいバッドノウハウを生み出している。

スマートポインタ使う時に気を回す手間で、
まともに free やdelete が書けるよ。まともな人なら

889:デフォルトの名無しさん
09/02/08 14:28:42
そう主張する人に限って例外安全に書けてないんだよな

890:デフォルトの名無しさん
09/02/08 14:29:46
プロセス終了すれば開放されるから別にいいじゃん

891:デフォルトの名無しさん
09/02/08 14:30:04
まともな人が書いてまともじゃない人がメンテする時もあるからねぇ。
そもそも例外とかスマートポインタを使わないメモリ管理は、free/deleteの箇所が分散して、まともな人でも見落とす/見づらいコードになりやすい。

892:デフォルトの名無しさん
09/02/08 14:30:28
実行中にどんどんメモリ増えたら困るじゃんw

893:デフォルトの名無しさん
09/02/08 14:31:57
そらスマートポインタにしろなんにしろ制限があるからね
原則として特定の状況の元、リークしない事を保証するって仕様なんだから
必要条件が満たされない状況においてはリークしない保証ができないし
だから「スマートポインタのせいだから直しません」ってのはまず無理だと思うがね

894:デフォルトの名無しさん
09/02/08 14:32:21
あたりまえだろ

895:デフォルトの名無しさん
09/02/08 14:32:40
まあGCほどオバカ仕様じゃないからね。

896:デフォルトの名無しさん
09/02/08 14:35:40
FireFoxもGC採用してからアホになった

897:デフォルトの名無しさん
09/02/08 15:04:48
毎日再起動すればいいじゃん
みんな無駄に求めすぎ

898:デフォルトの名無しさん
09/02/08 15:11:32
>>897
お前はGCよりオバカそうだな。

899:デフォルトの名無しさん
09/02/08 15:19:37
>>898
私は君みたいにおりこうさんじゃないからね
君たちがちゃんとやってくれればいいんだよ

900:デフォルトの名無しさん
09/02/08 16:07:03
かしこまりました。
その代わり給料上げてね。

901:デフォルトの名無しさん
09/02/08 16:11:18
>>831
残念ながら式テンプレートでも、排除しきれない例がある。
URLリンク(d.hatena.ne.jp)
operator =とは別に、一時オブジェクトを生成しないassign関数を用意しているから使い分けろという形。

902:デフォルトの名無しさん
09/02/08 16:11:56
FireFoxでニコニコ見てるときガクガクするようになったのはGCしてたからなのか

903:デフォルトの名無しさん
09/02/08 16:22:50
flashで動画再生するとmplayerで再生するより2倍(athlon64 3000+でのcpu使用率比)重くなる

904:デフォルトの名無しさん
09/02/08 17:41:24
アセンブラから上は全部構文糖なんだよ。
あの構文糖は甘すぎて不健康とか飴玉なめながら言ってんじゃねーよ、とか
思いますです。

905:デフォルトの名無しさん
09/02/08 17:53:34
アセンブラも構文糖だろwww

906:デフォルトの名無しさん
09/02/08 18:07:43
構文糖衣を全否定するならbrainfackでCやC++と同等の生産性をあげてくれ。
C++は構文糖衣が副作用を伴いすぎてることが問題。
なかには糖衣ですらないものも。

907:デフォルトの名無しさん
09/02/08 18:26:19
C/C++はbrainf*ckの構文糖ではないが・・・

908:デフォルトの名無しさん
09/02/08 18:28:33
>>906
oh,miss spell

909:デフォルトの名無しさん
09/02/08 18:29:02
構文糖衣つまり、Syntactic Sugarを勘違いしてないかな。
既にある構文と完全に同じ意味の構文として置き換えることのできる構文のことでしょ。
例えば、C言語で言うところの(*(p + i))とp[i]の関係や
char a[] = {'f', 'o', 'o', '\0'}とchar a[] = {"foo"}またはchar a[] = "foo"の関係など。

>>904,905
意味不明だな。これがC言語使いの発言なら、とても恥ずかしく思う。
ああ、C++使いの発言でありますように。

910:デフォルトの名無しさん
09/02/08 18:31:58
>>906
Fuck you

911:デフォルトの名無しさん
09/02/08 18:33:17
マシン語に構文がないと思ってるのだろうか?

912:デフォルトの名無しさん
09/02/08 18:35:42
fuch↑you↓

913:デフォルトの名無しさん
09/02/08 18:36:15
フーホヨウ?

914:デフォルトの名無しさん
09/02/08 18:39:19
芙蓉

915:デフォルトの名無しさん
09/02/08 18:54:06


916:デフォルトの名無しさん
09/02/08 18:59:12
                   ,  -―-  _
       , - _ ニニ = ー ' ´           ` ヽ 、
    , ',´ィ ' ´                          \
   / '/             ___    、     、  ヽ //ヽ
. / '´, '   /    ,  ,...:.:.':.´:.:.:.:.:.:.:.:.:.:.:.:.:`:.:.:.ヽ     ヽ  冫:;ィ::::;'  __
 '′/  ,/     /':.:.:.:.;:. -―¬¬¬―- 、:.:ヽ     ヽ/:/,.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 ' / /.n.',` .'|',| '!  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,'';;';!

917:デフォルトの名無しさん
09/02/08 19:07:18
もう900越えてんのかw
みんな好きだなあ

918:止しました。。。
09/02/08 20:53:29
真・スレッドストッパー。。。( ̄ー ̄)ニヤリッ

919:デフォルトの名無しさん
09/02/08 20:57:06
止まるの?

920:デフォルトの名無しさん
09/02/08 21:03:10
>>917
この景気だし暇なんだろ。

921:デフォルトの名無しさん
09/02/08 21:52:35
Linux is obsolate!
Linus is 釣り師!

922:デフォルトの名無しさん
09/02/08 23:17:35
>>916
誰だよw

923:デフォルトの名無しさん
09/02/09 00:09:34
>>914,915

924:デフォルトの名無しさん
09/02/09 00:21:36
糸電話だな

925:デフォルトの名無しさん
09/02/09 00:28:39
>>837
それは甘い
1+2+3
ではどうなると思う?
1+2の結果を一時オブジェクトにコピーして、その一時オブジェクトのメンバオペレータが呼び出されて+3の演算が行われて・・・となるよ。
(+ 1 2 3)
とかなら何度も一時オブジェクトが生成されない。

926:デフォルトの名無しさん
09/02/09 00:34:56
>>826
そうではない。
誰かがクラス定義をちょっといじると基本的に全部コンパイルしなおしとか。
クラスを使うだけなら、メンバ関数の仕様を固めておけばいいだけだが、
クラスの中をいじると、基本的にクラスメンバなんてメンバ関数にとってはグローバル変数同然なので影響はクラス全体に及ぶ。
統一した意思の下でクラスをいじるなら問題ないけど、勝手な思惑でクラスをいじられると影響する範囲が広すぎる。
それこそ、オーバーロードや派生がどうなっているかソースから追うとかいう自称Cエキスパート君のようになる。

ま、これはLinux風な開発をしている場合の話であって、業務で誰かが統括してれば本来起こるはずはない問題だと思うけどね。

927:デフォルトの名無しさん
09/02/09 00:41:53
>>926
バザールモデルで統一的な規約を強制しての開発はしにくい
ってことを言ってるのかな

>>826が言ってるのは、ABIがグダグダ&ソース依存性が高い(例えば
テンプレートライブラリはC++からしか利用できない上に、
ほとんどの処理系ではソースレベルでの利用となる)等の理由により、
低レベルのシステムプログラミングやライブラリ開発には結局向かない
(それ向きの言語であると喧伝されているが)ってことだろう

それぞれ別の、独立した問題だな

928:デフォルトの名無しさん
09/02/09 01:01:55
>>927
前半のとおりです。
だから、Linusがウンコと言ったところで、開発手法が違えばウンコではないわけでね。
とはいえ、複数人でソース分けて作るのは面倒くさいなぁ。
ヘッダの他人が作る部分にプレースホルダ入れてても、最後にマージとか面倒だな。
.o作るだけでもヘッダの依存性が高すぎる。


最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch

4335日前に更新/175 KB
担当:undef