バイナリをゲロる言語の魅力って何？

スクリプト言語でじゅうぶんぢゃん。

他人に使ってもらうプログラムはバイナリのほうがいいかも。

これの宣伝スレ?

http://0xcc.net/pub/decon2006/0015.html

バイナリをゲロってくれるのはおまけ。
その言語を使いたい（あるいは使わなければならない）理由がほかにあるから使う、それだけ。

ゲロるってコアを吐くってこと？

必要に応じて使い分ける。
ただそれだけ。

あっそ

バイナリ以外を出力する言語って何がある？

インタプリタは特にバイナリはゲロしないよな

ゲロるだなんて言うな！
バイナリってのはプログラム言語という卵子に俺のコードという精子を
ぶっかけることによって生まれてくる赤ん坊なんだ！ ひとつの命なんだよ！！

プログラミング言語とコンパイラ/インタプリタを混同している奴がいるな

バイナリをゲロる言語はとても良いあんばいナリ

>>1
スクリプトは遅すぎるから簡単な操作にしか使えないじゃん。

>>1は1つの言語しか使えない。
しかも、スクリプト系。

としゃぶつ

俺が今保守してるプロジェクトなんか、実行時間の99%以上はIOに費やしてるような
コードばっかりだから、Cなんか使わないでいいだろって思うよ。

>>16
その考えは別に問題なし
スクリプト言語で何でも出来ると思ってるのは間違い

バイナリを吐く言語の魅力
・多くのOSで、いわゆる「バイナリ」はコンテナファイル。
　PEとか、ELFとかCOFFとか。なので、コード以外のリソースをまとめられる。アイコンとか。
　メタデータを多重化できると言えばいいのか。　スクリプトでも頑張ればできるかも。
・解析が難しくなる。本気で解析されたらなんとでもなるけど。
・実行権限を独自に設定できる。
　Windows上だけの魅力だな。

機能的、速度的な違いは本質的ではない。
Unix系の、スクリプトの実行がシステムからサポートされるシステムと、
そうではないWindowsでは話が異なる。
Unix系だと、違いは無いと思う。

>>18
jarやODF考えるとコンテナだからいいってのは微妙…
実行環境次第ではなんとでもなるし。

むしろ、PC以外の環境(の方が実社会でははるかに多い、携帯とか)を
考慮したときに、>>1は糞、という結論。

>>18
まとめられるのは長所でも短所でもある。
文字列リソースなんかはむしろ外の方がいい。（隠したいなら別だが）
しかも、スクリプトもそんなに頑張らなくてもまとめられる。

>機能的、速度的な違いは本質的ではない。
この問題をあえて避けるのはどうかと思うが…。
結局は、このバランス取りを考えてどちらの言語を使うか？
という問題に落ち着くと思う

>>18
> Unix系の、スクリプトの実行がシステムからサポートされるシステムと、
> そうではないWindowsでは話が異なる。
アホなのかどうなのか知らんが、別にwindowsでもスクリプトの実行はサポート
されてるぞ。

というか、そのレス全体的に思い込みで書いてるだろ。

shebangのことを言ってるんだろうか>>18

windowsのスクリプトの方が強力だよね

>>21
・スクリプトに実行権限つける。
  - そのユーザの権限で、インタープリタ直接は実行不可だけど、そのスクリプトの実行は許可する
・拡張子以外の方法で、インタープリタを指定する。
  - #! 記法と同等のこと。
が、Windowsでできる？

setuidもできると良いけど、もともとWindowsには無いので、期待しない。
(Windows上ではバイナリ/スクリプトの差にはならない)

>>24
Windows Script Hostを勉強した方がいいと思うよ
un*xのスクリプトよりはるかに優秀

とりあえずwsf使えば、後者は達成できるな。

Windows の場合はカーネルがインタプリタを起動してくれないね、という話でそ。
CreateProcess でスクリプトを実行できないので、インタプリタを起動して引数でソースを指定するか、
ShellExecute でシェルを経由するかしなくてはならない。

>>26
wsf って拡張子いらないんだっけ？

