僕「C勉強してパソコン詳しくなりたい」教本「まず#includeスタジオH。呪文みたいなものだと思って」
■ このスレッドは過去ログ倉庫に格納されています
プログラムとパソコンは何の関係もない
君はパソコンに詳しくなって何がしたいんだい? テキストエディタで、 studio.h ファイルの中身を見るんだ! またプログラムを難しく教えるバカが出てきたか、 プログラムそのものに難しいものなんてないよ 必ず書くものならコンパイラが自動で含めろよとは思う おっと、 stdio.h か。果てしない迷宮の始まりとも言える。 >>4
それ面白いツッコミだと思ってんのお前だけだよ とにかく情報詰め込んで一晩寝れば何となくわかるようになる C言語なんか一日で大体マスターしろ!
あんなの日本語覚えるより簡単だぞ >>13
気持ちは分かるけど、日本語より難しいプログラミング言語自体が存在しないのでは >>14
brain fackとか言う嫌がらせしたいだけの言語なら でも確かにincludeは呪文です
と説明放棄する参考書多いな
決して放棄していいものではないけどね アセンブラとか幾何代数やった方がいいような
Cなんてアセンブラ知っていれば覚えなくても書けるし C言語の仕様ってよりコンパイラへの指示だからなぁ
Cは言語の組み込み関数とか命令がシンプルだから最低限のプログラム作るにもライブラリ関数が必須で、その辺の仕組をサンプル打ち込んで慣れろって初心者に説明すると混乱しやすいんだわな
studioの中にもinclude出てくるし 新しい語学学ぶのとそう変わりないんだ
人間相手じゃなくて機械相手への言葉なんだから 基本IOを使えるようにするだけの事で
何を諦めるんだっていう 今はわざわざCでつくるものってドライバとかゲームエンジンとか低レベルなものくらいじゃね?
(低レベルってのは技術的にレベルが低いという意味じゃなくハードに近いって意味で)
Cの絵本とかでポインタの概念をおさえておくくらいで十分でしょ。
まぁ、なにがやりたいかにもよるけど プログラムなんて所詮
データを読み込んで処理して格納するだけしか出来ないんだし
難しく考える必要も無ければ
変に自慢するような事でもないんだがな >>22
おまじないなんて曖昧な書き方するのが悪いんだ ほんで使うのがprintfだというのだから初心者には難儀な言語だなと思う includeすら分からない調べないゴミは言語変えようがあるいはツクールすらまともなもん作れないから
素直にFGOで鯖太郎してた方がマシだよ おまじないってのは
「お前には理解するための知識がねぇから」
をオブラートに包んだ表現やぞ すべての言語をマスターしてもパソコンに詳しくなるなんてことはないぞ プログラムの本質は想定通りに動作する事
学習が進めばstdio.hの役割を知る事は必要だけど
初心者には呪文でいい
>>1の様に変な所でつまずいてしまう 後でわかるようになるのにそこで躓いて止めちゃう奴は学習能力が低いと言わざるを得ない パソコンに詳しくなるためにGUI前提ですらない超古くさい言語を今更やってどうする 別に古臭くはないけどな
CUDAとかC言語がベースだし そもそも何で C 言語なんだ?
ドットネットが存在する今、別の言語でもいいだろう
C言のどこに詳しくなれる要素があるんだ?
ちなみにコンピューターの現場では、コンピューターを作ったのはアメリカ人だから英語ができないとコンピューターが使えないとか、
プログラムは英語だから英語が出来ない奴はプログラムを書いてはいけないとか、
コンピューター用語を英語で『書けない』やつはコンピューターを使う資格がないとかいう理屈が普通に通る場所 Cを学びたいのにいきなりスタジオでHするとか難易度高過ぎ〜!
てネタじゃないのか
違うのか おまじないでもスタンダードI/Oって言葉は書いてる
それで大体なんのことか分かるだろ ブレインファックは難解というかプログラムの原理そのものだから基礎を学ぶ為ならやって損はない
実用に生かす機会もないけど そろそろincludeからimportになるから。
あと、スタジオhはマジ呪文。探しても見つからないと思うけど プログラミング言語ってバイクメーカーみたく派閥があるんだっけ? >>44
C教とかJava教とか
最近なんか主張始めたPyton教徒とか
C教にはgnu原理主義も多い プログラミング言語としてはC#とSwiftが好き。 C言語自体はそんなに難しくもない
unixでプログラム作ってる分には普通に作れる
だがwindowsお前は駄目だ
プロシージャーとか何なんだよ
あれで嫌なったわ
しかも少しだけ処理したらOS側に処理返してやらないと占有し続けるとか
何時までイベントドリブンなんて引きずってんだよ
と昔思いました
今どうなってるかはもう全く分からんがw プログラムや派閥とか宗教作ってるやつはプログラミング下手なやつだから
プログラムは全てゴミクズ、 どれを使いこなしても自慢になりはしない
企業でプログラムやコンピュータスキルより重要視されるのがTOEICの時点で気づけ 詳しい人が多そうだから聞くけど
ディズニー・プログラミング学習教材「テクノロジア魔法学校」
https://www.technologia-schoolofmagic.jp/
ぷよぷよプログラミング
https://edu.monaca.io/puyo
こういうのはどうなの?
プロになる気はないけどお絵かきはほどほど出来るので
ミニゲームみたいな同人エロゲとか作りたい >>51
シェルスクリプトで覚えたらルートとか権限とかも理解できるから
案外プログラム覚える近道だったりするんかな >>55
どの程度がっつりプログラミングやるかと
人それぞれの適正みたいなにもよるから一概には言えない
パズルゲームみたいな感覚でプログラミングそのものを楽しめるタイプもいれば
勉強や仕事として真面目にやって身につけるタイプもいるし
絵が専門ならがっつりやりたいってわけじゃなさそうだから、
最終的には作りたいものが楽に作れるツールを使う形になると思う。
高度なものになるほど、ちゃんとしたスキルがいるけど
そういうツールレベルで基礎から逸脱しなければググりながらやれば結構なんとかなるから思うより難しくはない。
ただ、そういうツールを使うのでもプログラミング的思考ができるかどうかで違うし、
そこらへんを楽しめる範囲でそのあたり学べる本か講座を選ぶといいかもね。
オンライン講座はやったことないかどんな感じかはしらんけど、その2つで言うなら上の方がいいと思う
学習のコツみたいなのをいえば、プログラミングで大事なのは
簡単に考えること、簡単に考えられるようにすること。
プログラミングで一番有名な格言が「分割して統治せよ(困難は分割せよ)」なように
プログラミングの文化はいかに問題を簡単に扱えるようにするかという発想で発展してきたから
難しく雑然と考えるのではなく、シンプルに機械的に考える感覚が身につくと楽になる
プログラミングそのものの学習になるってわけじゃないけど、
そういう意味ではこないだ日本ゲームデザイナーズ大賞を受賞したbaba is youは
プログラミングをやってるときに近い思考と快感があるから感覚をイメージするにはオススメ、とゲハらしくしめてみる >>57
Powershell覚えればついでにWindowsにも詳しくなれるから有用といえば有用
でも就職後のお役立ち度合いではExcelVBAの方が上だと思う プログラムなんか覚えても金にならんから他の事やったほうがいいよ
人生リソースの無駄遣い >>58
ありがとう
よくわからんがまあツクールでもやってみてから教材選んでみるかな
RPGが作りたいわけじゃないんだが勉強にはなるだろ というかおまじないって言ってる教本も
とりあえず今はおまじないの様な物だと思っておいてください
って書いてるだろ。
その指示に従えよw いうて「アルゴリズムとか仕様とかがみえるようになってきたらよかったね」程度の教材にしかならんぞ
「自分が何を作りたいか」が最初にあって「どう作るか」が後からついてくるんだから
ツクールで作れるならそれで完結できるだろ
>>1
includeを「おまじない」と言っちゃうバカが
致命的なバグを生み出しまくったりするからな
「理由はわからんけど、なんか動いたからヨシッ」って奴は
オノで頭をカチ割ってブタの餌にしたくなる >>58
プログラム作る時に役にたつ思考法って背理法や数学的帰納法だよね
否定すると矛盾が発生するから真とか
要素を一つずつ増やして具体的な数値を計算してイメージと照合しながら実際のモデルを組み上げてくとか cは教本の変数名やら関数名が長すぎてめんどっちくなったわ
大昔のメモリカツカツbasicの方が読むのにしんどくない 多すぎる括弧の種類と何だっけtabキー?字下げ?あのへんの編集が煩わしい 書いてるとだんだん格ゲのコマンド打つみたいな感じでバシバシかけるようになってくの快感だったな
まぁもうとっくに書かなくなったけど スタンダードアイオー、エスティディアイオーって読むの面倒 >>51
Windows自体がそういうもんだからね
UIやキーボードやマウスを触るとEVENTが発生し、
プログラムはそのEVENTをシステムから取って取捨選択して処理する
Windowsプログラムは寄生虫で、宿主のWindowsシステムとセットじゃないと動かない C言語の知識あるとスパイウェアにも詳しくなれたりするんだろうか >>72
C言語だけ知ってても駄目だが、スパイウェアに本当に詳しい人はC言語でプログラム書けと言われたら書けると思う standard input and output
略してstdio
そりゃわからんわw >>73
いや、C言語ってOSを記述するのにも使ってるくらいだし
ハードを直接叩くソフトウェア作るのに向いてるのかなって JAVAだったらAPIを指定してあげるだけだった気がする
オブジェクトプログラムの方がとっつきやすいから頑張れぇ C言語勉強したの懐かしいな
ポインタとアドレスで死ぬがよい >>76
向いてるというか基本的に知らないと話にならない C 言語の特徴は、人間が読みやすいという特徴を持っていながら、ある程度ハードウェアに直結した操作が行えるというメリットがある
そして今現在、そんなメリットは何もない、 しかし、コンピューターの基礎原理がわからない人には、 C 言語を学んだ方がいいのかもしれない
ど素人に01の論理回路教えても、興味すら引けないだろうし ポインタを誰でも理解できるように説明できた人はいまだ存在しない >>82
組み込みやらないならC#かkotlinからでいいよ。
組み込みも最近はC++だからCをすっ飛ばしても良いけどね。
プログラミングの勉強が進まない人はマイコンとかでやってみるのも手だよ。
実物が動くからユニティとかでゲーム作りながら覚えるってのと同じくらいに達成感があるから長続きするで。 Cのポインターを真に理解するためには、機械語から入ったほう良いと思う。
俺はそれやったから、ああ機械語のあの機能を高級言語化しているんだなとすぐ分かった。
Cでは、関数へのポインターを返す関数の、ポインターの配列なんてのが普通に出てくるが、これも機械語が分かると直感的にあれをやっているんだなと分かる。 プログラムは義務教育で必修になるんだっけか
オッサンにとって興本を読むより小学生に頭下げて教えてもらった方が早い時代が来るよ Cを覚えても結局はやりたい分野の知識が必要になるからな
画像一つとってもデータ構造から理解しないと操れない
使うライブラリや統合環境の知識は必須だし
最近は便利になり過ぎてその便利さを享受するのに新しい知識が必要になるという悪循環 >>86
関数とか、関数へのポインターが関数の返し値になっているとか、一筋縄じゃいかないよね。 プログラムは出てくる英単語を辞書で全部日本語に直すのが一番の早道だと思った プログラムで大事なことは、言語に依存しない部分なのでやるならなんでもいい
一つやっとけば応用は利く >>1
スタンダードioだよw
スタジオにしてんじゃねえ >>91
pygameは実行速度微妙だしゲーム用途ならUnityの組み込みコードぐらいじゃん >>91
パイソンはスクリプト言語だから、実行速度もそれなり。やはりCは速い。可読性は悪いし、バグチェックも弱いけど。 >>83
ポインタ(名詞)やポインタ(動詞)って説明じゃダメなの?
ポインタをポインタるとか それで離脱する程度で
詳しくなりたいなんて言う資格はない 情報工学に命を捧げて死ぬ覚悟がないならプログラム開発なんて考えないほうが良いね
ゲームが作りたいならプランナーやディレクターになればいいだけだし とりあえずどうやったらコンピューターを理解してくれる教え方が出来るのか、
そしてコンピューターを学ぶ意味が全くない事をどう教えれば良いのか、
この両方を同時に実現しなくちゃいけない方法考えつつ、俺は寝るという選択肢を選んだ >>103
C言語を真に理解するには、機械語をかじる必要がある。
オブジェクト指向を真に理解するには、オブジェクト指向言語じゃないC言語をオブジェクト指向で書くデザインパターンなどのプログラム群を読解して初めて腑に落ちたよ。 >>103
なにかの本で
『プログラミングで一番有名な格言は「分割して統治せよ」だけど
オブジェクト指向はそれに「見えなければ気にならない」を加えたもの』と書かれてたな
箱型の装置があったとして、中身がどういうふうに動いてるかわからなくても
押しボタンがひとつついてれば、中身や仕組みを気にせず動作させ仕様させることができる、みたいな。
とはいえ、それだけだと書く場合はめんどくさい形式を強要されてるようで恩恵を感じづらい。
こういうふうにつかえて機能美があるんだって実感できるのはデザインパターンを学習してからかな。
結城浩先生のJava言語で学ぶデザインパターン入門が良書だからオススメ。
ただサンプルコードがJavaなのが今は使い所あんまなくて微妙かもだけど
難しいことはしてなかったと思うからさほど問題はないはず >>105
結城浩のあれは、デザインパターンの種類はわかるが、あくまで外見がわかるだけだな
個人的におすすめなのは、オブジェクト指向のこころ、って本が一番腑に落ちた
ただ、これ読むにはそれなりにプログラム組めることが前提にはなってくるかも >>103
オブジェクトってのは、データだけじゃなくて、そのデータ専用の関数を一緒に持つことが出来る
例えば、ケルビン温度クラスのオブジェクトに摂氏を出す関数(toC)と華氏を出す関数(toF)を持たせる様なイメージ
非オブジェクト志向だと、
KtoCとKtoFっていう関数を用意して、別途用意したケルビン温度のデータを入れて変換させるイメージ
これくらいだと大した差は無いけど、複数人で開発するようなのだと結構差が出る
非オブのKtoCやKtoFだと関係ない所から呼べたりするから、見当違いの使い方してバグるとか >>107
それはオブジェクト指向の説明では無いだろ。
それはオブジェクト指向を実現させる為のプログラミングの仕方だ。
まぁこんなレスしてるが既出の説明より上手く説明できる自信は全くないがw
電子工作から入るとオブジェクト指向って理解も利用できるようになるのも早いんだけどな。 >>108
>107の2行目以降は蛇足だからね
一言付け足すとしたら、存在するものは全部オブジェクトで良いよねっていう考え方がオブジェクト志向
たまにデータだけだったり関数だけだったりもするけど、両方無くちゃいけないとは言っていないのでセーフ プログラムなんてどうせ後から付け足しでスパゲッティになってくからオブジェクト指向もあまり意味ないのかなと
スカイリムを見て思いました 最初にある程度拡張できるように考えて作っても限界あるからね。
未来に求められる仕様なんて設計時に分からん。 たとえ中身がスパゲッティだろうと
入力と出力が確立してるなら問題ないということにしておこう オブジェクト指向って
より人間同士の会話に近いような融通の効く高級言語にしましたってことなんじゃないの
お互いの共通認識があれば「あれ」でもいろんな意味に取れて通じるみたいな
>>107ってその共通認識の設定の仕方でしょ オブジェクト指向というのは整理と分類の手法のこと
あるプログラムを作るとき「この領域は誰それ担当、あの領域は誰それ担当」
というふうに担当を決める
その区切られた区域はそれぞれ担当のデータと処理を持つ
それをクラスという
クラスは自分が担当するデータと処理に責任を持つ
責任の範囲を定める事を「カプセル化」という
クラスはそのクラスの機能を維持したまま拡張して別のクラスを作ることができる
これを「継承」という
あるクラスAがありそれが「処理Z」を持ってたとする
クラスAを継承したクラスB、クラスCがあるとする
クラスB、Cは同じコードで処理Zを呼び出せる
クラスAを入れられる箱にクラスBやCを取っ替え引っ替え入れて処理Zを
呼び出せる
このように違うクラスでも同じコードで同じ処理を呼び出せる事を
「ポリモーフィズム(多態性)」という
「カプセル化」「継承」「ポリモーフィズム」がオブジェクト指向を構成する
条件とされている あ、ちょっと言い方間違えたな
これじゃ不十分だ
クラスB、CはAを継承する時に処理Zの中身を変えれるんだ
クラスAの箱にクラスBを入れて処理Zを呼び出すとクラスBで書き換えられた
処理Zを呼び出せる
クラスAの箱にクラスCを入れて処理Zを呼び出すとクラスCで書き換えられた
処理Zを呼び出せる
このように同じコードで処理の内容が変わることが「ポリモーフィズム」 そんなこと繰り返してたらグチャグチャになってわけわからなくなったりしないの? グチャグチャになりにくくする工夫だぞ
もちろんなるときはなるけどな
最初のクラス設計が悪かったり、アホがムチャクチャしたらどうしようもないし 例えばゲーム機というクラスがあって、コントローラがあり、ボタンを押せば操作出来るということにすると、
ユーザーはどのゲーム機で遊ぶ場合でもボタン操作以外は基本的にやらなくていいわけな
中身にどんなチップ入ってるとかは気にしなくていい >>1
Cってのは言語を覚えるというより、プラットフォームの仕様を覚えるという感じに近い
高級言語の皮を被ったアセンブラと言われるぐらいだからね >>114
文章作る的な表現で言えば
クラスは定型文みたいな他でも引用可能な慣用句
カプセル化は主語の明記で「誰それは〜する」みたいな
継承が比喩で「例えば〜」みたいな、もしくはコピペ改変
ポリモーフィズムは言い回しだけ借りた別な表現で「猫に小判」や「鬼に金棒」みたいな感じ? 文章の書き方だと説明が難しそうだな
オブジェクト指向は概念、関係を整理して、知っておかなきゃいけないことと知らなくていいことを分け、同じ種類の概念には同じ知識で対応できるようにする >>122
複雑すぎて訳がわからんw
オブジェクト指向が一番わかりやすいのはシューティングゲーム
自機クラス、ステージクラス、自機弾クラス、敵クラス、入力クラスなどがある
入力クラスが自機クラスにメッセージを送り自機が動く
自機クラスは自機の移動や弾発射処理を持ってる
自機弾は自機弾の移動の処理を持ってる
そういうクラスごとに自分の処理を持ってその処理のアクセス権を設定するのがカプセル化
さて、敵のバリエーションを増やしたい、となった時敵クラスを派生させて
敵Aクラスを作る
これが継承だ
敵クラスにベースとなる移動処理、弾発射処理を付けておくと敵Aクラスでも
その処理が使える
しかし敵クラスの弾発射処理が例えば単なる単発弾で敵Aクラスでは3方向
発射に変えたいとする
そうすると敵Aクラスの弾発射処理を敵Aクラスで上書きしたい
これをオーバーライドという
敵クラスを入れられる箱にまず敵クラスを入れる
そして弾発射処理を行うと単発弾が出る
そしてその箱に敵Aクラスを入れて弾発射処理を行うと3方向弾を撃てる
同じ弾発射処理でも処理の内容を変えれる
これがポリモーフィズム プログラミングの本とかでも複雑で敷居高いんだよな
車クラスは乗り物クラスのサブクラスで云々みたいなのは良くあるけど、なんでそれが必要なのかが分からないと全く身に付かない
正直、実用的なサンプルコード見てこういうもんだってやった方が楽だと思う >>126
そう
なんでそれが必要なのか実感がないのよね
Cでも弾発射する場合単発でも3方向でも16方向でも関数一つでまかなえるし 丸暗記が苦手なタイプに良くある
覚えるときに意味と関連付けないと覚えられないんだ >>126
それはね
if文やswitch文を減らすため
例えば自機と敵が当たったとする
自機が敵を認識したとする
その認識した敵の「当たり処理」を呼び出したい
そういう時敵のクラスがバラバラだとその敵の当たり処理を呼び出すには
「敵aの場合」「敵bの場合」「敵cの場合」みたいにずらずらと分岐処理の
コードを書かないといけない
それがabc全部「敵baseクラス」の派生クラスだった場合敵baseクラスの当たり処理を
呼び出すだけでいい これの何が問題なのかというと
switch文がプログラムのそこかしこにあると例えば何万行もあるプログラムでは
対応できなくなりバグの山になる 所詮文法だから、数学分かってないと難しいねん
けどSEくらいならできるとかそんな微妙な感じ みんなが色々書いてるのを読むと何となくだけどそういうもんなのか
ってのが伝わってくるな
本だけ読んでもチンプンカンプンでプログラミング大昔に挫折したから >>126
正直車クラスのスーパークラスに乗り物クラスがある、とか
全くオブジェクト指向の説明になってないと思うしやめたほうがいいと思うね >>124
これは凄い解りやすいな。
ATMで説明したりするよりすげぇ解りやすいぞ。
シューティングゲームで説明するとか初めて聞いたけど
プログラミングを勉強した後で聞いたらこれは凄い解りやすい。
勉強する前はたぶん分からないけどw おまえらが他人になにかをレクチャーする能力がないのはよーく分かった
「勉強を終えた人間が見て分かり易い」とか何の役にも立たねえーんだわ
概念を学ばせるより、サンプルケースを示して作り方を解説する中で
プログラムの文法を学ぶ導線をしかないと誰もついてこない
デザインパターンとか経験3年目がようやく意識し始めるような概念なのに
いきなりぶつけるとかヘソ茶だぜぇぇぇえっぇぇぇぇぇlうぇ
なので初心者レベルの奴は実際に動くサンプルを掲載してる教本を中心に探してったほうがいい ガンダムWに出てくるガンダムという概念(クラス)には、自爆ボタンという操作(メソッド)がある
どのガンダムかということは気にせず、自爆ボタンを押せば自爆することが出来る
これがポリフォミズム
自爆装置がどうやって爆発物しているのかはパイロットにはどうでも良いのでので分からない(隠してある)
爆弾があるのかもしれないし、エンジンを暴走させてるのかもしれない
これがカプセル化
博士がちょっと弄ったデスサイズというガンダム(派生したもの)は自爆ボタンを押しても爆発しないように動作が変更されてたりすることもある
これがオーバーライド
ポリフォミズムの使い道として、色んな種類のガンダムを並べて同じ操作で次々自爆させることも出来る
エンドレスワルツのラストな PL/1最高やで!
IBMは凄く前にサポート切ったけど。COBOLにポインタの概念入れるなよ… >>129
そうそう、知りたいのは理由や動機なんだよな
そういうの教えずにやれって言われても頑として従わない人っているし
>>142
イラっとする理由をもそっと詳しく
でした
。
みたく改行して文が終了する感じがムカつくの?
最後の句読点まで「マル」って読ませる感じでなんかカワイイじゃん >>143
実際マジでその理由だけどな。
こっからここまで、ってのを分かりやすく示す為にやってる。 厚切りジェイソンがイジョウ!ってネタ締めるのもムカつかれてる可能性があるのか… >>128
今の教育は、全て小学校から高校まで、「なぜそうなるのか」「どんな意味があるのか」を丁寧に扱っている。
小学校でやった、筆算の仕方さえ「覚えろ!」ではなく、理由やら根拠やら意味やらで理解する形式だ。
それを分からず、いきなり「覚えろ!」とやるのは、教える側が自分でその事例をしっかり分析し、他人に
説明できるくらいの文章にできない何よりの証拠だ。自分が分かっていなくても、「とにかく覚えろ!」と
やるのは誰にでもできる!
まあ、ホントに分かっていなければ、実用的なコードさえ自分で組み立てられないのだろうが…でも質問
されて、教科書出す程度じゃ、ホントはその人も分かっていないってことで。 さて、オブジェクト指向だが…思想は何となく分かるが、どうプログラムにその思想が実装されるか分からんから
とにかく気持ち悪いってのが俺にはあった気がする。
で、非オブジェクト言語であるC言語で、そのオブジェクト言語の思想がどう実装されるのかを具体的にコードで
確認して俺は初めて腑に落ちたよ。
いずれにせよ、オブジェクト指向は大規模ソフト開発でバグ取りに苦労に苦労を重ねた末に考え出された手段
だから、俺みたいな小規模日曜プログラマーにはその上澄みを使う程度しかないのだろう。 まあコードの意味を分かりやすく簡潔に表現したりスコープを制限する意義なんてのは何回か痛い目見ないと理解出来ないだろうから、
初心者にいきなり説明しても理解するのは難しかろう バグの原因のあるある集みたいなのあればいいのに
ちょっと技術が必要な業界の人って見栄っ張りっていうか足の引っ張り合い好きなのか知らんけど
失敗を隠そうとする人多いよね
入門したてっていうか初心者ってしくじり先生みたいな話好きだけどあれ別にバカにしてて食いついてるわけじゃないのに stdio.hをStandard Input/Outputの略って教えてもらったことがなければ
スタジオHって勝手に解釈しちゃうのもあるあるでしょ
組み込みやればわかるってのも入力や出力する機器が特定されてない環境だからだし ■ このスレッドは過去ログ倉庫に格納されています