DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Er is helemaal niets mis met scanf en printf gebruiken in C++-code. Sterker nog, ik zie cout en cin zelden buiten leerboeken, en dat heeft een reden.quote:Op zaterdag 8 september 2012 16:29 schreef GS42 het volgende:
[..]
Ten eerste: waarom probeer je het te doen? Het lijkt op of een opgave uit een leerboek of een huiswerkopdracht. Iets meer context is handig.
Als het uit een leerboek is: hoe oud is je boek? Je gebruikt conio.h en int main(void) waardoor ik een beetje het idee heb weer in de jaren '80 te zitten.En als je boek werkelijk over C++ gaat, doe je er beter aan weg te gooien. Als je boek over C gaat, kan je er misschien wel iets mee.
Dat is namelijk het tweede punt: als je C++ code probeert te schrijven, kan je beter helemaal overnieuw beginnen: het gebruik van printf en scanf is een doodszonde. Beter kan je het vanaf het begin goed leren. (Als je echter een C programma probeert te schrijven, is het prima.)
En je lijkt nogal wat basisconcepten niet duidelijk te hebben, zoals wat er opgeslagen wordt in een fundamenteel type en wat de operatoren doen. Het helpt om hierover te lezen voordat je begint te typen.
Want ik heb destijds besloten, dat ik de harde weg ontwijk.
Dus blijf ik lopen door de sloten, het liefst in zeven tegelijk.
BZB - Zeven Sloten
Dus blijf ik lopen door de sloten, het liefst in zeven tegelijk.
BZB - Zeven Sloten
Tja, ik weet niet hoor maar std::cin en std::cout zijn zeg maar gemaakt voor C++ en scanf en printf zijn "oude" functies vanuit C overigens kunnen ze nog nuttig zijn maar het heeft een reden dat ze niet in de std zittenquote:
[..]
Er is helemaal niets mis met scanf en printf gebruiken in C++-code. Sterker nog, ik zie cout en cin zelden buiten leerboeken, en dat heeft een reden.
Beware of the Raping Zebra's
En waarom weet je dit dan niet als je die opdrachten moet maken?quote:
[..]
Ik moet voor a.s. woensdag 4 opdrachten inleveren en zit pas op 1/4Klakkeloos overnemen van anderen heeft geen zin bij dit vak, dat weet ik. Bovendien weet de docent dat snel genoeg te achterhalen dus daar ben ik niet op uit. Eerder informatie zodat ik een beetje op gang geholpen kan worden.
Die conio die je bedoelt is overbodig weet ik, maar ik laat 'm maar erbij staan.
Ik heb nog een vaag dictaat gevonden op school maar daar kom ik ook niet erg wijs uit. Weet jij een gratis betere NLse versie?
niet naar college geweest of is het een slechte docent?
of ben je gewoon te laat begonnen???
Beware of the Raping Zebra's
Heb een heel schooljaar gemist. Docent is maandag wel bereikbaar voor vragen. Programmeren valt eigenlijk niet uit te leggen. De stof komt al snel over als 'blackmagic'. Pas na 10 keer oefenen leer je er iets van.quote:
[..]
En waarom weet je dit dan niet als je die opdrachten moet maken?
niet naar college geweest of is het een slechte docent?
of ben je gewoon te laat begonnen???
Klopt, dat is dus ook de reden waarom je de basis moet begrijpen want anders zal het je niet lukken...quote:
[..]
Heb een heel schooljaar gemist. Docent is maandag wel bereikbaar voor vragen. Programmeren valt eigenlijk niet uit te leggen. De stof komt al snel over als 'blackmagic'. Pas na 10 keer oefenen leer je er iets van.
kijk hier anders eens: klik
en verder kun je heel veel vinden op google en wikipedia...
Beware of the Raping Zebra's
Je hebt nog niet aangegeven of de cursus nu in C of C++ wordt gegeven, maar op basis van de code neem ik aan dat het C is. Dan is dit een prima en online beschikbaar boek om te lezen: ftp://ftp.icce.rug.nl/pub/frank/tmp/cbook.pdfquote:
[..]
Ik moet voor a.s. woensdag 4 opdrachten inleveren en zit pas op 1/4
Die conio die je bedoelt is overbodig weet ik, maar ik laat 'm maar erbij staan.
Ik heb nog een vaag dictaat gevonden op school maar daar kom ik ook niet erg wijs uit. Weet jij een gratis betere NLse versie?
Als het toch C++ betreft, kan je hier kijken voor tips. Misschien zijn boeken op die lijst vertaald naar het Nederlands?
"Slechts diegene mag slopen die iets beters kan bouwen."
Ah, leuk. Waarom denk je dat er niets mis mee is en welke reden denk je gevonden te hebben?quote:
Er is helemaal niets mis met scanf en printf gebruiken in C++-code. Sterker nog, ik zie cout en cin zelden buiten leerboeken, en dat heeft een reden.
Misschien is mijn 'doodszonde' een beetje sterk uitgedrukt (
), maar ik sta er zeker achter dat in een C++ programma scanf en printf niet gebruikt moeten worden, tenzij daar heel erg goede en gedocumenteerde redenen voor zijn (waarvan ik geen enkel voorbeeld kan verzinnen...). En dat is niet omdat ze slecht zijn, maar wel omdat C++ voor beide een beter alternatief levert.Beide oude C-functies verwachten een format-string en scanf verwacht pointers naar types. Dit zijn twee punten waarop gemakkelijk fouten gemaakt kunnen worden die met de C++-functies onmogelijk zijn. Daarnaast geven de input en output streams van C++ betere uniformiteit (schrijven naar bestanden of sockets kan op dezelfde manier als schrijven naar cout), meer formatting opties (zie iomanip) en meer mogelijkheden (zo is het mogelijk een class direct in std::cout te stoppen). Vroeger waren er nog wel eens verhalen dat het een of het ander sneller zou zijn, maar de compiler-kwaliteit is nu zo dat ik geen enkel verschil verwacht; er is namelijk geen technische reden waarom er verschil zou zijn.
Ik zie ook wel eens (niet vaak) printf en scanf in C++-code staan en ik denk ook dat het een reden heeft. Die reden is volgens mij omdat veel C-programmeurs 'overgestapt' zijn naar C++ zonder hun programmeerstijl aan te passen: ze gebruiken C++ gewoon als C met een beetje STL. Prima natuurlijk, maar het levert geen nette C++ code op.
Maar zoals ik al zei, ik ben benieuwd naar jouw kant. Kijk je veel naar andermans code en naar welke reden verwijs je?
"Slechts diegene mag slopen die iets beters kan bouwen."
Er bestaat al een Nls C++ forum...quote:
[..]
Klopt, dat is dus ook de reden waarom je de basis moet begrijpen want anders zal het je niet lukken...
kijk hier anders eens: klik
en verder kun je heel veel vinden op google en wikipedia...
C++ is ook een erg goede taal om verschikkelijke code in te schrijven. De volgende code is geldige C++(11). Het is dus prima te compileren en te runnen. Kan je voorspellen wat de output is? En waarom?
Dit demonstreert mooi het nut van niet alleen juist maar ook duidelijk programmeren.
| 1 2 3 4 5 6 7 8 9 10 | ??=include <iostream> %:include <algorithm> #include <iterator> auto main() -> decltype(std::ios_base::xalloc() & false) ??< decltype(main()) _int<::> = <%??-??-72,101,??-??-108,108,111,??-??-32,119,111,??-??-114,108,100,??-??-46,10??>; std::copy(_int, _int + sizeof(_int) / sizeof(_int??(??--1U??)), std::ostream_iterator<decltype('??!')>(std::cout)); // Vreemd, he??/ std::cout << "Program done.\n"; ??> |
Dit demonstreert mooi het nut van niet alleen juist maar ook duidelijk programmeren.
"Slechts diegene mag slopen die iets beters kan bouwen."
Ik heb bij verschillende bedrijven code gezien en geschreven. Over het algemeen werd printf, scanf, cout en cin daar alleen gebruikt voor debug/logging. Vooral fprintf en fscanf dus. Deels zal dat zeker komen door mensen die overgestapt zijn uit C, maar zelf heb ik bijvoorbeeld eerst C++ geleerd (met cout en cin) en daarna pas C. Ik vind het gebruik van (f)printf en (f)scanf fijner omdat je op een makkelijkere en snellere manier meer controle hebt over hoe de formatting van je data is.quote:
[..]
Ah, leuk. Waarom denk je dat er niets mis mee is en welke reden denk je gevonden te hebben?
Misschien is mijn 'doodszonde' een beetje sterk uitgedrukt (
Beide oude C-functies verwachten een format-string en scanf verwacht pointers naar types. Dit zijn twee punten waarop gemakkelijk fouten gemaakt kunnen worden die met de C++-functies onmogelijk zijn. Daarnaast geven de input en output streams van C++ betere uniformiteit (schrijven naar bestanden of sockets kan op dezelfde manier als schrijven naar cout), meer formatting opties (zie iomanip) en meer mogelijkheden (zo is het mogelijk een class direct in std::cout te stoppen). Vroeger waren er nog wel eens verhalen dat het een of het ander sneller zou zijn, maar de compiler-kwaliteit is nu zo dat ik geen enkel verschil verwacht; er is namelijk geen technische reden waarom er verschil zou zijn.
Ik zie ook wel eens (niet vaak) printf en scanf in C++-code staan en ik denk ook dat het een reden heeft. Die reden is volgens mij omdat veel C-programmeurs 'overgestapt' zijn naar C++ zonder hun programmeerstijl aan te passen: ze gebruiken C++ gewoon als C met een beetje STL. Prima natuurlijk, maar het levert geen nette C++ code op.
Maar zoals ik al zei, ik ben benieuwd naar jouw kant. Kijk je veel naar andermans code en naar welke reden verwijs je?
Bijvoorbeeld:
| 1 | fprintf(dumpfile,"%.1f\t%.5f\n",input,result); |
| 1 2 3 4 | dumpfile.setprecision(1); dumpfile << fixed << input << "\t"; dumpfile.setprecision(5); dumpfile << result << endl; |
EDIT:
Ik zie nu dat dit ook kan, maar dan vind ik de fprintf nog steeds makkelijker.
| 1 | dumpfile << fixed << setprecision(1) << input << "\t" << setprecision(5) << result << endl; |
Want ik heb destijds besloten, dat ik de harde weg ontwijk.
Dus blijf ik lopen door de sloten, het liefst in zeven tegelijk.
BZB - Zeven Sloten
Dus blijf ik lopen door de sloten, het liefst in zeven tegelijk.
BZB - Zeven Sloten
Het voordeel van printf is de formatting, en het voordeel van cin en cout is dat je er niet tot beperkt bent maar dezelfde code bijvoorbeeld ook kunt toepassen op stringstreams. Het heeft allebei voor- en nadelen, en je moet gewoon datgene gebruiken wat voor je specifieke doeleinden het beste is.
Ik kan me wel voorstellen dat je het gemakkelijker en sneller vindt, omdat het inderdaad een stuk korter is om te typen. Echter, zover ik weet geeft printf niet "meer" controle. In jouw voorbeeldcode vind ik zelf de C++ code mooier om te lezen: ik vind het duidelijker om te zien wat er gebeurt, vooral omdat "setprecision" meer betekenis heeft dan "%.1f". Maar dit zal ook grotendeels gebaseerd zijn op voorkeur. De voordelen van de C++-aanpak die ik al genoemd heb, blijven natuurlijk onafhankelijk van mening.quote:
Ik vind het gebruik van (f)printf en (f)scanf fijner omdat je op een makkelijkere en snellere manier meer controle hebt over hoe de formatting van je data is.
Het enige objectieve voordeel van de printf-notatie is volgens mij dat printf tekst en variabelen mooi gescheiden houdt. Als je bijvoorbeeld een applicatie in meerdere talen wilt leveren, dan is iets als "Je leeftijd is %d jaar en %d dagen" mooi in een apart bestandje te zetten en kan je elke zin in een keer vertalen. Met std::cout gaat dit moeilijker, omdat je de zin in stukjes moet knippen.
Dit is natuurlijk niet de primaire functie van output-methoden en dus eigenlijk een toevallig effect van printf, maar wel een heel handige eigenschap. Boost heeft een library om dit effect ook in C++ te bereiken, met de voordelen van C++ (typesafe en eigen klassen gemakkelijk afdrukken) erbij.
Ik kan goed begrijpen dat je de printf-notatie gemakkelijker te typen vindt, maar ik denk dat de voordelen van de C++-alternatieven zwaarder wegen dan dat gemak.
"Slechts diegene mag slopen die iets beters kan bouwen."
Hm even analyseren.quote:
C++ is ook een erg goede taal om verschikkelijke code in te schrijven. De volgende code is geldige C++(11). Het is dus prima te compileren en te runnen. Kan je voorspellen wat de output is? En waarom?
[ code verwijderd ]
Dit demonstreert mooi het nut van niet alleen juist maar ook duidelijk programmeren.
Krijg wel leuke warnings.
trigraphs...
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | $ g++ -Wall -Wextra -std=c++11 -o meuk meuk.cpp meuk.cpp:1:1: warning: trigraph ??= converted to # [-Wtrigraphs] meuk.cpp:5:58: warning: trigraph ??< converted to { [-Wtrigraphs] meuk.cpp:6:35: warning: trigraph ??- converted to ~ [-Wtrigraphs] meuk.cpp:6:36: warning: trigraph ??- converted to ~ [-Wtrigraphs] meuk.cpp:6:44: warning: trigraph ??- converted to ~ [-Wtrigraphs] meuk.cpp:6:45: warning: trigraph ??- converted to ~ [-Wtrigraphs] meuk.cpp:6:58: warning: trigraph ??- converted to ~ [-Wtrigraphs] meuk.cpp:6:59: warning: trigraph ??- converted to ~ [-Wtrigraphs] meuk.cpp:6:71: warning: trigraph ??- converted to ~ [-Wtrigraphs] meuk.cpp:6:72: warning: trigraph ??- converted to ~ [-Wtrigraphs] meuk.cpp:6:85: warning: trigraph ??- converted to ~ [-Wtrigraphs] meuk.cpp:6:86: warning: trigraph ??- converted to ~ [-Wtrigraphs] meuk.cpp:6:92: warning: trigraph ??> converted to } [-Wtrigraphs] meuk.cpp:7:54: warning: trigraph ??( converted to [ [-Wtrigraphs] meuk.cpp:7:55: warning: trigraph ??- converted to ~ [-Wtrigraphs] meuk.cpp:7:59: warning: trigraph ??) converted to ] [-Wtrigraphs] meuk.cpp:7:95: warning: trigraph ??! converted to | [-Wtrigraphs] meuk.cpp:8:18: warning: trigraph ??/ converted to \ [-Wtrigraphs] meuk.cpp:8:5: warning: multi-line comment [-Wcomment] meuk.cpp:10:1: warning: trigraph ??> converted to } [-Wtrigraphs] |
-edit-
Als je wil weten wat dit wordt, gebruik -E in gcc
| 1 2 3 4 5 | auto main() -> decltype(std::ios_base::xalloc() & false) { decltype(main()) _int<::> = <%~~72,101,~~108,108,111,~~32,119,111,~~114,108,100,~~46,10}; std::copy(_int, _int + sizeof(_int) / sizeof(_int[~-1U]), std::ostream_iterator<decltype('|')>(std::cout)); } |
[ Bericht 30% gewijzigd door t4rt4rus op 14-09-2012 18:43:45 ]
Netjes, dat is de eerste stap. Dat zijn inderdaad twee vuile truukjes die ik erin heb gestopt: het gebruik van trigraphs en (gerelateerd) de dubbele commentaar-regel die schijnbaar uitgevoerde code verstopt.quote:
[..]
Hm even analyseren.
Krijg wel leuke warnings.
trigraphs...
[ code verwijderd ]
-edit-
Als je wil weten wat dit wordt, gebruik -E in gcc
[ code verwijderd ]
Let op dat ??/ in de comment er voor zorgt dat de regel erna ook een comment is.
Trigraphs zijn tekencombinaties die beginnen met ?? en bepaalde speciale tekens "#\^[]|{}~" kunnen vervangen (omdat die tekens vroeger niet op alle machines beschikbaar waren). Ook kan je ermee dus een commentaar-regel door laten lopen naar de volgende regel. De preprocessor vervangt deze trigraphs door het 'normale' teken en compileert daarna de code verder. Zoals je kunt zien leidt het gebruik van trigraphs tot onleesbare code en moet je ze dan ook nooit gebruiken, maar het is nuttig om te weten dat ze bestaan: ze kunnen rare problemen veroorzaken.
Maar zelfs nadat de preprocessor erover is geweest, is de code nog niet gemakkelijk te lezen. Er zit nog een aantal andere vreemde constructies in, waarbij de compiler-waarschuwingen je niet gaan helpen.
"Slechts diegene mag slopen die iets beters kan bouwen."
Als je dan ook nog de digraphs eruit haalt en de dubbele not operators, is het toch wel te lezen?quote:
[..]
Maar zelfs nadat de preprocessor erover is geweest, is de code nog niet gemakkelijk te lezen. Er zit nog een aantal andere vreemde constructies in, waarbij de compiler-waarschuwingen je niet gaan helpen.
Vond die digraph <::> wel leuk, dan denk je dat het een één of andere template is maar het is gewoon een array.
Wel vreemd dat de preprocessor de digraphs niet er niet uithaalt.
Even kijken of dat echt zo is...
-edit-
En volgens mij mag `decltype(main())' niet.
Je bedoelt met "dubbele not operators" de bitwise complement operators (~)? En die digraph vond ik inderdaad ook leuk om de template-achtige notitie. Het is niet vreemd dat de preprocessor de digraphs er niet uithaalt, omdat dit niet door de preprocessor gedaan wordt. De digraphs worden tijdens het compileren zelf verwerkt.quote:
[..]
Als je dan ook nog de digraphs eruit haalt en de dubbele not operators, is het toch wel te lezen?
Vond die digraph <::> wel leuk, dan denk je dat het een één of andere template is maar het is gewoon een array.
Wel vreemd dat de preprocessor de digraphs niet er niet uithaalt.
Even kijken of dat echt zo is...
-edit-
En volgens mij mag `decltype(main())' niet.
Waarom mag decltype(main()) niet, denk je? Ik ben er niet 100% zeker van dat het mag, maar ik heb niets gevonden dat zegt dat het niet mag. De functie wordt niet uitgevoerd (daarom is decltype(i++) ook zo'n gemeen statement) en main() levert een rvalue int op, dus ik neem aan dat dat type gewoon gebruikt wordt. Mis ik iets?
Ik ben er ook nog steeds niet helemaal zeker van of "~-1U" wel portable is. Er is natuurlijk wel een elegant en portable alternatief, maar toch.
"Slechts diegene mag slopen die iets beters kan bouwen."
Bitwise not of complement ja.quote:
[..]
Je bedoelt met "dubbele not operators" de bitwise complement operators (~)?
warning: ISO C++ forbids taking address of function ‘::main’quote:Waarom mag decltype(main()) niet, denk je? Ik ben er niet 100% zeker van dat het mag, maar ik heb niets gevonden dat zegt dat het niet mag. De functie wordt niet uitgevoerd (daarom is decltype(i++) ook zo'n gemeen statement) en main() levert een rvalue int op, dus ik neem aan dat dat type gewoon gebruikt wordt. Mis ik iets?
Ik snap hem ook niet.
Wanneer zou dat niet compatible zijn dan?quote:Ik ben er ook nog steeds niet helemaal zeker van of "~-1U" wel portable is. Er is natuurlijk wel een elegant en portable alternatief, maar toch.
Een tijdje terug heb ik op een site gezeten die vergelijkbaar is met Project Euler.
Alleen ging het daar echt om het programmeren en was het wat minder mathematisch.
Je had net als Project Euler vaste vragen, echter was er geen vast antwoord voor een vraag.
Voor elke vraag kreeg je een input die je moest gebruiken in je programma.
Deze input veranderde echter elke keer en je moest binnen een tijdslimiet je antwoord invullen of je moest de pagina herladen om een andere input te krijgen.
Kent iemand deze site?
Alleen ging het daar echt om het programmeren en was het wat minder mathematisch.
Je had net als Project Euler vaste vragen, echter was er geen vast antwoord voor een vraag.
Voor elke vraag kreeg je een input die je moest gebruiken in je programma.
Deze input veranderde echter elke keer en je moest binnen een tijdslimiet je antwoord invullen of je moest de pagina herladen om een andere input te krijgen.
Kent iemand deze site?
Ik wist niet dat ~ ook wel not genoemd wordt; ik dacht gelijk aan operator!.quote:
Bitwise not of complement ja.
[..]
warning: ISO C++ forbids taking address of function ‘::main’
Ik snap hem ook niet.
[..]
Wanneer zou dat niet compatible zijn dan?
En nee, ik snap niet waarom GCC over decltype(main()) klaagt. Misschien iets in de implementatie van decltype(), waardoor de compiler toch denkt dat de operand ergens uitgevoerd wordt. Of het mag echt niet om een of andere reden...
Ik twijfel aan ~-1U omdat ik niet zeker weet of -1U ook gegarandeerd alle bits op 1 zet op rare systemen.
"Slechts diegene mag slopen die iets beters kan bouwen."
ISO/IEC 14882:2011quote:
[..]
En nee, ik snap niet waarom GCC over decltype(main()) klaagt. Misschien iets in de implementatie van decltype(), waardoor de compiler toch denkt dat de operand ergens uitgevoerd wordt. Of het mag echt niet om een of andere reden...
3.6.1/3:
quote:The function main shall not be used within a program.
Boeit voor het programma verder ook niet.quote:Ik twijfel aan ~-1U omdat ik niet zeker weet of -1U ook gegarandeerd alle bits op 1 zet op rare systemen.
http://ideone.com/txgjY
[ Bericht 1% gewijzigd door t4rt4rus op 16-09-2012 20:51:54 ]
Zou USACO kunnen zijn?quote:
Een tijdje terug heb ik op een site gezeten die vergelijkbaar is met Project Euler.
Alleen ging het daar echt om het programmeren en was het wat minder mathematisch.
Je had net als Project Euler vaste vragen, echter was er geen vast antwoord voor een vraag.
Voor elke vraag kreeg je een input die je moest gebruiken in je programma.
Deze input veranderde echter elke keer en je moest binnen een tijdslimiet je antwoord invullen of je moest de pagina herladen om een andere input te krijgen.
Kent iemand deze site?
Die had ik ook gevonden, maar het verduidelijkt hier niet. C++ noemt code namelijk "gebruikt" als het op een plek staat die geevalueerd kan worden, wat binnen decltype() duidelijk niet het geval is.quote:
Dat klopt in deze context inderdaad. Ik vraag het me alleen nog wel af.quote:Boeit voor het programma verder ook niet.
"Slechts diegene mag slopen die iets beters kan bouwen."
Zitten er hier nog mensen op IRC?
Leuk om te channel te maken voor C++ op irc.fok.nl, irc.tweakers.net?
Leuk om te channel te maken voor C++ op irc.fok.nl, irc.tweakers.net?
primaquote:
Zitten er hier nog mensen op IRC?
Leuk om te channel te maken voor C++ op irc.fok.nl, irc.tweakers.net?
#cplusplus
[ Bericht 48% gewijzigd door ouyevoli op 27-09-2012 06:13:33 ]
Op zondag 30 september 2012 02:37 schreef LompeHork het volgende:
ouyevoli vind ik wel kwaliteit.
Op woensdag 3 oktober 2012 23:15 schreef Bitterlemon het volgende:
Ik wil kwaliteit, waar is Ouyevoli?
ouyevoli vind ik wel kwaliteit.
Op woensdag 3 oktober 2012 23:15 schreef Bitterlemon het volgende:
Ik wil kwaliteit, waar is Ouyevoli?
