Doit C++ éliminer les fichiers d'en-tête?

Rétro-Compatibilité - fichiers d'en-Tête ne sont pas éliminés parce qu'il allait se casser la Compatibilité ascendante.

Même Bjarne Stroustrup a appelé les fichiers d'en-tête une bidouille.

Mais sans un standard format binaire qui contient les métadonnées (comme les fichiers de classe Java, ou .Net fichiers PE) je ne vois pas de toute façon de mettre en œuvre la fonctionnalité. Une dépouillé d'un ELFE ou d'un.binaire n'a pas beaucoup d'informations que vous auriez besoin de les extraire. Et je ne pense pas que l'information est stockée dans Windows XCOFF fichiers.

C a été fait pour rendre l'écriture d'un compilateur facilement. Il fait BEAUCOUP de choses basées sur ce principe. Les pointeurs n'existent que pour faire de l'écriture d'un compilateur plus facile, comme le font les fichiers d'en-tête. Beaucoup de choses reporté à C++ sont basés sur la compatibilité avec ces fonctionnalités mises en œuvre pour faire compilateur écrit plus facile.

C'est une bonne idée en fait. Quand C a été créé, C et Unix étaient une sorte de paire. C portage d'Unix, Unix couru C. De cette façon, C et Unix peut rapidement se propager à partir de la plate-forme alors qu'un OS basé sur l'assemblée a dû être complètement ré-écrit pour être porté.

Le concept de la spécification d'une interface dans un fichier, et la mise en œuvre dans un autre n'est pas une mauvaise idée du tout, mais ce n'est pas ce que C fichiers d'en-tête sont. Ils sont simplement un moyen de limiter le nombre de passes d'un compilateur a faire par l'intermédiaire de votre code source et de permettre à certains limité abstraction du contrat entre les fichiers afin qu'ils puissent communiquer.

Ces éléments, les pointeurs, fichiers d'en-tête, etc... n'offrent pas vraiment un avantage par rapport à un autre système. En mettant le plus d'efforts dans le compilateur, vous pouvez compiler un objet de référence, aussi facilement qu'un pointeur vers l'exact même code objet. C'est ce que le C++ ne l'est aujourd'hui.

C est un grand, un langage simple. Il avait un nombre très limité de fonctionnalités, et vous pourriez écrire un compilateur sans trop d'effort. Le portage est généralement trivial! Je ne suis pas en train de dire que c'est un mauvais langage ou rien, c'est juste que C principaux objectifs quand il a été créé peuvent laisser des fragments dans la langue qui sont plus ou moins inutiles maintenant, mais vont être conservés à des fins de compatibilité.

---

Il semble que certaines personnes ne crois pas vraiment que C était écrit à port Unix, donc ici: (à partir de)

La première version d'UNIX a été écrit
en langage assembleur, mais Thompson
l'intention était qu'il serait écrit
dans un langage de haut niveau.

Thompson a d'abord essayé en 1971 à utiliser
Fortran sur le PDP-7, mais il a abandonné
après la première journée. Puis il a écrit un
un langage très simple, il a appelé B,
lequel il a obtenu le PDP-7. Il
travaillé, mais il y avait des problèmes.
D'abord, parce que la mise en œuvre a été
interprété, il a toujours été va être
lent. Deuxièmement, les notions de base B,
qui était basée sur le mot-orienté
BCPL, tout n'était pas bon pour un
octet-orienté de la machine comme le nouveau
PDP-11.

Ritchie utilisé le PDP-11 pour ajouter des types de
pour B, qui pour un certain temps a été appelé NB
pour "New B", et puis il a commencé à
écrire un compilateur pour elle. "De sorte que le
première phase de la C était vraiment ces deux
les phases en bref succession d', d'abord,
certains changements de langue à partir de B, vraiment,
l'ajout de la structure de type sans trop
beaucoup de changement dans la syntaxe; et faire
le compilateur," Ritchie dit.

"La deuxième phase a été plus lente," dit-il
de la réécriture d'UNIX dans C. Thompson
débuté à l'été 1972, mais a
deux problèmes: trouver comment exécuter
la base de la co-routines, qui est, comment
interrupteur de contrôle d'un processus à
l'autre; et la difficulté à obtenir le
la bonne structure de données, depuis la
la version originale de C n'ont pas
les structures.

"La combinaison de la les choses causé
Ken abandonner au cours de l'été,"
Ritchie a dit. "Au cours de l'année, j'ai ajouté
les structures et les a probablement fait l'
compilateur de code un peu mieux --
meilleur code -- et donc, au cours de la prochaine
l'été, c'était lorsque nous avons fait l'
des efforts concertés et en fait n'a refaire
l'ensemble du système d'exploitation dans C."

---

Ici est un parfait exemple de ce que je veux dire. À partir des commentaires:

