[C++] Typecasten

[Servowire]

Ik heb een probleempje in een programma waar ik mee bezig ben, ik kon het eerst niet vinden, maar het probleem zit ergens bij een constructie als dit:

C++:

#include <iostream.h>

void main(){
    int bla;
    char woei[3];
    std::cin >> woei;
    bla = int(woei[2]);
    std::cout << bla;
}

Als je bij de invoer b.v. "AA3A" invuld, zou bla dus 3 moeten worden.
Maar het word 53 ofzo....

de functie atoi() kun je niet toepassen op een array...
iemand een idee?

[ Voor 5% gewijzigd door Servowire op 23-01-2003 09:55 ]

[whoami]

Heb je al eens :

code:

bla = atoi(woei[2]);

geprobeerd?
Dan pas je het toch toe op een char, en niet op de array?

Wat jouw probleem wel is, is dat je een charachter array reserveert voor 3 elementen, waarvan één (het laatste) nog nodig is om de string af te sluiten ('\0'), en je een string van 4 elementen ingeeft terwijl er maar plaats is voor 2.

Je zult dus alleszins een char array van 5 moeten reserveren wil je 4 karakters kunnen ingeven:

code:

char woei[5];

[ Voor 60% gewijzigd door whoami op 23-01-2003 09:57 ]

[Servowire]

whoami schreef op 23 January 2003 @ 09:56:
Heb je al eens :

code:

bla = atoi(woei[2]);

geprobeerd?
Dan pas je het toch toe op een char, en niet op de array?

code:

testje.cpp: In function `int main(...)':
testje.cpp:8: passing `char' to argument 1 of `atoi(const char *)' lacks a cast

Dat gaat dus ook niet goed.....

[ Voor 8% gewijzigd door Servowire op 23-01-2003 10:06 ]

[Verwijderd]

Whoami bedoelde gewoon

C++:

bla = atoi(woei);

of

C++:

bla = atoi(&woei[0]);

Da's gewoon zo'n stom instinkertje als je nog geen koffie op heb op de vroege ochtend

[Janoz]

ff vraagje... Waarom zou bla 3 moeten zijn omdat er aa3a ingevuld is? Wat nu als er 3a3a ingevuld is?

[Verwijderd]

Janoz schreef op 23 januari 2003 @ 10:19:
ff vraagje... Waarom zou bla 3 moeten zijn omdat er aa3a ingevuld is? Wat nu als er 3a3a ingevuld is?

Hetzelfde: de code is

C++:

bla = int(woei[2]);

Eerste stap: we vragen de char op positie "2" in array "woei" op: dat is dus karakter '3', da's met hexwaarde 0x33. Die typecasten we naar een int, waardoor de waarde 0x33 ge-sign-extend wordt naar een int met waarde 0x33.

De juiste manier zou hier bijvoorbeeld kunnen zijn:

C++:

std::cin >> bla

dan heb je ook geen char-buffer nodig.

[Janoz]

Doelde meer op de topicstarter, maar had de [2] over het hoofd gezien ..

[MSalters]

Hmm.. dit programma is wel erg krakkemikkig. Wat als je geen 3 karakters invoert? Dan is woei[2] undefined, is niet goed.

Verder: <iostream> ipv <iostream.h>, int main() ipv void main(), en duidelijker zijn wat je nou precies wil.

[Verwijderd]

In C++ is "void main()" juist officieel toegestaan en goedgekeurd (volgens mij wordt dit in C alleen maar gedoogd, maar in C++ was het volgens mij officieel), en "#include <iostream.h>" is juist ook gewoon goed, al vind ik zonder .h beter en veel netter...

Maar inderdaad dat de TS alleen geinteresseerd is in het 3de karakter, en daar de atoi waarde van, dan wordt het dus atoi(&woei[2]); met een wrapper om te kijken of d'r wel een 3de karakter is...

En veel beter dan een char buffertje is uiteraard om dan een string te gebruiken, die is tenminste dynamisch...

