[C/C++] Omzetting C->C++: error C2440 bij casten

[lzandman]

Ik ben al een tijdje bezig met het omzetten van een stukje (werkende) C-code naar een C++ class (Microsoft Visual C++ 6). Maar ik krijg nu telkens een irritante compileerfout:

code:

error C2440: '=' : cannot convert from 'char *' to 'unsigned char *'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

Deze fout komt waarschijnlijk door het feit dat de oorspronkelijke broncode in C is geschreven en dat je in C++ op een andere manier moet casten. Maar helaas heb ik niet zoveel verstand van C++ om dit op te lossen. Hier wat code uit het project:

code:

// Dit zijn de variabelen
HGLOBAL hinputBuf ;
unsigned char * InternalDecoderInput ;

// En dan gaat het op de volgende regel mis
InternalDecoderInput = (char *)GlobalLock(hinputBuf);

Weet iemand van jullie hoe je dit wel door de compiler krijgt? De compiler geeft wel aanwijzingen, doordat er staat "Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast". Weet iemand hoe je op die manieren moet casten?

[Verwijderd]

Iets in de trend van (unsigned char*) ?

[MSalters]

De foutmelding zegt precies wat er nodig is, reinterpret-cast<unsigned char*>( )

[Verwijderd]

.

[ Voor 100% gewijzigd door Verwijderd op 31-10-2023 21:35 ]

[lzandman]

Ik heb het al werkend Het was heel simpel. Inderdaad gewoon het woordje 'unsigned' ervoor... Raar dat gewoon C die code wel slikte, maar C++ niet. Nou ja, het werkt nu...

Verwijderd schreef op 05 november 2002 @ 10:52:
Je hebt informatica gestudeerd en je werkt als software engineer?

Ja, so what Of bedoel je dat deze vraag te simpel was voor iemand die informatica heeft gestudeerd? Nou, ja. Ik heb gewoon nog nooit iets in C++ geprogd. Dat kregen we niet op school (alleen JAVA, Haskell, Pascal en C) en voor mijn werk heb ik het ook nog nooit nodig gehad. Natuurlijk, ik lees wel regelmatig C++ broncode, voornamelijk als ik iets uit de Microsoft SDK's nodig heb. Maar dat vertaal ik dan naar Delphi en gebruik het zo.

Ik ben een echte Delphi-fanaat. Maar het is natuurlijk wel zo dat het verrekte handig is om wat van C++ te snappen. Helemaal als je bijv. die SDK's van Microsoft moet doornemen. Toch maar eens een goed boek over Visual C++ kopen

[Verwijderd]

Hmm, ik ben misschien gek, maar wat de hell moet ik me voorstellen bij een unsigned char* ? Bestaan er signed char pointers dan? Een negatief geheugenadres of zo?
Ik zou proberen om die InternalDecoderInput als char te definieren, maar misschien mis ik iets hoor.

[Verwijderd]

Hmm, okee, ik ben gek, er bestaat wel degelijk een signed char pointer. Ik snap niet wat je met een negatieve char waarde zou willen doen, maar het bestaat.

[lzandman]

Verwijderd schreef op 05 november 2002 @ 11:24:
Hmm, okee, ik ben gek, er bestaat wel degelijk een signed char pointer. Ik snap niet wat je met een negatieve char waarde zou willen doen, maar het bestaat.

Nou, in dit geval is het gewoon de broncode (in C) van een H.263 codec (videocompressie) die we gekocht hebben. De codec is zo geprogrammeerd dat er slechts een instantie tegelijkertijd in je programma kan worden geladen (doordat 'ie gebruik maakt van globale variabelen voor z'n interne administratie enz.). Ik moet echter meerdere videostreams tegelijkertijd decoderen, dus heb ik meerdere instanties van die codec nodig. Daarom heb ik het geheel omgebouwd tot een C++ class. Nu kan ik meerdere instanties van de codec aanmaken en gebruiken.

