{デライト手定め離立}{希哲14年2月2日}{to_ 接頭子}{希哲14年2月2日の進捗時限}{希哲14年2月2日の進捗}{デライト先行離立}{複合型}{構築函数}{明示性}{進捗記録}...=}(22)

{希哲14年2月2日1歩 K#F85E/A-5B28-96B9}

デライト最終調整KNEST 認証整理。

睡眠食事を取り,作業再開。

途中で終了。

本日中の「デライト手定め離立」を目指す。これまで「デライト先行離立」と呼んでいたものとほとんど同じだが,表現を厳密化した。

型変換を統一的に扱うため,これまで活用していなかった to_ 接頭子を活用することにした。構築子構築函数to 演算子と中途半端に被る気がして避けてきたが,拡張性柔軟性明示性が高く変数名名称空間との衝突も避けられるため,s_T のような複合型ではこちらを標準的に利用した方がいいだろう。

=}
{名称空間}{xtd::}{kn}=}(3)
{Cμ 標準譜台規約}{Cμ 標準名称空間規約}{単純型}{希哲14年1月13日}{複合型}{名称空間}{台録構成}{明文化}{合理的}{函数}...=}(13)

{希哲14年1月13日の開発 K#F85E/A-5B28-6D7A}

名称空間台録構成の方針について整理が進んだ。

型に関する函数名称空間の関係について,foo が単純型の表現である場合は foo() を変換函数に,複合型の表現である場合は foo_T() を変換に利用し,必要であれば foo:: を関連函数などをまとめる名称空間として利用することを明文化することにした。

もともと,自然にやっていたことではあるが,改めて検証してみると意外に合理的だったことが分かった。

これら規約を Cμ 標準名称空間規約Cμ 標準譜台規約として管理していくことにした。

{希哲14年1月13日8歩}{希哲14年1月13日の開発}{名称空間規約}{Cμ 規約}{希哲14年1月13日}{名称空間}{明文化}{Cμ 標準規約}{経験則}=}(9)
{単純型}{希哲14年1月13日の進捗時限}{希哲14年1月13日の進捗}{希哲14年1月13日}{複合型}{進捗記録}{進捗時限記録}{進捗時限}{名称空間}{明文化}...=}(14)
{n::}{s::}{整合的}{s_T()}{単純型}{n()}{希哲14年1月13日の進捗時限}{希哲14年1月13日の進捗}{希哲14年1月13日}{複合型}...=}(27)

{希哲14年1月13日4歩 K#F85E/A-5B28-B756}

デライト最終調整KNEST 認証整理。

途中で終了。

における台録構成名称空間について方針を再確認。

もともと,名称空間を切り分けやすくしたい,ADL を効率的に利用するために foo_T を foo:: 以下に入れ,冗長性は use で解決するという方法を取っていたが,これはいまだに有用であるため,据え置くことにした。

一方,これに合わせて foo/ に foo.cl.h を入れる,というような方法は煩雑さの方が大きいため,廃止することにした。これは定義位置ではなく,通称を基準に考えることで整合性を取る。既存の譜類は順次移動させる。

foo:: と foo() が衝突する問題をどう回避するかという課題は Cμ 初期からずっと残っているが,今のところそれほど大きな障害にはなっていないため解決は急がないことにした。

C++ は参照内容によって foo が名称空間か函数か解決してくれるような気の効いた仕組みにはなっていないため,foo を名称空間として利用するか函数として利用するかは設計の問題と考えるしかないかもしれない。

これまで,数値への変換は n() で,文字列への変換は s_T() で行うことが多く,整合的ではない気がしていたが,よく考えると単純型複合型の使い分けとして合理的だったのかもしれない。s_T には s:: があった方がいいが,n::必要性は感じたことがない。

=}
{開き波括弧}{波括弧省略}{字上げ}{tp.h}{希哲14年1月10日の進捗時限}{希哲14年1月10日の進捗}{希哲14年1月10日}{Cμ 交度規約}{行末カンマ}{行頭カンマ}...=}(23)

{希哲14年1月10日15歩 K#F85E/A-5B28-56D7}

デライト最終調整KNEST 認証整理。

tp.h のまとめを終えたところで終了。

今日はここまで。

今日は Cμ 交度規約についてもいくつか進展があった。

これまで制御構造波括弧省略は避けてきたが,「書き始めは波括弧付きで,安定してきたら外す」という規則を導入することで,不安定な時期には波括弧付きで安全性を高め,外す余裕のある程度に安定した時期には外して可読性を高めていくことにした。行頭カンマ行末カンマ使い分けの経験が役立った。

また,多層的な名称空間を利用する際の問題だった字下げが深くなり過ぎるという問題について,次行の開き波括弧の位置を上げても良い,という規則を導入し,これを「字上げ」と呼ぶことにした。細かい法則については実験しながら決めていく。

あとは,苦手意識が残っていたテンプレートについて良い復習が出来,今後の応用力につながりそうだ。

=}
{部区}{希哲14年1月11日}{希哲14年1月11日のツイスト}{字上げ}{Cμ 交度規約}{名称空間}{波括弧}{ツイスト}{入れ子}{ブロック}...=}(13)
{名称空間}
{}