1read 100read
2011年10月1期プログラムs = "" + i;でintをStringに変換するのはなぜだめか TOP カテ一覧 スレ一覧 削除依頼
・ 次のスレ
いろんな言語で宿題 第五編
何でNULLって言うんですか?
ライフゲーム
YOUTUBEをすソフトを作りたい


s = "" + i;でintをStringに変換するのはなぜだめか


1 :10/08/02 〜 最終レス :12/01/09

2 :

3 :

4 :
このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
                  京都大学霊長類研究所

5 :
( bb || !bb ) ?

6 :
えっ、ダメなの?

7 :
HSPディスってんじゃねーぞ

8 :
まあ、馬鹿の一つ覚えっていうか、羹に懲りて膾を吹く馬鹿って多いからさ実際。

9 :
Java って邪魔くさいね
まで読んだ

10 :
Javascriptでもちゃんと
var s = String( i );
って書くよ。

11 :
http://en.wikipedia.org/wiki/Type_system#Strong_and_weak_typing

12 :
型のゆるい言語ならそういうこともできるんだろうね

13 :
+で文字列結合っていう発想がイヤすぎる
そんなのBASICとかいう糞言語の仕様だろ

14 :
るby

15 :
perl 臭いな
型に対して無防備な言語は俺は嫌いだ。

16 :
Javaのくせに生意気だ

17 :
C++も+で文字列結合するよ。
+で文字列結合がいやなやつって
言語あまり知らないんじゃね?

18 :
BASIC なら & だろ。

19 :
こんなページがあった
http://d.hatena.ne.jp/katona/20071221/p3
文字列結合に+を使う言語は多い

20 :
+で結合は一見便利なんだけど
実際のところは""のせいで
長くなってくると非常に見辛い
a + ", " + b + ", " + c
みたいに書くよりも
"%s + %s + %s" % (a, b, c)
"{{a}} + {{b}} + {{c}}"
"#{a} + #{b} + #{c}"
とか書ける方がうれしい

21 :
>17
それはStringクラスの演算子オーバロードだから本来の + の効果ではない

22 :
つまりどういうことです?

23 :
c の char みたいにローレベル操作じゃないから
気にくわない。

24 :
ロベール操作だって?

25 :
なんで結合用の演算子を用意しないんだろう
Haskellみたいに++にするとかさ

26 :
PHPでは文字列結合演算子として . が定義されてるぞ。

27 :
>>21
内部実装がどうであれ、+で結合できることにはかわらんだろ。
C++標準ライブラリのSTLのstringの話だ。

28 :
>>20
そういうことが標準でできないのは、JavaScriptぐらいだよな。