[ Voor 7% gewijzigd door Verwijderd op 23-01-2003 10:54 ]

[AaroN]

C++:

#include <iostream> 
#include <string>

using namespace std;

int main(){ 
    int bla; 
    string woei; 
    cin >> woei; 
    bla = int(woei.at(2))-48; 
    cout << bla;
    return 0;
}

Die -48 is om ascii '0' om te zetten in integer 0 (zie www.asciitable.com )

Jij gebruikt c, nu c++

[ Voor 33% gewijzigd door AaroN op 23-01-2003 10:55 ]

[Verwijderd]

AaroN schreef op 23 januari 2003 @ 10:53:

C++:

    bla = int(woei.at(2))-48; 

Die -48 is om ascii '0' om te zetten in integer 0 (zie www.asciitable.com )

...en die werkt niet, als het een [a..f] of een [A...F] is... Daar kun je dus beter een echte oplossing voor gebruiken, zoals bijvoorbeeld "atoi(..)".

[AaroN]

Hij wil alleen een cijfer inlezen op de derde plek van de string, dat begrijp ik eruit. Hij hoeft geen Hex in te lezen, dus dan klopt mijn stukkie code gewoon

Hij heeft waarschijnlijk character strings met cijfers op bepaalde plaatsen en deze wil hij in een integer variabele plaatsen, zie namelijk zijn andere topic over die bool-array

[ Voor 37% gewijzigd door AaroN op 23-01-2003 11:21 ]

[.oisyn]

[nohtml]

Verwijderd schreef op 23 January 2003 @ 10:50:
In C++ is "void main()" juist officieel toegestaan en goedgekeurd (volgens mij wordt dit in C alleen maar gedoogd, maar in C++ was het volgens mij officieel), en "#include <iostream.h>" is juist ook gewoon goed, al vind ik zonder .h beter en veel netter...

het is int main (), en iostream.h is deprecated (net als alle andere C++ headers met een .h erachter)

[AaroN]

Zo vertelt Stroustrup het inderdaad

Die *.h headers zijn oude c headers en daarin wordt gecheckt op bepaalde macro's zoals __cplusplus en doen dan uiteindelijk hetzelfde

[ Voor 65% gewijzigd door AaroN op 23-01-2003 11:26 ]

[drm]

Servowire:
de functie atoi() kun je niet toepassen op een array...
iemand een idee?

Dit vind ik wel een mooie, als je bedenkt dat atoi gewoon array to integer betekent
^</flauw>

[.oisyn]

Niet echt, die a staat gewoon voor een string (alphabet, ascii, verzin maar wat leuks )

[AaroN]

atoi is Ascii string to Integer
Ofwel Character Array to Integer, maar in principe is het dus Ascii to Integer

oeps te laat

[ Voor 8% gewijzigd door AaroN op 23-01-2003 11:35 ]

[AaroN]

verkeerde knopje

[ Voor 154% gewijzigd door AaroN op 23-01-2003 11:36 ]

[drm]

.oisyn:
Niet echt, die a staat gewoon voor een string (alphabet, ascii, verzin maar wat leuks )

Jawel, maar string (volgens C) is een array van characters. Array of characters to integer.

_{tenminste, zo heb ik het altijd geinterpreteerd}

[Janoz]

AaroN schreef op 23 januari 2003 @ 10:53:

Die -48 is om ascii '0' om te zetten in integer 0 (zie www.asciitable.com )

Jij gebruikt c, nu c++

Persoonlijk gebruik ik dan liever int('0') ipv 48. Op die manier weet je dat het altijd werkt. Nu is de ascii tabel redelijk constant, maar ik ben een beetje alergisch voor constanten in code .

[Verwijderd]

AaroN schreef op 23 januari 2003 @ 11:19:
Hij wil alleen een cijfer inlezen op de derde plek van de string, dat begrijp ik eruit. Hij hoeft geen Hex in te lezen, dus dan klopt mijn stukkie code gewoon

