What are the benefits to using string datatypes over bytes32 to represent text data. It seems my contract runs into an out of gas exception when I switch the data structures from bytes32 to string.
Why string instead of bytes32?
Use string for arbitrary-length string (UTF-8) data that's longer than 32 bytes. Frontends can decode a long string easier using methods like web3.toAscii or UTF-8 (when issues are fixed), instead of implementing the logic of UTF-8 decoding a series of bytes32.
From Solidity docs:
As a rule of thumb, use
bytesfor arbitrary-length raw byte data andstringfor arbitrary-length string (UTF-8) data. If you can limit the length to a certain number of bytes, always use one ofbytes1tobytes32because they are much cheaper.
String literals may also be helpful or convenient:
String literals are written with either double or single-quotes ("foo" or 'bar')...
String literals support escape characters, such as \n, \xNN and \uNNNN. \xNN takes a hex value and inserts the appropriate byte, while \uNNNN takes a Unicode codepoint and inserts an UTF-8 sequence.
Why bytes32 instead of string?
Answered in Why do Solidity examples use bytes32 type instead of string?
bytes32 uses less gas because it fits in a single word of the EVM, and string is a dynamically sized-type which has current limitations in Solidity (such as can't be returned from a function to a contract).
-
I am not sure if I understood the last sentence - string return types work in current Solidity compiler. – Mikko Ohtamaa Jan 21 '17 at 10:10
-
2@MikkoOhtamaa Emphasis is to a contract: I don't think ethereum.stackexchange.com/a/3788/42 is supported yet. – eth♦ Jan 21 '17 at 13:53
-
Ok so if you have a controlling contract and it's accessing data from another contract which is returning text that is longer than 32 bytes, you would need to return it in a bytes32 array? – ethereal Jan 22 '17 at 17:54
-
@ethereal Sounds right, give a size to the array like bytes32[3]. There may be assembly ways to get the size of the data being returned and avoiding a hardcoded size, for example the contracts in github.com/ownage-ltd/ether-router – eth♦ Jan 25 '17 at 0:50
-
If a contract cannot access another contract's string variables, then what can? Can web3? What if I want to store a list or array of 60-character strings, but I will need to access them from another contract or program, how do I do it? – Curt Aug 4 '17 at 1:59
Like the other post said, you only want to use strings for dynamically allocated data, otherwise Byte32 is going to perform better. Bytes32 is also going to be better in gas. If you want to play around with it, I built a little fiddle of it https://ethfiddle.com/70ipaEIFdk
Byte used 21465 gas
String used 21897 gas
pragma solidity ^0.4.18;
contract SampleOverflow {
string constant statictext = "HelloStackOverFlow";
bytes32 constant byteText = "HelloStackOverFlow";
function getString() payable public returns(string){
return statictext;
}
function getByte() payable public returns(bytes32){
return byteText;
}
}
Get Byte
Get String
https://ethfiddle.com/70ipaEIFdk
-
that fiddle doesn't work. I think it's to do with the escaped double quotes. I tried removing escape caharacters but eth fiddle didnt liek that either.. Here's your example working ethfiddle.com/SeXTGt-AWi – Damian Green Dec 30 '17 at 15:25