29 :
>>25
++はインクリメントを思い出すからだめだな。
記号としてなら & が一番いいんじゃないか?
A と Bをあわせて(ry
A & B で(ry

30 :
>>28-29
VBは嫌い

31 :
お前の趣味なんか知らんがな。

32 :
ダッグタイピングは糞のように扱かわれていたのに、言語が変わったら神扱い。

33 :
これだから型に厳密でない言語はくそなんだよ

34 :
Javaだと実装不可能、
C++だとテンプレートを駆使しないと出来ないようなことが
阿呆みたいに簡単にできるからなぁ

35 :
>>32
今でもくそだと思ってるよ。
C#に導入されたけど、乱用されませんように。

36 :
スクリプト言語やCOMとの相互運用のためだろ
ラッパー自動生成なんかより遥かにスマート

37 :
>>34
> Javaだと実装不可能
何の話してるの?
文字列の結合?それならJavaでも+だけど。

38 :
>>20
その思考回路がわからない。
余計見難くなってるようにしか思えないけど....
っていうか、そういうのは普通にデリミタ挟んで文字列の配列を結合するメソッドを
作ろう(またはライブラリのそういうメソッドを使おう)よ
話飛ぶけど、ダックタイピングだの型が厳密でないだの、>>1の意図がマジで全然
理解できてない奴が何人かいるんだなw

39 :
>>20 の感覚のほうが一般的だろ。
C++とかJavaとか、結局formatみたいの導入されてるし。

40 :
JavaScriptにはformat見たいなものすらない。

41 :
俺には>>1の意図はよくわかる。
「?」しか書いていない>>1は馬鹿で〜すといいたいわけだ。

42 :
いやいや「勝手に数値と文字列の変換をしちゃうような言語きめぇ」って意見に
なぜって疑問を呈してる訳だろ? >>1は。
>>38は、ダックタイピングの話題がでてるけど、それって>>1の疑問と関係ないよね、
おまえらわかってんの?って言ってるわけでしょ。

43 :
>>39
>>38 の言ってることは一理ある
' + '.join([a, b, c])
って書けるとかなりスマートだ

44 :
>>40
ExtJS とか入れると Javascript で format 使えるようになって嬉しかったり

45 :
>>43
でも、それ規則的な連結にしか使えないでしょ。

46 :
>>42
たとえば n を 10 倍するときに
s = n * 10;
ではなく
s = n + "0";
って書いてしまう馬鹿が perler とか PHPer とか VBer に少なからず居る

47 :
俺はPHPで仕事してるけどそんな珍奇なソースみたことないぞ

48 :
Cの書式こそ至高だな
それを知らない、使い方が分からないバカが連結持ち上げてるんでしょ

49 :
c++ はどうして
cout << "x = '" << hex << h << "'" << endl;
どうしてこうなった?

50 :
>>49
それ使いづらいから結局printf使ってる。

51 :
boost::formatは?

52 :
>>49
演算子オーバーロードとテンプレートを
使いたくて使いたくて仕方がなかったから。

53 :
iostreamは<<を使ってしまったのが失敗。
それでも、printf/scanfよりまし。

54 :
>>52
テンプレートは使ってないだろ。

55 :
???

56 :
テンプレートない時からあるから

57 :
>>53
kwsk
>>56
テンプレートは最初からあるぞ

58 :
>>51
boost::format はでかすぎなのと % がきもい
(s)printf と比べてメリットがそんなになさそう

59 :
>>57
printf/scanfはそもそも安全でないので話にならない。
C++でテンプレートが導入されたのは比較的新しい。

60 :
初期のC++を知らない世代になったんだな。
初期のC++にないもの。
・テンプレート
・例外
メモリの割り当てに失敗したら例外発生するんじゃなくて
NULL返すんだぜ。

61 :
protectedもなかったな。

62 :
今でも、テンプレートと例外は、いろいろ問題があるので、わざと使わないこともある。

63 :
>>60
それって90年代の中頃にはすでにあっただろ。
無い時代のC++知ってるのって、そうとうおっさんだけなんじゃない。

64 :
>>63
どっちにしても、テンプレートないころからiostreamはある。

65 :
初めてC++使ったの91年だけどテンプレートはあったな

66 :
俺がベル研にいたころはニューバランス履いてたけどまだ髪はあったな

67 :
初期のC++のコンテナは最悪だった
マクロとかvoid*使ってたんだぜ

68 :
ただのPPだったからな

69 :
generic.h なんて思い出させるなwww

70 :
awkの文字列連結は直感的。単にオブジェクトを並べるだけ。だから、こんなこともできる。
--
awk 'BEGIN {i = 10; j = 20; print i j;}'
--
これで 1020 と出力されるのだけど、裏を返せばTypoが怖いw

71 :
>70
C言語系書式のfor文と勘違いして混乱したじゃねーか

72 :
awkはガチ

73 :
同じ動的言語でも
Perlやawkは型の区別が無いが演算子は区別してる例
PythonやRubyは演算子は同じだが型付けが強く文字列と数値を自動的にcoerceしない
>>1の例はエラーになる)
だな
この両者に比べると>>1式はひどいように思う
JavaScriptは文字列にcoerceするので、数値を""と足すと文字列化になるが
バッドノウハウ的だし意図せぬ誤りの元
が、もっとひどいのがPowerShell
1+"2" -> 3
"1"+2 -> "12"
こうなるんだぜ

74 :
どこが酷いんだかさっぱりわからん。
>>73が何も分かってないだけだろw
>>1の意図は明らかにそういう奴をおちょくることにあるんだが、
まあ、おちょくりの対象側の人間にとってはこの通り蛙の面にしょんべんだわな。
なにせ自分の無理解の自覚がないんだからw

75 :
よせやい、褒めるなよ。照れるじゃないか。

76 :
>73
演算子の左辺の型によって演算子の挙動が変わるのか
いかにもバグの元になりそうな仕様だな

77 :
>>76
やっぱりわかってないな。

78 :
【法律】「ウイルス作成罪」創設へ 刑法改正を検討(10/08/09)
http://hibari.2ch.net/test/read.cgi/pcnews/1281355124/

79 :
コピペ君って馬鹿だな、まで読んだ。

80 :
残念だけどそれもコピペなんだよね

81 :
どう?
でもいい

82 :
>>73
1.+("2") -> 3
"1".+(2) -> "12"
うん、至って普通の動作だ

83 :
+を使うセンスの無さ

84 :
ZuSZSSっzっsqzyzっszんrbdんtrwfbmdsnSnzzzZQ

85 :
>>82
これを見てもそう思う?
1 + 0.5 -> 1.5
0.5 + 1 -> 1.5
PowerShellでも
1 + 0.5 は1にはならない(勿論.NETなので、1と0.5の型は違う)
糞ほどのセンスも感じられない一貫性の無さだね

86 :
>>85
もっと勉強しろ

87 :
>>85
ちゃんとスレ読んでるか?

88 :
いやよんでねえw
Int32 + String -> Int32
String + Int32 -> String
Int32 + Double -> Double
Double + Int32 -> Double
この仕様は君らにとってはOKなわけか、俺にはわからんわw
何でOKなのか教えてくれない?

89 :
>>88
文句は Perl に言ってくれ

90 :
何でPerlの話が出てくんのw
関係ないじゃん

91 :
実装側の頭があればすぐにわかることジャマイカ。

92 :
>>91
実装都合なんて無意味じゃね?
これと違う仕様にも実装できるし、事実そうなっている言語はたくさんある
純粋に仕様として綺麗か汚いかって話だと思うんだが

93 :
1 + "0.5"→1.5
(Int32 + String -> Double)
単純に左オペランドの型に変換しているわけではない模様
"1" + .5 -> "10.5"
"1" + 10e2 -> "11000"
"1" + 10e100 -> "11E+101"
この辺はこうなる、予想の範囲だが

94 :
春 21世紀枠に負けるとは末代までの恥
夏 エラーと落球で逆転を許すとは末代までの恥

95 :
こういうのって基本的に人間様が楽をするための仕様じゃないの?

96 :
型が緩すぎると他人のコードを読むのがしんどいからよくないって話はたまに聞くね。
書きなぐるコードじゃないなら型が厳しい方が好きだ。

97 :
確かに保守するなら型厳しい方が好きだわ。
型厳しいとIDEも頭良くなれるし。

98 :
sage test

99 :
だから>>1みたいのは型が緩いわけじゃないっての。
むしろユルいのはお前さんの頭(以下略
>>85
よくある愚論だけど、別に(プログラミング言語の設計において)全てにおいて
一貫性が優先されるわけじゃない。
直感的であることと表面的な一貫性が矛盾する場合、どっちを優先すべきかは明らか。
数値同士の演算結果が前のオペランドの型になるような仕様が嬉しい奴はいない。
stringの+演算子が、片方のオペランドのToString()を呼び出すように定義されている
(C#の場合)のは、自然で直感的な仕様だ。

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 削除依頼
・ 次のスレ
いろんな言語で宿題 第五編
何でNULLって言うんですか?
ライフゲーム
YOUTUBEをすソフトを作りたい