Hij heeft waarschijnlijk character strings met cijfers op bepaalde plaatsen en deze wil hij in een integer variabele plaatsen, zie namelijk zijn andere topic over die bool-array

Dat begreep ik er niet direct uit. "AA3A", dat kan ook zeker zeker hex zijn... "A" is ook een cijfer in het hexadecimale stelsel, en 2-9 weer niet in het binaire stelsel, ligt er maar aan wat je nodig hebt of dit kan..

In ieder geval zou je de char moeten checken op een zinnige waarde. In het decimale geval, moet de waarde dus binnen het bereik van '0' t/m '9' zitten.

[ Voor 13% gewijzigd door Verwijderd op 23-01-2003 12:03 ]

[Verwijderd]

.oisyn schreef op 23 January 2003 @ 11:21:
..en iostream.h is deprecated (net als alle andere C++ headers met een .h erachter)

Maar 'iostream.h' is zeker wel toegestaan, en 'void main()' ook zonder meer, depricated maar wel binnen de standaard. MSalters wekte de indruk dat het fout is, maar het is enkel een beetje slordig t.o.v. de "regels" voor fatsoenlijke code.

En IDE's maken vaak nog altijd standaard ".h" headers aan voor C++ projecten, dus dat .h nu al helemaal "uit" is valt ook wel mee.. Zelf vind ik .hpp/.hh/.hxx een veel betere aanduiding voor zowel project als lib-headers, maar voor de libs gaat dat uiteraard niet meer gebeuren


Voor de grap: de hele headerfile "/usr/include/g++-3/iostream":

C++:

// -*- C++ -*- forwarding header.
// This file is part of the GNU ANSI C++ Library.

#ifndef __IOSTREAM__
#define __IOSTREAM__
#include <iostream.h>
#endif

(Hier ben ik het dus wel weer fundamenteel mee oneens hoor: ik vind zowiezo dat de "iostream.h" de "iostream" moet includen en niet andersom En ja, iostream.h mag nog wel even blijven bestaan voor al het nog rondzwervende, verouderde C++ lesmateriaal en dan zo snel mogelijk weg...)

Kortom: backward-compatibility, dat noem ik niet "fout", het is "goed" en niet netjes, maar wel goed (zo interpreteer ik dat...)

En 'void main()' is een uitbreiding in vrijwel alle compilers, maar dat is blijkbaar nog geen deel van de standaard, als ik jullie zo hoor. Zo'n beetje elke compiler zal een "return 0" simuleren bij void main() - tenminste als een exitwaarde al wordt ondersteund, want dat is ook niet altijd het geval... (Vandaar soms ook 'void main(void);' )

[ Voor 51% gewijzigd door Verwijderd op 23-01-2003 13:12 ]

[.oisyn]

Verwijderd schreef op 23 January 2003 @ 12:15:
[...]

Maar 'iostream.h' is zeker wel toegestaan, en 'void main()' ook zonder meer, depricated maar wel binnen de standaard. MSalters wekte de indruk dat het fout is, maar het is enkel een beetje slordig t.o.v. de "regels" voor fatsoenlijke code.

dat heet backwards compatibility, dat wil niet zeggen dat het goed is

En IDE's maken vaak nog altijd standaard ".h" headers aan voor C++ projecten, dus dat .h nu al helemaal "uit" is valt ook wel mee.. Zelf vind ik .hpp/.hh/.hxx een veel betere aanduiding voor zowel project als lib-headers, maar voor de libs gaat dat uiteraard niet meer gebeuren

oeps mijn fout, ik bedoelde de standaard C++ headers, natuurlijk niet de headers die jij zelf definieert

Hier ben ik het dus wel weer fundamenteel mee oneens hoor: ik vind zowiezo dat de "iostream.h" de "iostream" moet includen en niet andersom En ja, iostream.h mag nog wel even blijven bestaan voor al het nog rondzwervende, verouderde C++ lesmateriaal en dan zo snel mogelijk weg...

