[llvm-commits] [PATCH] StringRef class.

[Daniel Dunbar]

Hi,

The attached patch provides a new StringRef helper class, which is
used to represent a constant string (pointer & length) which is not
owned.

This class is not intended for direct use, rather it is a way to have
uniform and efficient APIs. For example, this code in llvm/Value.h:
--
  /// getNameStart - Return a pointer to a null terminated string for this name.
  /// Note that names can have null characters within the string as well as at
  /// their end.  This always returns a non-null pointer.
  const char *getNameStart() const;
  /// getNameEnd - Return a pointer to the end of the name.
  const char *getNameEnd() const { return getNameStart() + getNameLen(); }

  /// isName - Return true if this value has the name specified by the provided
  /// nul terminated string.
  bool isName(const char *N) const;

  /// getNameLen - Return the length of the string, correctly handling nul
  /// characters embedded into them.
  unsigned getNameLen() const;

  /// getName()/getNameStr() - Return the name of the specified value,
  /// *constructing a string* to hold it.  Because these are guaranteed to
  /// construct a string, they are very expensive and should be avoided.
  std::string getName() const { return getNameStr(); }
  std::string getNameStr() const;


  void setName(const std::string &name);
  void setName(const char *Name, unsigned NameLen);
  void setName(const char *Name);  // Takes a null-terminated string.
--
becomes:
--
  StringRef getName() const;

  void setName(const StringRef &);
--
without any loss in efficiency (assuming a sufficiently smart
compiler), and an increase in convenience.

The downside is that combining unowned memory and implicit
construction provides some opportunities for shooting oneself in the
foot. To mitigate this risk, the general idiom is that one should
generally avoid explicitly naming the StringRef and only use it as a
compiler generated temporary. Storage of a StringRef should be limited
to contexts when the reference strings are available in some long term
storage (like a MemoryBuffer). Overall I think this is a good
compromise, and will allow us to have cleaner, more uniform, and
somewhat more efficient APIs, with a minimum of risk.

Comments?

 - Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StringRef.patch
Type: application/octet-stream
Size: 5622 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090720/e49f069a/attachment.obj>