2009-09-04 20 views
0

私は、削除したいファイルを指定するconst char *を持っています。 RF :: Deleteを使用して、TDesC16 を入力引数とするファイルを削除したいとします。簡単const char * to TDesC16

RFs fs; 
TUint err; 

const char *pFileToDelete = "c:\\myfile.txt"; 

if (fs.Connect() == KErrNone) 
{ 
    err = fs.Delete(pFileToDelete); 
    fs.Close(); 
} 

感謝を変換する方法を誰もが知っている、

答えて

-1

は、文字エンコーディングは、文字列pFileToDeleteのあるものを依存します。あなたがわからない場合、あなたはそれを知る必要があります(または自分で定義する必要があります)。 TFileNameはかなり大きなクラス(512バイトほど、IIRC)であるので、あなたが1つを置くことについて少し警戒になりたいので、その後

TPtr8 wrapper(pFileToDelete, User::StringLength(pFileToDelete)); 
{ 
    TFileName name; 
    name.Copy(wrapper); 
    error = fs.Delete(name); 
} 

中括弧だけであり、それは7ビットのASCIIだと仮定すると、

可能なかぎり最小限の範囲を与えてください。あなたは代わりにヒープ割り当てすることができます。

UTF-8の場合は、ConvertToUnicodeFromUTF8のクラスCnvUtfConverterをチェックしてください。

可能であれば、ファイル名を最初に記述子リテラルとして定義する方が良いでしょう。

+0

「ラッパー」の記述子をすでに持っているので、TFileNameは必要ありません – Dynite

+0

ユニコードの構築を前提にしていましたか?そうでなければ、「RFs :: Delete」はTDesC16を取るのですか? 。つまり、TDesCではなく8ビットの記述子であるため、ラッパーはDeleteに渡すことはできません。 –

0

これらの線に沿って何か:

_LIT(KMyFilename,"c:\\myfile.txt"); 
TPtrC filename(KMyFilename); 

RFs fs; 
TInt err =fs.Connect(); 
User::LeaveIfError(err); 
err = fs.Delete(filename); 
... 

しかしhttp://descriptors.blogspot.com

+0

質問には答えません。質問者がディスクリプタのポイントを完全に見逃していない場合、真にCスタイルの文字列を変換する必要があり、実際にディスクリプタリテラルを使用することはできません。 –

+1

... OP *が尋ねた質問に対して間違った答えだと言っているわけではありません。おそらくファイル名は記述子リテラルにすることができます。 –

2
RFs fs; 
TUint err; 
const char *pFileToDelete = "c:\\myfile.txt"; 
TPtrC8 filename8 = (const TText8*)pFileToDelete; 
//ok, so we could use a TBuf or a TFileName, but we'd need to now 
//the size of the TBuf at compile time and 
//TFileNames should never be allocated on the stack due to their size. 
//Easier to use a HBufC. 
HBufC* filename = HBufC::NewLC(filename8.Length()); 
//Copy will only do the right thing if the text in pFiletoDelete is 7-bit ascii 
filename->Des().Copy(filename8); 
if (fs.Connect() == KErrNone){   
    err = fs.Delete(*filename); 
    fs.Close(); 
} 
CleanupStack::PopAndDestroy(filename); 

をチェックし、それはSOMのTLCを必要とするかもしれないので、私は実際にこのコードをコンパイルしていません。

+0

"TFileNamesはスタックに決して割り当てられてはいけません"という疑問に対する正解ではありません。 Symbianはそれを言うかもしれませんが、彼らはワスです。私は前にそれをやった。誰も死んでおらず、私のスレッドに16kのスタックを与えても、私が目標としていたハンドセットの32MBのRAMにはあまり感謝していませんでした.-あなたはHBufCのコードを書くのに気を使うことができたからです。私はできませんでした。 –

+0

スタック上の単一のTFileNameは問題ありません。問題は、プログラム内の呼び出しパスにTFileNamesやその他の大きなスタックオブジェクトが多すぎることを保証する必要があることです。 – Ola