Mja, dat is slechts een specifieke implementatie van de standaard, niet hoe de standaard werkelijk in elkaar zit. Da's toch een fundamenteel verschil

[Zoijar]

Verwijderd schreef op 23 January 2003 @ 12:15:
[...]

Maar 'iostream.h' is zeker wel toegestaan, en 'void main()' ook zonder meer, depricated maar wel binnen de standaard. MSalters wekte de indruk dat het fout is, maar het is enkel een beetje slordig t.o.v. de "regels" voor fatsoenlijke code.

Nee dat is niet waar. De standaard stelt heel duidelijk dat het retrn type van de main functie int moet zijn.

An implementation shall not predefine the main function. This function shall not be overloaded. It shall
have a return type of type int, but otherwise its type is implementationdefined.
All implementations
shall allow both of the following definitions of main:

"Shall" betekend is ISO wording dat iets anders niet is toegestaan.

Overigens wordt ook dit gesteld:

A return statement in main has the effect of leaving the main function (destroying any objects with automatic storage duration) and calling exit with the return value as the argument. If control reaches the end of main without encountering a return statement, the effect is that of executing return 0;

Dus de return mag wel weer weg gelaten worden.

[ Voor 22% gewijzigd door Zoijar op 23-01-2003 13:25 ]

[Verwijderd]

.oisyn schreef op 23 January 2003 @ 12:42:
dat heet backwards compatibility, dat wil niet zeggen dat het goed is

niet altijd wordt er een exitwaarde ondersteunt, bijvoorbeeld door een (brak) besturingssysteem, of door het gebrek daaraan (embedded). Dan moet er speciaal een "int" return worden gefaked.

oeps mijn fout, ik bedoelde de standaard C++ headers, natuurlijk niet de headers die jij zelf definieert

Ja maar dat vind ik dus reuze inconsistent. De C++ libs mogen toch wel het goede voorbeeld geven (in mijn ogen: of alleen headers zonder extensie, of naast extensieloos een .hpp/.hh/hxx extensie o.i.d.) en de compilertools moeten mijns insziens het goed voorbeeld geven.

Mja, dat is slechts een specifieke implementatie van de standaard, niet hoe de standaard werkelijk in elkaar zit. Da's toch een fundamenteel verschil

Het was ook bedoelt als met een knipoog, maar das dit ook toch

[ Voor 4% gewijzigd door Verwijderd op 23-01-2003 13:25 ]

[Verwijderd]

An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementationdefined.

Wordt hier niet bedoelt dat een "int main()" declaratie moet worden ondersteunt door de compiler, maar dat daarnaast ook het een en ander nog mogelijk is? Want niet altijd wordt een daadwerkelijke exitwaarde ondersteunt.

[Zoijar]

Verwijderd schreef op 23 January 2003 @ 13:30:
[...]

Wordt hier niet bedoelt dat een "int main()" declaratie moet worden ondersteunt door de compiler, maar dat daarnaast ook het een en ander nog mogelijk is? Want niet altijd wordt een daadwerkelijke exitwaarde ondersteunt.

Nope

Er staat "the main function" en er boven wordt uitgelegd dat er maar 1 main is als entry point etc. Die moet worden opgevat als "the" main function.

[Verwijderd]

Zoijar schreef op 23 January 2003 @ 13:33:
[...]


Nope

Er staat "the main function" en er boven wordt uitgelegd dat er maar 1 main is als entry point etc. Die moet worden opgevat als "the" main function.

Ik zie niet hoe dit een argument "tegen" is, uiteraard is er maar een entry point en als er geen 'int main()' is, kan je pas een 'void main()' defineren... Dat is dan "the main". D'r is vast wel een argument tegen, maar niet zoals die hier staat...

