10
votes

Pourquoi les caractères @ et $ $ sont-ils utilisés pour rien dans C et C ++?

Dans les deux langues L'ensemble de caractères source de base comprend chaque caractère ASCII imprimable, sauf @ , $ et `. Je peux comprendre n'utilisant pas d'accent grave car il n'est pas toujours interprété comme un personnage séparé et il semble également très similaire à l'apostrophe. Mais y a-t-il une raison spécifique pour laquelle @ et $ n'a-t-il aucune utilisation ou que les concepteurs de langue ne sont-ils pas venus à court d'idées? :)


11 commentaires

Je suppose que cela a probablement quelque chose à voir avec de vieilles mises en page de clavier, mais je serais intéressé à entendre la vraie raison.


@ est utilisé dans l'objectif-c qui est strict superset de C et sera cassé si c l'utilise. Environ $ je ne sais pas. Pourquoi pensez-vous qu'ils devraient être utilisés?


Probablement garder des personnes qui veulent construire un sain de préprocesseurs C "préprocesseurs" personnalisés, en leur donnant des caractères d'évacuation sûrs :)


Devrait utiliser chaque personnage être un objectif dans la conception de la langue?


¥ et € n'utilisez pas non plus, parlez de discrimination.


Historiquement VI Editor a été trouvé autour du cadre de l'heure de langue C . Et dans VI éditeur, en fait $ notifie interne le sens de fin de ligne (bien qu'il ne soit pas utilisé explicitement). Cependant, @ peut avoir de bons usages; Cela aurait dû être dans la langue.


@LAURENT: ¥ et € ne sont pas ASCII.


Si leur objectif était de trouver une signification pour chaque caractère de ponctuation sur le clavier, ils auraient créé Perl; ^)


@Thilo: Ne pas oublier que c ande l'euro par quelques décennies.


DCER C autorisé en identifiant.


Certaines des réponses sont moins bonnes que la question, mais je ne sais pas que c'est la faute de la question. La question ressemble à une bonne question à laquelle personne ne connaissait la réponse. Rouvrir.


5 Réponses :


1
votes

Je ne vois aucune raison spécifique à leur utilisation.

Je veux dire, peut-être $ et @ aurait pu être utilisé pour désigner des scalaires et des tableaux comme dans Perl, mais je vois peu d'avantages dans l'ajout d'un caractère pour chaque nom de variable .

Aussi, en C, les tableaux ne sont vraiment que du sucre syntaxique pour les pointeurs, ils peuvent donc être utilisés dans un contexte scalaire de tri.

Peut-être qu'ils auraient pu être autorisés dans des noms de variables comme tout autre caractère valide.

ou peut-être que la raison est juste qu'ils n'en pensaient pas parce qu'il n'y avait vraiment aucune raison de les mettre.

aller demander k & r :)


4 commentaires

$ est une partie valide d'un identifiant dans Scala, Java et JavaScript - il ne doit pas être strictement à être pour les sigils. (Un identifiant qui contient une $ en Java ou Scala pourrait être pour un nom de classe généré automatiquement.)


Les tableaux sont pas juste du sucre syntaxique pour les pointeurs.


@Fred: vous avez lié à une FAQ C ++. Votre assertion est-elle également vraie pour C?


@ROBERT: Dans les deux langues, un tableau est un espace de stockage réel, c'est-à-dire un tableau de 10 éléments a une taille de 10 * Tailleof (élément), tandis qu'un pointeur est simplement une variable contenant une adresse. Pour que l'on puisse affecter un tableau à un pointeur du même type de base est une commodité. Mais un tableau n'est pas que du sucre syntaxique pour un pointeur.



5
votes

Je ne peux pas imaginer quelle capacité ils rempliraient. Peut-être utiliser @ pour signifier des pointeurs ...

mais $ et @ sont des symboles d'apparence très occupés, peut-être presque distrayant, et si vous les jetez dans le mélange avec une syntaxe déjà diverse, juste parce qu'ils sont Là, vous risquez de finir par avoir une langue qui lit comme une plus grande réégalité de Perl. Ce qui est de dire que cela ne lit pas du tout. : P


3 commentaires

De nombreuses implémentations Pascal utilisent "$" comme préfixe hexagonale. Beaucoup supérieur au 0x volumineux et laids.


@supercat - il doit être agréable de taper un $ suivi de huit chiffres. : P


