Je ne suis pas capable de comprendre cela. S'il vous plaît expliquer.
EDIT STRY>: IT Impression: 'Hello, World!' Code> P> #include <stdio.h>
int i;
main()
{
for(;i["]<i;++i){--i;}"];read('-'-'-',i+++"hell\o, world!\n",'/'/'/'));
//For loop executes once, calling function read with three arguments.
}
read(j,i,p)
{
write(j/p+p,i---j,i/i); //how does it work? like printf?
}
3 Réponses :
*((i) + (the string given))
Ce que vous avez expliqué n'est pas aussi obscurci. La seule partie de message est i ["] . Et ça?
@Tesséract ne serait pas le support carré le plus à droite (pour (; i ["] ] b>) soit inégalé, alors?
@computerfreaker regarde de cette façon: i ["..."] code> Non, le dernier support carré droit ne serait pas inégalé, le support carré droit est un littéral.
@CIPHERMAGI Le commentaire Je répondais à avoir interprété la séquence comme i [34] car "est 34 en décimal, qui me confondre depuis le plus à droite Le support carré serait inégalé à ce moment-là.
@ComputerFreaker Il doit avoir supprimé le commentaire, puis.
Oui, je viens de comprendre que bientôt que je l'avais posté, a supprimé mon commentaire. Pardon.
@CIPHERMAGI OUI. @HACCKS Je pense presque que cela fait une itération étrange à travers un tableau de caractères. pour (; code> signifie "Démarrer A pour la boucle sans valeur initiale." i ["] sève Un tableau de caractères de la même longueur que la chaîne "Hello World". ; lire ( code> appelle la fonction de lecture sur chaque itération de la boucle; i code> est incrémenté dans l'appel code> code> par opposition à l'incrémentation habituelle que vous " d Trouvez dans A pour boucle. Donc, si je corrige que ce code s'exécute jusqu'à ce que i code> atteigne la fin de son tableau de caractères. Le fait que le tableau de caractères ressemble à un code valide est probablement destiné à provoquer une confusion.
"string" [i] code> et i ["string"] code> sont identiques en C en raison de la manière dont ces crochets sont définis comme un raccourcité pour l'addition et la désérofacturation.
Briser est en panne, vous avez:
i---j
... Sauf que i code> (le global) commence par une valeur non définie, de sorte qu'elles utilisent réellement une mémoire d'accès aléatoirement.
"I 'est défini dans la zone" globale "afin qu'il recommencera toujours d'être zéro. Voir initialisation de la variable statique
Pouvez-vous doigter le papier sur papier? La logique et les preuves secondaires montrent que je me trompe, mais pouvez-vous finir cette pensée? Par exemple. Dans la spécification C99 à Open-std.org/jtc1 /sc22/wg14/www/docs/n1124.pdf ?
Pourquoi \ o code> intérieur "Hell \ o, monde!" Code> imprimé comme simple o code>? Je n'ai pas pu trouver cette séquence d'échappement.
Les codes d'échappement non définis sont pris par la plupart des compilateurs juste pour être le personnage. C'est un mal direct. Par exemple. Microsoft le mentionne comme "Microsoft spécifique" dans MSDN.MICROSSOFT.COM/EN- US / Bibliothèque / H21280BW.aspx
@HALEX: En fait, je pense que dans la version originale, la ligne était scindée en deux et que la barre oblique inverse a été utilisée comme caractère de continuation de la ligne. Il fonctionne de toute façon parce que des séquences d'échappement inconnues sont généralement traitées comme le caractère lui-même (probablement pas standard, mais c'est un comportement généralisé).
Voir d'abord la syntaxe de lire code> et écrire code> fonctionner dans C et ce qu'ils font: write(j/p+p, i-- -j, i/i);
codewiki.wikidot.com/c:system-calls:write
Ce code invoque un comportement non défini à coup sûr.
En plus de ma réponse ci-dessous, voir CODEPAD.ORG/LUXVBKZS - sur ce compilateur Le programme ne produit aucune sortie. Votre code est dépendant du compilateur.
lien fonctionne ici
@HACCKS et quiconque le prélevé, où est exactement l'UB?
OP, C ++ est pas i> un superset de C. Certains Code C - tels que celui-ci - est pas i> valide C ++ -> Étiquette C ++ supprimée.
@Schighschagh; J'ai édité ma réponse. Lisez-le pour l'explication "Pourquoi cela invoque un comportement indéfini?".