Leg ajb uit wat "shall...otherwise..." in je quote naar jouw mening inhoudt, want ik wil het echt graag weten. 'int main()' is beter, maar een goede compiler moet ook 'void main()' ondersteunen voor zijn gebruikers, dat weet elke compilerbouwer, maar ik wil wel weten of dat eigenlijk toegestaan is in de standaard, of dat het extra non-ansi service aan de gebruikers is...

[ Voor 9% gewijzigd door Verwijderd op 23-01-2003 13:54 ]

[.oisyn]

Verwijderd schreef op 23 januari 2003 @ 13:30:
[...]

Wordt hier niet bedoelt dat een "int main()" declaratie moet worden ondersteunt door de compiler, maar dat daarnaast ook het een en ander nog mogelijk is? Want niet altijd wordt een daadwerkelijke exitwaarde ondersteunt.

de standaard C exit () functie heeft ook altijd een exit-code als parameter, of dat nou door het OS wordt ondersteund of niet. De returnwaarde van main () wordt gebruikt als de parameter voor exit, en dus zal main ook altijd int zijn, of die exitwaarde nou zinnig is of niet

[Zoijar]

Verwijderd schreef op 23 januari 2003 @ 13:44:
[...]

Ik zie niet hoe dit een argument "tegen" is, uiteraard is er maar een entry point en als er geen 'int main()' is, kan je pas een 'void main()' defineren... Dat is dan "the main". D'r is vast wel een argument tegen, maar niet zoals die hier staat...

Leg liever uit wat "shall...otherwise..." dan naar jouw mening inhoudt, want ik wil het echt graag weten. 'int main()' is beter, maar een goede compiler moet ook 'void main()' ondersteunen voor zijn gebruikers, dat weet elke compilerbouwer, maar ik wil wel weten of dat eigenlijk toegestaan is in de standaard, of dat het service aan de gebruikers is...

Ok, wat bedoeld wordt met "otherwise" is de rest van de main() specificatie. Dus alleen het return type moet int zijn, en verder is het implementatie afhankelijk. Dit is gedaan om het mogelijk te maken commandline argumenten mee te geven of niet. (waar ook weer wat restricties ed aan hangen)

Een standaard C++ programma returned altijd een exit-code.

Stel dat je "void main()" defineerd, dan is dat "the main" en vervolgens wordt er gesteld dat "the main" een type int returned. Het voldoet dus niet meer aan de standaard.

Veel compilers ondersteunen void main alleen om backwards compatible te zijn, maar in feite is het dan geen iso C++ compiler. Meestal heb je een -strict flag, of -pedantic en dan zou void main rejected moeten worden. Vergelijk het met microsoft language extensions.

Een programma dat void main gebruikt, is geen iso C++ programma. Als je dus standaard C++ wilt programmeren, dat op alle standaard C++ compilers werkt, moet je int main gebruiken. Zo is ook de header "iostream.h" niet standaard. Deze header hoeft dus niet per se aanwezig te zijn.

[Verwijderd]

Zoijar schreef op 23 januari 2003 @ 13:55:
Stel dat je "void main()" defineert, dan is dat "the main" en vervolgens wordt er gesteld dat "the main" een type int returned. Het voldoet dus niet meer aan de standaard.

Dat is niet de volgorde, er is gesteld dat de main een int retourneert. Vervolgens wordt een 'void main()' ook in vrijwel elke compiler geaccepteerd (met of zonder wanrning) waarbij de compiler een impliciete exit(0) genereert (behalve gcc, ook het weglaten van een return heeft in gcc het gevolg dat er niks wordt weggeschreven in het returnregister dat is dus niet ISO ). Verder wordt de "int" genegeerd voor targets waar een exit-code niet wordt/kan worden afgevangen.

Dit is overigens geenszins backwardscompatibility, want int was altijd al het returntype van main, daarbij is een officieuze, gedoogde versie met void bijgekomen...

[.oisyn]

(zucht)

C++:

void main ()
{
}

compilen met gcc 3.2 en de -pedantic switch:

code:

bla.cpp:1: `main' must return `int'
bla.cpp:1: warning: return type for `main' changed to `int'

