◀Unicode版開発トップへ
  • 25 インクルードガード
    • 35 Re:インクルードガード
    • 36 Re:インクルードガード
      • 43 Re2:インクルードガード
        • 44 Re3:インクルードガード
          • 45 Re4:インクルードガード
            • 50 Re5:インクルードガード
          • 52 Re4:インクルードガード
            • 55 Re5:インクルードガード
        • 46 Re3:インクルードガード
      • 54 Re2:インクルードガード
    • 48 とりあえず安定(trunk統合)するまでの方針
      • 49 RE: とりあえず安定(trunk統合)するまでの方針
    • 69 RE: インクルードガード
      • 72 Re2: インクルードガード
        • 73 Re3: インクルードガード
        • 74 Re3: インクルードガード
        • 75 ファイル終端の/*[EOF]*/

  • [25] インクルードガード dskoba 2007年11月17日 22:12

    #pragma once はどうしますか。
    今までは StdAfx.h にしか無かったと思いますが，Unicode版には数多くのファイルで使われています。

    #ifndef の方のシンボル名が "_" で始まるのは，これはこれで良くないようですが。

    • [35] Re:インクルードガード ラスティブ 2007年11月18日 15:18

      ▼ dskobaさん
      > #pragma once はどうしますか。
      打つ手間で比べるなら #pragma once のほうが。

    • [36] Re:インクルードガード kobake 2007年11月18日 17:07

      以下の理由により、自分も #pragma once を推します。

      ・打つ手間が楽
      ・意味が明白
      ・ミスが起こらない (#ifndefと#defineの間の定数名スペルミス、#endif抜け、等)
      ・ネーム空間を圧迫しない

      ＃互換性は気にせず「あるものは使う」という富豪スタイルです。
      　必要に迫られれば逆にプリプロセッサ側を自作します。

      • [43] Re2:インクルードガード もか 2007年11月19日 17:59

        BCCで使えないようですが、BCCも捨てでしょうか。

        • [44] Re3:インクルードガード kobake 2007年11月19日 19:34

          ▼ もかさん
          > BCCで使えないようですが、BCCも捨てでしょうか。

          おっとそんな身近なコンパイラも #pragma once 非対応なんですねぇ。。
          視野に入れたほうが良いとは思うのですが、「個人的には」BCC捨て派です。
          フリーで Visual Studio 2005 Express Edition が手に入る時代になりましたし。

          #pragma once の対処くらいなら、何をすれば良いかがハッキリしていて良いですが、
          それ以外のコンパイラ間の差 (仕様、性能など) を埋めるのに
          どれだけの手間がかかるのか、自分は知りません。
          たとえば深めの template などをちゃんと解釈してコンパイルしてくれるか不安です。
          けっこう template ゴリゴリ使ってるので。(規格に合うようには気をつけているつもりですが)

          ＃BCCの実際の性能は知りません。
          　ちょっと試してみようと思ったんですけど、サーバエラーで入手できずorz

          • [45] Re4:インクルードガード AC 2007年11月19日 21:29

            BCCは文字列系の挙動が違う
            そして、ボーランド派は意外と多い

            • [50] Re5:インクルードガード げんた 2007年11月19日 23:28

              >BCCは文字列系の挙動が違う
              私も普段使用していないのですが，かすかな記憶をたどると，localeが"C"でないと文字列関数の挙動が変わるので強制的にlocaleを競ってするコードが入っているはずです．

          • [52] Re4:インクルードガード げんた 2007年11月19日 23:28

            >おっとそんな身近なコンパイラも #pragma once 非対応なんですねぇ。。
            というか，#pragma と書いてある時点で特定コンパイラにしか通用しないと考えるのが自然では？

            かといって，#ifdefでVC2005以降なら#pragma onceとやるのは本末転倒(^^)

            • [55] Re5:インクルードガード kobake 2007年11月20日 00:04

              ▼ げんたさん
              > >おっとそんな身近なコンパイラも #pragma once 非対応なんですねぇ。。
              > というか，#pragma と書いてある時点で特定コンパイラにしか通用しないと考えるのが自然では？

              自分が使ったことあるコンパイラ (VisualStudio, CodeWarrior, gcc) では全て使えてたので、
              割とメジャーな部類の方言、かと思ってました。

        • [46] Re3:インクルードガード ラスティブ＠ボーランド派 2007年11月19日 22:04

          インクルードガードを従来の形式に変更するとともに、
          my_tchar.h my_icmp.h 系を util/string_ex.h に統合する
          パッチをアップしました。

          PatchUnicode #1834523 「保守パッチ」

          エンバグさせてしまっている可能性が。

      • [54] Re2:インクルードガード げんた 2007年11月19日 23:42

        >・意味が明白
        Visual C専用だから，(Windows以外の開発者も含めて考えれば)かえって意味がわかりにくいと思います．
        #ifdef-#defineは完全にイディオムと言ってもよいレベルだと思いますし，十分明白だと思いますけど．

        >・ネーム空間を圧迫しない
        定数はenumかconstを使うべきですし，マクロもインライン関数で用が足りるので，マクロ定数を使うのはかなり限られた部分だけだと思います(と書いて，F_xxxがすべてdefineだったことを思い出したりして)
        まあ，PrefixかPostfixを決めておけば(つまりコーディングルールを決める)これが問題になることは無いのではないでしょうか．

        >富豪スタイル
        本当の富豪は，もはやC++なんぞ使っていなかったりして...(^^)
        JavaScriptでもエディタできちゃう時代ですし..

        ---
        とかいう議論はできた後で．

    • [48] とりあえず安定(trunk統合)するまでの方針 kobake 2007年11月19日 22:42

      ▼ ACさん
      > BCCは文字列系の挙動が違う
      > そして、ボーランド派は意外と多い

      なるほど、情報ありがとうございます。


      ＞皆様
      UNICODE仕様wikiにBCCの項を作りました。
      自分はまったく情報を持ってないので中身からっぽです。
      http://mofmof.nsf.tc/soft/sakura_unicode/index.php?BCC%E5%AF%BE%E5%BF%9C
      識者のご加筆をお待ちしています。


      さきほどの「BCC捨て」は個人的希望ですが、
      UNICODE化代表者 (になったらしい) 的見解としては、
      「trunkに統合されるまではVisualStudioのみ対応」で進めることを提案します。
      目的 (UNICODE版安定) への道のりはできるだけ短くシンプルに抑えたいです。

      trunk統合後のBCC対応はおいといて、
      とりあえずtrunk統合までの方針として上の案を挙げましたが、
      それに関してご意見ありますでしょうか。

      • [49] RE: とりあえず安定(trunk統合)するまでの方針 げんた 2007年11月19日 23:27

        >UNICODE化代表者 (になったらしい) 的見解としては、
        >「trunkに統合されるまではVisualStudioのみ対応」で進めることを提案します。
        ＃ソース見ないで発言します

        #defineの可変引数が使われていてVS2003でもコンパイル通らない訳なんですが，とりあえずVS 2005のみで進めてもらってもいいんじゃないでしょうか．

        VS2003やBCC対応はラッパー関数とか置換で後からなんとかなるような気がします．

        他にも起動が遅いとかバイナリがでかいとか気になるところはありますが，その辺も動いてからで．

    • [69] RE: インクルードガード げんた 2007年11月28日 19:49

      手で入力すると間違える，他のファイルと衝突するという問題を解決するために，ガード挿入マクロをつくりました．
      http://sakura.qp.land.to/?Macro%2F%C5%EA%B9%C6%2F184
      アンダーバーで始まるマクロは予約済みのようなので，SAKURA_ファイル名_GUID_H_ のようなガードを生成するようにしてみました．二回実行すると二つ入ってしまう点はご容赦ください．

      #pragma onceについて，gccのマニュアルではobsolete featureになっているので，世の中の流れとしては縮小傾向なのかなと．
      http://gcc.gnu.org/onlinedocs/gcc-4.0.3/cpp/Obsolete-once_002donly-headers.html
      ファイルのパスだけで同一性が判断されるのでsymbolic linkを使った場合に問題が出るみたいです．(ここでは関係ないですが)

      • [72] Re2: インクルードガード kobake 2007年11月29日 22:58

        ▼ げんたさん
        > 手で入力すると間違える，他のファイルと衝突するという問題を解決するために，ガード挿入マクロをつくりました．
        > http://sakura.qp.land.to/?Macro%2F%C5%EA%B9%C6%2F184
        > アンダーバーで始まるマクロは予約済みのようなので，SAKURA_ファイル名_GUID_H_ のようなガードを生成するようにしてみました．二回実行すると二つ入ってしまう点はご容赦ください．

        おぉ！ありがとうございます。ライセンス文も挿入してくれるのが良いですね。

        ところで前々から気になっていたのですが、
        ファイル終端の「/*[EOF]*/」にはどういった意図があるのでしょうか。
        本筋の話とは関係無いですが。


        > #pragma onceについて，gccのマニュアルではobsolete featureになっているので，世の中の流れとしては縮小傾向なのかなと．
        > http://gcc.gnu.org/onlinedocs/gcc-4.0.3/cpp/Obsolete-once_002donly-headers.html
        > ファイルのパスだけで同一性が判断されるのでsymbolic linkを使った場合に問題が出るみたいです．(ここでは関係ないですが)

        なるほど、個人的に残念です。
        時代を汲むならば#ifndef式に則るほうが良いんですかね。

        ＃余談ですが「#pragma once(任意識別子)」のような構文があれば最強だと思います。

        • [73] Re3: インクルードガード げんた 2007年11月30日 00:01

          >ファイル終端の「/*[EOF]*/」にはどういった意図があるのでしょうか。
          いやー，なんか最初からそうなっていたので私にもわかりません．無視していたら追加ファイルの末尾に親切に追加してくださる方が現れたりして，かといって禁止したり削除したりするほどの物でもないし，なんとなくそのままになってます．

          EOFでgrepするとファイルの行数が一覧できるとおっしゃった方がいましたが，ソースコード行数は専用のソフトで数えられるし...

          きっと後世の人が想像力のトレーニングをするようにと先祖が残した贈り物なんですよ．(大嘘)

        • [74] Re3: インクルードガード ラスティブ 2007年11月30日 00:55

          げんたさんのマクロをラッキーと叫びつつ使わせていただき、
          全てのヘッダファイルに以下のようなガードを挿入したものを、
          保守パッチとは別に新しく作成しています。インクルードガードの
          変更と bregexp.h の削除だけなので、そのままコミット出来るん
          ですが・・・kobakeさんに任せちゃってもよろしいでしょうか。

          #ifndef SAKURA_CAUTOSAVE_H__99022BB5_D7EC_492C_9CA2_3B247965BB45__INCLUDED_
          #define SAKURA_CAUTOSAVE_H__99022BB5_D7EC_492C_9CA2_3B247965BB45__INCLUDED_

          // ...

          #endif /* SAKURA_CAUTOSAVE_H__99022BB5_D7EC_492C_9CA2_3B247965BB45__INCLUDED_ */
          /*[EOF]*/

          どうでもいい事ですが、こちらでは stdafx.h で使われている
          インクルードガードを模しています。

          ▼ げんたさん(>>73)
          > きっと後世の人が想像力のトレーニングをするようにと
          > 先祖が残した贈り物なんですよ．(大嘘)

          (大嘘)← ココ重要ですよね・・・。

        • [75] ファイル終端の/*[EOF]*/ ryoji 2007年11月30日 01:42

          ▼ kobakeさん
          > ところで前々から気になっていたのですが、
          > ファイル終端の「/*[EOF]*/」にはどういった意図があるのでしょうか。
          > 本筋の話とは関係無いですが。
          元はどんな経緯でそうなっているのかはわかりませんが、最終行が空行（改行のみの行）になっていると、TortoizeSVNの"Apply Patch"で勝手に空行が追加される問題があります(>>dev:4637 で記述した「別の話」の件)。
          Ver1.4.5（current version）でもそうです。次期バージョンのNightly Buildsでは修正されていますが。
          TortoizeSVNのバージョンによっては気をつけていないと末端にどんどん空行が追加されていくことになるので、そのガードとしては意味があるんじゃないかと...