De broncode is dus gewoon gekocht en waarom die oorspronkelijke maker er unsigned char pointers van gemaakt heeft weet ik ook niet. Sterker nog, dat interesseert me niet eens. Het moet gewoon werken. En het lijkt erop dat het inderdaad werkt

Misschien zijn die types zo gedefinieerd, zodat ze gemakkelijker gebruikt kunnen worden vanuit een andere programmeeromgeving, zoals bijv. Delphi of VB. Er zaten nl. demoprogramma's bij die geschreven waren in Delphi. De codec wordt overigens ook door mij gebruikt in een Delphi programma.

[curry684]

Verwijderd schreef op 05 november 2002 @ 11:24:
Hmm, okee, ik ben gek, er bestaat wel degelijk een signed char pointer. Ik snap niet wat je met een negatieve char waarde zou willen doen, maar het bestaat.

Het datatype 'char' heeft geen enkele relatie tot een 'character' maar is gewoon de C/C++ term om een 'byte' dwz 8 bits te beschrijven. En die kan zo signed zijn als je wil, sterker nog: vrijwel alle standard libs zijn gebaseerd op 'char*' voor strings en daar default nog steeds 'signed' is zijn dat dus allemaal 'signed char*'

[curry684]

MSalters schreef op 05 november 2002 @ 10:47:
De foutmelding zegt precies wat er nodig is, reinterpret-cast<unsigned char*>( )

Mmmmm ik ben zelf niet zo'n fan van reinterpret_cast en prefereer voor dit soort dingen eigenlijk de goeie oude C-style cast die ook door de foutmelding gesuggereerd wordt.

[curry684]

lzandman schreef op 05 november 2002 @ 11:34:
De broncode is dus gewoon gekocht en waarom die oorspronkelijke maker er unsigned char pointers van gemaakt heeft weet ik ook niet.

Geheugenblokken worden 9 van de 10 keer als unsigned char-blokken beschouwd omdat het de meest logische manier is om met bytes te werken. Met signed kun je bijv. geemmer krijgen met sign-propagation: dwz je kopieert een byte 0xF0 in een integer voor processing en dan staat er in die int plotseling -16 (oftewel 0xFFFFFFF0).

[MSalters]

Overigens is GlobalLock/GlobalAlloc/GlobalFree verouderd (zie MSDN ); in C++ zou je std::vector<unsigned char> gebruiken en die hele Win32 api vergeten.

[lzandman]

MSalters schreef op 05 november 2002 @ 11:52:
Overigens is GlobalLock/GlobalAlloc/GlobalFree verouderd (zie MSDN ); in C++ zou je std::vector<unsigned char> gebruiken en die hele Win32 api vergeten.

Zover ben ik nog niet met C++ Dat moet ik dus nog allemaal leren. Het is in vergelijking met Delphi wel veel werk om iets simpels in elkaar te draaien zeg... Maar ja, Delphi heeft ook zo z'n beperkingen. Ik heb er nu weer een uitdaging bij...

[Verwijderd]

curry684 schreef op 05 november 2002 @ 11:38:
Het datatype 'char' heeft geen enkele relatie tot een 'character' maar is gewoon de C/C++ term om een 'byte' dwz 8 bits te beschrijven.

