「enum」を含む日記 RSS

はてなキーワード: enumとは

2018-08-14

anond:20180814163400

Enumにわけわからん値待たせてる。その値なんすか。意味わかんないんですけど。

からないことはちゃんと聞いて確認しないとダメでは?

ソースダサい

センスがないんだよね。

たぶん本人はかっこいいと思ってる。

name4User

とか。だっさ。

Enumにわけわからん値待たせてる。その値なんすか。意味わかんないんですけど。

言わずもがな本人も鬼ダサい

2018-08-10

anond:20180810151853

から、三値論理計算量だったりデータ量を落とすために利用するのにtrue/false/nullをDBに入れるのはアフォだろうと。そういうカラムはtinyintでやれ。enumでもええけど。

2017-10-21

何でもかんでも揃えようとしないでほしい

プログラマなんだけど、なんでも揃えようとしてる人がうざい

よくあるのが、JSON とかオブジェクト系の記述するところで、 「:」とか「=>」みたいなのの位置

揃えられると一見すると見やすいが、金額みたいに揃ったみやすさが必要ないところでされると面倒

10行並んでたら1つ変えたのが原因で10行とも変えないといけなかったりする

面倒だけどツール使えば揃えること自体は楽にできるからこれはまぁいい

だが、バージョン管理ソフトでの変更行数が無駄に増えるのでパット見たとき結構大きな変更してるように見えたりするからちょっとイヤ

さらgrep かけようにも空白数が不定だから正規表現にしないといけない

正規表現書くの面倒だしそもそも遅い

大規模プロジェクトだと待ち時間が大きく変わってくる

んだけど、まあここまでは別にいい

他でも十分ある宗派の違いだし、まだ理解できる

この揃えるとき

aaa      : {
    bbbb : 100
    ccccc: 200
},
dddd     : {
    e:   : 300
}

みたいに(フォントによっては揃ってなく見えるかも)、ネストが違うのに全部を揃えようとするの、ホントやめろ

わかりづらい

上の例みたいなシンプルだと困らないが複雑な構造になってるとかなり見づらい

せめて揃えるのは連続する行で同じ階層のものだけにしてほしい

上でいう aaa と dddd の行が10行程度離れていたら、ここを揃えても全くきれいに見えないし無駄

bbbb と ccccc みたいなときだけならまあ許せる



仏の顔も三度まで、

ここからは許せないレベルもの


(1) 文字数を合わせようとする

上で書いたみたいなのは文字数が違うから合わせるためにスペースを入れる必要がでる

しか文字数が揃ってたらそんな必要はなく見た目も綺麗だ

きれいなのはわかる、だが無理やり合わせようと単語を探し始めるとかありえない

5つ項目があって、4つが6文字単語で残りの1つが4文字だったとする

6文字にしたいからそれっぽい意味単語いか探そうとしてる

無駄な上に、本来のそれに適した単語じゃないのを無理やり使うのでわかりづらい

理解できない自己満足しか思えない

揃ってることはパット見綺麗でもプログラムみたいのだと、単語まで似てると気づかないミスが出て来る

beer と bear、 form と from、 fall と fail みたいな見た目が似てる単語と、見た目が全く違う単語比較ではミスの数が明らかに変わると思う

なのに、 enum みたいな選ぶタイプのもので、数文字違うだけの似た見た目の単語を探してきて選ぶとか、ミスを誘発しようとしてるのかと言いたい



(2) 単語の語尾とか

(1)のように大半が揃ってると残りも無理やりそうしたいということで、単語勝手に変化させたものがある

例えばだが、語尾が1つを除き全部 -ly になってたとする

そうすると残り一つに無理やり ly をつける

なんなの?イン踏みたいの?ラッパーなの??

経緯を知らない人が見たら意味不明単語である

そもそも名前みたいな固有名詞にすらそんなことしてるから意味不明にもほどがある



(3) 変化形無視

