[llvm-dev] Why StringRef is not a ArrayRef<char>
67 views
Skip to first unread message
Paweł Bylica
Nov 5, 2015, 11:58:18 AM11/5/15
to llvm-dev
Hi,
Why is StringRef not an ArrayRef<char> extension? That might simplify some interfaces.
Cheers,
Paweł
Ramkumar Ramachandra via llvm-dev
Nov 6, 2015, 9:08:33 AM11/6/15
to Paweł Bylica, llvm-dev
I think it's the same difference we have between int * and
ArrayRef<int>, for instance. If you have a raw pointer, you are
expected to keep track of the size out-of-band. In aggregate types,
size is part of the type, making it very difficult to confuse a [1 x
i8] with a [3 x i8]. Many people probably use the raw pointer as a way
to hold a reference to dynamically allocated memory, and as a
type-escape hatch.
ArrayRef<int>, for instance. If you have a raw pointer, you are
expected to keep track of the size out-of-band. In aggregate types,
size is part of the type, making it very difficult to confuse a [1 x
i8] with a [3 x i8]. Many people probably use the raw pointer as a way
to hold a reference to dynamically allocated memory, and as a
type-escape hatch.
> _______________________________________________
> LLVM Developers mailing list
> llvm...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Joerg Sonnenberger via llvm-dev
Nov 6, 2015, 9:24:48 AM11/6/15
to llvm...@lists.llvm.org
On Fri, Nov 06, 2015 at 09:07:43AM -0500, Ramkumar Ramachandra via llvm-dev wrote:
> I think it's the same difference we have between int * and
> ArrayRef<int>, for instance. If you have a raw pointer, you are
> expected to keep track of the size out-of-band. In aggregate types,
> size is part of the type, making it very difficult to confuse a [1 x
> i8] with a [3 x i8]. Many people probably use the raw pointer as a way
> to hold a reference to dynamically allocated memory, and as a
> type-escape hatch.
> I think it's the same difference we have between int * and
> ArrayRef<int>, for instance. If you have a raw pointer, you are
> expected to keep track of the size out-of-band. In aggregate types,
> size is part of the type, making it very difficult to confuse a [1 x
> i8] with a [3 x i8]. Many people probably use the raw pointer as a way
> to hold a reference to dynamically allocated memory, and as a
> type-escape hatch.
StringRef is explicitly sized. I'd be more interested in which
interfaces are actually simplified by implicit or explicit conversions
between StringRef and ArrayRef<char>.
Joerg
Paweł Bylica
Nov 6, 2015, 9:42:34 AM11/6/15
to Joerg Sonnenberger, llvm...@lists.llvm.org
On Fri, Nov 6, 2015 at 3:24 PM Joerg Sonnenberger via llvm-dev <llvm...@lists.llvm.org> wrote:
On Fri, Nov 06, 2015 at 09:07:43AM -0500, Ramkumar Ramachandra via llvm-dev wrote:
> I think it's the same difference we have between int * and
> ArrayRef<int>, for instance. If you have a raw pointer, you are
> expected to keep track of the size out-of-band. In aggregate types,
> size is part of the type, making it very difficult to confuse a [1 x
> i8] with a [3 x i8]. Many people probably use the raw pointer as a way
> to hold a reference to dynamically allocated memory, and as a
> type-escape hatch.
StringRef is explicitly sized. I'd be more interested in which
interfaces are actually simplified by implicit or explicit conversions
between StringRef and ArrayRef<char>.
I was thinking about mixing SmallVector<> with ArrayRef<>. E.g. to have SmallVector<>::assign(ArrayRef<>). That probably should be my first question. I just realized that ArrayRef and SmallVector are not directly related.
Having the interface above, SmallVector<char> would not work with StringRef.
Having the interface above, SmallVector<char> would not work with StringRef.
- Paweł
Reply all
Reply to author
Forward
0 new messages