Les pointeurs n'existent que pour faire de l'écriture d'un compilateur plus facile? Pas de. Les pointeurs existent parce qu'ils sont la plus simple possible abstraction au-dessus de l'idée d'indirection. – Adam Rosenfield (d'une heure)

Vous avez raison. Afin de mettre en œuvre indirection, les pointeurs sont les plus simples possible d'abstraction à mettre en œuvre. En aucune manière sont-ils les plus simples possible afin de les comprendre ou de les utiliser. Les tableaux sont beaucoup plus facile.

Le problème? Pour mettre en œuvre des tableaux de manière aussi efficace que les pointeurs vous avez à peu près l'ajout d'un ÉNORME tas de code de votre compilateur.

Il n'y a pas de raison qu'ils ne pouvaient pas conçues C sans pointeurs, mais avec ce code:

int i=0;
while(src[++i])
    dest[i]=src[i];

il va prendre beaucoup d'efforts (sur les compilateurs partie) afin de tenir compte de manière explicite de la i+src et i+dest ajouts et de faire créer le même code que cela ferait:

while(*(dest++) = *(src++))
    ;

D'affacturage que la variable "i" après la réalité est DIFFICILE. De nouveaux compilateurs peuvent le faire, mais à l'époque, il n'était tout simplement pas possible, et le système d'exploitation s'exécutant sur cette merde de matériel nécessaire peu d'optimisations comme ça.

Maintenant, peu de systèmes ont besoin de ce genre d'optimisation (je travaille sur l'un des plus faibles des plates-formes autour-de décodeurs câble, et la plupart de nos affaires est en Java) et dans les rares cas où vous pourriez avoir besoin d'elle, les nouveaux compilateurs C devrait être assez intelligent pour faire ce genre de conversion sur son propre.

Un de C++objectifs est d'être un sur-ensemble de C, et il est difficile pour elle de le faire si il ne peut pas soutenir fichiers d'en-tête. Et, par extension, si vous souhaitez d'accise fichiers d'en-tête vous pouvez envisager aussi bien l'excision du RPC (le pré-processeur, pas plus-plus) en tout; C# et Java ne spécifiez pas de macro pré-processeurs avec leurs normes (mais il convient de noter que dans certains cas ils peuvent être et sont même utilisées, même avec ces langues).

Que C++ est conçu droit maintenant, vous avez besoin de prototypes, un peu comme en C -- statiquement vérifier tout le code compilé que les références externes de fonctions et de classes. Sans les fichiers d'en-tête, vous devez taper ces définitions de classe et les déclarations de fonction avant de les utiliser. Pour le C++ de ne pas utiliser les fichiers d'en-tête, vous devez ajouter une fonction dans la langue qui serait en charge de quelque chose comme Java import mot-clé. Ce serait un ajout majeur, et de changement; pour répondre à votre question de savoir s'il serait pratique: je ne crois pas, pas du tout.

Bien, C++ en soi ne devrait pas éliminer les fichiers d'en-tête en raison de la compatibilité. Cependant, je ne pense qu'ils ont une idée stupide en général. Si vous souhaitez distribuer un code source fermé lib, ces informations peuvent être extraites automatiquement. Si vous voulez comprendre comment utiliser une classe w/o à la recherche à la mise en œuvre, c'est ce que la documentation générateurs sont pour, et ils font un diable de beaucoup mieux un emploi.

Un avantage de cette séparation, c'est qu'il est facile d'afficher uniquement l'interface, sans nécessitant une avancé de l'éditeur.

Aucune langue n'existe sans les fichiers d'en-tête. C'est un mythe.

De regarder n'importe quel propriétaire de la bibliothèque de la distribution de Java (je n'ai pas le C# de l'expérience à proprement parler, mais j'imagine que c'est la même chose). Ils ne vous donnent pas l'complet du fichier source; ils viennent de vous donner un fichier avec toutes les méthodes de mise en œuvre du vide ({} ou {return null;} ou similaires) et tout ce qu'ils peuvent s'en tirer avec de cacher caché. Vous ne pouvez pas appeler que rien, mais un en-tête.

Il n'y a pas de raison technique, cependant, pourquoi un C ou C++ compilateur a pu compter tout au bien-fichier marqué comme extern à moins que ce fichier est compilé directement. Cependant, les coûts de la compilation serait immense, parce que ni C ni C++ est rapide à analyser, et c'est une considération très importante. Plus complexe, la méthode de fusion des en-têtes et une source de rapidement rencontrer des problèmes techniques, comme la nécessité pour le compilateur pour connaître un objet de mise en page.

Oh Oui!

Après le codage en Java et C# c'est vraiment ennuyeux d'avoir 2 fichiers pour toutes les classes. Donc, je pensais à comment puis-je les fusionner sans casser le code existant.

En fait, c'est vraiment facile. Il suffit de mettre la définition (mise en œuvre) à l'intérieur d'un #ifdef l'article et ajouter une définition sur la ligne de commande du compilateur pour compiler ce fichier. C'est tout.

Voici un exemple:

/* File ClassA.cpp */

#ifndef _ClassA_
#define _ClassA_

#include "ClassB.cpp"
#include "InterfaceC.cpp"

class ClassA : public InterfaceC
{
public:
    ClassA(void);
    virtual ~ClassA(void);

    virtual void methodC();

private:
    ClassB b;
};

#endif

#ifdef compiling_ClassA

ClassA::ClassA(void)
{
}

ClassA::~ClassA(void)
{
}

void ClassA::methodC()
{
}

#endif

Sur la ligne de commande, de compiler ce fichier avec

-D compiling_ClassA

Les autres fichiers doivent inclure des ClassA suffit de faire

#include "ClassA.cpp"

Bien sûr l'ajout de la définir sur la ligne de commande peuvent facilement être ajoutées à l'aide d'une macro d'extension (compilateur Visual Studio) ou avec un système automatique de variables (gnu make) et en utilisant la même nomenclature pour la définir un nom.