上の時点で英語を完全無視英語力のなさはわかっただろうが、さらにこういうのもある

過去形には ed複数形には s のようなルールには単語によっては特殊な形をするものがあるのはもちろん知ってると思う

それを完全無視変数名を定義するから見ててすごく気持ち悪い

プレフィックスis つけるみたいな単語の組み合わせ部分なら気にしないけど単語としておかしいから、自分で書くとき本来の形で書くとエラーでるからさらイライラする

例えばこういうこと

readed, catched, taked, companys, boxs, mans, childs, fishs, classs

見てるとムズムズする

英語得意でない自分ですら違和感を感じるのに、これに何も感じないとか英語力ひどすぎると思う

まあエラーメッセージdon't have ~ とすべきところを has not ~ とか書いてたくらいだからなぁ

これが部下とか下の立場の人なら 「使う前にググってみて。おかしかったら『もしかして、~~』みたいの出るから」と言って直させるけど、上だからどうしようもない

間違ってますよー、と遠回しに言ってみたことはあるものの、直す気は全くないようだし、それどころか無邪気に揃えてやったぜみたいなこと言ってドヤ顔してるからホントどうしようもない

2016-11-09

switch文が許されるのはenumを処理するときだけ

しかenumを使う場面というのは、

外部と通信するためのパラメータの一部だったりするが、

内部の都合で値が自動生成されるenumの仕組みはその外部の仕様と合わせるのに実に相性が悪い。

よってenumは使い物にならないし、swtichを使う場面もない。

レガシー文法である

2016-11-05

PHP7で堅牢コードを書くとかいう風潮

いやまあ、これ読んだんすよ。

でさ、もうね、こいつ馬鹿なん?w ってゆう。

 

PHP7で堅牢コードを書く - 例外処理、表明プログラミング契約による設計 / PHP Conference 2016 // Speaker Deck
https://speakerdeck.com/twada/php-conference-2016

 

PHPみたいなレガシーゴミ言語にしがみついて、

必死に型とかEnumとか再発明って・・・

草すぎてコーラが無くなってしまうんだw

 

せめてさあ、Javaでも使えば?

いやっつーかホントPHPでここまで涙ぐましい努力しても、

劣化Javaしかないのが悲しいよね。

 

ペチプァっ~って馬鹿しかおらんのか?

こういうゴミ屑が勘違いして、

とか喧伝して糞案件量産してると思うと、反吐が出るね。

PHPと一緒にさっさと死んでほしい。

おまえもそう思うよな?

 

草プァ~~~w

2016-07-25

gitにおけるコミットログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくま単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのであるググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログから転載である。当然ながら各コミットログ著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユース範囲なら許してくれるだろうと考え名前プロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリGitHubSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した(あわせて前処理として、コミットログ冒頭のタグ情報は消去した)。

結果として対象としたリポジトリは以下の通り。

atomのみ5400件抽出していたため、計25400件のコミットログベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションフラグメニューを追加した
ファイルを追加した
メソッド機能を追加した
実装を別のものへ切り替えた
  • Use args.resourcePath instead of args.devResourcePath
  • Use arrays instead of while loops
  • Use auto instead of repeating explicit class names
  • Use weak pointer instead of manual bookkeeping
  • Change all uses of 'CInt' to 'Int32' in the SDK overlay
  • Change Integer#year to return a Fixnum instead of a Float to improve consistency
新しく何かに対応した/機能上の制約を取り払った
何かを使うようにした
より好ましい実装に改良した
何かを出来ない/しないようにした
  • Don't bail reading a metadata instance if swift_isaMask isn't available
  • Don't exit until the parent asks for an instance
  • Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
  • Don't use MatchesExtension for matching filters
  • Don't use ES6 class for AutoUpdater windows class
  • Don't use MatchesExtension for matching filters
  • Avoid `distinct` if a subquery has already materialized
  • Avoid infinite recursion when bad values are passed to tz aware fields