Plus souvent deux ou quatre chiffres. En utilisant "0x" comme préfixe hexagonale, des octets séparés par des virgules prennent cinq caractères chacun et les mots séparés par des virgules prennent sept. Même seize octets ou douze mots d'entre eux envelopperont une ligne de 80 caractères. En utilisant "$" en tant que préfixe hexagonale, les octets séparés par des virgules prennent quatre caractères, que ce soit écrit en hexagonale ou en décimal, ainsi que des mots 16 bits en prenant six. Seize octets séparés par des virgules conviendront en 64 caractères et dix mots sélarés par des virgules conviendront à 70. BTW, je vais accorder que le "0x" pour Hex n'est pas aussi horrible que "0" pour l'octal. C'est juste le mal.



2
votes

La première question que vous devriez demander est: "Pourquoi seuls certains caractères sont-ils autorisés dans la fonction C / C ++ et les noms de variables"?

Même je ne suis pas assez vieux pour répondre à cela ... mais je parierais beaucoup de caractères spéciaux (en particulier $ ) n'étaient pas légaux dans des symboles externes dans l'UNIX d'origine. C'est-à-dire que l'assembleur et la lieur vous étoufferaient.

Donc, la seule utilisation pour les caractères non alphanumériques était dans les opérateurs, comme + ou -> . Les concepteurs d'origine avaient probablement tous les opérateurs dont ils avaient besoin, il n'y avait donc aucune raison d'utiliser $ ou @ ou autre. (Comment faites-vous la coche arrière, de toute façon?)

Avec l'avènement de C ++ et Name Mangling, la plupart des restrictions sur les noms d'identifiant pourraient probablement être levées. Mais même le comité C ++ ne va pas casser avec la tradition sans raison.

Quoi qu'il en soit, c'est juste ma supposition. Je sais que pour répondre à votre question de manière définitive, vous devrez pratiquement vous transporter à 1973 ...


0 commentaires

1
votes

Peut-être que le comité des normes a laissé ces personnages car il y avait beaucoup de personnages à choisir et ils ont simplement trouvé que celles-ci étaient étranges. Nous ne pouvons jamais connaître la justification de pourquoi pas sauf si une personne du comité des normes répond en réalité.

Au moins $ est pris en charge comme identifiant valide dans MSVC & GCC par les extensions.

Le code suivant compile tous les deux: xxx


1 commentaires

Ces décisions ont eu lieu longtemps avant que C n'était même près de tout comité de normes.



3
votes

@ était une mauvaise idée parce que c'était le caractère de tuer. Si vous tapez dans un programme et que vous avez frappé accidentellement @, vous avez effacé toute la ligne d'entrée jusqu'à ce point.

# était plus ou moins une mauvaise idée parce que c'était le caractère effaçable. Si vous tapez dans un programme et que vous frappiez accidentellement #, vous avez effacé le caractère le plus récent.

Lorsque le préprocesseur a été ajouté au langage C, # a été accepté dans la première colonne d'une ligne, mais pas nulle part ailleurs. Donc, peut-être que ED a été modifié pour permettre à # d'être entré comme premier caractère d'une ligne, car il n'y avait rien avant de s'effacer.

Alors pourquoi le préprocesseur n'a-t-il pas utilisé $ au lieu de #? Nous y allons, j'ai répondu la moitié de votre question mais j'ai ajouté à l'autre moitié de votre question.

Les articles de journaux n'avaient pas l'habitude d'inclure le caractère @. Une fois que l'Internet est devenu courant, certains journalistes ou éditeurs mettent la chaîne de 4 caractères »(AT)» dans les articles de journaux car ils ne pouvaient pas ou n'utiliseraient pas une séquence d'échappement pour mettre un @ dans l'article. La définition du personnage de Kill de Unix a été copiée des équipements de journaux.

http://fr.wikipedia.org/wiki/seventh_edition_unix_terminal_interface


4 commentaires

Pascal (légèrement plus âgé que C, IIRC), utilisé @ comme opérateur d'adresse. ;-)


Pascal n'a pas été conçu en tandem avec UNIX, n'a pas copié le caractère de tuer des équipements de presse et n'a pas utilisé à l'origine des accolades frisées ni d'autres caractères dépendants des États-Unis.


Oui, eh bien, cela peut être vrai. Apparemment, pour WIRTH, @ n'était pas une mauvaise idée et pas un "caractère de tuer".


Oui, je suis d'accord, pour WIRTH @ n'était pas une mauvaise idée car il n'a pas développé Pascal en tandem avec UNIX et UNIX copiée @ de l'équipement de journal en tant que caractère de tuer lors de la saisie d'une contribution non utilisée par des compilateurs. Si c n'était pas développé en tandem avec UNIX, je parie que cela utiliserait @. Si UNIX utilisée à l'origine de l'espace retourné et de contrôle-x comme il le fait souvent maintenant, je parie @ n'aurait pas été une mauvaise idée dans les langages de programmation développés en tandem avec UNIX.