Je ne comprends pas ce C/C++ Blague

Question

Après la lecture de cet article sur thedailywtf.com je ne suis pas sûr que j'ai vraiment eu la blague.

Cela dit il n'y a qu'un mec a changé le code de

int function() 
{ 
  int x;
  char data_string[15];
  ...
  x = 2;
  strcpy(data_string,"data data data");
  ...
}

pour

int function() 
{
  int x = 2;
  char data_string[15] = "data data data";
  ...
}

partout dans le code et que, pour une raison quelconque n'a gonfler la taille de l'exécutable à partir de 1 à 2 Cd (ou peut-être qu'il ne l'ait pas fait?).

Évidemment, je ne suis pas assez familier avec le C/C++ pour obtenir cette blague, mais ce qui semble le plus étrange, c'est que le 2ème exemple de code semble plus "propre"—au moins de ce que j'ai dit à l'école (c'est que l'initialisation des variables est une bonne chose, pas une mauvaise).

Answer 1

De l'OCI, c'est un code source-le taux de désabonnement problème

À première vue, les deux formes sont équivalentes. Le second n'a pas l'air agréable, mais ils font la même chose.

Mais ensuite j'ai lu la page citée.

Le problème est que la nouvelle de guy de concocter l'arbre source, beaucoup d'elle. Il est mal vu de troll par un géant de l'arbre source et de faire un changement de sens. Bien sûr, peut-être un style est légèrement meilleure que l'autre, mais dans la pratique, il devrait être beaucoup mieux avant de mettre de 1 000 deltas dans un système de contrôle de code source pour les personnes à parcourir pour l'éternité est justifiée.

Je soupçonne que cela a été une source de libération, ou certains autres sous silence complexité de l'édition de nombreux dossiers à développer leur distribution. Les contributions à ce site sont édités tout à fait un peu, mais, fondamentalement, la question est compréhensible sans les détails.

L'un des problèmes avec l'édition d'une foultitude de fichiers pour un changement de style, c'est que la chance d'une erreur d'inadvertance augmente. Ce risque est considérablement multiplié lorsqu'un développeur junior t-il. Même pour les plus expérimentés, il y a la loi de Murphy à prendre en compte. Si cela se produit juste avant une libération c'est vraiment une pendaison de l'infraction.

Answer 2

Selon le compilateur et les options du compilateur, de l'initialisation comme ceci

char data_string[15] = "data data data";

les résultats dans beaucoup de déplacer les instructions pour copier les données littérales de la pile.

Appelant strcpy nécessite moins d'instructions.

Faire ce genre de chose tous sur une grande base de code peut augmenter la taille du binaire de manière significative.

Et bien sûr, il n'était pas passer son temps sur l'ajout de n'importe quelle valeur.

Answer 3

2ème code est en effet plus "propre", mais avec un projet de la taille de l'article, il est ridicule de penser refactoring comme ça, c'est au mieux inutile, au pire des erreurs.

Cependant ce type de refactoring ne pas gonfler un .Exe la taille, la forme 1 de 2 cd

Answer 4

Je ne peux pas obtenir un comportement différent de cela. Je l'ai essayé avec LLVM: j'ai dû ajouter un peu de trucs à la valeur de retour de sorte que LLVM n'optimisent pas tout de suite, mais le code généré pour l' wtf et wtf2 sont totalement identiques. Ce wtf est BAAAAAD

Entrée

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int wtf(int X) {
  int x;
  char data_string[15];
  x = 2;
  strcpy(data_string,"data data data");
  return 5*X+x+ data_string[X];
}
int wtf2(int X) {
  int x = 2;
  char data_string[15]="data data data";
  return 5*X+x+ data_string[X];
}
int main(int argc, char **argv) {
  printf("%d\n", wtf(atoi(argv[1]))+wtf2(atoi(argv[1])));
}

Sortie:

; ModuleID = '/tmp/webcompile/_3856_0.bc'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"
@.str = internal constant [15 x i8] c"data data data\00"    	; <[15 x i8]*> [#uses=3]
@.str1 = internal constant [4 x i8] c"%d\0A\00" 	; <[4 x i8]*> [#uses=1]

define i32 @wtf(i32 %X) nounwind readnone {
entry:
    %0 = mul i32 %X, 5		; <i32> [#uses=1]
    %1 = getelementptr [15 x i8]* @.str, i32 0, i32 %X		; <i8*> [#uses=1]
    %2 = load i8* %1, align 1		; <i8> [#uses=1]
    %3 = sext i8 %2 to i32		; <i32> [#uses=1]
    %4 = add i32 %0, 2		; <i32> [#uses=1]
    %5 = add i32 %4, %3		; <i32> [#uses=1]
    ret i32 %5
}

define i32 @wtf2(i32 %X) nounwind readnone {
entry:
    %0 = mul i32 %X, 5		; <i32> [#uses=1]
    %1 = getelementptr [15 x i8]* @.str, i32 0, i32 %X		; <i8*> [#uses=1]
    %2 = load i8* %1, align 1		; <i8> [#uses=1]
    %3 = sext i8 %2 to i32		; <i32> [#uses=1]
    %4 = add i32 %0, 2		; <i32> [#uses=1]
    %5 = add i32 %4, %3		; <i32> [#uses=1]
    ret i32 %5
}

define i32 @main(i32 %argc, i8** nocapture %argv) nounwind {
entry:
    %0 = getelementptr i8** %argv, i32 1		; <i8**> [#uses=1]
    %1 = load i8** %0, align 4		; <i8*> [#uses=1]
    %2 = tail call i32 @atoi(i8* %1) nounwind readonly		; <i32> [#uses=2]
    %3 = getelementptr [15 x i8]* @.str, i32 0, i32 %2		; <i8*> [#uses=1]
    %4 = load i8* %3, align 1		; <i8> [#uses=1]
    %5 = sext i8 %4 to i32		; <i32> [#uses=1]
    %tmp2 = mul i32 %2, 10		; <i32> [#uses=1]
    %6 = shl i32 %5, 1		; <i32> [#uses=1]
    %7 = add i32 %6, 4		; <i32> [#uses=1]
    %8 = add i32 %7, %tmp2		; <i32> [#uses=1]
    %9 = tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr ([4 x i8]* @.str1, i32 0, i32 0), i32 %8) nounwind		; <i32> [#uses=0]
    ret i32 undef
}

declare i32 @atoi(i8*) nounwind readonly

declare i32 @printf(i8*, ...) nounwind

Answer 5

Euh, re lire l'article :)

Le vrai WTF est qu'il a touché l'ensemble de la solution avec ces types de changements alors qu'il était censé résoudre une fuite de mémoire.

Également de faire un changement de tout cela ne serait pas beaucoup d'importance, sauf éventuellement la rupture/introduire des bogues dans d'autres, peut-être plus compliquée fichiers, que l'exemple d'une.