 
|
はてなキーワード: コンパイラとは
これは、「（他のライブラリが必要な）特殊なモジュール使ってますか？」「環境依存の設定ありますか？」とかを包括した質問かもしれない。
（コンパイラオプションで関数を使う／使わないって切り替えする奴とかで、おまじないとして大量の定義が必要な仕事場はあった）
使ってる検査ライブラリが、ドライバのライブラリを静的リンクしてた時、「なんか（インストールとか）必要なの？」って聞いたこともあるよ。
「この○○ってライブラリが参照してる××ってなに？」じゃなくてね。
まぁ、言語仕様は知ってるけど、開発環境の仕様は知らないって人、多いよ。
んで、そういう事についての感性が低い人は、確かにいる。
超氷河期だそうです。（これも就活ビジネスの煽り文句な気もしますが）
いや、でもまあ、確かにそうなんでしょう。周りも非正規が多いです。
「何がリーマン崩壊だよ！リーマンになれねーじゃん！」とか笑えないけど笑ってた気がします。
あのタイミングでこれはねーよ、と。
なにせFランクラス（ちょっと言い過ぎ？）の大学（校）だったので。
好きでやってたITだったので資格を取っておいたのだけが救いでした（応用情報技術者試験）
まあ、でも、終わってみればという感じです。
7、8社ほどで内定をいただきました。
ニュースでやってる、100社落ちたとかってのは余程訳があるのかなぁとか、考えたりしたもんです。
就活（笑）解禁だそうなのでメモ程度に経験を残しておこうと思います。ただ、人によっては全く参考にならない気も（笑）
1.中小のみ狙う。
1社だけ入りたかったウェブ関連の会社があったのですが（まぁ、中小ですが）、イミフな試験で落ちました。（愛と恋の違いだの何だのを書けとか書いてありましたね）
地方住まい、通勤圏内を求めていたのですが、県内にいい会社が見当たらなかったので高速で通える県外にしました。
本当は東京にでも出て、やりたい仕事をやっても良かったのですがやめました（理由は後述）
とにかく合同企業説明会（笑）でも人がいないところを狙います。
地方なんかだと地域でやってるUターン誘致の説明会とかジョブカフェのやってる説明会が狙い目です。
むしろリクなんちゃらとか、今話題のマイなんちゃらとかのは行かなくていいです。時間の無駄です。
2.話の合う人事の年齢を見つける
僕は年寄りに話を合わせるのが得意なので、年寄り人事がいる会社をさらに集中して狙いました。
若い人と話すのが得意なら若い人を狙えばいいと思います。
人気の無い企業の人事はとにかく暇なのでガンガンしゃべります。
話を聞いてくれるだけで嬉しいようです。（彼らだって暇なんだから当たり前っちゃ当たり前ですが）
3.乱発しすぎない
僕も焦っていろんな会社を手当たり次第に受けたことがありますが（最初の３社くらい）、あれはやめたほうがいいです。
時間もお金も有限です。企業をリスト化して優先順位（行きたい順だけじゃなくて入れそうなことも加味して）をつけて狙っていったほうが良いです。
4.自分を捨てる
よく言われているように、企業は技術や個性なんて求めちゃいません。
僕はある中堅ITの子会社で「僕はコンピュータが大好きです」といった直後に
「この仕事は、極端に言えばコンピュータがなくてもいい仕事だと思っています」とかなんとか言いました。（あほらしい話です）
SIerは技術者を軽視しているのが隅々まで行き渡っているのでこれであっさり受かります。（当然、蹴りましたが...）
自分の本当の考えなんて大して必要ありません。
5.なんだかんだで資格
学校名で「は？（笑）」みたいな感じでも「応用情報技術者試験受かりました（キリッ）」とかやっとけば覚えてもらえます。
中小企業だと「とりあえず一人はコイツでいいか」的な空気が会場一杯に広がります。
以上５点に気をつけると不本意な気分満点ですが、とりあえず内定しますよ。やってみてくださいね〜。
（以下蛇足）
此処から先は独り言。
僕は情報処理技術が大好きです。高校時代は文系で、心理学に興味があったのに、いつの間にか....。
実は大学（校）に入った理由は学費が安いということが一番で、ついでに興味のあるパソコンを、という気持ちだったのですが...。
大学時代は僕の人生で一番（一番は社会に出てからの今かもしれませんが）勉強した時期です。
あれほど熱中するものがなかった自分がここまでのめり込むとは思いませんでした。
OS、コンパイラ、画像処理、組み込み、データベース、ネットワーク。
何でもやりました。学校もなんだかんだで多くを学べる所でした。
実を言えば東京のベンチャーみたいな会社に憧れたりしたのです。
最先端で戦ってみたいという気持ちが今でもあります。（今はVBでサビ残して詐欺みたいなモノ作ってますからね）
ただ、長年付き合った恋人や、家族なんかのことも考え、今は地方にいます。「今は」
僕は三年は勉強期間だと思っています。社会のルールも知らないのですから。
もし、中小は嫌だとか不安だと思うのなら、こう考えてはいかがでしょうか？（あれ、独り言じゃない）
「三年間の職業訓練」
会社や社会人の方に怒られそうですね。3〜5年でやめられると中小には痛いそうですし。
でもまあ、雇った方も自己責任だし、ね。（こういう内容だと自分のブログに書けないから増田はいいと思う）
３年経てばテレワーク事情ももうちょいマシかも（さすがに無理？）
だめならこのまま人生を切り売りするか、バイト時代好きだった小売にでも転職しようかな、と考えたり。
（正直同じハードさなら小売のほうが楽しい。この業界PGはいてもプログラマいないし。OSS開発もできるからね）
だから、３年間だけ。
とりあえず昨日アマゾンから補充された、机の上に積み上げられた本を読まねば....。とりあえずトランザクション処理からにするか...。鈍器だろこれ
第1章 プログラム変換入門 佐藤泰介 1.1 今なぜプログラム変換か？ 1.2 変換あれこれ 1.3 システム化について 第2章 等式プログラムの等価変換 二木厚吉 2.1 等価変換例 2.2 等価性 2.3 等価変換法 2.4 おわりに 第3章 論理型言語におけるプログラム変換 玉木久夫 3.1 はじめに 3.2 論理プログラムとその意味論 3.3 展開/たたみ込み変換：例題 3.4 展開/たたみ込み変換の正当性 3.5 他の変換との両立性 3.6 おわりに 第4章 部分計算 二村良彦 4.1 はじめに 4.2 部分計算の概要 4.3 部分計算の応用例 4.4 部分計算の理論 4.5 実用化のための課題 第5章 メタ・プログラミングと部分計算 竹内彰一 5.1 はじめに 5.2 Prologプログラムの部分計算 5.3 メタ・プログラミングへの応用 5.4 メタ・インタプリタの段階的特殊化 5.5 おわりに 第6章 合成問題への新しいアプローチ 佐藤泰介 6.1 否定技法 6.2 二重否定技法 6.3 論理プログラムの合成 第7章 ベクトル化とプログラム変換 安村通晃 7.1 はじめに 7.2 プログラム変換 7.3 ベクトル化 7.4 主要変換 7.5 基軸変換 7.6 その他の変換 7.7 ベクトル化におけるプログラム変換の特徴 7.8 おわりに 第8章 GHCでのプログラム変換 吉川康一 8.1 はじめに 8.2 簡単な問題 8.3 フィルタ・プロセスの融合 8.4 プログラム変換の手順 8.5 電子回路シミュレータへの応用 8.6 おわりに 第9章 実用規模プログラムの変換試行事例 吉田紀彦 9.1 はじめに 9.2 コンパイラの変換 9.3 プログラム変換の実用可能性 9.4 おわりに
補足求められたので少しだけ書く。
https://market.android.com/details?id=com.disk.defrag.rubiks&hl=ja
私は起動してません。
あちらこちらで見られるスクリーンショットと、逆コンパイラ結果からの推測です
ちょっと調べればわかりますが、あえて書きません。
個人的に、クラックの入り口になる知識を非アプリ開発者に広める必要性を感じていないので
わかる人に検証してもらってください。
私が検証したのはバージョン1.0です(難読化はされていませんでした)
以下のurlにアクセスしてデフラグしているふりをし、Javascriptを介してアプリ側のダイアログを出す
http://rubiks.adzoone.com/defrag/index.php
魚拓(貼り方あってる？)
http://megalodon.jp/2011-0921-1203-48/rubiks.adzoone.com/defrag/index.php
とあるサイトでちまちまやっていたが今年の4月くらいに無料版が閉鎖
有料版のみになったのを機に何もやらなくなった
もともと経済、社会科学の学部に行きたかったということもあり、簿記２級に挑戦
本を買って半分くらいでやめた（この間に二度もの試験が行われた）
今の俺にとってもっとも身近な職業と言っていいだろうと思い、本を買う
とりあえずでC言語を選んだはいいがコンパイラがうまくダウンロードできずにやめた
うん、なにをやっても駄目だ
世の中で成功している人はみんな自分の力を見せつけて就職などして「働いて」いるというのに
俺のやっていることはまるでどんぐりの背比べであって、
いまさらに「働かせて」もらうための努力をしている
俺はだれにピックアップされたいんだろう
それによって付加価値の上げ方は変わってくるんだろうなと思う
こんなクズだけどそれでもなにかしら成功したいだとか、毎晩のように夢をほざいている
なんにもわからない
まぁ、バグ放置報道は「致命的なバグがあると知って」放置した場合だからな。
ところで、そのプログラムじゃ意味がなくって、引数でデータを渡して、バッファオーバーランが起こるようなプログラムがいいと思うよ。
したくなってきた。なんかこう、例の「バグ放置なだけで犯罪騒動」で。
#include <stdio.h> int main(int *argc[]){ double a=1; double b=0; printf("print %f * %f = %f",a, b, a/b); return 0; }
だが俺には才能がないのでなげやり。なんというヘタレ。というかc言語文法チェックをcodepadでやろうと思ったらサイトにつながんない…。たぶんどっかでヘタこいててコンパイラ通らないと思う。
追記：Floating point exception食らってたので修正。
関係ない。
生産性が高いと言われてる言語で行われた、ゴミみたいなプロジェクトは沢山ある。
生産性の高さが生かせると言うのは、設計からしてきちんと考えられていると言うことで、そういうチームが開発するなら言語は関係ない。
人間は必ずミスをするものだ、という前提を無視した開発手法は信用するに値しない。完全な設計は、存在しない。規模が大きくなればなるほど、そうしたナイーブな前提は容易に崩壊する。
まさかだけど、「Cで１からすべて書く」ことと「Javaの開発済みコード群を使う」ことを比較してたりとか、
「Cで行うテキストエディタとコマンドラインコンパイラのみの開発」と「Javaで行う高機能開発環境での開発」を比較してたりとか
本題とはあまり関係がないけど、そういうことも開発生産性の高さに貢献しているのも事実。
「○○はC言語でもできる」ではなくて、ライブラリやツールがどれだけ整備されているか、それらがどれだけ容易に導入できるか、という点に注目してみるといい。
SIerと言われるような会社に入った。地方の独立系のよくある中小企業だ。
会社の経営が特別酷いわけでもないし、研修もしっかりしている。同期もみんな満足しているように見える。
僕もそのつもりで入社した。別にすごいエンジニアと仕事が出来ると思って入った訳ではない。
でもいざ入ると寂しくなった。
言語はほとんどVBだけ、客先に行ってひたすら話しあって、仕様書を１プロジェクトに山ほど書く。ずっとプログラミングする立場でいるというのは困ると言われた。
別にこれが悪いと言ってるわけでもない。これは需要がある仕事だし、必要な仕事だと思う。それもわかって入社したつもりだった。
働いている上司や先輩も立派だ。見習うべき部分は山ほどあり、尊敬している。
ただ自宅でコンパイラ実装の解説書を読んだり、最新のウェブ技術の話をウェブで見た後、
同期と上司の会話で「オートマトン」という言葉が出ただけで上司が「難しい、最近のはわからん」などとあっさり話を切っているのを目にするとやっぱり寂しくなった。
これから先社内で同期や先輩と話す内容はゲームや車などの話ばかりなのだろうか。
部屋にある技術書を捨て去って簿記の資格でも取るべきなのだろうと思う。
オープンソースプロジェクトにでも参加してみればいいのだろうか。
家族の反対を跳ね除けても都会に出て他の会社を受けてみたほうが良かっただろうか。いや、実力不足で落ちたか。
入社したばかりでこんなことを考えるのは甘っちょろいと自分で思う。
こんなことを考えている間にコードを書いたり本を読んだりできたのだ。
ただ今回は本当に寂しい気持ちになった。ここに文章を書いたところで状況が変わるわけでもないだろうけど、気持ちが切り替わればいいと思う。
考えてみるとそもそも増田を書くなんて初めてなのだ。
明日にはこの記事を書いたことが僕にとっての黒歴史になってるかもしれないな（苦笑）
そういえばシューカツのために取った応用情報技術者の資格も、なんだか虚しいものに思える。手当てでもつけばいいんだけどな、どうだろ
http://1-byte.jp/2011/03/20/20_tips_you_need_to_learn_to_become_a_better_php_programmer/
良いPHPerだって？そんなものは丸めてゴミ箱にでも捨ててしまった方が資源の再利用になる分いくらかマシだ。
つまり俺たちがしなくちゃならないことは「より良いPHPerにならないため」に何ができるかってことなのさ。
それじゃ、始めよう。
?>なんて使っちゃいけない。そう俺たちはBAD PHPer。
無駄なホワイトスペースの出力に悩まされるくらいなら対称性なんて丸めてゴミ箱にでも捨てた方がまだマシだ。非対称性こそが賛美。
require_once("config.php");
未だにこんなことやってるやつがいるのかいベイベー。絶対にダメだ。この一行を見たら俺は悶絶する。
ダメだ、早く何とかしないと。
大抵このconfig.phpの中身はこうなっている。見て絶望だ。
$hoge_path = ''; if (!LOCAL) { define('FOO_FLAG', 1); if (HONBAN) { define('HOGE_FLAG', 1); } else if (TEST) { define('HOGE_FLAG', 2); } } else { $hoge_path = '/local'; define('FOO_FLAG', 2); define('HOGE_FLAG', 3); } define('HOGE_URL', $hoge_path.'/hoge/');
こういうのが延々と続くわけだ。もういやだ。もう見たくない。
本番環境とテスト環境でどういう値の違いがあるのか、ローカル環境だとどうなるのか、まったく把握できる気がしない。
なまじPHPな設定ファイルのせいで、処理をついつい書いてしまう。そしてどんどん複雑になってしまう。
やはり設定データは基本的にYAML等のデータしか定義できない形式のもので用意すべきだ。そして環境ごとに設定ファイルを分けるべきである。
そうすることで何にどういう違いがあるのかすぐにわかるし、diffすれば一度にすべて把握することができる。
# 本番環境設定ファイル foo_flag: 1 hoge_flag: 1 hoge_url: '/hoge/'
# テスト環境設定ファイル foo_flag: 1 hoge_flag: 2 hoge_url: '/hoge/'
# ローカル環境設定ファイル foo_flag: 2 hoge_flag: 3 hoge_url: '/local/hoge/'
// ここで後の処理のためにhogeメソッドを呼び出しておく $q->foo(); // $a['foo']はここに来る時点で真のはず // 2010-03-10 判定がおかしいので修正 // 2010-06-21 やっぱり値が入ってる方が正しい if ( !isset($hoge[0]) ) { }
コメントは保守されない。そう、それは真実。こんなコメントを発見したら即効削除しよう。コメントは基本信じるな。
俺たちにちょっとしたヒントと大きな損害を与えてくれる、それがコメントの役割なのだ。
わかる。いいたい事はとてもわかる。俺たちはしばしばインデントにスペースを使うはずだ。一方でIDEのしっかりした言語ではタブも使うことがある。しかし悪いことに、両者を混同しているプログラマも一定数いるのだ。
タブを画面上で認識しにくいエディタが世の中には存在する（何とは言わないが）
そして画面上で認識しにくいことを理由にタブを気にしないプログラマがいる。
この二つの条件が重なると、タブとスペースの交じり合ったインデントが完成する。もうぐちゃぐちゃだ。これは永遠に続く戦いだ。
私たちが勝利を掴むためにできることなどせいぜい、常にスペースしか使わない。タブを見つけたらその都度スペースに変換する。そういった地道な活動が明日へとつながるのだ。
われわれがプログラムをするとき、何に一番時間がかかってるか。実は変数の命名なのである。ここで拘り過ぎて時間をかけ過ぎては何も進まない。
御託はイイからさっさと書け、だ。しかしとはいっても変数名は重要。日頃からどういうときにどんな名前を使うかを決めておくといい。
そして変数名に型はまったく必要ない。型宣言のないPHPにおいて、型の変数名をつけること自体ナンセンスだ。
$iNumber = 'aaa';
になんの意味もない。コメントを信じるなでも言ったが、これはプログラマを混乱させるだけの害悪なものだ。
変数を使う前に初期化するのは、警告を出さないという意味でも良い癖だ。しかし具体的にどこでやるかが問題だ。
$foo = null; $foo = $q->foo();
こんな初期化に意味はない。よくあるのはやはり、if文で値を振り分けるケースだろう
$foo = null; if ( $hoge ) { $foo = 1; } else if ( $bar ) { $foo = 2; }
このときの初期化はとても有効だ。もしnullの初期化を忘れたまま$fooを使うと警告が出るが、ちゃんと初期化してるので出ない。基本中の基本だ。
function getStatus() { $bReturn = false; if ($i == 2) $bReturn = true; return $bReturn; }(中略)
もし、何かしらの理由で、あなたの書いたif文が間違っていたら？
この書き方をしていれば、間違った値に対して、常にfalseが返る。
私たちが、PHPでsensitiveなデータを取り扱うなら、正しいデータが入力されるまでは、動かないコードを書くべきだ。
trueとfalseの条件がいまいち明確ではないが、本当に動かないコードを書けというのであれば以下のようにすべきだ
function getStatus() { $bReturn = false; if ($i == 2) $bReturn = true; else if ($i == 1) $bReturn = false; else throw new Exception("bad status! $i"); return $bReturn; }
中途半端にfalseを返して生存させる必要性はまったくない。今すぐ死ね！
連想配列のキーを指定する場合だけ定数と間違わないようにクオートで囲まなければならない。そして逆に定数を使いたい場合はクオートで囲ってはいけない。
更に後世のプログラマが処理を見たときに、定数が使いたかったのか、文字列が使いたかったのかを明確にしたい場合はconstantを使うと良い。
// 定数のFOOを使うよということが明確になる print $a[constant('FOO')];
もし、文字列を変数の値と一緒に出力するとき、PHPではコンマの代わりにprintfを使うことが使える。
printf( “Hello, my name is %s“, $sName);
以下の代わりに上記のコードを使う。
echo “Hello, my name is “, $sName;
出力すべき変数が増えれば増えるほど、有効になっていく。とにかく迷ったならば、printfを使え、だ。
三項演算子はとても有効だ。しかし優先順位に難があるせいで、三項演算子をネストしようとすると以下のようなコードになってしまう
$n = (($i == 1) ? 2 : (($i == 2) ? 3 :$i));
括弧だらけで読みにくいったらありゃしない。三項演算子を使うなら一回まで。約束守れないやつは丸めてゴミ箱にでも捨てちまえ。
if ( $flag ) { }
仕様をちゃんと把握しているなら真偽値のチェックなどこれで十分。
もし事前にbool型だというのが確定してるのなら「$flag === true」を使えばいい。
インクリメント、デクリメント演算子は前に付くか後ろに付くかで意味が変わるので慣れるまでは非常にややこしい。
わけがわからなくなるくらいなら初めから使わないほうが良い。見極められないなら使うな。それがPHPerなのだ。
文句なしだ。これは文句がない。
他にも色々あるので覚えておこう
$a %= 1; $a &= 1; $a |= 1; $a ^= 1; $a <<= 1; $a >>= 1;
てっとり早く画面に表示する際にpreはよく使うが、デザインの関係上画面の文字が見えないときがある。
なのでdivを使って以下のようにしとくと便利だろう。
function p($var) {
echo "<div align='left' style='background-color:white;color:black;'><pre>";
print_r($var);
echo "</pre></div>";
}
君らが通常作るアプリケーションなんぞに、定数なんぞ必要ない。いいか、もう一度言う、お前ら程度のもんが、定数使おう何ぞ、おこがましいわ！
大丈夫。なんでもかんでも定数にする必要はない。結局設定ファイルに定数をずらずら作りまくってわけがわからなくなってるパターンが多い。
貴様みたいなもんに、定数は制御できん。いいか設定ファイルはYAML等のデータで持つようにし、その連想配列のデータ構造を一つ持ってるだけで定数の変わりになる。
このメリットに比べれば、定数だと書き換えられなくて良いという利点などこの歯のカスほどのものだ。そんなものは丸めてゴミ箱へ捨ててしまうといい。
認識を改めろ。俺たちはより良いPHPerにならないために努力している。
class Request { private $parameters; private $method; function __construct () { $this->method = $_SERVER['REQUEST_METHOD']; if ( strtoupper($this->method) === 'POST' ) { $this->parameters = $_POST; } else { $this->parameters = $_GET; } } function param ($key) { return isset($this->parameters[$key]) ? $this->parameters[$key] : null; } }
これだけでもいい。たったこれだけでもとても便利だ。ここから拡張してGETやPOSTを明示的に取るメソッドとかも作ってみるといい。自分の手を動かすのだ！
例が良くない。こんなのは引数が20個ある関数から、setを20回呼ぶオブジェクトに変わっただけではないか。
そもそもこの20個の引数とはなんなのか。何かのデータ構造なんであれば連想配列にして引数一つとして渡すべきだし、それぞれまったく異なる用途の変数なのであればWindowsプログラミングじゃあるまいし、20個も引数取る時点で設計が間違えている。
何がいいたいか。別に関数でもオブジェクトでもどっちでもいいということだ。
そんなことで悩んでる暇があったら設計を見直せ。
スキあらば自分自身を返せ。スキあらばオブジェクトを返せ。配列はArrayObjectのARRAY_AS_PROPSで返せ。
ひたすらメソッドチェイン。来る日も来る日もメソッドチェイン。とにかくメソッドチェインを使い続けろ。そこに未来はある。
どんなコードも繰り返すな。もし、少しでも同じコードを書いていたなら、それは関数に置き換えてしまえ。
・・・と、いうのはやめなさい。
一見同じように見えた処理でも前後の流れでまったく違うものということが往々にしてある。
まとめ方にも問題があるケースもある。何でもかんでも関数化すると、関数が膨大に増えていく。君は見たことがあるだろうか。common.phpやfunction.phpの恐ろしさを。
確かに細かく関数化はされているが、適切に関数化していないのである。結合度が非常に高い。なんでもかんでも盲目的にまとめれば良いという話ではないのだ！
あまりに極度に意識しすぎると、プログラムそのものができなくなる。そういう状態に陥る。
気を抜いて。そう気を抜いて。所詮あなたのコードなんてすぐに消えてなくなるよ。きっともっと偉い人が作り直すよ。だからまずは思うが侭にやるといい。
結合度を減らすというのは非常に難しい。何度も何度も失敗し続けて、ようやくここは分けた方が良かったんだなと気付く。次に活かそうと心に決める。そしてまた同じ過ちを繰り返していくわけだ。
まずは実装することだ。これが一番の早道だ。まずはがっつり結合した関数をあえて作るといい。何も考えずに作ろう。
そしてその後に、一部分使いまわしたいとおもうことがあるはずだ。その時に関数に切り出そう。それを繰り返すといい。そのうち初めから分けた方が良いと気付く。
何事も経験が必要である！経験を積まないプログラマは丸めてゴミ箱に捨ててしまえ。
さて、先の例で言うならば、私ならadd_result_outputという関数を作ってしまうだろう。だって、addとresultを連続して呼ぶのはめんどくさいんだもん。一連の流れをいつも使うのなら、その流れをやってくれる関数を作ればいいじゃないか。
function add_result_output ($iVar, $iVar2) { $r = add($iVar, $iVar2); echo result($r); }
もっと言えばクラス化してしまってもいいかもしれない。どんな感じになるかは君の手を動かして確認しよう！
このTipsはとてもわかりにくく、ニッチ過ぎる部分も多いかもしれない。
あくまでも「より良いPHPerにならないための20Tips」なのだ。
君はこの記事を鵜呑みにしてはならない。PHPをPHPと見抜けないPHPerはPHPを使うのは難しい。
もし、あなたがPHPプログラマなら、公式のPHPドキュメントはあなたのケツの穴を拭くための紙になるだろう。
私は、それぞれのセクションを眺めて、各関数でどんなことが出来るかなんぞ、歯クソのゴミ程に役に立たないとおもっている。動けばいい。はは。
あなたは、PHPで用意された既製関数で多くのことが実現できることに、（俺の仕事を減らすなと）驚くはずだ。
この記事があなたの役に立たない事を。
ふざけんな！
この記事に書かれている内容は、丸めてゴミ箱に捨てた方が良いレベルです。
3%タイプしたらあとはIDEが補完してくれるなら、その3%を記述しておけば後はコンパイラがよしなにやってくれる言語をつくればいいんじゃないかな。
(ここでいう「コンパイラ」は広い意味の処理系。インタラクティブにミスを指摘したりインクリメンタルにリンクしてくれたり、といった機能も込みで。)
期待しているものと少し違うかもしれないが、既にJava向けのウェブフレームワークでは、必要最低限のコードだけ書くと他の部分を自動生成してくれるようなプロダクトが出てきている。"Spring Roo"とか"Play framework"とかが代表的かな。バックグラウンドでツールを走らせておくと、ファイル変更のタイミングで、自動的にビルドとコード生成をやってくれる。
これらは、RoRと同様の生産性を実現しつつ、既存のJava資産を活用し、静的型言語の恩恵をも受けられるようにすることを目指している。
3%タイプしたらあとはIDEが補完してくれるなら、その3%を記述しておけば後はコンパイラがよしなにやってくれる言語をつくればいいんじゃないかな。
(ここでいう「コンパイラ」は広い意味の処理系。インタラクティブにミスを指摘したりインクリメンタルにリンクしてくれたり、といった機能も込みで。)
みたいな感じで、関数コールを嫌う文化だからなぁ突き詰めると。
そういう事をしようと思わない。別な書き方をするとかじゃなかろうか？
いちおう、C++ならクラス内にクラスは書けるから似たような事はできる。
C/C++は文化的に速度とメモリを重要視する言語だから、あんまりね、そう言うのは主流じゃないと思う。
class A{
private:
int A:
public:
A=a;
}
}
みたいなことも・・・あまり、おすすめできないし・・・。論理的には美しいんだけど・・・いろいろ弊害もあると考えるのがC/C++
ましていわんや、関数内。
※一番痛いのは、設定関数が1箇所なので、動作変更がすぐできる＞＞大規模システムではコードカバレッジがあるので、
根元の関数の挙動を大きく変えられたら、上位のクラスの莫大なテストやり直しだから、1箇所変更で全箇所変わるのはデメリットｗ。上位で修正が基本。
というか、やっちゃだめｗｗｗ。
たとえば、intをdoubleにとかなら、それもう別物だから、上位も変更でしょ。普通・・・。とか。
あと#define関数はデバッガーでおえないので、なるべくC++のコンパイラ通してinlineで書いてぇぇぇぇとか。色々。むしろ#defineで複雑なことしないでー
なんか知らないけど、外注の不具合を直せとか、他人の尻ぬぐいとか、破綻したプロジェクトの火消しとか、ばかりで、0からの開発なんてほとんどやらせてもらえないんだが。
第7位 main関数だけで2000行overだったプログラム(C言語)
第6位 switch文の1つのcaseブロックが1000行overだったプログラム(C言語)
第5位 コメント文ばっかりと思ったプログラムが、実は日本語関数名だったプログラム(VB)
第4位 どんなに読んで修正して実行しても、いっこうに直らないと思ったら、関数突入直後にreturnしていたプログラム(C言語)
第3位 どんなに読んで修正して実行しても、いっこうに直らないと思ったら、#if 0 ～ #endifでコメントアウトしていたプログラム(C言語)
残念ながら、その読書履歴だと、ここで言う「原理」には辿り着いてないと思います。挙げられた本はどれも計算に関する抽象概念からさらに上の、アーキテクチャを言語化する部分に関してです。それらも原理と言えば原理なのですが、そこからスタートしてもC言語でのプログラムは書けるようになりません (Rとかなら書けるかもですが)。
ここで言う『原理』すなわち、なぜ char x[sizeof(int)]; がダメなのか、という理解につながる原理は、「レジスタ」「ALU(CPUの中の計算ユニット)」「バス」「メモリ」といった原理です。メモリアクセスやヒープ・スタックの使い方、アセンブラといったような話です。
なんで言語の約束事の上っ面を覚えるのが難しいか、というと、「原理」を理解していないからなんです。原理を理解せずに約束事だけ覚えたって使えません。曖昧で良いので、プログラムを動かしているときにどのようにメモリが構成されどのようにアクセスされるのかを知る努力をして下さい。その上でC言語をよく見ると、いかにCPUアーキテクチャに近い所で記述されているのかがわかるようになると思います(*)。
それだけで、目の前の箱がどう動いているかの理解度が劇的に上がる筈です。
*: 理解したつもりになるだけですが、現実のコンパイラもCPUも、そのさらに7歩ぐらい先に行っています。ですが、この領域は進めば進むほど泥沼なので、「あ、Cって高級アセンブラなんだな」という所で実用上は十分だと思います。てか、偉そうなこと言っている私(某大学博士課程在籍、要は増田で現実逃避中のダメ学生)も、そこから先はちゃんと理解していません…。
#define false 0
としないで
#ifdef XXX
#define false 0
#endif
とするか？
なんで、ifdefで定義そのものをOFFれるかっていうと、まれにfalseを理解できるCコンパイラがいるからでしょ？（つまりC++コンパイラを使ってCをコンパイル通すケース）
だから、C++がなかった時代はそれでいいけど、C++ができた時代には、コーディング規約を見なおさないといけないという話でしょ？
ちなみに#define FALSEを残すのは MS系コンパイラへのコンパチビリティ。MS系の旧ライブラリを通すときは一応FALSEで渡したほうが良い。
作り直したタイミングで、新しい企画に対応していかないと、いつかどこかで、対応できなくなるし、そもそも、falseは有名すぎる。
そんな、改変すればいい特殊ルールをいつまでも残しておいて、組み込みは特殊だからとか言うなって話はあるよね。
普通の一般プログラマでも、改変できる範囲は最近は多くなってきているのに、わざと、さわれれない旧ルールを残し続ける。
コードが同一なら、そらしょうがないけど、バージョンアップで、新規作り直しのタイミングで変えないとしたら、それはおかしい。
新しい人入れなきゃいけけないし、短期的に人を増やすタイミングなんていくらでもある。
そういう時に、ダイナミックに人を追加できないようなコーディングルールにする意味が分からない。
コーディングルールを決めるのは、設計担当で、人のアサインの事まで考えて、ルールを決めなきゃいけないんだから、一般のC++プログラマを短期的に追加できるルールに変更すべき
それが、大きな問題になるならわかるけど、falseをやめて、ON/OFFにする もできない理由は思いつかない。（作り直しだから）
それはON/OFFじゃなくて？
true/false は真偽値なので
if(false){
}else{
}
がelse節になる必要がある。
if(local_false){
}else{
}
にthen節なるようなfalseを定義するべきじゃない。
回路の1/0判定については ON/OFFを割り当てるべきでtrue/falseを割り当てるのはそれこそ、プログラムの概念設計ミスだとおもわれる。
そのために
if(value==local_false)
なんて毎回やるのは、さらに 混乱のもと
if(value==local_on)
ならば、誰でも混乱はしない。
falseは真偽値というコンパイラが使う値であって ハードの固有値を割り当てて良いものではないと思われる。
大げさに表現すれば、
typedef long local_short
typedef short local_long
sizeof(local_long) ＜ sizeof(local_short)
ローカルFalseはこれに近い。既存のコンパイラが定めている概念を ひっくり返すようなローカル定義は この時代ではするべきではない。
#define HARD1_ON 0
#define HARD2_ON 1
これは必要。
#define HARD1_FALSE 1
これは害悪
#ifdef XXX
#define false 0
#endif
ならわかる
#ifdef XXX
#define my_false 0
#endif
後発企画への互換性とか考えないんだろうか・・・
大きなシステムで、独自定義が増えれば増えるほどメンテナンスコストがまして行くのに
my1_false my2_false my3_false なんて・・・増やしても仕方が無いだろ 可読性の上でゴミじゃねこれ・・・
え？falseが０じゃない場合・・・
それこそ コンパイラを治せ級の問題だろ いくらなんでも
古いコーディング規約を守り続けるのはいいんだが、世界的な仕様が変わっているんだから、追従はしないと駄目だろ。
バージョンアップされないコーディング規約は 害悪 という意味で。
あとは、#define False 0
#define FALSE 0
は先企画への互換性のために仕方がない
単純な例だと
微分積分を習うまで 算数から初めて 633で約10年ぐらい勉強して、その微分積分があって、フーリエ級数展開なんかがあって、そっから、初めて信号解析が始まって、MPEGのCODECの研究なんてのにたどり着き
ようするに、そういう例では 20年近くキャリアを積み重ねてるわけだよね？小学生から。
大規模設計で
ハードウエア使って基礎から設計 サーバーもクライアントも、一体で
ともなってくると、必要な知識だけでも、山ほどあるわけだが？終わるわけないだろ10年ぽっちで。
そういう基礎知識があって、それこそ８０８６のころからアセンブラやってる経験も含めて、ようやく できるようになってきた。まだまだ先は長いって間隔なのに
10年程度でできるようになるって、どんだけプログラムを浅く見てるんだ？
たぶん、一通りできるようになって、一人前ってので30年。 親方クラスで５０－６０年ぐらいだろ。修行は一生。
変な話だが、プログラム的にこう書いて、こう使うのが効率的だから、ハードはこういう風になって、ここにこういう部品を作って基盤作ってくれとか
ハードの知識までないといえないぞ？
逆にハードがこうなってるから、アルゴリズムはコッチ とか ハードの設計見て プログラム組み替えるとか、けっこうな経験がないと無理。
で、さらに、それを指示だしして、経験ないプログラマにある程度やらせて、レビューして・・・
そんな経験積んでいって、10年でできるようなもんじゃないとおもうが・・・
結局 文型10年プログラマーって 数学的知識だったり、たとえば、コンパイラの左結合とかそういう話だったり ついてこれないことがあって、学問的に無理。
まず、総論。「現場レベルのCプログラミングに通暁するとはどういうことか？」という問いに応えましょう。教材研究した結果から言えば、これは三段階の学習を行ったかどうか、になります。レベル１：〈リファレンス通読〉。レベル２：〈チュートリアルで実践〉。レベル３：〈実装〉。この段階で技術知識を頭にインストールすればよい。
レベル1のリファレンスについてはman pageに限ります。「誰でもわかるC」みたいなのは絶対に買わないでください。手元のマシンにプロも見るman pageがあります。man2とman3の下を通読する。回数は最低二周。
レベル2のチュートリアルはなんでもいいです。たとえば定番の「プログラミング言語C」とかは古典ですが、持ってるとハクがつくのでお勧めです。第一版を買うとK＆Rスタイルで書いてあって読みにくいので、ちゃんと第二版を買うこと。
レベル3の実装は自分のテーマに沿ってソフトウェアを作るということです。自分のレベルに合ったテーマを選びましょう。OSやコンパイラみたいな大物を実装するのは難しいですが、簡単すぎても無意味です。ちょっと背伸びしたテーマを選ぶのがお勧めです。また、一定の規模のソフトウェアをゼロから作る経験も大切ですが、完成度を95%から100%に上げる経験も同じくらい大切なので、技量としても熱意としてもやりきれるテーマを選ぶのがよい。
間違いもあるかもしれないし、詳細はググっていただくとして。
まずはFXの作りの話になるんだけど、あれのUIとかはXULって言う、javascriptやCSS, XMLなんかをベースにした言語で書かれている。
で、拡張機能はこのXULで作る。つまり、元々のUIとかを形作っているXUL群に追加でインストールするXULが拡張機能。
対してプラグインはnetscapeの時代から続く、DLLを使う方式。
拡張機能はスクリプト言語ベースで、しかもwebで使ってるものの流用だから、入りやすく作りやすい。メモ帳あれば作れる的。