NT系では、環境変数PATHEXT。

大抵の環境では拡張子が表示されないから問題ない

>>24
>が、Windowsでできる？
出来ても大して嬉しくないんだが…。
どうせ、他言語のスクリプトは動かないし。
つーか、一般ユーザー権限でログインして、NTFSにして、cygwin使えと。
こんなことだけで、バイナリとスクリプトは同じだ。なんて言う人はおそらく一人。

SFU最強伝説

>>30
流れを読め。
>>21がトンチンカンンなこと書いてるから突っ込まれてるわけで、
Windows でそういうことがしたいと言っているわけではないだろう。

>>30
WSHは任意の言語を実行できるようになっている。
VBScript, JScript以外にはActivePerl, ActiveScriptRubyが存在する。

Unix 系の OS では、実行許可ビットが立っていて、ファイルの先頭が#!/foo/barであれば、
カーネルがインタプリタ/foo/barを起動してそのファイルをスクリプトとして実行してくれる。

Windows では、ユーザなりシェルなりがインタプリタを起動して、スクリプトファイルを渡して
あげる必要がある。wsh ならば wsh.exe を起動して、引数でスクリプトファイルを渡す、等。

そういう違いがあるね、というだけの話。

>>32
>Windows でそういうことがしたいと言っているわけではないだろう。
そういうことをさせたくて書いたわけではなく、
そうすれば、>>34の違いはゴミみたいな問題になるでしょ。
という意味で書いた。

このゴミみたいな問題で、バイナリとスクリプトの長所の違いを
見るっつーのは、可笑しいだろ？

>>33
その4つしか選べないんなら、「任意」とは言わんだろ。
wshのフレームワークに組み込まれた言語を選択できる、って言い方になる。

>>35
実質的に、その「ゴミみたいな違い」しか、違いは無い、と思うが。
ゴミみたいな違いってのは、カーネルが直接実行形式とみなして、
属性評価を行う、ってことね。

>>24
#!記法は、解釈しないインタプリタもあれば解釈するコンパイラもあるぞ。
まったく本質的じゃないな。それは言語の周辺環境のごく一部の話だと
思うんだが。

#!記法に対応してるインタプリタがある言語の、Unixもどき系OSにおいての
利便性の違いだけを話してたの？ 意味はあるけど本質じゃないよな。

>>37
#!はインタプリタやコンパイラが解釈するんじゃなくて、カーネルが解釈する。

ウィンドウズの場合は、プロセスを起動する側がそのスクリプトを解釈する
インタプリタを知っていて、それを起動しなくちゃならないけど（←シェルに任せ
てもいいけど）、Unix ではそれをカーネルがやっているという話。

>>35
＞Unix系の、スクリプトの実行がシステムからサポートされるシステムと、
＞そうではないWindowsでは話が異なる。
＞Unix系だと、違いは無いと思う。

というのが元の発言だよね。長所短所の話ではなくて、「Unixでは違いが無い」
というのがこの主張の肝でそ。

Windows だとやっぱり違いがあると思うなぁ・・・
スクリプトはCreateProcessでは起動できないとか、拡張子で関連付けしておかないと
ShellExecute でもエクスプローラーでのダブルクリックでも起動できないとか。

なんでそんなくだらないことに拘るんだ？
Windowsはexeファイルすら関連付けしないと起動しないぞ？ｗ

いいかげん、
OSの違いを抜きに話し進めてくれないか？

アフォが信じて流布しちゃうわないように、小さな嘘やでたらめは
早い段階でちゃんと否定しておいた方がいいだろ。

>>39
関連付けなんかなくたって、CreateProcess で起動できますよ。

ここは言語スレであってOSスレじゃないな

「バイナリを吐く言語」に魅力があるのか、
言語としてのC++に魅力があるのか、
現状のバイナリを吐くC++に魅力があるのか、
と考えると3番目だけが事実だと思う。

（思うのはたぶん自由なのだろうから責めないでくれ）

バイナリを吐くC#が出来ないかな〜と妄想してみる