オブジェクトの内容や挙動確認やすくした
Assertを追加した
不要コードを除去した
コードを移動した
名前修正した
さなバグタイポ修正した, 警告を潰した
バグや好ましくない挙動修正した
テストコメントドキュメントを追加した
テストを削除した
テストコメント修正した
ドキュメント修正した

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

Add1149
Fix1014
Update584
Remove566
Use382
Don't260
Make228
Move178
Change103
Rename85
Improve76
Avoid68
Allow65
Implement60
Handle58

コミットログの基本形はもちろん動詞 + 名詞である名詞固有名詞複数形、不可算名詞が多いが、単数形場合冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテストドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typocrash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合Make sure が使われる(こちらはthat節が取れる)。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う(Ensure はさらに重い表現っぽい)。

また、Fixtypo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメントコメントテストに使われ、本体コード修正に対しては使われない。本体コード修正にあわせてテスト更新したなら Update が使われる。ただ、テスト機構それ自体バグ修正したなら Fix である

無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)からのもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合Don't use を使うことが多い。

何かをしないようにしたなら Don't を、内部実装効率化なら Make A + 比較級/形容詞Improve が使われる。

中身の変更を伴わない単なる名前の変更なら Rename A to B、コード機能論理上の場所を移動させたなら Move A to B である

この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。

余談

コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である

一方で、シンプル単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。

おわりに

8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体効率のいい学習になるという話と同じだと思う。

このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

2015-09-20

Windowsシステムディスク入れ替えで躓いた件の備忘録

ちょっとした事情からシステムディスク移設をしたところかなり躓いたので、備忘録的にメモ

時代に逆行して個人的な書き物をする場所を一切持ってないのでお借りします。

以下、Linuxなりの最低限の知識があり、バイトオーダーもわかり、細かいところは勝手に補間できる人向け。

目的

Windows 7システムディスクの入れ替え。

オフセット32256バイトを1048576バイトに調整する。

得てして非AFTからAFTという状況と思われる。

コピー元が壊れかけの時はやらないほうが吉。

手順には省略するがたぶんやらないといけないこと


手順

  1. c:\boot\BCDバックアップ(BCD.org等)
  2. clonezillaとLinux Live USB CreatorをDL
  3. clonezillaのUSB起動ディスク作成(「作成したファイルを隠す」、「LinuxLiveWindows上で起動可能にする」のチェックは外す)
  4. HDD接続し、NTFSフォーマット
  5. msinfo32.exeを実行し、オフセットが1048576になっていることを確認
  6. clonezillaのローカルパーティション→ローカルパーティションでクローニング、オプションは全部デフォルト
  7. HDDのみ接続し(念のためclonezillaのUSBも外す)、Windowsインストールディスクを起動
  8. 最初の画面で「次へ」を選択したらShift+F10でコマンドプロンプトを起動
  9. diskpartを起動、list disk → select disk n → list part → select part n → active し、exit
  10. bootrec /fixboot, bootrec /fixmbrを実行
  11. bcdedit /enum allを実行、随所でdeviceがunknownになっているはず
  12. bcdedit /set {bootmgr} device "partition=C:"等をunknownになっているぶんだけ行う。osdeviceやfiledeviceも。
  13. ほかはツールになにも弄られないようにしてシャットダウン
  14. この状態で起動しようと思ってもカーソル点滅から進まない。ここから先の情報(というか23.)は少なくとも日本語では見当たらなかった。
  15. clonezillaを再度起動
  16. lsblkで/lib/live/mount/mediumとなっているデバイスを調べる(仮に/dev/sdb1。ついでに新HDDシステムパーティションは/dev/sda1と仮定。)
  17. sudo mount -o remount,rw /dev/sdb1を実行(自信があれば/tmpとか使ってもいい。オススメしないけど。)
  18. /lib/live/mount/mediumに移動
  19. sudo dd if=/dev/sda1 of=./pbr.bin bs=512 count=1を実行(/dev/sdaだとMBRになってしまうので注意)
  20. pbr.binのバックアップを取る
  21. sudo vi -b pbr.binを実行
  22. :%!xxd でバイナリ編集できるようにする
  23. 1Cが"3F00"になっているはず。これがhidden sectorsすなわちオフセット。ここを"0008"に書き換える
  24. :%!xxd -rで元にもどし、:wqで保存終了
  25. sudo dd if=./pbr.bin of=/dev/sda1 bs=512 count=1を実行し書き戻し(/dev/sdaだと略)
  26. 祝起動

