2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

C/C++のこの機能逝ってよし

1 :デフォルトの名無しさん :01/09/24 11:00
 C/C++の滅多に使わん機能(標準ライブラリ含)を語るスレ
 個人的には広域ジャンプ使ったこと無し。

2 :デフォルトの名無しさん:01/09/24 12:09
trigraph sequence

3 :胴衣:01/09/24 12:11
ああ、それだ!

4 :au:01/09/24 12:12
while(1)

5 :デフォルトの名無しさん:01/09/24 12:13
多重継承いらない。
特にスーパークラス同士で同じ変数名やメンバ関数名使われると
わけわからなくなってくる。

6 :デフォルトの名無しさん:01/09/24 12:19
while(1) じゃなくて

neverendingloop{


}
ていうループを作って欲しいね

7 :反抗期:01/09/24 12:33
太重軽傷に関しては、オマエのデザインがぼろいだけ。

while (1), for (;;) なんかは
イディオムとして大昔から定着してるから問題無し!

8 :oop:01/09/24 12:37
delete

9 :デフォルトの名無しさん:01/09/24 12:37
#define neverendingloop for(;;)

10 :デフォルトの名無しさん:01/09/24 13:05
C/C++自体が逝ってよし!

11 :デフォルトの名無しさん:01/09/24 13:29
そんなんしはったら困ります

12 :デフォルトの名無しさん:01/09/24 16:02
>>5
多重継承の有効的な利用法をまだ知らない厨房発見。
カワイイ(・∀・)!

13 :5:01/09/24 16:14
>>7 >>12
君たちは少数派だね。

Java, C#, Delphi ほか多数が単継承です。
おれの勝ちは明白ですよ。

14 :デフォルトの名無しさん:01/09/24 16:19
0が"null pointer"…

15 :デフォルトの名無しさん:01/09/24 16:19
>>12
継承バカ発見。
継承よりも委譲を使おう。

16 :デフォルトの名無しさん:01/09/24 16:25
Javaで複数のinterfaceをimplementsしたら、
同名のメソッドやfinal定数が重なって酷い目に合いました。

どうしてこんなクソ言語になったのでしょうか。
開発者も使ってる連中も脳みそ腐ってるんでしょうか。

17 :デフォルトの名無しさん:01/09/24 16:29
>>15
継承で書いた方が素直に書けるものは、継承で書いてくれ。

18 :デフォルトの名無しさん:01/09/24 16:31
>Java, C#, Delphi ほか多数が単継承です。
>おれの勝ちは明白ですよ。

それらの言語では、貴方のようなドキュソのために
お手軽度を増してあるのです。

やみくもな継承は問題ですが、
mixin 的な使い方はやっぱし捨てがたいです。

>>16 考えなしに継承しちゃあ、だめだめ。

19 :あんちOOP:01/09/24 16:40
>>継承で書いた方が素直に書けるものは、継承で書いてくれ
ネットワークライブラリが、ウインドウハンドル
を持ってたり、LANのサーバークラスが勝手に外のDNSを参照
してたりするのは嫌。
継承っていもずる式に依存関係が複雑化していくと、
MFCを見てそう思う。
Mix-Inやテンプレートは重要。

20 :デフォルトの名無しさん:01/09/24 16:57
C++バカは多重継承、テンプレート使いすぎでコードの可読性が悪すぎます。
とにかくこれでもかといろいろコードを複雑にして他人を困らせてはほくそえんでいます。
あなたたちは書いて終わりでもデバッグする人のことを考えて下さい。
テク自慢は一人で趣味でやってなさい!

21 : :01/09/24 17:02
継承なんか使わずに変数としてクラスに組みこんでますが何か?

22 :デフォルトの名無しさん:01/09/24 17:05
まぁなんというか,新しい物を作ろうとせず,他人の作成物を罵るだけの
人に未来はありませんな。

Ruby 罵倒嵐と同レベル。

23 :デフォルトの名無しさん:01/09/24 17:05
>>21
それが「委譲」というやつです。

24 :デフォルトの名無しさん:01/09/24 17:06
goto の全てが悪なわけじゃないように、
(多重)継承も全てが悪なわけじゃない。
ホントはそんなことみんなわかってんだべ?

25 :デフォルトの名無しさん:01/09/24 17:06
オブジェクト思考がいらないなぁ・・・・

26 :デフォルトの名無しさん:01/09/24 17:09
>>24
ああ、わかっているさ。でも、そういったことを分かった上で、
保守性になるべく悪影響がでないようなコードを気遣って書いて
くれるマトモなプログラマがあまりにも少なすぎるので、最後には
goto禁止!多重継承禁止!になっちまう。
元を正せば馬鹿プログラマの自業自得。

27 :デフォルトの名無しさん:01/09/24 17:13
delete [] hoge ;

28 : :01/09/24 17:13
>>23
ありがとうございます。勉強になりました。m(_ _)mマジ

29 :デフォルトの名無しさん:01/09/24 17:14
C/C++に限らず「gotoは禁止」って言ってる奴ってかなりパーだよな。

30 :デフォルトの名無しさん:01/09/24 17:14
>>26
そういう部分部分への対処療法では
根本的な解決が得られないばかりか
泥々沼々でしょう?

31 :デフォルトの名無しさん:01/09/24 17:18
goto をループ抜ける目的以外で使ってる輩がパーです。
戻り方向に使ってるバカは N88BASIC を使って下さい。
あなたはどうですか? >>29

32 : :01/09/24 17:21
C++はすばらしいぞ!
オブジェクトとサブルーチンを分けてある。
ごっちゃにしてるほかのOOPより遥かに優秀!

33 :デフォルトの名無しさん:01/09/24 17:23
>>31
gotoを状態遷移に使ってますがパーですか?

34 :デフォルトの名無しさん:01/09/24 17:24
滅多に使わん機能ではないが、テンプレートの文法はダサいと思う。とくに
ネストした場合に vector<vecitr<int>> と書くと >> が演算子とみなされてエ
ラーになる仕様ね。

あとはヘッダと実装を二重に書くのも、面倒だよ。テンプレートを多用しだす
と、前方宣言を大量に入れる必要があって鬱。