>>38
> #!はインタプリタやコンパイラが解釈するんじゃなくて、カーネルが解釈する。
カーネルから渡されたあとにインタプリタやコンパイラが読み飛ばせなきゃ、
スクリプトは動かないよ。
人の話を無視してお前の言いたいことをリピートされても困る。

その言語を用いて書かれたプログラムを起動する方法が
・バイナリとスクリプト言語のどちらも同じ (unix)
・バイナリとスクリプト言語では異なっている (Windows)
のなら、後者についてはその差異による優劣が発生する可能性がある。

Windows に詳しい人が「そんなのありませんよ」と否定すれば
それまでだけど。

>>46
#!記法は解釈しないインタプリタもあれば解釈するコンパイラもあるっつーに。

Windowsの場合、解釈するカーネルは無いでそ。
それを言ってる。

だから普通のバイナリのようには使えない。
これでバイナリとスクリプトの優劣があると言えるほどの
差異なのかどうかはわからないけど。

カーネルが解釈しようがしまいが言語側が解釈できなきゃ意味ないんだってば。
スクリプト言語は#!を解釈するというその思い込みをどうにかしろよ。

そういうスクリプト言語についてはまた別に考えればいいじゃん。

「バイナリをゲロる言語の魅力って何」というテーマに沿って考えるにあたって、
今は「そもそもカーネルがバイナリファイルしか起動できないOSが普及してる」
という1つの事実に焦点を当てているとこなわけで。

いや、WindowsのカーネルはバッチファイルもEXE/COMの実行ファイルと同じ扱いで起動できる。

そういえば COMSPEC があった!w
こいつを lisp.exe とかにしとけば lisp のコードも一発起動か・・

>>50
> というのが元の発言だよね。長所短所の話ではなくて、「Unixでは違いが無い」
> というのがこの主張の肝でそ。

初心者意見なんだけどバイナリをゲロる言語でも、
スクリプトのようにも実行可能なコンパイラの拡張ってしないのかなあ。

ソースの頭に#!/usr/bin/gccひっつけて、実行形式変換すれば
スクリプト言語のように実行可能とか。

>>54
D言語使うといいよ

