Is het juist om gewoon alle header-bestanden op te nemen?

Het onthouden van de namen van systeemkopregelbestanden is lastig ...

Is er een manier om alle bestaande header-bestanden in één keer op te nemen?

Waarom doet niemand dat?

2
Natuurlijk is er een weg ". Maar het is geen goed idee. Misschien weten de meer ervaren C-programmeurs gewoon weten waar hun afhankelijkheden worden verklaard en bevatten ze alleen wat ze nodig hebben met volledig bewustzijn.
toegevoegd de auteur Kerrek SB, de bron
Als dit een goed idee was, zou er maar 1 header-bestand voor de volledige taal zijn
toegevoegd de auteur Adrian Cornish, de bron
Ik vind het een ongelooflijk slecht idee!
toegevoegd de auteur ldav1s, de bron
@AdrianCornish IIRC, een zeer vroege pre-STL C ++ standaardbibliotheek-draft had precies dat ... de header die alle C ++ headers bevatte. In een vlaag van gezond verstand raakten ze het kwijt ... en de rest van de tocht en begonnen opnieuw met STL.
toegevoegd de auteur ldav1s, de bron
Sarcasme hoort niet in een antwoord. Antwoorden zijn alleen dat - antwoorden op vragen.
toegevoegd de auteur Ken White, de bron
@ Nate, ik heb nooit gezegd dat er geen humor of sarcasme in een antwoord zou moeten zijn. Ik zei dat humor of sarcasme het niet antwoord zou moeten vormen zonder andere inhoud. Ik heb eigenlijk wat mijn vrienden en kennissen een goed gevoel voor humor noemen (dat zeggen ze sowieso). Humor/sarcasme met niets anders moet worden gemaakt als commentaar, niet gepost als antwoorden op vragen. Deze site is gedeeltelijk goed omdat er niet veel ruis en rommel in de vragen en antwoorden is; Ik ben er voor om het zo te houden. :) Ik heb niemand onderschreven, als u het opmerkt - ik gaf ldav1s de mogelijkheid om het antwoord te verwijderen.
toegevoegd de auteur Ken White, de bron
Als het zo moeilijk is om te onthouden, kunt u de eclipse en de functie "toevoegen toevoegen" gebruiken.
toegevoegd de auteur Nate, de bron

6 antwoord

Het opnemen van overbodige header-bestanden is een zeer slechte oefening. Het probleem van het vertragen van de compilatie kan of kan er niet toe doen; het grotere probleem is dat het afhankelijkheden verbergt . De verzameling headerbestanden die u in een bronbestand opneemt, moet de documentatie zijn van welke functionaliteit de module afhankelijk is, en in tegenstelling tot externe documentatie of opmerkingen, wordt deze automatisch gecontroleerd op volledigheid door de compiler (het niet opnemen van de benodigde headerbestanden resulteert in een fout). Zorgen voor de afwezigheid van ongewenste afhankelijkheden verbetert niet alleen de draagbaarheid; het helpt u ook onnodige en potentieel gevaarlijke interacties op te sporen, bijvoorbeeld gevallen waarbij een module die zuiver computationeel of zuiver datastructuurbeheer moet zijn, toegang heeft tot het bestandssysteem.

Deze principes zijn van toepassing ongeacht of de headers standaardsysteemheaders of headers voor modules binnen uw eigen programma of externe bibliotheken zijn.

9
toegevoegd

Niemand bevat alle header-bestanden. Er zijn te veel, en een paar van hen sluiten elkaar uit met andere bestanden (zoals ncurses.h en curses.h).

Het is echt niet zo erg als je een programma zelfs vanuit het niets schrijft. Een paar zijn vrij gemakkelijk te onthouden: stdio.h voor alle FILE dingen; ctype.h voor elke karakterclassificatie, alloc.h voor elk gebruik van malloc (), etc.

Als je er nog geen weet:

  • laat de # include out
  • achter
  • compile
  • onderzoek de eerste paar foutmeldingen op indicatie van een ontbrekend header-bestand, zoals een niet-gedeclareerd type, of roep een functie op met veronderstelde parametertypen
  • zoek uit welke functieaanroep de oorzaak is
  • kijk naar de man-pagina (of welke documentatie je compiler dan ook heeft) voor die functie
  • let op de # include die wordt weergegeven in de documentatie en voeg deze toe
  • herhalen totdat alle fouten zijn opgelost

Het is een stuk eenvoudiger om toe te voegen aan een bestaande codebasis. U kunt honderden of duizenden werkuren maken en nooit een # opnemen toevoegen.

5
toegevoegd

Uw broncodebestanden worden vooraf verwerkt voordat de compiler ze bekijkt en de # include -instructie is een van de richtlijnen die de preprocessor gebruikt. Wanneer ze worden voorverwerkt, worden # include -instructies vervangen door de volledige inhoud van het bestand dat wordt opgenomen. Het resultaat van het opnemen van alle systeembestanden zou bestaan ​​uit zeer grote bronbestanden die de compiler vervolgens moet verwerken, wat veel tijd kost tijdens het compileren.

5
toegevoegd

Nee, het is een vreselijk idee en zal je compileertijden enorm verhogen en mogelijk je exe een stuk groter maken door enorme hoeveelheden ongebruikte code op te nemen.

1
toegevoegd
@ Oli - waarschijnlijk gelijk met C - Ik dacht meer aan C ++ dat een lading extra sjablooncode kon genereren.
toegevoegd de auteur Adrian Cornish, de bron
Dit zou geen invloed moeten hebben op de exe-grootte.
toegevoegd de auteur Oliver Charlesworth, de bron

Ik weet waar je het over hebt, maar ik moet de functieprototypes controleren voor de functies die ik gebruik (voor degenen die ik niet dagelijks gebruik) - ik kopieer en plak gewoon de # omvat rechtstreeks uit de manpage voor de bijbehorende functies. Ik kijk nu al naar de manpage (het is een simpele K in vim (1) ), dus het voelt niet als een extra last.

1
toegevoegd

U kunt een 'hoofd'-header maken, waarin u al uw deelnamen invoegt. Dan is in al het andere het inbegrepen! Pas op voor conflicterende definities en circulaire verwijzingen ... Dus .... Master1.h, master2.h, ...

Ik pleit er niet voor. Gewoon zeggen.

1
toegevoegd