2014-07-10 22 views
5

ASCII karakterlerini EBCDIC'ye eşleme ve görüntülemeye yarayan aşağıdaki kod bloğum var (benim tarafımdan yazılmadı).C Code Aramada C++ 'ya Farklı Olarak Çalışıyor

// Variables. 
CodeHeader* tchpLoc = {}; 
... 
memset(tchpLoc->m_ucpEBCDCMap, 0xff, 256); 
for (i = 0; i < 256; i++) { 
    if (tchpLoc->m_ucpASCIIMap[i] != 0xff) { 
     ucTmp2 = i; 
     asc2ebn(&ucTmp1, &ucTmp2, 1); 
     tchpLoc->m_ucpEBCDCMap[ucTmp1] = tchpLoc->m_ucpASCIIMap[i]; 
    } 
} 

CodeHeader tanım

typedef struct { 
    ... 
    UCHAR* m_ucpASCIIMap; 
    UCHAR* m_ucpEBCDCMap; 
} CodeHeader; 

ve bana vererek sorunları gibi görünüyor yöntemdir

void asc2ebn(char* szTo, char* szFrom, int nChrs) 
{ 
    while (nChrs--) 
     *szTo++ = ucpAtoe[(*szFrom++) & 0xff]; 
} 

[Not, unsigned char dizisi ucpAtoe[256] sonunda kopyalanır olduğu referans için soru].

Şimdi eski bir C uygulaması ve C++ 11 dönüşümüm yan yana çalışıyor, iki kod çok büyük bir .bin dosyası yazıyor ve yukarıdaki kodla izlediğim küçük bir tutarsızlık var. Ne hem kodları oluyor blok

... 
    if (tchpLoc->m_ucpASCIIMap[i] != 0xff) { 
     ucTmp2 = i; 
     asc2ebn(&ucTmp1, &ucTmp2, 1); 
     tchpLoc->m_ucpEBCDCMap[ucTmp1] = tchpLoc->m_ucpASCIIMap[i]; 
    } 

i = 32 için girilen alır ve asc2ebn yöntem 64 olarak ucTmp1 veya C ve C ikisi için '@'döndürür olmasıdır ++ harika varyantları. Sonraki giriş Bu değer için asc2ebn yöntem 240 veya 'ð' ve C++ kodu olarak ucTmp1-16 veya 'ð' olarak ucTmp1 geri döner, i = 48 içindir. Benim sorum, bu arama/dönüşüm neden tam olarak aynı giriş ve arama dizisi (kopyalanan) için farklı sonuçlar üretiyor?

Bu durumda, eski C kodu doğru olarak alındı, bu yüzden C++ bu arama/dönüşüm için aynı sonucu üretmesini istiyorum. Zaman ayırdığın için teşekkürler. Her iki C ve C++ olarak