23.もそうだけど12.もどこにもなかった。(英語は面倒でしっかり読んでない)

2点でめっちゃ躓いたってお話

2014-08-02

金のマサカリ

タイトルは今考えた

世界一IQの低いソースコードはこれ。という記事を読んだんだが、批評の方向が斜めな気がしたのでいくつか指摘をしてみる

予め断っておくが、俺はこの本を持ってないし読んだこともない

switch文使え

switch文を使ったところでクソはクソ

しかし後述の理由から妥協した結果、巨大なswitch文ができてしまうのがAndroidの恐ろしいところ

その文字列、keyCodeから引いてこいよ

わかっているとは思うが、keyCodeはint型なのでこれがなかなか難しい

リフレクションについては更に後述

その処理、関数で用意されてるよ

android.view.KeyCode.keyCodeToString(keyCode)

同様のコードを今組むとするならばとても優秀、最適解

しかブコメにあるように、この関数API Level 12(2011/05/10)から追加された関数であって

発刊当時(2010/01/25)に相当するコード存在しない

まあ知らないことが悪いわけではないので、これを期に修正検討するのも良い

リフレクション使え

試しにコードを書いてみようか

private static final String keyCodeToString(int keyCode) {
  for (java.lang.reflect.Field f : android.view.KeyEvent.class.getFields()) {
    if (f.getInt(null) == keyCode) return f.getName();
  }
}

いや、実際はこんなものでは済まない

private static final String keyCodeToString(int keyCode) {
  try {
    for (java.lang.reflect.Field f : android.view.KeyEvent.class.getFields()) {
      if (f.getType() == int.class && f.getInt(null) == keyCode && f.getName().startsWith("KEYCODE_")) return f.getName();
    }
    throw new IllegalArgumentException("Unknown keyCode.");
  } catch (IllegalAccessException e) {
    throw new RuntimeException("Internal Error.");
  }
}

無論、こんなコードを書いたところで可読性は最悪だし、明らかに初学者向けではない

あなたが眠れない夜を過ごしたいのであれば止めはしない

余談だが…  
Androidは昔、端末リソースの少なさ故に、enumインスタンス化に必要な負荷を節約することが是とされてきた  
そういった理由から、一連の定数群が大きなカテゴリを形成したとしても、その全てがint型によって定義されているのは特段珍しい訳ではない

Androidはそういった定数値をログなどにより可視化する必要がある以上、どうしてもこのような処理ができてしまうのを避けられない

こういった経緯を知っていると、リフレクション処理時の処理速度より本末転倒とも言えるので極力避けたい(リフレクション実行時の処理速度についてはググるといろいろ出てくる)
AOPしろ DI使え

お前人の話し聞いてたか

こういったコードを生まないために

Androidでは次のような対応を心がけたい

  • C++で組んだら?

他に良い対応方法があったら教えてほしい

(マサカリを)投げていいのは(マサカリを)投げられる覚悟のある奴だけだ

この場合における正しいマサカリの投げ方

こんなコードを4ページも消費して本に書いたところで冗長すぎる
本に書く様なサンプルではないし、紙数の無駄

2014-06-04

http://anond.hatelabo.jp/20140604161616

途中で編集してトラバ先を変えた?まあいいけど

否定派は三つならenumにするんじゃなかったんすか?

