class {
public:
    operator bool() { std::cout &lt;&lt; "xxx\n"; return true; } //*1
    operator int() { std::cout &lt;&lt; "yyy\n"; return true; } //*2
} foo;

があったときに、「if (!foo)」だったら*1が、「if (foo == false)」だったら*2が実行されるような処理系がある。

最新のVC++だと後者は曖昧だってエラー出るね(たぶんC++だと「trueは1でfalseは0」なんかではなくあくまでもtrueとfalseなんだ)。

なんにせよ演算子や条件式などに関連する暗黙のキャストはわかりづらく、そしてそんなのを利用したコードはきっとバグる。

だから

（fooはいろんなオブジェクトだと思ってほしい）

というのが本当なら、==trueがどうこうなんて些細な問題はおいておいて、fooを暗黙のうちにintにキャストしたりboolにキャストしたりして使っているという危険な部分をまずなんとかすべきだろう。

VCとかVBとかじゃなくてC言語 仕様の話だろ

古いC言語風に書けばこんな感じ。
#define FALSE 0
#define TRUE (!FALSE)
確かに、実際に値を表示させてみると、昔のVC6だと「1」という結果が出てくるし、VB6だと「-1」という結果が出てくる。これ、当時混乱の元だったんだよね。

aとbが等しいときに、

C言語だと、(a==b)の評価結果が1になるけど、

BASICだと(a=b)の評価結果は-1になる。

VC6とか関係なくてC言語の仕様でそうなんだが、それをわかってないとすればやばい。

個人的な好き嫌い

個人的には

   if( foo != FALSE ){

も十分きもちわるいので

   if (foo) { ... }
   if (!foo) { ... }

にしてほしい。

Permalink | 記事への反応(0) | 12:25

■レガシー プログラマ

まぁ、タイトルの「レガシープログラマ」とは私の事なんですけどね。

最近（？）外注や自社の若いのが作ってくるプログラムに

    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 アナライザでデータが見にくくてしょうが無い。

でもなー、何も、Windowsの統合開発環境だけの仕事で食っていけるとは思って欲しくないなぁ。

Permalink | 記事への反応(4) | 10:10

2009-11-08

■マクロを組んで作業するのは実力ではないですか?、を読んで

http://okwave.jp/qa5419623.html?ans_count_asc=20

職場でのマクロを使うことについて討論されていたので、プログラマの視点で語ってみようと思う、

そもそもマクロとは、物事を自動化してヒューマンエラーを無くし、作業を素早く楽に処理出来るようにしてくれる便利なツールである、日頃楽をしたいと思ってるプログラマならマクロを使うことは大賛成だ、ここで上司が技術インフラが整っていない所でスキルを必要とするような事をされては困る、みたいな意見が出ていたが、この点でもプログラマは問題ない、他の人が使ってるマクロを、便利だね、って言ってソースを貰っても、修正したけりゃ自分で修正する、ソースが貰えなくてアイデアだけ教えて貰った場合でもVBAなんて触った事がないC++プログラマが、VBAの仕様を調べ、ソースを書き、マクロを完成させ、実行時にしかデバッグ出来ない事に愚痴をこぼし、付属のIDEの使い勝手に苛立ちを覚え、VB6.0ベースの言語仕様に辟易し、VBAなんてクソったれだ!!、という感想を持つまでにそう期間は必要無い、

ただこれは、最初からプログラムを作るという仕事をしている私たちのベクトルへ、IT化の名の下に紙と鉛筆で作業していた人達が歩み寄る形になった為に得た偶然の優位性だ、

上司の年齢は知らない、上司の立場からすれば紙と鉛筆で綺麗な字を正確に速く書くのが実力だと言われていた世代なのかもしれない、そう考えると仕事と直結しないマクロという間接的な技術のツールを作り効率化を図るというのに対しある種のジェネレーションギャップが生じたのかもしれない、上司はそのジェネレーションギャップに対応出来なかった固い頭の人なのか、はたまた技術インフラを考えての達観した人なのか、

IT化がどんどん進む昨今、私が上司のようにまったく違うベクトルに遭遇するという事はないかもしれない、しかしソースコードを書いてアプリケーションを作るという手法から先の手法になった時、私はこの種のジェネレーションギャップを乗り越える事が出来るだろうか。

Permalink | 記事への反応(2) | 20:35