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

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

プログラミング雑談スレ++

1 :デフォルトの名無しさん:2013/11/14(木) 18:55:43.66
プログラミングに関する雑談スレッドです。

■前スレ
プログラミング雑談スレ
http://toro.2ch.net/test/read.cgi/tech/1363792124/

2 :デフォルトの名無しさん:2013/11/14(木) 18:57:39.82
               ノ      ゚.ノヽ  , /}      ...
            ,,イ`"     、-'   `;_' '    ..::::::::::::::...
   ,-、  _.._   (        (,(~ヽ'~     ..:::::::::::::::::::::::
 )'~  レー'  〉   ヽ       i`'}       .:::::::::::::::::::::::
 ~つ     '-ー、  i       | i'     ...:::::::::::::::::::::::
 /       <  /     。/   !  ......:::::::::::::::::::::::::    これは>>1乙じゃなくて
/         ~^´     /},-'' ,●::::::::::::::::::::::::::::::::::::
i、        ,i' _,,...,-‐-、/    i  ::::::::  .:::::::::::::
..ゝ        <,,-==、   ,,-,/      .:::::::::::            放射能がうんたら
 )       {~''~>`v-''`ー゙`'~       ..:::::::::                          ........::.
 {        レ_ノ            ..::::::::.                         ......:::::::::
ノ         ''           ..:::::::                        ...::.:...:::::::::
                     .:::::::::                     ...:......:::::::::::: .
                    .:::::::::::.        .....      ..  ..::::::::::::::::::::::::   :::.
                    ::::::::::::::::.::::::....:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::.. ::  ::..
                    .:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::    ::.
                    ::::::::::::::::: :::::::::::::::::::::::::::::: :::::
                          .::    ::.  :::

3 :デフォルトの名無しさん:2013/11/14(木) 19:17:26.04
>>1


3スレ目は、
「プログラミング雑談スレ#」
になるんだろうか

4 :デフォルトの名無しさん:2013/11/14(木) 19:36:24.30
>>1

>>3に俺が言いたかった事言われた

5 :デフォルトの名無しさん:2013/11/14(木) 19:53:24.78
>>1

その次はDだな

6 :デフォルトの名無しさん:2013/11/14(木) 20:01:28.20
次スレの名前が楽しみだ
++++にならない事を願う

7 :デフォルトの名無しさん:2013/11/14(木) 20:57:58.06
+++でいいんじゃね

8 :デフォルトの名無しさん:2013/11/14(木) 20:58:58.19
いや+が無かったからそれはおかしい

9 :デフォルトの名無しさん:2013/11/14(木) 21:25:34.86
クイックソートの時代は何十年も前に終わってる

10 :デフォルトの名無しさん:2013/11/14(木) 21:26:45.75
Javaでスマホアプリ作りたいんだけど
どんな知識が必要?ExcelVBAとUNIX系とSQLを少しずつできる程度です
Javaでのアプリ開発の参考書で作れるようになる?

11 :デフォルトの名無しさん:2013/11/14(木) 21:27:34.57
timソートをポインタ使って高速化したtimpoソートが最速

12 :デフォルトの名無しさん:2013/11/14(木) 21:27:35.43
全スレ>>993がOpenCLで高速なクイックソートを書いてくれるそうです。
皆さん正座して待ちましょう。

13 :デフォルトの名無しさん:2013/11/14(木) 21:28:53.49
単純ソート、クイックソート、バブルソート
それぞれのロジックを簡単に説明して下さい

14 :デフォルトの名無しさん:2013/11/14(木) 21:29:43.47
class Program
{
  static void Main(string[] args)
  {
    int プログラミング雑談スレ = 1;

    Console.WriteLine(プログラミング雑談スレ++);
  }
}

15 :デフォルトの名無しさん:2013/11/14(木) 21:32:56.76
>>10
Javaのうすい参考書かるーくやって
Androidの参考書を書いたまえ。
飽きてやめることのないよう、わからない事はおまじないとしてどんどんスルーしたまえ。
作ってたらそのうち詳しくなってくる。

16 :デフォルトの名無しさん:2013/11/14(木) 21:36:16.73
>>13
単純ソートとバブルソートって同じじゃね?

17 :デフォルトの名無しさん:2013/11/14(木) 21:37:09.71
>>15
おまじないが肝なのだと読みました。アドバイスありがとうございます!

18 :デフォルトの名無しさん:2013/11/14(木) 21:55:00.46
>>15
いきなり執筆しろとはハードルたけえな

19 :デフォルトの名無しさん:2013/11/14(木) 22:29:11.77
http://ogawa.s18.xrea.com/tdiary/20121111p01.html

#include <stdio.h>

double f(double d) { return d + 1.0; }

int main() {
if (f(0.1) == f(0.1)) {
printf("equal\n");
} else {
printf("not equal\n");
}
return 0;
}

>次のプログラムをx86上のGCC 4.6.3でオプションなしでコンパイルすると、「not equal」が出力される。
とあるように手元にあるgccでビルドしたところ「not equal」が表示されました。
これはなぜなんでしょう。怖くて夜も眠れません。

20 :デフォルトの名無しさん:2013/11/14(木) 22:56:11.60
バグとしか思えねぇ…

21 :デフォルトの名無しさん:2013/11/14(木) 23:00:30.99
#include <stdio.h>

double f(double d) { return d + 1.0; }

int main() {
if (f(0.1) - f(0.1)) {
printf("not zero\n");
} else {
printf("zero\n");
}
return 0;
}

22 :デフォルトの名無しさん:2013/11/14(木) 23:03:10.81
1.0 - 0.9 != 0.1
ってのは浮動小数点問題で普通にあるけど>>19は初めて知った

23 :デフォルトの名無しさん:2013/11/14(木) 23:16:04.60
正確な引き算が出来ないからだろ

24 :デフォルトの名無しさん:2013/11/14(木) 23:23:25.47
え?

25 :デフォルトの名無しさん:2013/11/14(木) 23:25:26.22
浮動小数点は演算誤差が生じるけど同じ値を同じ手順で演算すれば同じ演算誤差が再現されるはず
だから両者で行われている演算の内容が異なると見るしかない
最初の f(0.1) の結果はいったんメモリに格納されるために 64 ビットの精度に落ちて
2度めの f(0.1) の結果はレジスタに載ったまま 80 ビットの精度が維持され
それを比較したために結果が異なるんではないかと推測するがどうか

26 :デフォルトの名無しさん:2013/11/14(木) 23:34:02.20
推測も何も常識だろ
http://0xcc.net/blog/archives/000164.html

27 :デフォルトの名無しさん:2013/11/14(木) 23:37:32.62
常識だね

28 :デフォルトの名無しさん:2013/11/14(木) 23:45:01.68
VCではzeroになるから問題だろ

29 :デフォルトの名無しさん:2013/11/14(木) 23:47:02.67
なるほど、わかったぞ…………………………つまりバグだな!!!

30 :デフォルトの名無しさん:2013/11/14(木) 23:52:11.87
常識て
バグだろ

31 :デフォルトの名無しさん:2013/11/15(金) 00:09:26.61
> A floating expression may be contracted, that is, evaluated as though it were an atomic operation,
> thereby omitting rounding errors implied by the source code and the expression evaluation method.
とあるから規格で認められている挙動になるのでは?

32 :デフォルトの名無しさん:2013/11/15(金) 00:14:11.25
絶対値が十分小さい数e以下っていう妥協策を用いるんだけどこのeって定数は用意されてる?

33 :デフォルトの名無しさん:2013/11/15(金) 00:14:59.47
差の絶対値

34 :デフォルトの名無しさん:2013/11/15(金) 00:15:44.95
>>32
目的に応じてその値を定めるのが設計

35 :デフォルトの名無しさん:2013/11/15(金) 01:04:25.73
必読書スレ誰も立てないのか

36 :デフォルトの名無しさん:2013/11/15(金) 02:03:53.94
>>9
え?
今はなに?

37 :デフォルトの名無しさん:2013/11/15(金) 02:06:07.76
>>32JavaScriptだと
Number.EPSILON = 2.2204460492503130808472633361816E-16
ただしdouble同士の誤差

38 :デフォルトの名無しさん:2013/11/15(金) 02:37:12.18
機械イプシロンはそういう用途には使えないな
ちょっと小さ過ぎる

39 :デフォルトの名無しさん:2013/11/15(金) 07:55:48.21
>>36
マージソート

40 :デフォルトの名無しさん:2013/11/15(金) 10:11:09.82
1回の演算の丸め誤差は確かこれでいけるんじゃなかったっけ?
abs(a-b) < max(a,b) * 2 * EPSILON

41 :デフォルトの名無しさん:2013/11/15(金) 10:56:51.63
>>40
どういう意味?

42 :デフォルトの名無しさん:2013/11/15(金) 12:04:58.65
右辺は確か、演算結果の精度(仮数部の最下位ビットが表す数)を
計算する式だった希ガス

左辺って何だっけ

43 :デフォルトの名無しさん:2013/11/15(金) 16:20:41.63
このスレ 解答側のレベルが
微妙に低くていいね
入りやすいよ

44 :デフォルトの名無しさん:2013/11/15(金) 16:25:29.55
質問側のたった数行の文字列から思惑を推測して、それっぽいレスでいなす。のがうまいと言ってほしいな

45 :デフォルトの名無しさん:2013/11/15(金) 16:28:32.25
arctan 1の展開刑
Σ(-1)^(n-1)・1/(2n+1)の四倍が
3.14159265に近づいていかないのは
丸め誤差が原因

46 :デフォルトの名無しさん:2013/11/15(金) 16:43:51.28
Stringのformatで小数点5桁くらいまで文字列にしてコンペアーしろ

47 :デフォルトの名無しさん:2013/11/15(金) 16:52:19.17
あと このスレって
何言語で質問したり答えたりしてるのか
よくわからん

48 :デフォルトの名無しさん:2013/11/15(金) 16:55:00.35
レス=質問なのか?
自分の経験したことある言語でのふと思った事をただ書いてるだけじゃないのん

49 :デフォルトの名無しさん:2013/11/15(金) 17:04:55.15
言語を限定したスレじゃないし、何でもいいんじゃない
マイナーな言語はレスが減るかもしれないが

50 :デフォルトの名無しさん:2013/11/15(金) 17:18:20.17
N+にプログラムスレが立った時に
やたらEXCEL推しが凄かったんだが
その中でINDIRECT関数が凄い便利ってレスしてる奴が居たんだが
使ってみたけどそんなに2chで喧騒するほどでもないと感じたんだが
俺が思うより便利な使い方があるのだろうか?

ただ単にプログラムしない奴がEXCELで
多少動的な処理出来たから感動したってだけなのかな?

51 :デフォルトの名無しさん:2013/11/15(金) 17:21:59.73
>>50
N+ってどんな言語なんだ!?って思った

52 :デフォルトの名無しさん:2013/11/15(金) 17:35:44.04
>>43
× 解答
○ 回答

キミのレベルも微妙……じゃないけど低くていいね。

53 :デフォルトの名無しさん:2013/11/15(金) 17:39:36.66
>>52
すまんな
関数型言語出身だから
解答のがしっくりくる

プログラムの実行じゃなくて評価みたいなもんで

54 :デフォルトの名無しさん:2013/11/15(金) 18:58:16.83
自動大量ウェブクエリから統計とって株の指針にしてる。
これ始めてから充分食えるだけの利益出るようになった。

55 :デフォルトの名無しさん:2013/11/15(金) 19:07:58.78
>>54
そういうのは秘密にしとかなきゃいけませんよw

56 :デフォルトの名無しさん:2013/11/15(金) 19:12:36.32
>>55
実はそれ逆なんです。
おおっぴらに書くと仕手筋認定されるので書けないだけで、自分が何を買ったか
何を買うべきか公表できるなら公表したほうが儲かるんですよ。

57 :デフォルトの名無しさん:2013/11/15(金) 19:14:29.50
>>56
なんだその程度のプログラマなんですか。忠告した僕がバカでした。

58 :デフォルトの名無しさん:2013/11/15(金) 19:21:47.87
大量の情報を生かして捌くのがプログラマの最たるものだ

59 :デフォルトの名無しさん:2013/11/15(金) 20:02:44.18
仮に本当だとしてもいつかは壁にぶつかる
自分が売買する量が増えていくと

60 :デフォルトの名無しさん:2013/11/15(金) 20:52:51.55
ExcelはBefungeのなりそこない

61 :デフォルトの名無しさん:2013/11/15(金) 21:19:52.22
風評の流布ですね
わかります

62 :デフォルトの名無しさん:2013/11/15(金) 21:35:22.91
ていうか、もっといい方法が見つかったから競合者を潰すためにやってるんだろ

種あかしをすれば、ビッグデータ解析で株取引のハブをみつけたんだな。
そんなビッグデータを扱えるのは大会社のコンピュータだけなんだが・・・

インサイダー取引か、業務上背任で通報しとくよ。


















#ハブはどこだYO,こっそり教えろよw

63 :デフォルトの名無しさん:2013/11/15(金) 21:38:33.23
1000
800
600
400
400
400
200
ってデータがあった時に
1000
800
600
402 (更新)
401 (更新)
400
200
っていう処理が必要なんだけど、思ってたより凄い面倒。思いつかん。
要するに降順ソートしたい際に、値をユニークにしたいだけなんだが。センス無いのかね

64 :デフォルトの名無しさん:2013/11/15(金) 21:40:08.91
アドレス割り当てろよ

65 :デフォルトの名無しさん:2013/11/15(金) 22:14:18.15
普通にけつから2要素ずつ比較していって百の位が同じなら頭+1でいいんじゃね

66 :デフォルトの名無しさん:2013/11/15(金) 22:18:33.57
>>65
そうやると・・・
200と400。何もしない
400と400。上を401にする
401と400。何もしない
って動いて、
1000
800
600
400
401
400
200
ってなるって、30分考えて気付いた

67 :デフォルトの名無しさん:2013/11/15(金) 22:21:13.02
ソート後に走査すりゃいいだけじゃないの

68 :デフォルトの名無しさん:2013/11/15(金) 22:27:01.54
ソートしてn=1して下から比較していく
同じなら n足す
小さいなら n=n+1してからn足す
大きいなら n=1する

69 :デフォルトの名無しさん:2013/11/15(金) 22:38:20.52

だめだ

70 :デフォルトの名無しさん:2013/11/15(金) 22:40:43.04
考えるほどドツボにはまる嫌らしい要求なんだよ

71 :デフォルトの名無しさん:2013/11/15(金) 22:45:14.38
if( p[i] >= p[i+1] ){ p[i+1] = p[i] + 1; }

72 :デフォルトの名無しさん:2013/11/15(金) 22:49:10.44
>>71
上からまわしてるの?下からまわしてるの?

73 :デフォルトの名無しさん:2013/11/15(金) 22:50:31.00
何が難しいかわからん。ソート中にやろうとするからこんがらがってるのでは

74 :デフォルトの名無しさん:2013/11/15(金) 22:52:01.15
>>63
ユニークにできないくらい詰まってたらどうすんだよ

75 :デフォルトの名無しさん:2013/11/15(金) 23:04:22.58
データはアクセス時間を意味して、longのエポックタイムが入っている
もともとは新しい奴を上、古い奴を下と、エポックタイム降順でソートしていた
仕様変更でこの順序を手動で並び替えできるようにする必要があった
ソートインデックスをカラムに追加するのは面倒なので、エポックタイプをあれこれして手動ソートできるようにしたい

という最悪の設計思想の結果これが必要になった。
ユニークにできないくらい詰まってるほどのデータ件数はない

76 :デフォルトの名無しさん:2013/11/15(金) 23:06:04.79
>>12
OpenCL関係なくね。
それにクイックソートとかは初回が終われば問題が分割されるから並列化は余裕。

バブルの方は良く分らんが・・・
バブルで回すようなサイズの問題が出てきて並列の速度求める状況なら、
問題自体を並列に回せるだろうから実用上問題ないとかじゃないかな。

>>39
マージはワークエリアが要るんじゃなかったか。

77 :デフォルトの名無しさん:2013/11/15(金) 23:10:05.15
>>66
どうしてそうなる
200と400。何もしない
400と400。上を401にする
401と400。上を402にする
ってなるだろよく読め
百の位以上の桁、つまり/100したのが等しいかで確認すればいいんだよ

78 :デフォルトの名無しさん:2013/11/15(金) 23:14:02.55
比較用の列を2つにして
メインが同じ数だったら、サブの数値で比較するのが普通だけどな。

79 :デフォルトの名無しさん:2013/11/15(金) 23:23:07.61
>>78
だな。
1足していって突き抜けないかどうかのケアがいるし、
足すことに対する整合性で早速困ってるじゃないか。

80 :デフォルトの名無しさん:2013/11/15(金) 23:25:15.77
こういう感じか
当然同じ数値は100個以下でなくちゃいけないけど

arr = [1000,800,600,400,400,400,200]

arr.reduceRight((r,l,i,a)=>((r/100|0)==(l/100|0))?(a[i]=r+1):l)

arr //[1000,800,600,402,401,400,200]

81 :デフォルトの名無しさん:2013/11/15(金) 23:32:52.49
ソート済だからもっと単純化出来るか

arr.reduceRight((r,l,i,a)=>(r-l)/100|0?l:a[i]=r+1)

82 :デフォルトの名無しさん:2013/11/15(金) 23:43:55.86
>>76
御託はいいからOpenCLで並列クイックソートと
バブルソートはよう。並列化に耐えるんだろ。

83 :デフォルトの名無しさん:2013/11/16(土) 01:22:38.05
Linuxのコマンドだと、ソートして、
連続した重複行を1行にまとめるのは、よくある
sort | uniq

1行にして書くと、
400,200,400,600,400が、
600,400,200になる

また逆に、uniqで、重複行だけも取り出せる
sortにも、重複をなくすオプションもあるかも

84 :デフォルトの名無しさん:2013/11/16(土) 08:10:52.73
重複を無くすって消し去っちゃマズイだろww

85 :デフォルトの名無しさん:2013/11/16(土) 09:21:48.83
map<int,int>は使えないのか?
valueのデフォを0として、
int uniqval(int key ){
int ans = map[ key ] + key
map[ key ] = map[ key ] + 1
return ans; }
でいける気がするけど。

86 :デフォルトの名無しさん:2013/11/16(土) 09:51:17.53
2chでインデント崩さずにコード張り付けるのは
どうやったらいいの?

87 :デフォルトの名無しさん:2013/11/16(土) 09:59:10.48
codepadとかideoneとかを使う

88 :デフォルトの名無しさん:2013/11/16(土) 11:09:25.39
全角スペースを使えばいいよ

89 :デフォルトの名無しさん:2013/11/16(土) 12:01:03.33
>>85
setつかえよ

90 :デフォルトの名無しさん:2013/11/16(土) 12:22:32.38
前の数+1で何か問題があるの?

91 :デフォルトの名無しさん:2013/11/16(土) 12:37:49.37
このソースはきちんとインデントされていますがバカには見えません
と宣言すればおk

92 :デフォルトの名無しさん:2013/11/16(土) 12:52:11.95
自分にも見えなかった

93 :デフォルトの名無しさん:2013/11/16(土) 13:14:00.47
>>86
Base64
uuencode
ISH
なんなりと

94 :デフォルトの名無しさん:2013/11/16(土) 13:37:07.53
馬鹿なの?

95 :デフォルトの名無しさん:2013/11/16(土) 13:58:14.33
あるクラスのメンバ関数があったとして,入力を
・メンバ関数の引数に指定する
・関数内でメンバ変数からとるようにする
のってどう使いわければいい?
入力がクラスのメンバ変数として妥当かどうか?

96 :デフォルトの名無しさん:2013/11/16(土) 14:06:44.07
必要に迫られた時以外変数は持たないようにするのが、バグの温床をつぶす意味でよろしいかと

97 :デフォルトの名無しさん:2013/11/16(土) 14:09:50.87
気分で使い分ければOK
みんなそうしてる

98 :デフォルトの名無しさん:2013/11/16(土) 15:21:29.19
>>96
なるべく引数にした方がいいってこと?
>>97
まじで・・・

そもそも設計の知識不足なだけかもしれん

99 :デフォルトの名無しさん:2013/11/16(土) 15:25:21.66
>>86
前スレ 711より
#define ___ /* empty; インデント用 --- 掃除したけりゃ %s/___ /\t/g とかで */
___ int i;
___ for (i = 0; i < 100; ++i) {
___ ___ fizzbuzz(i);
___ }

100 :デフォルトの名無しさん:2013/11/16(土) 15:39:49.68
>>95
データの性質による。
例えばよく変化するデータならコピーをとるのはバグでしかないし
プログラムの終了まで不変ならいちいち引数を取るのはムダ。
何にしてもそのインスタンスにどの程度の責任を与えるかという話なんで、
デザパタの本でも読み直して考えた方が良い。

101 :デフォルトの名無しさん:2013/11/16(土) 16:31:09.43
>>95
クラス名を見て
こういうメンバがありそうだなと容易に推測できる場合はメンバ
関数名を見て
こういう引数がありそうだなと容易に推測できる場合は引数

そこから先は経験

102 :デフォルトの名無しさん:2013/11/16(土) 17:41:11.96
>>95
マジレスすると

引数なら呼び出し側が値を指定するため
その値は呼び出し側の箇所だけの影響となるが

メンバ変数はオブジェクトの状態なので
クラスの設計とクラスの使い方に影響する。

どっちのほうが見通しがいいかで決めるのがいい。
この見通しの判断もチームメンバー構成や立場などによっても変化する。

103 :デフォルトの名無しさん:2013/11/16(土) 18:02:01.35
>>100
>>101
>>102
ありがとう すごい参考になった
たぶん悩んでる原因はクラスの規模が小さいせいで
入力がメンバ変数でも引数でも大きな違いがでなくてわかりづらいからだと思う
とりあえず他のチームメンバにも相談してみるわ

104 :デフォルトの名無しさん:2013/11/16(土) 21:17:37.34
>>82
OpenCLなんて条件どっから湧いて出てきたんだよ

105 :デフォルトの名無しさん:2013/11/17(日) 09:45:56.97
>>104
実用に耐えるんだろ
グダグダ言って逃げ回らないで
はよ書けよ

106 :デフォルトの名無しさん:2013/11/17(日) 11:53:11.21
OpenCLで書かれて無いと実用性は無いのか・・・知らなかったよ。
それに俺は前スレ>>993ではないので知ったこっちゃありません。

107 :デフォルトの名無しさん:2013/11/17(日) 13:21:35.10
顔真っ赤にして書き込まなくてもいいよ

108 :デフォルトの名無しさん:2013/11/17(日) 14:24:52.30
>>107
っ鏡

109 :デフォルトの名無しさん:2013/11/17(日) 14:42:26.66
あちゃー図星ついちゃった

110 :デフォルトの名無しさん:2013/11/17(日) 15:08:23.49
>>108
お前は赤ちゃんか?
自分の顔くらい自分で見ろ

111 :デフォルトの名無しさん:2013/11/17(日) 15:41:19.97
ときたま中高生みたいな下らない喧嘩腰になるのやめよう
普段は相手を許し認めて自分も許され認められてるんでしょ
いつもの感じでやろうよ中高生じゃないんだし

112 :デフォルトの名無しさん:2013/11/17(日) 15:55:07.12
>>111
お前も随分と喧嘩腰だな

113 :デフォルトの名無しさん:2013/11/17(日) 17:14:26.44
どんなレスをしようと
明日が月曜日であるという事実は変わらない

114 :デフォルトの名無しさん:2013/11/17(日) 18:52:22.07
明日が何曜日であろうと俺がニートであるという事実は変わらない

115 :デフォルトの名無しさん:2013/11/17(日) 18:55:34.22
ニート羨ましい
俺も月曜に休みたいよ

116 :デフォルトの名無しさん:2013/11/17(日) 18:56:40.05
そういうお前もニートなんだろ

117 :デフォルトの名無しさん:2013/11/17(日) 18:59:27.33
ニートできる環境を持ってるってのは武器の一つだからな
コネを持ってたり、技術を持ってるのと同じ水準で

118 :デフォルトの名無しさん:2013/11/17(日) 19:23:50.25
>>106
現実の用途で使えるから実用性があると言うんだろ。
今並列化したソートで意味がある速度出せるつったらGPUだ。
CPUで並列化させるぐらいなら単一コアで実行させた方がよっぽど現実的。
CPUで並列化ソートなんて遊びの範疇で実用的じゃない。

119 :デフォルトの名無しさん:2013/11/17(日) 19:30:56.64
>>118
マルチコアのご時世でそうなるのか?

120 :デフォルトの名無しさん:2013/11/17(日) 19:35:07.05
>>118
自分でそのレス書きながら、そんな事言い切れるわけがない。って気づいてるだろwww

121 :デフォルトの名無しさん:2013/11/17(日) 19:36:29.91
ぶっちゃけ、ソートがボトルネックになる事なんて殆どないからどうでもいい

122 :デフォルトの名無しさん:2013/11/17(日) 19:40:41.44
CPUで並列化させる方がよほど現実的だよ
4コアあるだけで3倍になる

123 :デフォルトの名無しさん:2013/11/17(日) 19:43:15.10
>>103
なにがしたいのか書いてみ。ちっさいクラスでもメンバーで
値を持つ意味がある場合は多いぞ。

例えば、こんな例。
FloatConvertor value1( 1.5 )
StringConvertor value2( "10" );
const ToDoubleConvertor *convertor;

convertor = &value1;

double x = convert->AsDouble();

convertor = &value2;
double y = convert->AsDouble();

ただベタ書きではあまり意味はないが、
convertorが引数の場合は、引き数に与える値を、
FloatConvertor型の値にしたり
StringConvertor型にしたりして処理を切り替えられる。

124 :デフォルトの名無しさん:2013/11/17(日) 19:44:40.11
>>120
お前は、はようコードを出せ。

125 :デフォルトの名無しさん:2013/11/17(日) 19:45:52.38
>>122
ならねぇよロックやらスレッドコストやらで2倍いけば御の字だろうが。

126 :デフォルトの名無しさん:2013/11/17(日) 19:48:44.75
>>122
クイックソートとか最初の方どうしても単一コアで処理する必要があるから3倍なんて(ヾノ・∀・`)ムリムリ

127 :デフォルトの名無しさん:2013/11/17(日) 19:50:39.59
>>124
あ、お前上のほうのレスでコード出せだせ言ってた奴か
俺はその相手じゃないよ。

ただどんなGPUとCPUを使ってるかによって話は全然変わるのに
言い切るのは乱暴だなーってだけ。
とっても並列処理が早いGPUと、遅いCPUなら、お前の言ってる通りになるんだろ

128 :デフォルトの名無しさん:2013/11/17(日) 21:51:36.82
いるよなー
言い訳ばかりで何もしない社会のクズ

129 :デフォルトの名無しさん:2013/11/17(日) 21:57:35.95
>>125
マージソートの並列化でロックなんか必要ないぞ、この馬鹿

130 :デフォルトの名無しさん:2013/11/17(日) 22:01:58.21
ソートの並列化でロックが必要とか言い出す馬鹿はどんなコード書いてるのだろうか

131 :デフォルトの名無しさん:2013/11/17(日) 22:13:25.33
実際の業務でソートがクリティカルな人ってどうしてるの?
一般人だとそもそもそんな大規模なデータがない

132 :デフォルトの名無しさん:2013/11/17(日) 22:21:44.34
大規模データはSQLで処理するだろ
チューニングしたDBのSQLロジックより早いソートが自前で書けるなら別だが

133 :デフォルトの名無しさん:2013/11/17(日) 22:23:53.98
>>129
お前がマージソート並みに実用性のある並列処理ができるっていってたのはクイックソートだろボケ
マージソートでロック不要なのはわかりきっとるわ
話ごまかして楽な方に逃げようとすんなクズ

134 :デフォルトの名無しさん:2013/11/17(日) 22:33:44.66
>>131
ソートする対象が大体分かってるものだし、
最初から全て用意されてることよりも徐々に追加されることのほうが多いから
まず追加される度に適当そうな位置に挿入してその後ソートする

135 :デフォルトの名無しさん:2013/11/17(日) 22:36:24.56
>>126
クイックソートみたいに2分割を繰り返すソートだと
それに加えコアに分割されたキャッシュが響く
ソート済みのキャッシュを全コアに反映せにゃならんからな。

>>130
クイックソートするときソート結果を何処に保持させる気だ
同じ書き込み先の配列を共有しない場合は、
毎回メモリーの再確保が発生するぞ。
当然その場合もメモリー確保コストに加え、
メモリー管理の排他が発生するから、
どのみち排他する事になるんだがな。

136 :デフォルトの名無しさん:2013/11/17(日) 22:40:58.67
>>131
大体ソートアルゴリズム自体が問題になる事は少ない。
それより如何にソート対象の値の比較を効率化させるかが
問題になる。
例えば文字列の比較をくそ真面目にやると遅いんで、
特殊な要約値(hash)に変換するなり工夫が必要になる。

137 :デフォルトの名無しさん:2013/11/17(日) 22:41:26.20
実測に拠らない速さ議論は空論

138 :デフォルトの名無しさん:2013/11/17(日) 22:45:44.58
>>137
とりあえず逃げ回ってる奴がソースコードを出せば済む話

139 :デフォルトの名無しさん:2013/11/17(日) 23:07:18.35
>>126
初回も絶対分割できないというわけじゃないけど初回を分割すると面倒ではあるな。
それとソート対象が大きいほど初回が占める比率は下がるから、状況次第で効果が違う。
だからって3倍4倍になるとは思わないけどな。
ただの予想だがメモリアクセスの限界の方が先に来るケースの方が多いだろう。

>>135
> どのみち排他する事になるんだがな。
分割した後左右を別のスレッドに振っても同じ領域にはアクセスしないからロックは不要。
なんでアクセスしない領域までロックする前提なんだ?

>>138
クイックソートの並列化(初回分割除く)でロックが居るとかアホな理屈に突っ込みいれてるだけだぞ。

140 :デフォルトの名無しさん:2013/11/17(日) 23:29:36.79
>>133
> お前がマージソート並みに実用性のある並列処理ができるっていってたのはクイックソートだろボケ

いやいや、「クイックソート」なんて言葉はここでは一回も書いたことないし
幻覚ほざくやつ気持ち悪いな

141 :デフォルトの名無しさん:2013/11/17(日) 23:36:50.18
並列あるならsleep sortが最強
理論上では定数時間でソートできる

142 :デフォルトの名無しさん:2013/11/17(日) 23:47:48.31
>>126
データが10億件あれば、最初の方にかかる処理は全体の30分の1程度だ。その程度のことは気にしなくていい。

143 :デフォルトの名無しさん:2013/11/18(月) 00:10:50.48
>>141 処理のオーダーは最高なのに、実用上は最悪というのは皮肉だねw

144 :デフォルトの名無しさん:2013/11/18(月) 00:14:27.75
>>133
マージソートでロック不要なのは分かってるのに
クイックソートの場合分からないなんて
どういうバカなんだよ

145 :デフォルトの名無しさん:2013/11/18(月) 00:26:56.33
>>132
Scanlineを作る際の頂点並び替えとかSQL使っとられんのだが。

あと並び替えに速度が必要なのは大規模情報に限らん。
Graphicsや幾何学分野は基本的に高速な並び替えが必要になる。

146 :デフォルトの名無しさん:2013/11/18(月) 00:29:38.06
>>140

>>9
>>12

147 :デフォルトの名無しさん:2013/11/18(月) 00:32:42.48
>>142
じゃあ早く書いて実測させろよ

148 :デフォルトの名無しさん:2013/11/18(月) 00:35:02.20
>>139
ソース書いてロック不要な事を証明してくれ

149 :デフォルトの名無しさん:2013/11/18(月) 00:42:28.07
>>146
他の奴が書いたものまで書いたことあるうちに入れるなよ

150 :デフォルトの名無しさん:2013/11/18(月) 00:45:40.21
>>132
1億件のレコードをオンメモリーでソートすればあっという間だが、
わざわざSQLでDBに入れてたら何十分もかかるんじゃないか?

151 :デフォルトの名無しさん:2013/11/18(月) 00:46:03.96
お前ら名無しのくせに自己を主張するな。やりたきゃコテつけろ。NGしてやるから。

152 :デフォルトの名無しさん:2013/11/18(月) 00:49:21.49
>>151
まずお前がコテ付けな

153 :デフォルトの名無しさん:2013/11/18(月) 01:08:06.63
>>139
その鈍くさい方法ならロックは要らんが、
基準値との比較をコア数分同時に行う場合は、必要になる。

154 :デフォルトの名無しさん:2013/11/18(月) 01:10:21.38
>>153
お前何言ってんだ?

155 :デフォルトの名無しさん:2013/11/18(月) 01:13:46.21
quicksortの並列化じゃなくて
partitionの並列化か?

156 :デフォルトの名無しさん:2013/11/18(月) 01:17:18.65
>>141
あれは時間を使うアイデアはすごかったが
実質はただのビンソートだぞ

157 :デフォルトの名無しさん:2013/11/18(月) 01:22:29.98
>>154
4コアの場合

対象配列: 987654321
基準値: 5

1回目の振り分け
1回目:1 2 9 8
2回目:1324 9786
1回目終了:132459786

158 :デフォルトの名無しさん:2013/11/18(月) 01:24:43.00
>>157
どう見てもクイックソートの動きじゃない

159 :デフォルトの名無しさん:2013/11/18(月) 01:27:27.25
>>157
クイックソートを並列化する際に、最初の一回目を並列化なんかするわけないだろ。
そんなバカなことしたら無駄に重くなるだけだ。

160 :デフォルトの名無しさん:2013/11/18(月) 01:31:04.84
>>139
全てのタスク(ジョブ)が終了した事をどうやって調べるんですかねぇ。
まさかfork-join?

161 :デフォルトの名無しさん:2013/11/18(月) 01:34:02.26
quicksortって暗黙的にinplaceの要件あるから
swapだけで処理しないと駄目だよ
だから振り分けは1コアになる

162 :デフォルトの名無しさん:2013/11/18(月) 01:34:34.60
>>159
なんで重くなんだよ
クイックソートは基準値を元に左右に分散してれば、
左右の値がどう並んでても良い。
1回目1コア2回目2コアよりよっぽど速いわ。

163 :デフォルトの名無しさん:2013/11/18(月) 01:36:29.31
仮にinplaceじゃないとして
左右配列への代入はどうするんだ?
同期処理入るんじゃないか?

164 :デフォルトの名無しさん:2013/11/18(月) 01:39:12.79
>>157
お前、入力データと同じ大きさのバッファを用意してるだろ?

165 :デフォルトの名無しさん:2013/11/18(月) 01:40:12.92
マージソートはロック不要で並列化ができるけど、
クイックソートはロックが必要。

と言ってる奴はマジキチ。

166 :デフォルトの名無しさん:2013/11/18(月) 01:41:34.54
>>159
1コアで100万件左右に振り分けるのと
4コアで100万件左右に振り分けるのどっちが速いか
多少考えりゃわかるだろうに

167 :デフォルトの名無しさん:2013/11/18(月) 01:42:58.50
>>166
最初の振り分けは1コアでやらないと、ロックだらけで大変遅くなる

168 :デフォルトの名無しさん:2013/11/18(月) 01:45:07.55
>>165
2コアならそれもできるが
最初から4コア振り分けって言ってるからそれも無理じゃねって言ってんだよ

169 :デフォルトの名無しさん:2013/11/18(月) 01:48:03.22
>>166
クイックソートは、データが10億件あればネストは30以上になるんだぞ。
そのうちの最初の一層を4コアにしても1コアにしても、全体の時間は変わりはしない。
ロックまみれにしながら第一層からスレッド分ける意味がない。

170 :デフォルトの名無しさん:2013/11/18(月) 01:48:17.50
>>133>>144
ていうか、マージソートの方がクイックソートより条件悪いぞ。
クイックソート
・初段の並列化に制限がある(並列化の方法によってはロックが必要)
・ソート完了判定で終了待ちが発生する
・作業領域を用意せずに破壊的にソート可能

マージソート
・最終段の並列化に制限がある(並列化の方法によってはロックが必要)
・各段ごとに、依存する前段の終了待ちが発生する
・作業領域の用意が必須

クイックソートは分割時にタスクを生成するが、マージソートは結合時に同期を待つ。
初段ないし最終段の並列化でロックが居る云々なんぞよりよほど致命的
少なくとも教科書的な実装で分割されたタスクを並列化するだけだとそうなる。
解決するなら改良しないとな。

171 :デフォルトの名無しさん:2013/11/18(月) 01:48:41.57
>>168
マジキチすぎて議論になりません

172 :デフォルトの名無しさん:2013/11/18(月) 01:52:18.16
>>171
じゃあ最初から4コアで振り分けるquicksortのアルゴリズムを
きちんとコードで説明してくれ

173 :デフォルトの名無しさん:2013/11/18(月) 01:55:07.80
プログラム知らない奴がこのスレ見たら、何でわけわからん事で争ってんだって思うだろうな
シャワートイレ板で和式派と洋式派で醜い争いが発生してるみたいな

174 :デフォルトの名無しさん:2013/11/18(月) 01:55:42.50
すまん>>172は途中から参加した
俺はマージソートに同期不要とは思ってない

175 :デフォルトの名無しさん:2013/11/18(月) 01:55:52.63
>>170

4コアで10億件あった場合、マージソートで並列化すると
スレッドの生成は何回あるという考えなんですか?

176 :デフォルトの名無しさん:2013/11/18(月) 01:59:33.23
>>170
御託はいいからソースを書けよ

177 :デフォルトの名無しさん:2013/11/18(月) 02:00:57.79
>>168
2コアでも駄目だろ。
ハードウェアなら入力2系統出力1系統にして入力を並列化できるが、
出力が1系統だからソフトウェアに落とすと1コアもしくは同期処理だ。

ハードウェアで同期取るのは簡単だけどソフトウェアでそれはちょっと…
CPUだと直列で書いて命令やパイプラインで並列化させる方が簡潔。
GPUだと並列に書けるかもしれんがCPUの話だよなコレ?

178 :デフォルトの名無しさん:2013/11/18(月) 02:05:39.11
A氏「マージソートの並列化にロック不要。クイックソートなら必要」
B氏「マージソートもクイックソートも並列化にはロックが必要」

どちらが頭悪い?

179 :デフォルトの名無しさん:2013/11/18(月) 02:06:17.44
>>177
2コア&inplaceなら最初の一回からできるよ
同一の大きさの配列作る
ピボットよりそれぞれ小さいもの、大きい物だけ選別するスレッドを生成
後は普通のinplaceクイックソート

180 :デフォルトの名無しさん:2013/11/18(月) 02:08:08.86
久しぶりにこのスレ盛り上がってるな

181 :デフォルトの名無しさん:2013/11/18(月) 02:09:14.90
>>179
> ピボットよりそれぞれ小さいもの、大きい物だけ選別する

という行為が何をすることなのか全く意味が分からない

182 :デフォルトの名無しさん:2013/11/18(月) 02:09:24.69
>>179
訂正
最初の一回はinplaceなら、じゃなくinplaceじゃないなら

183 :デフォルトの名無しさん:2013/11/18(月) 02:12:09.66
>>181
振り分けの並列化の話だよ

184 :デフォルトの名無しさん:2013/11/18(月) 02:12:56.81
inplaceじゃないクイックソートという
何のメリットもない俺様アルゴリズムを前提に
意味不明な理論を語る馬鹿が一名

185 :デフォルトの名無しさん:2013/11/18(月) 02:13:48.96
>>183
具体的にどうやれば振り分けの並列化ができるんですか?

186 :デフォルトの名無しさん:2013/11/18(月) 02:13:49.86
>>179
無理ってのはマージソートの最終段だろ。

187 :デフォルトの名無しさん:2013/11/18(月) 02:19:21.67
マージソートは最終段群が終わるまで、それらの親スレッド=最終段以外のスレッドが待ち状態に入るわけだよね
クイックソートは親スレッドは生成スレッドを待つ必要はないけれども、でも最終段まで全部終わったことは検知しないといけないよね

188 :デフォルトの名無しさん:2013/11/18(月) 02:19:57.94
>>178
マージソートに排他が要らんがクイックソートには排他がいるつう話しじゃなく
>>118から続くCPUでの並列化なんて大して速くならんつう話しの流れだ

189 :デフォルトの名無しさん:2013/11/18(月) 02:20:04.71
早く寝ろよ、月曜の朝もすぐそこだそ

190 :デフォルトの名無しさん:2013/11/18(月) 02:22:12.01
>>185
inplaceじゃなく、同じ大きさの空配列を作る前提なら
ピボットより小さい物は前から、大きい物は後ろから入れればいいだけ
このままだと容量がn*n必要になるから、2回目以降はinplace必須だろう

ちなみに俺もinplaceじゃないquicksortにあまり意味はないと思ってるよ

191 :デフォルトの名無しさん:2013/11/18(月) 02:22:42.64
>>187
マージだとどのブロックも負荷はほとんど同じだから待ちはほとんどない

192 :デフォルトの名無しさん:2013/11/18(月) 02:22:58.94
>>187
待ってる間CPUは他のスレッド処理してるわけで
遊んでるわけじゃないけどな

193 :デフォルトの名無しさん:2013/11/18(月) 02:23:40.25
>>188
まあ今回のお題では、データに分割にしたがってスレッド生成を連発すると、そのスレッド生成コストが結構ありそうだね
決め打ち生成(物理コアだけしか生成しない)の場合の書き方がちょっと想像できないが‥‥

194 :デフォルトの名無しさん:2013/11/18(月) 02:24:58.25
>>190
ピボットより小さい値を探すスレッドと、ピボットより大きい値を探すスレッドに分かれて、
両方のスレッドが全ての値に対して比較をする(比較回数はデータ数の2倍になる)
ということ?

195 :デフォルトの名無しさん:2013/11/18(月) 02:26:18.47
>>191
ブロックを2分割したあと、それぞれをソートするスレッドを生成したら、それが終わるまで自分は待たないといけないだろう?

196 :デフォルトの名無しさん:2013/11/18(月) 02:27:28.53
>>193
> 決め打ち生成(物理コアだけしか生成しない)の場合の書き方がちょっと想像できないが‥‥

さすがにここまで馬鹿な事を言う人は珍しい

197 :デフォルトの名無しさん:2013/11/18(月) 02:28:16.34
>>192
スレッド生成や待ちに結構コストを食いそうだ
手持ちの6コアでも、他のお題での今までの経験からするとせいぜい2倍くらいじゃないか?

198 :デフォルトの名無しさん:2013/11/18(月) 02:31:08.31
つかマージソートはオンラインアルゴリズムでキューが使えるから段階別に待つ必要ないだろ
前段階の1要素目が決まったら次の段階はそっから1要素ずつ取り出して処理すりゃいい
いくら排他がいるといっても、クイックソートとはCPU使用率の効率が違う。

199 :デフォルトの名無しさん:2013/11/18(月) 02:33:23.65
>>197
> スレッド生成や待ちに結構コストを食いそうだ

食うわけねーだろ馬鹿
百万件だろうが一億件だろうが、4コアしかなけりゃ生成も合流も3かいずつしかないんだから
そんなもの表面化するコストにならない。

> 手持ちの6コアでも、他のお題での今までの経験からするとせいぜい2倍くらいじゃないか?

2倍とか言ってる馬鹿はそういう考え方の奴ばかりなんだな。

200 :デフォルトの名無しさん:2013/11/18(月) 02:33:59.35
>>197
ここでスレッドとか書いてても文字通りスレッド使うわけ無いだろ
計算用途ならスレッドプール使うのが普通
だからスレッド生成コストなんてプロセスの初期化時しか発生せん

201 :デフォルトの名無しさん:2013/11/18(月) 02:34:09.49
>>198
>前段階の1要素目が決まったら

それが決まるまで待たないといけないよね
それが決まるのは最終段まで分割した「後」だよね
つまり最後まで待たないといけない点は、大枠でかわらないよね

202 :デフォルトの名無しさん:2013/11/18(月) 02:35:11.74
>>194
あ、確かにそのままだとそうなるな
凄く馬鹿なこと言ってた
並列で比較回数も下げるには一旦マージか同期が必須になるのか

203 :デフォルトの名無しさん:2013/11/18(月) 02:35:49.39
>>201
バカなの?

204 :デフォルトの名無しさん:2013/11/18(月) 02:36:39.63
>>202
今頃になって何を言ってんだ
お前の言ってることは全てが馬鹿なことなのに

205 :デフォルトの名無しさん:2013/11/18(月) 02:37:26.57
>>199
>食うわけねーだろ
それが結構食うんだね
win32api で CreateThread() を for() でぶんぶん廻すと、そのチャイルドスレッドがsleep(10秒)だったとしても
「もうスレッド作れません」に到達するよ

206 :デフォルトの名無しさん:2013/11/18(月) 02:38:07.05
>>204
これは恥ずかしい
馬鹿だったと認めるよ

207 :デフォルトの名無しさん:2013/11/18(月) 02:39:08.01
戦争は終わった・・・

208 :デフォルトの名無しさん:2013/11/18(月) 02:42:25.65
ま、まってくれ俺は自分が来る前から騒いでた奴は知らんぞ
いや、もしかしてあれも俺なのか・・?

209 :デフォルトの名無しさん:2013/11/18(月) 02:45:10.94
>>203
自スレッドが、上からもらったデータを二つに分割した後、スレッドをひとつ生成して半分(のポインタ)をそいつにわたす
残りの半分は次の段階で自スレッドで2分割する

としても、ある段階で「第一要素が決定する」ためには、それより下の段階の分割と統合は終わっていないといけないよね

210 :デフォルトの名無しさん:2013/11/18(月) 02:49:08.77
>>201

最終段階手前ブロック1構築
158…
79…

最終段階手前ブロック2構築
46…
23…

最終段階手前ブロック1
15789…

最終段階手前ブロック2
2346…

最終段階ブロック
123…

この状態だと最終段階ブロック1の1と最終段階ブロック2の2がわかった時点で、
最終段階ブロックの構成を開始できる
残りの3456…が整列できてる必要がない

211 :デフォルトの名無しさん:2013/11/18(月) 02:51:46.82
4コアで4億件のマージソートの話。
1億件ずつ4つのブロックに分けて、それそれABCDと呼ぶ。
最初の入り口の関数がバッファを用意してコア数も確認。
再帰用の関数に全部の情報を渡す。
再帰用の関数は普通のマージソートのように半分に割って、最初はブロックABとCDに割って、
それぞれ再帰でマージソートをやらせるのだが、
ここで子スレッドを生成して子スレッドにはCDのマージソートをやらせて自スレッドはABを担当して、終われば合流してシングルスレッドでマージをする。
ABを担当することになったスレッドはこれをAとBに分けて、またスレッドを一つ生成して、子スレッドにBをやらせて、自スレッドはAを担当する。
再帰でAだけを担当する処理が開始されるが、この段階では合計4スレッドが動いてる状態なので、
これ以上はスレッド分けが不要となるため、ブロックAを担当するスレッドは普通のマージソートを使ってブロックAを処理する。
4つのブロックに対して4つのスレッドが並列でマージソートをするが、
それぞれ異なる領域を処理しているので一切のロックがない。
そして大きさが同じなので、ほぼ同時に処理が終わる。
それらが終われば、ABとCDそれぞれのjoinが行われて2スレッドになり、
ABを担当するスレッドはAとBのマージを
CDを担当するスレッドはCとDのマージをする。
最後は一つのスレッドに戻ってABとCDのマージをする。

212 :デフォルトの名無しさん:2013/11/18(月) 02:52:30.28
>>205
スレッドの生成回数はコア数より少ないから、そんな負荷は無視しろ

213 :デフォルトの名無しさん:2013/11/18(月) 02:52:53.00
>>210
説明がよくわからん
[3, 1, 4, 5, 9, 2, 6, 8]
で説明してくれ

214 :デフォルトの名無しさん:2013/11/18(月) 02:55:35.83
>>211
あったまわりぃ
マージソートのオンライン特性利用しろよ
マルチコアの使用効率最大に活かせるんだぞ

215 :デフォルトの名無しさん:2013/11/18(月) 02:57:39.54
>>211続き

ちなみにクイックソートの場合も、
マージソートとは逆に最初に共通処理を終わらせて、そのあとからスレッド分割で小さい領域を分担する(ただし、4コアなら最初の4分割までスレッド分け)
ということなので、
マージソートとあまり変わらない。
数に偏りがあった場合はスレッド分けずに通常処理をするというやり方でも全然速度稼げる。
ということなので、マージソートもクイックソートも並列化をする際にロックは必要ない。

216 :デフォルトの名無しさん:2013/11/18(月) 02:57:54.79
>>212
>スレッドの生成回数はコア数より少ない
ライトウェイトプロセス方式のネイティブスレッドのことをいってるのか?

217 :デフォルトの名無しさん:2013/11/18(月) 02:58:12.58
>>214
キューの方が遅い

218 :デフォルトの名無しさん:2013/11/18(月) 02:58:20.57
>>213
ムリ
最終段階手前ブロックがキューであると
思ってよく考えてくれ

219 :デフォルトの名無しさん:2013/11/18(月) 02:59:55.45
>>217
残念ながら実測だと待機時間が他の処理に使われるから
待ち時間が殆ど発生しない

220 :デフォルトの名無しさん:2013/11/18(月) 03:02:41.96
>>217
もっと具体的に言うとキューの待ち時間にブロック構築が進むからCPUが処理待ちにならない

221 :デフォルトの名無しさん:2013/11/18(月) 03:17:12.99
そして新しい戦いが始まる・・・

222 :デフォルトの名無しさん:2013/11/18(月) 03:26:30.72
キューの同期化のオーバーヘッドはあるの?

223 :デフォルトの名無しさん:2013/11/18(月) 03:27:44.47
>>210
使える情報が流れてきたことを知るためにmutexとか使うの?

224 :デフォルトの名無しさん:2013/11/18(月) 03:33:15.06
>>218-220
これってリソースどれぐらい使うの?

225 :デフォルトの名無しさん:2013/11/18(月) 06:04:28.81
一言言うと、並列化は並列処理に比例して処理速度が速くなるってことよ。

226 :デフォルトの名無しさん:2013/11/18(月) 06:45:16.73
深いネストがあるクラスを書いてコンパイルしたら「閉じカッコと始まりカッコの数が違います」的なエラーが出て
エラー行参照したらクラスの終わりカッコだった時の、どこのカッコが閉じてないや感は異常

227 :デフォルトの名無しさん:2013/11/18(月) 06:53:28.10
>>224
こってりソースに見えた

228 :デフォルトの名無しさん:2013/11/18(月) 07:57:58.86
C/C++ なら } の後ろに(ホワイトスペースのぞいて) ; が来るケースはほとんどないんじゃね

229 :デフォルトの名無しさん:2013/11/18(月) 08:05:17.77
言葉が足りなかった

C/C++ なら } の後ろに(ホワイトスペースのぞいて) ; が来るケースは
クラス(構造体)の終わりカッコ以外はほとんどないんじゃね

230 :デフォルトの名無しさん:2013/11/18(月) 08:39:52.06
>>223
普通mq_sendとかOSのapiかchannelみたいな言語機能つかうだろ

231 :デフォルトの名無しさん:2013/11/18(月) 09:21:23.28
>>226
今時気の利いたエディタなら括弧の対応付けしてそれらしく表示くらいしてくれるだろう

232 :デフォルトの名無しさん:2013/11/18(月) 10:04:51.63
>>230
それで、このマージソートのリソースはどれぐらい使うの

233 :デフォルトの名無しさん:2013/11/18(月) 10:39:55.42
>>230
そのやり方はすげー遅い

234 :デフォルトの名無しさん:2013/11/18(月) 14:38:08.98
つうかデータの性質や比較関数の性質、それを事前に分かるか等で
どれが最適かは変わるんだから議論しても仕方ないよ
まあ自分はインサートを推しとくが

235 :デフォルトの名無しさん:2013/11/18(月) 14:56:01.61
>>193
今日の低脳君はこれだ

236 :デフォルトの名無しさん:2013/11/18(月) 18:49:08.20
>>231
C++/CLIというキメラ言語を生業にしているとVisualStudio2008までしか使えないんだわ
それ以降のVSはC++/CLIのインテリジェンスは対応してないっていうクソっぷり
んで2008は{から}へジャンプ機能が多分ない。もちろん強調表示もない

237 :デフォルトの名無しさん:2013/11/18(月) 18:54:35.12
>>236
かわいそう

238 :デフォルトの名無しさん:2013/11/18(月) 18:59:33.21
最近のVSはついに人工知能積んだのか

239 :デフォルトの名無しさん:2013/11/18(月) 19:41:47.65
インテリジェンスワロタ

C++/CLIに対応しないVS2010以降がクソなのか、
VS2010以降に匙を投げられるC++/CLIがクソなのか…

240 :デフォルトの名無しさん:2013/11/18(月) 19:47:48.07
C++/CLI自体がもう未来を感じない言語だわ
C#やればよかったー

241 :デフォルトの名無しさん:2013/11/18(月) 19:50:32.98
C#糞と思ってるJava使い俺以外に居る?

242 :デフォルトの名無しさん:2013/11/18(月) 19:52:24.49
C#やってないけど、きっとスマートでスタイリッシュな言語なんだろうなーって勝手に期待してるJava使いはいる

243 :デフォルトの名無しさん:2013/11/18(月) 20:02:21.39
ヘルたんlove

244 :デフォルトの名無しさん:2013/11/18(月) 20:12:38.58
C#使うためにJava本読んでます

245 :デフォルトの名無しさん:2013/11/18(月) 21:49:17.32
>>244
意味が分かりまへん
手続き型言語やってきて初めてオブジェクト思考やるから参考にとか?

246 :デフォルトの名無しさん:2013/11/18(月) 22:10:07.69
JavaよりはC#の方がいい
ただC#マンセーしてる奴はレベルが低いのが多い

247 :デフォルトの名無しさん:2013/11/18(月) 22:13:12.11
>>246
> JavaよりはC#の方がいい

どういう点で? 興味本位で聞いてるだけだが。

248 :デフォルトの名無しさん:2013/11/18(月) 22:15:10.35
>>245
まさにそれ

249 :デフォルトの名無しさん:2013/11/18(月) 22:31:15.85
>>247
コンテナにプリミティブ型格納するにはラッパークラス使ってください
関数を引数で渡すときはリスナークラス使ってください

250 :デフォルトの名無しさん:2013/11/19(火) 07:56:39.67
C#も機能がゴテゴテしてきた印象はあるけどさ、
総称、atomic、劣化using、lambda、etc. と、
導入が数年から10年遅れる上に、個々もクソ機能に変更する言語ですよ?
C#と比較して褒めるとか無茶ですわ。
JVMだけならまだしも。

251 :デフォルトの名無しさん:2013/11/19(火) 11:57:23.36
>>245
意味が分かりまへん
Java や C# が手続き型言語じゃないと?

252 :デフォルトの名無しさん:2013/11/19(火) 12:04:00.37
それは意味が解らないのではなく
相手の意図を理解した上で、揚げ足を取っているだけでは無かろうか

253 :デフォルトの名無しさん:2013/11/19(火) 18:02:00.61
JavaやC#は絶対クラスが必要だから手続き型ではない
もちろん手続き型のような書き方はできるけど

254 :デフォルトの名無しさん:2013/11/19(火) 18:27:34.65
そう考えるとC++やDって
まさにマルチバラダイムな言語なんだな

255 :デフォルトの名無しさん:2013/11/19(火) 19:02:38.69
C#が手続き型言語ってのは無理があるだろww
C#「やるため」にJava勉強してるって言ってるだろ

256 :デフォルトの名無しさん:2013/11/19(火) 20:16:13.37
手続型って関数型に対する用語で、
OOPLとの対義語としてつかうのは間違っとるようにわしは思う

257 :デフォルトの名無しさん:2013/11/19(火) 20:25:41.93
新しい技術が出てきた際に、古い技術に名前をつける必要が出てくる
そういった場合得てして漠然とした名前がついちゃうんだよ
スマホが出てきてケータイがフィーチャーフォンになったみたいな。
手続き型言語ってのもそんな感じなんじゃないの?

258 :デフォルトの名無しさん:2013/11/19(火) 20:33:10.16
いや、関数と手続きってい小さな対比は昔からあったんでは?
pascalにおいてはそのままfunctionとprocedureがあったように。


…これひょっとしてそういう話じゃなかた?w

259 :デフォルトの名無しさん:2013/11/19(火) 20:36:19.34
>>255
OOPLのループ
a := 1 to: 100.
a do:
[ :each |
 Transcript
  show: each asString;
  cr.
].

C#やCやjavaのループ
for( int i = 0; 100 > i ; ++i )
{
 System::Console->WriteLine(
"{0}", i );
}

260 :デフォルトの名無しさん:2013/11/19(火) 20:46:21.47
>>259
上の例は何て言う言語?

261 :デフォルトの名無しさん:2013/11/19(火) 20:46:48.93
>>258
小さくねえよ
純粋に近い関数型は引数の評価順序が不定で、
引数でしか処理を書けないから手続型の様に、
処理を手続的に書けない。
逆に引数の評価順序が保証されないという特性のお陰で、
並列処理につよいがな。

262 :デフォルトの名無しさん:2013/11/19(火) 20:51:30.42
>>260
ブレインファックじゃね?

263 :デフォルトの名無しさん:2013/11/19(火) 20:52:10.83
教えてあげないよっじゃん!

264 :デフォルトの名無しさん:2013/11/19(火) 20:53:25.74
CとC#とJavaをひとくくりにしている時点で悪意を感じる
そして例示はC++マネージ拡張系とかか?

265 :デフォルトの名無しさん:2013/11/19(火) 20:55:16.50
もっと冗長に書きなおしてみるか

| a b |
a := 1 to: 100.
b :=
[ :each |
 Transcript
  show: each asString;
  cr.
].

a do: b.

266 :デフォルトの名無しさん:2013/11/19(火) 20:56:48.33
>>259>>255に何をいいたいのかさっぱり分からんw
そのループの例が何を示してるのか…。

267 :デフォルトの名無しさん:2013/11/19(火) 21:00:03.82
>>266
何も意味のあることは言ってないと思うよ
彼の脳内のループバック通信がここに漏れ出ただけ

268 :デフォルトの名無しさん:2013/11/19(火) 21:07:43.94
脳内ループバック通信www

269 :デフォルトの名無しさん:2013/11/19(火) 22:02:08.93
public java.collection.List<java.lang.Integer> filledList( int begin, int end )
{
 java.collection.List<java.lang.Integer>
  filled = new java.collection.Vector<java.lang.Integer>();
 for( int i = begin; i < end; ++i ) filled.add( new java.lang.Integer( i ) );
 return result;
}
public java.collection.List<java.lang.Integer> filledList( java.collection.Collection<java.lang.Integer> values )
{
 result new java.collection.ArrayList<java.lang.Integer>( values );
}
java.collection.List<java.lang.Integer>
 list0 = this.filledList( 1, 3 ),
 list1 = this.filledList( new java.lang.Integer[]
 {
  new java.lang.Integer( 1 ),
  new java.lang.Integer( 2 ),
  new java.lang.Integer( 3 )
 } );
java.lang.System.println( java.lang.String.valueOf( list1.equals( list2 ) ) );
-------------------------------------------------------
| filledList list0 list1 |
filledList :=
[ :aCollection |
 OrderedCollection from: aCollection.
].
list0 := filledList value: ( 1 to: 3 ).
list1 := filledList value: #( 1 2 3 ).
Transcript
 show: ( list0 includeAll: list1 ) asString;
 cr.

270 :デフォルトの名無しさん:2013/11/19(火) 22:07:08.21
>>269
そこまでかたくなにimportしない理由はなんなんだ

271 :デフォルトの名無しさん:2013/11/19(火) 22:12:30.52
List型とArrayList型とVector型とCollection型とString型とInteger型と
System型は既にユーザー定義しててimportできないからに決まってるだろ。

272 :デフォルトの名無しさん:2013/11/19(火) 22:19:32.26
>>271
どんだけ基本クラス拡張したいんだよwww

273 :デフォルトの名無しさん:2013/11/19(火) 22:22:22.69
public java.collection.List<java.lang.Integer> filledList( int begin, int end )
{
 java.collection.List<java.lang.Integer>
  filled = new java.collection.Vector<java.lang.Integer>();
 for( int i = begin; i < end; ++i ) filled.add( new java.lang.Integer( i ) );
 return filled;
}
public java.collection.List<java.lang.Integer> filledList( java.collection.Collection<java.lang.Integer> values )
{
 result new java.collection.ArrayList<java.lang.Integer>( values );
}
java.collection.List<java.lang.Integer>
 list0 = this.filledList( 1, 3 ),
 list1 = this.filledList( new java.lang.Integer[]
 {
  new java.lang.Integer( 1 ),
  new java.lang.Integer( 2 ),
  new java.lang.Integer( 3 )
 } );
java.lang.System.println( java.lang.String.valueOf( list0.equals( list1 ) ) );
-------------------------------------------------------
| filledList list0 list1 |
filledList :=
[ :aCollection |
 OrderedCollection from: aCollection.
].
list0 := filledList value: ( 1 to: 3 ).
list1 := filledList value: #( 1 2 3 ).
Transcript
 show: ( list0 includeAll: list1 ) asString;
 cr.

274 :デフォルトの名無しさん:2013/11/19(火) 22:28:33.77
ね、Javaって糞言語でしょ。

275 :デフォルトの名無しさん:2013/11/19(火) 22:30:48.04
C++やC#,Goみたいに名前空間に別名付けられれば苦労しないのにね。

276 :デフォルトの名無しさん:2013/11/19(火) 22:31:26.57
全角スペース混入によるエラー探しに時間がかかる
腹たって全角スペース・半角スペース・タブをエディタ設定で見やすくするようにしたら
それだらけでさらに腹たつ

277 :デフォルトの名無しさん:2013/11/19(火) 22:41:07.30
sedしろよカス

278 :デフォルトの名無しさん:2013/11/19(火) 22:46:22.69
そんな腹立つ言語使わなきゃいいのに

279 :デフォルトの名無しさん:2013/11/19(火) 22:56:22.70
全角スペースでもコンパイルエラーにならない言語は快適です

280 :デフォルトの名無しさん:2013/11/19(火) 22:58:05.11
コボラーになって銀行系システムの保守だけで食っていきたい

281 :デフォルトの名無しさん:2013/11/19(火) 23:00:04.21
新しい環境で新規ならなんでもいいよ
レガシコードの移植はもいいやだやめたcomなんか死んじゃえ

282 :デフォルトの名無しさん:2013/11/19(火) 23:01:09.02
comはしぶとく残り続けるよ

283 :デフォルトの名無しさん:2013/11/20(水) 01:57:40.34
手続き型と並べて比べるのは宣言型。
関数型は宣言型の一部。

284 :デフォルトの名無しさん:2013/11/20(水) 02:06:34.77
WikiいわくC++は手続き型言語なのな
クラス作れるのがオブジェクト型言語だと思ってたら、どうも違うらしいね

285 :デフォルトの名無しさん:2013/11/20(水) 03:20:25.73
クラス作れなくてもオブジェクト指向なのはあるぞ
プロトタイプベースとか言うだろう?

286 :デフォルトの名無しさん:2013/11/20(水) 06:26:07.86
Smalltalkも手続型ですしお寿司

287 :デフォルトの名無しさん:2013/11/20(水) 09:03:35.63
オブジェクト指向と手続き型/宣言型は直行性のある概念。

288 :デフォルトの名無しさん:2013/11/20(水) 11:42:47.37
それは詭弁
手続き型オブジェクト指向なんて言い方はしない
狭義がデフォ

289 :デフォルトの名無しさん:2013/11/20(水) 13:19:33.52
>>284
選べる手を一つ増やしたというだけ
オブジェクト指向に閉じ込められたわけじゃない

290 :デフォルトの名無しさん:2013/11/20(水) 14:10:58.80
>>289
誰もそんな話をしてない

291 :デフォルトの名無しさん:2013/11/20(水) 14:35:48.91
関数型オブジェクト指向言語
OCaml

292 :デフォルトの名無しさん:2013/11/20(水) 15:01:37.81
メソッドチェーンソー

293 :デフォルトの名無しさん:2013/11/20(水) 15:54:13.33
アスペクト指向「出番マダー?」

294 :デフォルトの名無しさん:2013/11/20(水) 16:30:36.40
>>293
フレームワーク用の指向であってプログラミング言語にそんな指向を入れる余地はないと思う。

295 :デフォルトの名無しさん:2013/11/20(水) 17:06:44.59
frameworkってなに?

296 :デフォルトの名無しさん:2013/11/20(水) 17:26:58.33
>>293
AOPは使いどころが限られてるからな

297 :デフォルトの名無しさん:2013/11/20(水) 17:30:04.00
そういやAOPのスレって無いんだな…

298 :デフォルトの名無しさん:2013/11/20(水) 18:49:57.31
マルチパラダイム、でいいんじゃねーの。
関数型と手続き型だって、互いの関数呼び出しが不可能って訳じゃないだろ。

299 :デフォルトの名無しさん:2013/11/20(水) 20:05:55.91
C言語で書いた関数は呼び出せてもその逆が素直にできない事はいくらでもある。

300 :デフォルトの名無しさん:2013/11/20(水) 21:45:45.04
>>299
最悪、関数型のプログラムを手続き型の言語から起動して標準出力読めばよくね?
相互呼び出しのAPIが十分整っていないってのと、それが構造上不可能であるかってのは別の問題かと。

301 :デフォルトの名無しさん:2013/11/20(水) 22:46:53.26
xmlがあればなんでもできる

302 :デフォルトの名無しさん:2013/11/21(木) 07:51:22.56
>>298
言語のパラダイムの話だから ABI の話は関係ない。

303 :デフォルトの名無しさん:2013/11/23(土) 04:37:42.62
どっかの記事で読んだけど情報系の大学ではプログラム出来る奴と出来ない奴は
ハッキリ分かれててしかもそれは単純な学力とは違う問題だという話だけど本当?

数学バリバリ出来て結構良い大学行ってる理系の奴でも
何故かC言語の初歩の初歩(簡単な計算と入出力とか)で躓いて
なかなか覚えられない事があるらしい…

高等数学出来るくらいの論理力があればそんな初歩で躓くとかあり得ないような気がするけど…

304 :デフォルトの名無しさん:2013/11/23(土) 04:44:18.14
>>303
へえ
訓練メソッドしだいでなんとでも思う、というか教育体制の問題じゃない?
すずめの学校ぴーちくぱーちく、ではどうにもならないのがプログラミング

>>303 と同じく不思議に思うが、それが適性というものなのかもしれない‥
プログラミングを習得するために必要な思考手段/思考の作法はなにだろうか?

305 :デフォルトの名無しさん:2013/11/23(土) 04:51:58.57
>>304
まぁ確かに質問サイトとかでよく
「大学生ですがこの前PHPの入門書買って読んだんですが全然わかりません」
「どうやったらプログラムできるようになりますか?」
とか山ほど投稿ありますもんねぇ…

変な話これはただプログラミングが本当に好きかどうかという問題なんじゃないのかなとか思うけど…
ヘタクソでも情熱があれば少しは進歩するよね?
人間やりたくない事はなかなか覚えられないからなぁ。

306 :デフォルトの名無しさん:2013/11/23(土) 05:02:00.95
あ、そういえばこんな記事も読んだ事ある。
例えば

【問題】
int a = 10;
int b = 5;
a = a + b;
さてaは何になるでしょう?

という問題をプログラミングの知識が無い人間に見せて
時間をおいて何度もさせてみて間違いでも良いから
常に自分の中で一貫したモデルから答えを導ける人間は単位を落とさないとかなんとか…

でもこれも単に自分の中で幾つかのパターンの
モデルが構築出来てて A→X B→Y みたいな複数の論理的帰結が単純に分かったら良いだけだと思うんだけど。
結局数学が分かるくらいの論理力があれば問題ない気がするけどな。

307 :デフォルトの名無しさん:2013/11/23(土) 05:27:17.19
>>303
割と本当。そういう環境に居たけど、「適正ってあるんだなあ」って思ったよ

そういう奴でも、ステートメントを一行書けと言われたら書ける
変数が解らないとか、ポインタが解らないとかじゃないらしい(多分)

構造化出来ない(forとかwhileとか使わずに、同じステートメントをコピペで何度も書いちゃう)とか
関数が自作出来ない(全部main関数にだらだら書いて、後からメンテ出来なくなる)とか
俺の周囲だとそういうのが結構居た

308 :デフォルトの名無しさん:2013/11/23(土) 05:57:35.59
>>307
なんというかあれなのかね。
整理整頓能力みたいな。
本棚の整理が苦手な奴がダメみたいな。

自分で把握して改変しやすいコードを構築できる能力が無いと
全体の流れが分からなくなって混乱してしまうのかも。

結構プログラムも奥が深いよね。
ここは後々面倒になりそうだから効率よりも分かりやすさ重視でとか
ここは速度が要求されて中身が分かり辛くても機能さえ使えるようにしとけば
問題無いから最適化重視でとか

そういうケースバイケースで尚且つ全体の整理が出来ないと
保守管理しやすいプログラムって難しいもんね。

309 :デフォルトの名無しさん:2013/11/23(土) 06:10:17.13
能力ってのは脳力でもあるわけで
ある程度の努力で改善される事もあるだろうけど
でもやっぱし元々の資質もあるからねぇ…(脳に必要な機能が無ければどうしようもない場合もあるんじゃなかろうか…)
筋肉が付きやすい奴は何もやってなくても結構マッチョだったりするし。
プログラミング全然やった事ない奴でも直ぐにちょっとしたアプリ作ってたりするし。

310 :デフォルトの名無しさん:2013/11/23(土) 06:49:55.59
頭いい奴はスパゲティでも管理出来てしまうからコードがなかなか綺麗にならない
さん散らかしのデスクから直ぐに必要な書類が出せるやつみたいに綺麗である必要がないんだ

311 :デフォルトの名無しさん:2013/11/23(土) 06:50:20.86
アスペは2chに必要な適正七日

312 :デフォルトの名無しさん:2013/11/23(土) 06:50:49.80
ものごとの攻略法を見つけるが早い奴ってのはいるもんだ

313 :デフォルトの名無しさん:2013/11/23(土) 07:03:34.46
ある程度散らかってて、状態が奇妙でヘンテコな方が記憶しやすいんだ。
一般論として部屋の整理整頓が行き届いてるやつって記憶力悪いだろ。

314 :デフォルトの名無しさん:2013/11/23(土) 07:19:04.17
まぁ自分一人で開発してるなら
どんな汚いコードでも自身が把握出来て完成させる事が出来て
改変可能なら問題ないよね。

でも前の方で所謂プログラム出来ない奴の例で上がってるのは
自分自身でも把握困難になって結局破綻してしまうから問題なんだろうな。
この場合は努力して自分が管理し易い形に持って行く技術を磨く必要があるし
元々資質が無いなら無理な場合もあるだろうね。

要するに自分自身が把握可能な形に出来る能力があるかどうかが問題点で
自分自身が分かりやすい形に出来ており尚且つ一人だけの開発なら
他人が見てどんなにスパゲティコードでもこの場合はプログラミング能力があるという事になるんじゃないのかね。

315 :デフォルトの名無しさん:2013/11/23(土) 07:34:51.48
>>310
よく分からないのは
頭良い奴はスパゲティーの方が分かりやすいのか?
それとも結局頭良い奴でも整理整頓されたコードのが分かりやすいのか?
もし後者ならば、やっぱし自分がより分かりやすい形にコードを整える能力を養う方が後々も有利なので
総合的に頭が良い奴は結局、コードを整理する努力をするものじゃないのかな?

もちろん後者ならそういう努力は無駄だが、しかし
それならば、単純にそういう形のコードが(スパゲティーコードが)脳に記憶されやすいという
特異な脳構造を持っているだけであって頭が良いというのとは違うんじゃないのかという疑問が出るな。

316 :デフォルトの名無しさん:2013/11/23(土) 07:35:13.54
>>314
誰もが読めるコードが書けるけど
自分しか読まないからあえて効率優先できたないソースにしてる。ってんなら能力があるんだろうね
でもそんな奴はめったにいない

317 :デフォルトの名無しさん:2013/11/23(土) 07:54:13.58
スパゲッティーコードというのはgoto文であっちこっち飛んでこんがらがっているやつのことだぜ。
ブロック構造化されている最近の言語ではスパゲッティーコードというのは無い。
オブジェクト指向を間違った使いかたしてスパゲッティになっているのはスパゲッティというよりバカコード。

318 :デフォルトの名無しさん:2013/11/23(土) 08:03:03.84
イベントドリブンを使わずマルチスレッドでやろうとするのもゴチャゴチャしてるが
スパゲッティといえるのかわからないがこれはスパゲッティと言ってもいいかも。
イベントドリブンを使わずjsp上でイベント処理してるのも同様だ。

319 :デフォルトの名無しさん:2013/11/23(土) 08:07:29.91
あとHashtableをツリー構造にしてるのはアホコード
状態遷移表を使いたいのか知らんが全変数を配列の要素にしているのもアホコード

320 :デフォルトの名無しさん:2013/11/23(土) 08:19:39.74
あとifのネストが異様に多いのはド素人コード

321 :デフォルトの名無しさん:2013/11/23(土) 08:21:17.93
今までの話の中でのスパゲティーの定義は
単純に世の中の大多数が読み難いと思うコードって意味じゃない?

322 :デフォルトの名無しさん:2013/11/23(土) 08:21:33.71
多重ループのネストが異様に多いのは愚鈍コード
1つの関数やファイルが異様に大きいのは、糞コード

323 :デフォルトの名無しさん:2013/11/23(土) 08:22:10.01
>>313
判ります
道に迷うときってどの分岐入っても同じような景色が続いてるようなところで迷う

324 :デフォルトの名無しさん:2013/11/23(土) 08:23:56.23
ファイルが多くて読みにくいというのをスパゲティと言っている奴が多いと想像するが
それはエディタがヘボく多数のファイルを扱えない自己責任。

325 :デフォルトの名無しさん:2013/11/23(土) 08:27:36.22
>>322
KVSで使われるのはレコード
おやじの頭はバーコード

326 :デフォルトの名無しさん:2013/11/23(土) 08:37:41.67
>>319
>あとHashtableをツリー構造にしてるのはアホコード
くわしく
チェイン法でのリスト以外にもツリー構造をとることもあるのでは?

327 :デフォルトの名無しさん:2013/11/23(土) 08:51:19.75
hashtableは配列にすることに意味があるんだと言いたいんだろうな
もちろん衝突を考慮した場合はそこにリストやツリーが絡むけど

328 :デフォルトの名無しさん:2013/11/23(土) 10:20:34.03
ずぶずぶだからねぇ。
いろんなもんをイッパイ積み上げていく競技?趣味?
があるけどプログラミングってそれに近いものがある。

下から順に、カッチリ、かつ出っ張りのない単純な形でつくって、
またその上にそういうの作っていかないと、上まではとてもじゃないけど無理。
ましてや、下のほうからグラグラだったりフニャフニャだったり、
なんか別のもんとネッチャリと癒着してたりすると、
上まで作っていくまでに相当息苦しい思いをするし、
悪い部分を交換することも補強することも難しい。

ノイズとかリスクの増大を、抑えて抑えて行くのが大事。

329 :デフォルトの名無しさん:2013/11/23(土) 10:31:04.49
ハッシュコンテナとか自作する奴は素人。
プロは特に理由がない限りできるだけ標準のライブラリを使って車輪の再発明はしない。
無いならしょうがないけど。

330 :デフォルトの名無しさん:2013/11/23(土) 10:33:38.87
>>329
ちなみに聞くが、きみは中学生?高校生?

331 :デフォルトの名無しさん:2013/11/23(土) 10:48:21.32
いま小3だけど

332 :デフォルトの名無しさん:2013/11/23(土) 11:02:37.97
>>329
これ勘違いしてるやつ多いけど、車輪がどういう仕組みなのかを勉強するのは必須な。

333 :デフォルトの名無しさん:2013/11/23(土) 11:06:39.32
論理演算で四則演算ができるとかな

334 :デフォルトの名無しさん:2013/11/23(土) 11:11:23.37
車輪の再発明ガーって言ってる奴は自分では何も発明してない法則

335 :デフォルトの名無しさん:2013/11/23(土) 11:16:12.16
自作のプログラミン言語ぐらいは、作っとかないとな

336 :329:2013/11/23(土) 11:22:00.62
>>330
ファミコンやゲームボーイでアセンブラでゲーム作ってたおっさんだよ。
いまはC++でSTLやboost使ってる。

337 :デフォルトの名無しさん:2013/11/23(土) 11:26:17.66
ここに居るような人は、>>329みたいな台詞は、
中学か高校のころに一度は言ったことがあるはず。
最初の頃ってそういうの言いたくなっちゃうからね。

338 :デフォルトの名無しさん:2013/11/23(土) 11:28:29.53
まぁ基本的な部分になればなるほどだいたい整備されてるから自分で作ることはないだろうけど
初心者は最初からそんなところ手を出せないが
車輪の再発明ってうるさいやつはフレームワークとかそこらへんで連呼してるイメージ

339 :デフォルトの名無しさん:2013/11/23(土) 11:32:40.64
ゲームでboost使うとかどんな罰ゲームだよ

340 :デフォルトの名無しさん:2013/11/23(土) 11:33:30.24
>>303
受験数学は数学センス無くてもそこそこ取れる

341 :デフォルトの名無しさん:2013/11/23(土) 11:39:08.60
俺受験物理得意だったし大学も物理学科だったけど
物理エンジン自前で書いてて自分の力学の理解のなさに驚いた。

試験や勉強とそれを使って何かするというのはまったく別次元なのだろう。

342 :デフォルトの名無しさん:2013/11/23(土) 11:46:26.33
>>339
時間軸って知ってる?

343 :デフォルトの名無しさん:2013/11/23(土) 11:49:10.47
3DCGやってると、光速度とか気になるよな

344 :デフォルトの名無しさん:2013/11/23(土) 11:50:46.75
ゲームと一口に言っても
処理落ちを気にしなきゃならん様な、ピーキーなゲームばかりじゃないからな

ゲーム用途だと速度が云々とか言い出す奴は、
ACT・FTG・STG・FPSしかやらんのかと
(まあSTGは多少処理落ちしても良いっちゃ良いんだけど)

345 :デフォルトの名無しさん:2013/11/23(土) 11:52:17.96
コンシューマー系だと処理速度に問題なくても断片化の問題が大きい

346 :デフォルトの名無しさん:2013/11/23(土) 12:13:15.10
処理速度に問題ないと処理速度に関わる問題を語るとはこれいかに

347 :デフォルトの名無しさん:2013/11/23(土) 12:17:17.17
え?

348 :デフォルトの名無しさん:2013/11/23(土) 13:03:39.99
>>333
四則演算のみで論理演算作る方が難しいよね

349 :デフォルトの名無しさん:2013/11/23(土) 13:13:39.03
>>322
じゃ100行超える関数がざらのLinuxやWindowsは糞コードか。
まぁコード哲学語る前にまともに使えるソフト作ってから語れよw
hellow world量産してる場合じゃねえぞ

350 :デフォルトの名無しさん:2013/11/23(土) 13:16:49.92
>>344
ゲームの話がしたいんじゃなく、
速度要求が厳しい場合の話がしたいんだろ
アスペかよ

351 :デフォルトの名無しさん:2013/11/23(土) 13:20:15.36
>>329
確かにな。既存のロジック自作すんのはお勉強の時だけ。
実用目的のソフトに車輪の再発明入れまくる奴は間抜けだわ。

352 :デフォルトの名無しさん:2013/11/23(土) 13:28:02.96
ここって意外と中高生多いのか?

>>351
確かにな。コーラを飲んだらゲップが出るよな?
太陽見つめるとまぶしいよな?

353 :デフォルトの名無しさん:2013/11/23(土) 13:40:56.83
むだにめそっどをわけると
おーばーへっどによっておそくなりまする

354 :デフォルトの名無しさん:2013/11/23(土) 13:47:38.42
>>149
100行で多いと思ってるおまえは相当なカスだな。

355 :322:2013/11/23(土) 13:50:07.47
>>349
10行〜100行は普通。
1000行以上だと多い。

356 :デフォルトの名無しさん:2013/11/23(土) 13:51:11.37
>>354
いうても200行300行ざらなんだが
お前の見てきた長い関数って何行なんだ?

357 :デフォルトの名無しさん:2013/11/23(土) 13:54:11.07
分割できるなら100行でも多いよ。
実際には分岐の多いswitchと分岐あたりのコード量がそこそこあると
分割するほうが面倒なことも多いけど。
まあ書いてて分割が面倒でもスコープくらい付けてもいいな。

358 :デフォルトの名無しさん:2013/11/23(土) 13:55:53.88
そもそも関数の長さ云々で語ってる奴があほなんだよ。
関数ができるのに同じコードをベタベタ貼るヤツが糞って言えば良いんだよ。

359 :デフォルトの名無しさん:2013/11/23(土) 13:56:58.80
ある程度統計的な判断ができるから無意味ではない。

360 :デフォルトの名無しさん:2013/11/23(土) 14:00:55.38
別にmain関数が1000行有ろうが処理が重複せず、
ブロックで変数が区切られてりゃかまわんな。
vimやらjvmとかpostgressとか有名どころはそうだし、
1度きりしか呼ばれない関数作られるのも読みにくいし。

361 :デフォルトの名無しさん:2013/11/23(土) 14:01:48.75
コピペ一切禁止の俺DRYも問題だけど
コピペしまくる奴はもっと問題

362 :デフォルトの名無しさん:2013/11/23(土) 14:03:46.27
>>359
いや意味ないね。
重複が良くないと思うなら最初からそう言うべきで、
行数で語る奴はステップ数で見積もりだす奴と同じく
蔑まされるだけ

363 :デフォルトの名無しさん:2013/11/23(土) 14:03:52.89
いやブロックよりも関数のほうが引数と戻り値が明確になるし
(グローバルやメンバ変数使わなきゃの話だが)
名前付けて分けたほうが構造化が進むし検索もしやすい。

364 :デフォルトの名無しさん:2013/11/23(土) 14:04:43.79
>>362の無能さが痛々しい

365 :デフォルトの名無しさん:2013/11/23(土) 14:04:55.46
イージーミスの原因のかなりの割合をコピペが占めてる
完全コピペですまないコードの、コピペ後の修正漏れが多い
その時問題なくてもコメントの修正漏れとかがあって、後任者に迷惑かけることもある
短いコードなら手書きにすべきだね

366 :デフォルトの名無しさん:2013/11/23(土) 14:05:43.78
お前らがガチ中高生だとわかったw

367 :デフォルトの名無しさん:2013/11/23(土) 14:05:48.75
昔は行数で給料が決まってたらしい
だからfor文も手動で展開していたらしい

368 :デフォルトの名無しさん:2013/11/23(土) 14:07:42.81
そういう意味ではhaskellなら行数でなく関数数で給料決めるべき

369 :デフォルトの名無しさん:2013/11/23(土) 14:07:53.88
>>367
今でもステップ数で労力を測ってるとこあるけど、なんの意味あるの?って感じだわ

370 :デフォルトの名無しさん:2013/11/23(土) 14:08:41.34
>>363
ブロックとIDEでできるよ
IDE無くても大体それ用のpragmaあるしね

371 :デフォルトの名無しさん:2013/11/23(土) 14:09:05.89
いまだにソフトウェアのメトリクスが理解できない奴がいるんだな

372 :デフォルトの名無しさん:2013/11/23(土) 14:09:57.27
>>370
なはしがかみ合ってない

373 :デフォルトの名無しさん:2013/11/23(土) 14:10:27.92
>>363
重複しない処理だと読みづらいだけだろ

374 :デフォルトの名無しさん:2013/11/23(土) 14:11:34.92
>>373
>いやブロックよりも関数のほうが引数と戻り値が明確になるし
>(グローバルやメンバ変数使わなきゃの話だが)
ここが伝わっていないと思われる

375 :デフォルトの名無しさん:2013/11/23(土) 14:14:40.17
>>372
ブロックにマーカー置いとくとそこにすぐ飛べる機能があったりする
例えばXcodeとかgnu系で使える
#pragma mark 名前

実際関数で識別するより関数と独立できるんで便利
処理より仕様に近い名前を付けられる

376 :デフォルトの名無しさん:2013/11/23(土) 14:17:33.87
>>374
ブロックだと変数をスコープに区切れるし、
引数戻り値になる値が一貫して明瞭だろ。
それに広域変数の問題も発生しない。

377 :デフォルトの名無しさん:2013/11/23(土) 14:18:53.81
>>375
>>374
ちなみに
>(グローバルやメンバ変数使わなきゃの話だが)
もブロックだとしても同じことだからデメリットになるわけではない。
近辺にコードがないのはデメリットだが100行以上であればすでに近辺の意味は薄い。

378 :デフォルトの名無しさん:2013/11/23(土) 14:19:44.54
>>374
引数はともかく戻り値明瞭にするいみあんの?

379 :デフォルトの名無しさん:2013/11/23(土) 14:20:40.45
>>376
>(グローバルやメンバ変数使わなきゃの話だが)
ブロックは外のブロックを参照できるから意味が異なる。

380 :329:2013/11/23(土) 14:23:04.86
実装が上手い奴は制限なんか設けなくても関数は小さくなる。
構造化が上手いからな。

関数100行までという制限を設けるのは職場のアホ対策として有効。
どんなにアホでも関数を分ける時はそれなりに機能で分けようと頑張るからな。

381 :デフォルトの名無しさん:2013/11/23(土) 14:24:56.17
(余計な煽り入れんなよ・・・)

382 :今日のまとめ:2013/11/23(土) 14:27:21.61
レスが3行以内に収まらない場合は名前欄に関数名を入れること

383 :デフォルトの名無しさん:2013/11/23(土) 14:28:38.22
>>382
面白いww

384 :デフォルトの名無しさん:2013/11/23(土) 14:31:13.39
皮肉ったつもりが無理解を露呈するって良くあるよね

385 :デフォルトの名無しさん:2013/11/23(土) 14:35:48.14
>>377
一度しか使わない関数の短所
・前後の処理と分離されてるため、一度しか使わないにも変わらず、
 呼び出し元と定義先の往来が発生する
・一度しか使わないにも変わらず、初めて見た人は、他の箇所から
 呼び出される可能性を考える必要がある。
・関数名の名前付が微妙。名前付専用の構文と異なり、
 普通は処理に基づいた名前をつける必要がある。
 逆に仕様に近い名前を、付けると他の関数と一貫性が無くなる。
・別ファイルに置かれた場合、どこのファイルに
 置かれたか探す手間がかかる。
 共通の関数ならその手間も許せるものの1回しか
 使われてなかった場合のムカつき具合は異常。
・引数が独立してて変数の名前変更に手間がかかる。
 広域変数は良くないが、関数内でブロックを跨る
 局所変数の場合、広域変数で問題となる、
 どこで値が書き換えられたか分からず難解になる問題が
発生しない。

386 :デフォルトの名無しさん:2013/11/23(土) 14:40:37.51
>>385
・前後の処理と分離されてるため、一度しか使わないにも変わらず、
おれは気にならない(後続の理由による)
・一度しか使わないにも変わらず、初めて見た人は、他の箇所から
static関数やメンバ関数なら必要十分な限定ができる
・関数名の名前付が微妙。名前付専用の構文と異なり、
おれは気にならない
・別ファイルに置かれた場合、どこのファイルに
static関数にすれば気にならない(C/C++だけかな?・・・)
・引数が独立してて変数の名前変更に手間がかかる。
必要なコストと考える

よくまとまっていて助かる。
おれは持論を変えるまでには至らない。

387 :デフォルトの名無しさん:2013/11/23(土) 14:42:54.53
一度しか使わない関数の短所その2
・他の関数名の中に名前が交じる。
 ブロックを探したいんじゃ無く、
 純粋に関数を探したいときに邪魔。
・関数内スコープで飛べない。
 特定の関数内で目的の処理をちょくちょく飛びながら
 探すときに、関係のない関数名も並ぶ。

388 :デフォルトの名無しさん:2013/11/23(土) 14:43:47.28
>>386
主観だらけだなw

389 :デフォルトの名無しさん:2013/11/23(土) 14:44:49.51
>>386
お前みたいな周りを気にしない奴と仕事したくないわ

390 :デフォルトの名無しさん:2013/11/23(土) 14:45:54.77
>>387
・他の関数名の中に名前が交じる。
名前の規則で気にならないレベルまで解決できる
・関数内スコープで飛べない。
エディタの検索機能は必須と考えてるので問題ではないと考える。

391 :デフォルトの名無しさん:2013/11/23(土) 14:47:32.01
>>390
だったら最初から関数で代用せずIDEと連携する機能つかえよ

392 :デフォルトの名無しさん:2013/11/23(土) 14:48:21.32
>>389
いやいや行数気にしないほうが可読性低いと思うぞ。
俺の論点は一点で「変数スコープ」。
しかもそのために「100行限定」とするわけではなく
なるべくスコープ小さくしてね。目安として100行ね。って話。
プロジェクトによってはもっとゆるくするし。

393 :デフォルトの名無しさん:2013/11/23(土) 14:48:43.60
一度しか使わない関数はラムダで書くわ

394 :デフォルトの名無しさん:2013/11/23(土) 14:49:12.40
>>391別にIDEを使うことを否定してるわけではない
>>392

395 :デフォルトの名無しさん:2013/11/23(土) 14:50:22.44
>>386
なんでこいつこんな糞理論をこんなドヤ顔で披露してるの?

396 :デフォルトの名無しさん:2013/11/23(土) 14:51:31.97
>>386
しなくて良い苦労をして何がそんなに嬉しいの?

397 :デフォルトの名無しさん:2013/11/23(土) 14:52:49.24
>>395>>396
新たな問題点指摘は具体的に。
>>386の内容自体が気に食わないならそれは意見の相違。

398 :デフォルトの名無しさん:2013/11/23(土) 14:53:10.46
>>392
ほとんどの言語はブロックでスコープ限定できるぞ

399 :デフォルトの名無しさん:2013/11/23(土) 14:57:11.42
>>398
外部ブロック変数の参照も限定できるの?
できるんだったら処理として独立してるんだから分けていいよね?
別に3行でも分けろと言ってるわけじゃなく
例えば100行くらい以上なら分けたほうが読みやすくね?って話し。

400 :デフォルトの名無しさん:2013/11/23(土) 15:00:40.31
>>399
どういう理由で限定すんの?
使うから参照できる位置にわざわざ宣言するんでしょ。
あと不必要にソースを飛び回るほうが読み辛え

401 :デフォルトの名無しさん:2013/11/23(土) 15:02:30.12
無駄に離れてて名前ついてりゃ読みやすいんなら
誰も無名関数がほしいなんて言わないつーの

402 :デフォルトの名無しさん:2013/11/23(土) 15:02:48.67
>>385
一度しか使わない関数の短所
・前後関係が分離され、見通しが悪い。
 ・定義だけでは、単回呼び出しとわからない。
 ・別ファイルでさらにイライラ。
・分離する際に名称がつけにくい。難読性が増す。

これってこういう意味?
>>387に至っては、何がいいたいんだかわからん。

403 :デフォルトの名無しさん:2013/11/23(土) 15:05:01.37
>>400
俺の論点は一点で「変数スコープ」。
100行超えるようなコードが直線的である確率は低い。
であれば直線部分は関数に切り出されていたほうが見通しがいい。
かつ変数スコープは変数の変化状況を限定してくれるので見通しがいい。
逆にいろいろな変数を触るような関数は
設計に問題があることが多いのでその判断基準にもなりえる。

404 :デフォルトの名無しさん:2013/11/23(土) 15:07:46.00
きちんと同じ粒度で揃えればいいだけ。
例え1度しか使わなくても、見通しは悪くならないよ。

そんな固着した頭じゃ、初心者御用達のMVCなWEBフレームワークすら使えない。

405 :デフォルトの名無しさん:2013/11/23(土) 15:08:03.74
>>402
プログラム云々より国語の教科書や道徳の教科書よんで読解力つける方が先じゃ…

406 :デフォルトの名無しさん:2013/11/23(土) 15:09:51.32
>>404
しなくても良い苦労としなけりゃならん苦労は違うだろ

407 :デフォルトの名無しさん:2013/11/23(土) 15:11:14.77
>>405
冗長すぎてわかりにくいだけだと思うよ。
プログラマとは思えない。

408 :デフォルトの名無しさん:2013/11/23(土) 15:14:40.52
一度しか使わない関数の長所

関数が小さくまとまっているので処理内容を一瞬で理解できる。
その関数以外に影響範囲が及ばないことを簡単に確認できる。
関数が完成したあとはブラックボックスにできる。
呼び出し元関数を読む時にブラックボックスになっている関数を読み飛ばせる。
呼び出し元関数が小さくなって可読性が高まる。
同様の関数が現れる可能性が高く、1つにまとめられる。
関数をまとめて行くと総コード量が減る。
全く別のところでそのコードを流用できる可能性が高まりますます総コード量が減る。
コード量と不具合の量には統計的に相関関係があるので、一般的にコードが減れば不具合も減る。

デマルコの構造化分析からやり直しだな。
その前にCプログラミング診断室を読んだ方がいいかもな。

409 :デフォルトの名無しさん:2013/11/23(土) 15:15:17.03
>>404
そういや中身空っぽな構造体同然のモデル書くやつと、
一度しか書かない関数を分離するやつって往々にして同じ奴だな。
何のためか批判的に考えず形だけやってる感じ。
あと行数指定する奴も同類だ。

410 :デフォルトの名無しさん:2013/11/23(土) 15:18:51.70
下からと上からでは見える風景が全く違うというおはなし

411 :デフォルトの名無しさん:2013/11/23(土) 15:18:55.46
>>408
共通の処理が出てくるのは別問題だろ
そうなった時に初めて分離すりゃいい話。
むしろ既存の関数の分離の仕方が悪いと更に時間が掛る。
典型的なDRYの失敗例じゃん。

412 :デフォルトの名無しさん:2013/11/23(土) 15:19:06.39
>>408の内容は完全同意できるが

・関数切り出しは面倒
と言う厳然たる事実と
・既存のほとんどの言語は関数を切り出しても
 副作用がないことを保証するわけではないのでいまいち達成感がない
と言う厳然たる事実は指摘したい。

413 :デフォルトの名無しさん:2013/11/23(土) 15:20:14.35
>>409
一度しか使わなくても、例えばbusyboxのように、
完全に機能が分かれている場合なんかは、分けた方が見通しがいいよ。

そういう事も含めて、適当に「〜な感じ」なんて批判する方こそ中身がない。

414 :デフォルトの名無しさん:2013/11/23(土) 15:23:15.93
もちろんケースバイケースなワケだが
ダイクストラの構造化プログラミングを
単純否定するようなレスが散見するのはどうかと。

415 :デフォルトの名無しさん:2013/11/23(土) 15:23:26.08
何冊かプログラム設計の本を読んだほうがいい。
全部関数は小さくって書いてある。
色々読んだけど、少なくとも一度しか使わない関数を作らないほうがいいなんて書いてある本は見たことない。

416 :デフォルトの名無しさん:2013/11/23(土) 15:24:57.33
>>408
ブラックボックス化は最初から、再利用可能なものにだけすべきで、
全く再利用を意図しないものにすべきじゃない。
モノリシックとマイクロカーネルの失敗とか、
昔から良くわかってる話だろ。
Linuxで数百業の関数になっても一度しか使われない関数が忌避されてる理由をよく考えろ。

417 :デフォルトの名無しさん:2013/11/23(土) 15:25:16.87
関数呼び出し回数がわからんとか、名前が混ざるって、
静的解析やide使ってないのか?

418 :デフォルトの名無しさん:2013/11/23(土) 15:27:12.43
>Linuxで数百業の関数になっても一度しか使われない関数が忌避されてる
初耳
ソース

419 :デフォルトの名無しさん:2013/11/23(土) 15:28:05.13
>>413
批判ってのは批(付き合わせ)判(判断する)って意味だぞ
非難と間違えてないか?

420 :デフォルトの名無しさん:2013/11/23(土) 15:29:39.78
>>419
今度は言葉遊び?悪いけど付き合わないよ。

421 :デフォルトの名無しさん:2013/11/23(土) 15:30:56.61
>>414
ダイクストラの構造化プログラミングは、
ブロックをgotoで跨るなという話で今までの話とは全く関係ない。
ループからループの真ん中に飛び込むとか、
ifからループに飛び込むとか、そんな話一度も出てないだろ?

422 :デフォルトの名無しさん:2013/11/23(土) 15:31:16.02
>>416
モジュールとかブート部分とか
一度しか使わないコードばっかりなんですがそれは・・

423 :デフォルトの名無しさん:2013/11/23(土) 15:31:40.55
>>421
ごめんキミとは会話できない

424 :デフォルトの名無しさん:2013/11/23(土) 15:32:08.40
>>415
書いてなくてもLinuxやWindows 2000カーネルや
PostgreSQLとかはそうじゃん

425 :デフォルトの名無しさん:2013/11/23(土) 15:33:26.45
構造化プログラミング(こうぞうかプログラミング、structured programming)とは、1960年代後半にエドガー・ダイクストラらによって提唱された仮想機械モデルに基づく段階的詳細化法を用いたプログラミングのことを言う。

426 :デフォルトの名無しさん:2013/11/23(土) 15:33:53.88
>>422
そこにコールバック以外で一度しか呼ばれない関数はあった?
あったら貼ってくれ。

427 :デフォルトの名無しさん:2013/11/23(土) 15:34:43.56
>>423
そのまま返そう。

428 :デフォルトの名無しさん:2013/11/23(土) 15:34:49.18
>>425
ごめんgoto禁止論の話してたわ

429 :デフォルトの名無しさん:2013/11/23(土) 15:35:26.65
>>421この釣り針は・・・

430 :デフォルトの名無しさん:2013/11/23(土) 15:35:41.73
>>416
なんで俺たちこの構造化もオブジェクト指向も理解できないアホを一所懸命教育してんの?

431 :デフォルトの名無しさん:2013/11/23(土) 15:37:03.74
>>425
でもその内容って反復とか分岐の話で局所変数の話は、出てこないよな。
モジュールの概念も無いし。

432 :デフォルトの名無しさん:2013/11/23(土) 15:39:14.58
gotoは構造化を壊すという話しはあるけど、
構造化とはgotoを使わないことだ、という話はない。

関数を細かい構造に分けるのは構造化プログラミングの基本の1つだな。
関数を細かく分けると、関数呼び出しがツリー構造になってく様子が見えてくるだろ?
gotoを使うとこの関数のツリー構造が壊れる。

433 :デフォルトの名無しさん:2013/11/23(土) 15:40:00.23
>>429
goto禁止の論文に書いてある内容だよ
それに基づいていgoとかはブロック間で行き来したり、
上に戻れない限定されたgotoが搭載されたよね

434 :デフォルトの名無しさん:2013/11/23(土) 15:40:23.68
>>426
では今適当に調べた知らない関数を
http://lxr.linux.no/linux+v3.12.1/+code=deinit_rsq

435 :デフォルトの名無しさん:2013/11/23(土) 15:40:36.09
>>431
I 構造化プログラミング論
12 プログラムのモデルについて

局所的な変数について言及してる

436 :デフォルトの名無しさん:2013/11/23(土) 15:42:40.69
>>435
抜粋よろしく

437 :デフォルトの名無しさん:2013/11/23(土) 15:42:51.64
>>426
次にすぐ上にあった関数を
http://lxr.linux.no/linux+v3.12.1/+code=init_rsq

438 :デフォルトの名無しさん:2013/11/23(土) 15:44:32.45
>>435
お前ふざけんなw
これはつぎの2つの重要な面を反映していました。
第1番目は、”有効範囲(scope)”の概念です。
。。。

439 :デフォルトの名無しさん:2013/11/23(土) 15:45:16.57
くそw
>>438>>は>>436だった・・・

440 :デフォルトの名無しさん:2013/11/23(土) 15:50:46.41
>>426
では次にあなたの感想をどうぞ

441 :デフォルトの名無しさん:2013/11/23(土) 15:52:41.33
関数にしろ、クラスにしろ、機能として必要になるまで、分割する必要はないだろう。

機能として必要になったときそこで分割すれば、十分だよ。
あとで必要になるかもしれないで作っていたらゴミだらけになるじゃないか。
そんなもの品質を落とすだけの蛇足だ。

442 :デフォルトの名無しさん:2013/11/23(土) 15:52:53.92
糞コードをリファクタリングするときに真っ先に手を付けるのは巨大関数の構造化だな。
関数が小さくなるだけでもレビューやトレースがかなり捗る。

443 :デフォルトの名無しさん:2013/11/23(土) 15:52:57.44
コールバックは、ホモっぽい

444 :デフォルトの名無しさん:2013/11/23(土) 15:54:39.97
441がオブジェクト指向、ユニットテストときて、
契約プログラミングまで身につけるには100年くらいかかりそうだなこりゃ。

445 :デフォルトの名無しさん:2013/11/23(土) 15:58:09.68
>>443
バックってそういう・・ってバカ!

446 :デフォルトの名無しさん:2013/11/23(土) 16:00:21.27
ひとつのスレは1000行まで(キリっ
ひとつのレスは3行まで(キリっ

447 :デフォルトの名無しさん:2013/11/23(土) 16:00:27.53
>>437
そのコードも200行超がザラだな。
あと確かに一度しか呼ばれない関数もあったな。
ただその関数は将来再利用すること前提の関数だな。

448 :デフォルトの名無しさん:2013/11/23(土) 16:01:13.42
>>442
構造化された関数は?

449 :デフォルトの名無しさん:2013/11/23(土) 16:02:08.62
さすがに必死すぎ

450 :デフォルトの名無しさん:2013/11/23(土) 16:02:50.62
>>442 >>437みたいな構造化された巨大関数も、
でかいからって壊すの?

451 :デフォルトの名無しさん:2013/11/23(土) 16:05:25.41
動作しているコードをリファクタリングするのはそれなりのリスク。
だから書いてるときに分割できるならそれに越したことはない。
もちろん時間の関係上常にできるわけじゃない。

452 :デフォルトの名無しさん:2013/11/23(土) 16:05:56.43
分量を目安にして分割した場合、その関数に簡潔な名前が付くか疑問だ。

453 :デフォルトの名無しさん:2013/11/23(土) 16:06:24.56
>>444
オブジェクト指向でも再利用できんコードの分離は望まれてないよ。
例えばSmalltalkはブロックを多用し、出来るだけ1箇所に書く。
長いメソッドよりまとまらない処理の方が嫌われる。

454 :デフォルトの名無しさん:2013/11/23(土) 16:07:23.27
>オブジェクト指向でも再利用できんコードの分離は望まれてないよ。
ソース

455 :デフォルトの名無しさん:2013/11/23(土) 16:08:44.24
一回しか呼び出されない関数はまとまってるだろ・・・

456 :デフォルトの名無しさん:2013/11/23(土) 16:09:01.07
高頻度で再利用できるに越したことはないが、
上のほうでだれかが言っていたが、
関係する変数を関数内に隠せる場合、
その分だけでも片付いているのは事実。

457 :デフォルトの名無しさん:2013/11/23(土) 16:13:18.48
>>444
1箇所しか呼ばれない関数を分離する事と、プロトコルにあわせてメソッドを分離することは違うぞ。

458 :デフォルトの名無しさん:2013/11/23(土) 16:14:06.06
>>447
200超は一つで、200前後で見積もっても3ぐらいしかない
コードは2.4.16から変わってない上にstatic定義だから
将来の再利用性というよりは機能の分割目的だろう

459 :デフォルトの名無しさん:2013/11/23(土) 16:16:40.69
>>457
言い方が違うだけで、言ってること同じじゃないか。
何を今更。

460 :デフォルトの名無しさん:2013/11/23(土) 16:23:17.01
>>454
PharoのSmalltalkクラスオブジェクト
Smalltalkの中じゃかなり長いメソッドが多いが、
再利用できないメソッドはおいてない。
サードのコードが入ってないSystem系はだいたいそんな感じ。
あるとすればExample系位だよ
間違えて再利用できないメソッドにメッセージ送っても危険だしな。

461 :デフォルトの名無しさん:2013/11/23(土) 16:24:21.20
>>460
>間違えて再利用できないメソッドにメッセージ送っても危険だしな。
少なくともprivateのある現在の言語には関係ないな

462 :デフォルトの名無しさん:2013/11/23(土) 16:26:41.04
>>459
確かに、呼び出してはないがプロトコルに使われてるわけで、
プロトコルに必要とすらされない単なる分離された関数とは違うだろ。
それ言い出したら、コールバックも割り込みも同じ扱いじゃねえか。

463 :デフォルトの名無しさん:2013/11/23(土) 16:27:30.70
結局思い込んでただけと

464 :デフォルトの名無しさん:2013/11/23(土) 16:28:38.27
>>461
メソッドにprivateなんて要らんけどな。
それこそOOが出来てない。

465 :デフォルトの名無しさん:2013/11/23(土) 16:29:54.22
>>464
ハイ終了

466 :デフォルトの名無しさん:2013/11/23(土) 16:31:54.56
以下、>>464の超理論をお楽しみ下さい。

467 :デフォルトの名無しさん:2013/11/23(土) 16:32:29.35
Simulaから脈々と受け継がれてるprivateを要らないとまで言って
何を主張するつもりなんだよw

468 :デフォルトの名無しさん:2013/11/23(土) 16:32:30.56
アンチデマルコのコマルデ君はまずwikipeiaで凝集度のアーティクルを読むべき。

469 :デフォルトの名無しさん:2013/11/23(土) 16:33:41.28
じゃあ最初の定義を訂正すればいいわけだな。
申し訳ありませんでした。

コールバックではなく
かつ
プロトコルで要求されていない
かつ
再利用される予定もなく
かつ
一度しか呼ばれない関数は読みづらいだけ

470 :デフォルトの名無しさん:2013/11/23(土) 16:34:19.75
>>467
変数用だろアレ

471 :デフォルトの名無しさん:2013/11/23(土) 16:34:40.83
>>462
内部的な設計分離をプロトコルと言ってるのかと。
なら違う扱いであってると思うよ。
きちんと、別物の前提で話してるだろう。

472 :デフォルトの名無しさん:2013/11/23(土) 16:35:56.20
>>467
幾つかの言語はデフォでprivateなのは変数だけ

473 :デフォルトの名無しさん:2013/11/23(土) 16:36:48.26
>>464のOO
・privateは変数専用である

474 :デフォルトの名無しさん:2013/11/23(土) 16:37:20.35
普通って大学の情報学部では何の言語習うもんなんだ?
Cとjavaとアセンブリ言語しか必修じゃないけどこんなもん?
選択でRubyもあるけど

475 :デフォルトの名無しさん:2013/11/23(土) 16:37:41.09
>>470-472
よくないよなアレは
publicとかprivateとか恣意的に変えられないようにすべき

476 :デフォルトの名無しさん:2013/11/23(土) 16:38:37.93
>>471
インターフェースとかAPIとかと同じ意味合いだよ
主に実装の抽象化を目的としたやつ

477 :デフォルトの名無しさん:2013/11/23(土) 16:39:47.78
正直protectedはいらない
処理委譲したいならインターフェース渡せばいいだけや

478 :デフォルトの名無しさん:2013/11/23(土) 16:40:55.43
>>476
ならやっぱり同じだろ。
レイヤでの分離以外に、分離する理由がないだろ。

479 :デフォルトの名無しさん:2013/11/23(土) 16:42:09.40
ボコボコにされて主張変えたンゴww

480 :デフォルトの名無しさん:2013/11/23(土) 16:43:34.88
>>473
Smalltalk系統はそうだよ。
Selfやjavascriptに関してはprivateすらないけど。
そもそもC++系統のコンパイラーの実装がめんどかったんで、
スコープ修飾子は関数か変数か区別しません系とは
考え方が違うからな。

481 :片山博文MZコスモ ◆T6xkBnTXz7B0 :2013/11/23(土) 16:45:02.84
XScreenSaverの168個のスクリーンセーバーを移植したよ。
http://katahiromz.web.fc2.com/xscreensaverwin/
https://github.com/katahiromz/XScreenSaverWin

482 :デフォルトの名無しさん:2013/11/23(土) 16:45:20.32
>>478
非難されてんのは、行数減らすのが目的で、実装も抽象化できない関数だから。

483 :デフォルトの名無しさん:2013/11/23(土) 16:46:29.38
結局
・一度しか呼ばれない関数は読みづらいだけ
・関数というブロックより一段厳しいスコープによる可読性
のトレードオフってことでいいよね?

おれは上は気にならないし(気になる場合は残すが数百行単位ではない)
単純読みでもほとんどの場合関数になってたほうが見やすいし
スコープ制限されてるしで、できる余裕があるなら関数にするでいいや。

484 :デフォルトの名無しさん:2013/11/23(土) 16:48:09.29
最近の言語は訳がわかんねえズラ
インターフェースって何ズラ
仮想関数と何が違うズラ
デリゲートって何ズラ
関数ポインタと何が違うズラ
じじい着いて行けねえズラ

485 :デフォルトの名無しさん:2013/11/23(土) 16:48:29.84
>>480
どんどん病気が酷くなってくなw

486 :デフォルトの名無しさん:2013/11/23(土) 16:48:50.12
まあ何だかんだ>>469みたいな行数減らす目的の
関数は>>385 >>387の理由で読みづらい

487 :デフォルトの名無しさん:2013/11/23(土) 16:50:35.27
>>485
C++ってprivateでもオーバーライドできるんやでスゴイやろ

488 :デフォルトの名無しさん:2013/11/23(土) 16:52:30.20
またダイクストラ無視かよw
つか>>385>>387では
ダイクストラの「プログラムの段階的作成」はどういう立ち位置になるわけ?

489 :デフォルトの名無しさん:2013/11/23(土) 16:53:10.80
強引に結論にしたな。
>>385 >>387だけから>>469を導き出すって無茶だぞ。

490 :デフォルトの名無しさん:2013/11/23(土) 16:57:06.51
>>473
そもそもSmalltalk系だとprivate自体が重要じゃないからなぁ。
オブジェクト内の変数にアクセスしたいなら
結局#insVar:メッセージ送れば見られるし。
メッセージプロトコルを守る事が最重要で情報隠蔽なんそれって感じ
ただカプセル化は多用されるけどね。
カプセル化≠情報隠蔽private

491 :デフォルトの名無しさん:2013/11/23(土) 16:57:26.68
じゃあmain関数は一回しか呼ばれないから分割禁止な!

492 :デフォルトの名無しさん:2013/11/23(土) 16:59:15.56
>>488
ダイクストラ全く関係ないよな

493 :デフォルトの名無しさん:2013/11/23(土) 16:59:20.03
Smalltalkerにキチガイが多いのはなぜなんだ

494 :デフォルトの名無しさん:2013/11/23(土) 17:00:55.54
>>492
>>425>>491
これでも理解できない?

495 :デフォルトの名無しさん:2013/11/23(土) 17:02:01.58
>>493
自分の主張が通らないときちがい扱いか
経験も根拠もないくせに

496 :デフォルトの名無しさん:2013/11/23(土) 17:02:52.12
>>494
お前は例の読解力のない基地外か。

497 :デフォルトの名無しさん:2013/11/23(土) 17:03:13.72
>経験も根拠もないくせに
これ笑うとこ?w

498 :デフォルトの名無しさん:2013/11/23(土) 17:03:41.93
>>493
SmallTalkerどころかLoudSpeakerジャネーノ

499 :デフォルトの名無しさん:2013/11/23(土) 17:04:07.72
>>496
お前のそのレスいろいろ読解力ないことがばれてるぞ

500 :デフォルトの名無しさん:2013/11/23(土) 17:04:15.27
>>491
main内で静的変数使ってコマンドラインを再帰解析だ
これならニ回以上呼ばれる

501 :デフォルトの名無しさん:2013/11/23(土) 17:06:01.33
>>500
いやいや外から呼ばれるのは一回だからとマジレスw

502 :デフォルトの名無しさん:2013/11/23(土) 17:06:28.94
>>464
そういうあなたは、冗長な文章書いてた人ですね。

503 :デフォルトの名無しさん:2013/11/23(土) 17:07:31.10
>>502
な・・ならmainを呼ぶだけのmain_externalを作れば・・

504 :デフォルトの名無しさん:2013/11/23(土) 17:09:15.72
>>494
一度しか呼ばない関数を分割するな
じゃなく
抽象化やコールバック目的、プロトコルに準じる目的以外で、
一度しか呼ばれない関数を作るなと言ってるんだけど

main関数を分割するかどうかは関係ないのはわかってるか?

505 :デフォルトの名無しさん:2013/11/23(土) 17:09:21.21
>>503
それはmainから呼び出すので内部を分割しているのと変わりませんね
とマジレスw

506 :503:2013/11/23(土) 17:09:25.50
>>501だた・・

507 :デフォルトの名無しさん:2013/11/23(土) 17:10:33.03
>>499
>>491これを見てどう読解できるんだよ

508 :デフォルトの名無しさん:2013/11/23(土) 17:11:40.03
スコープを限定できる関数化が抽象化じゃなくてなんなんだ

509 :デフォルトの名無しさん:2013/11/23(土) 17:12:58.96
>>497
じゃ煽るだけじゃ無く
お前の豊富な経験で反論してみろよw

510 :デフォルトの名無しさん:2013/11/23(土) 17:13:45.51
>>508
COBOLer?

511 :デフォルトの名無しさん:2013/11/23(土) 17:14:07.10
ダイクストラの段階的詳細化法は抽象化ではないのか

512 :デフォルトの名無しさん:2013/11/23(土) 17:14:33.19
>>505
くそ・・じゃあエントリポイントを書き換えてmainを2回呼んでやる!

513 :デフォルトの名無しさん:2013/11/23(土) 17:14:49.58
まじで>>511だったか・・・

514 :デフォルトの名無しさん:2013/11/23(土) 17:14:52.12
>>508
関数外に依存してりゃ抽象化にならねえだろ

515 :デフォルトの名無しさん:2013/11/23(土) 17:18:19.47
>>514
まあそういう意味では完全ではないが一段限定されるでしょ。
変数スコープに限らなければ>>511

516 :デフォルトの名無しさん:2013/11/23(土) 17:18:19.57
>>514
説明をお願いします。

517 :デフォルトの名無しさん:2013/11/23(土) 17:21:41.28
>>511
お前が段階的抽象化論の意味を間違えてるように見える
段階的抽象化ってのは実装に依存しないようにしましょうって話だ
今回の話とは関係ない

518 :デフォルトの名無しさん:2013/11/23(土) 17:24:27.69
>>516
外部に依存する=関数の呼び出し元を変更すると関数内部に変更が必要な場合がある
外部に依存しない=関数呼び出し元を変更しても関数内部の変更は不要

519 :デフォルトの名無しさん:2013/11/23(土) 17:26:32.45
>>511
段階的抽象化には実装から独立したプロトコル(規約)が必要だろ

520 :デフォルトの名無しさん:2013/11/23(土) 17:26:56.05
>>517
それだけじゃないでしょ


プログラムサイズが大きくなったとしても正しさを証明できる
良く構造化されたプログラム(well-structured programs)、
大きなプログラムの理解を助ける段階的な抽象化(step-wise abstraction)、
抽象データとその操作の抽象文の共同詳細化(joint refinement)について述べた。

521 :デフォルトの名無しさん:2013/11/23(土) 17:27:01.35
うん?

関数を作る時点では一度しか呼ばないなんてわからないので
一度かどうかは関数を作る基準にならない。

少なくとも、関数を使っている場所とテストコードの
2箇所で使用するのは明らかなので
一度しか呼ばれない関数なんてものは存在しない。

522 :デフォルトの名無しさん:2013/11/23(土) 17:28:19.75
>>519

でその厳しい条件だとなにかいいことがあるの?
その条件じゃなければ分割に意味はないの?

523 :デフォルトの名無しさん:2013/11/23(土) 17:30:33.86
>>516
ある関数から呼ばれなくなった途端、
削除されたり名前が変わったりするのは抽象化と言えんだろ。
抽象化してたらシグニチャーを簡単に変更できない。

524 :デフォルトの名無しさん:2013/11/23(土) 17:31:54.05
関数を使っている場所にテストコードを含め内にしても、
テストをやる理由を考えて見ればわかる。

テストコードを書くのはテストコードが必要だからだ。
なぜテストコードが必要かというと、
バグを入れないために必要だからだ。

複雑なものほどバグが入りやすい。
だからバグを入れないようにするには、小さな単位でテストした方がいい。
小さな単位でテストできるようにするためには
少なくともそれが関数になっていないといけない。
もちろん疎結合になっているべきという理由もあるがね。
でも全ては小さな関数にすることが基本。

よって、テストをするために関数が必要。
それが一回しか呼ばれていないとか関係ない。
より小さな単位で関数化することで、テストも用意になり
複雑性もバグも減る。

525 :デフォルトの名無しさん:2013/11/23(土) 17:32:09.43
屁理屈大会になってまいりましたw

526 :デフォルトの名無しさん:2013/11/23(土) 17:32:46.03
>>518
ありがとう。でもちょっと理解できなかった。
一方の変更で済ませられないって、どういう場合?

527 :デフォルトの名無しさん:2013/11/23(土) 17:36:33.35
つまり
>大きなプログラムの理解を助ける段階的な抽象化(step-wise abstraction)
は抽象化ではないと。

528 :デフォルトの名無しさん:2013/11/23(土) 17:36:47.58
>>522
移植性を上げたり、再利用性を上げる上での基本だろ。
外部に依存してたら、最初から外部の一部にしておいた方が、
名前の変更だの引数の変更だの発生せず遥かにマシだわ。

529 :デフォルトの名無しさん:2013/11/23(土) 17:37:59.12
関数ってのは処理のフックポイントなんだよね。
関数の呼び出しの前後で、何かが変わる。

だから関数の呼び出し前と
呼び出し後を検証すれば
それがテストコードになる。

関数の呼び出し前と呼び出し後で
変更するものが多くあればあるほど
テストは難しくなる。

1つの値しか変わらないのなら、その1つだけをチェックすればいいが。
その値が2つになれば、組み合わせで4パターン。
3つになれば8パターン。4つになれば16パターン。どんどん増えていく。

だからそのようなことがないように、小さな関数に分けるわけ。

530 :デフォルトの名無しさん:2013/11/23(土) 17:38:07.68
>>521
それは形だけだろ、呼び出し元に依存してたらテストしても意味ねえよ。

531 :デフォルトの名無しさん:2013/11/23(土) 17:39:38.85
>>530
なら呼び出し元に依存していなければいいだけの話。

532 :デフォルトの名無しさん:2013/11/23(土) 17:40:19.07
>>528
うん屁理屈だね
分割しなかったら再利用性が高まるとかないから。
数100行にもわたるコードを1つ関数として切り出したところで
作業が増えるどころか見通しが上がるほうが多いよ。

で外部に依存てなんのこと?

533 :デフォルトの名無しさん:2013/11/23(土) 17:41:38.31
例えばライブラリを作ることを考えよう。

そのライブラリの関数は一回どころか
(テストコードを除いて)一回も使われていないことだってある。

ではなぜ、それを関数にしたのか?

答えられるかい?

534 :デフォルトの名無しさん:2013/11/23(土) 17:42:02.22
>>526
関数の行数を減らす目的で、関数の一部を別の関数に無理に分離した場合。
必要な引数が変更になる度に呼び出し元、呼び出し先相互に影響を受ける。
それから、呼び出しもとが使わなくなると大抵削除されてしまう。

535 :デフォルトの名無しさん:2013/11/23(土) 17:43:34.14
必要な引数が変更にならないような単位で
関数化すればいいだけじゃないかw

ほんと関数化が下手だなw

536 :デフォルトの名無しさん:2013/11/23(土) 17:44:09.36
>>534
お前が作ってるのは、関数ではなく
サブルーチンだよ。

関数を作れ。

537 :デフォルトの名無しさん:2013/11/23(土) 17:44:14.76
>>534
それはおかしい。
その修正は同じ箇所にあってもほぼ同じ量修正が入ってる。
違うのは関数のインターフェイスがあるかないかだけ。
これって1行しか差がない。
その数100行で1行分すら惜しいと言う感性が理解できない。

538 :デフォルトの名無しさん:2013/11/23(土) 17:46:33.18
>>532
呼び出し元から不要になるたびに削除
引数が増えるたびに引数追加でテストも変更
やっとられんな

539 :デフォルトの名無しさん:2013/11/23(土) 17:46:38.02
関数化が下手

関数にする

いろんな面倒事が起きる

だから関数にするべきじゃない

一回しか使わないものは面倒なだけ。


あー、なるほどね。要するにこういうわけかw

540 :デフォルトの名無しさん:2013/11/23(土) 17:47:07.44
>>538
それテストの粒度荒くしただけ

541 :デフォルトの名無しさん:2013/11/23(土) 17:47:21.53
>>538
いや、だから、なんでそんな関数作るの?

お前が関数作るの下手なだけだよね?

下手だから、そんなメンテナンス性の悪い関数を作ってしまい。
だから関数にするなって言ってるだけだよね?

542 :デフォルトの名無しさん:2013/11/23(土) 17:48:45.83
>>535
そういう行数減らすための再利用できないヘタな関数つくんなって話だ。

543 :デフォルトの名無しさん:2013/11/23(土) 17:48:51.35
>>534
もう考え方が違うんだな。
目的は置いておいて、名称付きの関数が抽象化された物と考えるなら、
引数の変更は実装ではなくて、抽象モデル自身の変更になる。

呼び出し側が変更されるなら、呼び出し側で対応するか、
別の関数を経由すればいい。

544 :デフォルトの名無しさん:2013/11/23(土) 17:49:13.30
この馬鹿がどんな関数を作るのか
見てみたいなw

なんか長い行のいい例ないかな。
まあ、長いのを途中でグループ化しただけの
サブルーチンを作るという落ちだろうけどなw

545 :デフォルトの名無しさん:2013/11/23(土) 17:49:53.50
>>541
一度しか呼ばない再利用できない関数がそれ以外にあるか?

546 :デフォルトの名無しさん:2013/11/23(土) 17:49:58.36
>>542
頭悪いな。

下手な関数じゃなくて、
上手な関数にすればいいだけだろ。

それとも何か?一回しか使わないものは
上手な関数に出来ないとでもいうのか?

547 :デフォルトの名無しさん:2013/11/23(土) 17:50:12.94
>>542
段階的詳細化って総コード量はお前も指摘するとおり増えてるぞw

548 :デフォルトの名無しさん:2013/11/23(土) 17:50:40.44
一回しか呼ばないことと、
きれいな関数が出来るかどうかは
全然関連性がないよね?

これが答えだよ。

549 :デフォルトの名無しさん:2013/11/23(土) 17:52:44.06
>>469を非難する奴の関数をみてみたいなw

550 :デフォルトの名無しさん:2013/11/23(土) 17:52:52.95
>>545
もしかして関数化する目的は、
再利用だけだと思ってないか?

再利用する以外にも関数化する意味があるのは事実だから
そのために関数化する意味があるよね。

551 :デフォルトの名無しさん:2013/11/23(土) 17:53:29.42
>>547
総コード量が重要なのではなく
メンテナンス性の方が重要だからね。

552 :デフォルトの名無しさん:2013/11/23(土) 17:53:53.90
>>546
上手な関数は再利用できるだろバカ

553 :デフォルトの名無しさん:2013/11/23(土) 17:54:49.86
>>552
再利用できるが、再利用しない場合はどうするんだ?
それが一回しか呼ばれない関数なんだが?

554 :デフォルトの名無しさん:2013/11/23(土) 17:55:07.05
>>547
総コード量じゃなくて関数内のコード量を言ってんだよ

555 :デフォルトの名無しさん:2013/11/23(土) 17:55:28.11
再利用可能なのと
再利用するかどうかは別の話だよね?

556 :デフォルトの名無しさん:2013/11/23(土) 17:55:39.91
>>553
それは今回の対象になってないだろ

557 :デフォルトの名無しさん:2013/11/23(土) 17:55:47.98
>>552
できるのとするのは別。
可視化のためにサブルーチン作るのは有意義。
平行線辿り過ぎてるわ。

558 :デフォルトの名無しさん:2013/11/23(土) 17:55:52.50
>>551>>554
>>537はどう理解してるの?

559 :デフォルトの名無しさん:2013/11/23(土) 17:56:59.70
ほら答えでた

一回しか使わなくても(再利用しなくても)
再利用可能であるならば関数にする方がいい。

560 :デフォルトの名無しさん:2013/11/23(土) 17:57:58.93
>>553
>>385を読む限り駄目

561 :デフォルトの名無しさん:2013/11/23(土) 17:58:15.38
>>553
>>469

562 :デフォルトの名無しさん:2013/11/23(土) 17:58:29.91
一回しか使わなくても(再利用しなくても)
再利用可能な関数を作れる人ってのが
技術力が高い人であり、

それが作れる、再利用可能に出来なかった理由を
一回しか使わないからだ!

って的はずれなことを言っているのが
ここにいるキチガイ。

563 :デフォルトの名無しさん:2013/11/23(土) 17:59:17.38
>>560
じゃあ>>385が間違っているってことで
終わりじゃねーの?

564 :デフォルトの名無しさん:2013/11/23(土) 17:59:21.85
再利用可能でなくても関数にする方が基本的にはいいよ。
可読性が上がるという意見が何度も出てるでしょ。

565 :デフォルトの名無しさん:2013/11/23(土) 18:00:10.59
あとテストが可能になるっていう理由もあるね。

再利用だけじゃないんだよ?
再利用しか思いつかないから
馬鹿な答えになるんだよ。

566 :デフォルトの名無しさん:2013/11/23(土) 18:00:54.66
>>559
>>469にも書いてあるしそれでいいんじゃない

567 :デフォルトの名無しさん:2013/11/23(土) 18:01:49.71
テストが面倒だから関数作らないって

568 :デフォルトの名無しさん:2013/11/23(土) 18:01:52.17
長い関数だったらテストどうするのさ?

569 :デフォルトの名無しさん:2013/11/23(土) 18:03:42.08
>>565
テストはインターフェースが固まってない関数にしちゃいかんのよ
Xcodeユニットテストガイドやケントベックがゆってた

570 :デフォルトの名無しさん:2013/11/23(土) 18:04:55.23
テストするために関数化するっていってるやつはユニットテストの目的解ってないニカワ

571 :デフォルトの名無しさん:2013/11/23(土) 18:05:12.63
>>569
奴は先にテスト書くから・・

572 :デフォルトの名無しさん:2013/11/23(土) 18:05:13.42
で固まった後もテストしないんですね
わかります

573 :デフォルトの名無しさん:2013/11/23(土) 18:06:36.22
まてまてテストできるかもわからない1000行レベルの関数を
そのままリリースするつもりか?

574 :デフォルトの名無しさん:2013/11/23(土) 18:06:49.84
http://otndnld.oracle.co.jp/products/jdev/pdf/905/J-gettingstartedwithunittesting.pdf

ホワイトボックス・テストを書かない
ユニット・テストでは、クラスがどのように実装されるかではなく、クラスが何
を行うかに重点を置く必要があります。クラスのホワイトボックス・テストは、
privateおよびprotectedメソッドもすべてテストすることになり、それによる実装
の変更によって、テストも変更が必要になる可能性が高くなります。したがって、
既存のテストを使用して何も破損しなかったことを実証する場合、ホワイトボッ
クス・テストは効果的なリファクタの妨げになります。同様に、インタフェース
の実装クラスではなく、インタフェースに対してテストを記述することをお薦め
します。
この記事以外にもあるのですが、有名どころの人が書いてるのはprivate

575 :デフォルトの名無しさん:2013/11/23(土) 18:07:04.41
>>570
coverage的にも分岐は関数化したほうが良い。
無駄にテスト項目増える。

576 :デフォルトの名無しさん:2013/11/23(土) 18:08:51.02
>>573
1000行の関数をテストすりゃいいだけだろ
glibのvsprintfの関数とかクソなげぇけどテスト書かれてるぞ

577 :デフォルトの名無しさん:2013/11/23(土) 18:09:48.05
>>575
ホワイトテストはすべきじゃないんですって

578 :デフォルトの名無しさん:2013/11/23(土) 18:11:07.86
>>576
1000行の関数が外部からテスト可能って動作実績があるもののおまけだよ

579 :デフォルトの名無しさん:2013/11/23(土) 18:12:42.05
>>577
ホワイトテストじゃなくてホワイトボックステストな
境界値とかも分岐が小さいほうが手間かからないんだよ

580 :デフォルトの名無しさん:2013/11/23(土) 18:12:51.93
>>578
そういう問題じゃない
そもそも無理にホワイトテストはしちゃいけない

581 :デフォルトの名無しさん:2013/11/23(土) 18:13:56.41
>>578
テストがおまけって意味?
そんなことないだろ。

582 :デフォルトの名無しさん:2013/11/23(土) 18:14:50.71
ホワイトボックステストすべきじゃないなら
どうやって自分のプログラムの動作を保証するの?
テストのコストもあるから
最終的にはブラックボックステストしか残さなくても
1000行もの関数をテストもせずに新規実装リリースするつもりか?

583 :デフォルトの名無しさん:2013/11/23(土) 18:15:07.19
>>579
内部を一部切り離そうが切り離すまいが、
ホワイトボックステストのテスト項目は変わらんだろ

584 :デフォルトの名無しさん:2013/11/23(土) 18:17:39.92
>>583
・・分岐網羅とかホワイトボックスだよな?
むしろホワイトボックステストの方は劇的に変わるはずだが

585 :デフォルトの名無しさん:2013/11/23(土) 18:19:49.54
>>584
ごめんブラックボックステストの間違いでした

586 :デフォルトの名無しさん:2013/11/23(土) 18:20:50.45
>>582
普通に関数の仕様に基づいてブラックボックステストだろ
仕様外の動作も保証する気なの?リファクタリングどうすんの?

587 :デフォルトの名無しさん:2013/11/23(土) 18:21:44.38
>>574とwikipediaの記述は矛盾してるな
単体テスト、あるいはユニットテストとは、
メソッドなどの小さな単位で行うテストのことである。
単体テストは、ホワイトボックステストを利用して行われる場合が多い。

588 :デフォルトの名無しさん:2013/11/23(土) 18:22:49.88
>>586
その仕様が固まっているなら
1000行もあれば簡単に内部分割できるでしょ。

589 :デフォルトの名無しさん:2013/11/23(土) 18:23:17.32
>>586
仕様決まってない段階なら
ゴッドオブジェクトならぬゴッド関数作るより
細分化したほうがブラックボックスでもやりやすいだろ

590 :デフォルトの名無しさん:2013/11/23(土) 18:25:11.63
>>587
俺でも編集できるWikipediaが正しいとかw

591 :デフォルトの名無しさん:2013/11/23(土) 18:26:44.53
>>588
関数化した関数が>>469を満たして無ければしてもテストしても意味ないぞ

592 :デフォルトの名無しさん:2013/11/23(土) 18:27:38.29
1度しか使わないつもりで作った関数でも、
後の仕様変更で複数回呼び出すようになるなんてことは普通にあるぞ。
再利用性の問題よりも、分割によって元の関数や別の関数との結合が疎になることのほうが、
仕様変更に対する柔軟性を高めるために重要だけど。

593 :デフォルトの名無しさん:2013/11/23(土) 18:28:13.79
またそれか

594 :デフォルトの名無しさん:2013/11/23(土) 18:29:36.31
>>589
再利用できない単位に分割すると、関数の作り直しで時間を食うし読みづらい

595 :デフォルトの名無しさん:2013/11/23(土) 18:30:00.56
一人対多数になって、誰も賛同者がいないのに勝利宣言するというのが一番寂しい。

596 :デフォルトの名無しさん:2013/11/23(土) 18:30:42.15
>>591
意味ないわけないでしょ。
自分の実装を確かめる手段を構築するんだよ。
その手段が外部に要求されてないなら公開する必要がないだけ。
おまえは良くわからないから全体が動けばいいやと言ってるわけだが
関数全体のテストはすべて周りが用意してくれるのか?
そのレベルだったら1000行にならないだろ。

597 :デフォルトの名無しさん:2013/11/23(土) 18:31:36.87
>>592
最初から再利用できる関数は対象になってないんだよ。何回同じ話繰り返すんだ。

598 :デフォルトの名無しさん:2013/11/23(土) 18:31:44.29
>>594
>>537

599 :デフォルトの名無しさん:2013/11/23(土) 18:33:09.33
>>590
http://www.atmarkit.co.jp/ait/articles/0909/14/news103.html
Webアプリケーション開発においては、
単体テストで関数やクラスメソッドをテストし、
結合テストでWebブラウザからの操作をテストするのが一般的です。
前者の単体テストをユニットテストと呼び

600 :デフォルトの名無しさん:2013/11/23(土) 18:35:16.80
>>597
最初から再利用できない関数がその後仕様変更で変わるという話なんだけど。

601 :デフォルトの名無しさん:2013/11/23(土) 18:37:08.72
要はテスト面倒だから関数分けたくない。
大きい関数でもテストの妥当性なんて誰もチェックしてないし。
ってことか。

602 :デフォルトの名無しさん:2013/11/23(土) 18:38:39.15
>>598
2chの行数の都合上一行にたたんではいるが、関数への移動の手間と、呼び出し元呼び出し先の変更の手間が掛る。ダウト。
int a;
{ int b= a }

int a;
{ int c; { int b=a +c; } }

int function(int a) { int b = a; return b; }
int a;
function( a );

int function(int a, int c){ int b = a + c; return b; }
int a,c;
function( a, c)

603 :デフォルトの名無しさん:2013/11/23(土) 18:39:45.43
>>599
oracleとatmarkどっちが正しいんでしょうねぇ

604 :デフォルトの名無しさん:2013/11/23(土) 18:40:54.24
>>601
ブラックボックステストはしてますしお寿司

605 :デフォルトの名無しさん:2013/11/23(土) 18:42:56.27
>>601

ホワイトボックス・テストを書かない
ユニット・テストでは、クラスがどのように実装されるかではなく、クラスが何
を行うかに重点を置く必要があります。クラスのホワイトボックス・テストは、
privateおよびprotectedメソッドもすべてテストすることになり、それによる実装
の変更によって、テストも変更が必要になる可能性が高くなります。したがって、
既存のテストを使用して何も破損しなかったことを実証する場合、ホワイトボッ
クス・テストは効果的なリファクタの妨げになります。同様に、インタフェース
の実装クラスではなく、インタフェースに対してテストを記述することをお薦め
します。

606 :デフォルトの名無しさん:2013/11/23(土) 18:44:00.57
>>602
行数変わってねえじゃん

607 :デフォルトの名無しさん:2013/11/23(土) 18:45:47.40
>>602
何が言いたいのか理解すんのが難しいw。
関数移動なんて普通のエディタやIDEじゃワンクリックワンキーだし、
呼び出し元は元の修正分と考えれば修正先の引数が変更になるだけじゃん。
で他の修正は等しく修正だからやっぱ一行。
まあ書き方によっては数行差が出るかもしれないが、
数100行の変更のなかで機械的な変更なんて誤差にもならないし
関数化されてスコープが狭くなってるメリットのほうが大きいよ。

608 :デフォルトの名無しさん:2013/11/23(土) 18:47:03.69
例えばトレースをするときに、ステップインするかステップオーバーするか選べるだろ?
何回かステップインして、ここはもう絶対問題ないと確定した関数はもうステップオーバーするだろ?
こうして問題ないところをどんどん除外していくと、トレースが加速して楽になって行くだろ?
関数をブレイクダウンしないと、こうやってテストの範囲を絞っていけないだろ。

609 :デフォルトの名無しさん:2013/11/23(土) 18:48:25.52
デバックしなければ解決

610 :デフォルトの名無しさん:2013/11/23(土) 18:49:15.83
>>608
ブロックこえたところにブレークポイント置くのは手間じゃないんだって

611 :デフォルトの名無しさん:2013/11/23(土) 18:49:31.18
>>606
行数じゃなく手間だよ

612 :デフォルトの名無しさん:2013/11/23(土) 18:50:28.21
>>597
再利用できない関数ってなんだ?

そもそもそれがおかしいだろ。

関数=再利用できる
再利用できない=関数ではない。

613 :デフォルトの名無しさん:2013/11/23(土) 18:50:51.43
>>607
関数移動しないでいいならそれが一番だろ
そう書いたら0か1かしか言えない上に鶏頭だから関数使うなとか言い出すんだろうな

614 :デフォルトの名無しさん:2013/11/23(土) 18:50:53.29
>>602
これが手間と思えるくらいのIDEとエディタの使い方なんだよ
デバッグも推して知るべし

615 :デフォルトの名無しさん:2013/11/23(土) 18:51:02.60
>>464
> メソッドにprivateなんて要らんけどな。
> それこそOOが出来てない。

privateメソッドがあればOO出来ていないとは??

616 :デフォルトの名無しさん:2013/11/23(土) 18:51:28.96
関数にすることで、ブラックボックステストがしやすくなるよな。

617 :デフォルトの名無しさん:2013/11/23(土) 18:51:56.23
>>612
>>518

618 :デフォルトの名無しさん:2013/11/23(土) 18:52:42.34
>>613
つまりキミはワンクリックの手間がおしいくらい
スコープ・関数のメリットが感じられないわけだね
もし仕事してるとしたら同僚に同情するわ

619 :デフォルトの名無しさん:2013/11/23(土) 18:53:07.20
>>605
> ユニット・テストでは、クラスがどのように実装されるかではなく、クラスが何
> を行うかに重点を置く必要があります。クラスのホワイトボックス・テストは、
> privateおよびprotectedメソッドもすべてテストすることになり、それによる実装


え?

ブラックボックステストっていつから
パブリックメソッドのテストになったんだ?

っていうかそれならなおさらパブリック関数にした方がいいな。

620 :デフォルトの名無しさん:2013/11/23(土) 18:53:14.41
>>614
IDEのマーカー機能とか折りたたみ機能使えないお前に言われたくない

621 :デフォルトの名無しさん:2013/11/23(土) 18:53:39.65
>>617
ワロタw

>>518が馬鹿ってだけじゃないかw

622 :デフォルトの名無しさん:2013/11/23(土) 18:54:32.82
まず、関数ってのは再利用できるもの。

実際に一回しか使うか使わないかは関係ない。

再利用可能なものが関数。

そうでないものは関数に似た別のものだ。

623 :デフォルトの名無しさん:2013/11/23(土) 18:54:51.86
>>618
マーカーつけたブロックに飛ぶんなら構わないんだどねぇ。

624 :デフォルトの名無しさん:2013/11/23(土) 18:55:56.90
>>464
> メソッドにprivateなんて要らんけどな。
> それこそOOが出来てない。

privateメソッドがあればOO出来ていないとは??

625 :デフォルトの名無しさん:2013/11/23(土) 18:56:05.72
関数にしたものは、引数は基本的に変わらないものなんだよね。

だから引数が変わったらーとかいってるのは
根本的におかしい。

それは正しく関数化出来なかっただけだから。

で、なんでこれが一回しか使わない関数の話になるの?

626 :デフォルトの名無しさん:2013/11/23(土) 18:56:21.52
>>622
>そうでないものは関数に似た別のものだ。
それを書くなって話だろ終わりじゃん

627 :デフォルトの名無しさん:2013/11/23(土) 18:56:51.86
なんのためにprivateメソッド作るの?

一回しかつかわないもの=privateメソッドじゃないよね。

628 :デフォルトの名無しさん:2013/11/23(土) 18:57:28.68
>>619
お前はどんなテストをする気なんだ?

629 :デフォルトの名無しさん:2013/11/23(土) 18:58:07.69
ちょっと見えた。
何で関数移動が手間だと思うのか。

今時普通は1クラス1ファイルで、1ファイルの行数自体が平均100行くらいだろ?
単一責任がよいクラスとされているし。
たまに300行くらいの大きいのもできるけど、50行以下のも多い。
ソースファイル全体が2〜3ページで収まるし、ファイル全体が1画面に収まることも珍しくない。
こうした中での関数分割や移動は全く苦にならない。

でもコマルデ君はきっと1ファイルに1000行とか平気で書いてる。そりゃ関数分割するとどこにあるのかわからなくもなる。
オブジェクト指向が身についてないか、オブジェクト指向言語を使っていたとしても、
メソッドが何十個もあったりとか、そういう状況なんじゃないかな。

まずはデザインパターンとか、最近の設計のトレンドを勉強したほうがいいと思う。

630 :デフォルトの名無しさん:2013/11/23(土) 18:58:16.05
>>626
> それを書くなって話だろ終わりじゃん

うん。だから1回しか使わない "関数" はありなわけだよ。

だって、関数である以上1回しか使わなくても
再利用可能なわけだから。

631 :デフォルトの名無しさん:2013/11/23(土) 18:58:27.15
>>627
OOできてない、の部分を知りたいんだが。なぜなのかと。

632 :デフォルトの名無しさん:2013/11/23(土) 19:00:19.90
private関数なんてあんのはC++系統と.net framework系ぐらいだよなぁ
しかもC++にprivate関数が作れるのは、構文解析を高速にするため
関数と変数の区別をしないて理由以外に特に理由はないし

633 :デフォルトの名無しさん:2013/11/23(土) 19:00:41.27
privateメソッドはテストできない(テストしない)のだから
関数にする理由ないよね?

634 :デフォルトの名無しさん:2013/11/23(土) 19:01:54.06
>>630

>>469に戻ると。ループザループ

635 :デフォルトの名無しさん:2013/11/23(土) 19:02:20.76
いやだから、>>464さんはもうここにいないのかな?
privateメソッドがあって、なぜOOできてないという結論に達するのか。
その課程が知りたい。

636 :デフォルトの名無しさん:2013/11/23(土) 19:02:24.82
最初は一度しか呼ばない関数はどうたらって言ってなかったっけ。
主張変わったのか。こっそり撤退の道を探っているのか。

637 :デフォルトの名無しさん:2013/11/23(土) 19:02:28.66
>private関数なんてあんのはC++系統と.net framework系ぐらいだよなぁ

ほとんどってことじゃないかw

638 :デフォルトの名無しさん:2013/11/23(土) 19:03:34.64
>>633
そもそもprivate関数がいらんだろあんなもん
Python, Ruby, Go, Pharo, javascript・・・
Smalltalk系統の言語にゃないしC++の負の遺産だ

639 :デフォルトの名無しさん:2013/11/23(土) 19:04:44.70
こっそりGoを混ぜるあたりがw

640 :デフォルトの名無しさん:2013/11/23(土) 19:04:55.12
>>636
>>469

641 :デフォルトの名無しさん:2013/11/23(土) 19:06:01.37
haskeller大激怒スレ

642 :デフォルトの名無しさん:2013/11/23(土) 19:06:03.67
private メソッドとOOPってなんか関係あんの?

643 :デフォルトの名無しさん:2013/11/23(土) 19:06:08.41
再利用性という尺度で評価できるんだよ。
それを問題にすべきだったんじゃないの?

作った関数がすべて同じだけ使われることはない。ムラがある。
その、再利用性の低い糞関数を問題にすべきだったんじゃないかな。

644 :デフォルトの名無しさん:2013/11/23(土) 19:07:17.30
いや関数化によるメリットは再利用性以外にもさんざん指摘されてるんだが

645 :デフォルトの名無しさん:2013/11/23(土) 19:07:28.62
>>642おれもそれが謎。>>464さん曰く、

> メソッドにprivateなんて要らんけどな。
> それこそOOが出来てない。

らしいが。

646 :デフォルトの名無しさん:2013/11/23(土) 19:07:40.57
そういやLispもGObjectもprivateメソッドなんてないな

647 :デフォルトの名無しさん:2013/11/23(土) 19:07:53.97
ある程度長くてそのクラス内では何度も使う処理だけど、他のクラスからは無価値なメソッドとかはどうするの?

648 :デフォルトの名無しさん:2013/11/23(土) 19:08:19.51
関数として名前つけるだけでも意味あるぞ。でないとブロックの説明コメントをグダグダ書くことになる。

649 :デフォルトの名無しさん:2013/11/23(土) 19:08:44.94
>>632
> private関数なんてあんのはC++系統と.net framework系ぐらいだよなぁ

Ruby にもある
PHP にもある
VB.NETにもある

JavaScript には将来classの導入とともにprivateが検討されている。
http://wiki.ecmascript.org/doku.php?id=harmony:classes

Python にはないが__をつけることでprivateだとすると公式に書いてある。
http://docs.python.jp/2/tutorial/classes.html#tut-private

お前が知らんだけだよ。

650 :デフォルトの名無しさん:2013/11/23(土) 19:09:10.23
>>643
>>469

651 :デフォルトの名無しさん:2013/11/23(土) 19:09:18.35
GObject支持派のOO信者珍しすぎるw

652 :デフォルトの名無しさん:2013/11/23(土) 19:09:43.24
>>648
その場合、関数名がグダグダになるという現象に悩まされるんだが。
それは俺が超絶愚か者だからかな?

653 :デフォルトの名無しさん:2013/11/23(土) 19:10:14.29
>>647
ブロックオブジェクトあるいは無名名前空間に定義

654 :デフォルトの名無しさん:2013/11/23(土) 19:10:15.85
actionscriptも3になってprivate付class導入してなかったか?

655 :デフォルトの名無しさん:2013/11/23(土) 19:11:05.61
>>469って馬鹿だな。
言っていることが的はずれすぎる。

656 :デフォルトの名無しさん:2013/11/23(土) 19:11:26.92
>>652
コメントが打てるなら関数名つくだろ
つまり・・・

657 :デフォルトの名無しさん:2013/11/23(土) 19:11:44.31
>>648
関数として名前つけられて、#pragma markみたいなブロックマーカーには何故名前を付けられないのか?

658 :デフォルトの名無しさん:2013/11/23(土) 19:11:48.02
>>469
>コールバックではなく
>かつ
>プロトコルで要求されていない
>かつ
>再利用される予定もなく
>かつ
>一度しか呼ばれない関数は読みづらいだけ

>>630
>うん。だから1回しか使わない "関数" はありなわけだよ。
>
>だって、関数である以上1回しか使わなくても
>再利用可能なわけだから。

あれ? どうなってんの?
一度しか呼ばない関数は読みづらいけどありなの?

659 :デフォルトの名無しさん:2013/11/23(土) 19:12:43.55
>>657
ブロックと関数ではスコープの扱いが違うから

660 :デフォルトの名無しさん:2013/11/23(土) 19:13:32.44
>>658
必要悪だろ
switch使うよりオブジェクトの多態の方がいいけど
絶対switch使わないのか?

661 :デフォルトの名無しさん:2013/11/23(土) 19:13:50.84
> 469 名前:デフォルトの名無しさん[sage] 投稿日:2013/11/23(土) 16:33:41.28
> じゃあ最初の定義を訂正すればいいわけだな。
> 申し訳ありませんでした。
>
> コールバックではなく
> かつ
> プロトコルで要求されていない
> かつ
> 再利用される予定もなく
> かつ
> 一度しか呼ばれない関数は読みづらいだけ

ようするに、

駄目なやつが書いた関数は読みづらいだけ

一度しか呼ばれていても、
コールバックだったり、プロトコルで要求されていたり
再利用されれる予定があったり、するものは読みづらいとは限らないと

自分でそう言っているのだから、この話は終わりじゃね?

662 :デフォルトの名無しさん:2013/11/23(土) 19:14:10.59
「privateメソッド」と「OOP出来てない」の関連だけでもはっきりしてから今日は眠りたいんだがw

663 :デフォルトの名無しさん:2013/11/23(土) 19:17:14.10
>>659
それで >>386-387 ここに戻るわけだ

>>469 に戻り
>>386-387 に来て
また>>469に戻る
以下無限ループ

664 :片山博文MZコスモ ◆T6xkBnTXz7B0 :2013/11/23(土) 19:19:09.02
XScreenSaverの168個のスクリーンセーバーをWindowsに移植したよ。
http://katahiromz.web.fc2.com/xscreensaverwin/
https://github.com/katahiromz/XScreenSaverWin
迷路もあるよ!

665 :デフォルトの名無しさん:2013/11/23(土) 19:19:40.91
>>663
それで >>386-387にもどるのなら>>618
と言ってるから無限ループにしているのはお前

666 :デフォルトの名無しさん:2013/11/23(土) 19:20:07.20
>>662
OOの考えならprivateメソッドにするぐらいなら、別のオブジェクトに委譲する。
privateメソッド呼び出してんならCで関数呼んでるのと同じ。OOPができていない。
以上。
満足か?

667 :デフォルトの名無しさん:2013/11/23(土) 19:20:16.28
ブロックだとその関数内の変数全てにアクセスできてしまう。
情報隠蔽、疎結合、副作用などの観点から良くない。

668 :デフォルトの名無しさん:2013/11/23(土) 19:21:39.66
プログラムを上から下にしか読めないやつにとっては、一度しか呼ばれない関数は読みづらいだけ。
そういうやつにはBASICが向いていると思う。

669 :652:2013/11/23(土) 19:22:48.00
結局、俺が言った点でもってみんな同意できるんじゃないの?
メリットデメリット踏まえたうえで、名前グダグダの関数名を作っちゃうべきかどうか。

それとも、プロの人は名前グダグダになんて一切ならないのかな?
それともAaaBbbCcccDdFffGGGudaguda(Foo foo, Bar bar, Buz buz)みたいな関数に問題は無いと?

670 :デフォルトの名無しさん:2013/11/23(土) 19:22:53.96
>>667
{
 int a;
 {
  int b;
  a;//○
  c;//×
 }
 int c;
 {
  b;//×
  c;//○
 }
}
{
 a;//×
}

671 :デフォルトの名無しさん:2013/11/23(土) 19:24:14.67
privateメソッドの機能を委譲すると言うことは
private変数いじれる内部関数がないからおかしくないか?

672 :デフォルトの名無しさん:2013/11/23(土) 19:24:51.79
>>659
それで >>386-387 ここに戻るわけだ

>>469 に戻り
>>386-387 に来て
また>>469に戻る
そして>>661で終わり

673 :デフォルトの名無しさん:2013/11/23(土) 19:25:15.19
APIなどには、そのアプリケーション内で一度どころか一度も呼ばれない関数もあるわけだが。

674 :デフォルトの名無しさん:2013/11/23(土) 19:25:49.18
>>669
>>661

終わった話。馬鹿な奴が書いたらだめになる当たり前のことで
それ以外の要件は何一つない。

675 :デフォルトの名無しさん:2013/11/23(土) 19:27:29.55
そう。この話は終わったんだよ。

関数はあるべき形に作ればいいってだけで、
そんな一回しか使わないものはだめみたいな
簡単なルールはない。

676 :デフォルトの名無しさん:2013/11/23(土) 19:27:40.13
グダグダな関数名でもうそがなければ関数スコープある分まし
うそがあるならfoobarつけとけ

677 :デフォルトの名無しさん:2013/11/23(土) 19:28:21.85
>>675
関数のあるべき形に
2回以上使っていなければだめ。

という要件はないってことだね。

678 :デフォルトの名無しさん:2013/11/23(土) 19:28:50.50
http://www.slideshare.net/MoriharuOhzu/ss-14083300

Jeff Beyのクラス設計を綺麗にするトレーニング。
いいコードを書くイメージを付けるトレーニングなので、
実際の業務ではもっと緩くていいけど、
ここでも関数のサイズを厳しく制限する練習をさせられる。

ルール1:インデント1段階
1つのメソッドにつきインデントは1段階までにすること
ルール2:else句禁止
else句を使用しないこと
ルール3:プリミティブ禁止
すべてのプリミティブ型と文字列型をラップすること
ルール4:ドット1つ
1行につきドットは1つまでにすること
ルール5:名前省略禁止
名前を省略しないこと
ルール6:小エンティティ
すべてのエンティティを小さくすること
ルール7:インスタンス変数2つ
1つのクラスにつきインスタンス変数は2つまでにすること
ルール8:ファーストクラスコレクション
ファーストクラスコレクションを使用すること
ルール9:プロパティ禁止
Getter/Setter/プロパティを使用しないこと

クラスの単純化を突き詰めると今度はオブジェクト間の連携が難しくなってくるので、
そのあとはデザインパターンを学ぶといい。

679 :デフォルトの名無しさん:2013/11/23(土) 19:29:16.72
>>674
そうかな?
ブロックの説明がグダグダになる場合、
それを関数名に置き換えたらスッキリするとでも?

もしそうだというのなら、俺はコレに関して本当に黙るw
そして滝に打たれてゼロからやり直してくる。

680 :デフォルトの名無しさん:2013/11/23(土) 19:29:56.80
>>678
重要な行を忘れてるぞw

断言する。これらのルールを破らずに1000行のプロジェクト書いたものはOOがうまくなる。

よって望めば制限を和らげることも出来るようになる。でも作者が指摘するのはそうする理由はないということ。

彼のチームはちょうど100,000行のプロジェクトをこの制限のうちに終えたところなんだ。

681 :デフォルトの名無しさん:2013/11/23(土) 19:32:01.90
関数化しとくとこの関数内ではこの変数しか使われてませんよということが明示できる。
C#のように引数の入出力が明示できればなおよい。
そうすると別人が後から追加拡張修正するときにこの関数内には引数にない変数zを使う処理は書き加えてはいけない
だから別のところに書こうというヒントがあたえられる。

682 :デフォルトの名無しさん:2013/11/23(土) 19:32:41.66
>>679
>>>674
>そうかな?
>ブロックの説明がグダグダになる場合、
>それを関数名に置き換えたらスッキリするとでも?

どう考えてもスッキリする。
即答だわw

683 :デフォルトの名無しさん:2013/11/23(土) 19:32:57.95
>>678
さすがに詐欺としか思えないけど

>ルール2:else句禁止
これはなぜ?
>ルール4:ドット1つ
これすごくない?
>ルール7:インスタンス変数2つ
階層深くならない?

684 :デフォルトの名無しさん:2013/11/23(土) 19:37:47.25
>>671
そもそもprivateメソッドなんて何に使ってんの?

685 :デフォルトの名無しさん:2013/11/23(土) 19:38:56.10
>>673
>>469
しつこい

686 :デフォルトの名無しさん:2013/11/23(土) 19:40:19.28
>>676
>>670
ブロックはスコープ付けるためのもんやで
これに#pragma markとかIDEの機能使えば名前も付けられるんやで

687 :デフォルトの名無しさん:2013/11/23(土) 19:41:39.77
つまりお前はすべてpublicで書けると言いたいだけですね
3000行ないとかけない処理があったとき
その3000行すべてに渡ってprivate変数をアクセスしようとすれば
そのpublic関数が3000で書かれるか、
public関数を分割して順番に呼んでくださいとコメントに書くのですね。
じゃなければうまく委譲するようにクラスデザインをあーだこーだやるわけですね。

688 :デフォルトの名無しさん:2013/11/23(土) 19:42:30.64
>>686
お前が理解してないのかわざとなのかわからんが
何度も指摘されているように一般的な言語では
ブロックは外のブロックが参照可能。

689 :デフォルトの名無しさん:2013/11/23(土) 19:42:40.82
>>680
1000行のプロジェクトだと複数呼ばない関数書くと余計行数増えるんじゃ・・・

690 :デフォルトの名無しさん:2013/11/23(土) 19:43:27.06
>>683

>>ルール2:else句禁止
>これはなぜ?

×if (i==x) { a=x; } else { a=i; }
⚪︎a=i; if (i==x) { a=x; }
こうしろってことだね。
俺は好きではないけど、昔からよく言われてるよ。

>>ルール4:ドット1つ
>これすごくない?
これはクラスの責任範囲を考える、
つまり言い換えれば疎結合を徹底しろってことだね。
実際のプロジェクトではそこまでやらなくてもいいと思うけど、
汎用性を高めたいとき、重くなった責任を軽くしたいときに
ドット数が減るように直すことはよくあるはず。

>>ルール7:インスタンス変数2つ
>階層深くならない?

深くなると思う。これもなかなか守れそうにない。
でもインスタンス変数が少ない=クラスの責任範囲が絞られている、
というのは理解できる。

691 :デフォルトの名無しさん:2013/11/23(土) 19:43:39.03
関数の細分化も、クラスの細分化も、
結局は名前が付けにくい単位に突き当たる。
当たらないという人は命名の名人か、アホ。

692 :デフォルトの名無しさん:2013/11/23(土) 19:43:45.80
>>688
>>670 を理解してるのか?

693 :デフォルトの名無しさん:2013/11/23(土) 19:44:04.37
クラス委譲による記述場所の分散は良くて
メンバ関数による記述場所の分散はダメって理屈がわからん

694 :デフォルトの名無しさん:2013/11/23(土) 19:45:27.22
>>690
極限を見る練習ってワケか。
まあちょっとどうでもいいや。
サンクス

695 :デフォルトの名無しさん:2013/11/23(土) 19:45:33.47
>>693
privateメンバーがだめって話。
再利用できんだろうし、再利用できない処理の記述を促進する。

696 :デフォルトの名無しさん:2013/11/23(土) 19:46:09.39
>>670
理解できない
 a;//×
ってなに?

697 :デフォルトの名無しさん:2013/11/23(土) 19:48:06.52
>>693
privateメンバーがマトモだと思うんなら、privateメンバーが必要なコード書いたことあるんだろ、
それをココに貼ってみ綺麗な形に書き換えるから。

698 :デフォルトの名無しさん:2013/11/23(土) 19:49:39.29
>>696
そこの行のaは参照出来んだろ

699 :デフォルトの名無しさん:2013/11/23(土) 19:49:44.28
>>697
そのレスの時点でアホ
長い関数をどうやってここに貼るんだよ

700 :デフォルトの名無しさん:2013/11/23(土) 19:50:26.63
>>697
横からだがそもそもその、
privateメンバー=privateメンバ変数+privateメンバ関数
ってこと?

701 :デフォルトの名無しさん:2013/11/23(土) 19:50:54.85
>>691
向いてないな

702 :デフォルトの名無しさん:2013/11/23(土) 19:52:50.60
>>698
#include <stdio.h>
int main()
{
int a = 1;
{
printf("%d\n",a);
}
return 0;
}

で結果が1っでことであってる?

703 :デフォルトの名無しさん:2013/11/23(土) 19:54:16.83
>>679
>>661

704 :デフォルトの名無しさん:2013/11/23(土) 19:54:49.07
>>685
お前こそしつこい



674 名前:デフォルトの名無しさん[sage] 投稿日:2013/11/23(土) 19:25:49.18
>>669
>>661

終わった話。馬鹿な奴が書いたらだめになる当たり前のことで
それ以外の要件は何一つない。

705 :デフォルトの名無しさん:2013/11/23(土) 19:54:53.76
>>699
ム板に来るのは初めてか?ここに貼れよ
ideone.com

>> 700
private関数限定の話

706 :デフォルトの名無しさん:2013/11/23(土) 19:56:55.36
>>702
#include <iostream>
int main()
{
 {
  int a = 1;
 }
 {
  std::cerr << a << std::endl;
 }
 return 0;
}

707 :デフォルトの名無しさん:2013/11/23(土) 19:58:07.38
>>678 2つだけは完全に間違っている。

ルール7:インスタンス変数2つ
いくらなんでも子供は2人までというくらい理不尽である

ルール9:プロパティ禁止
Getter/Setter/プロパティを使用しないこと
いやいやいやいや必要に応じて使用するのが正しい。

708 :702:2013/11/23(土) 19:58:42.64
ああわかった気が。
論点は>>702のaが見えてしまうのは関数より制限がゆるいというのであって
#include <stdio.h>
int main()
{
{
int a = 1;
}
{
printf("%d\n",a);
}
return 0;
}
が見えないことではない。

709 :デフォルトの名無しさん:2013/11/23(土) 19:59:25.90
privateメンバー関数が必要な例はマダー

710 :デフォルトの名無しさん:2013/11/23(土) 20:02:28.32
>>707
まぁPropertiyパターンはあんまり使うべきじゃないな
WikipediaのSmalltalkの記事みてみりゃ面白い

711 :デフォルトの名無しさん:2013/11/23(土) 20:07:50.52
>>708
関数でもグローバル変数使えば外の変数は見えるわけで、
どっちかというと、なんども呼び出せないブロックのほうが制限は強いんだがな。

712 :デフォルトの名無しさん:2013/11/23(土) 20:09:36.07
>>709じゃあとりあえずこれ
http://code.google.com/p/box2d/source/browse/trunk/Box2D/Box2D/Dynamics/b2Body.h

713 :デフォルトの名無しさん:2013/11/23(土) 20:10:55.89
>>711
変数にアクセスする制限は関数のほうが強いでしょ
関数を呼び出されて問題になるケースは何?

714 :デフォルトの名無しさん:2013/11/23(土) 20:15:38.10
>>709
先生、必要な例かどうかはわかりませんが、javaのクラスライブラリ、Stringクラスの例です。

/* Common private utility method used to bounds check the byte array
* and requested offset & length values used by the String(byte[],..)
* constructors.
*/
private static void checkBounds(byte[] bytes, int offset, int length) {
if (length < 0)
throw new StringIndexOutOfBoundsException(length);
if (offset < 0)
throw new StringIndexOutOfBoundsException(offset);
if (offset > bytes.length - length)
throw new StringIndexOutOfBoundsException(offset + length);
}

このチェックは、
public String(byte ascii[], int hibyte, int offset, int count)
public String(byte bytes[], int offset, int length, String charsetName)
public String(byte bytes[], int offset, int length)
から呼ばれているようです。

715 :デフォルトの名無しさん:2013/11/23(土) 20:15:57.53
>709
NonCopyable作る時

716 :デフォルトの名無しさん:2013/11/23(土) 20:17:42.14
俗人にはもっとわかりやすく説明した方がいい

旅館の全ての部屋にカギがついてなかったら防犯上よくないだろ。

717 :デフォルトの名無しさん:2013/11/23(土) 20:19:00.83
>>713
関数の呼び出し元で操作している対象の変数が何かわからない(広域変数の欠点)

int a, b, c ; // グローバル変数宣言
int main (int argc, char *argv [])
{
 FunctionA(); // グローバル変数cを書き換える
 FunctionB(); // グローバル変数cを元にグローバル変数aを書き換える
 FunctionC(); // グローバル変数a, cを元にグローバル変数bを書き換える
 return 0;
}

718 :デフォルトの名無しさん:2013/11/23(土) 20:21:20.92
>>717
判ってると思うけどそれグローバル変数の問題で
スコープでも問題は変わらない

719 :デフォルトの名無しさん:2013/11/23(土) 20:22:22.60
>>715
それはしょうがないな

>>714
普通に考えて、
StringBounds.check( byte[] bytes, int offset, int length );
に委譲すりゃいいわな
Javaのライブラリーって他のライブラリーに比べて出来が悪いわ

720 :デフォルトの名無しさん:2013/11/23(土) 20:24:40.79
一発降参ワロタw

721 :デフォルトの名無しさん:2013/11/23(土) 20:24:59.67
>>719
StringBoundsが含まれているパッケージを探すコストを考えたら、近くで定義した方がいい場合も多々ある。

722 :デフォルトの名無しさん:2013/11/23(土) 20:25:07.57
>>718
どういうことか解かりませんっ!!

723 :デフォルトの名無しさん:2013/11/23(土) 20:26:17.16
>>712 他人のコード晒してんじゃねぇぞタコ

724 :デフォルトの名無しさん:2013/11/23(土) 20:27:29.62
>>721
Javaは同じファイル内に複数クラス書けるから
同じファイルに書いときゃいい

725 :デフォルトの名無しさん:2013/11/23(土) 20:27:57.13
>>722
まじか・・・
ブロックで書こうが外部関数の呼び出し無しではないわけで
(まさかこれ否定しないよね)
その関数がグローバルを使っていてかつ、自分が直に書いたブロックにも
グローバル変数があるのなら同じ問題がおきるってこと

726 :デフォルトの名無しさん:2013/11/23(土) 20:28:01.06
>>719
公開する必要はないでしょ
そんなのでいちいち実装が変更されない保証とかしてらんない

727 :デフォルトの名無しさん:2013/11/23(土) 20:28:46.84
>>723
有名なBSDライセンスのオープンソースですが

728 :デフォルトの名無しさん:2013/11/23(土) 20:30:24.49
private int min(int x,int y){return x<y?x:y;}
が何故Mathに定義されてないのか考えたけどこいつばかりは毎度再定義した方が実行効率がよいようだ。

729 :デフォルトの名無しさん:2013/11/23(土) 20:30:57.92
>>725
int main (int argc, char *argv [])
{
 int a, b, c ; // グローバル変数宣言
 FunctionA(); // グローバル変数cを書き換える
 FunctionB(); // グローバル変数cを元にグローバル変数aを書き換える
 FunctionC(); // グローバル変数a, cを元にグローバル変数bを書き換える
 return 0;
}
こんなんしたらコンパイルエラーやで

730 :デフォルトの名無しさん:2013/11/23(土) 20:32:29.73
>>728
そしてCollections.minしか使わない現実

731 :デフォルトの名無しさん:2013/11/23(土) 20:32:29.92
だれか>>729を翻訳してください

732 :デフォルトの名無しさん:2013/11/23(土) 20:33:37.71
>>726
他の言語とおなじく仕様としてドキュメントに書かなきゃいいでしょ
あとどうでもいいけどclassをpublicにしなきゃJavaの場合公開にはならないぞ

733 :デフォルトの名無しさん:2013/11/23(土) 20:34:52.27
ああ本末転倒w

734 :デフォルトの名無しさん:2013/11/23(土) 20:36:06.86
>>728
今のVMじゃ大したコストにならんだろうに

735 :デフォルトの名無しさん:2013/11/23(土) 20:39:26.98
>>732
意味がわかりかねる。
privateスコープで公開メソッドのみのローカルクラスを用意するって意味?

736 :デフォルトの名無しさん:2013/11/23(土) 20:43:54.56
>>735
まさか、こんな感じで宣言できるの知らないのか?
// string.java
class StringBounds
{
}
public class String
{
}

737 :デフォルトの名無しさん:2013/11/23(土) 20:45:39.55
あれ?private君は関数切り出し反対派じゃなかったっけ?
委譲で切り出すのは問題ないんだ?

738 :デフォルトの名無しさん:2013/11/23(土) 20:45:43.32
>>734
普通に遅い
どうせ中身はJNI委譲してるだけだからネイティブかVMで直接計算したほうが速い

739 :デフォルトの名無しさん:2013/11/23(土) 20:46:54.10
>>736
あの、言ってること理解出来てる?

740 :デフォルトの名無しさん:2013/11/23(土) 20:51:58.18
>>739
>>735はこういうこと言いたかったんじゃないの?
public class String
{
 private class StringBounds
 {
 }
}

741 :デフォルトの名無しさん:2013/11/23(土) 20:57:49.29
>>740
staticならあってる
パッケージプライベートじゃString以外で使えちゃうでしょ
だから実装を保証する必要があるよね?

742 :デフォルトの名無しさん:2013/11/23(土) 20:59:49.66
他の言語同様パッケージ外で使わなきゃいいだけの話だし

743 :デフォルトの名無しさん:2013/11/23(土) 21:03:13.45
>>742
だから少なくとも同じ名前空間では同意が得られないとだめだろと
これでは意味が違う
必要と言うまでは反論するぞ

744 :デフォルトの名無しさん:2013/11/23(土) 21:04:39.09
>>715で終わってるだろ。はい次。

745 :デフォルトの名無しさん:2013/11/23(土) 21:05:54.85
>>743
他の言語と同様同意を得ればいいだろ

746 :デフォルトの名無しさん:2013/11/23(土) 21:08:04.16
>>745
では結局保証が必要という事で終わり

747 :デフォルトの名無しさん:2013/11/23(土) 21:08:25.02
>>743
大体おんなじパッケージ内の他の箇所で使われたって問題ないだろ
この処理が共有されて何の問題になる
どんだけ不特定多数で同じパッケージ共有する気だよ

748 :デフォルトの名無しさん:2013/11/23(土) 21:09:50.36
>>743
必要だから同じ名前空間内で共有してんだろ

749 :デフォルトの名無しさん:2013/11/23(土) 21:10:45.94
「内部処理を細かく分けるとぼくちゃん探せないから許してよ」
って戯言でよくここまで伸ばすな

750 :デフォルトの名無しさん:2013/11/23(土) 21:11:48.96
>>743
ドキュメントに無いメソッドをパッケージ外に公開したくないだけだったら
別にprivateじゃなくていいだろ

751 :デフォルトの名無しさん:2013/11/23(土) 21:15:56.39
>>747-750
とにかくpublicにするという話が元なんだから、
後悔する必要がなくても公開するという話でしょ?
必要ならそりゃ公開するしかないでしょ

752 :デフォルトの名無しさん:2013/11/23(土) 21:18:39.51
>>751
そもそもパッケージ外ならともかく、共有できるメソッドをなんでprivateにするんだ。

753 :デフォルトの名無しさん:2013/11/23(土) 21:24:05.85
>>751
意味不明な事をかいたな。訂正。
アクセス制限をパッケージ内に限定しているにも関わらず再利用できるメソッドをなんでprivateにするんだ。

754 :デフォルトの名無しさん:2013/11/23(土) 21:30:26.01
必要ないものもpublicにしてもいいのならそもそもメンバ変数もprivateいらない

755 :デフォルトの名無しさん:2013/11/23(土) 21:33:34.48
C++のpublic,protected,private
javaのpublic,protected,private,default

どれが必要でどれが不要なのか、また新たに定義した方がいいのか
今開発中の言語に生かすので教えてくだしあ。

756 :デフォルトの名無しさん:2013/11/23(土) 21:36:49.18
>>754
メンバー変数のprivateと関数のprivateだと意味合いがだいぶ違うんだが

757 :デフォルトの名無しさん:2013/11/23(土) 21:38:29.40
>>754
メンバー変数のprivateは、メッセージ経由でアクセスを強制するために居るもの、
逆にメンバー関数側は、privateにしてもあまり意味がない。

758 :デフォルトの名無しさん:2013/11/23(土) 21:39:08.01
>>756
その認識がすでにおかしい
具体的に意味合いの違いを述べてみよ

759 :デフォルトの名無しさん:2013/11/23(土) 21:40:05.71
メンバー関数はprivateメンバの更新権利持ってるんだから重要性は変わらない

760 :デフォルトの名無しさん:2013/11/23(土) 21:42:40.39
hoge ここに変数があって

f = なんとか ここで関数を定義したときに

fの中でhogeをどうかするときに変数につける修飾子に問題があるというか
トリックみたいな書き方してお茶を濁すみたいなことあるからここらへんは新言語で一旦再編成して欲しい

761 :デフォルトの名無しさん:2013/11/23(土) 21:43:07.64
>>759
最初から外部から操作してはいけないような操作をメンバー関数にしなければいいだけの話。さらにそういう関数は、privateだろうがpublicだろうが作りが悪い。

762 :デフォルトの名無しさん:2013/11/23(土) 21:44:48.30
>>761
言語は共同作業のベースでもあるので
俺はやらないからいらないと言う理屈は通らない
話にならん

763 :デフォルトの名無しさん:2013/11/23(土) 21:49:30.30
private関数による関数分割の可読性向上は認めないけど
委譲による分割による隠蔽は認めると言うのも独善的な視点
さらにいえば委譲のほうが関数分割より設計・修正のコスト高い

ん?やっぱ他人?

764 :デフォルトの名無しさん:2013/11/23(土) 21:53:36.68
計算速度とかメモリ量とかが無限なら可能な限りカプセル化した方がいい

ただ絶対に死なないように値チェックとか各カプセル内でするようになると同じチェックを何回もするようになるから
だったらそこは外に出した方がいいんじゃないかみたいなことになる

765 :デフォルトの名無しさん:2013/11/23(土) 21:54:07.39
>>762
privateメソッドの無い他の言語ならprivateなんて使わんだろ
他の言語なら上手く行ってることがなんでC++系統の言語だけ上手くいかない
そんなわけあるか

766 :デフォルトの名無しさん:2013/11/23(土) 21:55:01.19
>>765
何を言ってるのか理解不能

767 :デフォルトの名無しさん:2013/11/23(土) 21:57:22.77
>>765
じゃあCでlinuxカーネルはうまくいってるからOOPLはいらないな

768 :デフォルトの名無しさん:2013/11/23(土) 22:02:23.89
そもそもの主張がわからないというか
publicとかで躓いてるやつ今まで見たことないんだけど

769 :デフォルトの名無しさん:2013/11/23(土) 22:07:07.88
privateメソッドの無い他の言語でも
頭にアンダーバーをつけるなどして
工夫しているから、結局いるんだろうね。

770 :デフォルトの名無しさん:2013/11/23(土) 22:13:55.52
関数の名前というのはコメントでもある。
英語圏の人だとすんなりわかるんだろうということで
日本語で関数名を書くけれど。

function 関数 {
 : 略
 : 
 // ここから、とある数値を計算するコード
 : 
 : 略
 : 
 // ここまで、とある数値を計算するコード
 : 
 : 略
}

って書くぐらいなら、コメントを関数名にして、こう書いたほうがわかりやすい。

function 関数 {
 : 略
 : 
 結果 = とある数値を計算()
 : 
 : 略
}

771 :デフォルトの名無しさん:2013/11/23(土) 22:17:31.79
つか普段C++しか使ってないけど
SmalltalkにもPythonにもRubyにもメソッドprivate機能なかったっけ?

772 :デフォルトの名無しさん:2013/11/23(土) 22:20:10.06
Obj-Cは、無い

773 :デフォルトの名無しさん:2013/11/23(土) 22:21:12.96
mmならなんでもありだけどな

774 :デフォルトの名無しさん:2013/11/23(土) 22:25:44.46
>>770

関数にすると見やすいなw

775 :デフォルトの名無しさん:2013/11/23(土) 23:08:52.68
>>770
結果がどこに入るかとかも自明になるってのがよーわかるわ

776 :デフォルトの名無しさん:2013/11/23(土) 23:12:08.79
>>767
確かにLinuxカーネルはOOPで作られてると思う

777 :デフォルトの名無しさん:2013/11/23(土) 23:18:12.86
>>707
必要に応じてというあたりが微妙だけど、
stringみたいなデータを扱うことを目的としたクラスをのぞけば、メンバ変数は作るべきじゃないのだから、間違えちゃいないだろ。

getterの類にしても、考え方っていうやつで、そんなインタフェースは、publicメンバと大差ないから必要ない。
関数は、機能や目的つくるものなのだから、
名前もそれに則した命名にしろということなんじゃないかな。

それにしても、今日ののびは、すごいな(笑

778 :デフォルトの名無しさん:2013/11/23(土) 23:21:49.26
>メンバ変数は作るべきじゃない
組み込み型もstringもインスタンスなのだが

779 :デフォルトの名無しさん:2013/11/23(土) 23:31:39.39
>>771
Smalltalkは、ある処理系にはある

780 :デフォルトの名無しさん:2013/11/23(土) 23:42:42.44
まあ、厳密に適用するとぐだるっていうジョークの類だろ
多少心がけといた方が良いってのもあるが、ルールで縛ってもしょうがねえなって程度

781 :デフォルトの名無しさん:2013/11/23(土) 23:47:35.01
メッセージ投げるタイプの言語にプライベートなメソッドってのはかなり違和感ある

782 :デフォルトの名無しさん:2013/11/23(土) 23:53:17.21
>>781
コンテキストによるよ。self に投げてる場合だけ許すとか。

783 :デフォルトの名無しさん:2013/11/24(日) 02:11:05.36
>>707
「ルール4:ドット1つ」の時点で10段入れ子になってたら、一回しか参照しない変数使って10行で表現しろって事だぞ。
そういう手合いの理不尽の塊を押し付ける事で何かしらの洗脳だか教育だかしようってルールだよコレは。

784 :デフォルトの名無しさん:2013/11/24(日) 02:56:11.89
>>781
オブジェクト間の通信=メッセージって考えなら違和感ないと思うんだけどなあ

785 :デフォルトの名無しさん:2013/11/24(日) 06:32:46.81
>>783
バカだろお前。

city.school.class.teacher.pass(document);
こういうのがあったら、
city.enroll(document);
とやって、schoolやclassの事を申請者が知らなくても済むように疎結合しろってことだ。

786 :デフォルトの名無しさん:2013/11/24(日) 09:00:35.34
それコードにすると10行どころじゃないけどな

787 :デフォルトの名無しさん:2013/11/24(日) 10:32:19.17
同じ効果を得るのに行数は短い方がいいが。
追加の効果(保守性等)を得るために行数は増やしても問題ない。
重要なのはコードの行数ではない。メンテナンス性だ。

788 :デフォルトの名無しさん:2013/11/24(日) 10:35:39.32
原理原則論は現実の前では役に立たない

789 :デフォルトの名無しさん:2013/11/24(日) 11:32:32.66
アクセサ不要ってどういう話なの?
例えばPoint2Dクラスにおいて、getX, getYは必須だと思うけど、
これはアクセサ不要論としては駄目な例に入るの?

790 :デフォルトの名無しさん:2013/11/24(日) 11:35:28.83
何もしない単なるラッパーを機械的に全部やるべきみたいなことへの批判だろう

791 :デフォルトの名無しさん:2013/11/24(日) 11:47:06.31
>Point2Dクラスにおいて、getX, getYは必須
せっかく一まとめにしてるのに、個別に取り出したら台無しじゃね。

792 :デフォルトの名無しさん:2013/11/24(日) 12:32:06.40
>>791
駄目って事でいいの?その代替は?

793 :デフォルトの名無しさん:2013/11/24(日) 12:38:13.55
どんな座標でも入るクラスならアクセサをつける意味が無い

794 :デフォルトの名無しさん:2013/11/24(日) 12:46:01.83
そもそも、構造体的クラスの存在感こそが、潜在的に問題。
その点C#は値型としてstructってを用意してる。
その割り切りは評価したい。

795 :デフォルトの名無しさん:2013/11/24(日) 12:50:09.75
>>793
メンバをそのまま公開しろってこと?

796 :デフォルトの名無しさん:2013/11/24(日) 13:37:22.47
ドット一つは、クエリ式とかもダメってこと?

797 :デフォルトの名無しさん:2013/11/24(日) 14:10:37.84
>>796
依存クラスが増加するなら駄目じゃないの

798 :デフォルトの名無しさん:2013/11/24(日) 14:15:46.08
>>793
> どんな座標でも入るクラスならアクセサをつける意味が無い

それ、逆に言えば、どんな座標でも入るわけではないのなら
意味があるってことじゃね?

ほとんどのものは、入る値に制限があると思うんだけど?

例えば、座標が数字だとして、文字列や
何かのオブジェクトは入らないわけだろう?

型で制限すればいいというかもしれんが、
世の中には型がない言語だってあるんだぞ。

君の主張では、型がない言語ではアクセサをつける意味がある
という答えになるんだが。

799 :デフォルトの名無しさん:2013/11/24(日) 14:19:50.99
普通の数値だとしても上限つけるかも知れないしな

800 :デフォルトの名無しさん:2013/11/24(日) 14:23:03.05
それはプリミティブ型みたいなのとクラス型の違いの話で
直接関係はなさそう

801 :デフォルトの名無しさん:2013/11/24(日) 14:23:47.14
ルール3:プリミティブ禁止
すべてのプリミティブ型と文字列型をラップすること
class Score{
private int score;
};

ルール9:プロパティ禁止
Getter/Setter/プロパティを使用しないこと

どうやってscoreにアクセスすんの?

802 :デフォルトの名無しさん:2013/11/24(日) 14:24:57.90
コンストラクタだろ(真顔)

803 :デフォルトの名無しさん:2013/11/24(日) 14:25:49.95
数値しか入らない所に文字列を入れたら、
入れた時にエラーになってほしいものなんだが、
型がない言語では、入れた時ではなく使う時にエラーが出るんだ。

だから型がない言語ではエラーがでたとき
どこでこの変数にこんな値が入ったんだ?って
探しまわることになる。

804 :デフォルトの名無しさん:2013/11/24(日) 14:25:55.80
>>801
外部からアクセスさせてはならないって事だろ
俺は場合によると思うが

805 :デフォルトの名無しさん:2013/11/24(日) 14:30:23.04
要するに、

obj.value = 1って書いた時に、
obj.setValue(1)が呼ばれればいいわけさ。

そしてそういう言語がある
プロパティという機能で、
public変数=プロパティのgetter/setter省略
明示的にプロパティのgetter/setterを書くこともできる。

そういう言語、俺の知る中で最古の言語は
VB6(かその前のバージョン)だな。
C#にも導入されている。

806 :デフォルトの名無しさん:2013/11/24(日) 14:41:57.26
起源ってSmalltalkじゃないのか

807 :デフォルトの名無しさん:2013/11/24(日) 15:44:01.43
それはルール9で禁止されている

808 :デフォルトの名無しさん:2013/11/24(日) 16:09:53.09
>>807
厨二病め・・

809 :デフォルトの名無しさん:2013/11/24(日) 16:16:34.86
>>806
Smalltalkやそれ系統の言語で属性(Property)と言えば、
フィールドの代わりに連想配列を使う属性パターンの事。
Javaもその影響を受けて〜Propertyというクラスが存在する。

http://ja.m.wikipedia.org/wiki/Smalltalk

810 :デフォルトの名無しさん:2013/11/24(日) 16:17:24.47
>>806
Delphi

811 :デフォルトの名無しさん:2013/11/24(日) 16:18:45.99
>>771
ねぇよ

812 :デフォルトの名無しさん:2013/11/24(日) 16:20:44.56
>>811

813 :デフォルトの名無しさん:2013/11/24(日) 16:26:20.87
>>793
accessorの意義が分かってないだろ
ド素人向けの説明で入力を制限するためなんて書いてあるが、
実際そんなことはすりゃしない。
Smalltalkなんかだと、初期化や、委譲先の抽象化が主な目的だ。
例えば、あるnameメッセージを送った時、
そのnameの値はインスタンス変数かもしれ無いし、
クラスオブジェクトの変数かもしれ無い。もしかしたら、
別のオブジェクトから取ってきた値かもしれ無いし、
GUIからの入力かもしれない。

814 :デフォルトの名無しさん:2013/11/24(日) 16:33:13.01
>>801
auto Device = Console();
result = score.Add( One );
result.StoreOn( device );

815 :デフォルトの名無しさん:2013/11/24(日) 16:35:34.74
プロパティというものは有用だ。
なぜならプロパティで簡単に実装できものを、なんでもハッシュでやろうとするハッシュバカという大馬鹿を大量生産してしまう。

816 :デフォルトの名無しさん:2013/11/24(日) 16:39:11.54
>>815
ツリーマップならハッシュマップじゃないからいいよね

817 :デフォルトの名無しさん:2013/11/24(日) 16:41:50.68
いまどきSmalltalkを持ち出すやつはもれなく基地外

818 :デフォルトの名無しさん:2013/11/24(日) 16:41:51.66
>>815
SelfやJavascriptはPropertyパターン常に使ってるがめんどいぞ

819 :デフォルトの名無しさん:2013/11/24(日) 16:45:02.70
何だかんだ、今の言語は、初期の設計方針を引きずりつつSmalltalkへ原点回帰してるからな。
結局極めて行くとSmalltalkの形に落ち着く。

820 :デフォルトの名無しさん:2013/11/24(日) 16:53:09.29
reflectionやinspection、Linq、VM、lamdba、Metaclass、
Traits、自動委譲にDuckType 。
Smalltalk時代からあったものばっかり。DuckTypeなんて
それが当たり前なのに、何でそんな大層な名前を付けられたのか
わからん。

821 :デフォルトの名無しさん:2013/11/24(日) 16:54:16.32
名前がなかったから付けられただけだろ

822 :デフォルトの名無しさん:2013/11/24(日) 16:57:29.60
あきらかにSimula系統の流れが主流なのにな

823 :デフォルトの名無しさん:2013/11/24(日) 17:10:27.75
Simulaは任天堂。
Smalltalkはセガ。

824 :デフォルトの名無しさん:2013/11/24(日) 17:22:26.26
>>821
継承依存の多態にはなんで名前がないんだ

>>822
SmalltalkもSimula系統。それを言うならC++系統だろ。
言語はC++系が流行ってても、Libraryは、Smalltalkの猿真似ばかり。
無理やり真似してるもんだから、言語仕様にまで響いて言語拡張しまくって、
C#やJavaを始め無駄な言語機能が発生し始めてる。(属性だのLinqだの)
熊にドレスを着せるのは楽しくないぞ。

825 :デフォルトの名無しさん:2013/11/24(日) 17:23:42.30
またキチガイ

826 :デフォルトの名無しさん:2013/11/24(日) 17:25:18.38
“いまどきSmalltalkを持ち出すやつは―”
とかほざく奴は、たいてい、Smalltalkの何についての言及かすら把握できていない。
Smalltalkなんてあんなシンプルな言語、他に滅多にないのにな。常識のレベルだよ。
自分の不勉強や、理解不能な事があると認めるのが怖いから拒絶しているだけ。

827 :デフォルトの名無しさん:2013/11/24(日) 17:27:12.54
教養としてのSmalltalk - Memorandum by zerobase
http://zerobase.hateblo.jp/entry/2013/02/24/015610

828 :デフォルトの名無しさん:2013/11/24(日) 17:27:55.25
>>826
またキチガイ

829 :デフォルトの名無しさん:2013/11/24(日) 17:29:17.28
JavaやC#は何でnewがmethodじゃないの?
JavaやC#は何でClassがobjectじゃないの?
C++の真似をしたせいなんだろうが、そのせいでinstance creationみたいなパターンが使えないやるならreflection使うしかない。
C++はその辺templateで克服できるだけまだましだ。
ただC++は自動委譲が未だに仕様に取り込まれないのが残念。

830 :デフォルトの名無しさん:2013/11/24(日) 17:32:04.32
ちょw ドットインストールにSmalltalk入門なんてあんのか!

831 :デフォルトの名無しさん:2013/11/24(日) 17:33:15.41
smalltalk使いは他パラダイムも認められないほど狭量なの?

832 :デフォルトの名無しさん:2013/11/24(日) 17:34:57.78
>>830
SmalltalkについてはPharo by Exampleにざっと目を通しとくだけでも違うと思うよ

ttp://www.smalltalk-users.jp/Home/docs

833 :デフォルトの名無しさん:2013/11/24(日) 17:35:37.99
Smalltalkの話が出る度に基地外だの、
終わった言語だの言っているやつは無視しとけば良い。
奴らSmalltalk自体触ったことない癖に毛嫌いし学ぶことは無いと
思ってるやからだ。朝鮮人やCOBOLerと同じ。新しい事を学ぶ気が無いやつは
相手にするだけ無駄。

834 :デフォルトの名無しさん:2013/11/24(日) 17:37:34.80
>>832
一度は実際に使ったほうがいいと思うよ。見るだけだと何でそうなってるか
想像できない所が多いから。

835 :デフォルトの名無しさん:2013/11/24(日) 17:38:09.36
>>831
そんなことはないよ。
ただ教養レベルで基本レベルのSmalltalkのことも知ったうえで
そこから議論をスタートした方が建設的だとは思っている。

836 :デフォルトの名無しさん:2013/11/24(日) 17:38:18.34
そういうこと言ってるから学ぶことはないと思われてるんじゃないの?

837 :デフォルトの名無しさん:2013/11/24(日) 17:43:56.98
Pharoは導入簡単そうだね
Squeak使った事あるけど汎用性なさすぎてマジで糞だった

838 :デフォルトの名無しさん:2013/11/24(日) 17:50:26.24
SqueakなんておもちゃSmalltalkをわざわざ選んでおいて感想が糞だとかどんな情弱かと
プロなら黙っててもVisualWorksだろ
http://smalltalk.cincom.jp/main/

839 :デフォルトの名無しさん:2013/11/24(日) 17:52:49.95
こいつアホだw

840 :デフォルトの名無しさん:2013/11/24(日) 17:54:29.03
つまり、Smalltalkをやたら排除したがるのは単なる情弱の思考停止表明?

841 :デフォルトの名無しさん:2013/11/24(日) 17:58:44.57
本当に見下すためだけで言ってるんだな

842 :デフォルトの名無しさん:2013/11/24(日) 17:59:41.02
>>840
未来有望なJava COBOLerだからそっとしといてやれ

843 :デフォルトの名無しさん:2013/11/24(日) 18:01:41.33
Smalltalkというと最近はPharoやSqueakが取り上げられがちですが、
ことビジネス用途で見た場合、VisualWorksを外すわけにはいきません。
速く、安定しており、大変リッチなクラスライブラリを誇るこの処理系は、
今も昔もSmalltalk界のエース的な存在なのです。
ttp://umejava.wordpress.com/2013/11/21/

844 :デフォルトの名無しさん:2013/11/24(日) 18:12:45.45
以上、ステマ終わり。

845 :デフォルトの名無しさん:2013/11/24(日) 18:16:53.89
PharoのGUIが気に入らなきゃ、コマンドラインで動かす手もある。

下記の様に入力すればコマンドラインでインタプリタ―風に動作する。
ただし、Windowsだとダメかも
./pharo -headless "[イメージファイル名]" eval

その他のオプションを知りたければ最後を--listに返る
./pharo -headless "[イメージファイル名]" --list

標準入出力は、下記の様にFileStreamにメッセージを送る事で得られる。
stream := FileStream stdin.
stream := FileStream stdout.
stream := FileStream stderr.

846 :デフォルトの名無しさん:2013/11/24(日) 18:18:00.56
コマンドライン起動時に動くプログラムを作る場合は、CommandLineHandlerを継承した
クラスオブジェクトを作る。
この時クラスメソッドcommandNameとインスタンスメソッドactiveを定義する。
activeには実際にしたい処理を書く。

commandNameには、イメージファイル名の次に指定する引き数の名前を返すようにする。
./pharo -headless "[イメージファイル名]" "[commandName]"

インタプリタ―の真似事がしたければselfに対して下記のようなメッセージを送る。
クラスオブジェクト内でメッセージを送る場合は途中のclassは不要。
self class evaluatorClass evaluate: 'ソースコード'.

あと最初はSystemBrowserのRefactoringメニューを一通り使っておいたほうがいいと思う。
Refactoring以外に役に立つものが多い。

847 :デフォルトの名無しさん:2013/11/24(日) 18:22:13.39
>>837
外に出てきにくくて自分の目に触れにくい技術をあえて学ぼうってときに
汎用性で排除してたら駄目だろう…

848 :デフォルトの名無しさん:2013/11/24(日) 18:23:38.21
ちなみにDLLは、こんな感じで関数をメソッドに割り当てて呼び出す事ができる。
なのでWindowsのウィンドウに描画したりやConsoleを直接操作する事も可能。
あと<>でくくられてる奴はParagraphといい他にも色々ある。

example: aStatus
  <apicall: void '関数名' (long) module: 'kernel32.dll'>
  ^ self externalCallFailed.

849 :デフォルトの名無しさん:2013/11/24(日) 18:28:27.89
GUIのデザインをどうにかしたいなと思ったら、Worldメニューの
System->Setting->Appearance->User interface theme
でOS X風にしたり、Vistaや7のAero風にしたりできるよ。

850 :デフォルトの名無しさん:2013/11/24(日) 18:32:24.58
>>844
ステマっていうか>>835に尽きるな
うざがられるくらいに引き合いに出されるのはもうわかっているんだから
みんなSmalltalkの基本的なことくらい知っておこうよと
それこそ今時の言語に比べたら笑っちゃうくらいシンプルな言語ひとつ覚えるのもおぼつかないものなのか?

851 :デフォルトの名無しさん:2013/11/24(日) 18:35:54.96
smalltalkなんて知名度のないものがうざいくらい引き合いに出されてると本気で思ってるの?
うざいくらい引き合いに出してるの間違いじゃないの?

852 :デフォルトの名無しさん:2013/11/24(日) 18:36:10.07
そういやコマンドライン実行時の終了の仕方かいてなかったな。
Smalltalk exit:0.
これで終了。

853 :デフォルトの名無しさん:2013/11/24(日) 18:37:12.56
まぁ、なんで引き合いに出されるか理解する気もないCOBOLerには一生無縁だろうよ

854 :デフォルトの名無しさん:2013/11/24(日) 18:42:48.95
Smalltalkを学ぶ上で、一番おもしろいのはデザパタだの、さも新しいものの様に
言われていたものが、最初からライブラリーで使われてるとこ。
具体的に効果的な使い方ってのがどうなってるかよく解る。
それからMorphによるMVCなGUI構築の方法もかなり勉強になる。

855 :デフォルトの名無しさん:2013/11/24(日) 18:59:01.71
Smalltalkerはキチガイ
これを証明したスレ

856 :デフォルトの名無しさん:2013/11/24(日) 19:02:19.92
smalltalkはそんなに素晴らしいのになぜ普及してないの?

857 :デフォルトの名無しさん:2013/11/24(日) 19:06:57.81
二項演算子に優先順位が無いから(適当)

858 :デフォルトの名無しさん:2013/11/24(日) 19:06:58.90
プログラムが脳内で細部まで構築済みである前提で開発を強要するからじゃね?

859 :デフォルトの名無しさん:2013/11/24(日) 19:08:08.15
Smalltalkがサイコーとかはよう言わんが、
価値はあるのに普及していない物なんていくらでもあるだろう? 子供か?
あとそのもの自体は普及していなくても、別の派生物を介して普及しているパターンも多い。

860 :デフォルトの名無しさん:2013/11/24(日) 19:09:30.69
アスペ多すぎ

861 :デフォルトの名無しさん:2013/11/24(日) 19:10:57.77
>>857
そんなのは些細な問題だし、
たとえばSqueak Smalltalkなら2〜3箇所いじれば乗除優先なんか付けられる

862 :デフォルトの名無しさん:2013/11/24(日) 19:14:27.52
>>858
それはあるかもねw

863 :デフォルトの名無しさん:2013/11/24(日) 19:15:03.71
lispでいう神の言語を真面目に言ってそうで怖い

864 :デフォルトの名無しさん:2013/11/24(日) 19:15:31.63
Smalltalkerは林檎信者と同類

865 :デフォルトの名無しさん:2013/11/24(日) 19:17:01.63
>>855
Smalltalkerはキチガイとか言ってる奴はたいていが思考停止した情弱
これを証明したスレ

866 :デフォルトの名無しさん:2013/11/24(日) 19:20:27.14
>>864
林檎信者がApple発祥とか自慢してるMacのGUIとか
OSX/iOSのオブジェクト指向APIだとかは
ほとんどSmalltalkからのパクリだから、
Smalltalkerは林檎信者よりさらにたちが悪いよ。

867 :デフォルトの名無しさん:2013/11/24(日) 19:25:27.77
>>863
いや、LISPerのあれはガチだから

868 :デフォルトの名無しさん:2013/11/24(日) 19:26:07.41
普及するかどうかはそれが優れているかどうかとあまり関係ない
未だにプログラミング初心者にCを勧める老害が滅びないのと同じように

869 :デフォルトの名無しさん:2013/11/24(日) 19:29:48.08
手続き型見せずにOOPL見せるのはどうかと思う。
そういう意味でjavascriptは優秀。

870 :デフォルトの名無しさん:2013/11/24(日) 19:30:31.50
何かのテキストが普通に一行ごとにスクロールするのを見ていたジョブズが
「これがスムーズにドットごとに紙みたいに動いたらいいんだが」と言ったときのことである。
これはキーボードに向かうインガルズにとって、ニューオーリンズのジャズバンドが
「ライムハウス・ブルース」を演奏してくれと言われたようなものである。
スモールトークのコードが数行表示されているウインドウをクリックし、
ちょっと編集してテキストウインドウに戻った。ちちんぷいぷい!
もうスクロールは連続するようになっていた。
アップルのエンジニアたちは目が飛び出るほど驚いた。普通はどんなシステムでも、
コードを書き換えればプログラムの相当な部分、多くの場合は
ほぼすべてをコンパイルし直さなければならないものである。これには数時間かかるだろう。
ところがスモールトークでは、そのオブジェクト指向のモジュール化により、
ちょっとした変更で要求される再コンパイル量は十行か十行を超えることがなく、
わずか一、二秒しかかからないのである。
「本質的に瞬間的なものでしたからね」インガルズは言う。
もちろんスモールトークの開発者の一人である彼が、
変更をほとんど本能的にできたことが役に立ったのは言うまでもない。
「ちょっとズルだったかもしれませんね」彼は認める。
「システムの頭のてっぺんから爪の先まで知ってるんだから」

871 :デフォルトの名無しさん:2013/11/24(日) 19:37:21.23
>>866
OSXのメニューバーは、Squeakのメニューバーと同じだし、
Cocoaの設計は劣化Morphicだもんな。

872 :デフォルトの名無しさん:2013/11/24(日) 19:39:04.08
Smalltalkが普及しなかったのは当時のマシンだとVMが遅くCが普及したせいだろ
結局今中心になってるのはC系言語ばっかりだもんな

873 :デフォルトの名無しさん:2013/11/24(日) 19:42:09.60
基本的にSmalltalkに暴言吐いてる奴は、PharoとかSmalltalkの事一切知らんやつで、
Smalltalk擁護してるやつは、Smalltalk他複数の言語を使ったことがあるやつ。
学習意欲の無いやつなんて相手にしないほうがいい。何の得にもならん。

874 :デフォルトの名無しさん:2013/11/24(日) 19:44:01.78
信者が排他的すぎる
ミリオタのそれと一緒

875 :デフォルトの名無しさん:2013/11/24(日) 19:45:27.00
Cと比較したらそうだろう。
Perl、Python、Rubyと比較したら?
パフォーマンス的には変わらんだろうし、
後発言語だからsmalltalkよりもハンディがあった
はずなのにsmalltalkより普及してる。

876 :デフォルトの名無しさん:2013/11/24(日) 19:46:33.41
常人が理解できる部分ではSmalltalkは十分普及しているだろう?
WIMPなGUIとかコピペとか右クリックとかMVCとかデザパタとかIDEとかアジャイルとかTraitとか

877 :デフォルトの名無しさん:2013/11/24(日) 19:48:05.66
記法がキモいから?

878 :デフォルトの名無しさん:2013/11/24(日) 19:48:15.44
>>875
> 後発言語だからsmalltalkよりもハンディがあった

後発なら、より効果的にパクれて当然じゃないの?
その発想がわからん。

879 :デフォルトの名無しさん:2013/11/24(日) 19:50:22.15
>>877
それもあるね。w 非C言語的なのが嫌われた。
だけど必要とあればObjective-Cとか文句いわれつつ普及しているしなぁ…
やっぱり流行り廃りは時の運だよ

880 :デフォルトの名無しさん:2013/11/24(日) 19:51:15.61
後発言語だからユーザー数が少なくエバンジェリストもリファレンスとなるコードも少なかったというハンデ。

881 :デフォルトの名無しさん:2013/11/24(日) 19:56:17.89
>>847
扱いにくい事まで肯定したら駄目だろ
馬鹿か

882 :デフォルトの名無しさん:2013/11/24(日) 19:56:19.55
smalltalkが普及しなかったのは髭が足りなかったから

883 :デフォルトの名無しさん:2013/11/24(日) 19:59:10.04
>>881
ごめん。「汎用性」に「扱いにくい」という意味があるとは知らなかった。
馬鹿か

884 :デフォルトの名無しさん:2013/11/24(日) 20:00:53.94
smalltalkが普及しないのは機能の起源を主張するのに忙しいから

885 :デフォルトの名無しさん:2013/11/24(日) 20:01:17.38
きっと「>>837の扱いやすさ」=「>>837にとっての汎用性」なんだろうな。
お花畑か

886 :デフォルトの名無しさん:2013/11/24(日) 20:01:29.73
汎用性
読み方:はんようせい

ある物事について、幅広く適用したり、一般的に活用したりすることができる性質を意味する表現。

887 :デフォルトの名無しさん:2013/11/24(日) 20:02:30.46
>>885
そうやってユーザー排除してきた結果がこのザマなんだよ
一生カゴの中にいればいいさ

888 :デフォルトの名無しさん:2013/11/24(日) 20:04:49.10
>>882
マジレスすると、髭は足りてる(アラン・ケイのゴーストライターの人だけど)
http://www.smalltalk.org/people/daningalls.html

889 :デフォルトの名無しさん:2013/11/24(日) 20:06:13.10
smalltalkが普及しなかったのは時代を先取りしすぎ、多機能すぎ、なにより権利を守ることに無頓着すぎたから

890 :デフォルトの名無しさん:2013/11/24(日) 20:07:13.36
>>887
Smalltalk知っているからって他の言語を使えないわけじゃなし
自分の殻に閉じこもっているのはどっちかって話でもあるな

891 :デフォルトの名無しさん:2013/11/24(日) 20:08:56.66
>>888
> アラン・ケイのゴーストライター
アデル・ゴールドバーグに空目したw

892 :デフォルトの名無しさん:2013/11/24(日) 20:09:42.06
>>890
お前にはマイナー言語がピッタリだ

893 :デフォルトの名無しさん:2013/11/24(日) 20:10:46.04
Ruby信者並とは思わなかった。

894 :デフォルトの名無しさん:2013/11/24(日) 20:13:43.84
温故知新

895 :デフォルトの名無しさん:2013/11/24(日) 20:14:08.67
Ruby信者がMatzの発明とか自慢してる
ブロック付きメソッド呼び出しだのは
ほとんどSmalltalkからのパクリだから、
SmalltalkerはRuby信者よりたちが悪いよ。

896 :デフォルトの名無しさん:2013/11/24(日) 20:18:07.58
>>892
Smalltalk知ってるって言っただけで
なんでお前なんかにマイナー言語使い認定されなあかんの?

897 :デフォルトの名無しさん:2013/11/24(日) 20:19:31.14
Smalltalkなのに声だけは大きい信者かな

898 :デフォルトの名無しさん:2013/11/24(日) 20:22:40.82
>>875
速度的にはCog VMでPython以上。
VisualWorksのVMでJavaと同等の速度がでる。

899 :デフォルトの名無しさん:2013/11/24(日) 20:22:53.86
Smalltalkって小声でじゃべるって意味じゃないの知らないんだな
英語も不自由なのか

900 :デフォルトの名無しさん:2013/11/24(日) 20:23:00.78
いまどきOOはSmalltalkなしに語れるし
むしろ後発言語の改良のほうが重要な点が多いのに
わざわざSmalltalkを引き出してくるほうがおかしい。
それでいてSimulaは語らないし。

901 :デフォルトの名無しさん:2013/11/24(日) 20:24:14.53
基本的にソースコードは全て丸見えだから商用にはあんまり向かないのはある

902 :デフォルトの名無しさん:2013/11/24(日) 20:24:21.77
ゼロックスの時代からSmalltalk使ってたやつがどんだけ居るんだっつー話よ。
にわかな奴ほど語りたがる。

903 :デフォルトの名無しさん:2013/11/24(日) 20:25:09.94
誰が語りたがってるの・・・

904 :デフォルトの名無しさん:2013/11/24(日) 20:25:58.16
>>900
お前はSmalltalkの何をしってんだよ。
それからSimulaは、C++のモデルとなるclassを搭載してただけで、
Smalltalkで発達したデザパタとはかけ離れてるからな。
C++の標準ライブラリーみたいな感じだ。大して勉強にならん。

905 :デフォルトの名無しさん:2013/11/24(日) 20:27:18.74
SIMULA67は「クラス」とか「オブジェクト」といった言語機能のアイデアを
ストラウスストラップやケイがそれぞれに「オブジェクト指向」を考案するきっかけとして
提供しただけで、それこそなしで語れるんじゃない?
それよりストラウスストラップが「抽象データ型としてクラスを使う」というアイデアや
ケイの「オブジェクトをメッセージに受け手にして徹底した動的性を実現する」ってアイデアを抜きに
今のオブジェクト指向は語れないだろう?

906 :デフォルトの名無しさん:2013/11/24(日) 20:27:38.34
>>900
Smalltalkから後発の言語で改良されたOOの重要な点ってなんだ?
具体的に書いてみ。

907 :デフォルトの名無しさん:2013/11/24(日) 20:28:43.38
>>904
ほらね

908 :デフォルトの名無しさん:2013/11/24(日) 20:28:45.98
>>905
正直ケイはどうでもいいなぁ。Smalltalkの実際の作者の方が面白い。

909 :デフォルトの名無しさん:2013/11/24(日) 20:29:43.05
デザパタがSmalltalkを語る理由かよw

910 :デフォルトの名無しさん:2013/11/24(日) 20:30:16.30
>>908
いや、でも「メッセージングによる動的結合の徹底」というアイデアはケイのものだと思うけどなぁ…

911 :デフォルトの名無しさん:2013/11/24(日) 20:30:16.46
>>907
じゃお前Simulaの入出力ライブラリーについて言ってみ。
こっちは知った上で言ってるんだが。全く知りもしないお前と一緒にされたくないわ。

912 :デフォルトの名無しさん:2013/11/24(日) 20:31:28.15
「オブジェクトをメッセージに受け手にして徹底した動的性を実現する」

これってSimulaのコンセプトを強調しすぎてキチガイ作っただけだよな

913 :デフォルトの名無しさん:2013/11/24(日) 20:31:56.94
>>907
お前は知りもしないのに、役に立たないという。
こっちは知った上で役に立たないという。
その違いが分かるか?

914 :デフォルトの名無しさん:2013/11/24(日) 20:32:11.01
>>900
初めて知った
オブジェクト指向ってSimulaを指した言葉だったんだ
Smalltalkが起源とか全くの大嘘じゃん

915 :デフォルトの名無しさん:2013/11/24(日) 20:32:47.61
>>912
関係ない。

916 :デフォルトの名無しさん:2013/11/24(日) 20:32:59.98
「俺は知ってるんだぞ!」

Smalltalkerの主張のすべてw

917 :デフォルトの名無しさん:2013/11/24(日) 20:33:29.50
デザパタを語る時の落とし穴
1) あんなもんは新しくもなんともなく…←GoF本に何度もそれはそうだと書かれている
2) あれはカタログ化して意思疎通のために…←実際は理解には差があって言うほど意思疎通できん

918 :デフォルトの名無しさん:2013/11/24(日) 20:33:39.47
>>916
はようSimulaの入出力の一つでも語ってみろよ

919 :デフォルトの名無しさん:2013/11/24(日) 20:34:22.63
>>911
ダールやニガードは
ストラウストラップの「クラスを抽象データ型として利用する」ってアイデアを知ってから
あらためてSIMULAをオブジェクト指向言語として舵を切り直した経緯があるからなぁ…
http://phobos.ramapo.edu/~ldant/oop/simula_history.pdf

920 :デフォルトの名無しさん:2013/11/24(日) 20:36:17.70
>>918
知ってるんだからキミが語ってあげれば?
さぞかしOOに大切な話なんだろうね
物知りSmalltalker君

921 :デフォルトの名無しさん:2013/11/24(日) 20:36:22.60
>>913
いずれにしても役に立たないでFA

922 :デフォルトの名無しさん:2013/11/24(日) 20:37:06.41
>>910
メッセージングを徹底的にってのは設計者の方は、
Lispの影響を受けた実装者の考えだよ。

アランケイ的には、やりすぎだといってたぐらいだし。

923 :デフォルトの名無しさん:2013/11/24(日) 20:38:16.09
>>920
知らねんならSimulaの名前出すんじゃねぇよクズ

924 :デフォルトの名無しさん:2013/11/24(日) 20:38:22.53
Simulaは物理のシミュレーション記述を目的にしてきた経緯があるから
自然なコンセプトだよね。

925 :デフォルトの名無しさん:2013/11/24(日) 20:39:01.14
>>923で何を語ってくれるの?

926 :デフォルトの名無しさん:2013/11/24(日) 20:39:22.64
>>921
じゃJavaもC#も役に立たんゴミでFAだな

927 :デフォルトの名無しさん:2013/11/24(日) 20:39:57.94
>>922
いや、メッセージングを徹底しすぎたのはたしかにケイも批判的だったけど
彼がその先にある動的性を重視していたのは確かだよ。
http://metatoys.org/oxymoron/oxymoron.html

928 :デフォルトの名無しさん:2013/11/24(日) 20:40:15.14
>>923がSimulaのすべてを知った上でOOとして語るに値しない点を
これから述べてくれますので注目!

929 :デフォルトの名無しさん:2013/11/24(日) 20:40:18.97
つまりメッセージパッシングOOはLispが起源?

930 :デフォルトの名無しさん:2013/11/24(日) 20:40:46.43
Smer的にはOOPのメリットって何ナノ?
たまに>>924的ことを一番にあげる人居るけど。

俺は、抽象化によって整理を捗らせるのが肝だと思ってる。
だから、必要に応じて必要なだけOOすれば良いと思ってる。

931 :デフォルトの名無しさん:2013/11/24(日) 20:41:30.48
Smalltalkerは起源を語り始める。
これがどういうことだかわかるよね。

932 :デフォルトの名無しさん:2013/11/24(日) 20:41:48.63
>>929
いや、動的性のほう。メッセージングのメタファはケイが考えた手段。

933 :デフォルトの名無しさん:2013/11/24(日) 20:42:54.82
>>925
お前はまずここでお勉強してろ
http://www.macs.hw.ac.uk/~rjp/bookhtml/

934 :デフォルトの名無しさん:2013/11/24(日) 20:43:29.96
>>932
動的性って?
動的型はLispに、動的バインディングはSimulaにあるようだけど

935 :デフォルトの名無しさん:2013/11/24(日) 20:43:41.07
>>933
知ってるのに語らないなら>>925と同じだね

936 :デフォルトの名無しさん:2013/11/24(日) 20:44:15.60
>>930
>>927にもあるけど、やっぱり最終的には動的結合でしょう。
>>870なんかはその良い例で

937 :デフォルトの名無しさん:2013/11/24(日) 20:44:29.13
Smalltalkerは俺は知ってる詐欺

938 :デフォルトの名無しさん:2013/11/24(日) 20:46:14.92
でSimulaではなくSmalltalkを持ち上げる理由はなんなの?

939 :デフォルトの名無しさん:2013/11/24(日) 20:47:08.91
>>934
それを処理系それ自体を含む、コンピューターシステム全体に適用しようとした試みでしょう
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24#

940 :デフォルトの名無しさん:2013/11/24(日) 20:47:45.56
C++の劣化版としか言えないライブラリーのSimula。
線形代数系のライブラリーがC++風に構築されているSimula。
Smalltalkみたいに、新しい言語が結局帰着してしまうような
仕組みを作り上げたわけでもない。中身を除いてみれば
その後への影響力は構文の特徴だけで、新たに見つかるものもない。
まぁ、>>925 よりは知ってみる価値はあるがな。

941 :デフォルトの名無しさん:2013/11/24(日) 20:48:06.42
まさに>>900を実証した流れでした

942 :デフォルトの名無しさん:2013/11/24(日) 20:49:30.36
C++/Java/C#がSmalltalkより劣ってる点てなんなの?

943 :デフォルトの名無しさん:2013/11/24(日) 20:50:29.91
キチガイはC++やJavaのシェアも知らないから仕方ない

944 :デフォルトの名無しさん:2013/11/24(日) 20:51:49.60
>>938
Simulaのライブラリーは大して生産性のあるパターンや拡張性を
念頭に置いたパターンに力を入れられてない。継承してれば
オブジェクト指向ってな感じの効果の薄い原始的な方法ばっかり。
委譲による基底オブジェクトの入れ替えなんて考えられてない。

945 :デフォルトの名無しさん:2013/11/24(日) 20:52:17.17
>>942
信者のウザさ

946 :デフォルトの名無しさん:2013/11/24(日) 20:52:51.41
デザパタ発祥起源がそんなに大事だと思ってるのSmalltalkerだけなんだが

947 :デフォルトの名無しさん:2013/11/24(日) 20:52:55.27
>>934
あ、いや、Lispが起源なのは動的性のほう、という意味
メッセージングとそれの受け手としてオブジェクトを使ういうメタファで
動的性を徹底しようとしたのがケイのアイデア

948 :デフォルトの名無しさん:2013/11/24(日) 20:53:54.70
>>942
>>927

949 :デフォルトの名無しさん:2013/11/24(日) 20:55:26.08
>>942
instance creationが使えない
メッセージ転送が使えない

クラスオブジェクトとインスタンスオブジェクトが分かれてて、
デフォはクラスオブジェクトを使い、たまにインスタンスオブジェクトに
切り替えるようなパターンが使えない。

言語拡張無しにLinqの様な仕組みを効率的に実装できない

リフレクションの仕組みが通常のメッセージ送信とかけ離れてて、
既存のメソッドをリフレクションに適用できない

950 :デフォルトの名無しさん:2013/11/24(日) 20:55:33.24
SimulaベースのC++/JavaがOOを普及させるに足りる
柔軟性現実性を持っていたからOOは普及したのに
その過程で出てきたデザパタの起源でキチガイのように主張するわけですね

951 :デフォルトの名無しさん:2013/11/24(日) 20:56:15.83
>>949
なぜ使えないか考えたことある?

952 :デフォルトの名無しさん:2013/11/24(日) 20:57:07.46
>>951
なん・・・だと・・

953 :デフォルトの名無しさん:2013/11/24(日) 20:58:04.71
>>942
制御構文がメッセージじゃないんで、
制御構文と同じ書き方をコレクションとかに適用しようとしてもできない

Symbolが存在しないんで、全体で一意に扱い値を管理するための
辞書を態々作る必要がある

954 :デフォルトの名無しさん:2013/11/24(日) 20:59:25.81
>>951
JavaとかC#とか今必死こいて言語拡張して対応しようとしてるよな
C++の真似事から始めたからだ

955 :デフォルトの名無しさん:2013/11/24(日) 21:00:48.30
>>936
( ´・∀・`)へー
といっても動的束縛に関しての知識がC++/Javaあたりのことしか分かってないんだが、
大まかに言ったら多態性ってことでいいのかな?

>>870の例はモジュール化による、変更部分のコンパイル量とか時間を特にプッシュしてるみたいだけど。

956 :デフォルトの名無しさん:2013/11/24(日) 21:02:10.94
自分が作ったわけでもないものによく必死になれるよな

○○は起源=それを知ってた俺は凄い

957 :デフォルトの名無しさん:2013/11/24(日) 21:06:02.51
>>942
オブジェクトの生成が(new)がメッセージじゃなくて演算子。
他のクラスのオブジェクトをnewで返すような事もできない。
このせいでinstance createnの真似事もしづらい

ブロックにあたるラムダが今更追加され始めたが、
Smalltalkの復帰文(^)の様にブロック生成元の
メソッドまで戻れない。(多分数年後に同じ文が
追加されるとは思われる。)
このせいで、
value := map at:#key ifAbsent:[ ^self ].
これだけで済むものが、一行判定が入ったりしてクドクなる。

958 :デフォルトの名無しさん:2013/11/24(日) 21:07:20.23
>>951
なぜ今更真汚い構文追加して似事を始めてるかしってる?

959 :デフォルトの名無しさん:2013/11/24(日) 21:08:06.09
>>955
だいたいあっているけど、ちょっと大まかすぎるかな^^;
たとえば>>870を実現させたように、Smalltalkのコンパイルがデフォでインクリメンタルなのは
最小の変更部分を差し替えるだけで他の部分は(>>927の例にもあるけど既存のインスタンスも含め)
いじらずにそのまま動き続けさせたいって目指すところがあったからという設計思想の影響が大きい。

960 :デフォルトの名無しさん:2013/11/24(日) 21:08:55.66
Excelファイルみたいなもんか

961 :デフォルトの名無しさん:2013/11/24(日) 21:11:05.45
>>942
C++は問題ないが、Traitsが無い。
Rubyもmoduleで真似事を始めたが、
Javaなんかは、いちいち委譲する必要がある。
一応annotationを使えば近づけるが、
無理やりやってるもんだからボロが出まくる。

962 :930:2013/11/24(日) 21:12:41.33
>>959
動的束縛によって実現された多態性が設計的に嬉しいというだけでなく、
やっぱ>>870の例にあるような、コンパイル作業の効率化ってのもOOPの大事なメリットなのかな?

963 :デフォルトの名無しさん:2013/11/24(日) 21:13:19.49
結局風潮的には、
C++ベースの言語 → Smalltalkの機能
なんだよな。C++ベースの慣れ親しんだ構文でどうにか
Smalltalkの機能を再現できないか頑張ってる感じ。

964 :デフォルトの名無しさん:2013/11/24(日) 21:14:32.78
>>962
OOPってひとくくりにしちゃうと語弊があるかな…
これはSmalltalkが(というかケイがメッセージングで)特にって範疇の話なので…

965 :デフォルトの名無しさん:2013/11/24(日) 21:16:06.03
なんにしろメリットとデメリットがあるわけで一方的な面だけ見て優れてるって言っても
他の面でデメリットがあったら普及はしないんだよ

966 :デフォルトの名無しさん:2013/11/24(日) 21:16:20.95
前スレは埋まるまで8か月もかかったのが、
信者vsその他大勢のどぉぉぉぉぉぉぉぉでもいい煽り合いだけでわずか10日で埋めるかよ
流石プログラマ、粗探しだけは得意だな

967 :デフォルトの名無しさん:2013/11/24(日) 21:16:30.83
>>942
いくつかのデザパタは実装する必要がない
抽象化ファクトリーやフライウェイト、
オブザーバーパターンは、ライブラリーや言語機能で
実現できてるので、それを利用すれば済む。

968 :デフォルトの名無しさん:2013/11/24(日) 21:16:43.91
>>963
そうなのか?
C++は関数型に向かってる気がするが

969 :デフォルトの名無しさん:2013/11/24(日) 21:18:27.66
>>964
つかケイのOOの概念を応用したものは普及してるが、
ハゲが普及させたかったOOってなんだろうな。
単なるクラスを使った構文か?

970 :デフォルトの名無しさん:2013/11/24(日) 21:21:00.68
>>968
無名関数が入っただけで関数型って・・・
C++はtemplateでクラスオブジェクトを真似たり、
instance creationの真似をしたり、無名関数で
ブロックの真似事をしたりしてるよ。
この調子だと、そのうち無名関数に指定したコールスタックまで
戻るreturnが追加されるんじゃねぇか?

971 :デフォルトの名無しさん:2013/11/24(日) 21:22:14.78
>>968
関数型と共通している機能上げてみそ?
templateの特殊化ぐらいじゃないか?
無名関数なんて関数型特有じゃねぇぞ。

972 :デフォルトの名無しさん:2013/11/24(日) 21:24:22.02
>>969
ストラウストラップが実現したかったのは
http://www.stroustrup.com/whatis.pdf
でも述べられているように、SIMULA67の「クラス」で抽象データ型、つまりユーザー定義型を実現するアイデア。
ただクラス(というか継承)だけで抽象データ型を安全に運用するのには問題があって、
それでインターフェイスが考案された。(C++ではこの問題は顕在化しなかった。為念)
http://users.csc.calpoly.edu/~gfisher/work/specl/documentation/related-work/formal-semantics/p125-cook.pdf

973 :デフォルトの名無しさん:2013/11/24(日) 21:25:10.10
>>970
いやいやいやいや
テンプレートメタプログラミングは動的と真逆の発想だろう
constexprやリテラルクラスやrvalue referenceとか
最近の拡張は静的関数型のテンプレートみたいだよ

974 :デフォルトの名無しさん:2013/11/24(日) 21:25:43.77
OOPのメリットは本質的には何だろうね。

今まで
1) OOPの目的は現実世界と同じようにクラスを作れる(?)ことにある、
  仕様書をそのまま実装できる
と豪語する人や、
2) OOPなんかにメリットは無い、非OOPLでもOOP出来る
と断言する人がいた。
2)の人はOOPを否定しているうちにOOPLを否定しだして、
話が非OOPLでもOOPできる、だからOOPLにメリットは無い、
っていう今考えると意味不明な着地をしていたが。結局OOPしたいの?w