Een char is de kleinst adresseerbare geheugeneenheid in C en C++. Een char bestaat uit CHAR_BIT bits (#include <climits>), en dat is iets anders dan 8. Aannemen dat een char uit 8 bits bestaat is dus pertinent fout.

curry684 schreef op 05 november 2002 @ 11:42:
Mmmmm ik ben zelf niet zo'n fan van reinterpret_cast en prefereer voor dit soort dingen eigenlijk de goeie oude C-style cast die ook door de foutmelding gesuggereerd wordt.

Waarom denk je dat er newstyle casts zijn? Het is geen kwestie van voorkeur, maar een kwestie van optimalisatie. De meeste C++ compilers kunnen een oldstyle cast niet zo goed optimaliseren als een newstyle cast, want aan een oldstyle cast is niet zichtbaar of hij dynamisch (runtime) dan wel statisch (compiletime) is.

[lzandman]

Ben alweer iets anders tegengekomen. De compiler slikt het volgende niet:

code:

static unsigned int msk[33] =
{
  0x00000000,0x00000001,0x00000003,0x00000007,
  0x0000000f,0x0000001f,0x0000003f,0x0000007f,
  0x000000ff,0x000001ff,0x000003ff,0x000007ff,
  0x00000fff,0x00001fff,0x00003fff,0x00007fff,
  0x0000ffff,0x0001ffff,0x0003ffff,0x0007ffff,
  0x000fffff,0x001fffff,0x003fffff,0x007fffff,
  0x00ffffff,0x01ffffff,0x03ffffff,0x07ffffff,
  0x0fffffff,0x1fffffff,0x3fffffff,0x7fffffff,
  0xffffffff
};

Kun je arrays in C++ niet meer zo initialiseren? Moet ik dan gewoon het volgende doen (veel werk...) of kan het nog anders?

code:

static unsigned int msk[33];

msk[0] = 0x00000000;
  .
  .
  .
msk[32] = 0xffffffff;

[curry684]

Verwijderd schreef op 05 november 2002 @ 13:50:
Een char is de kleinst adresseerbare geheugeneenheid in C en C++. Een char bestaat uit CHAR_BIT bits (#include <climits>), en dat is iets anders dan 8. Aannemen dat een char uit 8 bits bestaat is dus pertinent fout.

Toegegeven, echter topicstarter is in Visual C++ aan het programmeren, dus voor Win32 op x86, dus 8 bits per byte.

Waarom denk je dat er newstyle casts zijn? Het is geen kwestie van voorkeur, maar een kwestie van optimalisatie. De meeste C++ compilers kunnen een oldstyle cast niet zo goed optimaliseren als een newstyle cast, want aan een oldstyle cast is niet zichtbaar of hij dynamisch (runtime) dan wel statisch (compiletime) is.

Bliep dit is onzin. Een old-style cast hoeft de compiler niet aan te kunnen zien of het een dynamische cast is want al zou het wel zo zijn dan doet ie het toch niet. Als een compiler daar langzamere code door maakt is het een waardeloze compiler. Alles wat de C-style cast speciaal kan doen is voor zover ik me voor kan stellen op compile-time af te leiden.

Ik citeer:

There are several casting operators specific to the C++ language. These operators are intended to remove some of the ambiguity and danger inherent in old style C language casts. Use const_cast and reinterpret_cast as a last resort, since these operators present the same dangers as old style casts. However, they are still necessary in order to completely replace old style casts.

Ergo de reinterpret_cast is alleen maar een moderne versie van de C-style cast om consequent te blijven in de naming style van C++ casts.

Ik heb het even uitgeprobeerd in VC.net:

C++:

char*           l_Test1 = "Test";
00411E0E  mov         dword ptr [l_Test1],offset string "Test" (424090h) 
unsigned char*  l_Test2 = reinterpret_cast<unsigned char*>(l_Test1);
00411E15  mov         eax,dword ptr [l_Test1] 
00411E18  mov         dword ptr [l_Test2],eax 
unsigned char*  l_Test3 = (unsigned char*)l_Test1;
00411E1B  mov         eax,dword ptr [l_Test1] 
00411E1E  mov         dword ptr [l_Test3],eax 

Toon mij de verschillen

[MSalters]

Verwijderd schreef op 05 november 2002 @ 13:50:
Waarom denk je dat er newstyle casts zijn? Het is geen kwestie van voorkeur, maar een kwestie van optimalisatie. De meeste C++ compilers kunnen een oldstyle cast niet zo goed optimaliseren als een newstyle cast, want aan een oldstyle cast is niet zichtbaar of hij dynamisch (runtime) dan wel statisch (compiletime) is.

Sorry, onzin. Elke old-style cast mapt op een of andere new-style cast, maar dat hangt alleen af van de types. De compiler weet de types, en vervangt op basis daarvan de old-style cast door een new-style cast. Die wordt vervolgens identiek gecompileerd.

De echte reden is dat ze leesbaarder zijn, en dat je ze met grep/Search kunt vinden.

[curry684]

lzandman schreef op 05 november 2002 @ 14:28:
Ben alweer iets anders tegengekomen. De compiler slikt het volgende niet:

code:

static unsigned int msk[33] =
{
  0x00000000,0x00000001,0x00000003,0x00000007,
  0x0000000f,0x0000001f,0x0000003f,0x0000007f,
  0x000000ff,0x000001ff,0x000003ff,0x000007ff,
  0x00000fff,0x00001fff,0x00003fff,0x00007fff,
  0x0000ffff,0x0001ffff,0x0003ffff,0x0007ffff,
  0x000fffff,0x001fffff,0x003fffff,0x007fffff,
  0x00ffffff,0x01ffffff,0x03ffffff,0x07ffffff,
  0x0fffffff,0x1fffffff,0x3fffffff,0x7fffffff,
  0xffffffff
};

Mijn VC.net slikt dit gewoon, zoals het hoort... wat voor foutmelding krijg je?

[MSalters]

lzandman schreef op 05 november 2002 @ 14:28:
Ben alweer iets anders tegengekomen. De compiler slikt het volgende niet:

code:

static unsigned int msk[33] =
{
  0x00000000,0x00000001,0x00000003,0x00000007,
 ( lijst )
};

Gebruik const ipv static.

[curry684]

MSalters schreef op 05 november 2002 @ 14:36:
Gebruik const ipv static.

Correct in deze situatie, maar static zou ook gewoon moeten werken:

Objects and variables defined outside all blocks have static lifetime and external linkage by default. A global object or variable that is explicitly declared as static has internal linkage.

[lzandman]

MSalters schreef op 05 november 2002 @ 14:36:
[...]

Gebruik const ipv static.

Werkt ook niet. Ik heb nu dit gedaan en dat werkt niet:

code:

class CH263Decoder  
{
private:
    const unsigned int msk[33] =
    {
      0x00000000,0x00000001,0x00000003,0x00000007,
      0x0000000f,0x0000001f,0x0000003f,0x0000007f,
      0x000000ff,0x000001ff,0x000003ff,0x000007ff,
      0x00000fff,0x00001fff,0x00003fff,0x00007fff,
      0x0000ffff,0x0001ffff,0x0003ffff,0x0007ffff,
      0x000fffff,0x001fffff,0x003fffff,0x007fffff,
      0x00ffffff,0x01ffffff,0x03ffffff,0x07ffffff,
      0x0fffffff,0x1fffffff,0x3fffffff,0x7fffffff,
      0xffffffff
    };
// en hier de rest van de class

Ik krijg dan een syntax error (error C2059: syntax error : '{') op de eerste regel met een accolade.

Moet ik die array niet pas initialiseren in de constructor van de class? Dus in de class definitie:

code:

const unsigned int msk[33];

En dan in de implementatie van de constructor zoiets:

code:

    msk =
    {
      0x00000000,0x00000001,0x00000003,0x00000007,
      0x0000000f,0x0000001f,0x0000003f,0x0000007f,
      0x000000ff,0x000001ff,0x000003ff,0x000007ff,
      0x00000fff,0x00001fff,0x00003fff,0x00007fff,
      0x0000ffff,0x0001ffff,0x0003ffff,0x0007ffff,
      0x000fffff,0x001fffff,0x003fffff,0x007fffff,
      0x00ffffff,0x01ffffff,0x03ffffff,0x07ffffff,
      0x0fffffff,0x1fffffff,0x3fffffff,0x7fffffff,
      0xffffffff
    };

[Verwijderd]

curry684 schreef op 05 november 2002 @ 14:30:
There are several casting operators specific to the C++ language. These operators are intended to remove some of the ambiguity and danger inherent in old style C language casts. Use const_cast and reinterpret_cast as a last resort, since these operators present the same dangers as old style casts. However, they are still necessary in order to completely replace old style casts.

Lezen roelt
Een compiler kan niet in alle gevallen uitmaken of een oldstyle cast moet worden omgezet naar een dynamic_cast of een reinterpret_cast. De compiler kan dan niet anders dan een langzame dynamic_cast toepassen, terwijl een reinterpret_cast genoeg kan zijn.

[.oisyn]

Verwijderd schreef op 05 november 2002 @ 14:48:
[...]

Lezen roelt
Een compiler kan niet in alle gevallen uitmaken of een oldstyle cast moet worden omgezet naar een dynamic_cast of een reinterpret_cast. De compiler kan dan niet anders dan een langzame dynamic_cast toepassen, terwijl een reinterpret_cast genoeg kan zijn.

Een dynamic cast werkt alleen met complete class types... niet met primitives dus. Een compiler kan zo'n cast dus helemaal niet uitvoeren mbv dynamic_cast

.edit: Zou trouwens ook vrij nutteloos zijn, omdat zo'n dynamic_cast altijd NULL op zou leveren... een primitive heeft tenslotte geen enkele relatie met een andere primitive

[Verwijderd]

.oisyn schreef op 05 november 2002 @ 14:57:
Een dynamic cast werkt alleen met complete class types... niet met primitives dus. Een compiler kan zo'n cast dus helemaal niet uitvoeren mbv dynamic_cast

Exact. Maar met een class type zijn zowel dynamic_casts als reinterpret_casts mogelijk. Die reinterpret_casts zijn gevaarlijk (als de sizeof() door de klassenhierarchie niet gelijk blijft of virtuele methodes gebruikt worden), maar een stuk sneller dan een dynamic_cast. Je kunt dus beter optimaliseren met newstyle casts, omdat ze de ambiguiteit tussen dynamic_casts en reinterpret_casts wegnemen.

[.oisyn]

We hadden het sowieso over een cast van char * naar unsigned char *, dus je verhaal is een beetje nutteloos, maar goed

Een compiler zal een old-style cast nooit vertalen naar een dynamic_cast. Ten eerste is dynamic_cast alleen nuttig als je compilet met RTTI, dat meestal mbv een compileroptie aan- of uitgezet kan worden. Een old-style cast van gerelateerde typen zal ie doen mbv static_cast, en die van 2 ongerelateerde typen met reinterpret_cast. De static_cast is gewoon wat pointer arithmetic wat dus vrijwel net zo snel is als de reinterpret_cast. Een old-style cast zal dus ook nooit NULL opleveren (tenzij dat natuurlijk gewoon de uitkomst is van de berekening )

Een dynamic_cast werkt trouwens ook niet op class typen die niet polymorphic zijn (dus geen virtual functions hebben), en een static_cast niet met typen die niet gerelateerd zijn

[curry684]

lzandman schreef op 05 november 2002 @ 14:47:
Werkt ook niet. Ik heb nu dit gedaan en dat werkt niet:
Ik krijg dan een syntax error (error C2059: syntax error : '{') op de eerste regel met een accolade.

Aha nu wordt het verhaal heel anders... je impliceerde eerst dat je een global array wilde maken.

Moet ik die array niet pas initialiseren in de constructor van de class? Dus in de class definitie:

Dat kan, maar eigenlijk zoek je deze constructie:

C++:

// Header
class MyClass
{
private:
  static const unsigned int     msk[33];
};

// CPP
const unsigned int MyClass::msk[] =
  {
    0x00000000,0x00000001,0x00000003,0x00000007,
    0x0000000f,0x0000001f,0x0000003f,0x0000007f,
    0x000000ff,0x000001ff,0x000003ff,0x000007ff,
    0x00000fff,0x00001fff,0x00003fff,0x00007fff,
    0x0000ffff,0x0001ffff,0x0003ffff,0x0007ffff,
    0x000fffff,0x001fffff,0x003fffff,0x007fffff,
    0x00ffffff,0x01ffffff,0x03ffffff,0x07ffffff,
    0x0fffffff,0x1fffffff,0x3fffffff,0x7fffffff,
    0xffffffff
  };

De member array is const en static nu, en in de CPP vul je de array 1 keer in in de global ruimte, let op de MyClass:: scope identifier.

[MSalters]

Verwijderd schreef op 05 november 2002 @ 14:48:
[...]

Lezen roelt
Een compiler kan niet in alle gevallen uitmaken of een oldstyle cast moet worden omgezet naar een dynamic_cast of een reinterpret_cast. De compiler kan dan niet anders dan een langzame dynamic_cast toepassen, terwijl een reinterpret_cast genoeg kan zijn.

Schrijven roelt nog meer

Ik heb aan de cast-paragraaf van de standaard lopen schrijven, dus trust me, of lees dit:

[expr.cast] 5.4 Explicit type conversion (cast notation) /5 :
The conversions performed by
— a const_cast (5.2.11),
— a static_cast (5.2.9),
— a static_cast followed by a const_cast,
— a reinterpret_cast (5.2.10), or
— a reinterpret_cast followed by a const_cast,
can be performed using the cast notation of explicit type conversion. The same semantic restrictions and behaviors apply. If a conversion can be interpreted in more than one of the ways listed above, the interpretation that appears first in the list is used, even if a cast resulting from that interpretation is ill-formed.

De compiler heeft dus een simpele regel om te kiezen als er meer mogelijkheden zijn, en een dynamic_cast staat niet eens op de lijst.

[lzandman]

curry684 schreef op 05 november 2002 @ 15:23:
[...]

Dat kan, maar eigenlijk zoek je deze constructie:

Mijn dank is groot Alleen jammer dat ik net dit allemaal had ingetypt:

C++:

    msk[0]  = 0x00000000;
    msk[1]  = 0x00000001;
    msk[2]  = 0x00000003;
    msk[3]  = 0x00000007;
    msk[4]  = 0x0000000f;
    msk[5]  = 0x0000001f;
    msk[6]  = 0x0000003f;
    msk[7]  = 0x0000007f;
    msk[8]  = 0x000000ff;
    msk[9]  = 0x000001ff;
    msk[10] = 0x000003ff;

    msk[11] = 0x000007ff;
    msk[12] = 0x00000fff;
    msk[13] = 0x00001fff;
    msk[14] = 0x00003fff;
    msk[15] = 0x00007fff;
    msk[16] = 0x0000ffff;
    msk[17] = 0x0001ffff;
    msk[18] = 0x0003ffff;
    msk[19] = 0x0007ffff;
    msk[20] = 0x000fffff;

    msk[21] = 0x001fffff;
    msk[22] = 0x003fffff;
    msk[23] = 0x007fffff;
    msk[24] = 0x00ffffff;
    msk[25] = 0x01ffffff;
    msk[26] = 0x03ffffff;
    msk[27] = 0x07ffffff;
    msk[28] = 0x0fffffff;
    msk[29] = 0x1fffffff;
    msk[30] = 0x3fffffff;
    msk[31] = 0x7fffffff;
    msk[32] = 0xffffffff;

[curry684]

Hehe lullig

[lzandman]

OK, weer een probleempje.

Ik heb nu het volgende data type:

code:

typedef struct {
  int val, run, sign;
} RunCoef;

Ik heb een method in mijn class die als return-value zo'n struct terug moet geven:

code:

RunCoef CH263Decoder::Decode_Escape_Char(int intra, int *last)

Alleen de compiler klaagt dat 'ie dat type niet kent. Dat kan wel kloppen, want ik weet nl. niet hoe ik in C++ zo'n type toevoeg aan een class. Ik kan bovenstaande code wel toevoegen aan het CPP-bestand, maar dan is het type nog niet bekend binnen de class. Moet ik 'm misschien ook aan de class-definitie toevoegen? En hoe moet dit dan?

[lzandman]

lzandman schreef op 06 november 2002 @ 10:55:
OK, weer een probleempje.

Mmmm... Volgens mij heb ik het al. Ik heb die typedef-instructie gewoon in de headerfile boven de class-definitie gezet. En nu krijg ik geen foutmelding meer Maar of die de juiste manier is?

[lzandman]

OK, nog een vraagje...

Ik krijg een foutmelding op deze regel:

code:

  x4 = (x8+(W1-W7)*x4)>>3;

De definities van de variabelen zijn:

code:

#define W1 -1609L
#define W7 1.4142143562 

int x4, x8;

De foutmelding is: "error C2296: '>>' : illegal, left operand has type 'double'". Ik snap deze foutmelding wel, maar waarom krijg ik deze foutmelding wel onder C++ en niet onder C? En hoe converteer ik het type van die expressie van double naar int (want dat is toch de bedoeling)? Ik kan natuurlijk casten:

code:

  x4 = (int)(x8+(W1-W7)*x4)>>3;

maar ik weet niet of dat wel veilig is...

[curry684]

lzandman schreef op 06 november 2002 @ 10:58:
[...]
Mmmm... Volgens mij heb ik het al. Ik heb die typedef-instructie gewoon in de headerfile boven de class-definitie gezet. En nu krijg ik geen foutmelding meer Maar of die de juiste manier is?

C++ werkt op volgorde van declaratie ja, dus dat is correct.

Stelregel voor headers: eerst de types, en daarna de classes.

[curry684]

lzandman schreef op 06 november 2002 @ 12:03:
De foutmelding is: "error C2296: '>>' : illegal, left operand has type 'double'". Ik snap deze foutmelding wel, maar waarom krijg ik deze foutmelding wel onder C++ en niet onder C?

Omdat C++ typesafety propageert en C niet

En hoe converteer ik het type van die expressie van double naar int (want dat is toch de bedoeling)? Ik kan natuurlijk casten:

code:

  x4 = (int)(x8+(W1-W7)*x4)>>3;

maar ik weet niet of dat wel veilig is...

Dat kan en dat is veilig. Ik zou echter voor de charmes gaan en even de floor en round functies opzoeken.

[lzandman]

MSalters schreef op 05 november 2002 @ 11:52:
Overigens is GlobalLock/GlobalAlloc/GlobalFree verouderd (zie MSDN ); in C++ zou je std::vector<unsigned char> gebruiken en die hele Win32 api vergeten.

Als ik kijk op MSDN bij GlobalLock dan raden ze me aan HeapAlloc() enz. te gebruiken. Weten jullie hoe dat moet?

Die std::vector kan ik denk ik niet gebruiken, omdat ik een stuk geheugen tussen de DLL en het main programma moet delen. Ik geef de DLL tijdens het initialiseren een tweetal pointers mee, die vanuit de DLL geallocceerd (en ook weer gedeallocceerd) worden.

[MSalters]

lzandman schreef op 06 November 2002 @ 17:13:
[...]

Als ik kijk op MSDN bij GlobalLock dan raden ze me aan HeapAlloc() enz. te gebruiken. Weten jullie hoe dat moet?

De C of C++ runtime library gebruiken, die wordt niet in elke versie gerenamed. Simpelweg new[]/delete[] gebruiken. Bovendien hoef je dan niet eens meer te casten, dan vertel je gewoon wat voor een pointer je wilt hebben.