dat compilers het toestaan wil nog niet zeggen dat het volgens de standaard is

[ Voor 17% gewijzigd door .oisyn op 23-01-2003 14:55 ]

[Zoijar]

Misschien dat je het van Stroustrup wel aan neemt...ik schijn in ieder geval niet echt over te komen hehe

The definition
void main() { /* ... */ }

is not and never has been C++, nor has it even been C. See the ISO C++ standard 3.6.1[2] or the ISO C standard 5.1.2.2.1. A conforming implementation accepts
int main() { /* ... */ }

and
int main(int argc, char* argv[]) { /* ... */ }

A conforming implementation may provide more versions of main(), but they must all have return type int. The int returned by main() is a way for a program to return a value to "the system" that invokes it. On systems that doesn't provide such a facility the return value is ignored, but that doesn't make "void main()" legal C++ or legal C. Even if your compiler accepts "void main()" avoid it, or risk being considered ignorant by C and C++ programmers.
In C++ main() need not contain an explicit return statement. In that case, the value returned is 0, meaning successful execution. For example:

#include<iostream>

int main()
{
std::cout << "This program returns the integer value 0\n";
}

Note also that neither ISO C++ nor C99 allows you to leave the type out of a declaration. That is, in contrast to C89 and ARM C++ ,"int" is not assumed where a type is missing in a declaration. Consequently:
#include<iostream>

main() { /* ... */ }

is an error because the return type of main() is missing.

[ Voor 5% gewijzigd door Zoijar op 23-01-2003 15:29 ]

[Verwijderd]

.oisyn schreef op 23 January 2003 @ 14:54:
dat compilers het toestaan wil nog niet zeggen dat het volgens de standaard is