とにかく、OOPのメリットについて断言してくれる人の話を聞いたこがない。
>>936さんは親切にも付き合ってくれたけども。

975 :デフォルトの名無しさん:2013/11/24(日) 21:26:50.97
>>973
動的な処理を静的に真似てんだろ

976 :デフォルトの名無しさん:2013/11/24(日) 21:30:29.28
>>973
テンプレートクラスの型安全に関しては、
c++独自だがテンプレートによる多態はダックタイプの真似事だぞ

977 :デフォルトの名無しさん:2013/11/24(日) 21:31:49.40
本当に何でも起源を主張するんだな

978 :デフォルトの名無しさん:2013/11/24(日) 21:32:27.62
>>974
既存の処理の再利用だろ
Smalltalk風に言えばメッセージパターンの再利用。

979 :デフォルトの名無しさん:2013/11/24(日) 21:32:31.24
たぶん一般的なクラスが必要ないって人はいないだろう
でも全部クラスにしろとか思想が入ると使いにくくなる
クラス「も」使えるくらいがいいんだろうけど思想の一貫性という意味では面白くないんだろうな

980 :デフォルトの名無しさん:2013/11/24(日) 21:35:56.82
>>979
要らない人がSelfとjavascriptを作った

981 :デフォルトの名無しさん:2013/11/24(日) 21:36:20.74
>>954
大量のCプログラマを引き込むには悪くない手法だとは思うが。