static UCHAR ucpAtoe[256] = { 
    '\x00','\x01','\x02','\x03','\x37','\x2d','\x2e','\x2f',/*00-07*/ 
    '\x16','\x05','\x25','\x0b','\x0c','\x0d','\x0e','\x0f',/*08-0f*/ 
    '\x10','\x11','\x12','\xff','\x3c','\x3d','\x32','\xff',/*10-17*/ 
    '\x18','\x19','\x3f','\x27','\x22','\x1d','\x35','\x1f',/*18-1f*/ 
    '\x40','\x5a','\x7f','\x7b','\x5b','\x6c','\x50','\xca',/*20-27*/ 
    '\x4d','\x5d','\x5c','\x4e','\x6b','\x60','\x4b','\x61',/*28-2f*/ 
    '\xf0','\xf1','\xf2','\xf3','\xf4','\xf5','\xf6','\xf7',/*30-37*/ 
    '\xf8','\xf9','\x7a','\x5e','\x4c','\x7e','\x6e','\x6f',/*38-3f*/ 
    '\x7c','\xc1','\xc2','\xc3','\xc4','\xc5','\xc6','\xc7',/*40-47*/ 
    '\xc8','\xc9','\xd1','\xd2','\xd3','\xd4','\xd5','\xd6',/*48-4f*/ 
    '\xd7','\xd8','\xd9','\xe2','\xe3','\xe4','\xe5','\xe6',/*50-57*/ 
    '\xe7','\xe8','\xe9','\xad','\xe0','\xbd','\xff','\x6d',/*58-5f*/ 
    '\x79','\x81','\x82','\x83','\x84','\x85','\x86','\x87',/*60-67*/ 
    '\x88','\x89','\x91','\x92','\x93','\x94','\x95','\x96',/*68-6f*/ 
    '\x97','\x98','\x99','\xa2','\xa3','\xa4','\xa5','\xa6',/*70-77*/ 
    '\xa7','\xa8','\xa9','\xc0','\x6a','\xd0','\xa1','\xff',/*78-7f*/ 
    '\xff','\xff','\xff','\xff','\xff','\xff','\xff','\xff',/*80-87*/ 
    '\xff','\xff','\xff','\xff','\xff','\xff','\xff','\xff',/*88-8f*/ 
    '\xff','\xff','\xff','\xff','\xff','\xff','\xff','\xff',/*90-97*/ 
    '\xff','\xff','\xff','\x4a','\xff','\xff','\xff','\xff',/*98-9f*/ 
    '\xff','\xff','\xff','\xff','\xff','\xff','\xff','\xff',/*a0-a7*/ 
    '\xff','\xff','\xff','\xff','\xff','\xff','\xff','\xff',/*a8-af*/ 
    '\xff','\xff','\xff','\x4f','\xff','\xff','\xff','\xff',/*b0-b7*/ 
    '\xff','\xff','\xff','\xff','\xff','\xff','\xff','\xff',/*b8-bf*/ 
    '\xff','\xff','\xff','\xff','\xff','\x8f','\xff','\xff',/*c0-c7*/ 
    '\xff','\xff','\xff','\xff','\xff','\xff','\xff','\xff',/*c8-cf*/ 
    '\xff','\xff','\xff','\xff','\xff','\xff','\xff','\xff',/*d0-d7*/ 
    '\xff','\xff','\xff','\xff','\xff','\xff','\xff','\xff',/*d8-df*/ 
    '\xff','\xff','\xff','\xff','\xff','\xff','\xff','\xff',/*e0-e7*/ 
    '\xff','\xff','\xff','\xff','\xff','\xff','\xff','\xff',/*e8-ef*/ 
    '\xff','\xff','\xff','\x8c','\xff','\xff','\xff','\xff',/*f0-f7*/ 
    '\xff','\xff','\xff','\xff','\xff','\xff','\xff','\xff' }; 
+9

'240' ve' -16' 'char' için aynı değerlerdir, değil mi? –

+3

"char" yerine "imzasız char" kullanarak açık bir şekilde denediniz mi ... çünkü "char" işareti imzasız veya imzalı olabilir. –

+0

'asc2ebn()' hiç bir şey döndürmüyor - void asc2ebn (...) 'olarak bildirildi. – twalberg

cevap

2


, standart bir signed veya unsigned türü olduğu char gerektirmez. C++ derleyicisi signed char olarak belirlenirken, bu uygulama tanımlanmış ve görünüşe göre, C derleyici char unsigned char olmak karar verdi.

GCC için, bayrağı char yapmak için olması -funsigned-char'dur. MSVC için, /J.

+0

Zaman ayırdığınız için teşekkür ederiz. Fakat bu, tüm “karakter” değerlerinin “imzasız” olmaya zorlanmayacak mıdır? Eğer öyleyse, bu ben 'char' değerlerinde kasten kullanılır kodun başka bir yerde istediğim gibi değil ... C++ sürümü için bu bayrak (' \ J') kullanmayı denedim ve bu dönüştürme yardımcı olmadı. 'Asc2ebn' dönüştürme yöntemini yeniden yazabilirim, belki de onu biçimlendiririm ... – MoonKnight

+0

@Killercam: Hiçbir şey şablonunu kullanmanıza gerek yok, sadece 'szTo' ve' szFrom' seçeneklerine 'imzasız char *' ya erişmeniz veya 'asc2ebn’nizi yapmanıza gerek yoktur. 'İmzasız char * işlevini kabul eder. İşte bu yüzden neden üç farklı karakter vardır: 'char', 'imzalı char', 'imzasız char'. – mafso

+0

Bu, sorunu çözmedi, ancak doğrudan doğru yola koydu, teşekkürler. Sonunda, hem imzasız char * hem de char * 'alma yöntemini aşırı yükledim. Bunun nedeni kodun başka bir yerinde, 'char *' kabul edildi ve negatif indeksler kabul edildi (!?) - Buna bakmak zorunda kalacağım. – MoonKnight

İlgili konular