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

プログラミングに関する雑談スレッドです。

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

　　　　 　　　　　　　　　　ノ 　　　　 ﾟ.ﾉヽ　 , /}　　　　　　...
　　　　　　　　　　　　,,ｲ`"　　　　　､-' 　 `;_' '　　　　..::::::::::::::...
　　　,-､　　_.._　　　(　　　　　　　　(,(~ヽ'~　　　　　..:::::::::::::::::::::::
　）'~ 　ﾚｰ'　　〉　　 ヽ　　　　　　　i`'}　　　　　　　.:::::::::::::::::::::::
　~つ　　 　　'-ｰ､　　i　　　　　　　|　i'　　　　　...:::::::::::::::::::::::
　／　　　　　　 <　　/　　　　　。/ 　 !　　......:::::::::::::::::::::::::　　　　これは>>1乙じゃなくて
/　　　　　　　　　~^´　　　　 /},-''　,●::::::::::::::::::::::::::::::::::::
i､　　　　　　　　,i'　_,,...,-‐-､/　　　 i　 ::::::::　　.:::::::::::::
..ゝ　　　　　　　　<,,-＝=､　　　,,-,/　　　　　 .:::::::::::　　　　　　　　　　　　放射能がうんたら
　)　　　　　　　{~''~>`v-''`ｰﾞ`'~　　　　　　　..:::::::::　　　　　　　　　　　　　　　　　　　　　　　　　　........::.
　{　　　　　　　 ﾚ_ﾉ　　　　　　　　　　　　..::::::::.　　　　　　　　　　　　　　　　　　　　　　　　　......:::::::::
ノ　　　　　　　　　''　　　　　　　　　　　..:::::::　　　　　　　　　　　　　　　　　　　　　　　 ...::.:...:::::::::
　　　　　　　　　　　　　　　　　　　　 .:::::::::　　　　　　　　　　　　　　　　　　　　　...:......::::::::::::　.
　　　　　　　　　　　　　　　　　　　　.:::::::::::.　　　　　　　　.....　　　　　 ..　　..::::::::::::::::::::::::　　　:::.
　　　　　　　　　　　　　　　　　　　　::::::::::::::::.::::::....:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::..　::　 ::..
　　　　　　　　　　　　　　　　　　　 .::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::　:::　　　　::.
　　　　　　　　　　　　　　　　　　　　:::::::::::::::::　::::::::::::::::::::::::::::::　:::::
　　　　　　　　　　　　　　　　　　　　　　　　　 .::　　　 ::.　　:::

>>1
乙

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

>>1乙

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

>>1乙

その次はDだな

次スレの名前が楽しみだ
++++にならない事を願う

+++でいいんじゃね

いや+が無かったからそれはおかしい

クイックソートの時代は何十年も前に終わってる

Javaでスマホアプリ作りたいんだけど
どんな知識が必要？ExcelVBAとUNIX系とSQLを少しずつできる程度です
Javaでのアプリ開発の参考書で作れるようになる？

timソートをポインタ使って高速化したtimpoソートが最速

全スレ>>993がOpenCLで高速なクイックソートを書いてくれるそうです。
皆さん正座して待ちましょう。

単純ソート、クイックソート、バブルソート
それぞれのロジックを簡単に説明して下さい

class Program
{
　　static void Main(string[] args)
　　{
　　　　int プログラミング雑談スレ = 1;

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

>>10
Javaのうすい参考書かるーくやって
Androidの参考書を書いたまえ。
飽きてやめることのないよう、わからない事はおまじないとしてどんどんスルーしたまえ。
作ってたらそのうち詳しくなってくる。

>>13
単純ソートとバブルソートって同じじゃね？

>>15
おまじないが肝なのだと読みました。アドバイスありがとうございます！

>>15
いきなり執筆しろとはハードルたけえな

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」が表示されました。
これはなぜなんでしょう。怖くて夜も眠れません。

バグとしか思えねぇ…

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

1.0 - 0.9 != 0.1
ってのは浮動小数点問題で普通にあるけど>>19は初めて知った

正確な引き算が出来ないからだろ

え？

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

推測も何も常識だろ
http://0xcc.net/blog/archives/000164.html

常識だね

VCではzeroになるから問題だろ

なるほど、わかったぞ…………………………つまりバグだな！！！

常識て
バグだろ

> 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.
とあるから規格で認められている挙動になるのでは？

絶対値が十分小さい数e以下っていう妥協策を用いるんだけどこのeって定数は用意されてる？

差の絶対値

>>32
目的に応じてその値を定めるのが設計

必読書スレ誰も立てないのか

>>9
え？
今はなに？

>>32JavaScriptだと
Number.EPSILON = 2.2204460492503130808472633361816E-16
ただしdouble同士の誤差

機械イプシロンはそういう用途には使えないな
ちょっと小さ過ぎる

>>36
マージソート

１回の演算の丸め誤差は確かこれでいけるんじゃなかったっけ？
abs(a-b) < max(a,b) * 2 * EPSILON

>>40
どういう意味？

右辺は確か、演算結果の精度(仮数部の最下位ビットが表す数)を
計算する式だった希ガス

左辺って何だっけ

このスレ　解答側のレベルが
微妙に低くていいね
入りやすいよ

質問側のたった数行の文字列から思惑を推測して、それっぽいレスでいなす。のがうまいと言ってほしいな

arctan 1の展開刑
Σ（-１）^(n-1)･１/（２ｎ+１）の四倍が
3.14159265に近づいていかないのは
丸め誤差が原因

Stringのformatで小数点5桁くらいまで文字列にしてコンペアーしろ

あと　このスレって
何言語で質問したり答えたりしてるのか
よくわからん

レス=質問なのか？
自分の経験したことある言語でのふと思った事をただ書いてるだけじゃないのん

言語を限定したスレじゃないし、何でもいいんじゃない
マイナーな言語はレスが減るかもしれないが

N+にプログラムスレが立った時に
やたらEXCEL推しが凄かったんだが
その中でINDIRECT関数が凄い便利ってレスしてる奴が居たんだが
使ってみたけどそんなに２ｃｈで喧騒するほどでもないと感じたんだが
俺が思うより便利な使い方があるのだろうか？

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

>>50
N+ってどんな言語なんだ！？って思った

>>43
× 解答
○ 回答

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

>>52
すまんな
関数型言語出身だから
解答のがしっくりくる

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

自動大量ウェブクエリから統計とって株の指針にしてる。
これ始めてから充分食えるだけの利益出るようになった。

>>54
そういうのは秘密にしとかなきゃいけませんよw

>>55
実はそれ逆なんです。
おおっぴらに書くと仕手筋認定されるので書けないだけで、自分が何を買ったか
何を買うべきか公表できるなら公表したほうが儲かるんですよ。

>>56
なんだその程度のプログラマなんですか。忠告した僕がバカでした。

大量の情報を生かして捌くのがプログラマの最たるものだ

仮に本当だとしてもいつかは壁にぶつかる
自分が売買する量が増えていくと

ExcelはBefungeのなりそこない

風評の流布ですね
わかります

ていうか、もっといい方法が見つかったから競合者を潰すためにやってるんだろ

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

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


















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

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

アドレス割り当てろよ

普通にけつから２要素ずつ比較していって百の位が同じなら頭+1でいいんじゃね

>>65
そうやると・・・
200と400。何もしない
400と400。上を401にする
401と400。何もしない
って動いて、
1000
800
600
400
401
400
200
ってなるって、30分考えて気付いた

ソート後に走査すりゃいいだけじゃないの

ソートしてn=1して下から比較していく
同じなら n足す
小さいなら n=n+1してからn足す
大きいなら n=1する

あ
だめだ

考えるほどドツボにはまる嫌らしい要求なんだよ

if( p[i] >= p[i+1] ){ p[i+1] = p[i] + 1; }

>>71
上からまわしてるの？下からまわしてるの？

何が難しいかわからん。ソート中にやろうとするからこんがらがってるのでは

>>63
ユニークにできないくらい詰まってたらどうすんだよ

データはアクセス時間を意味して、longのエポックタイムが入っている
もともとは新しい奴を上、古い奴を下と、エポックタイム降順でソートしていた
仕様変更でこの順序を手動で並び替えできるようにする必要があった
ソートインデックスをカラムに追加するのは面倒なので、エポックタイプをあれこれして手動ソートできるようにしたい

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

>>12
OpenCL関係なくね。
それにクイックソートとかは初回が終われば問題が分割されるから並列化は余裕。

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

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

>>66
どうしてそうなる
200と400。何もしない
400と400。上を401にする
401と400。上を402にする
ってなるだろよく読め
百の位以上の桁、つまり/100したのが等しいかで確認すればいいんだよ

比較用の列を２つにして
メインが同じ数だったら、サブの数値で比較するのが普通だけどな。

>>78
だな。
1足していって突き抜けないかどうかのケアがいるし、
足すことに対する整合性で早速困ってるじゃないか。

こういう感じか
当然同じ数値は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]

ソート済だからもっと単純化出来るか

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

>>76
御託はいいからOpenCLで並列クイックソートと
バブルソートはよう。並列化に耐えるんだろ。

Linuxのコマンドだと、ソートして、
連続した重複行を1行にまとめるのは、よくある
sort | uniq

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

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

重複を無くすって消し去っちゃマズイだろｗｗ

map<int,int>は使えないのか？
valueのデフォを0として、
int uniqval(int key ){
int ans = map[ key ] + key
map[ key ] = map[ key ] + 1
return ans; }
でいける気がするけど。

2chでインデント崩さずにコード張り付けるのは
どうやったらいいの？

codepadとかideoneとかを使う

全角スペースを使えばいいよ

>>85
setつかえよ

前の数+1で何か問題があるの？

このソースはきちんとインデントされていますがバカには見えません
と宣言すればおｋ

自分にも見えなかった

>>86
Base64
uuencode
ISH
なんなりと

馬鹿なの？

あるクラスのメンバ関数があったとして，入力を
・メンバ関数の引数に指定する
・関数内でメンバ変数からとるようにする
のってどう使いわければいい？
入力がクラスのメンバ変数として妥当かどうか？

必要に迫られた時以外変数は持たないようにするのが、バグの温床をつぶす意味でよろしいかと

気分で使い分ければOK
みんなそうしてる

>>96
なるべく引数にした方がいいってこと？
>>97
まじで・・・

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

>>86
前スレ 711より
#define ___ /* empty; インデント用 --- 掃除したけりゃ %s/___ /\t/g とかで */
___ int i;
___ for (i = 0; i < 100; ++i) {
___ ___ fizzbuzz(i);
___ }

>>95
データの性質による。
例えばよく変化するデータならコピーをとるのはバグでしかないし
プログラムの終了まで不変ならいちいち引数を取るのはムダ。
何にしてもそのインスタンスにどの程度の責任を与えるかという話なんで、
デザパタの本でも読み直して考えた方が良い。

>>95
クラス名を見て
こういうメンバがありそうだなと容易に推測できる場合はメンバ
関数名を見て
こういう引数がありそうだなと容易に推測できる場合は引数

そこから先は経験

>>95
マジレスすると

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

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

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

>>100
>>101
>>102
ありがとう　すごい参考になった
たぶん悩んでる原因はクラスの規模が小さいせいで
入力がメンバ変数でも引数でも大きな違いがでなくてわかりづらいからだと思う
とりあえず他のチームメンバにも相談してみるわ

>>82
OpenCLなんて条件どっから湧いて出てきたんだよ

>>104
実用に耐えるんだろ
グダグダ言って逃げ回らないで
はよ書けよ

OpenCLで書かれて無いと実用性は無いのか・・・知らなかったよ。
それに俺は前スレ>>993ではないので知ったこっちゃありません。

顔真っ赤にして書き込まなくてもいいよ

>>107
っ鏡

あちゃー図星ついちゃった

>>108
お前は赤ちゃんか？
自分の顔くらい自分で見ろ

ときたま中高生みたいな下らない喧嘩腰になるのやめよう
普段は相手を許し認めて自分も許され認められてるんでしょ
いつもの感じでやろうよ中高生じゃないんだし

>>111
お前も随分と喧嘩腰だな

どんなレスをしようと
明日が月曜日であるという事実は変わらない

明日が何曜日であろうと俺がニートであるという事実は変わらない

ニート羨ましい
俺も月曜に休みたいよ

そういうお前もニートなんだろ

ニートできる環境を持ってるってのは武器の一つだからな
コネを持ってたり、技術を持ってるのと同じ水準で

>>106
現実の用途で使えるから実用性があると言うんだろ。
今並列化したソートで意味がある速度出せるつったらGPUだ。
CPUで並列化させるぐらいなら単一コアで実行させた方がよっぽど現実的。
CPUで並列化ソートなんて遊びの範疇で実用的じゃない。

>>118
マルチコアのご時世でそうなるのか？

>>118
自分でそのレス書きながら、そんな事言い切れるわけがない。って気づいてるだろｗｗｗ

ぶっちゃけ、ソートがボトルネックになる事なんて殆どないからどうでもいい

CPUで並列化させる方がよほど現実的だよ
4コアあるだけで3倍になる

>>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型にしたりして処理を切り替えられる。

>>120
お前は、はようコードを出せ。

>>122
ならねぇよロックやらスレッドコストやらで2倍いけば御の字だろうが。

>>122
クイックソートとか最初の方どうしても単一コアで処理する必要があるから3倍なんて(ヾﾉ･∀･`)ﾑﾘﾑﾘ

>>124
あ、お前上のほうのレスでコード出せだせ言ってた奴か
俺はその相手じゃないよ。

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

いるよなー
言い訳ばかりで何もしない社会のクズ

>>125
マージソートの並列化でロックなんか必要ないぞ、この馬鹿

ソートの並列化でロックが必要とか言い出す馬鹿はどんなコード書いてるのだろうか

実際の業務でソートがクリティカルな人ってどうしてるの？
一般人だとそもそもそんな大規模なデータがない

大規模データはSQLで処理するだろ
チューニングしたDBのSQLロジックより早いソートが自前で書けるなら別だが

>>129
お前がマージソート並みに実用性のある並列処理ができるっていってたのはクイックソートだろボケ
マージソートでロック不要なのはわかりきっとるわ
話ごまかして楽な方に逃げようとすんなクズ

>>131
ソートする対象が大体分かってるものだし、
最初から全て用意されてることよりも徐々に追加されることのほうが多いから
まず追加される度に適当そうな位置に挿入してその後ソートする

>>126
クイックソートみたいに2分割を繰り返すソートだと
それに加えコアに分割されたキャッシュが響く
ソート済みのキャッシュを全コアに反映せにゃならんからな。

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

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

実測に拠らない速さ議論は空論

>>137
とりあえず逃げ回ってる奴がソースコードを出せば済む話

>>126
初回も絶対分割できないというわけじゃないけど初回を分割すると面倒ではあるな。
それとソート対象が大きいほど初回が占める比率は下がるから、状況次第で効果が違う。
だからって3倍4倍になるとは思わないけどな。
ただの予想だがメモリアクセスの限界の方が先に来るケースの方が多いだろう。

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

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

>>133
> お前がマージソート並みに実用性のある並列処理ができるっていってたのはクイックソートだろボケ

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

並列あるならsleep sortが最強
理論上では定数時間でソートできる

>>126
データが10億件あれば、最初の方にかかる処理は全体の30分の1程度だ。その程度のことは気にしなくていい。

>>141 処理のオーダーは最高なのに、実用上は最悪というのは皮肉だねw

>>133
マージソートでロック不要なのは分かってるのに
クイックソートの場合分からないなんて
どういうバカなんだよ

>>132
Scanlineを作る際の頂点並び替えとかSQL使っとられんのだが。

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

>>140

>>9
>>12

>>142
じゃあ早く書いて実測させろよ

>>139
ソース書いてロック不要な事を証明してくれ

>>146
他の奴が書いたものまで書いたことあるうちに入れるなよ

>>132
1億件のレコードをオンメモリーでソートすればあっという間だが、
わざわざSQLでDBに入れてたら何十分もかかるんじゃないか？

お前ら名無しのくせに自己を主張するな。やりたきゃコテつけろ。NGしてやるから。

>>151
まずお前がコテ付けな

>>139
その鈍くさい方法ならロックは要らんが、
基準値との比較をコア数分同時に行う場合は、必要になる。

>>153
お前何言ってんだ？

quicksortの並列化じゃなくて
partitionの並列化か？

>>141
あれは時間を使うアイデアはすごかったが
実質はただのビンソートだぞ

>>154
4コアの場合

対象配列: 987654321
基準値: 5

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

>>157
どう見てもクイックソートの動きじゃない

>>157
クイックソートを並列化する際に、最初の一回目を並列化なんかするわけないだろ。
そんなバカなことしたら無駄に重くなるだけだ。

>>139
全てのタスク(ジョブ)が終了した事をどうやって調べるんですかねぇ。
まさかfork-join?

quicksortって暗黙的にinplaceの要件あるから
swapだけで処理しないと駄目だよ
だから振り分けは1コアになる

>>159
なんで重くなんだよ
クイックソートは基準値を元に左右に分散してれば、
左右の値がどう並んでても良い。
1回目1コア2回目2コアよりよっぽど速いわ。

仮にinplaceじゃないとして
左右配列への代入はどうするんだ？
同期処理入るんじゃないか？

>>157
お前、入力データと同じ大きさのバッファを用意してるだろ？

マージソートはロック不要で並列化ができるけど、
クイックソートはロックが必要。

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

>>159
1コアで100万件左右に振り分けるのと
4コアで100万件左右に振り分けるのどっちが速いか
多少考えりゃわかるだろうに

>>166
最初の振り分けは1コアでやらないと、ロックだらけで大変遅くなる

>>165
2コアならそれもできるが
最初から4コア振り分けって言ってるからそれも無理じゃねって言ってんだよ

>>166
クイックソートは、データが10億件あればネストは30以上になるんだぞ。
そのうちの最初の一層を4コアにしても1コアにしても、全体の時間は変わりはしない。
ロックまみれにしながら第一層からスレッド分ける意味がない。

>>133>>144
ていうか、マージソートの方がクイックソートより条件悪いぞ。
クイックソート
・初段の並列化に制限がある(並列化の方法によってはロックが必要)
・ソート完了判定で終了待ちが発生する
・作業領域を用意せずに破壊的にソート可能

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

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

>>168
マジキチすぎて議論になりません

>>171
じゃあ最初から4コアで振り分けるquicksortのアルゴリズムを
きちんとコードで説明してくれ

プログラム知らない奴がこのスレ見たら、何でわけわからん事で争ってんだって思うだろうな
シャワートイレ板で和式派と洋式派で醜い争いが発生してるみたいな

すまん>>172は途中から参加した
俺はマージソートに同期不要とは思ってない

>>170

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

>>170
御託はいいからソースを書けよ

>>168
2コアでも駄目だろ。
ハードウェアなら入力2系統出力1系統にして入力を並列化できるが、
出力が1系統だからソフトウェアに落とすと1コアもしくは同期処理だ。

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

A氏「マージソートの並列化にロック不要。クイックソートなら必要」
B氏「マージソートもクイックソートも並列化にはロックが必要」

どちらが頭悪い？

>>177
2コア＆inplaceなら最初の一回からできるよ
同一の大きさの配列作る
ピボットよりそれぞれ小さいもの、大きい物だけ選別するスレッドを生成
後は普通のinplaceクイックソート

久しぶりにこのスレ盛り上がってるな

>>179
> ピボットよりそれぞれ小さいもの、大きい物だけ選別する

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

>>179
訂正
最初の一回はinplaceなら、じゃなくinplaceじゃないなら

>>181
振り分けの並列化の話だよ

inplaceじゃないクイックソートという
何のメリットもない俺様アルゴリズムを前提に
意味不明な理論を語る馬鹿が一名

>>183
具体的にどうやれば振り分けの並列化ができるんですか？

>>179
無理ってのはマージソートの最終段だろ。

マージソートは最終段群が終わるまで、それらの親スレッド＝最終段以外のスレッドが待ち状態に入るわけだよね
クイックソートは親スレッドは生成スレッドを待つ必要はないけれども、でも最終段まで全部終わったことは検知しないといけないよね

>>178
マージソートに排他が要らんがクイックソートには排他がいるつう話しじゃなく
>>118から続くCPUでの並列化なんて大して速くならんつう話しの流れだ

早く寝ろよ、月曜の朝もすぐそこだそ

>>185
inplaceじゃなく、同じ大きさの空配列を作る前提なら
ピボットより小さい物は前から、大きい物は後ろから入れればいいだけ
このままだと容量がn*n必要になるから、2回目以降はinplace必須だろう

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

>>187
マージだとどのブロックも負荷はほとんど同じだから待ちはほとんどない

>>187
待ってる間CPUは他のスレッド処理してるわけで
遊んでるわけじゃないけどな

>>188
まあ今回のお題では、データに分割にしたがってスレッド生成を連発すると、そのスレッド生成コストが結構ありそうだね
決め打ち生成（物理コアだけしか生成しない）の場合の書き方がちょっと想像できないが‥‥

>>190
ピボットより小さい値を探すスレッドと、ピボットより大きい値を探すスレッドに分かれて、
両方のスレッドが全ての値に対して比較をする（比較回数はデータ数の2倍になる）
ということ？

>>191
ブロックを２分割したあと、それぞれをソートするスレッドを生成したら、それが終わるまで自分は待たないといけないだろう？

>>193
> 決め打ち生成（物理コアだけしか生成しない）の場合の書き方がちょっと想像できないが‥‥

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

>>192
スレッド生成や待ちに結構コストを食いそうだ
手持ちの6コアでも、他のお題での今までの経験からするとせいぜい2倍くらいじゃないか？

つかマージソートはオンラインアルゴリズムでキューが使えるから段階別に待つ必要ないだろ
前段階の1要素目が決まったら次の段階はそっから1要素ずつ取り出して処理すりゃいい
いくら排他がいるといっても、クイックソートとはCPU使用率の効率が違う。

>>197
> スレッド生成や待ちに結構コストを食いそうだ

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

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

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

>>197
ここでスレッドとか書いてても文字通りスレッド使うわけ無いだろ
計算用途ならスレッドプール使うのが普通
だからスレッド生成コストなんてプロセスの初期化時しか発生せん

>>198
＞前段階の1要素目が決まったら

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

>>194
あ、確かにそのままだとそうなるな
凄く馬鹿なこと言ってた
並列で比較回数も下げるには一旦マージか同期が必須になるのか

>>201
バカなの？

>>202
今頃になって何を言ってんだ
お前の言ってることは全てが馬鹿なことなのに

>>199
＞食うわけねーだろ
それが結構食うんだね
win32api で CreateThread() を for() でぶんぶん廻すと、そのチャイルドスレッドがsleep(10秒)だったとしても
「もうスレッド作れません」に到達するよ

>>204
これは恥ずかしい
馬鹿だったと認めるよ

戦争は終わった・・・

ま、まってくれ俺は自分が来る前から騒いでた奴は知らんぞ
いや、もしかしてあれも俺なのか・・？

>>203
自スレッドが、上からもらったデータを二つに分割した後、スレッドをひとつ生成して半分（のポインタ）をそいつにわたす
残りの半分は次の段階で自スレッドで2分割する

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

>>201

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

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

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

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

最終段階ブロック
123…

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

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のマージをする。

>>205
スレッドの生成回数はコア数より少ないから、そんな負荷は無視しろ

>>210
説明がよくわからん
[3, 1, 4, 5, 9, 2, 6, 8]
で説明してくれ

>>211
あったまわりぃ
マージソートのオンライン特性利用しろよ
マルチコアの使用効率最大に活かせるんだぞ

>>211続き

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

>>212
＞スレッドの生成回数はコア数より少ない
ライトウェイトプロセス方式のネイティブスレッドのことをいってるのか？

>>214
キューの方が遅い

>>213
ムリ
最終段階手前ブロックがキューであると
思ってよく考えてくれ

>>217
残念ながら実測だと待機時間が他の処理に使われるから
待ち時間が殆ど発生しない

>>217
もっと具体的に言うとキューの待ち時間にブロック構築が進むからCPUが処理待ちにならない

そして新しい戦いが始まる・・・

キューの同期化のオーバーヘッドはあるの？

>>210
使える情報が流れてきたことを知るためにmutexとか使うの？

>>218-220
これってリソースどれぐらい使うの？

一言言うと、並列化は並列処理に比例して処理速度が速くなるってことよ。

深いネストがあるクラスを書いてコンパイルしたら「閉じカッコと始まりカッコの数が違います」的なエラーが出て
エラー行参照したらクラスの終わりカッコだった時の、どこのカッコが閉じてないや感は異常

>>224
こってりソースに見えた

C/C++ なら } の後ろに(ホワイトスペースのぞいて) ; が来るケースはほとんどないんじゃね

言葉が足りなかった

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

>>223
普通mq_sendとかOSのapiかchannelみたいな言語機能つかうだろ

>>226
今時気の利いたエディタなら括弧の対応付けしてそれらしく表示くらいしてくれるだろう

>>230
それで、このマージソートのリソースはどれぐらい使うの

>>230
そのやり方はすげー遅い

つうかデータの性質や比較関数の性質、それを事前に分かるか等で
どれが最適かは変わるんだから議論しても仕方ないよ
まあ自分はインサートを推しとくが

>>193
今日の低脳君はこれだ

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

>>236
かわいそう

最近のVSはついに人工知能積んだのか

インテリジェンスﾜﾛﾀ

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

C++/CLI自体がもう未来を感じない言語だわ
C#やればよかったー

C#糞と思ってるJava使い俺以外に居る？

C#やってないけど、きっとスマートでスタイリッシュな言語なんだろうなーって勝手に期待してるJava使いはいる

ヘルたんlove

C#使うためにJava本読んでます

>>244
意味が分かりまへん
手続き型言語やってきて初めてオブジェクト思考やるから参考にとか？

JavaよりはC#の方がいい
ただC#マンセーしてる奴はレベルが低いのが多い

>>246
> JavaよりはC#の方がいい

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

>>245
まさにそれ

>>247
コンテナにプリミティブ型格納するにはラッパークラス使ってください
関数を引数で渡すときはリスナークラス使ってください

C#も機能がゴテゴテしてきた印象はあるけどさ、
総称、atomic、劣化using、lambda、etc. と、
導入が数年から10年遅れる上に、個々もクソ機能に変更する言語ですよ？
C#と比較して褒めるとか無茶ですわ。
JVMだけならまだしも。

>>245
意味が分かりまへん
Java や C# が手続き型言語じゃないと？

それは意味が解らないのではなく
相手の意図を理解した上で、揚げ足を取っているだけでは無かろうか

JavaやC#は絶対クラスが必要だから手続き型ではない
もちろん手続き型のような書き方はできるけど

そう考えるとC++やDって
まさにマルチバラダイムな言語なんだな

C#が手続き型言語ってのは無理があるだろｗｗ
C#「やるため」にJava勉強してるって言ってるだろ

手続型って関数型に対する用語で、
OOPLとの対義語としてつかうのは間違っとるようにわしは思う

新しい技術が出てきた際に、古い技術に名前をつける必要が出てくる
そういった場合得てして漠然とした名前がついちゃうんだよ
スマホが出てきてケータイがフィーチャーフォンになったみたいな。
手続き型言語ってのもそんな感じなんじゃないの？

いや、関数と手続きってい小さな対比は昔からあったんでは？
pascalにおいてはそのままfunctionとprocedureがあったように。


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

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

>>259
上の例は何て言う言語？

>>258
小さくねえよ
純粋に近い関数型は引数の評価順序が不定で、
引数でしか処理を書けないから手続型の様に、
処理を手続的に書けない。
逆に引数の評価順序が保証されないという特性のお陰で、
並列処理につよいがな。

>>260
ブレインファックじゃね？

教えてあげないよっじゃん！

CとC#とJavaをひとくくりにしている時点で悪意を感じる
そして例示はC++マネージ拡張系とかか？

もっと冗長に書きなおしてみるか

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

a do: b.

>>259が>>255に何をいいたいのかさっぱり分からんｗ
そのループの例が何を示してるのか…。

>>266
何も意味のあることは言ってないと思うよ
彼の脳内のループバック通信がここに漏れ出ただけ

脳内ループバック通信ｗｗｗ

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.

>>269
そこまでかたくなにimportしない理由はなんなんだ

List型とArrayList型とVector型とCollection型とString型とInteger型と
System型は既にユーザー定義しててimportできないからに決まってるだろ。

>>271
どんだけ基本クラス拡張したいんだよｗｗｗ

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.

ね、Javaって糞言語でしょ。

C++やC#,Goみたいに名前空間に別名付けられれば苦労しないのにね。

全角スペース混入によるエラー探しに時間がかかる
腹たって全角スペース・半角スペース・タブをエディタ設定で見やすくするようにしたら
それだらけでさらに腹たつ

sedしろよカス

そんな腹立つ言語使わなきゃいいのに

全角スペースでもコンパイルエラーにならない言語は快適です

コボラーになって銀行系システムの保守だけで食っていきたい

新しい環境で新規ならなんでもいいよ
レガシコードの移植はもいいやだやめたcomなんか死んじゃえ

comはしぶとく残り続けるよ

手続き型と並べて比べるのは宣言型。
関数型は宣言型の一部。

WikiいわくC++は手続き型言語なのな
クラス作れるのがオブジェクト型言語だと思ってたら、どうも違うらしいね

クラス作れなくてもオブジェクト指向なのはあるぞ
プロトタイプベースとか言うだろう？

Smalltalkも手続型ですしお寿司

オブジェクト指向と手続き型/宣言型は直行性のある概念。

それは詭弁
手続き型オブジェクト指向なんて言い方はしない
狭義がデフォ

>>284
選べる手を一つ増やしたというだけ
オブジェクト指向に閉じ込められたわけじゃない

>>289
誰もそんな話をしてない

関数型オブジェクト指向言語
OCaml

メソッドチェーンソー

アスペクト指向「出番ﾏﾀﾞｰ？」

>>293
フレームワーク用の指向であってプログラミング言語にそんな指向を入れる余地はないと思う。

frameworkってなに？

>>293
AOPは使いどころが限られてるからな

そういやAOPのスレって無いんだな…

マルチパラダイム、でいいんじゃねーの。
関数型と手続き型だって、互いの関数呼び出しが不可能って訳じゃないだろ。

C言語で書いた関数は呼び出せてもその逆が素直にできない事はいくらでもある。

>>299
最悪、関数型のプログラムを手続き型の言語から起動して標準出力読めばよくね？
相互呼び出しのAPIが十分整っていないってのと、それが構造上不可能であるかってのは別の問題かと。

xmlがあればなんでもできる

>>298
言語のパラダイムの話だから ABI の話は関係ない。

どっかの記事で読んだけど情報系の大学ではプログラム出来る奴と出来ない奴は
ハッキリ分かれててしかもそれは単純な学力とは違う問題だという話だけど本当？

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

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

>>303
へえ
訓練メソッドしだいでなんとでも思う、というか教育体制の問題じゃない？
すずめの学校ぴーちくぱーちく、ではどうにもならないのがプログラミング

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

>>304
まぁ確かに質問サイトとかでよく
「大学生ですがこの前PHPの入門書買って読んだんですが全然わかりません」
「どうやったらプログラムできるようになりますか？」
とか山ほど投稿ありますもんねぇ…

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

あ、そういえばこんな記事も読んだ事ある。
例えば

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

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

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

>>303
割と本当。そういう環境に居たけど、「適正ってあるんだなあ」って思ったよ

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

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

>>307
なんというかあれなのかね。
整理整頓能力みたいな。
本棚の整理が苦手な奴がダメみたいな。

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

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

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

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

頭いい奴はスパゲティでも管理出来てしまうからコードがなかなか綺麗にならない
さん散らかしのデスクから直ぐに必要な書類が出せるやつみたいに綺麗である必要がないんだ

アスペは２ｃｈに必要な適正七日

ものごとの攻略法を見つけるが早い奴ってのはいるもんだ

ある程度散らかってて、状態が奇妙でヘンテコな方が記憶しやすいんだ。
一般論として部屋の整理整頓が行き届いてるやつって記憶力悪いだろ。

まぁ自分一人で開発してるなら
どんな汚いコードでも自身が把握出来て完成させる事が出来て
改変可能なら問題ないよね。

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

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

>>310
よく分からないのは
頭良い奴はスパゲティーの方が分かりやすいのか？
それとも結局頭良い奴でも整理整頓されたコードのが分かりやすいのか？
もし後者ならば、やっぱし自分がより分かりやすい形にコードを整える能力を養う方が後々も有利なので
総合的に頭が良い奴は結局、コードを整理する努力をするものじゃないのかな？

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

>>314
誰もが読めるコードが書けるけど
自分しか読まないからあえて効率優先できたないソースにしてる。ってんなら能力があるんだろうね
でもそんな奴はめったにいない

スパゲッティーコードというのはgoto文であっちこっち飛んでこんがらがっているやつのことだぜ。
ブロック構造化されている最近の言語ではスパゲッティーコードというのは無い。
オブジェクト指向を間違った使いかたしてスパゲッティになっているのはスパゲッティというよりバカコード。

イベントドリブンを使わずマルチスレッドでやろうとするのもゴチャゴチャしてるが
スパゲッティといえるのかわからないがこれはスパゲッティと言ってもいいかも。
イベントドリブンを使わずjsp上でイベント処理してるのも同様だ。

あとHashtableをツリー構造にしてるのはアホコード
状態遷移表を使いたいのか知らんが全変数を配列の要素にしているのもアホコード

あとifのネストが異様に多いのはド素人コード

今までの話の中でのスパゲティーの定義は
単純に世の中の大多数が読み難いと思うコードって意味じゃない？

多重ループのネストが異様に多いのは愚鈍コード
１つの関数やファイルが異様に大きいのは、糞コード

>>313
判ります
道に迷うときってどの分岐入っても同じような景色が続いてるようなところで迷う

ファイルが多くて読みにくいというのをスパゲティと言っている奴が多いと想像するが
それはエディタがヘボく多数のファイルを扱えない自己責任。

>>322
KVSで使われるのはレコード
おやじの頭はバーコード

>>319
＞あとHashtableをツリー構造にしてるのはアホコード
くわしく
チェイン法でのリスト以外にもツリー構造をとることもあるのでは？

hashtableは配列にすることに意味があるんだと言いたいんだろうな
もちろん衝突を考慮した場合はそこにリストやツリーが絡むけど

ずぶずぶだからねぇ。
いろんなもんをイッパイ積み上げていく競技？趣味？
があるけどプログラミングってそれに近いものがある。

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

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

ハッシュコンテナとか自作する奴は素人。
プロは特に理由がない限りできるだけ標準のライブラリを使って車輪の再発明はしない。
無いならしょうがないけど。

>>329
ちなみに聞くが、きみは中学生？高校生？

いま小3だけど

>>329
これ勘違いしてるやつ多いけど、車輪がどういう仕組みなのかを勉強するのは必須な。

論理演算で四則演算ができるとかな

車輪の再発明ガーって言ってる奴は自分では何も発明してない法則

自作のプログラミン言語ぐらいは、作っとかないとな

>>330
ファミコンやゲームボーイでアセンブラでゲーム作ってたおっさんだよ。
いまはC++でSTLやboost使ってる。

ここに居るような人は、>>329みたいな台詞は、
中学か高校のころに一度は言ったことがあるはず。
最初の頃ってそういうの言いたくなっちゃうからね。

まぁ基本的な部分になればなるほどだいたい整備されてるから自分で作ることはないだろうけど
初心者は最初からそんなところ手を出せないが
車輪の再発明ってうるさいやつはフレームワークとかそこらへんで連呼してるイメージ

ゲームでboost使うとかどんな罰ゲームだよ

>>303
受験数学は数学センス無くてもそこそこ取れる

俺受験物理得意だったし大学も物理学科だったけど
物理エンジン自前で書いてて自分の力学の理解のなさに驚いた。

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

>>339
時間軸って知ってる？

3DCGやってると、光速度とか気になるよな

ゲームと一口に言っても
処理落ちを気にしなきゃならん様な、ピーキーなゲームばかりじゃないからな

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

コンシューマー系だと処理速度に問題なくても断片化の問題が大きい

処理速度に問題ないと処理速度に関わる問題を語るとはこれいかに

え？

>>333
四則演算のみで論理演算作る方が難しいよね

>>322
じゃ100行超える関数がざらのLinuxやWindowsは糞コードか。
まぁコード哲学語る前にまともに使えるソフト作ってから語れよw
hellow world量産してる場合じゃねえぞ

>>344
ゲームの話がしたいんじゃなく、
速度要求が厳しい場合の話がしたいんだろ
アスペかよ

>>329
確かにな。既存のロジック自作すんのはお勉強の時だけ。
実用目的のソフトに車輪の再発明入れまくる奴は間抜けだわ。

ここって意外と中高生多いのか？

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

むだにめそっどをわけると
おーばーへっどによっておそくなりまする

>>149
１００行で多いと思ってるおまえは相当なカスだな。

>>349
１０行～１００行は普通。
１０００行以上だと多い。

>>354
いうても200行300行ざらなんだが
お前の見てきた長い関数って何行なんだ？

分割できるなら１００行でも多いよ。
実際には分岐の多いswitchと分岐あたりのコード量がそこそこあると
分割するほうが面倒なことも多いけど。
まあ書いてて分割が面倒でもスコープくらい付けてもいいな。

そもそも関数の長さ云々で語ってる奴があほなんだよ。
関数ができるのに同じコードをベタベタ貼るヤツが糞って言えば良いんだよ。

ある程度統計的な判断ができるから無意味ではない。

別にmain関数が1000行有ろうが処理が重複せず、
ブロックで変数が区切られてりゃかまわんな。
vimやらjvmとかpostgressとか有名どころはそうだし、
1度きりしか呼ばれない関数作られるのも読みにくいし。

コピペ一切禁止の俺DRYも問題だけど
コピペしまくる奴はもっと問題

>>359
いや意味ないね。
重複が良くないと思うなら最初からそう言うべきで、
行数で語る奴はステップ数で見積もりだす奴と同じく
蔑まされるだけ

いやブロックよりも関数のほうが引数と戻り値が明確になるし
(グローバルやメンバ変数使わなきゃの話だが)
名前付けて分けたほうが構造化が進むし検索もしやすい。

>>362の無能さが痛々しい

イージーミスの原因のかなりの割合をコピペが占めてる
完全コピペですまないコードの、コピペ後の修正漏れが多い
その時問題なくてもコメントの修正漏れとかがあって、後任者に迷惑かけることもある
短いコードなら手書きにすべきだね

お前らがガチ中高生だとわかったｗ

昔は行数で給料が決まってたらしい
だからfor文も手動で展開していたらしい

そういう意味ではhaskellなら行数でなく関数数で給料決めるべき

>>367
今でもステップ数で労力を測ってるとこあるけど、なんの意味あるの？って感じだわ

>>363
ブロックとIDEでできるよ
IDE無くても大体それ用のpragmaあるしね

いまだにソフトウェアのメトリクスが理解できない奴がいるんだな

>>370
なはしがかみ合ってない

>>363
重複しない処理だと読みづらいだけだろ

>>373
＞いやブロックよりも関数のほうが引数と戻り値が明確になるし
＞(グローバルやメンバ変数使わなきゃの話だが)
ここが伝わっていないと思われる

>>372
ブロックにマーカー置いとくとそこにすぐ飛べる機能があったりする
例えばXcodeとかgnu系で使える
#pragma mark 名前

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

>>374
ブロックだと変数をスコープに区切れるし、
引数戻り値になる値が一貫して明瞭だろ。
それに広域変数の問題も発生しない。

>>375
>>374
ちなみに
＞(グローバルやメンバ変数使わなきゃの話だが)
もブロックだとしても同じことだからデメリットになるわけではない。
近辺にコードがないのはデメリットだが１００行以上であればすでに近辺の意味は薄い。

>>374
引数はともかく戻り値明瞭にするいみあんの？

>>376
＞(グローバルやメンバ変数使わなきゃの話だが)
ブロックは外のブロックを参照できるから意味が異なる。

実装が上手い奴は制限なんか設けなくても関数は小さくなる。
構造化が上手いからな。

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

（余計な煽り入れんなよ・・・）

レスが3行以内に収まらない場合は名前欄に関数名を入れること

>>382
面白いｗｗ

皮肉ったつもりが無理解を露呈するって良くあるよね

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

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

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

一度しか使わない関数の短所その2
・他の関数名の中に名前が交じる。
　ブロックを探したいんじゃ無く、
　純粋に関数を探したいときに邪魔。
・関数内スコープで飛べない。
　特定の関数内で目的の処理をちょくちょく飛びながら
　探すときに、関係のない関数名も並ぶ。

>>386
主観だらけだなw

>>386
お前みたいな周りを気にしない奴と仕事したくないわ

>>387
・他の関数名の中に名前が交じる。
名前の規則で気にならないレベルまで解決できる
・関数内スコープで飛べない。
エディタの検索機能は必須と考えてるので問題ではないと考える。

>>390
だったら最初から関数で代用せずIDEと連携する機能つかえよ

>>389
いやいや行数気にしないほうが可読性低いと思うぞ。
俺の論点は一点で「変数スコープ」。
しかもそのために「１００行限定」とするわけではなく
なるべくスコープ小さくしてね。目安として１００行ね。って話。
プロジェクトによってはもっとゆるくするし。

一度しか使わない関数はラムダで書くわ

>>391別にIDEを使うことを否定してるわけではない
>>392

>>386
なんでこいつこんな糞理論をこんなドヤ顔で披露してるの？

>>386
しなくて良い苦労をして何がそんなに嬉しいの？

>>395>>396
新たな問題点指摘は具体的に。
>>386の内容自体が気に食わないならそれは意見の相違。

>>392
ほとんどの言語はブロックでスコープ限定できるぞ

>>398
外部ブロック変数の参照も限定できるの？
できるんだったら処理として独立してるんだから分けていいよね？
別に３行でも分けろと言ってるわけじゃなく
例えば１００行くらい以上なら分けたほうが読みやすくね？って話し。

>>399
どういう理由で限定すんの？
使うから参照できる位置にわざわざ宣言するんでしょ。
あと不必要にソースを飛び回るほうが読み辛え

無駄に離れてて名前ついてりゃ読みやすいんなら
誰も無名関数がほしいなんて言わないつーの

>>385
一度しか使わない関数の短所
・前後関係が分離され、見通しが悪い。
　・定義だけでは、単回呼び出しとわからない。
　・別ファイルでさらにイライラ。
・分離する際に名称がつけにくい。難読性が増す。

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

>>400
俺の論点は一点で「変数スコープ」。
100行超えるようなコードが直線的である確率は低い。
であれば直線部分は関数に切り出されていたほうが見通しがいい。
かつ変数スコープは変数の変化状況を限定してくれるので見通しがいい。
逆にいろいろな変数を触るような関数は
設計に問題があることが多いのでその判断基準にもなりえる。

きちんと同じ粒度で揃えればいいだけ。
例え1度しか使わなくても、見通しは悪くならないよ。

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

>>402
プログラム云々より国語の教科書や道徳の教科書よんで読解力つける方が先じゃ…

>>404
しなくても良い苦労としなけりゃならん苦労は違うだろ

>>405
冗長すぎてわかりにくいだけだと思うよ。
プログラマとは思えない。

一度しか使わない関数の長所

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

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

>>404
そういや中身空っぽな構造体同然のモデル書くやつと、
一度しか書かない関数を分離するやつって往々にして同じ奴だな。
何のためか批判的に考えず形だけやってる感じ。
あと行数指定する奴も同類だ。

下からと上からでは見える風景が全く違うというおはなし

>>408
共通の処理が出てくるのは別問題だろ
そうなった時に初めて分離すりゃいい話。
むしろ既存の関数の分離の仕方が悪いと更に時間が掛る。
典型的なDRYの失敗例じゃん。

>>408の内容は完全同意できるが

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

>>409
一度しか使わなくても、例えばbusyboxのように、
完全に機能が分かれている場合なんかは、分けた方が見通しがいいよ。

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

もちろんケースバイケースなワケだが
ダイクストラの構造化プログラミングを
単純否定するようなレスが散見するのはどうかと。

何冊かプログラム設計の本を読んだほうがいい。
全部関数は小さくって書いてある。
色々読んだけど、少なくとも一度しか使わない関数を作らないほうがいいなんて書いてある本は見たことない。

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

関数呼び出し回数がわからんとか、名前が混ざるって、
静的解析やide使ってないのか？

＞Linuxで数百業の関数になっても一度しか使われない関数が忌避されてる
初耳
ソース

>>413
批判ってのは批(付き合わせ)判(判断する)って意味だぞ
非難と間違えてないか？

>>419
今度は言葉遊び？悪いけど付き合わないよ。

>>414
ダイクストラの構造化プログラミングは、
ブロックをgotoで跨るなという話で今までの話とは全く関係ない。
ループからループの真ん中に飛び込むとか、
ifからループに飛び込むとか、そんな話一度も出てないだろ？

>>416
モジュールとかブート部分とか
一度しか使わないコードばっかりなんですがそれは・・

>>421
ごめんキミとは会話できない

>>415
書いてなくてもLinuxやWindows 2000カーネルや
PostgreSQLとかはそうじゃん

構造化プログラミング（こうぞうかプログラミング、structured programming）とは、1960年代後半にエドガー・ダイクストラらによって提唱された仮想機械モデルに基づく段階的詳細化法を用いたプログラミングのことを言う。

>>422
そこにコールバック以外で一度しか呼ばれない関数はあった？
あったら貼ってくれ。

>>423
そのまま返そう。

>>425
ごめんgoto禁止論の話してたわ

>>421この釣り針は・・・

>>416
なんで俺たちこの構造化もオブジェクト指向も理解できないアホを一所懸命教育してんの？

>>425
でもその内容って反復とか分岐の話で局所変数の話は、出てこないよな。
モジュールの概念も無いし。

gotoは構造化を壊すという話しはあるけど、
構造化とはgotoを使わないことだ、という話はない。

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

>>429
goto禁止の論文に書いてある内容だよ
それに基づいていgoとかはブロック間で行き来したり、
上に戻れない限定されたgotoが搭載されたよね

>>426
では今適当に調べた知らない関数を
http://lxr.linux.no/linux+v3.12.1/+code=deinit_rsq

>>431
I 構造化プログラミング論
12 プログラムのモデルについて
で
局所的な変数について言及してる

>>435
抜粋よろしく

>>426
次にすぐ上にあった関数を
http://lxr.linux.no/linux+v3.12.1/+code=init_rsq

>>435
お前ふざけんなｗ
これはつぎの２つの重要な面を反映していました。
第１番目は、”有効範囲(scope)”の概念です。
。。。

くそｗ
>>438>>は>>436だった・・・

>>426
では次にあなたの感想をどうぞ

関数にしろ、クラスにしろ、機能として必要になるまで、分割する必要はないだろう。

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

糞コードをリファクタリングするときに真っ先に手を付けるのは巨大関数の構造化だな。
関数が小さくなるだけでもレビューやトレースがかなり捗る。

コールバックは、ホモっぽい

441がオブジェクト指向、ユニットテストときて、
契約プログラミングまで身につけるには100年くらいかかりそうだなこりゃ。

>>443
バックってそういう・・ってバカ！

ひとつのスレは1000行まで（キリっ
ひとつのレスは3行まで（キリっ

>>437
そのコードも200行超がザラだな。
あと確かに一度しか呼ばれない関数もあったな。
ただその関数は将来再利用すること前提の関数だな。

>>442
構造化された関数は？

さすがに必死すぎ

>>442　>>437みたいな構造化された巨大関数も、
でかいからって壊すの？

動作しているコードをリファクタリングするのはそれなりのリスク。
だから書いてるときに分割できるならそれに越したことはない。
もちろん時間の関係上常にできるわけじゃない。

分量を目安にして分割した場合、その関数に簡潔な名前が付くか疑問だ。

>>444
オブジェクト指向でも再利用できんコードの分離は望まれてないよ。
例えばSmalltalkはブロックを多用し、出来るだけ1箇所に書く。
長いメソッドよりまとまらない処理の方が嫌われる。

＞オブジェクト指向でも再利用できんコードの分離は望まれてないよ。
ソース

一回しか呼び出されない関数はまとまってるだろ・・・

高頻度で再利用できるに越したことはないが、
上のほうでだれかが言っていたが、
関係する変数を関数内に隠せる場合、
その分だけでも片付いているのは事実。

>>444
1箇所しか呼ばれない関数を分離する事と、プロトコルにあわせてメソッドを分離することは違うぞ。

>>447
200超は一つで、200前後で見積もっても3ぐらいしかない
コードは2.4.16から変わってない上にstatic定義だから
将来の再利用性というよりは機能の分割目的だろう

>>457
言い方が違うだけで、言ってること同じじゃないか。
何を今更。

>>454
PharoのSmalltalkクラスオブジェクト
Smalltalkの中じゃかなり長いメソッドが多いが、
再利用できないメソッドはおいてない。
サードのコードが入ってないSystem系はだいたいそんな感じ。
あるとすればExample系位だよ
間違えて再利用できないメソッドにメッセージ送っても危険だしな。

>>460
＞間違えて再利用できないメソッドにメッセージ送っても危険だしな。
少なくともprivateのある現在の言語には関係ないな

>>459
確かに、呼び出してはないがプロトコルに使われてるわけで、
プロトコルに必要とすらされない単なる分離された関数とは違うだろ。
それ言い出したら、コールバックも割り込みも同じ扱いじゃねえか。

結局思い込んでただけと

>>461
メソッドにprivateなんて要らんけどな。
それこそOOが出来てない。

>>464
ハイ終了

以下、>>464の超理論をお楽しみ下さい。

Simulaから脈々と受け継がれてるprivateを要らないとまで言って
何を主張するつもりなんだよｗ

アンチデマルコのコマルデ君はまずwikipeiaで凝集度のアーティクルを読むべき。

じゃあ最初の定義を訂正すればいいわけだな。
申し訳ありませんでした。

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

>>467
変数用だろアレ

>>462
内部的な設計分離をプロトコルと言ってるのかと。
なら違う扱いであってると思うよ。
きちんと、別物の前提で話してるだろう。

>>467
幾つかの言語はデフォでprivateなのは変数だけ

>>464のOO
・privateは変数専用である

普通って大学の情報学部では何の言語習うもんなんだ？
Cとjavaとアセンブリ言語しか必修じゃないけどこんなもん？
選択でRubyもあるけど

>>470-472
よくないよなアレは
publicとかprivateとか恣意的に変えられないようにすべき

>>471
インターフェースとかAPIとかと同じ意味合いだよ
主に実装の抽象化を目的としたやつ

正直protectedはいらない
処理委譲したいならインターフェース渡せばいいだけや

>>476
ならやっぱり同じだろ。
レイヤでの分離以外に、分離する理由がないだろ。

ボコボコにされて主張変えたンゴｗｗ

>>473
Smalltalk系統はそうだよ。
Selfやjavascriptに関してはprivateすらないけど。
そもそもC++系統のコンパイラーの実装がめんどかったんで、
スコープ修飾子は関数か変数か区別しません系とは
考え方が違うからな。

XScreenSaverの168個のスクリーンセーバーを移植したよ。
http://katahiromz.web.fc2.com/xscreensaverwin/
https://github.com/katahiromz/XScreenSaverWin

>>478
非難されてんのは、行数減らすのが目的で、実装も抽象化できない関数だから。

結局
・一度しか呼ばれない関数は読みづらいだけ
・関数というブロックより一段厳しいスコープによる可読性
のトレードオフってことでいいよね？

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

最近の言語は訳がわかんねえズラ
インターフェースって何ズラ
仮想関数と何が違うズラ
デリゲートって何ズラ
関数ポインタと何が違うズラ
じじい着いて行けねえズラ

>>480
どんどん病気が酷くなってくなｗ

まあ何だかんだ>>469みたいな行数減らす目的の
関数は>>385 >>387の理由で読みづらい

>>485
C++ってprivateでもオーバーライドできるんやでスゴイやろ

またダイクストラ無視かよｗ
つか>>385>>387では
ダイクストラの「プログラムの段階的作成」はどういう立ち位置になるわけ？

強引に結論にしたな。
>>385 >>387だけから>>469を導き出すって無茶だぞ。

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

じゃあmain関数は一回しか呼ばれないから分割禁止な！

>>488
ダイクストラ全く関係ないよな

Smalltalkerにキチガイが多いのはなぜなんだ

>>492
>>425>>491
これでも理解できない？

>>493
自分の主張が通らないときちがい扱いか
経験も根拠もないくせに

>>494
お前は例の読解力のない基地外か。

＞経験も根拠もないくせに
これ笑うとこ？ｗ

>>493
SmallTalkerどころかLoudSpeakerｼﾞｬﾈｰﾉ

>>496
お前のそのレスいろいろ読解力ないことがばれてるぞ

>>491
main内で静的変数使ってコマンドラインを再帰解析だ
これならニ回以上呼ばれる

>>500
いやいや外から呼ばれるのは一回だからとマジレスｗ

>>464
そういうあなたは、冗長な文章書いてた人ですね。

>>502
な・・ならmainを呼ぶだけのmain_externalを作れば・・

>>494
一度しか呼ばない関数を分割するな
じゃなく
抽象化やコールバック目的、プロトコルに準じる目的以外で、
一度しか呼ばれない関数を作るなと言ってるんだけど

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

>>503
それはmainから呼び出すので内部を分割しているのと変わりませんね
とマジレスｗ

>>501だた・・

>>499
>>491これを見てどう読解できるんだよ

スコープを限定できる関数化が抽象化じゃなくてなんなんだ

>>497
じゃ煽るだけじゃ無く
お前の豊富な経験で反論してみろよw

>>508
COBOLer?

ダイクストラの段階的詳細化法は抽象化ではないのか

>>505
くそ・・じゃあエントリポイントを書き換えてmainを2回呼んでやる！

まじで>>511だったか・・・

>>508
関数外に依存してりゃ抽象化にならねえだろ

>>514
まあそういう意味では完全ではないが一段限定されるでしょ。
変数スコープに限らなければ>>511

>>514
説明をお願いします。

>>511
お前が段階的抽象化論の意味を間違えてるように見える
段階的抽象化ってのは実装に依存しないようにしましょうって話だ
今回の話とは関係ない

>>516
外部に依存する=関数の呼び出し元を変更すると関数内部に変更が必要な場合がある
外部に依存しない=関数呼び出し元を変更しても関数内部の変更は不要

>>511
段階的抽象化には実装から独立したプロトコル(規約)が必要だろ

>>517
それだけじゃないでしょ


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

うん？

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

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

>>519

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

>>516
ある関数から呼ばれなくなった途端、
削除されたり名前が変わったりするのは抽象化と言えんだろ。
抽象化してたらシグニチャーを簡単に変更できない。

関数を使っている場所にテストコードを含め内にしても、
テストをやる理由を考えて見ればわかる。

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

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

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

屁理屈大会になってまいりましたｗ

>>518
ありがとう。でもちょっと理解できなかった。
一方の変更で済ませられないって、どういう場合？

つまり
＞大きなプログラムの理解を助ける段階的な抽象化(step-wise abstraction)
は抽象化ではないと。

>>522
移植性を上げたり、再利用性を上げる上での基本だろ。
外部に依存してたら、最初から外部の一部にしておいた方が、
名前の変更だの引数の変更だの発生せず遥かにマシだわ。

関数ってのは処理のフックポイントなんだよね。
関数の呼び出しの前後で、何かが変わる。

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

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

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

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

>>521
それは形だけだろ、呼び出し元に依存してたらテストしても意味ねえよ。

>>530
なら呼び出し元に依存していなければいいだけの話。

>>528
うん屁理屈だね
分割しなかったら再利用性が高まるとかないから。
数１００行にもわたるコードを１つ関数として切り出したところで
作業が増えるどころか見通しが上がるほうが多いよ。

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

例えばライブラリを作ることを考えよう。

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

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

答えられるかい？

>>526
関数の行数を減らす目的で、関数の一部を別の関数に無理に分離した場合。
必要な引数が変更になる度に呼び出し元、呼び出し先相互に影響を受ける。
それから、呼び出しもとが使わなくなると大抵削除されてしまう。

必要な引数が変更にならないような単位で
関数化すればいいだけじゃないかｗ

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

>>534
お前が作ってるのは、関数ではなく
サブルーチンだよ。

関数を作れ。

>>534
それはおかしい。
その修正は同じ箇所にあってもほぼ同じ量修正が入ってる。
違うのは関数のインターフェイスがあるかないかだけ。
これって１行しか差がない。
その数１００行で１行分すら惜しいと言う感性が理解できない。

>>532
呼び出し元から不要になるたびに削除
引数が増えるたびに引数追加でテストも変更
やっとられんな

関数化が下手
↓
関数にする
↓
いろんな面倒事が起きる
↓
だから関数にするべきじゃない
↓
一回しか使わないものは面倒なだけ。


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

>>538
それテストの粒度荒くしただけ

>>538
いや、だから、なんでそんな関数作るの？

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

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

>>535
そういう行数減らすための再利用できないヘタな関数つくんなって話だ。

>>534
もう考え方が違うんだな。
目的は置いておいて、名称付きの関数が抽象化された物と考えるなら、
引数の変更は実装ではなくて、抽象モデル自身の変更になる。

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

この馬鹿がどんな関数を作るのか
見てみたいなｗ

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

>>541
一度しか呼ばない再利用できない関数がそれ以外にあるか？

>>542
頭悪いな。

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

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

>>542
段階的詳細化って総コード量はお前も指摘するとおり増えてるぞｗ

一回しか呼ばないことと、
きれいな関数が出来るかどうかは
全然関連性がないよね？

これが答えだよ。

>>469を非難する奴の関数をみてみたいなw

>>545
もしかして関数化する目的は、
再利用だけだと思ってないか？

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

>>547
総コード量が重要なのではなく
メンテナンス性の方が重要だからね。

>>546
上手な関数は再利用できるだろバカ

>>552
再利用できるが、再利用しない場合はどうするんだ？
それが一回しか呼ばれない関数なんだが？

>>547
総コード量じゃなくて関数内のコード量を言ってんだよ

再利用可能なのと
再利用するかどうかは別の話だよね？

>>553
それは今回の対象になってないだろ

>>552
できるのとするのは別。
可視化のためにサブルーチン作るのは有意義。
平行線辿り過ぎてるわ。

>>551>>554
>>537はどう理解してるの？

ほら答えでた

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

>>553
>>385を読む限り駄目

>>553
>>469

一回しか使わなくても（再利用しなくても）
再利用可能な関数を作れる人ってのが
技術力が高い人であり、

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

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

>>560
じゃあ>>385が間違っているってことで
終わりじゃねーの？

再利用可能でなくても関数にする方が基本的にはいいよ。
可読性が上がるという意見が何度も出てるでしょ。

あとテストが可能になるっていう理由もあるね。

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

>>559
>>469にも書いてあるしそれでいいんじゃない

テストが面倒だから関数作らないって

長い関数だったらテストどうするのさ？

>>565
テストはインターフェースが固まってない関数にしちゃいかんのよ
Xcodeユニットテストガイドやケントベックがゆってた

テストするために関数化するっていってるやつはユニットテストの目的解ってないニカワ

>>569
奴は先にテスト書くから・・

で固まった後もテストしないんですね
わかります

まてまてテストできるかもわからない１０００行レベルの関数を
そのままリリースするつもりか？

http://otndnld.oracle.co.jp/products/jdev/pdf/905/J-gettingstartedwithunittesting.pdf

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

>>570
coverage的にも分岐は関数化したほうが良い。
無駄にテスト項目増える。

>>573
1000行の関数をテストすりゃいいだけだろ
glibのvsprintfの関数とかクソなげぇけどテスト書かれてるぞ

>>575
ホワイトテストはすべきじゃないんですって

>>576
１０００行の関数が外部からテスト可能って動作実績があるもののおまけだよ

>>577
ホワイトテストじゃなくてホワイトボックステストな
境界値とかも分岐が小さいほうが手間かからないんだよ

>>578
そういう問題じゃない
そもそも無理にホワイトテストはしちゃいけない

>>578
テストがおまけって意味？
そんなことないだろ。

ホワイトボックステストすべきじゃないなら
どうやって自分のプログラムの動作を保証するの？
テストのコストもあるから
最終的にはブラックボックステストしか残さなくても
１０００行もの関数をテストもせずに新規実装リリースするつもりか？

>>579
内部を一部切り離そうが切り離すまいが、
ホワイトボックステストのテスト項目は変わらんだろ

>>583
・・分岐網羅とかホワイトボックスだよな？
むしろホワイトボックステストの方は劇的に変わるはずだが

>>584
ごめんブラックボックステストの間違いでした

>>582
普通に関数の仕様に基づいてブラックボックステストだろ
仕様外の動作も保証する気なの？リファクタリングどうすんの？

>>574とwikipediaの記述は矛盾してるな
単体テスト、あるいはユニットテストとは、
メソッドなどの小さな単位で行うテストのことである。
単体テストは、ホワイトボックステストを利用して行われる場合が多い。

>>586
その仕様が固まっているなら
１０００行もあれば簡単に内部分割できるでしょ。

>>586
仕様決まってない段階なら
ゴッドオブジェクトならぬゴッド関数作るより
細分化したほうがブラックボックスでもやりやすいだろ

>>587
俺でも編集できるWikipediaが正しいとかw

>>588
関数化した関数が>>469を満たして無ければしてもテストしても意味ないぞ

1度しか使わないつもりで作った関数でも、
後の仕様変更で複数回呼び出すようになるなんてことは普通にあるぞ。
再利用性の問題よりも、分割によって元の関数や別の関数との結合が疎になることのほうが、
仕様変更に対する柔軟性を高めるために重要だけど。

またそれか

>>589
再利用できない単位に分割すると、関数の作り直しで時間を食うし読みづらい

一人対多数になって、誰も賛同者がいないのに勝利宣言するというのが一番寂しい。

>>591
意味ないわけないでしょ。
自分の実装を確かめる手段を構築するんだよ。
その手段が外部に要求されてないなら公開する必要がないだけ。
おまえは良くわからないから全体が動けばいいやと言ってるわけだが
関数全体のテストはすべて周りが用意してくれるのか？
そのレベルだったら１０００行にならないだろ。

>>592
最初から再利用できる関数は対象になってないんだよ。何回同じ話繰り返すんだ。

>>594
>>537

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

>>597
最初から再利用できない関数がその後仕様変更で変わるという話なんだけど。

要はテスト面倒だから関数分けたくない。
大きい関数でもテストの妥当性なんて誰もチェックしてないし。
ってことか。

>>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)

>>599
oracleとatmarkどっちが正しいんでしょうねぇ

>>601
ブラックボックステストはしてますしお寿司

>>601

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

>>602
行数変わってねえじゃん

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

例えばトレースをするときに、ステップインするかステップオーバーするか選べるだろ？
何回かステップインして、ここはもう絶対問題ないと確定した関数はもうステップオーバーするだろ？
こうして問題ないところをどんどん除外していくと、トレースが加速して楽になって行くだろ？
関数をブレイクダウンしないと、こうやってテストの範囲を絞っていけないだろ。

デバックしなければ解決

>>608
ブロックこえたところにブレークポイント置くのは手間じゃないんだって

>>606
行数じゃなく手間だよ

>>597
再利用できない関数ってなんだ？

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

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

>>607
関数移動しないでいいならそれが一番だろ
そう書いたら0か1かしか言えない上に鶏頭だから関数使うなとか言い出すんだろうな

>>602
これが手間と思えるくらいのIDEとエディタの使い方なんだよ
デバッグも推して知るべし

>>464
> メソッドにprivateなんて要らんけどな。
> それこそOOが出来てない。

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

関数にすることで、ブラックボックステストがしやすくなるよな。

>>612
>>518

>>613
つまりキミはワンクリックの手間がおしいくらい
スコープ・関数のメリットが感じられないわけだね
もし仕事してるとしたら同僚に同情するわ

>>605
> ユニット・テストでは、クラスがどのように実装されるかではなく、クラスが何
> を行うかに重点を置く必要があります。クラスのホワイトボックス・テストは、
> privateおよびprotectedメソッドもすべてテストすることになり、それによる実装


え？

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

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

>>614
IDEのマーカー機能とか折りたたみ機能使えないお前に言われたくない

>>617
ワロタｗ

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

まず、関数ってのは再利用できるもの。

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

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

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

>>618
マーカーつけたブロックに飛ぶんなら構わないんだどねぇ。

>>464
> メソッドにprivateなんて要らんけどな。
> それこそOOが出来てない。

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

関数にしたものは、引数は基本的に変わらないものなんだよね。

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

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

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

>>622
>そうでないものは関数に似た別のものだ。
それを書くなって話だろ終わりじゃん

なんのためにprivateメソッド作るの？

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

>>619
お前はどんなテストをする気なんだ？

ちょっと見えた。
何で関数移動が手間だと思うのか。

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

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

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

>>626
> それを書くなって話だろ終わりじゃん

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

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

>>627
OOできてない、の部分を知りたいんだが。なぜなのかと。

private関数なんてあんのはC++系統と.net framework系ぐらいだよなぁ
しかもC++にprivate関数が作れるのは、構文解析を高速にするため
関数と変数の区別をしないて理由以外に特に理由はないし

privateメソッドはテストできない（テストしない）のだから
関数にする理由ないよね？

>>630

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

いやだから、>>464さんはもうここにいないのかな？
privateメソッドがあって、なぜOOできてないという結論に達するのか。
その課程が知りたい。

最初は一度しか呼ばない関数はどうたらって言ってなかったっけ。
主張変わったのか。こっそり撤退の道を探っているのか。

＞private関数なんてあんのはC++系統と.net framework系ぐらいだよなぁ

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

>>633
そもそもprivate関数がいらんだろあんなもん
Python, Ruby, Go, Pharo, javascript・・・
Smalltalk系統の言語にゃないしC++の負の遺産だ

こっそりGoを混ぜるあたりがｗ

>>636
>>469

haskeller大激怒スレ

private メソッドとOOPってなんか関係あんの？

再利用性という尺度で評価できるんだよ。
それを問題にすべきだったんじゃないの？

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

いや関数化によるメリットは再利用性以外にもさんざん指摘されてるんだが

>>642おれもそれが謎。>>464さん曰く、

> メソッドにprivateなんて要らんけどな。
> それこそOOが出来てない。

らしいが。

そういやLispもGObjectもprivateメソッドなんてないな

ある程度長くてそのクラス内では何度も使う処理だけど、他のクラスからは無価値なメソッドとかはどうするの？

関数として名前つけるだけでも意味あるぞ。でないとブロックの説明コメントをグダグダ書くことになる。

>>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

お前が知らんだけだよ。

>>643
>>469

GObject支持派のOO信者珍しすぎるｗ

>>648
その場合、関数名がグダグダになるという現象に悩まされるんだが。
それは俺が超絶愚か者だからかな？

>>647
ブロックオブジェクトあるいは無名名前空間に定義

actionscriptも3になってprivate付class導入してなかったか？

>>469って馬鹿だな。
言っていることが的はずれすぎる。

>>652
コメントが打てるなら関数名つくだろ
つまり・・・

>>648
関数として名前つけられて、#pragma markみたいなブロックマーカーには何故名前を付けられないのか？

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

>>630
>うん。だから1回しか使わない "関数" はありなわけだよ。
>
>だって、関数である以上1回しか使わなくても
>再利用可能なわけだから。

あれ？ どうなってんの？
一度しか呼ばない関数は読みづらいけどありなの？

>>657
ブロックと関数ではスコープの扱いが違うから

>>658
必要悪だろ
switch使うよりオブジェクトの多態の方がいいけど
絶対switch使わないのか？

> 469 名前：デフォルトの名無しさん[sage] 投稿日：2013/11/23(土) 16:33:41.28
> じゃあ最初の定義を訂正すればいいわけだな。
> 申し訳ありませんでした。
>
> コールバックではなく
> かつ
> プロトコルで要求されていない
> かつ
> 再利用される予定もなく
> かつ
> 一度しか呼ばれない関数は読みづらいだけ

ようするに、

駄目なやつが書いた関数は読みづらいだけ

一度しか呼ばれていても、
コールバックだったり、プロトコルで要求されていたり
再利用されれる予定があったり、するものは読みづらいとは限らないと

自分でそう言っているのだから、この話は終わりじゃね？

「privateメソッド」と「OOP出来てない」の関連だけでもはっきりしてから今日は眠りたいんだがｗ

>>659
それで >>386-387 ここに戻るわけだ
で
>>469 に戻り
>>386-387 に来て
また>>469に戻る
以下無限ループ

XScreenSaverの168個のスクリーンセーバーをWindowsに移植したよ。
http://katahiromz.web.fc2.com/xscreensaverwin/
https://github.com/katahiromz/XScreenSaverWin
迷路もあるよ！

>>663
それで >>386-387にもどるのなら>>618
と言ってるから無限ループにしているのはお前

>>662
OOの考えならprivateメソッドにするぐらいなら、別のオブジェクトに委譲する。
privateメソッド呼び出してんならCで関数呼んでるのと同じ。OOPができていない。
以上。
満足か？

ブロックだとその関数内の変数全てにアクセスできてしまう。
情報隠蔽、疎結合、副作用などの観点から良くない。

プログラムを上から下にしか読めないやつにとっては、一度しか呼ばれない関数は読みづらいだけ。
そういうやつにはBASICが向いていると思う。

結局、俺が言った点でもってみんな同意できるんじゃないの？
メリットデメリット踏まえたうえで、名前グダグダの関数名を作っちゃうべきかどうか。

それとも、プロの人は名前グダグダになんて一切ならないのかな？
それともAaaBbbCcccDdFffGGGudaguda(Foo foo, Bar bar, Buz buz)みたいな関数に問題は無いと？

>>667
{
　int a;
　{
　　int b;
　　a;//○
　　c;//×
　}
　int c;
　{
　　b;//×
　　c;//○
　}
}
{
　a;//×
}

privateメソッドの機能を委譲すると言うことは
private変数いじれる内部関数がないからおかしくないか？

>>659
それで >>386-387 ここに戻るわけだ
で
>>469 に戻り
>>386-387 に来て
また>>469に戻る
そして>>661で終わり

APIなどには、そのアプリケーション内で一度どころか一度も呼ばれない関数もあるわけだが。

>>669
>>661

終わった話。馬鹿な奴が書いたらだめになる当たり前のことで
それ以外の要件は何一つない。

そう。この話は終わったんだよ。

関数はあるべき形に作ればいいってだけで、
そんな一回しか使わないものはだめみたいな
簡単なルールはない。

グダグダな関数名でもうそがなければ関数スコープある分まし
うそがあるならfoobarつけとけ

>>675
関数のあるべき形に
2回以上使っていなければだめ。

という要件はないってことだね。

http://www.slideshare.net/MoriharuOhzu/ss-14083300

Jeff Beyのクラス設計を綺麗にするトレーニング。
いいコードを書くイメージを付けるトレーニングなので、
実際の業務ではもっと緩くていいけど、
ここでも関数のサイズを厳しく制限する練習をさせられる。

ルール1：インデント１段階
1つのメソッドにつきインデントは1段階までにすること
ルール2：else句禁止
else句を使用しないこと
ルール3：プリミティブ禁止
すべてのプリミティブ型と文字列型をラップすること
ルール4：ドット１つ
1行につきドットは1つまでにすること
ルール5：名前省略禁止
名前を省略しないこと
ルール6：小エンティティ
すべてのエンティティを小さくすること
ルール7：インスタンス変数２つ
1つのクラスにつきインスタンス変数は2つまでにすること
ルール8：ファーストクラスコレクション
ファーストクラスコレクションを使用すること
ルール9：プロパティ禁止
Getter/Setter/プロパティを使用しないこと

クラスの単純化を突き詰めると今度はオブジェクト間の連携が難しくなってくるので、
そのあとはデザインパターンを学ぶといい。

>>674
そうかな？
ブロックの説明がグダグダになる場合、
それを関数名に置き換えたらスッキリするとでも？

もしそうだというのなら、俺はコレに関して本当に黙るｗ
そして滝に打たれてゼロからやり直してくる。

>>678
重要な行を忘れてるぞｗ

断言する。これらのルールを破らずに1000行のプロジェクト書いたものはOOがうまくなる。

よって望めば制限を和らげることも出来るようになる。でも作者が指摘するのはそうする理由はないということ。

彼のチームはちょうど100,000行のプロジェクトをこの制限のうちに終えたところなんだ。

関数化しとくとこの関数内ではこの変数しか使われてませんよということが明示できる。
C#のように引数の入出力が明示できればなおよい。
そうすると別人が後から追加拡張修正するときにこの関数内には引数にない変数zを使う処理は書き加えてはいけない
だから別のところに書こうというヒントがあたえられる。

>>679
>>>674
>そうかな？
>ブロックの説明がグダグダになる場合、
>それを関数名に置き換えたらスッキリするとでも？

どう考えてもスッキリする。
即答だわw

>>678
さすがに詐欺としか思えないけど

＞ルール2：else句禁止
これはなぜ？
＞ルール4：ドット１つ
これすごくない？
＞ルール7：インスタンス変数２つ
階層深くならない？

>>671
そもそもprivateメソッドなんて何に使ってんの？

>>673
>>469
しつこい

>>676
>>670
ブロックはスコープ付けるためのもんやで
これに#pragma markとかIDEの機能使えば名前も付けられるんやで

つまりお前はすべてpublicで書けると言いたいだけですね
３０００行ないとかけない処理があったとき
その３０００行すべてに渡ってprivate変数をアクセスしようとすれば
そのpublic関数が3000で書かれるか、
public関数を分割して順番に呼んでくださいとコメントに書くのですね。
じゃなければうまく委譲するようにクラスデザインをあーだこーだやるわけですね。

>>686
お前が理解してないのかわざとなのかわからんが
何度も指摘されているように一般的な言語では
ブロックは外のブロックが参照可能。

>>680
1000行のプロジェクトだと複数呼ばない関数書くと余計行数増えるんじゃ・・・

>>683

>＞ルール2：else句禁止
>これはなぜ？

×if (i==x) { a=x; } else { a=i; }
⚪︎a=i; if (i==x) { a=x; }
こうしろってことだね。
俺は好きではないけど、昔からよく言われてるよ。

>＞ルール4：ドット１つ
>これすごくない？
これはクラスの責任範囲を考える、
つまり言い換えれば疎結合を徹底しろってことだね。
実際のプロジェクトではそこまでやらなくてもいいと思うけど、
汎用性を高めたいとき、重くなった責任を軽くしたいときに
ドット数が減るように直すことはよくあるはず。

>＞ルール7：インスタンス変数２つ
>階層深くならない？

深くなると思う。これもなかなか守れそうにない。
でもインスタンス変数が少ない=クラスの責任範囲が絞られている、
というのは理解できる。

関数の細分化も、クラスの細分化も、
結局は名前が付けにくい単位に突き当たる。
当たらないという人は命名の名人か、アホ。

>>688
>>670 を理解してるのか？

クラス委譲による記述場所の分散は良くて
メンバ関数による記述場所の分散はダメって理屈がわからん

>>690
極限を見る練習ってワケか。
まあちょっとどうでもいいや。
サンクス

>>693
privateメンバーがだめって話。
再利用できんだろうし、再利用できない処理の記述を促進する。

>>670
理解できない
　a;//×
ってなに？

>>693
privateメンバーがマトモだと思うんなら、privateメンバーが必要なコード書いたことあるんだろ、
それをココに貼ってみ綺麗な形に書き換えるから。

>>696
そこの行のaは参照出来んだろ

>>697
そのレスの時点でアホ
長い関数をどうやってここに貼るんだよ

>>697
横からだがそもそもその、
privateメンバー＝privateメンバ変数＋privateメンバ関数
ってこと？

>>691
向いてないな

>>698
#include <stdio.h>
int main()
{
int a = 1;
{
printf("%d\n",a);
}
return 0;
}

で結果が1っでことであってる？

>>679
>>661

>>685
お前こそしつこい



674 名前：デフォルトの名無しさん[sage] 投稿日：2013/11/23(土) 19:25:49.18
>>669
>>661

終わった話。馬鹿な奴が書いたらだめになる当たり前のことで
それ以外の要件は何一つない。

>>699
ム板に来るのは初めてか？ここに貼れよ
ideone.com

>> 700
private関数限定の話

>>702
#include <iostream>
int main()
{
　{
　　int a = 1;
　}
　{
　　std::cerr << a << std::endl;
　}
　return 0;
}

>>678　２つだけは完全に間違っている。

ルール7：インスタンス変数２つ
いくらなんでも子供は２人までというくらい理不尽である

ルール9：プロパティ禁止
Getter/Setter/プロパティを使用しないこと
いやいやいやいや必要に応じて使用するのが正しい。

ああわかった気が。
論点は>>702のaが見えてしまうのは関数より制限がゆるいというのであって
#include <stdio.h>
int main()
{
{
int a = 1;
}
{
printf("%d\n",a);
}
return 0;
}
が見えないことではない。

privateメンバー関数が必要な例はマダー

>>707
まぁPropertiyパターンはあんまり使うべきじゃないな
WikipediaのSmalltalkの記事みてみりゃ面白い

>>708
関数でもグローバル変数使えば外の変数は見えるわけで、
どっちかというと、なんども呼び出せないブロックのほうが制限は強いんだがな。

>>709じゃあとりあえずこれ
http://code.google.com/p/box2d/source/browse/trunk/Box2D/Box2D/Dynamics/b2Body.h

>>711
変数にアクセスする制限は関数のほうが強いでしょ
関数を呼び出されて問題になるケースは何？

>>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)
から呼ばれているようです。

>709
NonCopyable作る時

俗人にはもっとわかりやすく説明した方がいい

旅館の全ての部屋にカギがついてなかったら防犯上よくないだろ。

>>713
関数の呼び出し元で操作している対象の変数が何かわからない(広域変数の欠点)

int a, b, c ; // グローバル変数宣言
int main (int argc, char *argv [])
{
　FunctionA(); // グローバル変数cを書き換える
　FunctionB(); // グローバル変数cを元にグローバル変数aを書き換える
　FunctionC(); // グローバル変数a, cを元にグローバル変数bを書き換える
　return 0;
}

>>717
判ってると思うけどそれグローバル変数の問題で
スコープでも問題は変わらない

>>715
それはしょうがないな

>>714
普通に考えて、
StringBounds.check( byte[] bytes, int offset, int length );
に委譲すりゃいいわな
Javaのライブラリーって他のライブラリーに比べて出来が悪いわ

一発降参ワロタｗ

>>719
StringBoundsが含まれているパッケージを探すコストを考えたら、近くで定義した方がいい場合も多々ある。

>>718
どういうことか解かりませんっ!!

>>712　他人のコード晒してんじゃねぇぞタコ

>>721
Javaは同じファイル内に複数クラス書けるから
同じファイルに書いときゃいい

>>722
まじか・・・
ブロックで書こうが外部関数の呼び出し無しではないわけで
(まさかこれ否定しないよね)
その関数がグローバルを使っていてかつ、自分が直に書いたブロックにも
グローバル変数があるのなら同じ問題がおきるってこと

>>719
公開する必要はないでしょ
そんなのでいちいち実装が変更されない保証とかしてらんない

>>723
有名なBSDライセンスのオープンソースですが

private int min(int x,int y){return x<y?x:y;}
が何故Mathに定義されてないのか考えたけどこいつばかりは毎度再定義した方が実行効率がよいようだ。

>>725
int main (int argc, char *argv [])
{
　int a, b, c ; // グローバル変数宣言
　FunctionA(); // グローバル変数cを書き換える
　FunctionB(); // グローバル変数cを元にグローバル変数aを書き換える
　FunctionC(); // グローバル変数a, cを元にグローバル変数bを書き換える
　return 0;
}
こんなんしたらコンパイルエラーやで

>>728
そしてCollections.minしか使わない現実

だれか>>729を翻訳してください

>>726
他の言語とおなじく仕様としてドキュメントに書かなきゃいいでしょ
あとどうでもいいけどclassをpublicにしなきゃJavaの場合公開にはならないぞ

ああ本末転倒ｗ

>>728
今のVMじゃ大したコストにならんだろうに

>>732
意味がわかりかねる。
privateスコープで公開メソッドのみのローカルクラスを用意するって意味？

>>735
まさか、こんな感じで宣言できるの知らないのか？
// string.java
class StringBounds
{
}
public class String
{
}

あれ？private君は関数切り出し反対派じゃなかったっけ？
委譲で切り出すのは問題ないんだ？

>>734
普通に遅い
どうせ中身はJNI委譲してるだけだからネイティブかVMで直接計算したほうが速い

>>736
あの、言ってること理解出来てる？

>>739
>>735はこういうこと言いたかったんじゃないの？
public class String
{
　private class StringBounds
　{
　}
}

>>740
staticならあってる
パッケージプライベートじゃString以外で使えちゃうでしょ
だから実装を保証する必要があるよね？

他の言語同様パッケージ外で使わなきゃいいだけの話だし

>>742
だから少なくとも同じ名前空間では同意が得られないとだめだろと
これでは意味が違う
必要と言うまでは反論するぞ

>>715で終わってるだろ。はい次。

>>743
他の言語と同様同意を得ればいいだろ

>>745
では結局保証が必要という事で終わり

>>743
大体おんなじパッケージ内の他の箇所で使われたって問題ないだろ
この処理が共有されて何の問題になる
どんだけ不特定多数で同じパッケージ共有する気だよ

>>743
必要だから同じ名前空間内で共有してんだろ

「内部処理を細かく分けるとぼくちゃん探せないから許してよ」
って戯言でよくここまで伸ばすな

>>743
ドキュメントに無いメソッドをパッケージ外に公開したくないだけだったら
別にprivateじゃなくていいだろ

>>747-750
とにかくpublicにするという話が元なんだから、
後悔する必要がなくても公開するという話でしょ？
必要ならそりゃ公開するしかないでしょ

>>751
そもそもパッケージ外ならともかく、共有できるメソッドをなんでprivateにするんだ。

>>751
意味不明な事をかいたな。訂正。
アクセス制限をパッケージ内に限定しているにも関わらず再利用できるメソッドをなんでprivateにするんだ。

必要ないものもpublicにしてもいいのならそもそもメンバ変数もprivateいらない

C++のpublic,protected,private
javaのpublic,protected,private,default

どれが必要でどれが不要なのか、また新たに定義した方がいいのか
今開発中の言語に生かすので教えてくだしあ。

>>754
メンバー変数のprivateと関数のprivateだと意味合いがだいぶ違うんだが

>>754
メンバー変数のprivateは、メッセージ経由でアクセスを強制するために居るもの、
逆にメンバー関数側は、privateにしてもあまり意味がない。

>>756
その認識がすでにおかしい
具体的に意味合いの違いを述べてみよ

メンバー関数はprivateメンバの更新権利持ってるんだから重要性は変わらない

hoge ここに変数があって

f = なんとか　ここで関数を定義したときに

fの中でhogeをどうかするときに変数につける修飾子に問題があるというか
トリックみたいな書き方してお茶を濁すみたいなことあるからここらへんは新言語で一旦再編成して欲しい

>>759
最初から外部から操作してはいけないような操作をメンバー関数にしなければいいだけの話。さらにそういう関数は、privateだろうがpublicだろうが作りが悪い。

>>761
言語は共同作業のベースでもあるので
俺はやらないからいらないと言う理屈は通らない
話にならん

private関数による関数分割の可読性向上は認めないけど
委譲による分割による隠蔽は認めると言うのも独善的な視点
さらにいえば委譲のほうが関数分割より設計・修正のコスト高い

ん？やっぱ他人？

計算速度とかメモリ量とかが無限なら可能な限りカプセル化した方がいい

ただ絶対に死なないように値チェックとか各カプセル内でするようになると同じチェックを何回もするようになるから
だったらそこは外に出した方がいいんじゃないかみたいなことになる

>>762
privateメソッドの無い他の言語ならprivateなんて使わんだろ
他の言語なら上手く行ってることがなんでC++系統の言語だけ上手くいかない
そんなわけあるか

>>765
何を言ってるのか理解不能

>>765
じゃあCでlinuxカーネルはうまくいってるからOOPLはいらないな

そもそもの主張がわからないというか
publicとかで躓いてるやつ今まで見たことないんだけど

privateメソッドの無い他の言語でも
頭にアンダーバーをつけるなどして
工夫しているから、結局いるんだろうね。

関数の名前というのはコメントでもある。
英語圏の人だとすんなりわかるんだろうということで
日本語で関数名を書くけれど。

function 関数 {
　：　略
　：　
　// ここから、とある数値を計算するコード
　：　
　：　略
　：　
　// ここまで、とある数値を計算するコード
　：　
　：　略
}

って書くぐらいなら、コメントを関数名にして、こう書いたほうがわかりやすい。

function 関数 {
　：　略
　：　
　結果 = とある数値を計算()
　：　
　：　略
}

つか普段C++しか使ってないけど
SmalltalkにもPythonにもRubyにもメソッドprivate機能なかったっけ？

Obj-Cは、無い

mmならなんでもありだけどな

>>770

関数にすると見やすいなｗ

>>770
結果がどこに入るかとかも自明になるってのがよーわかるわ

>>767
確かにLinuxカーネルはOOPで作られてると思う

>>707
必要に応じてというあたりが微妙だけど、
stringみたいなデータを扱うことを目的としたクラスをのぞけば、メンバ変数は作るべきじゃないのだから、間違えちゃいないだろ。

getterの類にしても、考え方っていうやつで、そんなインタフェースは、publicメンバと大差ないから必要ない。
関数は、機能や目的つくるものなのだから、
名前もそれに則した命名にしろということなんじゃないかな。

それにしても、今日ののびは、すごいな（笑

＞メンバ変数は作るべきじゃない
組み込み型もstringもインスタンスなのだが

>>771
Smalltalkは、ある処理系にはある

まあ、厳密に適用するとぐだるっていうジョークの類だろ
多少心がけといた方が良いってのもあるが、ルールで縛ってもしょうがねえなって程度

メッセージ投げるタイプの言語にプライベートなメソッドってのはかなり違和感ある

>>781
コンテキストによるよ。self に投げてる場合だけ許すとか。

>>707
「ルール4：ドット１つ」の時点で10段入れ子になってたら、一回しか参照しない変数使って10行で表現しろって事だぞ。
そういう手合いの理不尽の塊を押し付ける事で何かしらの洗脳だか教育だかしようってルールだよコレは。

>>781
オブジェクト間の通信＝メッセージって考えなら違和感ないと思うんだけどなあ

>>783
バカだろお前。

city.school.class.teacher.pass(document);
こういうのがあったら、
city.enroll(document);
とやって、schoolやclassの事を申請者が知らなくても済むように疎結合しろってことだ。

それコードにすると１０行どころじゃないけどな

同じ効果を得るのに行数は短い方がいいが。
追加の効果（保守性等）を得るために行数は増やしても問題ない。
重要なのはコードの行数ではない。メンテナンス性だ。

原理原則論は現実の前では役に立たない

アクセサ不要ってどういう話なの？
例えばPoint2Dクラスにおいて、getX, getYは必須だと思うけど、
これはアクセサ不要論としては駄目な例に入るの？

何もしない単なるラッパーを機械的に全部やるべきみたいなことへの批判だろう

>Point2Dクラスにおいて、getX, getYは必須
せっかく一まとめにしてるのに、個別に取り出したら台無しじゃね。

>>791
駄目って事でいいの？その代替は？

どんな座標でも入るクラスならアクセサをつける意味が無い

そもそも、構造体的クラスの存在感こそが、潜在的に問題。
その点C#は値型としてstructってを用意してる。
その割り切りは評価したい。

>>793
メンバをそのまま公開しろってこと？

ドット一つは、クエリ式とかもダメってこと？

>>796
依存クラスが増加するなら駄目じゃないの

>>793
> どんな座標でも入るクラスならアクセサをつける意味が無い

それ、逆に言えば、どんな座標でも入るわけではないのなら
意味があるってことじゃね？

ほとんどのものは、入る値に制限があると思うんだけど？

例えば、座標が数字だとして、文字列や
何かのオブジェクトは入らないわけだろう？

型で制限すればいいというかもしれんが、
世の中には型がない言語だってあるんだぞ。

君の主張では、型がない言語ではアクセサをつける意味がある
という答えになるんだが。

普通の数値だとしても上限つけるかも知れないしな

それはプリミティブ型みたいなのとクラス型の違いの話で
直接関係はなさそう

ルール3：プリミティブ禁止
すべてのプリミティブ型と文字列型をラップすること
class Score{
private int score;
};

ルール9：プロパティ禁止
Getter/Setter/プロパティを使用しないこと

どうやってscoreにアクセスすんの？

コンストラクタだろ（真顔）

数値しか入らない所に文字列を入れたら、
入れた時にエラーになってほしいものなんだが、
型がない言語では、入れた時ではなく使う時にエラーが出るんだ。

だから型がない言語ではエラーがでたとき
どこでこの変数にこんな値が入ったんだ？って
探しまわることになる。

>>801
外部からアクセスさせてはならないって事だろ
俺は場合によると思うが

要するに、

obj.value = 1って書いた時に、
obj.setValue(1)が呼ばれればいいわけさ。

そしてそういう言語がある
プロパティという機能で、
public変数＝プロパティのgetter/setter省略
明示的にプロパティのgetter/setterを書くこともできる。

そういう言語、俺の知る中で最古の言語は
VB6（かその前のバージョン）だな。
C#にも導入されている。

起源ってSmalltalkじゃないのか

それはルール9で禁止されている

>>807
厨二病め・・

>>806
Smalltalkやそれ系統の言語で属性(Property)と言えば、
フィールドの代わりに連想配列を使う属性パターンの事。
Javaもその影響を受けて～Propertyというクラスが存在する。

http://ja.m.wikipedia.org/wiki/Smalltalk

>>806
Delphi

>>771
ねぇよ

>>811

>>793
accessorの意義が分かってないだろ
ド素人向けの説明で入力を制限するためなんて書いてあるが、
実際そんなことはすりゃしない。
Smalltalkなんかだと、初期化や、委譲先の抽象化が主な目的だ。
例えば、あるnameメッセージを送った時、
そのnameの値はインスタンス変数かもしれ無いし、
クラスオブジェクトの変数かもしれ無い。もしかしたら、
別のオブジェクトから取ってきた値かもしれ無いし、
GUIからの入力かもしれない。

>>801
auto Device = Console();
result = score.Add( One );
result.StoreOn( device );

プロパティというものは有用だ。
なぜならプロパティで簡単に実装できものを、なんでもハッシュでやろうとするハッシュバカという大馬鹿を大量生産してしまう。

>>815
ツリーマップならハッシュマップじゃないからいいよね

いまどきSmalltalkを持ち出すやつはもれなく基地外

>>815
SelfやJavascriptはPropertyパターン常に使ってるがめんどいぞ

何だかんだ、今の言語は、初期の設計方針を引きずりつつSmalltalkへ原点回帰してるからな。
結局極めて行くとSmalltalkの形に落ち着く。

reflectionやinspection、Linq、VM、lamdba、Metaclass、
Traits、自動委譲にDuckType 。
Smalltalk時代からあったものばっかり。DuckTypeなんて
それが当たり前なのに、何でそんな大層な名前を付けられたのか
わからん。

名前がなかったから付けられただけだろ

あきらかにSimula系統の流れが主流なのにな

Simulaは任天堂。
Smalltalkはセガ。

>>821
継承依存の多態にはなんで名前がないんだ

>>822
SmalltalkもSimula系統。それを言うならC++系統だろ。
言語はC++系が流行ってても、Libraryは、Smalltalkの猿真似ばかり。
無理やり真似してるもんだから、言語仕様にまで響いて言語拡張しまくって、
C#やJavaを始め無駄な言語機能が発生し始めてる。(属性だのLinqだの)
熊にドレスを着せるのは楽しくないぞ。

またキチガイ

“いまどきSmalltalkを持ち出すやつは―”
とかほざく奴は、たいてい、Smalltalkの何についての言及かすら把握できていない。
Smalltalkなんてあんなシンプルな言語、他に滅多にないのにな。常識のレベルだよ。
自分の不勉強や、理解不能な事があると認めるのが怖いから拒絶しているだけ。

教養としてのSmalltalk - Memorandum by zerobase
http://zerobase.hateblo.jp/entry/2013/02/24/015610

>>826
またキチガイ

JavaやC#は何でnewがmethodじゃないの？
JavaやC#は何でClassがobjectじゃないの？
C++の真似をしたせいなんだろうが、そのせいでinstance creationみたいなパターンが使えないやるならreflection使うしかない。
C++はその辺templateで克服できるだけまだましだ。
ただC++は自動委譲が未だに仕様に取り込まれないのが残念。

ちょｗ ドットインストールにSmalltalk入門なんてあんのか！

smalltalk使いは他パラダイムも認められないほど狭量なの？

>>830
SmalltalkについてはPharo by Exampleにざっと目を通しとくだけでも違うと思うよ

ttp://www.smalltalk-users.jp/Home/docs

Smalltalkの話が出る度に基地外だの、
終わった言語だの言っているやつは無視しとけば良い。
奴らSmalltalk自体触ったことない癖に毛嫌いし学ぶことは無いと
思ってるやからだ。朝鮮人やCOBOLerと同じ。新しい事を学ぶ気が無いやつは
相手にするだけ無駄。

>>832
一度は実際に使ったほうがいいと思うよ。見るだけだと何でそうなってるか
想像できない所が多いから。

>>831
そんなことはないよ。
ただ教養レベルで基本レベルのSmalltalkのことも知ったうえで
そこから議論をスタートした方が建設的だとは思っている。

そういうこと言ってるから学ぶことはないと思われてるんじゃないの？

Pharoは導入簡単そうだね
Squeak使った事あるけど汎用性なさすぎてマジで糞だった

SqueakなんておもちゃSmalltalkをわざわざ選んでおいて感想が糞だとかどんな情弱かと
プロなら黙っててもVisualWorksだろ
http://smalltalk.cincom.jp/main/

こいつアホだｗ

つまり、Smalltalkをやたら排除したがるのは単なる情弱の思考停止表明？

本当に見下すためだけで言ってるんだな

>>840
未来有望なJava COBOLerだからそっとしといてやれ

Smalltalkというと最近はPharoやSqueakが取り上げられがちですが、
ことビジネス用途で見た場合、VisualWorksを外すわけにはいきません。
速く、安定しており、大変リッチなクラスライブラリを誇るこの処理系は、
今も昔もSmalltalk界のエース的な存在なのです。
ttp://umejava.wordpress.com/2013/11/21/

以上、ステマ終わり。

PharoのGUIが気に入らなきゃ、コマンドラインで動かす手もある。

下記の様に入力すればコマンドラインでインタプリタ―風に動作する。
ただし、Windowsだとダメかも
./pharo -headless "[イメージファイル名]" eval

その他のオプションを知りたければ最後を--listに返る
./pharo -headless "[イメージファイル名]" --list

標準入出力は、下記の様にFileStreamにメッセージを送る事で得られる。
stream := FileStream stdin.
stream := FileStream stdout.
stream := FileStream stderr.

コマンドライン起動時に動くプログラムを作る場合は、CommandLineHandlerを継承した
クラスオブジェクトを作る。
この時クラスメソッドcommandNameとインスタンスメソッドactiveを定義する。
activeには実際にしたい処理を書く。

commandNameには、イメージファイル名の次に指定する引き数の名前を返すようにする。
./pharo -headless "[イメージファイル名]" "[commandName]"

インタプリタ―の真似事がしたければselfに対して下記のようなメッセージを送る。
クラスオブジェクト内でメッセージを送る場合は途中のclassは不要。
self class evaluatorClass evaluate: 'ソースコード'.

あと最初はSystemBrowserのRefactoringメニューを一通り使っておいたほうがいいと思う。
Refactoring以外に役に立つものが多い。

>>837
外に出てきにくくて自分の目に触れにくい技術をあえて学ぼうってときに
汎用性で排除してたら駄目だろう…

ちなみにDLLは、こんな感じで関数をメソッドに割り当てて呼び出す事ができる。
なのでWindowsのウィンドウに描画したりやConsoleを直接操作する事も可能。
あと<>でくくられてる奴はParagraphといい他にも色々ある。

example: aStatus
　　<apicall: void '関数名' (long) module: 'kernel32.dll'>
　　^ self externalCallFailed.

GUIのデザインをどうにかしたいなと思ったら、Worldメニューの
System->Setting->Appearance->User interface theme
でOS X風にしたり、Vistaや7のAero風にしたりできるよ。

>>844
ステマっていうか>>835に尽きるな
うざがられるくらいに引き合いに出されるのはもうわかっているんだから
みんなSmalltalkの基本的なことくらい知っておこうよと
それこそ今時の言語に比べたら笑っちゃうくらいシンプルな言語ひとつ覚えるのもおぼつかないものなのか？

smalltalkなんて知名度のないものがうざいくらい引き合いに出されてると本気で思ってるの？
うざいくらい引き合いに出してるの間違いじゃないの？

そういやコマンドライン実行時の終了の仕方かいてなかったな。
Smalltalk exit:0.
これで終了。

まぁ、なんで引き合いに出されるか理解する気もないCOBOLerには一生無縁だろうよ

Smalltalkを学ぶ上で、一番おもしろいのはデザパタだの、さも新しいものの様に
言われていたものが、最初からライブラリーで使われてるとこ。
具体的に効果的な使い方ってのがどうなってるかよく解る。
それからMorphによるMVCなGUI構築の方法もかなり勉強になる。

Smalltalkerはキチガイ
これを証明したスレ

smalltalkはそんなに素晴らしいのになぜ普及してないの？

二項演算子に優先順位が無いから(適当)

プログラムが脳内で細部まで構築済みである前提で開発を強要するからじゃね？

Smalltalkがサイコーとかはよう言わんが、
価値はあるのに普及していない物なんていくらでもあるだろう？　子供か？
あとそのもの自体は普及していなくても、別の派生物を介して普及しているパターンも多い。

アスペ多すぎ

>>857
そんなのは些細な問題だし、
たとえばSqueak Smalltalkなら２～３箇所いじれば乗除優先なんか付けられる

>>858
それはあるかもねｗ

lispでいう神の言語を真面目に言ってそうで怖い

Smalltalkerは林檎信者と同類

>>855
Smalltalkerはキチガイとか言ってる奴はたいていが思考停止した情弱
これを証明したスレ

>>864
林檎信者がApple発祥とか自慢してるMacのGUIとか
OSX/iOSのオブジェクト指向APIだとかは
ほとんどSmalltalkからのパクリだから、
Smalltalkerは林檎信者よりさらにたちが悪いよ。

>>863
いや、LISPerのあれはガチだから

普及するかどうかはそれが優れているかどうかとあまり関係ない
未だにプログラミング初心者にＣを勧める老害が滅びないのと同じように

手続き型見せずにOOPL見せるのはどうかと思う。
そういう意味でjavascriptは優秀。

何かのテキストが普通に一行ごとにスクロールするのを見ていたジョブズが
「これがスムーズにドットごとに紙みたいに動いたらいいんだが」と言ったときのことである。
これはキーボードに向かうインガルズにとって、ニューオーリンズのジャズバンドが
「ライムハウス・ブルース」を演奏してくれと言われたようなものである。
スモールトークのコードが数行表示されているウインドウをクリックし、
ちょっと編集してテキストウインドウに戻った。ちちんぷいぷい！
もうスクロールは連続するようになっていた。
アップルのエンジニアたちは目が飛び出るほど驚いた。普通はどんなシステムでも、
コードを書き換えればプログラムの相当な部分、多くの場合は
ほぼすべてをコンパイルし直さなければならないものである。これには数時間かかるだろう。
ところがスモールトークでは、そのオブジェクト指向のモジュール化により、
ちょっとした変更で要求される再コンパイル量は十行か十行を超えることがなく、
わずか一、二秒しかかからないのである。
「本質的に瞬間的なものでしたからね」インガルズは言う。
もちろんスモールトークの開発者の一人である彼が、
変更をほとんど本能的にできたことが役に立ったのは言うまでもない。
「ちょっとズルだったかもしれませんね」彼は認める。
「システムの頭のてっぺんから爪の先まで知ってるんだから」

>>866
OSXのメニューバーは、Squeakのメニューバーと同じだし、
Cocoaの設計は劣化Morphicだもんな。

Smalltalkが普及しなかったのは当時のマシンだとVMが遅くCが普及したせいだろ
結局今中心になってるのはC系言語ばっかりだもんな

基本的にSmalltalkに暴言吐いてる奴は、PharoとかSmalltalkの事一切知らんやつで、
Smalltalk擁護してるやつは、Smalltalk他複数の言語を使ったことがあるやつ。
学習意欲の無いやつなんて相手にしないほうがいい。何の得にもならん。

信者が排他的すぎる
ミリオタのそれと一緒

Cと比較したらそうだろう。
Perl、Python、Rubyと比較したら？
パフォーマンス的には変わらんだろうし、
後発言語だからsmalltalkよりもハンディがあった
はずなのにsmalltalkより普及してる。

常人が理解できる部分ではSmalltalkは十分普及しているだろう？
WIMPなGUIとかコピペとか右クリックとかMVCとかデザパタとかIDEとかアジャイルとかTraitとか

記法がキモいから？

>>875
> 後発言語だからsmalltalkよりもハンディがあった

後発なら、より効果的にパクれて当然じゃないの？
その発想がわからん。

>>877
それもあるね。ｗ　非C言語的なのが嫌われた。
だけど必要とあればObjective-Cとか文句いわれつつ普及しているしなぁ…
やっぱり流行り廃りは時の運だよ

後発言語だからユーザー数が少なくエバンジェリストもリファレンスとなるコードも少なかったというハンデ。

>>847
扱いにくい事まで肯定したら駄目だろ
馬鹿か

smalltalkが普及しなかったのは髭が足りなかったから

>>881
ごめん。「汎用性」に「扱いにくい」という意味があるとは知らなかった。
馬鹿か

smalltalkが普及しないのは機能の起源を主張するのに忙しいから

きっと「>>837の扱いやすさ」＝「>>837にとっての汎用性」なんだろうな。
お花畑か

汎用性
読み方：はんようせい

ある物事について、幅広く適用したり、一般的に活用したりすることができる性質を意味する表現。

>>885
そうやってユーザー排除してきた結果がこのザマなんだよ
一生カゴの中にいればいいさ

>>882
マジレスすると、髭は足りてる（アラン・ケイのゴーストライターの人だけど）
http://www.smalltalk.org/people/daningalls.html

smalltalkが普及しなかったのは時代を先取りしすぎ、多機能すぎ、なにより権利を守ることに無頓着すぎたから

>>887
Smalltalk知っているからって他の言語を使えないわけじゃなし
自分の殻に閉じこもっているのはどっちかって話でもあるな

>>888
> アラン・ケイのゴーストライター
アデル・ゴールドバーグに空目したｗ

>>890
お前にはマイナー言語がピッタリだ

Ruby信者並とは思わなかった。

温故知新

Ruby信者がMatzの発明とか自慢してる
ブロック付きメソッド呼び出しだのは
ほとんどSmalltalkからのパクリだから、
SmalltalkerはRuby信者よりたちが悪いよ。

>>892
Smalltalk知ってるって言っただけで
なんでお前なんかにマイナー言語使い認定されなあかんの？

Smalltalkなのに声だけは大きい信者かな

>>875
速度的にはCog VMでPython以上。
VisualWorksのVMでJavaと同等の速度がでる。

Smalltalkって小声でじゃべるって意味じゃないの知らないんだな
英語も不自由なのか

いまどきOOはSmalltalkなしに語れるし
むしろ後発言語の改良のほうが重要な点が多いのに
わざわざSmalltalkを引き出してくるほうがおかしい。
それでいてSimulaは語らないし。

基本的にソースコードは全て丸見えだから商用にはあんまり向かないのはある

ゼロックスの時代からSmalltalk使ってたやつがどんだけ居るんだっつー話よ。
にわかな奴ほど語りたがる。

誰が語りたがってるの・・・

>>900
お前はSmalltalkの何をしってんだよ。
それからSimulaは、C++のモデルとなるclassを搭載してただけで、
Smalltalkで発達したデザパタとはかけ離れてるからな。
C++の標準ライブラリーみたいな感じだ。大して勉強にならん。

SIMULA67は「クラス」とか「オブジェクト」といった言語機能のアイデアを
ストラウスストラップやケイがそれぞれに「オブジェクト指向」を考案するきっかけとして
提供しただけで、それこそなしで語れるんじゃない？
それよりストラウスストラップが「抽象データ型としてクラスを使う」というアイデアや
ケイの「オブジェクトをメッセージに受け手にして徹底した動的性を実現する」ってアイデアを抜きに
今のオブジェクト指向は語れないだろう？

>>900
Smalltalkから後発の言語で改良されたOOの重要な点ってなんだ？
具体的に書いてみ。

>>904
ほらね

>>905
正直ケイはどうでもいいなぁ。Smalltalkの実際の作者の方が面白い。

デザパタがSmalltalkを語る理由かよｗ

>>908
いや、でも「メッセージングによる動的結合の徹底」というアイデアはケイのものだと思うけどなぁ…

>>907
じゃお前Simulaの入出力ライブラリーについて言ってみ。
こっちは知った上で言ってるんだが。全く知りもしないお前と一緒にされたくないわ。

「オブジェクトをメッセージに受け手にして徹底した動的性を実現する」

これってSimulaのコンセプトを強調しすぎてキチガイ作っただけだよな

>>907
お前は知りもしないのに、役に立たないという。
こっちは知った上で役に立たないという。
その違いが分かるか？

>>900
初めて知った
オブジェクト指向ってSimulaを指した言葉だったんだ
Smalltalkが起源とか全くの大嘘じゃん

>>912
関係ない。

「俺は知ってるんだぞ！」

Smalltalkerの主張のすべてｗ

デザパタを語る時の落とし穴
1) あんなもんは新しくもなんともなく…←GoF本に何度もそれはそうだと書かれている
2) あれはカタログ化して意思疎通のために…←実際は理解には差があって言うほど意思疎通できん

>>916
はようSimulaの入出力の一つでも語ってみろよ

>>911
ダールやニガードは
ストラウストラップの「クラスを抽象データ型として利用する」ってアイデアを知ってから
あらためてSIMULAをオブジェクト指向言語として舵を切り直した経緯があるからなぁ…
http://phobos.ramapo.edu/~ldant/oop/simula_history.pdf

>>918
知ってるんだからキミが語ってあげれば？
さぞかしOOに大切な話なんだろうね
物知りSmalltalker君

>>913
いずれにしても役に立たないでＦＡ

>>910
メッセージングを徹底的にってのは設計者の方は、
Lispの影響を受けた実装者の考えだよ。

アランケイ的には、やりすぎだといってたぐらいだし。

>>920
知らねんならSimulaの名前出すんじゃねぇよクズ

Simulaは物理のシミュレーション記述を目的にしてきた経緯があるから
自然なコンセプトだよね。

>>923で何を語ってくれるの？

>>921
じゃJavaもC#も役に立たんゴミでFAだな

>>922
いや、メッセージングを徹底しすぎたのはたしかにケイも批判的だったけど
彼がその先にある動的性を重視していたのは確かだよ。
http://metatoys.org/oxymoron/oxymoron.html

>>923がSimulaのすべてを知った上でOOとして語るに値しない点を
これから述べてくれますので注目！

つまりメッセージパッシングOOはLispが起源？

Smer的にはOOPのメリットって何ナノ？
たまに>>924的ことを一番にあげる人居るけど。

俺は、抽象化によって整理を捗らせるのが肝だと思ってる。
だから、必要に応じて必要なだけOOすれば良いと思ってる。

Smalltalkerは起源を語り始める。
これがどういうことだかわかるよね。

>>929
いや、動的性のほう。メッセージングのメタファはケイが考えた手段。

>>925
お前はまずここでお勉強してろ
http://www.macs.hw.ac.uk/~rjp/bookhtml/

>>932
動的性って？
動的型はLispに、動的バインディングはSimulaにあるようだけど

>>933
知ってるのに語らないなら>>925と同じだね

>>930
>>927にもあるけど、やっぱり最終的には動的結合でしょう。
>>870なんかはその良い例で

Smalltalkerは俺は知ってる詐欺

でSimulaではなくSmalltalkを持ち上げる理由はなんなの？

>>934
それを処理系それ自体を含む、コンピューターシステム全体に適用しようとした試みでしょう
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24#

C++の劣化版としか言えないライブラリーのSimula。
線形代数系のライブラリーがC++風に構築されているSimula。
Smalltalkみたいに、新しい言語が結局帰着してしまうような
仕組みを作り上げたわけでもない。中身を除いてみれば
その後への影響力は構文の特徴だけで、新たに見つかるものもない。
まぁ、>>925 よりは知ってみる価値はあるがな。

まさに>>900を実証した流れでした

C++/Java/C#がSmalltalkより劣ってる点てなんなの？

キチガイはC++やJavaのシェアも知らないから仕方ない

>>938
Simulaのライブラリーは大して生産性のあるパターンや拡張性を
念頭に置いたパターンに力を入れられてない。継承してれば
オブジェクト指向ってな感じの効果の薄い原始的な方法ばっかり。
委譲による基底オブジェクトの入れ替えなんて考えられてない。

>>942
信者のウザさ

デザパタ発祥起源がそんなに大事だと思ってるのSmalltalkerだけなんだが

>>934
あ、いや、Lispが起源なのは動的性のほう、という意味
メッセージングとそれの受け手としてオブジェクトを使ういうメタファで
動的性を徹底しようとしたのがケイのアイデア

>>942
>>927

>>942
instance creationが使えない
メッセージ転送が使えない

クラスオブジェクトとインスタンスオブジェクトが分かれてて、
デフォはクラスオブジェクトを使い、たまにインスタンスオブジェクトに
切り替えるようなパターンが使えない。

言語拡張無しにLinqの様な仕組みを効率的に実装できない

リフレクションの仕組みが通常のメッセージ送信とかけ離れてて、
既存のメソッドをリフレクションに適用できない

SimulaベースのC++/JavaがOOを普及させるに足りる
柔軟性現実性を持っていたからOOは普及したのに
その過程で出てきたデザパタの起源でキチガイのように主張するわけですね

>>949
なぜ使えないか考えたことある？

>>951
なん・・・だと・・

>>942
制御構文がメッセージじゃないんで、
制御構文と同じ書き方をコレクションとかに適用しようとしてもできない

Symbolが存在しないんで、全体で一意に扱い値を管理するための
辞書を態々作る必要がある

>>951
JavaとかC#とか今必死こいて言語拡張して対応しようとしてるよな
C++の真似事から始めたからだ

>>936
（　´・∀・`）へー
といっても動的束縛に関しての知識がC++/Javaあたりのことしか分かってないんだが、
大まかに言ったら多態性ってことでいいのかな？

>>870の例はモジュール化による、変更部分のコンパイル量とか時間を特にプッシュしてるみたいだけど。

自分が作ったわけでもないものによく必死になれるよな

○○は起源＝それを知ってた俺は凄い

>>942
オブジェクトの生成が(new）がメッセージじゃなくて演算子。
他のクラスのオブジェクトをnewで返すような事もできない。
このせいでinstance createnの真似事もしづらい

ブロックにあたるラムダが今更追加され始めたが、
Smalltalkの復帰文(^)の様にブロック生成元の
メソッドまで戻れない。(多分数年後に同じ文が
追加されるとは思われる。)
このせいで、
value := map at:#key ifAbsent:[ ^self ].
これだけで済むものが、一行判定が入ったりしてクドクなる。

>>951
なぜ今更真汚い構文追加して似事を始めてるかしってる？

>>955
だいたいあっているけど、ちょっと大まかすぎるかな^^;
たとえば>>870を実現させたように、Smalltalkのコンパイルがデフォでインクリメンタルなのは
最小の変更部分を差し替えるだけで他の部分は（>>927の例にもあるけど既存のインスタンスも含め）
いじらずにそのまま動き続けさせたいって目指すところがあったからという設計思想の影響が大きい。

Excelファイルみたいなもんか

>>942
C++は問題ないが、Traitsが無い。
Rubyもmoduleで真似事を始めたが、
Javaなんかは、いちいち委譲する必要がある。
一応annotationを使えば近づけるが、
無理やりやってるもんだからボロが出まくる。

>>959
動的束縛によって実現された多態性が設計的に嬉しいというだけでなく、
やっぱ>>870の例にあるような、コンパイル作業の効率化ってのもOOPの大事なメリットなのかな？

結局風潮的には、
C++ベースの言語 → Smalltalkの機能
なんだよな。C++ベースの慣れ親しんだ構文でどうにか
Smalltalkの機能を再現できないか頑張ってる感じ。

>>962
OOPってひとくくりにしちゃうと語弊があるかな…
これはSmalltalkが（というかケイがメッセージングで）特にって範疇の話なので…

なんにしろメリットとデメリットがあるわけで一方的な面だけ見て優れてるって言っても
他の面でデメリットがあったら普及はしないんだよ

前スレは埋まるまで8か月もかかったのが、
信者vsその他大勢のどぉぉぉぉぉぉぉぉでもいい煽り合いだけでわずか10日で埋めるかよ
流石プログラマ、粗探しだけは得意だな

>>942
いくつかのデザパタは実装する必要がない
抽象化ファクトリーやフライウェイト、
オブザーバーパターンは、ライブラリーや言語機能で
実現できてるので、それを利用すれば済む。

>>963
そうなのか？
C++は関数型に向かってる気がするが

>>964
つかケイのOOの概念を応用したものは普及してるが、
ハゲが普及させたかったOOってなんだろうな。
単なるクラスを使った構文か？