35 :29じゃねえですけど:01/09/24 17:25
ループ抜ける以外にも、エラー処理をまとめたり、
状態遷移をハードコードするときには goto が欠かせません。
まさか while + switch で無理矢理代用するなんてしないよね。

36 : :01/09/24 17:25
>>31

同意。
ループ抜けるのにはよく使う。

規模にもよると思うが、
飛ぶ先がすぐ分からないのは却下。だとおもふ。

37 :デフォルトの名無しさん:01/09/24 17:29
>>33 >>35
そのコードを見せて下されば幸いです。

38 :デフォルトの名無しさん:01/09/24 17:30
continueとbreakで事足りること多いけどね。
gotoがいけないなんて事は無いけど。

39 :デフォルトの名無しさん:01/09/24 17:33
幾重にもネストしているループを抜ける場合 goto はうれしいです。

40 :29:01/09/24 17:34
gotoを使ってはいけない理由を
「わかりにくくなるから」
以外に述べてください。

41 :デフォルトの名無しさん:01/09/24 17:35
>>40
構造化やOOを切り裂くから。

42 :デフォルトの名無しさん:01/09/24 17:37
>>41
breakやcontinueやreturnも使ってはいけないのですか?

43 :デフォルトの名無しさん:01/09/24 17:40
C/C++に限らず,「構造化」とか言ってる人のコードって
異様にネストが深いことが多い。

44 :43じゃないよ。:01/09/24 17:41
>>43 確かに。よく理解できるなと感心する時がある。

45 :デフォルトの名無しさん:01/09/24 17:44
>>37
簡単なので悪いけど /^[+-]?\d+$/ みたいなのを判定する関数
インデントは勘弁。

int
parse_int(const char* s, int* result)
{
int sign = 1;
int num = 0;

SIGN:
if (*s == '+') { s++; goto BODY; }
if (*s == '-') { s++; sign = -1; goto BODY; }
if (isdigit(*s)) { goto BODY; }
goto ERROR;
BODY:
if (isdigit(*s)) {
num = num * 10 + (*s - '0');
s++;
goto BODY;
}
if (*s == '\0') {
if (result)
*result = num * sign;
return 1;
}
ERROR:
return 0;
}

46 :デフォルトの名無しさん:01/09/24 17:45
>>42
使ってもいいが駆使してはいけない。

47 :デフォルトの名無しさん:01/09/24 17:47
結論:
gotoは悪くない。
gotoを下手に使うパーが悪い。

48 :デフォルトの名無しさん:01/09/24 17:55
つか今時gotoについて語ること自体がおかしいと思う。
ネタ?

49 :デフォルトの名無しさん:01/09/24 17:55
OOPができないうえに、そもそもマトモなコードを書けない人が、
わけのわからないコードを「構造化で書いてる」と言い訳する
見苦しい場面に、最近よくあいますが…

50 :デフォルトの名無しさん:01/09/24 17:59
>>45

>BODY:
>if (isdigit(*s)) {
>num = num * 10 + (*s - '0');
>s++;
>goto BODY;
>}

何で for or while 使わないでわざわざ goto 使ってるの?

51 : :01/09/24 18:00
>>45
死ぬ。目が腐る。

52 : :01/09/24 18:01
>>45
コボラーかBasic臭のするコード・・。

53 :デフォルトの名無しさん:01/09/24 18:01
>>45 ネタでしょ?突っ込む気もおこらん。