(zucht) Dat zei ik niet, maar vrijwel elke compiler ondersteunt het en en al is het niet netjes, toch kan het wel bij vrijwel alle compilers. Ik vind er wat voor te zeggen dat een programmeurs het onzinnig vinden om een int te returnen bij elke main, als die int geen wezelijk nut heeft (dus geen exit-code codering) en je weet dat de compiler ervoor zorgt dat alles goed komt. Dat zijn dingen waar je als programmeur je toch echt verder niet mee bezig wilt houden... (ik gebruik wel, ookal is het onnodig, altijd een "int main(){...; return 0;}" constructie, maar dat wil niet zeggen dat ik ook vind dat programmeurs die dat anders doen foute code maken (hooguit slechte of non-portable).
Dat men vanuit de main van een DSP de main niet laat returnen, maar void declareert, kan me echt niet boeien aangezien d'r pas in het alleruiterste geval uit de main zou mogen stappen en de processor dan ook niets meer te doen heeft en dit niet de gewoonte is dat dat gebeurt..)

[ Voor 33% gewijzigd door Verwijderd op 23-01-2003 16:32 ]

[Verwijderd]

Zoijar schreef op 23 January 2003 @ 15:28:
Misschien dat je het van Stroustrup wel aan neemt...ik schijn in ieder geval niet echt over te komen hehe

Jawel hoor, ik zit vooral ook maar te stoken. Maar ik vind het echt wel 100% gerechtvaardigd dat men een void main() gebruikt als je geen omgeving hebt waarnaar je returned. DSP is wel een wat ondergewaardeerde toepassingstak van C++ lijkt het wel, aangezien d'r vaak zo'n ophef wordt gemaakt - idd ook door Stroustrup - over het "int main()" principe. Ik vind eigenlijk dat het main prototype zo goed mogelijk de omgeving zou moeten modelleren waar de main zich in bevindt. Maar goed, daar is niemand het verder hier mee eens i.e.g.

[ Voor 11% gewijzigd door Verwijderd op 23-01-2003 16:24 ]

[MSalters]

Verwijderd schreef op 23 januari 2003 @ 13:23:
Ja maar dat vind ik dus reuze inconsistent. De C++ libs mogen toch wel het goede voorbeeld geven (in mijn ogen: of alleen headers zonder extensie, of naast extensieloos een .hpp/.hh/hxx extensie o.i.d.) en de compilertools moeten mijns insziens het goed voorbeeld geven.

Die redenering houd niet echt lang stand: De C++ libs definieren hun namen in std::, dus dat moet jij ook doen ? Niet dus; de std:: vorm voor identifiers is juist gekozen om name clashes te voorkomen, en de <iostream> vorm ook. Juist omdat de .h/.hpp/.hxx vormen worden gebruikt door programmeurs is het veilig voor de compiler om de extensie-loze vorm te gebruiken .

[MSalters]

Verwijderd schreef op 23 January 2003 @ 16:11:
[...]

Jawel hoor, ik zit vooral ook maar te stoken. Maar ik vind het echt wel 100% gerechtvaardigd dat men een void main() gebruikt als je geen omgeving hebt waarnaar je returned. DSP is wel een wat ondergewaardeerde toepassingstak van C++ lijkt het wel, aangezien d'r vaak zo'n ophef wordt gemaakt - idd ook door Stroustrup - over het "int main()" principe. Ik vind eigenlijk dat het main prototype zo goed mogelijk de omgeving zou moeten modelleren waar de main zich in bevindt. Maar goed, daar is niemand het verder hier mee eens i.e.g.

Ehm, nou ja, als je er nou een DSP hebt, dan heb je wel weer gelijk met void main(), maar dan is de std::cout weer fout. De standaard library voor embedded systemen is heel veel kleiner. (Alleen std::bad_alloc voor new, en dat soort kruimels)

[MSalters]

Zoijar schreef op 23 January 2003 @ 13:55:
Veel compilers ondersteunen void main alleen om backwards compatible te zijn, maar in feite is het dan geen iso C++ compiler. Meestal heb je een -strict flag, of -pedantic en dan zou void main rejected moeten worden. Vergelijk het met microsoft language extensions.

Nou, zo streng is de standaard weer niet. Als er maar een "diagnostic" (warning of error) komt, is alles daarna goed. Een ISO-C++ compiler mag dus ook Pascal code herkennen, de diagnostic "Assuming ISO Pascal" geven en het daarna gewoon compileren. 'void main() ' met een waarschuwing accepteren (a la GCC -Wall) is dus legaal.

[Verwijderd]

MSalters schreef op 23 January 2003 @ 16:46:Ehm, nou ja, als je er nou een DSP hebt, dan heb je wel weer gelijk met void main(), maar dan is de std::cout weer fout. De standaard library voor embedded systemen is heel veel kleiner. (Alleen std::bad_alloc voor new, en dat soort kruimels)

Da's niet waar, std::cout bestaat heel vaak wel, het is alleen vaak configureerbaar (== je moet het vaak zelf configureren hoe je het wilt hebben). Je kunt dan bijvoorbeeld kiezen met een I/O poort als stdout (naar een display of compoort, etc) of een virtuele-buffer in je geheugen (die je shared met, en laat uitlezen door een microcontrollertje...)
Voor C++ DSP gebruik je echt dezelfde even uitgebreide STL, alleen sommige dingen zijn wat minder nuttig misschien... Andere zul je misschien alleen voor DSPs veel gebruiken. I/O streams zul je in elk geval veel gebruiken

[Verwijderd]

Het stomme vind ik trouwens dat Dinkum doet voorkomen alsof <iostream.h> de header is die je moet includen als je geen wcin/wcout/wcerr/wclog support wenst... Ik weet wel beter (echt hoor!), maar ik vind dat nogal misleidend, helemaal aangezien hun online STL referentie d'r regelmatig op nagelezen wordt... Het staat er wel bij ("in this implementation"), maar niet voor iedereen even duidelijk. (uiteraard is iostream.h depricated.)

[ Voor 14% gewijzigd door Verwijderd op 23-01-2003 17:16 ]