3つだからenumってことはなく、2つでenum、定数値だって問題ないよ。

bool?だって「true,false,null許容」が最適なら使われるべきだよ。

ただstate A,B,Cの3つを表現するのに、bool?が3値とれるからって理由で

trueはA, falseはB, nullならCみたいに本来の意味を変えて使うのはいかんな。

個人で書くコードならなんでもいいけど。

http://anond.hatelabo.jp/20140604161945

うーん、いまいちbool?否定派の意見わからん

「外部結合するフラグ値」をC#表現したいとき、どうして、enumを使わないといけないんだ?(true,false,nullしか入らないんだぜ)

bool?の方がお手軽で楽チンじゃん、定義を見れば一目で分かるし。

それをユーザー定義定義解釈するかどうかは、プログラム側の問題であって、3つ以上増えない「外部結合のフタグ値」を、bool?で定義した方が分かりやすいだろ。

http://anond.hatelabo.jp/20140604161616

すでにそうなっているものに文句を言ってもしょうがないだろ。

どうでもいいけど

Nullableの説明で

通常、値型は null 値(無効な値)を取れません。

http://ufcpp.net/study/csharp/sp2_nullable.html

とあるけど そもそも double型などはそもそも値だけではなく最初からNaNが使える。

数値とNaNの併用が可能な型。(Cの場合というのがある。)

まり用途に応じてEnumだったりdoubleだったりオブジェクトだったりを使い分ければいい。

フォーム型なんかの場合は元々オブジェクト指向になっていて、中身の実装がポインタポインタ=NULL とポインタ=BooleanObjectという実装だから出来る話。

ちなみに、未設定をCでやる場合enumではなく、ビット演算子を使うことになるかとは思う。3値ならenum C#ならNULLABLEでもいいんじゃね?

http://anond.hatelabo.jp/20140604161431

http://anond.hatelabo.jp/20140604153229

あれ、bool?否定派は三つならenumにするんじゃなかったんすか?

http://anond.hatelabo.jp/20140604154102

俺も横だから、ココにトラバつけるわ。

C#触ったことなから知らなかったけど、bool?(null 許容型)てのがあるんだね。

MSDNみてみたけど http://msdn.microsoft.com/ja-jp/library/1t3y8s4s.aspx

数値型と Boolean 型に null を割り当てる機能が便利なのは、値を割り当てられていない可能性がある要素を含むデータベースや他のデータ型を処理するときです。 たとえば、データベースの Boolean フィールドには、値 true または false を格納するか、未定義にすることが可能です。

ってことがnull許容型の理由みたいね

bool? であれば3つの状態を表すことができるかもしれないけど、やっぱりboolはtrueかfalseだよ。

MSDNにある通り、nullを許容するとしてもね。

3つ以上の状態を作りたいなら、それこそenumでもなんでも使えばいい。

bool?で宣言されてる変数を追って行って「3つの状態保持のために使ってまーす」ってコード見たら

ハァ?(゚Д゚) ってなるわ。nullはnullよ。

http://anond.hatelabo.jp/20140604155608

そういうのこそ、enum を使いたまえ、キミ!

http://anond.hatelabo.jp/20140604153229

>状態が3つになった時点でenumのほうがいいじゃん。

状態が四つ以上になることはありえないんだから、bool?の方が手間が省けていいじゃん。

これが、増える可能性があるようなものだったら、君の意見に賛成するけど。

http://anond.hatelabo.jp/20140604152234

状態が3つになった時点でenumのほうがいいじゃん。

ドライバ仕様でbool?が返ってくるとしたら定数にして

if(人事画面使えるかどうかフラグ == AVAILABLE)
「使えるよ! 開くよ!」
else if(人事画面使えるかどうかフラグ == UNAVAILABLE)
「権限がないから開けないよ!」
else if(人事画面使えるかどうかフラグ == UNDEFINED)
「ユーザーグループが未定義だよ!」

