1Differences with beres/deres 2############################ 3 4Some of your old rdef files may fail to compile with rc. Besides different command line arguments, 5rc also has slightly different syntax and semantics. These changes were made to allow for the future 6expansion of the rdef grammar and to make resource scripts easier to write and understand. The 7compiler should be backwards compatible with the majority of old scripts, but in some cases it was 8necessary to break stuff. 9 10Differences with beres 11====================== 12 13We allow the \0 escape in string literals. 14 15Our handling of the minus sign is more restrictive; we don't treat it like a unary minus operator, 16which means you may only put one minus in front of a number to negate it (i.e. "- -10" is an error). 17 18beres allows #define statements, but apparently ignores them. The compiler reports no error, but 19any symbols you define are not recognized later on. We don't allow #defines (yet). 20 21beres allows you to put enum symbols in resource data, and replaces the symbol with its value. For 22some reason, it lets you assign any kind of data to enum symbols, such as strings and floats. Since 23that is not valid C/C++ syntax, librdef does not allow this. As a result, it does not make much 24sense for us to support enum symbols in resource data. 25 26We only allow a few type casts, but enough to be backwards compatible. beres allows you to cast 27from bool to all other types, between strings and numeric types, etc. The usefulness of this is 28limited, so to keep things simple librdef doesn't allow that. 29 30There is no need to put parentheses around a type code, even for simple data; beres sometimes 31requires the parens and sometimes it doesn't. With rc, they are always optional (preferred notation 32is without the parens). 33 34beres allows multiple type codes and/or type casts per resource statement/data field, but we allow 35only one of each. Because we don't associate type codes with data (but only with the resource 36itself or with individual message fields), we don't allow the shortcut notation that lets you put a 37type code and cast inside one set of parentheses. 38 39We do not allow arrays to have named fields, nor do we allow messages (and archives) to have 40unnamed fields. beres apparently treats all compound data the same, but we don't, because not all 41compound data is the same. 42 43When specifying array data, the "array" keyword is required. beres allows you to omit the array 44keyword and just put the data between braces, but that conflicts with our handling of user-defined 45types. 46 47Field names in message resources may only be string literals. beres allows identifiers but it 48converts them to string literals anyway. Just like normal data, you may cast the field's data to a 49different type, but not to a different type code. Specifying a non-standard type code is fine, but 50it goes in front of the type name. Just like beres, rc considers "array", "message", and "archive" 51to be valid data type names, but "message" and "archive" cannot be followed by a "what" code 52(beres ignores that anyway). When you cast an archive to a message, we don't strip the "class" 53field (in fact, we don't perform any conversion). 54 55We allow users to define their own types. The built-in types from beres (point, rect, and rgb_color) 56are re-implemented as such user-defined types. The syntax for these three built-ins should still be 57backwards compatible with old scripts. 58 59beres automatically adds names for resources that are specified as "resource(R_Symbol)", unless the 60"explicit names only" option is set. We do that the other way around: we don't automatically add 61names unless the user sets the "auto names" option. 62 63Differences with deres 64====================== 65 66We do not write the "generated at" time into the files. 67 68Type codes that cannot be represented as #'xxxx' are written as #num where num is a decimal number, not hexadecimal. 69 70Floats and doubles have a bunch of extra zeroes. 71 72Hex numbers are always uppercase. 73 74We may render string literals somewhat differently. 75 76We only write a header file if the "auto names" option is set. 77 78