54 :45:01/09/24 18:07
キタナイものをお見せしてすみませんね(w
37 のリクエストに答えたまで。

特定の正規表現をハードコードしたイメージ。
なので元の正規表現がわかってれば読めます(たぶん)。

整数だと単純だからアレだけど、
例えば整数と浮動小数点数と文字列と全部判断するとなると
いわゆるキレイ+効率的には書けないでしょ。

実際にはマクロとかつかってもすこし見やすくなります。
ただし、C には見えなくなるかもしれんけど。

55 :45:01/09/24 18:11
>>50
goto で飛ぶのは、状態の遷移に対応してるので
ループにすると意味が通りにくくなります。

つーか、正直悪かった。
あやまるよ。
goto 使いはクズだよね!

56 : :01/09/24 18:11
SIGN:
ってなんなんだーゴルア

57 :デフォルトの名無しさん:01/09/24 18:13
>>54
lex/yacc の吐くコードがこんな感じだよね。
自分で lexer 書くときは ERROR に飛ぶのだけ goto 使ってる。

58 :デフォルトの名無しさん:01/09/24 18:14
「符号(=sign)を読むぜ」という状態

つーか、もういじめないで(w

59 :デフォルトの名無しさん:01/09/24 18:15
>>57
lex だと汎用的すぎてでかくなるのがイヤな時は、
自分でこんな風にスキャナを書いて yacc と連係します。
初見のイメージほど読みにくくないよ。

だからいじめないで(w

60 :デフォルトの名無しさん:01/09/24 18:25
>>54
むしろ、サンプルが「単純すぎた」のが敗因だと思うが。これだと goto は ERROR:
以外要らないし。

苛められすぎなんで、ちょっと弁護しておく。

状態遷移は色々書き方あるけど、最も高速に動作するのが手書きで goto 駆使し
たコード。状態を変数に入れて switch - case したり、関数ポインタを使って管理
するよりも速くなる。

処理系を書く場合、字句解析は性能を左右する部分なので、コードが汚くなろうが
気合入れて最適化する必要がある。そこで goto 使うのはアリだし、敢えて while
などを使わず、状態に対応するラベルを残しておいて、設計変更時に備えるのも
常套手段。


ま、俺は lex 使うけど(← ……

61 :デフォルトの名無しさん:01/09/24 18:31
>>1
longjmp/setjmpは無いと困る

62 :デフォルトの名無しさん:01/09/24 18:34
volatile使ったことない

63 :デフォルトの名無しさん:01/09/24 18:34
終りか…
構造化原理主義者は根性無しばかりというわけだ。
アヒャヒャヒャヒャ次はなにしてあそぼかな。

64 :デフォルトの名無しさん:01/09/24 18:43
C++ の protected 継承は使ったことないなぁ。

65 :45:01/09/24 18:43
ああっ、63 はオイラとは違うよ。(T_T)

66 :デフォルトの名無しさん:01/09/24 18:51
>>62
制御系だと必須だが。周辺機器への入出力を特定のアドレスにマッピングしてる
ような場合、

int *p = (int *)0x00f0;
// read from I/O port
n = *p;
// again
n = *p;

これだと一度 0x00f0 番地から読み出したデータをレジスタに格納しておいて、
使いまわされる恐れがある。

あとは setjmp(), longjmp() が絡む場合も volatile にしておかないとローカル変数
がレジスタに割り当てられて泣けるぞ。

67 : :01/09/24 18:57
>>60
まあ、GOTOはともかく状態遷移は理解できます。
同じ層で状態遷移しなきゃならないのに、サブルーチン作っちゃって
他の処理へ飛ぼうとして立ち往生する奴いたもので。

68 :デフォルトの名無しさん:01/09/24 20:22
C++ の話。
なんていうか、private な部分の宣言がヘッダに見えちゃうのが嫌いだな。
外部に無関係なはずのに、さわったら全部コンパイルしなおしってのが。
効率/実装上いたしかたないという気持わわかるんだけれども。

69 :デフォルトの名無しさん:01/09/24 20:25
>>68
そんなあなたに Bridge パターン。Win32 なら COM もアリ。

言語レベルで対処してくれれば嬉しかったのに、というのは同意だが。

70 :デフォルトの名無しさん:01/09/24 20:27
#define private public

71 :デフォルトの名無しさん:01/09/24 20:29

そういう話じゃないってば(藁

72 :デフォルトの名無しさん:01/09/24 20:30
>>69
単に、実装クラスに委譲するラッパー書けばいいだけだよね?

73 :ラッパーって??:01/09/24 20:34
三木道三 とか?

74 :69:01/09/24 20:37
>>72
その通りでございます。

75 :68:01/09/24 20:39
ま、そう言ってしまえばそれまでだね。(笑

76 :デフォルトの名無しさん:01/09/24 20:40
こういうこと。HogeImplのソース/ヘッダを公開する必要は
無いので、HogeImplの実装を隠蔽できます。

>>>>ランタイムにして隠すクラスのヘッダ
class HogeImpl{
private int hoge;
public int getHoge(){return hoge;}
public void setHoge(int val){hoge = val;}
}
>>>>>

>>>>>公開するヘッダ
class HogeWrapper{
private HogeImpl impl;
public int getHoge();
public void setHoge(int val);
}
>>>>

77 :デフォルトの名無しさん:01/09/24 21:26
>>66
なんで組み込みの人って
IOポートアクセスみたいな特殊な処理を
さらりと代入文で書いちゃうの?
C++なら
inline int inport(int port) { return *((volatile int *)port); }
int main() {
int port = 0x00f0;
// read from I/O port
n = inport(port);
// again
n = inport(port);
}
とした方がOS変える時とか変更箇所が少なくて良いと思うんだけど
あ、volatileが必要ってのはそりゃそうなんだけど。

78 :デフォルトの名無しさん:01/09/24 21:29
mutable

79 :デフォルトの名無しさん:01/09/24 21:33
union

80 :デフォルトの名無しさん:01/09/24 21:45
参照かポインタ
とっちか片方にしてくれ

81 :デフォルトの名無しさん:01/09/24 23:30
>>77
>66 のはメモリマップドI/Oだから。
あなたのはI/OマップドI/Oだから inport, outport などの関数を
使うのです。

82 :66:01/09/25 00:00
>>81
微妙に勘違いしてるぞ。>>77 は inport() も自前で定義してる。

>>77
あのコードは単に volatile 使う一例として書いたから。実際には 0x00f0 なんて
マジックナンバーはコードに埋め込まないし、抽象化もします。

83 :デフォルトの名無しさん:01/09/25 00:04
>>81
いや、メモリマップドI/Oだからって普通のメモリ(?)
と同じ風にアクセスするのはやめようよって言ってるんだけど。
>>77はメモリマップドI/O用に書いたんだよ。
関数inport()という名前が悪かった(I/Oマップド用に見える)
というならメンゴ

けど、>>77みたいに書いてれば、
たとえば、メモリマップドのMIPS用に書かれた関数を
I/Oマップドのx86用に書き直すときに簡単になるとか、
I/Oアクセスタイミングが分かり易くなるとかメリット多いでしょ?

84 :デフォルトの名無しさん:01/09/25 00:17
Placement newってどんな時使うんですか?

85 :デフォルトの名無しさん:01/09/25 01:01
任意の場所をコンストラクタに初期化させたい時

86 :デフォルトの名無しさん:01/09/25 01:10
コンパイルの遅さ=時間の無駄
時は金なり。

87 :デフォルトの名無しさん:01/09/25 01:12
>>86
けっこう同意(w

88 :デフォルトの名無しさん:01/09/25 01:12
>>45
それ、ERROR:以下にエラー処理ないやんか…

89 :デフォルトの名無しさん:01/09/25 01:20
>>86
コンパイル遅いって、何と比較してるの?

昔は切実だったが、最近だと大きめのプロジェクトでもプリコンパイルヘッダ/インクリ
メンタルリンクを使えば数分で終わるから、もはや気にしなくなったが。

90 :デフォルトの名無しさん:01/09/25 01:21
>>89
Delphi

91 :デフォルトの名無しさん:01/09/25 01:25
>>90
Del 使いが C/C++ スレッドに来ると、スレチガイの書き込みを繰り返して荒れる
のが常。早めにお帰り願いたい。

92 :デフォルトの名無しさん:01/09/25 01:36
>>89
VC使ってIDEのエディタで変数名や関数名とかの定義位置を
探すときにいちいちコンパイルするでしょ。あれが長ったらしくていやなんだよね。

93 :デフォルトの名無しさん:01/09/25 01:46
>>88
エラー処理じゃなくて ERROR という状態なんだってば。
自分のアフォさをさらけだすだけだからもうよせって。

94 :デフォルトの名無しさん:01/09/25 01:46
DelのPersonalをダウンロードして、サンプルをいくつかコンパイル
してみたけど、噂ほどは早くないって印象だけど。

95 :デフォルトの名無しさん:01/09/25 01:54
>>94
そんなことはないだろう。
たいてい数秒以下で終わるぞ。DelPro だけど。
マシンの Mem が 32MB とかないよなー。

96 :デフォルトの名無しさん:01/09/25 02:00
速いとか遅いとか言っても、ほんの数秒の話だしね……

97 :デフォルトの名無しさん:01/09/25 02:10
C++のasm宣言

98 :デフォルトの名無しさん:01/09/25 02:59
>>97
asm って言語仕様にないだろう。特定の処理系の話になるんじゃないか。
まーそうは言ってもたいてい asm 使えるけど。

99 :デフォルトの名無しさん:01/09/25 03:36
>>83
x86の経験しかない厨房的質問でスマソ
使った事があるMMIOを提供しているボードは皆書き込んだ後にoutpを
要求しているんだけどこれって少数派?
#outport()で*ptrとoutp()を両立できないよね?って云ってますです

それとドライバを書く時に他CPUへの移植性なんて意識しちゃいないん
だけど、皆普通に考えてるもんなの?

微妙にスレ違いな気がするのでsage

100 :デフォルトの名無しさん:01/09/25 03:51
ひゃく

101 :デフォルトの名無しさん:01/09/25 04:01
reinterpret_cast の使い道が良く分からないです
単なるキャストとちがうのですか?

102 :デフォルトの名無しさん:01/09/25 04:25
このへん
http://piza2.2ch.net/test/read.cgi/tech/996640937/190-195

103 :デフォルトの名無しさん:01/09/25 04:42
valarray

104 :デフォルトの名無しさん:01/09/25 04:53
io/fstream

105 :101:01/09/25 04:57
>>102
ありがとうございます
明示的にキャスト変換を呼ばない(でいいのかな)んですね。
疑問が解けました。なかなかの曲者ですね。

106 :デフォルトの名無しさん:01/09/25 08:08
>>95
確かにDelのコンパイルは激速。
もちろん差分コンパイルは一瞬なのは言わずもがなだが、
手元の6万行くらいのコードを再構築(PenIII700MHz)してみたところかかった時間は5秒・・・。
思わず笑ってしまった。

昔はマシンスペックがあがればgccもVCのコンパイラもストレスなく使えると
思っていたがそうでなかったので少々がっかり。

107 : :01/09/25 12:09

コンパイルが遅いというか、
中間ファイルがデカい気がするのですが、
気のせい?>VC

108 :デフォルトの名無しさん:01/09/25 12:58
>>106
pascalはLL(1)文法で定義されているから速いのは当然
ただ、Delphiの文法もLL(1)文法かは知らない。

C言語はLR(1)(LALR)文法だから遅い。

109 :デフォルトの名無しさん:01/09/26 01:46
というかヘッダがテキスト取り込みなのが遅い原因と思うが…
あと#defineを置換して回るのも遅そうだ

110 :デフォルトの名無しさん:01/09/26 08:29
printf()でおなじみの「可変長引数」って実装したことないや。
なんであれがコンパイル通るんだろ。不思議でたまらん。
va_listマクロなんかは特別扱いされてんのかな?

111 :デフォルトの名無しさん:01/09/26 10:11
>>110

使ったことあるよ。
stdarg.hだっけ?

CVSの読み込みに%d,%s,%fみたいに読めるようにした。

112 :デフォルトの名無しさん:01/09/26 11:04
>>109
バカこけ。自分でテキスト置換プログラム書いてみろよ。
どんななアホが書いたって一瞬で終わるよ。

113 :デフォルトの名無しさん:01/09/26 11:20
I/Oアクセスは関数書いて抽象化出来るならそれに越した事ないけど
 速度的に出来ない場合も多いし
 関数内部じゃ結局 volatile 必用になる場合多いよね
 といっても最後はインラインアセンブラになっててvolatile 使わない事になるけど

114 :デフォルトの名無しさん:01/09/26 13:14
>>112
> どんななアホが書いたって一瞬で終わるよ。
お前もcppを書いてみてからそーゆー大口を叩け。

115 :デフォルトの名無しさん:01/09/26 14:45
>>114
正直、ありったけのインクルードファイルを読み込んでも、
そんなに重くならない気がする。
(内部で何してるかは知らないので、何ともいえないが。)

116 :デフォルトの名無しさん:01/09/26 19:27
>>108
Cも再帰下降でかけなかったっけ?
つまりLL(1)

117 :デフォルトの名無しさん:01/09/26 19:29
>>108
それと、Pascalのパースが速い理由は1パスだからで、
文法は関係無い。

118 :デフォルトの名無しさん:01/09/26 19:32
>>116
一カ所だけかけない部分があります。考えてみそ。

119 :デフォルトの名無しさん:01/09/26 19:39
if elseのネストってんでしょ

120 :デフォルトの名無しさん:01/09/27 02:53
>>118
ケッ、エラソーニ

121 :109:01/09/27 05:46
>> 112
うーむ、結構速く済むな。
でもDelphiなら同じ時間でコンパイルまで終わっちまいそうだが。
>> 119
Pascalのifもelseの前にセミコロンがあるかないかでCと同じ。勿論ネスト可能。
ということで違う気がする。
キャストかな。再帰下降なら(int*)Aとかで"("がキャストの括弧なのか
優先の括弧なのか区別がつかなさそう。

122 :デフォルトの名無しさん:01/09/27 20:12
>>116
純粋に LL(1) じゃないけど、だいたい再帰下降でパースできます。Dennis
謹製の初期 C コンパイラに関するドキュメントとソースコード。

http://cm.bell-labs.com/cm/cs/who/dmr/primevalC.html

そもそも最初の C コンパイラが世に出たときって、まだ LALR 用のコン
パイラジェネレータ存在してなかったから LALR ってことは、ありえない
でしょ。手作業で LALR 状態遷移表を計算するのは無謀だから、コンパ
イラジェネレータ無しだとやってられんし。

>>118
ほんとに一箇所?

123 :デフォルトの名無しさん:01/09/29 00:10
118はあふぉですので

124 :デフォルトの名無しさん:01/09/29 04:47
>> 108=118?
で、答えは?

125 :デフォルトの名無しさん:01/09/29 10:47
>>115
ありったけのインクルードファイルをインクルードしてみた。
86万行。

126 :デフォルトの名無しさん:01/09/29 13:17
VC++はプリコンパイル済みヘッダーという機能があります
これを使うと、ほとんど書き換わらないヘッダファイルが何万行あっても
遅くならないです

windows.hがデカイ遅いとお悩みの方は利用を検討してみては。
あと、gccに導入されないのが不思議。

スレ違いっぽいのでsage

127 :デフォルトの名無しさん:01/09/29 17:59
だから、108はあふぉですよ

128 :デフォルトの名無しさん:01/09/29 18:41
なんといっても、一番うっとおしいのはアロー演算子( -> )やな。
ドット( . )にしとけや!!!
C#では廃止されたけどな。

129 :デフォルトの名無しさん:01/09/29 18:42
>>128
ハァ?

130 :デフォルトの名無しさん:01/09/29 18:45
>>128
激しく同意!

131 :デフォルトの名無しさん:01/09/29 18:46
128 はアフォということで。

132 :デフォルトの名無しさん:01/09/29 18:47
>>128>>130はまともにC/C++が使える人間ならば出ない発言だと思うが…

133 :デフォルトの名無しさん:01/09/29 18:51
>>129>>131-132はまともにC/C++が使える人間ならば出ない発言だと思うが…

134 :デフォルトの名無しさん:01/09/29 18:52
暴れているのはJava厨房かな?

135 :デフォルトの名無しさん:01/09/29 19:29
>>132
禿同

>>133 は実体・参照・ポインタの区別の付かないJava厨房と思われ。

136 :デフォルトの名無しさん:01/09/29 19:39
Java厨は悲しいね。
理解できないのは言語仕様のせいですか。

137 :デフォルトの名無しさん:01/09/29 20:04
確かに -> の機能を . に置き換えても文法的に問題なさそう。
Cとの互換性以外は。

C++が言語仕様を複雑にしてるのは他人に自慢するため?
実体・参照・ポインタを区別して良いことある?
ほんとにその仕様はリーズナブル?

138 :デフォルトの名無しさん:01/09/29 20:08
>>137
GCがない分、stackに置いたobjectがスコープはずれて
自動でデストラクトされるのは非常に重要なんすが。

139 :sage:01/09/29 20:13
>>137
->と.は別に一緒でもいいと思うが、
参照とポインタが明確に区別されているからこそ、
低水準なプログラムもスマートに書けるようになるんだよ。

C++は高級言語ではないってこと、忘れてないか?

140 :デフォルトの名無しさん:01/09/29 20:23
>>139
C++ に限って言えば operator->() 使えないと、スマートポインタを実装するのに
困らない?

141 :デフォルトの名無しさん:01/09/29 20:29
>>137
> 確かに -> の機能を . に置き換えても文法的に問題なさそう。
文法勉強してから出直してこい

142 :デフォルトの名無しさん:01/09/29 20:46
>>137
マジで言ってんのかよ・・・
コンパイラコンパイラの本でも読んで、本当に問題が無いか考え直してくれ。

143 :デフォルトの名無しさん:01/09/29 20:56
>>142
つ−か137はJavaと同様にせよっていってるんじゃないの?
Java厨だね。

144 :デフォルトの名無しさん:01/09/29 20:59
>>138
それはわかる、けど3種類いらないでしょ。
実体とポインタで十分でしょ?

>>139
わかんない。参照あるとswapがかけるとか?

>>140
operator.()オーバロードできるようにしちゃえ

145 :デフォルトの名無しさん:01/09/29 21:03
Javaも十分複雑だとおもいます。
packageでのアクセス制限とか
コンストラクタでの仮想関数の挙動だとか
synchronizedの扱いが実は難しいとか
初心者泣かせで、かつ、実装ミスを誘発やデバグを困難にする原因になっていますね。
Java厨というのはそういうところまで使い込んでないんですよね。

146 :デフォルトの名無しさん:01/09/29 21:05
オブジェクトの実体参照は必要なし。すべてポインタを介してアクセスすればよい。
現にボーランドの言語製品はそうしてる。

147 :138:01/09/29 21:06
>>144
つまり、参照とポインタの両方あるのは何故?どうして?
っていう典型的な議論に帰結するわけね。
もう語り尽くされているからどうでもいい。

148 :デフォルトの名無しさん:01/09/29 21:06
Del厨まで登場かよ!

149 :デフォルトの名無しさん:01/09/29 21:07
わたしはJava厨房ではありません。Delphi厨房です。

150 :デフォルトの名無しさん:01/09/29 21:09
C++Builder のソース見てみろ。アロー演算子だらけだぞ。

151 :デフォルトの名無しさん:01/09/29 21:10
>>145
> packageでのアクセス制限とか
そうかな?暗黙なのがやなのか?

> コンストラクタでの仮想関数の挙動だとか
これはC++の方が決まってないことが多いだけで、
挙動がはっきりしてるJavaは分かり易いかと

> synchronizedの扱いが実は難しいとか
マルチスレッドはどの世界でも難しいんであって
言語レベルで取り込んでしまったからしょうがない。
けど、もうちょっと分かり易い実装でも好かったかも

っていうかなんでJavaを出したがる?

152 :デフォルトの名無しさん:01/09/29 21:11
JavaでOOPできてるPGはあまり見ないねー
C++プログラマーの3%はOOPができるみたいだねー
科学者のJavaプログラムはすごくきれいで読みやすいねー
C++でOOPを勘違いしてると、ある意味突っ込めない(w
実行時ポリモーフィズム使いずらいって,C++

153 :デフォルトの名無しさん:01/09/29 21:12
>>142
-> を . をまとめるって言ってる人は、

a.b

というコードが出てきたとき、a の型によって . の意味を変えようといってる
わけだよね(ちょうど [] に対するアセンブラ出力が、変数の型によって異な
るように)。

これは既存の文法と衝突せずに実装できそうな気がするんですが、パー
ズ不可能になるコードの実例を挙げられる人はいます?

>>144
operator.() をオーバーロードしたら、auto_ptr 自体のメソッドと auto_ptr に
格納されているオブジェクトのメソッドを区別できませんがな。

std::auto_ptr<foo> p;
p.reset(); // この reset() は auto_ptr<foo>::reset(), それとも foo::method() ?

154 :デフォルトの名無しさん:01/09/29 21:13
>>147
結論は?URLプリーズ

155 :デフォルトの名無しさん:01/09/29 21:13
>>152
意味不明な上に、スレ違い。

「C/C++のこの機能逝って良し」に関係ない話題は yoso でやってくれ。

156 :デフォルトの名無しさん:01/09/29 21:14
Java はオブジェクト指向を徹底しすぎて逆に使いにくい部分がある。
グローバルな関数を作りたい時もあるんだよ。

157 :デフォルトの名無しさん:01/09/29 21:15
>>152
ソースを示せ。つーかPGって何だよ。ペログリしかおもいつかねえ。

>>138
そうだな。std::stringをnewしねえと駄目なんじゃ、Cとかわらん(藁
悪夢だ。

158 :デフォルトの名無しさん:01/09/29 21:16
>>156
定数一つ宣言するのも、オブジェクトのメンバにしないといけないし。

159 :デフォルトの名無しさん:01/09/29 21:18
>>156
ハァ?つくれるじゃん。staticなメソッドに我慢がならない
のか?C厨は名前空間(一般名詞)の概念も理解できないのかね。

160 :デフォルトの名無しさん:01/09/29 21:19
>>158
s/オブジェクト/クラス/ だね。

C++ でコード書くときにも、定数やグローバル関数は namespace 切るから、
手間は大差ないと思うが。

161 :デフォルトの名無しさん:01/09/29 21:20
とりあえず、Java知らないやつが結構多いよね
C++でできるオブジェクト指向って・・・

162 :デフォルトの名無しさん:01/09/29 21:21
>>161
具体的に C++ の機能を批判するのではなく感想文を書きたいだけなら、
逝ってくれ。

163 :デフォルトの名無しさん:01/09/29 21:25
じゃぁ話題を。
C99のこの機能逝ってよし!を誰か提供してくれ。読みたい。

164 :デフォルトの名無しさん:01/09/29 21:26
>>153
> std::auto_ptr<foo> p;
> p.reset(); // この reset() は auto_ptr<foo>::reset(), それとも foo::method() ?
.をオーバーロードした人はpublicなメソッドを持つのは諦める。
auto_ptr<foo>::reset(p)

あるいは他の単項演算子でアクセサクラスを返すようにして、
(*p).reset()
とか

165 :デフォルトの名無しさん:01/09/29 21:26
VB厨房も仲間に入れてください…

166 :デフォルトの名無しさん:01/09/29 21:28
駄目>165

167 :デフォルトの名無しさん:01/09/29 21:31
>>163
とりあえず、リンク張っとくか。

プログラミング言語 C の新機能
http://www.geocities.co.jp/SiliconValley/1002/c99d/

個人的には bool ではなく _Bool ってのがショックだったが。

168 :デフォルトの名無しさん:01/09/29 21:41
機能拡張して良くなってんのか?
可能性は広がるとしても、複雑化するのは止めてほしい!

169 :デフォルトの名無しさん:01/09/29 21:47
>>167
多重継承できないクラス逝ってよし
と思ったけど無かった。保守的な規格だったのね。

170 :デフォルトの名無しさん:01/09/29 21:48
VCで採用されなきゃ意味無し。 >C99

171 :デフォルトの名無しさん:01/09/29 21:59
>>170
VC++でC言語でプログラム書くような人たちって存在するの?
俺はUNIX屋だからよくわからんのだが。

172 :デフォルトの名無しさん:01/09/29 22:00
>>171
まあ、極稀に。
普通はC++だろうなぁ。

173 :デフォルトの名無しさん:01/09/29 22:07
class使わなければCとたいしてかわらん。

174 :デフォルトの名無しさん:01/09/29 22:14
>>170
C99 も gcc あたりで実装してくれると嬉しい人は多いと思うが。

VC++ には、C99 はどうでも良いから、むしろ早く ANSI C++ に準拠して template
まわりのバグをつぶして欲しい。

175 :153:01/09/29 22:18
結局 >>142-143 は勘違いだったってことで、ファイナルアンサー?

176 :sage:01/09/29 22:25
>>171
UNIXみたいなとこにポートすることを前提にしてる場合は有り。

177 :sage:01/09/29 22:26
>>140
困るね。気づかなかったすまん

178 :デフォルトの名無しさん:01/09/29 22:30
C++の強化版がC#ということでいいですか?みなさん。

179 :デフォルトの名無しさん:01/09/29 22:33
C#できればC++しなくていいのなら
C#マンセー

180 :デフォルトの名無しさん:01/09/29 22:35
>>178 かなり良くはなっているけど、
MSが提供する既存APIの呪縛からは逃れられないのかね〜?

181 :デフォルトの名無しさん:01/09/29 22:45
C#では基本的にWindowsAPIを直接コールすることはしない(やろうと思えば出きるが)
すべてCLRのライブラリを介して行うのだ。

182 :デフォルトの名無しさん:01/09/30 01:28
.と->の話題が気になって追いかけてたんだけど、>>153へのレスはないの?>.と->両方要る派の人

183 :デフォルトの名無しさん:01/09/30 01:54
>>181
だったらjavaでいいじゃん。

184 :デフォルトの名無しさん:01/09/30 04:00
javaってjavaしか(シームレスには)使えないっていうのがもう時代遅れの感があるね。
開発者の頭もカタくなってしまうし、周りが見えなくなるし、javaは弊害が多いね。

185 :デフォルトの名無しさん:01/09/30 05:27
MSはJavaの名前を使えなくなったから新しい言語を作ったのだ。C#=Java + ObjectPascal + C++

186 :デフォルトの名無しさん:01/09/30 05:30
>>185
VBが入っていないYO!

187 :デフォルトの名無しさん:01/09/30 05:32
>>185
っていうか C# = VJ++ + Delphi + VC++

188 :デフォルトの名無しさん:01/09/30 05:59
C#にはCも入ってる?(ANSIライブラリ)

189 :デフォルトの名無しさん:01/09/30 06:34
奥までくわえてもらうとすごくいいです。

190 :189:01/09/30 06:35
すみません。スレ違いでした。

191 :デフォルトの名無しさん:01/09/30 06:53
んー、でも意味は通るな 藁

192 :デフォルトの名無しさん:01/09/30 07:59
>>188
入ってない。

193 :デフォルトの名無しさん:01/09/30 13:51
っていうか、C/C++以外の言語逝ってよし。
Del厨やVB厨やshigeがこの世から消えるからな。

194 : :01/09/30 14:35
>>193
C#はどうなるよ?
逝っていいの?
(あえて二行目には突っ込まない(w

195 :デフォルトの名無しさん:01/09/30 14:41
>>194
C#は存在していてもまだ実務で使われるレベルのものじゃない(製品が無い
それから、システムを記述できる万能言語でもないから、無くてもいい
C/C++があれば事足りる。

196 :デフォルトの名無しさん:01/09/30 14:42
アセンブラとCとC++以外は消えて無くなるような予感・・・。

197 :デフォルトの名無しさん:01/09/30 15:14
キミが消えてなくなるような予感・・(藁

198 :デフォルトの名無しさん:01/09/30 15:54
>>196
普通にBasicも生き残るダロ。
使<s>え</s>わないけど(;´Д`)

199 :デフォルトの名無しさん:01/10/01 01:50
-> を . に置き換えるというと、
(*p).a みたいにするって事?
p[i].a ならよく使うよ。

200 :デフォルトの名無しさん:01/10/01 02:13
VCで
ifstream f1(argv[1], ios::in | ios::);
つかえねーじゃんか!!

201 :デフォルトの名無しさん:01/10/01 02:58
C/C++にもlispの内部定義(+無名関数)とか入れて欲しいなあ。
多分、文法上は関数定義が置ける以外は何も変わらないと思う。
そういうプリプロセッサでもあったらいいんだけど。

202 :デフォルトの名無しさん:01/10/01 03:57
つうかC++は機能拡張よりもシンプルになるべき!
あっそれがC#やjavaか・・・。

203 :デフォルトの名無しさん:01/10/01 04:35
>>201
ローカル関数みたいの?
そんで inline 展開されたりすると素敵。

>>202
C/C++ と C#/Java 系は字面的にちょっと似せてあるだけで
方向性が全然違うと思う。単純に比較するのもどうかと思う。

204 :デフォルトの名無しさん:01/10/01 05:05
>>201
nested functionならgccの拡張にあるねぇ
foo (double a, double b) {
double square (double z) { return z * z; }
return square (a) + square (b);
}
無名関数/無名クラスは欲しいなぁ
STLと食い合わせてみたい

やっぱ、C/C++は臨床実験言語として
いろんな機能を取り込んでってほしいかな。
漏れは普段使わないから

205 :デフォルトの名無しさん:01/10/01 05:07
>>203
ローカル関数なら、関数の中でクラスを宣言してstaticなクラス関数を書けば、
それがローカル関数にならなくもない。in C++。こんなかんじ。

void test{
class FUNC{
public:
static void function(){ printf("test");};
};
FUNC::function();
}

コールバック書くときとかに時々使える。あんまりつかうとソースが汚くなる。

206 :203:01/10/01 05:14
わかってると思うけど、
可能なのとサポートされてるのは違うじゃん。

207 :デフォルトの名無しさん:01/10/01 05:24
>>203
方向性として

C++ は豊富な言語仕様/効率性重視
C#/Java はシンプルな言語使用に豊富なライブラリ/仮想マシンによる抽象化

と、ぜんぜん違うと思う。

208 :デフォルトの名無しさん:01/10/01 08:31
>>205
char v[] = {...};
qsort(v. sizeof(v), sizeof(v[0]), int __cdecl lambda(const void* e1, const void* e2) { return *(char*)e1 - *(char*)e2; });

209 :デフォルトの名無しさん:01/10/01 08:33
ちなみに、そういうプリプロセッサ何年か前に書いたことあったけど、
使わなかったから消したと思う

210 :デフォルトの名無しさん:01/10/01 14:02
>>208
おお、なるほど。俺はついインラインアセンブラで書いちゃう(w

211 :デフォルトの名無しさん:01/10/01 14:10
実行効率 java < C/C++
開発効率 java > C/C++

212 :デフォルトの名無しさん:01/10/02 01:48
>>211
物によるダロ>開発効率

213 :デフォルトの名無しさん:01/10/02 11:40
>>212

Hello World の開発効率はどっちが有利でしょう?

214 :デフォルトの名無しさん:01/10/02 11:54
hugeポインタ最近使った?

215 :デフォルトの名無しさん:01/10/02 13:28
暗黙の型変換逝ってよし,という漏れは潔癖厨房ですか?

216 :デフォルトの名無しさん:01/10/02 14:49
んー、組み込み型間の暗黙の変換は必要だろうなぁ。これを否定しちゃうと
ちょっと厨房カモ。

でもユーザー定義型を含む暗黙の型変換は、極力使うべきではないってのが、
最近の流れじゃないんですか?どうなんでしょう。

217 :デフォルトの名無しさん:01/10/02 23:27
explicitじゃなくてimplicitキーワードを導入すれば良かったのにねぇ。
なんかFortranを思い出すな。

218 :デフォルトの名無しさん :01/10/03 04:07
>>216
integral <-> pointerも許すの?
subtype関係にないtype間の暗黙の型変換は有害だよ。

219 :デフォルトの名無しさん:01/10/03 07:46
>>213
JavaよりC++Builderのほうが上。

220 :デフォルトの名無しさん:01/10/03 09:34
>>217
> explicitじゃなくてimplicitキーワードを導入すれば良かったのにねぇ。
explicitは明示しろってことだろう。

221 :デフォルトの名無しさん:01/10/03 10:57
>>220
暗黙の型変換を行うのがデフォルトではなくて、
implicitで明示しない限り型変換できないようにすべきということだろ?

222 :デフォルトの名無しさん:01/10/03 13:02
> 暗黙の型変換を行うのがデフォルトではなくて、
> implicitで明示しない限り型変換できないようにすべきということだろ?

暗黙にするときは明示しろ!ってなんかすごいね

223 :デフォルトの名無しさん:01/10/03 13:06
つーかimplicitなんか導入した日にゃ、
今までのコードがコンパイルできなくなるんだが?

224 :216:01/10/03 14:33
>>218
あれ、integerとポインタ間って暗黙変換できましたっけ?
C++では少なくともワーニング出ると思うんだけど。

最近Javaばっかりだから記憶があいまいだ...

225 :216:01/10/03 14:35
あー、スマソ。オレの「組み込み型間の暗黙の変換は必要だろうなぁ」から
「integerとポインタも組み込み型だから、暗黙の変換は必要だ」と解釈した
わけね。

前言撤回。「C++で許される組み込み型間の暗黙の変換は必要」に改めます。

226 :デフォルトの名無しさん:01/10/03 22:04
>>223
クラス定義の最初にimplicit none; と書くのさ。
Fortran77に習って。
あとimplicit virtual;で暗黙的に仮想関数になる機能とか。
文法ぐっちゃぐちゃ。

227 :デフォルトの名無しさん:01/10/04 01:21
>>213
だから〜
何でやるんだYO?

メッセージボックス一個とかよ?
それとも単にprintfちっくにやるだけでいいのかよ?
それともウィンドウ作らないときがすまないのかよ?

わかんね〜YO

228 :デフォルトの名無しさん:01/10/04 10:14
>>224
> あれ、integerとポインタ間って暗黙変換できましたっけ?
> C++では少なくともワーニング出ると思うんだけど。

Warningってのは、lint++の機能をcompilerが持ったというだけで、C++の仕様とは違うだろ。
integral <-暗黙型変換-> pointerは、0がnull pointerと同時に逝ってよし大賞。

>>225
subtype関係にあるclass同士はどうするんだー?明示なのか?

229 :デフォルトの名無しさん:01/10/04 12:00
>>228
C++では0をNULLの変わりに使わないか?
void*からの変換でwarning出るし

230 :216:01/10/04 12:43
>>228
integerとpointerは暗黙変換できませんでした。最初から確認すればよかったね。
具体的にはVC++6.0では以下の文はそれぞれエラー(C2440)でした。
char *p = 0x10000;
int n = p;

0リテラルがnull pointerっつーのは、Cとの互換を考えると仕方ないとも思うけど、
言語仕様としては望ましくないと思うね。

subtype関係にあるclass同士ってのは、どういうこと?以下のクラスがある時に
class Foo {..};
class Goo: public Foo {...};

Foo f = Goo(..); のとき?これはトラブルの元になりやすいから、暗黙変換を禁止
していいんじゃないかなぁ。

Foo *p = new Goo(..); は 「Goo型へのポインタ」という組み込み型から「Foo型への
ポインタ」という組み込み型への変換だよね。で、C++では許されている暗黙変換なので、
これはOKだと思う。参照も同じだよね。

231 :デフォルトの名無しさん:01/10/04 21:19
>>228
どうでもいいが、本気で整数型を integral だと思ってる?

232 :228じゃないが:01/10/04 22:07
integral は「整数の」という意味の形容詞だが、なにか問題でも?
(「積分の」という意味と無理やり混乱したいとでも??)

233 :デフォルトの名無しさん:01/10/04 23:54
>>231
> どうでもいいが、本気で整数型を integral だと思ってる?

すまん、疑問形で投げかけられても、意味が分からん。明確に話してくれ。
”Integral type”ってのは、翻訳本だと、

論理型、文字型、整数型は整数系データ型: integral typeと総称され、

のことだ。Cの頃からの用語。

>>230
ああ、参照は組み込み型だっけ…(今、自宅なので規格書がない)

234 :231:01/10/04 23:57
>>232-233
なるほど。勉強になったよ。

235 :デフォルトの名無しさん:01/10/05 00:15
>>234 素直で(・∀・)イイ!!

236 :デフォルトの名無しさん:01/10/05 03:32
教養のために一言
integerの読みはインティジャーです。
あなたはインテガーとか逝っていませんか?

237 :デフォルトの名無しさん:01/10/05 09:07
>>236
超合金ロボみたいだ、インテガー

238 :デフォルトの名無しさん:01/10/07 01:21
>>205
>ローカル関数なら、関数の中でクラスを宣言してstaticなクラス関数を書けば、
>それがローカル関数にならなくもない。in C++。こんなかんじ。

でも、その関数内クラスってテンプレートに使うとかーちゃんに怒られるんだ
よなぁ。言語仕様的にもダメなのかは知らんけど。STLマンセーな俺的にはちょ
っと不便。

下がってきたので保守age

239 :デフォルトの名無しさん:01/10/07 22:18
>>238
俺もだ。VC++特有かな?
言語仕様かな?

むしろlambda classきぼーん。
gccには拡張構文であるんだっけ?

240 :デフォルトの名無しさん:01/10/07 22:30
>>239
テンプレートの中身にはローカルな型は使えないぞゴルァ!って怒られるんだっけね。

241 :名無しさん:01/10/07 22:41
俺は
おまえの
フレンドだ

242 :デフォルトの名無しさん:01/10/07 22:42
俺の物は俺の物。
お前の物は俺の物。

243 :デフォルトの名無しさん:01/10/08 03:57
↑ジャイアン発見

244 :デフォルトの名無しさん:01/10/08 13:03
↑Yahoo発見

245 :デフォルトの名無しさん:01/10/08 13:10
↑Geocityesかよ

246 :デフォルトの名無しさん:01/10/08 13:26
↑Geocitiesだろ。ネタじゃないよね?(プププ

247 :デフォルトの名無しさん:01/10/08 13:37
>>246 シマッタ。外資で働いてるのに。鬱で氏んで来る。

248 :デフォルトの名無しさん:01/10/08 20:24
ttp://www.sptopix.com/icp/5333/japanese/5333top_j.html
ココ?>>247

249 :デフォルトの名無しさん:01/10/08 21:34
274>>248 座布団やるよ。俺の遺品だけど取っといてくれ。

       ||
     Λ||Λ
    ( / ⌒ヽ
     | |   |
     ∪ / ノ
      | ||
      ∪∪

56 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)