Qui architecturé / conçu C++ ' s IOStreams, et encore sera-t-il considéré bien conçu par aujourd'hui ' normes s ?

Question

Tout d'abord, il peut sembler que je suis en demandant des avis subjectifs, mais ce n'est pas ce que je suis après. J'aimerais beaucoup connaître le bien-fondé des arguments sur ce sujet.

---

Dans l'espoir d'obtenir un aperçu de la façon moderne des flux / de sérialisation cadre doit donc être conçu, récemment, j'ai eu moi-même un exemplaire du livre de C++ Standard IOStreams et les paramètres régionaux par Angelika Langer et Klaus Kreft. J'ai pensé que si IOStreams n'a pas été bien conçu, il n'aurait pas fait dans la norme C++ de la bibliothèque dans la première place.

Après avoir lu les différentes parties de ce livre, je commence à avoir des doutes si IOStreams peut comparer par exemple à la STL à partir d'un ensemble architectural de point de vue. Lire par exemple cet entretien avec Alexander Stepanov (de la STL, "inventeur") pour en savoir plus sur les décisions de conception qui est entré dans la STL.

Ce qui me surprend en particulier:

• Il semble être inconnu qui était responsable de IOStreams' ensemble de la conception (je serais ravi de lire quelques informations à propos de ce — que quelqu'un connait de bonnes ressources?);

• Une fois que vous plongez sous la surface immédiate de IOStreams, par exemple, si vous souhaitez étendre IOStreams avec vos propres classes, vous obtenez une interface avec assez énigmatique et déroutant membre des noms de fonction, par exemple, getloc/imbue, uflow/underflow, snextc/sbumpc/sgetc/sgetn, pbase/pptr/epptr (et il y en a probablement pire des exemples). Cela rend les choses beaucoup plus difficile de comprendre l'ensemble de la conception et de la façon dont les différentes parties de coopérer. Même le livre que j'ai mentionné ci-dessus n'aide pas que beaucoup (à mon humble avis).

---

Donc ma question:

Si vous aviez à en juger par les logiciels d'aujourd'hui les normes d'ingénierie (si il y en est de parvenir à un accord général sur ces), serait de C++IOStreams encore être considéré comme un bien conçu? (Je ne veux améliorer mon logiciel de compétences en conception de quelque chose qui est généralement considéré comme obsolète.)

Answer 1

Plusieurs malades idées préconçues trouvé leur chemin dans le standard: auto_ptr, vector<bool>, valarray et export, pour n'en nommer que quelques-uns. Je ne voudrais pas tenir compte de la présence de IOStreams nécessairement comme un signe de la qualité de la conception.

IOStreams ont une histoire mouvementée. Ils sont en fait une modification d'un premier flux de la bibliothèque, mais ont été créés à une époque où beaucoup d'aujourd'hui, du C++ idiomes n'existe pas, donc les concepteurs n'ont pas l'avantage du recul. Une question qui n'est apparu qu'au fil du temps, il est presque impossible de mettre en œuvre IOStreams aussi efficacement que C est stdio, en raison de l'abondante utilisation de fonctions virtuelles et le transfert vers la mémoire tampon interne des objets à même le meilleur niveau de granularité, et aussi grâce à quelques insondables de l'étrangeté dans la façon dont les paramètres régionaux sont définis et mis en œuvre. Ma mémoire est assez floue, je vous l'avoue; je me souviens qu'il soit l'objet d'un intense débat il y a quelques années, sur comp.lang.c++.modérés.

Answer 2

Si vous aviez à en juger par aujourd'hui génie logiciel des normes (si il y a en fait aucune générales l'accord sur ces), serait de C++ IOStreams encore être considérée comme bien conçu? (Je ne veux pas améliorer mon logiciel de compétences en conception de quelque chose qui est généralement considéré comme dépassée.)

Je dirais PAS, pour plusieurs raisons:

La mauvaise gestion des erreurs

Conditions d'erreur doit être signalée à quelques exceptions près, pas avec operator void*.

La "zombie objet" anti-modèle est quelles sont les causes de bugs comme ces.

Mauvaise séparation entre la mise en forme et I/O

Cela rend les objets de flux inutilement complexe, car ils doivent contenir supplémentaire les informations d'état pour la mise en forme, si vous en avez besoin ou pas.

Elle augmente également les chances de l'écriture de bugs comme:

using namespace std; // I'm lazy.
cout << hex << setw(8) << setfill('0') << x << endl;
// Oops!  Forgot to set the stream back to decimal mode.

Si au lieu de cela, vous avez écrit quelque chose comme:

cout << pad(to_hex(x), 8, '0') << endl;

Il n'y aurait pas de mise en forme sur l'état des bits, et pas de problème.

Notez que dans "moderne" des langues comme Java, C# et Python, tous les objets ont un toString/ToString/__str__ fonction qui est appelée par le I/O de routines. Autant que je sache, seulement le C++ est-il dans l'autre sens en utilisant stringstream que le niveau moyen de la conversion d'une chaîne de caractères.

Mauvais support i18n

Iostream la sortie divise les littéraux de chaîne en morceaux.

cout << "My name is " << name << " and I am " << occupation << " from " << hometown << endl;

Les chaînes de Format des phrases entières dans les littéraux de chaîne.

printf("My name is %s and I am %s from %s.\n", name, occupation, hometown);

Cette dernière approche est plus facile de s'adapter à l'internationalisation des bibliothèques comme la GNU gettext, parce que l'utilisation de l'ensemble des phrases fournit plus de contexte pour les traducteurs. Si votre chaîne de formatage routine prend en charge la réorganisation (comme la POSIX $ printf paramètres), puis il est aussi mieux poignées de différences dans l'ordre des mots entre les langues.

Answer 3

j'ai toujours trouvé le C++ IOStreams mal conçue: leur mise en œuvre fait qu'il est très difficile de bien définir un nouveau type de flux. ils ont également mélanger io caractéristiques et les fonctionnalités de mise en forme (penser à des manipulateurs).

personnellement, le meilleur flux de conception et de mise en œuvre que j'ai jamais trouvé réside dans le langage de programmation Ada. c'est un modèle à découplage, une joie de créer un nouveau type de flux, et les fonctions de sortie de toujours travailler quel que soit le flux utilisé. c'est grâce à un plus petit dénominateur commun: vous les octets de sortie d'un cours d'eau. fonctions flux de prendre soin de mettre les octets dans le flux, il n'est pas leur travail, par exemple le format d'un nombre entier en hexadécimal (bien sûr, il y a un ensemble d'attributs de type, équivalent à un membre de la classe, définie pour le traitement de mise en forme)

je souhaite que le C++ était aussi simple concernant les cours d'eau...