>>54
つ[#!/tcc -run]

>>55
いつの間にそんな機能がついたんだ。変態言語だなｗ

>>54
先頭1行削ってテンポラリの実行ファイルを作って実行、
というgccrunなるスクリプトを作って、
#!/usr/local/bin/gccrun
とか書いておけばいいのでは・・・

>>1
機能的な面はさておき、
スクリプト言語よりもCとかjavaの方が文系経営者に信頼されるでしょう

>>1
自作スクリプト言語の処理系を作るのに役立ってます

JAVA
Java
java

NullPo

ジャヴァ
じゃわ
ι゛ゃゎ

Gagh

>>54
exerb
(ruby)

Windowsでも、拡張子に対して実行ファイルを指定すれば、インタープリタの起動は勝手にしてくれるし
PATHEXTを設定すれば、コマンドラインでも意識することなく使用することが可能

あるOSの信者は別のOSのことは詳しくは無い

>>64
シェル経由の話じゃないんだよね。
一番プリミティブなとこのAPIが対応してるかってのが重要。
スクリプト言語のスクリプトファイルに対して直接CreateProcessできて、
インタープリタのパスが分からなくても、セキュリティコンテキストの継承とか指定とかできるかってこと。
少なくとも現行のWindowsではできない。

>>66
俺はバカだから良く分からないのだが...
ShellExecuteじゃ駄目なん?

UNIXの

#!/fugafuga/hogehoge

行って誰が解析してるん？

kernel?

>>68
execve

Wikipediaをwikiって略すな！
同時にWikipedia以外のWikiも盛り上げよう！

>>1
では、そのスクリプトを実行するプログラムはスクリプトなのか？
そうだとしても、結局それを実行するのはバイナリだろう。
スクリプトはバイナリの存在が無ければ成り立たない。
その事を理解していればそんな事は言えないだろう。

まあスクリプトを直接解釈するCPUがあるなら別だが。

>>72
スクリプトを直接解釈するCPUならば、それは既にスクリプトではなくバイナリでは?

>>68
ばあちゃんが言ってた
死んだじいちゃんが解析してるんだってさ

>68
execve(2)

てか、evalれない言語なんて、メタプログラミングしにくすぎ
C言語のマクロ、C++のtemplateクソすぎるし

Manpage of EXECVE より
> execve() は、filename によって指定されたプログラムを実行する。
> filename は、バイナリ実行形式か、以下の形式の行で始まるスクリプトでなければならない。
>
> #! interpreter [optional-arg]
...
> interpreter は有効な実行ファイルのパス名でなければならず、
> それ自身がスクリプトであってはならない。

つまり、スクリプト型実行ファイルでは、インタプリタを実装出来ない。
windowsよりはスクリプトの実行がシステムAPIレベルでサポートされているが、
バイナリ実行形式と同様のサポートとは言い難い。



と亀レスしてみる

用途に応じて使い分けるが正解だろ？
ペンチとプライヤー，どっちが優れてるかなんてのは愚問。

>>34

ははは/bin/sh等の存在は無視ですか？そうですか。

スクリプトでもバイナリ作ってから実行するのあるよ。
pythonとか。

おれもわからなくなってきたけど、バイトコードで動くやつもバイナリっていうのか？

>>81
ttp://ja.wikipedia.org/wiki/バイナリ
ここを信用するなら、バイトコードもバイナリだね

読める文字で書かれてないものは全てバイナリ

brainf*ckは？

whitespace？

タモリ鉄道博物館
　・名古屋市営地下鉄の車内搭載発車促進メロディーはフジテレビ系「なるほど・ザ・ワールド」の時間切れ前警報音を参考にして考案されたものです。
　・ドレミファモーター（京浜急行）は芸能界の鉄道ファンタモリさんがテレビ朝日系「タモリ倶楽部」の中でで考案しました。
　・名鉄パノラマカー7000系の発車音・走行音・減速音・停止音は日本テレビ系「欽ちゃんの仮装大賞」の不合格の時の効果音に似ている。
　・西鉄のnimocaは歌手でタレントで倖田來未の実妹であるmisonoさんが考案したのもです。
タモリ空耳アワー
　・高校三年生：　あ、あー、あ、あ、あー　合ーコン三年生ーーーーーーーーーー
タモリさん名古屋大好き
　・タモリさんはエビフリャーの名付け親です。
　・タモリさんは日本の中で名古屋が一番好きであり、且つ地元の人以上に名古屋の文化や風習に詳しい人です。
　・タモリさんは自分の第2のふるさとは名古屋であると言っており、将来名古屋市役所から名古屋親善大使として任命されると思います。

結論から言うと、バッチファイルやVBScriptはバイナリってこと？

なんじゃそりゃ

#!に処理系を書かない限り動かないなんて糞みたいな仕様だろ
処理系を、標準とは違うpathにインストールされてたら動かないじゃん

別にフルパスで書かなきゃいけないわけじゃないけどね。

でもスペル書き間違えたら動かないじゃん

またそういうことを

スレ違い

465 名刺は切らしておりまして 2009/04/22(水) 23:04:36 ID:LMZKff4U
>>447
それでも歴史は繰り返す(w

メインフレームはCPUもOSも最初から仮想化の権化だったが
(数十年前のアセンブラやバイナリが、最新モデルで今も無修正で動く)、
ハード依存ばりばり、ハード丸見えだぜ！のUNIXやx86が台頭した。

一時はMicrokernelやOOがもてはやされたが、
NT kernelやLinuxを含めて後退した。

Javaの理想はOS非依存だが、実際はJSFとかも併用される。
.NET(CLR)もサーバー本体の開発には使われない。

OSI/COM+/CORBA/EJB/SOAPとか、理想だが面倒で遅いものは結局普及しない。

技術者は美学でレイヤーに走るが、遅いと売れないのでハード依存に戻る。
ハードの性能は上がるが、同じハードで遅ければ評判を落とす。

歴史は繰り返す(w