みたいにしたい

http://anond.hatelabo.jp/20140604133746

null=どちらでも良い

自明じゃないと言いたいんだ。どちらも駄目、とか不明、とかかもしれないし。

enumのほうが優れてると言いたいんだ。

1人で作るプログラムなら好きにすりゃいいが、仕事で書くプログラムは優れたやり方で統一したい。

2014-03-04

http://anond.hatelabo.jp/20140304185035

何の言語かしらないが、正しい定義を書けよ


const MODE_VIEW = 1;
const MODE_PRINT = 2;
const MODE_DOWNLOAD = 3;

/* 表示モード */
const MODE_1 = 1;

/* 印刷モード */
const MODE_2 = 2;

/* ダウンロードモード */
const MODE_3 = 3;

というか Cだと

enum ENUM_Mode{
    MODE_NONE=0,
    MODE_VIEW,
    MODE_PRINT,
    MODE_DOWNLOAD,
};

enumになってないと デバッガーで追い切れない?

※使わなくても、NONEは作って0にしておくのは小技

※MODE_DOWNLOADは 和訳すれば ダウンロードモード(和訳なのか?)なのでコメントを書く必要性がそもそも無い。

 

なんつーか、コメント日本語を使うな!がコメント上達への第一歩だと思う。

2013-07-02

わーい、今日からやっと配属だという初日に、エクリプス環境設定で一人やらかす。

手順書読み飛ばしてた自分が悪いんだけど、ビルドが通らない理由が切なかった

enumの文字がエラーメッセージに表示されて、そういえばJava先生に、

昔のjavaってenumは使えなかったんだ、みたいな小話を聞いたのを思い出して

あ、コンパイラー設定かも..と見直したらJREバージョンが新しいままになってた(といっても1.6だけど)。

この新人大丈夫かな、って周囲の目もきつかったが、ボロい開発環境もひいたし、

もう、なんか疲れた。やってけるのかな。

2013-03-03

http://anond.hatelabo.jp/20130303135038

Java学習コストが低くHaskell学習コストが高い」みたいな話をよく見るけど、本当なのかねぇ。

初期のJavaならともかく、AutoBoxingの落とし穴とかワイルドカードの正しい使い方とか、

強力なenumの使い方とか、色々入ってる今のJavaがそこまで簡単には思えない。

機能豊富さというより機能抽象度の高さが問題ってことなのかな。

2011-01-09

http://anond.hatelabo.jp/20110109000805

最近は、24インチ 30インチディスプレイなんて安いんだから、横80ではなく横120ぐらいは平気で使える。

classname::enumname という毎回指定でも エディタインテリジェントに保管してくれるから問題ない。

個人的には、毎回、スコープを明示して欲しい

 

基本的に 外部ツールがチェックしてくれるんだから

class{

enum{

{

};

で問題ないと思われ

言い方を変えれば、class内部以外でenum定義することなんて最近はあるのか?グローバルなenumなんて余り無いと思うが・・・

クラス内部では、省略できるし、外部からクラス内部の値を呼ぶときは、どのクラスのこのenumって外部だよって意味で毎回書いたほうが安全だろ?

 

スコープの省略は基本、オススメできない。

using namespace std

ですら、書かないほうが安全 毎回std::って書かないと、うっかり、stringクラス定義する人がいないとは限らんからね・・・

一斉に変更したい? エディタ正規表現で置換すればよろしい・・・

 

原則、外部のツールで解決できる問題は、外部のツールで解決すればいい。

言語仕様拡張されると、初心者に、その理屈を説明するという問題が出てきて、そういうのは初心者には無理。

他方、ツールを使えない初心者でも、毎回コピペや手で置換は出来る。

 

ソーシャルな人を使うという観点から、そういう言語拡張オススメできない。

2010-07-24

google発のProtocol Buffersについて

オブジェクトシリアライズツールであるプロトコルバッファについて書きます。

プロトコルバッファって何って方はこちらへ

Protocol Buffers 本家

http://code.google.com/apis/protocolbuffers/

XMLはもう不要!? Googleシリアライズツール「Protocol Buffer」

http://journal.mycom.co.jp/articles/2008/07/18/protocolbuffer/index.html

Protocol Buffers (Protocol Buffers の内部解説記事。とても参考になります)

http://dodgson.org/omo/t/?date=20080712

内容

プロトコルバッファは異種言語間でオブジェクトのやりとりをするための規格です。

独自の言語によりオブジェクトインターフェースを規定することで、多言語対応を行っています。

例えばこんな感じ。

