06/10/15 08:41:51
スクリプト言語でじゅうぶんぢゃん。
2:デフォルトの名無しさん
06/10/15 08:57:31
他人に使ってもらうプログラムはバイナリのほうがいいかも。
3:デフォルトの名無しさん
06/10/15 09:08:34
これの宣伝スレ?
URLﾘﾝｸ(0xcc.net)
4:デフォルトの名無しさん
06/10/15 09:37:49
バイナリをゲロってくれるのはおまけ。
その言語を使いたい（あるいは使わなければならない）理由がほかにあるから使う、それだけ。
5:デフォルトの名無しさん
06/10/15 10:00:07
ゲロるってコアを吐くってこと？
6:デフォルトの名無しさん
06/10/15 10:00:47
必要に応じて使い分ける。
ただそれだけ。
7:デフォルトの名無しさん
06/10/15 10:09:28
あっそ
8:デフォルトの名無しさん
06/10/15 11:22:34
バイナリ以外を出力する言語って何がある？
9:デフォルトの名無しさん
06/10/15 11:56:44
インタプリタは特にバイナリはゲロしないよな
10:デフォルトの名無しさん
06/10/15 11:58:47
ゲロるだなんて言うな！
バイナリってのはプログラム言語という卵子に俺のコードという精子を
ぶっかけることによって生まれてくる赤ん坊なんだ！ ひとつの命なんだよ！！
11:デフォルトの名無しさん
06/10/15 14:20:38
プログラミング言語とコンパイラ/インタプリタを混同している奴がいるな
12:デフォルトの名無しさん
06/10/15 15:17:57
バイナリをゲロる言語はとても良いあんばいナリ
13:デフォルトの名無しさん
06/10/15 15:43:44
>>1
スクリプトは遅すぎるから簡単な操作にしか使えないじゃん。
14:デフォルトの名無しさん
06/10/15 15:57:17
>>1は1つの言語しか使えない。
しかも、スクリプト系。
15:デフォルトの名無しさん
06/10/15 16:38:29
としゃぶつ
16:デフォルトの名無しさん
06/10/15 16:56:14 BE:279569287-2BP(204)
俺が今保守してるプロジェクトなんか、実行時間の99%以上はIOに費やしてるような
コードばっかりだから、Cなんか使わないでいいだろって思うよ。
17:デフォルトの名無しさん
06/10/15 17:59:46
>>16
その考えは別に問題なし
スクリプト言語で何でも出来ると思ってるのは間違い
18:デフォルトの名無しさん
06/10/16 16:50:13
バイナリを吐く言語の魅力
・多くのOSで、いわゆる「バイナリ」はコンテナファイル。
PEとか、ELFとかCOFFとか。なので、コード以外のリソースをまとめられる。アイコンとか。
メタデータを多重化できると言えばいいのか。 スクリプトでも頑張ればできるかも。
・解析が難しくなる。本気で解析されたらなんとでもなるけど。
・実行権限を独自に設定できる。
Windows上だけの魅力だな。
機能的、速度的な違いは本質的ではない。
Unix系の、スクリプトの実行がシステムからサポートされるシステムと、
そうではないWindowsでは話が異なる。
Unix系だと、違いは無いと思う。
19:デフォルトの名無しさん
06/10/16 19:29:06
>>18
jarやODF考えるとコンテナだからいいってのは微妙…
実行環境次第ではなんとでもなるし。
むしろ、PC以外の環境(の方が実社会でははるかに多い、携帯とか)を
考慮したときに、>>1は糞、という結論。
20:デフォルトの名無しさん
06/10/16 20:02:26
>>18
まとめられるのは長所でも短所でもある。
文字列リソースなんかはむしろ外の方がいい。（隠したいなら別だが）
しかも、スクリプトもそんなに頑張らなくてもまとめられる。
>機能的、速度的な違いは本質的ではない。
この問題をあえて避けるのはどうかと思うが…。
結局は、このバランス取りを考えてどちらの言語を使うか？
という問題に落ち着くと思う
21:デフォルトの名無しさん
06/10/16 22:47:30
>>18
> Unix系の、スクリプトの実行がシステムからサポートされるシステムと、
> そうではないWindowsでは話が異なる。
アホなのかどうなのか知らんが、別にwindowsでもスクリプトの実行はサポート
されてるぞ。
というか、そのレス全体的に思い込みで書いてるだろ。
22:デフォルトの名無しさん
06/10/16 22:56:21
shebangのことを言ってるんだろうか>>18
23:デフォルトの名無しさん
06/10/17 00:31:00
windowsのスクリプトの方が強力だよね
24:デフォルトの名無しさん
06/10/17 10:14:35
>>21
・スクリプトに実行権限つける。
- そのユーザの権限で、インタープリタ直接は実行不可だけど、そのスクリプトの実行は許可する
・拡張子以外の方法で、インタープリタを指定する。
- #! 記法と同等のこと。
が、Windowsでできる？
setuidもできると良いけど、もともとWindowsには無いので、期待しない。
(Windows上ではバイナリ/スクリプトの差にはならない)
25:デフォルトの名無しさん
06/10/17 18:51:45
>>24
Windows Script Hostを勉強した方がいいと思うよ
un*xのスクリプトよりはるかに優秀
26:デフォルトの名無しさん
06/10/17 19:02:14
とりあえずwsf使えば、後者は達成できるな。
27:デフォルトの名無しさん
06/10/17 20:28:25
Windows の場合はカーネルがインタプリタを起動してくれないね、という話でそ。
CreateProcess でスクリプトを実行できないので、インタプリタを起動して引数でソースを指定するか、
ShellExecute でシェルを経由するかしなくてはならない。
>>26
wsf って拡張子いらないんだっけ？
28:デフォルトの名無しさん
06/10/17 21:47:07
NT系では、環境変数PATHEXT。
29:デフォルトの名無しさん
06/10/17 21:49:55
大抵の環境では拡張子が表示されないから問題ない
30:デフォルトの名無しさん
06/10/17 22:04:40
>>24
>が、Windowsでできる？
出来ても大して嬉しくないんだが…。
どうせ、他言語のスクリプトは動かないし。
つーか、一般ユーザー権限でログインして、NTFSにして、cygwin使えと。
こんなことだけで、バイナリとスクリプトは同じだ。なんて言う人はおそらく一人。
31:デフォルトの名無しさん
06/10/17 22:11:14
SFU最強伝説
32:デフォルトの名無しさん
06/10/17 22:21:41
>>30
流れを読め。
>>21がトンチンカンンなこと書いてるから突っ込まれてるわけで、
Windows でそういうことがしたいと言っているわけではないだろう。
33:デフォルトの名無しさん
06/10/17 22:21:49
>>30
WSHは任意の言語を実行できるようになっている。
VBScript, JScript以外にはActivePerl, ActiveScriptRubyが存在する。
34:デフォルトの名無しさん
06/10/17 22:29:31
Unix 系の OS では、実行許可ビットが立っていて、ファイルの先頭が#!/foo/barであれば、
カーネルがインタプリタ/foo/barを起動してそのファイルをスクリプトとして実行してくれる。
Windows では、ユーザなりシェルなりがインタプリタを起動して、スクリプトファイルを渡して
あげる必要がある。wsh ならば wsh.exe を起動して、引数でスクリプトファイルを渡す、等。
そういう違いがあるね、というだけの話。
35:デフォルトの名無しさん
06/10/18 06:03:32
>>32
>Windows でそういうことがしたいと言っているわけではないだろう。
そういうことをさせたくて書いたわけではなく、
そうすれば、>>34の違いはゴミみたいな問題になるでしょ。
という意味で書いた。
このゴミみたいな問題で、バイナリとスクリプトの長所の違いを
見るっつーのは、可笑しいだろ？
36:デフォルトの名無しさん
06/10/18 10:15:10
>>33
その4つしか選べないんなら、「任意」とは言わんだろ。
wshのフレームワークに組み込まれた言語を選択できる、って言い方になる。
>>35
実質的に、その「ゴミみたいな違い」しか、違いは無い、と思うが。
ゴミみたいな違いってのは、カーネルが直接実行形式とみなして、
属性評価を行う、ってことね。
37:デフォルトの名無しさん
06/10/18 10:39:58
>>24
#!記法は、解釈しないインタプリタもあれば解釈するコンパイラもあるぞ。
まったく本質的じゃないな。それは言語の周辺環境のごく一部の話だと
思うんだが。
#!記法に対応してるインタプリタがある言語の、Unixもどき系OSにおいての
利便性の違いだけを話してたの？ 意味はあるけど本質じゃないよな。
38:デフォルトの名無しさん
06/10/18 12:42:05
>>37
#!はインタプリタやコンパイラが解釈するんじゃなくて、カーネルが解釈する。
ウィンドウズの場合は、プロセスを起動する側がそのスクリプトを解釈する
インタプリタを知っていて、それを起動しなくちゃならないけど（←シェルに任せ
てもいいけど）、Unix ではそれをカーネルがやっているという話。
>>35
＞Unix系の、スクリプトの実行がシステムからサポートされるシステムと、
＞そうではないWindowsでは話が異なる。
＞Unix系だと、違いは無いと思う。
というのが元の発言だよね。長所短所の話ではなくて、「Unixでは違いが無い」
というのがこの主張の肝でそ。
Windows だとやっぱり違いがあると思うなぁ・・・
スクリプトはCreateProcessでは起動できないとか、拡張子で関連付けしておかないと
ShellExecute でもエクスプローラーでのダブルクリックでも起動できないとか。
39:デフォルトの名無しさん
06/10/18 18:35:22
なんでそんなくだらないことに拘るんだ？
Windowsはexeファイルすら関連付けしないと起動しないぞ？ｗ
40:デフォルトの名無しさん
06/10/18 18:52:19
いいかげん、
OSの違いを抜きに話し進めてくれないか？
41:デフォルトの名無しさん
06/10/18 18:52:42
アフォが信じて流布しちゃうわないように、小さな嘘やでたらめは
早い段階でちゃんと否定しておいた方がいいだろ。
>>39
関連付けなんかなくたって、CreateProcess で起動できますよ。
42:デフォルトの名無しさん
06/10/18 18:57:31
ここは言語スレであってOSスレじゃないな
43:デフォルトの名無しさん
06/10/18 19:02:07
「バイナリを吐く言語」に魅力があるのか、
言語としてのC++に魅力があるのか、
現状のバイナリを吐くC++に魅力があるのか、
と考えると3番目だけが事実だと思う。
（思うのはたぶん自由なのだろうから責めないでくれ）
44:デフォルトの名無しさん
06/10/18 19:59:03
バイナリを吐くC#が出来ないかな～と妄想してみる
45:デフォルトの名無しさん
06/10/18 20:41:37
>>38
> #!はインタプリタやコンパイラが解釈するんじゃなくて、カーネルが解釈する。
カーネルから渡されたあとにインタプリタやコンパイラが読み飛ばせなきゃ、
スクリプトは動かないよ。
人の話を無視してお前の言いたいことをリピートされても困る。
46:デフォルトの名無しさん
06/10/18 21:00:16
その言語を用いて書かれたプログラムを起動する方法が
・バイナリとスクリプト言語のどちらも同じ (unix)
・バイナリとスクリプト言語では異なっている (Windows)
のなら、後者についてはその差異による優劣が発生する可能性がある。
Windows に詳しい人が「そんなのありませんよ」と否定すれば
それまでだけど。
47:デフォルトの名無しさん
06/10/18 22:00:59
>>46
#!記法は解釈しないインタプリタもあれば解釈するコンパイラもあるっつーに。
48:デフォルトの名無しさん
06/10/18 22:27:59
Windowsの場合、解釈するカーネルは無いでそ。
それを言ってる。
だから普通のバイナリのようには使えない。
これでバイナリとスクリプトの優劣があると言えるほどの
差異なのかどうかはわからないけど。
49:デフォルトの名無しさん
06/10/18 22:48:32
カーネルが解釈しようがしまいが言語側が解釈できなきゃ意味ないんだってば。
スクリプト言語は#!を解釈するというその思い込みをどうにかしろよ。
50:デフォルトの名無しさん
06/10/18 22:54:54
そういうスクリプト言語についてはまた別に考えればいいじゃん。
「バイナリをゲロる言語の魅力って何」というテーマに沿って考えるにあたって、
今は「そもそもカーネルがバイナリファイルしか起動できないOSが普及してる」
という1つの事実に焦点を当てているとこなわけで。
51:デフォルトの名無しさん
06/10/18 23:10:35
いや、WindowsのカーネルはバッチファイルもEXE/COMの実行ファイルと同じ扱いで起動できる。
52:デフォルトの名無しさん
06/10/18 23:14:23
そういえば COMSPEC があった!w
こいつを lisp.exe とかにしとけば lisp のコードも一発起動か・・
53:デフォルトの名無しさん
06/10/18 23:46:38
>>50
> というのが元の発言だよね。長所短所の話ではなくて、「Unixでは違いが無い」
> というのがこの主張の肝でそ。
54:デフォルトの名無しさん
06/10/19 07:04:27
初心者意見なんだけどバイナリをゲロる言語でも、
スクリプトのようにも実行可能なコンパイラの拡張ってしないのかなあ。
ソースの頭に#!/usr/bin/gccひっつけて、実行形式変換すれば
スクリプト言語のように実行可能とか。
55:デフォルトの名無しさん
06/10/19 07:12:23
>>54
D言語使うといいよ
56:デフォルトの名無しさん
06/10/19 11:59:25
>>54
つ[#!/tcc -run]
57:デフォルトの名無しさん
06/10/20 00:30:42
>>55
いつの間にそんな機能がついたんだ。変態言語だなｗ
58:デフォルトの名無しさん
06/10/23 18:39:46
>>54
先頭1行削ってテンポラリの実行ファイルを作って実行、
というgccrunなるスクリプトを作って、
#!/usr/local/bin/gccrun
とか書いておけばいいのでは・・・
59:デフォルトの名無しさん
06/11/21 12:57:10
>>1
機能的な面はさておき、
スクリプト言語よりもCとかjavaの方が文系経営者に信頼されるでしょう
60:デフォルトの名無しさん
06/11/21 13:13:32
>>1
自作スクリプト言語の処理系を作るのに役立ってます
61:デフォルトの名無しさん
06/12/09 06:46:27
JAVA
Java
java
NullPo
62:デフォルトの名無しさん
06/12/29 02:50:50
ジャヴァ
じゃわ
ι゛ゃゎ
Gagh
63:デフォルトの名無しさん
06/12/29 05:46:19
>>54
exerb
(ruby)
64:デフォルトの名無しさん
07/04/10 16:38:42
Windowsでも、拡張子に対して実行ファイルを指定すれば、インタープリタの起動は勝手にしてくれるし
PATHEXTを設定すれば、コマンドラインでも意識することなく使用することが可能
65:デフォルトの名無しさん
07/04/19 13:37:47
あるOSの信者は別のOSのことは詳しくは無い
66:デフォルトの名無しさん
07/04/20 23:12:57
>>64
シェル経由の話じゃないんだよね。
一番プリミティブなとこのAPIが対応してるかってのが重要。
スクリプト言語のスクリプトファイルに対して直接CreateProcessできて、
インタープリタのパスが分からなくても、セキュリティコンテキストの継承とか指定とかできるかってこと。
少なくとも現行のWindowsではできない。
67:デフォルトの名無しさん
07/04/23 15:55:34
>>66
俺はバカだから良く分からないのだが...
ShellExecuteじゃ駄目なん?
68:デフォルトの名無しさん
07/04/30 11:24:20
UNIXの
#!/fugafuga/hogehoge
行って誰が解析してるん？
69:デフォルトの名無しさん
07/04/30 11:50:26
kernel?
70:デフォルトの名無しさん
07/04/30 16:27:49
>>68
execve
71:デフォルトの名無しさん
07/04/30 16:52:02
Wikipediaをwikiって略すな！
同時にWikipedia以外のWikiも盛り上げよう！
72:デフォルトの名無しさん
07/05/07 01:27:33
>>1
では、そのスクリプトを実行するプログラムはスクリプトなのか？
そうだとしても、結局それを実行するのはバイナリだろう。
スクリプトはバイナリの存在が無ければ成り立たない。
その事を理解していればそんな事は言えないだろう。
まあスクリプトを直接解釈するCPUがあるなら別だが。
73:デフォルトの名無しさん
07/09/19 17:00:29
>>72
スクリプトを直接解釈するCPUならば、それは既にスクリプトではなくバイナリでは?
74:デフォルトの名無しさん
07/10/15 14:35:42
>>68
ばあちゃんが言ってた
死んだじいちゃんが解析してるんだってさ
75:デフォルトの名無しさん
07/10/15 19:39:52
>68
execve(2)
76:デフォルトの名無しさん
07/11/12 15:18:22
てか、evalれない言語なんて、メタプログラミングしにくすぎ
C言語のマクロ、C++のtemplateクソすぎるし
77:デフォルトの名無しさん
07/11/18 12:47:36
Manpage of EXECVE より
> execve() は、filename によって指定されたプログラムを実行する。
> filename は、バイナリ実行形式か、以下の形式の行で始まるスクリプトでなければならない。
>
> #! interpreter [optional-arg]
...
> interpreter は有効な実行ファイルのパス名でなければならず、
> それ自身がスクリプトであってはならない。
つまり、スクリプト型実行ファイルでは、インタプリタを実装出来ない。
windowsよりはスクリプトの実行がシステムAPIレベルでサポートされているが、
バイナリ実行形式と同様のサポートとは言い難い。
と亀レスしてみる
78:デフォルトの名無しさん
07/11/19 23:53:14
用途に応じて使い分けるが正解だろ？
ペンチとプライヤー，どっちが優れてるかなんてのは愚問。
79:デフォルトの名無しさん
07/11/20 16:37:07
>>34
ははは/bin/sh等の存在は無視ですか？そうですか。
80:デフォルトの名無しさん
07/11/25 18:19:10
スクリプトでもバイナリ作ってから実行するのあるよ。
pythonとか。
81:デフォルトの名無しさん
07/12/05 00:56:29
おれもわからなくなってきたけど、バイトコードで動くやつもバイナリっていうのか？
82:デフォルトの名無しさん
07/12/05 21:38:59
>>81
URLﾘﾝｸ(ja.wikipedia.org)バイナリ
ここを信用するなら、バイトコードもバイナリだね
83:デフォルトの名無しさん
08/02/11 21:03:38
読める文字で書かれてないものは全てバイナリ
84:デフォルトの名無しさん
08/04/08 14:28:42
brainf*ckは？
85:デフォルトの名無しさん
08/04/08 16:36:16
whitespace？
86:エビフリャー
08/06/29 17:46:42
タモリ鉄道博物館
・名古屋市営地下鉄の車内搭載発車促進メロディーはフジテレビ系「なるほど・ザ・ワールド」の時間切れ前警報音を参考にして考案されたものです。
・ドレミファモーター（京浜急行）は芸能界の鉄道ファンタモリさんがテレビ朝日系「タモリ倶楽部」の中でで考案しました。
・名鉄パノラマカー7000系の発車音・走行音・減速音・停止音は日本テレビ系「欽ちゃんの仮装大賞」の不合格の時の効果音に似ている。
・西鉄のnimocaは歌手でタレントで倖田來未の実妹であるmisonoさんが考案したのもです。
タモリ空耳アワー
・高校三年生： あ、あー、あ、あ、あー 合ーコン三年生ーーーーーーーーーー
タモリさん名古屋大好き
・タモリさんはエビフリャーの名付け親です。
・タモリさんは日本の中で名古屋が一番好きであり、且つ地元の人以上に名古屋の文化や風習に詳しい人です。
・タモリさんは自分の第2のふるさとは名古屋であると言っており、将来名古屋市役所から名古屋親善大使として任命されると思います。
87:デフォルトの名無しさん
08/06/29 20:13:13
結論から言うと、バッチファイルやVBScriptはバイナリってこと？
88:デフォルトの名無しさん
08/06/30 20:57:36
なんじゃそりゃ
89:デフォルトの名無しさん
08/10/29 15:44:49
#!に処理系を書かない限り動かないなんて糞みたいな仕様だろ
処理系を、標準とは違うpathにインストールされてたら動かないじゃん
90:デフォルトの名無しさん
08/10/29 15:48:44
別にフルパスで書かなきゃいけないわけじゃないけどね。
91:デフォルトの名無しさん
08/10/29 15:57:25
でもスペル書き間違えたら動かないじゃん