[C++] n00b header vraag

[Verwijderd]

Ik heb dit weekend is met C++ lopen "kloten" en een klein calculatortje gemaakt (totaal useless, maar was wel grappig)

alles ging goed en het proggie werkt, maar ik schrok een beetje van de grote van de .exe die was namelijk 0.5MB en dat voor een geen honderd regels aan code, nu heb ik een beetje rondgezocht met de search naar compilers omdat ik dacht dat het daaraan lag, (ik gebruik die van MS (visual nog wat :P:))) en die werd juist aangeraden (naast die van borland) verder zou ik eigenlijk niet weten waar(naar) ik zou moeten zoeken.

misschien ligt het aan de volgende zin:

code:

#include <iostream>

(ik zag namelijk bij andere stukken iostream.h staan,

Ik heb hier (op me stage) geen compiler bij de hand dus dat kank niet uit proberen.

de source staat op http://exci.xs4all.nl/Excilat0r.cpp

[Fvdlaar]

Je hebt wel de Release gecompileerd i.p.v. de Debug?

edit:

Bij mij is ie maar +/- 114 kB

[NiMu83]

iostream en iostream.h zijn precies hetzelfde...die '.h' wordt gebruikt in de gewone C dacht ik, terwijl die zonder '.h' in c++ zit.

[Soultaker]

Niet helemaal on-topic, maar header files dragen doorgaans niet bij aan de grote van je broncode.

Verder kan ik me niet voorstellen dat een release-build 500k wordt. Check je Build en Project Settings dus even.

[Verwijderd]

Op maandag 06 mei 2002 11:47 schreef Soultaker het volgende:
Niet helemaal on-topic, maar header files dragen doorgaans niet bij aan de grote van je broncode.

Verder kan ik me niet voorstellen dat een release-build 500k wordt. Check je Build en Project Settings dus even.

Zelfs voor een debug is dit GROOT

[edit] Ik heb op het moment geen VSC++ geinst maar dit zou toch ergen bij de 20k moeten liggen ? Dit is immers maar een simpel dos proggie.

[MSalters]

Standaard oorzaken:
* Debug mode
* Optimize for speed (ipv size)
* Inline all
* Staticly linked lib (ipv DLL)

<iostream> is goed, <iostream.h> is alleen voor backwards compatibility met VC1.0 t/m 4.2 en dus niet voor nieuwe programma's.

[Soultaker]

Standaard debug build wordt bij mij ook zo'n 500kb, standaard release build is 120kb, geoptimaliseerd voor grootte (zonder verdere tweaks) wordt 'ie 104kb.

Ik denk dat de statische deel van C++ library (en/of de STL) 'm zo groot maakt. Ik gok dat een C implementatie zo'n 50kb zou worden en dat 'ie met assembly wel onder de 4k is te krijgen, hoewel Windows binaries standaard al enkele kb's groot moeten zijn.

edit:
De C port (ik schijn tijd over te hebben) is 44kb

[Verwijderd]

Op maandag 06 mei 2002 12:10 schreef MSalters het volgende:
...
<iostream> is goed, <iostream.h> is alleen voor backwards compatibility met VC1.0 t/m 4.2 en dus niet voor nieuwe programma's.

En niet te vergeten een heleboel andere C++ compilers... Voor zover ik mij kan herinneren slikken niet veel compilers de versie zonder ".h"

[Verwijderd]

De versie zonder h heeft gewoon te maken met namespaces en komt dus uit c++. Dit is gedaan om ambiguiteit tegen te gaan. Alles is tegenwoordig onder gebracht in de namespace "std". Jammer genoeg staat er in menig C++ boek de hele foute regel:
using namespace std;

Als je dat doet kun je net zo goed gebruik maken van de header files met h erbij. Het gaat er om dat je alleen objecten een classes "gebruikt" ( keyword using ) die je ook daadwerkelijk toepast, dus bv:

code:

#include <iostream>

using std :: cin;  //maakt cin globaal bruikbaar

int main() {
/**En als je het maar een keer gebruikt kun je er ook zo gebruik van maken*/
std :: cout << "namespace test" << std :: endl;

cin.get();
return 0;
}

[Soultaker]

Op maandag 06 mei 2002 13:46 schreef Hieronymus het volgende:
En niet te vergeten een heleboel andere C++ compilers... Voor zover ik mij kan herinneren slikken niet veel compilers de versie zonder ".h"

Ik zou zelfs willen beweren dat geen enkele C++ compiler include-directives pikt. Deze worden namelijk door de preprocessor al verwerkt. Vanuit die overweging vind ik het zelf niet netjes om een notatie te gebruiken zonder extentie, aangezien de preprocessor in principe ook voor andere talen gebruikt kan worden (zoals ook gedaan wordt, bijvoorbeeld voor het compileren van CORBA IDL bestanden). De preprocessor zou zich dus enigszins taalneutraal op moeten stellen (ook al heet 't ding de 'C preprocessor').

De GNU C Preprocessor doet dat dan ook en ondersteund die functionaliteit alleen door (extra) extensieloze include files op te nemen in de distributie, ie. een file 'iostream' die niets doet behalve 'iostream.h' includen (of omgekeerd).

Ik geloof trouwens dat onder de meeste omgevingen (in ieder geval GNU en Microsoft) het weglaten van een extentie wel ondersteund wordt voor standaard C++ headers, dus waarschijnlijk is dat geen probleem.

[MSalters]

Op maandag 06 mei 2002 13:55 schreef markvleth het volgende:
De versie zonder h heeft gewoon te maken met namespaces en komt dus uit c++. Dit is gedaan om ambiguiteit tegen te gaan. Alles is tegenwoordig onder gebracht in de namespace "std". Jammer genoeg staat er in menig C++ boek de hele foute regel:
using namespace std;

Als je dat doet kun je net zo goed gebruik maken van de header files met h erbij.
[KNIP]

<iostream.h> en verwanten verschillen heel sterk per compiler; da's dus een goede reden om 'm niet te gebruiken. bvb <iomanip> is er lang niet altijd in .h variant. Dus using namespace std is bijna net zo slecht als <iostream.h>

[Verwijderd]

Op maandag 06 mei 2002 14:02 schreef Soultaker het volgende:
De GNU C Preprocessor doet dat dan ook en ondersteund die functionaliteit alleen door (extra) extensieloze include files op te nemen in de distributie, ie. een file 'iostream' die niets doet behalve 'iostream.h' includen (of omgekeerd).

Dat is niet helemaal waar, het verschil is toch iets groter dan alleen maar het doorlinken van een header file. Misschien wel in het geval van "iostream" (behalve dus het onderbrengen van de namespace wat dus al anders is ), maar niet in het geval van "cstdlib". Daarbij zijn sommige objecten/classes wel onder gebracht in de de std namespace en andere weer niet. ( bijvoorbeeld NULL )

[Zoijar]

Je gebruikt gewoon nooit <iostream.h> als je standaard C++ compiled, punt. :-) Het is niet "slecht" maar gewoon "fout" hehe. Altijd de headers zonder .h extensie gebruiken.

[Soultaker]

Op maandag 06 mei 2002 14:13 schreef markvleth het volgende:
Dat is niet helemaal waar, het verschil is toch iets groter dan alleen maar het doorlinken van een header file. Misschien wel in het geval van "iostream" (behalve dus het onderbrengen van de namespace wat dus al anders is ), maar niet in het geval van "cstdlib". Daarbij zijn sommige objecten/classes wel onder gebracht in de de std namespace en andere weer niet. ( bijvoorbeeld NULL )

Mijn punt was voornamelijk dat de preprocesser files zonder extentie niet op een speciale manier behandeld. Je beweert dat dit wel zo is? Ik kan me niet herinneren er ooit iets van gemerkt te hebben, maar ik werk dan ook weinig met C++.

Mijn "cstdlib" file include gewoon "stdlib.h" (en stopt abs nog ff bij), maar er gebeurt verder niets bijzonders.

[Verwijderd]

Op maandag 06 mei 2002 14:27 schreef Soultaker het volgende:
Mijn punt was voornamelijk dat de preprocesser files zonder extentie niet op een speciale manier behandeld. Je beweert dat dit wel zo is?

Nee nee nee, dat verhaal klopt als een bus, maar het ging er mij even om dat er iets meer verschil zit tussen header file met of zonder extensie dan jij doet laten voorkomen.

edit :: cstdlib was trouwens een heel fout voorbeeld van mij inderdaad...

[Soultaker]

Op maandag 06 mei 2002 14:31 schreef markvleth het volgende:
maar het ging er mij even om dat er iets meer verschil zit tussen header file met of zonder extensie dan jij doet laten voorkomen.

Ach ja, in die extensie-loze headerfile kan natuurlijk heel ander spul staan dan in de file met extentie, waardoor het wel uitmaakt of je de een of de ander include. De preprocessor en compiler maken dit verschil echter niet.

We zijn het zo geloof ik wel met elkaar eens.

[Verwijderd]

Op maandag 06 mei 2002 14:02 schreef Soultaker het volgende:

[..]

Ik zou zelfs willen beweren dat geen enkele C++ compiler include-directives pikt. Deze worden namelijk door de preprocessor al verwerkt.

Woordfoutje wat ik niet had mogen maken inderdaad... Is alweer eventjes geleden dat ik compilerbouw heb gehad als vak
Met de rest van het verhaal kan ik het alleen maar eens zijn, wel even goede herhaling voor het vak wat ik straks moet gaan afronden....

[.oisyn]

the Ultimate Packer for eXecutables, voor de laatste stap in het kleiner maken van je executable

hij was 46k ik m had ingepakt na optimisen voor size (wat 104k werd)

[Verwijderd]

het was inderdaad Debug, maar nadat ik het had veranderd naar release sloot het proggie automatisch af terwijl dat bij debug niet gebeurde

maar met een

code:

while (!kbhit());

was dat snel opgelost (ook juiste header ge-include uiteraard) ik heb me vandaag ook laten vertellen dat het verschil tussen de iostream newer is dan iostream.h

maarja het gaat erom dat ie het nu doet en ik heb ook weer wat geleerd


maar om maar weer ff een vraag te stellen over headers, waar kan ik nou simpele informatie vinden over bepaalde Headers? waat ze precies doen en waar ik ze voor kan gebruiken. ik vindt conio.h namelijk wel interresant en daar wil ik wel even mee gaan "kloten". maar dat zou een stuk makkelijker zijn als ik wist waar ik goeie informatie kan vinden.

ja ik weet het ik zou hier ook een newe topic voor kunnen hopen, maar het topic blijft hetzelfde nl. Header vraag

iig bedankt voor de vele hulp
MvG
Exci

[Aaargh!]

Op maandag 06 mei 2002 13:45 schreef Soultaker het volgende:
Ik denk dat de statische deel van C++ library (en/of de STL) 'm zo groot maakt. Ik gok dat een C implementatie zo'n 50kb zou worden en dat 'ie met assembly wel onder de 4k is te krijgen, hoewel Windows binaries standaard al enkele kb's groot moeten zijn.

edit:
De C port (ik schijn tijd over te hebben) is 44kb

Ik heb 'm onder linux gecompileerd (de c++ versie) en dan word ie 8kb (8227 bytes) met debuggin symbols en gestripped is ie 6 kb (6104 bytes)

[Verwijderd]

Op maandag 06 mei 2002 12:10 schreef MSalters het volgende:
Standaard oorzaken:
* Debug mode
* Optimize for speed (ipv size) --> deze bedoel ik
* Inline all
* Staticly linked lib (ipv DLL)

<iostream> is goed, <iostream.h> is alleen voor backwards compatibility met VC1.0 t/m 4.2 en dus niet voor nieuwe programma's.

is het gebruikelijk dat de code _toe_ neemt in hoeveelheid om het sneller te krijgen ik dacht altijd des te minder regels das te sneller het is ..

[Soultaker]

Op dinsdag 07 mei 2002 00:01 schreef Aaargh! het volgende:
Ik heb 'm onder linux gecompileerd (de c++ versie) en dan word ie 8kb (8227 bytes) met debuggin symbols en gestripped is ie 6 kb (6104 bytes)

Ik geloof dat MSVC libc altijd statisch linkt. Dat verklaart het verschil in grootte, want dit gebeurt onder (GNU) Linux standaard niet.

In assembly zou 'ie ook onder Windows tot een paar kilobyte teruggebracht kunnen worden.

[Aaargh!]

Op dinsdag 07 mei 2002 00:07 schreef Soultaker het volgende:
Ik geloof dat MSVC libc altijd statisch linkt. Dat verklaart het verschil in grootte, want dit gebeurt onder (GNU) Linux standaard niet.

Kan je dit niet uitzetten dan ?

nogal ruimteverspilling lijkt me.

[.oisyn]

Op dinsdag 07 mei 2002 00:07 schreef Gila het volgende:

[..]

is het gebruikelijk dat de code _toe_ neemt in hoeveelheid om het sneller te krijgen ik dacht altijd des te minder regels das te sneller het is ..

je moet het niet zien in termen van regels. Er zijn enorm veel factoren die ervoor kunnen zorgen dat een programma sneller loopt. Neem bijvoorbeeld data en code alignment... door variabelen en functies op doubleword boundaries, of zelfs quadword boundaries, te alignen, neemt de snelheid toe. Je krijgt hier natuurlijk ook gaten door, aangezien niet alles aansluit. De grootte gaat dan ten koste van snelheid.
Evenals met inline functies. Een functiecall brengt overhead met zich mee, dus sneller zou zijn om dat wat in de functie zou moeten gebeuren direct in het stuk code te zetten wat die functie aangeroepen zou hebben. Ook hier neemt natuurlijk de grootte toe naarmate de functie van meer verschillende plekken wordt aangeroepen

[.oisyn]

met multithreaded DLL runtime lib wordt ie slechts 16k

en ingepakt met upx wordt dat 3.5k

[Verwijderd]

Op maandag 06 mei 2002 13:55 schreef markvleth het volgende:
De versie zonder h heeft gewoon te maken met namespaces en komt dus uit c++. Dit is gedaan om ambiguiteit tegen te gaan. Alles is tegenwoordig onder gebracht in de namespace "std". Jammer genoeg staat er in menig C++ boek de hele foute regel:
using namespace std;

Als je dat doet kun je net zo goed gebruik maken van de header files met h erbij. Het gaat er om dat je alleen objecten een classes "gebruikt" ( keyword using ) die je ook daadwerkelijk toepast, dus bv:

code:

#include <iostream>

using std :: cin;  //maakt cin globaal bruikbaar

int main() {
/**En als je het maar een keer gebruikt kun je er ook zo gebruik van maken*/
std :: cout << "namespace test" << std :: endl;

cin.get();
return 0;
}

using namespace std;

is handiger lijkt me

[.oisyn]

Op dinsdag 07 mei 2002 00:42 schreef Caesium het volgende:

[..]

using namespace std;

is handiger lijkt me

heb je z'n verhaal uberhaupt wel gelezen?

en dan met name de regel

Jammer genoeg staat er in menig C++ boek de hele foute regel:
using namespace std;

[morphje]

Op maandag 06 mei 2002 13:55 schreef markvleth het volgende:
De versie zonder h heeft gewoon te maken met namespaces en komt dus uit c++. Dit is gedaan om ambiguiteit tegen te gaan. Alles is tegenwoordig onder gebracht in de namespace "std". Jammer genoeg staat er in menig C++ boek de hele foute regel:
using namespace std;

Als je dat doet kun je net zo goed gebruik maken van de header files met h erbij. Het gaat er om dat je alleen objecten een classes "gebruikt" ( keyword using ) die je ook daadwerkelijk toepast, dus bv:

code:

#include <iostream>

using std :: cin;  //maakt cin globaal bruikbaar

int main() {
/**En als je het maar een keer gebruikt kun je er ook zo gebruik van maken*/
std :: cout << "namespace test" << std :: endl;

cin.get();
return 0;
}

Dus als ik je goed begrijp.
- Using namespace standaard include dus de godganze lib en maakt het zo groot.
- std :: cout zorgt er alleen voor dat cout geinclude word en de rest niet.

Als ik het zo begrijp is het idd een complete optimizer qua kilobytes. Maar als je nou een groot aantal functies gebruikt uit de iostream lib dan kon using namespaces standaard wel eens makkelijker zijn wat betreft aantal regels en vergeten van includen van bepaalde functies

[MSalters]

Op dinsdag 07 mei 2002 00:07 schreef Gila het volgende:

[..]

is het gebruikelijk dat de code _toe_ neemt in hoeveelheid om het sneller te krijgen ik dacht altijd des te minder regels das te sneller het is ..

Wat .oisyn schreef klopte (we kunnen het wel eens zijn ); daarnaast zijn er nog meer trucs om de code sneller te krijgen. Vergelijk:

code:

for( int i=0; i!=10; ++i )
  a[i]=i;

met

code:

a[0]=0;
a[1]=1;
...
a[9]=9;

Eerste is twee regels, laatste 10. Maar de eerste executen
duurt op sommige processoren langer vanwege de noodzaak i bij te houden. Op andere wint de cache efficiency en is de eerste versie juist sneller.

[Verwijderd]

Op dinsdag 07 mei 2002 09:00 schreef morphje het volgende:

[..]

Dus als ik je goed begrijp.
- Using namespace standaard include dus de godganze lib en maakt het zo groot.
- std :: cout zorgt er alleen voor dat cout geinclude word en de rest niet.

Als ik het zo begrijp is het idd een complete optimizer qua kilobytes. Maar als je nou een groot aantal functies gebruikt uit de iostream lib dan kon using namespaces standaard wel eens makkelijker zijn wat betreft aantal regels en vergeten van includen van bepaalde functies

Ik denk maar even even dat ik refereer naar de preprocessor verhalen aan het begin van dit topic. Namespace heeft niks te maken met wat daadwerkelijk gecompileerd wordt. Dit gaat er gewoon puur om ambiguïteit tegen te gaan. Het voordeel wat je nu hebt is dat je bijvoorbeeld een tweede "cout" zou kunnen hebben in je eigen namspace, een voorbeeld:

code:

#include <iostream>

namespace markvleth{
  class Cout {
    public:
    void operator<< ( const char * nullString ){
    std :: cout << nullString << std :: endl;
    }
  };
  Cout cout;
}

using namespace markvleth;

int main(){
  cout << "maak gebruik van de functie in namespace markvleth";
  std :: cout << "maak gebruik van de functie uit std";
  return 0;
}

[MSalters]

Op dinsdag 07 mei 2002 10:22 schreef markvleth het volgende:

[..]

een voorbeeld:

code:

#include <iostream>

namespace markvleth{
  class Cout {
    public:
    void operator<< ( const char * nullString ){
    std :: cout << nullString << std :: endl;
    }
  };
  Cout cout;
}

using namespace markvleth;

int main(){
  cout << "maak gebruik van de functie in namespace markvleth";
  std :: cout << "maak gebruik van de functie uit std";
  return 0;
}

En dan is er iemand zo vriendelijk om dit er voor te zetten:

code:

namespace markvleth {
  namespace std {
    int cout; // ::markvleth::std::cout
  }
}

Als je dit soort grappen aan het uithalen bent kun je beter jezelf indekken met ::std::cout