  • address.proto
package tutorial;

message Person {
  required string name = 1;
  required int32 id = 2;        // Unique ID number for this person.
  optional string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

  message PhoneNumber {
    required string number = 1;
    optional PhoneType type = 2 [default = HOME];
  }

  repeated PhoneNumber phone = 4;
}

// Our address book file is just one of these.
message AddressBook {
  repeated Person person = 1;
}

以上のようなprotoファイルから各言語ソースコード、または何らかのデータ操作ライブラリを使いオブジェクトの処理を行います。

googleによってC++, Java, Python用のライブラリ作成されましたが、他の言語対応したサードパーティー製のライブラリがいくらでもあるので、実質的にほぼすべての言語で使えると言っても過言ではありません。

以下はこのライブラリを使ってみた感想などです。

整数型はVarintという可変長型でバイナリに保存される

数字が多きければ大きいほど、長いバイト長で保存されます。ただし、負数の場合符号ビットが立つ関係で、ほとんど常に変換後のバイト数が最長バイト数(10)になってしまいます。フィールドの型をsint32, sint64で宣言しると、各数値にzig-zags変換が行われるため、負数であってもその値の絶対値で使用バイト数が決まるようになります。

保存されるデータは各メッセージID/型/値のみ

バイナリに保存されるデータは各メッセージID/型/値のみです。なので、同じ定義の二つのメッセージ型は、プロトコルバッファ上では全く同じように扱うことが出来ます。例えば、片方からシリアライズしたデータを、もう片方の型でデシリアライズすることが可能です。

またオブジェクト連続シリアライズ/デシリアライズすることもできます。

継承されたクラスマッピング

すでに存在する継承関係のあるクラスを、Protocol Buffersでシリアライズ/デシリアライズしたい場合は次のようにします。

(Base, Derived はすでに存在するとします)

(ソースコード中になぜか日本語が書けないので、コメントはすべて英語になっています)

message PbBase {
        require int32 id = 1;
        require int32 value = 2;

        require Derived derived = 10; // - Point !!!
}

message PbDerived {
        require string string_value = 1;
}

継承元のメッセージ定義に、継承先のメッセージを持たせます。Base継承するクラスシリアライズ/デシリアライズしたい場合は、PbBaseメッセージを中心に処理を行うことで、比較的簡単に処理を実装することが出来ます。

例えばこんな感じ

Base *Base_DeserializeFrom(PbBase &pbobj)
{
    // Arrange the classes which inherits from Base.
    if (pbobj.has_derived()) {
        return new Derived(pbobj);
    }
    else
    ...
}

class Base {
    ...
    virtual void Base::SerializeTo(PbBase &pbobj) {
        // Set the fields of 'pbobj',
    }
    ...
};

class Derived {
    ...
    virtual void Base::SerializeTo(PbBase &pbobj)
    {
        PbDerived *derived = pbobj.mutable_derived();

        Base::SerializeTo(pbobj);
        // Set the fields of 'derived',
        ...
    }
    ...
};

protoファイルを以下のように書くと、メッセージの扱いが非常に難しくなります。

message PbBase {
        require int32 id = 1;
        require int32 value = 2;
}

message PbDerived {
        required PbBase base = 1; // - Here is the point !!!
        require string string_value = 2;
}
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん