TCHARはまだ関連していますか？

https://stackoverflow.com/questions/234365

04-07-2019
|

質問

Windowsプログラミングは初めてで、Petzoldの本を読んだ後、私は疑問に思います：

TCHAR 型と _T（）関数を使用して文字列を宣言するか、または wchar_t および新しいコードの L＆quot;＆quot; 文字列？

Windows 2000以降のみをターゲットとし、コードは起動時から i18n になります。

解決

今日新しいプロジェクトを行う場合、TCHAR構文を引き続き使用します。それを使用することとWCHAR構文を使用することとの間に実際的な違いはあまりありません。文字タイプが明示されているコードを好みます。ほとんどのAPI関数とヘルパーオブジェクトはTCHAR型（CStringなど）を使用するため、使用するのが理にかなっています。さらに、ある時点でASCIIアプリでコードを使用する場合、またはWindowsがUnicode32などに進化した場合などに柔軟性を提供します。

WCHARルートに行くことを決めた場合、私はそれについて明示します。つまり、CStringの代わりにCStringWを使用し、TCHARに変換するときにマクロをキャストします（例：CW2CT）。

それは私の意見です、とにかく

他のヒント

短い答え：いいえ。

他のすべての人がすでに書いたように、多くのプログラマーはまだTCHARと対応する関数を使用しています。私の謙虚な意見では、概念全体は悪い考えでした。 UTF-16 文字列処理は、単純なASCII / MBCS文字列とは大きく異なります処理。両方で同じアルゴリズム/関数を使用する場合（これがTCHARのアイデアの根拠です！）、単純な文字列の連結よりも少し多く行うと、UTF-16バージョンで非常に悪いパフォーマンスが得られます（解析など）。主な理由は、代理人です。

ユニコードをサポートしていないシステム用にアプリケーションを本当にコンパイルしなければならない場合の唯一の例外はありますが、新しいアプリケーションで過去のこの荷物を使用する理由はありません。

サシャに同意する必要があります。 TCHAR / _T（） /などの根底にある前提は、「ANSI」ベースのアプリケーションを作成し、マクロを定義することでUnicodeサポートを魔法のように提供できることです。。しかし、これはいくつかの悪い仮定に基づいています：

ソフトウェアのMBCSバージョンとUnicodeバージョンの両方を積極的にビルドすること

それ以外の場合、多くの場所でスリップして通常の char * 文字列を使用します。

_T（＆quot; ...＆quot;）リテラルで非ASCIIバックスラッシュエスケープを使用しないこと

「ANSI」以外の場合エンコードはたまたまISO-8859-1であり、結果の char * および wchar_t * リテラルは同じ文字を表しません。

UTF-16文字列は、「ANSI」と同様に使用されます。文字列

そうではありません。 Unicodeには、ほとんどのレガシー文字エンコーディングには存在しないいくつかの概念が導入されています。代理。文字を組み合わせます。正規化。条件付きおよび言語依存の大文字小文字ルール。

そしておそらく最も重要なことは、UTF-16がディスクに保存されたりインターネット経由で送信されることはめったにないという事実です。UTF-8は外部表現に優先される傾向があります。

アプリケーションがインターネットを使用しないこと

（現在、これはお使いのソフトウェアの有効な仮定かもしれませんが...）

ウェブはUTF-8で実行されますおよび多数のまれなエンコーディング。 TCHAR の概念では、＆quot; ANSI＆quot;の2つのみが認識されます。（これは できません UTF-8 ）および＆quot; Unicode＆quot; （UTF-16）。 Windows API呼び出しをUnicode対応にするには便利かもしれませんが、Webアプリや電子メールアプリをUnicode対応にするには役に立たないでしょう。

Microsoft以外のライブラリを使用しないこと

TCHAR を使用する人はいません。 Poco は、 std :: string とUTF-8を使用します。 SQLite にはUTF-8およびUTF-16バージョンのAPIがありますが、 TCHAR はありません。 TCHAR は標準ライブラリにもないため、自分で定義したい場合を除き、 std :: tcout はありません。

TCHARの代わりに推奨するもの

「ANSI」を忘れてください有効なUTF-8ではないファイルを読み取る必要がある場合を除き、エンコーディングが存在します。 TCHAR も忘れてください。常に＆quot; W＆quot;を呼び出しますWindows API関数のバージョン。 #define _UNICODE は、誤って＆quot; A＆quot;を呼び出さないようにするためのものです。関数。

文字列には常にUTFエンコードを使用します。 char 文字列にはUTF-8、 wchar_t 文字列。プラットフォームの違いを避けるため、 typedef UTF16 および UTF32 の文字タイプ。



	
		
	
	
			まだ実際に使用されているかどうか疑問に思っているなら、はい、まだかなり使用されています。 TCHARと_T（＆quot;＆quot;）を使用している場合、誰もあなたのコードを面白く見ないでしょう。私が現在取り組んでいるプロジェクトは、ANSIからユニコードに変換しています-そして、私たちはポータブル（TCHAR）ルートに行きます。

  ただし...   