982 :デフォルトの名無しさん:2013/11/24(日) 21:36:31.78
>>976
型がある時点で別物
ダックタイプじゃないよ
Structural Subtyping

983 :デフォルトの名無しさん:2013/11/24(日) 21:38:31.46
危うく信者に騙されそうになったぜ・・怖いなあ

984 :デフォルトの名無しさん:2013/11/24(日) 21:40:08.93
>>978
ご回答ありがたく頂戴いたしました。
既存の処理の再利用。
非OOPではそれが出来ないか、満足できるレベルじゃない?

985 :デフォルトの名無しさん:2013/11/24(日) 21:42:32.82
>>974
show: aCollection
aCollection do:
[ :each |
 Transcript show: each asString.
].

上のshowメソッドは大抵の集合型に適用できる。
今まで非OOだったらどうだったか考えてみそ

986 :デフォルトの名無しさん:2013/11/24(日) 21:44:51.39
OOPでスレ立てお願い

987 :デフォルトの名無しさん:2013/11/24(日) 21:45:47.32
>>982
俺は型月のダックタイプで、ダックタイプに近い結果を得ようと
してると理解してたんだがお前の頭の中には、
全くの別物にしか見えなかったか
そうかそうか。
じゃあSmalltalkのデザパタもtemplateじゃ使えないわけだな。

