Die Verwendung von constructor () und der Fallback-Funktion im selben Vertrag führt zu Fehlern

Ich versuche etwas zu kompilieren, das ein Muster wie dieses widerspiegelt, und erhalte beim Remix den folgenden Fehler:

"browser / ballot.sol: 26: 3: DeclarationError: Funktion mit demselben Namen und Argumenten, die zweimal definiert wurden. constructor () public {^ (Relevanter Quellteil beginnt hier und erstreckt sich über mehrere Zeilen). browser / ballot.sol: 31: 3 : Eine andere Erklärung ist hier: function () public payable {} ^ -------------------------- ^ "

der Code (wenn ich die zweite Fallback-Funktion auskommentiere, funktioniert es):

 pragma solidity ^ 0.4 . 0 ; contract C { address public  owner ; address public  creator ; 

   constructor   ( address _creator )   public   { owner =  tx . origin ; creator =  _creator ; 
   } 

   function ()   public  payable {} 

   function  printOwner ()   public  view returns ( address h )   { h =  owner ; 
   } 

 } 

 //factory contract for C contract CFactory   { address public  owner ; address public  currentContractAddress ; 

   constructor ()   public   { owner =  msg . sender ; currentContractAddress =  address ( this ); 
   } 

   //function() public payable {} 

   function  test1 ()   public  returns ( address ){ C c =   new  C ( currentContractAddress ); 
     return  c . printOwner (); 
   } 

 } 

Antworten (1)

Das Problem ist, dass es nicht kompiliert wird.

constructor . Das ist falsch. In solc 0.4.22 kann man function constructor() sagen, ist aber neu (heute), daher habe ich die traditionellere Methode " solc 0.4.22 Name als Vertrag" verwendet.

tx.orgin ist ein Sicherheitsrisiko, daher wurde es mit einem Pass-Through-Muster in msg.sender geändert.

 pragma solidity ^ 0.4 . 17 ; contract C { address public  owner ; address public  creator ; 

   function  C ( address _creator ,  address _owner )   public   { owner =  _owner ; creator =  _creator ; 
   } 

   function ()   public  payable {} 

   function  printOwner ()   public  view returns ( address h )   { h =  owner ; 
   } 

 } 

 //factory contract for C contract CFactory   { address public  owner ; address public  currentContractAddress ; 

   function   CFactory ()   public   { owner =  msg . sender ; currentContractAddress =  address ( this ); 
   } 

   //function() public payable {} 

   function  test1 ()   public  returns ( address ){ C c =   new  C ( currentContractAddress ,  msg . sender ); 
     return  c . printOwner (); 
   } 

 } 

Ich hoffe es hilft.

Danke, ich sehe, dass es mit alter Syntax funktioniert. Remix fordert mich auf, constructor () zu verwenden, wie in den Dokumenten solidity.readthedocs.io/en/v0.4.22/contracts.html erläutert. Wird es funktionieren, wenn ich nur eine kostenpflichtige Fallback-Funktion verwenden würde? Ich habe tx.origin nur verwendet, um den Eigentümer zum Zeitpunkt der Erstellung festzulegen. Ich würde es nicht verwenden, um Berechtigungen in Funktionen zu überprüfen. Wird es trotzdem eine Sicherheitslücke sein?
Möglicherweise irre ich mich über die neue Konstruktorsyntax. tx.origin ist immer ein Sicherheitsrisiko in der Liste "Nicht verwenden". Die Art und Weise, wie ich umgestaltet habe, entspricht genau dem, was Sie zuvor hatten, genau wie beabsichtigt, ohne das Risiko. Ich bin mir nicht sicher, was Sie mit dem zahlbaren Fallback anfangen wollen. Vertrag C schluckt einfach Geld, ohne dass es möglich ist, es abzuheben. Es ist schwer zu sagen, wohin du damit gehst.
Beide Verträge enthalten eine zahlbare Funktion und eine Rücknahme- und / oder Selbstzerstörungsfunktion. Ich könnte die zahlbare Funktion tatsächlich problemlos aus dem Vertrag entfernen. Aber jetzt wundere ich mich über den Fehler, den ich zuvor beschrieben habe. Ich würde gerne wissen, ob ich etwas falsch verstanden habe, wie die Crontracts und die Fallback-Funktion funktionieren
Ich denke, Sie müssen es als neue Frage wiederholen.
Ich weiß, wahrscheinlich war ich unklar. Das Problem ergibt sich aus der Tatsache, dass Konstruktor () und Funktion () in denselben Hash übersetzt werden, sodass sie unterschiedliche Parameter haben müssen. An diesem Punkt bin ich mir nicht sicher, ob dies ein unerwartetes Verhalten ist oder ob es absichtlich erfunden wurde. Ich werde auf die Fallback-Funktion verzichten, da sie in meinem Fall nicht relevant ist