私の投票は、すべてのANSI / UNICODEポータブルマクロ（TCHAR、_T（＆quot;＆quot;）、およびすべての_tXXXXXX呼び出しなど）を忘れて、どこでもUnicodeを仮定することです。あなたがANSIバージョンを必要としないならば、私は本当に移植性のあるポイントを見ません。すべてのワイド文字関数とタイプを直接使用します。すべての文字列リテラルにLを前に付けます。
	


	
		
	
	
			  Windowsプログラミング入門記事 MSDNによると


  新しいアプリケーションは、常に（APIの）Unicodeバージョンを呼び出す必要があります。
  
    TEXT および TCHAR マクロは、すべてのアプリケーションがUnicodeを使用する必要があるため、今日ではあまり役に立ちません。


  wchar_t および L＆quot;＆quot; に固執します。
	


	
		
	
	
			別のアプローチを提案したいと思います（2つとも）。

要約すると、char *およびstd :: stringを使用し、UTF-8エンコードを想定し、API関数をラップする場合にのみUTF-16に変換します。

 Windowsプログラムでのこのアプローチの詳細と正当性は、 http://www.utf8everywhere.org で見つけることができます。
 >	


	
		
	
	
			一部のレガシープロジェクトでは、  TCHAR  /  WCHAR で十分な場合があります。しかし、新しいアプリケーションの場合、 NO と言います。

これらすべての TCHAR  /  WCHAR のものは、歴史的な理由から存在しています。  TCHAR は、ANSIテキストエンコーディング（MBCS）とUnicodeテキストエンコーディング（UTF-16）を切り替えるための、見た目が良い方法（変装）を提供します。過去には、人々は世界中のすべての言語の文字数を理解していませんでした。彼らは、すべての文字を表現するには2バイトで十分であり、したがって WCHAR を使用した固定長文字エンコード方式を持っていると想定していました。ただし、 1996 でUnicode 2.0がリリースされた後、これは当てはまりません。

つまり：
 CHAR  /  WCHAR  /  TCHAR のどちらを使用しても、プログラムのテキスト処理部は可変長を処理できる必要があります。国際化のための文字。

したがって、実際には、Windowsでのプログラミングでは、 CHAR  /  WCHAR  /  TCHAR から選択する以上のことを行う必要があります。


アプリケーションが小さく、テキスト処理を行わない場合（つまり、テキスト文字列を引数として渡すだけの場合）、 WCHAR を使い続けます。この方法はUnicodeをサポートしたWinAPIで作業する方が簡単なので、
それ以外の場合、UTF-8を内部エンコーディングとして使用し、テキストをchar文字列またはstd :: stringに保存することをお勧めします。そして、WinAPIを呼び出すときにそれらをUTF-16に変換します。  UTF-8 は現在、主要なエンコーディングであり、多くの便利なライブラリとツールがあります。 UTF-8文字列を処理します。


さらに詳しく読むには、この素晴らしいWebサイトをご覧ください。
 http://utf8everywhere.org/  
	


	
		
	
	
			はい、絶対に。少なくとも_Tマクロの場合。ただし、ワイド文字についてはよくわかりません。

 WinCEまたはその他の非標準のWindowsプラットフォームをより適切にサポートするためです。コードがNT上に残ることを100％確信している場合は、おそらく通常のC文字列宣言を使用できます。ただし、ライブラリを移植する必要がある場合に数千行のコードを調べてどこにでも追加するよりも、Windows以外のプラットフォームでそのマクロを#defineする方がはるかに簡単なので、より柔軟なアプローチに向かうのが最善ですWindows Mobileへ。
	


	
		
	
	
			 IMHO、コードにTCHARが含まれている場合、間違った抽象化レベルで作業しています。

文字列タイプ whatever を使用することは、テキスト処理を扱う際に最も便利です。これはユニコードをサポートするものになることを望みますが、それはあなた次第です。必要に応じて、OS APIの境界で変換を行います。

ファイルパスを扱うときは、文字列を使用する代わりに独自のカスタムタイプを作成します。これにより、OSに依存しないパスセパレーターが可能になり、手動の文字列の連結と分割よりもコードへのインターフェイスが簡単になり、さまざまなOS（ansi、ucs-2、utf-8など）に簡単に適応できるようになります。 。
	


	
		
	
	
			明示的なWCHAR以外の何かを使用する唯一の理由は、移植性と効率性です。

最終的な実行可能ファイルをできるだけ小さくしたい場合は、charを使用します。

 RAMの使用を気にせず、国際化を単純な翻訳と同じくらい簡単にしたい場合は、WCHARを使用します。 

コードを柔軟にする場合は、TCHARを使用します。

ラテン文字のみを使用する場合は、ASCII / MBCS文字列を使用して、ユーザーがそれほど多くのRAMを必要としないようにすることもできます。

「最初からi18n」である人のために、ソースコードスペースを節約し、すべてのUnicode関数を使用してください。
	


	
		
	
	
			古い質問に追加するだけです：

いいえ

 VS2010で新しいCLR C ++プロジェクトを開始します。 Microsoft自身は L＆quot; Hello World＆quot; を使用しています、「nuffが言いました。



	
		
			ライセンス： CC-BY-SA と 帰属
			所属していません StackOverflow