- グラフィカルなプログラミング言語ない？
847 ：デフォルトの名無しさん[sage]：2014/04/25(金) 01:04:32.37 ID:4klH39dY - >>845
それ用意されているものを配置しているだけでしょう？
|
- Git 9
141 ：デフォルトの名無しさん[sage]：2014/04/25(金) 04:23:50.66 ID:4klH39dY - 気に入らない部分が、git以外には多すぎる。
|
- Git 9
144 ：デフォルトの名無しさん[sage]：2014/04/25(金) 11:14:49.10 ID:4klH39dY - 三つ前のコミットIDから
ブランチ作ればいいじゃん。
|
- グラフィカルなプログラミング言語ない？
850 ：デフォルトの名無しさん[sage]：2014/04/25(金) 11:28:40.59 ID:4klH39dY - >>849
えと、だからそのライブラリ（用意されているパーツ）を
どうやって作るのかを見てみたいって話なんだけど。
|
- グラフィカルなプログラミング言語ない？
852 ：デフォルトの名無しさん[sage]：2014/04/25(金) 12:20:07.17 ID:4klH39dY - 残念、結局普通の言語で作るのか。
グラフィカルなプログラミング言語というより
用意されているものを、つなげるだけなのね。
|
- グラフィカルなプログラミング言語ない？
854 ：デフォルトの名無しさん[sage]：2014/04/25(金) 13:40:48.39 ID:4klH39dY - >>853
> いや、だから普通の言語と同じでしょ。
それは言い方がおかしい。
君が言った
> 一般的な話としてはプリミティブな奴は普通の言語で作ればいいでしょ？
からすると、
グラフィカル言語が普通の言語と同じなのではなく、
パーツを作るときにはグラフィカル言語のやり方ができないので、
普通の言語で作るしか無いという意味でしょう？
|
- 文字コード総合スレ part8
852 ：デフォルトの名無しさん[sage]：2014/04/25(金) 13:55:02.90 ID:4klH39dY - 何を悩んでいるのかしら無いけど、
初期のUTF16の話として16bit固定っていうのはわかるよね？
C言語風に書くならば、WCHAR型（16bit）となって、
WCHAR *text = "あいうえお";
こういう定義になる。
この時のメモリ配列はC言語の仕様によりCPUのエンディアンによって変わる。
このメモリ内容がUTF-16BEやUTF-16LEなんだよ。
ファイルに保存するときはどちらかに統一してもいいが、
処理を速くするためにCPUに合わせた形式でメモリには格納しないといけない。
だからUTF16-BEかUTF16-LEというものが生まれることになる。
メモリ内で使うために、UTF16-BE と UTF16-LE の存在を無くすことは出来ない。
そのメモリ内容をそのまま保存することもある。テキストファイルではなくて
構造体データの一部としてテキストが含まれている場合とか、一項目ずつ保存するのではなくて
メモリの構造体データを丸ごと保存したりするからね。
だから、UTF16-BEかUTF16-LEという存在はCPUのエンディアンの存在によって生まれ、
それを保存するファイルに格納されたデータの呼び名にもなる。
|
- グラフィカルなプログラミング言語ない？
856 ：デフォルトの名無しさん[sage]：2014/04/25(金) 14:02:45.52 ID:4klH39dY - >>855
だって、プリミティブなもの（＝パーツ）を
どうやって作るのかを質問したのですから・・・。
|