[OSASK 836] Re: タグシステム.

[Myurika <myurika !Atmark! pop06.odn.ne.jp>]

  こんばんは、Myurikaです。


  Hidemi KAWAI さんにいただいた [OSASK 826] Re: タグシステム. へのお返事です。

>  でも、僕の意見を一つ言わせてください。ブリンク属性など、「属性
>」を文字コードに含ませることはもちろん可能ですが、僕は感心しませ
>ん。もし、属性を文字コードに含ませるなら、「億」なんて全然足りな
>いです。色だけでも16bitは使うでしょうし、背景色も含めたらさらに1
>6bitです。文字コードは純粋に文字を意味することにした方が、不都合
>が少ないように思えます。むろん、この件に関しても最終決定権はシェ
>ル班にあります。

  賛成です。
  というか、文字コードの段階で色とか決め打ちされると、プログラム組みにく
いッス。

>>  もし、文字コードが32bitだったりすると、個人的にはcharが32bitになってほ
>>しいなぁ、とか思ってしまうのですけど…。こうすると、strcpyとかを普通に使
>>っても 32bitコード対応に(笑)。でも、その分、char*をバイトアクセスで使われ
>>たときに面倒ですが…。
>  互換性の問題もありますから、切り替えられるようにした方が、安全
>ですね。

  ですね。
  あるいは、strcpyとかの互換を完全に捨て、新たにstr型みたいのを作ってしま
う、とか、short charとlong charを作る、とか、strcpとかの型を int *にして
しまうとか…。
  あ、でも、

  int words[] = "Words";

  みたいな宣言は違和感あるなぁ(汗)。

>  ちなみに、これは純粋に僕の好みの問題ですが、Ｃ言語での標準のよ
>うに、文字列の長さがターミネーター文字（'\0'）を探すことでしか分
>からないような文字列は、嫌いです。そういう関係で、僕が作るルーチ
>ンのほとんどでは、最初の4バイトで文字列長が指定され、その後に実
>際の文字が並ぶという形式が多いです。これが気に入らない人は、strl
>enをかましてから呼び出すルーチンを作って隠すとか、僕の書いたコー
>ドなんか使わないで自作してしまうとか、そうやって対処してください
>。

  んー、それだったら、バッファオーバーフローも考えて、バッファサイズ、今
の長さ、文字列の実体、というほうがいいかもしれません。

>>  あと、文字コードが32bitだったりすると、OSASKネイティブなアプリにテキス
>>トファイルを渡すときに、SJISからの変換とか行われたりするんでしょうか。
>># こう言ってると、プレーンテキストですらファイルタイプグループになってし
>>まうかも(汗)。
>  僕は、32bit文字コードが主流になるとは思っていません。なにしろ
>、かさばりますからね。ただ、テキストにもコンバーターは必要になる
>とは思っています。文字コードの変換や、改行コードの変換のために、
>です。

  多少かさばっても、無理のないI18Nには32bitコードが欠かせない…、と個人的
には思っています。
  他のOSやアプリなんかが、「L10Nじゃだめだ、時代はI18Nだ!」とか言って苦労
しているのを見ると、最初からそういうことを考えていた方が無難かなぁ、と。


  それでは。

| Myurika （尾藤主和） myurika !Atmark! pop06.odn.ne.jp |