988 :デフォルトの名無しさん:2013/11/24(日) 21:48:24.96
>>982
別物だから真似事なんだろ

989 :デフォルトの名無しさん:2013/11/24(日) 21:48:51.13
androidではできない。iPhoneだけ。

これと同じ。

990 :デフォルトの名無しさん:2013/11/24(日) 21:49:02.52
>>987
方向は似てても別物だよ
静的にしか受け付けないもの

991 :デフォルトの名無しさん:2013/11/24(日) 21:50:10.36
iPhoneと同じでないものはクソ
例え便利であっても。

992 :デフォルトの名無しさん:2013/11/24(日) 21:50:17.68
>>988
お前は本当にSmalltalkが起源だと言いたいだけなの?
他に言えることないの?

993 :デフォルトの名無しさん:2013/11/24(日) 21:50:35.07
>>984
WindowsAPIの構造体想像してみ
同じnameって要素
もってても構造体別に処理が必用

994 :デフォルトの名無しさん:2013/11/24(日) 21:51:17.01
>>990
方向が同じだって言ってんだろ

995 :デフォルトの名無しさん:2013/11/24(日) 21:52:06.71
>>994
なら否定することないじゃない
真似事ではないよ

996 :デフォルトの名無しさん:2013/11/24(日) 21:52:43.28
起源だったらもっと誰も知らないような言語とか論文のみとか概念はあったんじゃないかね

997 :デフォルトの名無しさん:2013/11/24(日) 21:52:43.35
そろそろスレも終わって平和になるなあ

998 :デフォルトの名無しさん:2013/11/24(日) 21:53:02.34
>>992
起源だなんて言ってんのはお前だけだろ
結局Smalltalkの方向にいくといってんだ

999 :デフォルトの名無しさん:2013/11/24(日) 21:53:35.99
>>992
すまん俺は単発だ。
「真似事」が「そのもの」と違いがある(型が普通にある)のは当然って突っ込みいれただけ。

1000 :デフォルトの名無しさん:2013/11/24(日) 21:54:41.97
というか静的型でダックタイピングの真似は無茶だよ
受け付ける型関係なくメソッドを動的に呼ぶ事が無茶

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

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

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