 
|
はてなキーワード: C++とは
基金訓練、今は求職者支援制度に名前が変わったみたいですけど、そこの講師をやめたというか、会社ごとやめて転職しました。
何の講師をやっていたかというと、今をときめく(?)Androidの講師です。
転職先にも少しなれてきて、今までのことを振り返って書き留めてみたのですが、せっかくなので発表することにしました。もともと僕だけが読むメモのつもりで書いたので、読みやすい文書ではないですがご容赦のほど。
Androidの講師になるまでは、Javaのサーバーサイドのエンジニアをやっていました。
お客様のところに常駐し、システムの一部ではあるけど、自社メンバーだけで上流行程から担当し、僕はそのチームリーダーでした。
プロパーの方でも仕事がないような状況で、それでも僕らのチームは半年ほどは細々とメンテなどの作業をやっていたのですが、最終的には契約終了になってしまいました。
自社に戻って、何をするのだろうと思っていたら、Androidの講師をやれ、といわれました。
Androidは、暇だった時期に少し動かしてみて、簡単なアプリなら組めるようになっていたのですが、人に教えるほどの技術はありません。しかも準備期間は1週間ほどしかありませんでした。
ビデオ教材と教科書が用意されていて、それに従っていれば最低限の講義はできるのと、最初のうちは純粋なJavaの講義だったので、前半をやっている間に講師はAndroidの勉強をしよう、という、何とも乱暴な計画を立てたのでした。
ほぼ定員いっぱい近い受講者の方が集まったのですが、スキルが全くバラバラです。
JavaやC#,C,C++の経験者がいるかと思えば、人差し指だけでキーボードを打っている方もいます。
講義の最初のうちはコマンドプロンプトを使うのですが、教材には説明がなく、最近の人は知らないだろうと思って説明書を作っていたのですが、まさかコピーペーストのやり方から説明することになるとは思っていませんでした。
それでもやる気のある方はまだましで、どうみても給付金目当てとしか思えない、やる気のない方が何人もいます。
こちらも準備不足の中、生まれて初めて「先生」と呼ばれる仕事を始めることになりました。
基金訓練を始める前は「きちんと技術を教えられるかな」ということばかり気にしていたのですが、講義の運営の方が問題続出でした。
いかにもやる気のない方々は講義中もトイレだ電話だといって抜けてしまう、講義中に当てても「わかりません」しかいわない、かといって質問もしない。当然課題も期限までに出さないので0点しか付けようがません。
そういう方でも、こちらから無理にやめさせたりすることはできないので、何とか講義だけはでてもらっていました。
けど、それがよくなかったようです。
まじめに受講されている方々から「金をもらって受講しているのにあの態度は何だ」「入校条件（キーボード入力）すら満たしていないのではないか」「講義のペースが遅すぎて時間が余る」などの苦情があがり、まじめな方から「就職が決まった」などの理由で辞めていってしまいました。
後に残った、やる気のない方々と、講義を続けていくしかありませんでした。
１度目の皆さんが修了し、2回目の講義を行うに当たって、前回の反省点を改善すべく、いろんな手を打ちました。
最後の手は、会社に怒られるのではないかと正直不安でした。実際辞めていく方が増えたのですが、こういう方は「家業が忙しくなったので手伝う」「体調が悪くなったので療養する」といったもっともらしい（？）理由で辞めていったので会社から怒られるようなことはありませんでした。
むしろ受講生の方の中から、積極的に他の方にアドバイスする方が増えたため、スキルの低い方からも「質問をしにいける人が(講師以外にも)大勢いたのでよかった」といってもらえるようになりました。
今回は、終了後の受講生の方どおしの打ち上げ会に呼んでいただきました。おおむね好評だったのだろうと思います。
未経験だけど、求職者支援制度を利用してプログラマになりたい方向けに、こういう人がプログラマに向いている、こうした方がいい、という条件を挙げてみます。
プログラムの勉強ははっきり言って辛いです。やりたいことが明確になっていないと、なかなか続かないです。
僕は「写経」と呼んでいるのですが、サンプルプログラムを実際に打ち込んでみて、エラーがあれば自分で修正する
という「訓練」をやらないと基礎が身に付かないです。そもそもキーを打つのが苦手、という人はきっぱりあきらめましょう。エラーの原因を自分でぐぐって調べられないような人も、この業界には向いていないです。
いき当たりばったりではなく、最初に手順・段取りを考えてから作業を始める方が向いています。
講義でも、課題作成に何日もかかる課題があるので、何も考えずに適当にやっていると期限までに終わりません。
「きりん、うさぎ、あひる、かば、4つの動物で仲間外れは？」みたいな問題が苦手な人は、向いていないと思います。
単に「読める」ではなく、課題を理解し、既知の技術で解けるものと未知のものに分けたり、繰り返し処理や、複数の似たような処理を一つにまとめるといった作業ができるかどうかです。
さっきの抽象的な考えもそうですが、今までそういうことを意識してやっていない、という方が多いと思います。そういう人は、しんどい思いをすると思います。
「ＡとＢという方法がありますが、ここではＡについて説明します」と講師がいったら、Ｂは自分で調べましょう。習ったプログラムを少し変えてみてどうなるか試してみましょう。それがうまくいかなかったとしても、経験というプラスが残ります。
講師の言うことが理解できたと思ったら、自分で応用問題を考えて、プログラムを書いてみましょう。もしそれが期待した結果にならなければ、どこかで理解が間違っている可能性が高いです。
先ほどの「試してみる」もそうですが、BLOGで実施すると、それをみた方からコメントやアドバイスをもらえることもあります。
いきなり何十行もプログラムを書いて動かなかったとしても初心者はまず動かせるようになりません。少し書いて、動かして動作を確認し、また動かして、を繰り返す方が結局早く完成します。
ちゃんと動く「プログラムの断片」を増やすことは、後で同じようなプログラムを書くときに、「断片」をそのままコピーして使えるようになると言うことです。
一度プログラムを書き始めたら、まずやることはプログラムを完成させて動かしてみることです。プログラムを書いている途中で、同じような処理があるからforで書きたいとか、メソッド化したいとか、思うかもしれませんが、プログラムの初心者はまず動くプログラムを書いて、それができてからきれいに書き直しをした方がいいです。
すぐに解けない課題は、書いて残しておきましょう。書いて整理することで、解けることがあります。今は解けなくても、後で見返して解けることがあります。
特に図に書く、という作業は意識的にやった方がいいです。講師に質問するときも、口で説明するより、図に書いた方がずっと通じやすいことがあります。
自分ができたことで他の人が詰まっていれば、アドバイスしてあげましょう。助けてあげると言うだけでなく、他人に説明すると言う作業は、自分自身の理解をより深める作業でもあります。
もちろん自力で最後まで解くことが重要な課題もありますが、そういうときは講師がそれとなく言ってくれるはずです。
とりあえずアプリを書いたら、同じ講義を受けている人や講師に見せて感想をもらいましょう。
アイコンを書くのが苦手なら、イラストが上手そうな人を見つけて、書いてもらったり、書き方を教わったりしましょう。
訓練を受けているのは同じような環境の方ばかりなので、相手だって同じことを考えているはずです。
紙のノートに講義内容を書いたり、テキストの余白にメモしている人がいますが、それは講義の内容を聞いて即理解できる人が、聞いたことを忘れないためのやり方です。
わからない人は、わかるようになるまで、何回でもノートを書き直した方がいいです。わかったことを継ぎ足して、表現を見直して、時には冗長な表現を削って、自分だけのオリジナルのテキストを作るつもりで書きましょう。当然書くのは紙のノートではなくパソコンをつかいます。
プログラミング以外の世界でもプロや、プロ顔負けの技術を持つセミプロ、ハイアマチュアといった方は自分の作品を世に出すときに恥ずかしがったりしません。不安はあっても、それを上回る意欲を持って、どんどんアプリを書いて、マーケットに載せましょう。
ひょっとすると業界の習慣よりあなたの意見の方が正しいこともあるかもしれませんが、未経験の人が言っても周囲はたぶん聞いてくれません。「私はずっとこのやり方でやってきたしこれからもやる」という意見はひとまずおいておいて、まずは周囲に認めてもらうようにしましょう。
余りに差がありすぎて自信をなくすと逆効果ですが、技術を身につけたければ自分より優れた人から学ぶのが一番です。コミュニティーや勉強会にも積極的に参加しましょう。
2010/05/16 23:40
こんにちは。昨日会った者です（これで特定するには情報不足だけど、まあわかるよね）。
で「幅優先探索でやる」という方針自体はいいと思うし、データ構造の作り方も基本は押さえていると思います（斜め読みしかしてませんが）。
ただ、コーディングの発想が「C で作る」という大方針から見て、少しちぐはぐな印象も受けます。データ構造の設計や操作の部分、汎用のライブラリを作ろうというのならあれでもいいと思うのですが、わざわざ汎用のライブラリを使わずに自分で専用の道具を一から作ろうというのなら、問題の性質を考慮して能率良くやることが大事です。
ところが、ここに載っているコードを見ると、見かけが C らしくなく、C++ や Java の劣化版のような印象を受けます。記法（マクロを大文字化しない、ルーチン名を大文字で始めるなど）だけの問題ではなく、データ構造の設計思想が「C で書く」という方針と矛盾しているように見えます。
もう少し具体的に言うと、そもそも C というのは現在 Web 系の世界などで流行のスクリプト言語類とは逆で、汎用言語でありながら低レベル（ハードウェアに近い）処理が簡単にできることに特色があります。つまり、組み込みを想定してプラットフォーム非依存のコードを書いたり、ハードウェアの特性を考慮して低レベルな最適化をやりたいというときに適しています。
そこでこの問題ですが、これを C でやるということは、処理速度や使用メモリ量の最適化が要求される状況、つまり迷路の大きさが途方もなく大きいような状況を想定すべきです。もっと言ってしまえばこの問題、たとえば画像処理などで似たような発想が要求されることがあります。このため、どうすれば時間のかかる処理を切りつめることができるかを考えてやらねばなりません。
このプログラムの場合、時間のかかる処理の代表格である malloc() が大量に使われています。これはいかにもまずいです。このような大量データを処理する場合の定石は、あらかじめ必要なだけメモリを確保しておいて、自分で割り当てることです。具体的には、必要と想定される量だけメモリを配列の形でどかっと確保しておいて、配列のインデックスをポインタ代わりに使います。そして、足りなくなったら倍々のような感じでメモリを realloc() してやればよいのです。
なお、そのような観点で言って、木の各節点の子の数は高々 4 （スタート地点が内点でないとすれば 3）であることを使っていることはよいと思います。ここで「子のリスト」とかを作ってしまっていたらこれはもうアホもいいところですから（容量の節約にすらなりません）。
そんな感じでしょうか。
とにかく、この手の問題は、アルゴリズムさえわかっていれば可読性もヘッタクレもないので、「短く書く」というような表層的なことよりも、何が求められているのかをよく考えて、柔軟に設計思想を考えることが大事だと思います。
2010/05/17 13:54
Oさんですね。専門的なコメントありがとうございます！cで書くと言いつつObjective-Cっぽい発想で書いていました。マクロの命名もその影響で、関数はImage Magickなどに似た命名規則になっている気がします。mallocを使いすぎると時間がかかるということは全然意識していませんでした。今度作るときはメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました！
C
をこの順番で覚えた。
変り種は2006年に勉強を始めたC++で、軽量言語花盛りのその時期に、CGIを書きたいがためにC++を学んだ。
C++は習得が難しい言語と言われているが、必要性を感じなかったので参考書の類は買わなかった。
他の言語もそうだ。
参考書は必要なかった。
これ自体は悪い本ではない。
でも結局、最初のWEBアプリ（サービス）はPHPではなくC++で作った。
この読書は、購入前に漠然と感じていたPHPへの不快感を再認識させただけだった。
そして学んだ。
歴史は繰り返す。
今まさに「明解Java 入門編」を購入しようか思案中なのだ。
今までJavaを避けてきたのは「ジェームズ・ゴスリンが嫌い」あるいは「金の匂いがする」からだ。
PHPの経験から言って、Javaも実用できないかもしれない。
Javaを覚えれば幅が広がるのは分かるんだけど…
なぜだろう、ワクワクしない。
http://www.heroesofnewerth.com/
プログラミング能力もないし、日本人は同人でやってることがレベルが低すぎる
糞ジャップの開発能力は一生、シューティング、テトリス、横スク、ラノベ、ターンＲＰＧ
そんな程度だよ
↑みたいなをC++で書いてデザインもして作れてないのにUnityとかほざいてる
基本を学べとかいってる割に Unityからやっちゃうんですか(笑）
Unity勉強家の連中がやってることも低レベル見ればわかるよ
日本の同人・ＬＬジャップがやってることは２０１１年にもなって
ＲＰＧの基本 Ｒｏｇｕｅ風
作れない
ＰＣ向けのオンラインゲーム作ってるプロジェクトやＬＬ使いがいたらそいつ凄いけどね
せいぜい２０１１年にもなってカスタムロボみたいなのも作れねーだろ同人で
たかがしれてんだよ
なぜ両方使うという選択肢がない。真の技術者はウェブ標準だろうがFlashだろうがネイティブだろうが、その場その場でユーザーの体験を最善にし、クライアントの要求を最高に満たすベストの技術を使う。JavaScriptかFlashかなんて動きさえすればユーザーには関係ないんだから。実際、HTML5スゲＥＥＥＥＥ！！！ってページにFlashタグのブクマが間違ってつけられたりしてるよ？（笑） ウェブ標準の崇高さなんてパンピーにはわからんのです。
そもそも分からないんだけど、HTML5が「投資」するほどたいしたもの？ 誰もが基礎教養として身につけているはずの、これまでのHTML＋CSS＋JavaScriptの延長線上の技術でしょ。今まで普通にやってきたウェブ開発者ならすぐにキャッチアップできるはずだよ。
どうせHTML5の実装の普及には当分かかるし、その時点のブラウザ環境で使用可能なものをゆっくりまったりと導入していけばいいだけ。その意味ではいわゆる遅延評価学習で十分。あわてることはないです。どうせ皆使うことになるんだから。
一応言っておくと、いいものだと思いますよ、HTML5は。現段階で頑張って凝ったものを動かしておられるイノベーターの方々もたいしたものだと思います。敬意を。マリオやらグラディウスやらは著作権的にどーなのかと突っ込みたいが。
それはシナリオのひとつですよね。Googleの甲斐性次第では十分にあり得る。それと、ジョブズが翻意するというシナリオもありますよ。今までに散々あったことですが。どこかでそれをネタにしている記事があったと思いますが。
もしEdgeを見てそう思ったのなら、Flash CSを使って制作したことがありますか？ Edgeを実際に使ってみましたか？ と問いたい。
他にも、最低でも、
これらにきちんと答えられない人間にHTML5 vs Flashなど語る資格はないです。そもそも対立させる時点でわかってないなー ┐(´д｀)┌ って感じなのだけど。
あとFlashへの投資が無駄になると思ってるようですが、俺はFlashは投資判断「Buy」継続だと見てますよ。たとえこのままiOSで動かずともね。AIRもあるし、ブラウザのプラグインとしてのFlashだけ見ていると考えを誤るよ。ブラウザのほうにしても、GPUアクセラレーションつきの3Dが真っ先に使用可能になるのはFlash。プレイヤーの普及が速いから、WebGLと異なり、今後1～2年内に実案件で使用可能になるでしょう。そういった面ではなおカッティングエッジな技術だよ。
まあ、プラットフォームや言語の選択は投機だから、どの銘柄が買いか売りかで紛糾するのはわかる。ただ、それなら分散投資だとか、インデックス投資という考え方もあるのでね。HTML5に惚れ込んで一点買いなんて若いエンジニアがいたら、それはもう相当危なっかしいなと、視野も相当狭くなるだろうなと危惧するよ。
というか、JavaだろうがC++だろうがObjective-CだろうがLLだろうがアセンブリ言語だろうが関数型言語だろうが、一度全部触ってみなよ。いいから。HTML5で手一杯なんてのでは話にならんですよ。
K＆RのCで書かれたプログラムを渡された（もう少し正確に言えば、VisualStudioのWizardで作られたものにK＆RのCでコーディングしてある(C++ですら無い)ので純粋なCでは無いが果てしなくK＆RのCだ）。あと、これを作った人はどうにも「ポインタ」の概念が無いらしく、無駄に多次元配列だったり、配列のアドレス渡しとかが多用されている。
作業指示は、これを流用して、C++/CLIかつ.netFramework3.5使用かつ新規案件に対応せよ、との事。
個人的にはどう見積もっても3人で4ヶ月かかる量なんだが、予算が1人で1ヶ月、と言って来た。理由は「Cからの流用だから」。
参ったな。自分としては、C++/CLIはもはや別言語だと思っているんだが。
どうにも上司と顧客に説明出来ない。説明出来ないのは、自分が理解していないせいだ、と言われればそれまでなのだが、自分の感覚で言うと、高段者がうっている将棋や囲碁の一手を初心者に教える、とでも言うか、小学生に微分積分を教えるというか、そんな感覚がある。
いや、相手が、K＆RやANSI、C++、C++/CLIを分かっている人間になら、説明は出来るのだが、相手のレベルに合わせて、説明が出来ない。
今回のこれに限らず、見積もりとかすると、「なんでこんなに時間かかるの？」とか「高い」とかよく言われるのだが、やっぱり説明が出来ない。デスマってるプロジェクトには、よくさらなる人員投入がされる事が多々あるのだが、デスマってる時点で負け戦だし、「混乱したプロジェクトに人を投入すれば、さらに混乱するだけ」と自分は思っているので、やめてもらいたいと思っている。
「あんたの小学生になる子供が、100人いたら、東大に合格するくらいの学力が発揮されるんですか？」と問いたい。
あれは、VisualBasic4が出た頃か。それまでWindowsプログラムというものをCまたはC++で書いていた自分には、驚異的な言語に思えた。そしてみんな言う。「VBで作れば簡単ですよ」
自分にはVBという言語はとてつもなく難しい言語に思えた(MFCは論外)。なぜなら「かゆいところに手が届かない」言語だったから。だから、皆が言う「VBなら簡単」の理由がさっぱり分からなかった。ちょっとした使い捨てツールや、極々Windows標準的な事しかやらないのであれば、VBは簡単な言語であったのは分かる。実際自分もそういう使い方をしていたから。
そして、うちの職場ではそんな製品を作る所では無く、仕様を満たすためにはサブクラス化とかWin32APIを使うとかしないと実現出来なかった。もちろん「VBで作れば簡単ですよ」と言っていた連中にサブクラス化など理解出来ようも無く、ただただ右往左往してデスマーチに突入していった。
その時も、お偉方や顧客に説明が出来なかった。「VBなら簡単」と言っていただろう、と言われるだけ。
まぁ、VBも.net時代になってから、だいぶマシになってきたと思うけどね。少なくとも、スレッドセーフになってくれただけでもありがたい。
まぁ、その辺はともかく、もしかして、デスマやIT土方とかなるのは「説明が出来ないから」なのではなかろうか？と思えてきた。必要な時間と予算を説明出来ないから、泥沼になるのではなかろうか、と。
説明が出来ない限り、プログラマーは永遠にIT土方であり、地位向上は望めないと思う。人月の神話じゃなく、ファンクションポイント法とか、なにか定量的に説明出来ればいいのだけど。ファンクションポイント法だって、それが分からない人には通じないわけで。「小学校に入学した児童にも分かるような」説明が出来ないとダメなんだろうなぁ。どうすればいいんだろ？
fooのintへのキャストがtrue/falseを返すというように、fooのクラス仕様が決められてるんなら、
そしてboolへのキャストが未定義だったり、また違う意味なのなら
if (foo) {
ではなく
if (foo == true) {
って書かざるをえないだろう。嫌いとか好きとかの問題ではないと思う。
class { public: operator bool() { std::cout << "xxx\n"; return true; } //*1 operator int() { std::cout << "yyy\n"; return true; } //*2 } foo;
があったときに、「if (!foo)」だったら*1が、「if (foo == false)」だったら*2が実行されるような処理系がある。
最新のVC++だと後者は曖昧だってエラー出るね(たぶんC++だと「trueは1でfalseは0」なんかではなくあくまでもtrueとfalseなんだ)。
なんにせよ演算子や条件式などに関連する暗黙のキャストはわかりづらく、そしてそんなのを利用したコードはきっとバグる。
だから
というのが本当なら、==trueがどうこうなんて些細な問題はおいておいて、fooを暗黙のうちにintにキャストしたりboolにキャストしたりして使っているという危険な部分をまずなんとかすべきだろう。
古いC言語風に書けばこんな感じ。
#define FALSE 0 #define TRUE (!FALSE)確かに、実際に値を表示させてみると、昔のVC6だと「1」という結果が出てくるし、VB6だと「-1」という結果が出てくる。これ、当時混乱の元だったんだよね。
VC6とか関係なくてC言語の仕様でそうなんだが、それをわかってないとすればやばい。
個人的には
if( foo != FALSE ){
も十分きもちわるいので
if (foo) { ... }
if (!foo) { ... }
にしてほしい。
まぁ、タイトルの「レガシープログラマ」とは私の事なんですけどね。
if( foo == TRUE ){
という判定文をよく見かける（fooはいろんなオブジェクトだと思ってほしい）。
個人的には、この書き方、嫌いなんだよね。
if( foo ){
か
if( foo != FALSE ){
と書いて欲しいわけよ。とにかく「TRUEか？」という判定にはして欲しくないわけです。
で、なんでこう書くの？と外注や若い連中に聞いたら、「TUREは1ですから」と必ず答える（断言する）。
あ、あれ？？？自分は「TRUEはFALSEでは無い。確定しているのはFALSE=0という事だけ」だとずっと思っていたんですわ。
古いC言語風に書けばこんな感じ。
#define FALSE 0 #define TRUE (!FALSE)
確かに、実際に値を表示させてみると、昔のVC6だと「1」という結果が出てくるし、VB6だと「-1」という結果が出てくる。これ、当時混乱の元だったんだよね。
新しいC++や規格ではBOOL型というのがきちんと定義されたと思うけど、製品寿命が20年とかいう私の職場では、DOSやC(K＆R)、アセンブラは現役だし、プラットフォームもなにもWindowsに限らない。組み込みマイコンも使う（うちのところはVxWOKSだが）し、UNIXやLINUXも使う。
もちろん、マネージドC++（.netFramework)やC#、JAVA、Parlも私は使うし。でも、どのプラットフォームでどの言語になっても「TRUEか？」という判定文は使ってこなかった。
で、試しに、VC2008のincludeフォルダをgrepしてみたら、
#define TRUE 1
あ、ほんとに「1」だ。
typedef bool int
なんて見かけるから、やろうと思えば「5」でも何でも数字が入ってしまうわけですよ。そこで「== TRUE」なんてやられたら、絶対に成立しないわけで。バグの温床になるんじゃないかなー、と思ってかたくなに前述の姿勢を持っていたわけです。
今（最近の）言語はきちんと「BOOL」型（またはboolという名のクラス）を定義されていて、コンパイルエラーになるか、自動的に補正してもらえるのかもしれないけど、ちょっと気持ち悪い。
最近、ちょくちょく外注や若い連中と意見や話が合わず、「ああ、俺ってレガシープログラマなんだな」と思う事が多くなった今日この頃。ネットワークに平気でリトルエンディアンのデータを流すとか、勘弁して欲しい。LANアナライザでデータが見にくくてしょうが無い。
みたいな感じで、関数コールを嫌う文化だからなぁ突き詰めると。
そういう事をしようと思わない。別な書き方をするとかじゃなかろうか？
いちおう、C++ならクラス内にクラスは書けるから似たような事はできる。
C/C++は文化的に速度とメモリを重要視する言語だから、あんまりね、そう言うのは主流じゃないと思う。
class A{
private:
int A:
public:
A=a;
}
}
みたいなことも・・・あまり、おすすめできないし・・・。論理的には美しいんだけど・・・いろいろ弊害もあると考えるのがC/C++
ましていわんや、関数内。
※一番痛いのは、設定関数が1箇所なので、動作変更がすぐできる＞＞大規模システムではコードカバレッジがあるので、
根元の関数の挙動を大きく変えられたら、上位のクラスの莫大なテストやり直しだから、1箇所変更で全箇所変わるのはデメリットｗ。上位で修正が基本。
というか、やっちゃだめｗｗｗ。
たとえば、intをdoubleにとかなら、それもう別物だから、上位も変更でしょ。普通・・・。とか。
あと#define関数はデバッガーでおえないので、なるべくC++のコンパイラ通してinlineで書いてぇぇぇぇとか。色々。むしろ#defineで複雑なことしないでー
http://b.hatena.ne.jp/entry/d.hatena.ne.jp/yaneurao/20110109%23p1
http://d.hatena.ne.jp/yaneurao/20110109#p1
いや、実際そういう悩みはちょっと懐疑心があれば誰しもがとおる道かと思うのだが、そんな穿った見方せずとも「歯車の運用テスト」と見れば十分わかるだろ。
つまり、内容や方法の新旧ではなく、統一された指標としてひとりひとりの人間の出来具合を、「学力」という指標でテストしているだけのこと。
だから過マンガン酸カリウムが大事なのではなく、与えられた情報から適切な解を導き出せるかどうかが問題なの。
だから、これまでのテスト工程を簡素化し、さらに歯車養成さえ否定した「ゆとり教育」は、テスト信奉者からは糾弾されたし、そのテストをくぐり抜けてきた「ゆとり世代」は不良品含有率が多いことを危惧され、実際そうなっているという談が随所にあるだろ？
それでなくとも、テスト数の少ない私大はバカにされてるし、正規のテスト工程でない「推薦」「附属上がり」も不良品が多いと見做されてるわな。実際そう思うけど。
まあ、つまるところ「詐欺師の集団」なんて論はあなたの見方によって正しいけど、それ以上の意味はない。
こういうシステムの不備を訴える主張はよくあるのだけど、より良いパフォーマンスのシステムを提案できないなら愚問もいいとこだよね。
テスト工程という観点から見れば、あなたが持ち出したC++の例はいいんじゃないか？平等なものからすれば、それよりはHTMLとCSSになるんじゃないかと思うけど。
まあいっちょ前にブラウザの挿げ替えで優越感浸る現状から見れば、ブックマークレットやユーザーjsのひとつぐらい作れるようになる教育は必要だと思うがね。
レジストリ弄れるようになれとは言わないけども。
仰る通り、ハードウェアアーキテクチャについては知らないですね（スタックやヒープがどうとかは表面上わかりますが）。
というのはズバリそこが非常に嫌い（肌に合わない）で、意図的に避けてるからです…。アセンブラの本とかも持ってますが、どうにも読めないですね…。
当然Cは嫌いです…。C++がギリで、できればRやpythonレベルの抽象度で全部済ませたい派です。が、さっきも書いたようにちょっと踏み込むとすぐ低レベルの話が出てきますね…。
最近はGPUだの並列化だのを使いこなさないと生きていけない感じですし。
関数型言語くらい抽象化して数学っぽい雰囲気になってると個人的には嬉しいですねw
そうではなくて、独自規格から始まったものが後日改変されて、正しく定義され規格化された場合、その日以後の新プロジェクトはその規格に従ってくれという事。（例外もあるだろうが）
当初true/falseという物はなかったが のちのちC++などのために定義された その定義の中には if(false){がelse節になるという自明の理が含まれている。
であるならば、falseという名前を含んだものがifでthen節になるルールを、後発規格ができたあとに作るな。という事。
そういうものが必要であるならば、ON/OFFであるとかActive/Inactiveであるとか、命名規則が矛盾しないルールを作って、規格化されたルールとまぎらわしい、ルールを作るのは、誤用の観点から、なぜ、そんな事をするのか？害悪じゃないのか？という事。
なぜならば、後発規格で定義された標準仕様に反するから、新規参入メンバーが混乱し、同一視した結果、意図しない潜在バグが発生するおそれもあり、教育コストの面からのデメリットしか無く、経済的メリットが挙げられない。コンパチビリティーで先発規格に合わせるのは除外して。（MS定義のFALSEなど、旧システムのfalseは仕方がない）
同様に int,short,long の定義は short<long でありint は適宜最適な長さ という意味なので my_longなどを独自定義せずに 4バイトが欲しいならDWORD（先発規格）かint32_tを定義するか使え</p>
いつまで、my_longを定義しているんだ！いい加減 規格に対応しろ という事。
10頃ライブラリを呼び出します。lib1_true lib2_true lib3_true lib4_true ・・・・ lib1がtrueだったときにlib2にtrueを渡して・・・その結果をlib3に・・・載せ替えて・・・ってどんだけ、コンパチの確認を目視でしなきゃならんのだと・・・。
各個人、各会社で独自仕様でしかも、C/C++の規格と紛らわしいとか、やめてくれ。可能なかぎりC/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にする もできない理由は思いつかない。（作り直しだから）
なんつーかかんつーか。 キャリア30年の30代と キャリア10年の30代くらべて、
キャリア10年の30代の奴を何人も集めれば、キャリア30年の30代 と同じだけの研究開発ができるはず！みたいな、ノリだけは、なんというか、勘弁願いたい。
できるようなことなら、そらいいんだが・・・できてないから、こっちが乗り出してきてるわけで・・・
この国の団塊の世代は研究開発舐めトンのかと。いくらなんでも、文型の30代で会社はいってからパソコン始めました見たいな奴と
比べるだけでも失礼だし、できるんじゃないか？みたいなことを思って、やらせるだけでも、こっちを侮辱してるって感性はないのかねぇ・・・。
いくらなんでもC++ができる前から、プログラムやってるコッチと、そんなん比較にならんし・・・同じ人間だからできるはず！みたいな感性もちだされても・・・
そら、できるだろうけど、研究だけでも４年ぐらいミッチリ専門課程受けて来いって感じなんだか・・・
大学名じゃなくて、受けてきた、履修科目を見るという概念はないのか・・・
さすがに、今年は疲れた・・・。
そりゃあ、やろうと思えば様々な手法があるだろうけど…
いかに余計な作業を減らして「やりたいことを実現」するための作業に専念するか、を考えている。
いろんな言語への興味はあるが、むしろそのせいで今まで時間食いまくってるので、そろそろ「手早く作る方法」を知りたい。
あんまり色々な手法を試してもいられない。
「これ！」ってやり方を決めたい。
プログラミング言語は、C C++ Java Python Perl VB C# HSP PHP JavaScriptなど、どれも基礎を触ったりしてばかりで何年も過ごしてきた。
FLASHは持ってない。(PalaFlaは触ったことあるけど、いまいちイメージしにくかった)
なんだかんだで一番慣れてるのがHTML+CSSで、次点でPHPかJavaScript。
ただ、PHPだのjavaScriptだのSQLだの、複数言語を同時に扱ってると非常に面倒。
そこでサーバーサイドJavaScriptに目をつけたものの、『Jaxer』は2008年に書かれた記事がちょっとあるばかりだし…
Node.jsってどうなんだろう…？
うーん、あまり纏まってないが、とりあえず現状をダンプしておく。
なんか参考になるものがあればなー。
こういうこと色々聞ける相手も周りにいないし…